mainline kernel: cpufreq for bcm2835

Discussion:

Stefan Wahren

2018-04-02 16:09:03 UTC

Permalink

Hi Sergey,

[add linux-rpi-kernel]

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

Peter Robinson

2018-04-02 16:21:13 UTC

Permalink

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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].
- 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?

It's probably one of the most complained about things I get on Fedora
along side the touch screen and camera. It's on my list to try and get
working but I've not had huge luck. The downstream driver builds, but
complains about being unable to find the firmware when I load it as a
module. The firmware interface is built in (it has to be for things
like usb power) so by the time userspace is running in level 3 I would
have though the firmware interface would be available, I've not had
time to debug it further than that. Can provide more details later in
the week if it's helpful.

Peter

Stefan Wahren

2018-04-02 16:41:47 UTC

Permalink

Hi Peter,

Post by Peter Robinson

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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 ?

It's probably one of the most complained about things I get on Fedora
along side the touch screen and camera.

at least for the touch screen there is a panel driver and a DT snippet (Eric prefer an overlay).

Since the camera requires VCHIQ the corruption should be fixed before.

Post by Peter Robinson
It's on my list to try and get
working but I've not had huge luck. The downstream driver builds, but
complains about being unable to find the firmware when I load it as a
module.

one issue with the downstream driver is the lack of DT operating points [1],
but this is not related to your issue.

Stefan

[1] - https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/opp/opp.txt?h=next-20180329

Post by Peter Robinson
The firmware interface is built in (it has to be for things
like usb power) so by the time userspace is running in level 3 I would
have though the firmware interface would be available, I've not had
time to debug it further than that. Can provide more details later in
the week if it's helpful.
Peter

Sergey Suloev

2018-04-02 17:14:10 UTC

Permalink

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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 ?

Thanks

well, that seems to be a lot of work.

Is the following patch an attempt of porting the driver ?

http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-October/002402.html

Thank you for details.

Stefan Wahren

2018-04-02 20:02:22 UTC

Permalink

Hi Sergey,

Post by Sergey Suloev

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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 ?

Thanks

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 ?
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.

Best regards
Stefan

Post by Sergey Suloev
Thank you for details.

Sergey Suloev

2018-04-02 21:15:48 UTC

Permalink

Hi Stefan

Post by Stefan Wahren
Hi Sergey,

Post by Sergey Suloev

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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 ?

Thanks

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 ?
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?
- 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.
Best regards
Stefan

Post by Sergey Suloev
Thank you for details.

I tried to do a quick test and looked at cpufreq-dt driver. It seems to
require an explicitly set CPU clock but there is nothing set in the
existing device trees like bcm2837.dtsi.

Eric Anholt

2018-04-02 23:17:40 UTC

Permalink

Post by Stefan Wahren
Hi Sergey,

Post by Sergey Suloev

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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 ?

Thanks

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 ?
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.

Sergey Suloev

2018-04-02 19:52:25 UTC

Permalink

Hi Stefan

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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 ?

Thanks

do you know a resource where OPP table for RPi3 can be obtained from ?

Stefan Wahren

2018-04-02 20:08:37 UTC

Permalink

Hi Sergey,

Hi Stefan

Post by Stefan Wahren
Hi Sergey,
[add linux-rpi-kernel]

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 ?

Thanks

do you know a resource where OPP table for RPi3 can be obtained from ?

use the downstream kernel, select the userspace governor and get the values from the sysfs. For the first steps you could use min and max frequency.

Best regards
Stefan