[PATCH 2/2] phy: qcom-qmp: Register as a typec switch for orientation detection

[Bjorn Andersson]

On Tue 06 Jul 17:35 PDT 2021, Bryan O'Donoghue wrote:

> On 07/07/2021 01:00, Bjorn Andersson wrote:
> > In order to perform link training on 4 lanes we need to reset the
> > PHY_MODE_CTRL with only DP_MODE.
> 
> We're only the two lanes for USB on sm8250 and at the moment only USB works
> - not dp on 8250.
> 
> Perhaps you've discovered why the DP times out on 8250..
> 

The way this problem manifest itself in my testing (on sc8180x) is that
the 3rd lane fails to complete link training, although it wasn't
completely obvious from the kernel prints until you look at the
implementation.

I don't know if you're still struggling with the AUX timeout, but if
you're past that this would be a strong candidate. That said, if you set
data-lanes = <0 1> in your DP node then it won't attempt to go 4 lanes
and wouldn't hit this problem.

> > In my efforts on sc8180x I skipped the disable/enable in switch_set() (I
> > believe because I didn't have the init_count check...) and then in
> > qcom_qmp_phy_configure_dp_mode() I issue a reset when we're heading to 4
> > lanes. Perhaps we can do the disable/enable and achieve the same thing,
> > but as written here you won't get 4 lanes...
> > 
> > I will do some more testing.
> 
> Do you have a commit I can cherry pick ? Might be worth testing out with
> tcpm + dp on the sm8250 if its working for you on sc8180x
> 

I dumped my hack-branch on github a while ago and have been working on
cleaning this up to get the patches out:

https://github.com/andersson/kernel/commits/wip/sc8180x-edp-dp-nvme-sdx55-dump

Unfortunately I extended my testing and realized that DPMS doesn't work
reliably.

With my MST hub (and single monitor) I often hit a security violation
when accessing REG_DP_STATE_CTRL when powering down the display, unless
I have drm.debug=511 (i.e. changing the timing of things). With the more
favourable timing DPMS on/off works nicely.

With my direct type-c/dp cable I can reliably power down the display,
but resuming it generally fails immediately - the monitor is waking up,
and then goes back to sleep (probably because the software has given up
on me already).

Trying to debug these two issues currently.

Connecting, disconnecting and reconnecting the cable works reliably
though, so once upstream boots again I intend to send out most of my
cleaned up patches.

Regards,
Bjorn