Unfortunately, we have only configured it and tested it for host mode.

The other USB port can be configured as OTG to do either host or device mode.

adam

Thanks for you fast reply.

On the source code, I found this: on the board file (board-omap3logic.c), the ISP1763 platform data has a parameter to set port1 as OTG:

---

static struct isp1763_platform_data omap3logic_isp1763_pdata = {
.bus_width_8 = 0,
.port1_otg = 1,
.dack_polarity_high = 0,
.dreq_polarity_high = 0,
.intr_polarity_high = 0,
.intr_edge_trigger = 0,
}

--

And on kernel menuconfig settings, you can select ISP1763 device mode, which (solving an trivial compilation error) works 'kind of' on peripheral mode.
The point it that, for the scope of our project, we require to make ISP1763 work as peripheral, because musb is already used for other requirement.

I know that on the evaluation kit, you're implemented and tested basically on host mode. That is your basic purpose.

But the source code implementation seems practically prepared for OTG, but fails when 'registering a gadget'.
So I try to figure it out, and I see two options:

1) On the past, you developed and tested an OTG 'just for fun', and now you're just not supporting because the driver on Eval Kit was not intended for that.
2) You really never make it, and all this part of sourcecode is just the result of other USB chip porting (you know, in order to not start from scratch)


So.. Is this true? Your answer could really really help us a lot.

Thanks and regards!

I did a little digging into this and with some discussion with a colleague, the best we can find is that the driver was ported from something else.

There was another customer who was asking for isochronous support (http://support.logicpd.co.../1804/Default.aspx), but the driver we have doesn't support it while the hardware does.

If you wanted help with improving the driver, we can setup a service contract if you like.

The Linux BSP test results are posted http://support.logicpd.co...talid=0&EntryId=1400
In there is steps through what was tested and what wasn't.

Due to the open source nature of Linux, and the fact that some of the was was done by TI, sometimes drivers are started, but not completed. Since we already had a peripheral driver on the other port, we opted not to finish it due to lack of customer demand. That may explain some of the partially completed drivers you noted in the menuconfig options.

I'm sorry. I know it's not what you wanted to hear.
adam

Ok, thank you for being so honest, Adam.

Are you able to contact me using the email address of my login account for this forum?

As I told you before, for our project we need to use that port, so we could require a service contract.
Please, send us the information about support contract using my email address.

Thanks and regards

Another thing,
Is the other customer still asking for the USB driver improvement?

I beleive in honesty. The Linux community is based on full disclosure and a community working together. To my knowledge the original request didn't go anywhere. I have looked up your e-mail address, and I will forward it along to the proper people. You should be contacted by someone. If not, respond to this post and I will see what I can do.

adam

Hello Adam,

Today we didn't receive any email for the support contract (18:00 West Europe time)
We could add also roman.gimenez@idneo.es as your contact for the technical support contract.

I will following up. I'll see what I can do to expedite it.

Sorry about that.

adam