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:
quoted
On Wed, Feb 8, 2012 at 7:06 PM, Greg KH [off-list ref] wrote:
quoted
On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
quoted
Grazvydas Ignotas [off-list ref] writes:
quoted
On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman [off-list ref] wrote:
quoted
Kevin Hilman [off-list ref] writes:
quoted
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html