[U-Boot] [PATCH] spi: tegra: fix hand in set_mode()

[Jagan Teki]

On Fri, Aug 19, 2016 at 10:28 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 08/19/2016 10:56 AM, Jagan Teki wrote:
>>
>> On 18 August 2016 at 22:23, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>
>>> From: Stephen Warren <swarren at 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.

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.