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

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

[Nicolas Saenz Julienne]

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

[RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks

[Nicolas Saenz Julienne]

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

[RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly

[Nicolas Saenz Julienne]

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

[RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Nicolas Saenz Julienne]

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

[RFC v2 4/5] dts: bcm2837: add per-cpu clock devices

[Nicolas Saenz Julienne]

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

[RFC v2 5/5] cpufreq: add driver for Raspbery Pi

[Nicolas Saenz Julienne]

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

Re: [RFC v2 5/5] cpufreq: add driver for Raspbery Pi

[Viresh Kumar]

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

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

[Viresh Kumar]

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

Re: [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks

[Stefan Wahren]

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

Re: [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly

[Stefan Wahren]

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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Stefan Wahren]

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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Stefan Wahren]

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

Re: [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices

[Stefan Wahren]

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

Re: [RFC v2 5/5] cpufreq: add driver for Raspbery Pi

[Stefan Wahren]

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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Oliver Neukum]

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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Nicolas Saenz Julienne]

[-- 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

Re: [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices

[Nicolas Saenz Julienne]

[-- 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

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

[Nicolas Saenz Julienne]

[-- 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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Petr Tesarik]

[-- 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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Nicolas Saenz Julienne]

[-- 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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Stefan Wahren]

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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Nicolas Saenz Julienne]

[-- 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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Stefan Wahren]

> 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

Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

[Nicolas Saenz Julienne]

[-- 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