Re: General questions about linux driver functionality

[Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>]

On Fri, Mar 13, 2009 at 04:48:47PM -0500, Tim Barr wrote:
> I have been using the 8250 driver code as a baseline for how
> to fix some of these issue. But I am not sure how some of the
> capabilities of the serial driver should be managed.

Good, because that driver does things the right way.

> For instance, because the 8250 has one interrupt mask for parity errors
> , frame errors, overrun, and break, the code was written to use read and
> ignore flags to determine which functions should be processed. So the
> interrupt is always enabled and the specific function counters are
> always incremented.

No, you misinterpret the reason for the 'read' flags and 'ignore' flags.
They exist because of the combinations in the termios.  The termios
settings allow you to enable parity checking independently of ignoring
characters with parity errors.

So, if you ask for INPCK (parity checking, the 'read' flag) without
IGNPAR (ignore characters with parity errors, the 'ignore' flag) you
will see characters with parity errors in the received data stream,
optionally marked as such if PARMRK is set.

However, if both INPCK and IGNPAR are set, then these characters will
not appear.

Finally, if INPCK is clear, parity errors will be ignored and the
character read anyway, however the status counters (which are Linux
specific) will still be incremented.

> But since the Atmel ARM9 processor has separate
> interrupt masks for each function, the atmel_serial code was written to
> mask the interrupt itself if the function was to be ignored. but if the
> driver does that then these functions would not increment the counters
> unless they were specifically enabled. So then the counters would no
> longer work in the same way and would be processor/ board specific.

As I say, these counters are specific to Linux, and aren't a part of the
POSIX Generic Terminal Interface, so I don't think there's a definite
requirement for how these should behave.

It would be reasonable to expect that they should all behave the same.
However, I would suggest that if you possibly can, using limiting
yourself to the POSIX APIs would be a more portable way to go about
this.

The POSIX APIs are documented on www.opengroup.org's website - from
what I remember, there's free registration there to get at the web
based documents.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php