Handling an Extra Signal at PHY Reset

Handling an Extra Signal at PHY Reset

[Paul Kocialkowski]

Hi,

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?

Cheers and thanks in advance,

Paul

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

Re: Handling an Extra Signal at PHY Reset

[Thomas Petazzoni]

Hello Paul,

On Tue, 19 Feb 2019 10:14:20 +0100
Paul Kocialkowski <paul.kocialkowski@bootlin.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 ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Handling an Extra Signal at PHY Reset

[Paul Kocialkowski]

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@bootlin.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

Re: Handling an Extra Signal at PHY Reset

[Andrew Lunn]

On Tue, Feb 19, 2019 at 10:14:20AM +0100, Paul Kocialkowski wrote:
> Hi,
> 
> 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.
 
Hi Paul

I assume there are two PHYs on the MDIO bus, and you need to ensure
they have different addresses? Do we have an Ethernet switch involved
here, or are they two SoC Ethernet networks with one shared MDIO bus?

This seems like an odd design. I've normally seen weak pull up/down
resistors, not a switch, so i'm wondering why it is designed like
this.

   Thanks
	Andrew

Re: Handling an Extra Signal at PHY Reset

[Paul Kocialkowski]

Hi Andrew,

On Tue, 2019-02-19 at 14:36 +0100, Andrew Lunn wrote:
> On Tue, Feb 19, 2019 at 10:14:20AM +0100, Paul Kocialkowski wrote:
> > Hi,
> > 
> > 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.
>  
> Hi Paul
> 
> I assume there are two PHYs on the MDIO bus, and you need to ensure
> they have different addresses? Do we have an Ethernet switch involved
> here, or are they two SoC Ethernet networks with one shared MDIO bus?

Thanks for your answer!

I think the reason why we need to deal with the CONFIG pin is more
about setting the correct I/O voltage than the PHY address (it just
happens that the CONFIG pin configures both at once).

With our setup, we only have a single PHY and no fancy eth switch setup
(although there is a GMII2RGMII converter that is controlled through
the MDIO bus, but there is no risk of address conflict).

> This seems like an odd design. I've normally seen weak pull up/down
> resistors, not a switch, so i'm wondering why it is designed like
> this.

Yes, that's definitely unusual and pretty specific to the PHY. I would
also have expected pull resistors but the way it's done is to connect
one pin to another at reset and disconnect them later on so that both
can be used for the intended function (PTP clock and LED).

I hope this clarifies our situation a bit.

Cheers,

Paul

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

Re: Handling an Extra Signal at PHY Reset

[Andrew Lunn]

> I think the reason why we need to deal with the CONFIG pin is more
> about setting the correct I/O voltage than the PHY address (it just
> happens that the CONFIG pin configures both at once).

Hi Paul

I don't have the datasheet...

What I/O voltages are we talking about? Is the device addressable over
the MDIO bus without this configuration? Can the voltages be
configured via register writes during probe? I assume not, or you
would be doing that...

      Andrew

Re: Handling an Extra Signal at PHY Reset

[Florian Fainelli]

On February 19, 2019 1:14:20 AM PST, Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote:
>Hi,
>
>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.

Even voltage? What guarantees do you have that you are not reducing the lifetime of your pads if e.g.: you are configured for 3.3V while the other end is 1.8/2.5V? Is there some kind of embedded voltage comparator that can be used to help making the right decision?


>
>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;

That would be a mis-representstion of the HW though, since the reset line is tied to the PHY package. Making use of the current implementation details to put a second reset line does not sound great.

>
>- 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);

Indeed, and still has the same design flaw as 1) outline above.

>
>- 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);

That one looks the most compelling and future proof although I do wonder how many people would make use of that.

>
>- 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?

You could explore having the MDIO bus layer scan its children nodes (PHY nodes) and handle properties in there before registering devices, so for insurance your PHY DT nodes can have an arbitrary number of reset lines, power sequencing properties etc. and the MDIO bus layer knowing it's internal implementation does make sure that it makes use of these properties in order to make PHY devices functional.

Does that make sense? One possible caveat is that the CONFIG pin also dictates the address on the bus, so what do we do with the PHY's "reg" property, is it it's actual address or is it the desired one that we should configure through reset?
-- 
Florian

Re: Handling an Extra Signal at PHY Reset

[Thomas Petazzoni]

On Tue, 19 Feb 2019 14:36:29 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

> This seems like an odd design. I've normally seen weak pull up/down
> resistors, not a switch, so i'm wondering why it is designed like
> this.

The key point here is that this "CONFIG" pin of the PHY is used during
reset to configure the PHY, but then once the reset sequence is
finished, this pin is used for PTP. From the datasheet, section 2.28.1
"PTP Control":

"""
To support the PTP Time Stamping function, the device has four pins
that are global to the entire PHY:

- PTP clock input pin (The CONFIG pin is used for this purpose.)
- PTP Event Request input pin (The LED[1] pin is used for this purpose)
- PTP Event Request input pin (The LED[1] pin is used for this purpose)
- Interrupt Pin (The LED[2] pin is used for this purpose)
"""

A bit further down in the datasheet:

"After configuration is completed and the external clock source is
enabled, the CONFIG pin is used as the external 125 Mhz reference clock
input"

So that's why our design as a switch: it allows the CONFIG pin to be
used for configuration during the reset sequence, and then as the pin
for the PTP clock input.

Does that clarify why the CONFIG pin is not simply connected to some
static pull-up/pull-down ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Handling an Extra Signal at PHY Reset

[Andrew Lunn]

On Tue, Feb 19, 2019 at 10:14:20AM +0100, Paul Kocialkowski wrote:
> Hi,
> 
> 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.

Hi Paul

Turns out the datasheet is publicly available.

So you can at run-time configure the voltage. Page 2, register 24, bit
13.

So back to my last question. Can you address the PHY without using the
switch? Even if it has the wrong voltage?

If you can, you could set the correct voltage in the probe() function.

   Andrew

Re: Handling an Extra Signal at PHY Reset

[Paul Kocialkowski]

Hi Andrew,

On Thu, 2019-02-21 at 02:49 +0100, Andrew Lunn wrote:
> On Tue, Feb 19, 2019 at 10:14:20AM +0100, Paul Kocialkowski wrote:
> > Hi,
> > 
> > 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.
> 
> Hi Paul
> 
> Turns out the datasheet is publicly available.
> 
> So you can at run-time configure the voltage. Page 2, register 24, bit
> 13.
> 
> So back to my last question. Can you address the PHY without using the
> switch? Even if it has the wrong voltage?
> 
> If you can, you could set the correct voltage in the probe() function.

Thanks for looking into our issue :)

I did some more investigating in the meantime, and the hardware logic
actually connects our CONFIG and LED pins when the controlling GPIO is
open-drain.

I can also confirm that it does not prevent contacting the PHY on the
MDIO bus, contrary to what I have stated previously.

So the important step for us to do is to disconnect the CONFIG and LED
pins (at least so we can see our LED blink properly) once the PHY was
reset. But we can't really rely on the fact that the pins were
connected before PHY reset (e.g. U-Boot may have disconnected them
already to use Ethernet) so we still need a way to connect them before
the PHY reset from the MDIO bus core hits, and disconnect them after
that.

Cheers,

Paul

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

Re: Handling an Extra Signal at PHY Reset

[Paul Kocialkowski]

Hi Florian,

On Tue, 2019-02-19 at 08:07 -0800, Florian Fainelli wrote:
> 
> On February 19, 2019 1:14:20 AM PST, Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > 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.
> 
> Even voltage? What guarantees do you have that you are not reducing
> the lifetime of your pads if e.g.: you are configured for 3.3V while
> the other end is 1.8/2.5V? Is there some kind of embedded voltage
> comparator that can be used to help making the right decision?

I'm really not sure about that. We know from the hardware design that
we need 1.8V/2.5V.

Unlike what I stated previously, the two pins are actually connected
when the controlling GPIO is open-drain and what we really need to do
is to disconnect them after reset so that both pins can be used for
their individual functions. But we can't be sure that they were not
already disconnected before by e.g. U-Boot, so we should also make sure
they are connected before issuing reset.

> > 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;
> 
> That would be a mis-representstion of the HW though, since the reset
> line is tied to the PHY package. Making use of the current
> implementation details to put a second reset line does not sound
> great.

Agreed, this is quite a far-fetched solution and in the end, what we
are controlling is not a reset line.

> > - 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);
> 
> Indeed, and still has the same design flaw as 1) outline above.
> 
> > - 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);
> 
> That one looks the most compelling and future proof although I do
> wonder how many people would make use of that.

About that one, it turns out that what we need to do has little to do
with power sequencing and more to do with configuration at reset time,
so it doesn't feel like a great fit either.

> > - 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?
> 
> You could explore having the MDIO bus layer scan its children nodes
> (PHY nodes) and handle properties in there before registering
> devices, so for insurance your PHY DT nodes can have an arbitrary
> number of reset lines, power sequencing properties etc. and the MDIO
> bus layer knowing it's internal implementation does make sure that it
> makes use of these properties in order to make PHY devices
> functional.
> 
> Does that make sense? One possible caveat is that the CONFIG pin also
> dictates the address on the bus, so what do we do with the PHY's
> "reg" property, is it it's actual address or is it the desired one
> that we should configure through reset?

That sounds like a good option to me as it would allow keeping the
property on the PHY node. I think having a "config-gpios" property on
the PHY node would work. Then the MDIO core can just walk the children
nodes, set this GPIO before reset, issue PHY reset and then unset the
GPIO.

Maybe we could also allow having the reset-gpios property on the PHY
node? As far as I understand, this property on the MDIO bus was
described as a bus-wide reset, but it seems to be used for PHY reset
instead most of the time (which is not really an accurate description
of the hardware).

I think we should keep the PHY's configured address in the description,
since the PHY will not change its address, but use the one set by the
CONFIG pin from reset.

Cheers,

Paul

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

Re: Handling an Extra Signal at PHY Reset

[Andrew Lunn]

> I can also confirm that it does not prevent contacting the PHY on the
> MDIO bus, contrary to what I have stated previously.

O.K, so wrong voltage does not matter, you can still probe the PHY.

Ignore the switch. Use a pin hog to set the GPIO to the disabled
state. And set the voltage using the PHY register during probe().

    Andrew
 

Re: Handling an Extra Signal at PHY Reset

[Paul Kocialkowski]

Hi Andrew,

On Thu, 2019-02-21 at 15:04 +0100, Andrew Lunn wrote:
> > I can also confirm that it does not prevent contacting the PHY on the
> > MDIO bus, contrary to what I have stated previously.
> 
> O.K, so wrong voltage does not matter, you can still probe the PHY.
> 
> Ignore the switch. Use a pin hog to set the GPIO to the disabled
> state. And set the voltage using the PHY register during probe().

Thanks a lot for your suggestion! I have tried it out and it appears to
work just as well as before.

Although the CONFIG pin state is still sampled at PHY reset, having it
connected to the PTP clock instead of the LED pin does not seem to
change the address we're getting.

We'll stick with that solution, since it's the least invasive one.

Cheers,

Paul

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