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

[Bryan O'Donoghue]

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.

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

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.


Greetings,
Bryan