Re: [PATCH 17/22] phy: qcom-qmp-combo: merge USB and DP configurations

[Johan Hovold <johan@kernel.org>]

On Mon, Nov 14, 2022 at 01:10:43PM +0300, Dmitry Baryshkov wrote:
> On 14/11/2022 11:54, Johan Hovold wrote:
> > On Sat, Nov 12, 2022 at 10:43:14AM +0300, Dmitry Baryshkov wrote:
> >> On 11/11/2022 11:56, Johan Hovold wrote:
> >>> It does not really make any sense to keep separate configuration
> >>> structures for the USB and DP parts of the same PHY so merge them.
   
> >>> -/* struct qmp_phy_cfg - per-PHY initialization config */
> >>>    struct qmp_phy_cfg {
> >>> -	/* phy-type - PCIE/UFS/USB */
> >>> -	unsigned int type;
> >>>    	int lanes;
> >>
> >> int lanes doesn't really make sense here in my opinion. It should be
> >> usb_lanes and dp_lanes.
> > 
> > It doesn't make much less sense than having it here currently do.
> > 
> > All of these USB-C PHYs are dual lane for bi-directional SS USB and
> > quad lane for uni-directional DP (even if only CC1 orientation and lanes
> > 2 and 3 are currently supported).
> 
> I was under impression that sdm845 has just a single lane for each of 
> USB and DP. After rechecking the phy/next, I see that it was my mistake 
> (quite logical, SS is two lanes, so the compliant PHY must have two 
> lanes too).
> 
> I wander how/if 4-lane DP works. The only thing that we do is 
> programming of the QSERDES_DP_PHY_PD_CTL register, however judging e.g. 
> your 4-lane PCIe changes, one should probably also program the other two 
> lanes. Maybe it is handled automatically inside the hardware.

4-lane PCIe on SC8280XP is a different thing entirely (and remember that
that's actually 8 uni-directional lanes).

I'm sure there are further problems with the current DP alt mode
implementation, but hopefully that can be resolved when adding support
for orientation detection. I'm just fixing the obvious bugs and try to
stay "bug compatible" otherwise. :)

> > I should probably just drop the lanes parameter completely, either as a
> > preparatory clean up or as follow-on one (e.g. also a bit depending on
> > if there are other reasons for respinning a v2).
> 
> I think a follow up is enough, but let's get it. Having a single lanes=2 
> field looks... strange.

I dropped the lane parameter as a preparatory patch to this one in v2
that I'll post in a bit.

Johan