Re: USB output in ucom

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On 01/10/2025 07:21, Emmanuel Dreyfus wrote:
> On Wed, Oct 01, 2025 at 06:54:48AM +0100, Nick Hudson wrote:
> > You won't have been able to initiate USBD_SYNCHRONOUS transfers, but you
> > should have been able to initiate non-USBD_SYNCHRONOUS transfers unless I
> > misremember.
> Asynchronous transfers in polling mode panic in usbd_transfer() here:
>           while (!xfer->ux_done) {
>                if (pipe->up_dev->ud_bus->ub_usepolling)
>                        panic("usbd_transfer: not done");

Err, think that's for synchronous transfers

https://nxr.netbsd.org/xref/src/sys/dev/usb/usbdi.c#487

    487     /* Sync transfer, wait for completion. */
    488     if (pipe->up_dev->ud_bus->ub_usepolling == 0)
    489         usbd_lock_pipe(pipe);
    490     while (!xfer->ux_done) {
    491         if (pipe->up_dev->ud_bus->ub_usepolling)
    492             panic("usbd_transfer: not done");


Async transfers exit usbd_transfer earlier

https://nxr.netbsd.org/xref/src/sys/dev/usb/usbdi.c#472

> > Also, I don't remember anything in polling mode that would prevent multiple
> > transfers at once.
> That may work, but it would require using mulitple struct usbd_xfer,
> otherwise we corrupt the pipe queue by inserting the same struct usbd_xfer
> multiple times.
I didn't mean multiple transfers to the same endpoint, but that should 
work too.
> I did not try this since it is not even done for regular I/O. There is
> this comment in ucom.c:
>   * XXX: We can submit multiple input/output buffers to the usb stack
>   * to improve throughput, but the usb stack is too lame to deal with this
>   * in a number of places.

yeah, it's true that many (not all) host controller drivers don't 
schedule more than one transfer on most endpoints, but the usb stack can 
accept them. That comment is probably a little stale now too.

dwc2 is probably still the only HCD that schedules more than one 
transfer if possible.

> I introduced struct usbd_xfer dedicated to console input/output
> (cn_xfer_in and cn_xfer_out in struct ucom_cnstate). I tried to do
> without, and piggyback console I/O on regular I/O, but that made
> the code quite complicated, because console I/O has to work when
> no process has open the console device.

This is fine.


> > > The USB to serial adapter has no interrupt endpoint, hence I
> > > understand I cannot use the polling mode. You suggest it could
> > > be set controller-wide, which is admissible when cn_tab->cn_getc()
> > > is used: root device prompt on boot -a, and in DDB.
> > ... nor the use of bulk endpoints in polling mode. In fact they're probably
> > more suited.
> >
> > Did you ever try?
> My statement above about interrupt endpoint was not enough informed,
> I indeed understood afterwards that bulk endpoint could do it. This
> is what is done in my proposed change, and it works.

OK, cool.

Nick