Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-usb@vger.kernel.org,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>,
	Sean Paul <seanpaul@chromium.org>,
	dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers
Date: Wed, 27 Feb 2019 12:55:46 +0200	[thread overview]
Message-ID: <20190227105546.GF27730@kuha.fi.intel.com> (raw)
In-Reply-To: <20190225132037.31458-1-hdegoede@redhat.com>

Hi Hans,

On Mon, Feb 25, 2019 at 02:20:34PM +0100, Hans de Goede wrote:
> Hi All,
> 
> On some Cherry Trail devices, DisplayPort over Type-C is supported through
> a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
> datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
> case does the PD/alt-mode negotiation itself, rather then everything being
> handled in firmware.
> 
> So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch
> to DP mode and sets the mux accordingly. In this setup the HPD pin is not
> connected, so the i915 driver needs to respond to a software event and scan
> the DP port for changes manually.
> 
> Thanks to Heikki's great work on the DisplayPort altmode support in the
> typec subsys, we now correctly tell the dongle to switch to DP altmode
> and we correctly set the mux and orientation switches to connect the
> DP lines to the Type-C connector.
> 
> This just leaves sending an out-of-band hotplug event from the Type-C
> subsystem to the i915 driver and then we've fully working DP over Type-C
> on these devices.
> 
> This series implements this. The first patch adds a generic mechanism
> for oob hotplug events to be send to the drm subsys, the second patch
> adds support for this mechanism to the i915 driver and the third patch
> makes the typec displayport_altmode driver send these events.
> 
> The commit message of the first patch explains why I've chosen to things
> the way these patches do them.

One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.

I guess that is not a critical issue since there is a workaround (I
think) where the driver basically does trial and error, but ideally we
should be able to tell i915 also the pin assignment that was
negotiated with the partner device so it knows the DP lane count.

My original idea was that we pass that struct typec_displayport_data
as payload in the event. From the Configuration VDO the GPU drivers
can then see the negotiated DP pin assignment and determine the lane
count.

thanks,

-- 
heikki
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx