> On Thu, Jul 04, 2019 at 10:54:47AM +0200, Benjamin Beckmeyer wrote:
>> On 03.07.19 17:55, Andrew Lunn wrote:
>>> On Wed, Jul 03, 2019 at 03:10:34PM +0200, Benjamin Beckmeyer wrote:
>>>> Hey folks,
>>>>
>>>> I'm having a problem with a custom i.mx6ul board. When DSA is loaded I
>>>> can't
>>>> get access to the switch via MDIO, but the DSA is working properly. I set
>>>> up
>>>> a bridge for testing and the switch is in forwarding mode and i can ping
>>>> the
>>>> board. But the MDIO access isn't working at address 2 for the switch. When
>>>> I
>>>> delete the DSA from the devicetree and start the board up, I can access
>>>> the
>>>> switch via MDIO.
>>>>
>>>> With DSA up and running:
>>>>
>>>> mii -i 2 0 0x9800
>>>> mii -i 2 1
>>>> phyid:2, reg:0x01 -> 0x4000
>>>> mii -i 2 0 0x9803
>>>> mii -i 2 1
>>>> phyid:2, reg:0x01 -> 0x4000
>>>> mii -i 2 1 0x1883
>>>> mii -i 2 1
>>>> phyid:2, reg:0x01 -> 0x4000
>>> Hi Benjamin
>>>
>>> I'm guessing that the driver is also using register 0 and 1 at the
>>> same time you are, e.g. to poll the PHYs for link status etc.
>>>
>>> There are trace points for MDIO, so you can get the kernel to log all
>>> registers access. That should confirm if i'm right.
>>>
>>> Andrew
>> Hi Andrew,
>> you were absolutly right. The bus is really busy the whole time, I've
>> checked that with the tracepoints in mdio_access.
>>
>> But I'm still wondering why isn't that with a single chip addressing
>> mode configured switch? I mean, okay, the switch has more ports, but
>> I've checked the accesses for both. The 6321(single chip addressing
>> mode) has around 4-5 accesses to the MDIO bus and the 6390(multi chip
>> addressing mode) has around 600 accesses per second.
> Hi Benjamin
>
> In single chip mode, reading a register is atomic. With multi-chip,
> you need to access two registers, so it clearly is not atomic. And so
> any other action on the bus will cause you problems when doing things
> from user space without being able to take the register mutex.
>
> But 4-5 vs 600 suggests you don't have the interrupt line in your
> device tree. If you have the interrupt line connected to a GPIO, and
> the driver knows about it, it has no need to poll the PHYs. I also
> added support for 'polled interrupts', as a fall back when then
> interrupt is not listed in device tree. 10 times a second the driver
> polls the interrupt status register, and if any interrupts have
> happened within the switch, it triggers the needed handlers. Reading
> one status register every 100ms is much less effort than reading all
> the PHY status registers once per second.
>
> Still, 600 per second sounds too high. Do you have an SNMP agent
> getting statistics?
>
> Andrew
Hi Andrew,
thanks for the hint with the interrupt line. I added it now but I'm
having the same problem. But it is older kernel and tomorrow I will try
a newer kernel in which your patch with the polled setup is applied to.
And I will get an oscilloscop to look if anything is happening on the
interrupt line.
Is this device tree snip correct (about interrupts)?
--snip
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
phy-supply = <®_3v3>;
phy-mode = "rmii";
phy-handle = <&fecphy1>;
status = "okay";
mdio0: mdio {
#address-cells = <1>;
#size-cells = <0>;
fecphy1: fecphy1@1 {
reg = <0x1>;
};
};
};
&mdio0 {
interrupt-parent = <&gpio1>;
interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
switch0: switch0@2 {
compatible = "marvell,mv88e6190";
reg = <2>;
pinctrl-0 = <&pinctrl_gpios>;
reset-gpios = <&gpio4 16 GPIO_ACTIVE_LOW>;
dsa,member = <0 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&fec1>;
phy-mode = "rmii";
fixed-link {
speed = <100>;
full-duplex;
};
};
--snip
There is no SNMP agent running at all.
Cheers,
Benjamin
