The pin controller resources start at 0xc0 from the CRU base which is at
0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
are currently off by 0x100. The resource size of the CRU is also
incorrect and should end at 0x248 bytes from 0x100 which is the start
address. Finally, the compatibility strings defined for the
pin-controller node should reflect the SoC being used.
Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux controller")
Reported-by: Christian Lamparter <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
---
Christian, can you test this as a preliminary patch for your Cisco
Meraki MR32 series? Thanks!
arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
arch/arm/boot/dts/bcm4709.dtsi | 4 ++++
arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++----
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
index 1a19e97a987d..5064fe51e402 100644
--- a/arch/arm/boot/dts/bcm4708.dtsi
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -43,6 +43,10 @@ cpu@1 {
};
+&pinctrl {
+ compatible = "brcm,bcm4708-pinmux";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
index e1bb8661955f..7417c275ea9d 100644
--- a/arch/arm/boot/dts/bcm4709.dtsi
+++ b/arch/arm/boot/dts/bcm4709.dtsi
@@ -5,6 +5,10 @@
#include "bcm4708.dtsi"
+&pinctrl {
+ compatible = "brcm,bcm4709-pinmux";
+};
+
&uart0 {
clock-frequency = <125000000>;
status = "okay";
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 2d9b4dd05830..bf49943f504a 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -402,14 +402,14 @@ dmu@1800c000 {
cru@100 {
compatible = "simple-bus";
- reg = <0x100 0x1a4>;
+ reg = <0x100 0x248>;
ranges;
#address-cells = <1>;
#size-cells = <1>;
- pin-controller@1c0 {
- compatible = "brcm,bcm4708-pinmux";
- reg = <0x1c0 0x24>;
+ pinctrl: pin-controller@c0 {
+ compatible = "brcm,bcm53012-pinmux";
+ reg = <0xc0 0x24>;
reg-names = "cru_gpio_control";
spi-pins {
--
2.25.1
On 8/18/2020 9:23 PM, Florian Fainelli wrote:
> The pin controller resources start at 0xc0 from the CRU base which is at
> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
> are currently off by 0x100. The resource size of the CRU is also
> incorrect and should end at 0x248 bytes from 0x100 which is the start
> address. Finally, the compatibility strings defined for the
> pin-controller node should reflect the SoC being used.
>
> Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux controller")
> Reported-by: Christian Lamparter <[email protected]>
> Signed-off-by: Florian Fainelli <[email protected]>
> ---
> Christian, can you test this as a preliminary patch for your Cisco
> Meraki MR32 series? Thanks!
>
> arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
> arch/arm/boot/dts/bcm4709.dtsi | 4 ++++
> arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++----
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> index 1a19e97a987d..5064fe51e402 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -43,6 +43,10 @@ cpu@1 {
>
> };
>
> +&pinctrl {
> + compatible = "brcm,bcm4708-pinmux";
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
> index e1bb8661955f..7417c275ea9d 100644
> --- a/arch/arm/boot/dts/bcm4709.dtsi
> +++ b/arch/arm/boot/dts/bcm4709.dtsi
> @@ -5,6 +5,10 @@
>
> #include "bcm4708.dtsi"
>
> +&pinctrl {
> + compatible = "brcm,bcm4709-pinmux";
> +};
> +
> &uart0 {
> clock-frequency = <125000000>;
> status = "okay";
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index 2d9b4dd05830..bf49943f504a 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -402,14 +402,14 @@ dmu@1800c000 {
>
> cru@100 {
> compatible = "simple-bus";
> - reg = <0x100 0x1a4>;
> + reg = <0x100 0x248>;
> ranges;
> #address-cells = <1>;
> #size-cells = <1>;
>
> - pin-controller@1c0 {
> - compatible = "brcm,bcm4708-pinmux";
> - reg = <0x1c0 0x24>;
> + pinctrl: pin-controller@c0 {
> + compatible = "brcm,bcm53012-pinmux";
> + reg = <0xc0 0x24>;
> reg-names = "cru_gpio_control";
>
> spi-pins {
>
Reviewed-by: Ray Jui <[email protected]>
On Wed, 19 Aug 2020 at 06:23, Florian Fainelli <[email protected]> wrote:
> The pin controller resources start at 0xc0 from the CRU base which is at
> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
> are currently off by 0x100. The resource size of the CRU is also
> incorrect and should end at 0x248 bytes from 0x100 which is the start
> address. Finally, the compatibility strings defined for the
> pin-controller node should reflect the SoC being used.
>
> Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux controller")
Let me verify that fix. I'm confused as I believe I got pinctrl
working for uart1 :|
On 8/19/20 8:36 AM, Rafał Miłecki wrote:
> On Wed, 19 Aug 2020 at 06:23, Florian Fainelli <[email protected]> wrote:
>> The pin controller resources start at 0xc0 from the CRU base which is at
>> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
>> are currently off by 0x100. The resource size of the CRU is also
>> incorrect and should end at 0x248 bytes from 0x100 which is the start
>> address. Finally, the compatibility strings defined for the
>> pin-controller node should reflect the SoC being used.
>>
>> Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux controller")
>
> Let me verify that fix. I'm confused as I believe I got pinctrl
> working for uart1 :|
Sure, please let me know what you find. Chances are that UART1 was
already pinmuxed corectly by the boot loader for your device and this
could have turned out as a no-op.
--
Florian
On 2020-08-19 06:23, Florian Fainelli wrote:
> The pin controller resources start at 0xc0 from the CRU base which is at
> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
> are currently off by 0x100. The resource size of the CRU is also
> incorrect and should end at 0x248 bytes from 0x100 which is the start
> address. Finally, the compatibility strings defined for the
> pin-controller node should reflect the SoC being used.
>
> Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux controller")
> Reported-by: Christian Lamparter <[email protected]>
> Signed-off-by: Florian Fainelli <[email protected]>
> ---
> Christian, can you test this as a preliminary patch for your Cisco
> Meraki MR32 series? Thanks!
Hm, it looks like this is more complicated than this. We should have
looked at pinctrl-ns.c's ns_pinctrl_probe() [0] before calling it.
| ns_pinctrl->regmap = syscon_node_to_regmap(of_get_parent(np));
| if (IS_ERR(ns_pinctrl->regmap)) {
| int err = PTR_ERR(ns_pinctrl->regmap);
|
| dev_err(dev, "Failed to map pinctrl regs: %d\n", err);
|
| return err;
| }
|
| if (of_property_read_u32(np, "offset", &ns_pinctrl->offset)) {
| dev_err(dev, "Failed to get register offset\n");
| return -ENOENT;
| }
So, the ns_pinctrl_probe() takes the address of the parent node (cru)
and then looks for a "offset" property to add to this (which is missing
in the bcm5301x.dtsi [1]).
Thing is, for this to work, the parent-node should be a "simple-mfd" (so
a regmap is created for the reg), right? This would also mean that the
"reg" property in the pin-controller node is just cosmetic.
I guess the reason why this sort-of-works for me is because I'm using
this MR32 with OpenWrt (Rafał Miłecki is probably using it too ;) ).
(Note: We should not forget to update the binding-documentation as well!)
BTW: I'll reply my findings for the i2c issue with the MR32 in the other
mail.
>
> arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
> arch/arm/boot/dts/bcm4709.dtsi | 4 ++++
> arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++----
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> index 1a19e97a987d..5064fe51e402 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -43,6 +43,10 @@ cpu@1 {
>
> };
>
> +&pinctrl {
> + compatible = "brcm,bcm4708-pinmux";
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
> index e1bb8661955f..7417c275ea9d 100644
> --- a/arch/arm/boot/dts/bcm4709.dtsi
> +++ b/arch/arm/boot/dts/bcm4709.dtsi
> @@ -5,6 +5,10 @@
>
> #include "bcm4708.dtsi"
>
> +&pinctrl {
> + compatible = "brcm,bcm4709-pinmux";
> +};
> +
> &uart0 {
> clock-frequency = <125000000>;
> status = "okay";
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index 2d9b4dd05830..bf49943f504a 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -402,14 +402,14 @@ dmu@1800c000 {
>
> cru@100 {
> compatible = "simple-bus";
> - reg = <0x100 0x1a4>;
> + reg = <0x100 0x248>;
> ranges;
> #address-cells = <1>;
> #size-cells = <1>;
>
> - pin-controller@1c0 {
> - compatible = "brcm,bcm4708-pinmux";
> - reg = <0x1c0 0x24>;
> + pinctrl: pin-controller@c0 {
> + compatible = "brcm,bcm53012-pinmux";
> + reg = <0xc0 0x24>;
> reg-names = "cru_gpio_control";
>
> spi-pins {
>
[0]
<https://elixir.bootlin.com/linux/v5.9-rc1/source/drivers/pinctrl/bcm/pinctrl-ns.c#L302>
[1]
<https://elixir.bootlin.com/linux/v5.9-rc1/source/arch/arm/boot/dts/bcm5301x.dtsi#L410>
On 8/19/20 1:48 PM, Christian Lamparter wrote:
> On 2020-08-19 06:23, Florian Fainelli wrote:
>> The pin controller resources start at 0xc0 from the CRU base which is at
>> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
>> are currently off by 0x100. The resource size of the CRU is also
>> incorrect and should end at 0x248 bytes from 0x100 which is the start
>> address. Finally, the compatibility strings defined for the
>> pin-controller node should reflect the SoC being used.
>>
>> Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux
>> controller")
>> Reported-by: Christian Lamparter <[email protected]>
>> Signed-off-by: Florian Fainelli <[email protected]>
>> ---
>> Christian, can you test this as a preliminary patch for your Cisco
>> Meraki MR32 series? Thanks!
>
> Hm, it looks like this is more complicated than this. We should have
> looked at pinctrl-ns.c's ns_pinctrl_probe() [0] before calling it.
>
> | ns_pinctrl->regmap = syscon_node_to_regmap(of_get_parent(np));
> | if (IS_ERR(ns_pinctrl->regmap)) {
> | int err = PTR_ERR(ns_pinctrl->regmap);
> |
> | dev_err(dev, "Failed to map pinctrl regs: %d\n", err);
> |
> | return err;
> | }
> |
> | if (of_property_read_u32(np, "offset", &ns_pinctrl->offset)) {
> | dev_err(dev, "Failed to get register offset\n");
> | return -ENOENT;
> | }
>
> So, the ns_pinctrl_probe() takes the address of the parent node (cru)
> and then looks for a "offset" property to add to this (which is missing
> in the bcm5301x.dtsi [1]).
>
> Thing is, for this to work, the parent-node should be a "simple-mfd" (so
> a regmap is created for the reg), right? This would also mean that the
> "reg" property in the pin-controller node is just cosmetic.
>
> I guess the reason why this sort-of-works for me is because I'm using
> this MR32 with OpenWrt (Rafał Miłecki is probably using it too ;) ).
>
> (Note: We should not forget to update the binding-documentation as well!)
>
> BTW: I'll reply my findings for the i2c issue with the MR32 in the other
> mail.
Rafal, has this driver ever worked to begin with? None of this should be
necessary, we should just be using a simple platform device resource here.
--
Florian
On 8/19/2020 1:49 PM, Florian Fainelli wrote:
> On 8/19/20 1:48 PM, Christian Lamparter wrote:
>> On 2020-08-19 06:23, Florian Fainelli wrote:
>>> The pin controller resources start at 0xc0 from the CRU base which is at
>>> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
>>> are currently off by 0x100. The resource size of the CRU is also
>>> incorrect and should end at 0x248 bytes from 0x100 which is the start
>>> address. Finally, the compatibility strings defined for the
>>> pin-controller node should reflect the SoC being used.
>>>
>>> Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux
>>> controller")
>>> Reported-by: Christian Lamparter <[email protected]>
>>> Signed-off-by: Florian Fainelli <[email protected]>
>>> ---
>>> Christian, can you test this as a preliminary patch for your Cisco
>>> Meraki MR32 series? Thanks!
>>
>> Hm, it looks like this is more complicated than this. We should have
>> looked at pinctrl-ns.c's ns_pinctrl_probe() [0] before calling it.
>>
>> | ns_pinctrl->regmap = syscon_node_to_regmap(of_get_parent(np));
>> | if (IS_ERR(ns_pinctrl->regmap)) {
>> | int err = PTR_ERR(ns_pinctrl->regmap);
>> |
>> | dev_err(dev, "Failed to map pinctrl regs: %d\n", err);
>> |
>> | return err;
>> | }
>> |
>> | if (of_property_read_u32(np, "offset", &ns_pinctrl->offset)) {
>> | dev_err(dev, "Failed to get register offset\n");
>> | return -ENOENT;
>> | }
>>
>> So, the ns_pinctrl_probe() takes the address of the parent node (cru)
>> and then looks for a "offset" property to add to this (which is missing
>> in the bcm5301x.dtsi [1]).
>>
>> Thing is, for this to work, the parent-node should be a "simple-mfd" (so
>> a regmap is created for the reg), right? This would also mean that the
>> "reg" property in the pin-controller node is just cosmetic.
>>
>> I guess the reason why this sort-of-works for me is because I'm using
>> this MR32 with OpenWrt (Rafał Miłecki is probably using it too ;) ).
>>
>> (Note: We should not forget to update the binding-documentation as well!)
>>
>> BTW: I'll reply my findings for the i2c issue with the MR32 in the other
>> mail.
>
> Rafal, has this driver ever worked to begin with? None of this should be
> necessary, we should just be using a simple platform device resource here.
>
Florian, what if CDRU is a shared resource whose registers are accessed
and shared by multiple blocks (and therefore device drivers) within the
chip? Then accessing this shared CDRU resource through syscon makes sure
there's no race condition, isn't it?
On 8/19/20 2:14 PM, Ray Jui wrote:
>
>
> On 8/19/2020 1:49 PM, Florian Fainelli wrote:
>> On 8/19/20 1:48 PM, Christian Lamparter wrote:
>>> On 2020-08-19 06:23, Florian Fainelli wrote:
>>>> The pin controller resources start at 0xc0 from the CRU base which is at
>>>> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
>>>> are currently off by 0x100. The resource size of the CRU is also
>>>> incorrect and should end at 0x248 bytes from 0x100 which is the start
>>>> address. Finally, the compatibility strings defined for the
>>>> pin-controller node should reflect the SoC being used.
>>>>
>>>> Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux
>>>> controller")
>>>> Reported-by: Christian Lamparter <[email protected]>
>>>> Signed-off-by: Florian Fainelli <[email protected]>
>>>> ---
>>>> Christian, can you test this as a preliminary patch for your Cisco
>>>> Meraki MR32 series? Thanks!
>>>
>>> Hm, it looks like this is more complicated than this. We should have
>>> looked at pinctrl-ns.c's ns_pinctrl_probe() [0] before calling it.
>>>
>>> | ns_pinctrl->regmap = syscon_node_to_regmap(of_get_parent(np));
>>> | if (IS_ERR(ns_pinctrl->regmap)) {
>>> | int err = PTR_ERR(ns_pinctrl->regmap);
>>> |
>>> | dev_err(dev, "Failed to map pinctrl regs: %d\n", err);
>>> |
>>> | return err;
>>> | }
>>> |
>>> | if (of_property_read_u32(np, "offset", &ns_pinctrl->offset)) {
>>> | dev_err(dev, "Failed to get register offset\n");
>>> | return -ENOENT;
>>> | }
>>>
>>> So, the ns_pinctrl_probe() takes the address of the parent node (cru)
>>> and then looks for a "offset" property to add to this (which is missing
>>> in the bcm5301x.dtsi [1]).
>>>
>>> Thing is, for this to work, the parent-node should be a "simple-mfd" (so
>>> a regmap is created for the reg), right? This would also mean that the
>>> "reg" property in the pin-controller node is just cosmetic.
>>>
>>> I guess the reason why this sort-of-works for me is because I'm using
>>> this MR32 with OpenWrt (Rafał Miłecki is probably using it too ;) ).
>>>
>>> (Note: We should not forget to update the binding-documentation as well!)
>>>
>>> BTW: I'll reply my findings for the i2c issue with the MR32 in the other
>>> mail.
>>
>> Rafal, has this driver ever worked to begin with? None of this should be
>> necessary, we should just be using a simple platform device resource here.
>>
>
> Florian, what if CDRU is a shared resource whose registers are accessed
> and shared by multiple blocks (and therefore device drivers) within the
> chip? Then accessing this shared CDRU resource through syscon makes sure
> there's no race condition, isn't it?
In this particular case there is no register overlap, and the driver has
been written with a binding that does not match what we have in tree,
that would need fixing one way or the other.
In fact, the entire Device Tree tree should be re-organized such that
all relevant child nodes are in the CDRU (like PLL controls).
--
Florian
On 19.08.2020 06:23, Florian Fainelli wrote:
> The pin controller resources start at 0xc0 from the CRU base which is at
> 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we
> are currently off by 0x100. The resource size of the CRU is also
> incorrect and should end at 0x248 bytes from 0x100 which is the start
> address. Finally, the compatibility strings defined for the
> pin-controller node should reflect the SoC being used.
I can confirm 0x1800c1c0 is the correct absolute offset.
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index 2d9b4dd05830..bf49943f504a 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -402,14 +402,14 @@ dmu@1800c000 {
>
> cru@100 {
> compatible = "simple-bus";
> - reg = <0x100 0x1a4>;
> + reg = <0x100 0x248>;
> ranges;
> #address-cells = <1>;
> #size-cells = <1>;
>
> - pin-controller@1c0 {
> - compatible = "brcm,bcm4708-pinmux";
> - reg = <0x1c0 0x24>;
> + pinctrl: pin-controller@c0 {
> + compatible = "brcm,bcm53012-pinmux";
> + reg = <0xc0 0x24>;
> reg-names = "cru_gpio_control";
>
> spi-pins {
>
That whole binding has a bit messy story.
Initially it used to be binding like:
compatible = "brcm,bcm4708-pinmux";
reg = <0x1800c1c0 0x24>;
reg-names = "cru_gpio_control";
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c12fb1774deaa9c9408b19db8d43d3612f6e47a0
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f9f82b3ffb8bfe01988c890e3a24328e9e1c1df
Later example binding was rewritten to include dmu and cru (simplified
below):
dmu@1800c000 {
compatible = "simple-bus";
ranges = <0 0x1800c000 0x1000>;
cru@100 {
compatible = "simple-bus";
reg = <0x100 0x1a4>;
ranges;
pin-controller@1c0 {
compatible = "brcm,bcm4708-pinmux";
reg = <0x1c0 0x24>;
reg-names = "cru_gpio_control";
};
};
};
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93d39737b29eaf1974bf850ccdc903b2418c800b
I don't understand or remember why pin-controller reg was relative to
dmu instead of cru. Some DT offset calculation magic?
Finally I updated binding to use "offset", see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ae80900f239484069569380e1fc4340fd6e0089
and then updated driver to follow:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a49d784d5a8272d0f63c448fe8dc69e589db006e
but I never updated DTS file accordingly.
To OpenWrt I pushed relevant kernel patch in the commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a28f6ab27f9ae1a08c6945013cdb796b12ce150d
(called [PATCH] ARM: dts: BCM5301X: Update Northstar pinctrl binding)
but I never sent it upstream.
Florian: your change doesn't match docs or existing Linux driver:
1. Driver seems to ignore "reg"
2. Driver requires "offset"
3. Property "cru_gpio_control" is leftover (undocumented and unused)
I think we need to take a step back and cleanup Northstar bindings. Few
months ago I sent e-mail:
Subject: Proper DT bindings for Broadcom's DMU node
Message-ID: <[email protected]>
I didn't get any reply from Rob who previously pointed out that
compatible = "syscon", "simple-mfd";
is not a valid compatibility.
I suggest we hold on on DTS update for a moment and switch back to my
question from March on designing proper bindings.