From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rodolfo Giometti Date: Mon, 21 May 2007 00:23:42 +0200 Subject: [U-Boot-Users] PXA27x usbtty start up sequence In-Reply-To: <20070520224017.1e50894c@localhost.localdomain> References: <20070512231906.GG11070@enneenne.com> <20070513132536.6ab397df@localhost.localdomain> <20070518171521.GA4199@enneenne.com> <20070520145436.180807c6@localhost.localdomain> <20070520160702.GB3887@enneenne.com> <20070520224017.1e50894c@localhost.localdomain> Message-ID: <20070520222342.GD30191@enneenne.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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