[RFC,v2,0/5] cpufreq support for the Raspberry Pi

Message

Nicolas Saenz Julienne May 20, 2019, 10:47 a.m. UTC

Hi all,
as some of you may recall I've been spending some time looking into
providing 'cpufreq' support for the Raspberry Pi platform[1]. I think
I'm close to something workable, so I'd love for you to comment on it.

There has been some design changes since the last version. Namely the
fact that I now make sure *only* the CPU frequency is updated. The
firmware API we use has two modes, with or without turbo. Enabling turbo
implies not only scaling the CPU clock but also the VPU and other
peripheral related clocks.  This is problematic as some of them are not
prepared for this kind frequency changes. I spent some time adapting the
peripheral drivers, but the result was disappointing as they poorly
support live frequency changes (which most other chips accept, think for
instance I2C and clock stretching) but also turned out hard to integrate
into the kernel. As we were planning to use 'clk_notifiers' which turns
out not to be such a good idea as it's prone to deadlocks and not
recommended by the clock maintainers[2]. It's also worth mentioning that
the foundation kernel doesn't support VPU frequency scaling either.

With this in mind, and as suggested by clock maintainers[2], I've
decided to integrate the firmware clock interface into the bcm2835 clock
driver. This, in my opinion, provides the least friction with the
firmware and lets us write very simple and portable higher level
drivers. As I did with the 'cpufreq' driver which simply queries the max
and min frequencies available, which are configurable in the firmware,
to then trigger the generic 'cpufreq-dt'.

In the future we could further integrate other firmware dependent clocks
into the main driver. For instance to be able to scale the VPU clock,
which should be operated through a 'devfreq' driver.

This was tested on a RPi3b+ and if the series is well received I'll test
it further on all platforms I own.

That's all,
kind regards,
Nicolas

[1] https://lists.infradead.org/pipermail/linux-rpi-kernel/2019-April/008634.html
[2] https://www.spinics.net/lists/linux-clk/msg36937.html

---

Changes since v1:
  - Addressed Viresh's comments in cpufreq driver
  - Resend with (hopefully) proper CCs

Nicolas Saenz Julienne (5):
  clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks
  clk: bcm2835: set pllb_arm divisor as readonly
  clk: bcm2835: use firmware interface to update pllb
  dts: bcm2837: add per-cpu clock devices
  cpufreq: add driver for Raspbery Pi

 arch/arm/boot/dts/bcm2837.dtsi        |   8 +
 drivers/clk/bcm/clk-bcm2835.c         | 284 ++++++++++++++++++++++++--
 drivers/cpufreq/Kconfig.arm           |   8 +
 drivers/cpufreq/Makefile              |   1 +
 drivers/cpufreq/raspberrypi-cpufreq.c |  83 ++++++++
 5 files changed, 366 insertions(+), 18 deletions(-)
 create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c

Comments

Viresh Kumar May 20, 2019, 10:51 a.m. UTC | #1

On 20-05-19, 12:47, Nicolas Saenz Julienne wrote:
> Hi all,
> as some of you may recall I've been spending some time looking into
> providing 'cpufreq' support for the Raspberry Pi platform[1]. I think
> I'm close to something workable, so I'd love for you to comment on it.
> 
> There has been some design changes since the last version. Namely the
> fact that I now make sure *only* the CPU frequency is updated. The
> firmware API we use has two modes, with or without turbo. Enabling turbo
> implies not only scaling the CPU clock but also the VPU and other
> peripheral related clocks.  This is problematic as some of them are not
> prepared for this kind frequency changes. I spent some time adapting the
> peripheral drivers, but the result was disappointing as they poorly
> support live frequency changes (which most other chips accept, think for
> instance I2C and clock stretching) but also turned out hard to integrate
> into the kernel. As we were planning to use 'clk_notifiers' which turns
> out not to be such a good idea as it's prone to deadlocks and not
> recommended by the clock maintainers[2]. It's also worth mentioning that
> the foundation kernel doesn't support VPU frequency scaling either.
> 
> With this in mind, and as suggested by clock maintainers[2], I've
> decided to integrate the firmware clock interface into the bcm2835 clock
> driver. This, in my opinion, provides the least friction with the
> firmware and lets us write very simple and portable higher level
> drivers. As I did with the 'cpufreq' driver which simply queries the max
> and min frequencies available, which are configurable in the firmware,
> to then trigger the generic 'cpufreq-dt'.
> 
> In the future we could further integrate other firmware dependent clocks
> into the main driver. For instance to be able to scale the VPU clock,
> which should be operated through a 'devfreq' driver.
> 
> This was tested on a RPi3b+ and if the series is well received I'll test
> it further on all platforms I own.

Please always supply version history on what has changed from V1. And
why do you keep sending it as RFC ? Just keep the default PATCH thing,
the patches are in good shape I would say.

Nicolas Saenz Julienne May 21, 2019, 12:02 p.m. UTC | #2

Hi Viresh, thanks for the comments.

On Mon, 2019-05-20 at 16:21 +0530, Viresh Kumar wrote:
> On 20-05-19, 12:47, Nicolas Saenz Julienne wrote:
> > Hi all,
> > as some of you may recall I've been spending some time looking into
> > providing 'cpufreq' support for the Raspberry Pi platform[1]. I think
> > I'm close to something workable, so I'd love for you to comment on it.
> > 
> > There has been some design changes since the last version. Namely the
> > fact that I now make sure *only* the CPU frequency is updated. The
> > firmware API we use has two modes, with or without turbo. Enabling turbo
> > implies not only scaling the CPU clock but also the VPU and other
> > peripheral related clocks.  This is problematic as some of them are not
> > prepared for this kind frequency changes. I spent some time adapting the
> > peripheral drivers, but the result was disappointing as they poorly
> > support live frequency changes (which most other chips accept, think for
> > instance I2C and clock stretching) but also turned out hard to integrate
> > into the kernel. As we were planning to use 'clk_notifiers' which turns
> > out not to be such a good idea as it's prone to deadlocks and not
> > recommended by the clock maintainers[2]. It's also worth mentioning that
> > the foundation kernel doesn't support VPU frequency scaling either.
> > 
> > With this in mind, and as suggested by clock maintainers[2], I've
> > decided to integrate the firmware clock interface into the bcm2835 clock
> > driver. This, in my opinion, provides the least friction with the
> > firmware and lets us write very simple and portable higher level
> > drivers. As I did with the 'cpufreq' driver which simply queries the max
> > and min frequencies available, which are configurable in the firmware,
> > to then trigger the generic 'cpufreq-dt'.
> > 
> > In the future we could further integrate other firmware dependent clocks
> > into the main driver. For instance to be able to scale the VPU clock,
> > which should be operated through a 'devfreq' driver.
> > 
> > This was tested on a RPi3b+ and if the series is well received I'll test
> > it further on all platforms I own.
> 
> Please always supply version history on what has changed from V1.

Will do

> And why do you keep sending it as RFC ?

Well it's because of patch #3 which integrates the firmware interface into the
clock driver. I want some approval from the maintainers before cleaning it up
testing it on all RPi versions.

> Just keep the default PATCH thing,the patches are in good shape I would say.

Thanks :)

Regards,
Nicolas