Hi Heikki, I have a question regarding the preferred_role node. +What: /sys/class/typec/<port>/preferred_role +Date: March 2017 +Contact: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> +Description: + The user space can notify the driver about the preferred role. + It should be handled as enabling of Try.SRC or Try.SNK, as + defined in USB Type-C specification, in the port drivers. By + default the preferred role should come from the platform. + + Valid values: source, sink, none (to remove preference) What is the expected behavior when the userspace changes the preferred_role node when the port is in connected state ? 1. the state machine re-resolves the port roles right away based on the new state machine in place ? (or) 2. Wait till the subsequent connect for resolving port roles based on the new state machine. For #1 to happen the policy_engine layer would have to reset the port to resolve the port roles based on the (Try.SRC /Try.SNK/ Default) new state machine preference. Say for example when two non-PD devices following none (default state machine) are connected, the port role resolution is going to be random. But, if the userspace in one of the devices later changes the preferred_role to source, then that device is most likely to become source if the Try.SRC state-machine is re-run. Does the above question fall under a policy decision ? If so, should there be another node to say if the port roles have to re-resolved based on the new state machine right away ? Thanks !! On Fri, Mar 10, 2017 at 3:41 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > On 03/10/2017 02:22 PM, Mats Karrman wrote: >> >> On 2017-03-08 14:58, Heikki Krogerus wrote: >> >>> On Tue, Mar 07, 2017 at 11:30:54PM +0100, Mats Karrman wrote: >>>> >>>> If I read Heikki's original suggestion I understand it like the DP >>>> driver would be >>>> responsible for AM specific USB PD/VDM communication. But wouldn't that >>>> lead >>>> to a lot of code duplication since the AM protocol is the same for all >>>> drivers of >>>> a kind? >>> >>> No that's not what I mean. I'm still mixing your PD controller with >>> something else above, sorry about that. Your PD controller driver >>> should not ideally even need to be aware of Type-C connector, right? >>> It definitely does not need to do any USB PD communication. >> >> >> Right. >> >>> I would imagine you have on top of the DP controller, a mux (which >>> could be a DP/USB3 PHY like on Rockchip RK3399, discrete mux like >>> Pericom PI3USB30532, or something else), and a USB Type-C PHY or USB >>> PD controller. The bus would be tying the mux to the Type-C port (PHY >>> or PD controller) and its partner (note that it does not tie the mux >>> to the DP controller). Please correct me if I'm wrong about your >>> hardware. >> >> >> No, you're correct, a discrete mux and a fusb302. >> >>> Assuming that is how your board roughly looks like, the driver for the >>> mux would be the driver for the DP altmode devices. That driver would >>> be the one converting things like the Attention messages notifying >>> about HPD into toggling of GPIOs, or what ever is needed on your >>> board, etc. >> >> >> OK. >> >>> The actual PD communication with VDMs should be considered as just the >>> protocol, so we probable should have "protocol drivers". For example >>> DP alternate mode VDMs and communication will always be the same >>> despite of the hardware. The DP alternate mode "protocol driver" would >>> then be tied to the alternate mode device for the partner, and that >>> driver could have its own hooks for what ever is needed, like HPD >>> signal handling, configuration changes, whatever. In any case, >>> hopefully making things easy and straightforward for the "mux driver", >>> _so that it does not need to care about the actual PD communication_. >> >> >> I'm digesting your and Guenter's replies and patches. >> I will try getting something up and running too soon and hopefully the >> foggy parts will >> dissolve. As for now I find it a lot easier to grok Guenter's drivers than >> to see the >> advantages and/or disadvantages of an altmode bus :-) >> >> @Guenter: There _is_ interest for your fusb302 driver, thank you >> > > Ok, I'll see what I need to do to publish it. > > 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 -- 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
