Message ID | 20220902213721.946138-1-sean.anderson@seco.com |
---|---|
Headers | show |
Series | phy: Add support for Lynx 10G SerDes | expand |
Hi Vinod/Kishon, On 9/2/22 5:37 PM, Sean Anderson wrote: > This adds support for the Lynx 10G SerDes found on the QorIQ T-series > and Layerscape series. Due to limited time and hardware, only support > for the LS1046ARDB is added in this initial series. There is a sketch > for LS1088ARDB support, but it is incomplete. > > Dynamic reconfiguration does not work. That is, the configuration must > match what is set in the RCW. From my testing, SerDes register settings > appear identical. The issue appears to be between the PCS and the MAC. > The link itself comes up at both ends, and a mac loopback succeeds. > However, a PCS loopback results in dropped packets. Perhaps there is > some undocumented register in the PCS? > > I suspect this driver is around 95% complete, but, unfortunately, I no > longer have time to investigate this further. > > Changes in v5: > - Update commit description > - Dual id header > - Remove references to PHY_INTERFACE_MODE_1000BASEKX to allow this > series to be applied directly to linux/master. > - Add fsl,lynx-10g.h to MAINTAINERS > > Changes in v4: > - Add 2500BASE-X and 10GBASE-R phy types > - Use subnodes to describe lane configuration, instead of describing > PCCRs. This is the same style used by phy-cadence-sierra et al. > - Add ids for Lynx 10g PLLs > - Rework all debug statements to remove use of __func__. Additional > information has been provided as necessary. > - Consider alternative parent rates in round_rate and not in set_rate. > Trying to modify out parent's rate in set_rate will deadlock. > - Explicitly perform a stop/reset sequence in set_rate. This way we > always ensure that the PLL is properly stopped. > - Set the power-down bit when disabling the PLL. We can do this now that > enable/disable aren't abused during the set rate sequence. > - Fix typos in QSGMII_OFFSET and XFI_OFFSET > - Rename LNmTECR0_TEQ_TYPE_PRE to LNmTECR0_TEQ_TYPE_POST to better > reflect its function (adding post-cursor equalization). > - Use of_clk_hw_onecell_get instead of a custom function. > - Return struct clks from lynx_clks_init instead of embedding lynx_clk > in lynx_priv. > - Rework PCCR helper functions; T-series SoCs differ from Layerscape SoCs > primarily in the layout and offset of the PCCRs. This will help bring a > cleaner abstraction layer. The caps have been removed, since this handles the > only current usage. > - Convert to use new binding format. As a result of this, we no longer need to > have protocols for PCIe or SATA. Additionally, modes now live in lynx_group > instead of lynx_priv. > - Remove teq from lynx_proto_params, since it can be determined from > preq_ratio/postq_ratio. > - Fix an early return from lynx_set_mode not releasing serdes->lock. > - Rename lynx_priv.conf to .cfg, since I kept mistyping it. > > Changes in v3: > - Manually expand yaml references > - Add mode configuration to device tree > - Rename remaining references to QorIQ SerDes to Lynx 10G > - Fix PLL enable sequence by waiting for our reset request to be cleared > before continuing. Do the same for the lock, even though it isn't as > critical. Because we will delay for 1.5ms on average, use prepare > instead of enable so we can sleep. > - Document the status of each protocol > - Fix offset of several bitfields in RECR0 > - Take into account PLLRST_B, SDRST_B, and SDEN when considering whether > a PLL is "enabled." > - Only power off unused lanes. > - Split mode lane mask into first/last lane (like group) > - Read modes from device tree > - Use caps to determine whether KX/KR are supported > - Move modes to lynx_priv > - Ensure that the protocol controller is not already in-use when we try > to configure a new mode. This should only occur if the device tree is > misconfigured (e.g. when QSGMII is selected on two lanes but there is > only one QSGMII controller). > - Split PLL drivers off into their own file > - Add clock for "ext_dly" instead of writing the bit directly (and > racing with any clock code). > - Use kasprintf instead of open-coding the snprintf dance > - Support 1000BASE-KX in lynx_lookup_proto. This still requires PCS > support, so nothing is truly "enabled" yet. > - Describe modes in device tree > - ls1088a: Add serdes bindings > > Changes in v2: > - Rename to fsl,lynx-10g.yaml > - Refer to the device in the documentation, rather than the binding > - Move compatible first > - Document phy cells in the description > - Allow a value of 1 for phy-cells. This allows for compatibility with > the similar (but according to Ioana Ciornei different enough) lynx-28g > binding. > - Remove minItems > - Use list for clock-names > - Fix example binding having too many cells in regs > - Add #clock-cells. This will allow using assigned-clocks* to configure > the PLLs. > - Document the structure of the compatible strings > - Rename driver to Lynx 10G (etc.) > - Fix not clearing group->pll after disabling it > - Support 1 and 2 phy-cells > - Power off lanes during probe > - Clear SGMIIaCR1_PCS_EN during probe > - Rename LYNX_PROTO_UNKNOWN to LYNX_PROTO_NONE > - Handle 1000BASE-KX in lynx_proto_mode_prep > - Use one phy cell for SerDes1, since no lanes can be grouped > - Disable SerDes by default to prevent breaking boards inadvertently. > > Sean Anderson (8): > dt-bindings: phy: Add 2500BASE-X and 10GBASE-R > dt-bindings: phy: Add Lynx 10G phy binding > dt-bindings: clock: Add ids for Lynx 10g PLLs > phy: fsl: Add Lynx 10G SerDes driver > arm64: dts: ls1046a: Add serdes bindings > arm64: dts: ls1088a: Add serdes bindings > arm64: dts: ls1046ardb: Add serdes bindings > [WIP] arm64: dts: ls1088ardb: Add serdes bindings > > .../devicetree/bindings/phy/fsl,lynx-10g.yaml | 236 ++++ > Documentation/driver-api/phy/index.rst | 1 + > Documentation/driver-api/phy/lynx_10g.rst | 66 + > MAINTAINERS | 7 + > .../boot/dts/freescale/fsl-ls1046a-rdb.dts | 112 ++ > .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 18 + > .../boot/dts/freescale/fsl-ls1088a-rdb.dts | 161 +++ > .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 18 + > drivers/phy/freescale/Kconfig | 20 + > drivers/phy/freescale/Makefile | 3 + > drivers/phy/freescale/lynx-10g.h | 16 + > drivers/phy/freescale/phy-fsl-lynx-10g-clk.c | 501 +++++++ > drivers/phy/freescale/phy-fsl-lynx-10g.c | 1162 +++++++++++++++++ > include/dt-bindings/clock/fsl,lynx-10g.h | 14 + > include/dt-bindings/phy/phy.h | 2 + > 15 files changed, 2337 insertions(+) > create mode 100644 Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml > create mode 100644 Documentation/driver-api/phy/lynx_10g.rst > create mode 100644 drivers/phy/freescale/lynx-10g.h > create mode 100644 drivers/phy/freescale/phy-fsl-lynx-10g-clk.c > create mode 100644 drivers/phy/freescale/phy-fsl-lynx-10g.c > create mode 100644 include/dt-bindings/clock/fsl,lynx-10g.h > I noticed in patchwork [1] that this entire series is marked as "Changes Requested," despite having received only automated feedback on one patch in the series. I am concerned about this because last time this occurred [2], the series received no feedback for a month. I suspect this is because series marked "Changes Requested" are hidden in patchwork by default. Can you change the status of this series back to new? Or should I just resend again? --Sean [1] https://patchwork.kernel.org/project/linux-phy/list/?series=673741&state=* [2] https://patchwork.kernel.org/project/linux-phy/list/?series=665484&state=*
On 09-09-22, 11:05, Sean Anderson wrote: > > I noticed in patchwork [1] that this entire series is marked as "Changes > Requested," despite having received only automated feedback on one patch > in the series. I am concerned about this because last time this occurred > [2], the series received no feedback for a month. I suspect this is > because series marked "Changes Requested" are hidden in patchwork by > default. Can you change the status of this series back to new? Or should > I just resend again? Yes please, update with ack collected any feedback addressed would be right... > [1] https://patchwork.kernel.org/project/linux-phy/list/?series=673741&state=* > [2] https://patchwork.kernel.org/project/linux-phy/list/?series=665484&state=*