On Fri, Aug 19, 2016 at 10:28 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/19/2016 10:56 AM, Jagan Teki wrote:
On 18 August 2016 at 22:23, 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.
Do we need to set the clock for claim_bus() as well? I think it's better to move this on to set_speed so-that any call to set_speed() will update the same. I don't think claim_bus would require this again.
I explained this in the commit message: The clock rate needs to be set in claim_bus() so that the frequency requested by set_speed() is in force.
Usually I would rather skip the claim_bus for setting freq, if any call to set_speed I took the speed and evaluate the desired/correct freq and set the same in set_speed it self. This is because frequent calls to calm_bus does the same frequency init for respective transactions.