ENGR00311101 QSPI: i.MX6SX: fixed the random QSPI access failed issue

ENGR00311101 QSPI: i.MX6SX: fixed the random QSPI access failed issue

We found there is a low probability(5%) QSPI access timeout issue,
usually it happened on kernel boot stage, the first time kernel tried to
access QSPI chip. The READ_ID command was sent but not executed,
consequently the probe function failed.

Finally we located the issue by these steps.

1. Since the issue happened randomly and usually it cost half day to
reproduce, we add more debug code in driver, to create a timeout file if
the issue occurred.

2. Prepared an autorun script to keep rebooting the system and check if
the timeout file existed, if the file existed, stop reboot.

3. The system will stop rebooting when timeout error occurred, set the
CCM_CCOSR register and related IOMUX to measure QPSI clock, found there
is no clock output, while clock output can be measured when QSPI driver
successfully probed.

4. Check the code and found QSPI clock rate was changed while not
disabled clock gate, most of the multiplexers on i.MX6 are glitch ones,
clock glitch may occurred and propagated into downstream clock dividers

Based on the new clock flag(CLK_SET_RATE_GATE) and new framework, we
need to change the approach of seting clock rate. In current
implementation, there are several places in which the clock was touched.

1. probe function. prepare and enable clock before setting the QSPI
register, disable and unprepare the clock before exit.

2. nor_setup & nor_setup_last, since we change clock rate in these two
functions.

3. fsl_qspi_prep and fsl_qspi_unprep, clock was enabled only when got
QSPI access request.

4. resume function. Clock was required to restroe the setting after
resume, disable the clock before exit.

Signed-off-by: Allen Xu <b45815@freescale.com>
(cherry picked from commit 04b31985952a4a8ba226d7bac474f70a95f5e674)