Hi,
On 27-02-19 12:16, Jani Nikula wrote:
On Wed, 27 Feb 2019, Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> wrote:
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.
Also, orientation.
The orientation should simply be correct with Type-C over DP. The mux /
orientation-switch used will take care of (physically) swapping the
lanes if the connector is inserted upside-down.
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.
Yeah, if the information is there, we'd like to know.
So far machines actually using a setup where the kernel does the
USB-PD / Type-C negotiation rather then this being handled in firmware
in say the Alpine Ridge controller, are very rare.
AFAIK in the Alpine Ridge controller case, there is no communication
with the i915 driver, the only thing the Alpine Ridge controller does
which the everything done in the kernel approach does not, is that
it actually has a pin connected to the HDP pin of the displayport in
question. But that just lets the i915 driver know about hotplug-events,
not how many lanes are used.
Currently I'm aware of only 2 x86 models which actually need the
hotplug event propagation from the Type-C subsystem to the i915 driver.
Do we really want to come up with a much more complex solution to
optimize for this corner case, while the much more common case
(Alpine Ridge controller) does not provide this info to the i915 driver?
To give some idea of the complexity, first of all we need some
mechanism to let the kernel know which drm_connector is connected
to which Type-C port. For the 2 models I know if which need this, this
info is not available and we would need to hardcode it in the kernel
based on e.g. DMI matching.
Then once we have this link, we need to start thinking about probe
ordering. Likely we need the typec framework to find the drm_connector,
since the typec-partner device is only created when there actually is
a DP capable "dongle" connected, making doing it the other way around
tricky. Then the typec-partner device needs to get a reference or some
such to make sure the drm_connector does not fgo away during the lifetime
of the typec-partner device.
I would really like to avoid this, so if we want to send more info to
the i915 driver, I suggest we create some event struct for this which
gets passed to the notifier, this could include a string to
describe the DP connector which the Type-C connector is connected to
when the mux is set to DP mode, e.g. "i915/DP-1" should be unique
or probably better, use the PCI device name, so: "0000:00:02.0/DP-1"
Then we still have a loose coupling avoiding lifetime issues, while
the receiving drm driver can check which connector the event is for
and we can then also include other info such as lane-count and orientation
in the event struct.
With the orientation
As said, the orientation *should* be corrected by the mux switch,
it is corrected by the mux switch on the hardware I know about and
actually getting it wrong breaks the display output (we had a bug there),
so I guess that getting it wrong leads to the lines being swizzled in a way
which the i915 driver does not check for ...
Regards,
Hans
