Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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 output looks fine.
> 
> OK.  Is the input corruption at the beginning of the pasted buffer, or the 
> middle?  And this is with CPUIdle enabled?
> 
> With CPUIdle disabled here, what I thought was output corruption occurs in 
> the middle of the pasted buffer occasionally.  But it might be input 
> corruption, if the CPU manages to empty the RX FIFO while the TX FIFO is 
> empty.
> 
> 
> - Paul

Yes, cpu-idle is enabled.

I think corruption is mostly early, though it isn't very consistent.

e.g.

# C!jHhzys/Y?omap/omap_uart.2/power/autosuspend_delay_ms
-bash: !jHhzys/Y?omap/omap_uart.2/power/autosuspend_delay_ms: event not found
# echo 0 > /sys/devices/platFK/mpWWt.]au%e_mHHHhQ 5
-bash: /sys/devices/platFK/mpWWt.]au%e_mHHHhQ: No such file or directory


NeilBrown


signature.asc
Description: PGP signature

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 buffer, or the 
middle?  And this is with CPUIdle enabled?

With CPUIdle disabled here, what I thought was output corruption occurs in 
the middle of the pasted buffer occasionally.  But it might be input 
corruption, if the CPU manages to empty the RX FIFO while the TX FIFO is 
empty.


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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 best I can get is 8 ms.
> > > 
> > > Of course, ideally it should work fine at autosuspend_delay_ms = 0, so 
> > > likely there's some other infelicity that we're currently missing.
> > > 
> > > Neil, care to give this a test and confirm it on your setup?
> > 
> > Yes, that seems to make the output corruption go away.
> 
> Cool, thanks for the test :-)
> 
> > Even with small autosuspend_delay_ms down to 0 it doesn't corrupt output,
> > but as the first input byte is corrupted, I cannot really type with those
> > setting (so I ssh to gain control again).
> 
> Could you try pasting in a buffer from another window?  If I paste in the 
> buffer at the bottom of this message a few times, I see some output 
> corruption. 

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.

NeilBrown


> 
> 
> - Paul
> 
> 
>  
> ;
> ;
> ;
> ;
> cat  /sys/devices/platform/omap/omap_uart.2/power/autosuspend_delay_ms
> echo 0 > /sys/devices/platform/omap/omap_uart.2/power/autosuspend_delay_ms
> cat /proc/interrupts
> ;
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



signature.asc
Description: PGP signature

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 autosuspend_delay_ms = 0, so 
> > likely there's some other infelicity that we're currently missing.
> > 
> > Neil, care to give this a test and confirm it on your setup?
> 
> Yes, that seems to make the output corruption go away.

Cool, thanks for the test :-)

> Even with small autosuspend_delay_ms down to 0 it doesn't corrupt output,
> but as the first input byte is corrupted, I cannot really type with those
> setting (so I ssh to gain control again).

Could you try pasting in a buffer from another window?  If I paste in the 
buffer at the bottom of this message a few times, I see some output 
corruption. 


- Paul


 
;
;
;
;
cat  /sys/devices/platform/omap/omap_uart.2/power/autosuspend_delay_ms
echo 0 > /sys/devices/platform/omap/omap_uart.2/power/autosuspend_delay_ms
cat /proc/interrupts
;

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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 reproduced this on 35xx BeagleBoard.  Looks like the UART is indeed 
> going idle while the TX FIFO has bytes in it.

That makes me happy :-)

> 
> 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 autosuspend_delay_ms = 0, so 
> likely there's some other infelicity that we're currently missing.
> 
> Neil, care to give this a test and confirm it on your setup?

Yes, that seems to make the output corruption go away.

Even with small autosuspend_delay_ms down to 0 it doesn't corrupt output,
but as the first input byte is corrupted, I cannot really type with those
setting (so I ssh to gain control again).

The patch disables the IDLEMODE_SMART setting that happens on runtime
suspend/resume so that the IDLEMODE_NO setting stays in force.

So it clearly isn't "stopping the clocks" that is the problem - as I first
imagined - but rather the SIDLE handshake isn't doing what we think it should
do.

Thanks,
NeilBrown



signature.asc
Description: PGP signature

RE: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 good, but 
we're still awaiting the followup patch for it.

> > From: Paul Walmsley [mailto:p...@pwsan.com]
> > Sent: Friday, February 03, 2012 7:00 PM
> 
> > What's particularly remarkable is that it looks like the UARTs will
> > idle-ack while their transmit FIFOs have data in them (!)
> 
> Generally a module can ACK its ICLK if it is not used internally. The 
> FCLK can push data out with out ICLK and is controlled separately always 
> (omap4 changed encoding, to optional clock). This allows interconnect to 
> idle during tx to save power. 

Yep, that's a good point.  Unfortunately the PER has a hardware sleep 
dependency with the CORE_L3 clockdomain on OMAP3... so I'm not sure how 
much power we'd be able to save.  Perhaps some: it appears that the UART3 
functional clock comes from the CORE_L4 clockdomain.  So it might be worth 
implementing some extra intelligence here.  The kernel code is disabling 
both the ICLK and the FCLK simultaneously, so that may not be optimal in 
this situation.

In the short-term, on the kernel side, we should just keep the PM runtime 
count non-zero when the UART is transmitting.  Since we can get an 
interrupt when the TX is done, or close to being done anyway, we can just 
disable the clocks at that point.  Not ideal, but should work.

> The trick is to ensure all module wakeup plumbing is enabled so a 
> functional tx irq will flow.  Audits last showed several drivers missing 
> steps (omap specific). Some drivers seemed to rely on static 
> dependencies or coincident neighbor activity to allow their functional 
> interrupt to flow... to many interdependent custom details... and yes 
> some errata.

Yeah.  I think we've got an acceptable workaround for the missing TX 
wakeup problem.  And we've got a somewhat unpleasant workaround for the 
missing RX timeout wakeup problem.   Now we just need to put together a 
strategy for the idle-during-TX problem...

> Anyway, even with all SOC specific wake bits you may lose the character 
> with latency of restart. Point I was raising was external chip hook can 
> not be neglected as its part of equation.

Indeed.

Thanks for the info -- it's always nice to see your posts on the lists --


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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 dropped (as expected) but
> > > sometimes I get corrupted char instead too. Corrupt char seems to
> > > almost always happen if I set cpufreq to powersave, on performace it's
> > > almost always ok, so maybe it's some timing problem,
> > 
> > I see that too - I'm glad someone else does :-)
> 
> 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.
> 
> If you just hook up simple RX and TX lines and not other flow control it is 
> very likely especially with older OMAPs you can lose the 'wake' character on 
> debug console. The UART operates on a derived clock from a 96MHz DPLL which 
> was probably stopped. When the wakeup event hits the IO ring many internals 
> may need to repower and its source DPLL needs to relock. This all can take a 
> while and you can lose the start bit at high baud rate. If you use flow 
> control you might be able to get ahead of it.

So... if flow control is available, then when we idle the uart we should set
the trigger so that RTS is de-asserted as soon as one character arrives.
That would minimise the number of corrupt character we receive and ensure we
resync as early as possible (I have seen 2 corrupt characters when CR,NL
arrive back-to-back.  Neither get through correctly).

Actually ... could we make the off-mode setting of the RTS pin be "ready to
send", but as soon as we wake up, it is reset to "don't send now" until
everything is properly awake and configured?  That should ensure only one
byte is lost.


> Outside of debug console, this loss has not been huge. Protocols like irda 
> would retransmit their magic wake packets. You can move between DMA and 
> interrupt modes with activity. So far there has been a work around per 
> attached device.


What about bluetooth?  HCI/UART doesn't seem to have a lot of error
handling.  Maybe it has enough though.
(I have bluetooth on UART1 ... of course we might not have the same problems
on UART1 .. I haven't played with bluetooth much yet).

Thanks for the insights,

NeilBrown


signature.asc
Description: PGP signature

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 TX FIFO has bytes in it.

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 autosuspend_delay_ms = 0, so 
likely there's some other infelicity that we're currently missing.

Neil, care to give this a test and confirm it on your setup?

Will also give the CLOCKACTIVITY bits a quick test.


- Paul

>From 3b8a272e7af23abe472c594da9bce514a0468a80 Mon Sep 17 00:00:00 2001
From: Paul Walmsley 
Date: Fri, 3 Feb 2012 19:00:03 -0700
Subject: [PATCH] UART idle TX bug test

The UART driver messes around with the SYSCONFIG bits behind the hwmod 
code's back.  For debugging purposes, prevent the hwmod code from changing 
the SYSCONFIG register.  That in turn should allow the SIDLEMODE no-idle 
setting to persist through the length of the MPU's involvement with the 
transmit operation, which it currently does not.

Then, prevent the UART from being put back into no-idle until we get the 
TX empty interrupt from the UART.  That should ensure that the TX FIFO is 
drained before allowing the UART to go into idle.

---
 arch/arm/mach-omap2/omap_hwmod.c |4 ++--
 drivers/tty/serial/omap-serial.c |9 +++--
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..bfd7e24 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -980,7 +980,7 @@ static void _enable_sysc(struct omap_hwmod *oh)
v = oh->_sysc_cache;
sf = oh->class->sysc->sysc_flags;
 
-   if (sf & SYSC_HAS_SIDLEMODE) {
+   if (strcmp(oh->name, "uart3") && sf & SYSC_HAS_SIDLEMODE) {
idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
_set_slave_idlemode(oh, idlemode, &v);
@@ -1047,7 +1047,7 @@ static void _idle_sysc(struct omap_hwmod *oh)
v = oh->_sysc_cache;
sf = oh->class->sysc->sysc_flags;
 
-   if (sf & SYSC_HAS_SIDLEMODE) {
+   if (strcmp(oh->name, "uart3") && sf & SYSC_HAS_SIDLEMODE) {
idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
HWMOD_IDLEMODE_FORCE : HWMOD_IDLEMODE_SMART;
_set_slave_idlemode(oh, idlemode, &v);
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 72fa783..fbefcf2 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -159,9 +159,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
}
 
-   if (!up->use_dma && pdata->set_forceidle)
-   pdata->set_forceidle(up->pdev);
-
pm_runtime_mark_last_busy(&up->pdev->dev);
pm_runtime_put_autosuspend(&up->pdev->dev);
 }
@@ -251,6 +248,7 @@ ignore_char:
 static void transmit_chars(struct uart_omap_port *up)
 {
struct circ_buf *xmit = &up->port.state->xmit;
+   struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
int count;
 
if (up->port.x_char) {
@@ -261,6 +259,8 @@ static void transmit_chars(struct uart_omap_port *up)
}
if (uart_circ_empty(xmit) || uart_tx_stopped(&up->port)) {
serial_omap_stop_tx(&up->port);
+   if (!up->use_dma && pdata->set_forceidle)
+   pdata->set_forceidle(up->pdev);
return;
}
count = up->port.fifosize / 4;
@@ -274,9 +274,6 @@ static void transmit_chars(struct uart_omap_port *up)
 
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(&up->port);
-
-   if (uart_circ_empty(xmit))
-   serial_omap_stop_tx(&up->port);
 }
 
 static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
-- 
1.7.9

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Woodruff, Richard]

> 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
> > showed up (as you had to wait several frame times before functional
> > interrupt asserted) but there was no wake at anticipated frame timeout
> > because lack of linking of internal event to wake event.
> 
> Indeed, it seems that we are just now working around these wakeup-related
> bugs.  Kind of surprising that no errata showed up for them.

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.

> What's particularly remarkable is that it looks like the UARTs will
> idle-ack while their transmit FIFOs have data in them (!)

Generally a module can ACK its ICLK if it is not used internally. The FCLK can 
push data out with out ICLK and is controlled separately always (omap4 changed 
encoding, to optional clock). This allows interconnect to idle during tx to 
save power. The trick is to ensure all module wakeup plumbing is enabled so a 
functional tx irq will flow.  Audits last showed several drivers missing steps 
(omap specific). Some drivers seemed to rely on static dependencies or 
coincident neighbor activity to allow their functional interrupt to flow... to 
many interdependent custom details... and yes some errata.

Anyway, even with all SOC specific wake bits you may lose the character with 
latency of restart. Point I was raising was external chip hook can not be 
neglected as its part of equation.

Regards,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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.

We've been losing wakeup characters in mainline for many years now ;-)

> 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 
> showed up (as you had to wait several frame times before functional 
> interrupt asserted) but there was no wake at anticipated frame timeout 
> because lack of linking of internal event to wake event.

Indeed, it seems that we are just now working around these wakeup-related 
bugs.  Kind of surprising that no errata showed up for them.

What's particularly remarkable is that it looks like the UARTs will 
idle-ack while their transmit FIFOs have data in them (!)


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] pinctrl: Add simple pinmux driver using device tree data

[Tony Lindgren]

* Linus Walleij  [120203 14:18]:
> On Fri, Feb 3, 2012 at 9:55 PM, Tony Lindgren  wrote:
> 
> > Add simple pinmux driver using device tree data.
> >
> > Currently this driver only works on omap2+ series of
> > processors, where there is either an 8 or 16-bit mux
> > register for each pin. Support for other similar pinmux
> > controllers could be added.
> 
> So since it's not named pinctrl-omap I guess you intend it
> to be fully generic for simple muxes, which is nice!
> If people start ACK:ing this I will be happy with it too,
> because it's very easy to understand.

Yes the idea is that it should stay generic. I don't know
how easy or hard it would be to enhance it to support
also other type mux cases, like multiple mux registers per
pin, but I guess we'll see.
 
> > Note that this patch does not yet support pinconf_ops
> > or GPIO. Further, alternative mux modes are not yet
> > handled.
> 
> Do you want to evolve the patch for these features
> or do you want to refactor it in later?

Well I'd like to test it a bit more first as I've only
done minimal testing so far. So maybe let's assume there
will be one more iteration at least.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Woodruff, Richard]

> 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 char seems to
> > almost always happen if I set cpufreq to powersave, on performace it's
> > almost always ok, so maybe it's some timing problem,
> 
> I see that too - I'm glad someone else does :-)

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.

If you just hook up simple RX and TX lines and not other flow control it is 
very likely especially with older OMAPs you can lose the 'wake' character on 
debug console. The UART operates on a derived clock from a 96MHz DPLL which was 
probably stopped. When the wakeup event hits the IO ring many internals may 
need to repower and its source DPLL needs to relock. This all can take a while 
and you can lose the start bit at high baud rate. If you use flow control you 
might be able to get ahead of it.

As the silicon process has shrunk from 90nm (omap2) to 65nm (omap3) to 45nm 
(omap4) the DPLL relock times have dropped a lot. With certain DPLL parameters 
it could take hundreds of uS to relock in OMAP2. And there are more variables 
to latency stack up than just DPLL. Most of these have improved (gotten 
smaller) over time.

Always the hack for debug console was activity timer along with denying idle 
while SW and HW TX FIFOs had characters in them. This made debug console 
useable.

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 showed up (as you had to wait several 
frame times before functional interrupt asserted) but there was no wake at 
anticipated frame timeout because lack of linking of internal event to wake 
event.

Outside of debug console, this loss has not been huge. Protocols like irda 
would retransmit their magic wake packets. You can move between DMA and 
interrupt modes with activity. So far there has been a work around per attached 
device.

If your screen blanks and you hit a char to wakeup, do you expect to see the 
character or do you throw it away?  You can set some timeout or policy to deny 
lower c-states which can ensure a debug console doesn't have any issue.  If 
your application is a phone it is not likely something you would do.

Maybe your issue today is due to some other software bug... but at the end of 
the trail you still may have an issue unless your attached hardware 
accommodates.

Regards,
Richard W.


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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 might consider removing this code at the end 
> > > of transmit_chars():
> > > 
> > >   if (uart_circ_empty(xmit))
> > >   serial_omap_stop_tx(&up->port);
> > 
> > I read the code and chickened out of just removing that.
> > serial_omap_stop_tx seem to do 2 things:
> >  1/ tell the uart to stop sending interrupts when the tx fifo is empty
> >  2/ set forceidle (really smartidle) on the uart.
> > 
> > I didn't feel comfortable removing '1' as I thought it might generate an
> > interrupt storm .. maybe not.
> 
> Might be worth a try.  In theory, since the current UART driver sets the 
> TX_EMPTY flag in the SCR register, the UART should only raise a TX 
> interrupt when the FIFO + shift register are totally empty.  So hopefully 
> you should only get one extra interrupt per TTY transmit operation.
> 
> > Instead I just removed '2'.  In fact I replaced the 'set_forceidle' call 
> > with
> > 'set_noidle'.  So the uart should never report that it was idle.
> > 
> > I did this with my other patch removed so pm_runtime_put() was still being
> > called.
> > 
> > Result:  I still get corruption.
> > So having the UART say "no, I'm not idle" does *not* stop the clock
> > being turned off when we use omap_hwmod_idle() to turn off the clocks.
> 
> Hmm that's doubtful.  If that's really so, then we should be seeing 
> massive UART transmit problems.  I'd expect that the driver wouldn't be 
> able to get any transmit buffers out the door at all before the UART's 
> fclk is cut.

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...


> 
> What's probably happening in this case is that the hwmod code is rewriting 
> the UART SIDLEMODE bits in the hwmod code's _idle() function.  This gets 
> called as part of the PM runtime suspend operation.  So it's bypassing 
> your debugging hack :-)  The hwmod code expects to control the SYSCONFIG 
> register bits itself, and the current way that the UART driver messes with 
> the SYSCONFIG bits is a total hack that that hwmod code is not expecting.  
> You could try disabling that behavior in _idle_sysc() by adding a hack to 
> skip it if it's the UART3 hwmod.
> 
> > When we turn off a clock, if that is the last clock in the clock-domain, we
> > also turn off the clock-domain (I think).
> 
> That's only true if the clockdomain is programmed to use 
> software-supervised idle.  CORE & PER should both be programmed to 
> hardware-supervised idle by mach-omap2/pm34xx.c.  In that case, we let the 
> PRCM put the clockdomain to sleep by itself.
> 
> > Could it be that the clock-domain doesn't do any handshaking with modules,
> > and so turns off the clocks even though they are being used?
> 
> Probably not -- I'd think that hardware-supervised idle wouldn't work at 
> all if that were true.

Thanks for those hints.  Next time I dive into the code/doco they might help
me understand a bit more.

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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():
> > 
> > if (uart_circ_empty(xmit))
> > serial_omap_stop_tx(&up->port);
> 
> I read the code and chickened out of just removing that.
> serial_omap_stop_tx seem to do 2 things:
>  1/ tell the uart to stop sending interrupts when the tx fifo is empty
>  2/ set forceidle (really smartidle) on the uart.
> 
> I didn't feel comfortable removing '1' as I thought it might generate an
> interrupt storm .. maybe not.

Might be worth a try.  In theory, since the current UART driver sets the 
TX_EMPTY flag in the SCR register, the UART should only raise a TX 
interrupt when the FIFO + shift register are totally empty.  So hopefully 
you should only get one extra interrupt per TTY transmit operation.

> Instead I just removed '2'.  In fact I replaced the 'set_forceidle' call with
> 'set_noidle'.  So the uart should never report that it was idle.
> 
> I did this with my other patch removed so pm_runtime_put() was still being
> called.
> 
> Result:  I still get corruption.
> So having the UART say "no, I'm not idle" does *not* stop the clock
> being turned off when we use omap_hwmod_idle() to turn off the clocks.

Hmm that's doubtful.  If that's really so, then we should be seeing 
massive UART transmit problems.  I'd expect that the driver wouldn't be 
able to get any transmit buffers out the door at all before the UART's 
fclk is cut.

What's probably happening in this case is that the hwmod code is rewriting 
the UART SIDLEMODE bits in the hwmod code's _idle() function.  This gets 
called as part of the PM runtime suspend operation.  So it's bypassing 
your debugging hack :-)  The hwmod code expects to control the SYSCONFIG 
register bits itself, and the current way that the UART driver messes with 
the SYSCONFIG bits is a total hack that that hwmod code is not expecting.  
You could try disabling that behavior in _idle_sysc() by adding a hack to 
skip it if it's the UART3 hwmod.

> When we turn off a clock, if that is the last clock in the clock-domain, we
> also turn off the clock-domain (I think).

That's only true if the clockdomain is programmed to use 
software-supervised idle.  CORE & PER should both be programmed to 
hardware-supervised idle by mach-omap2/pm34xx.c.  In that case, we let the 
PRCM put the clockdomain to sleep by itself.

> Could it be that the clock-domain doesn't do any handshaking with modules,
> and so turns off the clocks even though they are being used?

Probably not -- I'd think that hardware-supervised idle wouldn't work at 
all if that were true.


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] pinctrl: Add simple pinmux driver using device tree data

[Linus Walleij]

On Fri, Feb 3, 2012 at 9:55 PM, Tony Lindgren  wrote:

> Add simple pinmux driver using device tree data.
>
> Currently this driver only works on omap2+ series of
> processors, where there is either an 8 or 16-bit mux
> register for each pin. Support for other similar pinmux
> controllers could be added.

So since it's not named pinctrl-omap I guess you intend it
to be fully generic for simple muxes, which is nice!
If people start ACK:ing this I will be happy with it too,
because it's very easy to understand.

> Note that this patch does not yet support pinconf_ops
> or GPIO. Further, alternative mux modes are not yet
> handled.

Do you want to evolve the patch for these features
or do you want to refactor it in later?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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
> > > > 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 immediately after returning 
> > > > from the
> > > > WFI instruction we could avoid the corruption
> > > 
> > > The PRCM should be re-enabling the UART's functional clock itself, with 
> > > no 
> > > kernel involvement.  The sequence should go something like this 
> > > (simplified):
> > > 
> > > 1. I/O wakeup occurs
> > > 
> > > 2. CORE & PER powerdomains are awakened
> > > 
> > > 3. The UART notices an event on its input lines and deasserts its idle-ack
> > 
> > It just occurred to me that, supposedly, the only UART input line that is 
> > attached to the SWAKEUP signal is CTS.  So the UART may not in fact be 
> > able to deassert its idle-ack autonomously at this point.
> 
> How does that relate to the RX_CTS_WU_EN bit which enables an interrupt on 
> "a falling edge of pins RX, nCTS, or nDSR"

That's the bit I'm talking about :-)  Maybe it might work appropriately, 
then, if it also tests RX.  Section 19.3.2.3 "Wake-up Request" only 
mentions the CTS lines.  Flip a coin ;-)

> This seems to be a "wakeup interrupt", bit it isn't clear what it wakes us.

The UART.  It should send an SWAKEUP to the PRCM and bring the UART out of 
idle-ack.

- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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 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 immediately after returning from 
> > > the
> > > WFI instruction we could avoid the corruption
> > 
> > The PRCM should be re-enabling the UART's functional clock itself, with no 
> > kernel involvement.  The sequence should go something like this 
> > (simplified):
> > 
> > 1. I/O wakeup occurs
> > 
> > 2. CORE & PER powerdomains are awakened
> > 
> > 3. The UART notices an event on its input lines and deasserts its idle-ack
> 
> It just occurred to me that, supposedly, the only UART input line that is 
> attached to the SWAKEUP signal is CTS.  So the UART may not in fact be 
> able to deassert its idle-ack autonomously at this point.

How does that relate to the RX_CTS_WU_EN bit which enables an interrupt on 
"a falling edge of pins RX, nCTS, or nDSR"

This seems to be a "wakeup interrupt", bit it isn't clear what it wakes us.

> 
> So you might want to give your clock re-enable after WFI idea a shot!  It 
> would be interesting if it helps.

Might be a bit beyond me at the moment :-(

Thanks,
NeilBrown

> 
> I regret the oversight, 
> 
> 
> - Paul



signature.asc
Description: PGP signature

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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:
> > > > 
> > > > diff --git a/drivers/tty/serial/omap-serial.c 
> > > > b/drivers/tty/serial/omap-serial.c
> > > > index f809041..c7ef760 100644
> > > > --- a/drivers/tty/serial/omap-serial.c
> > > > +++ b/drivers/tty/serial/omap-serial.c
> > > > @@ -440,7 +440,8 @@ static unsigned int serial_omap_tx_empty(struct 
> > > > uart_port *port)
> > > > spin_lock_irqsave(&up->port.lock, flags);
> > > > ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 
> > > > 0;
> > > > spin_unlock_irqrestore(&up->port.lock, flags);
> > > > -   pm_runtime_put(&up->pdev->dev);
> > > > +   pm_runtime_mark_last_busy(&up->pdev->dev);
> > > > +   pm_runtime_put_autosuspend(&up->pdev->dev);
> > > > return ret;
> > > >  }
> 
> It's a little surprising that this helps.  The pm_runtime_get*() and 
> _put*() in serial_omap_tx_empty() are just intended to ensure that the 
> UART's clocks are running for that LSR register read.
> 
> 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():
> 
>   if (uart_circ_empty(xmit))
>   serial_omap_stop_tx(&up->port);

I read the code and chickened out of just removing that.
serial_omap_stop_tx seem to do 2 things:
 1/ tell the uart to stop sending interrupts when the tx fifo is empty
 2/ set forceidle (really smartidle) on the uart.

I didn't feel comfortable removing '1' as I thought it might generate an
interrupt storm .. maybe not.
Instead I just removed '2'.  In fact I replaced the 'set_forceidle' call with
'set_noidle'.  So the uart should never report that it was idle.

I did this with my other patch removed so pm_runtime_put() was still being
called.

Result:  I still get corruption.
So having the UART say "no, I'm not idle" does *not* stop the clock
being turned off when we use omap_hwmod_idle() to turn off the clocks.

When we turn off a clock, if that is the last clock in the clock-domain, we
also turn off the clock-domain (I think).
Could it be that the clock-domain doesn't do any handshaking with modules,
and so turns off the clocks even though they are being used?

NeilBrown


signature.asc
Description: PGP signature

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 sure - though I think the former.
> > 
> > Maybe if we could enable the UART clocks immediately after returning from 
> > the
> > WFI instruction we could avoid the corruption
> 
> The PRCM should be re-enabling the UART's functional clock itself, with no 
> kernel involvement.  The sequence should go something like this 
> (simplified):
> 
> 1. I/O wakeup occurs
> 
> 2. CORE & PER powerdomains are awakened
> 
> 3. The UART notices an event on its input lines and deasserts its idle-ack

It just occurred to me that, supposedly, the only UART input line that is 
attached to the SWAKEUP signal is CTS.  So the UART may not in fact be 
able to deassert its idle-ack autonomously at this point.

So you might want to give your clock re-enable after WFI idea a shot!  It 
would be interesting if it helps.

I regret the oversight, 


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 00/25] gpio/omap: driver cleanup and fixes

[Grant Likely]

On Fri, Feb 3, 2012 at 10:51 AM, Kevin Hilman  wrote:
> Grant Likely  writes:
>
>> On Thu, Feb 02, 2012 at 11:00:26PM +0530, Tarun Kanti DebBarma wrote:
>>> The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
>>>   Linus Torvalds (1):
>>>         Linux 3.3-rc2
>>>
>>> are available in the git repository at:
>>> http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev
>>> Branch: for_3.4/gpio_cleanup_fixes_v9
>>
>> Bad git url.  I had to replace 'http:' with 'git:'.
>>
>> I've merged this series into my gpio/next branch.  It should show up in
>> linux-next in a couple of days.
>
> Grant, this series isn't quite ready for merge, and shouldn't be
> considered a pull request.

No problem.  I'll drop it from my tree.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 up via I/O ring/chain wakeup.
> > I/O ring/chain wakeup is driven by a 32KiHz clock and is therefore 
> > relatively high-latency.  So this could easily cause the first character 
> > or first few characters to be lost or corrupted, depending on the exact 
> > sequence of events, the low power state that the chip was in, etc.
> 
> A 32KiHz cycles every 30mSec.
> At 115200 bps, there is one bit every 8.7 microseconds.
> 
> When I type "return" - which looks like 01011... on the wire,
> I see '0xC3' which looks like 0111... on the wire.
> So we lost exactly 2 bits, or a delay around 17 microseconds.
> 
> I find it hard to reconcile that delay with the cause being a 32KiHZ clock.

If you're not disabling the HF clock oscillator via the AUTOEXTCLKMODE 
bits, the wakeup logic may be getting clocked by the sys_clk, which is 
quite a bit faster.  That might explain the corruption patterns you're 
seeing.


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 00/25] gpio/omap: driver cleanup and fixes

[Kevin Hilman]

Hi Tarun,

Tarun Kanti DebBarma  writes:

> The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
>   Linus Torvalds (1):
> Linux 3.3-rc2
>
> are available in the git repository at:
> http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev
> Branch: for_3.4/gpio_cleanup_fixes_v9
>
> This series is continuation of cleanup of OMAP GPIO driver and fixes.
> The cleanup include getting rid of cpu_is_* checks wherever possible,
> use of gpio_bank list instead of static array, use of unique platform
> specific value associated data member to OMAP platforms to avoid
> cpu_is_* checks. The series also include PM runtime support.

This version is looking pretty good, and I'm almost ready to queue it up
for Grant.

However, one more minor nit.  Please fix up the compile warnings when
built without CONFIG_PM_SLEEP or CONFIG_PM_RUNTIME.

The definitons of the dev_pm_ops callbacks need to be conditional when
using the SET_*_PM_OPS() macros, otherwise you get these warnings:

  CC  drivers/gpio/gpio-omap.o
/work/kernel/omap/pm/drivers/gpio/gpio-omap.c:1142:12: warning: 
'omap_gpio_suspend' defined but not used [-Wunused-function]
/work/kernel/omap/pm/drivers/gpio/gpio-omap.c:1167:12: warning: 
'omap_gpio_resume' defined but not used [-Wunused-function]
/work/kernel/omap/pm/drivers/gpio/gpio-omap.c:1191:12: warning: 
'omap_gpio_runtime_suspend' defined but not used [-Wunused-function]
/work/kernel/omap/pm/drivers/gpio/gpio-omap.c:1237:12: warning: 
'omap_gpio_runtime_resume' defined but not used [-Wunused-function]


Thanks,

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reg pinmux driver for OMAP based SoC- AM335X

[Tony Lindgren]

* Tony Lindgren  [120201 09:43]:
> * Hiremath, Vaibhav  [120201 01:34]:
> > On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote:
> > > 
> > > The driver I'm working leaves all the data out of kernel, and the driver
> > > just knows how to handle a pinmux register instances. 
> > 
> > Tony,
> > 
> > Is this hosted or accessible somewhere? Just for reference...
> 
> Still few more things to fix before I can post it..

OK now posted as thread "[PATCH 0/2] Initial DT only generic
pinctrl-simple driver". Did not Cc any omap people as I assume
they're all reading linux-omap.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] pinctrl: Add simple pinmux driver using device tree data

[Tony Lindgren]

Add simple pinmux driver using device tree data.

Currently this driver only works on omap2+ series of
processors, where there is either an 8 or 16-bit mux
register for each pin. Support for other similar pinmux
controllers could be added.

Note that this patch does not yet support pinconf_ops
or GPIO. Further, alternative mux modes are not yet
handled.

Signed-off-by: Tony Lindgren 
---
 .../devicetree/bindings/pinmux/pinctrl-simple.txt  |   62 +
 drivers/pinctrl/Kconfig|6 
 drivers/pinctrl/Makefile   |1 
 drivers/pinctrl/pinctrl-simple.c   | 1286 
 4 files changed, 1355 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinmux/pinctrl-simple.txt
 create mode 100644 drivers/pinctrl/pinctrl-simple.c

diff --git a/Documentation/devicetree/bindings/pinmux/pinctrl-simple.txt 
b/Documentation/devicetree/bindings/pinmux/pinctrl-simple.txt
new file mode 100644
index 000..ca1a48d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinmux/pinctrl-simple.txt
@@ -0,0 +1,62 @@
+Generic simple device tree based pinmux driver
+
+Required properties:
+- compatible :  one of:
+   - "pinctrl-simple"
+   - "ti,omap2420-pinmux"
+   - "ti,omap2430-pinmux"
+   - "ti,omap3-pinmux"
+   - "ti,omap4-pinmux"
+- reg : offset and length of the register set for the mux registers
+- #pinmux-cells : width of the pinmux array, currently only 2 is supported
+- pinctrl-simple,register-width : pinmux register access width
+- pinctrl-simple,function-mask : mask of allowed pinmux function bits
+- pinctrl-simple,function-off : function off mode for disabled state
+- pinctrl-simple,pinconf-mask : mask of allowed pinconf bits
+
+Example:
+
+   /* SoC common file, such as omap4.dtsi */
+   omap4_pmx_core: pinmux@4a100040 {
+   compatible = "ti,omap4-pinmux";
+   reg = <0x4a100040 0x0196>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #pinmux-cells = <2>;
+   pinctrl-simple,register-width = <16>;
+   pinctrl-simple,function-mask = <0x7>;
+   pinctrl-simple,function-off = <0x7>;
+   pinctrl-simple,pinconf-mask = <0xfff8>;
+   };
+
+   omap4_pmx_wkup: pinmux@4a31e040 {
+   compatible = "ti,omap4-pinmux";
+   reg = <0x4a31e040 0x0038>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #pinmux-cells = <2>;
+   pinctrl-simple,register-width = <16>;
+   pinctrl-simple,function-mask = <0x7>;
+   pinctrl-simple,function-off = <0x7>;
+   pinctrl-simple,pinconf-mask = <0xfff8>;
+   };
+
+   uart3: serial@4802 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart3";
+   clock-frequency = <4800>;
+   }
+
+   /* board specific .dts file, such as omap4-sdp.dts */
+   pinmux@4a100040 {
+   pmx_uart3: pinconfig-uart3 {
+   mux = <0x0104 0x100
+  0x0106 0x0>;
+};
+};
+   };
+
+   serial@4802 {
+   pinctrl = <&pmx_uart3>;
+   };
+
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index afaf885..73848b1 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -42,6 +42,12 @@ config PINCTRL_COH901
  COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
  ports of 8 GPIO pins each.
 
+config PINCTRL_SIMPLE
+   tristate "Simple device tree based pinmux driver"
+   depends on OF
+   help
+ This selects the device tree based generic pinmux driver.
+
 endmenu
 
 endif
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 827601c..4b05649 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PINCONF)   += pinconf.o
 obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
 obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
 obj-$(CONFIG_PINCTRL_COH901)   += pinctrl-coh901.o
+obj-$(CONFIG_PINCTRL_SIMPLE)   += pinctrl-simple.o
diff --git a/drivers/pinctrl/pinctrl-simple.c b/drivers/pinctrl/pinctrl-simple.c
new file mode 100644
index 000..370e0c3
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-simple.c
@@ -0,0 +1,1286 @@
+/*
+ * Generic simple device tree based pinmux driver
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "core.h"
+
+#define PMX_MUX_NAME   "mux"
+#define PMX_PINCTRL_NAME   "pinctrl"
+#

[PATCH 1/2] pinmux: Export pinmux_register_mappings for pinmux modules

[Tony Lindgren]

With devidce tree based pinmux drivers we may not have
static pinmux mappings as they can be dynamically created
based on the device tree entries.

Signed-off-by: Tony Lindgren 
---
 drivers/pinctrl/pinmux.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 7c3193f..140d207 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -338,7 +338,7 @@ EXPORT_SYMBOL_GPL(pinmux_gpio_direction_output);
  * passed into this function will be owned by the pinmux core and cannot be
  * freed.
  */
-int __init pinmux_register_mappings(struct pinmux_map const *maps,
+int pinmux_register_mappings(struct pinmux_map const *maps,
unsigned num_maps)
 {
void *tmp_maps;
@@ -402,6 +402,7 @@ int __init pinmux_register_mappings(struct pinmux_map const 
*maps,
pinmux_maps_num += num_maps;
return 0;
 }
+EXPORT_SYMBOL_GPL(pinmux_register_mappings);
 
 /**
  * acquire_pins() - acquire all the pins for a certain function on a pinmux

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] Initial DT only generic pinctrl-simple driver

[Tony Lindgren]

Hi all,

Here's finally something that mostly works for omap2/3/4, this
is now using a minimal subset of the mux bindings posted earlier
by Stephen Warren.

No support for alternative modes at this point, bunch of features
missing.. And the map allocation is copying things unnecessarily
right now. But basically this is what I promised to post few
weeks ago as pinmux-simple.

Hmm, how should we mark the pinmux hogs in .dts?

Regards,

Tony

---

Tony Lindgren (2):
  pinmux: Export pinmux_register_mappings for pinmux modules
  pinctrl: Add simple pinmux driver using device tree data


 .../devicetree/bindings/pinmux/pinctrl-simple.txt  |   62 +
 drivers/pinctrl/Kconfig|6 
 drivers/pinctrl/Makefile   |1 
 drivers/pinctrl/pinctrl-simple.c   | 1286 
 drivers/pinctrl/pinmux.c   |3 
 5 files changed, 1357 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinmux/pinctrl-simple.txt
 create mode 100644 drivers/pinctrl/pinctrl-simple.c

-- 
Signature
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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:
> > >>
> > >> > 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 I 
> > >> > sometimes get
> > >> > corruption on output.
> > >>
> > >> I don't see any output corruption on 35xx BeagleBoard, either with or
> > >> without these patches.  So this is presumably a 37xx-centric problem, and
> > >> unrelated to these patches, I would guess.
> > >
> > > 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 set, I usually get first char dropped (as expected) but
> > sometimes I get corrupted char instead too. Corrupt char seems to
> > almost always happen if I set cpufreq to powersave, on performace it's
> > almost always ok, so maybe it's some timing problem,
> 
> OK so let's distinguish between two corruption situations:
> 
> 1. The first character transmitted to the OMAP UART in a serial console 
> when the UART powerdomain is in a non-functional, low power state (e.g., 
> RET or below) is corrupted.  This is not actually output corruption, this 
> is input corruption.
> 
> 2. Characters are corrupted while the OMAP UART is transmitting data, but 
> there has been no recent data sent to the OMAP.
> 
> 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 up via I/O ring/chain wakeup.
> I/O ring/chain wakeup is driven by a 32KiHz clock and is therefore 
> relatively high-latency.  So this could easily cause the first character 
> or first few characters to be lost or corrupted, depending on the exact 
> sequence of events, the low power state that the chip was in, etc.

A 32KiHz cycles every 30mSec.
At 115200 bps, there is one bit every 8.7 microseconds.

When I type "return" - which looks like 01011... on the wire,
I see '0xC3' which looks like 0111... on the wire.
So we lost exactly 2 bits, or a delay around 17 microseconds.

I find it hard to reconcile that delay with the cause being a 32KiHZ clock.

If the first char I type is a space (0x20 or 00100111) then
the character received is 0x90 (01001) which is exactly 1 bit missing,
so an 8 or 9 usec delay.
If the first char I type is 'o' (0x6f, or 00110111) then the character
received is 0xfb (011011) which misses 5 bits.
I think it misses the first bit, then waits for a start bit (0), then takes
the next 8 bits.

At 230400 bps, I always lose at least 2 bits.
At 460800 bps, I seem lose at least 3 bits.
(above there, nothing works at all ... could be my USB/serial cable at fault).

So it looks a lot like a delay which is a small number of microseconds.
Could be the wake-up latency in the I/O ring/chain, but doesn't look like the
32 KiHz clock :-)

> 
> Case 2 is not expected.  That is likely a bug somewhere.  Neil, this is 
> what I understood that you are experiencing.  Is that correct?

Correct.

Thanks,
NeilBrown

> 
> Gražvydas, are you seeing case 1 or 2 (or something completely different 
> ;-) ?
> 
> 
> - Paul



signature.asc
Description: PGP signature

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 state, that might be worth experimenting with.


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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/omap-serial.c
> > > index f809041..c7ef760 100644
> > > --- a/drivers/tty/serial/omap-serial.c
> > > +++ b/drivers/tty/serial/omap-serial.c
> > > @@ -440,7 +440,8 @@ static unsigned int serial_omap_tx_empty(struct 
> > > uart_port *port)
> > >   spin_lock_irqsave(&up->port.lock, flags);
> > >   ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
> > >   spin_unlock_irqrestore(&up->port.lock, flags);
> > > - pm_runtime_put(&up->pdev->dev);
> > > + pm_runtime_mark_last_busy(&up->pdev->dev);
> > > + pm_runtime_put_autosuspend(&up->pdev->dev);
> > >   return ret;
> > >  }

It's a little surprising that this helps.  The pm_runtime_get*() and 
_put*() in serial_omap_tx_empty() are just intended to ensure that the 
UART's clocks are running for that LSR register read.

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():

if (uart_circ_empty(xmit))
serial_omap_stop_tx(&up->port);



- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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, that's the point of the idle protocol.  If there's 
data left in the TX FIFO, the UART should prevent the rest of the chip 
from cutting its clocks until the TX FIFO is drained.  Even if the MPU has 
requested that the UART clocks be cut.

Of course, there may well be a bug that prevents this from working the 
way it was intended.


- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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 immediately after returning from the
> WFI instruction we could avoid the corruption

The PRCM should be re-enabling the UART's functional clock itself, with no 
kernel involvement.  The sequence should go something like this 
(simplified):

1. I/O wakeup occurs

2. CORE & PER powerdomains are awakened

3. The UART notices an event on its input lines and deasserts its idle-ack

4. The PRCM re-enables the clocks to the UART

5. The UART receives the input character into its FIFO and raises an MPU 
   interrupt

That's the theory, anyway.

- 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 info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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
> >> > sometimes lose the first char I type (that is known) but also I 
> >> > sometimes get
> >> > corruption on output.
> >>
> >> I don't see any output corruption on 35xx BeagleBoard, either with or
> >> without these patches.  So this is presumably a 37xx-centric problem, and
> >> unrelated to these patches, I would guess.
> >
> > 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 set, I usually get first char dropped (as expected) but
> sometimes I get corrupted char instead too. Corrupt char seems to
> almost always happen if I set cpufreq to powersave, on performace it's
> almost always ok, so maybe it's some timing problem,

OK so let's distinguish between two corruption situations:

1. The first character transmitted to the OMAP UART in a serial console 
when the UART powerdomain is in a non-functional, low power state (e.g., 
RET or below) is corrupted.  This is not actually output corruption, this 
is input corruption.

2. Characters are corrupted while the OMAP UART is transmitting data, but 
there has been no recent data sent to the OMAP.

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 up via I/O ring/chain wakeup.
I/O ring/chain wakeup is driven by a 32KiHz clock and is therefore 
relatively high-latency.  So this could easily cause the first character 
or first few characters to be lost or corrupted, depending on the exact 
sequence of events, the low power state that the chip was in, etc.

Case 2 is not expected.  That is likely a bug somewhere.  Neil, this is 
what I understood that you are experiencing.  Is that correct?

Gražvydas, are you seeing case 1 or 2 (or something completely different 
;-) ?


- Paul

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

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/autosuspend_delay_ms = 0.  
> > I think you are simply enabling the autosuspend timer.  There was a 
> > significant behavior change here from 3.2, I believe.
> 
> However the default autosuspend_delay_ms is "-1", not "0", and "-1" does
> disable runbtime_pm completely.  It increments usage_count (see
> update_autosuspend()) so runtime_pm can never suspend the device.

OK good, so you are indeed keeping the clocks enabled, then.

> Hmm... I thought it was the other way around - CLKEN could gate the clock
> off, and PRCM could also turn it off after a handshake.  But I finally found
> the relevant text:
> 
>The software effect is immediate and direct. The functional clock is
>turned on as soon as the bit is set, and turned off if the bit is cleared
>and the clock is not required by any module.
> 
> so it seems I was wrong.

Well, one shouldn't take the TRM too seriously.  But in this case, yes I 
think you had a slightly different idea than what the hardware people
intended ;-)

> Still - something is definitely going wrong because I definitely an regularly
> see garbage characters.  And the patch fixes it.  So some runtime-suspend
> handler must be doing something bad, and it must happen while characters
> are being written.

It's certainly possible that there is another idle bug in the UART where 
it could be mistakenly idle-acking when there are bytes left to be 
transmitted.  But the patch 'tty: serial: OMAP: block idle while the UART 
is transferring data in PIO mode' should fix that.  Are you running with 
those patches applied?  Also, are you using PIO or DMA?

> > > i.e. when the tx buffer is empty, so turn the clocks off immediately, 
> > > but wait a while for the fifo to empty.  Hopefully the auto-suspend time 
> > > is enough.
> > 
> > Hmm, this statement is a little unclear to me.  The clocks won't be turned 
> > off immediately - the request to disable the clocks only happens when the 
> > autosuspend timer expires.  And even then, as mentioned above, it's just a 
> > request.  The hardware should not actually disable the functional clock 
> > until the UART FIFO is drained...
> 
> If you pm_runtime_put_autosuspend(), the suspend won't happen immediately but
> will wait the timeout.
> If you pm_runtime_put_sync(), the suspend happens straight away.
> If you pm_runtime_put(), the suspend is schedule immediately in another
> thread, so it happens very soon.  It doesn't wait for a timer to expire (no
> timer is ticking at this point).
> 
> Just because an autosuspend timeout was set earlier, that won't cause
> pm_runtime_put() to delay in suspending the device when it is called.
> 
> So I think it does request that the clocks be turned off immediately.

I was under the impression you were referring to the behavior after your 
patch was applied, rather than before it.  My misunderstanding.

> > Anyway, consider trying a different CLOCKACTIVITY setting for the UARTs. 
> 
> My TRM saids that SYSC for the UARTs doesn't have CLOCKACTIVITY. Only
>  AUTOIDLE SOFTRESET ENAWAKEUP IDLEMODE
> 
> Is it worth trying anyway?

Sure, why not.  It's fast to try, and if it happens to work, it's better 
than hacking the driver..  

> > Incidentally, I have some patches to fix the latency calculation here that 
> > are in the works, similar to the ones you describe.  The current 
> > calculation in the driver is pretty broken, but since the changes to fix 
> > the calculation are rather involved, Kevin and I thought it would be best 
> > to defer most of them to the v3.4 merge window.  The calculation fix in 
> > the 3.3-rc series is simply intended to deal with a very basic power 
> > management regression, as you know - not to make it ideal, which is more 
> > complicated.  Anyway, the patches are at git://git.pwsan.com/linux-2.6 in 
> > the branch 'omap_serial_fix_pm_qos_formula_devel_3.4'.  Keep in mind that 
> > at least one patch in that branch is broken, but perhaps you might get an 
> > idea of where they are trying to go.  Comments welcome.
> > 
> > > However I am using a lot more power than in 3.2.  
> > 
> > Is this without disabling the UART clocks?  If the driver is keeping the 
> > UART clocks enabled, then increased power consumption is definitely 
> > expected.
> 
> Both. With clocks kept on (autosuspend == -1) I'm using about 30 mA more than
> before.  With clocks allowed to go off it is closer to 40mA more !!! Weird,
> isn't it?

Interesting.  A few questions.  Do you have the PMIC and the OMAP 
configured to scale voltage in retention?  Also, does the power effect 
differ if you use different autosuspend timeouts?

> > > If I then enabled runtime_pm with a 5 second autosuspend delay:
> > >   CORE 

Re: [PATCH 1/2] ARM: OMAP: Get rid of reset for system timer

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

> On Fri, Feb 3, 2012 at 12:10 AM, Kevin Hilman  wrote:
>> Santosh Shilimkar  writes:
>>
>>> From: Rajendra Nayak 
>>>
>>> hwmod setup already does a reset and sets the OCP sysconfig
>>> registers appropriately. Avoid doing a reset again and overriding
>>> the OCP sysconfig settings in the system timer init code.
>>
>> That is true for OMAP4, but have you verified if this is indeed a
>> duplicate reset on  OMAP2/3?
>>
> Yes. It is duplicate for OMAP2 and OMAP3 devices as well.
> Actually this should have been fixed when the driver was
> hwmod converted but some how got missed. We noticed
> an issue on OMAP5, when timer interrupts stopped firing when
> always on clock domain was allowed to idle. This was because
> this reset was clearing the correctly set sysc value by hwmod.
>
> The patch is also tested on ZOOM3 ( OMAP3630)
> and OMAP2430SDP.

Great, thanks for testing on OMAP2/3.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 00/25] gpio/omap: driver cleanup and fixes

[Kevin Hilman]

Grant Likely  writes:

> On Thu, Feb 02, 2012 at 11:00:26PM +0530, Tarun Kanti DebBarma wrote:
>> The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
>>   Linus Torvalds (1):
>> Linux 3.3-rc2
>> 
>> are available in the git repository at:
>> http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev
>> Branch: for_3.4/gpio_cleanup_fixes_v9
>
> Bad git url.  I had to replace 'http:' with 'git:'.
>
> I've merged this series into my gpio/next branch.  It should show up in
> linux-next in a couple of days.

Grant, this series isn't quite ready for merge, and shouldn't be
considered a pull request.

I still need to give it a once over and some final testing.

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count

[Kevin Hilman]

Felipe Balbi  writes:

[...]

>> >This question remains. Why do we need those funtions ?
>> 
>> These functions are called from the CPUIdle path so outside the scope
>> of the GPIO driver. These are part of a bunch of nasty PM hacks we
>> are doing in the CPU idle loop. We are in the process of getting rid
>> of most of them, but it looks like some are still needed.
>
> Too bad. I can see that the gpio pm implementation seems a bit
> "peculiar". I mean, pm does reference counting and yet the driver has
> checks to prevent multiple gets and puts on a single bank (meaning that
> pm counter will be either 0 or 1 at any point in time).
>
> To me it looks like those functions are there in order to forcefully put
> PER power domain in OFF because drivers are always holding a reference
> to their gpios (drivers generally gpio_request() on probe() and
> gpio_free() on remove()).
>
> Looks like the entire pm implementation on OMAP gpio driver has always
> considered only the fact that gpios can be requested and freed, but
> never that we want the system to go to OFF even while gpios are
> requested, because we have I/O PAD wakeups. At some point that has to be
> sorted out because that HACK is quite ugly :-)
>
> I'll see if I find some time to go over the interactions between
> gpio-omap.c and pm24x.c and pm34xx.c any of these days, but I can't
> promise anything ;-)

If you look at the state of these prepare/resume hacks at the end of
this series, you'll see that they are significantly cleaner and do
nothing but call the runtime PM hooks.

We have explored several ways to get rid of them completely in the idle
path but have not yet come up with a clean way, but this series gets us
a long ways towards that goal.

Kevin



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Russell King - ARM Linux]

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_empty() is called to test if the
> tx queue is empty.

Not just the queue.  The documentation for that function is accurate:

  tx_empty(port)
This function tests whether the transmitter fifo and shifter
for the port described by 'port' is empty.  If it is empty,
this function should return TIOCSER_TEMT, otherwise return 0.
If the port does not support this operation, then it should
return TIOCSER_TEMT.

So, if this is returning TIOCSER_TEMT while there's still a transmission
in progress, then it's buggy.

> So when I
> 
>cat somefile
> 
> to the serial console, most of the file comes out fine.  But after 'cat'
> finishes and returns to the shell - while some chars are still in the FIFO - 
> the shell does an 'stty' ioctl to make sure the settings are still OK.
> This ioctl calls serial_omap_tx_empty which calls pm_resume_put() which
> immediately suspends the uart, which seems to stop some clock - even though
> we think it shouldn't.

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?

I guess this is highlighting a problem with doing runtime PM with
serial ports: you don't know when the port has _actually_ finished
sending its final character, which is even more of a problem if the
port does hardware CTS flow control itself.

It seems that runtime PM should be checking whether the TX FIFO is empty
before shutting the port down - and that probably means a hook into the
idle stuff.

Note though, that serial_omap_tx_empty() can be called via ioctl from
userspace, so this function would still need the runtime callbacks in
it so that the register is readable at _any_ time that the port is open.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Felipe Contreras]

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

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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 power but I
> >> > sometimes lose the first char I type (that is known) but also I 
> >> > sometimes get
> >> > corruption on output.
> >>
> >> I don't see any output corruption on 35xx BeagleBoard, either with or
> >> without these patches.  So this is presumably a 37xx-centric problem, and
> >> unrelated to these patches, I would guess.
> >
> > 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 set, I usually get first char dropped (as expected) but
> sometimes I get corrupted char instead too. Corrupt char seems to
> almost always happen if I set cpufreq to powersave, on performace it's
> almost always ok, so maybe it's some timing problem,

I see that too - I'm glad someone else does :-)

If I look at the corruption as compared to the expected character, it is
always the case some it has been shifted down a few bits, with '1's shifted
in the top.
As bytes are sent lsb first followed by stop bits which are '1', this is
completely consistent with clocking the bits in a little bit late.

I see this with baud rates of 115200 and higher, but never with lower.

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 immediately after returning from the
WFI instruction we could avoid the corruption

NeilBrown



signature.asc
Description: PGP signature

RE: [PATCH v9 00/25] gpio/omap: driver cleanup and fixes

[Hebbar, Gururaja]

Hi,

On Fri, Feb 03, 2012 at 15:29:49, DebBarma, Tarun Kanti wrote:
> On Fri, Feb 3, 2012 at 2:51 PM, Hebbar, Gururaja
>  wrote:
> 
> 
>   Tarun,
>   
>   I am interested in testing these patches on AM335x. Do you have
> a tree with these
>   patches applied so that I can pull.
>   
> 
> You can find the series here:-
> git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-oma
> p-dev for_3.4/gpio_cleanup_fixes_v9

I am unable to download from this repo. The Gitorious web page fails to show
the tree and gives 500 error

downloading using https protocol fails with below error.

ghebbar@linux-psp-server:~/projects/linux-gits/gitorious-omap$ git remote add 
omap-gpio2 https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git

ghebbar@linux-psp-server:~/projects/linux-gits/gitorious-omap$ git fetch 
omap-gpio2

error: Unable to get pack index 
https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-a461f67f3067aa122c09f38cf55346152c9fafb8.idx

error: Unable to get pack index 
https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-a66a5d34b6388e1b0c6b49fe4a029cbf755b17c7.idx

error: Unable to get pack index 
https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-952401733bd66c72bc947b54ad5a04ca8edfff2a.idx

error: Unable to get pack index 
https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-1f38918dfb5427f9b79b88d7c6cda15e85c2ad92.idx

error: Unable to get pack file 
https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-2e39094e5e34e6ce642fc2513727a2025b23f8c7.pack
GnuTLS recv error (-9): A TLS packet with unexpected length was received.
error: Unable to find f5af8c1f05d8a1e27ca910285da3fee28eb5acce under 
https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git
Cannot obtain needed object f5af8c1f05d8a1e27ca910285da3fee28eb5acce
while processing commit 7e0e6be8759e6423a4f97b4bbc5e9fec0e5cfde3.
error: Fetch failed.
ghebbar@linux-psp-server:~/projects/linux-gits/gitorious-omap$ git fetch 
omap-gpio2
error: Unable to get pack index 
https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-a461f67f3067aa122c09f38cf55346152c9fafb8.idx

error: wrong index v2 file size in 
.git/objects/pack/pack-952401733bd66c72bc947b54ad5a04ca8edfff2a.idx
error: .git/objects/pack/pack-2e39094e5e34e6ce642fc2513727a2025b23f8c7.pack 
SHA1 checksum mismatch
error: inflate: data stream error (invalid distance too far back)


is there any issue with the repo.

> --
> Tarun
>  
> 
> 
> 
>   On Thu, Feb 02, 2012 at 23:00:26, DebBarma, Tarun Kanti wrote:
>   > The following changes since commit
> 62aa2b537c6f5957afd98e29f96897419ed5ebab:
>   >   Linus Torvalds (1):
>   > Linux 3.3-rc2
>   >
>   > are available in the git repository at:
>   >
> http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-om
> ap-dev
>  -omap-dev> 
>   > Branch: for_3.4/gpio_cleanup_fixes_v9
>   >
>   > This series is continuation of cleanup of OMAP GPIO driver and
> fixes.
>   > The cleanup include getting rid of cpu_is_* checks wherever
> possible,
>   > use of gpio_bank list instead of static array, use of unique
> platform
>   > specific value associated data member to OMAP platforms to
> avoid
>   > cpu_is_* checks. The series also include PM runtime support.
>   >
>   > Power Tests
>   > a) OMAP3430SDP
>   > - Modify board-3430sdp.c file to have multiple GPIO modules
> active
>   >   with debounce timeout enabled.
>   > - Enable CPU-Idle
>   > - Enable UART timeouts
>   > - Enable offmode
>   > - echo mem > /sys/power/state
>   > - Verify retention and offmode count increment
>   >
>   >   Used following patches to avoid exception during system
> suspend:-
>   >   [PATCH RFC 1/2] mtd : Prevent the NULL pointer access
>   >   [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the
> suspend is not implemented
>   >
>   > # echo mem > /sys/power/state
>   > [   47.128021] PM: Syncing filesystems ... done.
>   > [   47.144104] Freezing user space processes ... (elapsed 0.01
> seconds) done.
>   > [   47.168243] Freezing remaining freezable tasks ... (elapsed
> 0.02 seconds) don
> e.
>   > [   47.205139] Unable to handle kernel NULL pointer
> dereference at virtual addre
> ss 00a0
>   > [   47.213317] pgd = deaac000
>   > [   47.216033] [00a0] *pgd=9e932831, *pte=,
> *ppte=
>   > [   47.222381] Internal error: Oops: 17 [#1] SMP
>   > [   47.226745] Modules linked in:
>   > [   47.229827] CPU: 0Not tainted
> (3.3.0-rc2-00031-g12c5c5c #235)
>   > [   47.236022] PC is at mtd_cls_suspend+0x8/0x20
>   > [   47.240386] LR is at mtd_cls_suspend+0x8/0x20
>   > [   47.244750]

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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:
> >> >
> >> > > 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-kernel&m=132754676014389&w=2
> >> > http://marc.info/?l=linux-arm-kernel&m=132754677914395&w=2
> >> > http://marc.info/?l=linux-arm-kernel&m=132754676014388&w=2
> >>
> >> Any comments on these?
> >
> > 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)
> > 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 I sometimes 
> > get
> > corruption on output.
> >
> > The problem seems to be that we turn off the clocks when the kernel's ring
> > buffer is empty rather than waiting for the UART's fifo to be empty.
> > So I get corruption near the end of a stream of output ... not right at the
> > end so something must be turning the clocks back on somehow.
> >
> > I can remove this effect with:
> >
> > diff --git a/drivers/tty/serial/omap-serial.c 
> > b/drivers/tty/serial/omap-serial.c
> > index f809041..c7ef760 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -440,7 +440,8 @@ static unsigned int serial_omap_tx_empty(struct 
> > uart_port *port)
> >        spin_lock_irqsave(&up->port.lock, flags);
> >        ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
> >        spin_unlock_irqrestore(&up->port.lock, flags);
> > -       pm_runtime_put(&up->pdev->dev);
> > +       pm_runtime_mark_last_busy(&up->pdev->dev);
> > +       pm_runtime_put_autosuspend(&up->pdev->dev);
> >        return ret;
> >  }
> >
> 
> But looking into it UART_LSR_TEMT("include/linux/serial_reg.h") => 0x40
> 
> from omap trm:
> 
> TX_SR_E => bit 6
> "Read 0x1: Transmitter hold (TX FIFO) and shift registers are empty."
> 
> So it means all data from tx fifo has shifted out and no pending data in
> tx fifo.
> 
> But we had used UART_LSR_THRE (0x20) here for tx fifo emptiness comparison
> then  from omap trm
> 
> TX_FIFO_E => bit 5
> 
> "Read 0x1: Transmit hold register (TX FIFO) is empty.
> The transmission is not necessarily complete"
> 
> So I think all data has been shifted out from tx fifo for
> serial_omap_tx_empty check.

Useful and interesting - thanks.
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_empty() is called to test if the
tx queue is empty.

It is called in a loop at the end of uart_wait_until_sent.

uart_wait_until_sent it calls from various places, but particularly when
doing an 'stty' ioctl.

The loop isn't a very tight loop though it would be tighter if jiffies were
smaller.  As it is it checks every jiffy and usually loops 3 times when I
see corruption.

So when I

   cat somefile

to the serial console, most of the file comes out fine.  But after 'cat'
finishes and returns to the shell - while some chars are still in the FIFO - 
the shell does an 'stty' ioctl to make sure the settings are still OK.
This ioctl calls serial_omap_tx_empty which calls pm_resume_put() which
immediately suspends the uart, which seems to stop some clock - even though
we think it shouldn't.

(If is use 'dash' instead of 'bash', that shell doesn't fiddle with stty, and
I don't see any corruption).

After a bit more experimentation, I find that if either UART3 or UART4 (which
are numbers 2 and 3 is sysfs!!!) have auto_suspend_delay set to -1, then I
don't see any corruption.
But if both are set to 5000, then I do.

(The settings of UART1 and UART2 seem to be irrelevant - presumably because
they are in CORE, not PER).

So if either uart wants PER_48M_FCLK on, then it stays on.  But if neither
explicitly request it and are only keeping it on by being active ... then
there is room for a hiccup it seems.
Or maybe it isn't the clocks ... maybe the problem is that PER goes into
RET mode, which it does for about 40msec.

If I run
 cat /sys/kernel/debug/pm_debug/time; stty 115200; \
 cat /sys/kernel/debug/pm_debug/time

then I see corruption near the end of the first output of the 'time' file,
and the time that PER is in RET goes up by about 40msec.
This could be because the clock goes off, or maybe it has some other cause
that I'm not awa

[PATCH 1/1] ARM: OMAP3+: dpll: Configure autoidle mode only if its supported

[Vaibhav Bedia]

The current DPLL code enables and disables autoidle features
without checking whether the autoidle register is available.
Fix this by putting a check for the existence of the autoidle
register in the DPLL data.

With such a check in place, for DPLLs which do not support this
feature, simply skipping the autoidle_reg entry in the DPLL data
is sufficient.

Signed-off-by: Vaibhav Bedia 
---
 arch/arm/mach-omap2/dpll3xxx.c |   23 ++-
 1 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 57c4c7c..bf0db5d 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -142,7 +142,8 @@ static int _omap3_noncore_dpll_lock(struct clk *clk)

ai = omap3_dpll_autoidle_read(clk);

-   omap3_dpll_deny_idle(clk);
+   if (ai)
+   omap3_dpll_deny_idle(clk);

_omap3_dpll_write_clken(clk, DPLL_LOCKED);

@@ -186,8 +187,6 @@ static int _omap3_noncore_dpll_bypass(struct clk *clk)

if (ai)
omap3_dpll_allow_idle(clk);
-   else
-   omap3_dpll_deny_idle(clk);

return r;
 }
@@ -216,8 +215,6 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)

if (ai)
omap3_dpll_allow_idle(clk);
-   else
-   omap3_dpll_deny_idle(clk);

return 0;
 }
@@ -520,6 +517,9 @@ u32 omap3_dpll_autoidle_read(struct clk *clk)

dd = clk->dpll_data;

+   if (!dd->autoidle_reg)
+   return -EINVAL;
+
v = __raw_readl(dd->autoidle_reg);
v &= dd->autoidle_mask;
v >>= __ffs(dd->autoidle_mask);
@@ -546,6 +546,12 @@ void omap3_dpll_allow_idle(struct clk *clk)

dd = clk->dpll_data;

+   if (!dd->autoidle_reg) {
+   pr_debug("clock: DPLL %s: autoidle not supported\n",
+   clk->name);
+   return;
+   }
+
/*
 * REVISIT: CORE DPLL can optionally enter low-power bypass
 * by writing 0x5 instead of 0x1.  Add some mechanism to
@@ -555,6 +561,7 @@ void omap3_dpll_allow_idle(struct clk *clk)
v &= ~dd->autoidle_mask;
v |= DPLL_AUTOIDLE_LOW_POWER_STOP << __ffs(dd->autoidle_mask);
__raw_writel(v, dd->autoidle_reg);
+
 }

 /**
@@ -573,6 +580,12 @@ void omap3_dpll_deny_idle(struct clk *clk)

dd = clk->dpll_data;

+   if (!dd->autoidle_reg) {
+   pr_debug("clock: DPLL %s: autoidle not supported\n",
+   clk->name);
+   return;
+   }
+
v = __raw_readl(dd->autoidle_reg);
v &= ~dd->autoidle_mask;
v |= DPLL_AUTOIDLE_DISABLE << __ffs(dd->autoidle_mask);
--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH-V3 3/3] ARM: OMAP: am33xx: Hook-up am33xx support to existing prm code

[Vaibhav Hiremath]

Reuse existing omap4 prminst code for am33xx device,
add separate prm base table for am33xx device and initialize
it during __init for future use.

Also, since cpu_is_omap34xx() check is true for am33xx family of
devices, we must change the order of cpu_is_ check, so first
check for cpu_is_am33xx() to follow right execution path.

Signed-off-by: Vaibhav Hiremath 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
CC: Tony Lindgren 
Cc: Paul Walmsley 
Cc: Benoit Cousson 
---
 arch/arm/mach-omap2/io.c  |1 +
 arch/arm/mach-omap2/omap_hwmod.c  |   44 ++---
 arch/arm/mach-omap2/prcm44xx.h|2 +
 arch/arm/mach-omap2/prminst44xx.c |9 +++
 4 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index aa33cfb..df94693 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -475,6 +475,7 @@ void __init am33xx_init_early(void)
 {
omap2_set_globals_am33xx();
omap_common_init_early();
+   omap44xx_prminst_init();
omap3xxx_clk_init();
 }
 #endif
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e91c4a0..0fb5287 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1289,14 +1289,20 @@ static int _assert_hardreset(struct omap_hwmod *oh, 
const char *name)
if (IS_ERR_VALUE(ret))
return ret;

-   if (cpu_is_omap24xx() || cpu_is_omap34xx())
-   return omap2_prm_assert_hardreset(oh->prcm.omap2.module_offs,
- ohri.rst_shift);
-   else if (cpu_is_omap44xx())
+   /*
+* In order to use omap4 prm code for am33xx family of devices,
+* first check cpu_is_am33xx here.
+*
+* Note: cpu_is_omap34xx is true for am33xx device as well.
+*/
+   if (cpu_is_omap44xx() || cpu_is_am33xx())
return omap4_prminst_assert_hardreset(ohri.rst_shift,
  oh->clkdm->pwrdm.ptr->prcm_partition,
  oh->clkdm->pwrdm.ptr->prcm_offs,
  oh->prcm.omap4.rstctrl_offs);
+   else if (cpu_is_omap24xx() || cpu_is_omap34xx())
+   return omap2_prm_assert_hardreset(oh->prcm.omap2.module_offs,
+ ohri.rst_shift);
else
return -EINVAL;
 }
@@ -1323,11 +1329,13 @@ static int _deassert_hardreset(struct omap_hwmod *oh, 
const char *name)
if (IS_ERR_VALUE(ret))
return ret;

-   if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
-   ret = omap2_prm_deassert_hardreset(oh->prcm.omap2.module_offs,
-  ohri.rst_shift,
-  ohri.st_shift);
-   } else if (cpu_is_omap44xx()) {
+   /*
+* In order to use omap4 prm code for am33xx family of devices,
+* first check cpu_is_am33xx here.
+*
+* Note: cpu_is_omap34xx is true for am33xx device as well.
+*/
+   if (cpu_is_omap44xx() || cpu_is_am33xx()) {
if (ohri.st_shift)
pr_err("omap_hwmod: %s: %s: hwmod data error: OMAP4 
does not support st_shift\n",
   oh->name, name);
@@ -1335,6 +1343,10 @@ static int _deassert_hardreset(struct omap_hwmod *oh, 
const char *name)
  oh->clkdm->pwrdm.ptr->prcm_partition,
  oh->clkdm->pwrdm.ptr->prcm_offs,
  oh->prcm.omap4.rstctrl_offs);
+   } else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+   ret = omap2_prm_deassert_hardreset(oh->prcm.omap2.module_offs,
+  ohri.rst_shift,
+  ohri.st_shift);
} else {
return -EINVAL;
}
@@ -1365,14 +1377,20 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
char *name)
if (IS_ERR_VALUE(ret))
return ret;

-   if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
-   return 
omap2_prm_is_hardreset_asserted(oh->prcm.omap2.module_offs,
-  ohri.st_shift);
-   } else if (cpu_is_omap44xx()) {
+   /*
+* In order to use omap4 prm code for am33xx family of devices,
+* first check cpu_is_am33xx here.
+*
+* Note: cpu_is_omap34xx is true for am33xx device as well.
+*/
+   if (cpu_is_omap44xx() || cpu_is_am33xx()) {
return omap4_prminst_is_hardreset_asserted(ohri.rst_shift,
  oh->clkdm->pwrdm.ptr->prcm_partition,
  oh->clkdm->pwrdm.ptr->prcm_offs,
  oh->prcm.omap4.rstctrl_offs);
+   } else if (cpu_is_om

[PATCH-V3 1/3] ARM: OMAP4: Remove hardcoded reg-offs for PWRSTCTRL & PWRSTST

[Vaibhav Hiremath]

This patch removes the existing hard-coded way of providing
offset to omap4_prminst_xxx API's and instead use offsets
provided in powerdomains_data.

Very much required for the new device AM33XX, where,

PRM module in AM33XX is closer to OMAP4 PRM module, so it makes
complete sense to reuse all the code from existing OMAP4 implementation.
Having said that, there is a catch here with respect to AM33XX device,

The register offset in PRM module is not consistent
across (crazy IP integration), for example,

PRM_XXX PWRSTCTRL PWRSTST RSTCTRL RSTST
===
PRM_PER_MOD:0x0C, 0x08,   0x00,   0x04
PRM_WKUP_MOD:   0x04, 0x08,   0x00,   0x0C
PRM_MPU_MOD:0x00, 0x04,   0x08,   NA
PRM_DEVICE_MOD: NA,   NA, 0x00,   0x08

So in order to reuse the existing OMAP4 code, we have to add
seperate entry for register offsets, especially
PWRSTCTRL & PWRSTST.

Signed-off-by: Vaibhav Hiremath 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
Cc: Benoit Cousson 

Merge to "Remove-hardcoded-reg-offs-for-PWRSTCT"
---
 arch/arm/mach-omap2/powerdomain.h   |4 
 arch/arm/mach-omap2/powerdomain44xx.c   |   24 
 arch/arm/mach-omap2/powerdomains44xx_data.c |9 +
 3 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.h 
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..9ebb872 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -92,6 +92,8 @@ struct powerdomain;
  * @pwrdm_clkdms: Clockdomains in this powerdomain
  * @node: list_head linking all powerdomains
  * @voltdm_node: list_head linking all powerdomains in a voltagedomain
+ * @pwrstctrl_offs: XXX_PWRSTCTRL reg offset from prcm_offs
+ * @pwrstst_offs: XXX_PWRSTST reg offset from prcm_offs
  * @state:
  * @state_counter:
  * @timer:
@@ -121,6 +123,8 @@ struct powerdomain {
unsigned ret_logic_off_counter;
unsigned ret_mem_off_counter[PWRDM_MAX_MEM_BANKS];

+   u8 pwrstctrl_offs;
+   u8 pwrstst_offs;
 #ifdef CONFIG_PM_DEBUG
s64 timer;
s64 state_timer[PWRDM_MAX_PWRSTS];
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c 
b/arch/arm/mach-omap2/powerdomain44xx.c
index a7880af..b088540 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -28,7 +28,7 @@ static int omap4_pwrdm_set_next_pwrst(struct powerdomain 
*pwrdm, u8 pwrst)
omap4_prminst_rmw_inst_reg_bits(OMAP_POWERSTATE_MASK,
(pwrst << OMAP_POWERSTATE_SHIFT),
pwrdm->prcm_partition,
-   pwrdm->prcm_offs, OMAP4_PM_PWSTCTRL);
+   pwrdm->prcm_offs, 
pwrdm->pwrstctrl_offs);
return 0;
 }

@@ -37,7 +37,7 @@ static int omap4_pwrdm_read_next_pwrst(struct powerdomain 
*pwrdm)
u32 v;

v = omap4_prminst_read_inst_reg(pwrdm->prcm_partition, pwrdm->prcm_offs,
-   OMAP4_PM_PWSTCTRL);
+   pwrdm->pwrstctrl_offs);
v &= OMAP_POWERSTATE_MASK;
v >>= OMAP_POWERSTATE_SHIFT;

@@ -49,7 +49,7 @@ static int omap4_pwrdm_read_pwrst(struct powerdomain *pwrdm)
u32 v;

v = omap4_prminst_read_inst_reg(pwrdm->prcm_partition, pwrdm->prcm_offs,
-   OMAP4_PM_PWSTST);
+   pwrdm->pwrstst_offs);
v &= OMAP_POWERSTATEST_MASK;
v >>= OMAP_POWERSTATEST_SHIFT;

@@ -61,7 +61,7 @@ static int omap4_pwrdm_read_prev_pwrst(struct powerdomain 
*pwrdm)
u32 v;

v = omap4_prminst_read_inst_reg(pwrdm->prcm_partition, pwrdm->prcm_offs,
-   OMAP4_PM_PWSTST);
+   pwrdm->pwrstst_offs);
v &= OMAP4430_LASTPOWERSTATEENTERED_MASK;
v >>= OMAP4430_LASTPOWERSTATEENTERED_SHIFT;

@@ -73,7 +73,7 @@ static int omap4_pwrdm_set_lowpwrstchange(struct powerdomain 
*pwrdm)
omap4_prminst_rmw_inst_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK,
(1 << 
OMAP4430_LOWPOWERSTATECHANGE_SHIFT),
pwrdm->prcm_partition,
-   pwrdm->prcm_offs, OMAP4_PM_PWSTCTRL);
+   pwrdm->prcm_offs, 
pwrdm->pwrstctrl_offs);
return 0;
 }

@@ -82,7 +82,7 @@ static int omap4_pwrdm_clear_all_prev_pwrst(struct 
powerdomain *pwrdm)
omap4_prminst_rmw_inst_reg_bits(OMAP4430_LASTPOWERSTATEENTERED_MASK,
OMAP4430_LASTPOWERSTATEENTERED_MASK,
pwrdm->prcm_partition,
-   pwrdm->prcm_offs, OMAP4_PM_PWSTST);
+   pwrdm->prcm_offs, pwrdm->pwrstst_offs

[PATCH-V3 0/3] ARM: OMAP4: Remove hardcoded reg-offs for PWRSTCTRL & PWRSTST

[Vaibhav Hiremath]

This patch series removes the existing hard-coded way of providing
offset to omap4_prminst_xxx API's and instead use offsets
provided in powerdomains_data.
Also, hook up AM33XX device support to existing omap4 PRM code.

Background:
==
PRM module in AM33XX is closer to OMAP4 PRM module, so it complete
sense to reuse all the code from existing OMAP4 implementation.
Having said that, there is a catch here with respect to AM33XX device,

The register offset in PRM module is not consistent
across (crazy IP integration), for example,

PRM_XXX PWRSTCTRL PWRSTST RSTCTRL RSTST
===
PRM_PER_MOD:0x0C, 0x08,   0x00,   0x04
PRM_WKUP_MOD:   0x04, 0x08,   0x00,   0x0C
PRM_MPU_MOD:0x00, 0x04,   0x08,   NA
PRM_DEVICE_MOD: NA,   NA, 0x00,   0x08

So in order to reuse the existing OMAP4 code, we have to add
seperate entry for register offsets, especially
PWRSTCTRL & PWRSTST.

NOTE: Boot tested on AM335x EVM and AM37xEVM

Changes from V2:
- As per Kevin's comment, created separate prm_base table
  for am33xx and added __init function for prminst to
  initialize prm_base table during boot time.
- Minor comment from Kevin, to add extra line in patch 1/3
Changes from V1:
- As per Kevin's comment, patch is split into logical
  commits for ease of review.
- Added specific comment for cpu_is_xxx check order
  change.


Vaibhav Hiremath (3):
  ARM: OMAP4: Remove hardcoded reg-offs for PWRSTCTRL & PWRSTST
  ARM: OMAP4: prminst: Add boot time __init function for prminst
  ARM: OMAP: am33xx: Hook-up am33xx support to existing prm code

 arch/arm/mach-omap2/io.c|3 ++
 arch/arm/mach-omap2/omap_hwmod.c|   44 +++
 arch/arm/mach-omap2/powerdomain.h   |4 ++
 arch/arm/mach-omap2/powerdomain44xx.c   |   24 +++---
 arch/arm/mach-omap2/powerdomains44xx_data.c |9 +
 arch/arm/mach-omap2/prcm44xx.h  |2 +
 arch/arm/mach-omap2/prminst44xx.c   |   35 -
 arch/arm/mach-omap2/prminst44xx.h   |2 +-
 8 files changed, 89 insertions(+), 34 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH-V3 2/3] ARM: OMAP4: prminst: Add boot time __init function for prminst

[Vaibhav Hiremath]

AM33xx PRM module is closer to OMAP4 PRM module, and
in order to reuse prminst api's we have to address
some of the differences like, base addresses and partitions.
Unlike OMAP4 PRM, AM33xx doesn't have any partitions and
maintains single partition.

So, in order to reuse the existing OMAP4 prminst code
for AM33xx this patch adds,

  - Boot time __init function, to initialize _prm_bases
based on cpu_is_xxx
  - Instead of maintaining phy addr for PRM partition
in _prm_bases[] table and then changing it to virt addr,
directly maintain respective virt addr.

Signed-off-by: Vaibhav Hiremath 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
CC: Tony Lindgren 
Cc: Paul Walmsley 
Cc: Benoit Cousson 
---
 arch/arm/mach-omap2/io.c  |2 ++
 arch/arm/mach-omap2/prminst44xx.c |   26 ++
 arch/arm/mach-omap2/prminst44xx.h |2 +-
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2daaec1..aa33cfb 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -39,6 +39,7 @@
 #include 
 #include "voltage.h"
 #include "powerdomain.h"
+#include "prminst44xx.h"

 #include "clockdomain.h"
 #include 
@@ -486,6 +487,7 @@ void __init omap4430_init_early(void)
omap4xxx_check_features();
omap_common_init_early();
omap44xx_voltagedomains_init();
+   omap44xx_prminst_init();
omap44xx_powerdomains_init();
omap44xx_clockdomains_init();
omap44xx_hwmod_init();
diff --git a/arch/arm/mach-omap2/prminst44xx.c 
b/arch/arm/mach-omap2/prminst44xx.c
index f6de5bc..68e13bd 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -24,32 +24,34 @@
 #include "prcm44xx.h"
 #include "prcm_mpu44xx.h"

-static u32 _prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
+static u32 **_prm_bases;
+static u32 max_prm_partitions;
+
+static u32 *omap44xx_prm_bases[] = {
[OMAP4430_INVALID_PRCM_PARTITION]   = 0,
-   [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE,
+   [OMAP4430_PRM_PARTITION]= 
OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
[OMAP4430_CM1_PARTITION]= 0,
[OMAP4430_CM2_PARTITION]= 0,
[OMAP4430_SCRM_PARTITION]   = 0,
-   [OMAP4430_PRCM_MPU_PARTITION]   = OMAP4430_PRCM_MPU_BASE,
+   [OMAP4430_PRCM_MPU_PARTITION]   = 
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
 };

 /* Read a register in a PRM instance */
 u32 omap4_prminst_read_inst_reg(u8 part, s16 inst, u16 idx)
 {
-   BUG_ON(part >= OMAP4_MAX_PRCM_PARTITIONS ||
+   BUG_ON(part >= max_prm_partitions ||
   part == OMAP4430_INVALID_PRCM_PARTITION ||
   !_prm_bases[part]);
-   return __raw_readl(OMAP2_L4_IO_ADDRESS(_prm_bases[part] + inst +
-  idx));
+   return __raw_readl(_prm_bases[part] + ((inst + idx)/sizeof(u32)));
 }

 /* Write into a register in a PRM instance */
 void omap4_prminst_write_inst_reg(u32 val, u8 part, s16 inst, u16 idx)
 {
-   BUG_ON(part >= OMAP4_MAX_PRCM_PARTITIONS ||
+   BUG_ON(part >= max_prm_partitions ||
   part == OMAP4430_INVALID_PRCM_PARTITION ||
   !_prm_bases[part]);
-   __raw_writel(val, OMAP2_L4_IO_ADDRESS(_prm_bases[part] + inst + idx));
+   __raw_writel(val, _prm_bases[part] + ((inst + idx)/sizeof(u32)));
 }

 /* Read-modify-write a register in PRM. Caller must lock */
@@ -174,3 +176,11 @@ void omap4_prminst_global_warm_sw_reset(void)
OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_RSTCTRL_OFFSET);
 }
+
+void __init omap44xx_prminst_init(void)
+{
+   if (cpu_is_omap44xx()) {
+   _prm_bases = omap44xx_prm_bases;
+   max_prm_partitions = ARRAY_SIZE(omap44xx_prm_bases);
+   }
+}
diff --git a/arch/arm/mach-omap2/prminst44xx.h 
b/arch/arm/mach-omap2/prminst44xx.h
index 46f2efb..9a44c68 100644
--- a/arch/arm/mach-omap2/prminst44xx.h
+++ b/arch/arm/mach-omap2/prminst44xx.h
@@ -29,5 +29,5 @@ extern int omap4_prminst_assert_hardreset(u8 shift, u8 part, 
s16 inst,
  u16 rstctrl_offs);
 extern int omap4_prminst_deassert_hardreset(u8 shift, u8 part, s16 inst,
u16 rstctrl_offs);
-
+extern void __init omap44xx_prminst_init(void);
 #endif
--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Grazvydas Ignotas]

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 I sometimes 
>> > get
>> > corruption on output.
>>
>> I don't see any output corruption on 35xx BeagleBoard, either with or
>> without these patches.  So this is presumably a 37xx-centric problem, and
>> unrelated to these patches, I would guess.
>
> 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 set, I usually get first char dropped (as expected) but
sometimes I get corrupted char instead too. Corrupt char seems to
almost always happen if I set cpufreq to powersave, on performace it's
almost always ok, so maybe it's some timing problem,



-- 
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[NeilBrown]

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.
> > 
> > If I enable runtime pm by setting power/autosuspend_delay_ms (e.g. to 5000)
> 
> Runtime PM should be enabled even with power/autosuspend_delay_ms = 0.  
> I think you are simply enabling the autosuspend timer.  There was a 
> significant behavior change here from 3.2, I believe.

However the default autosuspend_delay_ms is "-1", not "0", and "-1" does
disable runbtime_pm completely.  It increments usage_count (see
update_autosuspend()) so runtime_pm can never suspend the device.

> 
> > 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 I sometimes 
> > get
> > corruption on output.
> 
> I don't see any output corruption on 35xx BeagleBoard, either with or 
> without these patches.  So this is presumably a 37xx-centric problem, and 
> unrelated to these patches, I would guess.

Maybe it is 37xx specific.  I think this is a DM3730.


> 
> > The problem seems to be that we turn off the clocks when the kernel's ring
> > buffer is empty rather than waiting for the UART's fifo to be empty.
> 
> pm_runtime_put*() calls will write to the CM_*CLKEN registers if the 
> usecount goes to zero.  But the PRCM should not actually turn off the 
> clocks if the UART isn't idle.  So I would suggest that you first try some 
> hwmod CLOCKACTIVITY changes to fix this (described briefly below).

Hmm... I thought it was the other way around - CLKEN could gate the clock
off, and PRCM could also turn it off after a handshake.  But I finally found
the relevant text:

   The software effect is immediate and direct. The functional clock is
   turned on as soon as the bit is set, and turned off if the bit is cleared
   and the clock is not required by any module.

so it seems I was wrong.

Still - something is definitely going wrong because I definitely an regularly
see garbage characters.  And the patch fixes it.  So some runtime-suspend
handler must be doing something bad, and it must happen while characters
are being written.


> 
> > I can remove this effect with:
> > 
> > diff --git a/drivers/tty/serial/omap-serial.c 
> > b/drivers/tty/serial/omap-serial.c
> > index f809041..c7ef760 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -440,7 +440,8 @@ static unsigned int serial_omap_tx_empty(struct 
> > uart_port *port)
> > spin_lock_irqsave(&up->port.lock, flags);
> > ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
> > spin_unlock_irqrestore(&up->port.lock, flags);
> > -   pm_runtime_put(&up->pdev->dev);
> > +   pm_runtime_mark_last_busy(&up->pdev->dev);
> > +   pm_runtime_put_autosuspend(&up->pdev->dev);
> > return ret;
> >  }
> 
> Well this change probably makes sense anyway, just to keep the autosuspend 
> behavior consistent when an autosuspend timeout is set.  But the effect of 
> this patch may be a little different than what you think; see below.
> 
> > i.e. when the tx buffer is empty, so turn the clocks off immediately, 
> > but wait a while for the fifo to empty.  Hopefully the auto-suspend time 
> > is enough.
> 
> Hmm, this statement is a little unclear to me.  The clocks won't be turned 
> off immediately - the request to disable the clocks only happens when the 
> autosuspend timer expires.  And even then, as mentioned above, it's just a 
> request.  The hardware should not actually disable the functional clock 
> until the UART FIFO is drained...

If you pm_runtime_put_autosuspend(), the suspend won't happen immediately but
will wait the timeout.
If you pm_runtime_put_sync(), the suspend happens straight away.
If you pm_runtime_put(), the suspend is schedule immediately in another
thread, so it happens very soon.  It doesn't wait for a timer to expire (no
timer is ticking at this point).

Just because an autosuspend timeout was set earlier, that won't cause
pm_runtime_put() to delay in suspending the device when it is called.

So I think it does request that the clocks be turned off immediately.


> 
> Anyway, consider trying a different CLOCKACTIVITY setting for the UARTs. 

My TRM saids that SYSC for the UARTs doesn't have CLOCKACTIVITY. Only
 AUTOIDLE SOFTRESET ENAWAKEUP IDLEMODE

Is it worth trying anyway?
 
> There are fields and flags for this in the hwmod code; see for example the 
> I2C SYSCONFIG settings in mach-omap2/omap_hwmod_3xxx_data.c.  It's 
> possible that the UART is currently assuming that its functional clock 
> will stay on when it idle-acks.  That might cause the corruption that you 
> are seeing.
> 
> > But I decided not to pursue this further as turning off the clocks seems 
> > like the wrong thing to be doing.
> 
> The clock

RE: [PATCH v9 00/25] gpio/omap: driver cleanup and fixes

[Hebbar, Gururaja]

Tarun,

I am interested in testing these patches on AM335x. Do you have a tree with 
these 
patches applied so that I can pull. 

On Thu, Feb 02, 2012 at 23:00:26, DebBarma, Tarun Kanti wrote:
> The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
>   Linus Torvalds (1):
> Linux 3.3-rc2
> 
> are available in the git repository at:
> http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev
> Branch: for_3.4/gpio_cleanup_fixes_v9
> 
> This series is continuation of cleanup of OMAP GPIO driver and fixes.
> The cleanup include getting rid of cpu_is_* checks wherever possible,
> use of gpio_bank list instead of static array, use of unique platform
> specific value associated data member to OMAP platforms to avoid
> cpu_is_* checks. The series also include PM runtime support.
> 
> Power Tests
> a) OMAP3430SDP
> - Modify board-3430sdp.c file to have multiple GPIO modules active
>   with debounce timeout enabled.
> - Enable CPU-Idle
> - Enable UART timeouts
> - Enable offmode
> - echo mem > /sys/power/state
> - Verify retention and offmode count increment
> 
>   Used following patches to avoid exception during system suspend:-
>   [PATCH RFC 1/2] mtd : Prevent the NULL pointer access
>   [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not 
> implemented
> 
> # echo mem > /sys/power/state
> [   47.128021] PM: Syncing filesystems ... done.
> [   47.144104] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [   47.168243] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) 
> don   
>   e.
> [   47.205139] Unable to handle kernel NULL pointer dereference at virtual 
> addre 
> ss 00a0
> [   47.213317] pgd = deaac000
> [   47.216033] [00a0] *pgd=9e932831, *pte=, *ppte=
> [   47.222381] Internal error: Oops: 17 [#1] SMP
> [   47.226745] Modules linked in:
> [   47.229827] CPU: 0Not tainted  (3.3.0-rc2-00031-g12c5c5c #235)
> [   47.236022] PC is at mtd_cls_suspend+0x8/0x20
> [   47.240386] LR is at mtd_cls_suspend+0x8/0x20
> [   47.244750] pc : []lr : []psr: a013
> [   47.244750] sp : dea1fe60  ip :   fp : c0ee7d40
> [   47.256256] r10: c0ee7cf0  r9 :   r8 : c02e78f0
> [   47.261474] r7 :   r6 :   r5 : 0002  r4 : dea45800
> [   47.268005] r3 : deb4cac0  r2 :   r1 : 0002  r0 : 
> [   47.274536] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> user
> [   47.281677] Control: 10c5387d  Table: 9eaac019  DAC: 0015
> [   47.287445] Process sh (pid: 1177, stack limit = 0xdea1e2f8)
> [   47.293090] Stack: (0xdea1fe60 to 0xdea2)
> [...]
> 
> b) ZOOM3
> - Enable CPU-Idle
> - Enable UART timeout
> - echo mem > /sys/power/state
> - Wakeup system using serial keyboard
> - Verify retention count increment
> 
> Functional Tests
> - Done on OMAP2430, OMAP3430SDP, ZOOM3, OMAP4430
> 
> Bootup Test
> - Done on OMAP1710
>   Used following patch to fix OMAP1 build error:-
>   [PATCH] i2c: OMAP: Fix OMAP1 build error
> 

[..]
[..]

> Charulatha V (8):
>   gpio/omap: remove dependency on gpio_bank_count
>   gpio/omap: use flag to identify wakeup domain
>   gpio/omap: make gpio_context part of gpio_bank structure
>   gpio/omap: make non-wakeup GPIO part of pdata
>   gpio/omap: avoid cpu checks during module ena/disable
>   gpio/omap: use pinctrl offset instead of macro
>   gpio/omap: remove bank->method & METHOD_* macros
>   gpio/omap: fix bankwidth for OMAP7xx MPUIO
> 
> Nishanth Menon (4):
>   gpio/omap: save and restore debounce registers
>   gpio/omap: enable irq at the end of all configuration in restore
>   gpio/omap: restore OE only after setting the output level
>   gpio/omap: handle set_dataout reg capable IP on restore
> 
> Tarun Kanti DebBarma (13):
>   gpio/omap: handle save/restore context in GPIO driver
>   gpio/omap: further cleanup using wkup_en register
>   gpio/omap: use level/edge detect reg offsets
>   gpio/omap: remove hardcoded offsets in context save/restore
>   gpio/omap: cleanup set_gpio_triggering function
>   gpio/omap: cleanup omap_gpio_mod_init function
>   gpio/omap: remove unnecessary bit-masking for read access
>   gpio/omap: use pm-runtime framework
>   gpio/omap: optimize suspend and resume functions
>   gpio/omap: cleanup prepare_for_idle and resume_after_idle
>   gpio/omap: fix debounce clock handling
>   gpio/omap: fix incorrect access of debounce module
>   gpio/omap: remove omap_gpio_save_context overhead
> 
>  arch/arm/mach-omap1/gpio15xx.c |7 +-
>  arch/arm/mach-omap1/gpio16xx.c |   47 ++-
>  arch/arm/mach-omap1/gpio7xx.c  |   14 +-
>  arch/arm/mach-omap2/gpio.c |   36 +-
>  arch/arm/mach-omap2/pm34xx.c   |   14 -
>  arch/arm/plat-omap/include/plat/gpio.h | 

Re: [RFC/PATCH] arm: omap3: pm: do not clear power states twice

[Felipe Balbi]

On Fri, Feb 03, 2012 at 01:34:55PM +0530, Shilimkar, Santosh wrote:
> On Fri, Feb 3, 2012 at 12:58 PM, Felipe Balbi  wrote:
> > The way the code is written, pwrdm_pre_transion()
> > calls _pwrdm_pre_transition_cb() (for each powerdomain)
> > which, in turn, calls pwrdm_clear_all_prev_pwrst().
> >
> > It looks unnecessary to clear all previous power
> > states twice, so drop the initial set.
> >
> > Signed-off-by: Felipe Balbi 
> > ---
> >
> > Hasn't been tested yet. Compile tested only. It looks
> > like we can safely remove those calls, but I would
> > like to hear from the PM folks first :-)
> >
> Bit late :)
> 
> Paul already cleaned this up.
> http://www.spinics.net/lists/linux-omap/msg63602.html

that's too bad. Missed an oportunity to have a commit on pm code, heh.
Anyway, thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC/PATCH] arm: omap3: pm: do not clear power states twice

[Shilimkar, Santosh]

On Fri, Feb 3, 2012 at 12:58 PM, Felipe Balbi  wrote:
> The way the code is written, pwrdm_pre_transion()
> calls _pwrdm_pre_transition_cb() (for each powerdomain)
> which, in turn, calls pwrdm_clear_all_prev_pwrst().
>
> It looks unnecessary to clear all previous power
> states twice, so drop the initial set.
>
> Signed-off-by: Felipe Balbi 
> ---
>
> Hasn't been tested yet. Compile tested only. It looks
> like we can safely remove those calls, but I would
> like to hear from the PM folks first :-)
>
Bit late :)

Paul already cleaned this up.
http://www.spinics.net/lists/linux-omap/msg63602.html

Regards
santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html