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