TT> For example, at some point get rid of /dev/cuaXXX
TT> support once and for all, from *all* of the drivers.
This seems to be a religious issue. I personally would love to see
them go since I think of seperate callout device as an administrative
headache and a waste of major and/or minor numbers.
Speaking of which, *8 bit* majors and minors? What were you
*thinking*, Linus? ;-) (yes, I know, this is changing)...
Gael Gence <gael@arcadis.be> wrote:
GG> I know that when the driver read an UART register,
GG> it is cleared. An ioctl returns the LSR status
GG> (if 0, we are transmitting) but that's all.
GG> I've modified the
GG> get_lsr_status function to return the value of lsr instead
GG> of 1 || 0... But i never see that we are receiving data...
Typically, the 16550 LSR register is checked in an interrupt routine:
when the ISR's LSR bit is set, we know to check the LSR. When the LSR
becomes clear, we're done receiving data and we can exit interrupt
processing (I'm simplifying, but you get the picture). Ioctl's aren't
typically processed during interrupt processing unless it's to issue a
BREAK command or something similar.
An ioctl to get current LSR status almost certainly won't be handled
during interrupt context. In fact, I don't see the point of getting
the current LSR status outside of an interrupt routine, which makes me
think that I'm misunderstanding Gael's scenario.
(Drivers for other OS's which support multiple threads within the
kernel might do tricks like scheduling a task to receive the data
outside of the interrupt routine: this becomes especially important
for those OS's with realtime constraints and limits on the amount of
time which can be spent processing an interrupt.)
Thus for Linux, if an ioctl is returning the current LSR, you'll always
get 0, just like you're seeing.
GG> But is there a clean way to give this info to
GG> user space programs with a new member in the serial struct or
GG> something like that ?
Perhaps I'm missing something in the translation, so I'll say that
this looks to me like you're asking for UART register information
to be passsed up to user space when requested. If I misunderstand
your intent, please accept my apology.
If I understand your inquiry correctly, here's why it won't work:
LSR is specific to the 8250, 16450, 16550 UARTs and their many clones
found in PeeCee's. I'm looking at /usr/src/linux/drivers/char/ on a
Sun Sparc 10, which uses Zilog 8530 UARTs. SGI Indy workstations, for
which there is also a porting effort, also uses the 8530. The 8530 is
nothing like the 16550.
Another popular UART is the CD1400, which has yet another set of
registers. And if you're controlling intelligent serial adapters
(e.g. Digiboard, Specialix, Cyclades, Stallion, even my own employer
Central Data ;-) you're not talking to UART registers at all, but
rather communicating via some channel with something akin to a
programming language. Perhaps these intelligent adapters use 16550's,
but the register state is not available to the device driver.
In summary, Linux is being ported to all manner of hardware platforms
and has done a fairly good job of avoiding PC'isms like references in
a user-visible structure to registers in a specific UART model.
I do get that haunting feeling now that I may have misunderstood Gael's
question, but I've already typed all this in :-) so I'm sending it.
Richard Masoner
-- Richard F. Masoner Central Data Corporation richardm@cd.com Champaign, IL 61821 USA +1 217 359 8010 http://www.cd.com/