Messages in this thread |  | | | From | Arnd Bergmann <> | | Subject | Re: Writing a console/tty driver -- how to use tty_port? | | Date | Fri, 29 Oct 2010 16:21:42 +0200 |
| |
On Thursday 28 October 2010, Timur Tabi wrote: > Arnd Bergmann wrote: > > If the device is not a UART, the best option may be to make the driver > > a backend to the hvc driver, like e.g. drivers/char/hvc_tile.c. > > The current version *is* a backend to hvc, but I have to abandon that because of > this thread: > > http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085664.html > > I posted a patch that causes hvc to spin if the backend driver returns -EAGAIN, > which is my driver does when the output buffer is full. > > In other words, hvc does not support backend drivers that can detect full output > buffers.
To be more specific, hvc does support retransmitting characters on the tty but not on the console!
The backend drivers return 0 to notify the tty driver that output is busy and should be retried, which will set the timer.
> > This works for all devices with or without interrupts that don't need > > to set up the communication parameters but simply provide a read/write > > character interface. > > If my patch were accepted, I wouldn't need to do the rewrite. Dropping > characters during a printk() is not acceptable for us.
Why do you care about printk output overflowing more than others do? Most of the hvc drivers block internally and never return 0, but those that do probably all need the same solution.
Your original one-line patch from last year didn't seem too wrong, though you might want to check with the iseries people, since that driver might return zero in error cases.
The idea of adding a special return code from ->put_chars to distinguish buffer full from other errors also seemed reasonable, as did the approach to flag the hv_ops to tell the base layer wether you want retransmits or drops.
Arnd
|  |