Re: [PATCH] [RFC] ARM: shmobile: koelsch-reference: Work around core clock issues

[Ben Dooks <ben.dooks@codethink.co.uk>]

On 14/03/14 17:55, Ben Dooks wrote:
> On 14/03/14 17:33, Ben Dooks wrote:
>> On 14/03/14 16:48, Magnus Damm wrote:
>>> Hi Ben,
>>>
>>> That would not surprise me. But it would trigger both for
>>> multiplatform and legacy in such case, don't you think?
>>>
>>> If static enablement using the clock workaround fixes the
>>> multiplatform case then it is most likely related to that the driver
>>> assumes that Runtime PM controls the clock. Or perhaps some hidden
>>> clock dependency that only triggers with CCF?
>>
>> It seems very sensitive to code (or possibly compiler) in some but
>> not all cases we are seeing the system pm the device and then the
>> driver does something that requires clocks.
>>
>> At the moment the depending on how much debug it either works, or
>> does not.
>
> So far I am down to the following being executed
>
>          pm_runtime_enable(&pdev->dev);
>          pm_runtime_resume(&pdev->dev);
>
> and by the time it gets to:
>
>      read_mac_address(ndev, pd->mac_addr);
>
> the ethernet unit's clock has already been disabled.

 From investigation, the pm is running a work-queue that
is causing the clock to be disabled. The only thing I can
think is we need to change the

 >          pm_runtime_enable(&pdev->dev);
 >          pm_runtime_resume(&pdev->dev);

to include a pm_runtime_get_sync() call.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius