Re: USB output in ucom

[ 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