Re: Delay in performing "suspend-to-ram" issued via RT thread (SCHED_FIFO)

[Arun KS]

CCing linux-pm list.

On Wed, May 26, 2010 at 9:07 PM, uthappa  wrote:
>
> Hello Everyone,
>
>        I am currently working with the linux 2.6.29-omap1 kernel. Right now I
> am porting a legacy application code that puts the OMAP 5912 host to
> sleep. The host wakes up after 4 secs via an RTC interrupt which is
> configured to be the wake-up source. Everything seems to be fine running
> in a loop. The system wakes up and goes back to sleep in 4 seconds every
> time. But I am observing a behavior that I am unable to explain. The
> legacy application thread that puts the system to sleep is originally an
> RT thread with the scheduling policy (SCHED_FIFO) and priority 5. The
> thread runs in a loop. The following bash script mimics the behavior of
> this thread exactly (however you will probably need some wake up source
> like an RTC interrupt to try it on your side):
>
> ## Script start #
>
> #!/bin/bash
>
> NAME_OF_THE_SCRIPT=`basename $0`
>
> SELF_PID=`pidof $NAME_OF_THE_SCRIPT`
> /usr/bin/chrt -f -p 5 $SELF_PID
>
> sleep 1
>
> while (true)
> do
>        echo mem > /sys/power/state
>        usleep 3
> done
>
> ## Script end ###
>
>        With this thread running, I see the following messages looping
> repeatedly on the target console screen:
>
> ## Console o/p start #
>
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.92 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: OMAP16212316 is trying to enter deep sleep...
> PM: OMAP16212316 is re-starting from deep sleep...
> Restarting tasks ... RTC IRQ cleared
> done.
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.90 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: OMAP16212316 is trying to enter deep sleep...
> PM: OMAP16212316 is re-starting from deep sleep...
> Restarting tasks ... RTC IRQ cleared
> done.
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.92 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: OMAP16212316 is trying to enter deep sleep...
> PM: OMAP16212316 is re-starting from deep sleep...
> Restarting tasks ... RTC IRQ cleared
> done.
>
> ## Console o/p end ###
>
>        You can observe from the above messages that the elapsed time in
> "Freezing" the user processes is in the order of around 0.9 seconds.
> Also, (although not evident here) when the message "Restarting
> tasks ..." appears it takes around a second for the "done." message to
> follow.
>
>        Now comes the fun part. When I do not fiddle around with the scheduling
> policy and priority of the legacy RT thread and just let it be a normal
> user space thread (SCHED_OTHER with priority 20, nice 0) (You can
> achieve this in the script that I shared with you all by simply
> commenting out the command that says "/usr/bin/chrt -f -p 5 $SELF_PID").
> Then there is almost no delay at all during "Freezing" and
> "Restarting" (I should probably call this "Thawing") the user space
> tasks. That is, I now have the following console o/p:
>
> ## Console o/p start #
>
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: OMAP16212316 is trying to enter deep sleep...
> PM: OMAP16212316 is re-starting from deep sleep...
> Restarting tasks ... RTC IRQ cleared
> done.
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: OMAP16212316 is trying to enter deep sleep...
> PM: OMAP16212316 is re-starting from deep sleep...
> Restarting tasks ... RTC IRQ cleared
> done.
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: OMAP16212316 is trying to enter deep sleep...
> PM: OMAP16212316 is re-starting from deep sleep...
> Restarting tasks ... RTC IRQ cleared
> done.
>
> ## Console o/p end ###
>
>        As you can see from the above log that the time elapsed during freeze
> is now reported as 0.00 seconds. And I observed here that there is no
> time delay between printing "Restarting tasks ..." and "done.".
>
>        I am having a tough time searching for an explanation to this behavior.
> And I hoping 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 23:09:43 +0100
Alan Cox  wrote:

> We now have suggestions how to do the job properly so the right thing is
> probably to go and explore those suggestions not merge crap.
> 
> Merging crap won't help anyway. The rest of the kernel community can
> still simply stonewall those interfaces, and a volunteer community has
> ways of dealing with abuse of process, notably by simply not getting
> around to, or implementing things directly contrary to the crap bits.
> 
> So it's not even in the interest of people to play political games. Even
> if you get away with in the short term the people who rely on the junk
> will end up out on a limb and holding the baby when the crap hits the fan
> (see reiserfs)
> 
> Alan

I'm not interested in "abusing processes". I just think, this is in
limbo for too long already.
Just decide something. One way or the other. The world will continue.

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 22:03:37 +0200
Vitaly Wool  wrote:

> On Wed, May 26, 2010 at 9:56 PM, Florian Mickler  wrote:
> 
> > Your approach definitely sounds better than the current solution.
> > What about mapping suspend blocker functionality later on, when this
> > interface exists, on to this new approach and deprecating it?
> 
> What about coming back after some while with the appropriate solution
> when it's ready instead of stubbornly pushing crap?
> 
> ~Vitaly

Because quite frankly, for a good part of linux users, suspend blockers
is already in the kernel. It's just an historical mistake that they are
not in the linux kernel's hosted on kernel.org. 
So why don't we do what we always do? Improve existing interfaces step
by step? 

Top Down approaches fail from time to time. Also it is not clear, that
that proposed interface works for the use cases. This has to be proven
by providing an implementation. 

Cheers,
Flo
--
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] ARM:VFPv3:enable {d16-d31} access

[DebBarma, Tarun Kanti]

Russell,

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Thursday, May 27, 2010 1:40 AM
> To: DebBarma, Tarun Kanti
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] ARM:VFPv3:enable {d16-d31} access
> 
> On Wed, May 26, 2010 at 05:13:24PM +0530, DebBarma, Tarun Kanti wrote:
> > 1) With the existing implementation I am not able to correctly
> > write/read {d0-d15} but not the {d16-d31} set
> >
> > 2) With my changes I am able to write/read correctly.
> 
> The reason this happens is simple.  In vfp_get_double(), we have:
> 
> 1:  fmrrd   r0, r1, d\dr
> 1:  mrrcp11, 3, r0, r1, c\dr@ fmrrd r0, r1, d\dr
> 
> but in vfp_put_double(), we have:
> 
> 1:  fmdrr   d\dr, r0, r1
> 1:  mcrrp11, 3, r1, r2, c\dr@ fmdrr r1, r2, d\dr
> 
> Note the different registers.  Change "r1, r2" to "r0, r1" and it
> should work.

Yes, that's right. I figured that out yesterday and confirmed the test results. 
Thanks!

Can I go ahead with next version of the patch?

BR
Tarun
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Alan Cox :
> On Wed, 26 May 2010 15:30:58 -0700
> Arve Hjønnevåg  wrote:
>
>> On Wed, May 26, 2010 at 6:16 AM, Alan Cox  wrote:
>> >> Really, what are you getting at? Do you deny that there are programs,
>> >> that prevent a device from sleeping? (Just think of the bouncing
>> >> cows app)
>> >>
>> >> And if you have two kernels, one with which your device is dead after 1
>> >> hour and one with which your device is dead after 10 hours. Which would
>> >> you prefer? I mean really... this is ridiculous.
>> >
>> > The problem you have is that this is policy. If I have the device wired
>> > to a big screen and I want cows bouncing on it I'll be most upset if
>> > instead it suspends.
>>
>> We never suspend when the screen is on. If the screen is off, I would
>> not be upset if it suspends.
>
> This is policy and platform specific. The OLPC can suspend with the
> screen on. Should I write my app to know about this once for Android and
> once for OLPC (and no doubt once for Apple). In the OLPC case cows could
> indeed suspend to RAM between frames if the wakeup time was suitable.

Are you still talking about Linux suspend? If you can enter S3 from
idle and still wake up for the next timer or interrupt, then do that.
Suspend blockers should have not effect on this.

>
> My app simply should not have to know this sort of crap, that's the whole
> point of an OS.
>

Most apps does not have to know about this with opportunistic suspend
either. If the user is interacting with the device, we don't suspend.
If your apps needs to run when the user is not interacting with the
device, then you can block suspend.

>> > What you are essentially arguing for is for the
>> > kernel to disobey the userspace.
>>
>> No I'm not. User-space asked the kernel to suspend when possible.
>> Suspend is an existing kernel feature. All opportunistic suspend adds
>> is the ability to use it safely when there are wakeup event you cannot
>> afford to ignore.
>
> Don't get me wrong - opportunistic suspend isn't the problem. Suspend
> blockers are - or more precisely - the manner in which they express
> intent from userspace. Opportunistic suspend is wonderful stuff for all
> sorts of things and if it persuades people like netbook manufacturers to
> think harder, and Linux driver authors to optimise their suspend/resume
> paths we all win.
>
>> Our actual stating point is this: Some systems can only enter their
>> lowest power state from suspend. So we added an api that allowed us to
>> use suspend without loosing wakeup events. Since suspending also
>> improves our battery life on platforms that enter the same power state
>> from idle and suspend and we already have a way to safely use suspend,
>> we would be crazy not to use it.
>
> Opportunistic suspend isn't special. Suspend is just a very deep idle. In

Suspend as it is currently implemented in Linux is special. Regular
timers stop, and only specially marked wakeup events can bring the
system back to the normal state.

> fact some of the low power states on processors look little different to
> suspend - the OS executes a whole pile of CPU state saving and cache
> flushing. It might be a hardware state machine, it might be buried in
> firmware or it might be quite explicit (eg mrst). So we already have
> differing degrees of doing additional work in different states.
>
> User triggered suspend is a bit special in that the user is usually right
> in that case to override the power management policy.
>

On a phone this is not the case. The user manually can toggle the
screen on and off, and we may or may not enter suspend when the screen
is off. If we forced suspend when the user turned the screen off, we
could miss phone calls.

> Note I'm not suggesting we run off and restructure all our power
> management code to take this view right now. I'm suggesting we need a
> clean 'opportunistic suspend is not special' view by user space. How the
> kernel handles this is addressible later without app breakage, but only
> if we get the interface wrong to begin with.
>
>> > Sandboxing/Resource Limits: handling apps that can't be trusted. So the
>> > phone runs the appstore code via something like
>>
>> Sandboxing is problematic on Android since there are a lot of cross
>> process dependencies. When a call comes in I don't know where the name
>> and picture to display comes from. With suspend blockers we block
>> suspend when we get notified that we have an incoming call and we can
>> call into any process and get a response.
>
> But you can express user suspend blocking in this manner. Your call
> incoming code would say 'I want good latency'. As someone needs good
> latency the box won't suspend. If your approach is to start with an
> initial 'anyone can set a low latency we don't care' then anyone can
> block suspends.
>
> Equally your call handling example is about latency not about suspend.
> You want the phone to stay on, to fetch a picture and display it promptly.
>

I don't think a l

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg  wrote:

> On Wed, May 26, 2010 at 6:16 AM, Alan Cox  wrote:
> >> Really, what are you getting at? Do you deny that there are programs,
> >> that prevent a device from sleeping? (Just think of the bouncing
> >> cows app)
> >>
> >> And if you have two kernels, one with which your device is dead after 1
> >> hour and one with which your device is dead after 10 hours. Which would
> >> you prefer? I mean really... this is ridiculous.
> >
> > The problem you have is that this is policy. If I have the device wired
> > to a big screen and I want cows bouncing on it I'll be most upset if
> > instead it suspends.
> 
> We never suspend when the screen is on. If the screen is off, I would
> not be upset if it suspends.

This is policy and platform specific. The OLPC can suspend with the
screen on. Should I write my app to know about this once for Android and
once for OLPC (and no doubt once for Apple). In the OLPC case cows could
indeed suspend to RAM between frames if the wakeup time was suitable.

My app simply should not have to know this sort of crap, that's the whole
point of an OS.

> > What you are essentially arguing for is for the
> > kernel to disobey the userspace.
> 
> No I'm not. User-space asked the kernel to suspend when possible.
> Suspend is an existing kernel feature. All opportunistic suspend adds
> is the ability to use it safely when there are wakeup event you cannot
> afford to ignore.

Don't get me wrong - opportunistic suspend isn't the problem. Suspend
blockers are - or more precisely - the manner in which they express
intent from userspace. Opportunistic suspend is wonderful stuff for all
sorts of things and if it persuades people like netbook manufacturers to
think harder, and Linux driver authors to optimise their suspend/resume
paths we all win.

> Our actual stating point is this: Some systems can only enter their
> lowest power state from suspend. So we added an api that allowed us to
> use suspend without loosing wakeup events. Since suspending also
> improves our battery life on platforms that enter the same power state
> from idle and suspend and we already have a way to safely use suspend,
> we would be crazy not to use it.

Opportunistic suspend isn't special. Suspend is just a very deep idle. In
fact some of the low power states on processors look little different to
suspend - the OS executes a whole pile of CPU state saving and cache
flushing. It might be a hardware state machine, it might be buried in
firmware or it might be quite explicit (eg mrst). So we already have
differing degrees of doing additional work in different states.

User triggered suspend is a bit special in that the user is usually right
in that case to override the power management policy.

Note I'm not suggesting we run off and restructure all our power
management code to take this view right now. I'm suggesting we need a
clean 'opportunistic suspend is not special' view by user space. How the
kernel handles this is addressible later without app breakage, but only
if we get the interface wrong to begin with.

> > Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> > phone runs the appstore code via something like
> 
> Sandboxing is problematic on Android since there are a lot of cross
> process dependencies. When a call comes in I don't know where the name
> and picture to display comes from. With suspend blockers we block
> suspend when we get notified that we have an incoming call and we can
> call into any process and get a response.

But you can express user suspend blocking in this manner. Your call
incoming code would say 'I want good latency'. As someone needs good
latency the box won't suspend. If your approach is to start with an
initial 'anyone can set a low latency we don't care' then anyone can
block suspends.

Equally your call handling example is about latency not about suspend.
You want the phone to stay on, to fetch a picture and display it promptly.

So what are expressing

'I am using device 'screen' please keep it live'  (which may or may not
block suspend - see OLPC). I guess your display server and kernel support
manage this bit.

'I want the photo to appear in a resonable timescale'  (latency). It's
not a suspend question - an imaginary non suspend idle mode with a 20
second latency would be just as annoying yes ?

At the moment we have a very real bigger problem that your problem is
part of.

- Hard real time people want to be able to limit the CPU sleeping
  behaviour based upon what tasks are running

- Certain gaming types want their boxes to be good power citizens except
  when committing digital mass murder. Right now that involves wrapping
  the game in a script with bits occurring as root and that generally
  breaks if the game crashes so the script doesn't run nicely on exit

- Virtual machine people desperately want to see latency data to help
  schedule stuff in a power efficient manner.  In a virtual mach

[PATCH pm-wip/uart 4/4] 24xx: need .module_offs = CORE_MOD

[Kevin Hilman]

---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index c1618a5..682eecd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -239,6 +239,7 @@ static struct omap_hwmod omap2420_uart1_hwmod = {
.main_clk   = "uart1_fck",
.prcm   = {
.omap2 = {
+   .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP24XX_EN_UART1_SHIFT,
},
@@ -273,6 +274,7 @@ static struct omap_hwmod omap2420_uart2_hwmod = {
.main_clk   = "uart2_fck",
.prcm   = {
.omap2 = {
+   .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP24XX_EN_UART2_SHIFT,
},
@@ -307,6 +309,7 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.main_clk   = "uart3_fck",
.prcm   = {
.omap2 = {
+   .module_offs = CORE_MOD,
.prcm_reg_id = 2,
.module_bit = OMAP24XX_EN_UART3_SHIFT,
},
-- 
1.7.0.2

--
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 pm-wip/uart 3/4] OMAP2420: hwmod: UART3 needs prcm_reg_id = 2

[Kevin Hilman]

PRCM bits for UART3 are in PRCM reg id 2 (CM_IDLEST2_CORE, etc.)

Signed-off-by: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b9a957d..c1618a5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -307,7 +307,7 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.main_clk   = "uart3_fck",
.prcm   = {
.omap2 = {
-   .prcm_reg_id = 1,
+   .prcm_reg_id = 2,
.module_bit = OMAP24XX_EN_UART3_SHIFT,
},
},
-- 
1.7.0.2

--
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 pm-wip/uart 2/4] OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST

[Kevin Hilman]

Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().

Signed-off-by: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 ++---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   12 
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index bbe3006..b9a957d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -66,7 +66,8 @@ static struct omap_hwmod omap2420_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
.slaves = omap2420_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l3_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 static struct omap_hwmod omap2420_l4_wkup_hwmod;
@@ -156,7 +157,8 @@ static struct omap_hwmod omap2420_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
.slaves = omap2420_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_core_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 /* Slave interfaces on the L4_WKUP interconnect */
@@ -176,7 +178,8 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
.slaves = omap2420_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_wkup_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 /* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 45767b1..d7faef2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -66,7 +66,8 @@ static struct omap_hwmod omap2430_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
.slaves = omap2430_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l3_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 static struct omap_hwmod omap2430_l4_wkup_hwmod;
@@ -155,7 +156,8 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
.slaves = omap2430_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_core_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 /* Slave interfaces on the L4_WKUP interconnect */
@@ -178,7 +180,8 @@ static struct omap_hwmod omap2430_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
.slaves = omap2430_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_wkup_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 /* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5bf8690..6bc1173 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -77,7 +77,8 @@ static struct omap_hwmod omap3xxx_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
.slaves = omap3xxx_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l3_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
@@ -185,7 +186,8 @@ static struct omap_hwmod omap3xxx_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
.slaves = omap3xxx_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_core_slaves),
-   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+   .flags  = HWMOD_NO_IDLEST,
 };
 
 /* Slave interfaces on the L4_PER interconnect */
@@ -207,7 +209,8 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_per_masters),
.slaves = omap3xxx_l4_per_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l

[PATCH pm-wip/uart 1/4] OMAP3: hwmod: UART: add module offs

[Kevin Hilman]

fold into OMAP3 hwmod patch
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f88bfff..5bf8690 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -287,6 +287,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.main_clk   = "uart1_fck",
.prcm   = {
.omap2 = {
+   .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_UART1_SHIFT,
},
@@ -321,6 +322,7 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
.main_clk   = "uart2_fck",
.prcm   = {
.omap2 = {
+   .module_offs = CORE_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_UART2_SHIFT,
},
@@ -355,6 +357,7 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
.main_clk   = "uart3_fck",
.prcm   = {
.omap2 = {
+   .module_offs = OMAP3430_PER_MOD,
.prcm_reg_id = 1,
.module_bit = OMAP3430_EN_UART3_SHIFT,
},
-- 
1.7.0.2

--
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 pm-wip/uart 0/4] misc. fixes for IDLEST and OMAP24xx support

[Kevin Hilman]

This series on top of my pm-wip/uart branch fixes up various issues
with UART hwmods for 24xx as well as IDLEST issues after Benoit's
fixes/cleanup series.

Tested on OMAP3 (omap3evm) and OMAP2 (n810/2420).

Note that for OMAP2, this recently posted patch is required as well:

  [PATCH] OMAP24xx: CM: fix mask used for checking IDLEST status

These ares posted as FYI, and will be folded into the original hwmod
data for OMAP2+ UARTs.

Kevin


Kevin Hilman (4):
  OMAP3: hwmod: UART: add module offs
  OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
  OMAP2420: hwmod: UART3 needs prcm_reg_id = 2
  24xx: need .module_offs = CORE_MOD

 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   14 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 ++---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   15 +++
 3 files changed, 27 insertions(+), 11 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] OMAP24xx: CM: fix mask used for checking IDLEST status

[Kevin Hilman]

On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3.
The mask used to check this was using the bit position instead of the
bit mask.

This patch fixes the problem by using the bit mask instead of the bit
field.

Signed-off-by: Kevin Hilman 
---
Found when testing UART hwmods on OMAP2420 (n810)

 arch/arm/mach-omap2/cm.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/cm.c b/arch/arm/mach-omap2/cm.c
index 2d83565..721c3b6 100644
--- a/arch/arm/mach-omap2/cm.c
+++ b/arch/arm/mach-omap2/cm.c
@@ -50,15 +50,15 @@ int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id, 
u8 idlest_shift)
 
cm_idlest_reg = cm_idlest_offs[idlest_id - 1];
 
+   mask = 1 << idlest_shift;
+
if (cpu_is_omap24xx())
-   ena = idlest_shift;
+   ena = mask;
else if (cpu_is_omap34xx())
ena = 0;
else
BUG();
 
-   mask = 1 << idlest_shift;
-
/* XXX should be OMAP2 CM */
omap_test_timeout(((cm_read_mod_reg(prcm_mod, cm_idlest_reg) & mask) == 
ena),
  MAX_MODULE_READY_TIME, i);
-- 
1.7.0.2

--
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 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra :
> On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra :
>> > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
>> >> 2010/5/26 Peter Zijlstra :
>> >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>> >> >
>> >> >> and on systems where the
>> >> >> same power state can be used from idle and suspend, we use suspend so
>> >> >> we can stay in the low power state for minutes to hours instead of
>> >> >> milliseconds to seconds.
>> >> >
>> >> > So don't you think working on making it possible for systems to be idle
>> >> > _that_ long would improve things for everybody? as opposed to this
>> >> > auto-suspend which only improves matters for those that (can) use it?
>> >>
>> >> I'm not preventing anyone from working on improving this. Currently
>> >> both the kernel and our user-space code polls way too much. I don't
>> >> think it is reasonable to demand that no one should run any user-space
>> >> code with periodic timers when we have not even fixed the kernel to
>> >> not do this.
>> >
>> > All I'm saying is that merging a stop-gap measure will decrease the
>> > urgency and thus the time spend fixing the actual issues while adding
>> > the burden of maintaining this stop-gap measure.
>> >
>>
>> Fixing the actually issue means fixing all user-space code, and
>> replacing most x86 hardware. I don't think keeping this feature out of
>> the kernel will significantly accelerate this.
>
> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
> near fast enough for this to be usable.

x86 systems already auto-suspend.

>
> My laptop still takes several seconds to suspend (Lenovo T500), and
> resume (aside from some userspace bustage) takes the same amount of
> time. That is quick enough for manual suspend, but I'd hate it to try
> and auto-suspend.
>

Why? If your suspend is currently set to sleep after 30 minutes of
inactivity, you can still have the same setting with opportunistic
suspend. With opportunistic suspend you can have an alarm set to run a
task at a specific time without risking that this task does not run at
that time just because your inactivity timer expired at the same time
as the alarm went off.

> Getting longer idle periods however is something that everybody benefits
> from. On x86 we're nowhere close to hitting the max idle time of the
> platform, you get _tons_ of wakeups on current 'desktop' software.
>
> But x86 being a PITA shouldn't stop people from working on this, there's
> plenty other architectures out there, I remember fixing a NO_HZ bug with
> davem on sparc64 because his niagra had cores idling for very long times
> indeed.
>
> So yes, I do think merging this will delay the effort in fixing
> userspace, simply because all the mobile/embedded folks don't care about
> it anymore.
>

To me this is not a good argument for not merging the code. If people
stop caring about the problem if this feature is merged that means it
solved a problem for them. You want to prevent merging a feature
_because_ it solves a problem.

-- 
Arve Hjønnevå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 v2] serial: Add OMAP high-speed UART driver

[Kevin Hilman]

"Govindraj.R"  writes:

> This patch adds driver support for OMAP3/4 high speed UART.
>
> The driver is made separate from 8250 driver as we cannot
> over load 8250 driver with omap platform specific configuration for
> features like DMA, it makes easier to implement features like DMA and
> hardware flow control and software flow control configuration with
> this driver as required for the omap-platform.This patch involves only
> the core driver and its dependent.
>
> Cc: Tony Lindgren 
> Tested-by: Kevin Hilman 
> Signed-off-by: Govindraj.R 
> ---
> Platform data support for this driver is currently
> present in Kevin's PM tree remotes/origin/pm-wip/uart branch
> This branch contains uart-hwmod platform conversion which
> utilizes the omap-hwmod framework. Tested using OMAP
> 3430/3630/4430SDP boards.
>
>  arch/arm/plat-omap/include/plat/omap-serial.h |  129 +++
>  drivers/serial/Kconfig|   27 +
>  drivers/serial/Makefile   |1 +
>  drivers/serial/omap-serial.c  | 1318 
> +
>  include/linux/serial_core.h   |3 +
>  5 files changed, 1478 insertions(+), 0 deletions(-)

[...]

> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index f55c494..4346bfa 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -1387,6 +1387,33 @@ config SERIAL_OF_PLATFORM
> Currently, only 8250 compatible ports are supported, but
> others can easily be added.
>
> +config SERIAL_OMAP
> + tristate "OMAP serial port support"
> + depends on ARCH_OMAP3 || ARCH_OMAP4

FYI... this also works on OMAP2.  

I tested it on my n810 along with UART hwmod conversion and it works
just fine there.

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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 6:16 AM, Alan Cox  wrote:
>> Really, what are you getting at? Do you deny that there are programs,
>> that prevent a device from sleeping? (Just think of the bouncing
>> cows app)
>>
>> And if you have two kernels, one with which your device is dead after 1
>> hour and one with which your device is dead after 10 hours. Which would
>> you prefer? I mean really... this is ridiculous.
>
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends.

We never suspend when the screen is on. If the screen is off, I would
not be upset if it suspends.

> What you are essentially arguing for is for the
> kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible.
Suspend is an existing kernel feature. All opportunistic suspend adds
is the ability to use it safely when there are wakeup event you cannot
afford to ignore.

> It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
>
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.
>
> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
>

Our actual stating point is this: Some systems can only enter their
lowest power state from suspend. So we added an api that allowed us to
use suspend without loosing wakeup events. Since suspending also
improves our battery life on platforms that enter the same power state
from idle and suspend and we already have a way to safely use suspend,
we would be crazy not to use it.

> - You don't know which processes should be ignored for the purpose of
>  suspend (except for kernel threads) and there is no way to set this
>
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>  just a really deep idle in truth anyway) might break wakeups
>  requirements because a device has wake dependencies due to hardware
>  design (eg a port that has no electronics to kick the box out of
>  suspend into running). This is a problem we have already. [1]
>
> That maps onto two existing ideas
>
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like

Sandboxing is problematic on Android since there are a lot of cross
process dependencies. When a call comes in I don't know where the name
and picture to display comes from. With suspend blockers we block
suspend when we get notified that we have an incoming call and we can
call into any process and get a response.

>
>                setpidle(getpid(), something);
>                exec()
>
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
>
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone.
>
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
>


What about platforms that currently cannot enter low power states from
idle? Do you remove suspend support from the kernel?


> Alan
> --
>
> [1] Note I disagree with Kevin here on static/dynamic power management.
> There are IMHO two types of PM but they are 'user invoked' and
> 'automatic'. "Static" simply means it's not been made fast enough yet but
> its just a policy divide dependant on the users 'acceptable' resume time
> (which for hard RT may just as well rule out some more usual power states)
>
>
> --
> To uns

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> > suspend blockers are completely backwards as they basically disable
> > the kernels ability to do resource management.
> 
> I don't think this is a defect in the approach but the point of it. 

I think it's both. It's the point of it, and that itself is a defect. Its
designed wrongly.

> drivers code is needed anyway. What looses the kernel by implementing
> suspend blockers, and later a more finegrained approach and mapping the
> userspace part of suspend blockers on that finegrained approach later
> on?

The Linux approach is to do the job right. That means getting the
interface right and so it works across all the interested parties (or as
close as we can get).

> >   - how much delay of wakeups is tolerated (missing interface)
> 
> Doesn't solve the segregation problem and is probably overkill for most
> applications. I see this as an orthogonal thing (i.e. not
> affecting this merge). 

The key question that matters for suspend management is 'what wakeup
delay is tolerated'. So it's absolutely fundamental.

> True. But I wouldnt say, that it is the linux kernel who should force
> this politics onto its users.

This is the Linux way of doing things. It's like the GPL and being
shouted at by Linus. They are things you accept when you choose to take
part. Google chose to use Linux, if they want a feature upstream then the
way you get it there is to figure out how to solve the real problem and
make *everyone* (within reason) happy.

We now have suggestions how to do the job properly so the right thing is
probably to go and explore those suggestions not merge crap.

Merging crap won't help anyway. The rest of the kernel community can
still simply stonewall those interfaces, and a volunteer community has
ways of dealing with abuse of process, notably by simply not getting
around to, or implementing things directly contrary to the crap bits.

So it's not even in the interest of people to play political games. Even
if you get away with in the short term the people who rely on the junk
will end up out on a limb and holding the baby when the crap hits the fan
(see reiserfs)

Alan
--
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: [RFC] Initial attempt to make ARM use LMB

[Russell King - ARM Linux]

On Wed, May 26, 2010 at 06:51:29AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux  [100526 00:45]:
> > On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote:
> > 
> > > After applying the next patch in your lmb branch "ARM: OMAP: Convert
> > > to use ->reserve method to reserve boot time memory" tux still works
> > > on 5912osk, but not on n900. The difference is that osk5912 uses
> > > the old omapfb code.
> > 
> > I guess this is because I don't have board-n900.c in my tree.  All OMAP
> > boards need a ".reserve = omap_reserve," line added in their machine
> > descriptor.
> 
> It's there but well hidden, board-rx51.c is the one for n900.
>  
> > I just noticed that board-n8x0.c contains more than one machine descriptor,
> > which I've now fixed up.
> 
> OK good catch.
> 
> > > Anyways, I've picked the patches from lmb branch up to the one below
> > > into omap-testing. Will add more of them once we get them working.
> > 
> > You should now be able to pick all but the last patch.
> 
> Yeah I'll do that once the dss2 code has been verified to work.

It'd help with this patch - it seems rx51 needs some additional stuff.
Any other OMAP platforms with this kind of thing?

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 3bd956f..e3a42d1 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -144,17 +144,22 @@ static void __init rx51_init(void)
 static void __init rx51_map_io(void)
 {
omap2_set_globals_343x();
-   rx51_video_mem_init();
omap34xx_map_common_io();
 }
 
+static void __init rx51_reserve(void)
+{
+   rx51_video_mem_init();
+   omap_reserve();
+}
+
 MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
/* Maintainer: Lauri Leukkunen  */
.phys_io= 0x4800,
.io_pg_offst= ((0xfa00) >> 18) & 0xfffc,
.boot_params= 0x8100,
.map_io = rx51_map_io,
-   .reserve= omap_reserve,
+   .reserve= rx51_reserve,
.init_irq   = rx51_init_irq,
.init_machine   = rx51_init,
.timer  = &omap_timer,

--
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 04/10] OMAP4: hwmod: Replace OCPIF_HAS_IDLEST by HWMOD_NO_IDLEST

[Kevin Hilman]

Benoit Cousson  writes:

> Some initiator modules in OMAP2 & 3 does not have IDLEST bit,
> in that case we cannot detect the module readiness by
> polling that bit and must exist the function immediately
> assuming that the module is ready.
>
> The previous flag was affected to the OCP interface. While it is
> technically true that the idlest is related to the L4 slave
> interface of the module, the PRCM status belong to the module.
>
> Signed-off-by: Benoit Cousson 
> Cc: Paul Walmsley 

We had some discussions off-list on this patch... summarizing below.

> ---
>  arch/arm/mach-omap2/omap_hwmod.c |2 +-
>  arch/arm/plat-omap/include/plat/omap_hwmod.h |8 +---
>  2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 4a134c4..6459d07 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -808,7 +808,7 @@ static int _wait_target_ready(struct omap_hwmod *oh)
>  
>   os = *oh->slaves + oh->_mpu_port_index;
>  
> - if (!(os->flags & OCPIF_HAS_IDLEST))
> + if (oh->flags & HWMOD_NO_IDLEST)
>   return 0;

This changes the default from assuming a module doesn't have an IDLEST
to assuming it does.

Because of this, we now get a bunch of failures in _enable() on
OMAP2/3 due to missing fields in the hwmods, in particular the members
of the 'struct omap_hwmod_omap2_prcm' are required to get correct
_wait_for_ready() behavior.

Therefore, when creating new hwmods, please be sure the fields of this
struct are filled out and correct.

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: NULL Pointer Deference: NFS & Telnet

[Eric Dumazet]

Le mercredi 26 mai 2010 à 15:19 -0500, Arce, Abraham a écrit :

> By increasing the allocation length of our rx skbuff the corruption issue is 
> fixed... I have increased it by 2... Were we writing outside our boundaries 
> of skb data?
> 
> Please let me know about this approach...
> 
> diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
> index b4fb07a..6da81e1 100644
> --- a/drivers/net/ks8851.c
> +++ b/drivers/net/ks8851.c
> @@ -504,7 +504,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
>ks->rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
> 
> if (rxlen > 0) {
> -   skb = netdev_alloc_skb(ks->netdev, rxlen + 2 + 8);
> +   skb = netdev_alloc_skb(ks->netdev, rxlen + 4 + 8);
> if (!skb) {
> 
> Best Regards
> Abraham
> 

Yes that makes sense, nr_frag is right after the packet (padded to L1
cache size)

But please do the correct allocation ?

Also, we dont need FCS ?

diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..05bd312 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -503,8 +503,9 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
ks8851_wrreg16(ks, KS_RXQCR,
   ks->rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
 
-   if (rxlen > 0) {
-   skb = netdev_alloc_skb(ks->netdev, rxlen + 2 + 8);
+   if (rxlen > 4) {
+   rxlen -= 4;
+   skb = netdev_alloc_skb(ks->netdev, 2 + 8 + ALIGN(rxlen, 
4));
if (!skb) {
/* todo - dump frame and move on */
}
@@ -513,7 +514,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
 * for the status header and 4 bytes of garbage */
skb_reserve(skb, 2 + 4 + 4);
 
-   rxpkt = skb_put(skb, rxlen - 4) - 8;
+   rxpkt = skb_put(skb, rxlen) - 8;
 
/* align the packet length to 4 bytes, and add 4 bytes
 * as we're getting the rx status header as well */
@@ -526,7 +527,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
netif_rx(skb);
 
ks->netdev->stats.rx_packets++;
-   ks->netdev->stats.rx_bytes += rxlen - 4;
+   ks->netdev->stats.rx_bytes += rxlen;
}
 
ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);


--
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: NULL Pointer Deference: NFS & Telnet

[Arce, Abraham]

Thanks Eric, David,

[..]

> > > > -   if (skb_shinfo(skb)->nr_frags) {
> > > > +   if (skb_shinfo(skb)->nr_frags && skb_has_frags(skb)) {
> > > > int i;
> > > > for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
> > > > 
> > > > put_page(skb_shinfo(skb)->frags[i].page);
> > >
> > > skb_shinfo(skb)->nr_frags counts the number of entries contained
> > > in the skb_shinfo(skb)->frags[] array.
> > >
> > > This has nothing to do with the frag list pointer,
> > > skb_shinfo(skb)->frag_list, which is what skb_has_frags()
> > > tests.
> > >
> > > You've got some kind of memory corruption going on and it
> > > appears to have nothing to do with the code paths you're
> > > playing with here.
> >
> > Do you have any recommendation on debugging technique/tool for this memory
> corruption issue?

[..]

> It seems quite strange. You have a skb->nr_frags > 0 value, but a
> frags[i].page = 0 value
> 
> You might add following function :
> 
> shinfo_check(struct sk_buff *skb)
> {
>   struct skb_shared_info *shinfo = skb_shinfo(skb);
>   int i;
> 
>   WARN_ON(shinfo->nr_frags >= MAX_SKB_FRAGS);
>   for (i = 0; i < shinfo->nr_frags; i++)
>   WARN_ON(!shinfo->frags[i].page);
> }
> 
> And call it from various points, to check who corrupts your skb.

By increasing the allocation length of our rx skbuff the corruption issue is 
fixed... I have increased it by 2... Were we writing outside our boundaries of 
skb data?

Please let me know about this approach...

diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..6da81e1 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -504,7 +504,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
   ks->rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);

if (rxlen > 0) {
-   skb = netdev_alloc_skb(ks->netdev, rxlen + 2 + 8);
+   skb = netdev_alloc_skb(ks->netdev, rxlen + 4 + 8);
if (!skb) {

Best Regards
Abraham

--
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 0/8] Suspend block api (version 8)

[Zygo Blaxell]

On Wed, May 26, 2010 at 02:53:16PM +0200, Peter Zijlstra wrote:
> On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:
> > This is an area where machines are improving and where the ability to
> > do stuff like autosuspend, the technology like the OLPC screen and so on
> > create an incentive for the BIOS and platform people to improve their
> > bits of it.
> 
> But do you think its a sensible thing to do? Explicitly not running
> runnable tasks just sounds wrong. 
[...]
> Why would the code holding suspend blockers be any more or less
> important than any other piece of runnable code.

With my userspace developer hat on, I'd *kill* for a way to tell
the kernel that there are more important things for the system to
be doing than executing my runnable task.  In some cases, the set of
"more important things" the system might include running other tasks,
but it also might include conserving power.  I'd like to have my program
tell the kernel things like "wake me up in 0.1 seconds, plus or minus
a year if you have something better to do."

With my sysadmin hat on (which is nearly identical to my phone owner hat,
BTW), I'd like whatever syscall implements those features to take a PID
argument, so I can impose my importance decisions on other processes.
I'd also like to set the relative importance of keeping the CPU idle on
the same scale, so that I could raise or lower the importance of keeping
the CPU idle as power availability changes.

> This whole thing introduces an artificial segregation of code. My 'cool'
> code is more important than your 'uncool' code. Without a clear
> definition of what makes code cool or not.

It's impossible in the general case for an application to know whether
it's important or not, so it's also impossible for the kernel to derive
this information from the application's behavior--and impossible, in the
general case, to decide whether the application is more important than the
battery or some other scarce resource the kernel might also be managing
(e.g. if the machine is running hot, heat dissipation might be scarce,
and we'd want to be idle then too).  This is similar to niceness and
SCHED_RR/FIFO:  there's no way for the kernel to automatically assign
those values either, they have to be specified by a user or administrator.
Of course, programs are free--within limits--to specify these values
about themselves.

Consider a traditional Unix program like "sort".  Seriously, how is "sort"
supposed to know that it's the most important application on the system
(because I need my contacts list alphabetized *now*), or the least
(because the screensaver needs to know which is the oldest graphics
hack in the list)?

"sort" gets invoked from a shell, cooperating with other processes to do
its work.  It knows very little about the context in which it is executing
(nor should it).  Should "sort" sprout command-line arguments for every
possible scheduling latency and power management policy option, or should
"sort" not care, and defer such decisions to other command-line
tools which set these options before exec()ing "sort", or to a management
utility like "top" that implements policy across the entire system?

--
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] ARM:VFPv3:enable {d16-d31} access

[Russell King - ARM Linux]

On Wed, May 26, 2010 at 05:13:24PM +0530, DebBarma, Tarun Kanti wrote:
> 1) With the existing implementation I am not able to correctly
> write/read {d0-d15} but not the {d16-d31} set
> 
> 2) With my changes I am able to write/read correctly.

The reason this happens is simple.  In vfp_get_double(), we have:

1:  fmrrd   r0, r1, d\dr
1:  mrrcp11, 3, r0, r1, c\dr@ fmrrd r0, r1, d\dr

but in vfp_put_double(), we have:

1:  fmdrr   d\dr, r0, r1
1:  mcrrp11, 3, r1, r2, c\dr@ fmdrr r1, r2, d\dr

Note the different registers.  Change "r1, r2" to "r0, r1" and it
should work.
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 9:56 PM, Florian Mickler  wrote:

> Your approach definitely sounds better than the current solution.
> What about mapping suspend blocker functionality later on, when this
> interface exists, on to this new approach and deprecating it?

What about coming back after some while with the appropriate solution
when it's ready instead of stubbornly pushing crap?

~Vitaly
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 19:02:04 +0100
Alan Cox  wrote:

> > The power efficiency of a mobile device is depending on a sane overall
> > software stack and not on the ability to mitigate crappy software in
> > some obscure way which is prone to malfunction and disappoint users.
> 
> Even if you believe the kernel should be containing junk the model that
> works and is used for everything else is resource management. Not giving
> various tasks the ability to override rules, otherwise you end up needing
> suspend blocker blockers next week.
> 
> A model based on the idea that a task can set its desired wakeup
> behaviour *subject to hard limits* (ie soft/hard process wakeup) works
> both for the sane system where its elegantly managing hard RT, and for
> the crud where you sandbox it to stop it making a nasty mess.
> 
> Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
> trick ?
> 
> Alan

Your approach definitely sounds better than the current solution. 
What about mapping suspend blocker functionality later on, when this
interface exists, on to this new approach and deprecating it?

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 19:22:16 +0200 (CEST)
Thomas Gleixner  wrote:

> Florian,
> 
> On Wed, 26 May 2010, Florian Mickler wrote:
> >
> > On the other hand, applications can say, they don't need that much
> > power and userspace guaranties and not take a suspend blocker.
> > 
> > This is an option which they currently don't have.
> 
> Wrong. A well coded power aware application is very well able to
> express that in various ways already today. Admittedly it's far from
> perfect, but that can be fixed by adding interfaces which allow the
> power aware coder to express the requirements of his application
> actively, not by avoiding it.

Yeah, but a user can't say: "I don't
know programming, but I had this idea. Here try it out." 
to his friend. Because his friends phone then will crap out.

This is a negative. The phone just doesn't work well. 

A knowledgeable programmer is able to do extra work to enable specific
guarantees. A dummy-throw-away-programmer doesn't want to do
any extra work. 

> 
> suspend blockers are completely backwards as they basically disable
> the kernels ability to do resource management.

I don't think this is a defect in the approach but the point of it. 

> 
> Also they enforce a black and white scheme (suspend or run) on the
> kernel which is stupid, as there are more options to efficiently save
> power than those two. While current android devices might not provide
> them, later hardware will have it and any atom based device has them
> already.

This is true. Nonetheless, in my opinion, implementing the "backwards
approach" in any form (suspend blockers or some other sort of "sane"
interface) is necessary in the long run.  I also believe that Alan's
approach is the more flexible one. But I'm not in a position to judge
on this.

If it really is better and superior, I think userland will switch
over to it, as soon as it is possible to do it. The impact to the
drivers code is needed anyway. What looses the kernel by implementing
suspend blockers, and later a more finegrained approach and mapping the
userspace part of suspend blockers on that finegrained approach later
on?



> 
> So what the kernel needs to know to make better decisions are things
> like:
> 
>   - how much slack can timers have (exisiting interface)

I liked this idea of Arjan, to give some applications infinite timer
slack. But I don't know if it can made work in a "dummy proof" way.
(I.e. it is too complicated to get it right in general, except for the
"infinity" or not kind of tuning)

>   - how much delay of wakeups is tolerated (missing interface)

Doesn't solve the segregation problem and is probably overkill for most
applications. I see this as an orthogonal thing (i.e. not
affecting this merge). 

> 
> and probably some others. That information would allow the kernel to
> make better decisions versus power states, grouping timers, race to
> idle and other things which influence the power consumption based on
> the hardware you are running on.
> 
> > I don't think opportunistic suspend is a policy decision by the kernel.
> > it is something new. Something which currently only the android
> > userspace implements / supports. If you don't want to suspend while
> > looking at the bouncing-cow, you have to take a suspend blocker and
> > make yourself a user-visible power-eater, or don't do 
> > 
> > echo "opportunistic" > /sys/power/policy 
> > 
> > in the first place.
> > 
> > This "optionally being badly written, who cares?" is a new feature the
> > kernel can provide to applications. 
> 
> It's a misfeature which the kernel should not provide at all. It sends
> out the completely wrong message: Hey, we can deal with your crappy
> code, keep on coding that way.

I can't really say anything against that. Or anything in favor of it.  
Except that this is probably a really hard decision for Linus to
make. 

> 
> While this seems to sound cool to certain people in the mobile space,
> it's completely backwards and will backfire in no time. 

Maybe. It is something which seems to not come from the traditional
"linux distribution" model of software deployment, where you have a
party that codes and another party that packages that code. 

It instead is more targeted at the decentralised 3rd-party-app
approach under which windows is suffering.

> The power efficiency of a mobile device is depending on a sane overall
> software stack and not on the ability to mitigate crappy software in
> some obscure way which is prone to malfunction and disappoint users.

True. But I wouldnt say, that it is the linux kernel who should force
this politics onto its users.

> 
> Thanks,
> 
>   tglx
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> The power efficiency of a mobile device is depending on a sane overall
> software stack and not on the ability to mitigate crappy software in
> some obscure way which is prone to malfunction and disappoint users.

Even if you believe the kernel should be containing junk the model that
works and is used for everything else is resource management. Not giving
various tasks the ability to override rules, otherwise you end up needing
suspend blocker blockers next week.

A model based on the idea that a task can set its desired wakeup
behaviour *subject to hard limits* (ie soft/hard process wakeup) works
both for the sane system where its elegantly managing hard RT, and for
the crud where you sandbox it to stop it making a nasty mess.

Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the
trick ?

Alan
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Florian,

On Wed, 26 May 2010, Florian Mickler wrote:
>
> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.
> 
> This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to
express that in various ways already today. Admittedly it's far from
perfect, but that can be fixed by adding interfaces which allow the
power aware coder to express the requirements of his application
actively, not by avoiding it.

suspend blockers are completely backwards as they basically disable
the kernels ability to do resource management.

Also they enforce a black and white scheme (suspend or run) on the
kernel which is stupid, as there are more options to efficiently save
power than those two. While current android devices might not provide
them, later hardware will have it and any atom based device has them
already.

So what the kernel needs to know to make better decisions are things
like:

  - how much slack can timers have (exisiting interface)
  - how much delay of wakeups is tolerated (missing interface)

and probably some others. That information would allow the kernel to
make better decisions versus power states, grouping timers, race to
idle and other things which influence the power consumption based on
the hardware you are running on.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android
> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.
> 
> This "optionally being badly written, who cares?" is a new feature the
> kernel can provide to applications. 

It's a misfeature which the kernel should not provide at all. It sends
out the completely wrong message: Hey, we can deal with your crappy
code, keep on coding that way.

While this seems to sound cool to certain people in the mobile space,
it's completely backwards and will backfire in no time. 

The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.

Thanks,

tglx

--
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 12/17] drivers/video/omap2/displays: Add missing mutex_unlock

[Julia Lawall]

From: Julia Lawall 

Add a mutex_unlock missing on the error paths.  The use of the mutex is
balanced elsewhere in the file.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression E1;
@@

* mutex_lock(E1,...);
  <+... when != E1
  if (...) {
... when != E1
*   return ...;
  }
  ...+>
* mutex_unlock(E1,...);
// 

Signed-off-by: Julia Lawall 

---
 drivers/video/omap2/displays/panel-acx565akm.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/omap2/displays/panel-acx565akm.c 
b/drivers/video/omap2/displays/panel-acx565akm.c
index 1f8eb70..07fbb8a 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -592,7 +592,7 @@ static int acx_panel_power_on(struct omap_dss_device 
*dssdev)
r = omapdss_sdi_display_enable(dssdev);
if (r) {
pr_err("%s sdi enable failed\n", __func__);
-   return r;
+   goto fail_unlock;
}
 
/*FIXME tweak me */
@@ -633,6 +633,8 @@ static int acx_panel_power_on(struct omap_dss_device 
*dssdev)
return acx565akm_bl_update_status(md->bl_dev);
 fail:
omapdss_sdi_display_disable(dssdev);
+fail_unlock:
+   mutex_unlock(&md->mutex);
return r;
 }
 
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler  wrote:

> On Wed, 26 May 2010 17:45:00 +0200
> Peter Zijlstra  wrote:
> 
> > On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > > On Wed, 26 May 2010 17:15:47 +0200
> > > Peter Zijlstra  wrote:
> > > 
> > > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > > I'm not saying that your argument is not valid. But why don't you look
> > > > > at suspend blockers as a contract between userspace and kernelspace? 
> > > > > An
> > > > > Opt-In to the current guarantees the kernel provides in the 
> > > > > non-suspend
> > > > > case.
> > > > 
> > > > That's backwards.
> > > 
> > > I think that's the point of it. 
> > 
> > Apparently, and you're not accepting that we're telling you we think its
> > a singularly bad idea. Alan seems to have the skill to clearly explain
> > why, I suggest you re-read his emails again.
> 
> I'm sorry if I offend you. I indeed read Alan's emails. It's just they
> have more content than yours. So it takes longer. 
> 
> Cheers,
> Flo

p.s.: also they encourage me to think more before answering. 
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra  wrote:

> On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 17:15:47 +0200
> > Peter Zijlstra  wrote:
> > 
> > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > I'm not saying that your argument is not valid. But why don't you look
> > > > at suspend blockers as a contract between userspace and kernelspace? An
> > > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > > case.
> > > 
> > > That's backwards.
> > 
> > I think that's the point of it. 
> 
> Apparently, and you're not accepting that we're telling you we think its
> a singularly bad idea. Alan seems to have the skill to clearly explain
> why, I suggest you re-read his emails again.

I'm sorry if I offend you. I indeed read Alan's emails. It's just they
have more content than yours. So it takes longer. 

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 17:15:47 +0200
> Peter Zijlstra  wrote:
> 
> > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > I'm not saying that your argument is not valid. But why don't you look
> > > at suspend blockers as a contract between userspace and kernelspace? An
> > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > case.
> > 
> > That's backwards.
> 
> I think that's the point of it. 

Apparently, and you're not accepting that we're telling you we think its
a singularly bad idea. Alan seems to have the skill to clearly explain
why, I suggest you re-read his emails again.

--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra  wrote:

> On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > I'm not saying that your argument is not valid. But why don't you look
> > at suspend blockers as a contract between userspace and kernelspace? An
> > Opt-In to the current guarantees the kernel provides in the non-suspend
> > case.
> 
> That's backwards.

I think that's the point of it. 

--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

It is a contract - but not the right one. You are removing autonomy from
the kernel when only the kernel can measure the full picture and when the
kernel is actually supposed to be responsible for resource management.

> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.

Even the the model is wrong.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android

Disagree. It's an arbitary and misleading divide that happens to reflect
a specific vendors current phones. Worse yet it may not reflect their own
future products. It assumes for example that their is some power level
that is 'suspend' that is singular, application understood and can be
effectively user space managed. Big assumptions and not ones that seem to
be sensible.

It also breaks another rule - when the hardware changes your application
blocker policies will be wrong. Do you want multiple hand optimised
copies of each app ? Take a look at what happened to CPU designs where
the assumption was you'd recompile the app for each CPU version to get
any useful performance.

If you are instead expressing it as "must be able to respond in time X"
and "must be able to wake up from an event on an active device" then your
interface is generic and hardware independant.

If "bouncing cows" says 'need to wake up every 0.3 seconds" you want the
kernel to decide how best to do that. It will vary by hardware. On todays
desktop PC thats probably a low power state limit. On some current
embedded hardware it might be a special deep sleep mode. On one or two
devices it might be 'suspend'. It might also be that the properties have
been set to 2 seconds already so it gets told it can't have 0.3.

The app cannot be allowed to know platform specific stuff or your
portability comes apart and you end up with a disaster area where each
app only comes on a subset of devices. Express the requirement right and
you get a simple clean interface that continues to work.

Express it wrong and you get a mess.

> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 

Thats a very big hammer and it doesn't express what I actually want,
which is to allow the cows to run as efficiently as possible.
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.

But you can do this properly by having a per process idle requirement,
and that can encompass things like hard real time as well (or even
gaming). The suspend blockers break all the global policy, don't solve
real time and don't allow for sensible expansion models. They don't solve
our existing wakeup versus device problems either.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

In this environment the problem cannot occur in the first place unless
there are kernel code bugs, if there are then they are in GPL code and can
be fixed. But you are mixing up interfaces and implementations which I
find is usually a bad idea. Doing the right thing badly gives you an
interface to an implementation you can later fix. Doing the wrong thing
well leaves you stuck down a hole.

> p.s.: 
> d...@schatten /usr/src/linux $ grep -r "setpidle" .

Yes I know - no point having a new function which has an in use name is
there ? It's trivial to add per process idling or wakeup requirements.

Alan
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote:
> > > Really, what are you getting at? Do you deny that there are programs,
> > > that prevent a device from sleeping? (Just think of the bouncing
> > > cows app)
> > > 
> > > And if you have two kernels, one with which your device is dead after 1
> > > hour and one with which your device is dead after 10 hours. Which would
> > > you prefer? I mean really... this is ridiculous. 
> > 
> > The problem you have is that this is policy. If I have the device wired
> > to a big screen and I want cows bouncing on it I'll be most upset if
> > instead it suspends. What you are essentially arguing for is for the
> > kernel to disobey the userspace. It's as ridiculous (albeit usually less
> > damaging) as a file system saying "Ooh thats a rude file name, the app
> > can't have meant it, I'll put your document soemwhere else"
> > 
> > The whole API feels wrong to me. It's breaking rule #1 of technology "You
> > cannot solve a social problem with technology". In this case you have a
> > social/economic problem which is crap code. You solve it with an
> > economics solution - creative incentives not to produce crap code like
> > boxes that keep popping up saying "App XYZ is using all your battery" and
> > red-amber-green powermeter scores in app stores.
> 
> I completely agree. 
> 
> We have already proven that the social pressure on crappy applications
> works. When NOHZ was merged into the kernel we got no effect at all
> because a big percentage of user space applications just used timers
> at will and without any thoughts, also it unveiled busy polling and
> other horrible coding constructs. So what happened ? Arjan created
> powertop which lets the user analyse the worst offenders in his
> system. As a result the offending apps got fixed rapidly simply
> because no maintainer wanted to be on top of the powertop sh*tlist.
> 
> In the mobile app space it's basically the same problem. Users can
> influence the app writers simply by voting and setting up public lists
> of apps which are crappy or excellent. All it needs is a nice powertop
> tool for the phone which allows the users to identify the crap on
> their phones. That provides much more incentive - especially for
> commercial players - to fix their crappy code.
> 
> Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
> is just counter productive as it signals to the app provider: Go
> ahead, keep on coding crap!
> 
> That's not a solution, that's just capitulation. 
> 
> It's absurd that some folks believe that giving up the most efficient
> tool to apply pressure to crappy app providers is a good idea.

I couldn't agree more with both of you. I also have stated that a
powertop application with a fancy UI would do the job. Also building
some sort of power estimations on the SDK would allow the developer the
have fast feedback about potential power consumption caused by his app
on the device.

On top of that, the app stores can use the same power estimation
"technology" to rate apps automatically and even reject apps that are
wy too badly written.

I also feel that kernel shouldn't have to deal, fix, hide bad behavior
from apps.

-- 
balbi
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

Alan Cox  writes:

> [1] Note I disagree with Kevin here on static/dynamic power management.
> There are IMHO two types of PM but they are 'user invoked' and
> 'automatic'. "Static" simply means it's not been made fast enough yet but
> its just a policy divide dependant on the users 'acceptable' resume time
> (which for hard RT may just as well rule out some more usual power states)

Completely agree with this.

I used the static/dynamic names out of habit, but since on most
embedded devices, there is really no difference in hardware power
state, I agree that the difference is only a matter of wakeup latency.

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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
How about we don't merge that junk and don't give you the opportunity to
do silly things like that? :-)

--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

That's backwards.

--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > Implementation-wise it probably ties into setpidle, its simply that a task
> > has a pair of idle values, a dynamic one and a base one, the dynamic one
> > being the base one but updatable temporarily by drivers.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

By not suspending obviously.

--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:16:12 +0100
Alan Cox  wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.

<>

On the other hand, applications can say, they don't need that much
power and userspace guaranties and not take a suspend blocker.

This is an option which they currently don't have.

I don't think opportunistic suspend is a policy decision by the kernel.
it is something new. Something which currently only the android
userspace implements / supports. If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and
make yourself a user-visible power-eater, or don't do 

echo "opportunistic" > /sys/power/policy 

in the first place.

This "optionally being badly written, who cares?" is a new feature the
kernel can provide to applications. 

That said, your proposed alternative implementation scheme looks like
another possible approach.


> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
> 
> - You don't know which processes should be ignored for the purpose of
>   suspend (except for kernel threads) and there is no way to set this
> 
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>   just a really deep idle in truth anyway) might break wakeups
>   requirements because a device has wake dependencies due to hardware
>   design (eg a port that has no electronics to kick the box out of
>   suspend into running). This is a problem we have already. [1]
> 
> That maps onto two existing ideas
> 
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like
> 
>   setpidle(getpid(), something);
>   exec()
> 
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
> 
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone. 
> 
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
> 
> Alan

How does this address the loss of wakeup events while using suspend? 
(For example the 2 issues formulated by Alan Stern in [1])

cheers,
Flo

[1]http://lkml.org/lkml/2010/5/21/458

p.s.: 
d...@schatten /usr/src/linux $ grep -r "setpidle" .
d...@schatten /usr/src/linux $ 
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Wed, 26 May 2010, Florian Mickler wrote:

> I don't think that the in-kernel suspend block is a bad idea. 
> 
> You could probably use the suspend-blockers unconditionally in the
> suspend framework to indicate if a suspend is possible or not.

That's not how it works.  Drivers aren't supposed to abort
unconditional suspend -- not without a really good reason (for example,
the device received a wakeup event before it was fully suspended).  In
short, suspends should be considered to be _always_ possible.

> Regardless of opportunistic suspend or not. This way, you don't have to
> try-and-fail on a suspend request and thus making suspending
> potentially more robust or allowing for a "suspend as soon as
> possible" semantic (which is probably a good idea, if you have to grab
> your laptop in a hurry to get away).

That's different.  Suspend blockers could block (not abort!) regular 
suspends, just as they do opportunistic suspends.

But why should they?  I mean, if userspace wants to initiate a suspend
that is capable of being blocked by a kernel suspend blocker, then all
it has to do is initiate an opportunistic suspend instead of a normal
suspend.

Alan Stern

--
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: [RFC] Initial attempt to make ARM use LMB

[Tony Lindgren]

* Russell King - ARM Linux  [100526 00:45]:
> On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote:
> 
> > After applying the next patch in your lmb branch "ARM: OMAP: Convert
> > to use ->reserve method to reserve boot time memory" tux still works
> > on 5912osk, but not on n900. The difference is that osk5912 uses
> > the old omapfb code.
> 
> I guess this is because I don't have board-n900.c in my tree.  All OMAP
> boards need a ".reserve = omap_reserve," line added in their machine
> descriptor.

It's there but well hidden, board-rx51.c is the one for n900.
 
> I just noticed that board-n8x0.c contains more than one machine descriptor,
> which I've now fixed up.

OK good catch.

> > Anyways, I've picked the patches from lmb branch up to the one below
> > into omap-testing. Will add more of them once we get them working.
> 
> You should now be able to pick all but the last patch.

Yeah I'll do that once the dss2 code has been verified to work.

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 1/2] Adding LogicPD OMAP 3530 LV SOM and OMAP 35x Torpedo

[Jacob Tanenbaum]

Adding LogicPD OMAP3 board support

Adding support for LogicPD's OMAP 3530 LV SOM and
OMAP 35x Torpedo board.

Signed-off-by: Jacob Tanenbaum 
---
 arch/arm/configs/omap3_logic_defconfig |  990 
 arch/arm/mach-omap2/Kconfig|8 +
 arch/arm/mach-omap2/Makefile   |4 +
 arch/arm/mach-omap2/board-omap3logic.c |  185 ++
 4 files changed, 1187 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/configs/omap3_logic_defconfig
 create mode 100644 arch/arm/mach-omap2/board-omap3logic.c

diff --git a/arch/arm/configs/omap3_logic_defconfig 
b/arch/arm/configs/omap3_logic_defconfig
new file mode 100644
index 000..90f5ecd
--- /dev/null
+++ b/arch/arm/configs/omap3_logic_defconfig
@@ -0,0 +1,990 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.32
+# Wed May  5 19:56:47 2010
+#
+CONFIG_ARM=y
+CONFIG_SYS_SUPPORTS_APM_EMULATION=y
+CONFIG_GENERIC_GPIO=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
+CONFIG_HARDIRQS_SW_RESEND=y
+CONFIG_GENERIC_IRQ_PROBE=y
+CONFIG_RWSEM_GENERIC_SPINLOCK=y
+CONFIG_ARCH_HAS_CPUFREQ=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
+CONFIG_OPROFILE_ARMV7=y
+CONFIG_VECTORS_BASE=0x
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+CONFIG_CONSTRUCTORS=y
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_LOCK_KERNEL=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=""
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_BSD_PROCESS_ACCT=y
+# CONFIG_BSD_PROCESS_ACCT_V3 is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_TREE_RCU=y
+# CONFIG_TREE_PREEMPT_RCU is not set
+# CONFIG_RCU_TRACE is not set
+CONFIG_RCU_FANOUT=32
+# CONFIG_RCU_FANOUT_EXACT is not set
+# CONFIG_TREE_RCU_TRACE is not set
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_GROUP_SCHED=y
+CONFIG_FAIR_GROUP_SCHED=y
+# CONFIG_RT_GROUP_SCHED is not set
+CONFIG_USER_SCHED=y
+# CONFIG_CGROUP_SCHED is not set
+# CONFIG_CGROUPS is not set
+# CONFIG_SYSFS_DEPRECATED_V2 is not set
+# CONFIG_RELAY is not set
+# CONFIG_NAMESPACES is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=""
+CONFIG_RD_GZIP=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL=y
+CONFIG_ANON_INODES=y
+CONFIG_EMBEDDED=y
+CONFIG_UID16=y
+# CONFIG_SYSCTL_SYSCALL is not set
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+# CONFIG_ELF_CORE is not set
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_AIO=y
+
+#
+# Kernel Performance Events And Counters
+#
+CONFIG_VM_EVENT_COUNTERS=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
+CONFIG_PROFILING=y
+CONFIG_TRACEPOINTS=y
+CONFIG_OPROFILE=y
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_CLK=y
+
+#
+# GCOV-based kernel profiling
+#
+# CONFIG_GCOV_KERNEL is not set
+# CONFIG_SLOW_WORK is not set
+CONFIG_HAVE_GENERIC_DMA_COHERENT=y
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_MODULE_SRCVERSION_ALL=y
+CONFIG_BLOCK=y
+CONFIG_LBDAF=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+# CONFIG_DEFAULT_AS is not set
+# CONFIG_DEFAULT_DEADLINE is not set
+CONFIG_DEFAULT_CFQ=y
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="cfq"
+CONFIG_FREEZER=y
+
+#
+# System Type
+#
+CONFIG_MMU=y
+# CONFIG_ARCH_AAEC2000 is not set
+# CONFIG_ARCH_INTEGRATOR is not set
+# CONFIG_ARCH_REALVIEW is not set
+# CONFIG_ARCH_VERSATILE is not set
+# CONFIG_ARCH_AT91 is not set
+# CONFIG_ARCH_CLPS711X is not set
+# CONFIG_ARCH_GEMINI is not set
+# CONFIG_ARCH_EBSA110 is not set
+# CONFIG_ARCH_EP93XX is not set
+# CONFIG_ARCH_FOOTBRIDGE is not set
+# CONFIG_ARCH_MXC is not set
+# CONFIG_ARCH_STMP3XXX is not set
+# CONFIG_ARCH_NETX is not set
+# CONFIG_ARCH_H720X is not set
+# CONFIG_ARCH_NOMADIK is not set
+# CONFIG_ARCH_IOP13XX is not set
+# CONFIG_ARCH_IOP32X is not set
+# CONFIG_ARCH_IOP33X is not set
+# CONFIG_ARCH_IXP23XX is not set
+# CONFIG_ARCH_IXP2000 is not set
+# CONFIG_ARCH_IXP4XX is not set
+# CONFIG_ARCH_L7200 is not set
+# CONFIG_ARCH_KIRKWOOD is not set
+# CONFIG_ARCH_LOKI is not set
+# CONFIG_ARCH_MV78XX0 is not set
+# CONFIG_ARCH_ORION5X is

[PATCH 2/2] Adding low-level init for hsmmc controller for OMAP 3530 LV SOM and OMAP 35x Torpedo

[Jacob Tanenbaum]

ARM: OMAP3LOGIC: Adding SDMMC support

Add low-level initialization for hsmmc controller for
LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board.

Signed-off-by: Jacob Tanenbaum 
---
 arch/arm/mach-omap2/board-omap3logic.c |   69 +++-
 1 files changed, 68 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3logic.c 
b/arch/arm/mach-omap2/board-omap3logic.c
index fe5db85..13e0b16 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -33,13 +33,18 @@
 #include 
 
 #include "mux.h"
-
+#include "hsmmc.h"
 #include 
 #include 
 #include 
 #include 
 #include 
 
+#define OMAP3530_LV_SOM_MMC_GPIO_CD 110
+#define OMAP3530_LV_SOM_MMC_GPIO_WP 126
+#define OMAP3_TORPEDO_MMC_GPIO_CD   127
+#define OMAP3_TORPEDO_MMC_GPIO_WP   (-EINVAL)
+
 /* Micron MT46H32M32LF-6 */
 /* FIXME: borrowed from sdram-micron-mt46h32m32lf-6.h because on LogicPD
  * boards we can't use the default values -- why? I suspect the reason
@@ -80,6 +85,28 @@ static struct omap_sdrc_params mt46h32m32lf6_sdrc_params[] = 
{
},
 };
 
+
+static struct regulator_consumer_supply omap3logic_vmmc1_supply = {
+   .supply = "vmmc",
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
+static struct regulator_init_data omap3logic_vmmc1 = {
+   .constraints = {
+   .name   = "VMMC1",
+   .min_uV = 185,
+   .max_uV = 315,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+   | REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = 1,
+   .consumer_supplies  = &omap3logic_vmmc1_supply,
+};
+
+
 static int omap3logic_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
 {
@@ -121,6 +148,44 @@ static int __init omap3logic_i2c_init(void)
return 0;
 }
 
+
+static struct omap2_hsmmc_info __initdata board_mmc_info[] = {
+   {
+   .name   = "external",
+   .mmc= 1,
+   .wires  = 4,
+   .gpio_cd= -EINVAL,
+   .gpio_wp= -EINVAL,
+   },
+   {}  /* Terminator */
+};
+
+static void __init board_mmc_init(void)
+{
+   /* OMAP3530 LV SOM board */
+   if (machine_is_omap3530_lv_som()) {
+   board_mmc_info[0].gpio_cd = OMAP3530_LV_SOM_MMC_GPIO_CD;
+   board_mmc_info[0].gpio_wp = OMAP3530_LV_SOM_MMC_GPIO_WP;
+   omap_mux_init_signal("gpio_110", OMAP_PIN_OUTPUT);
+   omap_mux_init_signal("gpio_126", OMAP_PIN_OUTPUT);
+
+
+   /* OMAP3 Torpedo board */
+   } else if (machine_is_omap3_torpedo()) {
+   board_mmc_info[0].gpio_cd = OMAP3_TORPEDO_MMC_GPIO_CD;
+   omap_mux_init_signal("gpio_127", OMAP_PIN_OUTPUT);
+   /* unsupported board */
+   } else {
+   printk(KERN_ERR "%s(): unknown machine type\n", __func__);
+   return;
+   }
+
+   omap2_hsmmc_init(board_mmc_info);
+   /* link regulators to MMC adapters */
+   omap3logic_vmmc1_supply.dev = board_mmc_info[0].dev;
+}
+
+
 static struct omap_board_config_kernel omap3logic_config[] __initdata = {
 };
 
@@ -164,6 +229,7 @@ static void __init omap3logic_map_io(void)
 
 MACHINE_START(OMAP3_TORPEDO, "Logic OMAP3 Torpedo board")
/* Maintainer: Peter Barada  */
+
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) >> 18) & 0xfffc,
.boot_params= 0x8100,
@@ -175,6 +241,7 @@ MACHINE_END
 
 MACHINE_START(OMAP3530_LV_SOM, "OMAP Logic 3530 LV SOM board")
/* Maintainer: Peter Barada  */
+
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) >> 18) & 0xfffc,
.boot_params= 0x8100,
-- 
1.6.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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Alan,

On Wed, 26 May 2010, Alan Cox wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I completely agree. 

We have already proven that the social pressure on crappy applications
works. When NOHZ was merged into the kernel we got no effect at all
because a big percentage of user space applications just used timers
at will and without any thoughts, also it unveiled busy polling and
other horrible coding constructs. So what happened ? Arjan created
powertop which lets the user analyse the worst offenders in his
system. As a result the offending apps got fixed rapidly simply
because no maintainer wanted to be on top of the powertop sh*tlist.

In the mobile app space it's basically the same problem. Users can
influence the app writers simply by voting and setting up public lists
of apps which are crappy or excellent. All it needs is a nice powertop
tool for the phone which allows the users to identify the crap on
their phones. That provides much more incentive - especially for
commercial players - to fix their crappy code.

Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
is just counter productive as it signals to the app provider: Go
ahead, keep on coding crap!

That's not a solution, that's just capitulation. 

It's absurd that some folks believe that giving up the most efficient
tool to apply pressure to crappy app providers is a good idea.

Thanks,

tglx
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:19:42 +0100
Alan Cox  wrote:


> > This is a _big_ plus for attracting 3rd party programs. (And of course
> > the thing you don't like). 
> 
> You would do better to concentrate on technical issues that the
> assignment of malicious intent to other parties.
> 
> Alan

This was nothing the kind of! He explicitly said this:

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi  wrote:

> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.

And I responded that if the kernel would do this, then that would
be a "_big_ plus for attracting 3d party programs". 

I had no intent in attacking anyone or putting word's in someones mouth.
Sorry if this was unclearly written.

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra  wrote:

> On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> > The kernel can not win if it does not try to integrate any use of it.
> 
> If we'd integrate every patch that came to lkml, you'd run away
> screaming.
> 
> We most certainly do not want to integrate _any_ use.

We most certainly do want to integrate any use that is not harmful to
others.

I don't buy the argument that this is harmful. 

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool  wrote:

> On Wed, May 26, 2010 at 2:24 PM, Florian Mickler  wrote:
> 
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> >
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous.
> 
> You almost always need to "hack" the mainline software for a
> production system. So do it here as well. Make sure the hack is well
> isolated and local. You can even submit it to the mainline, better as
> a configuration option, _unless_ it is a *framework* that provokes
> writing code in an ugly and unsafe way.
> 
> ~Vitaly

I don't think that the in-kernel suspend block is a bad idea. 

You could probably use the suspend-blockers unconditionally in the
suspend framework to indicate if a suspend is possible or not.
Regardless of opportunistic suspend or not. This way, you don't have to
try-and-fail on a suspend request and thus making suspending
potentially more robust or allowing for a "suspend as soon as
possible" semantic (which is probably a good idea, if you have to grab
your laptop in a hurry to get away).

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

That seems to me to be conflating models of behaviour and implementations.

> This is a _big_ plus for attracting 3rd party programs. (And of course
> the thing you don't like). 

You would do better to concentrate on technical issues that the
assignment of malicious intent to other parties.

Alan
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
> 
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous. 

The problem you have is that this is policy. If I have the device wired
to a big screen and I want cows bouncing on it I'll be most upset if
instead it suspends. What you are essentially arguing for is for the
kernel to disobey the userspace. It's as ridiculous (albeit usually less
damaging) as a file system saying "Ooh thats a rude file name, the app
can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You
cannot solve a social problem with technology". In this case you have a
social/economic problem which is crap code. You solve it with an
economics solution - creative incentives not to produce crap code like
boxes that keep popping up saying "App XYZ is using all your battery" and
red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense
if you look at it from a different starting point. The starting point
being this: We have idling logic in the kernel and improving this helps
everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of
  suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is
  just a really deep idle in truth anyway) might break wakeups
  requirements because a device has wake dependencies due to hardware
  design (eg a port that has no electronics to kick the box out of
  suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the
phone runs the appstore code via something like

setpidle(getpid(), something);
exec()

where 'something' is a value with meaning to both user space and to the
existing idling logic in the kernel that basically says to what extent it
is permitted to block idling/suspend. That also seems to tie into some of
the realtime + idle problems. This I think deals with Kevin Hillman's
thoughts on dealing with untrustworthy app code more cleanly and avoids
the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in
their current situation they require that the power level doesn't drop
below some limit unless user requested. This is really important because
the platform vendor of the phone/pda/tablet whatever effectively owns the
kernel - so it's *their* problem, *their* control, *their* hardware and
they can make it work as best for the device. Best of all it means its
all free software stuff so if the vendor screws up you can still fix your
phone. 

Implementation-wise it probably ties into setpidle, its simply that a task
has a pair of idle values, a dynamic one and a base one, the dynamic one
being the base one but updatable temporarily by drivers.

Alan
--

[1] Note I disagree with Kevin here on static/dynamic power management.
There are IMHO two types of PM but they are 'user invoked' and
'automatic'. "Static" simply means it's not been made fast enough yet but
its just a policy divide dependant on the users 'acceptable' resume time
(which for hard RT may just as well rule out some more usual power states)


--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> The kernel can not win if it does not try to integrate any use of it.

If we'd integrate every patch that came to lkml, you'd run away
screaming.

We most certainly do not want to integrate _any_ use.
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote:

> It really comes down to a policy decision by the distribution maker.
> And I don't think kernel upstream should be the one to force one way or
> the other.

That's exactly what we always do. If we were not to do so, the kernel
would be a bloated incoherent piece of crap.

>  So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

I really think we should not do so. Let them help in fixing the real
issue instead of creating a new class of userspace that is more
important than another.

> But look at it this way: Suspend blockers are a way for the kernel
> to make user space programs accountable for using the resource "power".

How is userspace without suspend blockers not accountable? We can easily
account runtime and in fact have several ways to do so.
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra  wrote:

> On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 15:29:32 +0300
> > Felipe Balbi  wrote:
> > 
> > > hi,
> > > 
> > > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > > >And if you have two kernels, one with which your device is dead after 1
> > > >hour and one with which your device is dead after 10 hours. Which would
> > > >you prefer? I mean really... this is ridiculous.
> > > 
> > > What I find ridiculous is the assumption that kernel should provide good 
> > > power management even for badly written applications. They should work, 
> > > of course, but there's no assumption that the kernel should cope with 
> > > those applications and provide good battery usage on those cases.
> > > 
> > > You can install and run anything on the device, and they will work as 
> > > they should (they will be scheduled and will be processed) but you can't 
> > > expect the kernel to prevent that application from waking up the CPU 
> > > every 10 ms simply because someone didn't think straight while writting 
> > > the app.
> > > 
> > 
> > But then someone at the user side has to know what he is doing. 
> > 
> > I fear, if you target mass market without central distribution
> > channels, you can not assume that much.
> 
> Provide the developers and users with tools. 
> 
> Notify the users that their phone is using power at an unadvised rate
> due to proglet $foo.
> 
> Also, if you can integrate into the development environment and provide
> developers instant feedback on suckage of their app they can react and
> fix before letting users run into the issue.
> 

Yeah. And I personally agree with you there. But this is a policy
decision that should not prevent android from doing it differently.
The kernel can not win if it does not try to integrate any use of it.
After all, we are a free comunity and if someone wants to use it their
way, why not allow for it? (As long as it does not directly impact other
uses)

The best solution wins, but not by decision of some kernel
development gatekeepers, but because it is superior. There are no clear
markings of the better solution. Time will tell.

Cheers,
Flo


--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 2:24 PM, Florian Mickler  wrote:

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
>
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous.

You almost always need to "hack" the mainline software for a
production system. So do it here as well. Make sure the hack is well
isolated and local. You can even submit it to the mainline, better as
a configuration option, _unless_ it is a *framework* that provokes
writing code in an ugly and unsafe way.

~Vitaly
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi  wrote:

> Hi,
> 
> On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
> >But then someone at the user side has to know what he is doing.
> >
> >I fear, if you target mass market without central distribution
> >channels, you can not assume that much.
> 
> and that's enough to push hacks into the kernel ? I don't think so. Do 
> it like apple and prevent multi-tasking for any non-apple applications 
> :-p
> 
:) 

It really comes down to a policy decision by the distribution maker.
And I don't think kernel upstream should be the one to force one way or
the other. So merging this patch set will allow android to continue
their work _on mainline_ while everybody else can continue as before.

All points about the impact on the kernel have already been raised. So
you should be happy there. 

Nonetheless, I really think the kernel needs to allow for the android
way of power saving. It misses out on a big feature and a big user-base
if not.

Also I expect there to be synergies between android development and
mainline kernel development _only_ if android development can use
mainline kernel.

And as for the quality of the "hack": I think you find this ugly, just
because you don't like the concept of degrading user space guaranties on
timers and stuff. 

But look at it this way: Suspend blockers are a way for the kernel
to make user space programs accountable for using the resource "power".
If a user space program needs the "traditional" guaranties for
functioning properly, it needs to take a suspend blocker. But _THEN_ it
better be well behaved. This is a kind of contract between userspace
and kernelspace.

On the other hand, if I don't need these traditional guaranties on
timers and stuff, I don't have to know device specific things about
power consumption. I can just use whatever facilities the programming
language provides without needing to worry about low level details.

This is a _big_ plus for attracting 3rd party programs. (And of course
the thing you don't like). 

Cheers,
Flo




--
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 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 13:35 +0100, Alan Cox wrote:

> This is an area where machines are improving and where the ability to
> do stuff like autosuspend, the technology like the OLPC screen and so on
> create an incentive for the BIOS and platform people to improve their
> bits of it.

But do you think its a sensible thing to do? Explicitly not running
runnable tasks just sounds wrong. Also, at the extreme end, super fast
suspend is basically an efficient idle mode.

Why would the code holding suspend blockers be any more or less
important than any other piece of runnable code.

In fact, having runnable but non suspend blocking tasks around will
delay the completion of the suspend blocker, so will we start removing
those?

This whole thing introduces an artificial segregation of code. My 'cool'
code is more important than your 'uncool' code. Without a clear
definition of what makes code cool or not.

> > So yes, I do think merging this will delay the effort in fixing
> > userspace, simply because all the mobile/embedded folks don't care about
> > it anymore.
> 
> The mobile space probably doesn't care too much about many of the large
> bloated desktop apps anyway and traditional embedded generally has a very
> small fixed application set where the optimise both halves of the system
> together.

Sure, but at least we share the kernel. It was said that the kernel
generates too many wakeups (and iwlagn certainly is the top most waker
on my laptop). Improvements to the kernel will benefit all, regardless
of whatever userspace we run.


--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 15:29:32 +0300
> Felipe Balbi  wrote:
> 
> > hi,
> > 
> > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > >And if you have two kernels, one with which your device is dead after 1
> > >hour and one with which your device is dead after 10 hours. Which would
> > >you prefer? I mean really... this is ridiculous.
> > 
> > What I find ridiculous is the assumption that kernel should provide good 
> > power management even for badly written applications. They should work, 
> > of course, but there's no assumption that the kernel should cope with 
> > those applications and provide good battery usage on those cases.
> > 
> > You can install and run anything on the device, and they will work as 
> > they should (they will be scheduled and will be processed) but you can't 
> > expect the kernel to prevent that application from waking up the CPU 
> > every 10 ms simply because someone didn't think straight while writting 
> > the app.
> > 
> 
> But then someone at the user side has to know what he is doing. 
> 
> I fear, if you target mass market without central distribution
> channels, you can not assume that much.

Provide the developers and users with tools. 

Notify the users that their phone is using power at an unadvised rate
due to proglet $foo.

Also, if you can integrate into the development environment and provide
developers instant feedback on suckage of their app they can react and
fix before letting users run into the issue.


--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution
channels, you can not assume that much.


and that's enough to push hacks into the kernel ? I don't think so. Do 
it like apple and prevent multi-tasking for any non-apple applications 
:-p


--
balbi

DefectiveByDesign.org
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi  wrote:

> hi,
> 
> On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> >And if you have two kernels, one with which your device is dead after 1
> >hour and one with which your device is dead after 10 hours. Which would
> >you prefer? I mean really... this is ridiculous.
> 
> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.
> 
> You can install and run anything on the device, and they will work as 
> they should (they will be scheduled and will be processed) but you can't 
> expect the kernel to prevent that application from waking up the CPU 
> every 10 ms simply because someone didn't think straight while writting 
> the app.
> 

But then someone at the user side has to know what he is doing. 

I fear, if you target mass market without central distribution
channels, you can not assume that much.

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

hi,

On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:

And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
you prefer? I mean really... this is ridiculous.


What I find ridiculous is the assumption that kernel should provide good 
power management even for badly written applications. They should work, 
of course, but there's no assumption that the kernel should cope with 
those applications and provide good battery usage on those cases.


You can install and run anything on the device, and they will work as 
they should (they will be scheduled and will be processed) but you can't 
expect the kernel to prevent that application from waking up the CPU 
every 10 ms simply because someone didn't think straight while writting 
the app.


--
balbi

DefectiveByDesign.org
--
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 0/8] Suspend block api (version 8)

[Alan Cox]

> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
> near fast enough for this to be usable.

Yet...

> My laptop still takes several seconds to suspend (Lenovo T500), and
> resume (aside from some userspace bustage) takes the same amount of
> time. That is quick enough for manual suspend, but I'd hate it to try
> and auto-suspend.

This is an area where machines are improving and where the ability to
do stuff like autosuspend, the technology like the OLPC screen and so on
create an incentive for the BIOS and platform people to improve their
bits of it.

> So yes, I do think merging this will delay the effort in fixing
> userspace, simply because all the mobile/embedded folks don't care about
> it anymore.

The mobile space probably doesn't care too much about many of the large
bloated desktop apps anyway and traditional embedded generally has a very
small fixed application set where the optimise both halves of the system
together.

Alan
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool  wrote:

> On Wed, May 26, 2010 at 1:37 PM, Florian Mickler  wrote:
> 
> > This is not "protection". This is functioning properly in a real world
> > scenario. Why would the user change the kernel, if the device would be
> > buggy after that? (Except maybe he is a geek)
> 
> Hmm... Why would the user continue to use the program if it slows down
> his device and sucks the battery as a vampire (Except maybe he's a
> moron)? ;)
> 
> ~Vitaly

Because he is using a robust kernel that provides suspend blockers and
is preventing the vampire from sucking power? 

Most users don't even grasp the simple concept of different "programs".
They just have a device and click here and there and are happy. 

Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)

And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
you prefer? I mean really... this is ridiculous. 

Cheers,
Flo

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

Delay in performing "suspend-to-ram" issued via RT thread (SCHED_FIFO)

[uthappa]

Hello Everyone,

I am currently working with the linux 2.6.29-omap1 kernel. Right now I
am porting a legacy application code that puts the OMAP 5912 host to
sleep. The host wakes up after 4 secs via an RTC interrupt which is
configured to be the wake-up source. Everything seems to be fine running
in a loop. The system wakes up and goes back to sleep in 4 seconds every
time. But I am observing a behavior that I am unable to explain. The
legacy application thread that puts the system to sleep is originally an
RT thread with the scheduling policy (SCHED_FIFO) and priority 5. The
thread runs in a loop. The following bash script mimics the behavior of
this thread exactly (however you will probably need some wake up source
like an RTC interrupt to try it on your side):

## Script start #

#!/bin/bash

NAME_OF_THE_SCRIPT=`basename $0`

SELF_PID=`pidof $NAME_OF_THE_SCRIPT`
/usr/bin/chrt -f -p 5 $SELF_PID

sleep 1

while (true)
do
echo mem > /sys/power/state
usleep 3
done

## Script end ###

With this thread running, I see the following messages looping
repeatedly on the target console screen:

## Console o/p start #

PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.92 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: OMAP16212316 is trying to enter deep sleep...
PM: OMAP16212316 is re-starting from deep sleep...
Restarting tasks ... RTC IRQ cleared
done.
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.90 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: OMAP16212316 is trying to enter deep sleep...
PM: OMAP16212316 is re-starting from deep sleep...
Restarting tasks ... RTC IRQ cleared
done.
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.92 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.99 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: OMAP16212316 is trying to enter deep sleep...
PM: OMAP16212316 is re-starting from deep sleep...
Restarting tasks ... RTC IRQ cleared
done.

## Console o/p end ###

You can observe from the above messages that the elapsed time in
"Freezing" the user processes is in the order of around 0.9 seconds.
Also, (although not evident here) when the message "Restarting
tasks ..." appears it takes around a second for the "done." message to
follow.

Now comes the fun part. When I do not fiddle around with the scheduling
policy and priority of the legacy RT thread and just let it be a normal
user space thread (SCHED_OTHER with priority 20, nice 0) (You can
achieve this in the script that I shared with you all by simply
commenting out the command that says "/usr/bin/chrt -f -p 5 $SELF_PID").
Then there is almost no delay at all during "Freezing" and
"Restarting" (I should probably call this "Thawing") the user space
tasks. That is, I now have the following console o/p:

## Console o/p start #

PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: OMAP16212316 is trying to enter deep sleep...
PM: OMAP16212316 is re-starting from deep sleep...
Restarting tasks ... RTC IRQ cleared
done.
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: OMAP16212316 is trying to enter deep sleep...
PM: OMAP16212316 is re-starting from deep sleep...
Restarting tasks ... RTC IRQ cleared
done.
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: OMAP16212316 is trying to enter deep sleep...
PM: OMAP16212316 is re-starting from deep sleep...
Restarting tasks ... RTC IRQ cleared
done.

## Console o/p end ###

As you can see from the above log that the time elapsed during freeze
is now reported as 0.00 seconds. And I observed here that there is no
time delay between printing "Restarting tasks ..." and "done.".

I am having a tough time searching for an explanation to this behavior.
And I hoping that some of you might have already experienced this
behavior or knows what is happening and can explain this to me.

Many thanks in advance.

Best regards,
Uthappa



Please do not print this email unless it is absolutely necessary. Spread 
environmental awareness.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 1:37 PM, Florian Mickler  wrote:

> This is not "protection". This is functioning properly in a real world
> scenario. Why would the user change the kernel, if the device would be
> buggy after that? (Except maybe he is a geek)

Hmm... Why would the user continue to use the program if it slows down
his device and sucks the battery as a vampire (Except maybe he's a
moron)? ;)

~Vitaly
--
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] ARM:VFPv3:enable {d16-d31} access

[DebBarma, Tarun Kanti]

Russell,

-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] 
Sent: Wednesday, May 26, 2010 12:28 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH] ARM:VFPv3:enable {d16-d31} access

On Tue, May 25, 2010 at 02:39:17PM +0530, DebBarma, Tarun Kanti wrote:
>  #ifdef CONFIG_VFPv3
>   @ d16 - d31 registers
> - .irpdr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
> -1:   mrrcp11, 3, r0, r1, c\dr@ fmrrd r0, r1, d\dr
> + .irpdr,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
> +1:   fmrrd   r0, r1, d\dr

The existing code is correct.

For every fmrrd instruction, there is a corresponding mrrc version which
assembles to exactly the same opcode.

mrrc instructions take:

1. Co-processor number, range 0-15.
2. Opcode number N, range 0-15.
3. Destination register 1, range 0-15.
4. Destination register 2, range 0-15.
5. Co-processor register number R, range 0-15.

For fmrrd encodings, the first 16 registers are encoded using N=1 with
R=0 to 15.  The second 16 registers are encoded using N=3 with R=0 to 15.
Specifying a co-processor register number greater than 15 is illegal,
hence why the 'irp' specifies the numbers 0 to 15.

If we look at the instruction encodings, for MRRC:

 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
|  cond |1 1 0 0 0 1 0 1|  Rn   |  Rm   |CP Num |   N   |   R   |

For FMRRD:

 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
|  cond |1 1 0 0 0 1 0 1|  Rn   |  Rm   |1 0 1 1 0 0 M 1|   R   |

where "M" and "R" together define the register.

As I said above, the existing code is correct.  What problem are you
actually trying to solve here?

##
I have a test case which exercise all VFP general purpose registers by writing 
a known value and reading it back using vfp_put_double() and vfp_get_double() 
APIs.

long long d1=777, d2=0;
int i=31;
for (; i>=0; i--){
vfp_put_double(d1, i);
d2 = vfp_get_double(i);
printk("D%d read=%lld\n",i, (long long)d2);
d2 = 0.0;
}

1) With the existing implementation I am not able to correctly write/read 
{d0-d15} but not the {d16-d31} set

2) With my changes I am able to write/read correctly.

Tarun
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 13:18:51 +0200
Vitaly Wool  wrote:

> On Wed, May 26, 2010 at 12:02 PM, Florian Mickler  wrote:
> 
> >> So why again was this such a great scheme? Go fix your userspace to not
> >> not run when not needed.
> >
> > Hi Peter!
> >
> > This was already mentioned in one of these threads.
> >
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> 
> I don't see this as a valid point. Everyone can run a different kernel
> where nothing will just work. Are you aiming protection against that
> as well?
> 
> ~Vitaly

This is not "protection". This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
buggy after that? (Except maybe he is a geek)

Cheers,
Flo
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

2010/5/26 Arve Hjønnevåg :

> Fixing the actually issue means fixing all user-space code, and
> replacing most x86 hardware. I don't think keeping this feature out of
> the kernel will significantly accelerate this.

But if this feature gets merged, I bet you'll find another 100 reasons
to not fix the actual issue. I wouldn't say so if you haven't provided
the irrelevant points already, like "replacing x86 hardware". You're
trying to merge the approach which makes the bad way of handing things
the easiest way. This shouldn't get in as it is IMO.

~Vitaly
--
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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 12:02 PM, Florian Mickler  wrote:

>> So why again was this such a great scheme? Go fix your userspace to not
>> not run when not needed.
>
> Hi Peter!
>
> This was already mentioned in one of these threads.
>
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.

I don't see this as a valid point. Everyone can run a different kernel
where nothing will just work. Are you aiming protection against that
as well?

~Vitaly
--
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 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote: 
> 2010/5/26 Peter Zijlstra :
> > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
> >> 2010/5/26 Peter Zijlstra :
> >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
> >> >
> >> >> and on systems where the
> >> >> same power state can be used from idle and suspend, we use suspend so
> >> >> we can stay in the low power state for minutes to hours instead of
> >> >> milliseconds to seconds.
> >> >
> >> > So don't you think working on making it possible for systems to be idle
> >> > _that_ long would improve things for everybody? as opposed to this
> >> > auto-suspend which only improves matters for those that (can) use it?
> >>
> >> I'm not preventing anyone from working on improving this. Currently
> >> both the kernel and our user-space code polls way too much. I don't
> >> think it is reasonable to demand that no one should run any user-space
> >> code with periodic timers when we have not even fixed the kernel to
> >> not do this.
> >
> > All I'm saying is that merging a stop-gap measure will decrease the
> > urgency and thus the time spend fixing the actual issues while adding
> > the burden of maintaining this stop-gap measure.
> >
> 
> Fixing the actually issue means fixing all user-space code, and
> replacing most x86 hardware. I don't think keeping this feature out of
> the kernel will significantly accelerate this.

I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
near fast enough for this to be usable.

My laptop still takes several seconds to suspend (Lenovo T500), and
resume (aside from some userspace bustage) takes the same amount of
time. That is quick enough for manual suspend, but I'd hate it to try
and auto-suspend.

Getting longer idle periods however is something that everybody benefits
from. On x86 we're nowhere close to hitting the max idle time of the
platform, you get _tons_ of wakeups on current 'desktop' software.

But x86 being a PITA shouldn't stop people from working on this, there's
plenty other architectures out there, I remember fixing a NO_HZ bug with
davem on sparc64 because his niagra had cores idling for very long times
indeed. 

So yes, I do think merging this will delay the effort in fixing
userspace, simply because all the mobile/embedded folks don't care about
it anymore.
--
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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

- Original Message -
From: "Jonathan Cameron"
> On 05/26/10 09:30, Hemanth V wrote:
>>> From: Hemanth V 
>>> Date: Fri, 21 May 2010 15:52:03 +0530
>>> Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
>>>
>>> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>>>
>>> BH1780 supports I2C interface. Driver supports read/update of power state 
>>> and
>>> read of lux value (through SYSFS). Writing value 3 to power_state enables 
>>> the
>>> sensor and current lux value could be read.
>>>
>> Jonathan, Daniel
>>
>> If there are no more comments, do you know howto push this to linus tree.

> It's in misc, so send a copy (with reference back to review thread)
> to Andrew Morton 
>
> Andrew tends to pick things up eventually for lkml, but he'll notice
> it quicker if you cc him in on relevant emails!
>

Andrew,

Could you pull the patch listed in https://patchwork.kernel.org/patch/101860/

This is version 2 of the patch. Review comments and discussion are listed part
of https://patchwork.kernel.org/patch/101396/

Thanks
Hemanth


--
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 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra :
> On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
>> 2010/5/26 Peter Zijlstra :
>> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>> >
>> >> and on systems where the
>> >> same power state can be used from idle and suspend, we use suspend so
>> >> we can stay in the low power state for minutes to hours instead of
>> >> milliseconds to seconds.
>> >
>> > So don't you think working on making it possible for systems to be idle
>> > _that_ long would improve things for everybody? as opposed to this
>> > auto-suspend which only improves matters for those that (can) use it?
>>
>> I'm not preventing anyone from working on improving this. Currently
>> both the kernel and our user-space code polls way too much. I don't
>> think it is reasonable to demand that no one should run any user-space
>> code with periodic timers when we have not even fixed the kernel to
>> not do this.
>
> All I'm saying is that merging a stop-gap measure will decrease the
> urgency and thus the time spend fixing the actual issues while adding
> the burden of maintaining this stop-gap measure.
>

Fixing the actually issue means fixing all user-space code, and
replacing most x86 hardware. I don't think keeping this feature out of
the kernel will significantly accelerate this.

-- 
Arve Hjønnevå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 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
> 2010/5/26 Peter Zijlstra :
> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
> >
> >> and on systems where the
> >> same power state can be used from idle and suspend, we use suspend so
> >> we can stay in the low power state for minutes to hours instead of
> >> milliseconds to seconds.
> >
> > So don't you think working on making it possible for systems to be idle
> > _that_ long would improve things for everybody? as opposed to this
> > auto-suspend which only improves matters for those that (can) use it?
> 
> I'm not preventing anyone from working on improving this. Currently
> both the kernel and our user-space code polls way too much. I don't
> think it is reasonable to demand that no one should run any user-space
> code with periodic timers when we have not even fixed the kernel to
> not do this.

All I'm saying is that merging a stop-gap measure will decrease the
urgency and thus the time spend fixing the actual issues while adding
the burden of maintaining this stop-gap measure.
--
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 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra :
> On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>
>> and on systems where the
>> same power state can be used from idle and suspend, we use suspend so
>> we can stay in the low power state for minutes to hours instead of
>> milliseconds to seconds.
>
> So don't you think working on making it possible for systems to be idle
> _that_ long would improve things for everybody? as opposed to this
> auto-suspend which only improves matters for those that (can) use it?

I'm not preventing anyone from working on improving this. Currently
both the kernel and our user-space code polls way too much. I don't
think it is reasonable to demand that no one should run any user-space
code with periodic timers when we have not even fixed the kernel to
not do this.

-- 
Arve Hjønnevå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 0/8] Suspend block api (version 8)

[Brian Swetland]

On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra  wrote:
> On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>
>> and on systems where the
>> same power state can be used from idle and suspend, we use suspend so
>> we can stay in the low power state for minutes to hours instead of
>> milliseconds to seconds.
>
> So don't you think working on making it possible for systems to be idle
> _that_ long would improve things for everybody? as opposed to this
> auto-suspend which only improves matters for those that (can) use it?

As we've stated a number of times in the several weeks of discussion
(this time around) of this patchset, we are all in favor of improving
runtime pm, finding and resolving issues that prevent idle, and
heading toward ever lower power states in idle -- after all, this
benefits our battery life in the cases when the system is not
suspended as well as moving us closer to a future where the power
savings between actively entering suspend and not doing so approach
zero.  Aggressively entering the lowest possible power state at all
times is our goal here.

At the moment, the power savings from opportunistic suspend do
directly lead to improved battery life, and there are some advantages
to this model in the face of a non-optimal userspace (as we encounter
in a world where there are not restrictions on what applications users
may install and run).

Brian
--
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 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:

> and on systems where the
> same power state can be used from idle and suspend, we use suspend so
> we can stay in the low power state for minutes to hours instead of
> milliseconds to seconds.

So don't you think working on making it possible for systems to be idle
_that_ long would improve things for everybody? as opposed to this
auto-suspend which only improves matters for those that (can) use it?


--
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 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra :
> On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
>
>> I was not talking about our user-space code. Suspend has to be called
>> by a running thread, so at least one runqueue is not empty.
>
> But why would you need to suspend if the machine is fully idle?
>

I have never seen a system that is fully idle for hours or even minutes.

> Is it because you're using broken hardware that has lower power
> consumption in suspend state as in idle?
>

Initially, yes, but for shipping android phones, no.

> Couldn't you make the runtime-pm smarter and utilize the suspend states?
>

I don't think runtime-pm is relevant here. We don't use suspend to
power down devices that are not in use, we use suspend to enter system
power states that we cannot enter from idle, and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds.

-- 
Arve Hjønnevå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 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 12:08:04 +0200
Peter Zijlstra  wrote:

> On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> > 
> > So anything relying on (all) userspace solves a different problem.
> 
> So what stops an application from grabbing a suspend blocker?

Well, I don't own any android devices, but  If I read this all
correctly, an app can request the permission to grab an suspend blocker
at installation time. ("This application is requesting permission to
keep the device from sleeping, thus possibly reducing your battery
time. Are you shure you want to continue? [Yes,No]")

every app grabbing a suspend blocker is showing
up in a "these programs stop suspend" kind of battery-app and are thus
well accounted for. _And the user knows who to blame_.

Maybe this is implemented via fs-permissions? Anyway, I'm shure,
that the access control uses a well established method. :)  

Cheers,
Flo
--
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 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:

> I was not talking about our user-space code. Suspend has to be called
> by a running thread, so at least one runqueue is not empty.

But why would you need to suspend if the machine is fully idle?

Is it because you're using broken hardware that has lower power
consumption in suspend state as in idle?

Couldn't you make the runtime-pm smarter and utilize the suspend states?
--
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 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.
> 
> So anything relying on (all) userspace solves a different problem.

So what stops an application from grabbing a suspend blocker?
--
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 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

2010/5/26 Peter Zijlstra :
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
>> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra  wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend blockers into any
>> >> > drivers/subsystems considered "useful", which by looking through current
>> >> > Android kernels is many of them.
>> >>
>> >> That depends on the maintainers of these subsystems, who still have the 
>> >> power
>> >> to reject requested changes.
>> >
>> > So as a scheduler maintainer I'm going to merge a patch that does a
>> > suspend_blocker when the runqueue's aren't empty... how about that?
>> >
>>
>> I don't know if you are serious, since the all the runqueues are never
>> empty while suspending, this would disable opportunistic suspend
>> altogether.
>
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.
>

I was not talking about our user-space code. Suspend has to be called
by a running thread, so at least one runqueue is not empty.

-- 
Arve Hjønnevå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 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra  wrote:

> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> > On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra  
> > wrote:
> > > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > >> > This of course will lead to a scattering of suspend blockers into any
> > >> > drivers/subsystems considered "useful", which by looking through 
> > >> > current
> > >> > Android kernels is many of them.
> > >>
> > >> That depends on the maintainers of these subsystems, who still have the 
> > >> power
> > >> to reject requested changes.
> > >
> > > So as a scheduler maintainer I'm going to merge a patch that does a
> > > suspend_blocker when the runqueue's aren't empty... how about that?
> > >
> > 
> > I don't know if you are serious, since the all the runqueues are never
> > empty while suspending, this would disable opportunistic suspend
> > altogether.
> 
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.

Hi Peter!

This was already mentioned in one of these threads. 

The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system, without an app-store or the like. Everyone can run what he
wants.

So anything relying on (all) userspace solves a different problem.

Cheers,
Flo




> --
> 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
> 
--
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 v2 2/7] DSPBRIDGE: maintain mapping and page info

[Ohad Ben-Cohen]

On Mon, May 24, 2010 at 7:05 PM, Ohad Ben-Cohen  wrote:
> Every time the MM application calls proc_map to map
> a memory area, remember the details of that mapping,
> together with the related page structures.
> Whenever a buffer is unmapped, clean up the mapping
> information resources.
> This information is maintained as part of the
> DMM resource tracking mechanism.
>
> Signed-off-by: Ohad Ben-Cohen 
> ---
> If you want, you can also reach me at <  ohadb at ti dot com  >.
>
>  arch/arm/plat-omap/include/dspbridge/dspdefs.h |    3 +-
>  drivers/dsp/bridge/core/io_sm.c                |   11 ++-
>  drivers/dsp/bridge/core/tiomap3430.c           |    9 ++-
>  drivers/dsp/bridge/rmgr/proc.c                 |  125 
> ++--
>  4 files changed, 113 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/dspbridge/dspdefs.h 
> b/arch/arm/plat-omap/include/dspbridge/dspdefs.h
> index 3dfe406..f09bdbd 100644
> --- a/arch/arm/plat-omap/include/dspbridge/dspdefs.h
> +++ b/arch/arm/plat-omap/include/dspbridge/dspdefs.h
> @@ -182,7 +182,8 @@ typedef dsp_status(*fxn_brd_memwrite) (struct 
> bridge_dev_context
>  typedef dsp_status(*fxn_brd_memmap) (struct bridge_dev_context
>                                     * hDevContext, u32 ul_mpu_addr,
>                                     u32 ulVirtAddr, u32 ul_num_bytes,
> -                                    u32 ulMapAttrs);
> +                                    u32 ulMapAttrs,
> +                                    struct page **mapped_pages);
>
>  /*
>  *   bridge_brd_mem_un_map 
> diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
> index d6c1a98..7fda364 100644
> --- a/drivers/dsp/bridge/core/io_sm.c
> +++ b/drivers/dsp/bridge/core/io_sm.c
> @@ -503,7 +503,8 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr)
>                                    hio_mgr->intf_fxns->
>                                    pfn_brd_mem_map(hio_mgr->hbridge_context,
>                                                    pa_curr, va_curr,
> -                                                   page_size[i], map_attrs);
> +                                                   page_size[i], map_attrs,
> +                                                   NULL);
>                                if (DSP_FAILED(status))
>                                        goto func_end;
>                                pa_curr += page_size[i];
> @@ -568,7 +569,8 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr)
>                                    hio_mgr->intf_fxns->
>                                    pfn_brd_mem_map(hio_mgr->hbridge_context,
>                                                    pa_curr, va_curr,
> -                                                   page_size[i], map_attrs);
> +                                                   page_size[i], map_attrs,
> +                                                   NULL);
>                                dev_dbg(bridge,
>                                        "shm MMU PTE entry PA %x"
>                                        " VA %x DSP_VA %x Size %x\n",
> @@ -636,7 +638,8 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr)
>                                     hio_mgr->ext_proc_info.ty_tlb[i].
>                                     ul_gpp_phys,
>                                     hio_mgr->ext_proc_info.ty_tlb[i].
> -                                    ul_dsp_virt, 0x10, map_attrs);
> +                                    ul_dsp_virt, 0x10, map_attrs,
> +                                    NULL);
>                        }
>                }
>                if (DSP_FAILED(status))
> @@ -655,7 +658,7 @@ dsp_status bridge_io_on_loaded(struct io_mgr *hio_mgr)
>                status = hio_mgr->intf_fxns->pfn_brd_mem_map
>                    (hio_mgr->hbridge_context, 
> l4_peripheral_table[i].phys_addr,
>                     l4_peripheral_table[i].dsp_virt_addr, HW_PAGE_SIZE4KB,
> -                    map_attrs);
> +                    map_attrs, NULL);
>                if (DSP_FAILED(status))
>                        goto func_end;
>                i++;
> diff --git a/drivers/dsp/bridge/core/tiomap3430.c 
> b/drivers/dsp/bridge/core/tiomap3430.c
> index c7b0d83..e122f04 100644
> --- a/drivers/dsp/bridge/core/tiomap3430.c
> +++ b/drivers/dsp/bridge/core/tiomap3430.c
> @@ -101,7 +101,8 @@ static dsp_status bridge_brd_mem_write(struct 
> bridge_dev_context *dev_context,
>                                    u32 ul_num_bytes, u32 ulMemType);
>  static dsp_status bridge_brd_mem_map(struct bridge_dev_context *hDevContext,
>                                  u32 ul_mpu_addr, u32 ulVirtAddr,
> -                                 u32 ul_num_bytes, u32 ul_map_attr);
> +                                 u32 ul_num_bytes, u32 ul_map_attr,
> +                                 struct page **mapped_pages);
>  static dsp_status bridge_brd_mem_un_map(struct bridge_dev_conte

Re: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra  wrote:
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
>> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra  wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend blockers into any
>> >> > drivers/subsystems considered "useful", which by looking through current
>> >> > Android kernels is many of them.
>> >>
>> >> That depends on the maintainers of these subsystems, who still have the 
>> >> power
>> >> to reject requested changes.
>> >
>> > So as a scheduler maintainer I'm going to merge a patch that does a
>> > suspend_blocker when the runqueue's aren't empty... how about that?
>> >
>>
>> I don't know if you are serious, since the all the runqueues are never
>> empty while suspending, this would disable opportunistic suspend
>> altogether.
>
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.


Thanks for your constructive feedback.

Brian
--
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 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra  wrote:
> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> >> > This of course will lead to a scattering of suspend blockers into any
> >> > drivers/subsystems considered "useful", which by looking through current
> >> > Android kernels is many of them.
> >>
> >> That depends on the maintainers of these subsystems, who still have the 
> >> power
> >> to reject requested changes.
> >
> > So as a scheduler maintainer I'm going to merge a patch that does a
> > suspend_blocker when the runqueue's aren't empty... how about that?
> >
> 
> I don't know if you are serious, since the all the runqueues are never
> empty while suspending, this would disable opportunistic suspend
> altogether.

So why again was this such a great scheme? Go fix your userspace to not
not run when not needed.
--
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 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra  wrote:
> On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> > This of course will lead to a scattering of suspend blockers into any
>> > drivers/subsystems considered "useful", which by looking through current
>> > Android kernels is many of them.
>>
>> That depends on the maintainers of these subsystems, who still have the power
>> to reject requested changes.
>
> So as a scheduler maintainer I'm going to merge a patch that does a
> suspend_blocker when the runqueue's aren't empty... how about that?
>

I don't know if you are serious, since the all the runqueues are never
empty while suspending, this would disable opportunistic suspend
altogether.

-- 
Arve Hjønnevå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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver

[Jonathan Cameron]

On 05/26/10 09:30, Hemanth V wrote:
>> From: Hemanth V 
>> Date: Fri, 21 May 2010 15:52:03 +0530
>> Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
>>
>> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>>
>> BH1780 supports I2C interface. Driver supports read/update of power state and
>> read of lux value (through SYSFS). Writing value 3 to power_state enables the
>> sensor and current lux value could be read.
>>
> Jonathan, Daniel
> 
> If there are no more comments, do you know howto push this to linus tree.
It's in misc, so send a copy (with reference back to review thread)
to Andrew Morton 

Andrew tends to pick things up eventually for lkml, but he'll notice
it quicker if you cc him in on relevant emails!

Jonathan
> 
> Thanks
> Hemanth
> 
>> Signed-off-by: Hemanth V 
>> Reviewed-by: Daniel Mack 
>> Acked-by: Jonathan Cameron 
>> ---
>>  drivers/misc/Kconfig |   10 ++
>>  drivers/misc/Makefile|1 +
>>  drivers/misc/bh1780gli.c |  273 
>> ++
>>  3 files changed, 284 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/misc/bh1780gli.c
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 0d0d625..3f5bf0f 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -278,6 +278,16 @@ config SENSORS_TSL2550
>>This driver can also be built as a module.  If so, the module
>>will be called tsl2550.
>>
>> +config SENSORS_BH1780
>> +tristate "ROHM BH1780GLI ambient light sensor"
>> +depends on I2C && SYSFS
>> +help
>> +  If you say yes here you get support for the ROHM BH1780GLI
>> +  ambient light sensor.
>> +
>> +  This driver can also be built as a module.  If so, the module
>> +  will be called bh1780gli.
>> +
>>  config EP93XX_PWM
>>  tristate "EP93xx PWM support"
>>  depends on ARCH_EP93XX
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index 7b6f7ee..c479d91 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)  += iwmc3200top/
>>  obj-y   += eeprom/
>>  obj-y   += cb710/
>>  obj-$(CONFIG_VMWARE_BALLOON)+= vmware_balloon.o
>> +obj-$(CONFIG_SENSORS_BH1780)+= bh1780gli.o
>> diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
>> new file mode 100644
>> index 000..774531d
>> --- /dev/null
>> +++ b/drivers/misc/bh1780gli.c
>> @@ -0,0 +1,273 @@
>> +/*
>> + * bh1780gli.c
>> + * ROHM Ambient Light Sensor Driver
>> + *
>> + * Copyright (C) 2010 Texas Instruments
>> + * Author: Hemanth V 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but 
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program.  If not, see .
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define BH1780_REG_CONTROL  0x80
>> +#define BH1780_REG_PARTID   0x8A
>> +#define BH1780_REG_MANFID   0x8B
>> +#define BH1780_REG_DLOW 0x8C
>> +#define BH1780_REG_DHIGH0x8D
>> +
>> +#define BH1780_REVMASK  (0xf)
>> +#define BH1780_POWMASK  (0x3)
>> +#define BH1780_POFF (0x0)
>> +#define BH1780_PON  (0x3)
>> +
>> +/* power on settling time in ms */
>> +#define BH1780_PON_DELAY2
>> +
>> +struct bh1780_data {
>> +struct i2c_client *client;
>> +int power_state;
>> +/* lock for sysfs operations */
>> +struct mutex lock;
>> +};
>> +
>> +static int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char 
>> *msg)
>> +{
>> +int ret = i2c_smbus_write_byte_data(ddata->client, reg, val);
>> +if (ret < 0)
>> +dev_err(&ddata->client->dev,
>> +"i2c_smbus_write_byte_data failed error %d\
>> +Register (%s)\n", ret, msg);
>> +return ret;
>> +}
>> +
>> +static int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
>> +{
>> +int ret = i2c_smbus_read_byte_data(ddata->client, reg);
>> +if (ret < 0)
>> +dev_err(&ddata->client->dev,
>> +"i2c_smbus_read_byte_data failed error %d\
>> + Register (%s)\n", ret, msg);
>> +return ret;
>> +}
>> +
>> +static ssize_t bh1780_show_lux(struct device *dev,
>> +struct device_attribute *attr, char *buf)
>> +{
>> +struct platform_device *pdev = to_platform_device(dev);
>> +struct bh1780_data *ddata = platform_get_drvd

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > This of course will lead to a scattering of suspend blockers into any
> > drivers/subsystems considered "useful", which by looking through current
> > Android kernels is many of them.
> 
> That depends on the maintainers of these subsystems, who still have the power
> to reject requested changes. 

So as a scheduler maintainer I'm going to merge a patch that does a
suspend_blocker when the runqueue's aren't empty... how about that?
--
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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver

[Hemanth V]

> From: Hemanth V 
> Date: Fri, 21 May 2010 15:52:03 +0530
> Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
>
> This patch adds support for ROHM BH1780GLI Ambient light sensor.
>
> BH1780 supports I2C interface. Driver supports read/update of power state and
> read of lux value (through SYSFS). Writing value 3 to power_state enables the
> sensor and current lux value could be read.
>
Jonathan, Daniel

If there are no more comments, do you know howto push this to linus tree.

Thanks
Hemanth

> Signed-off-by: Hemanth V 
> Reviewed-by: Daniel Mack 
> Acked-by: Jonathan Cameron 
> ---
>  drivers/misc/Kconfig |   10 ++
>  drivers/misc/Makefile|1 +
>  drivers/misc/bh1780gli.c |  273 
> ++
>  3 files changed, 284 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/misc/bh1780gli.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 0d0d625..3f5bf0f 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -278,6 +278,16 @@ config SENSORS_TSL2550
> This driver can also be built as a module.  If so, the module
> will be called tsl2550.
>
> +config SENSORS_BH1780
> + tristate "ROHM BH1780GLI ambient light sensor"
> + depends on I2C && SYSFS
> + help
> +   If you say yes here you get support for the ROHM BH1780GLI
> +   ambient light sensor.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called bh1780gli.
> +
>  config EP93XX_PWM
>   tristate "EP93xx PWM support"
>   depends on ARCH_EP93XX
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 7b6f7ee..c479d91 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)  += iwmc3200top/
>  obj-y+= eeprom/
>  obj-y+= cb710/
>  obj-$(CONFIG_VMWARE_BALLOON) += vmware_balloon.o
> +obj-$(CONFIG_SENSORS_BH1780) += bh1780gli.o
> diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
> new file mode 100644
> index 000..774531d
> --- /dev/null
> +++ b/drivers/misc/bh1780gli.c
> @@ -0,0 +1,273 @@
> +/*
> + * bh1780gli.c
> + * ROHM Ambient Light Sensor Driver
> + *
> + * Copyright (C) 2010 Texas Instruments
> + * Author: Hemanth V 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BH1780_REG_CONTROL   0x80
> +#define BH1780_REG_PARTID0x8A
> +#define BH1780_REG_MANFID0x8B
> +#define BH1780_REG_DLOW  0x8C
> +#define BH1780_REG_DHIGH 0x8D
> +
> +#define BH1780_REVMASK   (0xf)
> +#define BH1780_POWMASK   (0x3)
> +#define BH1780_POFF  (0x0)
> +#define BH1780_PON   (0x3)
> +
> +/* power on settling time in ms */
> +#define BH1780_PON_DELAY 2
> +
> +struct bh1780_data {
> + struct i2c_client *client;
> + int power_state;
> + /* lock for sysfs operations */
> + struct mutex lock;
> +};
> +
> +static int bh1780_write(struct bh1780_data *ddata, u8 reg, u8 val, char *msg)
> +{
> + int ret = i2c_smbus_write_byte_data(ddata->client, reg, val);
> + if (ret < 0)
> + dev_err(&ddata->client->dev,
> + "i2c_smbus_write_byte_data failed error %d\
> + Register (%s)\n", ret, msg);
> + return ret;
> +}
> +
> +static int bh1780_read(struct bh1780_data *ddata, u8 reg, char *msg)
> +{
> + int ret = i2c_smbus_read_byte_data(ddata->client, reg);
> + if (ret < 0)
> + dev_err(&ddata->client->dev,
> + "i2c_smbus_read_byte_data failed error %d\
> +  Register (%s)\n", ret, msg);
> + return ret;
> +}
> +
> +static ssize_t bh1780_show_lux(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct bh1780_data *ddata = platform_get_drvdata(pdev);
> + int lsb, msb;
> +
> + lsb = bh1780_read(ddata, BH1780_REG_DLOW, "DLOW");
> + if (lsb < 0)
> + return lsb;
> +
> + msb = bh1780_read(ddata, BH1780_REG_DHIGH, "DHIGH");
> + if (msb < 0)
> + return msb;
> +
> + return sprintf(buf, "%d\n", (msb << 8) | lsb);
> +}
> +
> +static ssize_t bh1780_show_power_state(st

omapfb problem (omapfb: irq error status 4020)

[Sudipta GHOSH]

Hi,

I have taken latest Linux Kernel for beagle board (C3).

I tried my image in that board.

But getting omapfb error.

DISPC version 3.0 initialized
omapfb: irq error status 4020
...

I feel this is known issue.

Could you please reply whats need to be done.

Regards,
-S
--
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: [RFC] Initial attempt to make ARM use LMB

[Russell King - ARM Linux]

On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote:
> > So, below is a patch to sanitize the code in arch/arm/plat-omap/fb.c.
> > The logic in this file is rather convoluted, but essentially:
> 
> I've tried the patch below with the patches from your lmb branch
> up to this one and I can see tux on my osk5912 and n900:
> 
> Acked-by: Tony Lindgren 

Interesting patch name!

> After applying the next patch in your lmb branch "ARM: OMAP: Convert
> to use ->reserve method to reserve boot time memory" tux still works
> on 5912osk, but not on n900. The difference is that osk5912 uses
> the old omapfb code.

I guess this is because I don't have board-n900.c in my tree.  All OMAP
boards need a ".reserve = omap_reserve," line added in their machine
descriptor.

I just noticed that board-n8x0.c contains more than one machine descriptor,
which I've now fixed up.

> Then, looks like reordering of the patches now causes patch
> "ARM: initial LMB trial" to fail with:
> 
> arch/arm/mm/init.c:301: error: conflicting types for 'bootmem_init'
> arch/arm/mm/mm.h:32: error: previous declaration of 'bootmem_init' was here
> arch/arm/mm/init.c: In function 'bootmem_init':
> arch/arm/mm/init.c:312: error: 'mdesc' undeclared (first use in this function)
> arch/arm/mm/init.c:312: error: (Each undeclared identifier is reported only 
> once
> arch/arm/mm/init.c:312: error: for each function it appears in.)
> make[1]: *** [arch/arm/mm/init.o] Error 1

Now fixed, thanks.

> Also, the last patch in lmb branch "ARM: use LMB to allocate system
> memory MMIO resource structures" causes both osk5912 and n900
> to hang very early. Maybe I'm missing some patch again..

Hmm, I'll take a look later today.

> Anyways, I've picked the patches from lmb branch up to the one below
> into omap-testing. Will add more of them once we get them working.

You should now be able to pick all but the last patch.
--
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

[PATCHv3 3/3] omap: rx51: Add supply and data for the tpa6130a2 headphone amplifier

[Jarkko Nikula]

With these and upcoming change to tpa6130a2 driver it's possible to add
support for the TPA6130A2 headphone amplifier.

Signed-off-by: Jarkko Nikula 
---
v3:
- No functional changes. Rebased on top of 1/3.

v2:
- Rebased on top of 7b93a0d
- Only Vdd supply added as the CPVSS turned out to be miss defined in
  tpa6130a2. Thanks to Eduardo Valentin  for
  noticing.
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 0f9d2e9..87e00b8 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 
 #include "mux.h"
 #include "hsmmc.h"
@@ -315,6 +316,8 @@ static struct regulator_consumer_supply 
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY("AVDD", "2-0018"),
REGULATOR_SUPPLY("DRVDD", "2-0018"),
+   /* tpa6130a2 */
+   REGULATOR_SUPPLY("Vdd", "2-0060"),
/* Keep vmmc as last item. It is not iterated for newer boards */
REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.1"),
 };
@@ -692,6 +695,11 @@ static struct aic3x_pdata rx51_aic3x_data __initdata = {
.gpio_reset = 60,
 };
 
+static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
+   .id = TPA6130A2,
+   .power_gpio = 98,
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[] = {
{
I2C_BOARD_INFO("twl5030", 0x48),
@@ -706,6 +714,10 @@ static struct i2c_board_info __initdata 
rx51_peripherals_i2c_board_info_2[] = {
I2C_BOARD_INFO("tlv320aic3x", 0x18),
.platform_data = &rx51_aic3x_data,
},
+   {
+   I2C_BOARD_INFO("tpa6130a2", 0x60),
+   .platform_data = &rx51_tpa6130a2_data,
+   }
 };
 
 static int __init rx51_i2c_init(void)
-- 
1.7.1

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

[PATCHv3 2/3] omap: rx51: Use REGULATOR_SUPPLY macro when initializing regulator consumers

[Jarkko Nikula]

There is REGULATOR_SUPPLY macro available for initializing the struct
regulator_consumer_supply so use it where applicable (all other supplies
than vdds_sdi) as it improves the readability.

Signed-off-by: Jarkko Nikula 
Acked-by: Eduardo Valentin 
---
v3:
No functional changes. Rebased on top of 1/3.

v2:
No functional changes but short description added, rebased on top of 7b93a0d
and added Eduardo's ack to v1.
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   43 ++---
 1 files changed, 11 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 7a604e0..0f9d2e9 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -302,48 +302,27 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{}  /* Terminator */
 };
 
-static struct regulator_consumer_supply rx51_vmmc1_supply = {
-   .supply   = "vmmc",
-   .dev_name = "mmci-omap-hs.0",
-};
+static struct regulator_consumer_supply rx51_vmmc1_supply =
+   REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.0");
 
-static struct regulator_consumer_supply rx51_vaux3_supply = {
-   .supply   = "vmmc",
-   .dev_name = "mmci-omap-hs.1",
-};
+static struct regulator_consumer_supply rx51_vaux3_supply =
+   REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.1");
 
-static struct regulator_consumer_supply rx51_vsim_supply = {
-   .supply   = "vmmc_aux",
-   .dev_name = "mmci-omap-hs.1",
-};
+static struct regulator_consumer_supply rx51_vsim_supply =
+   REGULATOR_SUPPLY("vmmc_aux", "mmci-omap-hs.1");
 
 static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
-   {
-   .supply = "AVDD",
-   .dev_name   = "2-0018",
-   },
-   {
-   .supply = "DRVDD",
-   .dev_name   = "2-0018",
-   },
+   REGULATOR_SUPPLY("AVDD", "2-0018"),
+   REGULATOR_SUPPLY("DRVDD", "2-0018"),
/* Keep vmmc as last item. It is not iterated for newer boards */
-   {
-   .supply = "vmmc",
-   .dev_name   = "mmci-omap-hs.1",
-   },
+   REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.1"),
 };
 
 static struct regulator_consumer_supply rx51_vio_supplies[] = {
/* tlv320aic3x digital supplies */
-   {
-   .supply = "IOVDD",
-   .dev_name   = "2-0018"
-   },
-   {
-   .supply = "DVDD",
-   .dev_name   = "2-0018"
-   },
+   REGULATOR_SUPPLY("IOVDD", "2-0018"),
+   REGULATOR_SUPPLY("DVDD", "2-0018"),
 };
 
 #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
-- 
1.7.1

--
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 1/3] omap: rx51: Add platform_data for tlv320aic3x with reset gpio number

[Jarkko Nikula]

Proper operation of the tlv320aic3x audio codec requires that reset
sequencing is done in pair with supply voltages when using the regulator
framework. Add the codec reset gpio used in Nokia RX51 to tlv320aic3x
data.

Signed-off-by: Jarkko Nikula 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index abdf321..7a604e0 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 
+#include 
+
 #include "mux.h"
 #include "hsmmc.h"
 
@@ -707,6 +709,10 @@ static struct twl4030_platform_data rx51_twldata 
__initdata = {
.vio= &rx51_vio,
 };
 
+static struct aic3x_pdata rx51_aic3x_data __initdata = {
+   .gpio_reset = 60,
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[] = {
{
I2C_BOARD_INFO("twl5030", 0x48),
@@ -719,6 +725,7 @@ static struct i2c_board_info __initdata 
rx51_peripherals_i2c_board_info_1[] = {
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
+   .platform_data = &rx51_aic3x_data,
},
 };
 
-- 
1.7.1

--
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/3] omap: rx51: board-rx51-peripherals.c updates

[Jarkko Nikula]

Hi

There are now required sound/soc/ patches in mainline and linux-omap to get
basic Nokia N900 audio working.

Patch 1/3 is continuation to earlier set, see

http://marc.info/?l=linux-omap&m=127306914008392&w=2

IMO, it should go for 2.6.35 as it's kind of fix for unworking audio due
codec being in unknown reset state.

Patches 2-3/3 are posted earlier but now based on top 1/3 since it has
priority over them.

Patches 2/3/3 are not important for 2.6.35 but they are preparation for 2.6.36
and must hit the mainline before adding headphone support to
sound/soc/omap/rx51.c.


-- 
Jarkko
--
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: [RFC PATCHv2 2/7] OMAP SSI: Introducing OMAP SSI driver

[Carlos Chinea]

On Tue, 2010-05-18 at 16:05 +0200, ext Sebastien Jan wrote:
> On Tuesday 18 May 2010 11:07:20 Carlos Chinea wrote:
> [cut]
> > > > +   val |= __raw_readl(omap_ssi->sys +
> > > > SSI_MPU_ENABLE_REG(port->num, 0)); +   __raw_writel(val,
> > > > omap_ssi->sys +
> > > >  SSI_MPU_ENABLE_REG(port->num, 0)); +
> > > > +   msg->status = HSI_STATUS_COMPLETED;
> > > > +   msg->actual_len = sg_dma_len(msg->sgt.sgl);
> > > > +   spin_unlock(&omap_ssi->lock);
> > > > +}
> > >
> > > Don't you need to check the queue related to this transfer at this point,
> > > to start the potentially next queued transfer on the same channel?
> > > (calling ssi_start_transfer(), like in ssi_pio_complete()?)
> > 
> > No this is done in ssi_pio_complete(). Notice that we do not call the
> > complete callback at any point here. We just arm the pio interrupt for
> > that channel and transfer direction. AFAIK, this is the SW logic
> > expected by the OMAP SSI HW.
> 
> Ok, though I would not expect the interrupt to fire in an Rx scenario as the 
> fifo would have already been emptied by the DMA for this transfer (unless you 
> rely on the next transfer initiated by the peer to make the Rx interrupt fire 
> on this channel?)?

No I do not rely on the next RX transfer. I rely on the fact that the
GDD(DMA) controller does not reset the RX status bit for that channel
when RX transfer is finished.

Br,
-- 
Carlos Chinea 

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