To otg-fsm or not to otg-fsm? That is the question.

To otg-fsm or not to otg-fsm? That is the question.

[Tim Bird]

Hey Linux USBer's,

I'm looking to add host support to the qualcomm OTG USB driver.  The
driver in mainline currently has gadget support only.  I'm starting
with an out-of-tree driver that has full gadget and host support.  It
has it's own OTG state machine implement in the driver, that I was
about to forward-port to top-of-tree.

However, I found the files /usb/common/usb-otg-fsm.c and I'm wondering
what the status of that is.  There appears to be only one driver
currently using it.  Should I modify the qualcomm driver
(drivers/usb/phy/phy-msm-usb.c to use that state machine, or just try
to mainline the state machine from the out-of-tree driver?  I'm
suspecting the former will be more work, but I want to do the right
thing.

Really I'm just checking that using the generic state machine is the
preferred method of supporting USB OTG drivers going forward.

Thanks!

 -- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation

RE: To otg-fsm or not to otg-fsm? That is the question.

[Peter Chen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1731 bytes --]

 
> Hey Linux USBer's,
> 
> I'm looking to add host support to the qualcomm OTG USB driver.  The
> driver in mainline currently has gadget support only.  I'm starting with
> an out-of-tree driver that has full gadget and host support.  It has it's
> own OTG state machine implement in the driver, that I was about to
> forward-port to top-of-tree.
> 
> However, I found the files /usb/common/usb-otg-fsm.c and I'm wondering
> what the status of that is.  There appears to be only one driver
> currently using it.  Should I modify the qualcomm driver
> (drivers/usb/phy/phy-msm-usb.c to use that state machine, or just try to
> mainline the state machine from the out-of-tree driver?  I'm suspecting
> the former will be more work, but I want to do the right thing.
> 

Hi Tim,

The OTG FSM at /usb/common/usb-otg-fsm.c is a software OTG FSM implementation
which follows On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification
(Revision 2.0 version 1.1a) Chapter 7 State Diagrams.

If the platform doesn't support hardware otg fsm, it should follow above fsm implementation since
it follows the newest OTG & EH spec. Besides, as far as I know, the qualcomm uses
chipidea core for its usb2, then it should be easy for qualcomm using this common
otg fsm implementation.

Peter

> Really I'm just checking that using the generic state machine is the
> preferred method of supporting USB OTG drivers going forward.
> 
> Thanks!
> 
>  -- Tim Bird
> Senior Software Engineer, Sony Mobile
> Architecture Group Chair, CE Workgroup, Linux Foundation
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ºÆâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br	šê+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹\x1e®w¥¢¸?™¨è­Ú&¢)ߢ^[f

Re: To otg-fsm or not to otg-fsm? That is the question.

[Tim Bird]

On Mon, Aug 11, 2014 at 5:28 PM, Peter Chen <Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> The OTG FSM at /usb/common/usb-otg-fsm.c is a software OTG FSM implementation
> which follows On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification
> (Revision 2.0 version 1.1a) Chapter 7 State Diagrams.
>
> If the platform doesn't support hardware otg fsm, it should follow above fsm implementation since
> it follows the newest OTG & EH spec. Besides, as far as I know, the qualcomm uses
> chipidea core for its usb2, then it should be easy for qualcomm using this common
> otg fsm implementation.

OK.  sounds good.

Yes, the qualcomm chips use a chipidea core for usb2.  The main
difficulty, IMHO, will
be mapping the qcom charger state machine onto the generic OTG state
machine implementation
in usb-otg-fsm.  I'm not sure if I'll be able to embed the needed
functionality into the existing functions
called by the generic state machine, or if I'll need to add some new
entries to the function table
to handle this extra logic.

I'll probably try to get the driver working without the charger stuff
first, and then, once I have a
better idea of how the state machines map, try adding the charger
stuff.  If I feel like I need
to modify the generic state machine, I'll ask on list.  I'm a newbie
at USB stuff and I don't want
to break anything.

Thanks.

 -- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: To otg-fsm or not to otg-fsm? That is the question.

[Peter Chen]

On Tue, Aug 12, 2014 at 09:13:47AM -0700, Tim Bird wrote:
> On Mon, Aug 11, 2014 at 5:28 PM, Peter Chen <Peter.Chen@freescale.com> wrote:
> > The OTG FSM at /usb/common/usb-otg-fsm.c is a software OTG FSM implementation
> > which follows On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification
> > (Revision 2.0 version 1.1a) Chapter 7 State Diagrams.
> >
> > If the platform doesn't support hardware otg fsm, it should follow above fsm implementation since
> > it follows the newest OTG & EH spec. Besides, as far as I know, the qualcomm uses
> > chipidea core for its usb2, then it should be easy for qualcomm using this common
> > otg fsm implementation.
> 
> OK.  sounds good.
> 
> Yes, the qualcomm chips use a chipidea core for usb2.  The main
> difficulty, IMHO, will
> be mapping the qcom charger state machine onto the generic OTG state
> machine implementation
> in usb-otg-fsm.  I'm not sure if I'll be able to embed the needed
> functionality into the existing functions
> called by the generic state machine, or if I'll need to add some new
> entries to the function table
> to handle this extra logic.
> 
> I'll probably try to get the driver working without the charger stuff
> first, and then, once I have a
> better idea of how the state machines map, try adding the charger
> stuff.  If I feel like I need
> to modify the generic state machine, I'll ask on list.  I'm a newbie
> at USB stuff and I don't want
> to break anything.
> 
> Thanks.
> 

One remind, you may need to know which role-switch function you need,
if you only need role-switch based in ID pin, then no OTG FSM support
is needed, this is current most of "OTG" device supports, it is not fully
OTG compliance.

-- 
Best Regards,
Peter Chen