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@intel.com> 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
>