mainline kernel: cpufreq for bcm2835

[Eric Anholt]

Stefan Wahren <stefan.wahren at i2se.com> writes:

> Hi Sergey,
>
>> Sergey Suloev <ssuloev at orpaltech.com> hat am 2. April 2018 um 19:14 geschrieben:
>> 
>> 
>> On 04/02/2018 07:09 PM, Stefan Wahren wrote:
>> > Hi Sergey,
>> >
>> > [add linux-rpi-kernel]
>> >
>> >> Sergey Suloev <ssuloev at orpaltech.com> hat am 2. April 2018 um 17:45 geschrieben:
>> >>
>> >>
>> >> Hi Stefan
>> >>
>> >> can any give any hint about the status of bcn2835 cpufreq in mainline
>> >> kernel ?
>> > in short: currently no support yet
>> >
>> >> Are you (or anyone else) working on it ?
>> > No, this not on my TODO list [1].
>> >
>> > Current prio:
>> > - Raspberry Pi 3+
>> > - fixes and improvements for Raspberry Pi 3 DT
>> > - VCHIQ data corruption
>> >
>> > Implementing/Porting the cpufreq driver is only half of the work. Also all drivers which depend on the VPU core clock should be able to handle a frequency change (sdhost, i2c, aux uart comes to my mind). But i will be happy if somebody takes care of it.
>> >
>> > Is this a critical feature for you?
>> >
>> > Best regards
>> > Stefan
>> >
>> > [1] - https://github.com/lategoodbye/rpi-zero/issues
>> >
>> >>
>> >> Thanks
>> >>
>> well, that seems to be a lot of work.
>
> maybe less than you think (apart from testing).
>
>> 
>> Is the following patch an attempt of porting the driver ?
>> 
>> http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-October/002402.html
>
> No, this isn't a good starting point (please look at Stephen's
> comment, which still apply).
>
> My suggestion would be to use or extend the cpufreq-dt. I'm not sure
> that we can you use clk-bcm2835 or need a separate clock driver (via
> mailbox) which changes the VPU clock.
>
> @Eric: What's your opinion?
>
> The advantages of this approach: - no new binding required - in good
> case no cpufreq driver is necessary - chance of acceptance in mainline
> is very high
>
> AFAIK there is only a need to register the cpufreq-dt within the
> bcm2835 plaform code and provide the operation points.

If Linux wanted direct control of the CPU, bus, and/or SDRAM clocks
rather than having the firmware drive those changes, we'd need to at
least make sure that the VPU's
undervoltage/undercurrent/thermal-triggered changes of those clocks were
disabled somehow.  I know RPi wants to maintain control of those for
warranty purposes, rather than just trusting Linux.  I think you'd need
to come up with something that managed all of those and proposed an
interlock with the firmware to pass off that responsibility.  Also, IIRC
SDRAM rate changes are hard because you have to execute code from some
spare memory while the SDRAM is disabled.

If you want to use the existing FW support for allowing turbo, I'd
probably extend the FW driver to create a bus so that a cpufreq driver
could probe on the bus directly instead of needing a DT binding.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20180402/569da9d7/attachment.sig>