Message-ID: <7504ea5a-335b-4152-a0f4-5be68f048903@ti.com>
Date: Thu, 11 Jul 2024 13:23:34 +0530
From: Siddharth Vadapalli <s-vadapalli@...com>
To: Swapnil Kashinath Jakhade <sjakhade@...ence.com>
CC: Siddharth Vadapalli <s-vadapalli@...com>,
        "vkoul@...nel.org"
	<vkoul@...nel.org>,
        "kishon@...nel.org" <kishon@...nel.org>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "rogerq@...nel.org"
	<rogerq@...nel.org>,
        "thomas.richard@...tlin.com"
	<thomas.richard@...tlin.com>,
        "theo.lebrun@...tlin.com"
	<theo.lebrun@...tlin.com>,
        "robh@...nel.org" <robh@...nel.org>,
        "linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
        "srk@...com" <srk@...com>, Milind
 Parab <mparab@...ence.com>
Subject: Re: [PATCH v2] phy: cadence-torrent: add support for three or more
 links using 2 protocols

On Thu, Jul 11, 2024 at 06:43:01AM +0000, Swapnil Kashinath Jakhade wrote:
> Hi Siddharth,

Hello Swapnil,

Thank you for reviewing this patch.

[...]

> > - A multilink configuration doesn't necessarily imply two protocols
> >   since a single protocol may be split across links as follows:
> >   Lane 0 => Protocol 1
> >   Lane 1 => Unused
> >   Lane 2 => Protocol 1
> >   Lane 3 => Unused
> >   which corresponds to two links and therefore two sub-nodes. In such a
> >   case, treat it as two single-link configurations performed sequentially
> >   which happens to be the case prior to this patch. To address this,
> >   handle the case where cdns_torrent_phy_configure_multilink() can be
> >   invoked for a single protocol with multiple sub-nodes (links) by
> >   erroring out only when the number of protocols is strictly greater
> >   than two, followed by handling the configuration similar to how it was
> >   done prior to this patch.
> 
> The assumption here that "a single protocol when split across links is to be
> considered as single-link configurations performed sequentially" is not always
> correct.
> e.g. If there are 2 PCIe links, then this is a case of 'Multilink PCIe' and not 2 separate
> 'single link PCIe'. Multilink PCIe has different PLL configurations than for single link
> PCIe resulting in different register configurations.
> Also, for multi-protocol case, in cdns_torrent_phy_configure_multilink() function,
> the existing implementation considers this as multilink case of combination of 2
> protocols which has different register config than single link of each protocol.

I suppose that PCIe is the only such protocol since it can have
different speeds despite a single protocol (Gen1, Gen2, Gen3...), unlike
other protocols which have a fixed speed and therefore the PLL
associated with them doesn't have to be reconfigured as the rate will
never change. Please let me know if there are other protocols (maybe DP?)
which also require such special handling.

[...]

> > +		phy_t1 = fns(cdns_phy->protocol_bitmask, 0);
> > +		/**
> > +		 * For a single protocol split across multiple links,
> > +		 * assign TYPE_NONE to phy_t2 for configuring each link
> > +		 * identical to a single-link configuration with a single
> > +		 * protocol.
> > +		 */
> > +		phy_t2 = TYPE_NONE;
> 
> As mentioned above, assuming phy_t2 = TYPE_NONE is not correct here.

I can update this patch to handle it differently for PCIe multi-link, but
as of now I don't see any PCIe multi-link support in the current Torrent
SERDES driver in Mainline Linux.

> 
> FYI. I have shared few patches to TI earlier removing the constraint of Maximum 2 links (subnodes)
> in the driver specifically for Multilink PCIe cases.
> Please check first 4 patches in link below.
> https://github.com/t-c-collab/linux/commits/ti-linux-6.1.y-torrent-multi-pcie-sgmii-v1

The patches you are referring to above seem to remove the constraint of
a maximum of 2 links, __only__ when one of the protocols is PCIe [1].
However, that is not necessarily the only use-case for multiple links.

Please consider the following valid use-case:
SERDES Lane 0 -> SGMII
SERDES Lane 1 -> SGMII
SERDES Lane 2 -> QSGMII
SERDES Lane 3 -> SGMII
Representing the above in the device-tree will require 3 sub-nodes
(links):
&serdes {
	serdes_sgmii_link1: phy@0 {
		reg = <0>;
		cdns,num-lanes = <2>;
		#phy-cells = <0>;
		cdns,phy-type = <PHY_TYPE_SGMII>;
		resets = <&serdes_wiz 1>, <&serdes_wiz 2>;
	};
	serdes_qsgmii_link2: phy@2 {
		reg = <2>;
		cdns,num-lanes = <1>;
		#phy-cells = <0>;
		cdns,phy-type = <PHY_TYPE_QSGMII>;
		resets = <&serdes_wiz 3>;
	};
	serdes_sgmii_link3: phy@3 {
		reg = <3>;
		cdns,num-lanes = <1>;
		#phy-cells = <0>;
		cdns,phy-type = <PHY_TYPE_SGMII>;
		resets = <&serdes_wiz 4>;
	};
};

Such a configuration is valid since it is still using only 2 different
protocols. But the existing driver doesn't allow splitting/alternating
protocols. So any use-case is forced to conform to a consecutive allocation
of protocols. This patch enables the aforementioned use-case and this has
been validated for functionality on the J784S4 SoC with a custom board [2].

I believe that this patch can be extended further to support the PCIe
Multi-link configuration as well. Please let me know your thoughts on
this.

[1] https://github.com/t-c-collab/linux/commit/fd87922da100b1ed30015333e037c506c510e932#diff-814f5e3b47c89595aa30310ec07ab7aa8ac96f2921f524c4f5cd536a2c3c5adbR2488
[2] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1383684/tda4ap-q1-limitations-for-configuration-for-serdes-lanes-when-using-qsgmii-sgmii-and-sgmii-usb3-mixed/

Powered by blists - more mailing lists