Messages in this thread | | | Date | Fri, 5 Apr 2024 10:08:34 +0200 | From | Neil Armstrong <> | Subject | Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode |
| |
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@chromium.org/
Thanks, Neil
> > Regards > Luca > >> >> Konrad >
| |