[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLWE-8YkYmrKoP6-+2xherwsGZ8-CeUyOFe9YPQj6EuSpg@mail.gmail.com>
Date: Fri, 18 Oct 2019 12:53:33 -0700
From: John Stultz <john.stultz@...aro.org>
To: Hans de Goede <hdegoede@...hat.com>
Cc: lkml <linux-kernel@...r.kernel.org>, Yu Chen <chenyu56@...wei.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Chunfeng Yun <chunfeng.yun@...iatek.com>,
Felipe Balbi <balbi@...nel.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Jun Li <lijun.kernel@...il.com>,
Valentin Schneider <valentin.schneider@....com>,
Linux USB List <linux-usb@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>
Subject: Re: [RFC][PATCH 2/3] usb: roles: Add usb role switch notifier.
On Fri, Oct 18, 2019 at 12:30 PM Hans de Goede <hdegoede@...hat.com> wrote:
> Looking at drivers/usb/typec/tcpm/tcpci.c: tcpci_set_vconn I see that
> there is a data struct with vendor specific callbacks and that the
> drivers/usb/typec/tcpm/tcpci_rt1711h.c implements that.
>
> So you may want something similar here. But things are tricky here,
> because when nothing is connected you want to provide Vbus for
> the USB-A ports, which means that if someone then connects a
> USB-A to C cable to connect the board to a PC (switching the port
> to device mode) there will be a time when both sides are supplying
> 5V if I remember the schedule correctly.
Ok. Thanks for the pointer, I'll take a look at that to see if I can
get it to work.
> I think that the original hack might not be that bad, the whole hw
> design seems so, erm, broken, that you probably cannot do proper
> roleswapping anyways. So just tying Vbus to host mode might be
> fine, the question then becomes again how can some other piece
> of code listen to the role-switch events...
So, at least in the current approach (see the v3 series), I've
basically set the hub driver as an role-switch intermediary, sitting
between the calls from the tcpm to the dwc3 driver. It actually works
better then the earlier notifier method (which had some issues with
reliably establishing the initial state on boot). Does that approach
work for you?
thanks
-john
Powered by blists - more mailing lists