Re: [PATCH] omap_hsmmc: Remove unused state variable

[Tony Lindgren]

* Sergio Aguirre  [100608 23:35]:
> This fixes the following warning:
> 
> drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend':
> drivers/mmc/host/omap_hsmmc.c:2275: warning: unused variable 'state'
> 
> Introduced by commit ID:
> 
>   commit 1a13f8fa76c880be41d6b1e6a2b44404bcbfdf9e
>   Author: Matt Fleming 
>   Date:   Wed May 26 14:42:08 2010 -0700
> 
>   mmc: remove the "state" argument to mmc_suspend_host()
> 
> The unique usage of this var was removed there, and missed
> removing the respective declaration aswell.

This should be sent to linux-mmc list.

Tony

 
> Signed-off-by: Sergio Aguirre 
> ---
>  drivers/mmc/host/omap_hsmmc.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index b032828..d50e917 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2272,7 +2272,6 @@ static int omap_hsmmc_suspend(struct device *dev)
>   int ret = 0;
>   struct platform_device *pdev = to_platform_device(dev);
>   struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
> - pm_message_t state = PMSG_SUSPEND; /* unused by MMC core */
>  
>   if (host && host->suspended)
>   return 0;
> -- 
> 1.6.3.3
> 
--
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: simple sd card performance bug fix on OMAP

[Tony Lindgren]

* Madhusudhan  [100602 20:13]:
> 
> 
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand
> > Sent: Friday, May 28, 2010 2:55 PM
> > To: Stephen Schwarm, CSDP; linux-omap@vger.kernel.org
> > Subject: RE: simple sd card performance bug fix on OMAP
> > 
> > Stephen Schwarm, CSDP wrote:
> > >
> > > I have not had time to make a formal patch for this but I thought it was
> > > significant enough just to send it out.  The problem is on omap systems
> > > that use omap_hsmmc.c to run sd or mmc cards.  If the system you are
> > > using has an 8 wire interface, it will only use a one wire interface to
> > > 4 wire cards (eg, sd class 4 and sd class 6).
> > >
> > > In the file driver/mmc/omap_hsmmc.c in the function omap_hsmmc_probe:
> > > at about line 1739 change:
> > >
> > > if (mmc_slot(host).wires >= 8)
> > > mmc->caps |= MMC_CAP_8_BIT_DATA;
> > > else if (mmc_slot(host).wires >= 4)
> > > mmc->caps |= MMC_CAP_4_BIT_DATA;
> > >
> > > to:
> > >
> > > if (mmc_slot(host).wires >= 8)
> > > mmc->caps |= MMC_CAP_8_BIT_DATA;
> > > if (mmc_slot(host).wires >= 4)
> > > mmc->caps |= w;
> > >
> > > just delete the word "else".  This sets the MMC_CAP_4_BIT_DATA bit on
> > > interfaces that have 8 wire interfaces.
> > >
> > > We have seen a BIG performance improvement on our systems.
> > >
> > 
> > Thanks for reporting this.
> > 
> > A similar patch was posted a while ago and is currently marked as
> > "awaiting upstream", although it looks like it got lost again.
> > 
> > 
> > 
> A revised version of the same patch was posted.
> 
> https://patchwork.kernel.org/patch/93519/
> 
> Tony, Can you please push this?

This needs to get merged via linux-mmc list.

Regards,

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

Re: Timekeeping issue on aggressive suspend/resume

[Suresh Rajashekara]

On Wed, Jun 9, 2010 at 1:22 PM, Thomas Gleixner  wrote:
> Though we could change that conditionally - the default would still be
> the freeze of jiffies and CLOCK_MONOTONIC for historical compability.

If I were to change it only for our implementation, and make all the
user space timers use CLOCK_REALTIME, then could you please point me
in a direction as to what part of the kernel I should be touching to
make that change?

Earlier we faced issue with time that the application sees. It wasn't
getting updated when we suspend and resume the system (where as the
time inside the kernel kept updating) and hence eventually would drift
from the actual time.

for eg, if I use this loop at the command prompt

while date
do
echo mem > /sys/power/state
done

then the date command always displayed the same time, but the prints
from the kernel (I was using the printk time information) was
advancing as expected.

I found a patch at
https://patchwork.kernel.org/patch/50070/

Though this fixed the application time update issue, there are lot of
timers in the application which is still not working right.

Could anyone please point in some direction to find the solution?

Thanks,
Suresh
--
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: [alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes

[Tony Lindgren]

* Peter Ujfalusi  [100602 15:09]:
> On Wednesday 02 June 2010 12:15:22 ext Liam Girdwood wrote:
> > On Wed, 2010-06-02 at 12:05 +0300, Peter Ujfalusi wrote:
> > > Hi,
> > > 
> > > On Tuesday 01 June 2010 14:18:19 Ujfalusi Peter (Nokia-D/Tampere) wrote:
> > > 
> > > ..
> > > 
> > > Liam if you are going to take the series, could you fix the patch names?
> > > I can also resend them if it is easier for you.
> > 
> > Peter, I think it's probably better if you can resend. Can you also
> > append the Acks too.
> > 
> > Tony, do we have your ack too ?
> 
> No problem, I'll wait for Tony's ack, and resend the series.

Hmm, I thought I already acked these.. Anyways, the whole series
looks good to me:

Acked-by: Tony Lindgren 
--
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] omap2 usb-ehci: Add missing dma-mapping.h

[Tony Lindgren]

* Jonathan Cameron  [100607 19:55]:
> Signed-off-by: Jonathan Cameron 
> ---
>  I'm not a user of this code but was browsing the kautobuild logs
>  and saw the igep0020 build error that has been there since
>  24th of May using the defconfig.  Looks like a trivial
>  missing header to me.  I can not verify the resulting
>  build works, but it does build cleanly with this patch
>  on mainline as of a few minutes ago.  Sorry for the noise
>  if this has already been addressed but I'm not seeing
>  anything in the linux-o...@vger archive.

Thanks, a similar patch from Amit Kucheria is already queued up:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=bfb01197589965663772e6388f2bdf452e25adf2

Regards,

Tony
 
>  arch/arm/mach-omap2/usb-ehci.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/usb-ehci.c b/arch/arm/mach-omap2/usb-ehci.c
> index c68f799..465699f 100644
> --- a/arch/arm/mach-omap2/usb-ehci.c
> +++ b/arch/arm/mach-omap2/usb-ehci.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> -- 
> 1.6.4.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 2/2]OMAP: Disable internal I2C pull-ups in OMAP3630

[Tony Lindgren]

* Leon Woestenberg  [100609 22:20]:
> Hello Tony,
> 
> On Tue, Jun 8, 2010 at 12:04 PM, Tony Lindgren  wrote:
> > Because of this, 3630 boards should have the mux register pull-ups disabled,
> > and only use the dedicated I2C pull-ups. In theory external pull-ups should
> > not be needed. The value configured for the dedicated I2C pull-ups depends
> > on the connected I2C device, and the number of devices.
> >
> If the internal pull-ups are disabled, why are external pull-ups not needed?

There are two omap internal pull-ups available: The iopad mux pull-ups and the
I2C specific pull-ups. Only the I2C specific ones should be used.

Regards,

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

RE: [RFC] DSS: Movement of base addr, silicon specific data from driver to platform_device

[Hiremath, Vaibhav]

> -Original Message-
> From: Guruswamy, Senthilvadivu
> Sent: Thursday, June 10, 2010 10:49 AM
> To: linux-omap@vger.kernel.org; t...@atomide.com; tomi.valkei...@nokia.com;
> Hiremath, Vaibhav
> Subject: [RFC] DSS: Movement of base addr, silicon specific data from driver
> to platform_device
> 
> Hi,
> 
> This RFC is for making DSS drivers not aware of omap versions and
> omap2,3 specific data like base addr, and irqs.
> DSS base address, irqs, and silicon specific data could be placed in
> platform_device.
> This avoids the base address changes in the dss specific drivers like rfbi,
> dsi, sdi.
> Board specific data shall be continued to be maintained in platform_data.
> More details are inlined in the patch with signature [RFC].
> Please provide your comments on this.
> 
[Hiremath, Vaibhav] Ideally, this is correct way of sharing the resource. I do 
agree that we should take all the platform/device specific resources from 
platform_data.


> Files tentatively to be modified are:
>  arch/arm/mach-omap2/board-3430sdp.c and all omap board files.
>  arch/arm/mach-omap2/devices.c
>  arch/arm/plat-omap/include/plat/display.h
>  drivers/video/omap2/dss/core.c
>  drivers/video/omap2/dss/dispc.c
>  drivers/video/omap2/dss/dsi.c and all other dss driver files.
>  drivers/video/omap2/dss/dss.c
>  drivers/video/omap2/dss/dss.h
> 
> Regards,
> Senthil
> 
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
> omap2/board-3430sdp.c
> index 540d28f..bfdc5f0
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -536,16 +536,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
>   .default_device =   &sdp3430_lcd_device,
>  };
> 
> -static struct platform_device sdp3430_dss_device = {
> - .name   =   "omapdss",
> - .id =   -1,
> - .dev= {
> - .platform_data = &sdp4430_dss_data,
> - },
> -};
> -
>  static struct platform_device *sdp3430_devices[] __initdata = {
> - &sdp3430_dss_device,
>   &sdp3430_keypad_device,
>  };
> @@ -905,6 +896,7 @@ static void __init omap_3430sdp_init(void)
>   platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
>   omap_serial_init();
> + display_init(&sdp3430_dss_data);
> 
> [RFC]  Platform device shall be moved to devices.c for definition and
> registration
> of the dss device in the platform bus.
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 83bd3d6..e481f63
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "mux.h"
> 
> @@ -790,7 +791,103 @@ static inline void omap_hdq_init(void)
>  #else
>  static inline void omap_hdq_init(void) {}
>  #endif
> +/*-
> --*/
> +#ifdef CONFIG_OMAP2_DSS
> +
> +#define OMAP4_DISPC_BASE 0x58001000
> +#define OMAP2_DISPC_BASE 0x48050400
> +#define OMAP3_DSI_BASE   0x4804FC00
> +#define OMAP4_DSI_BASE   0x58004000
> +#define OMAP4_DSI2_BASE  0x58005000
> +#define OMAP2_DSS_BASE   0x4805
> +#define OMAP4_DSS_BASE   0x5800
> +
> +
> [RFC]  Move the Base Address macros from the dss driver files to devices.c
> where
> the platform_device is defined.  These macros get into resource structure.
> The
> resource strucutre would be a part of platform_device.
> 
[Hiremath, Vaibhav] Don't you think this should be part of either omap24xx.h, 
omap34xx.h or omap44xx.h.

> 
> +
> +static struct platform_device omap_display_dev = {
> + .name   = "omapdss",
> + .id = 1,
> + .dev= {
> + .platform_data = NULL, // rename as omapboard_dss_data
> + },
> + .num_resources  = 0,
> + .resource   = NULL,
> +};
> +
> +
> +static struct resource omap2_dss_resources[] = {
> + {
> + .start  = OMAP2_DISPC_BASE,
> + .name   = "dispc",
> + .flags  = IORESOURCE_MEM,
> + },
> + {
> + .start  = OMAP2_DSS_BASE,
> + .name   = "dss",
> + .flags  = IORESOURCE_MEM,
> + },
> +};
> +static struct resource omap3_dss_resources[] = {
> + {
> + .start  = OMAP2_DISPC_BASE,
> + .name   = "dispc",
> + .flags  = IORESOURCE_MEM,
> + },
> + {
> + .start  = OMAP2_DSS_BASE,
> + .name   = "dss",
> + .flags  = IORESOURCE_MEM,
> + },
> + {
> + .start  = OMAP2_DSI_BASE,
> + .name   = "dsi",
> + .flags  = IORESOURCE_MEM,
> + },
> +};
> +static struct resource omap4_dss_resources[] = {

[RFC] DSS: Movement of base addr, silicon specific data from driver to platform_device

[Guruswamy, Senthilvadivu]

Hi,

This RFC is for making DSS drivers not aware of omap versions and 
omap2,3 specific data like base addr, and irqs. 
DSS base address, irqs, and silicon specific data could be placed in 
platform_device.
This avoids the base address changes in the dss specific drivers like rfbi, 
dsi, sdi.
Board specific data shall be continued to be maintained in platform_data.
More details are inlined in the patch with signature [RFC].
Please provide your comments on this.

Files tentatively to be modified are:
 arch/arm/mach-omap2/board-3430sdp.c and all omap board files.
 arch/arm/mach-omap2/devices.c
 arch/arm/plat-omap/include/plat/display.h
 drivers/video/omap2/dss/core.c   
 drivers/video/omap2/dss/dispc.c 
 drivers/video/omap2/dss/dsi.c and all other dss driver files.
 drivers/video/omap2/dss/dss.c   
 drivers/video/omap2/dss/dss.h   

Regards,
Senthil

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 540d28f..bfdc5f0
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -536,16 +536,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device =   &sdp3430_lcd_device,
 };
 
-static struct platform_device sdp3430_dss_device = {
-   .name   =   "omapdss",
-   .id =   -1,
-   .dev= {
-   .platform_data = &sdp4430_dss_data,
-   },
-};
-
 static struct platform_device *sdp3430_devices[] __initdata = {
-   &sdp3430_dss_device,
&sdp3430_keypad_device,
 };
@@ -905,6 +896,7 @@ static void __init omap_3430sdp_init(void)
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
omap_serial_init();
+   display_init(&sdp3430_dss_data);

[RFC]  Platform device shall be moved to devices.c for definition and 
registration
of the dss device in the platform bus.

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 83bd3d6..e481f63
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux.h"
 
@@ -790,7 +791,103 @@ static inline void omap_hdq_init(void)
 #else
 static inline void omap_hdq_init(void) {}
 #endif
+/*---*/
+#ifdef CONFIG_OMAP2_DSS
+
+#define OMAP4_DISPC_BASE   0x58001000
+#define OMAP2_DISPC_BASE   0x48050400
+#define OMAP3_DSI_BASE 0x4804FC00
+#define OMAP4_DSI_BASE 0x58004000
+#define OMAP4_DSI2_BASE0x58005000
+#define OMAP2_DSS_BASE 0x4805
+#define OMAP4_DSS_BASE 0x5800
+
+
[RFC]  Move the Base Address macros from the dss driver files to devices.c where
the platform_device is defined.  These macros get into resource structure.  The
resource strucutre would be a part of platform_device.


+
+static struct platform_device omap_display_dev = {
+   .name   = "omapdss",
+   .id = 1,
+   .dev= {
+   .platform_data = NULL, // rename as omapboard_dss_data
+   },
+   .num_resources  = 0,
+   .resource   = NULL,
+};
+
+
+static struct resource omap2_dss_resources[] = {
+   {
+   .start  = OMAP2_DISPC_BASE,
+   .name   = "dispc",
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP2_DSS_BASE,
+   .name   = "dss",
+   .flags  = IORESOURCE_MEM,
+   },
+};
+static struct resource omap3_dss_resources[] = {
+   {
+   .start  = OMAP2_DISPC_BASE,
+   .name   = "dispc",
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP2_DSS_BASE,
+   .name   = "dss",
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP2_DSI_BASE,
+   .name   = "dsi",
+   .flags  = IORESOURCE_MEM,
+   },
+};
+static struct resource omap4_dss_resources[] = {
+   {
+   .start  = OMAP4_DISPC_BASE,
+   .name   = "dispc",
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP4_DSS_BASE,
+   .name   = "dss",
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP4_DSI_BASE,
+   .name   = "dsi",
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = OMAP4_DSI2_BASE,
+   .name   = "dsi2",
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
 
+void __init disp

Re: [linux-pm] suspend blockers & Android integration

[Neil Brown]

On Wed, 9 Jun 2010 21:51:38 -0700
Arve Hjønnevåg  wrote:

> The current user space interface does not require that clients
> register the file descriptors that they get wakeup events from with
> another process.
> 

However I believe they *do* register these file descriptors with the kernel,
via some sort of ioctl (I think you have said that is the case for input
devices at least).
Can you confirm that?

If that is the case, is it really such a big change to register with another
process instead of with the kernel?

Thanks,
NeilBrown


--
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] suspend blockers & Android integration

[Arve Hjønnevåg]

2010/6/9  :
> On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:
>
>>
>> The power may not see the event, the process that reads the event will
>> always see it. If the power manager is not in the poll call when the
>> event happens, the process that reads the event can read the event
>> before the power manager calls poll.
>>
>
>>
>> All input events that can wake the system are handled by one
>> user-space suspend blocker. Input devices come and go so we would need
>> to add and remove the fds dynamically.
>
>
>>
>> For that to work the wakeup events would have to be reported to the
>> power manager in a reliable way in the first place. Passing the file
>> descriptor that the app uses to the power manager does not work for
>> this, since the app could read the event while the power manager was
>> not in the poll call and the power manager would never see it. Also,
>> existing apps don't pass their file descriptors to the power manager,
>> so it has the get the event from somewhere else.
>>
>
> why could the suspend blocker process see all events, but the power manager
> process not see the events?
>

Because in this proposal the power manager only looks for the events
(on the same queue) when no user space suspend blockers are active.

> have the userspace talk to the power manager the way it does to the suspend
> blocker now and what's the difference?
>
> effectivly think s/suspend blocker/power manager/ (with the power manager
> doing all the other things that are proposed instead of grabbing the
> wakelock), the difference should be hidden to the rest of userspace.
>
> what am I missing here?
>

The current user space interface does not require that clients
register the file descriptors that they get wakeup events from with
another process.

-- 
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: [linux-pm] suspend blockers & Android integration

[david]

On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:



The power may not see the event, the process that reads the event will
always see it. If the power manager is not in the poll call when the
event happens, the process that reads the event can read the event
before the power manager calls poll.





All input events that can wake the system are handled by one
user-space suspend blocker. Input devices come and go so we would need
to add and remove the fds dynamically.





For that to work the wakeup events would have to be reported to the
power manager in a reliable way in the first place. Passing the file
descriptor that the app uses to the power manager does not work for
this, since the app could read the event while the power manager was
not in the poll call and the power manager would never see it. Also,
existing apps don't pass their file descriptors to the power manager,
so it has the get the event from somewhere else.



why could the suspend blocker process see all events, but the power 
manager process not see the events?


have the userspace talk to the power manager the way it does to the 
suspend blocker now and what's the difference?


effectivly think s/suspend blocker/power manager/ (with the power manager 
doing all the other things that are proposed instead of grabbing the 
wakelock), the difference should be hidden to the rest of userspace.


what am I missing here?

David Lang
--
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 09/10] omap: mailbox: convert block api to kfifo

[Ohad Ben-Cohen]

On Wed, Jun 9, 2010 at 12:38 AM, Guzman Lugo, Fernando
 wrote:
>>From: Ohad Ben-Cohen [o...@wizery.com]
>>But now that you point me to this irq on/off thing, it looks a bit
>>broken in terms of multiple concurrent mbox support since it relies on
>>a global rq_full state. I guess it'd be better to hold that rq_full
>>state in the relevant mbox queue state itself.
>
> Yes, you are right Ohad. Only should be disable the "new message" interrupt 
> of the mailbox which kfifo is full.


Great! do you plan to submit a fix to patch 05/10 then ?

Thanks,
Ohad.

>
> regards,
> Fernando.
>
>>
>>Thanks,
>>Ohad.
>
--
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] suspend blockers & Android integration

[Arve Hjønnevåg]

2010/6/9 Alan Stern :
> On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:
>
>> >> Wakeup event occurs, and the driver:
>> >> - report wakeup event type A
>> >> - queue event for delivery to user-space
>> >
>> > That's not really two distinct steps.  Queuing the event for delivery
>> > to userspace involves waking up any tasks that are waiting to read the
>> > device file; that action (calling wake_up_all() or whatever the driver
>> > does) is how the event gets reported.
>> >
>>
>> If you want to ensure that more than one process see the event it has
>> to be two steps, but it does not affect the race I was trying to
>> describe.
>
> Are you sure about that?  If two processes call poll() for the same
> file descriptor, don't both calls return when data becomes available?

Yes if they are both already in the poll call they both return, but if
one process reads the data while the second process is not in the poll
call the second process will not see anything.

> But agreed, it doesn't matter -- especially since I only need one
> process (the power manager) to see the event.

The power may not see the event, the process that reads the event will
always see it. If the power manager is not in the poll call when the
event happens, the process that reads the event can read the event
before the power manager calls poll.

>
>> >> User space wakes up:
>> >> - Calls api to block task freezing for event type A
>> >
>> > Again, that's a confusing way of putting it.  The API you're referring
>> > to is simply the function that activates a suspend blocker.  It does
>> > prevent task freezing, but you shouldn't say it prevents freezing for
>> > event type A.  More like the other way around: In addition to
>> > preventing freezing, the function tells the power manager that event
>> > type A should no longer be considered active.  Thus, in a sense it
>> > _stops_ event type A from preventing freezing.
>> >
>> >> Another wakeup event occurs, and the driver:
>> >> - report wakeup event type A
>
> I think this is where you misunderstood.  There is no "report wakeup
> event" as such.  All that happens is that data becomes available to be
> read from the input device file.  However the power manager process
> isn't polling the device file at this point (because a suspend blocker
> is active), so it doesn't realize that the source has become active
> again.
>

Yes this is not what I though you were suggesting. I thought you were
trying to make sure the power manager sees all wakeup events. If you
are only listening for wakeup events while no suspend blockers are
active, why latch them?

>> >> - queue event for delivery to user-space
>> >
>> > Same as above.
>> >
>> >> User space continues:
>> >> - Read events
>>
>> Sorry, I missed the unblock task freezing step here.
>>
>> >> - Wait for more events
>> >>
>> >> Result: Task are not frozen again.
>> >
>> > Because the suspend blocker was never deactivated.  The same thing
>> > happens with wakelocks: If a task activates a wakelock and never
>> > deactivates it, the system won't go into opportunistic suspend again.
>>
>> Yes, but with the sequence of events above task will not be frozen
>> again even if the wake-lock/suspend-blocker/task-freezing-preventer is
>> released.
>
> Yes they will.  When the suspend blocker is deactivated, the power
> manager process will realize that there are no active suspend blockers
> and it will think there are no active sources.  Thus it will freeze
> processes as usual.
>
>> > Here's how my scheme is meant to work:
>> >
>> >        Wakeup event for input device A occurs.
>> >
>> >        A's driver adds an entry to the input device queue and
>> >        (if the queue was empty) does wake_up_all() on the device
>> >        file's wait_queue.
>> >
>> >        The PM process returns from poll() and sees that device
>> >        file A is now readable, so it adds A to its list of active
>> >        sources and unfreezes userspace.
>> >
>> >        Some other process sees that device file A is now readable,
>> >        so it activates a suspend blocker and reads events from A.
>> >
>> >        When the PM process receives the request to activate the
>> >        suspend blocker, it removes A from its list of active
>> >        sources.  But it doesn't freeze userspace yet, because now
>> >        a suspend blocker is active.
>>
>> If another event happens at this point don't you put A back on the
>> list? If so, it never gets removed.
>
> No, you don't put A back on the list.  Sources get put on the list only
> when the information returned by poll() indicates they have data
> available.  The power manager doesn't poll while suspend blockers are
> active.
>
>> >        The other process consumes events from A and does other
>> >        stuff.  Maybe more input data arrives while this is happening
>> >        and the process reads it.  Eventually the process decides to
>> >        deactivate the suspend blocker, perhaps when no more data
>> >        is available fr

Re: Gumstix Overo non-responsive TTY after resume

[Michael Trimarchi]

Robert Lukassen wrote:

Hi,

I've just started with the linux-omap-pm branch, and are experiencing problems 
with the keyboard when resuming from sleep. There seems to be an earlier post 
on this matter:


4) Suspend to memory (echo mem > /sys/power/state) works now, but when I
wake up the board (via a keypress), I am no longer able to type anything
at the prompt. Any clue about this one?

Indeed, I was able to reproduce this as well and seems to be a new
regression in the PM branch.  I see the same on omap3evm and n900 now
too.mount 


If you enable the UART timeouts + sleep_while_idle, you should avoid
this problem while I try and figure out what's going on:

echo 5 > /sys/devices/platform/serial8250.0/sleep_timeout
echo 5 > /sys/devices/platform/serial8250.1/sleep_timeout
echo 5 > /sys/devices/platform/serial8250.2/sleep_timeout
echo 1 > /debug/pm_debug/sleep_while_idle


I've been following these lines as well, using the kernel from linux-pm-omap 
(tag: b1ce30edb70d1572d314b6a70de257150f5b20d1).
I'm using an Overo Fire (OMAP3530 + OpenGL + Wifi/BT gumstix) on a Tobi board. 
The rootfs is straight from the org.openembedded.com build result.

The lines above do not seem to help. After suspend (echo mem > 
/sys/power/state), the Overo resumes when waking it up with a key press on the 
console. However, after resume, the console does not accept any input from the 
keyboard. I've also experimented with a parallel 'ssh' session via the Ethernet 
connection of the Tobi. After resume, this session is still responsive, albeit 
somewhat sluggish compared to the state before the suspend.

Has there been any development on this issue? I saw the reference to an "OMAP3: 
Serial: improved sleep" thread that mentions an update to the PM branch, but in the 
git log of the linux-omap-pm branch, I do not see a change related to it.

I am also interested in results concerning waking the Overo from suspend using 
a USB device connected to the USB Host port (not the USB OTG port).


I have the same problem using the experimental android 2.6.34 branch. The 
console send garbage to the serial device. I will try tomorrow to investigate a 
little bit more

Michael Trimarchi



Regards,

Robert Lukassen
--
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: [linux-pm] suspend blockers & Android integration

[Neil Brown]

On Wed, 9 Jun 2010 11:40:27 +0200
"Rafael J. Wysocki"  wrote:

> On Wednesday 09 June 2010, Felipe Contreras wrote:
> > On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
> >  wrote:
> > > On Tue, 8 Jun 2010, da...@lang.hm wrote:
> > >>
> > >> having suspend blockers inside the kernel adds significant complexity, 
> > >> it's
> > >> worth it only if the complexity buys you enough. In this case the 
> > >> question is
> > >> if the suspend blockers would extend the sleep time enough more to 
> > >> matter. As
> > >> per my other e-mail, this is an area with rapidly diminishing returns as 
> > >> the
> > >> sleep times get longer.
> > >
> > > Well, the counter-argument that nobody seems to have brought up is that
> > > suspend blockers exist, are real code, and end up being shipped in a lot
> > > of machines.
> > >
> > > That's a _big_ argument in favour of them. Certainly much bigger than
> > > arguing against them based on some complexity-arguments for an alternative
> > > that hasn't seen any testing at all.
> > >
> > > IOW, I would seriously hope that this discussion was more about real code
> > > that _exists_ and does what people need. It seems to have degenerated into
> > > something else.
> > >
> > > Because in the end, "code talks, bullshit walks". People can complain and
> > > suggest alternatives all they want, but you can't just argue. At some
> > > point you need to show the code that actually solves the problem.
> > 
> > That's assuming there is an actual problem, which according to all the
> > embedded people except android, there is not.
> 
> Yes, there is, but they've decided to ignore it.
> 
> > And if there is indeed such a problem (probably not big), it might be
> > solved properly by the time suspend blockers are merged, or few
> > releases after.
> 
> Not quite.  Have you followed all of the discussion, actually?
> 
> > Whatever the solution (or workaround) is, it would be nice if it could
> > be used by more than just android people, and it would also be nice to
> > do it without introducing user-space API that *nobody* likes and might
> > be quickly deprecated.
> 
> I agree with Linus and I don't have that much of a problem with the API that
> people seem to have.  In fact the much-hated user space API is just a char
> device driver with 3 ioctls (that can be extended in future if need be) and
> the kernel API is acceptable to me. 

I think there is a little bit more to it than that.  It seems there is a new
ioctl for input/event devices to say "Any events queued here should be
treated as wake-up events".  There may be similar additions to other devices,
but I know of no details.

I wonder if we can get a complete statement of changes to the user-space
API...

>   Yes, there is some overlap between it
> and PM QoS, but IMhO that overlap may be reduced over time (eg. by
> using PM QoS requirements to implement suspend blockers). 
> 
> To me, the question boils down to whether or not we're able to persuade the
> Android people to use any other approach (eg. by demonstrating that something
> else is actually better), because even if we invent a brilliant new approach,
> but Android ends up using its old one anyway, the net result will be as though
> we haven't done anything useful.

Yes.  There is no point unless we can meet somewhere in the middle.  I think
that would have to include a full suspend that freezes all processes.
Solutions which reject that - while quite clever - would require too much
change to Android user-space to be acceptable.

NeilBrown

> 
> Rafael

--
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: Timekeeping issue on aggressive suspend/resume

[Thomas Gleixner]

On Wed, 9 Jun 2010, Suresh Rajashekara wrote:

> I have an application (running on 2.6.29-omap1) which puts an OMAP1
> system to suspend aggressively. The system wakes up every 4 seconds
> and stays awake for about 35 milliseconds and sleeps again for another
> 4 seconds. This design is to save power on a battery operated device.
> 
> This aggressive suspend resume action seems like creating an issue to
> other applications in the system waiting for some timeout to happen
> (especially an application which is waiting using the mq_timedreceive
> and is supposed to timeout every 30 seconds. It seems to wake up every
> 90 seconds). Seems like the timekeeping is not happening properly in
> side the kernel.
> 
> If the suspend duration is changed from 4 second to 1 second, then
> things work somewhat better. On reducing it to 0.5 second (which was
> our earlier design on 2.6.16-rc3), the problem seems to disappear.
> 
> Is this expected?

Yes, that's caused by the fact that suspend (via sys/power/state )
freezes the kernel internal timers and the user space visible timers
which are based on CLOCK_MONOTONIC or jiffies (like mq_timedreceive on
your .29 kernel). Only CLOCK_REALTIME based timers are kept correct as
we have to align to the wall clock time.

The reason for this is, that otherwise almost all timers are expired
when we resume and we get a thundering herd of apps and kernel
facilities due to firing timeouts.

Another problem is that jiffies can wrap around on 32 bit systems
during a long suspend though I don't think that's a real world problem
as it takes between 49 to 497 days of suspend depending on the HZ
setting. SO for your usecase it would not matter.

I'm more concerned about code getting surprised by firing timers as
the kernel has this behaviour for a long time now.

Though we could change that conditionally - the default would still be
the freeze of jiffies and CLOCK_MONOTONIC for historical compability.

There will be probably some accounting issues. uptime, cpu time of the
suspend task and some others, but that needs to be found out.

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

Timekeeping issue on aggressive suspend/resume

[Suresh Rajashekara]

I have an application (running on 2.6.29-omap1) which puts an OMAP1
system to suspend aggressively. The system wakes up every 4 seconds
and stays awake for about 35 milliseconds and sleeps again for another
4 seconds. This design is to save power on a battery operated device.

This aggressive suspend resume action seems like creating an issue to
other applications in the system waiting for some timeout to happen
(especially an application which is waiting using the mq_timedreceive
and is supposed to timeout every 30 seconds. It seems to wake up every
90 seconds). Seems like the timekeeping is not happening properly in
side the kernel.

If the suspend duration is changed from 4 second to 1 second, then
things work somewhat better. On reducing it to 0.5 second (which was
our earlier design on 2.6.16-rc3), the problem seems to disappear.

Is this expected?

Thanks in advance,

Suresh
--
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 V3 2/2]OMAP: Disable internal I2C pull-ups in OMAP3630

[Leon Woestenberg]

Hello Tony,

On Tue, Jun 8, 2010 at 12:04 PM, Tony Lindgren  wrote:
> Because of this, 3630 boards should have the mux register pull-ups disabled,
> and only use the dedicated I2C pull-ups. In theory external pull-ups should
> not be needed. The value configured for the dedicated I2C pull-ups depends
> on the connected I2C device, and the number of devices.
>
If the internal pull-ups are disabled, why are external pull-ups not needed?

Regards,
-- 
Leon
--
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] suspend blockers & Android integration

[Alan Stern]

On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:

> >> Wakeup event occurs, and the driver:
> >> - report wakeup event type A
> >> - queue event for delivery to user-space
> >
> > That's not really two distinct steps.  Queuing the event for delivery
> > to userspace involves waking up any tasks that are waiting to read the
> > device file; that action (calling wake_up_all() or whatever the driver
> > does) is how the event gets reported.
> >
> 
> If you want to ensure that more than one process see the event it has
> to be two steps, but it does not affect the race I was trying to
> describe.

Are you sure about that?  If two processes call poll() for the same
file descriptor, don't both calls return when data becomes available?  
But agreed, it doesn't matter -- especially since I only need one 
process (the power manager) to see the event.

> >> User space wakes up:
> >> - Calls api to block task freezing for event type A
> >
> > Again, that's a confusing way of putting it.  The API you're referring
> > to is simply the function that activates a suspend blocker.  It does
> > prevent task freezing, but you shouldn't say it prevents freezing for
> > event type A.  More like the other way around: In addition to
> > preventing freezing, the function tells the power manager that event
> > type A should no longer be considered active.  Thus, in a sense it
> > _stops_ event type A from preventing freezing.
> >
> >> Another wakeup event occurs, and the driver:
> >> - report wakeup event type A

I think this is where you misunderstood.  There is no "report wakeup
event" as such.  All that happens is that data becomes available to be
read from the input device file.  However the power manager process
isn't polling the device file at this point (because a suspend blocker
is active), so it doesn't realize that the source has become active
again.

> >> - queue event for delivery to user-space
> >
> > Same as above.
> >
> >> User space continues:
> >> - Read events
> 
> Sorry, I missed the unblock task freezing step here.
> 
> >> - Wait for more events
> >>
> >> Result: Task are not frozen again.
> >
> > Because the suspend blocker was never deactivated.  The same thing
> > happens with wakelocks: If a task activates a wakelock and never
> > deactivates it, the system won't go into opportunistic suspend again.
> 
> Yes, but with the sequence of events above task will not be frozen
> again even if the wake-lock/suspend-blocker/task-freezing-preventer is
> released.

Yes they will.  When the suspend blocker is deactivated, the power 
manager process will realize that there are no active suspend blockers 
and it will think there are no active sources.  Thus it will freeze 
processes as usual.

> > Here's how my scheme is meant to work:
> >
> >        Wakeup event for input device A occurs.
> >
> >        A's driver adds an entry to the input device queue and
> >        (if the queue was empty) does wake_up_all() on the device
> >        file's wait_queue.
> >
> >        The PM process returns from poll() and sees that device
> >        file A is now readable, so it adds A to its list of active
> >        sources and unfreezes userspace.
> >
> >        Some other process sees that device file A is now readable,
> >        so it activates a suspend blocker and reads events from A.
> >
> >        When the PM process receives the request to activate the
> >        suspend blocker, it removes A from its list of active
> >        sources.  But it doesn't freeze userspace yet, because now
> >        a suspend blocker is active.
> 
> If another event happens at this point don't you put A back on the
> list? If so, it never gets removed.

No, you don't put A back on the list.  Sources get put on the list only
when the information returned by poll() indicates they have data
available.  The power manager doesn't poll while suspend blockers are 
active.

> >        The other process consumes events from A and does other
> >        stuff.  Maybe more input data arrives while this is happening
> >        and the process reads it.  Eventually the process decides to
> >        deactivate the suspend blocker, perhaps when no more data
> >        is available from the device file, perhaps not.
> >
> >        When the PM process receives the request to deactivate the
> >        suspend blocker, it sees that now there are no active
> >        sources and no active suspend blockers.  Therefore it
> >        freezes userspace and does a big poll() on all possible
> >        sources.  (If there are still events on the input device
> >        queue, the poll() returns immediately.)
> >
> >        Rinse and repeat.
> >
> > I don't see any dangerous races there.  The scheme can be made a little
> > more efficient by having the PM process do another poll() (with 0
> > timeout) just before freezing userspace; if the result indicates that a
> > source is active then the freezing and unfreezing can be skipped.

> > There is no race.  The driver reports an e

Gumstix Overo non-responsive TTY after resume

[Robert Lukassen]

Hi,

I've just started with the linux-omap-pm branch, and are experiencing problems 
with the keyboard when resuming from sleep. There seems to be an earlier post 
on this matter:

> > 4) Suspend to memory (echo mem > /sys/power/state) works now, but when I
> > wake up the board (via a keypress), I am no longer able to type anything
> > at the prompt. Any clue about this one?
> 
> Indeed, I was able to reproduce this as well and seems to be a new
> regression in the PM branch.  I see the same on omap3evm and n900 now
> too.mount 
> 
> If you enable the UART timeouts + sleep_while_idle, you should avoid
> this problem while I try and figure out what's going on:
> 
> echo 5 > /sys/devices/platform/serial8250.0/sleep_timeout
> echo 5 > /sys/devices/platform/serial8250.1/sleep_timeout
> echo 5 > /sys/devices/platform/serial8250.2/sleep_timeout
> echo 1 > /debug/pm_debug/sleep_while_idle

I've been following these lines as well, using the kernel from linux-pm-omap 
(tag: b1ce30edb70d1572d314b6a70de257150f5b20d1).
I'm using an Overo Fire (OMAP3530 + OpenGL + Wifi/BT gumstix) on a Tobi board. 
The rootfs is straight from the org.openembedded.com build result.

The lines above do not seem to help. After suspend (echo mem > 
/sys/power/state), the Overo resumes when waking it up with a key press on the 
console. However, after resume, the console does not accept any input from the 
keyboard. I've also experimented with a parallel 'ssh' session via the Ethernet 
connection of the Tobi. After resume, this session is still responsive, albeit 
somewhat sluggish compared to the state before the suspend.

Has there been any development on this issue? I saw the reference to an "OMAP3: 
Serial: improved sleep" thread that mentions an update to the PM branch, but in 
the git log of the linux-omap-pm branch, I do not see a change related to it.

I am also interested in results concerning waking the Overo from suspend using 
a USB device connected to the USB Host port (not the USB OTG port).

Regards,

Robert Lukassen
--
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: [pm-wip/uart][PATCH 2/4] OMAP3: serial: Fix uart4 handling for 3630

[Tony Lindgren]

* Govindraj  [100607 17:50]:
> On Mon, Jun 7, 2010 at 5:02 PM, Govindraj  wrote:
> > On Mon, Jun 7, 2010 at 3:36 PM, Tony Lindgren  wrote:
> >> * Kevin Hilman  [100604 18:30]:
> >>>
> >>> > +   w &= ~0x7;
> >>> > +   w |= OMAP_MUX_MODE2;
> >>> > +   omap_ctrl_writew(w, uart->padconf);
> >>
> >> Generic NAK for tinkering with the mux registers directly.
> >>
> >> Instead, Govindraj, please add omap_mux_request_signal() into mux.c:
> >>
> >> void __iomem * __init omap_mux_request_signal(char *muxname);
> 
> Looking into mach-omap2/mux.c
> 
> Wouldn't retrieving offset will be enough as i have to depend on
> again *_mux_* function call for remux which can have the offset and val
> as parameter.

You call omap_mux_request_signal with the signal name, and get
the register address. Then you can just set it with readw/writew.
 
> So I need to use  ""K15_24XX_UART3_TX" as name to retrieve
> UART3 offset if I am correct and traverse through the list doing an strcmp
> on name to retrieve offset.
> 
> In that case I dont find uart1/2/4 in list,
> Should that be added into the list?

No, that's the old mux code. You want to do something like

void __iomem *uart1_rx;

uart1_rx = omap_mux_request_signal("uart1_rx");
if (!uart1_rx)
return -ENODEV;
...

See the signal names in mux34xx.c and the TRM. Then omap2 and omap4
will work automatically once the mux code is ready for those.

Regards,

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

Re: [linux-pm] suspend blockers & Android integration

[Mark Brown]

On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
> On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig  wrote:

> > On the other hand I've heard
> > that various hardware vendors or parties closed to them are rather
> > annoyed by their drivers beeing stuck in the android tree - but that
> > can be easily solved by getting removing the suspend blockers (at least
> > temporarily), cleaning up a few bits here and there and getting them in.

> This continues to baffle me.  If we (Google) are such a headache, why
> not just route around us.  The drivers we've written are GPLv2, the
> source is out there for anyone who wants it, etc.  The drivers other
> people have written we have no control over at all. From my point of
> view it'd be an annoyance if somebody took the code we wrote, modified
> it heavily, and pushed it upstream, but fundamentally I can't stop
> that from happening other than by pushing it upstream myself, first.

AFAICT this is purely down to the fact that the vendors producing
Android devices are using the kernel which is shipped with whatever
release they are using so people doing drivers end up getting locked in
to an older kernel with old APIs (independant of Android specifics) and
don't have the resource to redo things for upstream.  Suspend blockers
are one more API update in there, but general kernel development creates
far more.

I was looking at this just today and one thing that it occurs to me
might help is if when you guys rebase your work against upstream you
were to tag the results - at the minute the only "release" Android
kernels are those included in full stack releases so providing more
hints that other kernel versions could be substituted in may help.
--
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 V3 2/2]OMAP: Disable internal I2C pull-ups in OMAP3630

[Tony Lindgren]

* Woodruff, Richard  [100609 02:24]:
> 
> > Sorry for the delay, here's some more info on this issue. So it looks
> > like starting with 3630 there are dedicated pull-up for all the I2C buses.
> > And the pull values are configurable with software.
> 
> Even 3430 claimed to have this controllable in 
> CONGROL.CONTROL_DEVCONF1[12,13,14]

Hmm OK, that needs to be verified then.

Regards,

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

Re: [GIT PULL] omap iommu: fixes for 2.6.35-rc1

[Tony Lindgren]

* Tony Lindgren  [100608 14:30]:
> * Hiroshi DOYU  [100607 14:45]:
> > >  
> > >> Satish (1):
> > >>   omap iommu: Fix Memory leak
> > > 
> > > This one looks like a genuine fix :)
> > 
> > I've also updated the branch against -rc2. Please merge it if no problem.
> 
> OK, thanks for updating the series.

Well I ended up only cherry picking the memory leak one looking at
Linus' recent comments.. I've moved the two others into for-next
as they might be hard to justify as "regression fixes or
fixes to major bugs (oopses or security etc)". And we really want
to get the compile fixes in without having to wait for those.

Regards,

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

Re: [linux-pm] suspend blockers & Android integration

[Rafael J. Wysocki]

On Wednesday 09 June 2010, Felipe Contreras wrote:
> On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
>  wrote:
> > On Tue, 8 Jun 2010, da...@lang.hm wrote:
> >>
> >> having suspend blockers inside the kernel adds significant complexity, it's
> >> worth it only if the complexity buys you enough. In this case the question 
> >> is
> >> if the suspend blockers would extend the sleep time enough more to matter. 
> >> As
> >> per my other e-mail, this is an area with rapidly diminishing returns as 
> >> the
> >> sleep times get longer.
> >
> > Well, the counter-argument that nobody seems to have brought up is that
> > suspend blockers exist, are real code, and end up being shipped in a lot
> > of machines.
> >
> > That's a _big_ argument in favour of them. Certainly much bigger than
> > arguing against them based on some complexity-arguments for an alternative
> > that hasn't seen any testing at all.
> >
> > IOW, I would seriously hope that this discussion was more about real code
> > that _exists_ and does what people need. It seems to have degenerated into
> > something else.
> >
> > Because in the end, "code talks, bullshit walks". People can complain and
> > suggest alternatives all they want, but you can't just argue. At some
> > point you need to show the code that actually solves the problem.
> 
> That's assuming there is an actual problem, which according to all the
> embedded people except android, there is not.

Yes, there is, but they've decided to ignore it.

> And if there is indeed such a problem (probably not big), it might be
> solved properly by the time suspend blockers are merged, or few
> releases after.

Not quite.  Have you followed all of the discussion, actually?

> Whatever the solution (or workaround) is, it would be nice if it could
> be used by more than just android people, and it would also be nice to
> do it without introducing user-space API that *nobody* likes and might
> be quickly deprecated.

I agree with Linus and I don't have that much of a problem with the API that
people seem to have.  In fact the much-hated user space API is just a char
device driver with 3 ioctls (that can be extended in future if need be) and
the kernel API is acceptable to me.  Yes, there is some overlap between it
and PM QoS, but IMhO that overlap may be reduced over time (eg. by
using PM QoS requirements to implement suspend blockers). 

To me, the question boils down to whether or not we're able to persuade the
Android people to use any other approach (eg. by demonstrating that something
else is actually better), because even if we invent a brilliant new approach,
but Android ends up using its old one anyway, the net result will be as though
we haven't done anything useful.

Rafael
--
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/2] dspbridge: reorganize initialization and probe

[Felipe Contreras]

On Wed, Jun 9, 2010 at 11:49 AM, Ameya Palande  wrote:
> On Wed, 2010-06-09 at 09:25 +0200, ext Felipe Contreras wrote:
>> On Wed, Jun 9, 2010 at 3:48 AM, Omar Ramirez Luna  
>> wrote:
>> > Split the functions to have cleaner error handling paths, this
>> > will aslo cover a case where bridge initialization has failed but
>> > device entry is still available which leads to unknown behavior.
>>
>> Great, I was wondering why this was not the case.
>>
>> Now that you are on this, do you know if there's something missing in
>> order to automatically load the module when somebody tries to open
>> /dev/DspBridge?
>
> I thought /dev/DspBridge will only appear if you load the module ;)

Kind of...
$ sudo touch /dev/DspBridge
See? I have dspbridge on my laptop ;)

I think it's possible to have udev rules that create the file, and
automatically load the module when accessed, but I don't know much
about udev.

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

Re: [PATCH 0/2] dspbridge: reorganize initialization and probe

[Ameya Palande]

On Wed, 2010-06-09 at 09:25 +0200, ext Felipe Contreras wrote:
> On Wed, Jun 9, 2010 at 3:48 AM, Omar Ramirez Luna  wrote:
> > Split the functions to have cleaner error handling paths, this
> > will aslo cover a case where bridge initialization has failed but
> > device entry is still available which leads to unknown behavior.
> 
> Great, I was wondering why this was not the case.
> 
> Now that you are on this, do you know if there's something missing in
> order to automatically load the module when somebody tries to open
> /dev/DspBridge?

I thought /dev/DspBridge will only appear if you load the module ;)

Cheers,
Ameya.



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

On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler  wrote:
> On Sat, 5 Jun 2010 23:06:03 +0300
> Felipe Contreras  wrote:
>> How would such stats be calculated? I presume at regular intervals you
>> check which applications are holding suspend blockers and increase a
>> counter.
>>
>> How would you do that with the dynamic PM approach? At regular
>> intervals you check for which applications are running (not idle).
>
> IIRC, the patches discussed have debugging infrastructure in
> them. The kernel does the accounting.

We are not talking about debugging, we are talking about stats shown
in user-space so that users can see the offending apps. It doesn't
matter where the accounting is done, it would be at regular intervals
and there's nothing that prevents the dynamic PM approach to offer
similar stats.

>> > The only difference is, that with suspend blockers, he can than
>> > dismiss the applications permission to block suspend and will not miss
>> > his job interview the next day because his phones battery run
>> > out. And also he can use the application to a certain extent.
>>
>> So the difference is between removing the app, and making it run
>> crappy. I don't think that's a strong argument in favor of suspend
>> blockers.
>>
> If you think a little about it, it is. Because if the app wouldn't be
> usable at all, the bug wouldn't get fixed because the user wouldn't use
> it. Or not?

I'm not sure what's your point here. One user not using a certain
application doesn't prevent bugs to get fixed. In fact, less people
using an app will cause less buzz, and less downloads, and less
positive votes... which might wake up the author to think: hey, maybe
I'm doing something wrong? Maybe I should really listen to those bug
reports.

Anyway, my point is that there's nothing special about 3rd party app
stats with suspend blockers.

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

Re: [linux-pm] suspend blockers & Android integration

[Felipe Contreras]

On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
 wrote:
> On Tue, 8 Jun 2010, da...@lang.hm wrote:
>>
>> having suspend blockers inside the kernel adds significant complexity, it's
>> worth it only if the complexity buys you enough. In this case the question is
>> if the suspend blockers would extend the sleep time enough more to matter. As
>> per my other e-mail, this is an area with rapidly diminishing returns as the
>> sleep times get longer.
>
> Well, the counter-argument that nobody seems to have brought up is that
> suspend blockers exist, are real code, and end up being shipped in a lot
> of machines.
>
> That's a _big_ argument in favour of them. Certainly much bigger than
> arguing against them based on some complexity-arguments for an alternative
> that hasn't seen any testing at all.
>
> IOW, I would seriously hope that this discussion was more about real code
> that _exists_ and does what people need. It seems to have degenerated into
> something else.
>
> Because in the end, "code talks, bullshit walks". People can complain and
> suggest alternatives all they want, but you can't just argue. At some
> point you need to show the code that actually solves the problem.

That's assuming there is an actual problem, which according to all the
embedded people except android, there is not.

And if there is indeed such a problem (probably not big), it might be
solved properly by the time suspend blockers are merged, or few
releases after.

Whatever the solution (or workaround) is, it would be nice if it could
be used by more than just android people, and it would also be nice to
do it without introducing user-space API that *nobody* likes and might
be quickly deprecated.

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

Re: [PATCH 0/2] dspbridge: reorganize initialization and probe

[Felipe Contreras]

On Wed, Jun 9, 2010 at 3:48 AM, Omar Ramirez Luna  wrote:
> Split the functions to have cleaner error handling paths, this
> will aslo cover a case where bridge initialization has failed but
> device entry is still available which leads to unknown behavior.

Great, I was wondering why this was not the case.

Now that you are on this, do you know if there's something missing in
order to automatically load the module when somebody tries to open
/dev/DspBridge?

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