Re: [PATCH v4 2/2] arm: dts: ti: Adds support for AM335x and AM437x

[Parvathi Pudi <parvathi@couthit.com>]

Hi,

>> On the AM335x board, the CPSW MDIO and PRUSS MDIO signals are routed to the same
>> physical
>> pins (as shown in the schematic, see page 10 “MII_MUX” in
>> tmdxice3359_sch_3h0013_v2_1a.pdf
>> from https://www.ti.com/lit/zip/TIDR336 ). Because of this shared routing, the
>> pinmux
>> configuration applied by U-Boot for CPSW MDIO remains active even if the CPSW
>> MDIO node is
>> later disabled in Linux, and Linux does not automatically revert the pins to
>> their reset state.
> 
> It is generally a bad idea to rely on the bootloader. I would make the
> CPSW MDIO configure the pins how it needs it. The PRUSS MDIO should
> also configure the pins how it needs them. However, it is not as
> simple as that...
> 

On AM335x, the MDIO interface is selected by a hardware jumper before the
bootloader runs. The selection is latched in hardware, so only one MDIO
controller (CPSW or PRUSS) is active at a time.

Since the hardware choice is fixed prior to Linux boot, we decided to ensure
in U-Boot that the pins are configured according to the selected hardware latch.
Linux still configures the active MDIO controller as required via its DT and
pinctrl settings. The U‑Boot change ensures a clean initial state that matches
the hardware latched configuration, and we have this prepared as a patch that
will be submitted to mainline U‑Boot shortly.

> Looking at the schematic, what you have is ugly. You literally wire
> the outputs together, without a hardware mux. For MDC you assume one
> is Hi-Z, while the other drives the line. For MDIO it does not matter,
> both are inputs. so Hi-Z.
> 

Although the schematic shows the signals tied together without an explicit mux,
the hardware jumper selects RMII (CPSW) or MII (PRUSS) before boot. Only the
selected block is enabled, and the other remains inactive, so the lines are never
driven concurrently.

> I actually think you might need to represent this in Linux, with
> something i would call a pinmux-mux. You give it two sets of pinmux
> configurations. The active device claims the mux and gets it to set
> the two sets of pinmux as needed. Also, just setting the pinmux to
> GPIO is not sufficient, you also need to ensure the GPIO is configured
> for input, so the lines go Hi-Z. Often pinmux and GPIO controllers are
> interconnected, so the pinmux subsystem might be able to do that for
> you.
> 
> I don't know if a pinmux-mux already exists in Linux. You probably
> want to ask on the pinmux mailing list, or they might have a different
> idea how to cleanly do this.
> 
>	Andrew

In this case, the selection is static and determined by hardware via a jumper,
not switchable at runtime. Linux reflects this by choosing the Device Tree
configuration corresponding to the latched jumper, it enables the selected
MDIO controller and sets up its pinmux, while the other MDIO controller
remains disabled.

We will update the patches by removing the CPSW pin reset configuration in
ICSS context and post the next version shortly.

Thanks and Regards,
Parvathi