Russell, 2018-01-03 18:54 GMT+01:00 Russell King - ARM Linux <li...@armlinux.org.uk>: > On Wed, Jan 03, 2018 at 05:00:47PM +0000, Stefan Chulski wrote: >> > > > -----Original Message----- >> > > > Hi Russell, >> > > > >> > > > Indeed. RGMII MAC behaves same way, although it shouldn't be named >> > > > as 'in- band' to be on par with the specifications. Anyway - this >> > > > one is rather a stub for being able to work with ACPI, so once the >> > > > MDIO bus works there, this will be out of any concerns. >> > > >> > > Hi Marcin, >> > > >> > > This is correct. >> > > "in-band" supported only for SGMII mode. >> > > IRQ link interrupt depend on "in-band"' auto negation only if "in-band"' >> > enabled. >> > > But IRQ link interrupt could be triggered with "in-band", "out-band" or >> > > with >> > specific fixed speed/duplex/flow_contol. >> > >> > Hi Stefan, >> > >> > How does this work in RGMII mode - is this handled by the PP2 polling the >> > PHY >> > to get the speed, duplex and flow control settings? >> > >> >> IRQ interrupt doesn't handled speed, duplex and flow control settings. >> It's just raised if number of criterions met: >> 1) Physical signal detected by MAC >> 2) MAC auto negotiation succeeded(valid only auto negotiation enabled in MAC >> and "in-band" bypass disabled) >> >> So if auto negotiation mechanism disabled in MAC or bypassed, link status >> would changes to up and IRQ interrupt be triggered. >> >> In case of RGMII mode obviously we don't have "in-band" auto negotiation and >> "out-band" cannot be used in Kernel(due to missed locks). >> So auto negotiation should be disabled on MAC level and >> speed/duplex/flow_contol would be negotiate by PHY. >> phylink/phylib infrastructure should provide speed/duplex/flow_contol(that >> were agreed between PHY's) to ppv2 driver. > > Sorry, I find this very confusing. > > It seems we have some people telling me that when there's no PHY > described in DT, we use this link interrupt, and have a functional > network interface (presumably at whatever speed.) > > I can't see this working from what you describe - what you describe > basically tells me that when in-band autonegotiation is disabled, and we > have no PHY in the kernel, then effectively we are in fixed-link mode - > since we need to know what speed, duplex and flow control settings to > use. > > So, this means that mvpp2 should be enforcing the presence of a > fixed-link description in DT if there is no PHY node at the moment, but > it doesn't. > > Instead, it looks to me like the speed and duplex settings are inherited > from the boot loader or whatever was running before - I can't find > anything that configures MVPP2_GMAC_AUTONEG_CONFIG in this case. That > seems quite a mess.
Just 3 cents from me about the RGMII + link IRQ, which is only a temporary solution for ACPI. It works basing on the results of UEFI HW PHY polling and inherited GMAC settings. Once this MDIO bus / PHY handling lands, this configuration will be out of any question and usage in the pp2 driver. Marcin > > Maybe I'm missing something, but I don't see how mvpp2 can be converted > to phylink given this without causing some kind of regression, unless > someone can be much clearer about exactly what kinds of link mvpp2 > supports and how they work (which is basically what I asked back in > October.) > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up
