Message-ID: <f8885497540ce850c67d4bd17d66bc9f7c3b90fd.camel@bootlin.com>
Date:   Tue, 19 Feb 2019 13:53:18 +0100
From:   Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
        Mylène Josserand 
        <mylene.josserand@...tlin.com>
Subject: Re: Handling an Extra Signal at PHY Reset

Hi,

On Tue, 2019-02-19 at 10:36 +0100, Thomas Petazzoni wrote:
> Hello Paul,
> 
> On Tue, 19 Feb 2019 10:14:20 +0100
> Paul Kocialkowski <paul.kocialkowski@...tlin.com> wrote:
> 
> > We are dealing with an Ethernet PHY (Marvell 88E1512) that comes with a
> > CONFIG pin that must be connected to one of the other pins of the PHY
> > to configure the LSB of the PHY address as well as I/O voltages (see
> > section 2.18.1 Hardware Configuration of the datasheet). It must be
> > connected "soon after reset" for the PHY to be correctly configured.
> > 
> > We have a switch for connecting the CONFIG pin to the other pin (LED0),
> > which needs to be controlled by Linux. The CONFIG pin seems to be used
> > for a PTP clock the rest of the time.
> > 
> > So we are wondering how to properly represent this case, especially on
> > the device-tree side.
> > 
> > The trick here is that this step is necessary before the PHY can be
> > discovered on the MDIO bus (and thus the PHY driver selected) so we
> > can't rely on the PHY driver to do this. Basically, it looks like we
> > need to handle this like the reset pin and describe it at the MDIO bus
> > level.
> > 
> > Here are some ideas for potential solutions:
> > - Allowing more than a single GPIO to be passed to the MDIO bus' reset-
> > gpios via device-tree and toggling all the passed GPIOs at once;
> > 
> > - Adding a new optional GPIO for the MDIO bus dedicated to controlling 
> > switches for such config switching, perhaps called "config-gpios"
> > (quite a narrow solution);
> > 
> > - Adding a broader power sequence description to the MDIO bus (a bit
> > like it's done with the mmc pwrseq descriptions) which would allow
> > specifying the toggle order/delays of various GPIOs (would probably be
> > the most extensive solution);
> > 
> > - Adding the extra GPIO control to the MAC description and toggling it
> > through bus->reset (probably the less invasive solution for the core
> > but not very satisfying from the description perspective, since this is
> > definitely not MAC-specific).
> > 
> > What do you think about how we could solve this issue?
> > Do you see other options that I missed here?
> 
> I think it's important to mention the sequence that is needed:
> 
>  1. assert reset
>  2. wait 10 us
>  3. switch config signal
>  4. deassert reset
>  5. wait 100us
>  6. de-switch config signal
> 
> I.e, the config signal needs to be switched properly before deasserting
> reset, and then switched back to its original state so that the config
> pin can be used for its normal (non-reset) purpose.
> 
> So the manipulation of the config signal is intertwined with the
> assert/de-assert of the reset. So I don't see how your fourth option
> would work for example. Am I missing something here ?

So we discussed and checked this with Thomas and the sequence that he
mentionned is indeed the right way to go.

However, we also found that our board circuitry switches the signal
when the GPIO is not driven low. So assuming that it's either high-Z or
high when the kernel boots, we can manage with the final step (de-
switch config signal) alone (although it's safer to ensure this is the
case before reset).

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Powered by blists - more mailing lists