spi: spi-cadence-quadspi: Fix ospi resume failures conflicts

[Portia Stephens]

jammy:xilinx-zynqmp is carrying a patch subject "spi: spi-cadence-quadspi: Fix ospi resume failure" from the Xilinx tree , branch xlnx_rebase_v5.15_LTS_2022.1_update . This commit hasn't been upstreamed and completely rewrites the function cqspi_resume(). A change has landed in the v5.15.111 upstream stable release which conflicts with this Xilinx patch in such a way that we don't know how to resolve the conflicts and keep the functionality intact.

We have found where Xlinx resolved the merge on the XIlinx 6.1 branch but it doesn't seem correct. In the original commit:

(https://github.com/Xilinx/linux-xlnx/commit/6edac18033db445439ca57c23b8cee29a6bbdf0f)

in the function cqspi_resume() , the call to cqspi_controller_enable() is removed and ZynqMP specific controls are added. Upstream fixed an issue with suspend-resume (https://github.com/torvalds/linux/commit/2087e85bb66ee3652dafe732bb9b9b896229eafc). The upstream fix replaces the cqspi_controller_enable() with some clock initializations and a call to cqspi_controller_init() which does some register writes before calling cqspi_controller_enable(). Xilinx resolve the conflict by concatenating the two commit's changes to
cqspi_resume() (https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v6.1_LTS_2023.1_update/drivers/spi/spi-cadence-quadspi.c#L2271), the end result is that cqspi_resume() consists of ZynqMP specific controls followed by a (nested) call to cqspi_controller_enable(), the exact function call that was removed in XIlinx's original commit.

This bug is to track how this merge conflict is resolved.

[Radhey Shyam Pandey (radheys)]

The conflict resolved in 2023.1_update branch is basically merging xilinx and upstream resume implementation. In cqspi_resume() I see that below code sequence[1] is called twice which can be optimized but is functionally working as reported by the internal regression team.

[1]
cqspi_controller_init(cqspi);
cqspi->current_cs = -1;
cqspi->sclk = 0;

I had also discussed this merge conflict with the driver owner and he confirmed that the merge commit published to 2023.1_update should functionally work as we are calling _init with the same values so should not have any side effects.

Now there are two choices -
a) Continue to use merge resolution published to the 2023.1_update branch.
b) Use the below optimize fix for cqspi_resume.

static int cqspi_resume(struct device *dev)
{
        struct cqspi_st *cqspi = dev_get_drvdata(dev);
        struct spi_master *master = dev_get_drvdata(dev);
        u32 ret;

 clk_prepare_enable(cqspi->clk);
        cqspi_wait_idle(cqspi);
        cqspi_controller_init(cqspi);
        cqspi->current_cs = -1;
        cqspi->sclk = 0;
        cqspi->extra_dummy = false;
        cqspi->clk_tuned = false;

        ret = cqspi_setup_flash(cqspi);
        if (ret) {
                dev_err(dev, "failed to setup flash parameters %d\n", ret);
                return ret;
        }

        ret = zynqmp_pm_ospi_mux_select(cqspi->pd_dev_id,
                                        PM_OSPI_MUX_SEL_LINEAR);
        if (ret)
                return ret;

        /* Set the direction as output and enable the output */
        gpio_direction_output(cqspi->gpio, 1);
        udelay(1);

        /* Set value 0 to pin */
        gpio_set_value(cqspi->gpio, 0);
        udelay(10);

 /* Set value 1 to pin */
        gpio_set_value(cqspi->gpio, 1);
        udelay(35);

        return spi_master_resume(master);
}