[PATCH v1 6/6] ARM: BCM5301X: Add DT for Meraki MR32
Florian Fainelli
f.fainelli at gmail.com
Tue Aug 18 23:34:57 EDT 2020
On 8/18/2020 7:46 PM, Christian Lamparter wrote:
> On 2020-08-19 02:07, Ray Jui wrote:
>>
>>
>> On 8/18/2020 3:52 PM, Christian Lamparter wrote:
>>> Hello Florian,
>>>
>>> On 2020-08-18 22:11, Florian Fainelli wrote:
>>>>
>>>>
>>>> On 8/18/2020 9:39 AM, Christian Lamparter wrote:
>>>> [snip]
>>>>> + i2c-gpio {
>>>>> + compatible = "i2c-gpio";
>>>>> + sda-gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
>>>>> + scl-gpios = <&chipcommon 4 GPIO_ACTIVE_HIGH>;
>>>>> + i2c-gpio,delay-us = <10>; /* close to 100 kHz */
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>
>>>> Can you try using the hardware controller here instead of bit banging
>>>> i2c over gpios? GPIOs 4 and 5 are the default pins for I2C.
>>>
>>> Ok. I gave this a try. What I did was:
>>>
>>> I removed the i2c-gpio node and went with this in the mr32.dts:
>>>
>>> +&i2c0 {
>>> + status = "okay";
>>> +
>>> + clock-frequency = <100000>; /* also tried 400KHz */
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinmux_i2c>; /* editted bcm5301x.dtsi for this */
>>> +
>>> + cur_mon: ina2xx at 45 {
>>> + compatible = "ti,ina219";
>>> + reg = <0x45>;
>>> + shunt-resistor = <60000>; /* = 60 mOhms */
>>> + };
>>> +
>>> + meraki_eeprom: at24 at 50 {
>>> + compatible = "atmel,24c64";
>>> + reg = <0x50>;
>>> + pagesize = <32>;
>>> + read-only;
>>> + };
>>> +};
>>>
>>> I enabled CONFIG_I2C_BCM_IPROC=y and built the whole thing and moved it
>>> to the AP.
>>>
>>> During boot, I now get:
>>>
>>> |[ 1.039174] bcm-iproc-i2c 18009000.i2c: bus set to 100000 Hz
>>> |[ 8.918419] i2c /dev entries driver
>>> [...] (The i2c-bcm-iproc now causes a long "wait" during boot)
>>> |[ 59.385497] bcm-iproc-i2c 18009000.i2c: transaction timed out
>>> |[ 59.391272] ina2xx 0-0045: error configuring the device: -110
>>> |[ 110.585517] bcm-iproc-i2c 18009000.i2c: transaction timed out
>>>
>>
>> The long wait is probably caused by waiting for the I2C transaction to
>> time out, which it eventually did.
>
> Yes.
>
> >
>>
>>> Is there a special magic needed to get this working with bcm5301x's
>>> existing i2c0 node?
>>>
>>
>> Two things to check: 1) if pinmux is configured properly;
> Hm, any tips for testing this? The /sys/kernel/debug/pinctrl is
> populated correctly from what I can tell.
>
> What I don't know is if the DTS in bcm5301x.dtsi.
>
> | dmu at 1800c000 {
> | compatible = "simple-bus";
> | ranges = <0 0x1800c000 0x1000>;
> | #address-cells = <1>;
> | #size-cells = <1>;
> |
> | cru at 100 {
> | compatible = "simple-bus";
> | reg = <0x100 0x1a4>;
> | ranges;
> | #address-cells = <1>;
> | #size-cells = <1>;
> |
> | pin-controller at 1c0 {
> | compatible = "brcm,bcm4708-pinmux";
> | reg = <0x1c0 0x24>;
>
> Based on my understanding of the DT, the pinctrl register should be at
> 0x1800c2c0 (that would be outside of the 0x1a4 size though?!). This is
> because of 0x1800c000 (dmu base) + 0x100 (cru reg) + 0x1c0
> (pin-controller reg). If so, here are devmem's output of said region
> (read value is after the "=")
There is a translation problem here, we are off by 0x100 (need to check
the bcm4708 data sheet though quite positive it applies there, too), the
following would be more correct:
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
b/arch/arm/boot/dts/bcm5301x.dtsi
index 2d9b4dd05830..d73e5151ce51 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -407,9 +407,9 @@
#address-cells = <1>;
#size-cells = <1>;
- pin-controller at 1c0 {
- compatible = "brcm,bcm4708-pinmux";
- reg = <0x1c0 0x24>;
+ pin-controller at c0 {
+ compatible = "brcm,bcm53012-pinmux";
+ reg = <0xc0 0x24>;
reg-names = "cru_gpio_control";
spi-pins {
>
> devmem 0x1800c2c0 = 0x0
> devmem 0x1800c2c4 = 0x001D2003
> devmem 0x1800c2c8 = 0x00000284
> devmem 0x1800c2cc = 0x00000284
> devmem 0x1800c2d0 = 0x00000285
> devmem 0x1800c2d4 = 0x00000284
> devmem 0x1800c2d8 = 0x00000284
> devmem 0x1800c2dc = 0x00000284
> devmem 0x1800c2e0 = 0x00000284
> devmem 0x1800c2e4 = 0x00000284
>
> Just in case, I've also checked 0x1800c1c0.
> This is because I stumbled over the "Example" in the binding
> Documentation under
> Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt.
> Because this uses a "offset = <0xc0>"
> property and seems to be based of the cru at 100 node?!
>
> devmem 0x1800c1c0 = 0x00140037
So here we can see that bits 4 and 5 are set to 1, which means that they
are still configured as GPIOs, and not as pins for the desired functions
which explains the timeout.
--
Florian
More information about the linux-arm-kernel
mailing list