On 03/07/2017 10:50 PM, Peter Chen wrote:
You mean type-C trigger an ACPI event, and this ACPI event can notify
related USB controller driver doing role switch?
No (firmware programs the dual-role hw/registers), but never mind.
That could be the case.
If it is correct, there is a notifier between type-C and USB
controller driver, how to define this notifier for non-ACPI platform?
Once there is a platform with Type-C like that, the problem needs to
be solved. However..
I'm not commenting on Roger's dual role patch series, but I don't
really think it should be mixed with Type-C. USB Type-C and USB
Power Delivery define their own ways of handling the roles, and they
are not limited to the data role only. Things like OTG for example
will, and actually can not be supported. With Type-C we will have
competing state machines compared to OTG. The dual-role framework
may be useful on systems that provide more traditional connectors,
which possibly have the ID-pin like micro-AB, and possibly also
support OTG. It can also be something that exist in parallel with the Type-C
class, but there just can not be any dependencies between the two.
Yes, there are two independent things. But if the kernel doesn't have
a notifier between type-C message sender (type-c class) and message
receiver (like USB controller driver for role switch or other drivers
for alternate mode message), we had to find some ways at userspace.
..what ever the solution is, it really can't rely on user space.
... and, at least for our application, using extcon for the necessary notifications works
just fine.
I see, that means you have a hardware signal to notify role switch.
In our case the Type-C protocol manager (including alternate mode handling)
is implemented in an EC. The EC signals the extcon-cros_ec driver, which
in turn signals the phy driver as well as the DP driver. The Type-C class
is orthogonal; extcon-cros_ec will also register with the Type-C class code
once that is upstream.
As mentioned earlier, using extcon for signaling was the most convenient means
for us to pass events around. I am more than open to change it to a bus,
if that can be made to work - we'd have to keep in mind though that this code
already works without Type-C infrastructure and is for the most part already
upstream (the rk3399 code it ties into is upstream, and extcon-cros_ec has been
submitted as https://patchwork.kernel.org/patch/9583045/).
As for to how to handle alternate mode if the Type-C protocol manager
(TCPM) is implemented in the kernel - I have not yet implemented it yet,
but my thinking goes along the line described by Heikki in his last e-mail.
Note that we also have a kernel driver for FUSB302 which ties into my tcpm
driver. I'll have to check if that is public yet and if I or someone
else can publish it if there is interest.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
