[U-Boot-Users] PXA27x usbtty start up sequence

[Rodolfo Giometti]

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 at 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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127