On 2017-03-03 04:13, Guenter Roeck wrote:
On 03/02/2017 07:22 AM, Mats Karrman wrote:
....
Looking forward, one thing I have run into is how to connect the typec driver
with a
driver for an alternate mode. E.g. the DisplayPort Alternate Mode specification
includes the HPD (hot plug) and HPD-INT (hot plug interrupt) signals as bits in
the
Attention message. These signals are needed by the DisplayPort driver to know
when to
start negotiation etc.
Have you got any thoughts on how to standardize such interfaces?
That really depends on the lower level driver. For Chromebooks, where the Type-C
Protocol Manager runs on the EC, we have an extcon driver which reports the pin
states
to the graphics drivers and connects to the Type-C class code using the Type-C
class
API. I still need to update, re-test, and publish that code. The published code
in
https://chromium.googlesource.com/chromiumos/third_party/kernel/, branch
chromeos-4.4,
shows how it can be done, though that code currently still uses the Android
Type-C
infrastructure.
OK, thanks!
My system is a bit different. It's an i.MX6 SoC with the typec phy and DP
controller connected
directly to the SoC and it's using DTB/OF.
Using extcon I would have a driver that is both typec class and extcon driver
at the same time
since I can't share the access to the typec phy. Is this done elsewhere in the
kernel?
I don't know much about the wcove PMIC and what alternate modes it might
support but I
guess that driver would end up in the same place.
Do we need to further standardize attributes under (each) specific alternate
mode to
include things such as HPD for the DP mode?
BR // Mats
