Re: [PATCH] usb: chipidea: fix ci_irq for role-switching use-case

[Philippe Schenker <philippe.schenker@toradex.com>]

On Wed, 2020-07-01 at 09:02 +0000, Peter Chen wrote:
> On 20-07-01 08:32:22, Philippe Schenker wrote:
> > On Wed, 2020-07-01 at 02:52 +0000, Peter Chen wrote:
> > > On 20-06-30 11:59:49, Philippe Schenker wrote:
> > > > On Tue, 2020-06-30 at 00:43 +0000, Peter Chen wrote:
> > > > > On 20-06-29 10:04:13, Philippe Schenker wrote:
> > > > > > On Mon, 2020-06-29 at 07:26 +0000, Peter Chen wrote:
> > > > > > > On 20-06-26 13:03:11, Philippe Schenker wrote:
> > > > > > > > If the hardware is in low-power-mode and one plugs in
> > > > > > > > device
> > > > > > > > or
> > > > > > > > host
> > > > > > > > it did not switch the mode due to the early exit out of
> > > > > > > > the
> > > > > > > > interrupt.
> > > > > > > 
> > > > > > > Do you mean there is no coming call for role-switch? Could
> > > > > > > you
> > > > > > > please
> > > > > > > share
> > > > > > > your dts changes? Try below patch:
> > > > > > 
> > > > > > Here are my DTS changes:
> > > > > > 
> > > > > > diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > > > b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > > > index 97601375f2640..c424f707a1afa 100644
> > > > > > --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > > > +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > > > @@ -13,6 +13,13 @@
> > > > > >                 stdout-path = "serial0:115200n8";
> > > > > >         };
> > > > > >  
> > > > > > +       extcon_usbc_det: usbc_det {
> > > > > > +               compatible = "linux,extcon-usb-gpio";
> > > > > > +               id-gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
> > > > > > +               pinctrl-names = "default";
> > > > > > +               pinctrl-0 = <&pinctrl_usbc_det>;
> > > > > > +       };
> > > > > > +
> > > > > >         /* fixed crystal dedicated to mpc258x */
> > > > > >         clk16m: clk16m {
> > > > > >                 compatible = "fixed-clock";
> > > > > > @@ -174,6 +181,7 @@
> > > > > >  };
> > > > > >  
> > > > > >  &usbotg1 {
> > > > > > +       extcon = <&extcon_usbc_det>, <&extcon_usbc_det>;
> > > > > 
> > > > > If you have only ID extcon, but no VBUS extcon, you only need
> > > > > to
> > > > > add only phandle, see dt-binding for detail please.
> > > > 
> > > > You where right again! Thanks, this actually solves the RNDIS
> > > > issue
> > > > for
> > > > our colibri-imx7 board:
> > > > 
> > > > +       extcon = <0>, <&extcon_usbc_det>;
> > > > 
> > > > Howevever on this iMX7 board we have VBUS hooked up to the SoC,
> > > > that's
> > > > why it works only with ID.
> > > > 
> > > > On Colibri-iMX6ULL we do not have VBUS hooked up.
> > > 
> > > So, there is no any events for connecting to Host? If it is, the
> > > workaround for this board is disable runtime pm. And you only need
> > > to
> > > write one extcon phandle for ID since you have external event for
> > > ID,
> > > but no event for VBUS. ID event is not the same with VBUS, for
> > > example,
> > > if you plug cable into host, you will not get the ID event, you
> > > could
> > > only get VBUS event if there is an event (eg, through GPIO) for
> > > it.
> > > 
> > > Peter
> > 
> > No we don't have extra Host events. We have one GPIO, if it is high
> > USB
> > should be in gadget mode and if the GPIO is low USB should be in
> > host
> > mode.
> > 
> > Is there no way we can achieve this on mainline without disabling
> > runtime PM?
> > 
> 
> At least I think so, since you don't have any events to let the
> SW know you connects to host if the controller is in low power mode.
> 
> Peter

okay, good to know. Thank you very much for your help! I will try now
with a dummy-gpio I guess that could be a nice workaround for the ULL.

Best Regards,
Philippe

> 
> > Philippe
> > 
> > > > So device/host
> > > > switching works only with 'extcon = <&extcon_usbc_det>,
> > > > <&extcon_usbc_det>;' but then RNDIS and also a normal thumb-
> > > > drive
> > > > does
> > > > not work. How could I work around this fact? A dummy-gpio that
> > > > would
> > > > always read "high" for vbus would be a solution for me.
> > > > 
> > > > Philippe
> > > >