On 4/5/24 12:19, Luca Weiss wrote:
On Fri Apr 5, 2024 at 10:08 AM CEST, Neil Armstrong wrote:
Hi Luca,
On 29/03/2024 10:02, Luca Weiss wrote:
On Tue Mar 26, 2024 at 10:02 PM CET, Konrad Dybcio wrote:
On 16.03.2024 5:01 PM, Bjorn Andersson wrote:
On Fri, Mar 15, 2024 at 06:35:15PM +0100, Neil Armstrong wrote:
On 15/03/2024 18:19, Luca Weiss wrote:
On Thu Feb 29, 2024 at 2:07 PM CET, Neil Armstrong wrote:
Register a typec mux in order to change the PHY mode on the Type-C
mux events depending on the mode and the svid when in Altmode setup.
The DisplayPort phy should be left enabled if is still powered on
by the DRM DisplayPort controller, so bail out until the DisplayPort
PHY is not powered off.
The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states
will be set in between of USB-Only, Combo and DisplayPort Only so
this will leave enough time to the DRM DisplayPort controller to
turn of the DisplayPort PHY.
The patchset also includes bindings changes and DT changes.
This has been successfully tested on an SM8550 board, but the
Thinkpad X13s deserved testing between non-PD USB, non-PD DisplayPort,
PD USB Hubs and PD Altmode Dongles to make sure the switch works
as expected.
The DisplayPort 4 lanes setup can be check with:
$ cat /sys/kernel/debug/dri/ae01000.display-controller/DP-1/dp_debug
name = msm_dp
drm_dp_link
rate = 540000
num_lanes = 4
Hi Neil,
I tried this on QCM6490/SC7280 which should also support 4-lane DP but I
haven't had any success so far.
[..]
[ 1775.563969] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
[ 1775.564031] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
Interesting #1 means the 4 lanes are not physically connected to the other side,
perhaps QCM6490/SC7280 requires a specific way to enable the 4 lanes in the PHY,
or some fixups in the init tables.
I tested the same on rb3gen2 (qcs6490) a couple of weeks ago, with the
same outcome. Looking at the AUX reads, after switching to 4-lane the
link training is failing on all 4 lanes, in contrast to succeeding only
on the first 2 if you e.g. forget to mux the other two.
As such, my expectation is that there's something wrong in the QMP PHY
(or possibly redriver) for this platform.
Do we have any downstream tag where 4lane dp works? I'm willing to believe
the PHY story..
Just tested on Fairphone 5 downstream and 4 lane appears to work there.
This is with an USB-C to HDMI adapter that only does HDMI.
FP5:/ # cat /sys/kernel/debug/drm_dp/dp_debug
state=0x20a5
link_rate=270000
num_lanes=4
resolution=2560x1440@60Hz
pclock=241500KHz
bpp=24
test_req=DP_LINK_STATUS_UPDATED
lane_count=4
bw_code=10
v_level=0
p_level=0
Sources are here:
https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-5.4/+/refs/heads/odm/rc/target/13/fp5
And probably more importantly techpack/display:
https://gerrit-public.fairphone.software/plugins/gitiles/platform/vendor/opensource/display-drivers/+/refs/heads/odm/rc/target/13/fp5
Dts if useful:
https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/refs/heads/kernel/13/fp5
Could you retry with this applied ?
https://lore.kernel.org/all/20240405000111.1450598-1-swboyd@xxxxxxxxxxxx/
Unfortunately I do not see any change with this on QCM6490 Fairphone 5
and 4-lane DP.
Hm, could you like dump all the PHY regions up and downstream with the display
connected (and nothing connected) and compare them?
Konrad
