Re: [PATCH] omap2 usb-ehci: Add missing dma-mapping.h
* Jonathan Cameron ji...@cam.ac.uk [100607 19:55]: Signed-off-by: Jonathan Cameron ji...@cam.ac.uk --- I'm not a user of this code but was browsing the kautobuild logs and saw the igep0020 build error that has been there since 24th of May using the defconfig. Looks like a trivial missing header to me. I can not verify the resulting build works, but it does build cleanly with this patch on mainline as of a few minutes ago. Sorry for the noise if this has already been addressed but I'm not seeing anything in the linux-o...@vger archive. Thanks, a similar patch from Amit Kucheria is already queued up: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=bfb01197589965663772e6388f2bdf452e25adf2 Regards, Tony arch/arm/mach-omap2/usb-ehci.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/usb-ehci.c b/arch/arm/mach-omap2/usb-ehci.c index c68f799..465699f 100644 --- a/arch/arm/mach-omap2/usb-ehci.c +++ b/arch/arm/mach-omap2/usb-ehci.c @@ -20,6 +20,7 @@ #include linux/delay.h #include linux/platform_device.h #include linux/clk.h +#include linux/dma-mapping.h #include asm/io.h #include plat/mux.h -- 1.6.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
* Peter Ujfalusi peter.ujfal...@nokia.com [100602 15:09]: On Wednesday 02 June 2010 12:15:22 ext Liam Girdwood wrote: On Wed, 2010-06-02 at 12:05 +0300, Peter Ujfalusi wrote: Hi, On Tuesday 01 June 2010 14:18:19 Ujfalusi Peter (Nokia-D/Tampere) wrote: .. Liam if you are going to take the series, could you fix the patch names? I can also resend them if it is easier for you. Peter, I think it's probably better if you can resend. Can you also append the Acks too. Tony, do we have your ack too ? No problem, I'll wait for Tony's ack, and resend the series. Hmm, I thought I already acked these.. Anyways, the whole series looks good to me: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Timekeeping issue on aggressive suspend/resume
On Wed, Jun 9, 2010 at 1:22 PM, Thomas Gleixner t...@linutronix.de wrote: Though we could change that conditionally - the default would still be the freeze of jiffies and CLOCK_MONOTONIC for historical compability. If I were to change it only for our implementation, and make all the user space timers use CLOCK_REALTIME, then could you please point me in a direction as to what part of the kernel I should be touching to make that change? Earlier we faced issue with time that the application sees. It wasn't getting updated when we suspend and resume the system (where as the time inside the kernel kept updating) and hence eventually would drift from the actual time. for eg, if I use this loop at the command prompt while date do echo mem /sys/power/state done then the date command always displayed the same time, but the prints from the kernel (I was using the printk time information) was advancing as expected. I found a patch at https://patchwork.kernel.org/patch/50070/ Though this fixed the application time update issue, there are lot of timers in the application which is still not working right. Could anyone please point in some direction to find the solution? Thanks, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: simple sd card performance bug fix on OMAP
* Madhusudhan madhu...@ti.com [100602 20:13]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Friday, May 28, 2010 2:55 PM To: Stephen Schwarm, CSDP; linux-omap@vger.kernel.org Subject: RE: simple sd card performance bug fix on OMAP Stephen Schwarm, CSDP wrote: I have not had time to make a formal patch for this but I thought it was significant enough just to send it out. The problem is on omap systems that use omap_hsmmc.c to run sd or mmc cards. If the system you are using has an 8 wire interface, it will only use a one wire interface to 4 wire cards (eg, sd class 4 and sd class 6). In the file driver/mmc/omap_hsmmc.c in the function omap_hsmmc_probe: at about line 1739 change: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; to: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= w; just delete the word else. This sets the MMC_CAP_4_BIT_DATA bit on interfaces that have 8 wire interfaces. We have seen a BIG performance improvement on our systems. Thanks for reporting this. A similar patch was posted a while ago and is currently marked as awaiting upstream, although it looks like it got lost again. https://patchwork.kernel.org/patch/78713/ A revised version of the same patch was posted. https://patchwork.kernel.org/patch/93519/ Tony, Can you please push this? This needs to get merged via linux-mmc list. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap_hsmmc: Remove unused state variable
* Sergio Aguirre saagui...@ti.com [100608 23:35]: This fixes the following warning: drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend': drivers/mmc/host/omap_hsmmc.c:2275: warning: unused variable 'state' Introduced by commit ID: commit 1a13f8fa76c880be41d6b1e6a2b44404bcbfdf9e Author: Matt Fleming m...@console-pimps.org Date: Wed May 26 14:42:08 2010 -0700 mmc: remove the state argument to mmc_suspend_host() The unique usage of this var was removed there, and missed removing the respective declaration aswell. This should be sent to linux-mmc list. Tony Signed-off-by: Sergio Aguirre saagui...@ti.com --- drivers/mmc/host/omap_hsmmc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index b032828..d50e917 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2272,7 +2272,6 @@ static int omap_hsmmc_suspend(struct device *dev) int ret = 0; struct platform_device *pdev = to_platform_device(dev); struct omap_hsmmc_host *host = platform_get_drvdata(pdev); - pm_message_t state = PMSG_SUSPEND; /* unused by MMC core */ if (host host-suspended) return 0; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/uart][PATCH 2/4] OMAP3: serial: Fix uart4 handling for 3630
On Wed, Jun 9, 2010 at 7:58 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj govindraj...@gmail.com [100607 17:50]: On Mon, Jun 7, 2010 at 5:02 PM, Govindraj govindraj...@gmail.com wrote: On Mon, Jun 7, 2010 at 3:36 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [100604 18:30]: + w = ~0x7; + w |= OMAP_MUX_MODE2; + omap_ctrl_writew(w, uart-padconf); Generic NAK for tinkering with the mux registers directly. Instead, Govindraj, please add omap_mux_request_signal() into mux.c: void __iomem * __init omap_mux_request_signal(char *muxname); Looking into mach-omap2/mux.c Wouldn't retrieving offset will be enough as i have to depend on again *_mux_* function call for remux which can have the offset and val as parameter. You call omap_mux_request_signal with the signal name, and get the register address. Then you can just set it with readw/writew. So I need to use K15_24XX_UART3_TX as name to retrieve UART3 offset if I am correct and traverse through the list doing an strcmp on name to retrieve offset. In that case I dont find uart1/2/4 in list, Should that be added into the list? No, that's the old mux code. You want to do something like void __iomem *uart1_rx; uart1_rx = omap_mux_request_signal(uart1_rx); if (!uart1_rx) return -ENODEV; Thanks got it, - Shouldn't we just retrieve the offset and then use omap_ctrl_writew\ omap_ctrl_readw calls? - I hope muxmode configuration can be done in the existing code itself by manually populating the mode and use offset retrieved from omap_mux_request_signal and use omap_ctrl_writew. Any comment? -- Regards, Govindraj.R ... See the signal names in mux34xx.c and the TRM. Then omap2 and omap4 will work automatically once the mux code is ready for those. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thursday, June 10, 2010, Neil Brown wrote: On Wed, 9 Jun 2010 11:40:27 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. I think there is a little bit more to it than that. It seems there is a new ioctl for input/event devices to say Any events queued here should be treated as wake-up events. There may be similar additions to other devices, but I know of no details. That's not in the patchset as in my pull request. It is used on Android, though, and it would have been submitted separately, had the first patchset been merged. I wonder if we can get a complete statement of changes to the user-space API... Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Yes. There is no point unless we can meet somewhere in the middle. I think that would have to include a full suspend that freezes all processes. Solutions which reject that - while quite clever - would require too much change to Android user-space to be acceptable. Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/uart][PATCH 2/4] OMAP3: serial: Fix uart4 handling for 3630
* Govindraj govindraj...@gmail.com [100610 11:49]: - Shouldn't we just retrieve the offset and then use omap_ctrl_writew\ omap_ctrl_readw calls? Sure that works too. And that actually has the advantage that it's more likely to keep the mux read/write access in the platform init code. - I hope muxmode configuration can be done in the existing code itself by manually populating the mode and use offset retrieved from omap_mux_request_signal and use omap_ctrl_writew. Any comment? I'm not sure I follow you, but you should keep any mux functions in the platform init code and keep the driver as generic as possible. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] DSS2: make VRFB depends on OMAP2,3
From: Senthilvadivu Guruswamy svad...@ti.com config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3. Changes from v1: - Addressed multi-omap build issue Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com --- drivers/video/omap2/Kconfig|4 drivers/video/omap2/omapfb/Kconfig |1 - 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig index d877c36..18bb835 100644 --- a/drivers/video/omap2/Kconfig +++ b/drivers/video/omap2/Kconfig @@ -3,6 +3,10 @@ config OMAP2_VRAM config OMAP2_VRFB bool + depends on ARCH_OMAP2 || ARCH_OMAP3 + default y if FB_OMAP2 + help + OMAP VRFB buffer support is efficient for rotation source drivers/video/omap2/dss/Kconfig source drivers/video/omap2/omapfb/Kconfig diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig index a3ed15c..f186c2b 100644 --- a/drivers/video/omap2/omapfb/Kconfig +++ b/drivers/video/omap2/omapfb/Kconfig @@ -3,7 +3,6 @@ menuconfig FB_OMAP2 depends on FB OMAP2_DSS select OMAP2_VRAM - select OMAP2_VRFB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] DSS2 FB Allow usage of def_vrfb only for omap2,3
From: Senthilvadivu Guruswamy svad...@ti.com
Changes since v2:
Added a check to warn the wrong usage of vrfb in non-vrfb omap devices.
Force def_vrfb to 0 for non omap2, omap3 devices
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..0f79db8 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2128,6 +2128,16 @@ static int omapfb_probe(struct platform_device *pdev)
goto err0;
}
+ /* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
+ *available for OMAP2 and OMAP3
+ */
+ if (def_vrfb (!cpu_is_omap24xx()) (!cpu_is_omap34xx())) {
+ def_vrfb = 0;
+ dev_warn(pdev-dev, VRFB is not in this device,
+ using DMA for rotation\n);
+ }
+
+
mutex_init(fbdev-mtx);
fbdev-dev = pdev-dev;
--
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
[PATCH v3 1/3] DSS2: Allow FB_OMAP2 to build without VRFB
From: Senthilvadivu Guruswamy svad...@ti.com
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/plat-omap/include/plat/vrfb.h | 16
1 file changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
index d8a03ce..3792bde 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,6 +35,7 @@ struct vrfb {
bool yuv_mode;
};
+#ifdef CONFIG_OMAP2_VRFB
extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
@@ -47,4 +48,19 @@ extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long
paddr,
extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
extern void omap_vrfb_restore_context(void);
+#else
+static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
+static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
+static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp) {}
+static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
+ { return 0; }
+static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
+ { return 0; }
+static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
+static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
+ { return 0; }
+static inline void omap_vrfb_restore_context(void) {}
+#endif
#endif /* __VRFB_H */
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thu, 10 Jun 2010 10:59:43 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday, June 10, 2010, Neil Brown wrote: On Wed, 9 Jun 2010 11:40:27 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. I think there is a little bit more to it than that. It seems there is a new ioctl for input/event devices to say Any events queued here should be treated as wake-up events. There may be similar additions to other devices, but I know of no details. That's not in the patchset as in my pull request. It is used on Android, though, and it would have been submitted separately, had the first patchset been merged. Very true. But as the one cannot be used without the other, they really need to be considered as a package. I wonder if we can get a complete statement of changes to the user-space API... Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Yes. There is no point unless we can meet somewhere in the middle. I think that would have to include a full suspend that freezes all processes. Solutions which reject that - while quite clever - would require too much change to Android user-space to be acceptable. Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. Following that logic would we end up putting everything in the kernel? To my mind the advantage of having something in user-space is flexibility - you can refine the interfaces and behaviours without bothering the kernel. The reasons for putting things in the kernel are: - tight integration with VM or processes (the
[PATCH 1/2] DSPBRIDGE: fix a wrong clk index for gpt8
Mismatch between index for gpt clocks will result in writting out of bounds into dsp clock timer array when requesting gpt8, for the other gpt the bogus code is being masked as it falls within the array's range. Discovered-by: Ernesto Ramos Falcon erne...@ti.com Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/dsp/bridge/core/dsp-clock.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dsp/bridge/core/dsp-clock.c b/drivers/dsp/bridge/core/dsp-clock.c index 4613de9..dba0535 100644 --- a/drivers/dsp/bridge/core/dsp-clock.c +++ b/drivers/dsp/bridge/core/dsp-clock.c @@ -212,7 +212,8 @@ int dsp_clk_enable(IN enum dsp_clk_id clk_id) clk_enable(iva2_clk); break; case GPT_CLK: - timer[clk_id] = omap_dm_timer_request_specific(DMT_ID(clk_id)); + timer[clk_id - 1] = + omap_dm_timer_request_specific(DMT_ID(clk_id)); break; case MCBSP_CLK: mcbsp_clk_prepare(true, clk_id); @@ -287,7 +288,7 @@ int dsp_clk_disable(IN enum dsp_clk_id clk_id) clk_disable(iva2_clk); break; case GPT_CLK: - omap_dm_timer_free(timer[clk_id]); + omap_dm_timer_free(timer[clk_id - 1]); break; case MCBSP_CLK: mcbsp_clk_prepare(false, clk_id); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] DSPBRIDGE: reorganize gpt8 overflow handling
New function to encapsulate previous code to configure gpt overflow,
this prevents accessing dmtimer framework outside dsp-clock interface
or exposing clock handles to other bridge modules.
Besides that: duplicated and unused defines were removed, conditional
test for cnt was replaced for a time after jiffes macro.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Ernesto Ramos Falcon erne...@ti.com
---
arch/arm/plat-omap/include/dspbridge/clk.h |2 +
drivers/dsp/bridge/core/dsp-clock.c| 38 ++
drivers/dsp/bridge/core/ue_deh.c | 59 ++-
3 files changed, 45 insertions(+), 54 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/clk.h
b/arch/arm/plat-omap/include/dspbridge/clk.h
index 0814e92..61474bc 100644
--- a/arch/arm/plat-omap/include/dspbridge/clk.h
+++ b/arch/arm/plat-omap/include/dspbridge/clk.h
@@ -62,6 +62,8 @@ extern void dsp_clk_exit(void);
*/
extern void dsp_clk_init(void);
+void dsp_gpt_wait_overflow(short int clk_id, unsigned int load);
+
/*
* dsp_clk_enable
* Purpose:
diff --git a/drivers/dsp/bridge/core/dsp-clock.c
b/drivers/dsp/bridge/core/dsp-clock.c
index dba0535..dde63bd 100644
--- a/drivers/dsp/bridge/core/dsp-clock.c
+++ b/drivers/dsp/bridge/core/dsp-clock.c
@@ -192,6 +192,44 @@ static void mcbsp_clk_prepare(bool flag, u8 id)
}
}
+/**
+ * dsp_gpt_wait_overflow - set gpt overflow and wait for fixed timeout
+ * @clk_id: GP Timer clock id.
+ * @load:Overflow value.
+ *
+ * Sets an overflow interrupt for the desired GPT waiting for a timeout
+ * of 5 msecs for the interrupt to occur.
+ */
+void dsp_gpt_wait_overflow(short int clk_id, unsigned int load)
+{
+ struct omap_dm_timer *gpt = timer[clk_id - 1];
+ unsigned long timeout;
+
+ if (!gpt)
+ return;
+
+ /* Enable overflow interrupt */
+ omap_dm_timer_set_int_enable(gpt, OMAP_TIMER_INT_OVERFLOW);
+
+ /*
+* Set counter value to overflow counter after
+* one tick and start timer.
+*/
+ omap_dm_timer_set_load_start(gpt, 0, load);
+
+ /* Wait 80us for timer to overflow */
+ udelay(80);
+
+ timeout = msecs_to_jiffies(5);
+ /* Check interrupt status and wait for interrupt */
+ while (!(omap_dm_timer_read_status(gpt) OMAP_TIMER_INT_OVERFLOW)) {
+ if (time_is_after_jiffies(timeout)) {
+ pr_err(%s: GPTimer interrupt failed\n, __func__);
+ break;
+ }
+ }
+}
+
/*
* dsp_clk_enable
* Purpose:
diff --git a/drivers/dsp/bridge/core/ue_deh.c b/drivers/dsp/bridge/core/ue_deh.c
index fa0cc71..cf084cf 100644
--- a/drivers/dsp/bridge/core/ue_deh.c
+++ b/drivers/dsp/bridge/core/ue_deh.c
@@ -18,7 +18,6 @@
/* --- Host OS */
#include dspbridge/host_os.h
-#include plat/dmtimer.h
/* --- DSP/BIOS Bridge */
#include dspbridge/std.h
@@ -29,6 +28,7 @@
/* --- OS Adaptation Layer */
#include dspbridge/cfg.h
+#include dspbridge/clk.h
#include dspbridge/ntfy.h
#include dspbridge/drv.h
@@ -54,13 +54,6 @@
#define ALIGN_DOWN(x, a) ((x)(~((a)-1)))
-/* GP Timer number to trigger interrupt for MMU-fault ISR on DSP */
-#define GPTIMER_FOR_DSP_MMU_FAULT 8
-/* Bit mask to enable overflow interrupt */
-#define GPTIMER_IRQ_OVERFLOW 2
-/* Max time to check for GP Timer IRQ */
-#define GPTIMER_IRQ_WAIT_MAX_CNT 1000
-
static struct hw_mmu_map_attrs_t map_attrs = { HW_LITTLE_ENDIAN,
HW_ELEM_SIZE16BIT,
HW_MMU_CPUES
@@ -123,17 +116,7 @@ err:
/* If create failed, cleanup */
bridge_deh_destroy(deh_mgr);
deh_mgr = NULL;
- } else {
- timer = omap_dm_timer_request_specific(
- GPTIMER_FOR_DSP_MMU_FAULT);
- if (timer) {
- omap_dm_timer_disable(timer);
- } else {
- pr_err(%s: GPTimer not available\n, __func__);
- return -ENODEV;
- }
}
-
leave:
*ret_deh_mgr = deh_mgr;
@@ -161,10 +144,6 @@ int bridge_deh_destroy(struct deh_mgr *deh_mgr)
/* Deallocate the DEH manager object */
kfree(deh_mgr);
- /* The GPTimer is no longer needed */
- omap_dm_timer_free(timer);
- timer = NULL;
-
return 0;
}
@@ -194,7 +173,6 @@ void bridge_deh_notify(struct deh_mgr *deh_mgr, u32
ulEventMask, u32 dwErrInfo)
u32 hw_mmu_max_tlb_count = 31;
struct cfg_hostres *resources;
hw_status hw_status_obj;
- u32 cnt = 0;
if (!deh_mgr)
return;
@@ -253,42 +231,15 @@ void bridge_deh_notify(struct deh_mgr *deh_mgr, u32
ulEventMask, u32 dwErrInfo)
RE: [PATCH] omap_hsmmc: Remove unused state variable
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, June 10, 2010 1:49 AM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org; Matt Fleming Subject: Re: [PATCH] omap_hsmmc: Remove unused state variable * Sergio Aguirre saagui...@ti.com [100608 23:35]: This fixes the following warning: drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend': drivers/mmc/host/omap_hsmmc.c:2275: warning: unused variable 'state' Introduced by commit ID: commit 1a13f8fa76c880be41d6b1e6a2b44404bcbfdf9e Author: Matt Fleming m...@console-pimps.org Date: Wed May 26 14:42:08 2010 -0700 mmc: remove the state argument to mmc_suspend_host() The unique usage of this var was removed there, and missed removing the respective declaration aswell. This should be sent to linux-mmc list. Ok, No problem. I will do that now. Thanks and Regards, Sergio Tony Signed-off-by: Sergio Aguirre saagui...@ti.com --- drivers/mmc/host/omap_hsmmc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index b032828..d50e917 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2272,7 +2272,6 @@ static int omap_hsmmc_suspend(struct device *dev) int ret = 0; struct platform_device *pdev = to_platform_device(dev); struct omap_hsmmc_host *host = platform_get_drvdata(pdev); - pm_message_t state = PMSG_SUSPEND; /* unused by MMC core */ if (host host-suspended) return 0; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote: So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. I'm not clear where this requirement to simplify user space specifically for phones comes from - phones do have pretty substantial software stacks that aren't that far away to PCs. -- 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: suspend blockers Android integration
Hi! We started here because it's possibly the only api level change we have -- almost everything else is driver or subarch type work or controversial but entirely self-contained (like the binder, which I would be shocked to see ever hit mainline). [...] So why arent those bits mainline? It's a 1000 times easier to get drivers and small improvements and non-ABI changes upstream. After basically two years of growing your fork (and some attempts to get your drivers into drivers/staging/ - from where they have meanwhile dropped out again) you re-started with the worst possible thing to merge: a big and difficult kernel feature affecting many subsystems. Why? Because a large number of our drivers depend on it. The dependencies are trivial. Last time I checked, you had about 150KLoC drivers, with about 100 lines depending on wakelock support -- I know, I cleaned it up from staging. The changes required for merging 150KLoC will be definitely much bigger than 100 lines... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Wed, 9 Jun 2010, Arve Hjønnevåg wrote: I think this is where you misunderstood. There is no report wakeup event as such. All that happens is that data becomes available to be read from the input device file. However the power manager process isn't polling the device file at this point (because a suspend blocker is active), so it doesn't realize that the source has become active again. Yes this is not what I though you were suggesting. I thought you were trying to make sure the power manager sees all wakeup events. If you are only listening for wakeup events while no suspend blockers are active, why latch them? ... If you only poll the fd after the last user-space suspend blocker is released, why do you care when the kernel wakelock could have been released? It seem the only thing it saves you is an extra poll call when two wakeup events happen at the same time and one of them is fully processed and unblocks suspend before the other event handler blocks suspend. It seems strange to remove your wakeup event from the list when a specific suspend blocker is acquired when any suspend blocker will prevent that wakeup event from being added to the list in the first place. ... I don't think there is a need to tie the fds to anything else. If you poll the fds on the last suspend unblock call, you should get the same behaviour. You are quite right; there is no need to associate suspend blockers with wakeup sources. The power manager merely needs to poll all wakeup sources whenever no suspend blockers are active. I put those associations in the proposal because of the line of reasoning that led up to it, but they aren't necessary. All input events that can wake the system are handled by one user-space suspend blocker. Input devices come and go so we would need to add and remove the fds dynamically. Correct; the power manager would need to know whenever a wakeup-capable device file was opened or closed. The power manager would indeed have to know about wakeup devices that don't need to _keep_ the system awake. Here's one way to cope: During those times when no suspend blockers are active but the PM process thinks a wakeup source is active, the PM process could poll every few seconds to update its list of active sources. At those points it could remove wakeup sources that have timed out. For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. Also, existing apps don't pass their file descriptors to the power manager, so it has the get the event from somewhere else. Now you've put your finger on the key. The main difference between my scheme and the original wakelock scheme is that programs have to inform the power manager whenever they open or close a wakeup-capable device file. With everything implemented inside the kernel this isn't necessary, because obviously a kernel driver already knows when its device file is opened or closed. As I said before, this additional complication in userspace is the price paid for keeping stuff out of the kernel. If you had implemented wakelocks this way originally, you would not have needed to patch the vanilla kernel and this entire stormy discussion would never have occurred. (But of course you couldn't have used this for the original implementation of wakelocks, because back then the hardware couldn't achieve the lowest power states from idle.) Obviously this proposal would complicate your userspace. Not enormously, since most of the work is confined to the power manager, No, the main problem it that it is not confined to the power manager. The power manager does not have a list of file descriptors to monitor, so we have to modify all code that handles wakeup events. This includes vendor supplied code that we don't have the source for, but, on some platforms at least, this code relies on kernel wakelocks with a timeout and could at first be handled the same way we would have to handle existing apps reading from a socket. Look, I never said this scheme was _better_ than wakelocks. I merely said that it could be used without significant modifications to the kernel. The suspend blocker approach is more generally useful since it supports hardware where suspend is needed. Why this argument is being ignored is very puzzling. Probably because people doesn't envision system suspend being used for dynamic power management on that kind of
Re: [linux-pm] suspend blockers Android integration
On Wed, 9 Jun 2010 da...@lang.hm wrote: why could the suspend blocker process see all events, but the power manager process not see the events? have the userspace talk to the power manager the way it does to the suspend blocker now and what's the difference? effectivly think s/suspend blocker/power manager/ (with the power manager doing all the other things that are proposed instead of grabbing the wakelock), the difference should be hidden to the rest of userspace. what am I missing here? The main difference is that with a userspace power manager, programs have to tell the power manager whenever they open or close a wakeup-capable device file (and send it a copy of the file descriptor). With an in-kernel implementation these extra steps aren't needed, because of course kernel drivers already know when their device files are opened or closed. 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] suspend blockers Android integration
On Thu, 10 Jun 2010, Rafael J. Wysocki wrote: Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). That is all true. The power manager in userspace was meant to prove a point: that this _could_ be done without invasive changes to the kernel. It wasn't necessarily meant to be a _better_ solution. So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. This is a judgment call. Obviously different people have different opinions. 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
MTD repository for OMAP3
Hi, Could someone tell me which repository is used for developing MTD support for OMAP3 devices? Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: simple sd card performance bug fix on OMAP
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, June 10, 2010 1:36 AM To: Madhusudhan Cc: 'Gadiyar, Anand'; 'Stephen Schwarm, CSDP'; linux-omap@vger.kernel.org Subject: Re: simple sd card performance bug fix on OMAP * Madhusudhan madhu...@ti.com [100602 20:13]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Friday, May 28, 2010 2:55 PM To: Stephen Schwarm, CSDP; linux-omap@vger.kernel.org Subject: RE: simple sd card performance bug fix on OMAP Stephen Schwarm, CSDP wrote: I have not had time to make a formal patch for this but I thought it was significant enough just to send it out. The problem is on omap systems that use omap_hsmmc.c to run sd or mmc cards. If the system you are using has an 8 wire interface, it will only use a one wire interface to 4 wire cards (eg, sd class 4 and sd class 6). In the file driver/mmc/omap_hsmmc.c in the function omap_hsmmc_probe: at about line 1739 change: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; to: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= w; just delete the word else. This sets the MMC_CAP_4_BIT_DATA bit on interfaces that have 8 wire interfaces. We have seen a BIG performance improvement on our systems. Thanks for reporting this. A similar patch was posted a while ago and is currently marked as awaiting upstream, although it looks like it got lost again. https://patchwork.kernel.org/patch/78713/ A revised version of the same patch was posted. https://patchwork.kernel.org/patch/93519/ Tony, Can you please push this? This needs to get merged via linux-mmc list. Sure. We will repost it. Regards, Madhu Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: mmc: Fix the regulator resource for MMC2
Tony,
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, May 28, 2010 9:38 PM
To: linux-omap@vger.kernel.org
Cc: Shilimkar, Santosh; Nayak, Rajendra; Ghorai, Sukumar; Kadiyala, Kishore
Subject: [PATCH] omap4: mmc: Fix the regulator resource for MMC2
The MMC1 and MMC2 cards have seperate LDO supplies. Current code assumes
that they are powered by same LDO.
This patch fixes the same and has VAUX1 as supply to MMC2 card.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Tested-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Tested with omap3_defconfig on OMAP4430SDP
Any comments on this one ??
arch/arm/mach-omap2/board-4430sdp.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 7a78986..f62042e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -384,14 +384,16 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
+static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.0,
+ .dev_name = mmci-omap-hs.1,
},
+};
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.1,
+ .dev_name = mmci-omap-hs.0,
},
};
@@ -447,6 +449,8 @@ static struct regulator_init_data sdp4430_vaux1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp4430_vaux_supply,
};
static struct regulator_init_data sdp4430_vaux2 = {
@@ -487,7 +491,7 @@ static struct regulator_init_data sdp4430_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 2,
+ .num_consumer_supplies = 1,
.consumer_supplies = sdp4430_vmmc_supply,
};
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2] OMAP3EVM: Replace vdvi regulator supply with vdds_dsi
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, March 19, 2010 4:51 PM
To: linux-omap@vger.kernel.org
Cc: tomi.valkei...@nokia.com; t...@atomide.com; Hiremath, Vaibhav
Subject: [PATCH-V2] OMAP3EVM: Replace vdvi regulator supply with vdds_dsi
From: Vaibhav Hiremath hvaib...@ti.com
With recent changes happened in OMAP2/3 DSS library for regulator interface,
it
is required to define DSI regulator supply, without this DSS (in turn Fbdev)
fails to get regulator.
[Hiremath, Vaibhav] Tony,
I have also completely missed about this patch, and today I realized that this
patch is not merged.
Tony,
I have verified that this patch still gets applied cleanly ontop of
linux-omap/master.
Can it be merged, without this Video Display won't work on EVM?
Thanks,
Vaibhav
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
arch/arm/mach-omap2/board-omap3evm.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index 017bb2f..74bbdcb 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -514,14 +514,11 @@ static struct regulator_init_data omap3_evm_vdac = {
};
/* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_evm_vpll2_supply = {
- .supply = vdvi,
- .dev= omap3_evm_lcd_device.dev,
-};
+static struct regulator_consumer_supply omap3_evm_vpll2_supply =
+ REGULATOR_SUPPLY(vdds_dsi, omapdss);
static struct regulator_init_data omap3_evm_vpll2 = {
.constraints = {
- .name = VDVI,
.min_uV = 180,
.max_uV = 180,
.apply_uV = true,
--
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: MTD repository for OMAP3
On Thu, Jun 10, 2010 at 04:56:04PM +0200, ext Elvis Dowson wrote: Could someone tell me which repository is used for developing MTD support for OMAP3 devices? linux-2.6.git Try to always use mainline kernel for every patch and send them to correct mailing list with linux-o...@vger on Cc. -- 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] suspend blockers Android integration
On Thursday, June 10, 2010, Alan Stern wrote: On Thu, 10 Jun 2010, Rafael J. Wysocki wrote: Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). That is all true. The power manager in userspace was meant to prove a point: that this _could_ be done without invasive changes to the kernel. It wasn't necessarily meant to be a _better_ solution. So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. This is a judgment call. Obviously different people have different opinions. Agreed. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thursday, June 10, 2010, Mark Brown wrote: On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote: So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. I'm not clear where this requirement to simplify user space specifically for phones comes from This isn't a requirement, but something that IMO is reasonable. - phones do have pretty substantial software stacks that aren't that far away to PCs. That doesn't seem to be relevant here. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thursday, June 10, 2010, Neil Brown wrote: On Thu, 10 Jun 2010 10:59:43 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday, June 10, 2010, Neil Brown wrote: On Wed, 9 Jun 2010 11:40:27 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. I think there is a little bit more to it than that. It seems there is a new ioctl for input/event devices to say Any events queued here should be treated as wake-up events. There may be similar additions to other devices, but I know of no details. That's not in the patchset as in my pull request. It is used on Android, though, and it would have been submitted separately, had the first patchset been merged. Very true. But as the one cannot be used without the other, they really need to be considered as a package. You can use suspend blockers as in the pull request without the input patch in principle. I wonder if we can get a complete statement of changes to the user-space API... Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Yes. There is no point unless we can meet somewhere in the middle. I think that would have to include a full suspend that freezes all processes. Solutions which reject that - while quite clever - would require too much change to Android user-space to be acceptable. Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. Following that logic would we end up
[PATCH] DSPBRIDGE: Fix wrong prints of DBC_ENSURE()
The patch DSPBRIDGE: Check pointer instead of using MEM_IS_VALID_HANDLE macro uncovered an issue when calling the assertion macros after the pointer was freed, but not set to NULL. This issue was not showing before the above patch because the macro MEM_IS_VALID_HANDLE checked for the pointer and signature, which was not good because it dereferenced a pointer that was already freed. This patch removes DBC_ENSURE() whenever it checks for a previously freed pointer, or fix the code to avoid wrong assertions printing. Signed-off-by: Ivan Gomez Castellanos ivan.go...@ti.com --- drivers/dsp/bridge/pmgr/chnl.c |2 -- drivers/dsp/bridge/pmgr/dev.c |3 --- drivers/dsp/bridge/rmgr/dbdcd.c |5 ++--- drivers/dsp/bridge/rmgr/disp.c |2 -- drivers/dsp/bridge/rmgr/drv.c |2 +- drivers/dsp/bridge/rmgr/mgr.c |2 -- drivers/dsp/bridge/rmgr/nldr.c |1 - drivers/dsp/bridge/rmgr/strm.c | 11 --- 8 files changed, 7 insertions(+), 21 deletions(-) diff --git a/drivers/dsp/bridge/pmgr/chnl.c b/drivers/dsp/bridge/pmgr/chnl.c index bc5c3e9..32ddd46 100644 --- a/drivers/dsp/bridge/pmgr/chnl.c +++ b/drivers/dsp/bridge/pmgr/chnl.c @@ -127,8 +127,6 @@ dsp_status chnl_destroy(struct chnl_mgr *hchnl_mgr) status = -EFAULT; } - DBC_ENSURE(DSP_FAILED(status) || !chnl_mgr_obj); - return status; } diff --git a/drivers/dsp/bridge/pmgr/dev.c b/drivers/dsp/bridge/pmgr/dev.c index 3465b52..990695c 100644 --- a/drivers/dsp/bridge/pmgr/dev.c +++ b/drivers/dsp/bridge/pmgr/dev.c @@ -575,8 +575,6 @@ struct dev_object *dev_get_first(void) dev_obj = (struct dev_object *)drv_get_first_dev_object(); - DBC_ENSURE((dev_obj == NULL) || dev_obj); - return dev_obj; } @@ -644,7 +642,6 @@ struct dev_object *dev_get_next(struct dev_object *hdev_obj) next_dev_object = (struct dev_object *) drv_get_next_dev_object((u32) hdev_obj); } - DBC_ENSURE((next_dev_object == NULL) || next_dev_object); return next_dev_object; } diff --git a/drivers/dsp/bridge/rmgr/dbdcd.c b/drivers/dsp/bridge/rmgr/dbdcd.c index 3fa267f..c15d121 100644 --- a/drivers/dsp/bridge/rmgr/dbdcd.c +++ b/drivers/dsp/bridge/rmgr/dbdcd.c @@ -157,9 +157,8 @@ dsp_status dcd_create_manager(IN char *pszZlDllName, cod_delete(cod_mgr); } - DBC_ENSURE((DSP_SUCCEEDED(status)) || ((cod_mgr == NULL) - (status == -EPERM)) - || ((dcd_mgr_obj == NULL) (status == -ENOMEM))); + DBC_ENSURE((DSP_SUCCEEDED(status)) || + ((dcd_mgr_obj == NULL) (status == -ENOMEM))); func_end: return status; diff --git a/drivers/dsp/bridge/rmgr/disp.c b/drivers/dsp/bridge/rmgr/disp.c index c125395..1e7c22a 100644 --- a/drivers/dsp/bridge/rmgr/disp.c +++ b/drivers/dsp/bridge/rmgr/disp.c @@ -185,8 +185,6 @@ void disp_delete(struct disp_object *disp_obj) DBC_REQUIRE(disp_obj); delete_disp(disp_obj); - - DBC_ENSURE(!disp_obj); } /* diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c index aab6416..e30432c 100644 --- a/drivers/dsp/bridge/rmgr/drv.c +++ b/drivers/dsp/bridge/rmgr/drv.c @@ -512,7 +512,7 @@ dsp_status drv_destroy(struct drv_object *hDRVObject) kfree(pdrv_object); /* Update the DRV Object in Registry to be 0 */ (void)cfg_set_object(0, REG_DRV_OBJECT); - DBC_ENSURE(!pdrv_object); + return status; } diff --git a/drivers/dsp/bridge/rmgr/mgr.c b/drivers/dsp/bridge/rmgr/mgr.c index a0e89dc..0441d47 100644 --- a/drivers/dsp/bridge/rmgr/mgr.c +++ b/drivers/dsp/bridge/rmgr/mgr.c @@ -106,8 +106,6 @@ dsp_status mgr_destroy(struct mgr_object *hmgr_obj) /* Update the Registry with NULL for MGR Object */ (void)cfg_set_object(0, REG_MGR_OBJECT); - DBC_ENSURE(DSP_FAILED(status) || !hmgr_obj); - return status; } diff --git a/drivers/dsp/bridge/rmgr/nldr.c b/drivers/dsp/bridge/rmgr/nldr.c index 6d8c646..6faa439 100644 --- a/drivers/dsp/bridge/rmgr/nldr.c +++ b/drivers/dsp/bridge/rmgr/nldr.c @@ -658,7 +658,6 @@ void nldr_delete(struct nldr_object *nldr_obj) kfree(nldr_obj-ovly_table); } kfree(nldr_obj); - DBC_ENSURE(!nldr_obj); } /* diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c index aa3d81f..c3ae9a2 100644 --- a/drivers/dsp/bridge/rmgr/strm.c +++ b/drivers/dsp/bridge/rmgr/strm.c @@ -232,8 +232,8 @@ dsp_status strm_create(OUT struct strm_mgr **phStrmMgr, else delete_strm_mgr(strm_mgr_obj); - DBC_ENSURE(DSP_SUCCEEDED(status) - (*phStrmMgr || (DSP_FAILED(status) *phStrmMgr == NULL))); + DBC_ENSURE((DSP_SUCCEEDED(status) *phStrmMgr) || + (DSP_FAILED(status) *phStrmMgr == NULL)); return status; } @@ -249,8 +249,6 @@ void strm_delete(struct strm_mgr
Re: [linux-pm] suspend blockers Android integration
On Thu, Jun 10, 2010 at 05:46:46PM +0200, Rafael J. Wysocki wrote: On Thursday, June 10, 2010, Mark Brown wrote: On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote: So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. I'm not clear where this requirement to simplify user space specifically for phones comes from This isn't a requirement, but something that IMO is reasonable. - phones do have pretty substantial software stacks that aren't that far away to PCs. That doesn't seem to be relevant here. Sure, that's my point - you seem to be suggesting that phones have a different requirement here. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/10 Alan Stern st...@rowland.harvard.edu: On Wed, 9 Jun 2010, Arve Hjønnevåg wrote: I think this is where you misunderstood. There is no report wakeup event as such. All that happens is that data becomes available to be read from the input device file. However the power manager process isn't polling the device file at this point (because a suspend blocker is active), so it doesn't realize that the source has become active again. Yes this is not what I though you were suggesting. I thought you were trying to make sure the power manager sees all wakeup events. If you are only listening for wakeup events while no suspend blockers are active, why latch them? ... If you only poll the fd after the last user-space suspend blocker is released, why do you care when the kernel wakelock could have been released? It seem the only thing it saves you is an extra poll call when two wakeup events happen at the same time and one of them is fully processed and unblocks suspend before the other event handler blocks suspend. It seems strange to remove your wakeup event from the list when a specific suspend blocker is acquired when any suspend blocker will prevent that wakeup event from being added to the list in the first place. ... I don't think there is a need to tie the fds to anything else. If you poll the fds on the last suspend unblock call, you should get the same behaviour. You are quite right; there is no need to associate suspend blockers with wakeup sources. The power manager merely needs to poll all wakeup sources whenever no suspend blockers are active. I put those associations in the proposal because of the line of reasoning that led up to it, but they aren't necessary. All input events that can wake the system are handled by one user-space suspend blocker. Input devices come and go so we would need to add and remove the fds dynamically. Correct; the power manager would need to know whenever a wakeup-capable device file was opened or closed. The power manager would indeed have to know about wakeup devices that don't need to _keep_ the system awake. Here's one way to cope: During those times when no suspend blockers are active but the PM process thinks a wakeup source is active, the PM process could poll every few seconds to update its list of active sources. At those points it could remove wakeup sources that have timed out. For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. It is not the same. Using a wakelock with a timeout only has a problem if the app did not get a change to run and block suspend before the timeout expires. With the timeout values we use there is only a problem if the system is already unresponsive. If the driver does not block suspend but instead a power manager calls select or poll on a file descriptor while the app does a blocking read, the power manager can easily miss the event and suspend before the app blocks suspend. Also, existing apps don't pass their file descriptors to the power manager, so it has the get the event from somewhere else. Now you've put your finger on the key. The main difference between my scheme and the original wakelock scheme is that programs have to inform the power manager whenever they open or close a wakeup-capable device file. With everything implemented inside the kernel this isn't necessary, because obviously a kernel driver already knows when its device file is opened or closed. As I said before, this additional complication in userspace is the price paid for keeping stuff out of the kernel. If you had implemented wakelocks this way originally, you would not have needed to patch the vanilla kernel and this entire stormy discussion would never have occurred. (But of course you couldn't have used this for the original implementation of wakelocks, because back then the hardware couldn't achieve the lowest power states from idle.) Obviously this proposal would complicate your userspace. Not enormously, since most of the work is confined to the power manager, No, the main problem it that it is not confined to the power manager. The power manager does not have a list of file descriptors to monitor, so we have to modify all code that handles wakeup events. This includes vendor supplied code that we don't have the source for, but, on some platforms at least, this code relies on kernel
Re: Timekeeping issue on aggressive suspend/resume
On Wed, 2010-06-09 at 23:34 -0700, Suresh Rajashekara wrote: On Wed, Jun 9, 2010 at 1:22 PM, Thomas Gleixner t...@linutronix.de wrote: Though we could change that conditionally - the default would still be the freeze of jiffies and CLOCK_MONOTONIC for historical compability. If I were to change it only for our implementation, and make all the user space timers use CLOCK_REALTIME, then could you please point me in a direction as to what part of the kernel I should be touching to make that change? I think Thomas was suggesting that you consider creating a option for where CLOCK_MONOTONIC included total_sleep_time. In that case the *hack* (and this is a hack, we'll need some more thoughtful discussion before anything like it could make it upstream) would be in timekeeping_resume() to comment out the lines that update wall_to_monotonic and total_sleep_time. It would be interesting to hear if that hack works for you, and we can try to come up with a better way to think about how to accommodate both views of how to account time over suspend. Thomas, might this call for a new posix clock_id, CLOCK_BOOTTIME (ie: CLOCK_MONOTONIC + total_sleep_time) or something that userland could use to set timers on? thanks -john -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3] DSPBRIDGE: Include missing info in MMU Fault debugging trace
Some execution info is missing at the beginning of the
trace buffer printout. This fix is to include this information
according to the buffer contents description and
also couple of cosmetic changes to make the traces more
readable.
This fix also uses DYNEXTBASE address to filter symbols that
match low addresses in the hash table and are not useful to
print. Any address below DYNEXTBASE is not valid for the DSP.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/core/io_sm.c | 72 +--
1 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
index 53753ce..0f9e1b1 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -1948,9 +1948,9 @@ int print_dsp_trace_buffer(struct bridge_dev_context
*hbridge_context)
if (DSP_FAILED(status))
goto func_end;
/* Pack and do newline conversion */
- pr_info(%s: DSP Trace Buffer Begin:\n
+ pr_info(DSP Trace Buffer Begin:\n
===\n%s\n,
- __func__, psz_buf);
+ psz_buf);
/* convert to offset */
@@ -2057,8 +2057,10 @@ int dump_dsp_stack(struct bridge_dev_context
*bridge_context)
u32 size;
} mmu_fault_dbg_info;
u32 *buffer;
+ u32 *buffer_beg;
u32 *buffer_end;
u32 exc_type;
+ u32 dyn_ext_base;
u32 i;
u32 offset_output;
u32 total_size;
@@ -2066,6 +2068,7 @@ int dump_dsp_stack(struct bridge_dev_context
*bridge_context)
const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
IRP, NRP, AMR, SSR,
ILC, RILC, IER, CSR};
+ const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
struct bridge_drv_interface *intf_fxns;
struct dev_object *dev_object = bridge_context-hdev_obj;
@@ -2135,8 +2138,6 @@ int dump_dsp_stack(struct bridge_dev_context
*bridge_context)
total_size = MAX_MMU_DBGBUFF;
buffer = kzalloc(total_size, GFP_ATOMIC);
- buffer_end = buffer + total_size / 4;
-
if (!buffer) {
status = -ENOMEM;
pr_debug(%s: Failed to
@@ -2144,6 +2145,9 @@ int dump_dsp_stack(struct bridge_dev_context
*bridge_context)
goto func_end;
}
+ buffer_beg = buffer;
+ buffer_end = buffer + total_size / 4;
+
/* Read bytes from the DSP trace buffer... */
status = (*intf_fxns-pfn_brd_read)(bridge_context,
(u8 *)buffer, (u32)trace_begin,
@@ -2154,8 +2158,8 @@ int dump_dsp_stack(struct bridge_dev_context
*bridge_context)
goto func_end;
}
- pr_err(Aproximate Crash Position:\n);
- pr_err(--\n);
+ pr_err(\nAproximate Crash Position:\n
+ --\n);
exc_type = buffer[3];
if (!exc_type)
@@ -2163,15 +2167,42 @@ int dump_dsp_stack(struct bridge_dev_context
*bridge_context)
else
i = buffer[80]; /* NRP */
- if ((*buffer 0x0100) (node_find_addr(node_mgr, i,
+ status =
+ cod_get_sym_value(code_mgr, DYNEXTBASE, dyn_ext_base);
+ if (DSP_FAILED(status)) {
+ status = -EFAULT;
+ goto func_end;
+ }
+
+ if ((i dyn_ext_base) (node_find_addr(node_mgr, i,
0x1000, offset_output, name) == 0))
pr_err(0x%-8x [\%s\ + 0x%x]\n, i, name,
i - offset_output);
else
pr_err(0x%-8x [Unable to match to a symbol.]\n, i);
- pr_err(Execution Info:\n);
- pr_err(---\n);
+ buffer += 4;
+
+ pr_err(\nExecution Info:\n
+ ---\n);
+
+ if (*buffer ARRAY_SIZE(exec_ctxt)) {
+ pr_err(Execution context \t%s\n,
+ exec_ctxt[*buffer++]);
+ } else {
+ pr_err(Execution context corrupt\n);
+ kfree(buffer_beg);
+ return -EFAULT;
+ }
+ pr_err(Task Handle\t\t0x%x\n, *buffer++);
+ pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
+ pr_err(Stack Top\t\t0x%x\n, *buffer++);
+ pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
+ pr_err(Stack Size\t\t0x%x\n, *buffer++);
+
Re: [linux-pm] suspend blockers Android integration
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote: For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. It is not the same. Using a wakelock with a timeout only has a problem if the app did not get a change to run and block suspend before the timeout expires. With the timeout values we use there is only a problem if the system is already unresponsive. If the driver does not block suspend but instead a power manager calls select or poll on a file descriptor while the app does a blocking read, the power manager can easily miss the event and suspend before the app blocks suspend. You've lost me. If the power manager is sitting inside a select/poll, how can it miss the event (given that the event will make data available to be read on one of the descriptors being polled)? Or put it another way: With wakelocks, if the app doesn't use a suspend blocker then once it reads the event data and the timed wakelock is deactivated, there is nothing to prevent the system from immediately going into opportunistic suspend. My scheme can fail in the same way. Is that what you meant? The suspend blocker approach is more generally useful since it supports hardware where suspend is needed. Why this argument is being ignored is very puzzling. Probably because people doesn't envision system suspend being used for dynamic power management on that kind of hardware. I'm not sure what you mean by dynamic power management here (frequency of suspends?), but auto suspend is already in use on x86 desktops and laptops. Suspend blockers can fix the race with some wakeup events there. You should stress this point more strongly when conversing with others. I doubt it will be enough to change anybody's mind, but it can't hurt. Indeed, if you propose suspend blockers as a way to fix a lost-wakeup bug in existing distributions, rather than as something needed to support Android, people might view it more favorably. There's one question that I don't remember ever seeing answered. To which kernel drivers do you intend to add suspend blockers? 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] suspend blockers Android integration
2010/6/10 Alan Stern st...@rowland.harvard.edu: On Thu, 10 Jun 2010, Arve Hjønnevåg wrote: For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. It is not the same. Using a wakelock with a timeout only has a problem if the app did not get a change to run and block suspend before the timeout expires. With the timeout values we use there is only a problem if the system is already unresponsive. If the driver does not block suspend but instead a power manager calls select or poll on a file descriptor while the app does a blocking read, the power manager can easily miss the event and suspend before the app blocks suspend. You've lost me. If the power manager is sitting inside a select/poll, how can it miss the event (given that the event will make data available to be read on one of the descriptors being polled)? It cannot sit inside of select/poll all the time. Or put it another way: With wakelocks, if the app doesn't use a suspend blocker then once it reads the event data and the timed wakelock is deactivated, there is nothing to prevent the system from immediately going into opportunistic suspend. My scheme can fail in the same way. Is that what you meant? No, if an app reads from a file descriptor and block suspend when the read call returns, then suspend is blocked while processing the data. If the driver uses a wakelock with a timeout this will fail if the thread does not get to the suspend block call before the timeout expires, but unrelated events that don't prevent the app from running will not cause any problems. In your scheme the user-space power manager may miss events on this file descriptor since select/poll will not see an event if the app read that event right before the power manager called select/poll. The suspend blocker approach is more generally useful since it supports hardware where suspend is needed. Why this argument is being ignored is very puzzling. Probably because people doesn't envision system suspend being used for dynamic power management on that kind of hardware. I'm not sure what you mean by dynamic power management here (frequency of suspends?), but auto suspend is already in use on x86 desktops and laptops. Suspend blockers can fix the race with some wakeup events there. You should stress this point more strongly when conversing with others. I doubt it will be enough to change anybody's mind, but it can't hurt. Indeed, if you propose suspend blockers as a way to fix a lost-wakeup bug in existing distributions, rather than as something needed to support Android, people might view it more favorably. There's one question that I don't remember ever seeing answered. To which kernel drivers do you intend to add suspend blockers? All drivers that generate wakeup events need to either use suspend blockers directly or call into something else that does. For instance, with the patch to block suspend while input events are queued to user-space, an input driver that fully handles its events in its interrupt handler does not need any additional suspend blockers, but if the driver needs a work function or a timer to run before it reports the event it needs to block suspend until it has reported the event. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
This is a bit off the topic of Android flamage, but I thought it would be worth highlighting an example where the current frameworks may still have a deficiency... one that likewise relates to needing to block entry ot a system suspend state, but in this case user-space isn't very involved (just drivers coping with hardware). The example I wanted to re-post (I've done so in the past) is one where drivers ouldn't really do the right thing, since driver.suspend() wasn't quite powerful enough as a programming interface. The example works with USB on many ARM SoCs, and similar non-USB examples aren't rare. - Want to enter a system suspend state, with some USB wakeup sources. USB peripheral waken up by the host, or vice versa. NOTE ASSUMPTION: there are multiple suspend states supported by the hardware, significantly different in hardware configuration Linux should be able to use more than one such state... (if only because their power savings differ.) This can mean driver-specific knowledge about those various states. - The wakeup requires a particular clock to be active, so the USB controller can detect that the wakeup should trigger, then issue the right signals triggering the non-USB parts of the system. Problem: how does the device driver suspend() method block entry to a suspend state when it can't ensure that clock is going to be active. Magic return code? There are other issues here too. (Is the target system suspend state one of the ones which doesn't allow that clock to be active? SoC-specific calls might suffice for this issue. A number of years ago, this problem was insoluble with the then-current Linux PM and clock frameworks. I've been away from this issue for quite a while now, but don't recall seeing its sub-problems get solved ... If they're now solved, I'll be glad. (I know Kevin's recent OMAP stuff addresses similar issues, but It's OMAP-specific...) After all these thousands and thousands of emails... I'm not sure how much forward motion has happened. Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. (That QOS constraint should be removed when that driver no longer needs to issue wakeups; that's not quite the same as removed by driver.resume(). -- 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] DSPBRIDGE: Avoid possible buffer overflow in load_lib
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando Sent: Thursday, April 08, 2010 7:19 PM To: linux-omap@vger.kernel.org Cc: Hiroshi DOYU; Ameya Palande; felipe.contre...@nokia.com Subject: [PATCH] DSPBRIDGE: Avoid possible buffer overflow in load_lib From 770bb122ac96f6f87a4b0d93b98db683ae16eb36 Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ti.com Date: Wed, 24 Mar 2010 16:40:02 -0600 Subject: [PATCH] DSPBRIDGE: Avoid possible buffer overflow in load_lib Avoid possible buffer overflow in load_lib. Array pers_lib_table may use index 5. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/dsp/bridge/rmgr/nldr.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Pushed to dspbridge. - Omar -- 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] DSPBRIDGE: Avoid possible NULL pointer dereference in dspbridge
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando Sent: Thursday, April 08, 2010 7:17 PM To: linux-omap@vger.kernel.org Cc: Hiroshi DOYU; Ameya Palande; felipe.contre...@nokia.com Subject: [PATCH] DSPBRIDGE: Avoid possible NULL pointer dereference in dspbridge From 1471823b7a143bbb9566aaa192880309668f1bf9 Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ti.com Date: Wed, 24 Mar 2010 16:37:38 -0600 Subject: [PATCH] DSPBRIDGE: Avoid possible NULL pointer dereference in dspbridge Avoid possible NULL pointer dereference in dspbridge reported by KW. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/dsp/bridge/pmgr/dev.c | 14 +++- drivers/dsp/bridge/rmgr/nldr.c | 20 +++- drivers/dsp/bridge/rmgr/node.c |8 - drivers/dsp/bridge/rmgr/proc.c | 51 +-- drivers/dsp/bridge/wmd/io_sm.c |8 - drivers/dsp/bridge/wmd/tiomap3430.c |2 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c |4 ++- 7 files changed, 67 insertions(+), 40 deletions(-) Pushed to dspbridge. - Omar -- 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] DSPBRIDGE: Always delete nodes during resource cleanup
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ramos Falcon, Ernesto Sent: Friday, April 16, 2010 10:23 PM To: linux-omap@vger.kernel.org Cc: Ameya Palande; Doyu Hiroshi (Nokia-D/Helsinki); Contreras Felipe (Nokia-D/Helsinki) Subject: [PATCH] DSPBRIDGE: Always delete nodes during resource cleanup From 9b263cc8cf0dea7e440aabb77fc88d06e01d62a4 Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ernesto-desktop.(none) Date: Thu, 18 Mar 2010 23:48:56 -0600 Subject: [PATCH] DSPBRIDGE: Always delete nodes during resource cleanup Right now, during resource clean up, nodes are not being deleted if they are in state NODE_DONE. This fix makes sure they are deleted if they are in any valid state. Signed-off-by: Ernesto Ramos erne...@ti.com --- drivers/dsp/bridge/rmgr/drv.c | 12 +++- 1 files changed, 3 insertions(+), 9 deletions(-) Pushed to dspbridge. - Omar -- 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 1/3] DSPBRIDGE: fix cpufreq_register_notifier usage
From: Deepak Chitriki deepak.chitr...@ti.com cpufreq_register_notifier() function calls srcu_notifier_chain_register() which always returns 0 on success and dspbridge throws the error message clk_notifier_register failed for iva2_ck. Fix the faulty ! in if logic and the faulty error message we report to log. Cc: Ameya Palande ameya.pala...@nokia.com Cc: Andy Shevchenko ext-andriy.shevche...@nokia.com Cc: Deepak Chitriki deepak.chitr...@ti.com Cc: Fernando Guzman Lugo x0095...@ti.com Cc: Felipe Contreras felipe.contre...@nokia.com Cc: Hari Kanigeri h-kanige...@ti.com Cc: Hiroshi Doyu hiroshi.d...@nokia.com Cc: Omar Ramirez Luna omar.rami...@ti.com Cc: Ramesh Gupta grgu...@ti.com Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com --- drivers/dsp/bridge/rmgr/drv_interface.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Pushed to dspbridge. - Omar -- 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] DSPBRIDGE: fix incorrect reset in bridge_brd_start function
From: Chitriki Rudramuni, Deepak Sent: Thursday, May 20, 2010 9:42 AM To: Guzman Lugo, Fernando Cc: linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Ramirez Luna, Omar; Felipe Contreras Subject: Re: [PATCH] DSPBRIDGE: fix incorrect reset in bridge_brd_start function Guzman Lugo, Fernando wrote: From 595a54c6a886d8e707e04cbf5d0d9b6d6de7c6ec Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Tue, 18 May 2010 20:14:20 -0500 Subject: [PATCH] DSPBRIDGE: fix incorrect reset in bridge_brd_start function IVA mmu reset was not being done properly, so dsp bootaddress was not copied to SYSC register. Given as a result DSP was not booting from that address after reloading baseimage. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- drivers/dsp/bridge/core/tiomap3430.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/core/tiomap3430.c b/drivers/dsp/bridge/core/tiomap3430.c index c7b0d83..805e6f3 100644 --- a/drivers/dsp/bridge/core/tiomap3430.c +++ b/drivers/dsp/bridge/core/tiomap3430.c @@ -443,7 +443,7 @@ static dsp_status bridge_brd_start(struct bridge_dev_context *hDevContext, /* Reset and Unreset the RST2, so that BOOTADDR is copied to * IVA2 SYSC register */ (*pdata-dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2, -OMAP3430_RST1_IVA2, OMAP3430_IVA2_MOD, RM_RSTCTRL); +OMAP3430_RST2_IVA2, OMAP3430_IVA2_MOD, RM_RSTCTRL); udelay(100); (*pdata-dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2, 0, OMAP3430_IVA2_MOD, RM_RSTCTRL); Tested by: Deepak chitrikideepak.chitr...@ti.com Pushed to dspbridge. - Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] DSPBRIDGE: Remove comments refering to Windows OS.
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gomez Castellanos, Ivan Sent: Wednesday, May 19, 2010 5:22 PM To: linux-omap@vger.kernel.org Cc: hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com; Gomez Castellanos, Ivan Subject: [PATCH 0/4] DSPBRIDGE: Remove comments refering to Windows OS. This patch series remove comments refering to: WMD (Windows Mini Driver) WCD (Windows Class Driver) Mini-driver Class-driver As they refer to the Windows Driver Model. Instead of using these, they are replaced as follows: WMD = Bridge driver (Contain only hardware specific functionallity) WCD = DSP API (Since WCD provides an interface between the different layers of the Windows Driver Model and Applications) This patch series is a compliment of the patch series to remove code refering to other OS. Ivan Gomez Castellanos (4): DSPBRIDGE: Remove comments refering to WMD. DSPBRIDGE: Remove comments refering to WCD. DSPBRIDGE: Remove comments refering to mini driver DSPBRIDGE: Remove comments refering to class driver arch/arm/plat-omap/include/dspbridge/_chnl_sm.h|2 +- arch/arm/plat-omap/include/dspbridge/brddefs.h |2 +- arch/arm/plat-omap/include/dspbridge/cfg.h |6 +- arch/arm/plat-omap/include/dspbridge/cfgdefs.h |2 +- arch/arm/plat-omap/include/dspbridge/chnl.h|4 +- arch/arm/plat-omap/include/dspbridge/chnlpriv.h|3 +- arch/arm/plat-omap/include/dspbridge/dehdefs.h |2 +- arch/arm/plat-omap/include/dspbridge/dev.h | 65 ++-- arch/arm/plat-omap/include/dspbridge/devdefs.h |4 +- arch/arm/plat-omap/include/dspbridge/drvdefs.h |2 +- .../arm/plat-omap/include/dspbridge/dspapi-ioctl.h |2 +- arch/arm/plat-omap/include/dspbridge/dspchnl.h |4 +- arch/arm/plat-omap/include/dspbridge/dspdefs.h | 115 ++-- arch/arm/plat-omap/include/dspbridge/dspdeh.h |2 +- arch/arm/plat-omap/include/dspbridge/dspdrv.h |2 +- arch/arm/plat-omap/include/dspbridge/dspio.h |4 +- arch/arm/plat-omap/include/dspbridge/dspioctl.h|4 +- arch/arm/plat-omap/include/dspbridge/dspmsg.h |4 +- arch/arm/plat-omap/include/dspbridge/io_sm.h |6 +- arch/arm/plat-omap/include/dspbridge/ldr.h |2 +- arch/arm/plat-omap/include/dspbridge/memdefs.h |2 +- arch/arm/plat-omap/include/dspbridge/mgr.h |2 +- arch/arm/plat-omap/include/dspbridge/mgrpriv.h |2 +- arch/arm/plat-omap/include/dspbridge/node.h|2 +- arch/arm/plat-omap/include/dspbridge/proc.h|4 +- arch/arm/plat-omap/include/dspbridge/procpriv.h|2 +- arch/arm/plat-omap/include/dspbridge/utildefs.h|2 +- drivers/dsp/bridge/core/_msg_sm.h |4 +- drivers/dsp/bridge/core/_tiomap.h | 10 +- drivers/dsp/bridge/core/chnl_sm.c |8 +- drivers/dsp/bridge/core/io_sm.c| 20 ++-- drivers/dsp/bridge/core/msg_sm.c |2 +- drivers/dsp/bridge/core/tiomap3430.c | 12 +- drivers/dsp/bridge/core/tiomap3430_pwr.c |6 +- drivers/dsp/bridge/core/ue_deh.c |2 +- drivers/dsp/bridge/pmgr/chnl.c | 10 +- drivers/dsp/bridge/pmgr/chnlobj.h | 16 ++-- drivers/dsp/bridge/pmgr/dev.c | 48 + drivers/dsp/bridge/pmgr/dspapi.c |2 +- drivers/dsp/bridge/pmgr/io.c |4 +- drivers/dsp/bridge/pmgr/ioobj.h| 10 +- drivers/dsp/bridge/pmgr/msg.c |8 +- drivers/dsp/bridge/pmgr/msgobj.h | 11 +- drivers/dsp/bridge/rmgr/disp.c |5 +- drivers/dsp/bridge/rmgr/node.c |9 +- drivers/dsp/bridge/rmgr/proc.c | 11 +- drivers/dsp/bridge/rmgr/strm.c |7 +- drivers/dsp/bridge/services/cfg.c |2 +- 48 files changed, 235 insertions(+), 225 deletions(-) Pushed to dspbridge. - Omar -- 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] dspbridge: deh: fix corruption on MMU fault
From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Sunday, May 16, 2010 10:44 AM To: linux-omap Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Chitriki Rudramuni, Deepak; Felipe Contreras Subject: [PATCH v2] dspbridge: deh: fix corruption on MMU fault The DSP might misbehave and write to the dummy memory. So let's make sure that nobody else is using the pages related to it by grabbing a full page. Based on the analysis of Deepak Chitriki. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/dsp/bridge/core/ue_deh.c | 11 +++ 1 files changed, 3 insertions(+), 8 deletions(-) Pushed to dspbridge. - Omar -- 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
