From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756966AbdDRSwi (ORCPT ); Tue, 18 Apr 2017 14:52:38 -0400 Received: from mail-it0-f49.google.com ([209.85.214.49]:33897 "EHLO mail-it0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757309AbdDRSwf (ORCPT ); Tue, 18 Apr 2017 14:52:35 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170221142405.76299-1-heikki.krogerus@linux.intel.com> <20170221142405.76299-3-heikki.krogerus@linux.intel.com> <4b4bbffc-db02-3b54-04bc-e7de79b2d9ed@roeck-us.net> <07618170-d561-e7fe-08e0-91316c53d832@gmail.com> <20170303125940.GA6999@kuha.fi.intel.com> <6ddb2eac-03d5-127e-df1e-ad189968e6b2@gmail.com> <20170306131442.GC6999@kuha.fi.intel.com> <696552a7-c36a-1d73-9517-543907e9da39@gmail.com> <20170308135853.GH6999@kuha.fi.intel.com> <68817c44-d880-581a-e9f5-12845b9215eb@gmail.com> From: Badhri Jagan Sridharan Date: Tue, 18 Apr 2017 11:52:33 -0700 Message-ID: Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class To: Guenter Roeck Cc: Mats Karrman , Heikki Krogerus , Greg KH , Felipe Balbi , Oliver Neukum , LKML , USB Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Heikki, I have a question regarding the preferred_role node. +What: /sys/class/typec//preferred_role +Date: March 2017 +Contact: Heikki Krogerus +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 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html