Hi all,
I'm working on mainlining of NXP1102 PHY (BroadR Reach/802.3bw) support.
Basic functionality is working and support with mainline kernel. Now it is time
to extend it. According to the specification, each PHY can be master or slave.
The HW can be pre configured via bootstrap pins or fuses to have a default
configuration. But in some cases we still need to be able to configure the PHY
in a different mode:
--------------------------------------------------------------------------------
http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf
6.1 MASTER-SLAVE configuration resolution
All BroadR-Reach PHYs will default to configure as SLAVE upon power up or reset
until a management system (for example, processor/microcontroller) configures
it to be MASTER. MASTER-SLAVE assignment for each link configuration is
necessary for establishing the timing control of each PHY.
6.2 PHY-Initialization
Both PHYs sharing a link segment are capable of being MASTER or SLAVE. In IEEE
802.3-2012, MASTER-SLAVE resolution is attained during the Auto-Negotiation
process (see IEEE 802.3-2012 Clause 28). However, the latency for this process
is not acceptable for automotive application. A forced assignment scheme is
employed depending on the physical deployment of the PHY within the car. This
process is conducted at the power-up or reset condition. The station management
system manually configures the BroadR-Reach PHY to be MASTER (before the link
acquisition process starts) while the link partner defaults to SLAVE
(un-managed).
--------------------------------------------------------------------------------
Should phylink be involved in this configuration? What's the proper user
space interface to use for this kind of configuration? ethtool or ip
comes into mind. Further having a Device Tree property to configure a
default mode to overwrite the boot strap pins would be nice to have.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Wed, Mar 25, 2020 at 09:34:49AM +0100, Oleksij Rempel wrote:
> Hi all,
>
> I'm working on mainlining of NXP1102 PHY (BroadR Reach/802.3bw) support.
>
> Basic functionality is working and support with mainline kernel. Now it is time
> to extend it. According to the specification, each PHY can be master or slave.
>
> The HW can be pre configured via bootstrap pins or fuses to have a default
> configuration. But in some cases we still need to be able to configure the PHY
> in a different mode:
> --------------------------------------------------------------------------------
> http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf
>
> 6.1 MASTER-SLAVE configuration resolution
>
> All BroadR-Reach PHYs will default to configure as SLAVE upon power up or reset
> until a management system (for example, processor/microcontroller) configures
> it to be MASTER. MASTER-SLAVE assignment for each link configuration is
> necessary for establishing the timing control of each PHY.
>
> 6.2 PHY-Initialization
>
> Both PHYs sharing a link segment are capable of being MASTER or SLAVE. In IEEE
> 802.3-2012, MASTER-SLAVE resolution is attained during the Auto-Negotiation
> process (see IEEE 802.3-2012 Clause 28). However, the latency for this process
> is not acceptable for automotive application. A forced assignment scheme is
> employed depending on the physical deployment of the PHY within the car. This
> process is conducted at the power-up or reset condition. The station management
> system manually configures the BroadR-Reach PHY to be MASTER (before the link
> acquisition process starts) while the link partner defaults to SLAVE
> (un-managed).
> --------------------------------------------------------------------------------
>
> Should phylink be involved in this configuration? What's the proper user
> space interface to use for this kind of configuration? ethtool or ip
> comes into mind. Further having a Device Tree property to configure a
> default mode to overwrite the boot strap pins would be nice to have.
Well, the first question would be whether this is something that
userspace needs to alter, or whether static configuration at boot
time is what is necessary.
Given what is in the description, it seems that the concern is with
the latency it takes for the link to come up. I would suggest that
the lowest latency would be achieved when using static configuration
rather than waiting for the kernel to fully boot and userspace to
start before configuring the PHY.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
On 3/25/20 9:34 AM, Oleksij Rempel wrote:
> Hi all,
Hi,
> I'm working on mainlining of NXP1102 PHY (BroadR Reach/802.3bw) support.
>
> Basic functionality is working and support with mainline kernel. Now it is time
> to extend it. According to the specification, each PHY can be master or slave.
>
> The HW can be pre configured via bootstrap pins or fuses to have a default
> configuration. But in some cases we still need to be able to configure the PHY
> in a different mode:
> --------------------------------------------------------------------------------
> http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf
>
> 6.1 MASTER-SLAVE configuration resolution
>
> All BroadR-Reach PHYs will default to configure as SLAVE upon power up or reset
> until a management system (for example, processor/microcontroller) configures
> it to be MASTER. MASTER-SLAVE assignment for each link configuration is
> necessary for establishing the timing control of each PHY.
Thanks for reminding me of this. I sent out
https://patchwork.ozlabs.org/project/netdev/list/?series=166575
maybe it helps.
On Wed, 25 Mar 2020 10:11:12 +0000
Russell King - ARM Linux admin <[email protected]> wrote:
> On Wed, Mar 25, 2020 at 09:34:49AM +0100, Oleksij Rempel wrote:
> > Hi all,
> >
> > I'm working on mainlining of NXP1102 PHY (BroadR Reach/802.3bw) support.
> >
> > Basic functionality is working and support with mainline kernel. Now it is
> > time to extend it. According to the specification, each PHY can be master
> > or slave.
> >
> > The HW can be pre configured via bootstrap pins or fuses to have a default
> > configuration. But in some cases we still need to be able to configure the
> > PHY in a different mode:
> > --------------------------------------------------------------------------------
> > http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf
> >
> > 6.1 MASTER-SLAVE configuration resolution
> >
> > All BroadR-Reach PHYs will default to configure as SLAVE upon power up or
> > reset until a management system (for example, processor/microcontroller)
> > configures it to be MASTER. MASTER-SLAVE assignment for each link
> > configuration is necessary for establishing the timing control of each PHY.
> >
> > 6.2 PHY-Initialization
> >
> > Both PHYs sharing a link segment are capable of being MASTER or SLAVE. In
> > IEEE 802.3-2012, MASTER-SLAVE resolution is attained during the
> > Auto-Negotiation process (see IEEE 802.3-2012 Clause 28). However, the
> > latency for this process is not acceptable for automotive application. A
> > forced assignment scheme is employed depending on the physical deployment
> > of the PHY within the car. This process is conducted at the power-up or
> > reset condition. The station management system manually configures the
> > BroadR-Reach PHY to be MASTER (before the link acquisition process starts)
> > while the link partner defaults to SLAVE (un-managed).
> > --------------------------------------------------------------------------------
> >
> > Should phylink be involved in this configuration? What's the proper user
> > space interface to use for this kind of configuration? ethtool or ip
> > comes into mind. Further having a Device Tree property to configure a
> > default mode to overwrite the boot strap pins would be nice to have.
>
> Well, the first question would be whether this is something that
> userspace needs to alter, or whether static configuration at boot
> time is what is necessary.
>
> Given what is in the description, it seems that the concern is with
> the latency it takes for the link to come up. I would suggest that
> the lowest latency would be achieved when using static configuration
> rather than waiting for the kernel to fully boot and userspace to
> start before configuring the PHY.
Yes, that would be the fastest, and in many cases the preferred way. But the
lack of auto negotiation is not a choice. It is imposed by the spec. Because
of this, and since the PHY's are configurable in software, there is some need
for configuration in user-space. Of course latency would not be an issue in
such a case, otherwise a fixed strapped configuration was chosen.
Best regards,
--
David Jander
Protonic Holland.