Message-ID: <20231024130832.13596-1-ante.knezic@helmholz.de>
Date:   Tue, 24 Oct 2023 15:08:32 +0200
From:   Ante Knezic <ante.knezic@...mholz.de>
To:     <o.rempel@...gutronix.de>
CC:     <UNGLinuxDriver@...rochip.com>, <andrew@...n.ch>,
        <ante.knezic@...mholz.de>, <conor+dt@...nel.org>,
        <davem@...emloft.net>, <devicetree@...r.kernel.org>,
        <edumazet@...gle.com>, <f.fainelli@...il.com>,
        <krzysztof.kozlowski+dt@...aro.org>, <kuba@...nel.org>,
        <linux-kernel@...r.kernel.org>, <marex@...x.de>,
        <netdev@...r.kernel.org>, <olteanv@...il.com>, <pabeni@...hat.com>,
        <robh+dt@...nel.org>, <woojung.huh@...rochip.com>
Subject: Re: [PATCH net-next v4 2/2] net:dsa:microchip: add property to select

On Tue, 24 Oct 2023 12:09:15 +0200, Oleksij Rampel wrote:

> > As you suggested, it looks like KSZ9897 clocking mode depends on RMII interface
> > mode (with strapping pins), but I don't see this for KSZ8863. The PHY/MAC mode
> > is selected with Register 0x35 bit 7 and the clocking mode is selected via
> > strapping pins EN_REFCLKO and SMTXD32 (and additional register 0xC6 bit 3).
> > I guess its possible for the KSZ8863 to be the clock provider/consumer
> > regardless of PHY/MAC mode?
>
>Register 0x35 bit 7 is for MII mode
>Register 0xC6 bit 3 is for RMII mode
>
>MII != RMII

Yes, right you are. Looks like I got lost in the datasheets...

> > Table 3-5: RMII CLOCK SETTING of KSZ8863 datasheet describes the available
> > clocking modes. If we try to create a relation between KSZ9897 and KSZ8863:
> >
> > KSZ9897 "Normal Mode" is equivalent to KSZ8863 mode described in first column
> > of table 3-5:
> > - EN_REFCLKO = 0, 0xC6(3) = 0 -> external 50Mhz OSC input to REFCLKI and X1
> >   pin directly
> >
> > KSZ9897 "Clock Mode" is equivalent to KSZ8863 mode described in fourth/fifth
> > column (difference is only clock frequency) of table 3-5:
> > - EN_REFCLKO = 1, 0xC6(3) = 1 -> 50/25Mhz on X1 pin, 50/25Mhz RMII clock goes
> >   to REFCLKI internally. REFCLKI can be pulled down by resistor.
> >
> > That leaves us with additional columns 2 and 3 of table 3-5 for KSZ8863, that
> > are similar to KSZ9897 Clock mode, but REFCLKI needs to be fed externally from
> > REFCLKO.
> 
> All of 5 variants described in "Table 3-5: RMII CLOCK SETTING of KSZ8863"
> can be boiled down to two main configurations:
> 
> REFCLKI is used as clock source for internal MAC == Normal Mode or
> RevRMII mode.
> REFCLKI is not used as clock source for internal MAC == Clock Mode or
> RMII mode.
> 
> Variants 1, 2, 3 describe only how can we feed REFCLKI from outside of
> the chip. Even variant 2 and 3 make the switch to be an actually
> physical clock provider, we still need to use REFCLKI and wire it
> outside of the chip which make it practically a Normal Mode or RevRMII mode.

That is correct, I guess its a matter of nomenclature, but how do you 
"tell" the switch whether it has REFCLKI routed externally or not if not by 
setting the 0xC6 bit 3? Is there another way to achieve this?

> > > I already did some work to configure CPU interface, where which can be at least
> > > partially reused for your work:
> > > https://lore.kernel.org/all/20230517121034.3801640-2-o.rempel@pengutronix.de/
> > > (Looks I forgot to complete mainlining for this patch)
> > >
> > > If implanted as described, no new devicetree properties will be needed.
> >
> > I don't quite get how the proposed patch might effect this topic?
> 
> You will need to add ksz8_phylink_mac_link_up() as this patch already
> dose.
> 
> > By setting PHY/MAC mode? As noted, I dont see the same relation between clock and
> > MII mode for KSZ8863 as for KSZ9897?
> 
> I hope current mail will clear it.

I tried your patch but it does not do it for me. As stated, my hw platform does
not have REFCLKI routed externally so a state at column 4/5 is expected.

Powered by blists - more mailing lists