* [RFC v2 0/5] cpufreq support for the Raspberry Pi @ 2019-05-20 10:47 Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks Nicolas Saenz Julienne ` (5 more replies) 0 siblings, 6 replies; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-20 10:47 UTC (permalink / raw) To: stefan.wahren, devicetree, linux-rpi-kernel, linux-arm-kernel, linux-pm Cc: f.fainelli, ptesarik, sboyd, viresh.kumar, mturquette, rjw, linux-kernel, eric, bcm-kernel-feedback-list, Nicolas Saenz Julienne, linux-clk, mbrugger, ssuloev 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 -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne @ 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 11:42 ` Stefan Wahren 2019-05-20 10:47 ` [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly Nicolas Saenz Julienne ` (4 subsequent siblings) 5 siblings, 1 reply; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-20 10:47 UTC (permalink / raw) To: stefan.wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, Nicolas Saenz Julienne, linux-rpi-kernel, linux-clk, mbrugger, ssuloev Raspberry Pi's firmware is responsible for updating the cpu clocks and pll. This makes sure we get the right rates anytime. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- drivers/clk/bcm/clk-bcm2835.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c index 770bb01f523e..c2772dfb155a 100644 --- a/drivers/clk/bcm/clk-bcm2835.c +++ b/drivers/clk/bcm/clk-bcm2835.c @@ -411,6 +411,7 @@ struct bcm2835_pll_data { u32 reference_enable_mask; /* Bit in CM_LOCK to indicate when the PLL has locked. */ u32 lock_mask; + u32 flags; const struct bcm2835_pll_ana_bits *ana; @@ -1299,7 +1300,7 @@ static struct clk_hw *bcm2835_register_pll(struct bcm2835_cprman *cprman, init.num_parents = 1; init.name = data->name; init.ops = &bcm2835_pll_clk_ops; - init.flags = CLK_IGNORE_UNUSED; + init.flags = data->flags | CLK_IGNORE_UNUSED; pll = kzalloc(sizeof(*pll), GFP_KERNEL); if (!pll) @@ -1660,6 +1661,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { .ana_reg_base = A2W_PLLB_ANA0, .reference_enable_mask = A2W_XOSC_CTRL_PLLB_ENABLE, .lock_mask = CM_LOCK_FLOCKB, + .flags = CLK_GET_RATE_NOCACHE, .ana = &bcm2835_ana_default, @@ -1674,7 +1676,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { .load_mask = CM_PLLB_LOADARM, .hold_mask = CM_PLLB_HOLDARM, .fixed_divider = 1, - .flags = CLK_SET_RATE_PARENT), + .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE), /* * PLLC is the core PLL, used to drive the core VPU clock. -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks 2019-05-20 10:47 ` [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks Nicolas Saenz Julienne @ 2019-05-20 11:42 ` Stefan Wahren 0 siblings, 0 replies; 24+ messages in thread From: Stefan Wahren @ 2019-05-20 11:42 UTC (permalink / raw) To: Nicolas Saenz Julienne, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-pm, sboyd, viresh.kumar, mturquette, ptesarik, rjw, linux-kernel, mbrugger, linux-rpi-kernel, linux-clk, linux-arm-kernel, ssuloev On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > Raspberry Pi's firmware is responsible for updating the cpu clocks and > pll. This makes sure we get the right rates anytime. > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by: Stefan Wahren <stefan.wahren@i2se.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks Nicolas Saenz Julienne @ 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 11:43 ` Stefan Wahren 2019-05-20 10:47 ` [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Nicolas Saenz Julienne ` (3 subsequent siblings) 5 siblings, 1 reply; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-20 10:47 UTC (permalink / raw) To: stefan.wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, Nicolas Saenz Julienne, linux-rpi-kernel, linux-clk, mbrugger, ssuloev This divisor is controlled by the firmware, we don't want the clock subsystem to update it inadvertently. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- drivers/clk/bcm/clk-bcm2835.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c index c2772dfb155a..5aea110672f3 100644 --- a/drivers/clk/bcm/clk-bcm2835.c +++ b/drivers/clk/bcm/clk-bcm2835.c @@ -465,6 +465,7 @@ struct bcm2835_pll_divider_data { u32 hold_mask; u32 fixed_divider; u32 flags; + u32 div_flags; }; struct bcm2835_clock_data { @@ -1349,7 +1350,7 @@ bcm2835_register_pll_divider(struct bcm2835_cprman *cprman, divider->div.reg = cprman->regs + data->a2w_reg; divider->div.shift = A2W_PLL_DIV_SHIFT; divider->div.width = A2W_PLL_DIV_BITS; - divider->div.flags = CLK_DIVIDER_MAX_AT_ZERO; + divider->div.flags = data->div_flags | CLK_DIVIDER_MAX_AT_ZERO; divider->div.lock = &cprman->regs_lock; divider->div.hw.init = &init; divider->div.table = NULL; @@ -1676,7 +1677,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { .load_mask = CM_PLLB_LOADARM, .hold_mask = CM_PLLB_HOLDARM, .fixed_divider = 1, - .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE), + .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE, + .div_flags = CLK_DIVIDER_READ_ONLY), /* * PLLC is the core PLL, used to drive the core VPU clock. -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly 2019-05-20 10:47 ` [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly Nicolas Saenz Julienne @ 2019-05-20 11:43 ` Stefan Wahren 0 siblings, 0 replies; 24+ messages in thread From: Stefan Wahren @ 2019-05-20 11:43 UTC (permalink / raw) To: Nicolas Saenz Julienne, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-pm, sboyd, viresh.kumar, mturquette, ptesarik, rjw, linux-kernel, mbrugger, linux-rpi-kernel, linux-clk, linux-arm-kernel, ssuloev On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > This divisor is controlled by the firmware, we don't want the clock > subsystem to update it inadvertently. > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by: Stefan Wahren <stefan.wahren@i2se.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly Nicolas Saenz Julienne @ 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 12:11 ` Stefan Wahren 2019-05-20 12:43 ` Oliver Neukum 2019-05-20 10:47 ` [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices Nicolas Saenz Julienne ` (2 subsequent siblings) 5 siblings, 2 replies; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-20 10:47 UTC (permalink / raw) To: stefan.wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, Nicolas Saenz Julienne, linux-rpi-kernel, linux-clk, mbrugger, ssuloev Raspberry Pi's firmware, which runs in a dedicated processor, keeps track of the board's temperature and voltage. It's resposible for scaling the CPU frequency whenever it deems the device reached an unsafe state. On top of that the firmware provides an interface which allows Linux to to query the clock's state or change it's frequency. Being the sole user of the bcm2835 clock driver, this integrates the firmware interface into the clock driver and adds a first user: the CPU pll, also known as 'pllb'. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- drivers/clk/bcm/clk-bcm2835.c | 274 ++++++++++++++++++++++++++++++++-- 1 file changed, 259 insertions(+), 15 deletions(-) diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c index 5aea110672f3..ce5b16f3704e 100644 --- a/drivers/clk/bcm/clk-bcm2835.c +++ b/drivers/clk/bcm/clk-bcm2835.c @@ -35,6 +35,7 @@ #include <linux/platform_device.h> #include <linux/slab.h> #include <dt-bindings/clock/bcm2835.h> +#include <soc/bcm2835/raspberrypi-firmware.h> #define CM_PASSWORD 0x5a000000 @@ -289,6 +290,30 @@ #define LOCK_TIMEOUT_NS 100000000 #define BCM2835_MAX_FB_RATE 1750000000u +#define RPI_FIRMWARE_ARM_CLK_ID 0x000000003 +#define RPI_FIRMWARE_STATE_ENABLE_BIT 0x1 +#define RPI_FIRMWARE_STATE_WAIT_BIT 0x2 + +/* + * Structure of the message passed to Raspberry Pi's firmware in order to + * change clock rates. The 'disable_turbo' option is only available to the ARM + * clock (pllb) which we enable by default as turbo mode will alter multiple + * clocks at once. + * + * Even though we're able to access the clock registers directly we're bound to + * use the firmware interface as the firmware ultimately takes care of + * mitigating overheating/undervoltage situations and we would be changing + * frequencies behind his back. + * + * For more information on the firmware interface check: + * https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface + */ +struct bcm2835_firmware_prop { + u32 id; + u32 val; + u32 disable_turbo; +} __packed; + /* * Names of clocks used within the driver that need to be replaced * with an external parent's name. This array is in the order that @@ -316,6 +341,8 @@ struct bcm2835_cprman { */ const char *real_parent_names[ARRAY_SIZE(cprman_parent_names)]; + struct rpi_firmware *firmware; + /* Must be last */ struct clk_hw_onecell_data onecell; }; @@ -424,6 +451,23 @@ struct bcm2835_pll_data { unsigned long max_fb_rate; }; +struct bcm2835_fw_pll_data { + const char *name; + int firmware_clk_id; + u32 flags; + + unsigned long min_rate; + unsigned long max_rate; + + /* + * The rate provided to the firmware interface might not always match + * the clock subsystem's. For instance, in the case of the ARM cpu + * clock, even though the firmware ultimately edits 'pllb' it takes the + * expected 'pllb_arm' rate as it's input. + */ + unsigned int rate_rescale; +}; + struct bcm2835_pll_ana_bits { u32 mask0; u32 set0; @@ -505,6 +549,7 @@ struct bcm2835_pll { struct clk_hw hw; struct bcm2835_cprman *cprman; const struct bcm2835_pll_data *data; + const struct bcm2835_fw_pll_data *fw_data; }; static int bcm2835_pll_is_on(struct clk_hw *hw) @@ -517,6 +562,41 @@ static int bcm2835_pll_is_on(struct clk_hw *hw) A2W_PLL_CTRL_PRST_DISABLE; } +static int raspberrypi_clock_property(struct rpi_firmware *firmware, u32 tag, + u32 clk, u32 *val) +{ + int ret; + struct bcm2835_firmware_prop msg = { + .id = clk, + .val = *val, + .disable_turbo = 1, + }; + + ret = rpi_firmware_property(firmware, tag, &msg, sizeof(msg)); + if (ret) + return ret; + + *val = msg.val; + + return 0; +} + +static int bcm2835_fw_pll_is_on(struct clk_hw *hw) +{ + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); + struct bcm2835_cprman *cprman = pll->cprman; + u32 val = 0; + int ret; + + ret = raspberrypi_clock_property(cprman->firmware, + RPI_FIRMWARE_GET_CLOCK_STATE, + pll->fw_data->firmware_clk_id, &val); + if (ret) + return 0; + + return !!(val & RPI_FIRMWARE_STATE_ENABLE_BIT); +} + static void bcm2835_pll_choose_ndiv_and_fdiv(unsigned long rate, unsigned long parent_rate, u32 *ndiv, u32 *fdiv) @@ -547,16 +627,37 @@ static long bcm2835_pll_round_rate(struct clk_hw *hw, unsigned long rate, unsigned long *parent_rate) { struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); - const struct bcm2835_pll_data *data = pll->data; u32 ndiv, fdiv; - rate = clamp(rate, data->min_rate, data->max_rate); + if (pll->data) + rate = clamp(rate, pll->data->min_rate, pll->data->max_rate); + else + rate = clamp(rate, pll->fw_data->min_rate, + pll->fw_data->max_rate); bcm2835_pll_choose_ndiv_and_fdiv(rate, *parent_rate, &ndiv, &fdiv); return bcm2835_pll_rate_from_divisors(*parent_rate, ndiv, fdiv, 1); } +static unsigned long bcm2835_fw_pll_get_rate(struct clk_hw *hw, + unsigned long parent_rate) +{ + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); + struct bcm2835_cprman *cprman = pll->cprman; + u32 val = 0; + int ret; + + ret = raspberrypi_clock_property(cprman->firmware, + RPI_FIRMWARE_GET_CLOCK_RATE, + pll->fw_data->firmware_clk_id, + &val); + if (ret) + return ret; + + return val * pll->fw_data->rate_rescale; +} + static unsigned long bcm2835_pll_get_rate(struct clk_hw *hw, unsigned long parent_rate) { @@ -584,6 +685,35 @@ static unsigned long bcm2835_pll_get_rate(struct clk_hw *hw, return bcm2835_pll_rate_from_divisors(parent_rate, ndiv, fdiv, pdiv); } +static int bcm2835_fw_pll_on(struct clk_hw *hw) +{ + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); + struct bcm2835_cprman *cprman = pll->cprman; + u32 val; + int ret; + + val = RPI_FIRMWARE_STATE_ENABLE_BIT | RPI_FIRMWARE_STATE_WAIT_BIT; + + ret = raspberrypi_clock_property(cprman->firmware, + RPI_FIRMWARE_SET_CLOCK_STATE, + pll->fw_data->firmware_clk_id, &val); + if (ret) + return ret; + + return 0; +} + +static void bcm2835_fw_pll_off(struct clk_hw *hw) +{ + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); + struct bcm2835_cprman *cprman = pll->cprman; + u32 val = RPI_FIRMWARE_STATE_WAIT_BIT; + + raspberrypi_clock_property(cprman->firmware, + RPI_FIRMWARE_SET_CLOCK_STATE, + pll->fw_data->firmware_clk_id, &val); +} + static void bcm2835_pll_off(struct clk_hw *hw) { struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); @@ -651,6 +781,25 @@ bcm2835_pll_write_ana(struct bcm2835_cprman *cprman, u32 ana_reg_base, u32 *ana) cprman_write(cprman, ana_reg_base + i * 4, ana[i]); } +static int bcm2835_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate, + unsigned long parent_rate) +{ + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); + u32 new_rate = rate / pll->fw_data->rate_rescale; + struct bcm2835_cprman *cprman = pll->cprman; + int ret; + + ret = raspberrypi_clock_property(cprman->firmware, + RPI_FIRMWARE_SET_CLOCK_RATE, + pll->fw_data->firmware_clk_id, + &new_rate); + if (ret) + dev_err(cprman->dev, "Failed to change %s frequency: %d", + clk_hw_get_name(hw), ret); + + return ret; +} + static int bcm2835_pll_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate) { @@ -759,6 +908,15 @@ static const struct clk_ops bcm2835_pll_clk_ops = { .debug_init = bcm2835_pll_debug_init, }; +static const struct clk_ops bcm2835_firmware_pll_clk_ops = { + .is_prepared = bcm2835_fw_pll_is_on, + .prepare = bcm2835_fw_pll_on, + .unprepare = bcm2835_fw_pll_off, + .recalc_rate = bcm2835_fw_pll_get_rate, + .set_rate = bcm2835_fw_pll_set_rate, + .round_rate = bcm2835_pll_round_rate, +}; + struct bcm2835_pll_divider { struct clk_divider div; struct bcm2835_cprman *cprman; @@ -1287,6 +1445,83 @@ static const struct clk_ops bcm2835_vpu_clock_clk_ops = { .debug_init = bcm2835_clock_debug_init, }; +static int bcm2835_firmware_get_min_max_rates(struct bcm2835_cprman *cprman, + struct bcm2835_fw_pll_data *data) +{ + u32 min_rate = 0, max_rate = 0; + int ret; + + ret = raspberrypi_clock_property(cprman->firmware, + RPI_FIRMWARE_GET_MIN_CLOCK_RATE, + data->firmware_clk_id, + &min_rate); + if (ret) { + dev_err(cprman->dev, "Failed to get %s min freq: %d\n", + data->name, ret); + return ret; + } + + ret = raspberrypi_clock_property(cprman->firmware, + RPI_FIRMWARE_GET_MAX_CLOCK_RATE, + data->firmware_clk_id, + &max_rate); + if (ret) { + dev_err(cprman->dev, "Failed to get %s max freq: %d\n", + data->name, ret); + return ret; + } + + data->min_rate = min_rate * data->rate_rescale; + data->max_rate = max_rate * data->rate_rescale; + + dev_info(cprman->dev, "min %lu, max %lu\n", data->min_rate, data->max_rate); + return 0; +} + +static struct clk_hw *bcm2835_register_fw_pll(struct bcm2835_cprman *cprman, + const struct bcm2835_fw_pll_data *data) +{ + struct bcm2835_fw_pll_data *fw_data; + struct clk_init_data init; + struct bcm2835_pll *pll; + int ret; + + memset(&init, 0, sizeof(init)); + + /* All of the PLLs derive from the external oscillator. */ + init.parent_names = &cprman->real_parent_names[0]; + init.num_parents = 1; + init.name = data->name; + init.ops = &bcm2835_firmware_pll_clk_ops; + init.flags = data->flags | CLK_IGNORE_UNUSED; + + pll = kzalloc(sizeof(*pll), GFP_KERNEL); + if (!pll) + return NULL; + + /* + * As the max and min rate values are firmware dependent we need a non + * constant version of struct bcm2835_fw_pll_data. + */ + fw_data = devm_kmemdup(cprman->dev, data, sizeof(*data), + GFP_KERNEL); + if (!fw_data) + return NULL; + + ret = bcm2835_firmware_get_min_max_rates(cprman, fw_data); + if (ret) + return NULL; + + pll->cprman = cprman; + pll->hw.init = &init; + pll->fw_data = fw_data; + + ret = devm_clk_hw_register(cprman->dev, &pll->hw); + if (ret) + return NULL; + return &pll->hw; +} + static struct clk_hw *bcm2835_register_pll(struct bcm2835_cprman *cprman, const struct bcm2835_pll_data *data) { @@ -1462,6 +1697,9 @@ struct bcm2835_clk_desc { #define REGISTER_PLL(...) _REGISTER(&bcm2835_register_pll, \ &(struct bcm2835_pll_data) \ {__VA_ARGS__}) +#define REGISTER_FW_PLL(...) _REGISTER(&bcm2835_register_fw_pll, \ + &(struct bcm2835_fw_pll_data) \ + {__VA_ARGS__}) #define REGISTER_PLL_DIV(...) _REGISTER(&bcm2835_register_pll_divider, \ &(struct bcm2835_pll_divider_data) \ {__VA_ARGS__}) @@ -1654,21 +1892,11 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { .flags = CLK_SET_RATE_PARENT), /* PLLB is used for the ARM's clock. */ - [BCM2835_PLLB] = REGISTER_PLL( + [BCM2835_PLLB] = REGISTER_FW_PLL( .name = "pllb", - .cm_ctrl_reg = CM_PLLB, - .a2w_ctrl_reg = A2W_PLLB_CTRL, - .frac_reg = A2W_PLLB_FRAC, - .ana_reg_base = A2W_PLLB_ANA0, - .reference_enable_mask = A2W_XOSC_CTRL_PLLB_ENABLE, - .lock_mask = CM_LOCK_FLOCKB, .flags = CLK_GET_RATE_NOCACHE, - - .ana = &bcm2835_ana_default, - - .min_rate = 600000000u, - .max_rate = 3000000000u, - .max_fb_rate = BCM2835_MAX_FB_RATE), + .rate_rescale = 2, + .firmware_clk_id = RPI_FIRMWARE_ARM_CLK_ID), [BCM2835_PLLB_ARM] = REGISTER_PLL_DIV( .name = "pllb_arm", .source_pll = "pllb", @@ -2133,9 +2361,24 @@ static int bcm2835_clk_probe(struct platform_device *pdev) struct resource *res; const struct bcm2835_clk_desc *desc; const size_t asize = ARRAY_SIZE(clk_desc_array); + struct device_node *firmware_node; + struct rpi_firmware *firmware; size_t i; int ret; + firmware_node = of_find_node_by_name(NULL, "firmware"); + if (!firmware_node) { + dev_err(dev, "Missing firmware node\n"); + return -ENOENT; + } + + firmware = rpi_firmware_get(firmware_node); + of_node_put(firmware_node); + if (!firmware) { + dev_err(dev, "Can't get raspberrypi's firmware\n"); + return -EPROBE_DEFER; + } + cprman = devm_kzalloc(dev, struct_size(cprman, onecell.hws, asize), GFP_KERNEL); @@ -2144,6 +2387,7 @@ static int bcm2835_clk_probe(struct platform_device *pdev) spin_lock_init(&cprman->regs_lock); cprman->dev = dev; + cprman->firmware = firmware; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); cprman->regs = devm_ioremap_resource(dev, res); if (IS_ERR(cprman->regs)) -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-20 10:47 ` [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Nicolas Saenz Julienne @ 2019-05-20 12:11 ` Stefan Wahren 2019-05-20 12:14 ` Stefan Wahren 2019-05-21 12:40 ` Stefan Wahren 2019-05-20 12:43 ` Oliver Neukum 1 sibling, 2 replies; 24+ messages in thread From: Stefan Wahren @ 2019-05-20 12:11 UTC (permalink / raw) To: Nicolas Saenz Julienne, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-pm, sboyd, viresh.kumar, mturquette, ptesarik, rjw, linux-kernel, mbrugger, linux-rpi-kernel, linux-clk, linux-arm-kernel, ssuloev Hi Nicolas, the following comments applies only in case Eric is fine with the whole approach. On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > Raspberry Pi's firmware, which runs in a dedicated processor, keeps maybe we should clarify that the firmware is running in the VPU > track of the board's temperature and voltage. It's resposible for > scaling the CPU frequency whenever it deems the device reached an unsafe > state. On top of that the firmware provides an interface which allows > Linux to to query the clock's state or change it's frequency. I think this requires a separate update of the devicetree binding. > > Being the sole user of the bcm2835 clock driver, this integrates the > firmware interface into the clock driver and adds a first user: the CPU > pll, also known as 'pllb'. Please verify that the kernel still works (and this clock driver probe) under the following conditions: - CONFIG_RASPBERRYPI_FIRMWARE=n - CONFIG_RASPBERRYPI_FIRMWARE=m - older DTBs without patch #1 > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > --- > drivers/clk/bcm/clk-bcm2835.c | 274 ++++++++++++++++++++++++++++++++-- > 1 file changed, 259 insertions(+), 15 deletions(-) > > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c > index 5aea110672f3..ce5b16f3704e 100644 > --- a/drivers/clk/bcm/clk-bcm2835.c > +++ b/drivers/clk/bcm/clk-bcm2835.c > @@ -35,6 +35,7 @@ > #include <linux/platform_device.h> > #include <linux/slab.h> > #include <dt-bindings/clock/bcm2835.h> > +#include <soc/bcm2835/raspberrypi-firmware.h> > > #define CM_PASSWORD 0x5a000000 > > @@ -289,6 +290,30 @@ > #define LOCK_TIMEOUT_NS 100000000 > #define BCM2835_MAX_FB_RATE 1750000000u > > +#define RPI_FIRMWARE_ARM_CLK_ID 0x000000003 > +#define RPI_FIRMWARE_STATE_ENABLE_BIT 0x1 > +#define RPI_FIRMWARE_STATE_WAIT_BIT 0x2 > + > +/* > + * Structure of the message passed to Raspberry Pi's firmware in order to > + * change clock rates. The 'disable_turbo' option is only available to the ARM > + * clock (pllb) which we enable by default as turbo mode will alter multiple > + * clocks at once. > + * > + * Even though we're able to access the clock registers directly we're bound to > + * use the firmware interface as the firmware ultimately takes care of > + * mitigating overheating/undervoltage situations and we would be changing > + * frequencies behind his back. > + * > + * For more information on the firmware interface check: > + * https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface > + */ > +struct bcm2835_firmware_prop { > + u32 id; > + u32 val; > + u32 disable_turbo; > +} __packed; > + > /* > * Names of clocks used within the driver that need to be replaced > * with an external parent's name. This array is in the order that > @@ -316,6 +341,8 @@ struct bcm2835_cprman { > */ > const char *real_parent_names[ARRAY_SIZE(cprman_parent_names)]; > > + struct rpi_firmware *firmware; > + > /* Must be last */ > struct clk_hw_onecell_data onecell; > }; > @@ -424,6 +451,23 @@ struct bcm2835_pll_data { > unsigned long max_fb_rate; > }; > > +struct bcm2835_fw_pll_data { > + const char *name; > + int firmware_clk_id; > + u32 flags; > + > + unsigned long min_rate; > + unsigned long max_rate; > + > + /* > + * The rate provided to the firmware interface might not always match > + * the clock subsystem's. For instance, in the case of the ARM cpu > + * clock, even though the firmware ultimately edits 'pllb' it takes the > + * expected 'pllb_arm' rate as it's input. > + */ > + unsigned int rate_rescale; > +}; > + > struct bcm2835_pll_ana_bits { > u32 mask0; > u32 set0; > @@ -505,6 +549,7 @@ struct bcm2835_pll { > struct clk_hw hw; > struct bcm2835_cprman *cprman; > const struct bcm2835_pll_data *data; > + const struct bcm2835_fw_pll_data *fw_data; > }; > > static int bcm2835_pll_is_on(struct clk_hw *hw) > @@ -517,6 +562,41 @@ static int bcm2835_pll_is_on(struct clk_hw *hw) > A2W_PLL_CTRL_PRST_DISABLE; > } > > +static int raspberrypi_clock_property(struct rpi_firmware *firmware, u32 tag, > + u32 clk, u32 *val) > +{ > + int ret; > + struct bcm2835_firmware_prop msg = { > + .id = clk, > + .val = *val, > + .disable_turbo = 1, > + }; > + > + ret = rpi_firmware_property(firmware, tag, &msg, sizeof(msg)); > + if (ret) > + return ret; > + > + *val = msg.val; > + > + return 0; > +} > + > +static int bcm2835_fw_pll_is_on(struct clk_hw *hw) > +{ > + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); > + struct bcm2835_cprman *cprman = pll->cprman; > + u32 val = 0; > + int ret; > + > + ret = raspberrypi_clock_property(cprman->firmware, > + RPI_FIRMWARE_GET_CLOCK_STATE, > + pll->fw_data->firmware_clk_id, &val); > + if (ret) > + return 0; > + > + return !!(val & RPI_FIRMWARE_STATE_ENABLE_BIT); > +} > + > static void bcm2835_pll_choose_ndiv_and_fdiv(unsigned long rate, > unsigned long parent_rate, > u32 *ndiv, u32 *fdiv) > @@ -547,16 +627,37 @@ static long bcm2835_pll_round_rate(struct clk_hw *hw, unsigned long rate, > unsigned long *parent_rate) > { > struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); > - const struct bcm2835_pll_data *data = pll->data; > u32 ndiv, fdiv; > > - rate = clamp(rate, data->min_rate, data->max_rate); > + if (pll->data) > + rate = clamp(rate, pll->data->min_rate, pll->data->max_rate); > + else > + rate = clamp(rate, pll->fw_data->min_rate, > + pll->fw_data->max_rate); > > bcm2835_pll_choose_ndiv_and_fdiv(rate, *parent_rate, &ndiv, &fdiv); > > return bcm2835_pll_rate_from_divisors(*parent_rate, ndiv, fdiv, 1); > } > > +static unsigned long bcm2835_fw_pll_get_rate(struct clk_hw *hw, > + unsigned long parent_rate) > +{ > + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); > + struct bcm2835_cprman *cprman = pll->cprman; > + u32 val = 0; > + int ret; > + > + ret = raspberrypi_clock_property(cprman->firmware, > + RPI_FIRMWARE_GET_CLOCK_RATE, > + pll->fw_data->firmware_clk_id, > + &val); > + if (ret) > + return ret; > + > + return val * pll->fw_data->rate_rescale; > +} > + > static unsigned long bcm2835_pll_get_rate(struct clk_hw *hw, > unsigned long parent_rate) > { > @@ -584,6 +685,35 @@ static unsigned long bcm2835_pll_get_rate(struct clk_hw *hw, > return bcm2835_pll_rate_from_divisors(parent_rate, ndiv, fdiv, pdiv); > } > > +static int bcm2835_fw_pll_on(struct clk_hw *hw) > +{ > + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); > + struct bcm2835_cprman *cprman = pll->cprman; > + u32 val; > + int ret; > + > + val = RPI_FIRMWARE_STATE_ENABLE_BIT | RPI_FIRMWARE_STATE_WAIT_BIT; > + > + ret = raspberrypi_clock_property(cprman->firmware, > + RPI_FIRMWARE_SET_CLOCK_STATE, > + pll->fw_data->firmware_clk_id, &val); > + if (ret) > + return ret; > + > + return 0; > +} > + > +static void bcm2835_fw_pll_off(struct clk_hw *hw) > +{ > + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); > + struct bcm2835_cprman *cprman = pll->cprman; > + u32 val = RPI_FIRMWARE_STATE_WAIT_BIT; > + > + raspberrypi_clock_property(cprman->firmware, > + RPI_FIRMWARE_SET_CLOCK_STATE, > + pll->fw_data->firmware_clk_id, &val); > +} > + > static void bcm2835_pll_off(struct clk_hw *hw) > { > struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); > @@ -651,6 +781,25 @@ bcm2835_pll_write_ana(struct bcm2835_cprman *cprman, u32 ana_reg_base, u32 *ana) > cprman_write(cprman, ana_reg_base + i * 4, ana[i]); > } > > +static int bcm2835_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate, > + unsigned long parent_rate) > +{ > + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw); > + u32 new_rate = rate / pll->fw_data->rate_rescale; > + struct bcm2835_cprman *cprman = pll->cprman; > + int ret; > + > + ret = raspberrypi_clock_property(cprman->firmware, > + RPI_FIRMWARE_SET_CLOCK_RATE, > + pll->fw_data->firmware_clk_id, > + &new_rate); > + if (ret) > + dev_err(cprman->dev, "Failed to change %s frequency: %d", > + clk_hw_get_name(hw), ret); I think we should print this error only once or at least rate limited. > + > + return ret; > +} > + > static int bcm2835_pll_set_rate(struct clk_hw *hw, > unsigned long rate, unsigned long parent_rate) > { > @@ -759,6 +908,15 @@ static const struct clk_ops bcm2835_pll_clk_ops = { > .debug_init = bcm2835_pll_debug_init, > }; > > +static const struct clk_ops bcm2835_firmware_pll_clk_ops = { > + .is_prepared = bcm2835_fw_pll_is_on, > + .prepare = bcm2835_fw_pll_on, > + .unprepare = bcm2835_fw_pll_off, > + .recalc_rate = bcm2835_fw_pll_get_rate, > + .set_rate = bcm2835_fw_pll_set_rate, > + .round_rate = bcm2835_pll_round_rate, > +}; > + > struct bcm2835_pll_divider { > struct clk_divider div; > struct bcm2835_cprman *cprman; > @@ -1287,6 +1445,83 @@ static const struct clk_ops bcm2835_vpu_clock_clk_ops = { > .debug_init = bcm2835_clock_debug_init, > }; > > +static int bcm2835_firmware_get_min_max_rates(struct bcm2835_cprman *cprman, > + struct bcm2835_fw_pll_data *data) > +{ > + u32 min_rate = 0, max_rate = 0; > + int ret; > + > + ret = raspberrypi_clock_property(cprman->firmware, > + RPI_FIRMWARE_GET_MIN_CLOCK_RATE, > + data->firmware_clk_id, > + &min_rate); > + if (ret) { > + dev_err(cprman->dev, "Failed to get %s min freq: %d\n", > + data->name, ret); > + return ret; > + } > + > + ret = raspberrypi_clock_property(cprman->firmware, > + RPI_FIRMWARE_GET_MAX_CLOCK_RATE, > + data->firmware_clk_id, > + &max_rate); > + if (ret) { > + dev_err(cprman->dev, "Failed to get %s max freq: %d\n", > + data->name, ret); > + return ret; > + } > + > + data->min_rate = min_rate * data->rate_rescale; > + data->max_rate = max_rate * data->rate_rescale; > + > + dev_info(cprman->dev, "min %lu, max %lu\n", data->min_rate, data->max_rate); > + return 0; > +} > + > +static struct clk_hw *bcm2835_register_fw_pll(struct bcm2835_cprman *cprman, > + const struct bcm2835_fw_pll_data *data) > +{ > + struct bcm2835_fw_pll_data *fw_data; > + struct clk_init_data init; > + struct bcm2835_pll *pll; > + int ret; > + > + memset(&init, 0, sizeof(init)); > + > + /* All of the PLLs derive from the external oscillator. */ > + init.parent_names = &cprman->real_parent_names[0]; > + init.num_parents = 1; > + init.name = data->name; > + init.ops = &bcm2835_firmware_pll_clk_ops; > + init.flags = data->flags | CLK_IGNORE_UNUSED; > + > + pll = kzalloc(sizeof(*pll), GFP_KERNEL); > + if (!pll) > + return NULL; > + > + /* > + * As the max and min rate values are firmware dependent we need a non > + * constant version of struct bcm2835_fw_pll_data. > + */ > + fw_data = devm_kmemdup(cprman->dev, data, sizeof(*data), > + GFP_KERNEL); > + if (!fw_data) > + return NULL; > + > + ret = bcm2835_firmware_get_min_max_rates(cprman, fw_data); > + if (ret) > + return NULL; > + > + pll->cprman = cprman; > + pll->hw.init = &init; > + pll->fw_data = fw_data; > + > + ret = devm_clk_hw_register(cprman->dev, &pll->hw); > + if (ret) > + return NULL; > + return &pll->hw; > +} > + > static struct clk_hw *bcm2835_register_pll(struct bcm2835_cprman *cprman, > const struct bcm2835_pll_data *data) > { > @@ -1462,6 +1697,9 @@ struct bcm2835_clk_desc { > #define REGISTER_PLL(...) _REGISTER(&bcm2835_register_pll, \ > &(struct bcm2835_pll_data) \ > {__VA_ARGS__}) > +#define REGISTER_FW_PLL(...) _REGISTER(&bcm2835_register_fw_pll, \ > + &(struct bcm2835_fw_pll_data) \ > + {__VA_ARGS__}) > #define REGISTER_PLL_DIV(...) _REGISTER(&bcm2835_register_pll_divider, \ > &(struct bcm2835_pll_divider_data) \ > {__VA_ARGS__}) > @@ -1654,21 +1892,11 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .flags = CLK_SET_RATE_PARENT), > > /* PLLB is used for the ARM's clock. */ > - [BCM2835_PLLB] = REGISTER_PLL( > + [BCM2835_PLLB] = REGISTER_FW_PLL( > .name = "pllb", > - .cm_ctrl_reg = CM_PLLB, > - .a2w_ctrl_reg = A2W_PLLB_CTRL, > - .frac_reg = A2W_PLLB_FRAC, > - .ana_reg_base = A2W_PLLB_ANA0, > - .reference_enable_mask = A2W_XOSC_CTRL_PLLB_ENABLE, > - .lock_mask = CM_LOCK_FLOCKB, > .flags = CLK_GET_RATE_NOCACHE, > - > - .ana = &bcm2835_ana_default, > - > - .min_rate = 600000000u, > - .max_rate = 3000000000u, > - .max_fb_rate = BCM2835_MAX_FB_RATE), > + .rate_rescale = 2, > + .firmware_clk_id = RPI_FIRMWARE_ARM_CLK_ID), > [BCM2835_PLLB_ARM] = REGISTER_PLL_DIV( > .name = "pllb_arm", > .source_pll = "pllb", > @@ -2133,9 +2361,24 @@ static int bcm2835_clk_probe(struct platform_device *pdev) > struct resource *res; > const struct bcm2835_clk_desc *desc; > const size_t asize = ARRAY_SIZE(clk_desc_array); > + struct device_node *firmware_node; > + struct rpi_firmware *firmware; > size_t i; > int ret; > > + firmware_node = of_find_node_by_name(NULL, "firmware"); I prefer of_find_compatible_node() which is more specific. > + if (!firmware_node) { > + dev_err(dev, "Missing firmware node\n"); > + return -ENOENT; > + } The firmware node should be optional for the driver. > + > + firmware = rpi_firmware_get(firmware_node); > + of_node_put(firmware_node); > + if (!firmware) { > + dev_err(dev, "Can't get raspberrypi's firmware\n"); For in case the driver for the Raspberry Pifirmware is enabled, we shouldn't spam with errors here. Stefan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-20 12:11 ` Stefan Wahren @ 2019-05-20 12:14 ` Stefan Wahren 2019-05-21 12:40 ` Stefan Wahren 1 sibling, 0 replies; 24+ messages in thread From: Stefan Wahren @ 2019-05-20 12:14 UTC (permalink / raw) To: Nicolas Saenz Julienne, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, linux-rpi-kernel, linux-clk, mbrugger, ssuloev On 20.05.19 14:11, Stefan Wahren wrote: > > Please verify that the kernel still works (and this clock driver probe) > under the following conditions: > > - CONFIG_RASPBERRYPI_FIRMWARE=n > - CONFIG_RASPBERRYPI_FIRMWARE=m > - older DTBs without patch #1 Sorry, i meant patch #4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-20 12:11 ` Stefan Wahren 2019-05-20 12:14 ` Stefan Wahren @ 2019-05-21 12:40 ` Stefan Wahren 2019-05-21 15:47 ` Nicolas Saenz Julienne 1 sibling, 1 reply; 24+ messages in thread From: Stefan Wahren @ 2019-05-21 12:40 UTC (permalink / raw) To: Nicolas Saenz Julienne, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-pm, sboyd, viresh.kumar, mturquette, ptesarik, rjw, linux-kernel, mbrugger, linux-rpi-kernel, linux-clk, linux-arm-kernel, ssuloev Hi Nicolas, On 20.05.19 14:11, Stefan Wahren wrote: > Hi Nicolas, > > the following comments applies only in case Eric is fine with the whole > approach. > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: >> Raspberry Pi's firmware, which runs in a dedicated processor, keeps > maybe we should clarify that the firmware is running in the VPU >> track of the board's temperature and voltage. It's resposible for >> scaling the CPU frequency whenever it deems the device reached an unsafe >> state. On top of that the firmware provides an interface which allows >> Linux to to query the clock's state or change it's frequency. > I think this requires a separate update of the devicetree binding. >> Being the sole user of the bcm2835 clock driver, this integrates the >> firmware interface into the clock driver and adds a first user: the CPU >> pll, also known as 'pllb'. > Please verify that the kernel still works (and this clock driver probe) > under the following conditions: > > - CONFIG_RASPBERRYPI_FIRMWARE=n > - CONFIG_RASPBERRYPI_FIRMWARE=m > - older DTBs without patch #1 i thought about this and the case this driver would return -EPROBE_DEFER. The clock driver is too essential for doing such a thing. So i think the best solution would be to move these changes into a separate driver which should be register by the clock driver (similiar to vchiq). This also avoid the need of a new device tree binding. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-21 12:40 ` Stefan Wahren @ 2019-05-21 15:47 ` Nicolas Saenz Julienne 2019-05-21 21:43 ` Stefan Wahren 0 siblings, 1 reply; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-21 15:47 UTC (permalink / raw) To: Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, linux-rpi-kernel, linux-clk, mbrugger, ssuloev [-- Attachment #1.1: Type: text/plain, Size: 2427 bytes --] Hi Stefan, thanks for your comments! On Tue, 2019-05-21 at 14:40 +0200, Stefan Wahren wrote: > Hi Nicolas, > > On 20.05.19 14:11, Stefan Wahren wrote: > > Hi Nicolas, > > > > the following comments applies only in case Eric is fine with the whole > > approach. > > > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > > > Raspberry Pi's firmware, which runs in a dedicated processor, keeps > > maybe we should clarify that the firmware is running in the VPU > > > track of the board's temperature and voltage. It's resposible for > > > scaling the CPU frequency whenever it deems the device reached an unsafe > > > state. On top of that the firmware provides an interface which allows > > > Linux to to query the clock's state or change it's frequency. > > I think this requires a separate update of the devicetree binding. > > > Being the sole user of the bcm2835 clock driver, this integrates the > > > firmware interface into the clock driver and adds a first user: the CPU > > > pll, also known as 'pllb'. > > Please verify that the kernel still works (and this clock driver probe) > > under the following conditions: > > > > - CONFIG_RASPBERRYPI_FIRMWARE=n > > - CONFIG_RASPBERRYPI_FIRMWARE=m > > - older DTBs without patch #1 > i thought about this and the case this driver would return > -EPROBE_DEFER. The clock driver is too essential for doing such a thing. > So i think the best solution would be to move these changes into a > separate driver which should be register by the clock driver (similiar > to vchiq). This also avoid the need of a new device tree binding. I understand your concerns. Wouldn't you prefer registering the device trough the device tree? I'd go with the same approach as the firmware touchscreen driver, which is registered after the firmware's probe trough dt's 'simple-bus'. That said, it's not a strongly held opinion, I'm happy with whatever solution as long as it works. I get from your comments that you'd like the register based version of 'pllb' and 'pllb_arm' to be loaded if for some reason the firmware isn't available. Is that right? The main problem I see with this is the duplication of 'pllb' and 'pllb_arm'. Both drivers will create the same clock device through different interfaces. Any suggestions on how to deal with that? If not I can simply remove 'pllb' and 'pllb_arm' from clk-bcm2835.c. Regards, Nicolas [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-21 15:47 ` Nicolas Saenz Julienne @ 2019-05-21 21:43 ` Stefan Wahren 2019-05-23 8:51 ` Nicolas Saenz Julienne 0 siblings, 1 reply; 24+ messages in thread From: Stefan Wahren @ 2019-05-21 21:43 UTC (permalink / raw) To: Nicolas Saenz Julienne, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, linux-rpi-kernel, linux-clk, mbrugger, ssuloev > Nicolas Saenz Julienne <nsaenzjulienne@suse.de> hat am 21. Mai 2019 um 17:47 geschrieben: > > > Hi Stefan, thanks for your comments! > > On Tue, 2019-05-21 at 14:40 +0200, Stefan Wahren wrote: > > Hi Nicolas, > > > > On 20.05.19 14:11, Stefan Wahren wrote: > > > Hi Nicolas, > > > > > > the following comments applies only in case Eric is fine with the whole > > > approach. > > > > > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > > > > Raspberry Pi's firmware, which runs in a dedicated processor, keeps > > > maybe we should clarify that the firmware is running in the VPU > > > > track of the board's temperature and voltage. It's resposible for > > > > scaling the CPU frequency whenever it deems the device reached an unsafe > > > > state. On top of that the firmware provides an interface which allows > > > > Linux to to query the clock's state or change it's frequency. > > > I think this requires a separate update of the devicetree binding. > > > > Being the sole user of the bcm2835 clock driver, this integrates the > > > > firmware interface into the clock driver and adds a first user: the CPU > > > > pll, also known as 'pllb'. > > > Please verify that the kernel still works (and this clock driver probe) > > > under the following conditions: > > > > > > - CONFIG_RASPBERRYPI_FIRMWARE=n > > > - CONFIG_RASPBERRYPI_FIRMWARE=m > > > - older DTBs without patch #1 > > i thought about this and the case this driver would return > > -EPROBE_DEFER. The clock driver is too essential for doing such a thing. > > So i think the best solution would be to move these changes into a > > separate driver which should be register by the clock driver (similiar > > to vchiq). This also avoid the need of a new device tree binding. > > I understand your concerns. > > Wouldn't you prefer registering the device trough the device tree? I'd go with > the same approach as the firmware touchscreen driver, which is registered after > the firmware's probe trough dt's 'simple-bus'. That said, it's not a strongly > held opinion, I'm happy with whatever solution as long as it works. A devicetree binding always introduce some kind of inflexibility. In case someone finds a better solution later things can get really messy. A recent example is the clock handling for i2c-bcm2835. > > I get from your comments that you'd like the register based version of 'pllb' > and 'pllb_arm' to be loaded if for some reason the firmware isn't available. Is > that right? This wasn't my intention. I would prefer a simple approch here (no handover). > The main problem I see with this is the duplication of 'pllb' and > 'pllb_arm'. Both drivers will create the same clock device through different > interfaces. Any suggestions on how to deal with that? If not I can simply > remove 'pllb' and 'pllb_arm' from clk-bcm2835.c. Yes. So even if this driver is disabled, there shouldn't be a regression. Or did i miss something? > > Regards, > Nicolas > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-21 21:43 ` Stefan Wahren @ 2019-05-23 8:51 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-23 8:51 UTC (permalink / raw) To: Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-pm, sboyd, viresh.kumar, mturquette, ptesarik, rjw, linux-kernel, mbrugger, linux-rpi-kernel, linux-clk, linux-arm-kernel, ssuloev [-- Attachment #1.1: Type: text/plain, Size: 3390 bytes --] On Tue, 2019-05-21 at 23:43 +0200, Stefan Wahren wrote: > > Nicolas Saenz Julienne <nsaenzjulienne@suse.de> hat am 21. Mai 2019 um 17:47 > > geschrieben: > > > > > > Hi Stefan, thanks for your comments! > > > > On Tue, 2019-05-21 at 14:40 +0200, Stefan Wahren wrote: > > > Hi Nicolas, > > > > > > On 20.05.19 14:11, Stefan Wahren wrote: > > > > Hi Nicolas, > > > > > > > > the following comments applies only in case Eric is fine with the whole > > > > approach. > > > > > > > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > > > > > Raspberry Pi's firmware, which runs in a dedicated processor, keeps > > > > maybe we should clarify that the firmware is running in the VPU > > > > > track of the board's temperature and voltage. It's resposible for > > > > > scaling the CPU frequency whenever it deems the device reached an > > > > > unsafe > > > > > state. On top of that the firmware provides an interface which allows > > > > > Linux to to query the clock's state or change it's frequency. > > > > I think this requires a separate update of the devicetree binding. > > > > > Being the sole user of the bcm2835 clock driver, this integrates the > > > > > firmware interface into the clock driver and adds a first user: the > > > > > CPU > > > > > pll, also known as 'pllb'. > > > > Please verify that the kernel still works (and this clock driver probe) > > > > under the following conditions: > > > > > > > > - CONFIG_RASPBERRYPI_FIRMWARE=n > > > > - CONFIG_RASPBERRYPI_FIRMWARE=m > > > > - older DTBs without patch #1 > > > i thought about this and the case this driver would return > > > -EPROBE_DEFER. The clock driver is too essential for doing such a thing. > > > So i think the best solution would be to move these changes into a > > > separate driver which should be register by the clock driver (similiar > > > to vchiq). This also avoid the need of a new device tree binding. > > > > I understand your concerns. > > > > Wouldn't you prefer registering the device trough the device tree? I'd go > > with > > the same approach as the firmware touchscreen driver, which is registered > > after > > the firmware's probe trough dt's 'simple-bus'. That said, it's not a > > strongly > > held opinion, I'm happy with whatever solution as long as it works. > > A devicetree binding always introduce some kind of inflexibility. In case > someone finds a better solution later things can get really messy. A recent > example is the clock handling for i2c-bcm2835. Fair enough. > > I get from your comments that you'd like the register based version of > > 'pllb' > > and 'pllb_arm' to be loaded if for some reason the firmware isn't available. > > Is > > that right? > > This wasn't my intention. I would prefer a simple approch here (no handover). > > > The main problem I see with this is the duplication of 'pllb' and > > 'pllb_arm'. Both drivers will create the same clock device through different > > interfaces. Any suggestions on how to deal with that? If not I can simply > > remove 'pllb' and 'pllb_arm' from clk-bcm2835.c. > > Yes. So even if this driver is disabled, there shouldn't be a regression. Or > did i miss something? No, there shoudn't be any regressions as these clocks are not being used at the moment. I'll send a follow-up series soon :) Regrads, Nicolas [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-20 10:47 ` [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Nicolas Saenz Julienne 2019-05-20 12:11 ` Stefan Wahren @ 2019-05-20 12:43 ` Oliver Neukum 2019-05-21 11:39 ` Nicolas Saenz Julienne 1 sibling, 1 reply; 24+ messages in thread From: Oliver Neukum @ 2019-05-20 12:43 UTC (permalink / raw) To: Nicolas Saenz Julienne, stefan.wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, linux-rpi-kernel, linux-clk, mbrugger, ssuloev On Mo, 2019-05-20 at 12:47 +0200, Nicolas Saenz Julienne wrote: > + * For more information on the firmware interface check: > + * https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface > + */ > +struct bcm2835_firmware_prop { > + u32 id; > + u32 val; > + u32 disable_turbo; > +} __packed; Hi, technically we are not in arch and those fields have a defined endianness. Regards Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-20 12:43 ` Oliver Neukum @ 2019-05-21 11:39 ` Nicolas Saenz Julienne 2019-05-21 12:14 ` Petr Tesarik 0 siblings, 1 reply; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-21 11:39 UTC (permalink / raw) To: Oliver Neukum, stefan.wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt Cc: linux-arm-kernel, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, linux-rpi-kernel, linux-clk, mbrugger, ssuloev [-- Attachment #1.1: Type: text/plain, Size: 916 bytes --] Hi Oliver, thanks for the review. On Mon, 2019-05-20 at 14:43 +0200, Oliver Neukum wrote: > On Mo, 2019-05-20 at 12:47 +0200, Nicolas Saenz Julienne wrote: > > + * For more information on the firmware interface check: > > + * https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface > > + */ > > +struct bcm2835_firmware_prop { > > + u32 id; > > + u32 val; > > + u32 disable_turbo; > > +} __packed; > > Hi, > > technically we are not in arch and those fields have a defined > endianness. > Well I set it as packed since it's 'sent' through a memory mapped firmware interface. Hence the need for the structure format to be fixed. So I guessed we're safer with it, as I'm not 100% sure what the different compilers are going to do with it (although it's very likely it'll stay the same). BTW this will be built both for arm & arm64. Regards, Nicolas [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-21 11:39 ` Nicolas Saenz Julienne @ 2019-05-21 12:14 ` Petr Tesarik 2019-05-21 12:18 ` Nicolas Saenz Julienne 0 siblings, 1 reply; 24+ messages in thread From: Petr Tesarik @ 2019-05-21 12:14 UTC (permalink / raw) To: Nicolas Saenz Julienne Cc: stefan.wahren, Florian Fainelli, linux-arm-kernel, Scott Branden, linux-pm, sboyd, Ray Jui, mturquette, Oliver Neukum, rjw, linux-kernel, Eric Anholt, bcm-kernel-feedback-list, linux-rpi-kernel, viresh.kumar, linux-clk, mbrugger, ssuloev [-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --] On Tue, 21 May 2019 13:39:31 +0200 Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote: > Hi Oliver, thanks for the review. > > On Mon, 2019-05-20 at 14:43 +0200, Oliver Neukum wrote: > > On Mo, 2019-05-20 at 12:47 +0200, Nicolas Saenz Julienne wrote: > > > + * For more information on the firmware interface check: > > > + * https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface > > > + */ > > > +struct bcm2835_firmware_prop { > > > + u32 id; > > > + u32 val; > > > + u32 disable_turbo; > > > +} __packed; > > > > Hi, > > > > technically we are not in arch and those fields have a defined > > endianness. > > > > Well I set it as packed since it's 'sent' through a memory mapped firmware > interface. Hence the need for the structure format to be fixed. So I guessed > we're safer with it, as I'm not 100% sure what the different compilers are > going to do with it (although it's very likely it'll stay the same). BTW this > will be built both for arm & arm64. I believe that's not the point Oliver was trying to make. You should use __le32 instead of u32. That's because u32 means "host byte order" and this code is not located under arch/, so host endianness is unknown, but the mailbox interface requires little-endian. It's nit-picking, and that's why Oliver writes 'technically'; there is probably no way this firmware interface could be used on a big-endian CPU... Petr T [-- Attachment #1.2: Digitální podpis OpenPGP --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb 2019-05-21 12:14 ` Petr Tesarik @ 2019-05-21 12:18 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-21 12:18 UTC (permalink / raw) To: Petr Tesarik Cc: stefan.wahren, Florian Fainelli, linux-arm-kernel, Scott Branden, linux-pm, sboyd, Ray Jui, mturquette, Oliver Neukum, rjw, linux-kernel, Eric Anholt, bcm-kernel-feedback-list, linux-rpi-kernel, viresh.kumar, linux-clk, mbrugger, ssuloev [-- Attachment #1.1: Type: text/plain, Size: 1680 bytes --] On Tue, 2019-05-21 at 14:14 +0200, Petr Tesarik wrote: > On Tue, 21 May 2019 13:39:31 +0200 > Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote: > > > Hi Oliver, thanks for the review. > > > > On Mon, 2019-05-20 at 14:43 +0200, Oliver Neukum wrote: > > > On Mo, 2019-05-20 at 12:47 +0200, Nicolas Saenz Julienne wrote: > > > > + * For more information on the firmware interface check: > > > > + * > > > > https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface > > > > + */ > > > > +struct bcm2835_firmware_prop { > > > > + u32 id; > > > > + u32 val; > > > > + u32 disable_turbo; > > > > +} __packed; > > > > > > Hi, > > > > > > technically we are not in arch and those fields have a defined > > > endianness. > > > > > > > Well I set it as packed since it's 'sent' through a memory mapped firmware > > interface. Hence the need for the structure format to be fixed. So I guessed > > we're safer with it, as I'm not 100% sure what the different compilers are > > going to do with it (although it's very likely it'll stay the same). BTW > > this > > will be built both for arm & arm64. > > I believe that's not the point Oliver was trying to make. You should > use __le32 instead of u32. > > That's because u32 means "host byte order" and this code is not located > under arch/, so host endianness is unknown, but the mailbox interface > requires little-endian. > > It's nit-picking, and that's why Oliver writes 'technically'; there is > probably no way this firmware interface could be used on a big-endian > CPU... Understood, thanks for the clarification. Regards, Nicolas [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne ` (2 preceding siblings ...) 2019-05-20 10:47 ` [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Nicolas Saenz Julienne @ 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 12:19 ` Stefan Wahren 2019-05-20 10:47 ` [RFC v2 5/5] cpufreq: add driver for Raspbery Pi Nicolas Saenz Julienne 2019-05-20 10:51 ` [RFC v2 0/5] cpufreq support for the Raspberry Pi Viresh Kumar 5 siblings, 1 reply; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-20 10:47 UTC (permalink / raw) To: stefan.wahren, Rob Herring, Mark Rutland, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list Cc: linux-arm-kernel, devicetree, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, eric, linux-rpi-kernel, Nicolas Saenz Julienne, linux-clk, mbrugger, ssuloev The four CPUs share a same clock source called pllb_arm. The clock can be scaled through the raspberrypi firmware interface. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- arch/arm/boot/dts/bcm2837.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi index beb6c502dadc..a8fea6696b42 100644 --- a/arch/arm/boot/dts/bcm2837.dtsi +++ b/arch/arm/boot/dts/bcm2837.dtsi @@ -44,6 +44,8 @@ reg = <0>; enable-method = "spin-table"; cpu-release-addr = <0x0 0x000000d8>; + clocks = <&clocks BCM2835_PLLB_ARM>; + clock-names = "pllb_arm"; }; cpu1: cpu@1 { @@ -52,6 +54,8 @@ reg = <1>; enable-method = "spin-table"; cpu-release-addr = <0x0 0x000000e0>; + clocks = <&clocks BCM2835_PLLB_ARM>; + clock-names = "pllb_arm"; }; cpu2: cpu@2 { @@ -60,6 +64,8 @@ reg = <2>; enable-method = "spin-table"; cpu-release-addr = <0x0 0x000000e8>; + clocks = <&clocks BCM2835_PLLB_ARM>; + clock-names = "pllb_arm"; }; cpu3: cpu@3 { @@ -68,6 +74,8 @@ reg = <3>; enable-method = "spin-table"; cpu-release-addr = <0x0 0x000000f0>; + clocks = <&clocks BCM2835_PLLB_ARM>; + clock-names = "pllb_arm"; }; }; }; -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices 2019-05-20 10:47 ` [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices Nicolas Saenz Julienne @ 2019-05-20 12:19 ` Stefan Wahren 2019-05-21 11:40 ` Nicolas Saenz Julienne 0 siblings, 1 reply; 24+ messages in thread From: Stefan Wahren @ 2019-05-20 12:19 UTC (permalink / raw) To: Nicolas Saenz Julienne, Rob Herring, Mark Rutland, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list Cc: linux-arm-kernel, devicetree, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, eric, linux-rpi-kernel, linux-clk, mbrugger, ssuloev Hi Nicolas, On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > The four CPUs share a same clock source called pllb_arm. The clock can > be scaled through the raspberrypi firmware interface. do you see a problem with applying this also to bcm2835.dtsi and bcm2836.dtsi? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices 2019-05-20 12:19 ` Stefan Wahren @ 2019-05-21 11:40 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-21 11:40 UTC (permalink / raw) To: Stefan Wahren, Rob Herring, Mark Rutland, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list Cc: linux-arm-kernel, devicetree, ptesarik, sboyd, viresh.kumar, mturquette, linux-pm, rjw, linux-kernel, eric, linux-rpi-kernel, linux-clk, mbrugger, ssuloev [-- Attachment #1.1: Type: text/plain, Size: 395 bytes --] On Mon, 2019-05-20 at 14:19 +0200, Stefan Wahren wrote: > Hi Nicolas, > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > > The four CPUs share a same clock source called pllb_arm. The clock can > > be scaled through the raspberrypi firmware interface. > do you see a problem with applying this also to bcm2835.dtsi and > bcm2836.dtsi? Not at all. I just need to test it first. [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC v2 5/5] cpufreq: add driver for Raspbery Pi 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne ` (3 preceding siblings ...) 2019-05-20 10:47 ` [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices Nicolas Saenz Julienne @ 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 10:51 ` Viresh Kumar 2019-05-20 12:30 ` Stefan Wahren 2019-05-20 10:51 ` [RFC v2 0/5] cpufreq support for the Raspberry Pi Viresh Kumar 5 siblings, 2 replies; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-20 10:47 UTC (permalink / raw) To: stefan.wahren, Rafael J. Wysocki, Viresh Kumar Cc: linux-arm-kernel, f.fainelli, ptesarik, sboyd, mturquette, linux-pm, linux-kernel, eric, bcm-kernel-feedback-list, linux-rpi-kernel, Nicolas Saenz Julienne, linux-clk, mbrugger, ssuloev Raspberry Pi's firmware offers and interface though which update it's performance requirements. It allows us to request for specific runtime frequencies, which the firmware might or might not respect, depending on the firmware configuration and thermals. As the maximum and minimum frequencies are configurable in the firmware there is no way to know in advance their values. So the Raspberry Pi cpufreq driver queries them, builds an opp frequency table to then launch cpufreq-dt. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- drivers/cpufreq/Kconfig.arm | 8 +++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/raspberrypi-cpufreq.c | 83 +++++++++++++++++++++++++++ 3 files changed, 92 insertions(+) create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 179a1d302f48..f6eba7ae50d0 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -308,3 +308,11 @@ config ARM_PXA2xx_CPUFREQ This add the CPUFreq driver support for Intel PXA2xx SOCs. If in doubt, say N. + +config ARM_RASPBERRYPI_CPUFREQ + tristate "Raspberry Pi cpufreq support" + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST + help + This adds the CPUFreq driver for Raspberry Pi + + If in doubt, say N. diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 689b26c6f949..02678e9b2ff5 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -84,6 +84,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o +obj-$(CONFIG_ARM_RASPBERRYPI_CPUFREQ) += raspberrypi-cpufreq.o ################################################################################## diff --git a/drivers/cpufreq/raspberrypi-cpufreq.c b/drivers/cpufreq/raspberrypi-cpufreq.c new file mode 100644 index 000000000000..a85988867d56 --- /dev/null +++ b/drivers/cpufreq/raspberrypi-cpufreq.c @@ -0,0 +1,83 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Raspberry Pi cpufreq driver + * + * Copyright (C) 2019, Nicolas Saenz Julienne <nsaenzjulienne@suse.de> + */ + +#include <linux/of.h> +#include <linux/clk.h> +#include <linux/cpu.h> +#include <linux/module.h> +#include <linux/pm_opp.h> +#include <linux/cpufreq.h> +#include <linux/platform_device.h> + +static const struct of_device_id machines[] __initconst = { + { .compatible = "raspberrypi,3-model-b-plus" }, + { .compatible = "raspberrypi,3-model-b" }, + { /* sentinel */ } +}; + +static int __init raspberrypi_cpufreq_driver_init(void) +{ + struct platform_device *pdev; + struct device *cpu_dev; + struct clk *clk; + long min, max; + long rate; + int ret; + + if (!of_match_node(machines, of_root)) + return -ENODEV; + + cpu_dev = get_cpu_device(0); + if (!cpu_dev) { + pr_err("Cannot get CPU for cpufreq driver\n"); + return -ENODEV; + } + + clk = clk_get(cpu_dev, 0); + if (IS_ERR(clk)) { + dev_err(cpu_dev, "Cannot get clock for CPU0\n"); + return PTR_ERR(clk); + } + + /* + * The max and min frequencies are configurable in the Raspberry Pi + * firmware, so we query them at runtime + */ + min = clk_round_rate(clk, 0); + max = clk_round_rate(clk, ULONG_MAX); + clk_put(clk); + + for (rate = min; rate < max; rate += 100000000) { + ret = dev_pm_opp_add(cpu_dev, rate, 0); + if (ret) + goto remove_opp; + } + + ret = dev_pm_opp_add(cpu_dev, max, 0); + if (ret) + goto remove_opp; + + pdev = platform_device_register_data(NULL, "cpufreq-dt", -1, NULL, 0); + ret = PTR_ERR_OR_ZERO(pdev); + if (ret) { + dev_err(cpu_dev, "Failed to create platform device, %d\n", ret); + goto remove_opp; + } + + return 0; + +remove_opp: + dev_pm_opp_remove_all_dynamic(cpu_dev); + + return ret; +} + +late_initcall(raspberrypi_cpufreq_driver_init); + +MODULE_AUTHOR("Nicolas Saenz Julienne <nsaenzjulienne@suse.de"); +MODULE_DESCRIPTION("Raspberry Pi cpufreq driver"); +MODULE_LICENSE("GPL v2"); -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [RFC v2 5/5] cpufreq: add driver for Raspbery Pi 2019-05-20 10:47 ` [RFC v2 5/5] cpufreq: add driver for Raspbery Pi Nicolas Saenz Julienne @ 2019-05-20 10:51 ` Viresh Kumar 2019-05-20 12:30 ` Stefan Wahren 1 sibling, 0 replies; 24+ messages in thread From: Viresh Kumar @ 2019-05-20 10:51 UTC (permalink / raw) To: Nicolas Saenz Julienne Cc: stefan.wahren, f.fainelli, linux-arm-kernel, ptesarik, sboyd, mturquette, linux-pm, Rafael J. Wysocki, linux-kernel, eric, bcm-kernel-feedback-list, linux-rpi-kernel, linux-clk, mbrugger, ssuloev On 20-05-19, 12:47, Nicolas Saenz Julienne wrote: > Raspberry Pi's firmware offers and interface though which update it's > performance requirements. It allows us to request for specific runtime > frequencies, which the firmware might or might not respect, depending on > the firmware configuration and thermals. > > As the maximum and minimum frequencies are configurable in the firmware > there is no way to know in advance their values. So the Raspberry Pi > cpufreq driver queries them, builds an opp frequency table to then > launch cpufreq-dt. > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > --- > drivers/cpufreq/Kconfig.arm | 8 +++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/raspberrypi-cpufreq.c | 83 +++++++++++++++++++++++++++ > 3 files changed, 92 insertions(+) > create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index 179a1d302f48..f6eba7ae50d0 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -308,3 +308,11 @@ config ARM_PXA2xx_CPUFREQ > This add the CPUFreq driver support for Intel PXA2xx SOCs. > > If in doubt, say N. > + > +config ARM_RASPBERRYPI_CPUFREQ > + tristate "Raspberry Pi cpufreq support" > + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST > + help > + This adds the CPUFreq driver for Raspberry Pi > + > + If in doubt, say N. > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 689b26c6f949..02678e9b2ff5 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -84,6 +84,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o > obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o > obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o > obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o > +obj-$(CONFIG_ARM_RASPBERRYPI_CPUFREQ) += raspberrypi-cpufreq.o My bad sorry, I noticed this earlier and forgot to comment. The above two files are maintained in alphabetical order, please add the entries at relevant places. > ################################################################################## > diff --git a/drivers/cpufreq/raspberrypi-cpufreq.c b/drivers/cpufreq/raspberrypi-cpufreq.c > new file mode 100644 > index 000000000000..a85988867d56 > --- /dev/null > +++ b/drivers/cpufreq/raspberrypi-cpufreq.c > @@ -0,0 +1,83 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Raspberry Pi cpufreq driver > + * > + * Copyright (C) 2019, Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > + */ > + > +#include <linux/of.h> > +#include <linux/clk.h> > +#include <linux/cpu.h> > +#include <linux/module.h> > +#include <linux/pm_opp.h> > +#include <linux/cpufreq.h> > +#include <linux/platform_device.h> Would be better to keep above in alphabetical order as well. Please don't send another version now and wait for comments on the other patches. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 5/5] cpufreq: add driver for Raspbery Pi 2019-05-20 10:47 ` [RFC v2 5/5] cpufreq: add driver for Raspbery Pi Nicolas Saenz Julienne 2019-05-20 10:51 ` Viresh Kumar @ 2019-05-20 12:30 ` Stefan Wahren 1 sibling, 0 replies; 24+ messages in thread From: Stefan Wahren @ 2019-05-20 12:30 UTC (permalink / raw) To: Nicolas Saenz Julienne, Rafael J. Wysocki, Viresh Kumar Cc: linux-arm-kernel, f.fainelli, ptesarik, sboyd, mturquette, linux-pm, linux-kernel, eric, bcm-kernel-feedback-list, linux-rpi-kernel, linux-clk, mbrugger, ssuloev On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > Raspberry Pi's firmware offers and interface though which update it's > performance requirements. It allows us to request for specific runtime > frequencies, which the firmware might or might not respect, depending on > the firmware configuration and thermals. > > As the maximum and minimum frequencies are configurable in the firmware > there is no way to know in advance their values. So the Raspberry Pi > cpufreq driver queries them, builds an opp frequency table to then > launch cpufreq-dt. > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > --- > drivers/cpufreq/Kconfig.arm | 8 +++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/raspberrypi-cpufreq.c | 83 +++++++++++++++++++++++++++ > 3 files changed, 92 insertions(+) > create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index 179a1d302f48..f6eba7ae50d0 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -308,3 +308,11 @@ config ARM_PXA2xx_CPUFREQ > This add the CPUFreq driver support for Intel PXA2xx SOCs. > > If in doubt, say N. > + > +config ARM_RASPBERRYPI_CPUFREQ > + tristate "Raspberry Pi cpufreq support" > + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST The driver doesn't really require the firmware driver to compile, how about: select RASPBERRYPI_FIRMWARE > + help > + This adds the CPUFreq driver for Raspberry Pi > + > + If in doubt, say N. > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 689b26c6f949..02678e9b2ff5 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -84,6 +84,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o > obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o > obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o > obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o > +obj-$(CONFIG_ARM_RASPBERRYPI_CPUFREQ) += raspberrypi-cpufreq.o > > > ################################################################################## > diff --git a/drivers/cpufreq/raspberrypi-cpufreq.c b/drivers/cpufreq/raspberrypi-cpufreq.c > new file mode 100644 > index 000000000000..a85988867d56 > --- /dev/null > +++ b/drivers/cpufreq/raspberrypi-cpufreq.c > @@ -0,0 +1,83 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Raspberry Pi cpufreq driver > + * > + * Copyright (C) 2019, Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > + */ > + > +#include <linux/of.h> > +#include <linux/clk.h> > +#include <linux/cpu.h> > +#include <linux/module.h> > +#include <linux/pm_opp.h> > +#include <linux/cpufreq.h> > +#include <linux/platform_device.h> > + > +static const struct of_device_id machines[] __initconst = { > + { .compatible = "raspberrypi,3-model-b-plus" }, > + { .compatible = "raspberrypi,3-model-b" }, > + { /* sentinel */ } > +}; > + > +static int __init raspberrypi_cpufreq_driver_init(void) > +{ > + struct platform_device *pdev; > + struct device *cpu_dev; > + struct clk *clk; > + long min, max; > + long rate; > + int ret; > + > + if (!of_match_node(machines, of_root)) > + return -ENODEV; > + > + cpu_dev = get_cpu_device(0); > + if (!cpu_dev) { > + pr_err("Cannot get CPU for cpufreq driver\n"); > + return -ENODEV; > + } > + > + clk = clk_get(cpu_dev, 0); I suggest use the expected clock ID. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 0/5] cpufreq support for the Raspberry Pi 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne ` (4 preceding siblings ...) 2019-05-20 10:47 ` [RFC v2 5/5] cpufreq: add driver for Raspbery Pi Nicolas Saenz Julienne @ 2019-05-20 10:51 ` Viresh Kumar 2019-05-21 12:02 ` Nicolas Saenz Julienne 5 siblings, 1 reply; 24+ messages in thread From: Viresh Kumar @ 2019-05-20 10:51 UTC (permalink / raw) To: Nicolas Saenz Julienne Cc: stefan.wahren, devicetree, f.fainelli, linux-pm, sboyd, mturquette, ptesarik, rjw, linux-kernel, eric, bcm-kernel-feedback-list, linux-rpi-kernel, ssuloev, linux-clk, mbrugger, linux-arm-kernel 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. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC v2 0/5] cpufreq support for the Raspberry Pi 2019-05-20 10:51 ` [RFC v2 0/5] cpufreq support for the Raspberry Pi Viresh Kumar @ 2019-05-21 12:02 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 24+ messages in thread From: Nicolas Saenz Julienne @ 2019-05-21 12:02 UTC (permalink / raw) To: Viresh Kumar Cc: stefan.wahren, devicetree, f.fainelli, linux-pm, sboyd, mturquette, ptesarik, rjw, linux-kernel, eric, bcm-kernel-feedback-list, linux-rpi-kernel, ssuloev, linux-clk, mbrugger, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 2649 bytes --] 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 [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-05-23 8:51 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks Nicolas Saenz Julienne 2019-05-20 11:42 ` Stefan Wahren 2019-05-20 10:47 ` [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly Nicolas Saenz Julienne 2019-05-20 11:43 ` Stefan Wahren 2019-05-20 10:47 ` [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Nicolas Saenz Julienne 2019-05-20 12:11 ` Stefan Wahren 2019-05-20 12:14 ` Stefan Wahren 2019-05-21 12:40 ` Stefan Wahren 2019-05-21 15:47 ` Nicolas Saenz Julienne 2019-05-21 21:43 ` Stefan Wahren 2019-05-23 8:51 ` Nicolas Saenz Julienne 2019-05-20 12:43 ` Oliver Neukum 2019-05-21 11:39 ` Nicolas Saenz Julienne 2019-05-21 12:14 ` Petr Tesarik 2019-05-21 12:18 ` Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices Nicolas Saenz Julienne 2019-05-20 12:19 ` Stefan Wahren 2019-05-21 11:40 ` Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 5/5] cpufreq: add driver for Raspbery Pi Nicolas Saenz Julienne 2019-05-20 10:51 ` Viresh Kumar 2019-05-20 12:30 ` Stefan Wahren 2019-05-20 10:51 ` [RFC v2 0/5] cpufreq support for the Raspberry Pi Viresh Kumar 2019-05-21 12:02 ` Nicolas Saenz Julienne
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).