On Wednesday 04 October 2006 7:40 am, Thomann Andreas (thomaand) wrote:
> Hi all,
>
> I built an usb gadget driver with an isochronous fullspeed IN endpoint.
> I used a NET2280 PCI card (usb device controller) to develop this
> driver.
> Since my driver works on the NET2280-card I'm trying to port it to
> DaVinci.
>
> Now I've got two problems:
> 1.) musb_hdrc won't autoconfigure my isochronous endpoint. Does anyone
> has a idea
> what could be the problem? And how can I solve this problem? How can i
> configure the
> endpoint by myself?
Why isn't it configuring them? My first guess would be you're
using maxpacket size of more than 512 bytes. You may need to
use a different fifo_mode parameter, or define a new mode.
> 2.) to test the further features I changed the inoperable isochronous
> endpoint into a
> bulk endpoint. During handshake with the host, the host would like to
> send a request with "Data".
> Most requests sent by the host don't includes the field "Data" (see
> USB2.0 Spec. 9.4 Standard Device Requests)
Those go to _control_ endpoints (ep0), not _bulk_ endpoints ...
> But there are some requests like the SET_DESCRIPTOR or in my case the
> SET_CUR of VideoClass.
> With the NET2280-card I could get the Data the follwing way:
> CASE: USB_REQ_SET_CUR
> if(....){
> value = usb_ep_queue(gadget->ep0, req, GFP_ATOMIC);
> memcpy (&video_prob_commit, req->buf, w_length);
> ...
>
> I think that works with my NET2280-Card. I think I've got the correct
> data out of the "DATA"-field of the usb request.
"Think" being the operative word. That memcpy() must be done in
the completion callback for thatusb_request ... the first data
packet may not yet have arrived, much less the last one.
> As I told before I ported it to DaVinci and during the USB_REQ_SET_CUR
> request I've got the following kernel-info:
>
> musb_g_ep0_queue 874: ep0 request queued in state 0
> musb_g_ep0_queue 874: ep0 request queued in state 0
> musb_g_ep0_queue 874: ep0 request queued in state 0
UTSL and you'll see state 0 == SETUP, meaning you've terminated the
preceding request and are sending data with no request pending.
Are you maybe returning a nonzero status code from setup() and
then later queueing that usb_request?
> What's the reason of that? How can I solve this problem? I need the
> "DATA"-field for a successful probe/commit handshake.
You've not shown the whole program; I suggest you look at how
gadget zero handles control-OUT transfers. Or for something
that does Real Work using those transfer types (which are rather
unique in USB), see how RNDIS encapsulated commands work.
- Dave
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
