On Wed, Feb 08, 2012 at 11:53:27AM -0800, Greg KH wrote: > On Wed, Feb 08, 2012 at 07:23:34PM +0200, Grazvydas Ignotas wrote: > > On Wed, Feb 8, 2012 at 7:06 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote: > > >> Grazvydas Ignotas <notasas@xxxxxxxxx> writes: > > >> > > >> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman <khilman@xxxxxx> wrote: > > >> >> Kevin Hilman <khilman@xxxxxx> writes: > > >> >> > > >> >>> This one is indeed strange. I have not seen this on the 34xx devices > > >> >>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3). > > >> >> > > >> >> OK, I've reproduced this on v3.3-rc2. > > >> >> > > >> >> The reason I wasn't seeing this is because I'm using the fixes Paul has > > >> >> already posted that fix this problem: > > >> >> > > >> >> http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2 > > >> >> > > >> >> Kevin > > >> > > > >> > But it looks like these are now queued for 3.4 in tty tree? > > >> > > >> I believe they were targettted for 3.3-rc. > > >> > > >> Paul, Greg, can you confirm? > > > > > > I have no idea what you are refering to here, please be much more > > > specific. You can look at the linux-next tree to answer your question > > > yourself as well... > > > > It's about these patches in gregkh/tty.git tty-next: > > 6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in > > microseconds, not milliseconds > > edbe5db tty: serial: OMAP: block idle while the UART is transferring > > data in PIO mode > > 5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode > > > > It would look to me like they are queued for 3.4 but Kevin says there > > were intended for 3.3-rc. > > Kevin might have wished they would go into 3.3, but given that the first > round of these patches had to be reverted, I thought it safer to wait > for 3.4. Greg, There's currently a regression here: 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos) which causes OMAP3 platforms to spit out 16 characters every couple of seconds after typing 'dmesg' on the serial console. This is something which used to work before the above commit. The above commit doesn't revert because there's a bunch of other changes in later commits which remove some of the stuff it depends on, so a simple revert is out. What I'd like to see from OMAP folk is whether there's a simple solution. If not, then edbe5db looks like it should be targetted for -rc. However, I've not yet tested edbe5db to confirm whether it solves my observations (I've not seen it either). -- 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
