netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milind Parab <mparab@cadence.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: "nicolas.nerre@microchip.com" <nicolas.nerre@microchip.com>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"antoine.tenart@bootlin.com" <antoine.tenart@bootlin.com>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dhananjay Vilasrao Kangude <dkangude@cadence.com>,
	"a.fatoum@pengutronix.de" <a.fatoum@pengutronix.de>,
	"brad.mouring@ni.com" <brad.mouring@ni.com>,
	Parshuram Raju Thombare <pthombar@cadence.com>
Subject: RE: [PATCH v2 3/3] net: macb: add support for high speed interface
Date: Mon, 16 Dec 2019 12:49:59 +0000	[thread overview]
Message-ID: <BY5PR07MB65143D385836FF49966F5F6AD3510@BY5PR07MB6514.namprd07.prod.outlook.com> (raw)
In-Reply-To: <20191215152000.GW1344@shell.armlinux.org.uk>

>> > +	if (bp->phy_interface == PHY_INTERFACE_MODE_USXGMII) {
>>
>> Why bp->phy_interface and not state->interface?

okay, this needs to change to state->interface

>>
>> If you don't support selecting between USXGMII and other modes at
>> runtime, should macb_validate() be allowing ethtool link modes for
>> it when it's different from the configured setting?

We have separate SGMII and USXGMII PCS, which are enabled and programmed 
by MAC driver. Also, there are separate low speed (up to 1G) and high 
speed MAC which can be programmed though MAC driver. 
As long as, PHY (PMA, external to Cadence MAC controller) can handle 
this change, GEM can work with interface changes at a runtime.

>>
>> > +		if (gem_mac_usx_configure(bp, state) < 0) {
>> > +			spin_unlock_irqrestore(&bp->lock, flags);
>> > +			phylink_mac_change(bp->phylink, false);
>>
>> I guess this is the reason you're waiting for the USXGMII block
>> to lock - do you not have any way to raise an interrupt when
>> something changes with the USXGMII (or for that matter SGMII)
>> blocks?  Without that, you're fixed to a single speed.

Yes, we need to wait (poll) until USXGMII block lock is set.
Interrupt for USXGMII block lock set event is not supported.

>
>BTW, if you don't have an macb_mac_pcs_get_state() implementation,
>and from what you described last time around, I don't see how SGMII
>nor this new addition of USXGMII can work for you. Both these
>protocols use in-band control words, which should be read and
>interpreted in macb_mac_pcs_get_state().
>
>What I think you're trying to do is to use your PCS PHY as a normal
>PHY, or maybe you're ignoring the PCS PHY completely and relying on
>an external PHY (and hence always using MLO_AN_PHY or MLO_AN_FIXED
>mode.)

We are limiting our functionality to 10G fixed link using PCS and SFP+
Though the Cadence MAC is a full functional ethernet MAC controller, 
we are not sure what PHY or PCS be used in the end system.
Hence we are using PCS PHY as a normal PHY and not dependent on 
macb_mac_pcs_get_state(). Also it should be noted that we are 
not doing any change in SGMII. Status available in PCS is 
just a "status transferred" from PHY. So in case of SGMII, whether 
we read from PCS or from PHY, it is the same information. 

Below are listed all the possible use cases of Cadence GEM 10G controller

Basic MII MAC/PHY interconnect using MDIO for link status xfer.
 +-------------+                                    +--------+
 |             |                                    |        |
 | GEM MAC/DMA | <------ GMII/RGMII/RMII/MII -----> |  PHY   |
 |             |                                    |        |
 +-------------+                                    +--------+
       ^                                                 ^
       |_____________________ MDIO ______________________|

No PHY. No status xfer required. GEM PCS responsible for auto-negotiation
across link. Driver must interrogate PCS registers within GEM.
 +-------------+                                    +--------+
 |             |       |        |                   |        |
 | GEM MAC/DMA | <---> | SerDes | <- 1000BASE-X ->  |  SFP   |
 |    PCS      |       | (PMA)  |                   |        |
 +-------------+                                    +--------+      

SGMII MAC/PHY interconnect using MDIO for link status xfer.
 +-------------+                                    +--------+
 |             |       |        |                   |        |
 | GEM MAC/DMA | <---> | SerDes | <--- SGMII --->   |  PHY   |
 |  SGMII PCS  |       | (PMA)  |                   |        |
 +-------------+                                    +--------+
       ^                                                 ^
       |_____________________ MDIO ______________________|

SGMII MAC/PHY interconnect using inline status xfer. Multi-rate.
Driver must interrogate PCS registers within GEM.
 +-------------+                                    +--------+
 |             |       |        |                   |        |
 | GEM MAC/DMA | <---> | SerDes | <--- SGMII --->   |  PHY   |
 |  SGMII PCS  |       | (PMA)  |                   |        |
 +-------------+                                    +--------+

Up to 2.5G. MAC/PHY interconnect. Rate determined by 2.5GBASE-T PHY capability.
 +--------------+                                  +-----------+
 |              |       |        |                 |           |
 | GEM MAC/DMA  | <---> | SerDes | <-2500BASE-X->  |2.5GBASE-T |
 |2.5GBASE-X PCS|       | (PMA)  |                 |   PHY     |
 +--------------+                                  +-----------+

No ability for host to interrogate Optical.
 +--------------+                                  +-----------+
 |              |       |        |                 |  SFP+     |
 | GEM MAC/DMA  | <---> | SerDes | <---- SFI-----> | Optical   |
 |   USX PCS|   |       | (PMA)  |                 | Module    |
 +--------------+                                  +-----------+

Additional 3rd party I2C IP required (not part of GEM) for module
interrogation (MDIO to I2C handled by SW
 +--------------+                                  +-----------+
 |              |       |        |                 |  SFP+     |
 | GEM MAC/DMA  | <---> | SerDes | <---- SFI-----> | Optical   |
 |   USX PCS|   |       | (PMA)  |                 | Module    |
 +--------------+                                  +-----------+
                                                         ^
        +--------+                                       |
        | I2C    |                                       |
        | Master | <-------------------------------------|
        +--------+

Rate determined by 10GBASE-T PHY capability through auto-negotiation. 
I2C IP required
 +--------------+                                  +-----------+
 |              |       |        |                 |  SFP+ to  |
 | GEM MAC/DMA  | <---> | SerDes | <---- SFI-----> | 10GBASE-T |
 |   USX PCS|   |       | (PMA)  |                 |           |
 +--------------+                                  +-----------+
                                                         ^
        +--------+                                       |
        | I2C    |                                       |
        | Master | <-------------------------------------|
        +--------+

USXGMII PHY. Uses MDIO or equivalent for status xfer
 +-------------+                                    +--------+
 |             |       |        |                   |        |
 | GEM MAC/DMA | <---> | SerDes | <--- USXGMII ---> |  PHY   |
 |  USX PCS    |       | (PMA)  |                   |        |
 +-------------+                                    +--------+
       ^                                                 ^
       |_____________________ MDIO ______________________|


>
>
>
>--

  reply	other threads:[~2019-12-16 12:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13  9:40 [PATCH v2 0/3] net: macb: fix for fixed link, support for c45 mdio and 10G Milind Parab
2019-12-13  9:41 ` [PATCH v2 1/3] net: macb: fix for fixed-link mode Milind Parab
2019-12-15  4:33   ` Jakub Kicinski
2019-12-13  9:41 ` [PATCH v2 2/3] net: macb: add support for C45 MDIO read/write Milind Parab
2019-12-15 14:56   ` Andrew Lunn
2019-12-13  9:42 ` [PATCH v2 3/3] net: macb: add support for high speed interface Milind Parab
2019-12-15 15:12   ` Russell King - ARM Linux admin
2019-12-15 15:20     ` Russell King - ARM Linux admin
2019-12-16 12:49       ` Milind Parab [this message]
2019-12-16 13:09         ` Russell King - ARM Linux admin
2019-12-16 14:30           ` Russell King - ARM Linux admin
2019-12-20  9:05           ` Milind Parab
2019-12-21 11:08           ` Milind Parab
2020-01-08 10:32             ` Nicolas.Ferre
2019-12-15  9:49 ` [PATCH v2 0/3] net: macb: fix for fixed link, support for c45 mdio and 10G Parshuram Raju Thombare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BY5PR07MB65143D385836FF49966F5F6AD3510@BY5PR07MB6514.namprd07.prod.outlook.com \
    --to=mparab@cadence.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=andrew@lunn.ch \
    --cc=antoine.tenart@bootlin.com \
    --cc=brad.mouring@ni.com \
    --cc=davem@davemloft.net \
    --cc=dkangude@cadence.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.nerre@microchip.com \
    --cc=pthombar@cadence.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).