Re: USB output in ucom

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

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");

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

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. 

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

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost