Post by Stefan Wahren
Post by Sergey Suloev Post by Stefan Wahren
can any give any hint about the status of bcn2835 cpufreq in mainline
in short: currently no support yet
Are you (or anyone else) working on it ?
No, this not on my TODO list .
- 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?
 - https://github.com/lategoodbye/rpi-zero/issues
well, that seems to be a lot of work.
maybe less than you think (apart from testing).
Post by Sergey Suloev
Is the following patch an attempt of porting the driver ?
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.