RE: General questions about linux driver functionality

["Tim Barr" <tbarr@xxxxxxxxxxxxx>]

Thanks, the suggestion to check the POSIX specs helps a lot. I think the
only thing that will be difficult will be figuring out how to link
character data with error interrupts when in DMA mode. It could be
comparable to matching errors to character data in the receive buffer of
a 16550, so hopefully the 8250/16550 code has something I can use. Or
maybe I can be safe and flag everything in the DMA transfer associated
with a error interrupt? 

Timothy Barr
Hardware Development Engineer
for Multi-Tech Systems, Inc.
tbarr@xxxxxxxxxxxxx



> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx]
> Sent: Friday, March 13, 2009 5:31 PM
> To: Tim Barr
> Cc: linux-arm@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: General questions about linux driver functionality
> 
> 
> 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