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
