RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Guenter Roeck [mailto:groeck@xxxxxxxxxx]
> Sent: Monday, September 12, 2016 10:24 AM
> To: Jun Li <jun.li@xxxxxxx>
> Cc: Guenter Roeck <groeck@xxxxxxxxxxxx>; Felipe Balbi
> <felipe.balbi@xxxxxxxxxxxxxxx>; Chandra Sekhar Anagani
> <chandra.sekhar.anagani@xxxxxxxxx>; Bruce Ashfield
> <bruce.ashfield@xxxxxxxxxxxxx>; Bin Gao <bin.gao@xxxxxxxxx>; Pranav Tipnis
> <pranav.tipnis@xxxxxxxxx>; Heikki Krogerus
> <heikki.krogerus@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux-
> usb@xxxxxxxxxxxxxxx
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Sun, Sep 11, 2016 at 7:16 PM, Jun Li <jun.li@xxxxxxx> wrote:
> > Hi Guenter
> >
> >> -----Original Message-----
> >> From: Guenter Roeck [mailto:groeck@xxxxxxxxxx]
> >> Sent: Saturday, September 10, 2016 10:23 AM
> >> To: Jun Li <jun.li@xxxxxxx>
> >> Cc: Guenter Roeck <groeck@xxxxxxxxxxxx>; Felipe Balbi
> >> <felipe.balbi@xxxxxxxxxxxxxxx>; Chandra Sekhar Anagani
> >> <chandra.sekhar.anagani@xxxxxxxxx>; Bruce Ashfield
> >> <bruce.ashfield@xxxxxxxxxxxxx>; Bin Gao <bin.gao@xxxxxxxxx>; Pranav
> >> Tipnis <pranav.tipnis@xxxxxxxxx>; Heikki Krogerus
> >> <heikki.krogerus@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> >> linux- usb@xxxxxxxxxxxxxxx
> >> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li <jun.li@xxxxxxx> wrote:
> >> > Hi Guenter,
> >> >
> >> >> -----Original Message-----
> >> >> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-
> >> >> owner@xxxxxxxxxxxxxxx] On Behalf Of Guenter Roeck
> >> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> >> To: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
> >> >> Cc: Chandra Sekhar Anagani <chandra.sekhar.anagani@xxxxxxxxx>;
> >> >> Bruce Ashfield <bruce.ashfield@xxxxxxxxxxxxx>; Bin Gao
> >> >> <bin.gao@xxxxxxxxx>; Pranav Tipnis <pranav.tipnis@xxxxxxxxx>;
> >> >> Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>;
> >> >> linux-kernel@xxxxxxxxxxxxxxx;
> >> >> linux- usb@xxxxxxxxxxxxxxx; Guenter Roeck <groeck@xxxxxxxxxxxx>
> >> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> >> (tcpm)
> >> >>
> >> >> This driver implements the USB Type-C Power Delivery state machine
> >> >> for both source and sink ports. Alternate mode support is not
> >> >> fully implemented.
> >> >>
> >> >> The driver attaches to the USB Type-C class code implemented in
> >> >> the following patches.
> >> >>
> >> >>       usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C
> PHY
> >> >>       usb: USB Type-C connector class
> >> >>
> >> >> This driver only implements the state machine. Lower level drivers
> >> >> are responsible for
> >> >> - Reporting VBUS status and activating VBUS
> >> >> - Setting CC lines and providing CC line status
> >> >> - Setting line polarity
> >> >> - Activating and deactivating VCONN
> >> >> - Setting the current limit
> >> >> - Activating and deactivating PD message transfers
> >> >> - Sending and receiving PD messages
> >> >>
> >> >> The driver provides both a functional API as well as callbacks for
> >> >> lower level drivers.
> >> >>
> >> >> Signed-off-by: Guenter Roeck <groeck@xxxxxxxxxxxx>
> >> >> ---
> >> >
> >> > A specific question, if power sink wants to request a new power
> >> > level after SNK_READY, how to handle it with this tcpm?
> >> >
> >>
> >> So far I have considered the required power level to be static, based
> >> on our curent implementations. That should be easy to change, though,
> >> with an additional API function, to be called from a low level driver.
> >> Do you have that requirement, and would such a function meet your
> needs ?
> >>
> >
> > So you are going to make port->tcpc->config to be dynamic to meet my
> need?
> >
> What would that help ? How would tcpm get informed that the power
> requirements changed without an API function telling it that power
> requirements changed ?

Of cos I agree an additional API is required, I am just wondering how
that API will be look like, as current request build is according to
port->tcpc->config.

Li Jun	
> 
> Guenter
��.n��������+%������w��{.n�����{���)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux