Re: Delay in performing suspend-to-ram issued via RT thread (SCHED_FIFO)
CCing linux-pm list. On Wed, May 26, 2010 at 9:07 PM, uthappa utha...@mistralsolutions.com 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 that some of you might have already experienced this behavior or knows what is happening and can explain
[PATCH 2/3] musb: populate board_data within musb structure
Added board_data within musb as it would be required in
musb_platform_exit() also to unregister the nop transceiver.
Also changed the signature of musb_platform_init() as now
board_data can be taken from musb itself.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/blackfin.c |2 +-
drivers/usb/musb/davinci.c |2 +-
drivers/usb/musb/musb_core.c |3 ++-
drivers/usb/musb/musb_core.h |3 ++-
drivers/usb/musb/omap2430.c |4 ++--
drivers/usb/musb/tusb6010.c |2 +-
6 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index b611420..0bef011 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -323,7 +323,7 @@ int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
return -EIO;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
/*
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 5762436..ce2e16f 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -376,7 +376,7 @@ int musb_platform_set_mode(struct musb *musb, u8 mode)
return -EIO;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
void __iomem*tibase = musb-ctrl_base;
u32 revision;
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index d3911ab..1ccc4d7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1961,6 +1961,7 @@ bad_config:
}
spin_lock_init(musb-lock);
+ musb-board_data = plat-board_data;
musb-board_mode = plat-mode;
musb-board_set_power = plat-set_power;
musb-set_clock = plat-set_clock;
@@ -1995,7 +1996,7 @@ bad_config:
* isp1504, non-OTG, etc) mostly hooking up through ULPI.
*/
musb-isr = generic_interrupt;
- status = musb_platform_init(musb, plat-board_data);
+ status = musb_platform_init(musb);
if (status 0)
goto fail2;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7cef2b7..9dddaa4 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -393,6 +393,7 @@ struct musb {
int (*board_set_power)(int state);
int (*set_clock)(struct clk *clk, int is_active);
+ void*board_data;/* board specific data */
u8 min_power; /* vbus for periph, in mA/2 */
@@ -604,7 +605,7 @@ extern int musb_platform_get_vbus_status(struct musb *musb);
#define musb_platform_get_vbus_status(x) 0
#endif
-extern int __init musb_platform_init(struct musb *musb, void *board_data);
+extern int __init musb_platform_init(struct musb *musb);
extern int musb_platform_exit(struct musb *musb);
#endif /* __MUSB_CORE_H__ */
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index e06d65e..50591e7 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -189,10 +189,10 @@ int musb_platform_set_mode(struct musb *musb, u8
musb_mode)
return 0;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
u32 l;
- struct omap_musb_board_data *data = board_data;
+ struct omap_musb_board_data *data = musb-board_data;
#if defined(CONFIG_ARCH_OMAP2430)
omap_cfg_reg(AE5_2430_USB0HS_STP);
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 05c077f..60d3938 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1104,7 +1104,7 @@ err:
return -ENODEV;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
struct platform_device *pdev;
struct resource *mem;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP3: musb: add neednop flag to fix nop modular issue
NOP transceiver is getting registered in board files of OMAP3EVM
and OMAP4430 SDP as they use ISP150x and internal transceivers.
This registration in board file forces NOP transceiver to be
built into the kernel.
Fixing this by adding new flag '.neednop' within board_data
structure which would be used to register/unregister NOP
tranceiver in omap platform file within musb driver.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch set created against today's linus's tree.
arch/arm/mach-omap2/board-4430sdp.c |4 +---
arch/arm/mach-omap2/board-omap3evm.c |5 +
arch/arm/plat-omap/include/plat/usb.h |1 +
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index e4a5d66..fb29837 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -17,7 +17,6 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/gpio.h
-#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
@@ -138,6 +137,7 @@ static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
.mode = MUSB_PERIPHERAL,
.power = 100,
+ .neednop= 1,
};
static struct omap2_hsmmc_info mmc[] = {
@@ -374,8 +374,6 @@ static void __init omap_4430sdp_init(void)
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
- /* OMAP4 SDP uses internal transceiver so register nop transceiver */
- usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 81bba19..609f021 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -27,7 +27,6 @@
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl.h
-#include linux/usb/otg.h
#include linux/smsc911x.h
#include linux/regulator/machine.h
@@ -666,6 +665,7 @@ static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 100,
+ .neednop= 1,
};
static void __init omap3_evm_init(void)
@@ -682,9 +682,6 @@ static void __init omap3_evm_init(void)
omap_serial_init();
- /* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
-
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
omap_mux_init_gpio(22, OMAP_PIN_INPUT_PULLUP);
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index a32d3af..b53489a 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -69,6 +69,7 @@ struct omap_musb_board_data {
u8 mode;
u16 power;
unsigned extvbus:1;
+ unsigned neednop:1; /* NOP transceiver */
};
enum musb_interface{MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] musb: use neednop flag for nop registration
Some of the boards based on OMAP3 (like OMAP3EVM) and all the
board on OMAP4 uses nop transceiver so register and unregister
it based on '.neednop' flag passed from board files.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/omap2430.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 50591e7..2ec1bc4 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -198,6 +198,9 @@ int __init musb_platform_init(struct musb *musb)
omap_cfg_reg(AE5_2430_USB0HS_STP);
#endif
+ if (data-neednop)
+ usb_nop_xceiv_register();
+
/* We require some kind of external transceiver, hooked
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
@@ -323,8 +326,12 @@ static int musb_platform_resume(struct musb *musb)
int musb_platform_exit(struct musb *musb)
{
+ struct omap_musb_board_data *data = musb-board_data;
musb_platform_suspend(musb);
+ if (data-neednop)
+ usb_nop_xceiv_unregister();
+
return 0;
}
--
1.6.2.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)
2010/5/27 Arve Hjønnevåg a...@android.com: On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk 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. That's /wrong/. What if you have an active download ongoing when the screen is off? This ugly simplistic approach is one of the worst things in Android. ~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)
On Thu, May 27, 2010 at 7:14 AM, Florian Mickler flor...@mickler.org wrote: 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. Oh man, you rule the world eh? :) ~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: [RFC] Initial attempt to make ARM use LMB
On Wed, 2010-05-26 at 23:40 +0200, ext Russell King - ARM Linux wrote: On Wed, May 26, 2010 at 06:51:29AM -0700, Tony Lindgren wrote: 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? I think rx51 is currently the only board that configures the VRAM size dynamically at boot time. I tested your lmb branch on OMAP 3430SDP board, and after removing the topmost patch (ARM: use LMB to allocate system memory MMIO resource structures) everything related to DSS2 (drivers/video/omap2/) seemed to work ok. I tested the DSS2 both as built-in and as modules, and I also tested VRFB rotation. All seemed to be fine. Tomi -- 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)
On Wed, May 26, 2010 at 3:54 PM, Florian Mickler flor...@mickler.org 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. 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. Let's get rid of hypothetical uses in the future: suspend blockers is _only_ used by Android user-space. Nobody else has expressed any intention of using them. Also I expect there to be synergies between android development and mainline kernel development _only_ if android development can use mainline kernel. That's like saying there can only be synergies between linux real time and mainline _only_ if RT development can use mainline. I can give you my experience at Nokia... can you use mainline on any of the Maemo devices? No. You have to patch the kernel heavily, to be able to kind-of run the official user-space, or you have to use a different user-space. Does that prevent synergies? No. As Brian Swetland and Daniel Walker already expressed before; you can run mainline kernel with debian on Android phones. It would be nice to run Android user-space, or parts of it on mainline kernels, but if it's not possible, that's a deficiency on Android's design; Maemo/Moblin/Meego are good players in the linux ecosystem so you can re-use parts of the system on typical desktops (in fact many are coming from there), and there are community distributions re-using those parts and running just fine on mainline kernels. Sure, it would be easier for Android developers if all their crap was in the mainline, but even then there are no guarantees of anything. Just like any other linux phone, you'll probably need to add patches for 3D drivers, DSP, or other hardware acceleration, missing board-specfic patches, and bunch of hacks. So if you have to add all those patches anyway, what's the problem of having to add the suspend block patches? Why do some Android developers think they can be the exception and have patches merged in the core of linux _only_ for their specific user-space, and their specific drivers? If you separate suspend blockers from Android, and judge them on their technical merit, I don't see a single person saying this is a good idea, we'll switch all our user-space to use them. -- 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 2/3] musb: populate board_data within musb structure
-Original Message-
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Gupta, Ajay Kumar
Sent: Thursday, May 27, 2010 12:35 PM
To: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; felipe.ba...@nokia.com;
amit.kuche...@verdurent.com; khil...@deeprootsystems.com;
Gupta, Ajay Kumar
Subject: [PATCH 2/3] musb: populate board_data within musb structure
Added board_data within musb as it would be required in
musb_platform_exit() also to unregister the nop transceiver.
Also changed the signature of musb_platform_init() as now
board_data can be taken from musb itself.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/blackfin.c |2 +-
drivers/usb/musb/davinci.c |2 +-
drivers/usb/musb/musb_core.c |3 ++-
drivers/usb/musb/musb_core.h |3 ++-
drivers/usb/musb/omap2430.c |4 ++--
drivers/usb/musb/tusb6010.c |2 +-
6 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index b611420..0bef011 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -323,7 +323,7 @@ int musb_platform_set_mode(struct musb
*musb, u8 musb_mode)
return -EIO;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
/*
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 5762436..ce2e16f 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -376,7 +376,7 @@ int musb_platform_set_mode(struct musb
*musb, u8 mode)
return -EIO;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
void __iomem*tibase = musb-ctrl_base;
u32 revision;
diff --git a/drivers/usb/musb/musb_core.c
b/drivers/usb/musb/musb_core.c
index d3911ab..1ccc4d7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1961,6 +1961,7 @@ bad_config:
}
spin_lock_init(musb-lock);
+ musb-board_data = plat-board_data;
musb-board_mode = plat-mode;
musb-board_set_power = plat-set_power;
musb-set_clock = plat-set_clock;
I think musb structure already has a pointer to device structure which intern
has the platform_data pointer.
I think all of these member variables are not required. Might need to cleanup
the musb structre.
@@ -1995,7 +1996,7 @@ bad_config:
* isp1504, non-OTG, etc) mostly hooking up through ULPI.
*/
musb-isr = generic_interrupt;
- status = musb_platform_init(musb, plat-board_data);
+ status = musb_platform_init(musb);
if (status 0)
goto fail2;
diff --git a/drivers/usb/musb/musb_core.h
b/drivers/usb/musb/musb_core.h
index 7cef2b7..9dddaa4 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -393,6 +393,7 @@ struct musb {
int (*board_set_power)(int state);
int (*set_clock)(struct clk *clk,
int is_active);
+ void*board_data;/* board
specific data */
u8 min_power; /* vbus for
periph, in mA/2 */
@@ -604,7 +605,7 @@ extern int
musb_platform_get_vbus_status(struct musb *musb);
#define musb_platform_get_vbus_status(x) 0
#endif
-extern int __init musb_platform_init(struct musb *musb, void
*board_data);
+extern int __init musb_platform_init(struct musb *musb);
extern int musb_platform_exit(struct musb *musb);
#endif/* __MUSB_CORE_H__ */
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index e06d65e..50591e7 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -189,10 +189,10 @@ int musb_platform_set_mode(struct musb
*musb, u8 musb_mode)
return 0;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
u32 l;
- struct omap_musb_board_data *data = board_data;
+ struct omap_musb_board_data *data = musb-board_data;
#if defined(CONFIG_ARCH_OMAP2430)
omap_cfg_reg(AE5_2430_USB0HS_STP);
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 05c077f..60d3938 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1104,7 +1104,7 @@ err:
return -ENODEV;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
struct platform_device *pdev;
struct resource *mem;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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
Re: [RFC] Initial attempt to make ARM use LMB
On Thu, May 27, 2010 at 11:52:18AM +0300, Tomi Valkeinen wrote: On Wed, 2010-05-26 at 23:40 +0200, ext Russell King - ARM Linux wrote: On Wed, May 26, 2010 at 06:51:29AM -0700, Tony Lindgren wrote: 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? I think rx51 is currently the only board that configures the VRAM size dynamically at boot time. I tested your lmb branch on OMAP 3430SDP board, and after removing the topmost patch (ARM: use LMB to allocate system memory MMIO resource structures) everything related to DSS2 (drivers/video/omap2/) seemed to work ok. Great, can I add your tested-by for the OMAP and LMB stuff up to but not including the last commit? -- 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
On Thu, May 27, 2010 at 10:07:40AM +0530, DebBarma, Tarun Kanti wrote: 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! I've now committed a fix to change those registers. Are you ok with being credited with a Reported-by tag? -- 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
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, May 27, 2010 3:00 PM
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 Thu, May 27, 2010 at 10:07:40AM +0530, DebBarma, Tarun Kanti wrote:
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!
I've now committed a fix to change those registers. Are you ok with
being credited with a Reported-by tag?
That's fine!
--
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] omap: pandora: add support for wl1251 wifi chip
Define platform data and setup GPIOs so that TI wl1251 wifi chip
and it's driver can function.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
I could have sent this earlier but it depended on the wifi tree,
hope this can still go in for -rc2, it's just platform data anyway.
arch/arm/mach-omap2/board-omap3pandora.c | 83 ++
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 395d049..8e164f1 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -29,6 +29,7 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/gpio_keys.h
+#include linux/spi/wl12xx.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -46,6 +47,8 @@
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
+#define PANDORA_WIFI_IRQ_GPIO 21
+#define PANDORA_WIFI_NRESET_GPIO 23
#define OMAP3_PANDORA_TS_GPIO 94
/* hardware debounce: (value + 1) * 31us */
@@ -248,6 +251,7 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .ocr_mask = 0x80, /* MMC_VDD_165_195 */
},
{} /* Terminator */
};
@@ -255,12 +259,33 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
static int omap3pandora_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int ret, gpio_32khz;
+
/* gpio + {0,1} is mmc{0,1}_cd (input/IRQ) */
omap3pandora_mmc[0].gpio_cd = gpio + 0;
omap3pandora_mmc[1].gpio_cd = gpio + 1;
omap2_hsmmc_init(omap3pandora_mmc);
+ /* gpio + 13 drives 32kHz buffer for wifi module */
+ gpio_32khz = gpio + 13;
+ ret = gpio_request(gpio_32khz, wifi 32kHz);
+ if (ret 0) {
+ pr_err(Cannot get GPIO line %d, ret=%d\n, gpio_32khz, ret);
+ goto fail;
+ }
+
+ ret = gpio_direction_output(gpio_32khz, 1);
+ if (ret 0) {
+ pr_err(Cannot set GPIO line %d, ret=%d\n, gpio_32khz, ret);
+ goto fail_direction;
+ }
+
return 0;
+
+fail_direction:
+ gpio_free(gpio_32khz);
+fail:
+ return -ENODEV;
}
static struct twl4030_gpio_platform_data omap3pandora_gpio_data = {
@@ -539,10 +564,67 @@ static void __init omap3pandora_init_irq(void)
omap_gpio_init();
}
+static void pandora_wl1251_set_power(bool enable)
+{
+ /*
+* Keep power always on until wl1251_sdio driver learns to re-init
+* the chip after powering it down and back up.
+*/
+}
+
+static struct wl12xx_platform_data pandora_wl1251_pdata = {
+ .set_power = pandora_wl1251_set_power,
+ .use_eeprom = true,
+};
+
+static struct platform_device pandora_wl1251_data = {
+ .name = wl1251_data,
+ .id = -1,
+ .dev= {
+ .platform_data = pandora_wl1251_pdata,
+ },
+};
+
+static void pandora_wl1251_init(void)
+{
+ int ret;
+
+ ret = gpio_request(PANDORA_WIFI_IRQ_GPIO, wl1251 irq);
+ if (ret 0)
+ goto fail;
+
+ ret = gpio_direction_input(PANDORA_WIFI_IRQ_GPIO);
+ if (ret 0)
+ goto fail_irq;
+
+ pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO);
+ if (pandora_wl1251_pdata.irq 0)
+ goto fail_irq;
+
+ ret = gpio_request(PANDORA_WIFI_NRESET_GPIO, wl1251 nreset);
+ if (ret 0)
+ goto fail_irq;
+
+ /* start powered so that it probes with MMC subsystem */
+ ret = gpio_direction_output(PANDORA_WIFI_NRESET_GPIO, 1);
+ if (ret 0)
+ goto fail_nreset;
+
+ return;
+
+fail_nreset:
+ gpio_free(PANDORA_WIFI_NRESET_GPIO);
+fail_irq:
+ gpio_free(PANDORA_WIFI_IRQ_GPIO);
+fail:
+ printk(KERN_ERR wl1251 board initialisation failed\n);
+}
+
static struct platform_device *omap3pandora_devices[] __initdata = {
pandora_leds_gpio,
pandora_keys_gpio,
pandora_dss_device,
+ pandora_wl1251_data,
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
@@ -575,6 +657,7 @@ static void __init omap3pandora_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3pandora_i2c_init();
+ pandora_wl1251_init();
platform_add_devices(omap3pandora_devices,
ARRAY_SIZE(omap3pandora_devices));
omap_serial_init();
--
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: [RFC] Initial attempt to make ARM use LMB
On Thu, 2010-05-27 at 11:25 +0200, ext Russell King - ARM Linux wrote: On Thu, May 27, 2010 at 11:52:18AM +0300, Tomi Valkeinen wrote: I tested your lmb branch on OMAP 3430SDP board, and after removing the topmost patch (ARM: use LMB to allocate system memory MMIO resource structures) everything related to DSS2 (drivers/video/omap2/) seemed to work ok. Great, can I add your tested-by for the OMAP and LMB stuff up to but not including the last commit? Sure. I'll also try to find time to review the DSS side changes properly. Tomi -- 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)
On Wed, 26 May 2010 10:38:50 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: 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 Let me elaborate what i mean: The assumption beeing that specifying pm constraints in the drivers is a good thing which we will be doing anyway in the long run. (See Alan Cox's summary of current mainline problems[1].) I don't wanna go into specifing any constraint API here, but it could probably be either a blocker flag (the here presented suspend-blocker, which Alan doesnt like?) or maybe a few integer-typed constraints defined by the pm-core. (needed scheduler-latency/needed io-latency?) As an intermediate step, it would probably be possible to specify the I cant be suspended constraint (aka blocker) for all drivers not explicitly stating anything other. Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any no suspend (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.) A future switch from something like a flag (blocker) to a full integer-typed requirement would probably be a simple search and replace or even possible by extending the blocker-api. If that is done, the prototype of the driver callback int suspend(); could probably be changed to void suspend(); and it be expected to always _successfully_ suspend. The hard part is finding the places where special guarantees are needed. But android did show that this is possible. Cheers, Flo [1]: http://lkml.org/lkml/2010/5/26/575 -- 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 6/6] omap: move generic omap3 features to generic
Nishanth Menon n...@ti.com wrote:
sgx, iva, l2cache, sgx, neon, isp are generic features, make
them generic features, current OMAP3 detection mechanism
is still retained. 192Mhz is more specific OMAP3 feature
so it is retained as is
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Senthilvadivu Gurusamy svad...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Vishwanath S vishw...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/id.c | 20
arch/arm/plat-omap/common.c | 3 ++
arch/arm/plat-omap/include/plat/cpu.h | 39 +++-
3 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat; \
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
* AM35xx devices
*/
- if (omap3_has_sgx()) {
+ if (omap_has_sgx()) {
omap_revision = OMAP3517_REV(rev);
strcpy(cpu_name, AM3517);
} else {
/* Already set in omap3_check_revision() */
strcpy(cpu_name, AM3505);
}
- } else if (omap3_has_iva() omap3_has_sgx()) {
+ } else if (omap_has_iva() omap_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, OMAP3430/3530);
- } else if (omap3_has_iva()) {
+ } else if (omap_has_iva()) {
omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, OMAP3525);
- } else if (omap3_has_sgx()) {
+ } else if (omap_has_sgx()) {
omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, OMAP3515);
} else {
@@ -354,11 +354,11 @@ static void __init omap3_cpuinfo(void)
/* Print verbose information */
pr_info(%s ES%s (, cpu_name, cpu_rev);
- OMAP_SHOW_FEATURE(3, l2cache);
- OMAP_SHOW_FEATURE(3, iva);
- OMAP_SHOW_FEATURE(3, sgx);
- OMAP_SHOW_FEATURE(3, neon);
- OMAP_SHOW_FEATURE(3, isp);
+ OMAP_SHOW_FEATURE(, l2cache);
+ OMAP_SHOW_FEATURE(, iva);
+ OMAP_SHOW_FEATURE(, sgx);
+ OMAP_SHOW_FEATURE(, neon);
+ OMAP_SHOW_FEATURE(, isp);
OMAP_SHOW_FEATURE(3, 192mhz_clk);
printk()\n);
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 459a45f..259adc7 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -81,6 +81,9 @@ const void *omap_get_var_config(u16 tag, size_t *len)
}
EXPORT_SYMBOL(omap_get_var_config);
+/* OMAP Generic features */
+u32 omap_features;
+
void __init omap_check_revision()
{
#ifdef CONFIG_ARCH_OMAP1
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index f8ecbc4..3cc4947 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -331,14 +331,14 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap3517
# define cpu_is_omap3430() is_omap3430()
# define cpu_is_omap3503() (cpu_is_omap3430() \
- (!omap3_has_iva()) \
- (!omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (!omap_has_sgx()))
# define cpu_is_omap3515() (cpu_is_omap3430() \
- (!omap3_has_iva()) \
- (omap3_has_sgx()))
+ (!omap_has_iva()) \
+ (omap_has_sgx()))
# define cpu_is_omap3525()
omap3 pm: dependency between opp layer and cpufreq
Hi, While compiling for omap3_evm_defconfig, at the head of linux-omap, I encounter these errors: arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:364: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_enable': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:609: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:478: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:496: undefined reference to `omap_twl_uv_to_vsel' make: *** [.tmp_vmlinux1] Error 1 Turn our that comment and code in plat-omap/Makefile don't match: # OPP support in (OMAP3+ only at the moment) # XXX The OPP TWL/TPS code should only be included when a TWL/TPS # PMIC is selected. ifdef CONFIG_CPU_FREQ obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o endif But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to these errors: CC arch/arm/plat-omap/opp.o arch/arm/plat-omap/opp.c:54: error: redefinition of 'opp_get_voltage' arch/arm/plat-omap/include/plat/opp.h:240: error: previous definition of 'opp_get_voltage' was here arch/arm/plat-omap/opp.c:63: error: redefinition of 'opp_get_freq' arch/arm/plat-omap/include/plat/opp.h:245: error: previous definition of 'opp_get_freq' was here arch/arm/plat-omap/opp.c:79: error: conflicting types for 'opp_find_by_opp_id' arch/arm/plat-omap/include/plat/opp.h:296: error: previous definition of 'opp_find_by_opp_id' was here arch/arm/plat-omap/opp.c:102: error: redefinition of 'opp_get_opp_id' arch/arm/plat-omap/include/plat/opp.h:301: error: previous definition of 'opp_get_opp_id' was here arch/arm/plat-omap/opp.c:107: error: conflicting types for 'opp_get_opp_count' arch/arm/plat-omap/include/plat/opp.h:250: error: previous definition of 'opp_get_opp_count' was here arch/arm/plat-omap/opp.c:129: error: conflicting types for 'opp_find_freq_exact' arch/arm/plat-omap/include/plat/opp.h:256: error: previous definition of 'opp_find_freq_exact' was here arch/arm/plat-omap/opp.c:153: error: conflicting types for 'opp_find_freq_ceil' arch/arm/plat-omap/include/plat/opp.h:268: error: previous definition of 'opp_find_freq_ceil' was here arch/arm/plat-omap/opp.c:182: error: conflicting types for 'opp_find_freq_floor' arch/arm/plat-omap/include/plat/opp.h:262: error: previous definition of 'opp_find_freq_floor' was here arch/arm/plat-omap/opp.c:223: error: conflicting types for 'opp_add' arch/arm/plat-omap/include/plat/opp.h:280: error: previous definition of 'opp_add' was here arch/arm/plat-omap/opp.c:291: error: conflicting types for 'opp_init_list' arch/arm/plat-omap/include/plat/opp.h:274: error: previous definition of 'opp_init_list' was here arch/arm/plat-omap/opp.c:335: error: redefinition of 'opp_enable' arch/arm/plat-omap/include/plat/opp.h:285: error: previous definition of 'opp_enable' was here arch/arm/plat-omap/opp.c:345: error: redefinition of 'opp_disable' arch/arm/plat-omap/include/plat/opp.h:290: error: previous definition of 'opp_disable' was here arch/arm/plat-omap/opp.c:356: error: conflicting types for 'opp_init_cpufreq_table' arch/arm/plat-omap/include/plat/opp.h:307: error: previous definition of 'opp_init_cpufreq_table' was here make[1]: *** [arch/arm/plat-omap/opp.o] Error 1 The contents of plat-omap/include/plat/opp.h seem to be based on assumption that definition of OPP is needed only for cpufreq. But even if cpufreq is disabled, this information is required for setting the correct voltage against 'pre-defined' ARM frequency. Questions/ comments: 1) The linkage between OPP and Voltage are not driven by the PMIC. They are defined by/for the silicon itself. 2) The implementation for setting the voltage should depend upon the PMIC. 3) Was there any specific need to tie the functions opp_get_voltage and others to cpufreq only? I am working on a patch that should remove some of these dependencies. But, trying to open up a discussion as well... Best regards, Sanjeev -- 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)
ext Florian Mickler wrote: Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any no suspend (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.) That's not really true. Nothing prevents using from the beginning a sane approach where drivers are required to specify constraints. The way it has been done for the N900 was to let driver developers specify _very_ conservative constraints, during the conversion phase. Then each driver has been optimized. If you have as requirement for driver developers that their driver must be working properly when compiled as module, it is possible to test the system with a minimalistic kernel which enters the lowest power state as soon as possible, plus only those modules that are being optimized. This allows also to identify parasitic drivers, which fail to apply the proper constraint and instead rely on some other driver to keep the system alive. igor -- 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)
ext Florian Mickler wrote: Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any no suspend (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.) That's not really true. Nothing prevents using from the beginning a sane approach where drivers are required to specify constraints. The way it has been done for the N900 was to let driver developers specify _very_ conservative constraints, during the conversion phase. Then each driver has been optimized. If you have as requirement for driver developers that their driver must be working properly when compiled as module, it is possible to test the system with a minimalistic kernel which enters the lowest power state as soon as possible, plus only those modules that are being optimized. This allows also to identify parasitic drivers, which fail to apply the proper constraint and instead rely on some other driver to keep the system alive. igor -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3] OMAP3: PM: Workaround for DLL Lock issue
From: Vishwanath BS vishwanath...@ti.com
OMAP3430/3630 has a Silicon bug because of which SDRC is
released from IDLE even before Core DPLL has locked. This leads
to undefined behaviour of SDRC DLL.
Bug Descritpion: The root cause of the issue is that SDRC IDLEREQ
is deasserted before DPLL3 has locked. Because of this DLL may/may
not lock based on Process Voltage Temperature conditions. The bug
can occur when DPLL3 automatic transition is enabled. So DPLL3 automatic
transition is disabled by default and it is enabled only when system
is entering ret/off state (to facilitate voltage scaling). So when system
is entering ret/off state, WA is applied (since DPLL3 autoidle is enabled,
we can possibly hit the issue; hence the WA)
Errata id: i581
Workaround Descrioption:
Description of WA for 3430:
Initialization:
Disable DPLL3 automatic mode by default. Issue will not be faced as
DPLL3
is always locked.
Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
1. Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
(by changing M2 Divider value). This is increasing the period duration
of
one L3 clock cycle.
o In case of CORE is at OPP3 (166...@1.15v):
Lower the frequency to 83MHz.
o In case of CORE is at OPP2 (83...@1.05v):
Keep the frequency as it is (83MHz).
2. Increase CORE Voltage to 1.2V. This is reducing the timing duration of
the
critical path signal which will now fit to one L3 clock cycle.
3. Enable DPLL3 Automatic mode. This will ensure proper transition to
RETENTION or OFF mode.
After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1. Disable DPLL3 Automatic mode.
2. Restore previous DPLL3 M2 Frequency and CORE Voltage values.
Description of WA for 3630:
Initialization:
Disable DPLL3 automatic mode by default. Issue will not be faced as
DPLL3 is always
locked.
Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
1. Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
This is increasing the period duration of one L3 clock cycle and
reducing
the timing duration of the critical path signal which will now fit to
one
L3 clock cycle.
o In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
Lower the frequency to 100MHz.
Keep the voltage as it is (1.1375V).
o In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
Keep the frequency as it is (100MHz).
Increase the voltage to 1.1375V.
2. Enable DPLL3 Automatic mode. This will ensure proper transition to
RETENTION or OFF mode.
After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1. Disable DPLL3 Automatic mode.
2. Restore previous DPLL3 M2 Frequency and CORE Voltage values.
Also OSWR should not be attempted if DPLL3 has locked. This should be done as
part of OSWR patch
series.
These patch is based on Thara's Smart Reflex V3 patch series (wip_sr branch)
and Tero's OS Idle changes @
https://patchwork.kernel.org/patch/85268/
Patch tested on 3430SDP and 3630 ZOOM3.
Changes done in V3:
1. Addressed comments from Kevin
2. Optimized the code based on Peter's patch
Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 114 -
arch/arm/mach-omap2/voltage.c |1 +
2 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9c57081..b0a5d09 100755
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -55,6 +55,7 @@
#include pm.h
#include sdrc.h
#include omap3-opp.h
+#include clock3xxx.h
#ifdef CONFIG_SUSPEND
static suspend_state_t suspend_state = PM_SUSPEND_ON;
@@ -97,6 +98,15 @@ static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
+static struct powerdomain *dss_pwrdm, *usbhost_pwrdm;
+static struct powerdomain *cam_pwrdm, *sgx_pwrdm;
+static struct clk *dpll3_clk;
+static struct omap_opp *vdd2_opp50, *vdd2_opp100;
+static unsigned long vdd2_opp50_volt, vdd2_opp100_volt;
+
+#define DLL_LOCK_ERRATA_581 (1 0)
+static u16 pm34xx_errata;
+#define IS_PM34XX_ERRATA(id) (pm34xx_errata (id))
static inline void omap3_per_save_context(void)
{
@@ -367,6 +377,7 @@ void omap_sram_idle(void)
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
+ int prev_dpll3_div = 0;
if (!_omap_sram_idle)
return;
@@ -417,9
[PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices
From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Kconfig | 61 +-- drivers/media/video/Makefile|2 +- drivers/media/video/davinci/Kconfig | 93 +++ 3 files changed, 95 insertions(+), 61 deletions(-) create mode 100644 drivers/media/video/davinci/Kconfig diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index ad9e6f9..e5d74ae 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -570,66 +570,7 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. -config VIDEO_VPSS_SYSTEM - tristate VPSS System module driver - depends on ARCH_DAVINCI - help - Support for vpss system module for video driver - -config VIDEO_VPFE_CAPTURE - tristate VPFE Video Capture Driver - depends on VIDEO_V4L2 ARCH_DAVINCI - select VIDEOBUF_DMA_CONTIG - help - Support for DM VPFE based frame grabber. This is the - common V4L2 module for following DMXXX SoCs from Texas - Instruments:- DM6446 DM355. - - To compile this driver as a module, choose M here: the - module will be called vpfe-capture. - -config VIDEO_DM6446_CCDC - tristate DM6446 CCDC HW module - depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from slave decoders. - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_DM355_CCDC - tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DM355 CCD hw module. DM355 CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_ISIF - tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables ISIF hw module. This is the hardware module for - configuring ISIF in VPFE to capture Raw Bayer RGB data from - a image sensor or YUV data from a YUV source. - - To compile this driver as a module, choose M here: the - module will be called vpfe. +source drivers/media/video/davinci/Kconfig source drivers/media/video/omap/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index cc93859..aa1ea2f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -177,7 +177,7 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o -obj-$(CONFIG_ARCH_DAVINCI) += davinci/ +obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP)+= omap/ diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig new file mode 100644 index 000..97f889d --- /dev/null +++ b/drivers/media/video/davinci/Kconfig @@ -0,0 +1,93 @@ +config DISPLAY_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Display + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 + help + Support for DM6467 based display device. + + To compile this driver as a module, choose M here: the + module will be called vpif_display. + +config CAPTURE_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Capture + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help + Support for DM6467 based capture device. + + To compile this driver as a module, choose M here: the + module will be called vpif_capture. + +config VIDEO_DAVINCI_VPIF + tristate DaVinci VPIF Driver + depends on DISPLAY_DAVINCI_DM646X_EVM + help + Support for DaVinci VPIF Driver. + + To compile this driver as a module, choose M here: the + module will be called vpif. + +config VIDEO_VPSS_SYSTEM + tristate
[PATCH 0/2] Add support for AM3517 VPFE Capture module
From: Vaibhav Hiremath hvaib...@ti.com AM3517 uses similar VPFE-CCDC hardware IP as in Davinci, so reusing the driver. Currently the davinci driver is hardly tied with ARCH_DAVINCI, which was limiting AM3517 to reuse the driver. So created seperate Kconfig file for davinci and added AM3517 to dependancy. Also added board hook up code to board-am3517evm.c file. Vaibhav Hiremath (2): Davinci: Create seperate Kconfig file for davinci devices AM3517: Add VPFE Capture driver support to board file arch/arm/mach-omap2/board-am3517evm.c | 161 + drivers/media/video/Kconfig | 61 + drivers/media/video/Makefile |2 +- drivers/media/video/davinci/Kconfig | 93 +++ 4 files changed, 256 insertions(+), 61 deletions(-) create mode 100644 drivers/media/video/davinci/Kconfig -- 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: omap3 pm: dependency between opp layer and cpufreq
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Thursday, May 27, 2010 4:56 PM To: linux-omap@vger.kernel.org Subject: omap3 pm: dependency between opp layer and cpufreq Hi, While compiling for omap3_evm_defconfig, at the head of linux-omap, I encounter these errors: arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:364: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_enable': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:609: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:478: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:496: undefined reference to `omap_twl_uv_to_vsel' make: *** [.tmp_vmlinux1] Error 1 Turn our that comment and code in plat-omap/Makefile don't match: # OPP support in (OMAP3+ only at the moment) # XXX The OPP TWL/TPS code should only be included when a TWL/TPS # PMIC is selected. ifdef CONFIG_CPU_FREQ obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o endif But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to these errors: CC arch/arm/plat-omap/opp.o arch/arm/plat-omap/opp.c:54: error: redefinition of 'opp_get_voltage' arch/arm/plat-omap/include/plat/opp.h:240: error: previous definition of 'opp_get_voltage' was here arch/arm/plat-omap/opp.c:63: error: redefinition of 'opp_get_freq' arch/arm/plat-omap/include/plat/opp.h:245: error: previous definition of 'opp_get_freq' was here arch/arm/plat-omap/opp.c:79: error: conflicting types for 'opp_find_by_opp_id' arch/arm/plat-omap/include/plat/opp.h:296: error: previous definition of 'opp_find_by_opp_id' was here arch/arm/plat-omap/opp.c:102: error: redefinition of 'opp_get_opp_id' arch/arm/plat-omap/include/plat/opp.h:301: error: previous definition of 'opp_get_opp_id' was here arch/arm/plat-omap/opp.c:107: error: conflicting types for 'opp_get_opp_count' arch/arm/plat-omap/include/plat/opp.h:250: error: previous definition of 'opp_get_opp_count' was here arch/arm/plat-omap/opp.c:129: error: conflicting types for 'opp_find_freq_exact' arch/arm/plat-omap/include/plat/opp.h:256: error: previous definition of 'opp_find_freq_exact' was here arch/arm/plat-omap/opp.c:153: error: conflicting types for 'opp_find_freq_ceil' arch/arm/plat-omap/include/plat/opp.h:268: error: previous definition of 'opp_find_freq_ceil' was here arch/arm/plat-omap/opp.c:182: error: conflicting types for 'opp_find_freq_floor' arch/arm/plat-omap/include/plat/opp.h:262: error: previous definition of 'opp_find_freq_floor' was here arch/arm/plat-omap/opp.c:223: error: conflicting types for 'opp_add' arch/arm/plat-omap/include/plat/opp.h:280: error: previous definition of 'opp_add' was here arch/arm/plat-omap/opp.c:291: error: conflicting types for 'opp_init_list' arch/arm/plat-omap/include/plat/opp.h:274: error: previous definition of 'opp_init_list' was here arch/arm/plat-omap/opp.c:335: error: redefinition of 'opp_enable' arch/arm/plat-omap/include/plat/opp.h:285: error: previous definition of 'opp_enable' was here arch/arm/plat-omap/opp.c:345: error: redefinition of 'opp_disable' arch/arm/plat-omap/include/plat/opp.h:290: error: previous definition of 'opp_disable' was here arch/arm/plat-omap/opp.c:356: error: conflicting types for 'opp_init_cpufreq_table' arch/arm/plat-omap/include/plat/opp.h:307: error: previous definition of 'opp_init_cpufreq_table' was here make[1]: *** [arch/arm/plat-omap/opp.o] Error 1 The contents of plat-omap/include/plat/opp.h seem to be based on assumption that definition of OPP is needed only for cpufreq. But even if cpufreq is disabled, this information is required for setting the correct voltage against 'pre-defined' ARM frequency. Questions/ comments: 1) The linkage between OPP and Voltage are not driven by the PMIC. They are defined by/for the silicon itself. 2) The implementation for setting the voltage should depend upon the PMIC. 3) Was there any specific need to tie the functions opp_get_voltage and others to cpufreq only? I am working on a patch that should remove some of these dependencies. But, trying to open up a discussion as well... Best regards, Sanjeev Here is a quick patch for discussion. (Will wait for comments before submitting a formal patch) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 2b9ebf0..18d291f 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,7 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # OPP
[PATCH v4 0/3] omap3 nand: cleanup exiting platform related code
The following set of patches applies on top of for-next branch. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board And these are the patches required to address the following input - 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. Discussion: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27630.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28715.html Functions related to ecc and prefetch engine are optimized. v2: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28467.html Few functionality was missing like - There should be some locking as only one chipselect can use the ECC or prefetch engine at a time. If you have NAND in two chipselects, bad things would happen. v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28164.html Additionally, it was needed to implement more functions for the platform init code to use. Sukumar Ghorai (3): omap3 gpmc: functionality enhancement omap3 nand: cleanup virtual address usages omap3 nand: fix issue in board file to detect nand arch/arm/mach-omap2/board-cm-t35.c | 20 +--- arch/arm/mach-omap2/board-devkit8000.c | 25 +--- arch/arm/mach-omap2/board-omap3beagle.c| 24 +--- arch/arm/mach-omap2/board-omap3touchbook.c | 25 +--- arch/arm/mach-omap2/board-overo.c | 24 +--- arch/arm/mach-omap2/gpmc-nand.c| 39 ++ arch/arm/mach-omap2/gpmc.c | 219 +-- arch/arm/plat-omap/include/plat/gpmc.h | 36 - arch/arm/plat-omap/include/plat/nand.h |6 +- drivers/mtd/nand/omap2.c | 229 10 files changed, 320 insertions(+), 327 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 v4 1/3] omap3 gpmc: functionality enhancement
few functions added in gpmc module and to be used by other drivers like NAND.
E.g.: - ioctl function
- ecc functions
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 219 ++--
arch/arm/plat-omap/include/plat/gpmc.h | 33 +-
drivers/mtd/nand/omap2.c |4 +-
3 files changed, 239 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..48b5af0
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -46,8 +46,9 @@
#define GPMC_ECC_CONFIG0x1f4
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
+#define GPMC_ECC1_RESULT0x200
-#define GPMC_CS0 0x60
+#define GPMC_CS0_BASE 0x60
#define GPMC_CS_SIZE 0x30
#define GPMC_MEM_START 0x
@@ -92,7 +93,8 @@ struct omap3_gpmc_regs {
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
-static unsignedgpmc_cs_map;
+static unsignedint gpmc_cs_map;/* flag for cs which are
initialized */
+static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
static void __iomem *gpmc_base;
@@ -108,11 +110,27 @@ static u32 gpmc_read_reg(int idx)
return __raw_readl(gpmc_base + idx);
}
+static void gpmc_cs_write_byte(int cs, int idx, u8 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ __raw_writeb(val, reg_addr);
+}
+
+static u8 gpmc_cs_read_byte(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ return __raw_readb(reg_addr);
+}
+
void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
@@ -120,7 +138,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
@@ -419,8 +437,100 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
+ * gpmc_hwcontrol - hardware specific access (read/ write) control
+ * @cs: chip select number
+ * @cmd: command type
+ * @write: 1 for write; 0 for read
+ * @wval: value to write
+ * @rval: read pointer
+ */
+int gpmc_hwcontrol(int cs, int cmd, int write, int wval, int *rval)
+{
+ u32 regval = 0;
+
+ if (!write !rval)
+ return -EINVAL;
+
+ switch (cmd) {
+ case GPMC_STATUS_BUFFER:
+ regval = gpmc_read_reg(GPMC_STATUS);
+ /* 1 : buffer is available to write */
+ *rval = regval GPMC_STATUS_BUFF_EMPTY;
+ break;
+
+ case GPMC_GET_SET_IRQ_STATUS:
+ if (write)
+ gpmc_write_reg(GPMC_IRQSTATUS, wval);
+ else
+ *rval = gpmc_read_reg(GPMC_IRQSTATUS);
+ break;
+
+ case GPMC_PREFETCH_FIFO_CNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_FIFO_CNT(regval);
+ break;
+
+ case GPMC_PREFETCH_COUNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_COUNT(regval);
+ break;
+
+ case GPMC_CONFIG_WP:
+ regval = gpmc_read_reg(GPMC_CONFIG);
+ if (wval)
+ regval = ~GPMC_CONFIG_WRITEPROTECT; /* WP is ON */
+ else
+ regval |= GPMC_CONFIG_WRITEPROTECT; /* WP is OFF */
+ gpmc_write_reg(GPMC_CONFIG, regval);
+ break;
+
+ case GPMC_CONFIG_RDY_BSY:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_CONFIG_DEV_SIZE:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= GPMC_CONFIG1_DEVICESIZE(wval);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_CONFIG_DEV_TYPE:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= GPMC_CONFIG1_DEVICETYPE(wval);
+ if (wval == GPMC_DEVICETYPE_NOR)
+ regval |= GPMC_CONFIG1_MUXADDDATA;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
+
+ case GPMC_NAND_COMMAND:
+ gpmc_cs_write_byte(cs, GPMC_CS_NAND_COMMAND, wval);
+
[PATCH v4 3/3] omap3 nand: fix issue in board file to detect nand
Board file modified for not to provide gpmc phys_base address to nand driver.
The gpmc_nand_init funciton is now used to detect the nand and required to
adopt _prob function as in nand/omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 20 +---
arch/arm/mach-omap2/board-devkit8000.c | 25 +
arch/arm/mach-omap2/board-omap3beagle.c| 24 +---
arch/arm/mach-omap2/board-omap3touchbook.c | 25 +
arch/arm/mach-omap2/board-overo.c | 24 +---
5 files changed, 5 insertions(+), 113 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e679a2c..0544294
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -61,8 +61,6 @@
#define SB_T35_SMSC911X_GPIO 65
#define NAND_BLOCK_SIZESZ_128K
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS0_BASE_ADDR (OMAP34XX_GPMC_VIRT + GPMC_CS0_BASE)
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include linux/smsc911x.h
@@ -223,28 +221,12 @@ static struct omap_nand_platform_data cm_t35_nand_data = {
.nr_parts = ARRAY_SIZE(cm_t35_nand_partitions),
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
.cs = 0,
- .gpmc_cs_baseaddr = (void __iomem *)GPMC_CS0_BASE_ADDR,
- .gpmc_baseaddr = (void __iomem *)OMAP34XX_GPMC_VIRT,
};
-static struct resource cm_t35_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device cm_t35_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .num_resources = 1,
- .resource = cm_t35_nand_resource,
- .dev= {
- .platform_data = cm_t35_nand_data,
- },
-};
-
static void __init cm_t35_init_nand(void)
{
- if (platform_device_register(cm_t35_nand_device) 0)
+ if (gpmc_nand_init(cm_t35_nand_data) 0)
pr_err(CM-T35: Unable to register NAND device\n);
}
#else
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 77022b5..9a8135d
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -58,9 +58,6 @@
#include mux.h
#include hsmmc.h
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
#define OMAP_DM9000_GPIO_IRQ 25
@@ -104,20 +101,6 @@ static struct omap_nand_platform_data devkit8000_nand_data
= {
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
};
-static struct resource devkit8000_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device devkit8000_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .dev= {
- .platform_data = devkit8000_nand_data,
- },
- .num_resources = 1,
- .resource = devkit8000_nand_resource,
-};
-
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -581,8 +564,6 @@ static void __init devkit8000_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -604,13 +585,9 @@ static void __init devkit8000_flash_init(void)
if (nandcs GPMC_CS_NUM) {
devkit8000_nand_data.cs = nandcs;
- devkit8000_nand_data.gpmc_cs_baseaddr = (void *)
- (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
- devkit8000_nand_data.gpmc_baseaddr = (void *)
- (gpmc_base_add);
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
- if (platform_device_register(devkit8000_nand_device) 0)
+ if (gpmc_nand_init(devkit8000_nand_data) 0)
printk(KERN_ERR Unable to register NAND device\n);
}
}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 69b154c..dc5a7e8
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -48,9 +48,6 @@
#include mux.h
#include hsmmc.h
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
static struct mtd_partition omap3beagle_nand_partitions[] = {
@@ -93,20 +90,6 @@ static struct omap_nand_platform_data omap3beagle_nand_data
= {
.dev_ready = NULL,
};
-static struct resource omap3beagle_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device omap3beagle_nand_device = {
[PATCH v4 2/3] omap3 nand: cleanup virtual address usages
This patch removes direct reference of gpmc address from generic nand platform
code.
Nand platform code now uses wrapper functions which are implemented in gpmc
module.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c| 39 ++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
arch/arm/plat-omap/include/plat/nand.h |6 +-
drivers/mtd/nand/omap2.c | 225 +---
4 files changed, 77 insertions(+), 198 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..80f5d94
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -19,8 +19,6 @@
#include plat/board.h
#include plat/gpmc.h
-#define WR_RD_PIN_MONITORING 0x0060
-
static struct omap_nand_platform_data *gpmc_nand_data;
static struct resource gpmc_nand_resource = {
@@ -71,10 +69,10 @@ static int omap2_nand_gpmc_retime(void)
t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
/* Configure GPMC */
- gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
- GPMC_CONFIG1_DEVICETYPE_NAND);
-
+ gpmc_hwcontrol(gpmc_nand_data-cs,
+ GPMC_CONFIG_DEV_SIZE, 1, gpmc_nand_data-devsize, NULL);
+ gpmc_hwcontrol(gpmc_nand_data-cs,
+ GPMC_CONFIG_DEV_TYPE, 1, GPMC_DEVICETYPE_NAND, NULL);
err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
if (err)
return err;
@@ -82,27 +80,13 @@ static int omap2_nand_gpmc_retime(void)
return 0;
}
-static int gpmc_nand_setup(void)
-{
- struct device *dev = gpmc_nand_device.dev;
-
- /* Set timings in GPMC */
- if (omap2_nand_gpmc_retime() 0) {
- dev_err(dev, Unable to set gpmc timings\n);
- return -EINVAL;
- }
-
- return 0;
-}
-
int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
{
- unsigned int val;
int err = 0;
struct device *dev = gpmc_nand_device.dev;
gpmc_nand_data = _nand_data;
- gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_data-nand_setup = omap2_nand_gpmc_retime;
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
@@ -112,19 +96,17 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
- err = gpmc_nand_setup();
+/* Set timings in GPMC */
+ err = omap2_nand_gpmc_retime();
if (err 0) {
- dev_err(dev, NAND platform setup failed: %d\n, err);
+ dev_err(dev, Unable to set gpmc timings: %d\n, err);
return err;
}
/* Enable RD PIN Monitoring Reg */
if (gpmc_nand_data-dev_ready) {
- val = gpmc_cs_read_reg(gpmc_nand_data-cs,
-GPMC_CS_CONFIG1);
- val |= WR_RD_PIN_MONITORING;
- gpmc_cs_write_reg(gpmc_nand_data-cs,
- GPMC_CS_CONFIG1, val);
+ gpmc_hwcontrol(gpmc_nand_data-cs,
+ GPMC_CONFIG_RDY_BSY, 1, 1, NULL);
}
err = platform_device_register(gpmc_nand_device);
@@ -140,3 +122,4 @@ out_free_cs:
return err;
}
+
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 8a1e9d9..ccbc530
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -25,9 +25,6 @@
#define GPMC_CS_NAND_ADDRESS 0x20
#define GPMC_CS_NAND_DATA 0x24
-#define GPMC_CONFIG0x50
-#define GPMC_STATUS0x54
-
/* Control Commands */
#define GPMC_CONFIG_WP 0x0001
#define GPMC_CONFIG_RDY_BSY0x0002
@@ -63,7 +60,6 @@
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
-#define GPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(2)
#define GPMC_CONFIG1_MUXADDDATA (1 9)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val 3)
@@ -133,7 +129,6 @@ extern int gpmc_cs_reserved(int cs);
extern int gpmc_prefetch_enable(int cs, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
-extern int gpmc_prefetch_status(void);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
extern void gpmc_init(void);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index f8efd54..6562cd0
--- a/arch/arm/plat-omap/include/plat/nand.h
+++
RE: omap3 pm: dependency between opp layer and cpufreq
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Thursday, May 27, 2010 6:50 PM To: linux-omap@vger.kernel.org Subject: RE: omap3 pm: dependency between opp layer and cpufreq [snip]--[snip] diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 2b9ebf0..18d291f 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,7 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # OPP support in (OMAP3+ only at the moment) # XXX The OPP TWL/TPS code should only be included when a TWL/TPS # PMIC is selected. -ifdef CONFIG_CPU_FREQ +ifdef CONFIG_TWL4030_POWER obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o endif After sending the mail, I realized that inclusion of opp_twl_tps.o should depend upon CONFIG_TWL4030_POWER and opp.o should be included as default. ~sanjeev [snip]--[snip] -- 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)
On Thu, 27 May 2010, Florian Mickler wrote: On Wed, 26 May 2010 22:03:37 +0200 Vitaly Wool vitalyw...@gmail.com wrote: On Wed, May 26, 2010 at 9:56 PM, Florian Mickler flor...@mickler.org 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. No, it's not a historical mistake. It's a technical decision _NOT_ to merge crap. If we would accept every crappy patch which gets shipped in large quantities as a defacto part of the kernel we would have a completely unmaintainable mess since years. So why don't we do what we always do? Improve existing interfaces step by step? Exactly, that's what we are going to do. We improve and extend existing interfaces step by step, but not by creating a horrible and unmaintainable mess in the frist place which we can never get rid of anymore. 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. Nobody prevents you to sit down and start with a prove of concept implementation. 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)
On Wed, 26 May 2010, Florian Mickler wrote: On Wed, 26 May 2010 19:22:16 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: 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. Trying to solve that inside the kernel is the patently wrong approach. The only way to give Joe Clicker the ability to code his idea is to give him a restricted sandbox environment which takes care of the extra work and is created by knowledgable programmers with the Joe Clickers in mind. Every Joe Clicker can code websites and does this happily in his sandbox which consists of a web server and a web application framework. There is no single line of code in the kernel to make this work. As I said before we need new interfaces and new technologies to let the kernel do better power management, but definitely not a big hammer approach which is actively preventing the kernel to do smarter decisions. The correct approach is QoS based and everything else is just a bandaid which is going to hurt us badly. 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 know that this is the point of the approach, but that does not make it less wrong. Me, Alan and others explained already in great length why it is the wrong approach, but you refuse to listen. You remind me of my 14 year old son, who argues in circles to convince me that I must allow him something which is wrong. And if he would think about it w/o his primary goal of getting permission in mind he would concede that it's wrong. 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? The kernel loses the ability to remove suspend blockers once the interface is exposed to user space. That's the whole point. We would have to carry it on for a long time and trying to work around it when implementing a technical correct approach. And we have never seen crap move to a better interface. It will stay there forever and hell will break lose when we break it. 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) A mobile device can implement sensible defaults for the careless applications and let the good apps override them. - how much delay of wakeups is tolerated (missing interface) Doesn't solve the segregation problem and is probably overkill for most It solves the segregration problem quite nicely, as again it can be set to sensible defaults and to very long for the non verified apps. applications. I see this as an orthogonal thing (i.e. not affecting this merge). It's not orthogonal, it's essential to do QoS based power management, which is the only sensible technical solution to do, as it allows the kernel to optimize in various areas while at the same time guaranteeing the response time to applications which require them. Blockers are not orthogonal at all, as they
[PATCH] omap3: Increase limit on bootarg 'mpurate'
The value of mpurate is currently expected to be less than 1000 when specified in MHz. This patch raises this limit to 2000 to support 1GHz capable processors. The new limit should be reasonable for quite some time. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/clock.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 5261a09..7ea757e 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -175,6 +175,7 @@ EXPORT_SYMBOL(clk_get_parent); int __initdata mpurate; + /* * By default we use the rate set by the bootloader. * You can override this with mpurate= cmdline option. @@ -186,7 +187,7 @@ static int __init omap_clk_setup(char *str) if (!mpurate) return 1; - if (mpurate 1000) + if (mpurate 2000) mpurate *= 100; return 1; -- 1.6.6.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
[PATCHv2] omap3: Increase limit on bootarg 'mpurate'
The value of mpurate is currently expected to be less than 1000 when specified in MHz. This patch raises this limit to 2000 to support 1GHz capable processors. The new limit should be reasonable for quite some time. Signed-off-by: Sanjeev Premi pr...@ti.com --- v2: Removed a newline introduced in earlier patch --- arch/arm/plat-omap/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 5261a09..4fd1e15 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -186,7 +186,7 @@ static int __init omap_clk_setup(char *str) if (!mpurate) return 1; - if (mpurate 1000) + if (mpurate 2000) mpurate *= 100; return 1; -- 1.6.6.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
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:
- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a
latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those
later
- Suspend is just a power state
How does that fit your model and vision ?
I don't entirely see how this works. In order to deal with poorly
written applications, it's necessary to (optionally, based on some
policy) ignore them when it comes to the scheduler. The problem is how
to implement the optional nature of this in a race-free manner. This is
obviously a pathological case, but imagine an application that does
something along the following lines:
int input = open (/dev/input, O_RDONLY|O_NONBLOCK);
char foo;
while (1) {
suspend_block();
if (read(input, foo, 1) 0) {
(do something)
suspend_unblock();
} else {
suspend_unblock();
(draw bouncing cows and clouds and tractor beams briefly)
}
}
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains untrusted tasks - when the session is active we set a flag
one way which indicates to the scheduler that tasks in TASK_RUNNING
should be scheduled, and when the session is idle we set the flag the
other way and all processes in that cgroup get shifted to
TASK_INTERRUPTIBLE or something.
Except that doesn't work. If the session goes idle in the middle of the
app drawing a frame, we'll stop the process and the task will never call
read(). So the user hits a key, we wake up, nothing shifts from
TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go
back to sleep. The event never gets delivered.
Now let's try this in the Android world. The user hits a key and the
system wakes up. The input layer takes a suspend block. The application
now draws all the cows it wants to, takes its own suspend block and
reads the input device. This empties the queue and the kernel-level
suspend block is released. The application then processes the event
before releasing the suspend block. The event has been delivered and
handled.
You can't express that with resource limits or QoS constraints. If you
want to deal with this kind of situation then, as far as I can tell, you
need either suspend blockers or something so close to them that it makes
no difference.
--
Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
I don't entirely see how this works. In order to deal with poorly
written applications, it's necessary to (optionally, based on some
policy) ignore them when it comes to the scheduler. The problem is how
to implement the optional nature of this in a race-free manner. This is
obviously a pathological case, but imagine an application that does
something along the following lines:
int input = open (/dev/input, O_RDONLY|O_NONBLOCK);
char foo;
while (1) {
suspend_block();
if (read(input, foo, 1) 0) {
(do something)
suspend_unblock();
} else {
suspend_unblock();
(draw bouncing cows and clouds and tractor beams briefly)
}
}
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains untrusted tasks - when the session is active we set a flag
one way which indicates to the scheduler that tasks in TASK_RUNNING
should be scheduled, and when the session is idle we set the flag the
other way and all processes in that cgroup get shifted to
TASK_INTERRUPTIBLE or something.
What's wrong with simply making the phone beep loudly and displaying:
bouncing cows is preventing your phone from sleeping!
--
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)
On Wed, 26 May 2010, Arve Hjønnevåg wrote: 2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk: On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg a...@android.com wrote: On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk 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. It does not matter whether it's S3 or any other power saving state / mechanism in a particular device. What matters is that the kernel needs to know about the QoS requirements of the applications which are active to make optimal decisions for power management. If we can go into any given power state from idle then the decision which power state to select needs to be made on the requirements of an application to react on the next event (timer, interrupt, ...). So yes, we could go into S3 (with some effort) and arm the wakeup source which will bring us back when the requirements of the apps are known at the point where the decision is made. 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. You can express that in QoS requirements as well. If you say max wakeup latency 100ms then the kernel will select a power state which will meet this requirement. So it can decide whether to go into full suspend on a given system or select some other better suiting power saving mechanism. But this allows us to express this in a completely hardware independent way. If the hardware does not provide a suitable state, then the box stays on. 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. That's a matter of the current implementation. We can change that and improve it to do better resource management. And this requirement is not restricted to the mobile phone space, it's true for laptops, virtualization and other areas as well. 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 latency api is the right way to express this since the only latency values we would use is minimal-latency and
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote: one way which indicates to the scheduler that tasks in TASK_RUNNING should be scheduled, and when the session is idle we set the flag the other way and all processes in that cgroup get shifted to TASK_INTERRUPTIBLE or something. What's wrong with simply making the phone beep loudly and displaying: bouncing cows is preventing your phone from sleeping! Well, primarily that it's possible to design an implementation where it *doesn't* prevent your phone froms sleeping, but also because a given application may justifiably be preventing your phone from sleeping for a short while. What threshold do you use to determine the difference? -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote: one way which indicates to the scheduler that tasks in TASK_RUNNING should be scheduled, and when the session is idle we set the flag the other way and all processes in that cgroup get shifted to TASK_INTERRUPTIBLE or something. What's wrong with simply making the phone beep loudly and displaying: bouncing cows is preventing your phone from sleeping! Well, primarily that it's possible to design an implementation where it *doesn't* prevent your phone froms sleeping, but also because a given application may justifiably be preventing your phone from sleeping for a short while. What threshold do you use to determine the difference? Whatever you want, why would the kernel care? You can create a whole resource management layer in userspace, with different privilidge/trust levels. Trusted apps may wake more than untrusted apps. Who cares. The thing is, you can easily detect what keeps your cpu from idling. What you do about it a pure userspace solution. You can use the QoS stuff to give hints, like don't wake me more than 5 times a minute, if with those hints an app still doesn't meet whatever criteria are suitable for the current mode, yell at it. Or adjust its QoS parameters for it. Heck, for all I care, simply SIGKILL the thing and report it once the user starts looking at his screen 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)
On Thu, 2010-05-27 at 16:41 +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 15:35 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote: one way which indicates to the scheduler that tasks in TASK_RUNNING should be scheduled, and when the session is idle we set the flag the other way and all processes in that cgroup get shifted to TASK_INTERRUPTIBLE or something. What's wrong with simply making the phone beep loudly and displaying: bouncing cows is preventing your phone from sleeping! Well, primarily that it's possible to design an implementation where it *doesn't* prevent your phone froms sleeping, but also because a given application may justifiably be preventing your phone from sleeping for a short while. What threshold do you use to determine the difference? Whatever you want, why would the kernel care? You can create a whole resource management layer in userspace, with different privilidge/trust levels. Trusted apps may wake more than untrusted apps. Who cares. The thing is, you can easily detect what keeps your cpu from idling. What you do about it a pure userspace solution. You can use the QoS stuff to give hints, like don't wake me more than 5 times a minute, if with those hints an app still doesn't meet whatever criteria are suitable for the current mode, yell at it. Or adjust its QoS parameters for it. Heck, for all I care, simply SIGKILL the thing and report it once the user starts looking at his screen again. Provide incentive for Joe Clicker to improve his app, instead of cope with the shit he created. -- 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)
Now, if the user is playing this game, you want it to be scheduled. If the user has put down their phone and the screen lock has kicked in, you don't want it to be scheduled. So we could imagine some sort of cgroup that contains untrusted tasks - when the session is active we set a flag I would hope not, because I'd rather prefer my app that used the screen to get the chance to save important data on what it was doing irrespective of the screen blank: I have an elegant proof for this problem but my battery has gone flat (and I imagine we can play that examples game forever given Ashby's law) You can't express that with resource limits or QoS constraints. I don't see why not. You just have to think about the problem from the right end. Start from normality is well behaved applications and progress to but I can constrain bogus ones. So what are the resource constraints/QoS constraints for your example: [Simplistically] 1. App says 'I want to wakeup from events for me within 1 second' (Because I like drawing cows at about that rate) 2. App open driver for buttons 3. App opens driver for screen Driver for buttons goes 'humm, well I can trigger wakeup from all power states so I need no restrictions'. Screen will vary by device a lot. (I'll come back to the screen a bit more in a moment) So lets consider the same binary App runs on OLPC like h/w The pm code goes 'well I can suspend/resume in a second thats cool' The screen code goes 'Hey I've got OLPC like video so thats ok' The button driver can wake the system from suspend and queue an event App runs on Android like h/w The pm code goes 'well I can suspend/resume in a second thats cool' The screen code goes 'Gee the screen goes blank if I go below level X' so I'll set a limit The button driver can wake the system from suspend and queue an event App runs on Android like h/w but not trusted The pm code goes 'well tough, you can't do that, I'll refuse you' (Maybe user space wrapped by Android with a 'Cows wants to eat your phone alive [Refuse] [This Time Only] [Always] UI User hits refuse and Android duly assigns the code no guarantee and a hard limit of no guarantee. The screen code goes 'tough' The button driver can wake the system etc Cows will get suspended for longer than one second whether it likes it or not App runs on a desktop PC The pm code goes 'well I can't do suspend/resume in 1 second, but I can do C6' The screen goes 'I need C6' The button driver goes 'I need C6' Same app in each case and a lot less syscalls. No pathalogical cases either - with suspend blockers you can get emergent synchronization patterns between applications where each app rarely blocks suspends but together their timings fall such that they never allow it. How do you propose to even detect that ? Ok now the screen If I write to an X server and the server doesn't wish to talk to me it ignores the stream and I block. This has been the case since the 1980s. What is the problem here - your device driver for the display can block tasks it doesn't want to use the display. -- 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)
Heck, for all I care, simply SIGKILL the thing and report it once the user starts looking at his screen again. Provide incentive for Joe Clicker to improve his app, instead of cope with the shit he created. That isn't helpful. But if you feel like that I suggest you run with your memory management protection disabled, it's really on there to deal with crap code and its giving the wrong incentives. Come to think of it you might want to remove your seatbelts and any safety catches or airbags - it only encourages carelessness. The reality is you need a sane, generic, race free way to express your requirements (eg for hard RT) and ditto for constraining the expression (for 'crapplications') Arguing that you don't need to do this isn't useful. Android has demonstrated a need to do this. RT has a need to do some of this. Virtualisation wants elements of this etc. The question is how you do it right. -- 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)
On Thu, 2010-05-27 at 16:05 +0100, Alan Cox wrote: What is the problem here - your device driver for the display can block tasks it doesn't want to use the display. Very well put again. I bet the next example is a proglet that does: while(1); without device interaction :-). -- 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)
If people don't mind, here is a greatly simplified summary of the comments and objections I have seen so far on this thread: The in-kernel suspend blocker implementation is okay, even beneficial. Opportunistic suspends are okay. The proposed userspace API is too Android-specific. More kernel mechanisms are needed for expressing processes' latency requirements. The last one is obviously a longer-term issue, so let's ignore it for now. That leaves as the only point of contention the userspace suspend-blocker API. The proposal I made a couple of days ago removes this API and leaves the other things (i.e., the in-kernel suspend blockers and opportunistic suspend) intact. In place of the userspace kernel-blocker API, Android would have to implement a power manager process that would essentially juggle all the latency requirements in userspace. Communication between the power manager process and the kernel would be limited to adding a new opportunistic entry to /sys/power/state -- something which could well be useful in its own right. Even if this API turns out not to be good, it's simple enough that it could be removed pretty easily. This answers Alan Cox's (and other's) desire not to implement a questionable or special-purpose API. And it also answers Thomas's desire to make scheduling decisions based on latency requirements (although the answer is simply to punt all these decisions out of the kernel and into userspace -- which is reasonable for now since the alternative would require a long-term kernel development effort). Indeed, having a power manager thread may well turn out to be a useful thing -- but even if it doesn't, this scheme minimizes the damage while still allowing the Android platform to use a vanilla kernel with only limited modifications to their userspace. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-05-27 at 16:10 +0100, Alan Cox wrote: Heck, for all I care, simply SIGKILL the thing and report it once the user starts looking at his screen again. Provide incentive for Joe Clicker to improve his app, instead of cope with the shit he created. That isn't helpful. But if you feel like that I suggest you run with your memory management protection disabled, it's really on there to deal with crap code and its giving the wrong incentives. Come to think of it you might want to remove your seatbelts and any safety catches or airbags - it only encourages carelessness. The reality is you need a sane, generic, race free way to express your requirements (eg for hard RT) and ditto for constraining the expression (for 'crapplications') Arguing that you don't need to do this isn't useful. Android has demonstrated a need to do this. RT has a need to do some of this. Virtualisation wants elements of this etc. Sure, I fully agree with the task and per device QoS stuff. I'm just saying that its good to inform the user that some app is severely mis-behaving. -- 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)
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: Opportunistic suspends are okay. The proposed userspace API is too Android-specific. I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant. -- 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)
The proposal I made a couple of days ago removes this API and leaves the other things (i.e., the in-kernel suspend blockers and opportunistic suspend) intact. In place of the userspace kernel-blocker API, Android would have to implement a power manager process that would essentially juggle all the latency requirements in userspace. On the kernel side you really want to add two arguments from day one which is the time in ms and the power state. We have enumerations of current power states (plus add suspend) so this is easy to do. The governors may not use them for a while but ACPI for example can use the latency pretty fast. You want the information there from day one so it is captured otherwise it ends up a right royal pain in the arse adjusting the API later. If the numbers are in but don't always get used it'll be a lot smoother. Communication between the power manager process and the kernel would be limited to adding a new opportunistic entry to /sys/power/state -- something which could well be useful in its own right. Even if this API turns out not to be good, it's simple enough that it could be removed pretty easily. Yes. Probably it really should be linked to a cpufreq driver thing - cpufreq_android or whatever being the starting point but thats not a big deal and it doesn't leak into all the apps either. This is detail however. Indeed, having a power manager thread may well turn out to be a useful thing -- but even if it doesn't, this scheme minimizes the damage while still allowing the Android platform to use a vanilla kernel with only limited modifications to their userspace. There have been some horribly bad attempts to do this, but if it works for Android and its encapsulated in cpufreq_android.c maybe with a private interface to a single supporting daemon then it's not creating bad user APIs, its not peeing in anyone elses pond and the policy will all be in the kernel and a daemon which keeps the wrong platform knowledge out of the application space. 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)
On Thu, 27 May 2010 17:09:16 +0200 Peter Zijlstra pet...@infradead.org wrote: On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: Opportunistic suspends are okay. The proposed userspace API is too Android-specific. I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant. Assuming you are happy that opportunistically entering C6 and the like is ok via ACPI can you explain why you have a problem with opportunistic suspend and why it is different to a very deep sleep CPU state such as we have now (and which on many embedded platforms we deal with *is* sleeping external devices too) 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)
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:
- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a
latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those
later
- Suspend is just a power state
How does that fit your model and vision ?
I don't entirely see how this works. In order to deal with poorly
written applications, it's necessary to (optionally, based on some
policy) ignore them when it comes to the scheduler. The problem is how
to implement the optional nature of this in a race-free manner. This is
obviously a pathological case, but imagine an application that does
something along the following lines:
int input = open (/dev/input, O_RDONLY|O_NONBLOCK);
char foo;
while (1) {
suspend_block();
if (read(input, foo, 1) 0) {
(do something)
suspend_unblock();
} else {
suspend_unblock();
(draw bouncing cows and clouds and tractor beams briefly)
}
}
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains untrusted tasks - when the session is active we set a flag
one way which indicates to the scheduler that tasks in TASK_RUNNING
should be scheduled, and when the session is idle we set the flag the
other way and all processes in that cgroup get shifted to
TASK_INTERRUPTIBLE or something.
Except that doesn't work. If the session goes idle in the middle of the
app drawing a frame, we'll stop the process and the task will never call
read(). So the user hits a key, we wake up, nothing shifts from
TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go
back to sleep. The event never gets delivered.
Now let's try this in the Android world. The user hits a key and the
system wakes up. The input layer takes a suspend block. The application
now draws all the cows it wants to, takes its own suspend block and
reads the input device. This empties the queue and the kernel-level
suspend block is released. The application then processes the event
before releasing the suspend block. The event has been delivered and
handled.
Thanks for providing this example:
1) It proves that suspend blockers are solely designed to encourage
people to code crap.
2) It exposes the main conceptual problem of the approach:
The input layer in the kernel magically takes a suspend blocker
and releases it in an equally magic way just to allow the crappy
application to reach the point where it takes it's own suspend
blocker and can react on the user input.
And you need to do that, because the user applications suspend
blocker magic is racy as hell. To work around that you sprinkle
your suspend blocker magic all over the kernel instead of telling
people how to solve the problem correctly.
And what are you achieving with this versus power saving ?
Exaclty _NOTHING_ !
Simply because you move the cow drawing CPU time from the point
where the device wants to go into suspend to the point where the
user hits a key again. You even delay the reaction of your app to
the user input by the time it needs to finish drawing cows.
So you need to come up with a way better example why you need
your blockers than with this prove of misconception.
You can't express that with resource limits or QoS constraints. If you
want to deal with this kind of situation then, as far as I can tell, you
need either suspend blockers or something so close to them that it makes
no difference.
Wrong. If your application is interactive then you set the QoS
requirement once to interactive and be done.
So the correct point to make a power state decision is when the app
waits for a key press. At this point the kernel can take several
pathes:
1) Keep the system alive because the input device is in active
state and a key press is expected
2) Go into supsend because the input device is deactivated after
the screen lock kicked in.
This behaves exactly the same way in terms of power consumption as
your blocker example just without all the mess you are trying to
create.
And it allows the kernel to use intermediate power saving methods
(between idle and suspend) which might be available on some hardware.
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: On Thu, 27 May 2010 17:09:16 +0200 Peter Zijlstra pet...@infradead.org wrote: On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: Opportunistic suspends are okay. The proposed userspace API is too Android-specific. I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant. Assuming you are happy that opportunistically entering C6 and the like is ok via ACPI can you explain why you have a problem with opportunistic suspend and why it is different to a very deep sleep CPU state such as we have now (and which on many embedded platforms we deal with *is* sleeping external devices too) Agreed, but I understood the opportunistic suspend line from Alan Stern to mean the echo opportunistic /sys/power/foo thing. If you view it as an extra deep idle state I have no problem with it (because its simply an idle state, nothing magic about those). -- 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)
On Thu, 27 May 2010, Peter Zijlstra wrote: On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: On Thu, 27 May 2010 17:09:16 +0200 Peter Zijlstra pet...@infradead.org wrote: On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: Opportunistic suspends are okay. The proposed userspace API is too Android-specific. I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant. Assuming you are happy that opportunistically entering C6 and the like is ok via ACPI can you explain why you have a problem with opportunistic suspend and why it is different to a very deep sleep CPU state such as we have now (and which on many embedded platforms we deal with *is* sleeping external devices too) Agreed, but I understood the opportunistic suspend line from Alan Stern to mean the echo opportunistic /sys/power/foo thing. Yes, that's what I meant. Why do you think it is any worse than echo mem /sys/power/state? The only difference is that it will block until all in-kernel suspend blockers are disabled. Or do you also think that echo mem /sys/power/state is evil and should be removed from the kernel as soon as possible? And to answer Thomas's question: The whole reason for having in-kernel suspend blockers is so that userspace can tell the system to suspend without losing wakeup events. Suppose a key is pressed just as a user program writes mem to /sys/power/state. The keyboard driver handles the keystroke and queues an input event. Then the system suspends and doesn't wake up until some other event occurs -- even though the keypress was an important one and it should have prevented the system from suspending. With in-kernel suspend blockers and opportunistic suspend, this scenario is prevented. That is their raison-d'etre. 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
[PATCH v3 0/7] DSPBRIDGE: fix mem+cache API issues
This patchset introduces an approach to eliminate the direct calls to follow_page and to the low level cache APIs. The patchset works by caching the page information while memory is mapped, and then using that information later when needed instead of calling follow_page. The low level cache API is then replaced by standard DMA API. Changes from v2: * Fix rebase error that plagued the v2 series * Added some debug logs to help analyzing missing mapping issues Notes: 1. The global bridge device struct is used by adding an 'extern' to proc. This issue should be handled in a different patch series (the struct should not be global. instead, it should be accessible to the dspbridge code via one of the context objects. This way we will also be able to transform pr_* prints to dev_* prints). 2. The patchset was tested with testsuite, DMM sample app and varios MM and recovery scenarios. Many thanks to Ivan Gomez Castellanos for the help here. Also Many thanks to Felipe Contreras for the thorough review, comments and testing. Thanks, Ohad. --- If you want, you can also reach me at ohadb at ti dot com . Ohad Ben-Cohen (7): DSPBRIDGE: enhance dmm_map_object DSPBRIDGE: maintain mapping and page info DSPBRIDGE: do not call follow_page DSPBRIDGE: do not use low level cache manipulation API DSPBRIDGE: remove mem_flush_cache DSPBRIDGE: add dspbridge API to mark end of DMA DSPBRIDGE: add new PROC_BEGINDMA and PROC_ENDDMA ioctls arch/arm/plat-omap/include/dspbridge/drv.h | 32 +- .../arm/plat-omap/include/dspbridge/dspapi-ioctl.h |9 + arch/arm/plat-omap/include/dspbridge/dspapi.h |2 + arch/arm/plat-omap/include/dspbridge/dspdefs.h |3 +- arch/arm/plat-omap/include/dspbridge/proc.h| 29 ++ drivers/dsp/bridge/core/io_sm.c| 11 +- drivers/dsp/bridge/core/tiomap3430.c |9 +- drivers/dsp/bridge/pmgr/dspapi.c | 34 ++- drivers/dsp/bridge/rmgr/drv.c | 33 -- drivers/dsp/bridge/rmgr/proc.c | 410 10 files changed, 433 insertions(+), 139 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] DSPBRIDGE: enhance dmm_map_object
Enhance dmm_map_object to support additional mapping
and page information. This will be used to keep
track of mapping resources needed later to invoke
DMA transfers to/from the DSP.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/include/dspbridge/drv.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index 7de3323..b1312aa 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -88,6 +88,10 @@ struct node_res_object {
struct dmm_map_object {
struct list_head link;
u32 dsp_addr;
+ u32 mpu_addr;
+ u32 size;
+ u32 num_usr_pgs;
+ struct page **pages;
};
/* Used for DMM reserved memory accounting */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] DSPBRIDGE: maintain mapping and page info
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 o...@wizery.com --- 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..79d42ad 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_context *hDevContext, u32 ulVirtAddr, u32 ul_num_bytes); static dsp_status bridge_dev_create(OUT struct bridge_dev_context @@ -1208,7 +1209,8 @@ static dsp_status
[PATCH v3 3/7] DSPBRIDGE: do not call follow_page
Eliminate the call to follow_page. Instead, use the page
information that was kept during the proc_map call.
This also has the advantage that users can now only
specify memory areas that were previously mapped.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
You can also reach me at ohadb at ti dot com .
drivers/dsp/bridge/pmgr/dspapi.c |4 +-
drivers/dsp/bridge/rmgr/proc.c | 148 +-
2 files changed, 99 insertions(+), 53 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/dspapi.c b/drivers/dsp/bridge/pmgr/dspapi.c
index 05ea853..cc64a99 100644
--- a/drivers/dsp/bridge/pmgr/dspapi.c
+++ b/drivers/dsp/bridge/pmgr/dspapi.c
@@ -688,7 +688,7 @@ u32 procwrap_flush_memory(union Trapped_Args *args, void
*pr_ctxt)
PROC_WRITEBACK_INVALIDATE_MEM)
return -EINVAL;
- status = proc_flush_memory(args-args_proc_flushmemory.hprocessor,
+ status = proc_flush_memory(pr_ctxt,
args-args_proc_flushmemory.pmpu_addr,
args-args_proc_flushmemory.ul_size,
args-args_proc_flushmemory.ul_flags);
@@ -703,7 +703,7 @@ u32 procwrap_invalidate_memory(union Trapped_Args *args,
void *pr_ctxt)
dsp_status status;
status =
- proc_invalidate_memory(args-args_proc_invalidatememory.hprocessor,
+ proc_invalidate_memory(pr_ctxt,
args-args_proc_invalidatememory.pmpu_addr,
args-args_proc_invalidatememory.ul_size);
return status;
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 37258c4..6628483 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -189,6 +189,75 @@ out:
spin_unlock(pr_ctxt-dmm_map_lock);
}
+static int match_containing_map_obj(struct dmm_map_object *map_obj,
+ u32 mpu_addr, u32 size)
+{
+ u32 map_obj_end = map_obj-mpu_addr + map_obj-size;
+
+ return mpu_addr = map_obj-mpu_addr
+ mpu_addr + size = map_obj_end;
+}
+
+static struct dmm_map_object *find_containing_mapping(
+ struct process_context *pr_ctxt,
+ u32 mpu_addr, u32 size)
+{
+ struct dmm_map_object *map_obj;
+ pr_debug(%s: looking for mpu_addr 0x%x size 0x%x\n, __func__,
+ mpu_addr, size);
+
+ spin_lock(pr_ctxt-dmm_map_lock);
+ list_for_each_entry(map_obj, pr_ctxt-dmm_map_list, link) {
+ pr_debug(%s: candidate: mpu_addr 0x%x virt 0x%x size 0x%x\n,
+ __func__,
+ map_obj-mpu_addr,
+ map_obj-dsp_addr,
+ map_obj-size);
+ if (match_containing_map_obj(map_obj, mpu_addr, size)) {
+ pr_debug(%s: match!\n, __func__);
+ goto out;
+ }
+
+ pr_debug(%s: no match!\n, __func__);
+ }
+
+ map_obj = NULL;
+out:
+ spin_unlock(pr_ctxt-dmm_map_lock);
+ return map_obj;
+}
+
+static int find_first_page_in_cache(struct dmm_map_object *map_obj,
+ unsigned long mpu_addr)
+{
+ u32 mapped_base_page = map_obj-mpu_addr PAGE_SHIFT;
+ u32 requested_base_page = mpu_addr PAGE_SHIFT;
+ int pg_index = requested_base_page - mapped_base_page;
+
+ if (pg_index 0 || pg_index = map_obj-num_usr_pgs) {
+ pr_err(%s: failed (got %d)\n, __func__, pg_index);
+ return -1;
+ }
+
+ pr_debug(%s: first page is %d\n, __func__, pg_index);
+ return pg_index;
+}
+
+static inline struct page *get_mapping_page(struct dmm_map_object *map_obj,
+ int pg_i)
+{
+ pr_debug(%s: looking for pg_i %d, num_usr_pgs: %d\n, __func__,
+ pg_i, map_obj-num_usr_pgs);
+
+ if (pg_i 0 || pg_i = map_obj-num_usr_pgs) {
+ pr_err(%s: requested pg_i %d is out of mapped range\n,
+ __func__, pg_i);
+ return NULL;
+ }
+
+ return map_obj-pages[pg_i];
+}
+
/*
* proc_attach
* Purpose:
@@ -537,23 +606,30 @@ dsp_status proc_enum_nodes(void *hprocessor, void
**node_tab,
}
/* Cache operation against kernel address instead of users */
-static int memory_sync_page(struct vm_area_struct *vma, unsigned long start,
- ssize_t len, enum dsp_flushtype ftype)
+static int memory_sync_page(struct dmm_map_object *map_obj,
+ unsigned long start, ssize_t len, enum dsp_flushtype ftype)
{
struct page *page;
void *kaddr;
unsigned
[PATCH v3 4/7] DSPBRIDGE: do not use low level cache manipulation API
Instead of using low level cache manipulation API,
use the standard DMA API. This is achieved by adding
a proc_begin_dma function that takes a generic
dma_data_direction, and then implementing proc_flush_memory
and proc_invalidate_memory by means of proc_begin_dma
in the following manner:
* flush calls proc_begin_dma with DMA_BIDIRECTIONAL
* Invalidate calls proc_begin_dma with DMA_FROM_DEVICE
proc_begin_dma builds a scatter gatter list using the
page information that was kept during proc_map,
and feed it to the standard dma_map_sg API.
Note that now users cannot manipulate the cache state of any random
address; if the buffer is not part of a previous memory mapping of that
application, the request is denied.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/include/dspbridge/drv.h | 13 +++
drivers/dsp/bridge/rmgr/proc.c | 119 +---
2 files changed, 104 insertions(+), 28 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index b1312aa..3186935 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -84,6 +84,18 @@ struct node_res_object {
struct node_res_object *next;
};
+/* used to cache dma mapping information */
+struct bridge_dma_map_info {
+ /* direction of DMA in action, or DMA_NONE */
+ enum dma_data_direction dir;
+ /* number of elements requested by us */
+ int num_pages;
+ /* number of elements returned from dma_map_sg */
+ int sg_num;
+ /* list of buffers used in this DMA action */
+ struct scatterlist *sg;
+};
+
/* Used for DMM mapped memory accounting */
struct dmm_map_object {
struct list_head link;
@@ -92,6 +104,7 @@ struct dmm_map_object {
u32 size;
u32 num_usr_pgs;
struct page **pages;
+ struct bridge_dma_map_info dma_info;
};
/* Used for DMM reserved memory accounting */
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 6628483..2710a11 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -17,6 +17,8 @@
*/
/* Host OS */
+#include linux/dma-mapping.h
+#include linux/scatterlist.h
#include dspbridge/host_os.h
/* --- DSP/BIOS Bridge */
@@ -74,6 +76,8 @@
#define RBUF 0x4000 /* Input buffer */
#define WBUF 0x8000 /* Output Buffer */
+extern struct device *bridge;
+
/* --- Globals */
/* The proc_object structure. */
@@ -177,6 +181,7 @@ static void remove_mapping_information(struct
process_context *pr_ctxt,
if (match_exact_map_obj(map_obj, dsp_addr, size)) {
pr_debug(%s: match, deleting map info\n, __func__);
list_del(map_obj-link);
+ kfree(map_obj-dma_info.sg);
kfree(map_obj-pages);
kfree(map_obj);
goto out;
@@ -606,49 +611,108 @@ dsp_status proc_enum_nodes(void *hprocessor, void
**node_tab,
}
/* Cache operation against kernel address instead of users */
-static int memory_sync_page(struct dmm_map_object *map_obj,
- unsigned long start, ssize_t len, enum dsp_flushtype ftype)
+static int build_dma_sg(struct dmm_map_object *map_obj, unsigned long start,
+ ssize_t len, int pg_i)
{
struct page *page;
- void *kaddr;
unsigned long offset;
ssize_t rest;
- int pg_i;
-
- pg_i = find_first_page_in_cache(map_obj, start);
- if (pg_i 0) {
- pr_err(%s: failed to find first page in cache\n, __func__);
- return -EINVAL;
- }
+ int ret = 0, i = 0;
+ struct scatterlist *sg = map_obj-dma_info.sg;
while (len) {
page = get_mapping_page(map_obj, pg_i);
if (!page) {
pr_err(%s: no page for %08lx\n, __func__, start);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
} else if (IS_ERR(page)) {
pr_err(%s: err page for %08lx(%lu)\n, __func__, start,
PTR_ERR(page));
- return PTR_ERR(page);
+ ret = PTR_ERR(page);
+ goto out;
}
offset = start ~PAGE_MASK;
- kaddr = kmap(page) + offset;
rest = min_t(ssize_t, PAGE_SIZE - offset, len);
- mem_flush_cache(kaddr, rest, ftype);
- kunmap(page);
+ sg_set_page(sg[i], page, rest, offset);
+
len -= rest;
start +=
[PATCH v3 5/7] DSPBRIDGE: remove mem_flush_cache
Now that we use standard DMA API instead of low level cache
manipulation API, mem_flush_cache can be removed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
arch/arm/plat-omap/include/dspbridge/drv.h | 15
drivers/dsp/bridge/rmgr/drv.c | 33
2 files changed, 0 insertions(+), 48 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index 3186935..2eeb47f 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -466,21 +466,6 @@ extern void *mem_alloc_phys_mem(IN u32 byte_size,
IN u32 ulAlign, OUT u32 *pPhysicalAddress);
/*
- * mem_flush_cache
- * Purpose:
- * Performs system cache sync with discard
- * Parameters:
- * pMemBuf:Pointer to memory region to be flushed.
- * pMemBuf:Size of the memory region to be flushed.
- * Returns:
- * Requires:
- * MEM is initialized.
- * Ensures:
- * Cache is synchronized
- */
-extern void mem_flush_cache(void *pMemBuf, u32 byte_size, s32 FlushType);
-
-/*
* mem_free_phys_mem
* Purpose:
* Free the given block of physically contiguous memory.
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index a8e711a..6ffae0b 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1039,39 +1039,6 @@ void *mem_alloc_phys_mem(u32 byte_size, u32 ulAlign, OUT
u32 * pPhysicalAddress)
}
/*
- * mem_flush_cache
- * Purpose:
- * Flush cache
- */
-void mem_flush_cache(void *pMemBuf, u32 byte_size, s32 FlushType)
-{
- if (!pMemBuf)
- return;
-
- switch (FlushType) {
- /* invalidate only */
- case PROC_INVALIDATE_MEM:
- dmac_inv_range(pMemBuf, pMemBuf + byte_size);
- outer_inv_range(__pa((u32) pMemBuf), __pa((u32) pMemBuf +
- byte_size));
- break;
- /* writeback only */
- case PROC_WRITEBACK_MEM:
- dmac_clean_range(pMemBuf, pMemBuf + byte_size);
- outer_clean_range(__pa((u32) pMemBuf), __pa((u32) pMemBuf +
- byte_size));
- break;
- /* writeback and invalidate */
- case PROC_WRITEBACK_INVALIDATE_MEM:
- dmac_flush_range(pMemBuf, pMemBuf + byte_size);
- outer_flush_range(__pa((u32) pMemBuf), __pa((u32) pMemBuf +
- byte_size));
- break;
- }
-
-}
-
-/*
* mem_free_phys_mem
* Purpose:
* Free the given block of physically contiguous memory.
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] DSPBRIDGE: add dspbridge API to mark end of DMA
Add new dspbridge API that ends DMA transfers.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
drivers/dsp/bridge/rmgr/proc.c | 68
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 2710a11..e952d2e 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -653,6 +653,36 @@ out:
return ret;
}
+static int memory_regain_ownership(struct dmm_map_object *map_obj,
+ unsigned long start, ssize_t len, enum dma_data_direction dir)
+{
+ int ret = 0;
+ unsigned long first_data_page = start PAGE_SHIFT;
+ unsigned long last_data_page = ((u32)(start + len - 1) PAGE_SHIFT);
+ /* calculating the number of pages this area spans */
+ unsigned long num_pages = last_data_page - first_data_page + 1;
+ struct bridge_dma_map_info *dma_info = map_obj-dma_info;
+
+ if (!dma_info-sg)
+ goto out;
+
+ if (dma_info-dir != dir || dma_info-num_pages != num_pages) {
+ pr_err(%s: dma info doesn't match given params\n, __func__);
+ return -EINVAL;
+ }
+
+ dma_unmap_sg(bridge, dma_info-sg, num_pages, dma_info-dir);
+
+ pr_debug(%s: dma_map_sg unmapped\n, __func__);
+
+ kfree(dma_info-sg);
+
+ map_obj-dma_info.sg = NULL;
+
+out:
+ return ret;
+}
+
/* Cache operation against kernel address instead of users */
static int memory_give_ownership(struct dmm_map_object *map_obj,
unsigned long start, ssize_t len, enum dma_data_direction dir)
@@ -749,6 +779,44 @@ err_out:
return status;
}
+static int proc_end_dma(void *hprocessor, void *pmpu_addr, u32 ul_size,
+ enum dma_data_direction dir)
+{
+ /* Keep STATUS here for future additions to this function */
+ int status = 0;
+ struct process_context *pr_ctxt = (struct process_context *) hprocessor;
+ struct dmm_map_object *map_obj;
+
+ DBC_REQUIRE(refs 0);
+
+ if (!pr_ctxt) {
+ status = -EFAULT;
+ goto err_out;
+ }
+
+ pr_debug(%s: addr 0x%x, size 0x%x, type %d\n, __func__,
+ (u32)pmpu_addr,
+ ul_size, dir);
+
+ /* find requested memory are in cached mapping information */
+ map_obj = find_containing_mapping(pr_ctxt, (u32) pmpu_addr, ul_size);
+ if (!map_obj) {
+ pr_err(%s: find_containing_mapping failed\n, __func__);
+ status = -EFAULT;
+ goto err_out;
+ }
+
+ if (memory_regain_ownership(map_obj, (u32) pmpu_addr, ul_size, dir)) {
+ pr_err(%s: InValid address parameters %p %x\n,
+ __func__, pmpu_addr, ul_size);
+ status = -EFAULT;
+ goto err_out;
+ }
+
+err_out:
+ return status;
+}
+
/*
* proc_flush_memory
* Purpose:
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/7] DSPBRIDGE: add new PROC_BEGINDMA and PROC_ENDDMA ioctls
Add two new dspbridge ioctls that mark the
beginnind and end of a DMA transfer.
The direction of the DMA transfer is given as a parameter,
thus all three directions (DMA_BIDIRECTIONAL, DMA_TO_DEVICE
and DMA_FROM_DEVICE) are supported.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
If you want, you can also reach me at ohadb at ti dot com .
.../arm/plat-omap/include/dspbridge/dspapi-ioctl.h |9 ++
arch/arm/plat-omap/include/dspbridge/dspapi.h |2 +
arch/arm/plat-omap/include/dspbridge/proc.h| 29 +++
drivers/dsp/bridge/pmgr/dspapi.c | 30
drivers/dsp/bridge/rmgr/proc.c |4 +-
5 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
b/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
index 1780855..6ed2dcc 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspapi-ioctl.h
@@ -153,6 +153,13 @@ union Trapped_Args {
void *hprocessor;
void *pmpu_addr;
u32 ul_size;
+ u32 dir;
+ } args_proc_dma;
+
+ struct {
+ void *hprocessor;
+ void *pmpu_addr;
+ u32 ul_size;
u32 ul_flags;
} args_proc_flushmemory;
@@ -426,6 +433,8 @@ union Trapped_Args {
#define PROC_FLUSHMEMORY _IOW(DB, DB_IOC(DB_PROC, 14), unsigned long)
#define PROC_STOP _IOWR(DB, DB_IOC(DB_PROC, 15), unsigned long)
#define PROC_INVALIDATEMEMORY _IOW(DB, DB_IOC(DB_PROC, 16), unsigned long)
+#define PROC_BEGINDMA _IOW(DB, DB_IOC(DB_PROC, 17), unsigned long)
+#define PROC_ENDDMA_IOW(DB, DB_IOC(DB_PROC, 18), unsigned long)
/* NODE Module */
#define NODE_ALLOCATE _IOWR(DB, DB_IOC(DB_NODE, 0), unsigned long)
diff --git a/arch/arm/plat-omap/include/dspbridge/dspapi.h
b/arch/arm/plat-omap/include/dspbridge/dspapi.h
index 565c800..e821c7b 100644
--- a/arch/arm/plat-omap/include/dspbridge/dspapi.h
+++ b/arch/arm/plat-omap/include/dspbridge/dspapi.h
@@ -126,6 +126,8 @@ extern u32 procwrap_un_map(union Trapped_Args *args, void
*pr_ctxt);
extern u32 procwrap_flush_memory(union Trapped_Args *args, void *pr_ctxt);
extern u32 procwrap_stop(union Trapped_Args *args, void *pr_ctxt);
extern u32 procwrap_invalidate_memory(union Trapped_Args *args, void *pr_ctxt);
+extern u32 procwrap_begin_dma(union Trapped_Args *args, void *pr_ctxt);
+extern u32 procwrap_end_dma(union Trapped_Args *args, void *pr_ctxt);
/* NODE wrapper functions */
extern u32 nodewrap_allocate(union Trapped_Args *args, void *pr_ctxt);
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 18b51c5..58fcdea 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -456,6 +456,35 @@ extern dsp_status proc_start(void *hprocessor);
extern dsp_status proc_stop(void *hprocessor);
/*
+ * proc_end_dma
+ * Purpose:
+ * Begin a DMA transfer
+ * Parameters:
+ * hprocessor : The processor handle.
+ * pmpu_addr : Buffer start address
+ * ul_size: Buffer size
+ * dir: The direction of the transfer
+ * Requires:
+ * Memory was previously mapped.
+ */
+extern int proc_end_dma(void *hprocessor, void *pmpu_addr, u32 ul_size,
+ enum dma_data_direction dir);
+/*
+ * proc_begin_dma
+ * Purpose:
+ * Begin a DMA transfer
+ * Parameters:
+ * hprocessor : The processor handle.
+ * pmpu_addr : Buffer start address
+ * ul_size: Buffer size
+ * dir: The direction of the transfer
+ * Requires:
+ * Memory was previously mapped.
+ */
+extern int proc_begin_dma(void *hprocessor, void *pmpu_addr, u32 ul_size,
+ enum dma_data_direction dir);
+
+/*
* proc_flush_memory
* Purpose:
* Flushes a buffer from the MPU data cache.
diff --git a/drivers/dsp/bridge/pmgr/dspapi.c b/drivers/dsp/bridge/pmgr/dspapi.c
index cc64a99..2da2021 100644
--- a/drivers/dsp/bridge/pmgr/dspapi.c
+++ b/drivers/dsp/bridge/pmgr/dspapi.c
@@ -113,6 +113,8 @@ static struct api_cmd proc_cmd[] = {
{procwrap_flush_memory},/* PROC_FLUSHMEMORY */
{procwrap_stop},/* PROC_STOP */
{procwrap_invalidate_memory}, /* PROC_INVALIDATEMEMORY */
+ {procwrap_begin_dma}, /* PROC_BEGINDMA */
+ {procwrap_end_dma}, /* PROC_ENDDMA */
};
/* NODE wrapper functions */
@@ -677,6 +679,34 @@ u32 procwrap_enum_node_info(union Trapped_Args *args, void
*pr_ctxt)
return status;
}
+u32 procwrap_end_dma(union Trapped_Args *args, void *pr_ctxt)
+{
+ dsp_status status;
+
+
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains untrusted tasks - when the session is active we set a flag
I would hope not, because I'd rather prefer my app that used the screen
to get the chance to save important data on what it was doing
irrespective of the screen blank: I have an elegant proof for this
problem but my battery has gone flat
Perhaps set after callbacks are made. But given that the approach
doesn't work anyway...
What is the problem here - your device driver for the display can block
tasks it doesn't want to use the display.
It's still racy. Going back to my example without any of the suspend
blocking code, but using a network socket rather than an input device:
int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, addr, sizeof(addr))
while (1) {
if (read(input, foo, 1) 0) {
(do something)
} else {
(draw bouncing cows and clouds and tractor beams briefly)
}
}
A network packet arrives while we're drawing. Before we finish drawing,
the policy timeout expires and the screen turns off. The app's drawing
is blocked and so never gets to the point of reading the socket. The
wakeup event has been lost.
--
Matthew Garrett | mj...@srcf.ucam.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 v2] serial: Add OMAP high-speed UART driver
On Wednesday 26 May 2010 05:48:58 pm Kevin Hilman wrote: FYI... this also works on OMAP2. I tested it on my n810 along with UART hwmod conversion and it works just fine there. Is it somehow different from the basic 8250 driver on OMAP2? I've been struggling to figure out why my N810's GPS isn't working when I change kernels (I've already made sure ttyS0 is the correct major/minor and adjusted the GPIO calls; gpiodriver is talking to the chip, but not getting anywhere). -- 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)
On Thu, 27 May 2010, Alan Stern wrote: On Thu, 27 May 2010, Peter Zijlstra wrote: On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: On Thu, 27 May 2010 17:09:16 +0200 Peter Zijlstra pet...@infradead.org wrote: On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: Opportunistic suspends are okay. The proposed userspace API is too Android-specific. I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant. Assuming you are happy that opportunistically entering C6 and the like is ok via ACPI can you explain why you have a problem with opportunistic suspend and why it is different to a very deep sleep CPU state such as we have now (and which on many embedded platforms we deal with *is* sleeping external devices too) Agreed, but I understood the opportunistic suspend line from Alan Stern to mean the echo opportunistic /sys/power/foo thing. Yes, that's what I meant. Why do you think it is any worse than echo mem /sys/power/state? The only difference is that it will block until all in-kernel suspend blockers are disabled. Or do you also think that echo mem /sys/power/state is evil and should be removed from the kernel as soon as possible? And to answer Thomas's question: The whole reason for having in-kernel suspend blockers is so that userspace can tell the system to suspend without losing wakeup events. Suppose a key is pressed just as a user program writes mem to /sys/power/state. The keyboard driver handles the keystroke and queues an input event. Then the system suspends and doesn't wake up until some other event occurs -- even though the keypress was an important one and it should have prevented the system from suspending. With in-kernel suspend blockers and opportunistic suspend, this scenario is prevented. That is their raison-d'etre. I tend to disagree. You are still looking at suspend as some extra esoteric mechanism. We should stop doing this and look at suspend (to RAM) as an additional deep idle state, which is well defined in terms of power savings and wakeup latency. That's what I think opportunistic suspend is all about. Now if you look at our current idle states in x86 the incoming keystroke is never lost. So when suspend does lose the wakeup event then we need to fix that, but why do we need suspend blockers for this ? Let's take your example: The keyboard driver handles the keystroke and queues an input event. Then the system goes into suspend Why do we go into suspend at all? If there is an event queued then something is woken up and got running, which is reason enough _not_ to enter suspend. If that's broken in the current implementation then we need to fix it, but not with a big hammer by adding another interface. We have that information already and obviously we do not use it, so lets figure out why before adding suspend blockers just because they paper over the underlying problem. 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)
No. Suspend blockers are designed to ensure that suspend isn't racy with respect to wakeup events. The bit that mitigates badly written applications is the bit where the scheduler doesn't run any more. How does having applications taking blockers fix that - it makes it worse. They are now blocking the kernel doing the right job. If you're happy with a single badly written application being able to cripple your power management story, you don't need opportunistic And taking a suspend blocker isn't crippling your power management ??? What /is/ the correct way to solve this problem when entering explicit suspend states? How do you guarantee that an event has been delivered to userspace before transitioning into suspend? Now, this is a less interesting problem if you're not using opportunistic suspend, but it's still a problem. The same way as we deal with low power states on other non PC devices ? That's no good. If the input device has been deactivated, how does the wakeup event get delivered to the application? If the input device is letting itself get de-activated in a way that can lose events the input device driver is buggy. It's nobody elses business how it does the its job, and certainly *not* the applications. That's a kernel internal issue. You know the resource constraint exists because the driver knows it is open Your QoS guarantees tell you what you desired latency of response at the point you can become ready is. That's all your need to do it right. In kernel yes your device driver probably does need to say things like 'Don't go below C6 for a moment' just as a high speed serial port might want to say 'Nothing over 10mS please' I can't speak for Thomas, but I'm certainly not arguing that you don't need something that looks more like the blocker side of the logic *in kernel*, because there is stuff that you want to express which isn't tied to the task. So you need Userspace - QoS guarantee expression, implied resource expression via device use. *NO* knowledge of device or platform in the application Kernel space Drivers - Explicit guarantee expression not bound to tasks. Driver encapsulates the variety in the device hardware and expresses it in a uniform manner to the idling/suspend logic CPU Freq - Encapsulates the variety in the CPU and core power functionality of devices, makes policy based upon the uniform express from the drivers and tasks All the autonomy is now in the right places, and we have requisite variety to actually manage the situation. 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)
On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote: I can't speak for Thomas, but I'm certainly not arguing that you don't need something that looks more like the blocker side of the logic *in kernel*, because there is stuff that you want to express which isn't tied to the task. Sure, if you're not using opportunistic suspend then I don't think there's any real need for the userspace side of this. The question is how to implement something with the useful properties of opportunistic suspend without without implementing something pretty much equivalent to the userspace suspend blockers. I've sent another mail expressing why I don't think your proposed QoS style behaviour provides that. -- Matthew Garrett | mj...@srcf.ucam.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 6/6] omap: move generic omap3 features to generic
On 05/27/2010 01:24 PM, S, Venkatraman wrote:
Nishanth Menonn...@ti.com wrote:
[..]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 809e13a..01555b6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -161,7 +161,7 @@ static void __init omap24xx_check_revision(void)
#define OMAP3_CHECK_FEATURE(status,feat) \
if (((status OMAP3_ ##feat## _MASK) \
OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
- omap3_features |= OMAP3_HAS_ ##feat;\
+ omap_features |= OMAP_HAS_ ##feat; \
}
CHECK sounds like a querying API, whereas the macro populates data.
Maybe UPDATE or SET ?
Depends on where you are looking at it from: overall it is checking the
status bits from OMAP and deciding what features it has - this is
specifically important for 35xx series of processors. it is indeed a
check in that sense. if you look at it from features variable, yeah it
is updating it, but the idea of usage of the Macro is: check in status
if feature X is available.. which is what it does ;). btw, the intent of
the current patch was not meant to rename CHECK_FEATURE as it was very
OMAP3 specific ;)
static void __init omap3_check_features(void)
@@ -310,20 +310,20 @@ static void __init omap3_cpuinfo(void)
/*
[...]
+OMAP_HAS_FEATURE(, l2cache, L2CACHE)
+OMAP_HAS_FEATURE(, sgx, SGX)
+OMAP_HAS_FEATURE(, iva, IVA)
+OMAP_HAS_FEATURE(, neon, NEON)
+OMAP_HAS_FEATURE(, isp, ISP)
+
+/*
* Runtime detection of OMAP3 features
*/
extern u32 omap3_features;
-#define OMAP3_HAS_L2CACHE BIT(0)
-#define OMAP3_HAS_IVA BIT(1)
-#define OMAP3_HAS_SGX BIT(2)
-#define OMAP3_HAS_NEON BIT(3)
-#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
-OMAP_HAS_FEATURE(3, l2cache, L2CACHE)
-OMAP_HAS_FEATURE(3, sgx, SGX)
-OMAP_HAS_FEATURE(3, iva, IVA)
-OMAP_HAS_FEATURE(3, neon, NEON)
-OMAP_HAS_FEATURE(3, isp, ISP)
OMAP_HAS_FEATURE(3, 192mhz_clk, 192MHZ_CLK)
#endif
--
What about feature detection for OMAP2 and OMAP4 (similar to
omap3_check_features) ?
At least a dummy implementation with warning messages would be good,
so that they are not used without initialization.
there is no need for warning messages, they will return as feature not
present. cpu.h is a common header and variable omap_features is in
common.c, the check_feature and id.c has not set that bit, the variable
will remain 0, hence omap_has_sgx() will return 0 unless someone enables
that for lets say OMAP4 - feel free to do it, as I mentioned in 0/6,
this series was meant solely to reorganize and provide an infrastructure
for further development.
Regards,
Nishanth Menon
--
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: [UPDATE] [RFC] [PATCH 0/4] OMAP4 Keyboard Controller Support
Hi Dmitry, On Tue, May 18, 2010 at 06:13:48PM -0500, Arce, Abraham wrote: Hi, Here you have the list of changes done so far for OMAP4 Keyboard Controller Support v2. I'll appreciate if someone else has more comments to share. I finally had a chance to review the patches and I do not think that we shoudl be adding new hooks, especially omap-specific platform methods, into matrix_keypad_platform_data structure. Also, the structre does not really match the device since it does nto use GPIOs. Why don't we define a driver-specific platform structure based on matrix_keypad_data and use it instead? Agree, looks clean now... Please try the patch below and let me know if it works for you. Yes, it works... I am putting it in a TI internal tree... Btw, you should not be allocating platform data in the platform code - it meant to be statically allocated and preferrably constant. I'll take a look at this... + +#include plat/omap4_keypad.h One fix to your patch... #include plat/omap4-keypad.h [snip] 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: omap3 pm: dependency between opp layer and cpufreq
On 05/27/2010 01:25 PM, Premi, Sanjeev wrote: Hi, While compiling for omap3_evm_defconfig, at the head of linux-omap, I encounter these errors: arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:364: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_enable': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:609: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:478: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:496: undefined reference to `omap_twl_uv_to_vsel' make: *** [.tmp_vmlinux1] Error 1 Turn our that comment and code in plat-omap/Makefile don't match: # OPP support in (OMAP3+ only at the moment) # XXX The OPP TWL/TPS code should only be included when a TWL/TPS # PMIC is selected. ifdef CONFIG_CPU_FREQ obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o ok this needs to be split: a) opp_twl_tps should depend on TWL_CORE and not CPUFREQ - there is no need actually b) opp.o should remain dependent on CPU_FREQ. endif But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to these errors: see (b) CC arch/arm/plat-omap/opp.o arch/arm/plat-omap/opp.c:54: error: redefinition of 'opp_get_voltage' arch/arm/plat-omap/include/plat/opp.h:240: error: previous definition of 'opp_get_voltage' was here arch/arm/plat-omap/opp.c:63: error: redefinition of 'opp_get_freq' arch/arm/plat-omap/include/plat/opp.h:245: error: previous definition of 'opp_get_freq' was here arch/arm/plat-omap/opp.c:79: error: conflicting types for 'opp_find_by_opp_id' arch/arm/plat-omap/include/plat/opp.h:296: error: previous definition of 'opp_find_by_opp_id' was here arch/arm/plat-omap/opp.c:102: error: redefinition of 'opp_get_opp_id' arch/arm/plat-omap/include/plat/opp.h:301: error: previous definition of 'opp_get_opp_id' was here arch/arm/plat-omap/opp.c:107: error: conflicting types for 'opp_get_opp_count' arch/arm/plat-omap/include/plat/opp.h:250: error: previous definition of 'opp_get_opp_count' was here arch/arm/plat-omap/opp.c:129: error: conflicting types for 'opp_find_freq_exact' arch/arm/plat-omap/include/plat/opp.h:256: error: previous definition of 'opp_find_freq_exact' was here arch/arm/plat-omap/opp.c:153: error: conflicting types for 'opp_find_freq_ceil' arch/arm/plat-omap/include/plat/opp.h:268: error: previous definition of 'opp_find_freq_ceil' was here arch/arm/plat-omap/opp.c:182: error: conflicting types for 'opp_find_freq_floor' arch/arm/plat-omap/include/plat/opp.h:262: error: previous definition of 'opp_find_freq_floor' was here arch/arm/plat-omap/opp.c:223: error: conflicting types for 'opp_add' arch/arm/plat-omap/include/plat/opp.h:280: error: previous definition of 'opp_add' was here arch/arm/plat-omap/opp.c:291: error: conflicting types for 'opp_init_list' arch/arm/plat-omap/include/plat/opp.h:274: error: previous definition of 'opp_init_list' was here arch/arm/plat-omap/opp.c:335: error: redefinition of 'opp_enable' arch/arm/plat-omap/include/plat/opp.h:285: error: previous definition of 'opp_enable' was here arch/arm/plat-omap/opp.c:345: error: redefinition of 'opp_disable' arch/arm/plat-omap/include/plat/opp.h:290: error: previous definition of 'opp_disable' was here arch/arm/plat-omap/opp.c:356: error: conflicting types for 'opp_init_cpufreq_table' arch/arm/plat-omap/include/plat/opp.h:307: error: previous definition of 'opp_init_cpufreq_table' was here make[1]: *** [arch/arm/plat-omap/opp.o] Error 1 The contents of plat-omap/include/plat/opp.h seem to be based on assumption that definition of OPP is needed only for cpufreq. But even if cpufreq is disabled, this information is required for setting the correct voltage against 'pre-defined' ARM frequency. Questions/ comments: 1) The linkage between OPP and Voltage are not driven by the PMIC. They are defined by/for the silicon itself. look carefully at twl - it is the abstraction where needed for pmic translation of a voltage value - this you agree is PMIC dependent I suppose. 2) The implementation for setting the voltage should depend upon the PMIC. ACK- the concept should be independent of PMIC - each PMIC, like 5030/tps Vs custom PMICs have thier own unique mechanisms of setting voltages - the renewed SR series from Thara addresses this concern.(not in pm branch yet - but potentially soon) 3) Was there any specific need to tie the functions opp_get_voltage and others to cpufreq only? yes, because without cpufreq there is no transitions in the system :) I am working on a patch that should remove some of these dependencies. But, trying to open up a discussion as well... do post them. thanks Best regards,
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 16:10:54 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: The reality is you need a sane, generic, race free way to express your requirements (eg for hard RT) and ditto for constraining the expression (for 'crapplications') And the thing is, even a well written app can be a 'crapplication' depending on the context and mood of the user. 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)
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: If people don't mind, here is a greatly simplified summary of the comments and objections I have seen so far on this thread: The in-kernel suspend blocker implementation is okay, even beneficial. I disagree here. I believe expressing that as QoS is much better. Let the kernel decide which power state is better as long as I can say I need 100us IRQ latency or 100ms wakeup latency. -- 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)
On Thu, 27 May 2010 17:07:14 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains untrusted tasks - when the session is active we set a flag
I would hope not, because I'd rather prefer my app that used the screen
to get the chance to save important data on what it was doing
irrespective of the screen blank: I have an elegant proof for this
problem but my battery has gone flat
Perhaps set after callbacks are made. But given that the approach
doesn't work anyway...
Which approach doesn't work, and why ?
What is the problem here - your device driver for the display can block
tasks it doesn't want to use the display.
It's still racy. Going back to my example without any of the suspend
blocking code, but using a network socket rather than an input device:
int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, addr, sizeof(addr))
while (1) {
if (read(input, foo, 1) 0) {
(do something)
} else {
(draw bouncing cows and clouds and tractor beams briefly)
}
}
A network packet arrives while we're drawing. Before we finish drawing,
the policy timeout expires and the screen turns off.
Which is correct for a badly behaved application. You said you wanted to
constrain it. You've done so. Now I am not sure why such a timeout
would expire in the example as the task is clearly busy when drawing, or
is talking to someone else who is in turn busy. Someone somewhere is
actually drawing be it a driver or app code.
For a well behaved application you are drawing so you are running
drawing stuff so why would you suspend. The app has said it has a
latency constraint that suspend cannot meet, or has a device open that
cannot meet the constraints in suspend.
You also have the socket open so you can meaningfully extract resource
constraint information from that fact.
See it's not the read() that matters, it's the connect and the close.
If your policy for a well behaved application is 'thou shalt not
suspend in a way that breaks its networking' then for a well behaving app
once I connect the socket we cannot suspend that app until such point as
the app closes the socket. At any other point we will break the
connection. Whether that is desirable is a policy question and you get to
pick how much you choose to trust an app and how you interpret the
information in your cpufreq and suspend drivers.
If you have wake-on-lan then the network stack might be smarter and
choose to express itself as
'the constraint is C6 unless the input queue is empty in which
case suspend is ok as I have WoL and my network routing is such
that I can prove that interface will be used'
In truth I doubt much hardware can make such an inference but some phones
probably can. On the other hand for /dev/input/foo you can make the
inference very nicely thank you.
Again wake on lan information does not belong in the application !
--
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)
On Thu, 27 May 2010, Matthew Garrett wrote: On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: Now let's try this in the Android world. The user hits a key and the system wakes up. The input layer takes a suspend block. The application now draws all the cows it wants to, takes its own suspend block and reads the input device. This empties the queue and the kernel-level suspend block is released. The application then processes the event before releasing the suspend block. The event has been delivered and handled. Thanks for providing this example: 1) It proves that suspend blockers are solely designed to encourage people to code crap. No. Suspend blockers are designed to ensure that suspend isn't racy with respect to wakeup events. The bit that mitigates badly written applications is the bit where the scheduler doesn't run any more. If you're happy with a single badly written application being able to cripple your power management story, you don't need opportunistic suspend. But you still have complications when it comes to deciding to enter suspend at the same time as you receive a wakeup event. Wrong. Setting the QoS requirements of the badly written app to any latency will allow the kernel to suspend even if the crappy app is active. And again. I'm opposing the general chant that fixing crappy applications in the kernel is a good thing. It's the worst decision we could make. And you need to do that, because the user applications suspend blocker magic is racy as hell. To work around that you sprinkle your suspend blocker magic all over the kernel instead of telling people how to solve the problem correctly. What /is/ the correct way to solve this problem when entering explicit suspend states? How do you guarantee that an event has been delivered to userspace before transitioning into suspend? Now, this is a less interesting problem if you're not using opportunistic suspend, but it's still a problem. Holy crap. If an event happens _before_ we go into an idle state - and I see suspend as an deeper idle state - then we do not go there at all. The whole notion of treating suspend to RAM any different than a plain idle C-State is wrong. It's not different at all. You just use a different mechanism which has longer takedown and wakeup latencies and requires to shut down stuff and setup extra wakeup sources. And there is the whole problem. Switching from normal event delivery to those special wakeup sources. That needs to be engineered in any case carefuly and it does not matter whether you add suspend blockers or not. Simply because you move the cow drawing CPU time from the point where the device wants to go into suspend to the point where the user hits a key again. You even delay the reaction of your app to the user input by the time it needs to finish drawing cows. It's how application mainloops tend to work. So what's the f*cking point ? You draw exactly the same amount of power and still you are claiming that it's better or what ? You can't express that with resource limits or QoS constraints. If you want to deal with this kind of situation then, as far as I can tell, you need either suspend blockers or something so close to them that it makes no difference. Wrong. If your application is interactive then you set the QoS requirement once to interactive and be done. So the correct point to make a power state decision is when the app waits for a key press. At this point the kernel can take several pathes: 1) Keep the system alive because the input device is in active state and a key press is expected 2) Go into supsend because the input device is deactivated after the screen lock kicked in. That's no good. If the input device has been deactivated, how does the wakeup event get delivered to the application? This behaves exactly the same way in terms of power consumption as your blocker example just without all the mess you are trying to create. And means that wakeup events don't get delivered. That's a shortcoming. That's utter nonsense. If we have a problem with missed wakeups then it needs to be fixed and not papered over with suspend blocker magic. I'm starting to get really grumpy about the chant that suspend blockers are the only way to fix missed wakeups. That might be the only way you can think of with your pink android glasses on, but again this is not rocket science even if it does not fit into the current way the kernel handles the whole suspend mechanism. So if we really sit back and look at suspend as another idle state, then we have first off the same requirements for entering it as we have for any other idle state: No running tasks (and we can solve the don't care task problem nicely
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Alan Cox wrote: That's all your need to do it right. In kernel yes your device driver probably does need to say things like 'Don't go below C6 for a moment' just as a high speed serial port might want to say 'Nothing over 10mS please' I can't speak for Thomas, but I'm certainly not arguing that you don't need something that looks more like the blocker side of the logic *in kernel*, because there is stuff that you want to express which isn't tied to the task. I'm not opposed, but yes it needs to be expressed in quantifiable terms, i.e. wakeup latency. That's just contributing to the global QoS state of affairs even if it is not tied to a particular task. And that allows the driver to be intelligent about it. The serial port at 9600 has definitely different requirements than at 115200. But that's quite a different concept than the big hammer approach of the blockers. 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)
On Thu, 27 May 2010, Felipe Balbi wrote: On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: If people don't mind, here is a greatly simplified summary of the comments and objections I have seen so far on this thread: The in-kernel suspend blocker implementation is okay, even beneficial. I disagree here. I believe expressing that as QoS is much better. Let the kernel decide which power state is better as long as I can say I need 100us IRQ latency or 100ms wakeup latency. Does this mean you believe echo mem /sys/power/state is bad and should be removed? Or echo disk /sys/power/state? They pay no attention to latencies or other requirements. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Matthew Garrett wrote: On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote: I can't speak for Thomas, but I'm certainly not arguing that you don't need something that looks more like the blocker side of the logic *in kernel*, because there is stuff that you want to express which isn't tied to the task. Sure, if you're not using opportunistic suspend then I don't think there's any real need for the userspace side of this. The question is how to implement something with the useful properties of opportunistic suspend without without implementing something pretty much equivalent to the userspace suspend blockers. I've sent another mail expressing why I don't think your proposed QoS style behaviour provides that. Opportunistic suspend is just a deep idle state, nothing else. If the overall QoS requirements allow to enter that deep idle state then the kernel goes there. Same decision as for all other idle states. You don't need any user space blocker for this decision, just sensible QoS information. Stop thinking about suspend as a special mechanism. It's not - except for s2disk, which is an entirely different beast. 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)
On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: Sure, if you're not using opportunistic suspend then I don't think there's any real need for the userspace side of this. The question is how to implement something with the useful properties of opportunistic suspend without without implementing something pretty much equivalent to the userspace suspend blockers. I've sent another mail expressing why I don't think your proposed QoS style behaviour provides that. Opportunistic suspend is just a deep idle state, nothing else. No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. Stop thinking about suspend as a special mechanism. It's not - except for s2disk, which is an entirely different beast. On PCs, suspend has more in common with s2disk than it does C states. -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: Sure, if you're not using opportunistic suspend then I don't think there's any real need for the userspace side of this. The question is how to implement something with the useful properties of opportunistic suspend without without implementing something pretty much equivalent to the userspace suspend blockers. I've sent another mail expressing why I don't think your proposed QoS style behaviour provides that. Opportunistic suspend is just a deep idle state, nothing else. No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. I think Alan and Thomas but certainly I am saying is that you can get to the same state without suspend. Either you suspend (forcefully don't schedule stuff), or you end up blocking all tasks on QoS/resource limits and end up with an idle system that goes into a deep idle state (aka suspend). So why isn't blocking every task on a QoS/resource good enough for you? -- 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)
On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote: Does this mean you believe echo mem /sys/power/state is bad and should be removed? Or echo disk /sys/power/state? They pay no attention to latencies or other requirements. Those are a whole different beast, those are basically a quick-off button like thing. Forced suspend is conceptually a very different beast from power-saving a running 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Matthew Garrett wrote: On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: No. Suspend blockers are designed to ensure that suspend isn't racy with respect to wakeup events. The bit that mitigates badly written applications is the bit where the scheduler doesn't run any more. If you're happy with a single badly written application being able to cripple your power management story, you don't need opportunistic suspend. But you still have complications when it comes to deciding to enter suspend at the same time as you receive a wakeup event. Wrong. Setting the QoS requirements of the badly written app to any latency will allow the kernel to suspend even if the crappy app is active. That's not what I want if I'm using the app at the time... Your crappy app does not use suspend blockers either. And again. I'm opposing the general chant that fixing crappy applications in the kernel is a good thing. It's the worst decision we could make. You still need the in-kernel suspend blockers if you want to guarantee that you can't lose wakeup events. But yes, if you're not concerned handling badly behaved applications then I believe that you can lose opportunistic suspend and just use the scheduler. No, we do not. We need correctly implemented drivers and a safe switchover from normal event delivery to wakeup based. The whole notion of treating suspend to RAM any different than a plain idle C-State is wrong. It's not different at all. You just use a different mechanism which has longer takedown and wakeup latencies and requires to shut down stuff and setup extra wakeup sources. My question was about explicit suspend states, not implicitly handling an identical state based on scheduler constraints. Suspend-as-a-C-state isn't usable on x86 - you have to explicitly trigger it based on some And why not ? Just because suspend is not implemented as an ACPI C-state ? Nonsense, if we want to push the system into suspend from the idle state we can do that. It's just not implemented and we've never tried to do it as it requires a non trivial amount of work, but I have done it on an ARM two years ago as a prove of concept and it works like a charm. policy. And if you want to be able to do that without risking the loss of wakeup events then you need in-kernel suspend blockers. Crap. Stop beating on those lost wakeup events. If we lose them then the drivers are broken and do not handle the switch over correctly. Or the suspend mechanism is broken as it does not evaluate the system state correctly. Blockers are just papering over that w/o tackling the real problem. So if we really sit back and look at suspend as another idle state, then we have first off the same requirements for entering it as we have for any other idle state: There are various platforms where we cannot treat suspend as an idle state. Any solution that requires that doesn't actually solve the problem. Yes, this is *trivial* if you can depend on the scheduler. But we can't, and so it's difficult. Stop handwaving. Which platforms prevent us to go into suspend from idle ? Please point me to the relevant documentation which says so. Just because we have not tried to implemented it does not mean that we cannot implement it. 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)
On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote: No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. I think Alan and Thomas but certainly I am saying is that you can get to the same state without suspend. Either you suspend (forcefully don't schedule stuff), or you end up blocking all tasks on QoS/resource limits and end up with an idle system that goes into a deep idle state (aka suspend). So why isn't blocking every task on a QoS/resource good enough for you? Because you may then block them in such a way that they never handle an event that should wake them. -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, May 27, 2010 at 07:04:24PM +0200, ext Alan Stern wrote: On Thu, 27 May 2010, Felipe Balbi wrote: On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: If people don't mind, here is a greatly simplified summary of the comments and objections I have seen so far on this thread: The in-kernel suspend blocker implementation is okay, even beneficial. I disagree here. I believe expressing that as QoS is much better. Let the kernel decide which power state is better as long as I can say I need 100us IRQ latency or 100ms wakeup latency. Does this mean you believe echo mem /sys/power/state is bad and should be removed? Or echo disk /sys/power/state? They pay no attention to latencies or other requirements. no, not at all. I think they are also really useful. But I also think in-kernel suspend blockers are unnecessary. I think runtime pm + cpuidle + cpufreq is well enough for all cases. We just need to give those three information about desired latencies. -- 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)
Hi, On Thu, May 27, 2010 at 07:04:38PM +0200, ext Thomas Gleixner wrote: Opportunistic suspend is just a deep idle state, nothing else. If the overall QoS requirements allow to enter that deep idle state then the kernel goes there. Same decision as for all other idle states. You don't need any user space blocker for this decision, just sensible QoS information. agree completely with you. Adding virtual differences between power states is a bad idea and causes unnecessary complication to the system. If we have a generic way of describing desired latencies (irq, wakeup, throughput, whatever), then the kernel should decide what's the best power state for the current situation. -- 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)
On Thu, 2010-05-27 at 18:16 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote: No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. I think Alan and Thomas but certainly I am saying is that you can get to the same state without suspend. Either you suspend (forcefully don't schedule stuff), or you end up blocking all tasks on QoS/resource limits and end up with an idle system that goes into a deep idle state (aka suspend). So why isn't blocking every task on a QoS/resource good enough for you? Because you may then block them in such a way that they never handle an event that should wake them. *blink*, do explain? Suppose X (or whatever windowing system) will block all clients that try to draw when you switch off your screen. How would we not wake them when we do turn the screen back on and start servicing the pending requests again? Pretty much the same for everything else, input events, WoL etc.. -- 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)
On Thu, 27 May 2010 18:45:25 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: The whole notion of treating suspend to RAM any different than a plain idle C-State is wrong. It's not different at all. You just use a different mechanism which has longer takedown and wakeup latencies and requires to shut down stuff and setup extra wakeup sources. And there is the whole problem. Switching from normal event delivery to those special wakeup sources. That needs to be engineered in any case carefuly and it does not matter whether you add suspend blockers or not. Ok, I just don't know the answer: How is it just another idle state if the userspace gets frozen? Doesn't that bork the whole transition and you need a userspace-kernel synchronisation point to not loose events? 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)
On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Matthew Garrett wrote: You still need the in-kernel suspend blockers if you want to guarantee that you can't lose wakeup events. But yes, if you're not concerned handling badly behaved applications then I believe that you can lose opportunistic suspend and just use the scheduler. No, we do not. We need correctly implemented drivers and a safe switchover from normal event delivery to wakeup based. What is a Correctly implemented driver in this case? One that receives a wakeup event and then prevents suspend being entered until userspace has acknowledged that event? Because that's what an in-kernel suspend blocker is. My question was about explicit suspend states, not implicitly handling an identical state based on scheduler constraints. Suspend-as-a-C-state isn't usable on x86 - you have to explicitly trigger it based on some And why not ? Just because suspend is not implemented as an ACPI C-state ? Nonsense, if we want to push the system into suspend from the idle state we can do that. It's just not implemented and we've never tried to do it as it requires a non trivial amount of work, but I have done it on an ARM two years ago as a prove of concept and it works like a charm. ACPI provides no guarantees about what level of hardware functionality remains during S3. You don't have any useful ability to determine which events will generate wakeups. And from a purely practical point of view, since the latency is in the range of seconds, you'll never have a low enough wakeup rate to hit it. policy. And if you want to be able to do that without risking the loss of wakeup events then you need in-kernel suspend blockers. Crap. Stop beating on those lost wakeup events. If we lose them then the drivers are broken and do not handle the switch over correctly. Or the suspend mechanism is broken as it does not evaluate the system state correctly. Blockers are just papering over that w/o tackling the real problem. Ger;kljaserf;kljf;kljer;klj. Suspend blockers are the mechanism for the driver to indicate whether the wakeup event has been handled. That's what they're there for. The in-kernel ones don't paper over anything. -- Matthew Garrett | mj...@srcf.ucam.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)
Opportunistic suspend is just a deep idle state, nothing else. No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. Nothing gets scheduled in a deep idle state either - its idle. We leave the idle state to schedule anything. I believe the constraint is - Do not auto-enter a state for which you cannot maintain the devices in use properly. On a current PC that generally means 'not suspend', on a lot of embedded boards (including Android phones) it includes an opportunistic 'suspend' and also several states half way between the PC deepest idles and suspend. Stop thinking about suspend as a special mechanism. It's not - except for s2disk, which is an entirely different beast. On PCs, suspend has more in common with s2disk than it does C states. Todays PCs are a special case. More to the point I don't think anyone is expected opportunistic suspend to be useful on _todays_ x86 systems. Even on todays PCs your assumption is questionable for virtual machines where a VM suspend is a lot faster and rather useful. 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)
On Thu, 27 May 2010, Alan Stern wrote: On Thu, 27 May 2010, Thomas Gleixner wrote: The whole notion of treating suspend to RAM any different than a plain idle C-State is wrong. It's not different at all. You just use a different mechanism which has longer takedown and wakeup latencies and requires to shut down stuff and setup extra wakeup sources. This is where you are wrong. Maybe not wrong in principle, but wrong in practice -- the kernel's present suspend-to-RAM (or just suspend) implementation is _very_ different from C-states (or just idle). Holy bouncing cow. I damned good know that the current implementation is not doing that and that suspend is implemented in a totally different way. That does not mean that this is written in stone. We CAN change that and fix it to gain opportunistic suspend. The primary difference is that the kernel can be forced into suspend even when the system isn't idle. In particular, it may be in the middle of processing a potential wakeup event -- and the current design gives the PM core no way to know if that is so. This is a weakness that in-kernel suspend blockers fix. Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution. With C-states this can't happen. If the CPU goes into a deeper C-state then ipso facto it isn't busy processing anything, much less a wakeup event. And that's the whole point of doing the opportunistic suspend with the help of the scheduler. Now maybe this difference is a bad thing, and the whole PM suspend/hibernate infrastructure should be rewritten. But the fact, remains, that's how it works now. And it can't be changed easily or quickly. So what you are saying is that we better paper over the shortcomings of our current implementation with do_not_suspend() code sprinkled all over the place instead of sitting down and making suspend from idle work. It's more or less trivial depending on the platform, but not rocket science. 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)
On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote: Suppose X (or whatever windowing system) will block all clients that try to draw when you switch off your screen. How would we not wake them when we do turn the screen back on and start servicing the pending requests again? How (and why) does the WoL (which may be *any* packet, not just a magic one) turn the screen back on? -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote: On Thu, 27 May 2010 18:45:25 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: The whole notion of treating suspend to RAM any different than a plain idle C-State is wrong. It's not different at all. You just use a different mechanism which has longer takedown and wakeup latencies and requires to shut down stuff and setup extra wakeup sources. And there is the whole problem. Switching from normal event delivery to those special wakeup sources. That needs to be engineered in any case carefuly and it does not matter whether you add suspend blockers or not. Ok, I just don't know the answer: How is it just another idle state if the userspace gets frozen? Doesn't that bork the whole transition and you need a userspace-kernel synchronisation point to not loose events? There is no userspace to freeze when the runqueues are empty. And as explained, you won't loose events if all the devices do a proper state transition. To quote: On Thu, 2010-05-27 at 18:45 +0200, Thomas Gleixner wrote: If the interrupt happens _BEFORE_ we switch over to the quiescent state, then we need to backout. If it happens after the switch then it goes into the nirwana if the suspend wakeup has not been set up correctly. If we have it setup correctly then we go into suspend just to come back immediately. There is nothing you can do about that with suspend blockers. -- 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)
On Thu, 27 May 2010, Alan Stern wrote: On Thu, 27 May 2010, Felipe Balbi wrote: On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: If people don't mind, here is a greatly simplified summary of the comments and objections I have seen so far on this thread: The in-kernel suspend blocker implementation is okay, even beneficial. I disagree here. I believe expressing that as QoS is much better. Let the kernel decide which power state is better as long as I can say I need 100us IRQ latency or 100ms wakeup latency. Does this mean you believe echo mem /sys/power/state is bad and should be removed? Or echo disk /sys/power/state? They pay no mem should be replaced by an idle suspend to ram mechanism attention to latencies or other requirements. s2disk is a totally different beast as it shuts down the box into the complete power off state. 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)
On Thu, May 27, 2010 at 06:30:41PM +0100, Alan Cox wrote: Opportunistic suspend is just a deep idle state, nothing else. No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. Nothing gets scheduled in a deep idle state either - its idle. We leave the idle state to schedule anything. Certainly, if you can force the system to be idle then you don't need opportunistic suspend. But you haven't shown how to do that without it being racey. -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 2010-05-27 at 18:23 +0100, Matthew Garrett wrote: ACPI provides no guarantees about what level of hardware functionality remains during S3. You don't have any useful ability to determine which events will generate wakeups. And from a purely practical point of view, since the latency is in the range of seconds, you'll never have a low enough wakeup rate to hit it. If all of userspace is blocked on devices, WTH is keeping us from hitting 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)
On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote: Suppose X (or whatever windowing system) will block all clients that try to draw when you switch off your screen. How would we not wake them when we do turn the screen back on and start servicing the pending requests again? How (and why) does the WoL (which may be *any* packet, not just a magic one) turn the screen back on? Why would you care about the screen for a network event? -- 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)
On Thu, 27 May 2010, Peter Zijlstra wrote: On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote: Does this mean you believe echo mem /sys/power/state is bad and should be removed? Or echo disk /sys/power/state? They pay no attention to latencies or other requirements. Those are a whole different beast, those are basically a quick-off button like thing. Forced suspend is conceptually a very different beast from power-saving a running system. They may be different conceptually. Nevertheless, Android uses forced suspend as a form of power saving. Until better mechanisms are in place, it makes sense. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote: Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution. Even if we could use suspend-via-deep-idle-state on PCs, we still need to be able to enter suspend while the system isn't idle. There's two ways to do that: 1) Force the system to be idle. Doing this race-free is difficult. 2) Enter suspend even though the system isn't idle. Since we can't rely on the scheduler, we need drivers to know whether userspace has consumed all wakeup events before allowing the transition to occur. Doing so requires either in-kernel suspend blockers or something that's almost identical. -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 27 May 2010, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote: Opportunistic suspend is just a deep idle state, nothing else. No. The useful property of opportunistic suspend is that nothing gets scheduled. That's fundamentally different to a deep idle state. I think Alan and Thomas but certainly I am saying is that you can get to the same state without suspend. Either you suspend (forcefully don't schedule stuff), or you end up blocking all tasks on QoS/resource limits and end up with an idle system that goes into a deep idle state (aka suspend). So why isn't blocking every task on a QoS/resource good enough for you? On some platforms (like those with ACPI), deeper power-savings are available by using forced suspend than by using idle. That used to be the case on Android. Arve has said that it isn't necessarily true any more, but that's the way their software is set up. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote: They may be different conceptually. Nevertheless, Android uses forced suspend as a form of power saving. Until better mechanisms are in place, it makes sense. So let them, doesn't mean we have to merge it. Or will you saw your foot off too if google were to promotes 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)
On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote: How (and why) does the WoL (which may be *any* packet, not just a magic one) turn the screen back on? Why would you care about the screen for a network event? Because the application that needs to handle the network packet is currently blocked trying to draw something to the screen. -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote: Even if we could use suspend-via-deep-idle-state on PCs, ( see Alan Cox's argument on PCs ) we still need to be able to enter suspend while the system isn't idle. _WHY_!? We've been trying to tell you you don't need 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)
On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote: On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote: On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote: How (and why) does the WoL (which may be *any* packet, not just a magic one) turn the screen back on? Why would you care about the screen for a network event? Because the application that needs to handle the network packet is currently blocked trying to draw something to the screen. Then that's an application bug right there, isn't it? If should have listened to the window server telling its clients it was going to go away. Drawing after you get that is your own damn fault ;-) -- 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)
On Thu, 27 May 2010, Thomas Gleixner wrote: Crap. Stop beating on those lost wakeup events. If we lose them then the drivers are broken and do not handle the switch over correctly. Or the suspend mechanism is broken as it does not evaluate the system state correctly. Blockers are just papering over that w/o tackling the real problem. That's the point -- suspend does not evaluate the system state correctly because it doesn't have the necessary information. Suspend blockers are a way of providing it that information. They don't paper over the problem; they solve it. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote: we still need to be able to enter suspend while the system isn't idle. _WHY_!? Because if I'm running a kernel build in a tmpfs and I hit the sleep key, I need to go to sleep. Blocking processes on driver access isn't sufficient. -- Matthew Garrett | mj...@srcf.ucam.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)
On Thu, 27 May 2010, Thomas Gleixner wrote: Does this mean you believe echo mem /sys/power/state is bad and should be removed? Or echo disk /sys/power/state? They pay no mem should be replaced by an idle suspend to ram mechanism In other words, you are suggesting that not only should the Android patches not be accepted, in addition a large part of the PM suspend framework should be rewritten? 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
