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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
