Le Fri, 15 Apr 2022 16:16:46 +0200, Andrew Lunn <andrew@xxxxxxx> a écrit : > On Fri, Apr 15, 2022 at 10:24:53AM +0200, Clément Léger wrote: > > Le Fri, 15 Apr 2022 01:22:01 +0200, > > Andrew Lunn <andrew@xxxxxxx> a écrit : > > > > > On Thu, Apr 14, 2022 at 02:22:47PM +0200, Clément Léger wrote: > > > > Add the MII converter node which describes the MII converter that is > > > > present on the RZ/N1 SoC. > > > > > > Do you have a board which actually uses this? I just noticed that > > > renesas,miic-cfg-mode is missing, it is a required property, but maybe > > > the board .dts file provides it? > > > > > > Andrew > > > > Hi Andrew, yes, I have a board that defines and use that. > > Great. Do you plan to mainline it? It is always nice to see a user. Although we are working on a specific customer board, we will probably try to mailine this support for the RZ/N1D-DB. > > > The > > renesas,miic-cfg-mode actually configures the muxes that are present on > > the SoC. They allows to mux the various ethernet components (Sercos > > Controller, HSR Controller, Ethercat, GMAC1, RTOS-GMAC). > > All these muxes are actually controller by a single register > > CONVCTRL_MODE. You can actually see the muxes that are present in the > > manual [1] at Section 8 and the CONVCTRL_MODE possible values are listed > > on page 180. > > > > This seems to be something that is board dependent because the muxing > > controls the MII converter outputs which depends on the board layout. > > Does it also mux the MDIO lines as well? Nope, the MDIO lines are muxed using the pinctrl driver. > > We might want to consider the name 'mux'. Linux already has the > concept of a mux, e.g. an MDIO mux, and i2c mux etc. These muxes have > one master device, which with the aid of the mux you can connect to > multiple busses. And at runtime you flip the mux as needed to access > the devices on the multiple slave busses. For MDIO you typically see > this when you have multiple Ethernet switch, each has its own slave > MDIO bus, and you use the mux to connect the single SOC MDIO bus > master to the various slave busses as needed to perform a bus > transaction. I2C is similar, you can have multiple SFPs, either with > there own IC2 bus, connected via a mux to a single I2C bus controller > on the SoC. > > I've not looked at the data sheet yet, but it sounds like it operates > in a different way, so we might want to avoid 'mux'. Indeed, Let's not refer to it as mux in the code at all. If using your proposal below, I guess we could avoid that. > > > I'm open to any modification for this setup which does not really fit > > any abstraction that I may have seen. > > > > [1] > > https://www.renesas.com/us/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-system-introduction-multiplexing-electrical-and > > O.K, looking at figure 8.1. > > What the user wants to express is something like: > > Connect MI_CONV5 to SECOS PORTA > Connect MI_CONV4 to ETHCAT PORTB > Connect MI_CONV3 to SWITCH PORTC > Connect MI_CONV2 to SWITCH PORTD > > plus maybe > > Connect SWITCH PORTIN to RTOS Yes, that is correct. > > So i guess i would express the DT bindings like this, 5 values, and > let the driver then try to figure out the value you need to put in the > register, or return -EINVAL. For DT bindings we try to avoid magic > values which get written into registers. We prefer a higher level > description, and then let the driver figure out how to actually > implement that. Ok, looks like a more flexible way to doing it. Let's go with something like this: renesas,miic-port-connection = <PORTIN_GMAC2>, <MAC2>, <SWITCH_PORTC>, <SWITCH_PORTB>, <SWITCH_PORTA>; -- Clément Léger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com
