patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Sat, Feb 04, 2012 at 12:24:07PM -0700, Paul Walmsley wrote:
> On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
> 
> > On Sat, Feb 04, 2012 at 10:22:27AM -0700, Paul Walmsley wrote:
> > > No, that is not an example of a protocol with a retry.  That is an example 
> > > of a protocol that has no provision for reliable data delivery.  Sending a 
> > > new data string one second later is not a retry.
> > > 
> > > In such situations, the system integrator would just use the UART in the 
> > > default (lossless) mode.  And if they don't, they'll have to deal with the 
> > > consequences that they chose.  Those of us who ship battery-powered Linux 
> > > devices are indeed capable of making this choice.
> > 
> > Okay, lets see.  You're making a battery powered Linux device.  It has
> > a standard RS232 serial port available, and you allow users to load
> > 'apps' onto it.
> > 
> > Do you run the serial ports in lossless mode?
> 
> Not every serial port is available to arbitrary 'apps.'.  Not every 
> battery-powered Linux device allows users to run arbitrary 'apps.'
> 
> On devices that do allow users to load arbitrary 'apps,' and that allow 
> those 'apps' to have direct access to the serial ports, I personally 
> believe that system integrators should not change the default OMAP serial 
> setting, which is to run the serial ports in lossless mode.
> 
> Here is another example.  Suppose someone builds a GPS receiver with an 
> OMAP that is capable of sending NMEA position sentences, once per second, 
> to a remotely connected serial device.  No receive traffic is expected on 
> that port.
> 
> The position you seem to be advocating is that the mainline Linux kernel 
> should not support any ability to allow the system integrator to 
> affirmatively instruct the SoC to enter device idle between those position 
> sentences.  This will cause the SoC to consume energy to losslessly 
> handle an incoming serial character that will never come.  Is that really 
> what you're advocating?

Stop procrastinating.  Please answer my question.  Then I'll answer yours.