lkml.org 
[lkml]   [2019]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 1/2] soc/tegra: pmc: Query PCLK clock rate at probe time
From
Date
29.07.2019 16:07, Dmitry Osipenko пишет:
> 25.07.2019 14:15, Dmitry Osipenko пишет:
>> 25.07.2019 12:36, Peter De Schrijver пишет:
>>> On Tue, Jul 23, 2019 at 05:35:10AM +0300, Dmitry Osipenko wrote:
>>>> The PCLK clock is running off SCLK, which is a critical clock that is
>>>> very unlikely to randomly change its rate. It's also a bit clumsy (and
>>>> apparently incorrect) to query the clock's rate with interrupts being
>>>> disabled because clk_get_rate() takes a mutex and that's the case during
>>>> suspend/cpuidle entering.
>>>>
>>>
>>> SCLK and PCLK certainly can change rate at runtime, although the code to
>>> handle this hasn't reached upstream yet.
>>
>> Okay, maybe this patch is indeed not very worthwhile then. I'm leaving
>> it up to you, guys, to decide.
>>
>
> I now recalled what was the initial reason for this patch because
> happened to bump into the problem once again.. it's really problematic
> to call clk_get_rate() with the disabled preemption because some clk
> notifier handler may block (EMC) and cause reschedule, hence the CCF
> 'prepare' mutex is kept locked during of CPUIDLE driver entering LP2
> state and thus causing system lockup, since scheduling with the disabled
> interrupts obviously won't work well.
>
> So this patch actually is needed to be applied or some other solution
> have to be provided. Since PCLK rate currently isn't altering anywhere
> in the kernel, I'd suggest to imply apply this series. Please let me
> know if you have any objections. I may re-iterate this patch with an
> extended commit message, describing the resolved problem in a more
> details, if necessary.
>

I'll send v3 with a changed commit's message, please take a look at it.

\
 
 \ /
  Last update: 2019-07-30 19:41    [W:0.036 / U:2.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site