1000Base-KX lanes need a 312.5 MHz clock for backplane auto-negotiation.
The reference manual suggests to generate this frequency from the PLL's
FRATE_SEL/16, through the ex_dly_clk mechanism (note: we know that
FRATE_SEL must be 5 GHz for 1000Base-KX, as for all other 1G protocols).
The ex_dly_clk is used on some SoCs for other stuff as well: for example
on LS1028A, it is used to derive the SYS_CLK for the Felix Ethernet
switch when that has 1G SGMII or QSGMII lanes. For other SerDes
protocols, the switch SYS_CLK is derived from other places. But when it
comes from ex_dly_clk, the RCW will automatically set PLLnCR0[DLYDIV_SEL]
to 1.
To cope with that case, we bake logic into the driver to bump the usage
count of ex_dly_clk at driver probe time. This way, it never really
drops to zero even after all lanes went to 1000Base-KX and back to
something else.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Dynamic SerDes protocol changing has been tested using C73
auto-negotiation and it works, so remove the restriction.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
lynx_10g_switch_needs_rcw_override() determines whether the switchover
takes place between any 1G and 2.5G Ethernet lane mode, because those
don't require RCW override.
1000Base-KX is backplane Ethernet at 1G, and therefore it should also
be in this list, because no RCW override of the SerDes protocol is
necessary when switching to it from 1000Base-X, SGMII, or 2500Base-X.
This matters because some SoCs (like LS1028A) do not have RCW override
at all, and thus they error out on this check when enabling 1000Base-KX,
which is absolutely unnecessary.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Some SerDes protocols like QSGMII or 10G-QXGMII are multi-port - that
is, they multiplex multiple protocol converters onto the same SerDes
lane (PHY).
The question "what is the address of this lane's protocol converter?" as
asked by PHY_STATUS_PCVT_ADDR is nonsensical in such a case, because
there are multiple converters, and it is not clear which one is being
querier.
So far we've only been using PHY_PCVT_ETHERNET_ANLT (which indeed is at
most one per lane) and not PHY_PCVT_ETHERNET_PCS where the problem truly
lies. But we have to add more API to query the protocol converter count,
and then query the addresses of individual protocol converters for the
currently configured PHY mode.
Fix the PHY API, Lynx SerDes drivers and MTIP backplane AN/LT consumer
all in one go.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Add support for the RCW override procedure which enables runtime
reconfiguration of the protocol running on a SerDes lane. The procedure
is done through the DCFG DCSR space which now can be defined as the
second memory region of the guts DT node.
Support is added on the following SoCs: LS1046A, LS1088A, LS2088A.
The procedure is exported to the "client" driver - the Lynx10G SerDes
PHY driver - through the following functions:
- fsl_guts_lane_init() used to notify the initial / at boot time lane
mode running on a SerDes lane.
- fsl_guts_lane_validate() used to validate that changing the protocol
on a specific lane is supported.
- fsl_guts_lane_set_mode() which can be used to request the RCW
procedure be executed for a specific lane.
The necessary changes in the Lynx10G SerDes driver are also implemented
in this patch.
Since the RCW override procedure is different depending on the SoC, the
private fsl_soc_data structure is updated with two new per SoC callbacks
(.serdes_get_rcw_override() and .serdes_init_rcwcr()) which get used
from the generic fsl_guts_lane_set_mode() function. These two callbacks
hide all the SoC specific register offsets, masks and values so that the
_set_mode() procedure is straightforward.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
The lynx_lane_mode enum will need to be used from the fsl_guts driver in
order to do the RCW override procedure for a specific Lynx10G link mode.
Since we need the enum into a public header file, create the
phy-fsl-lynx.h header for this purpose.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Add a new field to struct lynx_info to be able to identify precisely the
Lynx10G block index. This will get used in the next patches which do RCW
override.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Fix the following bugs in the 'fsl,ls1088a-serdes1':
- Remove the LANE_MODE_2500BASEX mode since this is not listed in the
SoC RM as a support mode.
- Mark the XFI protocol converter as being available on lanes #2 and #3.
- Remove a forgotten 'return' statement from the
ls1088a_serdes1_get_pcvt_offset() function.
This driver was tested on the LS1088ARDB board with the following
protocols: 10GBASER, 1000BASE-X/SGMII and QSGMII. As such, mark the SoC
as tested.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
The 'fsl,ls2088a-serdes1' compatible handling was tested in a copper
backplane scenario. Remove the comment saying otherwise.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
lynx_pccr_read() may return -EOPNOTSUPP if the representation of the SoC
integration that is hardcoded in the driver - priv->info->get_pccr() -
does not expect there to exist a PCCR register for a given lane and
SerDes protocol.
In lynx_10g_backup_pccr_val(), we are ignoring that negative error code
on good faith, which means that the way in which the hardware is
configured at probe time will never take us by surprise.
Given the fact that we issue no hardware reset to the SerDes on probe,
it can happen that someone has messed with the lane configuration in an
invalid way during a prior boot stage (e.g. PBL), forcing a protocol
selection in LNaPSSR0_TYPE for which we have no actual protocol converter.
What would happen in that case is that we would happily ignore the
-EOPNOTSUPP from lynx_pccr_read() and proceed to save an uninitialized
"u32 val" as lane->default_pccr, and continue on, thinking this lane is
OK to be used.
What we should probably do instead is to mark the lane as having an
unknown protocol, because we don't expect it to be configured that way,
and produce a warning.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The blamed commit introduced a phy_exit() call which was missing before,
to lynx_pcs_destroy(). The role of phy_exit() is to bring the
phy->init_count from the phy core back to 0, so that a subsequent
phy_init() call gets propagated to the driver again.
What was happening is that when the dpaa2-mac driver had -EPROBE_DEFER
and it called phy_init() a second time, that didn't get propagated to
the driver, since the phy->init_count would just get bumped to 2.
That is no longer the case - we call phy_init() each time, but the Lynx
hardware is not prepared to power down a powered down lane. Instead, the
driver just hangs in the loop that expects the power down operation to
finalize.
Fix that by implementing phy_exit() as the operation which powers the
lane back up - essentially the expected operation when it is not managed
by a consumer, but operating as standalone.
Fixes: 7a560782c9 ("net: pcs: lynx: incorporate SerDes PHY handling from dpaa2-mac")
Debugged-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Introduce a driver for the networking lanes of the Lynx 10G block,
present on the majority of Layerscape and QorIQ (Freescale/NXP) SoCs.
Co-developed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
