Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Vivek Gautam]

On 01/20/2017 02:00 PM, Roger Quadros wrote:

Vivek,

On 19/01/17 17:15, vivek.gau...@codeaurora.org wrote:

Hi Roger,

On 2017-01-19 17:45, Roger Quadros wrote:

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:

Luckily hit this thread while checking about DRD role functionality for DWC3.


On 22/06/16 11:14, Felipe Balbi wrote:

Hi,

Roger Quadros  writes:

For the real use case, some Carplay platforms need it.

Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
specification which is not OTG-compliant.


Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

Okay, we have two scenarios here:

1. You need full OTG compliance

   For this, granted, you need the state machine if your HW doesn't
   track it. This is a given. With only one user, however, perhaps
   we don't need a generic layer. There are not enough different
   setups to design a good enough generic layer. We will end up
   with a pseudo-generic framework which is coupled with its only
   user.

2. Dual-role support, without OTG compliance

   In this case, you don't need a stack. All you need is a signal
   to tell you state of ID pin and another to tell you state of
   VBUS level. If you have those, you don't need to walk an OTG
   state machine at all. You don't need any of those quirky OTG
   timers, agreed?

   Given the above, why would you even want to use a subset of OTG
   state machine to implement something that's _usually_ as simple
   as:

8<--
   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
 id = read(ID_STATE); /* could be a gpio_get_value() */

 set_role(id);
 set_vbus(vbus);



In fact, the individual driver can do it by itself. The chipidea driver
handles OTG and dual-role well currently. By considering this OTG/DRD
framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the platforms which
has different drivers for host and peripheral to finish the role switch
well.

simplify how?  By adding unnecessary workqueues and a level indirection
that just goes back to the same driver?

What do you mean by same driver?

dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.


Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
be 3 totally independent drivers unlike dwc3 where you have a single
driver in control of both host and gadget.

That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good generic
layer.


Questions not clear to me are:

1) Which driver handles ID/VBUS events and makes a decision to do the
role swap?  Probably the PHY/MUX driver?

This is implementation dependent. For TI's USB subsystem, we have PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) to
switch between a separate XHCI or a separate dwc3. The same mux can be
put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
driver just detects role (at least for Type-C based plats) and executes
_DSM with correct arguments [1]. _DSM will program internal MUX, toggle
VBUS and, for type-C, toggle VCONN when needed.


2) How does it perform the role swap? Probably a register write to the
PHY/MUX without needing to stop/start controllers? Easy case is both
controllers can run in co-existence without interference. Is there any
platform other than dwc3 where this is not the case?

Again speculation. But to answer your question, only dwc3 is in such a
case today. But even for dwc3 we can have DRD with a much, much simpler
setup as I have already explained.


3) Even if host and gadget controllers can operate in coexistence,
there is no need for both to be running for embedded applications
which are usually power conservative.  How can we achieve that?

Now you're also speculating that you're running on embedded applications
and that we _can_ power off parts of the IP. I happen to know that we
can't power off XHCI part of dwc3 in 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Vivek Gautam]

On 01/20/2017 02:00 PM, Roger Quadros wrote:

Vivek,

On 19/01/17 17:15, vivek.gau...@codeaurora.org wrote:

Hi Roger,

On 2017-01-19 17:45, Roger Quadros wrote:

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:

Luckily hit this thread while checking about DRD role functionality for DWC3.


On 22/06/16 11:14, Felipe Balbi wrote:

Hi,

Roger Quadros  writes:

For the real use case, some Carplay platforms need it.

Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
specification which is not OTG-compliant.


Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

Okay, we have two scenarios here:

1. You need full OTG compliance

   For this, granted, you need the state machine if your HW doesn't
   track it. This is a given. With only one user, however, perhaps
   we don't need a generic layer. There are not enough different
   setups to design a good enough generic layer. We will end up
   with a pseudo-generic framework which is coupled with its only
   user.

2. Dual-role support, without OTG compliance

   In this case, you don't need a stack. All you need is a signal
   to tell you state of ID pin and another to tell you state of
   VBUS level. If you have those, you don't need to walk an OTG
   state machine at all. You don't need any of those quirky OTG
   timers, agreed?

   Given the above, why would you even want to use a subset of OTG
   state machine to implement something that's _usually_ as simple
   as:

8<--
   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
 id = read(ID_STATE); /* could be a gpio_get_value() */

 set_role(id);
 set_vbus(vbus);



In fact, the individual driver can do it by itself. The chipidea driver
handles OTG and dual-role well currently. By considering this OTG/DRD
framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the platforms which
has different drivers for host and peripheral to finish the role switch
well.

simplify how?  By adding unnecessary workqueues and a level indirection
that just goes back to the same driver?

What do you mean by same driver?

dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.


Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
be 3 totally independent drivers unlike dwc3 where you have a single
driver in control of both host and gadget.

That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good generic
layer.


Questions not clear to me are:

1) Which driver handles ID/VBUS events and makes a decision to do the
role swap?  Probably the PHY/MUX driver?

This is implementation dependent. For TI's USB subsystem, we have PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) to
switch between a separate XHCI or a separate dwc3. The same mux can be
put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
driver just detects role (at least for Type-C based plats) and executes
_DSM with correct arguments [1]. _DSM will program internal MUX, toggle
VBUS and, for type-C, toggle VCONN when needed.


2) How does it perform the role swap? Probably a register write to the
PHY/MUX without needing to stop/start controllers? Easy case is both
controllers can run in co-existence without interference. Is there any
platform other than dwc3 where this is not the case?

Again speculation. But to answer your question, only dwc3 is in such a
case today. But even for dwc3 we can have DRD with a much, much simpler
setup as I have already explained.


3) Even if host and gadget controllers can operate in coexistence,
there is no need for both to be running for embedded applications
which are usually power conservative.  How can we achieve that?

Now you're also speculating that you're running on embedded applications
and that we _can_ power off parts of the IP. I happen to know that we
can't power off XHCI part of dwc3 in TI's SoC because that's fed by 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Vivek,

On 19/01/17 17:15, vivek.gau...@codeaurora.org wrote:
> Hi Roger,
> 
> On 2017-01-19 17:45, Roger Quadros wrote:
>> Vivek,
>>
>> On 19/01/17 13:56, Vivek Gautam wrote:
>>> Hi,
>>>
>>>
>>> On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:
>>>
>>> Luckily hit this thread while checking about DRD role functionality for 
>>> DWC3.
>>>
 On 22/06/16 11:14, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros  writes:
>> For the real use case, some Carplay platforms need it.
>
> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
> closed
> specification which is not OTG-compliant.
>

 Yes, it is not OTG-compliant, but it can co-work with some 
 standard OTG FSM
 states to finish role swap.
>>>
>>> What are you referring to as "finish role swap"? I don't get that.
>>
>> Change current role from host to peripheral.
>
> Okay, we have two scenarios here:
>
> 1. You need full OTG compliance
>
>   For this, granted, you need the state machine if your HW doesn't
>   track it. This is a given. With only one user, however, perhaps
>   we don't need a generic layer. There are not enough different
>   setups to design a good enough generic layer. We will end up
>   with a pseudo-generic framework which is coupled with its only
>   user.
>
> 2. Dual-role support, without OTG compliance
>
>   In this case, you don't need a stack. All you need is a signal
>   to tell you state of ID pin and another to tell you state of
>   VBUS level. If you have those, you don't need to walk an OTG
>   state machine at all. You don't need any of those quirky OTG
>   timers, agreed?
>
>   Given the above, why would you even want to use a subset of OTG
>   state machine to implement something that's _usually_ as simple
>   as:
>
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
>
> set_role(id);
> set_vbus(vbus);
> 
>

 In fact, the individual driver can do it by itself. The chipidea driver
 handles OTG and dual-role well currently. By considering this OTG/DRD
 framework is worthwhile or not, we would like to see if it can
 simplify DRD design for each driver, and can benefit the platforms 
 which
 has different drivers for host and peripheral to finish the role switch
 well.
>>>
>>> simplify how?  By adding unnecessary workqueues and a level indirection
>>> that just goes back to the same driver?
>>
>> What do you mean by same driver?
>
> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
> layer jumps to a callback that goes back to dwc3 to e.g. start
> peripheral side.
>
> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>
>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>> be 3 totally independent drivers unlike dwc3 where you have a single
>> driver in control of both host and gadget.
>
> That's a totally different issue and one not being tackled by OTG
> layer, because there are no such users yet. We can't design anything
> based solely on speculation of what might happen.
>
> If there aren't enough users, there is no way to design a good generic
> layer.
>
>> Questions not clear to me are:
>>
>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>> role swap?  Probably the PHY/MUX driver?
>
> This is implementation dependent. For TI's USB subsystem, we have PMIC
> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
> has no intervention.
>
> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
> internal mux (much like TI's UTMI mailbox, but slightly different) to
> switch between a separate XHCI or a separate dwc3. The same mux can be
> put in HW-mode where SW has no intervention.
>
> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
> driver just detects role (at least for Type-C based plats) and executes
> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
> VBUS and, for type-C, toggle VCONN when needed.
>

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Vivek,

On 19/01/17 17:15, vivek.gau...@codeaurora.org wrote:
> Hi Roger,
> 
> On 2017-01-19 17:45, Roger Quadros wrote:
>> Vivek,
>>
>> On 19/01/17 13:56, Vivek Gautam wrote:
>>> Hi,
>>>
>>>
>>> On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:
>>>
>>> Luckily hit this thread while checking about DRD role functionality for 
>>> DWC3.
>>>
 On 22/06/16 11:14, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros  writes:
>> For the real use case, some Carplay platforms need it.
>
> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
> closed
> specification which is not OTG-compliant.
>

 Yes, it is not OTG-compliant, but it can co-work with some 
 standard OTG FSM
 states to finish role swap.
>>>
>>> What are you referring to as "finish role swap"? I don't get that.
>>
>> Change current role from host to peripheral.
>
> Okay, we have two scenarios here:
>
> 1. You need full OTG compliance
>
>   For this, granted, you need the state machine if your HW doesn't
>   track it. This is a given. With only one user, however, perhaps
>   we don't need a generic layer. There are not enough different
>   setups to design a good enough generic layer. We will end up
>   with a pseudo-generic framework which is coupled with its only
>   user.
>
> 2. Dual-role support, without OTG compliance
>
>   In this case, you don't need a stack. All you need is a signal
>   to tell you state of ID pin and another to tell you state of
>   VBUS level. If you have those, you don't need to walk an OTG
>   state machine at all. You don't need any of those quirky OTG
>   timers, agreed?
>
>   Given the above, why would you even want to use a subset of OTG
>   state machine to implement something that's _usually_ as simple
>   as:
>
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
>
> set_role(id);
> set_vbus(vbus);
> 
>

 In fact, the individual driver can do it by itself. The chipidea driver
 handles OTG and dual-role well currently. By considering this OTG/DRD
 framework is worthwhile or not, we would like to see if it can
 simplify DRD design for each driver, and can benefit the platforms 
 which
 has different drivers for host and peripheral to finish the role switch
 well.
>>>
>>> simplify how?  By adding unnecessary workqueues and a level indirection
>>> that just goes back to the same driver?
>>
>> What do you mean by same driver?
>
> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
> layer jumps to a callback that goes back to dwc3 to e.g. start
> peripheral side.
>
> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>
>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>> be 3 totally independent drivers unlike dwc3 where you have a single
>> driver in control of both host and gadget.
>
> That's a totally different issue and one not being tackled by OTG
> layer, because there are no such users yet. We can't design anything
> based solely on speculation of what might happen.
>
> If there aren't enough users, there is no way to design a good generic
> layer.
>
>> Questions not clear to me are:
>>
>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>> role swap?  Probably the PHY/MUX driver?
>
> This is implementation dependent. For TI's USB subsystem, we have PMIC
> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
> has no intervention.
>
> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
> internal mux (much like TI's UTMI mailbox, but slightly different) to
> switch between a separate XHCI or a separate dwc3. The same mux can be
> put in HW-mode where SW has no intervention.
>
> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
> driver just detects role (at least for Type-C based plats) and executes
> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
> VBUS and, for type-C, toggle VCONN when needed.
>
>> 2) How does it perform 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[vivek . gautam]

Hi Roger,

On 2017-01-19 17:45, Roger Quadros wrote:

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:

Luckily hit this thread while checking about DRD role functionality 
for DWC3.



On 22/06/16 11:14, Felipe Balbi wrote:


Hi,

Roger Quadros  writes:

For the real use case, some Carplay platforms need it.


Carplay does *NOT* rely on OTG. Apple has its own 
proprietary and closed

specification which is not OTG-compliant.



Yes, it is not OTG-compliant, but it can co-work with some 
standard OTG FSM

states to finish role swap.


What are you referring to as "finish role swap"? I don't get 
that.


Change current role from host to peripheral.


Okay, we have two scenarios here:

1. You need full OTG compliance

  For this, granted, you need the state machine if your HW 
doesn't
  track it. This is a given. With only one user, however, 
perhaps

  we don't need a generic layer. There are not enough different
  setups to design a good enough generic layer. We will end up
  with a pseudo-generic framework which is coupled with its only
  user.

2. Dual-role support, without OTG compliance

  In this case, you don't need a stack. All you need is a signal
  to tell you state of ID pin and another to tell you state of
  VBUS level. If you have those, you don't need to walk an OTG
  state machine at all. You don't need any of those quirky OTG
  timers, agreed?

  Given the above, why would you even want to use a subset of 
OTG
  state machine to implement something that's _usually_ as 
simple

  as:

8<--
  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
id = read(ID_STATE); /* could be a gpio_get_value() */

set_role(id);
set_vbus(vbus);




In fact, the individual driver can do it by itself. The chipidea 
driver
handles OTG and dual-role well currently. By considering this 
OTG/DRD

framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the 
platforms which
has different drivers for host and peripheral to finish the role 
switch

well.


simplify how?  By adding unnecessary workqueues and a level 
indirection

that just goes back to the same driver?


What do you mean by same driver?


dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and 
OTG

layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.

Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) 
can
be 3 totally independent drivers unlike dwc3 where you have a 
single

driver in control of both host and gadget.


That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good 
generic

layer.


Questions not clear to me are:

1) Which driver handles ID/VBUS events and makes a decision to do 
the

role swap?  Probably the PHY/MUX driver?


This is implementation dependent. For TI's USB subsystem, we have 
PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program 
UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where 
SW

has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) 
to
switch between a separate XHCI or a separate dwc3. The same mux can 
be

put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our 
PHY
driver just detects role (at least for Type-C based plats) and 
executes
_DSM with correct arguments [1]. _DSM will program internal MUX, 
toggle

VBUS and, for type-C, toggle VCONN when needed.

2) How does it perform the role swap? Probably a register write to 
the
PHY/MUX without needing to stop/start controllers? Easy case is 
both
controllers can run in co-existence without interference. Is there 
any

platform other than dwc3 where this is not the case?


Again speculation. But to answer your question, only dwc3 is in such 
a
case today. But even for dwc3 we can have DRD with a much, much 
simpler

setup as I have already explained.


3) Even if host and gadget controllers can operate in coexistence,
there is no need for both to be running for embedded applications
which are usually power conservative.  How can we achieve that?


Now you're also speculating that you're running on embedded 
applications
and that we _can_ power off parts of the IP. I happen to know that 
we
can't power off XHCI part of dwc3 in TI's SoC because that's fed by 
same

Clocks and power rails as the 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[vivek . gautam]

Hi Roger,

On 2017-01-19 17:45, Roger Quadros wrote:

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:

Luckily hit this thread while checking about DRD role functionality 
for DWC3.



On 22/06/16 11:14, Felipe Balbi wrote:


Hi,

Roger Quadros  writes:

For the real use case, some Carplay platforms need it.


Carplay does *NOT* rely on OTG. Apple has its own 
proprietary and closed

specification which is not OTG-compliant.



Yes, it is not OTG-compliant, but it can co-work with some 
standard OTG FSM

states to finish role swap.


What are you referring to as "finish role swap"? I don't get 
that.


Change current role from host to peripheral.


Okay, we have two scenarios here:

1. You need full OTG compliance

  For this, granted, you need the state machine if your HW 
doesn't
  track it. This is a given. With only one user, however, 
perhaps

  we don't need a generic layer. There are not enough different
  setups to design a good enough generic layer. We will end up
  with a pseudo-generic framework which is coupled with its only
  user.

2. Dual-role support, without OTG compliance

  In this case, you don't need a stack. All you need is a signal
  to tell you state of ID pin and another to tell you state of
  VBUS level. If you have those, you don't need to walk an OTG
  state machine at all. You don't need any of those quirky OTG
  timers, agreed?

  Given the above, why would you even want to use a subset of 
OTG
  state machine to implement something that's _usually_ as 
simple

  as:

8<--
  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
id = read(ID_STATE); /* could be a gpio_get_value() */

set_role(id);
set_vbus(vbus);




In fact, the individual driver can do it by itself. The chipidea 
driver
handles OTG and dual-role well currently. By considering this 
OTG/DRD

framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the 
platforms which
has different drivers for host and peripheral to finish the role 
switch

well.


simplify how?  By adding unnecessary workqueues and a level 
indirection

that just goes back to the same driver?


What do you mean by same driver?


dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and 
OTG

layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.

Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) 
can
be 3 totally independent drivers unlike dwc3 where you have a 
single

driver in control of both host and gadget.


That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good 
generic

layer.


Questions not clear to me are:

1) Which driver handles ID/VBUS events and makes a decision to do 
the

role swap?  Probably the PHY/MUX driver?


This is implementation dependent. For TI's USB subsystem, we have 
PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program 
UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where 
SW

has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) 
to
switch between a separate XHCI or a separate dwc3. The same mux can 
be

put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our 
PHY
driver just detects role (at least for Type-C based plats) and 
executes
_DSM with correct arguments [1]. _DSM will program internal MUX, 
toggle

VBUS and, for type-C, toggle VCONN when needed.

2) How does it perform the role swap? Probably a register write to 
the
PHY/MUX without needing to stop/start controllers? Easy case is 
both
controllers can run in co-existence without interference. Is there 
any

platform other than dwc3 where this is not the case?


Again speculation. But to answer your question, only dwc3 is in such 
a
case today. But even for dwc3 we can have DRD with a much, much 
simpler

setup as I have already explained.


3) Even if host and gadget controllers can operate in coexistence,
there is no need for both to be running for embedded applications
which are usually power conservative.  How can we achieve that?


Now you're also speculating that you're running on embedded 
applications
and that we _can_ power off parts of the IP. I happen to know that 
we
can't power off XHCI part of dwc3 in TI's SoC because that's fed by 
same

Clocks and power rails as the peripheral side.

[1] 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:
> Hi,
> 
> 
> On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:
> 
> Luckily hit this thread while checking about DRD role functionality for DWC3.
> 
>> On 22/06/16 11:14, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Roger Quadros  writes:
 For the real use case, some Carplay platforms need it.
>>>
>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
>>> closed
>>> specification which is not OTG-compliant.
>>>
>>
>> Yes, it is not OTG-compliant, but it can co-work with some standard 
>> OTG FSM
>> states to finish role swap.
>
> What are you referring to as "finish role swap"? I don't get that.

 Change current role from host to peripheral.
>>>
>>> Okay, we have two scenarios here:
>>>
>>> 1. You need full OTG compliance
>>>
>>>   For this, granted, you need the state machine if your HW doesn't
>>>   track it. This is a given. With only one user, however, perhaps
>>>   we don't need a generic layer. There are not enough different
>>>   setups to design a good enough generic layer. We will end up
>>>   with a pseudo-generic framework which is coupled with its only
>>>   user.
>>>
>>> 2. Dual-role support, without OTG compliance
>>>
>>>   In this case, you don't need a stack. All you need is a signal
>>>   to tell you state of ID pin and another to tell you state of
>>>   VBUS level. If you have those, you don't need to walk an OTG
>>>   state machine at all. You don't need any of those quirky OTG
>>>   timers, agreed?
>>>
>>>   Given the above, why would you even want to use a subset of OTG
>>>   state machine to implement something that's _usually_ as simple
>>>   as:
>>>
>>> 8<--
>>>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>>
>>> set_role(id);
>>> set_vbus(vbus);
>>> 
>>>
>>
>> In fact, the individual driver can do it by itself. The chipidea driver
>> handles OTG and dual-role well currently. By considering this OTG/DRD
>> framework is worthwhile or not, we would like to see if it can
>> simplify DRD design for each driver, and can benefit the platforms which
>> has different drivers for host and peripheral to finish the role switch
>> well.
>
> simplify how?  By adding unnecessary workqueues and a level indirection
> that just goes back to the same driver?

 What do you mean by same driver?
>>>
>>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>>> layer jumps to a callback that goes back to dwc3 to e.g. start
>>> peripheral side.
>>>
>>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>>
 Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
 be 3 totally independent drivers unlike dwc3 where you have a single
 driver in control of both host and gadget.
>>>
>>> That's a totally different issue and one not being tackled by OTG
>>> layer, because there are no such users yet. We can't design anything
>>> based solely on speculation of what might happen.
>>>
>>> If there aren't enough users, there is no way to design a good generic
>>> layer.
>>>
 Questions not clear to me are:

 1) Which driver handles ID/VBUS events and makes a decision to do the
 role swap?  Probably the PHY/MUX driver?
>>>
>>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>>> has no intervention.
>>>
>>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>>> switch between a separate XHCI or a separate dwc3. The same mux can be
>>> put in HW-mode where SW has no intervention.
>>>
>>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>>> driver just detects role (at least for Type-C based plats) and executes
>>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>>> VBUS and, for type-C, toggle VCONN when needed.
>>>
 2) How does it perform the role swap? Probably a register write to the
 PHY/MUX without needing to stop/start controllers? Easy case is both
 controllers can run in co-existence without interference. Is there any
 platform other than dwc3 where this is not the case?
>>>
>>> Again speculation. But to answer your question, only dwc3 is in 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:
> Hi,
> 
> 
> On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:
> 
> Luckily hit this thread while checking about DRD role functionality for DWC3.
> 
>> On 22/06/16 11:14, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Roger Quadros  writes:
 For the real use case, some Carplay platforms need it.
>>>
>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
>>> closed
>>> specification which is not OTG-compliant.
>>>
>>
>> Yes, it is not OTG-compliant, but it can co-work with some standard 
>> OTG FSM
>> states to finish role swap.
>
> What are you referring to as "finish role swap"? I don't get that.

 Change current role from host to peripheral.
>>>
>>> Okay, we have two scenarios here:
>>>
>>> 1. You need full OTG compliance
>>>
>>>   For this, granted, you need the state machine if your HW doesn't
>>>   track it. This is a given. With only one user, however, perhaps
>>>   we don't need a generic layer. There are not enough different
>>>   setups to design a good enough generic layer. We will end up
>>>   with a pseudo-generic framework which is coupled with its only
>>>   user.
>>>
>>> 2. Dual-role support, without OTG compliance
>>>
>>>   In this case, you don't need a stack. All you need is a signal
>>>   to tell you state of ID pin and another to tell you state of
>>>   VBUS level. If you have those, you don't need to walk an OTG
>>>   state machine at all. You don't need any of those quirky OTG
>>>   timers, agreed?
>>>
>>>   Given the above, why would you even want to use a subset of OTG
>>>   state machine to implement something that's _usually_ as simple
>>>   as:
>>>
>>> 8<--
>>>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>>
>>> set_role(id);
>>> set_vbus(vbus);
>>> 
>>>
>>
>> In fact, the individual driver can do it by itself. The chipidea driver
>> handles OTG and dual-role well currently. By considering this OTG/DRD
>> framework is worthwhile or not, we would like to see if it can
>> simplify DRD design for each driver, and can benefit the platforms which
>> has different drivers for host and peripheral to finish the role switch
>> well.
>
> simplify how?  By adding unnecessary workqueues and a level indirection
> that just goes back to the same driver?

 What do you mean by same driver?
>>>
>>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>>> layer jumps to a callback that goes back to dwc3 to e.g. start
>>> peripheral side.
>>>
>>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>>
 Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
 be 3 totally independent drivers unlike dwc3 where you have a single
 driver in control of both host and gadget.
>>>
>>> That's a totally different issue and one not being tackled by OTG
>>> layer, because there are no such users yet. We can't design anything
>>> based solely on speculation of what might happen.
>>>
>>> If there aren't enough users, there is no way to design a good generic
>>> layer.
>>>
 Questions not clear to me are:

 1) Which driver handles ID/VBUS events and makes a decision to do the
 role swap?  Probably the PHY/MUX driver?
>>>
>>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>>> has no intervention.
>>>
>>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>>> switch between a separate XHCI or a separate dwc3. The same mux can be
>>> put in HW-mode where SW has no intervention.
>>>
>>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>>> driver just detects role (at least for Type-C based plats) and executes
>>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>>> VBUS and, for type-C, toggle VCONN when needed.
>>>
 2) How does it perform the role swap? Probably a register write to the
 PHY/MUX without needing to stop/start controllers? Easy case is both
 controllers can run in co-existence without interference. Is there any
 platform other than dwc3 where this is not the case?
>>>
>>> Again speculation. But to answer your question, only dwc3 is in such a
>>> case today. But even 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Vivek Gautam]

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:

Luckily hit this thread while checking about DRD role functionality for DWC3.

> On 22/06/16 11:14, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros  writes:
>>> For the real use case, some Carplay platforms need it.
>>
>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
>> closed
>> specification which is not OTG-compliant.
>>
>
> Yes, it is not OTG-compliant, but it can co-work with some standard 
> OTG FSM
> states to finish role swap.

 What are you referring to as "finish role swap"? I don't get that.
>>>
>>> Change current role from host to peripheral.
>>
>> Okay, we have two scenarios here:
>>
>> 1. You need full OTG compliance
>>
>>   For this, granted, you need the state machine if your HW doesn't
>>   track it. This is a given. With only one user, however, perhaps
>>   we don't need a generic layer. There are not enough different
>>   setups to design a good enough generic layer. We will end up
>>   with a pseudo-generic framework which is coupled with its only
>>   user.
>>
>> 2. Dual-role support, without OTG compliance
>>
>>   In this case, you don't need a stack. All you need is a signal
>>   to tell you state of ID pin and another to tell you state of
>>   VBUS level. If you have those, you don't need to walk an OTG
>>   state machine at all. You don't need any of those quirky OTG
>>   timers, agreed?
>>
>>   Given the above, why would you even want to use a subset of OTG
>>   state machine to implement something that's _usually_ as simple
>>   as:
>>
>> 8<--
>>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>
>> set_role(id);
>> set_vbus(vbus);
>> 
>>
>
> In fact, the individual driver can do it by itself. The chipidea driver
> handles OTG and dual-role well currently. By considering this OTG/DRD
> framework is worthwhile or not, we would like to see if it can
> simplify DRD design for each driver, and can benefit the platforms which
> has different drivers for host and peripheral to finish the role switch
> well.

 simplify how?  By adding unnecessary workqueues and a level indirection
 that just goes back to the same driver?
>>>
>>> What do you mean by same driver?
>>
>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>> layer jumps to a callback that goes back to dwc3 to e.g. start
>> peripheral side.
>>
>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>
>>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>>> be 3 totally independent drivers unlike dwc3 where you have a single
>>> driver in control of both host and gadget.
>>
>> That's a totally different issue and one not being tackled by OTG
>> layer, because there are no such users yet. We can't design anything
>> based solely on speculation of what might happen.
>>
>> If there aren't enough users, there is no way to design a good generic
>> layer.
>>
>>> Questions not clear to me are:
>>>
>>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>>> role swap?  Probably the PHY/MUX driver?
>>
>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>> has no intervention.
>>
>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>> switch between a separate XHCI or a separate dwc3. The same mux can be
>> put in HW-mode where SW has no intervention.
>>
>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>> driver just detects role (at least for Type-C based plats) and executes
>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>> VBUS and, for type-C, toggle VCONN when needed.
>>
>>> 2) How does it perform the role swap? Probably a register write to the
>>> PHY/MUX without needing to stop/start controllers? Easy case is both
>>> controllers can run in co-existence without interference. Is there any
>>> platform other than dwc3 where this is not the case?
>>
>> Again speculation. But to answer your question, only dwc3 is in such a
>> case today. But even for dwc3 we can have DRD with a much, much simpler
>> setup as I have already explained.
>>
>>> 3) Even if host and gadget controllers can 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Vivek Gautam]

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:

Luckily hit this thread while checking about DRD role functionality for DWC3.

> On 22/06/16 11:14, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros  writes:
>>> For the real use case, some Carplay platforms need it.
>>
>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
>> closed
>> specification which is not OTG-compliant.
>>
>
> Yes, it is not OTG-compliant, but it can co-work with some standard 
> OTG FSM
> states to finish role swap.

 What are you referring to as "finish role swap"? I don't get that.
>>>
>>> Change current role from host to peripheral.
>>
>> Okay, we have two scenarios here:
>>
>> 1. You need full OTG compliance
>>
>>   For this, granted, you need the state machine if your HW doesn't
>>   track it. This is a given. With only one user, however, perhaps
>>   we don't need a generic layer. There are not enough different
>>   setups to design a good enough generic layer. We will end up
>>   with a pseudo-generic framework which is coupled with its only
>>   user.
>>
>> 2. Dual-role support, without OTG compliance
>>
>>   In this case, you don't need a stack. All you need is a signal
>>   to tell you state of ID pin and another to tell you state of
>>   VBUS level. If you have those, you don't need to walk an OTG
>>   state machine at all. You don't need any of those quirky OTG
>>   timers, agreed?
>>
>>   Given the above, why would you even want to use a subset of OTG
>>   state machine to implement something that's _usually_ as simple
>>   as:
>>
>> 8<--
>>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>
>> set_role(id);
>> set_vbus(vbus);
>> 
>>
>
> In fact, the individual driver can do it by itself. The chipidea driver
> handles OTG and dual-role well currently. By considering this OTG/DRD
> framework is worthwhile or not, we would like to see if it can
> simplify DRD design for each driver, and can benefit the platforms which
> has different drivers for host and peripheral to finish the role switch
> well.

 simplify how?  By adding unnecessary workqueues and a level indirection
 that just goes back to the same driver?
>>>
>>> What do you mean by same driver?
>>
>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>> layer jumps to a callback that goes back to dwc3 to e.g. start
>> peripheral side.
>>
>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>
>>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>>> be 3 totally independent drivers unlike dwc3 where you have a single
>>> driver in control of both host and gadget.
>>
>> That's a totally different issue and one not being tackled by OTG
>> layer, because there are no such users yet. We can't design anything
>> based solely on speculation of what might happen.
>>
>> If there aren't enough users, there is no way to design a good generic
>> layer.
>>
>>> Questions not clear to me are:
>>>
>>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>>> role swap?  Probably the PHY/MUX driver?
>>
>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>> has no intervention.
>>
>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>> switch between a separate XHCI or a separate dwc3. The same mux can be
>> put in HW-mode where SW has no intervention.
>>
>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>> driver just detects role (at least for Type-C based plats) and executes
>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>> VBUS and, for type-C, toggle VCONN when needed.
>>
>>> 2) How does it perform the role swap? Probably a register write to the
>>> PHY/MUX without needing to stop/start controllers? Easy case is both
>>> controllers can run in co-existence without interference. Is there any
>>> platform other than dwc3 where this is not the case?
>>
>> Again speculation. But to answer your question, only dwc3 is in such a
>> case today. But even for dwc3 we can have DRD with a much, much simpler
>> setup as I have already explained.
>>
>>> 3) Even if host and gadget controllers can operate in coexistence,
>>> 

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi Roger-san,

< snip >
>  commit 11c011a5e777c83819078a18672543f04482b3ec
>  Author: Srinivas Kandagatla 
>  Date:   Thu May 19 11:12:56 2016 +0100
> 
>  usb: echi-hcd: Add ehci_setup check before echi_shutdown
> 
> 
> 
>  In some cases, the USB code (gadget/hcd->start/stop) needs to be called
>  during the role swap. For example, if you have mux driver, you may
>  need to call usb_remove_hcd when ID from 0 to 1. Without Roger's 
>  framework,
>  how can we do that?
> >>>
> >>> You don't really need to remove the gadget. Just mask its interrupts and
> >>> ignore any calls to any gadget_driver ops, right? Likewise for
> >>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
> >>> the point of view of dwc3, it's simpler to unregister the platform
> >>> device we create for xhci-plat.c. I need no changes in XHCI to do that
> >>> and driver model will make sure to call xhci-plat's ->remove() which
> >>> will handle everything for me correctly.
> >>>
> >>
> >> I admit it can do in a IP driver, eg both host and peripheral for the
> >> single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
> >> or what else for HCD at mux driver?
> >
> > dwc3's OTG block has control of that, however, what I'll do is
> > platform_device_del() xhci-plat's device. Not one line changes inside
> > XHCI.
> >
> 
> Let's talk about how non dwc3 based platforms can get it done.
> 
> Yoshihiro-san, could you please share your platform requirements from 
> dual-role
> perspective?

My platform requirements about dual-role are:
- Initial settings of all host, gadget and OTG IP registers are needed before 
enters [AB]-device recognition procedure.
- In the recognition procedures, a software needs:
 - to check ID pin related register in OTG
 - to set OTG IP registers to change the role
  - and then host or gadget can start.
- In the disconnect detection procedures, a software needs similar 
checkings/settings with the recognition.

Best regards,
Yoshihiro Shimoda

> cheers,
> -roger

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi Roger-san,

< snip >
>  commit 11c011a5e777c83819078a18672543f04482b3ec
>  Author: Srinivas Kandagatla 
>  Date:   Thu May 19 11:12:56 2016 +0100
> 
>  usb: echi-hcd: Add ehci_setup check before echi_shutdown
> 
> 
> 
>  In some cases, the USB code (gadget/hcd->start/stop) needs to be called
>  during the role swap. For example, if you have mux driver, you may
>  need to call usb_remove_hcd when ID from 0 to 1. Without Roger's 
>  framework,
>  how can we do that?
> >>>
> >>> You don't really need to remove the gadget. Just mask its interrupts and
> >>> ignore any calls to any gadget_driver ops, right? Likewise for
> >>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
> >>> the point of view of dwc3, it's simpler to unregister the platform
> >>> device we create for xhci-plat.c. I need no changes in XHCI to do that
> >>> and driver model will make sure to call xhci-plat's ->remove() which
> >>> will handle everything for me correctly.
> >>>
> >>
> >> I admit it can do in a IP driver, eg both host and peripheral for the
> >> single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
> >> or what else for HCD at mux driver?
> >
> > dwc3's OTG block has control of that, however, what I'll do is
> > platform_device_del() xhci-plat's device. Not one line changes inside
> > XHCI.
> >
> 
> Let's talk about how non dwc3 based platforms can get it done.
> 
> Yoshihiro-san, could you please share your platform requirements from 
> dual-role
> perspective?

My platform requirements about dual-role are:
- Initial settings of all host, gadget and OTG IP registers are needed before 
enters [AB]-device recognition procedure.
- In the recognition procedures, a software needs:
 - to check ID pin related register in OTG
 - to set OTG IP registers to change the role
  - and then host or gadget can start.
- In the disconnect detection procedures, a software needs similar 
checkings/settings with the recognition.

Best regards,
Yoshihiro Shimoda

> cheers,
> -roger

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi,

> From: Peter Chen
> Sent: Wednesday, June 22, 2016 12:34 PM
> 
> On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Peter Chen  writes:
> > >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used 
> > >> >> >> >> >>> with OTG core.
> > >> >> >> >> >>
> > >> >> >> >> >> do you really know of any platform which has a separate OTG 
> > >> >> >> >> >> controller?
> > >> >> >> >> >>
> > >> >> >> >> >
> > >> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate 
> > >> >> >> >> > blocks for OTG, host
> > >> >> >> >> > and gadget.
> > >> >> >> >> >
> > >> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> > >> >> >> >>
> > >> >> >> >> that's not an OTG controller, it's just a mux. No different 
> > >> >> >> >> than Intel's
> > >> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> > >> >> >> >>
> > >> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into 
> > >> >> >> >> play. They
> > >> >> >> >> are two competing standards and, apparently, type-C is winning 
> > >> >> >> >> when it
> > >> >> >> >> comes to role-swapping.
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> > >> >> >> > dual-role,
> > >> >> >> > It will be considered as an OTG port.
> > >> >> >>
> > >> >> >> That's because "dual-role" is a non-standard OTG. Seen as people 
> > >> >> >> really
> > >> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
> > >> >> >> referring
> > >> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> > >> >> >
> > >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> > >> >> > "OTG" in Linux, right?
> > >> >>
> > >> >> to avoid confusion with the terminology, yes. With that settled, let's
> > >> >> figure out how you can deliver what your marketting guys are asking of
> > >> >> you.
> > >> >>
> > >> >
> > >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> > >> > test. The internal bsp has passed PET test, and formal compliance test
> > >> > is on the way (should pass too).
> > >> >
> > >> > The dual-role and OTG compliance use the same zImage, but different
> > >> > dtb.
> > >>
> > >> okay, that's good to know. Now, the question really is: considering we
> > >> only have one user for this generic OTG FSM layer, do we really need to
> > >> make it generic at all? I mean, just look at how invasive a change that
> > >> is.
> > >
> > > If the chipidea is the only user for this roger's framework, I don't
> > > think it is necessary. In fact, Roger introduces this framework, and
> > > the first user is dwc3, we think it can be used for others. Let's
> >
> > Right, we need to look at the history of dwc3 to figure out why the
> > conclusion that dwc3 needs this was made.
> >
> > Roger started working on this framework when Power on Reset section of
> > databook had some details which weren't always clear and, for safety, we
> > always had reset asserted for a really long time. It was so long (about
> > 400 ms) that resetting dwc3 for each role swap was just too much.
> >
> > Coupled with that, the OTG chapter wasn't very clear either on
> > expections from Host and Peripheral side initialization in OTG/DRD
> > systems.
> >
> > More recent version of dwc3 databook have a much better description of
> > how and which reset bits _must_ be asserted and which shouldn't be
> > touched unless it's for debugging purposes. When I implemented that, our
> > ->probe() went from 400ms down to about 50us.
> >
> > Coupled with that, the OTG chapter also became a lot clearer to the
> > point that it states you just don't initialize anything other than the
> > OTG block, and just wait for OTG interrupt to do whatever it is you need
> > to do.
> >
> > This meant that we could actually afford to do full reinitialization of
> > dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> > roles properly.
> >
> > (The reason for needing soft-reset during role swap is kinda long. But
> > in summary dwc3 shadows register writes to both host and peripheral
> > sides)
> >
> > > just discuss if it is necessary for dual-role switch.
> >
> > fair. However, if we have a single user we don't have a Generic
> > layer. There's not enough variance to come up with truly generic
> > architecture for this.
> >
> > --
> 
> I have put some points in my last reply [1], I summery it here to
> see if a generic framework is deserved or not?
> 
> 1. If there are some parts we can use during the role switch
> - The common start/stop host and peripheral operation
> eg, when switch from host to peripheral, all drivers can use
> usb_remove_hcd to finish it.
> - A common workqueue to handle vbus and id event
> - sysfs for role switch
> 
> 2. Does a mux driver can do it well? Yoshihiro, here we need your
> point. The main point is if we need to call USB API to change
> roles 

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi,

> From: Peter Chen
> Sent: Wednesday, June 22, 2016 12:34 PM
> 
> On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Peter Chen  writes:
> > >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used 
> > >> >> >> >> >>> with OTG core.
> > >> >> >> >> >>
> > >> >> >> >> >> do you really know of any platform which has a separate OTG 
> > >> >> >> >> >> controller?
> > >> >> >> >> >>
> > >> >> >> >> >
> > >> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate 
> > >> >> >> >> > blocks for OTG, host
> > >> >> >> >> > and gadget.
> > >> >> >> >> >
> > >> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> > >> >> >> >>
> > >> >> >> >> that's not an OTG controller, it's just a mux. No different 
> > >> >> >> >> than Intel's
> > >> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> > >> >> >> >>
> > >> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into 
> > >> >> >> >> play. They
> > >> >> >> >> are two competing standards and, apparently, type-C is winning 
> > >> >> >> >> when it
> > >> >> >> >> comes to role-swapping.
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> > >> >> >> > dual-role,
> > >> >> >> > It will be considered as an OTG port.
> > >> >> >>
> > >> >> >> That's because "dual-role" is a non-standard OTG. Seen as people 
> > >> >> >> really
> > >> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
> > >> >> >> referring
> > >> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> > >> >> >
> > >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> > >> >> > "OTG" in Linux, right?
> > >> >>
> > >> >> to avoid confusion with the terminology, yes. With that settled, let's
> > >> >> figure out how you can deliver what your marketting guys are asking of
> > >> >> you.
> > >> >>
> > >> >
> > >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> > >> > test. The internal bsp has passed PET test, and formal compliance test
> > >> > is on the way (should pass too).
> > >> >
> > >> > The dual-role and OTG compliance use the same zImage, but different
> > >> > dtb.
> > >>
> > >> okay, that's good to know. Now, the question really is: considering we
> > >> only have one user for this generic OTG FSM layer, do we really need to
> > >> make it generic at all? I mean, just look at how invasive a change that
> > >> is.
> > >
> > > If the chipidea is the only user for this roger's framework, I don't
> > > think it is necessary. In fact, Roger introduces this framework, and
> > > the first user is dwc3, we think it can be used for others. Let's
> >
> > Right, we need to look at the history of dwc3 to figure out why the
> > conclusion that dwc3 needs this was made.
> >
> > Roger started working on this framework when Power on Reset section of
> > databook had some details which weren't always clear and, for safety, we
> > always had reset asserted for a really long time. It was so long (about
> > 400 ms) that resetting dwc3 for each role swap was just too much.
> >
> > Coupled with that, the OTG chapter wasn't very clear either on
> > expections from Host and Peripheral side initialization in OTG/DRD
> > systems.
> >
> > More recent version of dwc3 databook have a much better description of
> > how and which reset bits _must_ be asserted and which shouldn't be
> > touched unless it's for debugging purposes. When I implemented that, our
> > ->probe() went from 400ms down to about 50us.
> >
> > Coupled with that, the OTG chapter also became a lot clearer to the
> > point that it states you just don't initialize anything other than the
> > OTG block, and just wait for OTG interrupt to do whatever it is you need
> > to do.
> >
> > This meant that we could actually afford to do full reinitialization of
> > dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> > roles properly.
> >
> > (The reason for needing soft-reset during role swap is kinda long. But
> > in summary dwc3 shadows register writes to both host and peripheral
> > sides)
> >
> > > just discuss if it is necessary for dual-role switch.
> >
> > fair. However, if we have a single user we don't have a Generic
> > layer. There's not enough variance to come up with truly generic
> > architecture for this.
> >
> > --
> 
> I have put some points in my last reply [1], I summery it here to
> see if a generic framework is deserved or not?
> 
> 1. If there are some parts we can use during the role switch
> - The common start/stop host and peripheral operation
> eg, when switch from host to peripheral, all drivers can use
> usb_remove_hcd to finish it.
> - A common workqueue to handle vbus and id event
> - sysfs for role switch
> 
> 2. Does a mux driver can do it well? Yoshihiro, here we need your
> point. The main point is if we need to call USB API to change
> roles (eg, usb_remove_hcd) 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

On 22/06/16 11:14, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> For the real use case, some Carplay platforms need it.
>
> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
> closed
> specification which is not OTG-compliant.
>

 Yes, it is not OTG-compliant, but it can co-work with some standard 
 OTG FSM
 states to finish role swap.
>>>
>>> What are you referring to as "finish role swap"? I don't get that.
>>
>> Change current role from host to peripheral.
>
> Okay, we have two scenarios here:
>
> 1. You need full OTG compliance
>
>   For this, granted, you need the state machine if your HW doesn't
>   track it. This is a given. With only one user, however, perhaps
>   we don't need a generic layer. There are not enough different
>   setups to design a good enough generic layer. We will end up
>   with a pseudo-generic framework which is coupled with its only
>   user.
>
> 2. Dual-role support, without OTG compliance
>
>   In this case, you don't need a stack. All you need is a signal
>   to tell you state of ID pin and another to tell you state of
>   VBUS level. If you have those, you don't need to walk an OTG
>   state machine at all. You don't need any of those quirky OTG
>   timers, agreed?
>
>   Given the above, why would you even want to use a subset of OTG
>   state machine to implement something that's _usually_ as simple
>   as:
>
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
>
> set_role(id);
> set_vbus(vbus);
> 
>

 In fact, the individual driver can do it by itself. The chipidea driver
 handles OTG and dual-role well currently. By considering this OTG/DRD
 framework is worthwhile or not, we would like to see if it can
 simplify DRD design for each driver, and can benefit the platforms which
 has different drivers for host and peripheral to finish the role switch
 well.
>>>
>>> simplify how?  By adding unnecessary workqueues and a level indirection
>>> that just goes back to the same driver?
>>
>> What do you mean by same driver?
> 
> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
> layer jumps to a callback that goes back to dwc3 to e.g. start
> peripheral side.
> 
> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
> 
>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>> be 3 totally independent drivers unlike dwc3 where you have a single
>> driver in control of both host and gadget.
> 
> That's a totally different issue and one not being tackled by OTG
> layer, because there are no such users yet. We can't design anything
> based solely on speculation of what might happen.
> 
> If there aren't enough users, there is no way to design a good generic
> layer.
> 
>> Questions not clear to me are:
>>
>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>> role swap?  Probably the PHY/MUX driver?
> 
> This is implementation dependent. For TI's USB subsystem, we have PMIC
> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
> has no intervention.
> 
> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
> internal mux (much like TI's UTMI mailbox, but slightly different) to
> switch between a separate XHCI or a separate dwc3. The same mux can be
> put in HW-mode where SW has no intervention.
> 
> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
> driver just detects role (at least for Type-C based plats) and executes
> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
> VBUS and, for type-C, toggle VCONN when needed.
> 
>> 2) How does it perform the role swap? Probably a register write to the
>> PHY/MUX without needing to stop/start controllers? Easy case is both
>> controllers can run in co-existence without interference. Is there any
>> platform other than dwc3 where this is not the case?
> 
> Again speculation. But to answer your question, only dwc3 is in such a
> case today. But even for dwc3 we can have DRD with a much, much simpler
> setup as I have already explained.
> 
>> 3) Even if host and gadget controllers can operate in coexistence,
>> there is no need for both to be running for embedded applications
>> which are usually power conservative.  How can we achieve that?
> 
> Now you're also speculating that you're running on embedded applications
> and that we 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

On 22/06/16 11:14, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> For the real use case, some Carplay platforms need it.
>
> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
> closed
> specification which is not OTG-compliant.
>

 Yes, it is not OTG-compliant, but it can co-work with some standard 
 OTG FSM
 states to finish role swap.
>>>
>>> What are you referring to as "finish role swap"? I don't get that.
>>
>> Change current role from host to peripheral.
>
> Okay, we have two scenarios here:
>
> 1. You need full OTG compliance
>
>   For this, granted, you need the state machine if your HW doesn't
>   track it. This is a given. With only one user, however, perhaps
>   we don't need a generic layer. There are not enough different
>   setups to design a good enough generic layer. We will end up
>   with a pseudo-generic framework which is coupled with its only
>   user.
>
> 2. Dual-role support, without OTG compliance
>
>   In this case, you don't need a stack. All you need is a signal
>   to tell you state of ID pin and another to tell you state of
>   VBUS level. If you have those, you don't need to walk an OTG
>   state machine at all. You don't need any of those quirky OTG
>   timers, agreed?
>
>   Given the above, why would you even want to use a subset of OTG
>   state machine to implement something that's _usually_ as simple
>   as:
>
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
>
> set_role(id);
> set_vbus(vbus);
> 
>

 In fact, the individual driver can do it by itself. The chipidea driver
 handles OTG and dual-role well currently. By considering this OTG/DRD
 framework is worthwhile or not, we would like to see if it can
 simplify DRD design for each driver, and can benefit the platforms which
 has different drivers for host and peripheral to finish the role switch
 well.
>>>
>>> simplify how?  By adding unnecessary workqueues and a level indirection
>>> that just goes back to the same driver?
>>
>> What do you mean by same driver?
> 
> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
> layer jumps to a callback that goes back to dwc3 to e.g. start
> peripheral side.
> 
> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
> 
>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>> be 3 totally independent drivers unlike dwc3 where you have a single
>> driver in control of both host and gadget.
> 
> That's a totally different issue and one not being tackled by OTG
> layer, because there are no such users yet. We can't design anything
> based solely on speculation of what might happen.
> 
> If there aren't enough users, there is no way to design a good generic
> layer.
> 
>> Questions not clear to me are:
>>
>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>> role swap?  Probably the PHY/MUX driver?
> 
> This is implementation dependent. For TI's USB subsystem, we have PMIC
> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
> has no intervention.
> 
> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
> internal mux (much like TI's UTMI mailbox, but slightly different) to
> switch between a separate XHCI or a separate dwc3. The same mux can be
> put in HW-mode where SW has no intervention.
> 
> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
> driver just detects role (at least for Type-C based plats) and executes
> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
> VBUS and, for type-C, toggle VCONN when needed.
> 
>> 2) How does it perform the role swap? Probably a register write to the
>> PHY/MUX without needing to stop/start controllers? Easy case is both
>> controllers can run in co-existence without interference. Is there any
>> platform other than dwc3 where this is not the case?
> 
> Again speculation. But to answer your question, only dwc3 is in such a
> case today. But even for dwc3 we can have DRD with a much, much simpler
> setup as I have already explained.
> 
>> 3) Even if host and gadget controllers can operate in coexistence,
>> there is no need for both to be running for embedded applications
>> which are usually power conservative.  How can we achieve that?
> 
> Now you're also speculating that you're running on embedded applications
> and that we _can_ power off 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> For the real use case, some Carplay platforms need it.

 Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
 closed
 specification which is not OTG-compliant.

>>>
>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
>>> FSM
>>> states to finish role swap.
>>
>> What are you referring to as "finish role swap"? I don't get that.
>
> Change current role from host to peripheral.

 Okay, we have two scenarios here:

 1. You need full OTG compliance

For this, granted, you need the state machine if your HW doesn't
track it. This is a given. With only one user, however, perhaps
we don't need a generic layer. There are not enough different
setups to design a good enough generic layer. We will end up
with a pseudo-generic framework which is coupled with its only
user.

 2. Dual-role support, without OTG compliance

In this case, you don't need a stack. All you need is a signal
to tell you state of ID pin and another to tell you state of
VBUS level. If you have those, you don't need to walk an OTG
state machine at all. You don't need any of those quirky OTG
timers, agreed?

Given the above, why would you even want to use a subset of OTG
state machine to implement something that's _usually_ as simple
as:

 8<--
vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
 id = read(ID_STATE); /* could be a gpio_get_value() */

 set_role(id);
 set_vbus(vbus);
 

>>>
>>> In fact, the individual driver can do it by itself. The chipidea driver
>>> handles OTG and dual-role well currently. By considering this OTG/DRD
>>> framework is worthwhile or not, we would like to see if it can
>>> simplify DRD design for each driver, and can benefit the platforms which
>>> has different drivers for host and peripheral to finish the role switch
>>> well.
>> 
>> simplify how?  By adding unnecessary workqueues and a level indirection
>> that just goes back to the same driver?
>
> What do you mean by same driver?

dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.

> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
> be 3 totally independent drivers unlike dwc3 where you have a single
> driver in control of both host and gadget.

That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good generic
layer.

> Questions not clear to me are:
>
> 1) Which driver handles ID/VBUS events and makes a decision to do the
> role swap?  Probably the PHY/MUX driver?

This is implementation dependent. For TI's USB subsystem, we have PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) to
switch between a separate XHCI or a separate dwc3. The same mux can be
put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
driver just detects role (at least for Type-C based plats) and executes
_DSM with correct arguments [1]. _DSM will program internal MUX, toggle
VBUS and, for type-C, toggle VCONN when needed.

> 2) How does it perform the role swap? Probably a register write to the
> PHY/MUX without needing to stop/start controllers? Easy case is both
> controllers can run in co-existence without interference. Is there any
> platform other than dwc3 where this is not the case?

Again speculation. But to answer your question, only dwc3 is in such a
case today. But even for dwc3 we can have DRD with a much, much simpler
setup as I have already explained.

> 3) Even if host and gadget controllers can operate in coexistence,
> there is no need for both to be running for embedded applications
> which are usually power conservative.  How can we achieve that?

Now you're also speculating that you're running on embedded applications
and that we _can_ power off parts of the IP. I happen to know that we
can't power off XHCI part of dwc3 in TI's SoC because that's fed by same
Clocks and power rails as the peripheral side.

[1] 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> For the real use case, some Carplay platforms need it.

 Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
 closed
 specification which is not OTG-compliant.

>>>
>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
>>> FSM
>>> states to finish role swap.
>>
>> What are you referring to as "finish role swap"? I don't get that.
>
> Change current role from host to peripheral.

 Okay, we have two scenarios here:

 1. You need full OTG compliance

For this, granted, you need the state machine if your HW doesn't
track it. This is a given. With only one user, however, perhaps
we don't need a generic layer. There are not enough different
setups to design a good enough generic layer. We will end up
with a pseudo-generic framework which is coupled with its only
user.

 2. Dual-role support, without OTG compliance

In this case, you don't need a stack. All you need is a signal
to tell you state of ID pin and another to tell you state of
VBUS level. If you have those, you don't need to walk an OTG
state machine at all. You don't need any of those quirky OTG
timers, agreed?

Given the above, why would you even want to use a subset of OTG
state machine to implement something that's _usually_ as simple
as:

 8<--
vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
 id = read(ID_STATE); /* could be a gpio_get_value() */

 set_role(id);
 set_vbus(vbus);
 

>>>
>>> In fact, the individual driver can do it by itself. The chipidea driver
>>> handles OTG and dual-role well currently. By considering this OTG/DRD
>>> framework is worthwhile or not, we would like to see if it can
>>> simplify DRD design for each driver, and can benefit the platforms which
>>> has different drivers for host and peripheral to finish the role switch
>>> well.
>> 
>> simplify how?  By adding unnecessary workqueues and a level indirection
>> that just goes back to the same driver?
>
> What do you mean by same driver?

dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.

> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
> be 3 totally independent drivers unlike dwc3 where you have a single
> driver in control of both host and gadget.

That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good generic
layer.

> Questions not clear to me are:
>
> 1) Which driver handles ID/VBUS events and makes a decision to do the
> role swap?  Probably the PHY/MUX driver?

This is implementation dependent. For TI's USB subsystem, we have PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) to
switch between a separate XHCI or a separate dwc3. The same mux can be
put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
driver just detects role (at least for Type-C based plats) and executes
_DSM with correct arguments [1]. _DSM will program internal MUX, toggle
VBUS and, for type-C, toggle VCONN when needed.

> 2) How does it perform the role swap? Probably a register write to the
> PHY/MUX without needing to stop/start controllers? Easy case is both
> controllers can run in co-existence without interference. Is there any
> platform other than dwc3 where this is not the case?

Again speculation. But to answer your question, only dwc3 is in such a
case today. But even for dwc3 we can have DRD with a much, much simpler
setup as I have already explained.

> 3) Even if host and gadget controllers can operate in coexistence,
> there is no need for both to be running for embedded applications
> which are usually power conservative.  How can we achieve that?

Now you're also speculating that you're running on embedded applications
and that we _can_ power off parts of the IP. I happen to know that we
can't power off XHCI part of dwc3 in TI's SoC because that's fed by same
Clocks and power rails as the peripheral side.

[1] 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> >> >> when they say OTG. Usually they just mean "a method for swapping 
>> >> >> >> between
>> >> >> >> host and peripheral roles, but we really don't want all the extra 
>> >> >> >> cost
>> >> >> >> of the OTG specification".
>> >> >> >> 
>> >> >> >
>> >> >> > That's what I thought before, but the request from the Marketing guy 
>> >> >> > is
>> >> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> >> >> > see the SoC reference manual say "it supports HNP and SRP"?
>> >> >> >
>> >> >> > If there is no request, who else wants to implement so complicated 
>> >> >> > FSM
>> >> >> > but seldom use cases, and go to pass OTG compliance test (tested by 
>> >> >> > PET).
>> >> >> 
>> >> >> I stand corrected :-)
>> >> >> 
>> >> >> So there is one user for this layer. And this user has its own role
>> >> >> control registers. I'm not convinced we need this large generic layer
>> >> >> for one user.
>> >> >> 
>> >> >
>> >> > You mean chipidea or dwc3? I have more comments below.
>> >> 
>> >> chipidea. From the point of OTG (or DRD) dwc3 is very
>> >> self-sufficient. HW itself tracks state machine, much like MUSB does.
>> >
>> > You mean HW can do state machine switch? If we are A device,
>> > - Does the hardware knows if B device is HNP enabled or not?
>> 
>> that's enabled through control message, keep a flag.
>> 
>> > - And if B device is HNP enabled, does it can switch itself from host
>> > to peripheral when the B device is disconnected (a_suspend->a_peripheral)
>> 
>> It cannot. It must rely on hnp polling which is, again, a control message.
>> 
>> > Does hardware can really follow Figure 7-1: OTG A-device with HNP State
>> > Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
>> > 2.0 Specification? And can pass PET test?
>> 
>> Seriously, what does this add to the conversation? It has already been
>> stated that there's nobody asking for OTG certification on dwc3. So all
>> of this is vaporware from the point of view of dwc3.
>
> This is just a technical question that I can't understand your words
> "HW itself tracks state machine"?

It's simple, really: HW knows that it starts in B_IDLE. All automatic
state changes, HW will do:

B_IDLE -> A_IDLE -> A_WAIT_VRISE -> A_WAIT_BCON -> A_HOST
B_IDLE -> B_WAIT_ACON -> B_PERIPHERAL

Some state changes need SW intervention, for those you need to kick the
correct event so HW makes the state change. But register will still tell
you correct state after HW switches to it.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> >> >> when they say OTG. Usually they just mean "a method for swapping 
>> >> >> >> between
>> >> >> >> host and peripheral roles, but we really don't want all the extra 
>> >> >> >> cost
>> >> >> >> of the OTG specification".
>> >> >> >> 
>> >> >> >
>> >> >> > That's what I thought before, but the request from the Marketing guy 
>> >> >> > is
>> >> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> >> >> > see the SoC reference manual say "it supports HNP and SRP"?
>> >> >> >
>> >> >> > If there is no request, who else wants to implement so complicated 
>> >> >> > FSM
>> >> >> > but seldom use cases, and go to pass OTG compliance test (tested by 
>> >> >> > PET).
>> >> >> 
>> >> >> I stand corrected :-)
>> >> >> 
>> >> >> So there is one user for this layer. And this user has its own role
>> >> >> control registers. I'm not convinced we need this large generic layer
>> >> >> for one user.
>> >> >> 
>> >> >
>> >> > You mean chipidea or dwc3? I have more comments below.
>> >> 
>> >> chipidea. From the point of OTG (or DRD) dwc3 is very
>> >> self-sufficient. HW itself tracks state machine, much like MUSB does.
>> >
>> > You mean HW can do state machine switch? If we are A device,
>> > - Does the hardware knows if B device is HNP enabled or not?
>> 
>> that's enabled through control message, keep a flag.
>> 
>> > - And if B device is HNP enabled, does it can switch itself from host
>> > to peripheral when the B device is disconnected (a_suspend->a_peripheral)
>> 
>> It cannot. It must rely on hnp polling which is, again, a control message.
>> 
>> > Does hardware can really follow Figure 7-1: OTG A-device with HNP State
>> > Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
>> > 2.0 Specification? And can pass PET test?
>> 
>> Seriously, what does this add to the conversation? It has already been
>> stated that there's nobody asking for OTG certification on dwc3. So all
>> of this is vaporware from the point of view of dwc3.
>
> This is just a technical question that I can't understand your words
> "HW itself tracks state machine"?

It's simple, really: HW knows that it starts in B_IDLE. All automatic
state changes, HW will do:

B_IDLE -> A_IDLE -> A_WAIT_VRISE -> A_WAIT_BCON -> A_HOST
B_IDLE -> B_WAIT_ACON -> B_PERIPHERAL

Some state changes need SW intervention, for those you need to kick the
correct event so HW makes the state change. But register will still tell
you correct state after HW switches to it.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not 
>> >> >> >> > mention
>> >> >> >> > "OTG" in Linux, right?
>> >> >> >> 
>> >> >> >> to avoid confusion with the terminology, yes. With that settled, 
>> >> >> >> let's
>> >> >> >> figure out how you can deliver what your marketting guys are asking 
>> >> >> >> of
>> >> >> >> you.
>> >> >> >> 
>> >> >> >
>> >> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
>> >> >> > test. The internal bsp has passed PET test, and formal compliance 
>> >> >> > test
>> >> >> > is on the way (should pass too). 
>> >> >> >
>> >> >> > The dual-role and OTG compliance use the same zImage, but different
>> >> >> > dtb.
>> >> >> 
>> >> >> okay, that's good to know. Now, the question really is: considering we
>> >> >> only have one user for this generic OTG FSM layer, do we really need to
>> >> >> make it generic at all? I mean, just look at how invasive a change that
>> >> >> is.
>> >> >
>> >> > If the chipidea is the only user for this roger's framework, I don't
>> >> > think it is necessary. In fact, Roger introduces this framework, and
>> >> > the first user is dwc3, we think it can be used for others. Let's
>> >> 
>> >> Right, we need to look at the history of dwc3 to figure out why the
>> >> conclusion that dwc3 needs this was made.
>> >> 
>> >> Roger started working on this framework when Power on Reset section of
>> >> databook had some details which weren't always clear and, for safety, we
>> >> always had reset asserted for a really long time. It was so long (about
>> >> 400 ms) that resetting dwc3 for each role swap was just too much.
>> >> 
>> >> Coupled with that, the OTG chapter wasn't very clear either on
>> >> expections from Host and Peripheral side initialization in OTG/DRD
>> >> systems.
>> >> 
>> >> More recent version of dwc3 databook have a much better description of
>> >> how and which reset bits _must_ be asserted and which shouldn't be
>> >> touched unless it's for debugging purposes. When I implemented that, our
>> >> ->probe() went from 400ms down to about 50us.
>> >> 
>> >> Coupled with that, the OTG chapter also became a lot clearer to the
>> >> point that it states you just don't initialize anything other than the
>> >> OTG block, and just wait for OTG interrupt to do whatever it is you need
>> >> to do.
>> >> 
>> >> This meant that we could actually afford to do full reinitialization of
>> >> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
>> >> roles properly.
>> >> 
>> >> (The reason for needing soft-reset during role swap is kinda long. But
>> >> in summary dwc3 shadows register writes to both host and peripheral
>> >> sides)
>> >> 
>> >> > just discuss if it is necessary for dual-role switch.
>> >> 
>> >> fair. However, if we have a single user we don't have a Generic
>> >> layer. There's not enough variance to come up with truly generic
>> >> architecture for this.
>> >> 
>> >> -- 
>> >
>> > I have put some points in my last reply [1], I summery it here to
>> > see if a generic framework is deserved or not?
>> >
>> > 1. If there are some parts we can use during the role switch
>> > - The common start/stop host and peripheral operation
>> > eg, when switch from host to peripheral, all drivers can use
>> > usb_remove_hcd to finish it.
>> 
>> a UDC such as dwc3 already implements start/stop for peripheral and
>> host. Why would go through and indirection layer that just comes back to
>> us? (well, dwc3's host side, start/stop translates to adding/removing
>> xhci-plat's device)
>> 
>> > - A common workqueue to handle vbus and id event
>> 
>> I already have a threaded IRQ handler. Why do I need a workqueue?
>> 
>
> I know it can be done in individual driver, don't you think
> we need a common part to manage the dual-role switch process,

A common part will be a requirement when we have at least 3 users for
it. Right now there's only one. So how can this be common at all?

> since dual-role switch is used more and more common, and
> there are so many switch methods:
>
> - ID pin
> - sysfs
> - type-c
> - OTG FSM
> - Registers
>
> Maybe Roger's framework is a little complicated, but if it is the
> correct direction, we can improve it.

IMO, we don't have enough users

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not 
>> >> >> >> > mention
>> >> >> >> > "OTG" in Linux, right?
>> >> >> >> 
>> >> >> >> to avoid confusion with the terminology, yes. With that settled, 
>> >> >> >> let's
>> >> >> >> figure out how you can deliver what your marketting guys are asking 
>> >> >> >> of
>> >> >> >> you.
>> >> >> >> 
>> >> >> >
>> >> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
>> >> >> > test. The internal bsp has passed PET test, and formal compliance 
>> >> >> > test
>> >> >> > is on the way (should pass too). 
>> >> >> >
>> >> >> > The dual-role and OTG compliance use the same zImage, but different
>> >> >> > dtb.
>> >> >> 
>> >> >> okay, that's good to know. Now, the question really is: considering we
>> >> >> only have one user for this generic OTG FSM layer, do we really need to
>> >> >> make it generic at all? I mean, just look at how invasive a change that
>> >> >> is.
>> >> >
>> >> > If the chipidea is the only user for this roger's framework, I don't
>> >> > think it is necessary. In fact, Roger introduces this framework, and
>> >> > the first user is dwc3, we think it can be used for others. Let's
>> >> 
>> >> Right, we need to look at the history of dwc3 to figure out why the
>> >> conclusion that dwc3 needs this was made.
>> >> 
>> >> Roger started working on this framework when Power on Reset section of
>> >> databook had some details which weren't always clear and, for safety, we
>> >> always had reset asserted for a really long time. It was so long (about
>> >> 400 ms) that resetting dwc3 for each role swap was just too much.
>> >> 
>> >> Coupled with that, the OTG chapter wasn't very clear either on
>> >> expections from Host and Peripheral side initialization in OTG/DRD
>> >> systems.
>> >> 
>> >> More recent version of dwc3 databook have a much better description of
>> >> how and which reset bits _must_ be asserted and which shouldn't be
>> >> touched unless it's for debugging purposes. When I implemented that, our
>> >> ->probe() went from 400ms down to about 50us.
>> >> 
>> >> Coupled with that, the OTG chapter also became a lot clearer to the
>> >> point that it states you just don't initialize anything other than the
>> >> OTG block, and just wait for OTG interrupt to do whatever it is you need
>> >> to do.
>> >> 
>> >> This meant that we could actually afford to do full reinitialization of
>> >> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
>> >> roles properly.
>> >> 
>> >> (The reason for needing soft-reset during role swap is kinda long. But
>> >> in summary dwc3 shadows register writes to both host and peripheral
>> >> sides)
>> >> 
>> >> > just discuss if it is necessary for dual-role switch.
>> >> 
>> >> fair. However, if we have a single user we don't have a Generic
>> >> layer. There's not enough variance to come up with truly generic
>> >> architecture for this.
>> >> 
>> >> -- 
>> >
>> > I have put some points in my last reply [1], I summery it here to
>> > see if a generic framework is deserved or not?
>> >
>> > 1. If there are some parts we can use during the role switch
>> > - The common start/stop host and peripheral operation
>> > eg, when switch from host to peripheral, all drivers can use
>> > usb_remove_hcd to finish it.
>> 
>> a UDC such as dwc3 already implements start/stop for peripheral and
>> host. Why would go through and indirection layer that just comes back to
>> us? (well, dwc3's host side, start/stop translates to adding/removing
>> xhci-plat's device)
>> 
>> > - A common workqueue to handle vbus and id event
>> 
>> I already have a threaded IRQ handler. Why do I need a workqueue?
>> 
>
> I know it can be done in individual driver, don't you think
> we need a common part to manage the dual-role switch process,

A common part will be a requirement when we have at least 3 users for
it. Right now there's only one. So how can this be common at all?

> since dual-role switch is used more and more common, and
> there are so many switch methods:
>
> - ID pin
> - sysfs
> - type-c
> - OTG FSM
> - Registers
>
> Maybe Roger's framework is a little complicated, but if it is the
> correct direction, we can improve it.

IMO, we don't have enough users

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Wed, Jun 22, 2016 at 09:56:22AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> Peter Chen  writes:
> >> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> >> >> when they say OTG. Usually they just mean "a method for swapping 
> >> >> >> between
> >> >> >> host and peripheral roles, but we really don't want all the extra 
> >> >> >> cost
> >> >> >> of the OTG specification".
> >> >> >> 
> >> >> >
> >> >> > That's what I thought before, but the request from the Marketing guy 
> >> >> > is
> >> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> >> >> > see the SoC reference manual say "it supports HNP and SRP"?
> >> >> >
> >> >> > If there is no request, who else wants to implement so complicated FSM
> >> >> > but seldom use cases, and go to pass OTG compliance test (tested by 
> >> >> > PET).
> >> >> 
> >> >> I stand corrected :-)
> >> >> 
> >> >> So there is one user for this layer. And this user has its own role
> >> >> control registers. I'm not convinced we need this large generic layer
> >> >> for one user.
> >> >> 
> >> >
> >> > You mean chipidea or dwc3? I have more comments below.
> >> 
> >> chipidea. From the point of OTG (or DRD) dwc3 is very
> >> self-sufficient. HW itself tracks state machine, much like MUSB does.
> >
> > You mean HW can do state machine switch? If we are A device,
> > - Does the hardware knows if B device is HNP enabled or not?
> 
> that's enabled through control message, keep a flag.
> 
> > - And if B device is HNP enabled, does it can switch itself from host
> > to peripheral when the B device is disconnected (a_suspend->a_peripheral)
> 
> It cannot. It must rely on hnp polling which is, again, a control message.
> 
> > Does hardware can really follow Figure 7-1: OTG A-device with HNP State
> > Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
> > 2.0 Specification? And can pass PET test?
> 
> Seriously, what does this add to the conversation? It has already been
> stated that there's nobody asking for OTG certification on dwc3. So all
> of this is vaporware from the point of view of dwc3.

This is just a technical question that I can't understand your words
"HW itself tracks state machine"?

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Wed, Jun 22, 2016 at 09:56:22AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> Peter Chen  writes:
> >> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> >> >> when they say OTG. Usually they just mean "a method for swapping 
> >> >> >> between
> >> >> >> host and peripheral roles, but we really don't want all the extra 
> >> >> >> cost
> >> >> >> of the OTG specification".
> >> >> >> 
> >> >> >
> >> >> > That's what I thought before, but the request from the Marketing guy 
> >> >> > is
> >> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> >> >> > see the SoC reference manual say "it supports HNP and SRP"?
> >> >> >
> >> >> > If there is no request, who else wants to implement so complicated FSM
> >> >> > but seldom use cases, and go to pass OTG compliance test (tested by 
> >> >> > PET).
> >> >> 
> >> >> I stand corrected :-)
> >> >> 
> >> >> So there is one user for this layer. And this user has its own role
> >> >> control registers. I'm not convinced we need this large generic layer
> >> >> for one user.
> >> >> 
> >> >
> >> > You mean chipidea or dwc3? I have more comments below.
> >> 
> >> chipidea. From the point of OTG (or DRD) dwc3 is very
> >> self-sufficient. HW itself tracks state machine, much like MUSB does.
> >
> > You mean HW can do state machine switch? If we are A device,
> > - Does the hardware knows if B device is HNP enabled or not?
> 
> that's enabled through control message, keep a flag.
> 
> > - And if B device is HNP enabled, does it can switch itself from host
> > to peripheral when the B device is disconnected (a_suspend->a_peripheral)
> 
> It cannot. It must rely on hnp polling which is, again, a control message.
> 
> > Does hardware can really follow Figure 7-1: OTG A-device with HNP State
> > Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
> > 2.0 Specification? And can pass PET test?
> 
> Seriously, what does this add to the conversation? It has already been
> stated that there's nobody asking for OTG certification on dwc3. So all
> of this is vaporware from the point of view of dwc3.

This is just a technical question that I can't understand your words
"HW itself tracks state machine"?

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Hi Felipe,

On 22/06/16 09:56, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
>>> Peter Chen  writes:
>>> So far, I haven't seen anybody talking about real USB OTG (the spec)
>>> when they say OTG. Usually they just mean "a method for swapping between
>>> host and peripheral roles, but we really don't want all the extra cost
>>> of the OTG specification".
>>>
>>
>> That's what I thought before, but the request from the Marketing guy is
>> "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> see the SoC reference manual say "it supports HNP and SRP"?
>>
>> If there is no request, who else wants to implement so complicated FSM
>> but seldom use cases, and go to pass OTG compliance test (tested by PET).
>
> I stand corrected :-)
>
> So there is one user for this layer. And this user has its own role
> control registers. I'm not convinced we need this large generic layer
> for one user.
>

 You mean chipidea or dwc3? I have more comments below.
>>>
>>> chipidea. From the point of OTG (or DRD) dwc3 is very
>>> self-sufficient. HW itself tracks state machine, much like MUSB does.
>>
>> You mean HW can do state machine switch? If we are A device,
>> - Does the hardware knows if B device is HNP enabled or not?
> 
> that's enabled through control message, keep a flag.
> 
>> - And if B device is HNP enabled, does it can switch itself from host
>> to peripheral when the B device is disconnected (a_suspend->a_peripheral)
> 
> It cannot. It must rely on hnp polling which is, again, a control message.
> 
>> Does hardware can really follow Figure 7-1: OTG A-device with HNP State
>> Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
>> 2.0 Specification? And can pass PET test?
> 
> Seriously, what does this add to the conversation? It has already been
> stated that there's nobody asking for OTG certification on dwc3. So all
> of this is vaporware from the point of view of dwc3.
> 
 For the real use case, some Carplay platforms need it.
>>>
>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>> specification which is not OTG-compliant.
>>>
>>
>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
>> FSM
>> states to finish role swap.
>
> What are you referring to as "finish role swap"? I don't get that.

 Change current role from host to peripheral.
>>>
>>> Okay, we have two scenarios here:
>>>
>>> 1. You need full OTG compliance
>>>
>>> For this, granted, you need the state machine if your HW doesn't
>>> track it. This is a given. With only one user, however, perhaps
>>> we don't need a generic layer. There are not enough different
>>> setups to design a good enough generic layer. We will end up
>>> with a pseudo-generic framework which is coupled with its only
>>> user.
>>>
>>> 2. Dual-role support, without OTG compliance
>>>
>>> In this case, you don't need a stack. All you need is a signal
>>> to tell you state of ID pin and another to tell you state of
>>> VBUS level. If you have those, you don't need to walk an OTG
>>> state machine at all. You don't need any of those quirky OTG
>>> timers, agreed?
>>>
>>> Given the above, why would you even want to use a subset of OTG
>>> state machine to implement something that's _usually_ as simple
>>> as:
>>>
>>> 8<--
>>> vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>>
>>> set_role(id);
>>> set_vbus(vbus);
>>> 
>>>
>>
>> In fact, the individual driver can do it by itself. The chipidea driver
>> handles OTG and dual-role well currently. By considering this OTG/DRD
>> framework is worthwhile or not, we would like to see if it can
>> simplify DRD design for each driver, and can benefit the platforms which
>> has different drivers for host and peripheral to finish the role switch
>> well.
> 
> simplify how?  By adding unnecessary workqueues and a level indirection
> that just goes back to the same driver?

What do you mean by same driver?
Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can be 3 
totally
independent drivers unlike dwc3 where you have a single driver in control of
both host and gadget.

Questions not clear to me are:
1) Which driver handles ID/VBUS events and makes a decision to do the role swap?
Probably the PHY/MUX driver?
2) How does it perform the role swap? Probably a register write to the PHY/MUX
without needing to stop/start controllers? Easy case is both controllers can
run in co-existence without interference. Is there any platform other than dwc3
where this is not the case?

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Hi Felipe,

On 22/06/16 09:56, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
>>> Peter Chen  writes:
>>> So far, I haven't seen anybody talking about real USB OTG (the spec)
>>> when they say OTG. Usually they just mean "a method for swapping between
>>> host and peripheral roles, but we really don't want all the extra cost
>>> of the OTG specification".
>>>
>>
>> That's what I thought before, but the request from the Marketing guy is
>> "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> see the SoC reference manual say "it supports HNP and SRP"?
>>
>> If there is no request, who else wants to implement so complicated FSM
>> but seldom use cases, and go to pass OTG compliance test (tested by PET).
>
> I stand corrected :-)
>
> So there is one user for this layer. And this user has its own role
> control registers. I'm not convinced we need this large generic layer
> for one user.
>

 You mean chipidea or dwc3? I have more comments below.
>>>
>>> chipidea. From the point of OTG (or DRD) dwc3 is very
>>> self-sufficient. HW itself tracks state machine, much like MUSB does.
>>
>> You mean HW can do state machine switch? If we are A device,
>> - Does the hardware knows if B device is HNP enabled or not?
> 
> that's enabled through control message, keep a flag.
> 
>> - And if B device is HNP enabled, does it can switch itself from host
>> to peripheral when the B device is disconnected (a_suspend->a_peripheral)
> 
> It cannot. It must rely on hnp polling which is, again, a control message.
> 
>> Does hardware can really follow Figure 7-1: OTG A-device with HNP State
>> Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
>> 2.0 Specification? And can pass PET test?
> 
> Seriously, what does this add to the conversation? It has already been
> stated that there's nobody asking for OTG certification on dwc3. So all
> of this is vaporware from the point of view of dwc3.
> 
 For the real use case, some Carplay platforms need it.
>>>
>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>> specification which is not OTG-compliant.
>>>
>>
>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
>> FSM
>> states to finish role swap.
>
> What are you referring to as "finish role swap"? I don't get that.

 Change current role from host to peripheral.
>>>
>>> Okay, we have two scenarios here:
>>>
>>> 1. You need full OTG compliance
>>>
>>> For this, granted, you need the state machine if your HW doesn't
>>> track it. This is a given. With only one user, however, perhaps
>>> we don't need a generic layer. There are not enough different
>>> setups to design a good enough generic layer. We will end up
>>> with a pseudo-generic framework which is coupled with its only
>>> user.
>>>
>>> 2. Dual-role support, without OTG compliance
>>>
>>> In this case, you don't need a stack. All you need is a signal
>>> to tell you state of ID pin and another to tell you state of
>>> VBUS level. If you have those, you don't need to walk an OTG
>>> state machine at all. You don't need any of those quirky OTG
>>> timers, agreed?
>>>
>>> Given the above, why would you even want to use a subset of OTG
>>> state machine to implement something that's _usually_ as simple
>>> as:
>>>
>>> 8<--
>>> vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>>
>>> set_role(id);
>>> set_vbus(vbus);
>>> 
>>>
>>
>> In fact, the individual driver can do it by itself. The chipidea driver
>> handles OTG and dual-role well currently. By considering this OTG/DRD
>> framework is worthwhile or not, we would like to see if it can
>> simplify DRD design for each driver, and can benefit the platforms which
>> has different drivers for host and peripheral to finish the role switch
>> well.
> 
> simplify how?  By adding unnecessary workqueues and a level indirection
> that just goes back to the same driver?

What do you mean by same driver?
Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can be 3 
totally
independent drivers unlike dwc3 where you have a single driver in control of
both host and gadget.

Questions not clear to me are:
1) Which driver handles ID/VBUS events and makes a decision to do the role swap?
Probably the PHY/MUX driver?
2) How does it perform the role swap? Probably a register write to the PHY/MUX
without needing to stop/start controllers? Easy case is both controllers can
run in co-existence without interference. Is there any platform other than dwc3
where this is not the case?
3) Even if host and gadget controllers can 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Wed, Jun 22, 2016 at 09:51:19AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not 
> >> >> >> > mention
> >> >> >> > "OTG" in Linux, right?
> >> >> >> 
> >> >> >> to avoid confusion with the terminology, yes. With that settled, 
> >> >> >> let's
> >> >> >> figure out how you can deliver what your marketting guys are asking 
> >> >> >> of
> >> >> >> you.
> >> >> >> 
> >> >> >
> >> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> >> >> > test. The internal bsp has passed PET test, and formal compliance test
> >> >> > is on the way (should pass too). 
> >> >> >
> >> >> > The dual-role and OTG compliance use the same zImage, but different
> >> >> > dtb.
> >> >> 
> >> >> okay, that's good to know. Now, the question really is: considering we
> >> >> only have one user for this generic OTG FSM layer, do we really need to
> >> >> make it generic at all? I mean, just look at how invasive a change that
> >> >> is.
> >> >
> >> > If the chipidea is the only user for this roger's framework, I don't
> >> > think it is necessary. In fact, Roger introduces this framework, and
> >> > the first user is dwc3, we think it can be used for others. Let's
> >> 
> >> Right, we need to look at the history of dwc3 to figure out why the
> >> conclusion that dwc3 needs this was made.
> >> 
> >> Roger started working on this framework when Power on Reset section of
> >> databook had some details which weren't always clear and, for safety, we
> >> always had reset asserted for a really long time. It was so long (about
> >> 400 ms) that resetting dwc3 for each role swap was just too much.
> >> 
> >> Coupled with that, the OTG chapter wasn't very clear either on
> >> expections from Host and Peripheral side initialization in OTG/DRD
> >> systems.
> >> 
> >> More recent version of dwc3 databook have a much better description of
> >> how and which reset bits _must_ be asserted and which shouldn't be
> >> touched unless it's for debugging purposes. When I implemented that, our
> >> ->probe() went from 400ms down to about 50us.
> >> 
> >> Coupled with that, the OTG chapter also became a lot clearer to the
> >> point that it states you just don't initialize anything other than the
> >> OTG block, and just wait for OTG interrupt to do whatever it is you need
> >> to do.
> >> 
> >> This meant that we could actually afford to do full reinitialization of
> >> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> >> roles properly.
> >> 
> >> (The reason for needing soft-reset during role swap is kinda long. But
> >> in summary dwc3 shadows register writes to both host and peripheral
> >> sides)
> >> 
> >> > just discuss if it is necessary for dual-role switch.
> >> 
> >> fair. However, if we have a single user we don't have a Generic
> >> layer. There's not enough variance to come up with truly generic
> >> architecture for this.
> >> 
> >> -- 
> >
> > I have put some points in my last reply [1], I summery it here to
> > see if a generic framework is deserved or not?
> >
> > 1. If there are some parts we can use during the role switch
> > - The common start/stop host and peripheral operation
> > eg, when switch from host to peripheral, all drivers can use
> > usb_remove_hcd to finish it.
> 
> a UDC such as dwc3 already implements start/stop for peripheral and
> host. Why would go through and indirection layer that just comes back to
> us? (well, dwc3's host side, start/stop translates to adding/removing
> xhci-plat's device)
> 
> > - A common workqueue to handle vbus and id event
> 
> I already have a threaded IRQ handler. Why do I need a workqueue?
> 

I know it can be done in individual driver, don't you think
we need a common part to manage the dual-role switch process,
since dual-role switch is used more and more common, and
there are so many switch methods:

- ID pin
- sysfs
- type-c
- OTG FSM
- Registers

Maybe Roger's framework is a little complicated, but if it is the
correct direction, we can improve it.
  
> > - sysfs for role switch
> 
> A generic sysfs is desirable, but I really don't know where to put it.
> Maybe it's enough to go down the hwmon route and just have an agreement
> of filename and contents to be written to.
> 
> -- 
> balbi



-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Wed, Jun 22, 2016 at 09:51:19AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not 
> >> >> >> > mention
> >> >> >> > "OTG" in Linux, right?
> >> >> >> 
> >> >> >> to avoid confusion with the terminology, yes. With that settled, 
> >> >> >> let's
> >> >> >> figure out how you can deliver what your marketting guys are asking 
> >> >> >> of
> >> >> >> you.
> >> >> >> 
> >> >> >
> >> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> >> >> > test. The internal bsp has passed PET test, and formal compliance test
> >> >> > is on the way (should pass too). 
> >> >> >
> >> >> > The dual-role and OTG compliance use the same zImage, but different
> >> >> > dtb.
> >> >> 
> >> >> okay, that's good to know. Now, the question really is: considering we
> >> >> only have one user for this generic OTG FSM layer, do we really need to
> >> >> make it generic at all? I mean, just look at how invasive a change that
> >> >> is.
> >> >
> >> > If the chipidea is the only user for this roger's framework, I don't
> >> > think it is necessary. In fact, Roger introduces this framework, and
> >> > the first user is dwc3, we think it can be used for others. Let's
> >> 
> >> Right, we need to look at the history of dwc3 to figure out why the
> >> conclusion that dwc3 needs this was made.
> >> 
> >> Roger started working on this framework when Power on Reset section of
> >> databook had some details which weren't always clear and, for safety, we
> >> always had reset asserted for a really long time. It was so long (about
> >> 400 ms) that resetting dwc3 for each role swap was just too much.
> >> 
> >> Coupled with that, the OTG chapter wasn't very clear either on
> >> expections from Host and Peripheral side initialization in OTG/DRD
> >> systems.
> >> 
> >> More recent version of dwc3 databook have a much better description of
> >> how and which reset bits _must_ be asserted and which shouldn't be
> >> touched unless it's for debugging purposes. When I implemented that, our
> >> ->probe() went from 400ms down to about 50us.
> >> 
> >> Coupled with that, the OTG chapter also became a lot clearer to the
> >> point that it states you just don't initialize anything other than the
> >> OTG block, and just wait for OTG interrupt to do whatever it is you need
> >> to do.
> >> 
> >> This meant that we could actually afford to do full reinitialization of
> >> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> >> roles properly.
> >> 
> >> (The reason for needing soft-reset during role swap is kinda long. But
> >> in summary dwc3 shadows register writes to both host and peripheral
> >> sides)
> >> 
> >> > just discuss if it is necessary for dual-role switch.
> >> 
> >> fair. However, if we have a single user we don't have a Generic
> >> layer. There's not enough variance to come up with truly generic
> >> architecture for this.
> >> 
> >> -- 
> >
> > I have put some points in my last reply [1], I summery it here to
> > see if a generic framework is deserved or not?
> >
> > 1. If there are some parts we can use during the role switch
> > - The common start/stop host and peripheral operation
> > eg, when switch from host to peripheral, all drivers can use
> > usb_remove_hcd to finish it.
> 
> a UDC such as dwc3 already implements start/stop for peripheral and
> host. Why would go through and indirection layer that just comes back to
> us? (well, dwc3's host side, start/stop translates to adding/removing
> xhci-plat's device)
> 
> > - A common workqueue to handle vbus and id event
> 
> I already have a threaded IRQ handler. Why do I need a workqueue?
> 

I know it can be done in individual driver, don't you think
we need a common part to manage the dual-role switch process,
since dual-role switch is used more and more common, and
there are so many switch methods:

- ID pin
- sysfs
- type-c
- OTG FSM
- Registers

Maybe Roger's framework is a little complicated, but if it is the
correct direction, we can improve it.
  
> > - sysfs for role switch
> 
> A generic sysfs is desirable, but I really don't know where to put it.
> Maybe it's enough to go down the hwmon route and just have an agreement
> of filename and contents to be written to.
> 
> -- 
> balbi



-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> Peter Chen  writes:
>> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> >> when they say OTG. Usually they just mean "a method for swapping 
>> >> >> between
>> >> >> host and peripheral roles, but we really don't want all the extra cost
>> >> >> of the OTG specification".
>> >> >> 
>> >> >
>> >> > That's what I thought before, but the request from the Marketing guy is
>> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> >> > see the SoC reference manual say "it supports HNP and SRP"?
>> >> >
>> >> > If there is no request, who else wants to implement so complicated FSM
>> >> > but seldom use cases, and go to pass OTG compliance test (tested by 
>> >> > PET).
>> >> 
>> >> I stand corrected :-)
>> >> 
>> >> So there is one user for this layer. And this user has its own role
>> >> control registers. I'm not convinced we need this large generic layer
>> >> for one user.
>> >> 
>> >
>> > You mean chipidea or dwc3? I have more comments below.
>> 
>> chipidea. From the point of OTG (or DRD) dwc3 is very
>> self-sufficient. HW itself tracks state machine, much like MUSB does.
>
> You mean HW can do state machine switch? If we are A device,
> - Does the hardware knows if B device is HNP enabled or not?

that's enabled through control message, keep a flag.

> - And if B device is HNP enabled, does it can switch itself from host
> to peripheral when the B device is disconnected (a_suspend->a_peripheral)

It cannot. It must rely on hnp polling which is, again, a control message.

> Does hardware can really follow Figure 7-1: OTG A-device with HNP State
> Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
> 2.0 Specification? And can pass PET test?

Seriously, what does this add to the conversation? It has already been
stated that there's nobody asking for OTG certification on dwc3. So all
of this is vaporware from the point of view of dwc3.

>> >> >> > For the real use case, some Carplay platforms need it.
>> >> >> 
>> >> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
>> >> >> closed
>> >> >> specification which is not OTG-compliant.
>> >> >> 
>> >> >
>> >> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
>> >> > FSM
>> >> > states to finish role swap.
>> >> 
>> >> What are you referring to as "finish role swap"? I don't get that.
>> >
>> > Change current role from host to peripheral.
>> 
>> Okay, we have two scenarios here:
>> 
>> 1. You need full OTG compliance
>> 
>>  For this, granted, you need the state machine if your HW doesn't
>>  track it. This is a given. With only one user, however, perhaps
>>  we don't need a generic layer. There are not enough different
>>  setups to design a good enough generic layer. We will end up
>>  with a pseudo-generic framework which is coupled with its only
>>  user.
>> 
>> 2. Dual-role support, without OTG compliance
>> 
>>  In this case, you don't need a stack. All you need is a signal
>>  to tell you state of ID pin and another to tell you state of
>>  VBUS level. If you have those, you don't need to walk an OTG
>>  state machine at all. You don't need any of those quirky OTG
>>  timers, agreed?
>> 
>>  Given the above, why would you even want to use a subset of OTG
>>  state machine to implement something that's _usually_ as simple
>>  as:
>> 
>> 8<--
>>  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>> 
>> set_role(id);
>> set_vbus(vbus);
>> 
>> 
>
> In fact, the individual driver can do it by itself. The chipidea driver
> handles OTG and dual-role well currently. By considering this OTG/DRD
> framework is worthwhile or not, we would like to see if it can
> simplify DRD design for each driver, and can benefit the platforms which
> has different drivers for host and peripheral to finish the role switch
> well.

simplify how?  By adding unnecessary workqueues and a level indirection
that just goes back to the same driver?

>> > commit 11c011a5e777c83819078a18672543f04482b3ec
>> > Author: Srinivas Kandagatla 
>> > Date:   Thu May 19 11:12:56 2016 +0100
>> >
>> > usb: echi-hcd: Add ehci_setup check before echi_shutdown
>> > 
>> >
>> >
>> > In some cases, the USB code (gadget/hcd->start/stop) needs to be called
>> > during the role swap. For example, if you have mux driver, you may
>> > need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
>> > how can we do that?
>> 
>> You don't really need to remove the gadget. Just mask its interrupts and
>> ignore any calls to any gadget_driver ops, right? Likewise for
>> XHCI. Just 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> Peter Chen  writes:
>> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> >> when they say OTG. Usually they just mean "a method for swapping 
>> >> >> between
>> >> >> host and peripheral roles, but we really don't want all the extra cost
>> >> >> of the OTG specification".
>> >> >> 
>> >> >
>> >> > That's what I thought before, but the request from the Marketing guy is
>> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> >> > see the SoC reference manual say "it supports HNP and SRP"?
>> >> >
>> >> > If there is no request, who else wants to implement so complicated FSM
>> >> > but seldom use cases, and go to pass OTG compliance test (tested by 
>> >> > PET).
>> >> 
>> >> I stand corrected :-)
>> >> 
>> >> So there is one user for this layer. And this user has its own role
>> >> control registers. I'm not convinced we need this large generic layer
>> >> for one user.
>> >> 
>> >
>> > You mean chipidea or dwc3? I have more comments below.
>> 
>> chipidea. From the point of OTG (or DRD) dwc3 is very
>> self-sufficient. HW itself tracks state machine, much like MUSB does.
>
> You mean HW can do state machine switch? If we are A device,
> - Does the hardware knows if B device is HNP enabled or not?

that's enabled through control message, keep a flag.

> - And if B device is HNP enabled, does it can switch itself from host
> to peripheral when the B device is disconnected (a_suspend->a_peripheral)

It cannot. It must rely on hnp polling which is, again, a control message.

> Does hardware can really follow Figure 7-1: OTG A-device with HNP State
> Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
> 2.0 Specification? And can pass PET test?

Seriously, what does this add to the conversation? It has already been
stated that there's nobody asking for OTG certification on dwc3. So all
of this is vaporware from the point of view of dwc3.

>> >> >> > For the real use case, some Carplay platforms need it.
>> >> >> 
>> >> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
>> >> >> closed
>> >> >> specification which is not OTG-compliant.
>> >> >> 
>> >> >
>> >> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
>> >> > FSM
>> >> > states to finish role swap.
>> >> 
>> >> What are you referring to as "finish role swap"? I don't get that.
>> >
>> > Change current role from host to peripheral.
>> 
>> Okay, we have two scenarios here:
>> 
>> 1. You need full OTG compliance
>> 
>>  For this, granted, you need the state machine if your HW doesn't
>>  track it. This is a given. With only one user, however, perhaps
>>  we don't need a generic layer. There are not enough different
>>  setups to design a good enough generic layer. We will end up
>>  with a pseudo-generic framework which is coupled with its only
>>  user.
>> 
>> 2. Dual-role support, without OTG compliance
>> 
>>  In this case, you don't need a stack. All you need is a signal
>>  to tell you state of ID pin and another to tell you state of
>>  VBUS level. If you have those, you don't need to walk an OTG
>>  state machine at all. You don't need any of those quirky OTG
>>  timers, agreed?
>> 
>>  Given the above, why would you even want to use a subset of OTG
>>  state machine to implement something that's _usually_ as simple
>>  as:
>> 
>> 8<--
>>  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>> 
>> set_role(id);
>> set_vbus(vbus);
>> 
>> 
>
> In fact, the individual driver can do it by itself. The chipidea driver
> handles OTG and dual-role well currently. By considering this OTG/DRD
> framework is worthwhile or not, we would like to see if it can
> simplify DRD design for each driver, and can benefit the platforms which
> has different drivers for host and peripheral to finish the role switch
> well.

simplify how?  By adding unnecessary workqueues and a level indirection
that just goes back to the same driver?

>> > commit 11c011a5e777c83819078a18672543f04482b3ec
>> > Author: Srinivas Kandagatla 
>> > Date:   Thu May 19 11:12:56 2016 +0100
>> >
>> > usb: echi-hcd: Add ehci_setup check before echi_shutdown
>> > 
>> >
>> >
>> > In some cases, the USB code (gadget/hcd->start/stop) needs to be called
>> > during the role swap. For example, if you have mux driver, you may
>> > need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
>> > how can we do that?
>> 
>> You don't really need to remove the gadget. Just mask its interrupts and
>> ignore any calls to any gadget_driver ops, right? Likewise for
>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
>> the point of view 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
>> >> >> > "OTG" in Linux, right?
>> >> >> 
>> >> >> to avoid confusion with the terminology, yes. With that settled, let's
>> >> >> figure out how you can deliver what your marketting guys are asking of
>> >> >> you.
>> >> >> 
>> >> >
>> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
>> >> > test. The internal bsp has passed PET test, and formal compliance test
>> >> > is on the way (should pass too). 
>> >> >
>> >> > The dual-role and OTG compliance use the same zImage, but different
>> >> > dtb.
>> >> 
>> >> okay, that's good to know. Now, the question really is: considering we
>> >> only have one user for this generic OTG FSM layer, do we really need to
>> >> make it generic at all? I mean, just look at how invasive a change that
>> >> is.
>> >
>> > If the chipidea is the only user for this roger's framework, I don't
>> > think it is necessary. In fact, Roger introduces this framework, and
>> > the first user is dwc3, we think it can be used for others. Let's
>> 
>> Right, we need to look at the history of dwc3 to figure out why the
>> conclusion that dwc3 needs this was made.
>> 
>> Roger started working on this framework when Power on Reset section of
>> databook had some details which weren't always clear and, for safety, we
>> always had reset asserted for a really long time. It was so long (about
>> 400 ms) that resetting dwc3 for each role swap was just too much.
>> 
>> Coupled with that, the OTG chapter wasn't very clear either on
>> expections from Host and Peripheral side initialization in OTG/DRD
>> systems.
>> 
>> More recent version of dwc3 databook have a much better description of
>> how and which reset bits _must_ be asserted and which shouldn't be
>> touched unless it's for debugging purposes. When I implemented that, our
>> ->probe() went from 400ms down to about 50us.
>> 
>> Coupled with that, the OTG chapter also became a lot clearer to the
>> point that it states you just don't initialize anything other than the
>> OTG block, and just wait for OTG interrupt to do whatever it is you need
>> to do.
>> 
>> This meant that we could actually afford to do full reinitialization of
>> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
>> roles properly.
>> 
>> (The reason for needing soft-reset during role swap is kinda long. But
>> in summary dwc3 shadows register writes to both host and peripheral
>> sides)
>> 
>> > just discuss if it is necessary for dual-role switch.
>> 
>> fair. However, if we have a single user we don't have a Generic
>> layer. There's not enough variance to come up with truly generic
>> architecture for this.
>> 
>> -- 
>
> I have put some points in my last reply [1], I summery it here to
> see if a generic framework is deserved or not?
>
> 1. If there are some parts we can use during the role switch
> - The common start/stop host and peripheral operation
> eg, when switch from host to peripheral, all drivers can use
> usb_remove_hcd to finish it.

a UDC such as dwc3 already implements start/stop for peripheral and
host. Why would go through and indirection layer that just comes back to
us? (well, dwc3's host side, start/stop translates to adding/removing
xhci-plat's device)

> - A common workqueue to handle vbus and id event

I already have a threaded IRQ handler. Why do I need a workqueue?

> - sysfs for role switch

A generic sysfs is desirable, but I really don't know where to put it.
Maybe it's enough to go down the hwmon route and just have an agreement
of filename and contents to be written to.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
>> >> >> > "OTG" in Linux, right?
>> >> >> 
>> >> >> to avoid confusion with the terminology, yes. With that settled, let's
>> >> >> figure out how you can deliver what your marketting guys are asking of
>> >> >> you.
>> >> >> 
>> >> >
>> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
>> >> > test. The internal bsp has passed PET test, and formal compliance test
>> >> > is on the way (should pass too). 
>> >> >
>> >> > The dual-role and OTG compliance use the same zImage, but different
>> >> > dtb.
>> >> 
>> >> okay, that's good to know. Now, the question really is: considering we
>> >> only have one user for this generic OTG FSM layer, do we really need to
>> >> make it generic at all? I mean, just look at how invasive a change that
>> >> is.
>> >
>> > If the chipidea is the only user for this roger's framework, I don't
>> > think it is necessary. In fact, Roger introduces this framework, and
>> > the first user is dwc3, we think it can be used for others. Let's
>> 
>> Right, we need to look at the history of dwc3 to figure out why the
>> conclusion that dwc3 needs this was made.
>> 
>> Roger started working on this framework when Power on Reset section of
>> databook had some details which weren't always clear and, for safety, we
>> always had reset asserted for a really long time. It was so long (about
>> 400 ms) that resetting dwc3 for each role swap was just too much.
>> 
>> Coupled with that, the OTG chapter wasn't very clear either on
>> expections from Host and Peripheral side initialization in OTG/DRD
>> systems.
>> 
>> More recent version of dwc3 databook have a much better description of
>> how and which reset bits _must_ be asserted and which shouldn't be
>> touched unless it's for debugging purposes. When I implemented that, our
>> ->probe() went from 400ms down to about 50us.
>> 
>> Coupled with that, the OTG chapter also became a lot clearer to the
>> point that it states you just don't initialize anything other than the
>> OTG block, and just wait for OTG interrupt to do whatever it is you need
>> to do.
>> 
>> This meant that we could actually afford to do full reinitialization of
>> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
>> roles properly.
>> 
>> (The reason for needing soft-reset during role swap is kinda long. But
>> in summary dwc3 shadows register writes to both host and peripheral
>> sides)
>> 
>> > just discuss if it is necessary for dual-role switch.
>> 
>> fair. However, if we have a single user we don't have a Generic
>> layer. There's not enough variance to come up with truly generic
>> architecture for this.
>> 
>> -- 
>
> I have put some points in my last reply [1], I summery it here to
> see if a generic framework is deserved or not?
>
> 1. If there are some parts we can use during the role switch
> - The common start/stop host and peripheral operation
> eg, when switch from host to peripheral, all drivers can use
> usb_remove_hcd to finish it.

a UDC such as dwc3 already implements start/stop for peripheral and
host. Why would go through and indirection layer that just comes back to
us? (well, dwc3's host side, start/stop translates to adding/removing
xhci-plat's device)

> - A common workqueue to handle vbus and id event

I already have a threaded IRQ handler. Why do I need a workqueue?

> - sysfs for role switch

A generic sysfs is desirable, but I really don't know where to put it.
Maybe it's enough to go down the hwmon route and just have an agreement
of filename and contents to be written to.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
> >> >> >> >> >>> OTG core.
> >> >> >> >> >> 
> >> >> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> >> >> controller?
> >> >> >> >> >> 
> >> >> >> >> >
> >> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
> >> >> >> >> > for OTG, host
> >> >> >> >> > and gadget.
> >> >> >> >> >
> >> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> >> >> 
> >> >> >> >> that's not an OTG controller, it's just a mux. No different than 
> >> >> >> >> Intel's
> >> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> >> >> 
> >> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into 
> >> >> >> >> play. They
> >> >> >> >> are two competing standards and, apparently, type-C is winning 
> >> >> >> >> when it
> >> >> >> >> comes to role-swapping.
> >> >> >> >> 
> >> >> >> >
> >> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> >> >> >> > dual-role,
> >> >> >> > It will be considered as an OTG port.
> >> >> >> 
> >> >> >> That's because "dual-role" is a non-standard OTG. Seen as people 
> >> >> >> really
> >> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
> >> >> >> referring
> >> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >> >> >
> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> >> >> > "OTG" in Linux, right?
> >> >> 
> >> >> to avoid confusion with the terminology, yes. With that settled, let's
> >> >> figure out how you can deliver what your marketting guys are asking of
> >> >> you.
> >> >> 
> >> >
> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> >> > test. The internal bsp has passed PET test, and formal compliance test
> >> > is on the way (should pass too). 
> >> >
> >> > The dual-role and OTG compliance use the same zImage, but different
> >> > dtb.
> >> 
> >> okay, that's good to know. Now, the question really is: considering we
> >> only have one user for this generic OTG FSM layer, do we really need to
> >> make it generic at all? I mean, just look at how invasive a change that
> >> is.
> >
> > If the chipidea is the only user for this roger's framework, I don't
> > think it is necessary. In fact, Roger introduces this framework, and
> > the first user is dwc3, we think it can be used for others. Let's
> 
> Right, we need to look at the history of dwc3 to figure out why the
> conclusion that dwc3 needs this was made.
> 
> Roger started working on this framework when Power on Reset section of
> databook had some details which weren't always clear and, for safety, we
> always had reset asserted for a really long time. It was so long (about
> 400 ms) that resetting dwc3 for each role swap was just too much.
> 
> Coupled with that, the OTG chapter wasn't very clear either on
> expections from Host and Peripheral side initialization in OTG/DRD
> systems.
> 
> More recent version of dwc3 databook have a much better description of
> how and which reset bits _must_ be asserted and which shouldn't be
> touched unless it's for debugging purposes. When I implemented that, our
> ->probe() went from 400ms down to about 50us.
> 
> Coupled with that, the OTG chapter also became a lot clearer to the
> point that it states you just don't initialize anything other than the
> OTG block, and just wait for OTG interrupt to do whatever it is you need
> to do.
> 
> This meant that we could actually afford to do full reinitialization of
> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> roles properly.
> 
> (The reason for needing soft-reset during role swap is kinda long. But
> in summary dwc3 shadows register writes to both host and peripheral
> sides)
> 
> > just discuss if it is necessary for dual-role switch.
> 
> fair. However, if we have a single user we don't have a Generic
> layer. There's not enough variance to come up with truly generic
> architecture for this.
> 
> -- 

I have put some points in my last reply [1], I summery it here to
see if a generic framework is deserved or not?

1. If there are some parts we can use during the role switch
- The common start/stop host and peripheral operation
eg, when switch from host to peripheral, all drivers can use
usb_remove_hcd to finish it.
- A common workqueue to handle vbus and id event
- sysfs for role switch

2. Does a mux driver can do it well? Yoshihiro, here we need your
point. The main point is if we need to call USB API to change
roles (eg, usb_remove_hcd) during the role switch, thanks.


[1] http://www.spinics.net/lists/linux-usb/msg142974.html
-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
> >> >> >> >> >>> OTG core.
> >> >> >> >> >> 
> >> >> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> >> >> controller?
> >> >> >> >> >> 
> >> >> >> >> >
> >> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
> >> >> >> >> > for OTG, host
> >> >> >> >> > and gadget.
> >> >> >> >> >
> >> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> >> >> 
> >> >> >> >> that's not an OTG controller, it's just a mux. No different than 
> >> >> >> >> Intel's
> >> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> >> >> 
> >> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into 
> >> >> >> >> play. They
> >> >> >> >> are two competing standards and, apparently, type-C is winning 
> >> >> >> >> when it
> >> >> >> >> comes to role-swapping.
> >> >> >> >> 
> >> >> >> >
> >> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> >> >> >> > dual-role,
> >> >> >> > It will be considered as an OTG port.
> >> >> >> 
> >> >> >> That's because "dual-role" is a non-standard OTG. Seen as people 
> >> >> >> really
> >> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
> >> >> >> referring
> >> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >> >> >
> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> >> >> > "OTG" in Linux, right?
> >> >> 
> >> >> to avoid confusion with the terminology, yes. With that settled, let's
> >> >> figure out how you can deliver what your marketting guys are asking of
> >> >> you.
> >> >> 
> >> >
> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> >> > test. The internal bsp has passed PET test, and formal compliance test
> >> > is on the way (should pass too). 
> >> >
> >> > The dual-role and OTG compliance use the same zImage, but different
> >> > dtb.
> >> 
> >> okay, that's good to know. Now, the question really is: considering we
> >> only have one user for this generic OTG FSM layer, do we really need to
> >> make it generic at all? I mean, just look at how invasive a change that
> >> is.
> >
> > If the chipidea is the only user for this roger's framework, I don't
> > think it is necessary. In fact, Roger introduces this framework, and
> > the first user is dwc3, we think it can be used for others. Let's
> 
> Right, we need to look at the history of dwc3 to figure out why the
> conclusion that dwc3 needs this was made.
> 
> Roger started working on this framework when Power on Reset section of
> databook had some details which weren't always clear and, for safety, we
> always had reset asserted for a really long time. It was so long (about
> 400 ms) that resetting dwc3 for each role swap was just too much.
> 
> Coupled with that, the OTG chapter wasn't very clear either on
> expections from Host and Peripheral side initialization in OTG/DRD
> systems.
> 
> More recent version of dwc3 databook have a much better description of
> how and which reset bits _must_ be asserted and which shouldn't be
> touched unless it's for debugging purposes. When I implemented that, our
> ->probe() went from 400ms down to about 50us.
> 
> Coupled with that, the OTG chapter also became a lot clearer to the
> point that it states you just don't initialize anything other than the
> OTG block, and just wait for OTG interrupt to do whatever it is you need
> to do.
> 
> This meant that we could actually afford to do full reinitialization of
> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
> roles properly.
> 
> (The reason for needing soft-reset during role swap is kinda long. But
> in summary dwc3 shadows register writes to both host and peripheral
> sides)
> 
> > just discuss if it is necessary for dual-role switch.
> 
> fair. However, if we have a single user we don't have a Generic
> layer. There's not enough variance to come up with truly generic
> architecture for this.
> 
> -- 

I have put some points in my last reply [1], I summery it here to
see if a generic framework is deserved or not?

1. If there are some parts we can use during the role switch
- The common start/stop host and peripheral operation
eg, when switch from host to peripheral, all drivers can use
usb_remove_hcd to finish it.
- A common workqueue to handle vbus and id event
- sysfs for role switch

2. Does a mux driver can do it well? Yoshihiro, here we need your
point. The main point is if we need to call USB API to change
roles (eg, usb_remove_hcd) during the role switch, thanks.


[1] http://www.spinics.net/lists/linux-usb/msg142974.html
-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 01:02:59PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> >> when they say OTG. Usually they just mean "a method for swapping between
> >> >> host and peripheral roles, but we really don't want all the extra cost
> >> >> of the OTG specification".
> >> >> 
> >> >
> >> > That's what I thought before, but the request from the Marketing guy is
> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> >> > see the SoC reference manual say "it supports HNP and SRP"?
> >> >
> >> > If there is no request, who else wants to implement so complicated FSM
> >> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> >> 
> >> I stand corrected :-)
> >> 
> >> So there is one user for this layer. And this user has its own role
> >> control registers. I'm not convinced we need this large generic layer
> >> for one user.
> >> 
> >
> > You mean chipidea or dwc3? I have more comments below.
> 
> chipidea. From the point of OTG (or DRD) dwc3 is very
> self-sufficient. HW itself tracks state machine, much like MUSB does.

You mean HW can do state machine switch? If we are A device,
- Does the hardware knows if B device is HNP enabled or not?
- And if B device is HNP enabled, does it can switch itself from host
to peripheral when the B device is disconnected (a_suspend->a_peripheral)

Does hardware can really follow Figure 7-1: OTG A-device with HNP State
Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification? And can pass PET test?

> 
> >> >> > For the real use case, some Carplay platforms need it.
> >> >> 
> >> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> >> >> specification which is not OTG-compliant.
> >> >> 
> >> >
> >> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
> >> > FSM
> >> > states to finish role swap.
> >> 
> >> What are you referring to as "finish role swap"? I don't get that.
> >
> > Change current role from host to peripheral.
> 
> Okay, we have two scenarios here:
> 
> 1. You need full OTG compliance
> 
>   For this, granted, you need the state machine if your HW doesn't
>   track it. This is a given. With only one user, however, perhaps
>   we don't need a generic layer. There are not enough different
>   setups to design a good enough generic layer. We will end up
>   with a pseudo-generic framework which is coupled with its only
>   user.
> 
> 2. Dual-role support, without OTG compliance
> 
>   In this case, you don't need a stack. All you need is a signal
>   to tell you state of ID pin and another to tell you state of
>   VBUS level. If you have those, you don't need to walk an OTG
>   state machine at all. You don't need any of those quirky OTG
>   timers, agreed?
> 
>   Given the above, why would you even want to use a subset of OTG
>   state machine to implement something that's _usually_ as simple
>   as:
> 
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
> 
> set_role(id);
> set_vbus(vbus);
> 
> 

In fact, the individual driver can do it by itself. The chipidea driver
handles OTG and dual-role well currently. By considering this OTG/DRD
framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the platforms which
has different drivers for host and peripheral to finish the role switch
well.

- The common start/stop host and peripheral operation
eg, when switch from host to peripheral, all drivers can use
usb_remove_hcd to finish it.
- A common workqueue to handle vbus and id event
- sysfs for role switch

> >> > Notice, it needs to swap role without disconnect cable.
> >> 
> >> right, I can swap role without changing cable, but that's not OTG. The
> >> mechanism for that, AFAICT, is not HNP. I don't know details about
> >> CarPlay because the spec isn't public, but my understanding is that
> >> CarPlay doesn't rely on anything from OTG spec.
> >
> > Since it is non-public, I can't say much. Some flows of its role-swap
> > refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> > Specification. 
> >
> > But OTG FSM is not the only way, the platform which can do role-swap
> > without disconnection can support it too.
> 
> Right, all you need for CarPlay is what I wrote above. You don't need
> full OTG compliance for that, right?
> 

OTG FSM is not necessary, other dual-role switch also can satisfy its
requirement.

> >> 
> >> > Consider the use case the host driver is at host/ and udc driver is
> >> > at gadget/udc, how to finish to role swap?
> >> 
> >> 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 01:02:59PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> >> when they say OTG. Usually they just mean "a method for swapping between
> >> >> host and peripheral roles, but we really don't want all the extra cost
> >> >> of the OTG specification".
> >> >> 
> >> >
> >> > That's what I thought before, but the request from the Marketing guy is
> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> >> > see the SoC reference manual say "it supports HNP and SRP"?
> >> >
> >> > If there is no request, who else wants to implement so complicated FSM
> >> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> >> 
> >> I stand corrected :-)
> >> 
> >> So there is one user for this layer. And this user has its own role
> >> control registers. I'm not convinced we need this large generic layer
> >> for one user.
> >> 
> >
> > You mean chipidea or dwc3? I have more comments below.
> 
> chipidea. From the point of OTG (or DRD) dwc3 is very
> self-sufficient. HW itself tracks state machine, much like MUSB does.

You mean HW can do state machine switch? If we are A device,
- Does the hardware knows if B device is HNP enabled or not?
- And if B device is HNP enabled, does it can switch itself from host
to peripheral when the B device is disconnected (a_suspend->a_peripheral)

Does hardware can really follow Figure 7-1: OTG A-device with HNP State
Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification? And can pass PET test?

> 
> >> >> > For the real use case, some Carplay platforms need it.
> >> >> 
> >> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> >> >> specification which is not OTG-compliant.
> >> >> 
> >> >
> >> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG 
> >> > FSM
> >> > states to finish role swap.
> >> 
> >> What are you referring to as "finish role swap"? I don't get that.
> >
> > Change current role from host to peripheral.
> 
> Okay, we have two scenarios here:
> 
> 1. You need full OTG compliance
> 
>   For this, granted, you need the state machine if your HW doesn't
>   track it. This is a given. With only one user, however, perhaps
>   we don't need a generic layer. There are not enough different
>   setups to design a good enough generic layer. We will end up
>   with a pseudo-generic framework which is coupled with its only
>   user.
> 
> 2. Dual-role support, without OTG compliance
> 
>   In this case, you don't need a stack. All you need is a signal
>   to tell you state of ID pin and another to tell you state of
>   VBUS level. If you have those, you don't need to walk an OTG
>   state machine at all. You don't need any of those quirky OTG
>   timers, agreed?
> 
>   Given the above, why would you even want to use a subset of OTG
>   state machine to implement something that's _usually_ as simple
>   as:
> 
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
> 
> set_role(id);
> set_vbus(vbus);
> 
> 

In fact, the individual driver can do it by itself. The chipidea driver
handles OTG and dual-role well currently. By considering this OTG/DRD
framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the platforms which
has different drivers for host and peripheral to finish the role switch
well.

- The common start/stop host and peripheral operation
eg, when switch from host to peripheral, all drivers can use
usb_remove_hcd to finish it.
- A common workqueue to handle vbus and id event
- sysfs for role switch

> >> > Notice, it needs to swap role without disconnect cable.
> >> 
> >> right, I can swap role without changing cable, but that's not OTG. The
> >> mechanism for that, AFAICT, is not HNP. I don't know details about
> >> CarPlay because the spec isn't public, but my understanding is that
> >> CarPlay doesn't rely on anything from OTG spec.
> >
> > Since it is non-public, I can't say much. Some flows of its role-swap
> > refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> > Specification. 
> >
> > But OTG FSM is not the only way, the platform which can do role-swap
> > without disconnection can support it too.
> 
> Right, all you need for CarPlay is what I wrote above. You don't need
> full OTG compliance for that, right?
> 

OTG FSM is not necessary, other dual-role switch also can satisfy its
requirement.

> >> 
> >> > Consider the use case the host driver is at host/ and udc driver is
> >> > at gadget/udc, how to finish to role swap?
> >> 
> >> ... why does the 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
>> >> >> >> >>> OTG core.
>> >> >> >> >> 
>> >> >> >> >> do you really know of any platform which has a separate OTG 
>> >> >> >> >> controller?
>> >> >> >> >> 
>> >> >> >> >
>> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
>> >> >> >> > for OTG, host
>> >> >> >> > and gadget.
>> >> >> >> >
>> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> >> >> >> 
>> >> >> >> that's not an OTG controller, it's just a mux. No different than 
>> >> >> >> Intel's
>> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
>> >> >> >> 
>> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. 
>> >> >> >> They
>> >> >> >> are two competing standards and, apparently, type-C is winning when 
>> >> >> >> it
>> >> >> >> comes to role-swapping.
>> >> >> >> 
>> >> >> >
>> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
>> >> >> > dual-role,
>> >> >> > It will be considered as an OTG port.
>> >> >> 
>> >> >> That's because "dual-role" is a non-standard OTG. Seen as people really
>> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
>> >> >> referring
>> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
>> >> >
>> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
>> >> > "OTG" in Linux, right?
>> >> 
>> >> to avoid confusion with the terminology, yes. With that settled, let's
>> >> figure out how you can deliver what your marketting guys are asking of
>> >> you.
>> >> 
>> >
>> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
>> > test. The internal bsp has passed PET test, and formal compliance test
>> > is on the way (should pass too). 
>> >
>> > The dual-role and OTG compliance use the same zImage, but different
>> > dtb.
>> 
>> okay, that's good to know. Now, the question really is: considering we
>> only have one user for this generic OTG FSM layer, do we really need to
>> make it generic at all? I mean, just look at how invasive a change that
>> is.
>
> If the chipidea is the only user for this roger's framework, I don't
> think it is necessary. In fact, Roger introduces this framework, and
> the first user is dwc3, we think it can be used for others. Let's

Right, we need to look at the history of dwc3 to figure out why the
conclusion that dwc3 needs this was made.

Roger started working on this framework when Power on Reset section of
databook had some details which weren't always clear and, for safety, we
always had reset asserted for a really long time. It was so long (about
400 ms) that resetting dwc3 for each role swap was just too much.

Coupled with that, the OTG chapter wasn't very clear either on
expections from Host and Peripheral side initialization in OTG/DRD
systems.

More recent version of dwc3 databook have a much better description of
how and which reset bits _must_ be asserted and which shouldn't be
touched unless it's for debugging purposes. When I implemented that, our
->probe() went from 400ms down to about 50us.

Coupled with that, the OTG chapter also became a lot clearer to the
point that it states you just don't initialize anything other than the
OTG block, and just wait for OTG interrupt to do whatever it is you need
to do.

This meant that we could actually afford to do full reinitialization of
dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
roles properly.

(The reason for needing soft-reset during role swap is kinda long. But
in summary dwc3 shadows register writes to both host and peripheral
sides)

> just discuss if it is necessary for dual-role switch.

fair. However, if we have a single user we don't have a Generic
layer. There's not enough variance to come up with truly generic
architecture for this.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
>> >> >> >> >>> OTG core.
>> >> >> >> >> 
>> >> >> >> >> do you really know of any platform which has a separate OTG 
>> >> >> >> >> controller?
>> >> >> >> >> 
>> >> >> >> >
>> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
>> >> >> >> > for OTG, host
>> >> >> >> > and gadget.
>> >> >> >> >
>> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> >> >> >> 
>> >> >> >> that's not an OTG controller, it's just a mux. No different than 
>> >> >> >> Intel's
>> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
>> >> >> >> 
>> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. 
>> >> >> >> They
>> >> >> >> are two competing standards and, apparently, type-C is winning when 
>> >> >> >> it
>> >> >> >> comes to role-swapping.
>> >> >> >> 
>> >> >> >
>> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
>> >> >> > dual-role,
>> >> >> > It will be considered as an OTG port.
>> >> >> 
>> >> >> That's because "dual-role" is a non-standard OTG. Seen as people really
>> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally 
>> >> >> referring
>> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
>> >> >
>> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
>> >> > "OTG" in Linux, right?
>> >> 
>> >> to avoid confusion with the terminology, yes. With that settled, let's
>> >> figure out how you can deliver what your marketting guys are asking of
>> >> you.
>> >> 
>> >
>> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
>> > test. The internal bsp has passed PET test, and formal compliance test
>> > is on the way (should pass too). 
>> >
>> > The dual-role and OTG compliance use the same zImage, but different
>> > dtb.
>> 
>> okay, that's good to know. Now, the question really is: considering we
>> only have one user for this generic OTG FSM layer, do we really need to
>> make it generic at all? I mean, just look at how invasive a change that
>> is.
>
> If the chipidea is the only user for this roger's framework, I don't
> think it is necessary. In fact, Roger introduces this framework, and
> the first user is dwc3, we think it can be used for others. Let's

Right, we need to look at the history of dwc3 to figure out why the
conclusion that dwc3 needs this was made.

Roger started working on this framework when Power on Reset section of
databook had some details which weren't always clear and, for safety, we
always had reset asserted for a really long time. It was so long (about
400 ms) that resetting dwc3 for each role swap was just too much.

Coupled with that, the OTG chapter wasn't very clear either on
expections from Host and Peripheral side initialization in OTG/DRD
systems.

More recent version of dwc3 databook have a much better description of
how and which reset bits _must_ be asserted and which shouldn't be
touched unless it's for debugging purposes. When I implemented that, our
->probe() went from 400ms down to about 50us.

Coupled with that, the OTG chapter also became a lot clearer to the
point that it states you just don't initialize anything other than the
OTG block, and just wait for OTG interrupt to do whatever it is you need
to do.

This meant that we could actually afford to do full reinitialization of
dwc3 on role swap (it's now only 50us anyway) and we knew how to swap
roles properly.

(The reason for needing soft-reset during role swap is kinda long. But
in summary dwc3 shadows register writes to both host and peripheral
sides)

> just discuss if it is necessary for dual-role switch.

fair. However, if we have a single user we don't have a Generic
layer. There's not enough variance to come up with truly generic
architecture for this.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 03:35:00PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
> >> >> >> >>> OTG core.
> >> >> >> >> 
> >> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> >> controller?
> >> >> >> >> 
> >> >> >> >
> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
> >> >> >> > for OTG, host
> >> >> >> > and gadget.
> >> >> >> >
> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> >> 
> >> >> >> that's not an OTG controller, it's just a mux. No different than 
> >> >> >> Intel's
> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> >> 
> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. 
> >> >> >> They
> >> >> >> are two competing standards and, apparently, type-C is winning when 
> >> >> >> it
> >> >> >> comes to role-swapping.
> >> >> >> 
> >> >> >
> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> >> >> > dual-role,
> >> >> > It will be considered as an OTG port.
> >> >> 
> >> >> That's because "dual-role" is a non-standard OTG. Seen as people really
> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally referring
> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >> >
> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> >> > "OTG" in Linux, right?
> >> 
> >> to avoid confusion with the terminology, yes. With that settled, let's
> >> figure out how you can deliver what your marketting guys are asking of
> >> you.
> >> 
> >
> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> > test. The internal bsp has passed PET test, and formal compliance test
> > is on the way (should pass too). 
> >
> > The dual-role and OTG compliance use the same zImage, but different
> > dtb.
> 
> okay, that's good to know. Now, the question really is: considering we
> only have one user for this generic OTG FSM layer, do we really need to
> make it generic at all? I mean, just look at how invasive a change that
> is.
> 

If the chipidea is the only user for this roger's framework, I don't
think it is necessary. In fact, Roger introduces this framework, and
the first user is dwc3, we think it can be used for others. Let's
just discuss if it is necessary for dual-role switch.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 03:35:00PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with 
> >> >> >> >>> OTG core.
> >> >> >> >> 
> >> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> >> controller?
> >> >> >> >> 
> >> >> >> >
> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks 
> >> >> >> > for OTG, host
> >> >> >> > and gadget.
> >> >> >> >
> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> >> 
> >> >> >> that's not an OTG controller, it's just a mux. No different than 
> >> >> >> Intel's
> >> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> >> 
> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. 
> >> >> >> They
> >> >> >> are two competing standards and, apparently, type-C is winning when 
> >> >> >> it
> >> >> >> comes to role-swapping.
> >> >> >> 
> >> >> >
> >> >> > In fact, OTG is mis-used by people. Currently, if the port is 
> >> >> > dual-role,
> >> >> > It will be considered as an OTG port.
> >> >> 
> >> >> That's because "dual-role" is a non-standard OTG. Seen as people really
> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally referring
> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >> >
> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> >> > "OTG" in Linux, right?
> >> 
> >> to avoid confusion with the terminology, yes. With that settled, let's
> >> figure out how you can deliver what your marketting guys are asking of
> >> you.
> >> 
> >
> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> > test. The internal bsp has passed PET test, and formal compliance test
> > is on the way (should pass too). 
> >
> > The dual-role and OTG compliance use the same zImage, but different
> > dtb.
> 
> okay, that's good to know. Now, the question really is: considering we
> only have one user for this generic OTG FSM layer, do we really need to
> make it generic at all? I mean, just look at how invasive a change that
> is.
> 

If the chipidea is the only user for this roger's framework, I don't
think it is necessary. In fact, Roger introduces this framework, and
the first user is dwc3, we think it can be used for others. Let's
just discuss if it is necessary for dual-role switch.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG 
>> >> >> >>> core.
>> >> >> >> 
>> >> >> >> do you really know of any platform which has a separate OTG 
>> >> >> >> controller?
>> >> >> >> 
>> >> >> >
>> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for 
>> >> >> > OTG, host
>> >> >> > and gadget.
>> >> >> >
>> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> >> >> 
>> >> >> that's not an OTG controller, it's just a mux. No different than 
>> >> >> Intel's
>> >> >> mux for swapping between XHCI and peripheral-only DWC3.
>> >> >> 
>> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
>> >> >> are two competing standards and, apparently, type-C is winning when it
>> >> >> comes to role-swapping.
>> >> >> 
>> >> >
>> >> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
>> >> > It will be considered as an OTG port.
>> >> 
>> >> That's because "dual-role" is a non-standard OTG. Seen as people really
>> >> didn't care about OTG, we (linux-usb folks) ended up naturally referring
>> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
>> >
>> > So, unless we use OTG FSM defined in OTG spec, we should not mention
>> > "OTG" in Linux, right?
>> 
>> to avoid confusion with the terminology, yes. With that settled, let's
>> figure out how you can deliver what your marketting guys are asking of
>> you.
>> 
>
> Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> test. The internal bsp has passed PET test, and formal compliance test
> is on the way (should pass too). 
>
> The dual-role and OTG compliance use the same zImage, but different
> dtb.

okay, that's good to know. Now, the question really is: considering we
only have one user for this generic OTG FSM layer, do we really need to
make it generic at all? I mean, just look at how invasive a change that
is.

My fear is that, as stated before, we don't have enough variance to be
able to design something that many could use. On top of that, most folks
are moving to type-c connector which, in reality, can't really implement
OTG.

Considering that Apple/Intel have already announced [1] that they will
use type-c connector, it's not too farfetched to speculate that CarPlay
will, eventually, rely on Power Delivery for role swapping. IOW, OTG has
its days counted. In 2 years' time, the market will have moved on to
Type-C and the generic OTG layer will be left to bit rot as time goes
by.

This is why I think that these changes should be local to chipidea,
considering chipidea is the only user for them. As for dwc3, we can get
something much simpler since, at least so far, there's no full OTG
requirement from anywhere I know and, even if OTG becomes a requirement
for any of dwc3 users, the HW handles the state machine for us.

What do you think?

[1] https://thunderbolttechnology.net/blog/thunderbolt-3-usb-c-does-it-all

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG 
>> >> >> >>> core.
>> >> >> >> 
>> >> >> >> do you really know of any platform which has a separate OTG 
>> >> >> >> controller?
>> >> >> >> 
>> >> >> >
>> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for 
>> >> >> > OTG, host
>> >> >> > and gadget.
>> >> >> >
>> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> >> >> 
>> >> >> that's not an OTG controller, it's just a mux. No different than 
>> >> >> Intel's
>> >> >> mux for swapping between XHCI and peripheral-only DWC3.
>> >> >> 
>> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
>> >> >> are two competing standards and, apparently, type-C is winning when it
>> >> >> comes to role-swapping.
>> >> >> 
>> >> >
>> >> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
>> >> > It will be considered as an OTG port.
>> >> 
>> >> That's because "dual-role" is a non-standard OTG. Seen as people really
>> >> didn't care about OTG, we (linux-usb folks) ended up naturally referring
>> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
>> >
>> > So, unless we use OTG FSM defined in OTG spec, we should not mention
>> > "OTG" in Linux, right?
>> 
>> to avoid confusion with the terminology, yes. With that settled, let's
>> figure out how you can deliver what your marketting guys are asking of
>> you.
>> 
>
> Since nxp SoC claims they are OTG compliance, we need to pass usb.org
> test. The internal bsp has passed PET test, and formal compliance test
> is on the way (should pass too). 
>
> The dual-role and OTG compliance use the same zImage, but different
> dtb.

okay, that's good to know. Now, the question really is: considering we
only have one user for this generic OTG FSM layer, do we really need to
make it generic at all? I mean, just look at how invasive a change that
is.

My fear is that, as stated before, we don't have enough variance to be
able to design something that many could use. On top of that, most folks
are moving to type-c connector which, in reality, can't really implement
OTG.

Considering that Apple/Intel have already announced [1] that they will
use type-c connector, it's not too farfetched to speculate that CarPlay
will, eventually, rely on Power Delivery for role swapping. IOW, OTG has
its days counted. In 2 years' time, the market will have moved on to
Type-C and the generic OTG layer will be left to bit rot as time goes
by.

This is why I think that these changes should be local to chipidea,
considering chipidea is the only user for them. As for dwc3, we can get
something much simpler since, at least so far, there's no full OTG
requirement from anywhere I know and, even if OTG becomes a requirement
for any of dwc3 users, the HW handles the state machine for us.

What do you think?

[1] https://thunderbolttechnology.net/blog/thunderbolt-3-usb-c-does-it-all

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 11:18:21AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> Peter Chen  writes:
> >> >> >>> +
> >> >> >>> +   /* start host */
> >> >> >>> +   ret = hcd_ops->add(otg->primary_hcd.hcd,
> >> >> >>> +  otg->primary_hcd.irqnum,
> >> >> >>> +  otg->primary_hcd.irqflags);
> >> >> >> 
> >> >> >> this is usb_add_hcd(), is it not? Why add an indirection?
> >> >> >
> >> >> > I've introduced the host and gadget ops interface to get around the
> >> >> > circular dependency issue we can't avoid.
> >> >> > otg needs to call host/gadget functions and host/gadget also needs to
> >> >> > call otg functions.
> >> >> 
> >> >> IMO, this shows a fragility of your design. You're, now, lying to
> >> >> usb_hcd and usb_udc and making them register into a virtual layer that
> >> >> doesn't exist. And that layer will end up calling the real registration
> >> >> function when some magic event happens.
> >> >> 
> >> >> This is only really needed for quirky devices like dwc3 (but see more on
> >> >> dwc3 below) where host and peripheral registers shadow each
> >> >> other. Otherwise we would be able to always keep hcd and udc always
> >> >> registered. They would get different interrupt statuses anyway and
> >> >> nothing would ever break.
> >> >> 
> >> >> However, when it comes to dwc3, we already have all the code necessary
> >> >> to workaround this issue by destroying the XHCI pdev when OTG interrupt
> >> >> says we should be peripheral (and vice-versa). DWC3 also keeps track of
> >> >> the OTG states for those folks who really care about OTG (Hint: nobody
> >> >> has cared for the past 10 years, why would they do so now?) and we don't
> >> >> need a SW state machine when the HW handles that for us, right?
> >> >> 
> >> >> As for chipidea, IIRC, that doesn't need a SW state machine either, but
> >> >> I know very little about that IP and don't even have documentation on
> >> >> it. My understanding, however, is that chipidea behaves kinda like MUSB,
> >> >> which changes roles automatically in HW based on ID pin state.
> >> >
> >> > Chipidea needs to set register for USB role manually.
> >> 
> >> okay, so chipidea has private control of role. Much like dwc3. That's good.
> >> 
> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG 
> >> >> >>> core.
> >> >> >> 
> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> controller?
> >> >> >> 
> >> >> >
> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for 
> >> >> > OTG, host
> >> >> > and gadget.
> >> >> >
> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> 
> >> >> that's not an OTG controller, it's just a mux. No different than Intel's
> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> 
> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
> >> >> are two competing standards and, apparently, type-C is winning when it
> >> >> comes to role-swapping.
> >> >> 
> >> >
> >> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
> >> > It will be considered as an OTG port.
> >> 
> >> That's because "dual-role" is a non-standard OTG. Seen as people really
> >> didn't care about OTG, we (linux-usb folks) ended up naturally referring
> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >
> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> > "OTG" in Linux, right?
> 
> to avoid confusion with the terminology, yes. With that settled, let's
> figure out how you can deliver what your marketting guys are asking of
> you.
> 

Since nxp SoC claims they are OTG compliance, we need to pass usb.org
test. The internal bsp has passed PET test, and formal compliance test
is on the way (should pass too). 

The dual-role and OTG compliance use the same zImage, but different
dtb.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 11:18:21AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> Peter Chen  writes:
> >> >> >>> +
> >> >> >>> +   /* start host */
> >> >> >>> +   ret = hcd_ops->add(otg->primary_hcd.hcd,
> >> >> >>> +  otg->primary_hcd.irqnum,
> >> >> >>> +  otg->primary_hcd.irqflags);
> >> >> >> 
> >> >> >> this is usb_add_hcd(), is it not? Why add an indirection?
> >> >> >
> >> >> > I've introduced the host and gadget ops interface to get around the
> >> >> > circular dependency issue we can't avoid.
> >> >> > otg needs to call host/gadget functions and host/gadget also needs to
> >> >> > call otg functions.
> >> >> 
> >> >> IMO, this shows a fragility of your design. You're, now, lying to
> >> >> usb_hcd and usb_udc and making them register into a virtual layer that
> >> >> doesn't exist. And that layer will end up calling the real registration
> >> >> function when some magic event happens.
> >> >> 
> >> >> This is only really needed for quirky devices like dwc3 (but see more on
> >> >> dwc3 below) where host and peripheral registers shadow each
> >> >> other. Otherwise we would be able to always keep hcd and udc always
> >> >> registered. They would get different interrupt statuses anyway and
> >> >> nothing would ever break.
> >> >> 
> >> >> However, when it comes to dwc3, we already have all the code necessary
> >> >> to workaround this issue by destroying the XHCI pdev when OTG interrupt
> >> >> says we should be peripheral (and vice-versa). DWC3 also keeps track of
> >> >> the OTG states for those folks who really care about OTG (Hint: nobody
> >> >> has cared for the past 10 years, why would they do so now?) and we don't
> >> >> need a SW state machine when the HW handles that for us, right?
> >> >> 
> >> >> As for chipidea, IIRC, that doesn't need a SW state machine either, but
> >> >> I know very little about that IP and don't even have documentation on
> >> >> it. My understanding, however, is that chipidea behaves kinda like MUSB,
> >> >> which changes roles automatically in HW based on ID pin state.
> >> >
> >> > Chipidea needs to set register for USB role manually.
> >> 
> >> okay, so chipidea has private control of role. Much like dwc3. That's good.
> >> 
> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG 
> >> >> >>> core.
> >> >> >> 
> >> >> >> do you really know of any platform which has a separate OTG 
> >> >> >> controller?
> >> >> >> 
> >> >> >
> >> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for 
> >> >> > OTG, host
> >> >> > and gadget.
> >> >> >
> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> >> 
> >> >> that's not an OTG controller, it's just a mux. No different than Intel's
> >> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> >> 
> >> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
> >> >> are two competing standards and, apparently, type-C is winning when it
> >> >> comes to role-swapping.
> >> >> 
> >> >
> >> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
> >> > It will be considered as an OTG port.
> >> 
> >> That's because "dual-role" is a non-standard OTG. Seen as people really
> >> didn't care about OTG, we (linux-usb folks) ended up naturally referring
> >> to "non-standard OTG" as "dual-role". Just to avoid confusion.
> >
> > So, unless we use OTG FSM defined in OTG spec, we should not mention
> > "OTG" in Linux, right?
> 
> to avoid confusion with the terminology, yes. With that settled, let's
> figure out how you can deliver what your marketting guys are asking of
> you.
> 

Since nxp SoC claims they are OTG compliance, we need to pass usb.org
test. The internal bsp has passed PET test, and formal compliance test
is on the way (should pass too). 

The dual-role and OTG compliance use the same zImage, but different
dtb.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Tony Lindgren  writes:
> * Felipe Balbi  [160621 03:06]:
>> 8<--
>>  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>> 
>> set_role(id);
>> set_vbus(vbus);
>
> We should use regulator framework API for set_vbus() because of
> the delays involved bringing it up. And we already have separate
> PHY and charger chips where VBUS is provided by the charger chip.

yeah, no arguments there.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Tony Lindgren  writes:
> * Felipe Balbi  [160621 03:06]:
>> 8<--
>>  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>> 
>> set_role(id);
>> set_vbus(vbus);
>
> We should use regulator framework API for set_vbus() because of
> the delays involved bringing it up. And we already have separate
> PHY and charger chips where VBUS is provided by the charger chip.

yeah, no arguments there.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Tony Lindgren]

* Felipe Balbi  [160621 03:06]:
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
> 
> set_role(id);
> set_vbus(vbus);

We should use regulator framework API for set_vbus() because of
the delays involved bringing it up. And we already have separate
PHY and charger chips where VBUS is provided by the charger chip.

Regards,

Tony

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Tony Lindgren]

* Felipe Balbi  [160621 03:06]:
> 8<--
>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
> 
> set_role(id);
> set_vbus(vbus);

We should use regulator framework API for set_vbus() because of
the delays involved bringing it up. And we already have separate
PHY and charger chips where VBUS is provided by the charger chip.

Regards,

Tony

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> when they say OTG. Usually they just mean "a method for swapping between
>> >> host and peripheral roles, but we really don't want all the extra cost
>> >> of the OTG specification".
>> >> 
>> >
>> > That's what I thought before, but the request from the Marketing guy is
>> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> > see the SoC reference manual say "it supports HNP and SRP"?
>> >
>> > If there is no request, who else wants to implement so complicated FSM
>> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
>> 
>> I stand corrected :-)
>> 
>> So there is one user for this layer. And this user has its own role
>> control registers. I'm not convinced we need this large generic layer
>> for one user.
>> 
>
> You mean chipidea or dwc3? I have more comments below.

chipidea. From the point of OTG (or DRD) dwc3 is very
self-sufficient. HW itself tracks state machine, much like MUSB does.

>> >> > For the real use case, some Carplay platforms need it.
>> >> 
>> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> >> specification which is not OTG-compliant.
>> >> 
>> >
>> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>> > states to finish role swap.
>> 
>> What are you referring to as "finish role swap"? I don't get that.
>
> Change current role from host to peripheral.

Okay, we have two scenarios here:

1. You need full OTG compliance

For this, granted, you need the state machine if your HW doesn't
track it. This is a given. With only one user, however, perhaps
we don't need a generic layer. There are not enough different
setups to design a good enough generic layer. We will end up
with a pseudo-generic framework which is coupled with its only
user.

2. Dual-role support, without OTG compliance

In this case, you don't need a stack. All you need is a signal
to tell you state of ID pin and another to tell you state of
VBUS level. If you have those, you don't need to walk an OTG
state machine at all. You don't need any of those quirky OTG
timers, agreed?

Given the above, why would you even want to use a subset of OTG
state machine to implement something that's _usually_ as simple
as:

8<--
vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
id = read(ID_STATE); /* could be a gpio_get_value() */

set_role(id);
set_vbus(vbus);


>> > Notice, it needs to swap role without disconnect cable.
>> 
>> right, I can swap role without changing cable, but that's not OTG. The
>> mechanism for that, AFAICT, is not HNP. I don't know details about
>> CarPlay because the spec isn't public, but my understanding is that
>> CarPlay doesn't rely on anything from OTG spec.
>
> Since it is non-public, I can't say much. Some flows of its role-swap
> refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> Specification. 
>
> But OTG FSM is not the only way, the platform which can do role-swap
> without disconnection can support it too.

Right, all you need for CarPlay is what I wrote above. You don't need
full OTG compliance for that, right?

>> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> >> > index f4fc0aa..1d74fb8 100644
>> >> >> > --- a/include/linux/usb/gadget.h
>> >> >> > +++ b/include/linux/usb/gadget.h
>> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >> >   * @in_epnum: last used in ep number
>> >> >> >   * @mA: last set mA value
>> >> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG 
>> >> >> > core.
>> >> >> 
>> >> >> do you really know of any platform which has a separate OTG controller?
>> >> >> 
>> >> >
>> >> > It may not be a real separate OTG controller. It can be a hardware part
>> >> > (external connector, external IC, SoC OTG register area, etc) to handle 
>> >> > vbus
>> >> > ,id and other signals which are used for role swap.
>> >> 
>> >> That's already solved. EXTCON solved that years back and OMAP has been
>> >> using EXTCON to program its UTMI mailbox.
>> >> 
>> >
>> > No, that's not the same thing, it does not include the swap role.
>> 
>> Read your original comment:
>> 
>> "handle vbus, id and other signals which are *used for* role swap"
>> 
>> You didn't include role swap in your original comment. Semantics aside...
>> 
>> > Consider the use case the host driver is at host/ and udc driver is
>> > at gadget/udc, how to finish to role swap?
>> 
>> ... why does the source code placement matter? And what do you mean by
>> "finish role 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> when they say OTG. Usually they just mean "a method for swapping between
>> >> host and peripheral roles, but we really don't want all the extra cost
>> >> of the OTG specification".
>> >> 
>> >
>> > That's what I thought before, but the request from the Marketing guy is
>> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> > see the SoC reference manual say "it supports HNP and SRP"?
>> >
>> > If there is no request, who else wants to implement so complicated FSM
>> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
>> 
>> I stand corrected :-)
>> 
>> So there is one user for this layer. And this user has its own role
>> control registers. I'm not convinced we need this large generic layer
>> for one user.
>> 
>
> You mean chipidea or dwc3? I have more comments below.

chipidea. From the point of OTG (or DRD) dwc3 is very
self-sufficient. HW itself tracks state machine, much like MUSB does.

>> >> > For the real use case, some Carplay platforms need it.
>> >> 
>> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> >> specification which is not OTG-compliant.
>> >> 
>> >
>> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>> > states to finish role swap.
>> 
>> What are you referring to as "finish role swap"? I don't get that.
>
> Change current role from host to peripheral.

Okay, we have two scenarios here:

1. You need full OTG compliance

For this, granted, you need the state machine if your HW doesn't
track it. This is a given. With only one user, however, perhaps
we don't need a generic layer. There are not enough different
setups to design a good enough generic layer. We will end up
with a pseudo-generic framework which is coupled with its only
user.

2. Dual-role support, without OTG compliance

In this case, you don't need a stack. All you need is a signal
to tell you state of ID pin and another to tell you state of
VBUS level. If you have those, you don't need to walk an OTG
state machine at all. You don't need any of those quirky OTG
timers, agreed?

Given the above, why would you even want to use a subset of OTG
state machine to implement something that's _usually_ as simple
as:

8<--
vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
id = read(ID_STATE); /* could be a gpio_get_value() */

set_role(id);
set_vbus(vbus);


>> > Notice, it needs to swap role without disconnect cable.
>> 
>> right, I can swap role without changing cable, but that's not OTG. The
>> mechanism for that, AFAICT, is not HNP. I don't know details about
>> CarPlay because the spec isn't public, but my understanding is that
>> CarPlay doesn't rely on anything from OTG spec.
>
> Since it is non-public, I can't say much. Some flows of its role-swap
> refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> Specification. 
>
> But OTG FSM is not the only way, the platform which can do role-swap
> without disconnection can support it too.

Right, all you need for CarPlay is what I wrote above. You don't need
full OTG compliance for that, right?

>> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> >> > index f4fc0aa..1d74fb8 100644
>> >> >> > --- a/include/linux/usb/gadget.h
>> >> >> > +++ b/include/linux/usb/gadget.h
>> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >> >   * @in_epnum: last used in ep number
>> >> >> >   * @mA: last set mA value
>> >> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG 
>> >> >> > core.
>> >> >> 
>> >> >> do you really know of any platform which has a separate OTG controller?
>> >> >> 
>> >> >
>> >> > It may not be a real separate OTG controller. It can be a hardware part
>> >> > (external connector, external IC, SoC OTG register area, etc) to handle 
>> >> > vbus
>> >> > ,id and other signals which are used for role swap.
>> >> 
>> >> That's already solved. EXTCON solved that years back and OMAP has been
>> >> using EXTCON to program its UTMI mailbox.
>> >> 
>> >
>> > No, that's not the same thing, it does not include the swap role.
>> 
>> Read your original comment:
>> 
>> "handle vbus, id and other signals which are *used for* role swap"
>> 
>> You didn't include role swap in your original comment. Semantics aside...
>> 
>> > Consider the use case the host driver is at host/ and udc driver is
>> > at gadget/udc, how to finish to role swap?
>> 
>> ... why does the source code placement matter? And what do you mean by
>> "finish role swap"?
>> 
>
> Well, it 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 10:26:00AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> >> 
> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> when they say OTG. Usually they just mean "a method for swapping between
> >> host and peripheral roles, but we really don't want all the extra cost
> >> of the OTG specification".
> >> 
> >
> > That's what I thought before, but the request from the Marketing guy is
> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> > see the SoC reference manual say "it supports HNP and SRP"?
> >
> > If there is no request, who else wants to implement so complicated FSM
> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> 
> I stand corrected :-)
> 
> So there is one user for this layer. And this user has its own role
> control registers. I'm not convinced we need this large generic layer
> for one user.
> 

You mean chipidea or dwc3? I have more comments below.

> >> > For the real use case, some Carplay platforms need it.
> >> 
> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> >> specification which is not OTG-compliant.
> >> 
> >
> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> > states to finish role swap.
> 
> What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

> 
> > Notice, it needs to swap role without disconnect cable.
> 
> right, I can swap role without changing cable, but that's not OTG. The
> mechanism for that, AFAICT, is not HNP. I don't know details about
> CarPlay because the spec isn't public, but my understanding is that
> CarPlay doesn't rely on anything from OTG spec.

Since it is non-public, I can't say much. Some flows of its role-swap
refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification. 

But OTG FSM is not the only way, the platform which can do role-swap
without disconnection can support it too.

> 
> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> >> > index f4fc0aa..1d74fb8 100644
> >> >> > --- a/include/linux/usb/gadget.h
> >> >> > +++ b/include/linux/usb/gadget.h
> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >> >> >   * @in_epnum: last used in ep number
> >> >> >   * @mA: last set mA value
> >> >> >   * @otg_caps: OTG capabilities of this gadget.
> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG 
> >> >> > core.
> >> >> 
> >> >> do you really know of any platform which has a separate OTG controller?
> >> >> 
> >> >
> >> > It may not be a real separate OTG controller. It can be a hardware part
> >> > (external connector, external IC, SoC OTG register area, etc) to handle 
> >> > vbus
> >> > ,id and other signals which are used for role swap.
> >> 
> >> That's already solved. EXTCON solved that years back and OMAP has been
> >> using EXTCON to program its UTMI mailbox.
> >> 
> >
> > No, that's not the same thing, it does not include the swap role.
> 
> Read your original comment:
> 
> "handle vbus, id and other signals which are *used for* role swap"
> 
> You didn't include role swap in your original comment. Semantics aside...
> 
> > Consider the use case the host driver is at host/ and udc driver is
> > at gadget/udc, how to finish to role swap?
> 
> ... why does the source code placement matter? And what do you mean by
> "finish role swap"?
> 

Well, it depends on your driver design, do you want the host driver's
API is still be called when current role is peripheral? One typical
problem you can refer below:

commit 11c011a5e777c83819078a18672543f04482b3ec
Author: Srinivas Kandagatla 
Date:   Thu May 19 11:12:56 2016 +0100

usb: echi-hcd: Add ehci_setup check before echi_shutdown



In some cases, the USB code (gadget/hcd->start/stop) needs to be called
during the role swap. For example, if you have mux driver, you may
need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
how can we do that?

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 10:26:00AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> >> 
> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> when they say OTG. Usually they just mean "a method for swapping between
> >> host and peripheral roles, but we really don't want all the extra cost
> >> of the OTG specification".
> >> 
> >
> > That's what I thought before, but the request from the Marketing guy is
> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> > see the SoC reference manual say "it supports HNP and SRP"?
> >
> > If there is no request, who else wants to implement so complicated FSM
> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> 
> I stand corrected :-)
> 
> So there is one user for this layer. And this user has its own role
> control registers. I'm not convinced we need this large generic layer
> for one user.
> 

You mean chipidea or dwc3? I have more comments below.

> >> > For the real use case, some Carplay platforms need it.
> >> 
> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> >> specification which is not OTG-compliant.
> >> 
> >
> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> > states to finish role swap.
> 
> What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

> 
> > Notice, it needs to swap role without disconnect cable.
> 
> right, I can swap role without changing cable, but that's not OTG. The
> mechanism for that, AFAICT, is not HNP. I don't know details about
> CarPlay because the spec isn't public, but my understanding is that
> CarPlay doesn't rely on anything from OTG spec.

Since it is non-public, I can't say much. Some flows of its role-swap
refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification. 

But OTG FSM is not the only way, the platform which can do role-swap
without disconnection can support it too.

> 
> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> >> > index f4fc0aa..1d74fb8 100644
> >> >> > --- a/include/linux/usb/gadget.h
> >> >> > +++ b/include/linux/usb/gadget.h
> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >> >> >   * @in_epnum: last used in ep number
> >> >> >   * @mA: last set mA value
> >> >> >   * @otg_caps: OTG capabilities of this gadget.
> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG 
> >> >> > core.
> >> >> 
> >> >> do you really know of any platform which has a separate OTG controller?
> >> >> 
> >> >
> >> > It may not be a real separate OTG controller. It can be a hardware part
> >> > (external connector, external IC, SoC OTG register area, etc) to handle 
> >> > vbus
> >> > ,id and other signals which are used for role swap.
> >> 
> >> That's already solved. EXTCON solved that years back and OMAP has been
> >> using EXTCON to program its UTMI mailbox.
> >> 
> >
> > No, that's not the same thing, it does not include the swap role.
> 
> Read your original comment:
> 
> "handle vbus, id and other signals which are *used for* role swap"
> 
> You didn't include role swap in your original comment. Semantics aside...
> 
> > Consider the use case the host driver is at host/ and udc driver is
> > at gadget/udc, how to finish to role swap?
> 
> ... why does the source code placement matter? And what do you mean by
> "finish role swap"?
> 

Well, it depends on your driver design, do you want the host driver's
API is still be called when current role is peripheral? One typical
problem you can refer below:

commit 11c011a5e777c83819078a18672543f04482b3ec
Author: Srinivas Kandagatla 
Date:   Thu May 19 11:12:56 2016 +0100

usb: echi-hcd: Add ehci_setup check before echi_shutdown



In some cases, the USB code (gadget/hcd->start/stop) needs to be called
during the role swap. For example, if you have mux driver, you may
need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
how can we do that?

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> Peter Chen  writes:
>> >> >>> +
>> >> >>> + /* start host */
>> >> >>> + ret = hcd_ops->add(otg->primary_hcd.hcd,
>> >> >>> +otg->primary_hcd.irqnum,
>> >> >>> +otg->primary_hcd.irqflags);
>> >> >> 
>> >> >> this is usb_add_hcd(), is it not? Why add an indirection?
>> >> >
>> >> > I've introduced the host and gadget ops interface to get around the
>> >> > circular dependency issue we can't avoid.
>> >> > otg needs to call host/gadget functions and host/gadget also needs to
>> >> > call otg functions.
>> >> 
>> >> IMO, this shows a fragility of your design. You're, now, lying to
>> >> usb_hcd and usb_udc and making them register into a virtual layer that
>> >> doesn't exist. And that layer will end up calling the real registration
>> >> function when some magic event happens.
>> >> 
>> >> This is only really needed for quirky devices like dwc3 (but see more on
>> >> dwc3 below) where host and peripheral registers shadow each
>> >> other. Otherwise we would be able to always keep hcd and udc always
>> >> registered. They would get different interrupt statuses anyway and
>> >> nothing would ever break.
>> >> 
>> >> However, when it comes to dwc3, we already have all the code necessary
>> >> to workaround this issue by destroying the XHCI pdev when OTG interrupt
>> >> says we should be peripheral (and vice-versa). DWC3 also keeps track of
>> >> the OTG states for those folks who really care about OTG (Hint: nobody
>> >> has cared for the past 10 years, why would they do so now?) and we don't
>> >> need a SW state machine when the HW handles that for us, right?
>> >> 
>> >> As for chipidea, IIRC, that doesn't need a SW state machine either, but
>> >> I know very little about that IP and don't even have documentation on
>> >> it. My understanding, however, is that chipidea behaves kinda like MUSB,
>> >> which changes roles automatically in HW based on ID pin state.
>> >
>> > Chipidea needs to set register for USB role manually.
>> 
>> okay, so chipidea has private control of role. Much like dwc3. That's good.
>> 
>> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG 
>> >> >>> core.
>> >> >> 
>> >> >> do you really know of any platform which has a separate OTG controller?
>> >> >> 
>> >> >
>> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for 
>> >> > OTG, host
>> >> > and gadget.
>> >> >
>> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> >> 
>> >> that's not an OTG controller, it's just a mux. No different than Intel's
>> >> mux for swapping between XHCI and peripheral-only DWC3.
>> >> 
>> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
>> >> are two competing standards and, apparently, type-C is winning when it
>> >> comes to role-swapping.
>> >> 
>> >
>> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
>> > It will be considered as an OTG port.
>> 
>> That's because "dual-role" is a non-standard OTG. Seen as people really
>> didn't care about OTG, we (linux-usb folks) ended up naturally referring
>> to "non-standard OTG" as "dual-role". Just to avoid confusion.
>
> So, unless we use OTG FSM defined in OTG spec, we should not mention
> "OTG" in Linux, right?

to avoid confusion with the terminology, yes. With that settled, let's
figure out how you can deliver what your marketting guys are asking of
you.

>> > You are right, if the connector is type-c, it will be called as "type-c
>> > port" by people :)
>> 
>> oh no, that's not what I'm talking about. If you read Type-C and PD
>> specs, they define their own method for data role swapping. USB OTG
>> doesn't fit on top of a Type-C environment. It's not about what people
>> will call it, it's really that OTG can't work on top of type-c. For
>> starters, there's no ID pin ;-)
>
> I know type-c, yes, there is no relationship between OTG and type-c.

okay, thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> Peter Chen  writes:
>> >> >>> +
>> >> >>> + /* start host */
>> >> >>> + ret = hcd_ops->add(otg->primary_hcd.hcd,
>> >> >>> +otg->primary_hcd.irqnum,
>> >> >>> +otg->primary_hcd.irqflags);
>> >> >> 
>> >> >> this is usb_add_hcd(), is it not? Why add an indirection?
>> >> >
>> >> > I've introduced the host and gadget ops interface to get around the
>> >> > circular dependency issue we can't avoid.
>> >> > otg needs to call host/gadget functions and host/gadget also needs to
>> >> > call otg functions.
>> >> 
>> >> IMO, this shows a fragility of your design. You're, now, lying to
>> >> usb_hcd and usb_udc and making them register into a virtual layer that
>> >> doesn't exist. And that layer will end up calling the real registration
>> >> function when some magic event happens.
>> >> 
>> >> This is only really needed for quirky devices like dwc3 (but see more on
>> >> dwc3 below) where host and peripheral registers shadow each
>> >> other. Otherwise we would be able to always keep hcd and udc always
>> >> registered. They would get different interrupt statuses anyway and
>> >> nothing would ever break.
>> >> 
>> >> However, when it comes to dwc3, we already have all the code necessary
>> >> to workaround this issue by destroying the XHCI pdev when OTG interrupt
>> >> says we should be peripheral (and vice-versa). DWC3 also keeps track of
>> >> the OTG states for those folks who really care about OTG (Hint: nobody
>> >> has cared for the past 10 years, why would they do so now?) and we don't
>> >> need a SW state machine when the HW handles that for us, right?
>> >> 
>> >> As for chipidea, IIRC, that doesn't need a SW state machine either, but
>> >> I know very little about that IP and don't even have documentation on
>> >> it. My understanding, however, is that chipidea behaves kinda like MUSB,
>> >> which changes roles automatically in HW based on ID pin state.
>> >
>> > Chipidea needs to set register for USB role manually.
>> 
>> okay, so chipidea has private control of role. Much like dwc3. That's good.
>> 
>> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG 
>> >> >>> core.
>> >> >> 
>> >> >> do you really know of any platform which has a separate OTG controller?
>> >> >> 
>> >> >
>> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for 
>> >> > OTG, host
>> >> > and gadget.
>> >> >
>> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> >> 
>> >> that's not an OTG controller, it's just a mux. No different than Intel's
>> >> mux for swapping between XHCI and peripheral-only DWC3.
>> >> 
>> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
>> >> are two competing standards and, apparently, type-C is winning when it
>> >> comes to role-swapping.
>> >> 
>> >
>> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
>> > It will be considered as an OTG port.
>> 
>> That's because "dual-role" is a non-standard OTG. Seen as people really
>> didn't care about OTG, we (linux-usb folks) ended up naturally referring
>> to "non-standard OTG" as "dual-role". Just to avoid confusion.
>
> So, unless we use OTG FSM defined in OTG spec, we should not mention
> "OTG" in Linux, right?

to avoid confusion with the terminology, yes. With that settled, let's
figure out how you can deliver what your marketting guys are asking of
you.

>> > You are right, if the connector is type-c, it will be called as "type-c
>> > port" by people :)
>> 
>> oh no, that's not what I'm talking about. If you read Type-C and PD
>> specs, they define their own method for data role swapping. USB OTG
>> doesn't fit on top of a Type-C environment. It's not about what people
>> will call it, it's really that OTG can't work on top of type-c. For
>> starters, there's no ID pin ;-)
>
> I know type-c, yes, there is no relationship between OTG and type-c.

okay, thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 10:19:32AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >>> +
> >> >>> +  /* start host */
> >> >>> +  ret = hcd_ops->add(otg->primary_hcd.hcd,
> >> >>> + otg->primary_hcd.irqnum,
> >> >>> + otg->primary_hcd.irqflags);
> >> >> 
> >> >> this is usb_add_hcd(), is it not? Why add an indirection?
> >> >
> >> > I've introduced the host and gadget ops interface to get around the
> >> > circular dependency issue we can't avoid.
> >> > otg needs to call host/gadget functions and host/gadget also needs to
> >> > call otg functions.
> >> 
> >> IMO, this shows a fragility of your design. You're, now, lying to
> >> usb_hcd and usb_udc and making them register into a virtual layer that
> >> doesn't exist. And that layer will end up calling the real registration
> >> function when some magic event happens.
> >> 
> >> This is only really needed for quirky devices like dwc3 (but see more on
> >> dwc3 below) where host and peripheral registers shadow each
> >> other. Otherwise we would be able to always keep hcd and udc always
> >> registered. They would get different interrupt statuses anyway and
> >> nothing would ever break.
> >> 
> >> However, when it comes to dwc3, we already have all the code necessary
> >> to workaround this issue by destroying the XHCI pdev when OTG interrupt
> >> says we should be peripheral (and vice-versa). DWC3 also keeps track of
> >> the OTG states for those folks who really care about OTG (Hint: nobody
> >> has cared for the past 10 years, why would they do so now?) and we don't
> >> need a SW state machine when the HW handles that for us, right?
> >> 
> >> As for chipidea, IIRC, that doesn't need a SW state machine either, but
> >> I know very little about that IP and don't even have documentation on
> >> it. My understanding, however, is that chipidea behaves kinda like MUSB,
> >> which changes roles automatically in HW based on ID pin state.
> >
> > Chipidea needs to set register for USB role manually.
> 
> okay, so chipidea has private control of role. Much like dwc3. That's good.
> 
> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> >> 
> >> >> do you really know of any platform which has a separate OTG controller?
> >> >> 
> >> >
> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, 
> >> > host
> >> > and gadget.
> >> >
> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> 
> >> that's not an OTG controller, it's just a mux. No different than Intel's
> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> 
> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
> >> are two competing standards and, apparently, type-C is winning when it
> >> comes to role-swapping.
> >> 
> >
> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
> > It will be considered as an OTG port.
> 
> That's because "dual-role" is a non-standard OTG. Seen as people really
> didn't care about OTG, we (linux-usb folks) ended up naturally referring
> to "non-standard OTG" as "dual-role". Just to avoid confusion.

So, unless we use OTG FSM defined in OTG spec, we should not mention
"OTG" in Linux, right?
 
> 
> > You are right, if the connector is type-c, it will be called as "type-c
> > port" by people :)
> 
> oh no, that's not what I'm talking about. If you read Type-C and PD
> specs, they define their own method for data role swapping. USB OTG
> doesn't fit on top of a Type-C environment. It's not about what people
> will call it, it's really that OTG can't work on top of type-c. For
> starters, there's no ID pin ;-)

I know type-c, yes, there is no relationship between OTG and type-c.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Jun 21, 2016 at 10:19:32AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >>> +
> >> >>> +  /* start host */
> >> >>> +  ret = hcd_ops->add(otg->primary_hcd.hcd,
> >> >>> + otg->primary_hcd.irqnum,
> >> >>> + otg->primary_hcd.irqflags);
> >> >> 
> >> >> this is usb_add_hcd(), is it not? Why add an indirection?
> >> >
> >> > I've introduced the host and gadget ops interface to get around the
> >> > circular dependency issue we can't avoid.
> >> > otg needs to call host/gadget functions and host/gadget also needs to
> >> > call otg functions.
> >> 
> >> IMO, this shows a fragility of your design. You're, now, lying to
> >> usb_hcd and usb_udc and making them register into a virtual layer that
> >> doesn't exist. And that layer will end up calling the real registration
> >> function when some magic event happens.
> >> 
> >> This is only really needed for quirky devices like dwc3 (but see more on
> >> dwc3 below) where host and peripheral registers shadow each
> >> other. Otherwise we would be able to always keep hcd and udc always
> >> registered. They would get different interrupt statuses anyway and
> >> nothing would ever break.
> >> 
> >> However, when it comes to dwc3, we already have all the code necessary
> >> to workaround this issue by destroying the XHCI pdev when OTG interrupt
> >> says we should be peripheral (and vice-versa). DWC3 also keeps track of
> >> the OTG states for those folks who really care about OTG (Hint: nobody
> >> has cared for the past 10 years, why would they do so now?) and we don't
> >> need a SW state machine when the HW handles that for us, right?
> >> 
> >> As for chipidea, IIRC, that doesn't need a SW state machine either, but
> >> I know very little about that IP and don't even have documentation on
> >> it. My understanding, however, is that chipidea behaves kinda like MUSB,
> >> which changes roles automatically in HW based on ID pin state.
> >
> > Chipidea needs to set register for USB role manually.
> 
> okay, so chipidea has private control of role. Much like dwc3. That's good.
> 
> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> >> 
> >> >> do you really know of any platform which has a separate OTG controller?
> >> >> 
> >> >
> >> > Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, 
> >> > host
> >> > and gadget.
> >> >
> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> >> 
> >> that's not an OTG controller, it's just a mux. No different than Intel's
> >> mux for swapping between XHCI and peripheral-only DWC3.
> >> 
> >> frankly, I would NEVER talk about OTG when type-C comes into play. They
> >> are two competing standards and, apparently, type-C is winning when it
> >> comes to role-swapping.
> >> 
> >
> > In fact, OTG is mis-used by people. Currently, if the port is dual-role,
> > It will be considered as an OTG port.
> 
> That's because "dual-role" is a non-standard OTG. Seen as people really
> didn't care about OTG, we (linux-usb folks) ended up naturally referring
> to "non-standard OTG" as "dual-role". Just to avoid confusion.

So, unless we use OTG FSM defined in OTG spec, we should not mention
"OTG" in Linux, right?
 
> 
> > You are right, if the connector is type-c, it will be called as "type-c
> > port" by people :)
> 
> oh no, that's not what I'm talking about. If you read Type-C and PD
> specs, they define their own method for data role swapping. USB OTG
> doesn't fit on top of a Type-C environment. It's not about what people
> will call it, it's really that OTG can't work on top of type-c. For
> starters, there's no ID pin ;-)

I know type-c, yes, there is no relationship between OTG and type-c.

-- 

Best Regards,
Peter Chen

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Yoshihiro Shimoda  writes:
> Hi Roger,
>
>> From: Roger Quadros
>> Sent: Monday, June 20, 2016 7:13 PM
>> 
>> Hi,
>> 
>> On 20/06/16 10:45, Felipe Balbi wrote:
> < snip >
>> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> index f4fc0aa..1d74fb8 100644
>> >> --- a/include/linux/usb/gadget.h
>> >> +++ b/include/linux/usb/gadget.h
>> >> @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >>   * @in_epnum: last used in ep number
>> >>   * @mA: last set mA value
>> >>   * @otg_caps: OTG capabilities of this gadget.
>> >> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >
>> > do you really know of any platform which has a separate OTG controller?
>> >
>> 
>> Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, host
>> and gadget.
>> 
>> [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> 
>> Yoshihiro,
>> 
>> How is the dual-role architecture on your Renesas platform?
>
> About the dual-role architecture, Renesas platform (R-Car H3) has a
> USB 2.0 host controller (EHCI/OHCI) with OTG function and a separate
> USB 2.0 peripheral controller (HS-USB).  The OTG function is related
> to some PHY control registers, so I intend to add the OTG/Dual-role
> core support into the phy driver (drivers/phy/phy-rcar-gen3-usb2.c).

that looks like a mux to me :-) thanks for the pointer

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Yoshihiro Shimoda  writes:
> Hi Roger,
>
>> From: Roger Quadros
>> Sent: Monday, June 20, 2016 7:13 PM
>> 
>> Hi,
>> 
>> On 20/06/16 10:45, Felipe Balbi wrote:
> < snip >
>> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> index f4fc0aa..1d74fb8 100644
>> >> --- a/include/linux/usb/gadget.h
>> >> +++ b/include/linux/usb/gadget.h
>> >> @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >>   * @in_epnum: last used in ep number
>> >>   * @mA: last set mA value
>> >>   * @otg_caps: OTG capabilities of this gadget.
>> >> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >
>> > do you really know of any platform which has a separate OTG controller?
>> >
>> 
>> Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, host
>> and gadget.
>> 
>> [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> 
>> Yoshihiro,
>> 
>> How is the dual-role architecture on your Renesas platform?
>
> About the dual-role architecture, Renesas platform (R-Car H3) has a
> USB 2.0 host controller (EHCI/OHCI) with OTG function and a separate
> USB 2.0 peripheral controller (HS-USB).  The OTG function is related
> to some PHY control registers, so I intend to add the OTG/Dual-role
> core support into the phy driver (drivers/phy/phy-rcar-gen3-usb2.c).

that looks like a mux to me :-) thanks for the pointer

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> > It provides APIs for the following tasks
>> >> >
>> >> > - Registering an OTG/dual-role capable controller
>> >> > - Registering Host and Gadget controllers to OTG core
>> >> > - Providing inputs to and kicking the OTG state machine
>> >> 
>> >> I think I have already mentioned this, but after over 10 years of OTG,
>> >> nobody seems to care about it, why are we still touching at all I don't
>> >> know. For common non-OTG role-swapping we really don't need any of this
>> >> and, quite frankly, I fail to see enough users for this.
>> >> 
>> >> Apparently there's only chipidea which, AFAICT, already had working
>> >> dual-role before this OTG State Machine was added to the kernel.
>> >
>> > Some users would like to know if vendor's platform is OTG compliance,
>> > so we add it to pass usb.org USB OTG certification test.
>> 
>> I strongly doubt that's really what they mean. IMHO, users want to know
>> if they can swap roles. Ask them if they are really going for OTG
>> certification. Ask them if they have an OPT tester. Ask them if they
>> really want all those timers. If they want HNP polling, etc etc etc.
>> 
>> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> when they say OTG. Usually they just mean "a method for swapping between
>> host and peripheral roles, but we really don't want all the extra cost
>> of the OTG specification".
>> 
>
> That's what I thought before, but the request from the Marketing guy is
> "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> see the SoC reference manual say "it supports HNP and SRP"?
>
> If there is no request, who else wants to implement so complicated FSM
> but seldom use cases, and go to pass OTG compliance test (tested by PET).

I stand corrected :-)

So there is one user for this layer. And this user has its own role
control registers. I'm not convinced we need this large generic layer
for one user.

>> > For the real use case, some Carplay platforms need it.
>> 
>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> specification which is not OTG-compliant.
>> 
>
> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

> Notice, it needs to swap role without disconnect cable.

right, I can swap role without changing cable, but that's not OTG. The
mechanism for that, AFAICT, is not HNP. I don't know details about
CarPlay because the spec isn't public, but my understanding is that
CarPlay doesn't rely on anything from OTG spec.

>> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> > index f4fc0aa..1d74fb8 100644
>> >> > --- a/include/linux/usb/gadget.h
>> >> > +++ b/include/linux/usb/gadget.h
>> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >   * @in_epnum: last used in ep number
>> >> >   * @mA: last set mA value
>> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >> 
>> >> do you really know of any platform which has a separate OTG controller?
>> >> 
>> >
>> > It may not be a real separate OTG controller. It can be a hardware part
>> > (external connector, external IC, SoC OTG register area, etc) to handle 
>> > vbus
>> > ,id and other signals which are used for role swap.
>> 
>> That's already solved. EXTCON solved that years back and OMAP has been
>> using EXTCON to program its UTMI mailbox.
>> 
>
> No, that's not the same thing, it does not include the swap role.

Read your original comment:

"handle vbus, id and other signals which are *used for* role swap"

You didn't include role swap in your original comment. Semantics aside...

> Consider the use case the host driver is at host/ and udc driver is
> at gadget/udc, how to finish to role swap?

... why does the source code placement matter? And what do you mean by
"finish role swap"?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> > It provides APIs for the following tasks
>> >> >
>> >> > - Registering an OTG/dual-role capable controller
>> >> > - Registering Host and Gadget controllers to OTG core
>> >> > - Providing inputs to and kicking the OTG state machine
>> >> 
>> >> I think I have already mentioned this, but after over 10 years of OTG,
>> >> nobody seems to care about it, why are we still touching at all I don't
>> >> know. For common non-OTG role-swapping we really don't need any of this
>> >> and, quite frankly, I fail to see enough users for this.
>> >> 
>> >> Apparently there's only chipidea which, AFAICT, already had working
>> >> dual-role before this OTG State Machine was added to the kernel.
>> >
>> > Some users would like to know if vendor's platform is OTG compliance,
>> > so we add it to pass usb.org USB OTG certification test.
>> 
>> I strongly doubt that's really what they mean. IMHO, users want to know
>> if they can swap roles. Ask them if they are really going for OTG
>> certification. Ask them if they have an OPT tester. Ask them if they
>> really want all those timers. If they want HNP polling, etc etc etc.
>> 
>> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> when they say OTG. Usually they just mean "a method for swapping between
>> host and peripheral roles, but we really don't want all the extra cost
>> of the OTG specification".
>> 
>
> That's what I thought before, but the request from the Marketing guy is
> "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> see the SoC reference manual say "it supports HNP and SRP"?
>
> If there is no request, who else wants to implement so complicated FSM
> but seldom use cases, and go to pass OTG compliance test (tested by PET).

I stand corrected :-)

So there is one user for this layer. And this user has its own role
control registers. I'm not convinced we need this large generic layer
for one user.

>> > For the real use case, some Carplay platforms need it.
>> 
>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> specification which is not OTG-compliant.
>> 
>
> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

> Notice, it needs to swap role without disconnect cable.

right, I can swap role without changing cable, but that's not OTG. The
mechanism for that, AFAICT, is not HNP. I don't know details about
CarPlay because the spec isn't public, but my understanding is that
CarPlay doesn't rely on anything from OTG spec.

>> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> > index f4fc0aa..1d74fb8 100644
>> >> > --- a/include/linux/usb/gadget.h
>> >> > +++ b/include/linux/usb/gadget.h
>> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >   * @in_epnum: last used in ep number
>> >> >   * @mA: last set mA value
>> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >> 
>> >> do you really know of any platform which has a separate OTG controller?
>> >> 
>> >
>> > It may not be a real separate OTG controller. It can be a hardware part
>> > (external connector, external IC, SoC OTG register area, etc) to handle 
>> > vbus
>> > ,id and other signals which are used for role swap.
>> 
>> That's already solved. EXTCON solved that years back and OMAP has been
>> using EXTCON to program its UTMI mailbox.
>> 
>
> No, that's not the same thing, it does not include the swap role.

Read your original comment:

"handle vbus, id and other signals which are *used for* role swap"

You didn't include role swap in your original comment. Semantics aside...

> Consider the use case the host driver is at host/ and udc driver is
> at gadget/udc, how to finish to role swap?

... why does the source code placement matter? And what do you mean by
"finish role swap"?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >>> +
>> >>> +/* start host */
>> >>> +ret = hcd_ops->add(otg->primary_hcd.hcd,
>> >>> +   otg->primary_hcd.irqnum,
>> >>> +   otg->primary_hcd.irqflags);
>> >> 
>> >> this is usb_add_hcd(), is it not? Why add an indirection?
>> >
>> > I've introduced the host and gadget ops interface to get around the
>> > circular dependency issue we can't avoid.
>> > otg needs to call host/gadget functions and host/gadget also needs to
>> > call otg functions.
>> 
>> IMO, this shows a fragility of your design. You're, now, lying to
>> usb_hcd and usb_udc and making them register into a virtual layer that
>> doesn't exist. And that layer will end up calling the real registration
>> function when some magic event happens.
>> 
>> This is only really needed for quirky devices like dwc3 (but see more on
>> dwc3 below) where host and peripheral registers shadow each
>> other. Otherwise we would be able to always keep hcd and udc always
>> registered. They would get different interrupt statuses anyway and
>> nothing would ever break.
>> 
>> However, when it comes to dwc3, we already have all the code necessary
>> to workaround this issue by destroying the XHCI pdev when OTG interrupt
>> says we should be peripheral (and vice-versa). DWC3 also keeps track of
>> the OTG states for those folks who really care about OTG (Hint: nobody
>> has cared for the past 10 years, why would they do so now?) and we don't
>> need a SW state machine when the HW handles that for us, right?
>> 
>> As for chipidea, IIRC, that doesn't need a SW state machine either, but
>> I know very little about that IP and don't even have documentation on
>> it. My understanding, however, is that chipidea behaves kinda like MUSB,
>> which changes roles automatically in HW based on ID pin state.
>
> Chipidea needs to set register for USB role manually.

okay, so chipidea has private control of role. Much like dwc3. That's good.

>> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >> 
>> >> do you really know of any platform which has a separate OTG controller?
>> >> 
>> >
>> > Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, 
>> > host
>> > and gadget.
>> >
>> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> 
>> that's not an OTG controller, it's just a mux. No different than Intel's
>> mux for swapping between XHCI and peripheral-only DWC3.
>> 
>> frankly, I would NEVER talk about OTG when type-C comes into play. They
>> are two competing standards and, apparently, type-C is winning when it
>> comes to role-swapping.
>> 
>
> In fact, OTG is mis-used by people. Currently, if the port is dual-role,
> It will be considered as an OTG port.

That's because "dual-role" is a non-standard OTG. Seen as people really
didn't care about OTG, we (linux-usb folks) ended up naturally referring
to "non-standard OTG" as "dual-role". Just to avoid confusion.

> You are right, if the connector is type-c, it will be called as "type-c
> port" by people :)

oh no, that's not what I'm talking about. If you read Type-C and PD
specs, they define their own method for data role swapping. USB OTG
doesn't fit on top of a Type-C environment. It's not about what people
will call it, it's really that OTG can't work on top of type-c. For
starters, there's no ID pin ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >>> +
>> >>> +/* start host */
>> >>> +ret = hcd_ops->add(otg->primary_hcd.hcd,
>> >>> +   otg->primary_hcd.irqnum,
>> >>> +   otg->primary_hcd.irqflags);
>> >> 
>> >> this is usb_add_hcd(), is it not? Why add an indirection?
>> >
>> > I've introduced the host and gadget ops interface to get around the
>> > circular dependency issue we can't avoid.
>> > otg needs to call host/gadget functions and host/gadget also needs to
>> > call otg functions.
>> 
>> IMO, this shows a fragility of your design. You're, now, lying to
>> usb_hcd and usb_udc and making them register into a virtual layer that
>> doesn't exist. And that layer will end up calling the real registration
>> function when some magic event happens.
>> 
>> This is only really needed for quirky devices like dwc3 (but see more on
>> dwc3 below) where host and peripheral registers shadow each
>> other. Otherwise we would be able to always keep hcd and udc always
>> registered. They would get different interrupt statuses anyway and
>> nothing would ever break.
>> 
>> However, when it comes to dwc3, we already have all the code necessary
>> to workaround this issue by destroying the XHCI pdev when OTG interrupt
>> says we should be peripheral (and vice-versa). DWC3 also keeps track of
>> the OTG states for those folks who really care about OTG (Hint: nobody
>> has cared for the past 10 years, why would they do so now?) and we don't
>> need a SW state machine when the HW handles that for us, right?
>> 
>> As for chipidea, IIRC, that doesn't need a SW state machine either, but
>> I know very little about that IP and don't even have documentation on
>> it. My understanding, however, is that chipidea behaves kinda like MUSB,
>> which changes roles automatically in HW based on ID pin state.
>
> Chipidea needs to set register for USB role manually.

okay, so chipidea has private control of role. Much like dwc3. That's good.

>> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >> 
>> >> do you really know of any platform which has a separate OTG controller?
>> >> 
>> >
>> > Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, 
>> > host
>> > and gadget.
>> >
>> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> 
>> that's not an OTG controller, it's just a mux. No different than Intel's
>> mux for swapping between XHCI and peripheral-only DWC3.
>> 
>> frankly, I would NEVER talk about OTG when type-C comes into play. They
>> are two competing standards and, apparently, type-C is winning when it
>> comes to role-swapping.
>> 
>
> In fact, OTG is mis-used by people. Currently, if the port is dual-role,
> It will be considered as an OTG port.

That's because "dual-role" is a non-standard OTG. Seen as people really
didn't care about OTG, we (linux-usb folks) ended up naturally referring
to "non-standard OTG" as "dual-role". Just to avoid confusion.

> You are right, if the connector is type-c, it will be called as "type-c
> port" by people :)

oh no, that's not what I'm talking about. If you read Type-C and PD
specs, they define their own method for data role swapping. USB OTG
doesn't fit on top of a Type-C environment. It's not about what people
will call it, it's really that OTG can't work on top of type-c. For
starters, there's no ID pin ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 20, 2016 at 03:03:37PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> >>> +
> >>> + /* start host */
> >>> + ret = hcd_ops->add(otg->primary_hcd.hcd,
> >>> +otg->primary_hcd.irqnum,
> >>> +otg->primary_hcd.irqflags);
> >> 
> >> this is usb_add_hcd(), is it not? Why add an indirection?
> >
> > I've introduced the host and gadget ops interface to get around the
> > circular dependency issue we can't avoid.
> > otg needs to call host/gadget functions and host/gadget also needs to
> > call otg functions.
> 
> IMO, this shows a fragility of your design. You're, now, lying to
> usb_hcd and usb_udc and making them register into a virtual layer that
> doesn't exist. And that layer will end up calling the real registration
> function when some magic event happens.
> 
> This is only really needed for quirky devices like dwc3 (but see more on
> dwc3 below) where host and peripheral registers shadow each
> other. Otherwise we would be able to always keep hcd and udc always
> registered. They would get different interrupt statuses anyway and
> nothing would ever break.
> 
> However, when it comes to dwc3, we already have all the code necessary
> to workaround this issue by destroying the XHCI pdev when OTG interrupt
> says we should be peripheral (and vice-versa). DWC3 also keeps track of
> the OTG states for those folks who really care about OTG (Hint: nobody
> has cared for the past 10 years, why would they do so now?) and we don't
> need a SW state machine when the HW handles that for us, right?
> 
> As for chipidea, IIRC, that doesn't need a SW state machine either, but
> I know very little about that IP and don't even have documentation on
> it. My understanding, however, is that chipidea behaves kinda like MUSB,
> which changes roles automatically in HW based on ID pin state.

Chipidea needs to set register for USB role manually.

> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> 
> >> do you really know of any platform which has a separate OTG controller?
> >> 
> >
> > Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, 
> > host
> > and gadget.
> >
> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> 
> that's not an OTG controller, it's just a mux. No different than Intel's
> mux for swapping between XHCI and peripheral-only DWC3.
> 
> frankly, I would NEVER talk about OTG when type-C comes into play. They
> are two competing standards and, apparently, type-C is winning when it
> comes to role-swapping.
> 

In fact, OTG is mis-used by people. Currently, if the port is dual-role,
It will be considered as an OTG port.

You are right, if the connector is type-c, it will be called as "type-c
port" by people :)

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 20, 2016 at 03:03:37PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> >>> +
> >>> + /* start host */
> >>> + ret = hcd_ops->add(otg->primary_hcd.hcd,
> >>> +otg->primary_hcd.irqnum,
> >>> +otg->primary_hcd.irqflags);
> >> 
> >> this is usb_add_hcd(), is it not? Why add an indirection?
> >
> > I've introduced the host and gadget ops interface to get around the
> > circular dependency issue we can't avoid.
> > otg needs to call host/gadget functions and host/gadget also needs to
> > call otg functions.
> 
> IMO, this shows a fragility of your design. You're, now, lying to
> usb_hcd and usb_udc and making them register into a virtual layer that
> doesn't exist. And that layer will end up calling the real registration
> function when some magic event happens.
> 
> This is only really needed for quirky devices like dwc3 (but see more on
> dwc3 below) where host and peripheral registers shadow each
> other. Otherwise we would be able to always keep hcd and udc always
> registered. They would get different interrupt statuses anyway and
> nothing would ever break.
> 
> However, when it comes to dwc3, we already have all the code necessary
> to workaround this issue by destroying the XHCI pdev when OTG interrupt
> says we should be peripheral (and vice-versa). DWC3 also keeps track of
> the OTG states for those folks who really care about OTG (Hint: nobody
> has cared for the past 10 years, why would they do so now?) and we don't
> need a SW state machine when the HW handles that for us, right?
> 
> As for chipidea, IIRC, that doesn't need a SW state machine either, but
> I know very little about that IP and don't even have documentation on
> it. My understanding, however, is that chipidea behaves kinda like MUSB,
> which changes roles automatically in HW based on ID pin state.

Chipidea needs to set register for USB role manually.

> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> 
> >> do you really know of any platform which has a separate OTG controller?
> >> 
> >
> > Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, 
> > host
> > and gadget.
> >
> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> 
> that's not an OTG controller, it's just a mux. No different than Intel's
> mux for swapping between XHCI and peripheral-only DWC3.
> 
> frankly, I would NEVER talk about OTG when type-C comes into play. They
> are two competing standards and, apparently, type-C is winning when it
> comes to role-swapping.
> 

In fact, OTG is mis-used by people. Currently, if the port is dual-role,
It will be considered as an OTG port.

You are right, if the connector is type-c, it will be called as "type-c
port" by people :)

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 20, 2016 at 03:08:15PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> Roger Quadros  writes:
> >> > It provides APIs for the following tasks
> >> >
> >> > - Registering an OTG/dual-role capable controller
> >> > - Registering Host and Gadget controllers to OTG core
> >> > - Providing inputs to and kicking the OTG state machine
> >> 
> >> I think I have already mentioned this, but after over 10 years of OTG,
> >> nobody seems to care about it, why are we still touching at all I don't
> >> know. For common non-OTG role-swapping we really don't need any of this
> >> and, quite frankly, I fail to see enough users for this.
> >> 
> >> Apparently there's only chipidea which, AFAICT, already had working
> >> dual-role before this OTG State Machine was added to the kernel.
> >
> > Some users would like to know if vendor's platform is OTG compliance,
> > so we add it to pass usb.org USB OTG certification test.
> 
> I strongly doubt that's really what they mean. IMHO, users want to know
> if they can swap roles. Ask them if they are really going for OTG
> certification. Ask them if they have an OPT tester. Ask them if they
> really want all those timers. If they want HNP polling, etc etc etc.
> 
> So far, I haven't seen anybody talking about real USB OTG (the spec)
> when they say OTG. Usually they just mean "a method for swapping between
> host and peripheral roles, but we really don't want all the extra cost
> of the OTG specification".
> 

That's what I thought before, but the request from the Marketing guy is
"To prove the SoC is OTG compliance, support HNP and SRP", don't you
see the SoC reference manual say "it supports HNP and SRP"?

If there is no request, who else wants to implement so complicated FSM
but seldom use cases, and go to pass OTG compliance test (tested by PET).

> > For the real use case, some Carplay platforms need it.
> 
> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> specification which is not OTG-compliant.
> 

Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
states to finish role swap. Notice, it needs to swap role without
disconnect cable.

> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> > index f4fc0aa..1d74fb8 100644
> >> > --- a/include/linux/usb/gadget.h
> >> > +++ b/include/linux/usb/gadget.h
> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >> >   * @in_epnum: last used in ep number
> >> >   * @mA: last set mA value
> >> >   * @otg_caps: OTG capabilities of this gadget.
> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> 
> >> do you really know of any platform which has a separate OTG controller?
> >> 
> >
> > It may not be a real separate OTG controller. It can be a hardware part
> > (external connector, external IC, SoC OTG register area, etc) to handle vbus
> > ,id and other signals which are used for role swap.
> 
> That's already solved. EXTCON solved that years back and OMAP has been
> using EXTCON to program its UTMI mailbox.
> 

No, that's not the same thing, it does not include the swap role.
Consider the use case the host driver is at host/ and udc driver is
at gadget/udc, how to finish to role swap?

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 20, 2016 at 03:08:15PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> Roger Quadros  writes:
> >> > It provides APIs for the following tasks
> >> >
> >> > - Registering an OTG/dual-role capable controller
> >> > - Registering Host and Gadget controllers to OTG core
> >> > - Providing inputs to and kicking the OTG state machine
> >> 
> >> I think I have already mentioned this, but after over 10 years of OTG,
> >> nobody seems to care about it, why are we still touching at all I don't
> >> know. For common non-OTG role-swapping we really don't need any of this
> >> and, quite frankly, I fail to see enough users for this.
> >> 
> >> Apparently there's only chipidea which, AFAICT, already had working
> >> dual-role before this OTG State Machine was added to the kernel.
> >
> > Some users would like to know if vendor's platform is OTG compliance,
> > so we add it to pass usb.org USB OTG certification test.
> 
> I strongly doubt that's really what they mean. IMHO, users want to know
> if they can swap roles. Ask them if they are really going for OTG
> certification. Ask them if they have an OPT tester. Ask them if they
> really want all those timers. If they want HNP polling, etc etc etc.
> 
> So far, I haven't seen anybody talking about real USB OTG (the spec)
> when they say OTG. Usually they just mean "a method for swapping between
> host and peripheral roles, but we really don't want all the extra cost
> of the OTG specification".
> 

That's what I thought before, but the request from the Marketing guy is
"To prove the SoC is OTG compliance, support HNP and SRP", don't you
see the SoC reference manual say "it supports HNP and SRP"?

If there is no request, who else wants to implement so complicated FSM
but seldom use cases, and go to pass OTG compliance test (tested by PET).

> > For the real use case, some Carplay platforms need it.
> 
> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> specification which is not OTG-compliant.
> 

Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
states to finish role swap. Notice, it needs to swap role without
disconnect cable.

> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> > index f4fc0aa..1d74fb8 100644
> >> > --- a/include/linux/usb/gadget.h
> >> > +++ b/include/linux/usb/gadget.h
> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >> >   * @in_epnum: last used in ep number
> >> >   * @mA: last set mA value
> >> >   * @otg_caps: OTG capabilities of this gadget.
> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> 
> >> do you really know of any platform which has a separate OTG controller?
> >> 
> >
> > It may not be a real separate OTG controller. It can be a hardware part
> > (external connector, external IC, SoC OTG register area, etc) to handle vbus
> > ,id and other signals which are used for role swap.
> 
> That's already solved. EXTCON solved that years back and OMAP has been
> using EXTCON to program its UTMI mailbox.
> 

No, that's not the same thing, it does not include the swap role.
Consider the use case the host driver is at host/ and udc driver is
at gadget/udc, how to finish to role swap?

-- 

Best Regards,
Peter Chen

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi Roger,

> From: Roger Quadros
> Sent: Monday, June 20, 2016 7:13 PM
> 
> Hi,
> 
> On 20/06/16 10:45, Felipe Balbi wrote:
< snip >
> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> index f4fc0aa..1d74fb8 100644
> >> --- a/include/linux/usb/gadget.h
> >> +++ b/include/linux/usb/gadget.h
> >> @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >>   * @in_epnum: last used in ep number
> >>   * @mA: last set mA value
> >>   * @otg_caps: OTG capabilities of this gadget.
> >> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >
> > do you really know of any platform which has a separate OTG controller?
> >
> 
> Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, host
> and gadget.
> 
> [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> 
> Yoshihiro,
> 
> How is the dual-role architecture on your Renesas platform?

About the dual-role architecture, Renesas platform (R-Car H3) has a USB 2.0 
host controller (EHCI/OHCI)
with OTG function and a separate USB 2.0 peripheral controller (HS-USB).
The OTG function is related to some PHY control registers, so I intend to add 
the OTG/Dual-role core
support into the phy driver (drivers/phy/phy-rcar-gen3-usb2.c).

Best regards,
Yoshihiro Shimoda

RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi Roger,

> From: Roger Quadros
> Sent: Monday, June 20, 2016 7:13 PM
> 
> Hi,
> 
> On 20/06/16 10:45, Felipe Balbi wrote:
< snip >
> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> index f4fc0aa..1d74fb8 100644
> >> --- a/include/linux/usb/gadget.h
> >> +++ b/include/linux/usb/gadget.h
> >> @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >>   * @in_epnum: last used in ep number
> >>   * @mA: last set mA value
> >>   * @otg_caps: OTG capabilities of this gadget.
> >> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >
> > do you really know of any platform which has a separate OTG controller?
> >
> 
> Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, host
> and gadget.
> 
> [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
> 
> Yoshihiro,
> 
> How is the dual-role architecture on your Renesas platform?

About the dual-role architecture, Renesas platform (R-Car H3) has a USB 2.0 
host controller (EHCI/OHCI)
with OTG function and a separate USB 2.0 peripheral controller (HS-USB).
The OTG function is related to some PHY control registers, so I intend to add 
the OTG/Dual-role core
support into the phy driver (drivers/phy/phy-rcar-gen3-usb2.c).

Best regards,
Yoshihiro Shimoda

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
>  config USB_COMMON
>   tristate
>  
> +config USB_OTG_CORE
> + tristate

 why tristate if you can never set it to 'M'?
>>>
>>> This gets internally set to M if either USB or GADGET is M.
>>> We select it in USB and GADGET.
>>> This was the only way I could get usb-otg.c to build as
>>>
>>> m if USB OR GADGET is m
>>> built-in if USB and GADGET are built in.
>> 
>> I could only see a "select USB_OTG_CORE", select will always set it 'y'
>> and disregard dependencies. Maybe I missed something else.
>
> Not always. See how USB_COMMON works.

USB_COMMON is always 'y'. That could be changes a bool as well.

Do you have any defconfig where USB_COMMON or USB_OTG_CORE gets set to
'm'?

> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_hcd)
> + return 1;

 these seems inverted. If hcd->primary is NULL (meaning, there's no
 ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
 to explain?
>>>
>>> hcd->primary_hcd is a link used by the shared hcd to point to the
>>> primary_hcd.  primary_hcd's have this link as NULL.
>> 
>> So the following check is unnecessary and should always evaluate to
>> false, right ?
>
> Actually primary_hcd's not having a shared HCD have hcd->primary_hcd as NULL
> and those having a shared HCD do have it pointing to the primary hcd.

But look at your check:

is_primary(struct usb_hcd *hcd)
{
if (!hcd->primary_hcd)
return true;

return hcd == hcd->primary_hcd;
}

if you're passing a primary hcd, you're gonna return on the first
branch. If you're passing a secondary hcd, then your equality will
always be false. 

IOW, this can be reduced to:

is_primary(struct usb_hcd *hcd)
{
return !hcd->primary_hcd;
}

right?

> +int usb_otg_start_host(struct usb_otg *otg, int on)
> +{
> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
> + int ret;
> +
> + dev_dbg(otg->dev, "otg: %s %d\n", __func__, on);
> + if (!otg->host) {
> + WARN_ONCE(1, "otg: fsm running without host\n");

 if (WARN_ONCE(!otg->host, "otg: fsm running without host\n"))
return 0;

 but, frankly, if you require a 'host' and a 'gadget' don't start this
 layer until you have both.
>>>
>>> We don't start the layer till we have both host and gadget. But
>>> this API is for external use and might be called at any time.
>> 
>> well, if callers call this at the wrong time, it's callers' fault. Let
>> them oops so we catch the error.
>
> So you suggest we allow a NULL pointer dereference here?

yes, it's a clear violation of the API contract. The only situation
where this would ever trigger, is if somebody is calling
usb_otg_start_host() without calling start_fsm() first. That shouldn't
be valid.

> + return 0;
> + }
> +
> + if (on) {
> + if (otg->flags & OTG_FLAG_HOST_RUNNING)
> + return 0;
> +
> + /* start host */
> + ret = hcd_ops->add(otg->primary_hcd.hcd,
> +otg->primary_hcd.irqnum,
> +otg->primary_hcd.irqflags);

 this is usb_add_hcd(), is it not? Why add an indirection?
>>>
>>> I've introduced the host and gadget ops interface to get around the
>>> circular dependency issue we can't avoid.
>>> otg needs to call host/gadget functions and host/gadget also needs to
>>> call otg functions.
>> 
>> IMO, this shows a fragility of your design. You're, now, lying to
>> usb_hcd and usb_udc and making them register into a virtual layer that
>> doesn't exist. And that layer will end up calling the real registration
>> function when some magic event happens.
>> 
>> This is only really needed for quirky devices like dwc3 (but see more on
>> dwc3 below) where host and peripheral registers shadow each
>> other. Otherwise we would be able to always keep hcd and udc always
>> registered. They would get different interrupt statuses anyway and
>> nothing would ever break.
>
> Well I only had the opportunity to work with dwc3 so I had to ensure
> the design worked with it.

but this is exactly what I'm pointing you to. DWC3 does not need to go
through this because the HW maintains state machine for you.

>> However, when it comes to dwc3, we already have all the code necessary
>> to workaround this issue by destroying the XHCI pdev when OTG interrupt
>> says we should be peripheral (and vice-versa). DWC3 also keeps track of
>> the OTG states for those folks who really care about OTG (Hint: nobody
>> has cared for the past 10 years, why would they do so now?) and we don't
>> need a SW 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
>  config USB_COMMON
>   tristate
>  
> +config USB_OTG_CORE
> + tristate

 why tristate if you can never set it to 'M'?
>>>
>>> This gets internally set to M if either USB or GADGET is M.
>>> We select it in USB and GADGET.
>>> This was the only way I could get usb-otg.c to build as
>>>
>>> m if USB OR GADGET is m
>>> built-in if USB and GADGET are built in.
>> 
>> I could only see a "select USB_OTG_CORE", select will always set it 'y'
>> and disregard dependencies. Maybe I missed something else.
>
> Not always. See how USB_COMMON works.

USB_COMMON is always 'y'. That could be changes a bool as well.

Do you have any defconfig where USB_COMMON or USB_OTG_CORE gets set to
'm'?

> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_hcd)
> + return 1;

 these seems inverted. If hcd->primary is NULL (meaning, there's no
 ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
 to explain?
>>>
>>> hcd->primary_hcd is a link used by the shared hcd to point to the
>>> primary_hcd.  primary_hcd's have this link as NULL.
>> 
>> So the following check is unnecessary and should always evaluate to
>> false, right ?
>
> Actually primary_hcd's not having a shared HCD have hcd->primary_hcd as NULL
> and those having a shared HCD do have it pointing to the primary hcd.

But look at your check:

is_primary(struct usb_hcd *hcd)
{
if (!hcd->primary_hcd)
return true;

return hcd == hcd->primary_hcd;
}

if you're passing a primary hcd, you're gonna return on the first
branch. If you're passing a secondary hcd, then your equality will
always be false. 

IOW, this can be reduced to:

is_primary(struct usb_hcd *hcd)
{
return !hcd->primary_hcd;
}

right?

> +int usb_otg_start_host(struct usb_otg *otg, int on)
> +{
> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
> + int ret;
> +
> + dev_dbg(otg->dev, "otg: %s %d\n", __func__, on);
> + if (!otg->host) {
> + WARN_ONCE(1, "otg: fsm running without host\n");

 if (WARN_ONCE(!otg->host, "otg: fsm running without host\n"))
return 0;

 but, frankly, if you require a 'host' and a 'gadget' don't start this
 layer until you have both.
>>>
>>> We don't start the layer till we have both host and gadget. But
>>> this API is for external use and might be called at any time.
>> 
>> well, if callers call this at the wrong time, it's callers' fault. Let
>> them oops so we catch the error.
>
> So you suggest we allow a NULL pointer dereference here?

yes, it's a clear violation of the API contract. The only situation
where this would ever trigger, is if somebody is calling
usb_otg_start_host() without calling start_fsm() first. That shouldn't
be valid.

> + return 0;
> + }
> +
> + if (on) {
> + if (otg->flags & OTG_FLAG_HOST_RUNNING)
> + return 0;
> +
> + /* start host */
> + ret = hcd_ops->add(otg->primary_hcd.hcd,
> +otg->primary_hcd.irqnum,
> +otg->primary_hcd.irqflags);

 this is usb_add_hcd(), is it not? Why add an indirection?
>>>
>>> I've introduced the host and gadget ops interface to get around the
>>> circular dependency issue we can't avoid.
>>> otg needs to call host/gadget functions and host/gadget also needs to
>>> call otg functions.
>> 
>> IMO, this shows a fragility of your design. You're, now, lying to
>> usb_hcd and usb_udc and making them register into a virtual layer that
>> doesn't exist. And that layer will end up calling the real registration
>> function when some magic event happens.
>> 
>> This is only really needed for quirky devices like dwc3 (but see more on
>> dwc3 below) where host and peripheral registers shadow each
>> other. Otherwise we would be able to always keep hcd and udc always
>> registered. They would get different interrupt statuses anyway and
>> nothing would ever break.
>
> Well I only had the opportunity to work with dwc3 so I had to ensure
> the design worked with it.

but this is exactly what I'm pointing you to. DWC3 does not need to go
through this because the HW maintains state machine for you.

>> However, when it comes to dwc3, we already have all the code necessary
>> to workaround this issue by destroying the XHCI pdev when OTG interrupt
>> says we should be peripheral (and vice-versa). DWC3 also keeps track of
>> the OTG states for those folks who really care about OTG (Hint: nobody
>> has cared for the past 10 years, why would they do so now?) and we don't
>> need a SW state machine when 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

On 20/06/16 15:03, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>>> Roger Quadros  writes:
 It provides APIs for the following tasks

 - Registering an OTG/dual-role capable controller
 - Registering Host and Gadget controllers to OTG core
 - Providing inputs to and kicking the OTG state machine
>>>
>>> I think I have already mentioned this, but after over 10 years of OTG,
>>> nobody seems to care about it, why are we still touching at all I don't
>>> know. For common non-OTG role-swapping we really don't need any of this
>>> and, quite frankly, I fail to see enough users for this.
>>>
>>> Apparently there's only chipidea which, AFAICT, already had working
>>> dual-role before this OTG State Machine was added to the kernel.
>>>
 Provide a dual-role device (DRD) state machine.
>>>
>>> there's not such thing as DRD state machine. You don't need to go
>>> through all these states, actually.
>>
>> There are 3 states though.
>> HOST (id = 0)
>> PERIPHERAL (id = 1, vbus = 1)
>> IDLE (id = 1, vbus = 0).
> 
> IDLE is pretty much given, though ;-)
> 
 DRD mode is a reduced functionality OTG mode. In this mode
 we don't support SRP, HNP and dynamic role-swap.

 In DRD operation, the controller mode (Host or Peripheral)
 is decided based on the ID pin status. Once a cable plug (Type-A
 or Type-B) is attached the controller selects the state
 and doesn't change till the cable in unplugged and a different
 cable type is inserted.

 As we don't need most of the complex OTG states and OTG timers
 we implement a lean DRD state machine in usb-otg.c.
 The DRD state machine is only interested in 2 hardware inputs
 'id' and 'b_sess_vld'.

 Signed-off-by: Roger Quadros 
 ---
 v11:
 - remove usb_otg_kick_fsm().
 - typo fixes: structa/structure, upto/up to.
 - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.

  drivers/usb/Kconfig  |  18 +
  drivers/usb/common/Makefile  |   6 +-
  drivers/usb/common/usb-otg.c | 877 
 +++
  drivers/usb/core/Kconfig |  14 -
  drivers/usb/gadget/Kconfig   |   1 +
  include/linux/usb/gadget.h   |   2 +
  include/linux/usb/hcd.h  |   1 +
  include/linux/usb/otg-fsm.h  |   7 +
  include/linux/usb/otg.h  | 174 -
  9 files changed, 1070 insertions(+), 30 deletions(-)
  create mode 100644 drivers/usb/common/usb-otg.c

 diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
 index 8689dcb..ed596ec 100644
 --- a/drivers/usb/Kconfig
 +++ b/drivers/usb/Kconfig
 @@ -32,6 +32,23 @@ if USB_SUPPORT
  config USB_COMMON
tristate
  
 +config USB_OTG_CORE
 +  tristate
>>>
>>> why tristate if you can never set it to 'M'?
>>
>> This gets internally set to M if either USB or GADGET is M.
>> We select it in USB and GADGET.
>> This was the only way I could get usb-otg.c to build as
>>
>> m if USB OR GADGET is m
>> built-in if USB and GADGET are built in.
> 
> I could only see a "select USB_OTG_CORE", select will always set it 'y'
> and disregard dependencies. Maybe I missed something else.

Not always. See how USB_COMMON works.
> 
 diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
 new file mode 100644
 index 000..a23ab1e
 --- /dev/null
 +++ b/drivers/usb/common/usb-otg.c
 @@ -0,0 +1,877 @@
 +/**
 + * drivers/usb/common/usb-otg.c - USB OTG core
 + *
 + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
 + * Author: Roger Quadros 
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +/* OTG device list */
 +LIST_HEAD(otg_list);
>>>
>>> not static? Who needs to touch this private list?
>>
>> right, it should be static.
>>
>>>
 +static DEFINE_MUTEX(otg_list_mutex);
 +
 +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
 +{
 +  if (!hcd->primary_hcd)
 +  return 1;
>>>
>>> these seems inverted. If hcd->primary is NULL (meaning, there's no
>>> ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
>>> to explain?
>>
>> hcd->primary_hcd is a link used by the shared hcd to point to the
>> primary_hcd.  primary_hcd's have 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

On 20/06/16 15:03, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>>> Roger Quadros  writes:
 It provides APIs for the following tasks

 - Registering an OTG/dual-role capable controller
 - Registering Host and Gadget controllers to OTG core
 - Providing inputs to and kicking the OTG state machine
>>>
>>> I think I have already mentioned this, but after over 10 years of OTG,
>>> nobody seems to care about it, why are we still touching at all I don't
>>> know. For common non-OTG role-swapping we really don't need any of this
>>> and, quite frankly, I fail to see enough users for this.
>>>
>>> Apparently there's only chipidea which, AFAICT, already had working
>>> dual-role before this OTG State Machine was added to the kernel.
>>>
 Provide a dual-role device (DRD) state machine.
>>>
>>> there's not such thing as DRD state machine. You don't need to go
>>> through all these states, actually.
>>
>> There are 3 states though.
>> HOST (id = 0)
>> PERIPHERAL (id = 1, vbus = 1)
>> IDLE (id = 1, vbus = 0).
> 
> IDLE is pretty much given, though ;-)
> 
 DRD mode is a reduced functionality OTG mode. In this mode
 we don't support SRP, HNP and dynamic role-swap.

 In DRD operation, the controller mode (Host or Peripheral)
 is decided based on the ID pin status. Once a cable plug (Type-A
 or Type-B) is attached the controller selects the state
 and doesn't change till the cable in unplugged and a different
 cable type is inserted.

 As we don't need most of the complex OTG states and OTG timers
 we implement a lean DRD state machine in usb-otg.c.
 The DRD state machine is only interested in 2 hardware inputs
 'id' and 'b_sess_vld'.

 Signed-off-by: Roger Quadros 
 ---
 v11:
 - remove usb_otg_kick_fsm().
 - typo fixes: structa/structure, upto/up to.
 - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.

  drivers/usb/Kconfig  |  18 +
  drivers/usb/common/Makefile  |   6 +-
  drivers/usb/common/usb-otg.c | 877 
 +++
  drivers/usb/core/Kconfig |  14 -
  drivers/usb/gadget/Kconfig   |   1 +
  include/linux/usb/gadget.h   |   2 +
  include/linux/usb/hcd.h  |   1 +
  include/linux/usb/otg-fsm.h  |   7 +
  include/linux/usb/otg.h  | 174 -
  9 files changed, 1070 insertions(+), 30 deletions(-)
  create mode 100644 drivers/usb/common/usb-otg.c

 diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
 index 8689dcb..ed596ec 100644
 --- a/drivers/usb/Kconfig
 +++ b/drivers/usb/Kconfig
 @@ -32,6 +32,23 @@ if USB_SUPPORT
  config USB_COMMON
tristate
  
 +config USB_OTG_CORE
 +  tristate
>>>
>>> why tristate if you can never set it to 'M'?
>>
>> This gets internally set to M if either USB or GADGET is M.
>> We select it in USB and GADGET.
>> This was the only way I could get usb-otg.c to build as
>>
>> m if USB OR GADGET is m
>> built-in if USB and GADGET are built in.
> 
> I could only see a "select USB_OTG_CORE", select will always set it 'y'
> and disregard dependencies. Maybe I missed something else.

Not always. See how USB_COMMON works.
> 
 diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
 new file mode 100644
 index 000..a23ab1e
 --- /dev/null
 +++ b/drivers/usb/common/usb-otg.c
 @@ -0,0 +1,877 @@
 +/**
 + * drivers/usb/common/usb-otg.c - USB OTG core
 + *
 + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
 + * Author: Roger Quadros 
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +/* OTG device list */
 +LIST_HEAD(otg_list);
>>>
>>> not static? Who needs to touch this private list?
>>
>> right, it should be static.
>>
>>>
 +static DEFINE_MUTEX(otg_list_mutex);
 +
 +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
 +{
 +  if (!hcd->primary_hcd)
 +  return 1;
>>>
>>> these seems inverted. If hcd->primary is NULL (meaning, there's no
>>> ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
>>> to explain?
>>
>> hcd->primary_hcd is a link used by the shared hcd to point to the
>> primary_hcd.  primary_hcd's have this link as NULL.
> 
> So the following check is unnecessary 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> Roger Quadros  writes:
>>> It provides APIs for the following tasks
>>>
>>> - Registering an OTG/dual-role capable controller
>>> - Registering Host and Gadget controllers to OTG core
>>> - Providing inputs to and kicking the OTG state machine
>> 
>> I think I have already mentioned this, but after over 10 years of OTG,
>> nobody seems to care about it, why are we still touching at all I don't
>> know. For common non-OTG role-swapping we really don't need any of this
>> and, quite frankly, I fail to see enough users for this.
>> 
>> Apparently there's only chipidea which, AFAICT, already had working
>> dual-role before this OTG State Machine was added to the kernel.
>> 
>>> Provide a dual-role device (DRD) state machine.
>> 
>> there's not such thing as DRD state machine. You don't need to go
>> through all these states, actually.
>
> There are 3 states though.
> HOST (id = 0)
> PERIPHERAL (id = 1, vbus = 1)
> IDLE (id = 1, vbus = 0).

IDLE is pretty much given, though ;-)

>>> DRD mode is a reduced functionality OTG mode. In this mode
>>> we don't support SRP, HNP and dynamic role-swap.
>>>
>>> In DRD operation, the controller mode (Host or Peripheral)
>>> is decided based on the ID pin status. Once a cable plug (Type-A
>>> or Type-B) is attached the controller selects the state
>>> and doesn't change till the cable in unplugged and a different
>>> cable type is inserted.
>>>
>>> As we don't need most of the complex OTG states and OTG timers
>>> we implement a lean DRD state machine in usb-otg.c.
>>> The DRD state machine is only interested in 2 hardware inputs
>>> 'id' and 'b_sess_vld'.
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>> v11:
>>> - remove usb_otg_kick_fsm().
>>> - typo fixes: structa/structure, upto/up to.
>>> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
>>>
>>>  drivers/usb/Kconfig  |  18 +
>>>  drivers/usb/common/Makefile  |   6 +-
>>>  drivers/usb/common/usb-otg.c | 877 
>>> +++
>>>  drivers/usb/core/Kconfig |  14 -
>>>  drivers/usb/gadget/Kconfig   |   1 +
>>>  include/linux/usb/gadget.h   |   2 +
>>>  include/linux/usb/hcd.h  |   1 +
>>>  include/linux/usb/otg-fsm.h  |   7 +
>>>  include/linux/usb/otg.h  | 174 -
>>>  9 files changed, 1070 insertions(+), 30 deletions(-)
>>>  create mode 100644 drivers/usb/common/usb-otg.c
>>>
>>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>>> index 8689dcb..ed596ec 100644
>>> --- a/drivers/usb/Kconfig
>>> +++ b/drivers/usb/Kconfig
>>> @@ -32,6 +32,23 @@ if USB_SUPPORT
>>>  config USB_COMMON
>>> tristate
>>>  
>>> +config USB_OTG_CORE
>>> +   tristate
>> 
>> why tristate if you can never set it to 'M'?
>
> This gets internally set to M if either USB or GADGET is M.
> We select it in USB and GADGET.
> This was the only way I could get usb-otg.c to build as
>
> m if USB OR GADGET is m
> built-in if USB and GADGET are built in.

I could only see a "select USB_OTG_CORE", select will always set it 'y'
and disregard dependencies. Maybe I missed something else.

>>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>>> new file mode 100644
>>> index 000..a23ab1e
>>> --- /dev/null
>>> +++ b/drivers/usb/common/usb-otg.c
>>> @@ -0,0 +1,877 @@
>>> +/**
>>> + * drivers/usb/common/usb-otg.c - USB OTG core
>>> + *
>>> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
>>> + * Author: Roger Quadros 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* OTG device list */
>>> +LIST_HEAD(otg_list);
>> 
>> not static? Who needs to touch this private list?
>
> right, it should be static.
>
>> 
>>> +static DEFINE_MUTEX(otg_list_mutex);
>>> +
>>> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
>>> +{
>>> +   if (!hcd->primary_hcd)
>>> +   return 1;
>> 
>> these seems inverted. If hcd->primary is NULL (meaning, there's no
>> ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
>> to explain?
>
> hcd->primary_hcd is a link used by the shared hcd to point to the
> primary_hcd.  primary_hcd's have this link as NULL.

So the following check is unnecessary and should always evaluate to
false, right ?

>>> +   return hcd == hcd->primary_hcd;
>>> +}
>>> +
>>> +/**
>>> + * usb_otg_get_data() - get usb_otg data 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> Roger Quadros  writes:
>>> It provides APIs for the following tasks
>>>
>>> - Registering an OTG/dual-role capable controller
>>> - Registering Host and Gadget controllers to OTG core
>>> - Providing inputs to and kicking the OTG state machine
>> 
>> I think I have already mentioned this, but after over 10 years of OTG,
>> nobody seems to care about it, why are we still touching at all I don't
>> know. For common non-OTG role-swapping we really don't need any of this
>> and, quite frankly, I fail to see enough users for this.
>> 
>> Apparently there's only chipidea which, AFAICT, already had working
>> dual-role before this OTG State Machine was added to the kernel.
>> 
>>> Provide a dual-role device (DRD) state machine.
>> 
>> there's not such thing as DRD state machine. You don't need to go
>> through all these states, actually.
>
> There are 3 states though.
> HOST (id = 0)
> PERIPHERAL (id = 1, vbus = 1)
> IDLE (id = 1, vbus = 0).

IDLE is pretty much given, though ;-)

>>> DRD mode is a reduced functionality OTG mode. In this mode
>>> we don't support SRP, HNP and dynamic role-swap.
>>>
>>> In DRD operation, the controller mode (Host or Peripheral)
>>> is decided based on the ID pin status. Once a cable plug (Type-A
>>> or Type-B) is attached the controller selects the state
>>> and doesn't change till the cable in unplugged and a different
>>> cable type is inserted.
>>>
>>> As we don't need most of the complex OTG states and OTG timers
>>> we implement a lean DRD state machine in usb-otg.c.
>>> The DRD state machine is only interested in 2 hardware inputs
>>> 'id' and 'b_sess_vld'.
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>> v11:
>>> - remove usb_otg_kick_fsm().
>>> - typo fixes: structa/structure, upto/up to.
>>> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
>>>
>>>  drivers/usb/Kconfig  |  18 +
>>>  drivers/usb/common/Makefile  |   6 +-
>>>  drivers/usb/common/usb-otg.c | 877 
>>> +++
>>>  drivers/usb/core/Kconfig |  14 -
>>>  drivers/usb/gadget/Kconfig   |   1 +
>>>  include/linux/usb/gadget.h   |   2 +
>>>  include/linux/usb/hcd.h  |   1 +
>>>  include/linux/usb/otg-fsm.h  |   7 +
>>>  include/linux/usb/otg.h  | 174 -
>>>  9 files changed, 1070 insertions(+), 30 deletions(-)
>>>  create mode 100644 drivers/usb/common/usb-otg.c
>>>
>>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>>> index 8689dcb..ed596ec 100644
>>> --- a/drivers/usb/Kconfig
>>> +++ b/drivers/usb/Kconfig
>>> @@ -32,6 +32,23 @@ if USB_SUPPORT
>>>  config USB_COMMON
>>> tristate
>>>  
>>> +config USB_OTG_CORE
>>> +   tristate
>> 
>> why tristate if you can never set it to 'M'?
>
> This gets internally set to M if either USB or GADGET is M.
> We select it in USB and GADGET.
> This was the only way I could get usb-otg.c to build as
>
> m if USB OR GADGET is m
> built-in if USB and GADGET are built in.

I could only see a "select USB_OTG_CORE", select will always set it 'y'
and disregard dependencies. Maybe I missed something else.

>>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>>> new file mode 100644
>>> index 000..a23ab1e
>>> --- /dev/null
>>> +++ b/drivers/usb/common/usb-otg.c
>>> @@ -0,0 +1,877 @@
>>> +/**
>>> + * drivers/usb/common/usb-otg.c - USB OTG core
>>> + *
>>> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
>>> + * Author: Roger Quadros 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* OTG device list */
>>> +LIST_HEAD(otg_list);
>> 
>> not static? Who needs to touch this private list?
>
> right, it should be static.
>
>> 
>>> +static DEFINE_MUTEX(otg_list_mutex);
>>> +
>>> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
>>> +{
>>> +   if (!hcd->primary_hcd)
>>> +   return 1;
>> 
>> these seems inverted. If hcd->primary is NULL (meaning, there's no
>> ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
>> to explain?
>
> hcd->primary_hcd is a link used by the shared hcd to point to the
> primary_hcd.  primary_hcd's have this link as NULL.

So the following check is unnecessary and should always evaluate to
false, right ?

>>> +   return hcd == hcd->primary_hcd;
>>> +}
>>> +
>>> +/**
>>> + * usb_otg_get_data() - get usb_otg data structure
>>> + * @otg_dev:   OTG controller device
>>> + *
>>> 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> Roger Quadros  writes:
>> > It provides APIs for the following tasks
>> >
>> > - Registering an OTG/dual-role capable controller
>> > - Registering Host and Gadget controllers to OTG core
>> > - Providing inputs to and kicking the OTG state machine
>> 
>> I think I have already mentioned this, but after over 10 years of OTG,
>> nobody seems to care about it, why are we still touching at all I don't
>> know. For common non-OTG role-swapping we really don't need any of this
>> and, quite frankly, I fail to see enough users for this.
>> 
>> Apparently there's only chipidea which, AFAICT, already had working
>> dual-role before this OTG State Machine was added to the kernel.
>
> Some users would like to know if vendor's platform is OTG compliance,
> so we add it to pass usb.org USB OTG certification test.

I strongly doubt that's really what they mean. IMHO, users want to know
if they can swap roles. Ask them if they are really going for OTG
certification. Ask them if they have an OPT tester. Ask them if they
really want all those timers. If they want HNP polling, etc etc etc.

So far, I haven't seen anybody talking about real USB OTG (the spec)
when they say OTG. Usually they just mean "a method for swapping between
host and peripheral roles, but we really don't want all the extra cost
of the OTG specification".

> For the real use case, some Carplay platforms need it.

Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
specification which is not OTG-compliant.

>> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> > index f4fc0aa..1d74fb8 100644
>> > --- a/include/linux/usb/gadget.h
>> > +++ b/include/linux/usb/gadget.h
>> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >   * @in_epnum: last used in ep number
>> >   * @mA: last set mA value
>> >   * @otg_caps: OTG capabilities of this gadget.
>> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> 
>> do you really know of any platform which has a separate OTG controller?
>> 
>
> It may not be a real separate OTG controller. It can be a hardware part
> (external connector, external IC, SoC OTG register area, etc) to handle vbus
> ,id and other signals which are used for role swap.

That's already solved. EXTCON solved that years back and OMAP has been
using EXTCON to program its UTMI mailbox.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> Roger Quadros  writes:
>> > It provides APIs for the following tasks
>> >
>> > - Registering an OTG/dual-role capable controller
>> > - Registering Host and Gadget controllers to OTG core
>> > - Providing inputs to and kicking the OTG state machine
>> 
>> I think I have already mentioned this, but after over 10 years of OTG,
>> nobody seems to care about it, why are we still touching at all I don't
>> know. For common non-OTG role-swapping we really don't need any of this
>> and, quite frankly, I fail to see enough users for this.
>> 
>> Apparently there's only chipidea which, AFAICT, already had working
>> dual-role before this OTG State Machine was added to the kernel.
>
> Some users would like to know if vendor's platform is OTG compliance,
> so we add it to pass usb.org USB OTG certification test.

I strongly doubt that's really what they mean. IMHO, users want to know
if they can swap roles. Ask them if they are really going for OTG
certification. Ask them if they have an OPT tester. Ask them if they
really want all those timers. If they want HNP polling, etc etc etc.

So far, I haven't seen anybody talking about real USB OTG (the spec)
when they say OTG. Usually they just mean "a method for swapping between
host and peripheral roles, but we really don't want all the extra cost
of the OTG specification".

> For the real use case, some Carplay platforms need it.

Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
specification which is not OTG-compliant.

>> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> > index f4fc0aa..1d74fb8 100644
>> > --- a/include/linux/usb/gadget.h
>> > +++ b/include/linux/usb/gadget.h
>> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >   * @in_epnum: last used in ep number
>> >   * @mA: last set mA value
>> >   * @otg_caps: OTG capabilities of this gadget.
>> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> 
>> do you really know of any platform which has a separate OTG controller?
>> 
>
> It may not be a real separate OTG controller. It can be a hardware part
> (external connector, external IC, SoC OTG register area, etc) to handle vbus
> ,id and other signals which are used for role swap.

That's already solved. EXTCON solved that years back and OMAP has been
using EXTCON to program its UTMI mailbox.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 20, 2016 at 10:45:31AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
> > It provides APIs for the following tasks
> >
> > - Registering an OTG/dual-role capable controller
> > - Registering Host and Gadget controllers to OTG core
> > - Providing inputs to and kicking the OTG state machine
> 
> I think I have already mentioned this, but after over 10 years of OTG,
> nobody seems to care about it, why are we still touching at all I don't
> know. For common non-OTG role-swapping we really don't need any of this
> and, quite frankly, I fail to see enough users for this.
> 
> Apparently there's only chipidea which, AFAICT, already had working
> dual-role before this OTG State Machine was added to the kernel.

Some users would like to know if vendor's platform is OTG compliance,
so we add it to pass usb.org USB OTG certification test.

For the real use case, some Carplay platforms need it.

> 
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index f4fc0aa..1d74fb8 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >   * @in_epnum: last used in ep number
> >   * @mA: last set mA value
> >   * @otg_caps: OTG capabilities of this gadget.
> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> 
> do you really know of any platform which has a separate OTG controller?
> 

It may not be a real separate OTG controller. It can be a hardware part
(external connector, external IC, SoC OTG register area, etc) to handle vbus
,id and other signals which are used for role swap.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 20, 2016 at 10:45:31AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
> > It provides APIs for the following tasks
> >
> > - Registering an OTG/dual-role capable controller
> > - Registering Host and Gadget controllers to OTG core
> > - Providing inputs to and kicking the OTG state machine
> 
> I think I have already mentioned this, but after over 10 years of OTG,
> nobody seems to care about it, why are we still touching at all I don't
> know. For common non-OTG role-swapping we really don't need any of this
> and, quite frankly, I fail to see enough users for this.
> 
> Apparently there's only chipidea which, AFAICT, already had working
> dual-role before this OTG State Machine was added to the kernel.

Some users would like to know if vendor's platform is OTG compliance,
so we add it to pass usb.org USB OTG certification test.

For the real use case, some Carplay platforms need it.

> 
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index f4fc0aa..1d74fb8 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >   * @in_epnum: last used in ep number
> >   * @mA: last set mA value
> >   * @otg_caps: OTG capabilities of this gadget.
> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> 
> do you really know of any platform which has a separate OTG controller?
> 

It may not be a real separate OTG controller. It can be a hardware part
(external connector, external IC, SoC OTG register area, etc) to handle vbus
,id and other signals which are used for role swap.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Hi,

On 20/06/16 10:45, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> It provides APIs for the following tasks
>>
>> - Registering an OTG/dual-role capable controller
>> - Registering Host and Gadget controllers to OTG core
>> - Providing inputs to and kicking the OTG state machine
> 
> I think I have already mentioned this, but after over 10 years of OTG,
> nobody seems to care about it, why are we still touching at all I don't
> know. For common non-OTG role-swapping we really don't need any of this
> and, quite frankly, I fail to see enough users for this.
> 
> Apparently there's only chipidea which, AFAICT, already had working
> dual-role before this OTG State Machine was added to the kernel.
> 
>> Provide a dual-role device (DRD) state machine.
> 
> there's not such thing as DRD state machine. You don't need to go
> through all these states, actually.

There are 3 states though.
HOST (id = 0)
PERIPHERAL (id = 1, vbus = 1)
IDLE (id = 1, vbus = 0).

> 
>> DRD mode is a reduced functionality OTG mode. In this mode
>> we don't support SRP, HNP and dynamic role-swap.
>>
>> In DRD operation, the controller mode (Host or Peripheral)
>> is decided based on the ID pin status. Once a cable plug (Type-A
>> or Type-B) is attached the controller selects the state
>> and doesn't change till the cable in unplugged and a different
>> cable type is inserted.
>>
>> As we don't need most of the complex OTG states and OTG timers
>> we implement a lean DRD state machine in usb-otg.c.
>> The DRD state machine is only interested in 2 hardware inputs
>> 'id' and 'b_sess_vld'.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>> v11:
>> - remove usb_otg_kick_fsm().
>> - typo fixes: structa/structure, upto/up to.
>> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
>>
>>  drivers/usb/Kconfig  |  18 +
>>  drivers/usb/common/Makefile  |   6 +-
>>  drivers/usb/common/usb-otg.c | 877 
>> +++
>>  drivers/usb/core/Kconfig |  14 -
>>  drivers/usb/gadget/Kconfig   |   1 +
>>  include/linux/usb/gadget.h   |   2 +
>>  include/linux/usb/hcd.h  |   1 +
>>  include/linux/usb/otg-fsm.h  |   7 +
>>  include/linux/usb/otg.h  | 174 -
>>  9 files changed, 1070 insertions(+), 30 deletions(-)
>>  create mode 100644 drivers/usb/common/usb-otg.c
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index 8689dcb..ed596ec 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -32,6 +32,23 @@ if USB_SUPPORT
>>  config USB_COMMON
>>  tristate
>>  
>> +config USB_OTG_CORE
>> +tristate
> 
> why tristate if you can never set it to 'M'?

This gets internally set to M if either USB or GADGET is M.
We select it in USB and GADGET.
This was the only way I could get usb-otg.c to build as

m if USB OR GADGET is m
built-in if USB and GADGET are built in.

> 
>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>> new file mode 100644
>> index 000..a23ab1e
>> --- /dev/null
>> +++ b/drivers/usb/common/usb-otg.c
>> @@ -0,0 +1,877 @@
>> +/**
>> + * drivers/usb/common/usb-otg.c - USB OTG core
>> + *
>> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
>> + * Author: Roger Quadros 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* OTG device list */
>> +LIST_HEAD(otg_list);
> 
> not static? Who needs to touch this private list?

right, it should be static.

> 
>> +static DEFINE_MUTEX(otg_list_mutex);
>> +
>> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
>> +{
>> +if (!hcd->primary_hcd)
>> +return 1;
> 
> these seems inverted. If hcd->primary is NULL (meaning, there's no
> ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
> to explain?

hcd->primary_hcd is a link used by the shared hcd to point to the primary_hcd.
primary_hcd's have this link as NULL.

> 
>> +return hcd == hcd->primary_hcd;
>> +}
>> +
>> +/**
>> + * usb_otg_get_data() - get usb_otg data structure
>> + * @otg_dev:OTG controller device
>> + *
>> + * Check if the OTG device is in our OTG list and return
>> + * usb_otg data, else NULL.
>> + *
>> + * otg_list_mutex must be held.
>> + *
>> + * Return: usb_otg data on success, NULL otherwise.
>> + */
>> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
>> +{
>> +struct usb_otg *otg;
>> +
>> +   

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

Hi,

On 20/06/16 10:45, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> It provides APIs for the following tasks
>>
>> - Registering an OTG/dual-role capable controller
>> - Registering Host and Gadget controllers to OTG core
>> - Providing inputs to and kicking the OTG state machine
> 
> I think I have already mentioned this, but after over 10 years of OTG,
> nobody seems to care about it, why are we still touching at all I don't
> know. For common non-OTG role-swapping we really don't need any of this
> and, quite frankly, I fail to see enough users for this.
> 
> Apparently there's only chipidea which, AFAICT, already had working
> dual-role before this OTG State Machine was added to the kernel.
> 
>> Provide a dual-role device (DRD) state machine.
> 
> there's not such thing as DRD state machine. You don't need to go
> through all these states, actually.

There are 3 states though.
HOST (id = 0)
PERIPHERAL (id = 1, vbus = 1)
IDLE (id = 1, vbus = 0).

> 
>> DRD mode is a reduced functionality OTG mode. In this mode
>> we don't support SRP, HNP and dynamic role-swap.
>>
>> In DRD operation, the controller mode (Host or Peripheral)
>> is decided based on the ID pin status. Once a cable plug (Type-A
>> or Type-B) is attached the controller selects the state
>> and doesn't change till the cable in unplugged and a different
>> cable type is inserted.
>>
>> As we don't need most of the complex OTG states and OTG timers
>> we implement a lean DRD state machine in usb-otg.c.
>> The DRD state machine is only interested in 2 hardware inputs
>> 'id' and 'b_sess_vld'.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>> v11:
>> - remove usb_otg_kick_fsm().
>> - typo fixes: structa/structure, upto/up to.
>> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
>>
>>  drivers/usb/Kconfig  |  18 +
>>  drivers/usb/common/Makefile  |   6 +-
>>  drivers/usb/common/usb-otg.c | 877 
>> +++
>>  drivers/usb/core/Kconfig |  14 -
>>  drivers/usb/gadget/Kconfig   |   1 +
>>  include/linux/usb/gadget.h   |   2 +
>>  include/linux/usb/hcd.h  |   1 +
>>  include/linux/usb/otg-fsm.h  |   7 +
>>  include/linux/usb/otg.h  | 174 -
>>  9 files changed, 1070 insertions(+), 30 deletions(-)
>>  create mode 100644 drivers/usb/common/usb-otg.c
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index 8689dcb..ed596ec 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -32,6 +32,23 @@ if USB_SUPPORT
>>  config USB_COMMON
>>  tristate
>>  
>> +config USB_OTG_CORE
>> +tristate
> 
> why tristate if you can never set it to 'M'?

This gets internally set to M if either USB or GADGET is M.
We select it in USB and GADGET.
This was the only way I could get usb-otg.c to build as

m if USB OR GADGET is m
built-in if USB and GADGET are built in.

> 
>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>> new file mode 100644
>> index 000..a23ab1e
>> --- /dev/null
>> +++ b/drivers/usb/common/usb-otg.c
>> @@ -0,0 +1,877 @@
>> +/**
>> + * drivers/usb/common/usb-otg.c - USB OTG core
>> + *
>> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
>> + * Author: Roger Quadros 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* OTG device list */
>> +LIST_HEAD(otg_list);
> 
> not static? Who needs to touch this private list?

right, it should be static.

> 
>> +static DEFINE_MUTEX(otg_list_mutex);
>> +
>> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
>> +{
>> +if (!hcd->primary_hcd)
>> +return 1;
> 
> these seems inverted. If hcd->primary is NULL (meaning, there's no
> ->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
> to explain?

hcd->primary_hcd is a link used by the shared hcd to point to the primary_hcd.
primary_hcd's have this link as NULL.

> 
>> +return hcd == hcd->primary_hcd;
>> +}
>> +
>> +/**
>> + * usb_otg_get_data() - get usb_otg data structure
>> + * @otg_dev:OTG controller device
>> + *
>> + * Check if the OTG device is in our OTG list and return
>> + * usb_otg data, else NULL.
>> + *
>> + * otg_list_mutex must be held.
>> + *
>> + * Return: usb_otg data on success, NULL otherwise.
>> + */
>> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
>> +{
>> +struct usb_otg *otg;
>> +
>> +if (!otg_dev)
>> +return NULL;

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> It provides APIs for the following tasks
>
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine

I think I have already mentioned this, but after over 10 years of OTG,
nobody seems to care about it, why are we still touching at all I don't
know. For common non-OTG role-swapping we really don't need any of this
and, quite frankly, I fail to see enough users for this.

Apparently there's only chipidea which, AFAICT, already had working
dual-role before this OTG State Machine was added to the kernel.

> Provide a dual-role device (DRD) state machine.

there's not such thing as DRD state machine. You don't need to go
through all these states, actually.

> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
>
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
>
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
>
> Signed-off-by: Roger Quadros 
> ---
> v11:
> - remove usb_otg_kick_fsm().
> - typo fixes: structa/structure, upto/up to.
> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
>
>  drivers/usb/Kconfig  |  18 +
>  drivers/usb/common/Makefile  |   6 +-
>  drivers/usb/common/usb-otg.c | 877 
> +++
>  drivers/usb/core/Kconfig |  14 -
>  drivers/usb/gadget/Kconfig   |   1 +
>  include/linux/usb/gadget.h   |   2 +
>  include/linux/usb/hcd.h  |   1 +
>  include/linux/usb/otg-fsm.h  |   7 +
>  include/linux/usb/otg.h  | 174 -
>  9 files changed, 1070 insertions(+), 30 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c
>
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
>  config USB_COMMON
>   tristate
>  
> +config USB_OTG_CORE
> + tristate

why tristate if you can never set it to 'M'?

> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> new file mode 100644
> index 000..a23ab1e
> --- /dev/null
> +++ b/drivers/usb/common/usb-otg.c
> @@ -0,0 +1,877 @@
> +/**
> + * drivers/usb/common/usb-otg.c - USB OTG core
> + *
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Roger Quadros 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* OTG device list */
> +LIST_HEAD(otg_list);

not static? Who needs to touch this private list?

> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_hcd)
> + return 1;

these seems inverted. If hcd->primary is NULL (meaning, there's no
->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
to explain?

> + return hcd == hcd->primary_hcd;
> +}
> +
> +/**
> + * usb_otg_get_data() - get usb_otg data structure
> + * @otg_dev: OTG controller device
> + *
> + * Check if the OTG device is in our OTG list and return
> + * usb_otg data, else NULL.
> + *
> + * otg_list_mutex must be held.
> + *
> + * Return: usb_otg data on success, NULL otherwise.
> + */
> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
> +{
> + struct usb_otg *otg;
> +
> + if (!otg_dev)
> + return NULL;
> +
> + list_for_each_entry(otg, _list, list) {
> + if (otg->dev == otg_dev)
> + return otg;
> + }
> +
> + return NULL;
> +}
> +
> +/**
> + * usb_otg_start_host() - start/stop the host controller
> + * @otg: usb_otg instance
> + * @on:  true to start, false to stop
> + *
> + * Start/stop the USB host controller. This function is meant
> + * for use by the OTG controller driver.
> + *
> + * Return: 0 on success, error value otherwise.
> + */
> +int usb_otg_start_host(struct usb_otg *otg, int on)
> +{
> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
> + 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> It provides APIs for the following tasks
>
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine

I think I have already mentioned this, but after over 10 years of OTG,
nobody seems to care about it, why are we still touching at all I don't
know. For common non-OTG role-swapping we really don't need any of this
and, quite frankly, I fail to see enough users for this.

Apparently there's only chipidea which, AFAICT, already had working
dual-role before this OTG State Machine was added to the kernel.

> Provide a dual-role device (DRD) state machine.

there's not such thing as DRD state machine. You don't need to go
through all these states, actually.

> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
>
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
>
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
>
> Signed-off-by: Roger Quadros 
> ---
> v11:
> - remove usb_otg_kick_fsm().
> - typo fixes: structa/structure, upto/up to.
> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
>
>  drivers/usb/Kconfig  |  18 +
>  drivers/usb/common/Makefile  |   6 +-
>  drivers/usb/common/usb-otg.c | 877 
> +++
>  drivers/usb/core/Kconfig |  14 -
>  drivers/usb/gadget/Kconfig   |   1 +
>  include/linux/usb/gadget.h   |   2 +
>  include/linux/usb/hcd.h  |   1 +
>  include/linux/usb/otg-fsm.h  |   7 +
>  include/linux/usb/otg.h  | 174 -
>  9 files changed, 1070 insertions(+), 30 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c
>
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
>  config USB_COMMON
>   tristate
>  
> +config USB_OTG_CORE
> + tristate

why tristate if you can never set it to 'M'?

> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> new file mode 100644
> index 000..a23ab1e
> --- /dev/null
> +++ b/drivers/usb/common/usb-otg.c
> @@ -0,0 +1,877 @@
> +/**
> + * drivers/usb/common/usb-otg.c - USB OTG core
> + *
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Roger Quadros 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* OTG device list */
> +LIST_HEAD(otg_list);

not static? Who needs to touch this private list?

> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_hcd)
> + return 1;

these seems inverted. If hcd->primary is NULL (meaning, there's no
->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
to explain?

> + return hcd == hcd->primary_hcd;
> +}
> +
> +/**
> + * usb_otg_get_data() - get usb_otg data structure
> + * @otg_dev: OTG controller device
> + *
> + * Check if the OTG device is in our OTG list and return
> + * usb_otg data, else NULL.
> + *
> + * otg_list_mutex must be held.
> + *
> + * Return: usb_otg data on success, NULL otherwise.
> + */
> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
> +{
> + struct usb_otg *otg;
> +
> + if (!otg_dev)
> + return NULL;
> +
> + list_for_each_entry(otg, _list, list) {
> + if (otg->dev == otg_dev)
> + return otg;
> + }
> +
> + return NULL;
> +}
> +
> +/**
> + * usb_otg_start_host() - start/stop the host controller
> + * @otg: usb_otg instance
> + * @on:  true to start, false to stop
> + *
> + * Start/stop the USB host controller. This function is meant
> + * for use by the OTG controller driver.
> + *
> + * Return: 0 on success, error value otherwise.
> + */
> +int usb_otg_start_host(struct usb_otg *otg, int on)
> +{
> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
> + int ret;
> +
> + dev_dbg(otg->dev, "otg: %s 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 13, 2016 at 10:56:30AM +0300, Roger Quadros wrote:
> It provides APIs for the following tasks
> 
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
> 
> Provide a dual-role device (DRD) state machine.
> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
> 
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
> 
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
> 
> Signed-off-by: Roger Quadros 
> ---
> v11:
> - remove usb_otg_kick_fsm().
> - typo fixes: structa/structure, upto/up to.
> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.

Acked-by: Peter Chen 

> 
>  drivers/usb/Kconfig  |  18 +
>  drivers/usb/common/Makefile  |   6 +-
>  drivers/usb/common/usb-otg.c | 877 
> +++
>  drivers/usb/core/Kconfig |  14 -
>  drivers/usb/gadget/Kconfig   |   1 +
>  include/linux/usb/gadget.h   |   2 +
>  include/linux/usb/hcd.h  |   1 +
>  include/linux/usb/otg-fsm.h  |   7 +
>  include/linux/usb/otg.h  | 174 -
>  9 files changed, 1070 insertions(+), 30 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c
> 
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
>  config USB_COMMON
>   tristate
>  
> +config USB_OTG_CORE
> + tristate
> +
> +config USB_OTG
> + bool "OTG/Dual-role support"
> + depends on PM && USB && USB_GADGET
> + default n
> + ---help---
> +   The most notable feature of USB OTG is support for a
> +   "Dual-Role" device, which can act as either a device
> +   or a host. The initial role is decided by the type of
> +   plug inserted and can be changed later when two dual
> +   role devices talk to each other.
> +
> +   Select this only if your board has Mini-AB/Micro-AB
> +   connector.
> +
>  config USB_ARCH_HAS_HCD
>   def_bool y
>  
> @@ -40,6 +57,7 @@ config USB
>   tristate "Support for Host-side USB"
>   depends on USB_ARCH_HAS_HCD
>   select USB_COMMON
> + select USB_OTG_CORE
>   select NLS  # for UTF-8 strings
>   ---help---
> Universal Serial Bus (USB) is a specification for a serial bus
> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
> index f8f2c88..5122b3f 100644
> --- a/drivers/usb/common/Makefile
> +++ b/drivers/usb/common/Makefile
> @@ -7,5 +7,7 @@ usb-common-y+= common.o
>  usb-common-$(CONFIG_USB_LED_TRIG) += led.o
>  
>  obj-$(CONFIG_USB_ULPI_BUS)   += ulpi.o
> -usbotg-y := usb-otg-fsm.o
> -obj-$(CONFIG_USB_OTG)+= usbotg.o
> +ifeq ($(CONFIG_USB_OTG),y)
> +usbotg-y := usb-otg.o usb-otg-fsm.o
> +obj-$(CONFIG_USB_OTG_CORE)   += usbotg.o
> +endif
> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> new file mode 100644
> index 000..a23ab1e
> --- /dev/null
> +++ b/drivers/usb/common/usb-otg.c
> @@ -0,0 +1,877 @@
> +/**
> + * drivers/usb/common/usb-otg.c - USB OTG core
> + *
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Roger Quadros 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* OTG device list */
> +LIST_HEAD(otg_list);
> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_hcd)
> + return 1;
> + return hcd == hcd->primary_hcd;
> +}
> +
> +/**
> + * usb_otg_get_data() - get usb_otg data structure
> + * @otg_dev: OTG controller device
> + *
> + * Check if the OTG device is in our OTG list and return
> + * usb_otg data, else NULL.
> + *
> + * otg_list_mutex must be held.
> + *
> + * Return: usb_otg data on success, NULL otherwise.
> + */
> +static struct usb_otg *usb_otg_get_data(struct 

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Peter Chen]

On Mon, Jun 13, 2016 at 10:56:30AM +0300, Roger Quadros wrote:
> It provides APIs for the following tasks
> 
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
> 
> Provide a dual-role device (DRD) state machine.
> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
> 
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
> 
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
> 
> Signed-off-by: Roger Quadros 
> ---
> v11:
> - remove usb_otg_kick_fsm().
> - typo fixes: structa/structure, upto/up to.
> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.

Acked-by: Peter Chen 

> 
>  drivers/usb/Kconfig  |  18 +
>  drivers/usb/common/Makefile  |   6 +-
>  drivers/usb/common/usb-otg.c | 877 
> +++
>  drivers/usb/core/Kconfig |  14 -
>  drivers/usb/gadget/Kconfig   |   1 +
>  include/linux/usb/gadget.h   |   2 +
>  include/linux/usb/hcd.h  |   1 +
>  include/linux/usb/otg-fsm.h  |   7 +
>  include/linux/usb/otg.h  | 174 -
>  9 files changed, 1070 insertions(+), 30 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c
> 
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
>  config USB_COMMON
>   tristate
>  
> +config USB_OTG_CORE
> + tristate
> +
> +config USB_OTG
> + bool "OTG/Dual-role support"
> + depends on PM && USB && USB_GADGET
> + default n
> + ---help---
> +   The most notable feature of USB OTG is support for a
> +   "Dual-Role" device, which can act as either a device
> +   or a host. The initial role is decided by the type of
> +   plug inserted and can be changed later when two dual
> +   role devices talk to each other.
> +
> +   Select this only if your board has Mini-AB/Micro-AB
> +   connector.
> +
>  config USB_ARCH_HAS_HCD
>   def_bool y
>  
> @@ -40,6 +57,7 @@ config USB
>   tristate "Support for Host-side USB"
>   depends on USB_ARCH_HAS_HCD
>   select USB_COMMON
> + select USB_OTG_CORE
>   select NLS  # for UTF-8 strings
>   ---help---
> Universal Serial Bus (USB) is a specification for a serial bus
> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
> index f8f2c88..5122b3f 100644
> --- a/drivers/usb/common/Makefile
> +++ b/drivers/usb/common/Makefile
> @@ -7,5 +7,7 @@ usb-common-y+= common.o
>  usb-common-$(CONFIG_USB_LED_TRIG) += led.o
>  
>  obj-$(CONFIG_USB_ULPI_BUS)   += ulpi.o
> -usbotg-y := usb-otg-fsm.o
> -obj-$(CONFIG_USB_OTG)+= usbotg.o
> +ifeq ($(CONFIG_USB_OTG),y)
> +usbotg-y := usb-otg.o usb-otg-fsm.o
> +obj-$(CONFIG_USB_OTG_CORE)   += usbotg.o
> +endif
> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> new file mode 100644
> index 000..a23ab1e
> --- /dev/null
> +++ b/drivers/usb/common/usb-otg.c
> @@ -0,0 +1,877 @@
> +/**
> + * drivers/usb/common/usb-otg.c - USB OTG core
> + *
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Roger Quadros 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* OTG device list */
> +LIST_HEAD(otg_list);
> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_hcd)
> + return 1;
> + return hcd == hcd->primary_hcd;
> +}
> +
> +/**
> + * usb_otg_get_data() - get usb_otg data structure
> + * @otg_dev: OTG controller device
> + *
> + * Check if the OTG device is in our OTG list and return
> + * usb_otg data, else NULL.
> + *
> + * otg_list_mutex must be held.
> + *
> + * Return: usb_otg data on success, NULL otherwise.
> + */
> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
> +{
> + struct usb_otg *otg;

[PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

It provides APIs for the following tasks

- Registering an OTG/dual-role capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine

Provide a dual-role device (DRD) state machine.
DRD mode is a reduced functionality OTG mode. In this mode
we don't support SRP, HNP and dynamic role-swap.

In DRD operation, the controller mode (Host or Peripheral)
is decided based on the ID pin status. Once a cable plug (Type-A
or Type-B) is attached the controller selects the state
and doesn't change till the cable in unplugged and a different
cable type is inserted.

As we don't need most of the complex OTG states and OTG timers
we implement a lean DRD state machine in usb-otg.c.
The DRD state machine is only interested in 2 hardware inputs
'id' and 'b_sess_vld'.

Signed-off-by: Roger Quadros 
---
v11:
- remove usb_otg_kick_fsm().
- typo fixes: structa/structure, upto/up to.
- remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.

 drivers/usb/Kconfig  |  18 +
 drivers/usb/common/Makefile  |   6 +-
 drivers/usb/common/usb-otg.c | 877 +++
 drivers/usb/core/Kconfig |  14 -
 drivers/usb/gadget/Kconfig   |   1 +
 include/linux/usb/gadget.h   |   2 +
 include/linux/usb/hcd.h  |   1 +
 include/linux/usb/otg-fsm.h  |   7 +
 include/linux/usb/otg.h  | 174 -
 9 files changed, 1070 insertions(+), 30 deletions(-)
 create mode 100644 drivers/usb/common/usb-otg.c

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..ed596ec 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -32,6 +32,23 @@ if USB_SUPPORT
 config USB_COMMON
tristate
 
+config USB_OTG_CORE
+   tristate
+
+config USB_OTG
+   bool "OTG/Dual-role support"
+   depends on PM && USB && USB_GADGET
+   default n
+   ---help---
+ The most notable feature of USB OTG is support for a
+ "Dual-Role" device, which can act as either a device
+ or a host. The initial role is decided by the type of
+ plug inserted and can be changed later when two dual
+ role devices talk to each other.
+
+ Select this only if your board has Mini-AB/Micro-AB
+ connector.
+
 config USB_ARCH_HAS_HCD
def_bool y
 
@@ -40,6 +57,7 @@ config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
select USB_COMMON
+   select USB_OTG_CORE
select NLS  # for UTF-8 strings
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index f8f2c88..5122b3f 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,5 +7,7 @@ usb-common-y  += common.o
 usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
-usbotg-y   := usb-otg-fsm.o
-obj-$(CONFIG_USB_OTG)  += usbotg.o
+ifeq ($(CONFIG_USB_OTG),y)
+usbotg-y   := usb-otg.o usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG_CORE) += usbotg.o
+endif
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..a23ab1e
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,877 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
+{
+   if (!hcd->primary_hcd)
+   return 1;
+   return hcd == hcd->primary_hcd;
+}
+
+/**
+ * usb_otg_get_data() - get usb_otg data structure
+ * @otg_dev:   OTG controller device
+ *
+ * Check if the OTG device is in our OTG list and return
+ * usb_otg data, else NULL.
+ *
+ * otg_list_mutex must be held.
+ *
+ * Return: usb_otg data on success, NULL otherwise.
+ */
+static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
+{
+   struct usb_otg *otg;
+
+   if (!otg_dev)
+   return NULL;
+
+   list_for_each_entry(otg, _list, list) {
+   if (otg->dev == otg_dev)
+   return otg;
+   }
+
+   return NULL;
+}
+
+/**
+ * usb_otg_start_host() - start/stop the host controller
+ * @otg:   

[PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Roger Quadros]

It provides APIs for the following tasks

- Registering an OTG/dual-role capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine

Provide a dual-role device (DRD) state machine.
DRD mode is a reduced functionality OTG mode. In this mode
we don't support SRP, HNP and dynamic role-swap.

In DRD operation, the controller mode (Host or Peripheral)
is decided based on the ID pin status. Once a cable plug (Type-A
or Type-B) is attached the controller selects the state
and doesn't change till the cable in unplugged and a different
cable type is inserted.

As we don't need most of the complex OTG states and OTG timers
we implement a lean DRD state machine in usb-otg.c.
The DRD state machine is only interested in 2 hardware inputs
'id' and 'b_sess_vld'.

Signed-off-by: Roger Quadros 
---
v11:
- remove usb_otg_kick_fsm().
- typo fixes: structa/structure, upto/up to.
- remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.

 drivers/usb/Kconfig  |  18 +
 drivers/usb/common/Makefile  |   6 +-
 drivers/usb/common/usb-otg.c | 877 +++
 drivers/usb/core/Kconfig |  14 -
 drivers/usb/gadget/Kconfig   |   1 +
 include/linux/usb/gadget.h   |   2 +
 include/linux/usb/hcd.h  |   1 +
 include/linux/usb/otg-fsm.h  |   7 +
 include/linux/usb/otg.h  | 174 -
 9 files changed, 1070 insertions(+), 30 deletions(-)
 create mode 100644 drivers/usb/common/usb-otg.c

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..ed596ec 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -32,6 +32,23 @@ if USB_SUPPORT
 config USB_COMMON
tristate
 
+config USB_OTG_CORE
+   tristate
+
+config USB_OTG
+   bool "OTG/Dual-role support"
+   depends on PM && USB && USB_GADGET
+   default n
+   ---help---
+ The most notable feature of USB OTG is support for a
+ "Dual-Role" device, which can act as either a device
+ or a host. The initial role is decided by the type of
+ plug inserted and can be changed later when two dual
+ role devices talk to each other.
+
+ Select this only if your board has Mini-AB/Micro-AB
+ connector.
+
 config USB_ARCH_HAS_HCD
def_bool y
 
@@ -40,6 +57,7 @@ config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
select USB_COMMON
+   select USB_OTG_CORE
select NLS  # for UTF-8 strings
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index f8f2c88..5122b3f 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,5 +7,7 @@ usb-common-y  += common.o
 usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
-usbotg-y   := usb-otg-fsm.o
-obj-$(CONFIG_USB_OTG)  += usbotg.o
+ifeq ($(CONFIG_USB_OTG),y)
+usbotg-y   := usb-otg.o usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG_CORE) += usbotg.o
+endif
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..a23ab1e
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,877 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
+{
+   if (!hcd->primary_hcd)
+   return 1;
+   return hcd == hcd->primary_hcd;
+}
+
+/**
+ * usb_otg_get_data() - get usb_otg data structure
+ * @otg_dev:   OTG controller device
+ *
+ * Check if the OTG device is in our OTG list and return
+ * usb_otg data, else NULL.
+ *
+ * otg_list_mutex must be held.
+ *
+ * Return: usb_otg data on success, NULL otherwise.
+ */
+static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
+{
+   struct usb_otg *otg;
+
+   if (!otg_dev)
+   return NULL;
+
+   list_for_each_entry(otg, _list, list) {
+   if (otg->dev == otg_dev)
+   return otg;
+   }
+
+   return NULL;
+}
+
+/**
+ * usb_otg_start_host() - start/stop the host controller
+ * @otg:   usb_otg instance
+ * @on: