Message-ID: <0dc54057-d7a0-4123-badc-8f7f07f2d930@kernel.org>
Date: Thu, 11 Jul 2024 11:04:57 +0300
From: Roger Quadros <rogerq@...nel.org>
To: Siddharth Vadapalli <s-vadapalli@...com>,
 Swapnil Kashinath Jakhade <sjakhade@...ence.com>
Cc: "vkoul@...nel.org" <vkoul@...nel.org>,
 "kishon@...nel.org" <kishon@...nel.org>,
 "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
 "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

Siddharth,

On 11/07/2024 10:53, Siddharth Vadapalli wrote:
> 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.

The constraint is PLL frequency and not protocols as such right?
e.g. If there are 4 protocols that all use same PLL frequency then we should
be able to support it?

How about updating the patch to limit on number of PLL frequencies rather than
number of protocols? This should deal with PCIe multi-link case as well.

> 
> [...]
> 
>>> +		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/

-- 
cheers,
-roger

Powered by blists - more mailing lists