From: Bryan O'Donoghue <bodonoghue@codehermit.ie>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] PXA27x usbtty start up sequence
Date: Mon, 21 May 2007 00:11:58 +0100 [thread overview]
Message-ID: <20070521001158.6056ad5d@localhost.localdomain> (raw)
In-Reply-To: <20070520222342.GD30191@enneenne.com>
On Mon, 21 May 2007 00:23:42 +0200
Rodolfo Giometti <giometti@enneenne.com> wrote:
> 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...
No, no, unless I'm *really* forgetting my USB enumeration behavior,
a device shouldn't go into the configured state unless and until
the host does a SET_CONFIGURATION, so the modification would be right
since without the USB cable connected the device should be in the
DEFAULT state, not the CONFIGURED state.
usb_20.pdf page - 240 Figure 9.1 see ?
> 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
Possibly... I don't think I'd take issue with the specific timeout
but, you *can* get a control request at *any* time... including 50% of
the way through a DATA IN transfer to the host... there's nothing in
the USB specification which precludes control requests on EP0 at
*any* time...
You'd probably "get away" with it if you limited your hardware to
functioning only with g_serial but, where would be the fun in doing
just g_serial ?
> Ok, what do you suggest to do? I'm a bit confused... :)
Possibly the simple solution is
#1: Fix it so SET_CONFIGURATION is the only thing to move the device
into the configured state.
#2: Either you or I should write a patch then which looks like this.
/* Not tested */
static void __usbtty_puts (const char *str, int len)
{
int maxlen = usbtty_output.totalsize;
int space, n;
/* break str into chunks < buffer size, if needed */
while (len > 0
&& device_instance->device_state == STATE_CONFIGURED) {
usbtty_poll ();
space = maxlen - usbtty_output.size;
/* Empty buffer here, if needed, to ensure space... */
if (space) {
write_buffer (&usbtty_output);
n = MIN (space, MIN (len, maxlen));
buf_push (&usbtty_output, str, n);
str += n;
len -= n;
}
}
}
I think... that *should* work.
Happy Monday.
Bryan
next prev parent reply other threads:[~2007-05-20 23:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-12 23:19 [U-Boot-Users] PXA27x usbtty start up sequence Rodolfo Giometti
2007-05-13 12:25 ` Bryan O'Donoghue
2007-05-14 6:35 ` Rodolfo Giometti
2007-05-18 17:15 ` Rodolfo Giometti
2007-05-20 13:54 ` Bryan O'Donoghue
2007-05-20 16:07 ` Rodolfo Giometti
2007-05-20 21:40 ` Bryan O'Donoghue
2007-05-20 22:23 ` Rodolfo Giometti
2007-05-20 23:11 ` Bryan O'Donoghue [this message]
2007-05-20 23:59 ` Bryan O'Donoghue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070521001158.6056ad5d@localhost.localdomain \
--to=bodonoghue@codehermit.ie \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox