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 majordom
> 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 r
> 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 ...
Yes I think you can improve situation with such tricks.
Unfortunately there are a few types of low-power idle wakeups which mu
On Sun, 5 Feb 2012 17:57:40 + "Woodruff, Richard"
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 acc
> 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
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 w
> 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
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]
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 tha
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 di
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 o
* Russell King - ARM Linux [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 string one second
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 pe
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, 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.
- Pa
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 wha
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 wha
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.
Pau
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 C
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 pow
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, 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 o
On Fri, Feb 3, 2012 at 9:42 PM, Paul Walmsley wrote:
> On Fri, 3 Feb 2012, Grazvydas Ignotas wrote:
>> On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown 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
>> sleep_timeout se
On Fri, 3 Feb 2012 20:56:07 -0700 (MST) Paul Walmsley 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
> > the o
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 pas
On Fri, 3 Feb 2012 20:16:08 -0700 (MST) Paul Walmsley wrote:
> On Sat, 4 Feb 2012, NeilBrown wrote:
>
> > On Fri, 3 Feb 2012 19:06:19 -0700 (MST) Paul Walmsley
> > wrote:
> > >
> > > Here's a patch that helps. It seems to work down to an
> > > autosuspend_delay_ms of 1 ms. Without it, the
On Sat, 4 Feb 2012, NeilBrown wrote:
> On Fri, 3 Feb 2012 19:06:19 -0700 (MST) Paul Walmsley 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 autos
On Fri, 3 Feb 2012 19:06:19 -0700 (MST) Paul Walmsley 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 reproduc
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 i
On Sat, 4 Feb 2012 00:23:09 + "Woodruff, Richard"
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 char d
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 major
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
> 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 stat
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 worki
> 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. Co
On Fri, 3 Feb 2012 16:02:42 -0700 (MST) Paul Walmsley wrote:
> On Sat, 4 Feb 2012, NeilBrown wrote:
>
> > On Fri, 3 Feb 2012 13:10:28 -0700 (MST) Paul Walmsley
> > wrote:
> >
> > > Considering your theory that the UART clocks are being cut while there's
> > > still data in the FIFO, you migh
On Sat, 4 Feb 2012, NeilBrown wrote:
> On Fri, 3 Feb 2012 13:10:28 -0700 (MST) Paul Walmsley 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 Sat, 4 Feb 2012, NeilBrown wrote:
> On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley 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 Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley 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 CPU
On Fri, 3 Feb 2012 13:10:28 -0700 (MST) Paul Walmsley wrote:
> One other comment..
>
> On Fri, 3 Feb 2012, NeilBrown wrote:
>
> > On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley
> > wrote:
> >
> > > On Fri, 3 Feb 2012, NeilBrown wrote:
> > >
> > > > I can remove this effect with:
> >
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
On Sat, 4 Feb 2012, NeilBrown wrote:
> On Fri, 3 Feb 2012 12:42:22 -0700 (MST) Paul Walmsley 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 the chip
On Fri, 3 Feb 2012 12:42:22 -0700 (MST) Paul Walmsley wrote:
> On Fri, 3 Feb 2012, Grazvydas Ignotas wrote:
>
> > On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown wrote:
> > > On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley
> > > wrote:
> > >> On Fri, 3 Feb 2012, NeilBrown wrote:
> > >>
> > >
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
One other comment..
On Fri, 3 Feb 2012, NeilBrown wrote:
> On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley wrote:
>
> > On Fri, 3 Feb 2012, NeilBrown wrote:
> >
> > > I can remove this effect with:
> > >
> > > diff --git a/drivers/tty/serial/omap-serial.c
> > > b/drivers/tty/serial/oma
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, tha
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 cloc
On Fri, 3 Feb 2012, Grazvydas Ignotas wrote:
> On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown wrote:
> > On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley
> > wrote:
> >> On Fri, 3 Feb 2012, NeilBrown wrote:
> >>
> >> > then CPUIDLE enters lower states and I think it uses less power but I
> >>
On Fri, 3 Feb 2012, NeilBrown wrote:
> On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley 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 power/autos
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 - serial_omap_tx_e
On Fri, Feb 3, 2012 at 6:07 AM, NeilBrown 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
--
To unsubs
On Fri, 3 Feb 2012 13:42:13 +0200 Grazvydas Ignotas wrote:
> On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown wrote:
> > On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley
> > wrote:
> >> On Fri, 3 Feb 2012, NeilBrown wrote:
> >>
> >> > then CPUIDLE enters lower states and I think it uses less po
On Fri, 3 Feb 2012 12:26:14 +0530 Govindraj wrote:
> On Fri, Feb 3, 2012 at 9:37 AM, NeilBrown wrote:
> > On Thu, 2 Feb 2012 13:03:01 -0700 (MST) Paul Walmsley
> > wrote:
> >
> >> Hi Greg,
> >>
> >> On Thu, 26 Jan 2012, Paul Walmsley wrote:
> >>
> >> > On Thu, 26 Jan 2012, Greg KH wrote:
> >>
On Fri, Feb 3, 2012 at 11:54 AM, NeilBrown wrote:
> On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley 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 is known) but also
On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley 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 9:37 AM, NeilBrown wrote:
> On Thu, 2 Feb 2012 13:03:01 -0700 (MST) 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 n
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 Thu, 2 Feb 2012 13:03:01 -0700 (MST) 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 pul
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 avai
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 pul
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
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:
http://marc.info/?l=linux-arm-ker
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
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 corre
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
> >
>
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
> git://git.kernel.org/pub/scm/linux/
66 matches
Mail list logo
