Re: [PATCH 3/3] cpufreq: exynos: Add exynos5420 cpufreq driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 10, 2013 at 10:02 PM, Lukasz Majewski
<l.majewski@xxxxxxxxxxx> wrote:
>>
>> Actually these values are not for PLL, but for the dividers.
>> If you see below, the PLL rate setting is done through clk_set_rate()
>> going via CCF. But I found an issue if the divider values are set via
>> clk_set_rate API.
>> What I found is, the system goes into freeze if all the divider
>> values are not set in one shot. So we cannot call multiple
>> clk_set_rate()'s on each divider. Thats why I continued with non-CCF
>> way of setting the divider.
>
> I see. I'm not an expert on common clock framework (CCF), but for me
> conceptually clock dividers setting shall be handled by CCF.
>
> However, I've poked a bit at CCF. There isn't any out of the box
> solutions available.
>
> A "virtual" clock can be defined and inside its implementation we can
> atomically set dividers. Another solution would be to hack the current
> CCF to provide atomic clock operations
>
CCF isn't only for clocks that have single divider or gate control
register. One could define a clock that manipulates more than one
divider/gate in one CCF callback. It is already abstract enough. So
implementing a virtual clock is the solution, imho.
 BTW, on my platform linux needs to send a 'non-atomic' IPC message to
a master co-processor to scale up/down cpufreq. I just define a
virtual clock and use the generic bL cpufreq driver
drivers/cpufreq/arm_big_little.c
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux