Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

Thanks,
Neil


Regards
Luca


Konrad






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux