On Wednesday 06 February 2008, Thomi Aurel RUAG A wrote: > Hy Hi ... can you fix your mailer so it wraps lines properly? Well before column 80.
> After further tests with the usb gadget serial on the pxa27x (see my > previous postings "USB gadget serial on PXA-270") i think i'm able to > address the problem more precisly. > It seems that the class request SET_LINE_CODING is handled by the gadget > driver _before_ its data OUT stage. You must be using an old kernel then. Current versions just stall that request ... someone should submit a patch to provide a real fix, of course. Of course, the fact that you're using a pxa27x_udc driver means that you're not using a mainstream driver. All versions of that driver that I've heard about have had problems that prevent any upstream merge. > Only considering the pxa27x_udc_irq and handle_ep0 functions: > > 1.a pxa27x_udc_irq gets an SETUP packet and calls handle_ep0 > 1.b handle_ep0 pass it to the gadget specific setup function > (as it is done now) > 1.c setup function handles class request (as it is done now) ... except that those ep0out transfers are not handled correctly by g_serial. If g_zero works right with "testusb -t14" then that should be the only problem: g_serial goofage. But there may well be problems with how the pxa27x udc driver handles ep0out, since that's not a common transfer type. > 2.a pxa27x_udc_irq gets an DATA OUT packet (in the data stage) > and do what? Should it pass it to handle_ep0? Do what's needed to make g_zero pass usbtest case 14 ... :) There will be a request queued by the gadget driver, with a buffer for ep0out. Just append the data to that buffer. If it's a short packet, or the buffer is filled, report completion of that request. Otherwise, wait until the STATUS phase starts before reporting completion. In all cases, the completion callback for that ep0out request should be able to stall the status stage of that control request. When there's no such buffer/request yet, most hardware will let the data stay in the ep0 fifo until the gadget driver provides a buffer. If pxa27x hardware demands that the FIFO be immediately emptied, then report an error (stall). > 2.b handle_ep0 pass it to the gadget specific setup > function (as it should be?) The setup() callback gets only SETUP packets. DATA buffers use the normal usb_request mechanism. > 2.c setup function handles class request (this time > with a valid request buffer) See above. Notice now the setup() callback doesn't have a mechanism to pass any data except a SETUP packet. That's a clear sign that your (2b) and (2c) are not on the right track... > 3. pxa27x should send a Handshake packet What do you mean by that? DATA packet acking/naking should be automatic. STATUS stage may not be acked (or stalled) until the gadget driver says what to do. If the completion callback for the data stage tells ep0 to stall, then the STATUS handshake will be STALL. If that completion hasn't returned, that handshake should be a NAK. If it returned without stalling, then the handshake should be an ACK. > What would be the right procedure for such an control > transfer (with a data OUT stage)? See above. If you don't have g_zero working for all test cases, go fix that problem first. > How can the handling of the class specific request be > delayed after the data OUT stage? Not clear what you mean. The SETUP part of the request is handled immediately ... usually a usb_request is submitted, rarely ep0 might be told to issue a protocol stall on the next OUT or IN packet. The DATA stage of the request would normally be handled in the completion callback of that usb_request ... that can't be delayed any further unless you never need to STALL the control request. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
