UART driver as kld - how?

[Ian Lepore]

On Mon, 2019-11-04 at 08:32 -0700, Warner Losh wrote:
> On Mon, Nov 4, 2019 at 4:35 AM Milan Obuch <freebsd-hackers at dino.sk> wrote:
> 
> > On Sun, 3 Nov 2019 13:01:18 +0100
> > Milan Obuch <freebsd-hackers at dino.sk> wrote:
> > 
> > > On Sat, 2 Nov 2019 21:23:21 -0700
> > > Oleksandr Tymoshenko <gonzo at bluezbox.com> wrote:
> > > 
> > > > Milan Obuch (freebsd-hackers at dino.sk) wrote:
> > 
> > 
[...]
> > > Back to testing... probe function now does work, so I am going to
> > > analyze what should be done in attach... and why I am getting now
> > > panic... I'll write again when I find another obstacle I do not
> > > understand or I have working driver, whatever comes first :)
> > > 
> > 
> > Now I am getting further... attach works now, device nodes expected are
> > being created, but there are some warnings mentioning locks on detach.
> > Also, my hardware design currently does not use interrupts. Do we have
> > any example of uart device being polled?
> > 
> 
> All UARTS have interrupts. It's the nature of UARTS. At least that's the
> nature of the model that uart(4) uses: there's a number of conditions that
> we notice from time to time and make a note in the ipend mask so that we
> can call uart specific code later to deal with that condition. Your system
> may not connect those uart signals to a system interrupt, but the internal
> model is the same.
> 
> I'd just use callouts to poll. Then call what would be the interrupt
> routines from there. Since we have a separation between noting a condition
> and processing it, that should work well. However, I'd also expect issues
> at higher data rates unless you have very deep FIFOs and some kind of
> hardware-assist for flow control.
> 

Polling support is built into uart(4) already.  Just set
debug.uart_force_poll=1 in loader.conf or via sysctl.  You can also set
debug.uart_poll_freq (default is 50hz).

-- Ian