
On Sun, May 20, 2007 at 10:40:17PM +0100, Bryan O'Donoghue wrote:
On Sun, 20 May 2007 18:07:02 +0200 Rodolfo Giometti giometti@enneenne.com wrote:
Hold on wait... I think I've thought of a better way still to send that data..
How about
__puts() { while(usb_configured() == TRUE && data_to_send){ /* do the thing */ } }
I think something like that would be better from the __puts() perspective, then a retry count.... I'll get back to you on that one though, because I may find some way to break that else I'll code up a patch around this idea, and submit at a later date.
Basically the __puts() function would function as a guaranteed delivery if and only-if the device was in the configured state, else it should happily allow the system to boot, for example in the case where the USB cable hasn't been connected.
This would mean that each usbdcore_* would export usb_get_state() or similar and disjoin on state == CONFIGURED, which would allow us not to do naff things like "retries", especially on something like USB bulk endpoints, which are supposed to guarantee data tx.
The problem is that the defice __is__ into configured state (USB cable is connected and /dev/ttyUSB0 is running) but nobody has opened the serial line (no minicom/kermit running).
So, I suppose, the above modification is useless...
It's into usbtty_poll() which calls write_buffer() when the USB device get connected (usbtty_configured() is true).
Function write_buffer() calls udc_endpoint_write() who calls driver low level function. This low level function, PXA270 specific, waits all data has been transmitted before returning to the caller, this because I need to know when a packet has been transmetted before sending a new one or I get some data lost during transmission.
If you loop indefinitely at the low-level BULK tx level... how would you deal with ep0 control requests that *must* be responded to immediately ?
You are right that you can't abandon BULK IN data... but, you aren't right to be doing the infinite loop in your function below endpoint_write() since this means you can't deal with a control request if one should happen.
Mmm... I see... I supposed to get no control request once device is connected...
Currently I use a timeout of 2ms but I suppose I should decrease it, shouldn't I? :-o
You'll see I have a tx_retry in udc_ep_tx and you *might* be thinking that that means I *give up* data transfer but, that's not so..
write_buffer() won't increment the data unless endpoint_write() says it successfully transmitted the data. Thus if the endpoint_write call stack returns anything other then 0, the implication is that there is TX data *still* to be sent, and that's precisely what a function like __puts() should do with a statement like
while(usb_configured() == TRUE && data_to_send) as the control.
The rationale behind this behavior is that it allows a high level function such as __puts() to make a decision as to provide either guaranteed or best-effort data transport to the host system.
Ok, what do you suggest to do? I'm a bit confused... :)
Ciao,
Rodolfo