Re: USB-C DP mode problem on linux

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

 



Got it.
Thank You for quick replying. Due to coronavirus I was not able to issue a ticket quickly . But I created it.

Best Regards,

wt., 20 paź 2020 o 16:25 Imre Deak <imre.deak@xxxxxxxxx> napisał(a):
Hi,

On Mon, Oct 19, 2020 at 05:24:59PM +0300, Heikki Krogerus wrote:
> Hi Andrzej,
>
> On Sat, Oct 17, 2020 at 01:34:54PM +0200, Andrzej Kre wrote:
> > Hi,
> >
> > I know that You were involved in working on USB-C DP drivers.
> > You are my last chance to resolve my issue.
> >
> > On my HP laptop I have Intel UHD Graphics 620.
> > When I'm connecting my 4K monitor to Display Port. It is assigning to
> > DP-2-2 socket and  I have full 3840x2160 with 60.00Hz
> > But, when I'm connecting the same monitor to the USB-C port, then it is
> > connecting to the DP-1 socket and the maximum that it can achieve is
> > 3840x2160 with only 30.00Hz.
> > But I'm making some trick: I'm connecting the same monitor through HDMI, so
> > it is connecting to DP-1 socket, and simultaneously I'm connecting USB-C,
> > and now USB-C is connecting to DP-2-2 socket (because DP-1 is occupied by
> > HDMI) and I can have full 4K with 60Hz.
> > Please, help me, how to force USB-C to connect always to DP-2-2 socket?
> > Or do You know maybe where is the problem?
>
> Unfortunately we have no control over the mux in the operating system
> on Skylakes, at least in USB subsystem. It all happens in firmware.
> Maybe graphics side can do something.
>
> Adding Jani, Imre, Ville and the Intel GFX list.

On SKL/KBL the USB-C -> native DP/HDMI conversion is done by an off-CPU
chip and the display driver doesn't have a way either to affect the
muxing.

Not sure why things work on DP-2 and not on DP-1, there is no port
specific limits on the CPU side that would explain this. There is a link
training failure in the log, so would be good to see more details on
that. Could you file a ticket at
https://gitlab.freedesktop.org/drm/intel/-/issues
providing a full log booting with drm.debug=0x1e for the working and
non-working cases?

Thanks,
Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux