Messages in this thread | | | Date | Thu, 24 Mar 2022 14:48:24 +0100 | From | Oleksij Rempel <> | Subject | Re: sja1105q: proper way to solve PHY clk dependecy |
| |
Hello Vladimir,
thank you for your response!
On Wed, Mar 23, 2022 at 11:52:40AM +0200, Vladimir Oltean wrote: > Hello Oleksij, > > On Wed, Mar 23, 2022 at 07:03:31AM +0100, Oleksij Rempel wrote: > > Hi Vladimir, > > > > I have SJA1105Q based switch with 3 T1L PHYs connected over RMII > > interface. The clk input "XI" of PHYs is connected to "MII0_TX_CLK/REF_CLK/TXC" > > pins of the switch. Since this PHYs can't be configured reliably over MDIO > > interface without running clk on XI input, i have a dependency dilemma: > > i can't probe MDIO bus, without enabling DSA ports. > > > > If I see it correctly, following steps should be done: > > - register MDIO bus without scanning for PHYs > > - define SJA1105Q switch as clock provider and PHYs as clk consumer > > - detect and attach PHYs on port enable if clks can't be controlled > > without enabling the port. > > - HW reset line of the PHYs should be asserted if we disable port and > > deasserted with proper reinit after port is enabled. > > > > Other way would be to init and enable switch ports and PHYs by a bootloader and > > keep it enabled. > > > > What is the proper way to go?
> The facts, as I see them, are as follows, feel free to debate them. > > 1. Scanning the bus is not the problem, but PHY probing is. > > If the MDIO bus is registered with of_mdiobus_register() - which is to > be expected, since the sja1105 driver only connects to a PHY using a > phy-handle - that should set mdio->phy_mask = ~0; which should disable > PHY scanning. > > But of_mdiobus_register() will still call of_mdiobus_register_phy() > which will probe the phy_device. Here, depending on the code path, > _some_ PHY reads might be performed - which will return an error if the > PHY is missing its clock. For example, if the PHY ID isn't part of the > compatible string, fwnode_mdiobus_register_phy() will attempt to read it > from the PHY via get_phy_device(). Alternatively, you could put the PHY > ID in the DT and this will end up calling phy_device_create(). > > Then there's the probe() method of the T1L PHY driver, which is the > reason why it would be good to know what that driver is. Since its clock > might not be available, I expect that this driver doesn't access > hardware from probe(), knowing that it is an RMII PHY driver and this is > a generic problem for RMII PHYs.
ack. describing DT with compatible PHYid seems to be good enough.
> 2. The sja1105 driver already does all it reasonably can to make the > RMII PHY happy. > > The clocks of a port are enabled/configured from sja1105_clocking_setup_port() > which has 3 call paths: > (a) during sja1105_setup(), aka during switch initialization, all ports > except RGMII ports have their clocks configured and enabled, via > priv->info->clocking_setup(). The RGMII ports have a clock that > depends upon the link speed, and we don't know the link speed. > (b) during sja1105_static_config_reload(). The sja1105 switch needs to > dynamically reset itself at runtime, and this cuts off the clocks > for a while. Again there is a call to priv->info->clocking_setup() > here. > (c) during phylink_mac_link_up -> sja1105_adjust_port_config(), a call > is made to sja1105_clocking_setup_port() for RGMII PHYs, because the > speed is now known. > > Since DSA calls dsa_slave_phy_setup() _after_ dsa_switch_setup(), this > means that by the time the PHY is attached, its config_init() runs, etc, > the RMII clock configured by sja1105_setup() should be running.
ack. it works.
> 3. Clock gating the PHY won't make it lose its settings. > > I expect that during the time when the sja1105 switch needs to reset, > the PHY just sees this as a few hundreds of ms during which there are no > clock edges on the crystal input pin. Sure, the PHY won't do anything > during that time, but this is quite different from a reset, is it not? > So asserting the hardware reset line of the PHY during the momentary > loss of clock, which is what you seem to suggest, will actively do more > harm than good.
can i be sure that MDIO access happens in the period where PHY is supplied with stable clk
> 4. Making the sja1105 driver a clock provider doesn't solve the problem > in the general sense. > > If you make this PHY driver expect the MAC to be a clock provider, > are you going to expect that all RMII-capable MAC drivers be patched? > For this reason I am in principle opposed to making the sja1105 driver > a clock provider, you won't be able to generalize this solution and it > would just create a huge mess going forward.
I can imagine optional clk support, but right now i do not have any stability issues so no need to spend time on it right now.
Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
| |