OTG implementation with external transceiver on PXA270

OTG implementation with external transceiver on PXA270

[Sergey Lapin]

Hi, all!

I try to implement external OTG transceiver on PXA270.
I just need basic device mode at the moment.

A problem is that PXA itself handles interrupt of external chip via
UDC interrupt. But I need to read my chip-specific registers
from there while I want to maintain pxa270_udc in a generic way
without cluttering it with i2c calls, so I can implement it in the
following ways:

* make chip-specific data struct global (like it is in isp1301_omap.c
and make exported function in OTG driver, enable handling of OTG interrupts
in pxa27x_udc and call that function from there.
* add API function like otg_handle_interrupt, enable handling of OTG interrupts
in pxa27x_udc and call it from there. Which seems to be less messy.

Any other suggestions? If that work is really being done somewhere,
I'd like to help with testing.

Thanks a lot,
S.

OTG implementation with external transceiver on PXA270

[Eric Miao]

On Mon, May 10, 2010 at 9:33 AM, Sergey Lapin <slapinid@gmail.com> wrote:
> Hi, all!
>
> I try to implement external OTG transceiver on PXA270.
> I just need basic device mode at the moment.
>
> A problem is that PXA itself handles interrupt of external chip via
> UDC interrupt. But I need to read my chip-specific registers
> from there while I want to maintain pxa270_udc in a generic way
> without cluttering it with i2c calls, so I can implement it in the
> following ways:
>
> * make chip-specific data struct global (like it is in isp1301_omap.c
> and make exported function in OTG driver, enable handling of OTG interrupts
> in pxa27x_udc and call that function from there.
> * add API function like otg_handle_interrupt, enable handling of OTG interrupts
> in pxa27x_udc and call it from there. Which seems to be less messy.
>
> Any other suggestions? If that work is really being done somewhere,
> I'd like to help with testing.
>

The problem with isp1301_omap.c is that it's not separating the components
into otg controller and otg transciever, which means at the moment the quickest
way is to write something similar as isp1301_pxa27x.c, but apparently, the
optimal way in my POV is to have a good abstraction, so the OTG transceiver
and controller code can be re-used.

OTG implementation with external transceiver on PXA270

[Robert Jarzmik]

Eric Miao <eric.y.miao@gmail.com> writes:

> On Mon, May 10, 2010 at 9:33 AM, Sergey Lapin <slapinid@gmail.com> wrote:
>> Hi, all!
>>
>> I try to implement external OTG transceiver on PXA270.
...
>>
>> * make chip-specific data struct global (like it is in isp1301_omap.c and
>> make exported function in OTG driver, enable handling of OTG interrupts in
>> pxa27x_udc and call that function from there.

Namespace expansion will be going on with every hardware, your second option is
far better IMO.

>> * add API function like otg_handle_interrupt, enable handling of OTG
>> interrupts in pxa27x_udc and call it from there. Which seems to be less
>> messy.

That seems a good idea.
If you expand it further, you could design the full OTG framework :
 - extend otg.c, add the OTG state machine
 - extend otg.h and otg.c with new calls :
   - otg_set_state()
   - otg_get_state()
   - otg_signal_udc()
 - extend otg.h, with callbacks like :
   - otg_handle_interrupt()

Separate the isp1301 driver from pxa270. The link will be done through the OTG
framework. Remember the pxa270 has taken the udc IO space, so no access can be
done from the isp1301 side (it should not actually for clean separation).

But that could be more or less what you were thinking about.

>> Any other suggestions? If that work is really being done somewhere,
>> I'd like to help with testing.
No, nobody fiddled yet with OTG on pxa270 :)

> The problem with isp1301_omap.c is that it's not separating the components
> into otg controller and otg transciever, which means at the moment the quickest
> way is to write something similar as isp1301_pxa27x.c, but apparently, the
> optimal way in my POV is to have a good abstraction, so the OTG transceiver
> and controller code can be re-used.
Exactly my thinking.

And you should ask David Brownell or Alan Stern, they have sharp ideas on the
usb framework.

Cheers.

--
Robert

OTG implementation with external transceiver on PXA270

[Mark Brown]

On Wed, May 12, 2010 at 08:23:21PM +0200, Robert Jarzmik wrote:
> Eric Miao <eric.y.miao@gmail.com> writes:

> That seems a good idea.
> If you expand it further, you could design the full OTG framework :
>  - extend otg.c, add the OTG state machine
>  - extend otg.h and otg.c with new calls :
>    - otg_set_state()
>    - otg_get_state()
>    - otg_signal_udc()
>  - extend otg.h, with callbacks like :
>    - otg_handle_interrupt()

> Separate the isp1301 driver from pxa270. The link will be done through the OTG
> framework. Remember the pxa270 has taken the udc IO space, so no access can be
> done from the isp1301 side (it should not actually for clean separation).

> But that could be more or less what you were thinking about.

This would be really good, not just for OTG but for USB in general -
there's other devices which could make use of information like PMICs
doing regulation of power draw from/to USB.