Hi
Just a quick note. Haven't had the chance to follow up on these threads
due to travel and other obligations, but plan to do so soon.
regards -
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
On Sun, 5 Feb 2012 17:57:40 + Woodruff, Richard r-woodru...@ti.com
wrote:
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Sunday, February 05, 2012 10:03 AM
To: Woodruff, Richard
On Sun, Feb 05, 2012 at 03:37:21PM +, Woodruff, Richard wrote:
[x] What is
From: NeilBrown [mailto:ne...@suse.de]
Sent: Friday, February 03, 2012 8:31 PM
So... if flow control is available, then when we idle the uart we should
set snip ...
Yes I think you can improve situation with such tricks.
Unfortunately there are a few types of low-power idle wakeups which
From: NeilBrown [mailto:ne...@suse.de]
Sent: Monday, February 06, 2012 5:58 PM
To: Woodruff, Richard
Apologies for mangled mails... I am years over due ditching current method.
I don't think it is really OK to drop chars on the UART-to-Debug console.
However it is OK to drop the BAUD rate
On Sat, Feb 04, 2012 at 12:37:06PM -0700, Paul Walmsley wrote:
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
On Sat, Feb 04, 2012 at 10:32:16AM -0700, Paul Walmsley wrote:
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
[detailed discussion of framing errors]
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Saturday, February 04, 2012 10:40 AM
It is entirely unacceptable to drop characters on a serial port through
the use of PM. Many serial protocols just will not cope
On Sun, Feb 05, 2012 at 03:37:21PM +, Woodruff, Richard wrote:
[x] What is acceptable depends is not black and white. Is there some
QOS mapping which can be set per channel which allows runtime PM to
pick a best chose (which may allow for loss and frame issues)?.
What you're asking is
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Sunday, February 05, 2012 10:03 AM
To: Woodruff, Richard
On Sun, Feb 05, 2012 at 03:37:21PM +, Woodruff, Richard wrote:
[x] What is acceptable depends is not black and white. Is there some
QOS mapping which can be
On Fri, Feb 3, 2012 at 9:42 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 3 Feb 2012, Grazvydas Ignotas wrote:
On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown ne...@suse.de wrote:
Maybe it is 37xx specific. I think this is a DM3730.
Not sure if it's the same problem but with 3530 on 3.2 with
On Sat, 4 Feb 2012, Grazvydas Ignotas wrote:
It's case 1. What I wanted to say is that first char is most often
nicely dropped and does not get into the terminal, so I can just type
the command after it. But in some cases terminal gets corrupted char
instead, so I must then first get rid of
On Sat, Feb 04, 2012 at 06:00:56PM +0200, Grazvydas Ignotas wrote:
It's case 1. What I wanted to say is that first char is most often
nicely dropped and does not get into the terminal, so I can just type
the command after it. But in some cases terminal gets corrupted char
instead, so I must
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
If you can't, then you can't do PM in this area while the port is open.
Runtime power management is _supposed_ to be transparent. If it isn't,
it's a bug plain and simple, which blocks the ability for the device to
even _use_ runtime power
On Sat, 4 Feb 2012, Paul Walmsley wrote:
The default behavior needs to be what you state: to not lose characters.
And indeed that is what it is in v3.3: the UART will not enter idle when
the PM runtime autosuspend timeout is -1.
One technical correction on this section -- rather, the
On Sat, Feb 04, 2012 at 09:31:29AM -0700, Paul Walmsley wrote:
Aside from trying some of the muxing suggestions that Neil proposed,
perhaps the UART driver should clear the RX FIFO if the UART detects a
framing error? e.g., section 17.4.4.1.3.5 Error Detection in the
34xx TRM vZT.
Paul, do
On Sat, Feb 04, 2012 at 09:49:57AM -0700, Paul Walmsley wrote:
There is indeed an argument here. The decision of how to act in this
situation needs to be up to the user of the serial port.
The default behavior needs to be what you state: to not lose characters.
And indeed that is what it
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
On Sat, Feb 04, 2012 at 09:49:57AM -0700, Paul Walmsley wrote:
There is indeed an argument here. The decision of how to act in this
situation needs to be up to the user of the serial port.
The default behavior needs to be what you
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
[detailed discussion of framing errors]
Thanks for the detailed description. If the driver is in fact discarding
characters with framing errors -- which I have not personally verified --
then taking further action there is pointless.
-
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
On Sat, Feb 04, 2012 at 10:32:16AM -0700, Paul Walmsley wrote:
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
[detailed discussion of framing errors]
Thanks for the detailed description. If the driver is in fact discarding
characters with framing errors -- which I have not
* Russell King - ARM Linux li...@arm.linux.org.uk [120204 09:16]:
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
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
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
On Sat, Feb 04, 2012 at 10:32:16AM -0700, Paul Walmsley wrote:
On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:
[detailed discussion of framing errors]
Thanks for the detailed description. If the driver is in fact discarding
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
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Hello Neil.
On Fri, 3 Feb 2012, NeilBrown wrote:
Can I comment??... They are good but
I've tried two approaches to getting serial behaviour that I am happy with.
They are with and without runtime pm.
On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown ne...@suse.de wrote:
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
then CPUIDLE enters lower states and I think it uses less power but I
sometimes lose the first char I type (that
On Fri, 3 Feb 2012 12:26:14 +0530 Govindraj govindraj...@gmail.com wrote:
On Fri, Feb 3, 2012 at 9:37 AM, NeilBrown ne...@suse.de wrote:
On Thu, 2 Feb 2012 13:03:01 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
Hi Greg,
On Thu, 26 Jan 2012, Paul Walmsley wrote:
On Thu, 26 Jan
On Fri, 3 Feb 2012 13:42:13 +0200 Grazvydas Ignotas nota...@gmail.com wrote:
On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown ne...@suse.de wrote:
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
then CPUIDLE enters lower
On Fri, Feb 3, 2012 at 6:07 AM, NeilBrown ne...@suse.de wrote:
If I then enabled runtime_pm with a 5 second autosuspend delay:
CORE is still permanently ON (I think the USB might be doing that).
Maybe related to this:
http://thread.gmane.org/gmane.linux.usb.general/56096
--
Felipe Contreras
On Fri, Feb 03, 2012 at 11:07:20PM +1100, NeilBrown wrote:
However what it really shows me is that I was misunderstanding the code
(If I spent the time to verify every conclusion that I jumped to, I'd never
get anywhere :-( ). Better clarify that now.
So this function -
On Fri, 3 Feb 2012, NeilBrown wrote:
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
If I enable runtime pm by setting power/autosuspend_delay_ms (e.g. to
5000)
Runtime PM should be enabled even with
On Fri, 3 Feb 2012, Grazvydas Ignotas wrote:
On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown ne...@suse.de wrote:
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
then CPUIDLE enters lower states and I think it uses less
On Fri, 3 Feb 2012, NeilBrown wrote:
My theory is that there is a delay between the falling RX line waking the
system up, and the CPU enabling the UART - whether enabling the clocks or
doing a full config, I am not sure - though I think the former.
Maybe if we could enable the UART clocks
On Fri, 3 Feb 2012, Russell King - ARM Linux wrote:
If there's an on-going transmission, why is the runtime PM count zero,
meaning that the UART can sleep at the point where serial_omap_tx_empty()
is being called - and obviously there's still characters in the FIFO?
In the case of OMAP,
One other comment..
On Fri, 3 Feb 2012, NeilBrown wrote:
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
I can remove this effect with:
diff --git a/drivers/tty/serial/omap-serial.c
On Fri, 3 Feb 2012, Paul Walmsley wrote:
2. CORE PER powerdomains are awakened
Incidentally, there might be a missing clkdm_add_wakeup() in
mach-omap2/pm34xx.c to wake up PER when CORE is awakened. For people who
are seeing some input character corruption when CORE/PER enters a
low-power
On Sat, 4 Feb 2012, NeilBrown wrote:
On Fri, 3 Feb 2012 12:42:22 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Case 1 is expected and is almost certainly not a bug. As Neil mentioned
it should be bps-rate dependent. It occurs when the first character
transmitted to the OMAP wakes
One correction on this part...
On Fri, 3 Feb 2012, Paul Walmsley wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
My theory is that there is a delay between the falling RX line waking the
system up, and the CPU enabling the UART - whether enabling the clocks or
doing a full config, I am not
On Fri, 3 Feb 2012 13:10:28 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
One other comment..
On Fri, 3 Feb 2012, NeilBrown wrote:
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
I can remove this effect
On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
One correction on this part...
On Fri, 3 Feb 2012, Paul Walmsley wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
My theory is that there is a delay between the falling RX line waking the
system up, and the
On Sat, 4 Feb 2012, NeilBrown wrote:
On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Fri, 3 Feb 2012, Paul Walmsley wrote:
On Fri, 3 Feb 2012, NeilBrown wrote:
My theory is that there is a delay between the falling RX line waking
the
On Sat, 4 Feb 2012, NeilBrown wrote:
On Fri, 3 Feb 2012 13:10:28 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Considering your theory that the UART clocks are being cut while there's
still data in the FIFO, you might consider removing this code at the end
of transmit_chars():
On Fri, 3 Feb 2012 16:02:42 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Sat, 4 Feb 2012, NeilBrown wrote:
On Fri, 3 Feb 2012 13:10:28 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
Considering your theory that the UART clocks are being cut while there's
still data in the
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of NeilBrown
Not sure if it's the same problem but with 3530 on 3.2 with
sleep_timeout set, I usually get first char dropped (as expected) but
sometimes I get corrupted char instead too. Corrupt
On Sat, 4 Feb 2012, Woodruff, Richard wrote:
When you have aggressive PM working at the SOC level you many times lost
a character on UART every since OMAP2. A strange but true statement is
it is nice to see it losing a character on mainline as it as in
indication that PM is likely working.
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, February 03, 2012 7:00 PM
One irritation was some internal interrupt sources were not linked to
low power wakeup events. If you were in interrupt mode and got
characters below watermark you could sleep before interrupt status
Hi Neil
On Sat, 4 Feb 2012, NeilBrown wrote:
Guess what happens if I set autosuspend_delay_ms to 0?
Massive transmit problems. Driver can hardly get anything out before the
UART's fclk is cut...
Just reproduced this on 35xx BeagleBoard. Looks like the UART is indeed
going idle while the
On Fri, 3 Feb 2012, Paul Walmsley wrote:
Will also give the CLOCKACTIVITY bits a quick test.
... which doesn't help. So, software workaround it is.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
On Sat, 4 Feb 2012 00:23:09 + Woodruff, Richard r-woodru...@ti.com
wrote:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of NeilBrown
Not sure if it's the same problem but with 3530 on 3.2 with
sleep_timeout set, I usually get first
On Sat, 4 Feb 2012, Woodruff, Richard wrote:
There have been errata over time in this area. Several I hit were
updated at 3630 time. UART did get IER2 but I don't recall all details
for UART. Probably that is not being used.
Govindraj sent an RFC patch a few days ago to add IER2, which is
On Fri, 3 Feb 2012 19:06:19 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Hi Neil
On Sat, 4 Feb 2012, NeilBrown wrote:
Guess what happens if I set autosuspend_delay_ms to 0?
Massive transmit problems. Driver can hardly get anything out before the
UART's fclk is cut...
Just
On Sat, 4 Feb 2012, NeilBrown wrote:
On Fri, 3 Feb 2012 19:06:19 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Here's a patch that helps. It seems to work down to an
autosuspend_delay_ms of 1 ms. Without it, the best I can get is 8 ms.
Of course, ideally it should work fine at
On Fri, 3 Feb 2012 20:16:08 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Sat, 4 Feb 2012, NeilBrown wrote:
On Fri, 3 Feb 2012 19:06:19 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
Here's a patch that helps. It seems to work down to an
autosuspend_delay_ms of 1 ms.
On Sat, 4 Feb 2012, NeilBrown wrote:
I have to set autosuspend_delay_ms for omap_uart.3 as well before the
behaviour is significant.
But then I see no output corruption. Lots of input corruption of course but
the output looks fine.
OK. Is the input corruption at the beginning of the pasted
On Fri, 3 Feb 2012 20:56:07 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Sat, 4 Feb 2012, NeilBrown wrote:
I have to set autosuspend_delay_ms for omap_uart.3 as well before the
behaviour is significant.
But then I see no output corruption. Lots of input corruption of course but
Hi Greg,
On Thu, 26 Jan 2012, Paul Walmsley wrote:
On Thu, 26 Jan 2012, Greg KH wrote:
Ok, I've just reverted both of these patches for now, please send new
ones when you have them.
Thanks. A pull request is at the bottom of this message. The patches
are also available from the
On Thu, Feb 02, 2012 at 01:03:01PM -0700, Paul Walmsley wrote:
Hi Greg,
On Thu, 26 Jan 2012, Paul Walmsley wrote:
On Thu, 26 Jan 2012, Greg KH wrote:
Ok, I've just reverted both of these patches for now, please send new
ones when you have them.
Thanks. A pull request is at
On Thu, Jan 26, 2012 at 12:34:50PM -0700, Paul Walmsley wrote:
On Thu, 26 Jan 2012, Greg KH wrote:
Ok, I've just reverted both of these patches for now, please send new
ones when you have them.
Thanks. A pull request is at the bottom of this message. The patches
are also available
On Thu, 2 Feb 2012 13:03:01 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Hi Greg,
On Thu, 26 Jan 2012, Paul Walmsley wrote:
On Thu, 26 Jan 2012, Greg KH wrote:
Ok, I've just reverted both of these patches for now, please send new
ones when you have them.
Thanks. A pull
Hello Neil.
On Fri, 3 Feb 2012, NeilBrown wrote:
Can I comment??... They are good but
I've tried two approaches to getting serial behaviour that I am happy with.
They are with and without runtime pm.
If I enable runtime pm by setting power/autosuspend_delay_ms (e.g. to 5000)
On Fri, Feb 3, 2012 at 9:37 AM, NeilBrown ne...@suse.de wrote:
On Thu, 2 Feb 2012 13:03:01 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Hi Greg,
On Thu, 26 Jan 2012, Paul Walmsley wrote:
On Thu, 26 Jan 2012, Greg KH wrote:
Ok, I've just reverted both of these patches for now,
On Wed, Jan 25, 2012 at 09:31:53PM -0700, Paul Walmsley wrote:
On Wed, 25 Jan 2012, Greg KH wrote:
On Wed, Jan 25, 2012 at 08:02:09PM -0700, Paul Walmsley wrote:
On Tue, 24 Jan 2012, gre...@suse.de wrote:
This is a note to let you know that I've just added the patch titled
On Thu, 26 Jan 2012, Greg KH wrote:
Ok, I've just reverted both of these patches for now, please send new
ones when you have them.
Thanks. A pull request is at the bottom of this message. The patches
are also available from the mailing list archives here:
cc lists
Hi Greg
On Tue, 24 Jan 2012, gre...@suse.de wrote:
This is a note to let you know that I've just added the patch titled
tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA
to my tty git tree which can be found at
On Wed, Jan 25, 2012 at 08:02:09PM -0700, Paul Walmsley wrote:
cc lists
Hi Greg
On Tue, 24 Jan 2012, gre...@suse.de wrote:
This is a note to let you know that I've just added the patch titled
tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA
to my tty git
On Wed, 25 Jan 2012, Greg KH wrote:
On Wed, Jan 25, 2012 at 08:02:09PM -0700, Paul Walmsley wrote:
On Tue, 24 Jan 2012, gre...@suse.de wrote:
This is a note to let you know that I've just added the patch titled
tty: serial: OMAP: ensure FIFO levels are set correctly in
65 matches
Mail list logo
