[v4,0/7] cpufreq support for Raspberry Pi
mbox series

Message ID 20190612182500.4097-1-nsaenzjulienne@suse.de
Headers show
Series
  • cpufreq support for Raspberry Pi
Related show

Message

Nicolas Saenz Julienne June 12, 2019, 6:24 p.m. UTC
Hi all,
this aims at adding cpufreq support to the Raspberry Pi family of
boards.

The series first factors out 'pllb' from clk-bcm2385 and creates a new
clk driver that operates it over RPi's firmware interface[1]. We are
forced to do so as the firmware 'owns' the pll and we're not allowed to
change through the register interface directly as we might race with the
over-temperature and under-voltage protections provided by the firmware.

Next it creates a minimal cpufreq driver that populates the CPU's opp
table, and registers cpufreq-dt. Which is needed as the firmware
controls the max and min frequencies available.

This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and
arm64's defconfig.

That's all,
kind regards,
Nicolas

[1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

---

Changes since v3:
  - Fix sparse warnings in clk-raspberrypi.c
  - Minor cleanups

Changes since v2:
  - Fixed configs to match Stefan's comments
  - Round OPP frequencies
  - Rebase onto linux-next
  - Minor cleanups & checkpatch.pl

Changes since v1:
  - Enabled by default on the whole family of devices
  - Added/Fixed module support
  - clk device now registered by firmware driver
  - raspberrypi-cpufreq device now registered by clk driver
  - Reimplemented clk rounding unsing determine_rate()
  - Enabled in configs for arm and arm64

Changes since RFC:
  - Move firmware clk device into own driver

Nicolas Saenz Julienne (7):
  clk: bcm2835: remove pllb
  clk: bcm283x: add driver interfacing with Raspberry Pi's firmware
  firmware: raspberrypi: register clk device
  cpufreq: add driver for Raspberry Pi
  clk: raspberrypi: register platform device for raspberrypi-cpufreq
  ARM: defconfig: enable cpufreq driver for RPi
  arm64: defconfig: enable cpufreq support for RPi3

 arch/arm/configs/bcm2835_defconfig    |   9 +
 arch/arm/configs/multi_v7_defconfig   |   2 +
 arch/arm64/configs/defconfig          |   2 +
 drivers/clk/bcm/Kconfig               |   7 +
 drivers/clk/bcm/Makefile              |   1 +
 drivers/clk/bcm/clk-bcm2835.c         |  28 +--
 drivers/clk/bcm/clk-raspberrypi.c     | 315 ++++++++++++++++++++++++++
 drivers/cpufreq/Kconfig.arm           |   8 +
 drivers/cpufreq/Makefile              |   1 +
 drivers/cpufreq/raspberrypi-cpufreq.c |  97 ++++++++
 drivers/firmware/raspberrypi.c        |  10 +
 11 files changed, 456 insertions(+), 24 deletions(-)
 create mode 100644 drivers/clk/bcm/clk-raspberrypi.c
 create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c

Comments

Stefan Wahren June 12, 2019, 8:17 p.m. UTC | #1
Hi Nicolas,

Am 12.06.19 um 20:24 schrieb Nicolas Saenz Julienne:
> Hi all,
> this aims at adding cpufreq support to the Raspberry Pi family of
> boards.
>
> The series first factors out 'pllb' from clk-bcm2385 and creates a new
> clk driver that operates it over RPi's firmware interface[1]. We are
> forced to do so as the firmware 'owns' the pll and we're not allowed to
> change through the register interface directly as we might race with the
> over-temperature and under-voltage protections provided by the firmware.
>
> Next it creates a minimal cpufreq driver that populates the CPU's opp
> table, and registers cpufreq-dt. Which is needed as the firmware
> controls the max and min frequencies available.
>
> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and
> arm64's defconfig.
>
this whole series is:

Acked-by: Stefan Wahren <stefan.wahren@i2se.com>

Thanks
Florian Fainelli June 13, 2019, 3:31 a.m. UTC | #2
On 6/12/2019 11:24 AM, Nicolas Saenz Julienne wrote:
> Hi all,
> this aims at adding cpufreq support to the Raspberry Pi family of
> boards.
> 
> The series first factors out 'pllb' from clk-bcm2385 and creates a new
> clk driver that operates it over RPi's firmware interface[1]. We are
> forced to do so as the firmware 'owns' the pll and we're not allowed to
> change through the register interface directly as we might race with the
> over-temperature and under-voltage protections provided by the firmware.
> 
> Next it creates a minimal cpufreq driver that populates the CPU's opp
> table, and registers cpufreq-dt. Which is needed as the firmware
> controls the max and min frequencies available.
> 
> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and
> arm64's defconfig.

How do we go about merging this? Stefan, will you pick up patch 3, 6 and
7 and submit them for 5.3/5.4? Viresh has already picked up patch 4.

> 
> That's all,
> kind regards,
> Nicolas
> 
> [1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
> 
> ---
> 
> Changes since v3:
>   - Fix sparse warnings in clk-raspberrypi.c
>   - Minor cleanups
> 
> Changes since v2:
>   - Fixed configs to match Stefan's comments
>   - Round OPP frequencies
>   - Rebase onto linux-next
>   - Minor cleanups & checkpatch.pl
> 
> Changes since v1:
>   - Enabled by default on the whole family of devices
>   - Added/Fixed module support
>   - clk device now registered by firmware driver
>   - raspberrypi-cpufreq device now registered by clk driver
>   - Reimplemented clk rounding unsing determine_rate()
>   - Enabled in configs for arm and arm64
> 
> Changes since RFC:
>   - Move firmware clk device into own driver
> 
> Nicolas Saenz Julienne (7):
>   clk: bcm2835: remove pllb
>   clk: bcm283x: add driver interfacing with Raspberry Pi's firmware
>   firmware: raspberrypi: register clk device
>   cpufreq: add driver for Raspberry Pi
>   clk: raspberrypi: register platform device for raspberrypi-cpufreq
>   ARM: defconfig: enable cpufreq driver for RPi
>   arm64: defconfig: enable cpufreq support for RPi3
> 
>  arch/arm/configs/bcm2835_defconfig    |   9 +
>  arch/arm/configs/multi_v7_defconfig   |   2 +
>  arch/arm64/configs/defconfig          |   2 +
>  drivers/clk/bcm/Kconfig               |   7 +
>  drivers/clk/bcm/Makefile              |   1 +
>  drivers/clk/bcm/clk-bcm2835.c         |  28 +--
>  drivers/clk/bcm/clk-raspberrypi.c     | 315 ++++++++++++++++++++++++++
>  drivers/cpufreq/Kconfig.arm           |   8 +
>  drivers/cpufreq/Makefile              |   1 +
>  drivers/cpufreq/raspberrypi-cpufreq.c |  97 ++++++++
>  drivers/firmware/raspberrypi.c        |  10 +
>  11 files changed, 456 insertions(+), 24 deletions(-)
>  create mode 100644 drivers/clk/bcm/clk-raspberrypi.c
>  create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c
>
Stefan Wahren June 13, 2019, 4:31 a.m. UTC | #3
Hi Florian,
hi Stephen,

Am 13.06.19 um 05:31 schrieb Florian Fainelli:
>
> On 6/12/2019 11:24 AM, Nicolas Saenz Julienne wrote:
>> Hi all,
>> this aims at adding cpufreq support to the Raspberry Pi family of
>> boards.
>>
>> The series first factors out 'pllb' from clk-bcm2385 and creates a new
>> clk driver that operates it over RPi's firmware interface[1]. We are
>> forced to do so as the firmware 'owns' the pll and we're not allowed to
>> change through the register interface directly as we might race with the
>> over-temperature and under-voltage protections provided by the firmware.
>>
>> Next it creates a minimal cpufreq driver that populates the CPU's opp
>> table, and registers cpufreq-dt. Which is needed as the firmware
>> controls the max and min frequencies available.
>>
>> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and
>> arm64's defconfig.
> How do we go about merging this? Stefan, will you pick up patch 3, 6 and
> 7 and submit them for 5.3/5.4? Viresh has already picked up patch 4.

is it possible to let patches 1,2, 3 and 5 go via clk-tree?

I would take care of 6 and 7.

Stefan

>
>> That's all,
>> kind regards,
>> Nicolas
>>
>> [1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
>>
>> ---
>>
>> Changes since v3:
>>   - Fix sparse warnings in clk-raspberrypi.c
>>   - Minor cleanups
>>
>> Changes since v2:
>>   - Fixed configs to match Stefan's comments
>>   - Round OPP frequencies
>>   - Rebase onto linux-next
>>   - Minor cleanups & checkpatch.pl
>>
>> Changes since v1:
>>   - Enabled by default on the whole family of devices
>>   - Added/Fixed module support
>>   - clk device now registered by firmware driver
>>   - raspberrypi-cpufreq device now registered by clk driver
>>   - Reimplemented clk rounding unsing determine_rate()
>>   - Enabled in configs for arm and arm64
>>
>> Changes since RFC:
>>   - Move firmware clk device into own driver
>>
>> Nicolas Saenz Julienne (7):
>>   clk: bcm2835: remove pllb
>>   clk: bcm283x: add driver interfacing with Raspberry Pi's firmware
>>   firmware: raspberrypi: register clk device
>>   cpufreq: add driver for Raspberry Pi
>>   clk: raspberrypi: register platform device for raspberrypi-cpufreq
>>   ARM: defconfig: enable cpufreq driver for RPi
>>   arm64: defconfig: enable cpufreq support for RPi3
>>
>>  arch/arm/configs/bcm2835_defconfig    |   9 +
>>  arch/arm/configs/multi_v7_defconfig   |   2 +
>>  arch/arm64/configs/defconfig          |   2 +
>>  drivers/clk/bcm/Kconfig               |   7 +
>>  drivers/clk/bcm/Makefile              |   1 +
>>  drivers/clk/bcm/clk-bcm2835.c         |  28 +--
>>  drivers/clk/bcm/clk-raspberrypi.c     | 315 ++++++++++++++++++++++++++
>>  drivers/cpufreq/Kconfig.arm           |   8 +
>>  drivers/cpufreq/Makefile              |   1 +
>>  drivers/cpufreq/raspberrypi-cpufreq.c |  97 ++++++++
>>  drivers/firmware/raspberrypi.c        |  10 +
>>  11 files changed, 456 insertions(+), 24 deletions(-)
>>  create mode 100644 drivers/clk/bcm/clk-raspberrypi.c
>>  create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c
>>
Stefan Wahren June 22, 2019, 9:54 a.m. UTC | #4
Hi Stephen,
hi Mike,

Am 13.06.19 um 06:31 schrieb Stefan Wahren:
> Hi Florian,
> hi Stephen,
>
> Am 13.06.19 um 05:31 schrieb Florian Fainelli:
>> On 6/12/2019 11:24 AM, Nicolas Saenz Julienne wrote:
>>> Hi all,
>>> this aims at adding cpufreq support to the Raspberry Pi family of
>>> boards.
>>>
>>> The series first factors out 'pllb' from clk-bcm2385 and creates a new
>>> clk driver that operates it over RPi's firmware interface[1]. We are
>>> forced to do so as the firmware 'owns' the pll and we're not allowed to
>>> change through the register interface directly as we might race with the
>>> over-temperature and under-voltage protections provided by the firmware.
>>>
>>> Next it creates a minimal cpufreq driver that populates the CPU's opp
>>> table, and registers cpufreq-dt. Which is needed as the firmware
>>> controls the max and min frequencies available.
>>>
>>> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and
>>> arm64's defconfig.
>> How do we go about merging this? Stefan, will you pick up patch 3, 6 and
>> 7 and submit them for 5.3/5.4? Viresh has already picked up patch 4.
> is it possible to let patches 1,2, 3 and 5 go via clk-tree?
>
> I would take care of 6 and 7.
>
> Stefan
are you fine with the series, since Viresh already picked up patch 4?

are you okay with my suggestion above?

Stefan
Stephen Boyd June 25, 2019, 11:02 p.m. UTC | #5
Quoting Stefan Wahren (2019-06-22 02:54:47)
> Hi Stephen,
> hi Mike,
> 
> Am 13.06.19 um 06:31 schrieb Stefan Wahren:
> > Hi Florian,
> > hi Stephen,
> >
> > Am 13.06.19 um 05:31 schrieb Florian Fainelli:
> >> On 6/12/2019 11:24 AM, Nicolas Saenz Julienne wrote:
> >>> Hi all,
> >>> this aims at adding cpufreq support to the Raspberry Pi family of
> >>> boards.
> >>>
> >>> The series first factors out 'pllb' from clk-bcm2385 and creates a new
> >>> clk driver that operates it over RPi's firmware interface[1]. We are
> >>> forced to do so as the firmware 'owns' the pll and we're not allowed to
> >>> change through the register interface directly as we might race with the
> >>> over-temperature and under-voltage protections provided by the firmware.
> >>>
> >>> Next it creates a minimal cpufreq driver that populates the CPU's opp
> >>> table, and registers cpufreq-dt. Which is needed as the firmware
> >>> controls the max and min frequencies available.
> >>>
> >>> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and
> >>> arm64's defconfig.
> >> How do we go about merging this? Stefan, will you pick up patch 3, 6 and
> >> 7 and submit them for 5.3/5.4? Viresh has already picked up patch 4.
> > is it possible to let patches 1,2, 3 and 5 go via clk-tree?
> >
> > I would take care of 6 and 7.
> >
> > Stefan
> are you fine with the series, since Viresh already picked up patch 4?
> 
> are you okay with my suggestion above?
> 

Oh I missed this. I can apply the clk patches most likely assuming it
doesn't break anything bisection-wise.