Re: Is exporting __clk_notify() acceptable?

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

 



Quoting Nicolas Saenz Julienne (2019-04-11 10:43:22)
> Hi,
> I'm working on implementing proper cpufreq support for Raspberry Pi and stumbled
> upon an issue I'd like your opinion on:

You may want to work with Eric. I think Eric has been looking at
Raspberry Pi clk things from what I can recall.

> 
> - Raspberry Pi's boot and other internal operations are operated by a firmware
>   running in it's VPU/GPU (called Video Core 4).
> 
> - Even though Raspberry Pi exports it's clock registers, we're unable to modify
>   them as we could clash with the firmware. Messing around with clocks behind
>   the firmware's back would potentially void the board's warranty or even break
>   it. So we're stuck using a firmware frequency scaling interface the board
>   provides.
> 
> - Some peripherals depend on VPU's clock (I2C, SPI, UART, ...). This clock is
>   updated by the firmware interface whenever we scale the frequency.

Ok. Got it.


> 
> - A solution would be to set all these clocks as non cachable, and alert the
>   peripherals through the clock notifier before and after the frequency scaling
>   happens. This way they could reprogram their dividers. It would be triggered
>   through a custom cpufreq driver that, with the knowledge of the possible VPU
>   frequencies, will pre-notify the peripherals, trigger the frequency scaling
>   and post-notify the peripherals. In order to achieve this, I figured I need
>   to create an exported version of __clk_notify(), which would trigger
>   notifications both for the provided clock and it's children.
> 
> In principle, would it be acceptable to export the function? Any alternatives?

I don't think we want to export __clk_notify(). If anything we've been
trying to slowly remove the notifier chains that the clk framework
implements, so exporting it would be going in the wrong direction.

> 
> Note that cpufreq notifiers are not an option as they provide the CPU clock
> change rates which are useless to the peripherals. Also note that the
> peripherals need to know the clock rate change in advance.
> 

How does it work today? Do the peripherals set clk rates under the
assumption that the parent of the clk they're dealing with (I guess VPU
clk?) isn't going to change rate?

If that's right then I see two pitfalls. The first is that we probably
want to maintain the frequency of those child clks when the VPU clk
changes rate. The second is that we should integrate the VPU clk into
the clk framework so that when it changes rate, the new frequency
propagates down to the child clks. It could still use the firmware
interface to change the VPU clk in the clk provider driver. I suppose
cpufreq-dt could be layered on top of the VPU clk too so that it all
just becomes a clk tree management problem.

After that's in place, I recommend that the downstream/child device
drivers using clks that are children of the VPU clk migrate to
clk_rate_exclusive_get() and clk_set_rate_exclusive() APIs. Once all the
child clks are "owning" the rate they want their clks to be at, then we
need to fix the clk framework rate setting code-path to let the parent
VPU clk change rates from CPUfreq and work out how to achieve the
"exclusive", i.e. "locked", rates for the children. If we do that then
we should be in good shape and we can let the VPU clk change rate while
maintaining the child clk rates for devices like UART, i2c, etc.





[Index of Archives]     [Linux Kernel Discussion]     [Linux RTC]     [Linux Year 2038 Problem]     [Ethernet Bridging]     [Linux Wireless Networking]     [Linux WPAN Networking]     [Linux Bluetooth Networking]     [Linux ATH6KL Networking]     [Linux Networking Users]     [Linux Coverity]     [Git]     [Security]     [Bugtraq]     [Yosemite Information]     [MIPS Linux]     [ARM Linux Kernel]     [ARM Linux]     [Linux Virtualization]     [Linux IDE]     [Linux RAID]     [Linux SCSI]

 /<.td> Powered by Linux