Jagan,
I've got to get a PR into TomR, so I'm including the Tegra SPI fix from Stephen. Hope this doesn't cause you any problems.
Tom
-----Original Message----- From: Tom Warren Sent: Thursday, August 25, 2016 1:52 PM To: Jagan Teki (jteki@openedev.com) jteki@openedev.com Cc: U-Boot Mailing List u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; Mirza Krak mirza.krak@hostmobility.com; Stephen Warren swarren@wwwdotorg.org; 'Simon Glass' sjg@chromium.org Subject: RE: [PATCH] spi: tegra: fix hand in set_mode()
Jagan,
Are you planning on taking this in via the SPI repo, or can I take it in to Tegra?
Tom
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Saturday, August 20, 2016 7:17 PM To: Simon Glass sjg@chromium.org Cc: U-Boot Mailing List u-boot@lists.denx.de; Jagan Teki jteki@openedev.com; Tom Warren TWarren@nvidia.com; Stephen
Warren
swarren@nvidia.com; Mirza Krak mirza.krak@hostmobility.com Subject: Re: [PATCH] spi: tegra: fix hand in set_mode()
On 08/20/2016 05:52 PM, Simon Glass wrote:
Hi Stephen,
On 18 August 2016 at 10:53, Stephen Warren swarren@wwwdotorg.org
wrote:
From: Stephen Warren swarren@nvidia.com
In tegra20_slink.c, the set_mode() function may be executed before the SPI bus is claimed the first time, and hence the clocks to the SPI controller may not be running. If so, any register read/write at this time will hang the CPU. Fix this by ensuring the clock is running as soon as the driver is probed. This is observed on the Tegra30
Beaver board.
Apply the same clock initialization fix to all other Tegra SPI drivers so that if set_mode() is ever implemented there, the same bug will
not appear.
Note that tegra114_spi.c already operates in this fashion.
The clock manipulation code is copied from claim_bus() to probe() rather than moved. This ensures that any calls to set_speed() take effect; the clock can't be set once during probe and left unchanged.
Fixes: 5cb1b7b395c0 ("spi: tegra20: Add support for mode selection") Cc: Mirza Krak mirza.krak@hostmobility.com Signed-off-by: Stephen Warren swarren@nvidia.com
drivers/spi/tegra20_sflash.c | 4 ++++ drivers/spi/tegra20_slink.c | 4 ++++ drivers/spi/tegra210_qspi.c | 3 +++ 3 files changed, 11 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
You might consider storing the mode and not acting on it until later. But this is fine.
I did that in previous patch (I suppose you could call it V1, but it was so different in implementation that I didn't), but Jagan asserted that claim_bus() isn't the correct place to process the mode value, and that's the place any deferred value would need to be applied.
-- nvpublic