Re: USB output in ucom

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

[ Coming to this late... sorry]

On 12/08/2025 15:38, Emmanuel Dreyfus wrote:
> On Tue, Jul 15, 2025 at 03:41:16PM -0000, Michael van Elst wrote:
> > > I understand kprintf operates at IPL_HIGH, while the USB subssytem
> > > processes I/O at IPL_SOFTCLOCK. Does that mean I just cannot rely
> > > on USB for console output?
> >
> > It can only work if USB is used in polling mode, which usually also means
> > that you must not use that USB controller for anything else.
>
> I had great success with a kernel thread that takes care of the
> actual USB output, while being fed by cn_tab->cn_putc() through a
> ring buffer. That works well for displaying kernel messages.

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.

Also, I don't remember anything in polling mode that would prevent 
multiple transfers at once.

> cn_tab->cn_getc() is another beast. It is called at splhigh and
> wants a char immediatly. I have red the polling code used by ukbd.c
> and uhidev.c I understand it needs to use usbd_open_pipe_intr()
> and that this uses an interrupt endpoint, not a bulk one.
>
> 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?

Nick