Re: [PATCH] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
On Tue, 10 Mar 2009 19:33:50 -0800 David Brownell davi...@pacbell.net wrote: It'd be nice to have a nice unambiguous set_voltage() request from the MMC core. The set_ios() thing has always been confusing. set_ios() should be taken out back. But someone has to have the time to reimplement things. :/ -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Suspend/Resume support with Omap2fb
Hi, I am using New Frame-Buffer driver which is based on DSS2 library submitted by Tomi, and I am trying to add full power management support. But things are not working out as expected, every time when I am issuing command echo mem /sys/power/state the system doesn't go into off state. It always points to dss_prwdm, below are the steps I am following - - Build the kernel with CPU_IDLE - Enable all the PM flags # echo 1 /sys/power/sleep_while_idle # echo 1 /sys/power/clocks_off_while_idle # echo 1 /sys/power/enable_off_mode - From Linux prompt issue command # echo mem /sys/power/state The log is - r...@arago:~# echo mem /sys/power/state 6PM: Syncing filesystems ... PM: Syncing filesystems ... done. done. Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. done. Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) 6omap-backlight: suspending... omapfb_suspend omapfb_resume 6omap-backlight: resuming... omap-backlight: suspending... omapfb_suspend Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend eth0: link down omapfb_resume omap-backlight: resuming... Restarting tasks ... Restarting tasks ... done. done. r...@arago:~# Some analysis which I observed during debugging this issue - - The root-cause is, DSS PowerDomain always shows it is in ON state (PWRDM_POWER_ON), and if I understand correctly this is only dependent on clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE enabled I am going to complete OFF state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). - If I compile out framebuffer driver and include DSS2 and V4L2 driver, everything works fine. I am not sure how omapfb is being tied with PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = omapfb, not sure how this is being used. I believe if system is hitting OFF state, then my enable/disable paths are proper, but really not sure about why mem is causing problem here. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - radio: remove uaccess include - omap24xxcam: don't set vfl_type. This should fix the daily build (for probably 10 seconds :-) ). Thanks, Hans diffstat: radio/radio-aimslab.c|1 - radio/radio-aztech.c |1 - radio/radio-cadet.c |1 - radio/radio-gemtek-pci.c |1 - radio/radio-gemtek.c |1 - radio/radio-maestro.c|1 - radio/radio-maxiradio.c |1 - radio/radio-rtrack2.c|1 - radio/radio-sf16fmi.c|1 - radio/radio-sf16fmr2.c |1 - radio/radio-terratec.c |1 - radio/radio-trust.c |1 - radio/radio-typhoon.c|1 - radio/radio-zoltrix.c|1 - video/omap24xxcam.c |1 - 15 files changed, 15 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe 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: Hello Tomi Valkeinen, I have some questions about dss2 driver.
Hi, On Wed, 2009-03-11 at 05:57 +0100, ext InKi Dae wrote: I am using your dss2 driver downloaded from your git server and tried to rotate an image(RGB24U and YUV2 format) using OMAPFB_ROT_DMA command. but I can't see rotated image on screen. I added variables for rotating like below. as the result, LCD Panel is stoped. omapfb.rotate=2 omapfb.vrfb=n and then I tried again using OMAPFB_ROT_VRFB command like below. omapfb.rotate=2 omapfb.vrfb=y In this case, I can see rotated image(only RGB24U format) on screen. You asid Rotation and mirroring currently only supports RGB565 and RGB modes. VRFB does not support mirroring through /Documentation/arm/OMAP/DSS file. Doesn't your dss2 driver support DMA rotation? It does. However, you should use DMA rotation only with OMAP2 when the framebuffer is in SRAM. It seems to work somewhat on OMAP3 and SDRAM, but I've noticed it doesn't always work. I don't know if lowering pixel clock, increasing dss fck or fiddling with fifo sizes could affect it. I am trying to add rotation feature for YUV2 image using VRFB to your dss2 driver. for this, I think that it have to change rot and mirror become 0 if rotation_type is OMAPFB_ROT_VRFB to be rot=ofbi-rotation and mirror = ofbi-mirror (in omapfb-main.c file) and add codes for calculating offset0, offset1, pixel increment and row increment value for YUV2 format also pixel size becomes 4 in YUV2 case (in dispc.c fild). omap_vrfb_setup function must be modifed also (in vrfb.c file)? Do you have any idea? No, I haven't really looked at YUV rotations. Tomi I need your help and advice. Thank you. - InKi- -- To unsubscribe from this list: send the line unsubscribe 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/Resume support with Omap2fb
Hi, On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: Hi, I am using New Frame-Buffer driver which is based on DSS2 library submitted by Tomi, and I am trying to add full power management support. But things are not working out as expected, every time when I am issuing command echo mem /sys/power/state the system doesn't go into off state. It always points to dss_prwdm, below are the steps I am following - OFF mode should work. I have verified it with DSI, DPI and SDI. However, it needs passing the get_last_off_on_transaction_id pointer in omap_dss_platform_data. Also, see below. - Build the kernel with CPU_IDLE - Enable all the PM flags # echo 1 /sys/power/sleep_while_idle # echo 1 /sys/power/clocks_off_while_idle # echo 1 /sys/power/enable_off_mode - From Linux prompt issue command # echo mem /sys/power/state The log is - r...@arago:~# echo mem /sys/power/state 6PM: Syncing filesystems ... PM: Syncing filesystems ... done. done. Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. done. Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) 6omap-backlight: suspending... omapfb_suspend omapfb_resume 6omap-backlight: resuming... omap-backlight: suspending... omapfb_suspend Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend eth0: link down omapfb_resume omap-backlight: resuming... Restarting tasks ... Restarting tasks ... done. done. r...@arago:~# Some analysis which I observed during debugging this issue - - The root-cause is, DSS PowerDomain always shows it is in ON state (PWRDM_POWER_ON), and if I understand correctly this is only dependent on clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE enabled I am going to complete OFF state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). - If I compile out framebuffer driver and include DSS2 and V4L2 driver, everything works fine. I am not sure how omapfb is being tied with PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = omapfb, not sure how this is being used. You have to change it to omapdss (or omap-dss in earlier DSS2 versions). Tomi I believe if system is hitting OFF state, then my enable/disable paths are proper, but really not sure about why mem is causing problem here. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Thanks, Vaibhav Hiremath -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, March 11, 2009 1:23 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: Suspend/Resume support with Omap2fb Hi, On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: Hi, I am using New Frame-Buffer driver which is based on DSS2 library submitted by Tomi, and I am trying to add full power management support. But things are not working out as expected, every time when I am issuing command echo mem /sys/power/state the system doesn't go into off state. It always points to dss_prwdm, below are the steps I am following - OFF mode should work. I have verified it with DSI, DPI and SDI. However, it needs passing the get_last_off_on_transaction_id pointer in omap_dss_platform_data. Also, see below. [Hiremath, Vaibhav] I believe this is only required when you do save and restore context right? Actually I have modified that part of code where it doesn't expect this pointer and save/restore happens perfectly fine, which I am very will sure about, since I am hitting state5 of CPU_IDLE (Full OFF state) and it resumes back with the same state. Again one more data point which I missed in last mail is, I am following clk-usecount which shows me 0. That means clocks are already disabled. r...@arago:~# cat /sys/devices/platform/omap-dss/clk - dss - internal clk count 0 dss_ick 83000 dss1_alwon_fck 96000 dss2_alwon_fck 13000 dss_tv_fck 54000 dss_96m_fck 96000 - dispc - dispc fclk source = dss1_alwon_fclk pixel clk = 9600 / 1 / 5 = 1920 r...@arago:~# - Build the kernel with CPU_IDLE - Enable all the PM flags # echo 1 /sys/power/sleep_while_idle # echo 1 /sys/power/clocks_off_while_idle # echo 1 /sys/power/enable_off_mode - From Linux prompt issue command # echo mem /sys/power/state The log is - r...@arago:~# echo mem /sys/power/state 6PM: Syncing filesystems ... PM: Syncing filesystems ... done. done. Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. done. Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) 6omap-backlight: suspending... omapfb_suspend omapfb_resume 6omap-backlight: resuming... omap-backlight: suspending... omapfb_suspend Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend eth0: link down omapfb_resume omap-backlight: resuming... Restarting tasks ... Restarting tasks ... done. done. r...@arago:~# Some analysis which I observed during debugging this issue - - The root-cause is, DSS PowerDomain always shows it is in ON state (PWRDM_POWER_ON), and if I understand correctly this is only dependent on clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE enabled I am going to complete OFF state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). - If I compile out framebuffer driver and include DSS2 and V4L2 driver, everything works fine. I am not sure how omapfb is being tied with PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = omapfb, not sure how this is being used. You have to change it to omapdss (or omap-dss in earlier DSS2 versions). [Hiremath, Vaibhav] I have tried this option also, didn't work out. Tomi, Do you have summary or list of changes required in clock and PowerDomain related files to make it work? How have you tested this? Have you also tested with echo mem /sys/power/state? Are you using Kevin's power management tree? What is default configuration of your kernel during this test? Tomi I believe if system is hitting OFF state, then my enable/disable paths are proper, but really not sure about why mem is causing problem here. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH] ARM: OMAP: Fix GPIO switch initial output state handling
On Tue, 2009-03-10 at 15:25 +0100, ext Kainan Cha wrote:
Jani,
Please see my comments below.
On Tue, Mar 10, 2009 at 4:26 AM, Jani Nikula
ext-jani.1.nik...@nokia.com wrote:
The switchover to cross-platform GPIO interface unexpectedly caused all
output GPIO switches to be set to high state by default, unlike the
original OMAP code. Introduce a new GPIO switch flag to define the
initial state. Unless the flag is set, the default is now low state.
Also store the state of output switches directly into the switch struct
instead of trying to read an output GPIO.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
---
arch/arm/plat-omap/gpio-switch.c | 13 +
arch/arm/plat-omap/include/mach/gpio-switch.h |1 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/gpio-switch.c
b/arch/arm/plat-omap/gpio-switch.c
index 2b5665d..b278024 100644
--- a/arch/arm/plat-omap/gpio-switch.c
+++ b/arch/arm/plat-omap/gpio-switch.c
@@ -286,12 +286,17 @@ static int __init new_switch(struct gpio_switch *sw)
/* input: 1, output: 0 */
direction = !(sw-flags OMAP_GPIO_SWITCH_FLAG_OUTPUT);
- if (direction)
+ if (direction) {
gpio_direction_input(sw-gpio);
- else
- gpio_direction_output(sw-gpio, true);
+ sw-state = gpio_sw_get_state(sw);
+ } else {
+ int state = sw-state =
+ !!(sw-flags
OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH);
- sw-state = gpio_sw_get_state(sw);
+ if (sw-flags OMAP_GPIO_SWITCH_FLAG_INVERTED)
+ state = !state;
Using OMAP_GPIO_SWITCH_FLAG_INVERTED along with
OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH here is somewhat confusing to
me.
INIT_HIGH indicates the state of the gpio, not the state of the
switch. Why not ignore the OMAP_GPIO_SWITCH_FLAG_INVERTED all together
when setting up the switch. This way, the user does not have to think
twice. :)
The INVERTED flag can't be ignored, since sw-state must be the opposite
of the GPIO if the flag is set. The only question is, should INIT_HIGH
flag refer to the GPIO or the switch.
I did think about this, and the patch is as I intended it to be, i.e.
INIT_HIGH refers to the switch. I thought this would be less confusing.
If INVERTED is set, it's inverted *everywhere* - why not also when
setting the initial value?
BR,
Jani.
+ gpio_direction_output(sw-gpio, state);
+ }
r = 0;
r |= device_create_file(sw-pdev.dev, dev_attr_state);
diff --git a/arch/arm/plat-omap/include/mach/gpio-switch.h
b/arch/arm/plat-omap/include/mach/gpio-switch.h
index a143253..107d23f 100644
--- a/arch/arm/plat-omap/include/mach/gpio-switch.h
+++ b/arch/arm/plat-omap/include/mach/gpio-switch.h
@@ -29,6 +29,7 @@
#define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
#define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
#define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
+#define OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH 0x0004
struct omap_gpio_switch {
const char *name;
--
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
--
To unsubscribe from this list: send the line unsubscribe 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/Resume support with Omap2fb
On Wed, 2009-03-11 at 09:46 +0100, ext Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, March 11, 2009 1:23 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: Suspend/Resume support with Omap2fb Hi, On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: Hi, I am using New Frame-Buffer driver which is based on DSS2 library submitted by Tomi, and I am trying to add full power management support. But things are not working out as expected, every time when I am issuing command echo mem /sys/power/state the system doesn't go into off state. It always points to dss_prwdm, below are the steps I am following - OFF mode should work. I have verified it with DSI, DPI and SDI. However, it needs passing the get_last_off_on_transaction_id pointer in omap_dss_platform_data. Also, see below. [Hiremath, Vaibhav] I believe this is only required when you do save and restore context right? Well, yes. But you need to save and restore context if you want OFF mode. Actually I have modified that part of code where it doesn't expect this pointer and save/restore happens perfectly fine, which I am very will sure about, since I am hitting state5 of CPU_IDLE (Full OFF state) and it resumes back with the same state. Again one more data point which I missed in last mail is, I am following clk-usecount which shows me 0. That means clocks are already disabled. r...@arago:~# cat /sys/devices/platform/omap-dss/clk - dss - internal clk count 0 dss_ick 83000 dss1_alwon_fck 96000 dss2_alwon_fck 13000 dss_tv_fck 54000 dss_96m_fck 96000 - dispc - dispc fclk source = dss1_alwon_fclk pixel clk = 9600 / 1 / 5 = 1920 r...@arago:~# - Build the kernel with CPU_IDLE - Enable all the PM flags # echo 1 /sys/power/sleep_while_idle # echo 1 /sys/power/clocks_off_while_idle # echo 1 /sys/power/enable_off_mode - From Linux prompt issue command # echo mem /sys/power/state The log is - r...@arago:~# echo mem /sys/power/state 6PM: Syncing filesystems ... PM: Syncing filesystems ... done. done. Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. done. Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) 6omap-backlight: suspending... omapfb_suspend omapfb_resume 6omap-backlight: resuming... omap-backlight: suspending... omapfb_suspend Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend eth0: link down omapfb_resume omap-backlight: resuming... Restarting tasks ... Restarting tasks ... done. done. r...@arago:~# Some analysis which I observed during debugging this issue - - The root-cause is, DSS PowerDomain always shows it is in ON state (PWRDM_POWER_ON), and if I understand correctly this is only dependent on clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE enabled I am going to complete OFF state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). - If I compile out framebuffer driver and include DSS2 and V4L2 driver, everything works fine. I am not sure how omapfb is being tied with PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = omapfb, not sure how this is being used. You have to change it to omapdss (or omap-dss in earlier DSS2 versions). [Hiremath, Vaibhav] I have tried this option also, didn't work out. Tomi, Do you have summary or list of changes required in clock and PowerDomain related files to make it work? How have you tested this? Have you also tested with echo mem /sys/power/state? Are you using Kevin's power management tree? What is default configuration of your kernel during this test? It's been some time since I tested it, but it did work on OMAP3 SDP with the pm-branch. Only changed needed were the get_last_off_on_transaction_id and omapfb - omapdss. I also tested echo mem I'll try to find time to test it again with latest trees. 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: [PATCH 0/2] OMAP3: GPIO off-mode fixes
The first patch in this set contains a small bug, missing kfree() for one of the dynamically reserved arrays during init in error path. Sending a fixed patch now. -Tero -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 09 March, 2009 20:48 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] OMAP3: GPIO off-mode fixes Tero Kristo tero.kri...@nokia.com writes: These two patches add fixes to GPIO off-mode handling. First patch is more important as it fixes a HW bug, second one just optimizes off-mode code a bit by removing a couple of unnecessary registers from the context save. Thanks, pushing both patches to PM branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3: PM: Fixed glitches in GPIO outputs during off-mode transitions
Output GPIOs will lose their context during wakeup from off-mode, causing
a short glitch in the output level until the GPIO context can be restored.
Pad configuration must be used to set corresponding pins into safe_mode
and pull-up / pull-down control is used to select the level of the signal.
Also, GPIO signals themselves must be set to INPUT mode before switching
pad configuration to safe mode, otherwise this will generate a glitch also.
See OMAP3 errata section 1.158 for more details.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |7 +-
arch/arm/plat-omap/gpio.c | 194 +++-
arch/arm/plat-omap/include/mach/gpio.h |1 +
3 files changed, 197 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7eefbb5..8ee6fa0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -417,9 +417,12 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
- omap2_gpio_resume_after_idle();
- if (per_prev_state == PWRDM_POWER_OFF)
+ if (per_prev_state == PWRDM_POWER_OFF) {
omap3_per_restore_context();
+ omap3_gpio_restore_pad_context(0);
+ } else if (per_next_state == PWRDM_POWER_OFF)
+ omap3_gpio_restore_pad_context(1);
+ omap2_gpio_resume_after_idle();
omap_uart_resume_idle(2);
if (per_state_modified)
pwrdm_set_next_pwrst(per_pwrdm, PWRDM_POWER_OFF);
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f18a191..438c137 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -20,11 +20,13 @@
#include linux/io.h
#include mach/hardware.h
+#include mach/control.h
#include asm/irq.h
#include mach/irqs.h
#include mach/gpio.h
#include asm/mach/irq.h
#include mach/powerdomain.h
+#include mach/mux.h
/*
* OMAP1510 GPIO registers
@@ -221,6 +223,10 @@ static struct gpio_bank gpio_bank_34xx[6] = {
{ OMAP34XX_GPIO6_BASE, INT_34XX_GPIO_BANK6, IH_GPIO_BASE + 160,
METHOD_GPIO_24XX },
};
+#define OMAP34XX_PAD_SAFE_MODE 0x7
+#define OMAP34XX_PAD_IN_PU_GPIO 0x11c
+#define OMAP34XX_PAD_IN_PD_GPIO 0x10c
+
struct omap3_gpio_regs {
u32 sysconfig;
u32 irqenable1;
@@ -238,6 +244,54 @@ struct omap3_gpio_regs {
};
static struct omap3_gpio_regs gpio_context[OMAP34XX_NR_GPIOS];
+
+/* GPIO - PAD init configuration struct */
+struct gpio_pad_range {
+ /* Range start GPIO # */
+ u16 min;
+ /* Range end GPIO # */
+ u16 max;
+ /* Start pad config offset */
+ u16 offset;
+};
+
+/*
+ * Defines GPIO to padconfig mapping. For example first definition tells
+ * us that there is a range of GPIOs 34...43 which have their padconfigs
+ * starting from offset 0x7a, i.e. gpio 34-0x7a, 35-0x7c, 36-0x7e ... etc.
+ */
+static const struct gpio_pad_range gpio_pads_config[] = {
+ { 34, 43, 0x7a },
+ { 44, 51, 0x9e },
+ { 52, 59, 0xb0 },
+ { 60, 62, 0xc6 },
+ { 63, 111, 0xce },
+ { 167, 167, 0x130 },
+ { 126, 126, 0x132 },
+ { 112, 166, 0x134 },
+ { 120, 122, 0x1a2 },
+ { 124, 125, 0x1a8 },
+ { 130, 131, 0x1ac },
+ { 169, 169, 0x1b0 },
+ { 188, 191, 0x1b2 },
+ { 168, 168, 0x1be },
+ { 183, 185, 0x1c0 },
+ { 170, 182, 0x1c6 },
+ { 0, 0, 0x1e0 },
+ { 186, 186, 0x1e2 },
+ { 12, 29, 0x5d8 },
+};
+
+/* GPIO - PAD config mapping for OMAP3 */
+struct gpio_pad {
+ s16 gpio;
+ u16 offset;
+ u16 save;
+};
+
+#define OMAP34XX_GPIO_AMT (32 * OMAP34XX_NR_GPIOS)
+
+struct gpio_pad *gpio_pads;
#endif
static struct gpio_bank *gpio_bank;
@@ -1291,6 +1345,68 @@ static struct clk * gpio5_fck;
#if defined(CONFIG_ARCH_OMAP3)
static struct clk *gpio_iclks[OMAP34XX_NR_GPIOS];
+
+/*
+ * Following pad init code in addition to the context / restore hooks are
+ * needed to fix glitches in GPIO outputs during off-mode. See OMAP3
+ * errate section 1.158
+ */
+static int __init omap3_gpio_pads_init(void)
+{
+ int i, j, min, max, gpio_amt;
+ u16 offset;
+ u16 *gpio_pad_map;
+
+ gpio_amt = 0;
+
+ gpio_pad_map = kzalloc(sizeof(u16) * OMAP34XX_GPIO_AMT, GFP_KERNEL);
+ if (gpio_pad_map == NULL) {
+ printk(KERN_ERR FATAL: Failed to allocate gpio_pad_map\n);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i ARRAY_SIZE(gpio_pads_config); i++) {
+ min = gpio_pads_config[i].min;
+ max = gpio_pads_config[i].max;
+ offset = gpio_pads_config[i].offset;
+
+ for (j = min; j = max; j++) {
+ /*
+* Check if pad has been
[patch 2.6.29-rc7-omap] OMAP1: ASoC buildfix for OSK
From: David Brownell dbrown...@users.sourceforge.net
Buildfix:
CC sound/soc/omap/osk5912.o
sound/soc/omap/osk5912.c: In function 'osk_soc_init':
sound/soc/omap/osk5912.c:189: error: implicit declaration of function
'clk_get_usecount'
make[3]: *** [sound/soc/omap/osk5912.o] Error 1
There's no such (standard) clock interface.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
There is currently such an interface in mainline; but there shouldn't
be ... which is why I'm sending this to the ASoC folk too (I think
those clock updates will hit in the 2.6.30 window).
Some of that OMAP1 clock code got hosed anyway; on top of many build
warnings, an oops in at least the OMAP tree:
asoc: tlv320aic23 - omap-mcbsp-dai-0 mapping ok
Unable to handle kernel NULL pointer dereference at virtual address 0014
pgd = c0004000
[0014] *pgd=
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0Not tainted (2.6.29-rc7-omap1 #10)
PC is at clk_set_rate+0x60/0x90
LR is at omap1_set_ext_clk_rate+0x28/0x68
pc : [c00313b8]lr : [c002f7d0]psr: 6093
sp : c1c21f08 ip : c1c21ed0 fp : c1c21f24
r10: 0001 r9 : r8 : c033eb20
r7 : c001a718 r6 : 8013 r5 : r4 : c0321abc
r3 : r2 : fefe0878 r1 : 0018 r0 : c0321abc
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 0005317f Table: 10004000 DAC: 0017
Process swapper (pid: 1, stack limit = 0xc1c20268)
Stack: (0xc1c21f08 to 0xc1c22000)
1f00: c0776c24 c001a718 c1c21f3c c1c21f28
1f20: c001a7b4 c0031368 c001fb94 c1c21fb4 c1c21f40 c0025240 c001a728
1f40: c1c21f8e c032fa50 c1c4af00 c032fa50 0100 c06edfb8 c1c21f84 c1c21f68
1f60: c00dd070 c00dce10 c1c21f84 c1c49d00 c00dd174 c1c21f8e c1c21fb4 c1c21f88
1f80: c0078ae0 c00dd000 c1c21fac 36330e48 c001fb94
1fa0: c1c21fcc c1c21fb8 c00084b8 c00251f8 c033eb20
1fc0: c1c21fdc c1c21fd0 c00084f4 c00084ac c1c21ff4 c1c21fe0 c000889c c00084e4
1fe0: c1c21ff8 c004737c c0008868
Backtrace:
[c0031358] (clk_set_rate+0x0/0x90) from [c001a7b4] (osk_soc_init+0x9c/0x118)
r7:c001a718 r6: r5: r4:c0776c24
[c001a718] (osk_soc_init+0x0/0x118) from [c0025240]
(__exception_text_end+0x58/0x190)
sound/soc/omap/osk5912.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
--- a/sound/soc/omap/osk5912.c
+++ b/sound/soc/omap/osk5912.c
@@ -186,13 +186,6 @@ static int __init osk_soc_init(void)
return -ENODEV;
}
- if (clk_get_usecount(tlv320aic23_mclk) 0) {
- /* MCLK is already in use */
- printk(KERN_WARNING
- MCLK in use at %d Hz. We change it to %d Hz\n,
- (uint) clk_get_rate(tlv320aic23_mclk), CODEC_CLOCK);
- }
-
/*
* Configure 12 MHz output on MCLK.
*/
@@ -205,9 +198,8 @@ static int __init osk_soc_init(void)
}
}
- printk(KERN_INFO MCLK = %d [%d], usecount = %d\n,
- (uint) clk_get_rate(tlv320aic23_mclk), CODEC_CLOCK,
- clk_get_usecount(tlv320aic23_mclk));
+ printk(KERN_INFO MCLK = %d [%d]\n,
+ (uint) clk_get_rate(tlv320aic23_mclk), CODEC_CLOCK);
return 0;
err1:
--
To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap] OMAP1: OMAP_TAG_USB buildfix (OSK)
From: David Brownell dbrown...@users.sourceforge.net
Build fix:
CC arch/arm/mach-omap1/board-osk.o
arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
arch/arm/mach-omap1/board-osk.c:512: error: implicit declaration of function
'omap_usb_init'
make[1]: *** [arch/arm/mach-omap1/board-osk.o] Error 1
The error is twofold. First, USB is on the mainboard, not the Mistral card;
that's specific to the OSK. Second, header goofage -- hurts all OMAP1 boards.
I'm puzzled by the notion tha the OMAP1: get rid of OMAP_TAG_USB patch could
have been compile-tested.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap1/board-osk.c |3 ++-
arch/arm/plat-omap/include/mach/usb.h | 10 +-
2 files changed, 7 insertions(+), 6 deletions(-)
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -509,7 +509,6 @@ static void __init osk_mistral_init(void
i2c_register_board_info(1, mistral_i2c_board_info,
ARRAY_SIZE(mistral_i2c_board_info));
- omap_usb_init(osk_usb_config);
platform_add_devices(mistral_devices, ARRAY_SIZE(mistral_devices));
}
#else
@@ -541,6 +540,8 @@ static void __init osk_init(void)
l |= (3 1);
omap_writel(l, USB_TRANSCEIVER_CTRL);
+ omap_usb_init(osk_usb_config);
+
/* irq for tps65010 chip */
/* bootloader effectively does: omap_cfg_reg(U19_1610_MPUIO1); */
if (gpio_request(OMAP_MPUIO(1), tps65010) == 0)
--- a/arch/arm/plat-omap/include/mach/usb.h
+++ b/arch/arm/plat-omap/include/mach/usb.h
@@ -33,9 +33,7 @@ extern void usb_musb_init(void);
static inline void usb_musb_init(void)
{
}
-#endif
-
-void omap_usb_init(struct omap_usb_config *pdata);
+#endif /* !OMAP1 !MUSB */
#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)
extern void usb_ehci_init(void);
@@ -43,9 +41,11 @@ extern void usb_ehci_init(void);
static inline void usb_ehci_init(void)
{
}
-#endif
+#endif /* !OMAP1 !EHCI */
-#endif
+#endif /* !OMAP1 */
+
+void omap_usb_init(struct omap_usb_config *pdata);
/*-*/
--
To unsubscribe from this list: send the line unsubscribe 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/Resume support with Omap2fb
Thanks, Vaibhav Hiremath -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, March 11, 2009 3:01 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: RE: Suspend/Resume support with Omap2fb On Wed, 2009-03-11 at 09:46 +0100, ext Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, March 11, 2009 1:23 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: Suspend/Resume support with Omap2fb Hi, On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: Hi, I am using New Frame-Buffer driver which is based on DSS2 library submitted by Tomi, and I am trying to add full power management support. But things are not working out as expected, every time when I am issuing command echo mem /sys/power/state the system doesn't go into off state. It always points to dss_prwdm, below are the steps I am following - OFF mode should work. I have verified it with DSI, DPI and SDI. However, it needs passing the get_last_off_on_transaction_id pointer in omap_dss_platform_data. Also, see below. [Hiremath, Vaibhav] I believe this is only required when you do save and restore context right? Well, yes. But you need to save and restore context if you want OFF mode. [Hiremath, Vaibhav] As I mentioned I am hitting full OFF state (state5), and save and restore is happening perfectly fine. Actually I have modified that part of code where it doesn't expect this pointer and save/restore happens perfectly fine, which I am very will sure about, since I am hitting state5 of CPU_IDLE (Full OFF state) and it resumes back with the same state. Again one more data point which I missed in last mail is, I am following clk-usecount which shows me 0. That means clocks are already disabled. r...@arago:~# cat /sys/devices/platform/omap-dss/clk - dss - internal clk count 0 dss_ick 83000 dss1_alwon_fck 96000 dss2_alwon_fck 13000 dss_tv_fck 54000 dss_96m_fck 96000 - dispc - dispc fclk source = dss1_alwon_fclk pixel clk = 9600 / 1 / 5 = 1920 r...@arago:~# - Build the kernel with CPU_IDLE - Enable all the PM flags # echo 1 /sys/power/sleep_while_idle # echo 1 /sys/power/clocks_off_while_idle # echo 1 /sys/power/enable_off_mode - From Linux prompt issue command # echo mem /sys/power/state The log is - r...@arago:~# echo mem /sys/power/state 6PM: Syncing filesystems ... PM: Syncing filesystems ... done. done. Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. done. Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) 6omap-backlight: suspending... omapfb_suspend omapfb_resume 6omap-backlight: resuming... omap-backlight: suspending... omapfb_suspend Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend eth0: link down omapfb_resume omap-backlight: resuming... Restarting tasks ... Restarting tasks ... done. done. r...@arago:~# Some analysis which I observed during debugging this issue - - The root-cause is, DSS PowerDomain always shows it is in ON state (PWRDM_POWER_ON), and if I understand correctly this is only dependent on clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE enabled I am going to complete OFF state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). - If I compile out framebuffer driver and include DSS2 and V4L2 driver, everything works fine. I am not sure how omapfb is being tied with PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = omapfb, not sure how this is being used. You have to change it to omapdss (or omap-dss in earlier DSS2 versions). [Hiremath, Vaibhav] I have tried this option also, didn't work out. Tomi, Do you have summary or list of changes required in clock and PowerDomain related files to make it work? How have you tested this? Have you also tested with echo mem /sys/power/state? Are you using Kevin's power management tree? What is
Re: [PATCH 2/2] OMAP: McBSP: Do not enable or disable clocks on failed path
On Tue, 10 Mar 2009 19:43:40 +0100 Nurkkala Eero.An (EXT-Offcode/Oulu) ext-eero.nurkk...@nokia.com wrote: Good comment... why do I always do everything in such a hurry, without thinking any =) Either that or leave clock disabling within the spin_lock covered code? (probably risky business) Didn't check any deeply can clk_disable sleep in any case but anyway there is no need to cover it with spinlock so better to not hold the lock while disabling. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: McBSP: Always maintain McBSP fclk while active
On Wed, 11 Mar 2009 06:48:10 +0100 Nurkkala Eero.An (EXT-Offcode/Oulu) ext-eero.nurkk...@nokia.com wrote: On Tue, 2009-03-10 at 15:29 +0100, Nikula Jarkko (Nokia-D/Helsinki) wrote: Looks like a valid change eventhough haven't tested the actual problem. Would it be possible with the PM branch and Beagle now? Jarkko Now this appears to be inherently wrong =) Read this: http://marc.info/?l=linux-omapm=123674373120880w=2 (Of course I went in to mention I am 100% certain the McBSP FCLK is the bit 8 =) Ah, ok. I was also reviewing your patch with even some older TRM (but this was going to be updated anyway only into next TRM) :-) Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc6+misc] MMC: regulator utilities
On Monday 09 March 2009, Liam Girdwood wrote:
From: David Brownell dbrown...@users.sourceforge.net
Glue between MMC and regulator stacks ... verified with
some OMAP3 boards using adjustable and configured-as-fixed
regulators on several MMC controllers.
...
Acked-by: Pierre Ossman drz...@drzeus.cx
Applied.
... actually you applied an old version, not the one that
was verified, with mmc_regulator_set_ocr() fixes and with
Pierre's ACK. The comment is in your GIT tree is wrong,
for starters...
Please use this one instead.
- Dave
== CUT HERE
From: David Brownell dbrown...@users.sourceforge.net
Glue between MMC and regulator stacks ... verified with
some OMAP3 boards using adjustable and configured-as-fixed
regulators on several MMC controllers.
These calls are intended to be used by MMC host adapters
using at least one regulator per host. Examples include
slots with regulators supporting multiple voltages and
ones using multiple voltage rails (e.g. DAT4..DAT7 using a
separate supply, or a split rail chip like certain SDIO
WLAN or eMMC solutions).
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Acked-by: Pierre Ossman drz...@drzeus.cx
---
Changes since previous version: simplified set_ocr() calling
convention, fixed an off-by-100mA error in that code, and don't
set voltage on regulators that don't need (and may disallow) it.
drivers/mmc/core/core.c | 100 +
include/linux/mmc/host.h |5 ++
2 files changed, 105 insertions(+)
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -21,6 +21,7 @@
#include linux/leds.h
#include linux/scatterlist.h
#include linux/log2.h
+#include linux/regulator/consumer.h
#include linux/mmc/card.h
#include linux/mmc/host.h
@@ -523,6 +524,105 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min,
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_REGULATOR
+
+/**
+ * mmc_regulator_get_ocrmask - return mask of supported voltages
+ * @supply: regulator to use
+ *
+ * This returns either a negative errno, or a mask of voltages that
+ * can be provided to MMC/SD/SDIO devices using the specified voltage
+ * regulator. This would normally be called before registering the
+ * MMC host adapter.
+ */
+int mmc_regulator_get_ocrmask(struct regulator *supply)
+{
+ int result = 0;
+ int count;
+ int i;
+
+ count = regulator_count_voltages(supply);
+ if (count 0)
+ return count;
+
+ for (i = 0; i count; i++) {
+ int vdd_uV;
+ int vdd_mV;
+
+ vdd_uV = regulator_list_voltage(supply, i);
+ if (vdd_uV = 0)
+ continue;
+
+ vdd_mV = vdd_uV / 1000;
+ result |= mmc_vddrange_to_ocrmask(vdd_mV, vdd_mV);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_get_ocrmask);
+
+/**
+ * mmc_regulator_set_ocr - set regulator to match host-ios voltage
+ * @vdd_bit: zero for power off, else a bit number (host-ios.vdd)
+ * @supply: regulator to use
+ *
+ * Returns zero on success, else negative errno.
+ *
+ * MMC host drivers may use this to enable or disable a regulator using
+ * a particular supply voltage. This would normally be called from the
+ * set_ios() method.
+ */
+int mmc_regulator_set_ocr(struct regulator *supply, unsigned short vdd_bit)
+{
+ int result = 0;
+ int min_uV, max_uV;
+ int enabled;
+
+ enabled = regulator_is_enabled(supply);
+ if (enabled 0)
+ return enabled;
+
+ if (vdd_bit) {
+ int tmp;
+ int voltage;
+
+ /* REVISIT mmc_vddrange_to_ocrmask() may have set some
+* bits this regulator doesn't quite support ... don't
+* be too picky, most cards and regulators are OK with
+* a 0.1V range goof (it's a small error percentage).
+*/
+ tmp = vdd_bit - ilog2(MMC_VDD_165_195);
+ if (tmp == 0) {
+ min_uV = 1650 * 1000;
+ max_uV = 1950 * 1000;
+ } else {
+ min_uV = 1900 * 1000 + tmp * 100 * 1000;
+ max_uV = min_uV + 100 * 1000;
+ }
+
+ /* avoid needless changes to this voltage; the regulator
+* might not allow this operation
+*/
+ voltage = regulator_get_voltage(supply);
+ if (voltage 0)
+ result = voltage;
+ else if (voltage min_uV || voltage max_uV)
+ result = regulator_set_voltage(supply, min_uV, max_uV);
+ else
+ result = 0;
+
+ if (result == 0 !enabled)
+
Re: [PATCH] ARM: OMAP: Fix GPIO switch initial output state handling
Jani Nikula wrote: INIT_HIGH indicates the state of the gpio, not the state of the switch. Why not ignore the OMAP_GPIO_SWITCH_FLAG_INVERTED all together when setting up the switch. This way, the user does not have to think twice. :) The INVERTED flag can't be ignored, since sw-state must be the opposite of the GPIO if the flag is set. The only question is, should INIT_HIGH flag refer to the GPIO or the switch. I did think about this, and the patch is as I intended it to be, i.e. INIT_HIGH refers to the switch. I thought this would be less confusing. If INVERTED is set, it's inverted *everywhere* - why not also when setting the initial value? How about INIT_ACTIVE to reduce possible confusion? HIGH does imply an electrical level, as opposed to a more abstract activation level. Cheers, Juha -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap] OMAP1: ASoC buildfix for OSK
On Wed, Mar 11, 2009 at 02:37:25AM -0800, David Brownell wrote: There is currently such an interface in mainline; but there shouldn't be ... which is why I'm sending this to the ASoC folk too (I think those clock updates will hit in the 2.6.30 window). I've applied this, thanks. -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap 0/5] mmc-twl4030 loses twl4030-dependency
The last dependency of that code on twl4030 specific behavior was coupled to regulator usage ... and, hey, there's a regulator framework to hide such details! The first four of these patches are from the regulator-next tree: - regulator: enumerate voltages - regulator: twl4030 voltage enumeration - regulator: twl4030 voltage enumeration cleanups - MMC: regulator utilities More precisely ... the first three are, but the wrong version of the fourth got merged; that should get sorted out soonish. The last patch does the magic: - mmc-twl4030 uses regulator framework This works if the boards have hooked up their regulators to the MMC devices. Beagle does that; so does the 3430 SDP (which has a second 1.8V SD/MMCplus slot). I'll resend a patch doing that for Overo. So for example two of Adrian's patches from yesterday are now subsumed by the regulator framework. To have MMC2 hook up to an eMMC chip that needs VccQ for interface level shifting, just hook up the aux supply to that MMC device. To have it use the VAUX3 supply instead of VMMC2, just be sure to hook up the right regulator. -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap 1/5] regulator: enumerate voltages
From: David Brownell dbrown...@users.sourceforge.net
Subject: regulator: enumerate voltages (v2)
Add a basic mechanism for regulators to report the discrete
voltages they support: list_voltage() enumerates them using
selectors numbered from 0 to an upper bound.
Use those methods to force machine-level constraints into bounds.
(Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board
constraints for that rail are 2.0V to 3.6V ... so the range of
voltages is then 2.4V to 3.3V on this board.)
Export those voltages to the regulator consumer interface, so for
example regulator hooked up to an MMC/SD/SDIO slot can report the
actual voltage options available to cards connected there.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
---
drivers/regulator/core.c | 113 +++
include/linux/regulator/consumer.h |2
include/linux/regulator/driver.h |9 ++
3 files changed, 124 insertions(+)
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -719,6 +719,69 @@ static int set_machine_constraints(struc
else
name = regulator;
+ /* constrain machine-level voltage specs to fit
+* the actual range supported by this regulator.
+*/
+ if (ops-list_voltage rdev-desc-n_voltages) {
+ int count = rdev-desc-n_voltages;
+ int i;
+ int min_uV = INT_MAX;
+ int max_uV = INT_MIN;
+ int cmin = constraints-min_uV;
+ int cmax = constraints-max_uV;
+
+ /* it's safe to autoconfigure fixed-voltage supplies */
+ if (count == 1 !cmin) {
+ cmin = INT_MIN;
+ cmax = INT_MAX;
+ }
+
+ /* else require explicit machine-level constraints */
+ else if (cmin = 0 || cmax = 0 || cmax cmin) {
+ pr_err(%s: %s '%s' voltage constraints\n,
+ __func__, invalid, name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* initial: [cmin..cmax] valid, [min_uV..max_uV] not */
+ for (i = 0; i count; i++) {
+ int value;
+
+ value = ops-list_voltage(rdev, i);
+ if (value = 0)
+ continue;
+
+ /* maybe adjust [min_uV..max_uV] */
+ if (value = cmin value min_uV)
+ min_uV = value;
+ if (value = cmax value max_uV)
+ max_uV = value;
+ }
+
+ /* final: [min_uV..max_uV] valid iff constraints valid */
+ if (max_uV min_uV) {
+ pr_err(%s: %s '%s' voltage constraints\n,
+ __func__, unsupportable, name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* use regulator's subset of machine constraints */
+ if (constraints-min_uV min_uV) {
+ pr_debug(%s: override '%s' %s, %d - %d\n,
+ __func__, name, min_uV,
+ constraints-min_uV, min_uV);
+ constraints-min_uV = min_uV;
+ }
+ if (constraints-max_uV max_uV) {
+ pr_debug(%s: override '%s' %s, %d - %d\n,
+ __func__, name, max_uV,
+ constraints-max_uV, max_uV);
+ constraints-max_uV = max_uV;
+ }
+ }
+
rdev-constraints = constraints;
/* do we need to apply the constraint voltage */
@@ -1245,6 +1308,56 @@ int regulator_is_enabled(struct regulato
EXPORT_SYMBOL_GPL(regulator_is_enabled);
/**
+ * regulator_count_voltages - count regulator_list_voltage() selectors
+ * @regulator: regulator source
+ *
+ * Returns number of selectors, or negative errno. Selectors are
+ * numbered starting at zero, and typically correspond to bitfields
+ * in hardware registers.
+ */
+int regulator_count_voltages(struct regulator *regulator)
+{
+ struct regulator_dev*rdev = regulator-rdev;
+
+ return rdev-desc-n_voltages ? : -EINVAL;
+}
+EXPORT_SYMBOL_GPL(regulator_count_voltages);
+
+/**
+ * regulator_list_voltage - enumerate supported voltages
+ * @regulator: regulator source
+ * @selector: identify voltage to list
+ * Context: can sleep
+ *
+ * Returns a voltage that can be passed to @regulator_set_voltage(),
+ * zero if this selector code can't be used on this sytem, or a
+ * negative errno.
+ */
+int regulator_list_voltage(struct regulator
[patch 2.6.29-rc7-omap 2/5] regulator: twl4030 voltage enumeration
From: David Brownell dbrown...@users.sourceforge.net
Subject: regulator: twl4030 voltage enumeration (v2)
Update previously-posted twl4030 regulator driver to export
supported voltages to upper layers using a new mechanism.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
---
drivers/regulator/twl4030-regulator.c | 62 +++-
1 file changed, 23 insertions(+), 39 deletions(-)
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -42,7 +42,6 @@ struct twlreg_info {
/* chip constraints on regulator behavior */
u16 min_mV;
- u16 max_mV;
/* used by regulator core */
struct regulator_desc desc;
@@ -262,6 +261,14 @@ static const u16 VDAC_VSEL_table[] = {
};
+static int twl4030ldo_list_voltage(struct regulator_dev *rdev, unsigned index)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int mV = info-table[index];
+
+ return IS_UNSUP(mV) ? 0 : (LDO_MV(mV) * 1000);
+}
+
static int
twl4030ldo_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV)
{
@@ -276,6 +283,8 @@ twl4030ldo_set_voltage(struct regulator_
continue;
uV = LDO_MV(mV) * 1000;
+ /* REVISIT for VAUX2, first match may not be best/lowest */
+
/* use the first in-range value */
if (min_uV = uV uV = max_uV)
return twl4030reg_write(info, VREG_DEDICATED, vsel);
@@ -297,6 +306,8 @@ static int twl4030ldo_get_voltage(struct
}
static struct regulator_ops twl4030ldo_ops = {
+ .list_voltage = twl4030ldo_list_voltage,
+
.set_voltage= twl4030ldo_set_voltage,
.get_voltage= twl4030ldo_get_voltage,
@@ -314,6 +325,13 @@ static struct regulator_ops twl4030ldo_o
/*
* Fixed voltage LDOs don't have a VSEL field to update.
*/
+static int twl4030fixed_list_voltage(struct regulator_dev *rdev, unsigned
index)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ return info-min_mV * 1000;
+}
+
static int twl4030fixed_get_voltage(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
@@ -322,6 +340,8 @@ static int twl4030fixed_get_voltage(stru
}
static struct regulator_ops twl4030fixed_ops = {
+ .list_voltage = twl4030fixed_list_voltage,
+
.get_voltage= twl4030fixed_get_voltage,
.enable = twl4030reg_enable,
@@ -343,6 +363,7 @@ static struct regulator_ops twl4030fixed
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
+ .n_voltages = ARRAY_SIZE(label##_VSEL_table), \
.ops = twl4030ldo_ops, \
.type = REGULATOR_VOLTAGE, \
.owner = THIS_MODULE, \
@@ -353,10 +374,10 @@ static struct regulator_ops twl4030fixed
.base = offset, \
.id = num, \
.min_mV = mVolts, \
- .max_mV = mVolts, \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
+ .n_voltages = 1, \
.ops = twl4030fixed_ops, \
.type = REGULATOR_VOLTAGE, \
.owner = THIS_MODULE, \
@@ -402,14 +423,11 @@ static int twl4030reg_probe(struct platf
struct regulator_init_data *initdata;
struct regulation_constraints *c;
struct regulator_dev*rdev;
- int min_uV, max_uV;
for (i = 0, info = NULL; i ARRAY_SIZE(twl4030_regs); i++) {
if (twl4030_regs[i].desc.id != pdev-id)
continue;
info = twl4030_regs + i;
- min_uV = info-min_mV * 1000;
- max_uV = info-max_mV * 1000;
break;
}
if (!info)
@@ -423,10 +441,6 @@ static int twl4030reg_probe(struct platf
* this driver and the chip itself can actually do.
*/
c = initdata-constraints;
- if (!c-min_uV || c-min_uV min_uV)
- c-min_uV = min_uV;
- if (!c-max_uV || c-max_uV max_uV)
- c-max_uV = max_uV;
c-valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
| REGULATOR_CHANGE_MODE
@@ -471,36 +485,6 @@ static struct platform_driver twl4030reg
static int __init twl4030reg_init(void)
{
- unsigned i, j;
-
- /* determine min/max voltage constraints, taking into account
-* whether set_voltage() will use the unsupported settings
-*/
- for (i = 0; i ARRAY_SIZE(twl4030_regs); i++) {
- struct twlreg_info *info = twl4030_regs + i;
- const u16
[patch 2.6.29-rc7-omap 3/5] regulator: twl4030 voltage enumeration cleanup
From: David Brownell dbrown...@users.sourceforge.net
Subject: regulator: twl4030 voltage enumeration (v2) cleanups
Minor cleanups to the twl403 regulator driver, mostly enabled
by other recent changes: comments, shrink memory usage, add
definition for one bit.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
---
drivers/regulator/twl4030-regulator.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -36,13 +36,13 @@ struct twlreg_info {
/* twl4030 resource ID, for resource control state machine */
u8 id;
+ /* FIXED_LDO voltage */
+ u8 deciV;
+
/* voltage in mV = table[VSEL]; table_len must be a power-of-two */
u8 table_len;
const u16 *table;
- /* chip constraints on regulator behavior */
- u16 min_mV;
-
/* used by regulator core */
struct regulator_desc desc;
};
@@ -97,6 +97,7 @@ static int twl4030reg_grp(struct regulat
#define P3_GRP BIT(7) /* peripherals */
#define P2_GRP BIT(6) /* secondary processor, modem, etc */
#define P1_GRP BIT(5) /* CPU/Linux */
+#define WARM_CFG BIT(4)
static int twl4030reg_is_enabled(struct regulator_dev *rdev)
{
@@ -329,14 +330,14 @@ static int twl4030fixed_list_voltage(str
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- return info-min_mV * 1000;
+ return info-deciV * 100 * 1000;
}
static int twl4030fixed_get_voltage(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- return info-min_mV * 1000;
+ return info-deciV * 100 * 1000;
}
static struct regulator_ops twl4030fixed_ops = {
@@ -373,7 +374,7 @@ static struct regulator_ops twl4030fixed
#define TWL_FIXED_LDO(label, offset, mVolts, num) { \
.base = offset, \
.id = num, \
- .min_mV = mVolts, \
+ .deciV = mVolts / 100 , \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
@@ -385,7 +386,7 @@ static struct regulator_ops twl4030fixed
}
/*
- * We list regulators here if systems need some level of
+ * We expose regulators here if systems need some level of
* software control over them after boot.
*/
static struct twlreg_info twl4030_regs[] = {
@@ -439,6 +440,7 @@ static int twl4030reg_probe(struct platf
/* Constrain board-specific capabilities according to what
* this driver and the chip itself can actually do.
+* (Regulator core now does this for voltage constraints.)
*/
c = initdata-constraints;
c-valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
--
To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap 4/5] MMC: regulator utilities
From: David Brownell dbrown...@users.sourceforge.net
Subject: MMC: regulator utilities
Glue between MMC and regulator stacks ... verified with
some OMAP3 boards using adjustable and configured-as-fixed
regulators on several MMC controllers.
These calls are intended to be used by MMC host adapters
using at least one regulator per host. Examples include
slots with regulators supporting multiple voltages and
ones using multiple voltage rails (e.g. DAT4..DAT7 using a
separate supply, or a split rail chip like certain SDIO
WLAN or eMMC solutions).
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Acked-by: Pierre Ossman drz...@drzeus.cx
---
Changes since previous version: simplified set_ocr() calling
convention, fixed an off-by-100mA error in that code, and don't
set voltage on regulators that don't need (and may disallow) it.
drivers/mmc/core/core.c | 100 +
include/linux/mmc/host.h |5 ++
2 files changed, 105 insertions(+)
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -21,6 +21,7 @@
#include linux/leds.h
#include linux/scatterlist.h
#include linux/log2.h
+#include linux/regulator/consumer.h
#include linux/mmc/card.h
#include linux/mmc/host.h
@@ -523,6 +524,105 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min,
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_REGULATOR
+
+/**
+ * mmc_regulator_get_ocrmask - return mask of supported voltages
+ * @supply: regulator to use
+ *
+ * This returns either a negative errno, or a mask of voltages that
+ * can be provided to MMC/SD/SDIO devices using the specified voltage
+ * regulator. This would normally be called before registering the
+ * MMC host adapter.
+ */
+int mmc_regulator_get_ocrmask(struct regulator *supply)
+{
+ int result = 0;
+ int count;
+ int i;
+
+ count = regulator_count_voltages(supply);
+ if (count 0)
+ return count;
+
+ for (i = 0; i count; i++) {
+ int vdd_uV;
+ int vdd_mV;
+
+ vdd_uV = regulator_list_voltage(supply, i);
+ if (vdd_uV = 0)
+ continue;
+
+ vdd_mV = vdd_uV / 1000;
+ result |= mmc_vddrange_to_ocrmask(vdd_mV, vdd_mV);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_get_ocrmask);
+
+/**
+ * mmc_regulator_set_ocr - set regulator to match host-ios voltage
+ * @vdd_bit: zero for power off, else a bit number (host-ios.vdd)
+ * @supply: regulator to use
+ *
+ * Returns zero on success, else negative errno.
+ *
+ * MMC host drivers may use this to enable or disable a regulator using
+ * a particular supply voltage. This would normally be called from the
+ * set_ios() method.
+ */
+int mmc_regulator_set_ocr(struct regulator *supply, unsigned short vdd_bit)
+{
+ int result = 0;
+ int min_uV, max_uV;
+ int enabled;
+
+ enabled = regulator_is_enabled(supply);
+ if (enabled 0)
+ return enabled;
+
+ if (vdd_bit) {
+ int tmp;
+ int voltage;
+
+ /* REVISIT mmc_vddrange_to_ocrmask() may have set some
+* bits this regulator doesn't quite support ... don't
+* be too picky, most cards and regulators are OK with
+* a 0.1V range goof (it's a small error percentage).
+*/
+ tmp = vdd_bit - ilog2(MMC_VDD_165_195);
+ if (tmp == 0) {
+ min_uV = 1650 * 1000;
+ max_uV = 1950 * 1000;
+ } else {
+ min_uV = 1900 * 1000 + tmp * 100 * 1000;
+ max_uV = min_uV + 100 * 1000;
+ }
+
+ /* avoid needless changes to this voltage; the regulator
+* might not allow this operation
+*/
+ voltage = regulator_get_voltage(supply);
+ if (voltage 0)
+ result = voltage;
+ else if (voltage min_uV || voltage max_uV)
+ result = regulator_set_voltage(supply, min_uV, max_uV);
+ else
+ result = 0;
+
+ if (result == 0 !enabled)
+ result = regulator_enable(supply);
+ } else if (enabled) {
+ result = regulator_disable(supply);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_set_ocr);
+
+#endif
+
/*
* Mask off any voltages we don't support and select
* the lowest voltage
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -192,5 +192,10 @@ static inline void mmc_signal_sdio_irq(s
wake_up_process(host-sdio_irq_thread);
}
+struct regulator;
+
+int mmc_regulator_get_ocrmask(struct regulator
[patch 2.6.29-rc7-omap 5/5] mmc-twl4030 uses regulator framework
From: David Brownell dbrown...@users.sourceforge.net
Subject: mmc-twl4030 uses regulator framework
Finish decoupling the HSMMC glue from the twl4030 as the only
regulator provider, using the regulator framework instead.
This makes the glue's mmc-twl4030 name become a complete
misnomer ... this code could probably all migrate into the
HSMMC driver now.
Tested on 3430SDP (SD and low-voltage MMC) and Beagle (SD),
plus some other boards (including Overo) after they were
converted to set up MMC regulators properly.
Eventually all boards should just associate a regulator with
each MMC controller they use. In some cases (Overo MMC2 and
Pandora MMC3, at least) that would be a fixed-voltage regulator
with no real software control. As a temporary hack (pending
regulator-next updates to make the fixed.c regulator become
usable) there's a new ocr_mask field for those boards.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/mmc-twl4030.c | 262 +---
arch/arm/mach-omap2/mmc-twl4030.h |3
drivers/mmc/host/omap_hsmmc.c |6
3 files changed, 100 insertions(+), 171 deletions(-)
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -16,8 +16,8 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/gpio.h
-#include linux/i2c/twl4030.h
-#include linux/regulator/machine.h
+#include linux/mmc/host.h
+#include linux/regulator/consumer.h
#include mach/hardware.h
#include mach/control.h
@@ -26,31 +26,9 @@
#include mmc-twl4030.h
-#if defined(CONFIG_TWL4030_CORE) \
- (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
-
-#define LDO_CLR0x00
-#define VSEL_S2_CLR0x40
-
-#define VMMC1_DEV_GRP 0x27
-#define VMMC1_CLR 0x00
-#define VMMC1_315V 0x03
-#define VMMC1_300V 0x02
-#define VMMC1_285V 0x01
-#define VMMC1_185V 0x00
-#define VMMC1_DEDICATED0x2A
-#define VMMC2_DEV_GRP 0x2B
-#define VMMC2_CLR 0x40
-#define VMMC2_315V 0x0c
-#define VMMC2_300V 0x0b
-#define VMMC2_285V 0x0a
-#define VMMC2_280V 0x09
-#define VMMC2_260V 0x08
-#define VMMC2_185V 0x06
-#define VMMC2_DEDICATED0x2E
-
-#define VMMC_DEV_GRP_P10x20
+#if defined(CONFIG_REGULATOR) \
+ (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
@@ -59,19 +37,16 @@ static u16 control_devconf1_offset;
static struct twl_mmc_controller {
struct omap_mmc_platform_data *mmc;
- u8 twl_vmmc_dev_grp;
- u8 twl_mmc_dedicated;
- charname[HSMMC_NAME_LEN + 1];
-} hsmmc[OMAP34XX_NR_MMC] = {
- {
- .twl_vmmc_dev_grp = VMMC1_DEV_GRP,
- .twl_mmc_dedicated = VMMC1_DEDICATED,
- },
- {
- .twl_vmmc_dev_grp = VMMC2_DEV_GRP,
- .twl_mmc_dedicated = VMMC2_DEDICATED,
- },
-};
+ /* Vcc == configured supply
+* Vcc_alt == optional
+* - MMC1, supply for DAT4..DAT7
+* - MMC2/MMC2, external level shifter voltage supply, for
+* chip (SDIO, eMMC, etc) or transceiver (MMC2 only)
+*/
+ struct regulator*vcc;
+ struct regulator*vcc_aux;
+ charname[HSMMC_NAME_LEN + 1];
+} hsmmc[OMAP34XX_NR_MMC];
static int twl_mmc_card_detect(int irq)
{
@@ -117,16 +92,42 @@ static int twl_mmc_late_init(struct devi
int ret = 0;
int i;
- ret = gpio_request(mmc-slots[0].switch_pin, mmc_cd);
- if (ret)
- goto done;
- ret = gpio_direction_input(mmc-slots[0].switch_pin);
- if (ret)
- goto err;
+ /* MMC/SD/SDIO doesn't require a card detect switch */
+ if (gpio_is_valid(mmc-slots[0].switch_pin)) {
+ ret = gpio_request(mmc-slots[0].switch_pin, mmc_cd);
+ if (ret)
+ goto done;
+ ret = gpio_direction_input(mmc-slots[0].switch_pin);
+ if (ret)
+ goto err;
+ }
+ /* require at least main regulator */
for (i = 0; i ARRAY_SIZE(hsmmc); i++) {
if (hsmmc[i].name == mmc-slots[0].name) {
+ struct regulator *reg;
+
hsmmc[i].mmc = mmc;
+
+ reg = regulator_get(dev, vmmc);
+ if (IS_ERR(reg)) {
+ dev_dbg(dev, vmmc regulator missing\n);
+ /* HACK: until fixed.c regulator is usable,
+* we don't require a main regulator
+
RE: Suspend/Resume support with Omap2fb
On Wed, 2009-03-11 at 11:47 +0100, ext Hiremath, Vaibhav wrote: How have you tested this? Have you also tested with echo mem /sys/power/state? Are you using Kevin's power management tree? What is default configuration of your kernel during this test? It's been some time since I tested it, but it did work on OMAP3 SDP with the pm-branch. Only changed needed were the get_last_off_on_transaction_id and omapfb - omapdss. I also tested echo mem I'll try to find time to test it again with latest trees. [Hiremath, Vaibhav] That would be great, I am also trying few things here at my end. Hopefully I will get something. Yeah, it works ok for me. I rebased my DSS2 tree to latest l-o, then merged pm-branch, and made the changes mentioned above. I get some warnings from getnstimeofday when resuming the kernel, but they seem to be unrelated to DSS, and the image is fine after resume. I used my dss_omap_3430sdp_defconfig and made the following commands to enable PM: echo 1 /sys/power/clocks_off_while_idle echo 1 /sys/power/enable_off_mode echo 1 /sys/power/voltage_off_while_idle echo 1 /sys/power/sleep_while_idle 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
[PATCH v2] ARM: OMAP: Fix GPIO switch initial output state handling
The switchover to cross-platform GPIO interface unexpectedly caused all
output GPIO switches to be set to high state by default, unlike the
original OMAP code. Introduce a new GPIO switch flag to define the
initial state of the switch. Unless the flag is set, the default is now
inactive state of the switch.
Also store the state of output switches directly into the switch struct
instead of trying to read an output GPIO.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
---
arch/arm/plat-omap/gpio-switch.c | 13 +
arch/arm/plat-omap/include/mach/gpio-switch.h | 11 ++-
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/gpio-switch.c b/arch/arm/plat-omap/gpio-switch.c
index 2b5665d..9053ea0 100644
--- a/arch/arm/plat-omap/gpio-switch.c
+++ b/arch/arm/plat-omap/gpio-switch.c
@@ -286,12 +286,17 @@ static int __init new_switch(struct gpio_switch *sw)
/* input: 1, output: 0 */
direction = !(sw-flags OMAP_GPIO_SWITCH_FLAG_OUTPUT);
- if (direction)
+ if (direction) {
gpio_direction_input(sw-gpio);
- else
- gpio_direction_output(sw-gpio, true);
+ sw-state = gpio_sw_get_state(sw);
+ } else {
+ int state = sw-state = !!(sw-flags
+ OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_ACTIVE);
- sw-state = gpio_sw_get_state(sw);
+ if (sw-flags OMAP_GPIO_SWITCH_FLAG_INVERTED)
+ state = !state;
+ gpio_direction_output(sw-gpio, state);
+ }
r = 0;
r |= device_create_file(sw-pdev.dev, dev_attr_state);
diff --git a/arch/arm/plat-omap/include/mach/gpio-switch.h
b/arch/arm/plat-omap/include/mach/gpio-switch.h
index a143253..2096780 100644
--- a/arch/arm/plat-omap/include/mach/gpio-switch.h
+++ b/arch/arm/plat-omap/include/mach/gpio-switch.h
@@ -24,11 +24,12 @@
* low - inactive
*
*/
-#define OMAP_GPIO_SWITCH_TYPE_COVER0x
-#define OMAP_GPIO_SWITCH_TYPE_CONNECTION 0x0001
-#define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
-#define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
-#define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
+#define OMAP_GPIO_SWITCH_TYPE_COVER0x
+#define OMAP_GPIO_SWITCH_TYPE_CONNECTION 0x0001
+#define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
+#define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
+#define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
+#define OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_ACTIVE 0x0004
struct omap_gpio_switch {
const char *name;
--
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: Problems in cpuidle
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, March 10, 2009 8:45 PM
To: Premi, Sanjeev
Cc: Högander Jouni; linux-omap@vger.kernel.org
Subject: Re: Problems in cpuidle
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Högander Jouni [mailto:jouni.hogan...@nokia.com]
Sent: Monday, March 09, 2009 3:36 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: Problems in cpuidle
ext Premi, Sanjeev pr...@ti.com writes:
While working with cpuidle, I have come across these problems.
I am also working on the solutions, but would be good to
hear more
thoughts.
1) The flag 'enable_dyn_sleep' is honoured only in
omap3_idle_bm_check()
but in the C1 state, omap3_enter_idle() is invoked directly.
So, the system can transition to deeper idle state(s)
Same is the case with 'sleep_block'.
Possible Solutions:
a) Call omap3_can_sleep() in omap3_enter_idle().
This makes omap3_idle_bm_check() redundant; and
can be removed.
b) Make single entry point for all idle states
But would be an overkill for C1 state.
c) Change omap3_can_sleep() to check for
omap_uart_can_sleep()
and omap3_fclks_active() only.
Move check for 'enable_dyn_sleep' and 'sleep_block' into
omap3_enter_idle()
I believe (c) would be the most optimal.
Selecting (c) will break traditional pm_idle. Current plan
is to add
one more C state (C1) which would prevent mpu/core sleep
transitions.
Then remove fclk_active check completely.
[sp] I meant doing the same for pm_idle as well.
Also, the new cstate will not help with 'sleep' block.
The proposed change look like:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx index 7fc3cb3..c25158c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -82,6 +82,11 @@ static int omap3_enter_idle(struct
cpuidle_device *dev,
/* Used to keep track of the total time in idle */
getnstimeofday(ts_preidle);
+ if (!enable_dyn_sleep)
+ goto return_sleep_time;
+ if (atomic_read(sleep_block) 0)
+ goto return_sleep_time;
+
/*
* Adjust the idle state (if required).
* Also, ensure that usage statistics of correct
state are updated.
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index 0716d60..5c7819a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -476,14 +476,10 @@ static int omap3_fclks_active(void)
int omap3_can_sleep(void)
{
- if (!enable_dyn_sleep)
- return 0;
if (!omap_uart_can_sleep())
return 0;
if (omap3_fclks_active())
return 0;
- if (atomic_read(sleep_block) 0)
- return 0;
return 1;
}
@@ -534,6 +530,11 @@ err:
static void omap3_pm_idle(void)
{
+ if (!enable_dyn_sleep)
+ return;
+ if (atomic_read(sleep_block) 0)
+ return;
+
local_irq_disable();
local_fiq_disable();
Sanjeev,
I think it's cleaner to just make all the states go through
the 'bm_check', so the standard PM idle and CPUidle use the
same paths.
[sp] I was trying to avoid duplicate code.
When all states go thru bm_check, omap3_enter_idle_bm() and
omap3_enter_idle() can be collapsed into single function.
Your thoughts?
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: Fix GPIO switch initial output state handling
I am okay with this. Thanks for the patch.
On Wed, Mar 11, 2009 at 8:07 AM, Jani Nikula
ext-jani.1.nik...@nokia.com wrote:
The switchover to cross-platform GPIO interface unexpectedly caused all
output GPIO switches to be set to high state by default, unlike the
original OMAP code. Introduce a new GPIO switch flag to define the
initial state of the switch. Unless the flag is set, the default is now
inactive state of the switch.
Also store the state of output switches directly into the switch struct
instead of trying to read an output GPIO.
Signed-off-by: Jani Nikula ext-jani.1.nik...@nokia.com
---
arch/arm/plat-omap/gpio-switch.c | 13 +
arch/arm/plat-omap/include/mach/gpio-switch.h | 11 ++-
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/gpio-switch.c
b/arch/arm/plat-omap/gpio-switch.c
index 2b5665d..9053ea0 100644
--- a/arch/arm/plat-omap/gpio-switch.c
+++ b/arch/arm/plat-omap/gpio-switch.c
@@ -286,12 +286,17 @@ static int __init new_switch(struct gpio_switch *sw)
/* input: 1, output: 0 */
direction = !(sw-flags OMAP_GPIO_SWITCH_FLAG_OUTPUT);
- if (direction)
+ if (direction) {
gpio_direction_input(sw-gpio);
- else
- gpio_direction_output(sw-gpio, true);
+ sw-state = gpio_sw_get_state(sw);
+ } else {
+ int state = sw-state = !!(sw-flags
+ OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_ACTIVE);
- sw-state = gpio_sw_get_state(sw);
+ if (sw-flags OMAP_GPIO_SWITCH_FLAG_INVERTED)
+ state = !state;
+ gpio_direction_output(sw-gpio, state);
+ }
r = 0;
r |= device_create_file(sw-pdev.dev, dev_attr_state);
diff --git a/arch/arm/plat-omap/include/mach/gpio-switch.h
b/arch/arm/plat-omap/include/mach/gpio-switch.h
index a143253..2096780 100644
--- a/arch/arm/plat-omap/include/mach/gpio-switch.h
+++ b/arch/arm/plat-omap/include/mach/gpio-switch.h
@@ -24,11 +24,12 @@
* low - inactive
*
*/
-#define OMAP_GPIO_SWITCH_TYPE_COVER0x
-#define OMAP_GPIO_SWITCH_TYPE_CONNECTION 0x0001
-#define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
-#define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
-#define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
+#define OMAP_GPIO_SWITCH_TYPE_COVER0x
+#define OMAP_GPIO_SWITCH_TYPE_CONNECTION 0x0001
+#define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
+#define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
+#define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
+#define OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_ACTIVE 0x0004
struct omap_gpio_switch {
const char *name;
--
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
--
To unsubscribe from this list: send the line unsubscribe 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] omap24xxcam: Fix use count handling if sensor enable fails in open()
Decrease use count back if omap24xxcam_sensor_enable() fails in
omap24xxcam_open(). Thanks to Hans Verkuil for pointing this out.
Compile tested only.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/omap24xxcam.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap24xxcam.c
b/drivers/media/video/omap24xxcam.c
index 73eb656..3002051 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -1476,10 +1476,8 @@ static int omap24xxcam_open(struct file *file)
if (atomic_inc_return(cam-users) == 1) {
omap24xxcam_hwinit(cam);
- if (omap24xxcam_sensor_enable(cam)) {
- mutex_unlock(cam-mutex);
+ if (omap24xxcam_sensor_enable(cam))
goto out_omap24xxcam_sensor_enable;
- }
}
mutex_unlock(cam-mutex);
@@ -1502,7 +1500,9 @@ static int omap24xxcam_open(struct file *file)
return 0;
out_omap24xxcam_sensor_enable:
+ atomic_dec(cam-users);
omap24xxcam_poweron_reset(cam);
+ mutex_unlock(cam-mutex);
module_put(cam-sdev-module);
out_try_module_get:
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe 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] ASoC: Complete Beagleboard support
On Wed, Jan 21, 2009 at 1:09 AM, Jarkko Nikula jarkko.nik...@nokia.com wrote: On Tue, 20 Jan 2009 23:05:27 -0800 ext Steve Sakoman sako...@gmail.com wrote: Commit dc06102a0c8b5aa0dd7f9a40ce241e793c252a87 in the asoc tree did not include the necessary Kconfig and Makefile changes. This patch completes the support for Beagleboard Signed-off-by: Steve Sakoman st...@sakoman.com Acked-by: Jarkko Nikula jarkko.nik...@nokia.com Not tested but definitely a way to go forward :-) Any updates on the status of this patch? Doesn't seem to have been applied yet. I've seen lot's of folks on the Beagle mailing list and IRC channels who are getting bitten by this issue. Steve -- To unsubscribe from this list: send the line unsubscribe 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] ASoC: Complete Beagleboard support
On Wed, Mar 11, 2009 at 06:50:18AM -0700, Steve Sakoman wrote: Any updates on the status of this patch? Doesn't seem to have been applied yet. I've seen lot's of folks on the Beagle mailing list and IRC channels who are getting bitten by this issue. It's been applied: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=80c509fdd74f3b158267374cc55156965c8bf930 -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap] twl4030-regulator: list more VAUX4 voltages
On Tue, 2009-03-10 at 11:51 -0800, David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net The VAUX4 voltage table scrolls onto a second page in many versions of the TWL4030 family manuals. This doesn't mean we should ignore those values! Some boards use the (fully supported) 2.8V setting. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- Applied to regulator-next. Thanks Liam -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv2] PM : cpuidle - Update statistics for correct state
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, March 09, 2009 11:31 PM
To: Premi, Sanjeev
Cc: Högander Jouni; linux-omap@vger.kernel.org
Subject: Re: [PATCHv2] PM : cpuidle - Update statistics for
correct state
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Högander Jouni [mailto:jouni.hogan...@nokia.com]
Sent: Monday, March 09, 2009 4:07 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv2] PM : cpuidle - Update statistics
for correct
state
ext Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Högander Jouni [mailto:jouni.hogan...@nokia.com]
Sent: Monday, March 09, 2009 3:38 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv2] PM : cpuidle - Update statistics
for correct
state
ext Sanjeev Premi pr...@ti.com writes:
When 'enable_off_mode' is 0, and (mpu_state
PWRDM_POWER_RET) the
local variables mpu_state and core_state are modified; but
the usage
count for the original state selected by the governor
are updated.
This patch updates the 'last_state' in the cpuidle
driver to ensure
that statistics for the correct state are updated.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 29
+++--
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 62fbb2e..b138abd 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -76,23 +76,32 @@ static int omap3_enter_idle(struct
cpuidle_device
*dev, {
struct omap3_processor_cx *cx =
cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
- u32 mpu_state = cx-mpu_state, core_state =
cx-core_state;
-
- current_cx_state = *cx;
+ u32 mpu_state, core_state;
/* Used to keep track of the total time in idle */
getnstimeofday(ts_preidle);
- local_irq_disable();
- local_fiq_disable();
-
+ /*
+ * Adjust the idle state (if required).
+ * Also, ensure that usage statistics of correct state
are updated.
+ */
if (!enable_off_mode) {
- if (mpu_state PWRDM_POWER_RET)
- mpu_state = PWRDM_POWER_RET;
- if (core_state PWRDM_POWER_RET)
- core_state = PWRDM_POWER_RET;
+ if (cx-type OMAP3_STATE_C4) {
+ state =
(dev-states[OMAP3_STATE_C4 - 1]);
+ dev-last_state = state ;
+
+ cx = cpuidle_get_statedata(state);
There is still C3 where OFF is used for MPU. This needs to
be taken
into account.
[sp] Thanks. Good catch!
I wasn't happy doing the OMAP3_STATEn - 1; but could
not find a better way.
It should be C2 as defined now.
This means C4 is not used if off mode is not enabled? I
think this is
not wanted. Would it be possible to remove OFF C states when
enable_off_mode is written to 0 and add them back when 1 written?
[sp] That should be possible. We could use the 'valid' field
for the purpose.
I would gladly take a patch which uses the 'valid' field for
this and then the enter hook whould drop to the next lower
valid state if the state requested is not valid.
Kevin
[sp] I have not yet tested it (working offline for sometime).
But, wanted to share the changes for an early review.
Initially, I was trying see if the CPUIDLE framework could
use .valid as an additional argument in cpuidle_state.
But, may be that's for later...
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx
index c25158c..9493553 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -88,16 +88,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
goto return_sleep_time;
/*
+* Check if the chosen idle state is valid.
+* If no, drop down to a lower valid state. Expects the lowest
+* state will always be active.
*/
+ if (!cx-valid) {
+ for (idx = (cx-type - 1); idx == 1; idx--) {
+ if (omap3_power_states[idx].valid)
+ break;
}
+ state = (dev-states[idx]);
+ dev-last_state = state ;
+
+ cx = cpuidle_get_statedata(state);
}
current_cx_state = *cx;
@@ -150,6 +153,26 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
return omap3_enter_idle(dev, new_state);
}
+/**
+ * omap3_toggle_off_states - Enable / Disable validity of idle
Re: [patch 2.6.29-rc6+misc] MMC: regulator utilities
On Wed, 2009-03-11 at 03:30 -0800, David Brownell wrote: On Monday 09 March 2009, Liam Girdwood wrote: From: David Brownell dbrown...@users.sourceforge.net Glue between MMC and regulator stacks ... verified with some OMAP3 boards using adjustable and configured-as-fixed regulators on several MMC controllers. ... Acked-by: Pierre Ossman drz...@drzeus.cx Applied. ... actually you applied an old version, not the one that was verified, with mmc_regulator_set_ocr() fixes and with Pierre's ACK. The comment is in your GIT tree is wrong, for starters... Please use this one instead. I've removed the old patch now and applied the correct one. In the future could you start a new thread or change the thread subject a little (i.e. patch V2) when a patch changes during discussion. This should avoid similar confusion in the future. Thanks Liam -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
Hi Folks, With the latest linux-omap pm + gitorious bridge changes on SDP3430, enabling BRIDGE_DVFS and SRF seems to cause an issue with clock notifier.. I am not entirely of the cause of the issue(don't have a debugger handy at the moment :( ): The condition is reproducible on exactly the third insmod of the driver as explained below. Looking for any advice to fix this issue :( Codebase: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm --track origin/pm git fetch git://gitorious.org/lk/mainline.git tidspbridge-pm:tidspbridge-pm git checkout tidspbridge-pm git merge pm defconfig: essentially omap_3430sdp_defconfig, enable SRF and bridge+bridge_dvfs. (diff b/w defconfig and .config attached). Bootargs: console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs rw nfsroot=myIP:myFS,nolock,wsize=1024,rsize=1024 mem=64M The error: insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 Unable to handle kernel paging request at virtual address 756e696c pgd = c3e0c000 *pgd=[756e696c] Internal error: Oops: 5 [#1] Modules linked in:Modules linked in: bridgedriver(+) bridgedriver(+) [last unloaded: bridgedriver] [last unloaded: bridgedriver] CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442 #1) PC is at clk_notifier_register+0x68/0x108 LR is at kmem_cache_alloc+0x7c/0x84 pc : [c003f684]lr : [c009f574]psr: 0093 sp : c3e05da0 ip : c3e0b3e0 fp : c3e05dbc snip Backtrace: Backtrace: [c003f61c] [c003f61c] (clk_notifier_register+0x0/0x108) (clk_notifier_register+0x0/0x108) from [bf08d394] from [bf08d394] (bridge_init+0x394/0x3ec [bridgedriver]) (bridge_init+0x394/0x3ec [bridgedriver]) r7: r7: r6:bf08ab88 r6:bf08ab88 r5:1dcd6500 r5:1dcd6500 r4:0ee6b280 r4:0ee6b280 [bf08d000] [bf08d000] (bridge_init+0x0/0x3ec [bridgedriver]) (bridge_init+0x0/0x3ec [bridgedriver]) from [c002d2d4] from [c002d2d4] (do_one_initcall+0x64/0x198) (do_one_initcall+0x64/0x198) r8:c002df28 r8:c002df28 r7: r7: r6:4023a000 r6:4023a000 r5:bf08a520 r5:bf08a520 r4:c03aa340 r4:c03aa340 [c002d270] [c002d270] (do_one_initcall+0x0/0x198) (do_one_initcall+0x0/0x198) from [c0078cac] from [c0078cac] (sys_init_module+0x98/0x188) (sys_init_module+0x98/0x188) [c0078c14] [c0078c14] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [c002dd80] from [c002dd80] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: Code: Code: e5943000 e5943000 e1530006 e1530006 0a05 0a05 e2424008 e2424008 (e5942008) (e5942008) 4---[ end trace c53b9e94a29571d4 ]--- ---[ end trace c53b9e94a29571d4 ]--- Segmentation fault Regards, Nishanth Menon sdp3430.defconfig.diff Description: sdp3430.defconfig.diff
RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Wednesday, March 11, 2009 9:51 AM With the latest linux-omap pm + gitorious bridge changes on SDP3430, enabling BRIDGE_DVFS and SRF seems to cause an issue with clock notifier.. I am not entirely of the cause of the issue(don't have a debugger handy at the moment :( ): The condition is reproducible on exactly the third insmod of the driver as explained below. Looking for any advice to fix this issue :( Does it need DVFS enabled to fail? Is voltage high enough (to current DM)? There were some issues there. Regards, Richard W. A side and possibly related note is the below 0x800 is way too high and will likely result in screen or other fifo related effects. The delay target should be around 5uS (for 26Mhz sysclk) and half of that for 13MHz sysclk. Given a value of 0xC8 with ARM at 125MHz, a vdd2-opp2 - vdd2-opp3 takes 105uS using current code. This it self is too high for some display fifos. 0x800 is out of the park high. End note is needs tuning for DVFS. configure_core_dpll: ldr r4, omap3_cm_clksel1_pll ldr r5, [r4] ldr r6, core_m2_mask_val@ modify m2 for core dpll and r5, r5, r6 orr r5, r5, r3, lsl #0x1B @ r3 contains the M2 val str r5, [r4] mov r5, #0x800 @ wait for the clock to stabilise cmp r3, #2 bne wait_clk_stable bx lr -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap] OMAP1: OMAP_TAG_USB buildfix (OSK)
On Wed, Mar 11, 2009 at 02:20:05AM -0800, David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Build fix: CC arch/arm/mach-omap1/board-osk.o arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init': arch/arm/mach-omap1/board-osk.c:512: error: implicit declaration of function 'omap_usb_init' make[1]: *** [arch/arm/mach-omap1/board-osk.o] Error 1 The error is twofold. First, USB is on the mainboard, not the Mistral card; that's specific to the OSK. Second, header goofage -- hurts all OMAP1 boards. I'm puzzled by the notion tha the OMAP1: get rid of OMAP_TAG_USB patch could have been compile-tested. it actually was for all omap1 defconfigs. Weird that these came only now :-( -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] OMAP: omap_wdt: Remove non-explanatory comments.
The call to clk_disable does need a trivial comment like /* Disable the clock */. Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com --- drivers/watchdog/omap_wdt.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 05dc55a..1364d7e 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -146,9 +146,9 @@ static int omap_wdt_open(struct inode *inode, struct file *file) return -EBUSY; if (wdev-mpu_wdt_ick) - clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock */ + clk_enable(wdev-mpu_wdt_ick); - clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */ + clk_enable(wdev-mpu_wdt_fck); /* initialize prescaler */ while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01) @@ -178,9 +178,9 @@ static int omap_wdt_release(struct inode *inode, struct file *file) omap_wdt_disable(wdev); if (wdev-mpu_wdt_ick) - clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */ + clk_disable(wdev-mpu_wdt_ick); - clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */ + clk_disable(wdev-mpu_wdt_fck); #else printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n); #endif @@ -345,9 +345,9 @@ static int __init omap_wdt_probe(struct platform_device *pdev) /* enable clocks for register access */ if (wdev-mpu_wdt_ick) - clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock */ + clk_enable(wdev-mpu_wdt_ick); - clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */ + clk_enable(wdev-mpu_wdt_fck); omap_wdt_disable(wdev); omap_wdt_adjust_timeout(timer_margin); @@ -370,8 +370,8 @@ static int __init omap_wdt_probe(struct platform_device *pdev) /* disable clocks since we don't need them now */ if (wdev-mpu_wdt_ick) - clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */ - clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */ + clk_disable(wdev-mpu_wdt_ick); + clk_disable(wdev-mpu_wdt_fck); omap_wdt_dev = pdev; -- 1.5.4.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 0/6] OMAP: omap_wdt: clocks and NOWAYOUT fixes.
This patchset reorganizes slightly the code of omap_wdt driver,
introduces proper management of clocks and
CONFIG_WATCHDOG_NOWAYOUT + PM support, which was broken.
Also, inspired by numerous watchdog drivers using this technique,
this patchset makes the NOWAYOUT behavior not to be restricted by kernel
configuration, but to be controlled by a module parameter.
It's not expected to be applied as is, as it's not utilizing the clkdev,
so part of it is obsolete. So I'm posting it because of the other changes
it introduced to be discussed.
Also the first patch in the patch set cannot apply because of the
current driver in linux-omap git tree being broken.
It will apply after applying the inlined patch provided by Felipe Balbi:
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/watchdog/omap_wdt.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 7bcbb7f..0fb9fd7 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -294,7 +294,7 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
goto err_busy;
}
- wdev = kzalloc(sizeof(struct omap_wdt_dev), GFP_KERNEL);
+ wdev = kzalloc(sizeof(*wdev), GFP_KERNEL);
if (!wdev) {
ret = -ENOMEM;
goto err_kzalloc;
@@ -347,8 +347,18 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
goto err_ioremap;
}
+ spin_lock_init(wdt_lock);
platform_set_drvdata(pdev, wdev);
+ /* enable clocks for register access */
+ if (cpu_is_omap16xx())
+ clk_enable(wdev-armwdt_ck);/* Enable the clock */
+
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock
*/
+ clk_enable(wdev-mpu_wdt_fck);/* Enable the functional
clock */
+ }
+
omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
@@ -368,6 +378,15 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
/* autogate OCP interface clock */
__raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
+ /* disable clocks since we don't need them now */
+ if (cpu_is_omap16xx())
+ clk_disable(wdev-armwdt_ck); /* Disable the clock */
+
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */
+ clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */
+ }
+
omap_wdt_dev = pdev;
return 0;
@@ -488,7 +507,6 @@ static struct platform_driver omap_wdt_driver = {
static int __init omap_wdt_init(void)
{
- spin_lock_init(wdt_lock);
return platform_driver_register(omap_wdt_driver);
}
--
And another thing to be noted: Imre Deak proposed to stay with
cpu_is_* macros for a better optimization.
Or to use a (!cpu_class_is_omap1()) instead of
(cpu_is_omap24xx() || cpu_is_omap34xx()).
I think it's the right thing to do, but it's not included in the patchset,
as this patchset is not expected to be applied as is anyway,
but rather to be discussed.
--
To unsubscribe from this list: send the line unsubscribe 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 6/6] OMAP: omap_wdt: Changing NOWAYOUT behavior does not require kernel reconfiguration.
By introducing additional module parameter we make the
CONFIG_WATCHDOG_NOWAYOUT to be a mere default module behavior,
which can be overriden by providing nowayout=[01] parameter at load time.
Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com
---
drivers/watchdog/omap_wdt.c | 48 +++---
1 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 6f6a524..6e9617c 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -53,6 +53,13 @@ static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, initial watchdog timeout (in seconds));
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout,
+ Watchdog cannot be stopped once started (default=
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ));
+
+
static unsigned int wdt_trgr_pattern = 0x1234;
static spinlock_t wdt_lock;
@@ -188,22 +195,20 @@ static int omap_wdt_release(struct inode *inode, struct
file *file)
{
struct omap_wdt_dev *wdev = file-private_data;
- /*
-* Shut off the timer unless NOWAYOUT is defined.
-*/
-#ifndef CONFIG_WATCHDOG_NOWAYOUT
-
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 1);
- omap_wdt_disable(wdev);
- omap_wdt_ick_enable(wdev-mpu_wdt_ick, 0);
+ if (nowayout) {
+ /* Give the user application some time to recover
+ * in case of crash.
+ * */
+ omap_wdt_ping(wdev);
+ printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
+ } else {
+ omap_wdt_disable(wdev);
- clk_disable(wdev-mpu_wdt_fck);
- wdev-omap_wdt_state = ~(1 OMAP_WDT_STATE_ACTIVATED_BIT);
-#else
- /* Give the user application some time to recover in case of crash. */
- omap_wdt_ping(wdev);
- printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
-#endif
+ clk_disable(wdev-mpu_wdt_fck);
+ wdev-omap_wdt_state = ~(1 OMAP_WDT_STATE_ACTIVATED_BIT);
+ }
+ omap_wdt_ick_enable(wdev-mpu_wdt_ick, 0);
wdev-omap_wdt_state = ~(1 OMAP_WDT_STATE_OPENED_BIT);
return 0;
@@ -385,9 +390,10 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
if (ret)
goto err_misc;
- pr_info(OMAP Watchdog Timer Rev 0x%02x: initial timeout %d sec\n,
+ pr_info(OMAP Watchdog Timer Rev 0x%02x: initial
+ timeout %d sec, nowayout is %s\n,
__raw_readl(wdev-base + OMAP_WATCHDOG_REV) 0xFF,
- timer_margin);
+ timer_margin, (nowayout ? on : off));
/* autogate OCP interface clock */
__raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
@@ -467,12 +473,6 @@ static int omap_wdt_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
-/* REVISIT ... not clear this is the best way to handle system suspend; and
- * it's very inappropriate for selective device suspend (e.g. suspending this
- * through sysfs rather than by stopping the watchdog daemon). Also, this
- * may not play well enough with NOWAYOUT...
- */
-
static int omap_wdt_suspend(struct platform_device *pdev, pm_message_t state)
{
struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
@@ -481,6 +481,8 @@ static int omap_wdt_suspend(struct platform_device *pdev,
pm_message_t state)
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 1);
omap_wdt_disable(wdev);
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 0);
+ clk_disable(wdev-mpu_wdt_fck);
+printk (KERN_EMERG omap_wdt: suspend \n);
}
return 0;
@@ -491,10 +493,12 @@ static int omap_wdt_resume(struct platform_device *pdev)
struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
if (wdev-omap_wdt_state (1OMAP_WDT_STATE_ACTIVATED_BIT)) {
+ clk_enable(wdev-mpu_wdt_fck);
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 1);
omap_wdt_enable(wdev);
omap_wdt_ping(wdev);
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 0);
+printk (KERN_EMERG omap_wdt: resume\n);
}
return 0;
--
1.5.4.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 5/6] OMAP: omap_wdt: Correct manage of activation states.
Needed to support CONFIG_WATCHDOG_NOWAYOUT option.
Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com
---
drivers/watchdog/omap_wdt.c | 40 ++--
1 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index d033139..6f6a524 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -56,10 +56,13 @@ MODULE_PARM_DESC(timer_margin, initial watchdog timeout
(in seconds));
static unsigned int wdt_trgr_pattern = 0x1234;
static spinlock_t wdt_lock;
+#define OMAP_WDT_STATE_OPENED_BIT 1
+#define OMAP_WDT_STATE_ACTIVATED_BIT 8
+
struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
- int omap_wdt_users;
+ int omap_wdt_state;
struct clk *mpu_wdt_ick;
struct clk *mpu_wdt_fck;
struct resource *mem;
@@ -152,19 +155,25 @@ static int omap_wdt_open(struct inode *inode, struct file
*file)
struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
void __iomem *base = wdev-base;
- if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
+ if (test_and_set_bit(OMAP_WDT_STATE_OPENED_BIT,
+ (unsigned long *)(wdev-omap_wdt_state)))
return -EBUSY;
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 1);
- clk_enable(wdev-mpu_wdt_fck);
+ if (wdev-omap_wdt_state (1 OMAP_WDT_STATE_ACTIVATED_BIT))
+ omap_wdt_ping(wdev);
+ else {
+ clk_enable(wdev-mpu_wdt_fck);
- /* initialize prescaler */
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
- cpu_relax();
+ /* initialize prescaler */
+ while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
+ cpu_relax();
- __raw_writel((1 5) | (PTV 2), base + OMAP_WATCHDOG_CNTRL);
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
- cpu_relax();
+ __raw_writel((1 5) | (PTV 2), base + OMAP_WATCHDOG_CNTRL);
+ while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
+ cpu_relax();
+ wdev-omap_wdt_state |= (1 OMAP_WDT_STATE_ACTIVATED_BIT);
+ }
file-private_data = (void *) wdev;
@@ -189,10 +198,13 @@ static int omap_wdt_release(struct inode *inode, struct
file *file)
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 0);
clk_disable(wdev-mpu_wdt_fck);
+ wdev-omap_wdt_state = ~(1 OMAP_WDT_STATE_ACTIVATED_BIT);
#else
+ /* Give the user application some time to recover in case of crash. */
+ omap_wdt_ping(wdev);
printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
#endif
- wdev-omap_wdt_users = 0;
+ wdev-omap_wdt_state = ~(1 OMAP_WDT_STATE_OPENED_BIT);
return 0;
}
@@ -307,7 +319,7 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
goto err_kzalloc;
}
- wdev-omap_wdt_users = 0;
+ wdev-omap_wdt_state = 0;
wdev-mem = mem;
if (cpu_is_omap16xx()) {
@@ -417,7 +429,7 @@ static void omap_wdt_shutdown(struct platform_device *pdev)
{
struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
- if (wdev-omap_wdt_users) {
+ if (wdev-omap_wdt_state (1OMAP_WDT_STATE_ACTIVATED_BIT)) {
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 1);
omap_wdt_disable(wdev);
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 0);
@@ -465,7 +477,7 @@ static int omap_wdt_suspend(struct platform_device *pdev,
pm_message_t state)
{
struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
- if (wdev-omap_wdt_users) {
+ if (wdev-omap_wdt_state (1OMAP_WDT_STATE_ACTIVATED_BIT)) {
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 1);
omap_wdt_disable(wdev);
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 0);
@@ -478,7 +490,7 @@ static int omap_wdt_resume(struct platform_device *pdev)
{
struct omap_wdt_dev *wdev = platform_get_drvdata(pdev);
- if (wdev-omap_wdt_users) {
+ if (wdev-omap_wdt_state (1OMAP_WDT_STATE_ACTIVATED_BIT)) {
omap_wdt_ick_enable(wdev-mpu_wdt_ick, 1);
omap_wdt_enable(wdev);
omap_wdt_ping(wdev);
--
1.5.4.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 2/6] OMAP: omap_wdt: Fix interface clock existence check.
When enabling/disabling the iterface clock, the question to be asked is if this clock exists rather than to decide about it's existance by retrieving the chip version. It can be done only once at init time. Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com --- drivers/watchdog/omap_wdt.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 5b72c7c..05dc55a 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -145,7 +145,7 @@ static int omap_wdt_open(struct inode *inode, struct file *file) if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users))) return -EBUSY; - if (cpu_is_omap24xx() || cpu_is_omap34xx()) + if (wdev-mpu_wdt_ick) clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock */ clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */ @@ -177,7 +177,7 @@ static int omap_wdt_release(struct inode *inode, struct file *file) omap_wdt_disable(wdev); - if (cpu_is_omap24xx() || cpu_is_omap34xx()) + if (wdev-mpu_wdt_ick) clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */ clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */ @@ -344,7 +344,7 @@ static int __init omap_wdt_probe(struct platform_device *pdev) platform_set_drvdata(pdev, wdev); /* enable clocks for register access */ - if (cpu_is_omap24xx() || cpu_is_omap34xx()) + if (wdev-mpu_wdt_ick) clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock */ clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */ @@ -369,7 +369,7 @@ static int __init omap_wdt_probe(struct platform_device *pdev) __raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG); /* disable clocks since we don't need them now */ - if (cpu_is_omap24xx() || cpu_is_omap34xx()) + if (wdev-mpu_wdt_ick) clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */ clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */ -- 1.5.4.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 1/6] OMAP: omap_wdt: Remove armwdt_ck field from omap_wdt_dev structure.
No need to hold three clocks, when for each paricular platform only
two are used - finctional and interface.
Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com
---
drivers/watchdog/omap_wdt.c | 51 --
1 files changed, 15 insertions(+), 36 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index b04f650..5b72c7c 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -60,7 +60,6 @@ struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
int omap_wdt_users;
- struct clk *armwdt_ck;
struct clk *mpu_wdt_ick;
struct clk *mpu_wdt_fck;
struct resource *mem;
@@ -146,13 +145,10 @@ static int omap_wdt_open(struct inode *inode, struct file
*file)
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;
- if (cpu_is_omap16xx())
- clk_enable(wdev-armwdt_ck);/* Enable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock
*/
- clk_enable(wdev-mpu_wdt_fck);/* Enable the functional
clock */
- }
+
+ clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */
/* initialize prescaler */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
@@ -181,13 +177,10 @@ static int omap_wdt_release(struct inode *inode, struct
file *file)
omap_wdt_disable(wdev);
- if (cpu_is_omap16xx())
- clk_disable(wdev-armwdt_ck); /* Disable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */
- clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */
- }
+
+ clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */
#else
printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
#endif
@@ -304,10 +297,10 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
wdev-mem = mem;
if (cpu_is_omap16xx()) {
- wdev-armwdt_ck = clk_get(pdev-dev, armwdt_ck);
- if (IS_ERR(wdev-armwdt_ck)) {
- ret = PTR_ERR(wdev-armwdt_ck);
- wdev-armwdt_ck = NULL;
+ wdev-mpu_wdt_fck = clk_get(pdev-dev, armwdt_ck);
+ if (IS_ERR(wdev-mpu_wdt_fck)) {
+ ret = PTR_ERR(wdev-mpu_wdt_fck);
+ wdev-mpu_wdt_fck = NULL;
goto err_clk;
}
}
@@ -351,13 +344,10 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, wdev);
/* enable clocks for register access */
- if (cpu_is_omap16xx())
- clk_enable(wdev-armwdt_ck);/* Enable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock
*/
- clk_enable(wdev-mpu_wdt_fck);/* Enable the functional
clock */
- }
+
+ clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */
omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
@@ -379,13 +369,9 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
__raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
/* disable clocks since we don't need them now */
- if (cpu_is_omap16xx())
- clk_disable(wdev-armwdt_ck); /* Disable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */
- clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */
- }
+ clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */
omap_wdt_dev = pdev;
@@ -399,8 +385,6 @@ err_ioremap:
wdev-base = NULL;
err_clk:
- if (wdev-armwdt_ck)
- clk_put(wdev-armwdt_ck);
if (wdev-mpu_wdt_ick)
clk_put(wdev-mpu_wdt_ick);
if (wdev-mpu_wdt_fck)
@@ -436,11 +420,6 @@ static int omap_wdt_remove(struct platform_device *pdev)
release_mem_region(res-start, res-end - res-start + 1);
platform_set_drvdata(pdev, NULL);
- if (wdev-armwdt_ck) {
- clk_put(wdev-armwdt_ck);
- wdev-armwdt_ck = NULL;
- }
-
if (wdev-mpu_wdt_ick) {
clk_put(wdev-mpu_wdt_ick);
wdev-mpu_wdt_ick = NULL;
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
Does the bridge driver call a clk_notifier_unregister on the exit path? CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442 #1) PC is at clk_notifier_register+0x68/0x108 LR is at kmem_cache_alloc+0x7c/0x84 Taking an objdump of clock.o shows me it probably is crashing some place while trying to traverse through the existing list of registered notifiers. It could very well be that one of these is an old function pointer registered by the previous insmod of the bridge driver. -Original Message- From: Menon, Nishanth Sent: Wednesday, March 11, 2009 8:21 PM To: linux-omap@vger.kernel.org Cc: ext Paul Walmsley; Nayak, Rajendra; Gupta, Ramesh Subject: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload Hi Folks, With the latest linux-omap pm + gitorious bridge changes on SDP3430, enabling BRIDGE_DVFS and SRF seems to cause an issue with clock notifier.. I am not entirely of the cause of the issue(don't have a debugger handy at the moment :( ): The condition is reproducible on exactly the third insmod of the driver as explained below. Looking for any advice to fix this issue :( Codebase: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-oma p-2.6.git git checkout -b pm --track origin/pm git fetch git://gitorious.org/lk/mainline.git tidspbridge-pm:tidspbridge-pm git checkout tidspbridge-pm git merge pm defconfig: essentially omap_3430sdp_defconfig, enable SRF and bridge+bridge_dvfs. (diff b/w defconfig and .config attached). Bootargs: console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs rw nfsroot=myIP:myFS,nolock,wsize=1024,rsize=1024 mem=64M The error: insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 Unable to handle kernel paging request at virtual address 756e696c pgd = c3e0c000 *pgd=[756e696c] Internal error: Oops: 5 [#1] Modules linked in:Modules linked in: bridgedriver(+) bridgedriver(+) [last unloaded: bridgedriver] [last unloaded: bridgedriver] CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442 #1) PC is at clk_notifier_register+0x68/0x108 LR is at kmem_cache_alloc+0x7c/0x84 pc : [c003f684]lr : [c009f574]psr: 0093 sp : c3e05da0 ip : c3e0b3e0 fp : c3e05dbc snip Backtrace: Backtrace: [c003f61c] [c003f61c] (clk_notifier_register+0x0/0x108) (clk_notifier_register+0x0/0x108) from [bf08d394] from [bf08d394] (bridge_init+0x394/0x3ec [bridgedriver]) (bridge_init+0x394/0x3ec [bridgedriver]) r7: r7: r6:bf08ab88 r6:bf08ab88 r5:1dcd6500 r5:1dcd6500 r4:0ee6b280 r4:0ee6b280 [bf08d000] [bf08d000] (bridge_init+0x0/0x3ec [bridgedriver]) (bridge_init+0x0/0x3ec [bridgedriver]) from [c002d2d4] from [c002d2d4] (do_one_initcall+0x64/0x198) (do_one_initcall+0x64/0x198) r8:c002df28 r8:c002df28 r7: r7: r6:4023a000 r6:4023a000 r5:bf08a520 r5:bf08a520 r4:c03aa340 r4:c03aa340 [c002d270] [c002d270] (do_one_initcall+0x0/0x198) (do_one_initcall+0x0/0x198) from [c0078cac] from [c0078cac] (sys_init_module+0x98/0x188) (sys_init_module+0x98/0x188) [c0078c14] [c0078c14] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [c002dd80] from [c002dd80] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: Code: Code: e5943000 e5943000 e1530006 e1530006 0a05 0a05 e2424008 e2424008 (e5942008) (e5942008) 4---[ end trace c53b9e94a29571d4 ]--- ---[ end trace c53b9e94a29571d4 ]--- Segmentation fault 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: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
Rajendra, -Original Message- From: Nayak, Rajendra Sent: Wednesday, March 11, 2009 9:25 PM To: Menon, Nishanth; linux-omap@vger.kernel.org Cc: ext Paul Walmsley; Gupta, Ramesh Subject: RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload Does the bridge driver call a clk_notifier_unregister on the exit path? Yes, it is called. CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442 #1) PC is at clk_notifier_register+0x68/0x108 LR is at kmem_cache_alloc+0x7c/0x84 Taking an objdump of clock.o shows me it probably is crashing some place while trying to traverse through the existing list of registered notifiers. It could very well be that one of these is an old function pointer registered by the previous insmod of the bridge driver. -Original Message- From: Menon, Nishanth Sent: Wednesday, March 11, 2009 8:21 PM To: linux-omap@vger.kernel.org Cc: ext Paul Walmsley; Nayak, Rajendra; Gupta, Ramesh Subject: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload Hi Folks, With the latest linux-omap pm + gitorious bridge changes on SDP3430, enabling BRIDGE_DVFS and SRF seems to cause an issue with clock notifier.. I am not entirely of the cause of the issue(don't have a debugger handy at the moment :( ): The condition is reproducible on exactly the third insmod of the driver as explained below. Looking for any advice to fix this issue :( Codebase: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-oma p-2.6.git git checkout -b pm --track origin/pm git fetch git://gitorious.org/lk/mainline.git tidspbridge-pm:tidspbridge-pm git checkout tidspbridge-pm git merge pm defconfig: essentially omap_3430sdp_defconfig, enable SRF and bridge+bridge_dvfs. (diff b/w defconfig and .config attached). Bootargs: console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs rw nfsroot=myIP:myFS,nolock,wsize=1024,rsize=1024 mem=64M The error: insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 rmmod bridgedriver insmod ./bridgedriver.ko phys_mempool_base=0x8700 phys_mempool_size=0x60 Unable to handle kernel paging request at virtual address 756e696c pgd = c3e0c000 *pgd=[756e696c] Internal error: Oops: 5 [#1] Modules linked in:Modules linked in: bridgedriver(+) bridgedriver(+) [last unloaded: bridgedriver] [last unloaded: bridgedriver] CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442 #1) PC is at clk_notifier_register+0x68/0x108 LR is at kmem_cache_alloc+0x7c/0x84 pc : [c003f684]lr : [c009f574]psr: 0093 sp : c3e05da0 ip : c3e0b3e0 fp : c3e05dbc snip Backtrace: Backtrace: [c003f61c] [c003f61c] (clk_notifier_register+0x0/0x108) (clk_notifier_register+0x0/0x108) from [bf08d394] from [bf08d394] (bridge_init+0x394/0x3ec [bridgedriver]) (bridge_init+0x394/0x3ec [bridgedriver]) r7: r7: r6:bf08ab88 r6:bf08ab88 r5:1dcd6500 r5:1dcd6500 r4:0ee6b280 r4:0ee6b280 [bf08d000] [bf08d000] (bridge_init+0x0/0x3ec [bridgedriver]) (bridge_init+0x0/0x3ec [bridgedriver]) from [c002d2d4] from [c002d2d4] (do_one_initcall+0x64/0x198) (do_one_initcall+0x64/0x198) r8:c002df28 r8:c002df28 r7: r7: r6:4023a000 r6:4023a000 r5:bf08a520 r5:bf08a520 r4:c03aa340 r4:c03aa340 [c002d270] [c002d270] (do_one_initcall+0x0/0x198) (do_one_initcall+0x0/0x198) from [c0078cac] from [c0078cac] (sys_init_module+0x98/0x188) (sys_init_module+0x98/0x188) [c0078c14] [c0078c14] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [c002dd80] from [c002dd80] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: Code: Code: e5943000 e5943000 e1530006 e1530006 0a05 0a05 e2424008 e2424008 (e5942008) (e5942008) 4---[ end trace c53b9e94a29571d4 ]--- ---[ end trace c53b9e94a29571d4 ]--- Segmentation fault Regards, Nishanth Menon Regards Ramesh Gupta G-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAP: omap_wdt: Remove armwdt_ck field from omap_wdt_dev structure.
Hi,
* Atal Shargorodsky ext-atal.shargorod...@nokia.com [090311 08:31]:
No need to hold three clocks, when for each paricular platform only
two are used - finctional and interface.
Signed-off-by: Atal Shargorodsky ext-atal.shargorod...@nokia.com
---
drivers/watchdog/omap_wdt.c | 51 --
1 files changed, 15 insertions(+), 36 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index b04f650..5b72c7c 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -60,7 +60,6 @@ struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
int omap_wdt_users;
- struct clk *armwdt_ck;
struct clk *mpu_wdt_ick;
struct clk *mpu_wdt_fck;
struct resource *mem;
@@ -146,13 +145,10 @@ static int omap_wdt_open(struct inode *inode, struct
file *file)
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;
- if (cpu_is_omap16xx())
- clk_enable(wdev-armwdt_ck);/* Enable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock
*/
- clk_enable(wdev-mpu_wdt_fck);/* Enable the functional
clock */
- }
+
+ clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */
/* initialize prescaler */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
Some extra work required.. You will need to rebase at least this patch as
the big pile of clock changes by Paul and Russell will go in this coming
merge window.
Basically the code above will be cleaner with no need for cpu_is_ stuff:
clk_enable(wdev-ick);/* Enable the interface clock */
clk_enable(wdev-fck);/* Enable the functional clock */
I'm mirroring Russell's omap-clks3 branch in the linux-omap tree as
clks-testing branch, so please take a look at that branch.
Then see the MAINTAINERS file for WATCHDOG DEVICE DRIVERS, so you
can find the address for Wim. Please send the series to Wim with
LKML, LAKML, and linux-omap mailing lists Cc'd. Please also mention
that these patches depend on some pending clock changes.
Or even better, maybe you can leave out the clock part from your patch
so your series applies to both the mainline kernel and clks-testing
branch with some offset warnings ;)
Regards,
Tony
@@ -181,13 +177,10 @@ static int omap_wdt_release(struct inode *inode, struct
file *file)
omap_wdt_disable(wdev);
- if (cpu_is_omap16xx())
- clk_disable(wdev-armwdt_ck); /* Disable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
clk_disable(wdev-mpu_wdt_ick); /* Disable the clock */
- clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */
- }
+
+ clk_disable(wdev-mpu_wdt_fck); /* Disable the clock */
#else
printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
#endif
@@ -304,10 +297,10 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
wdev-mem = mem;
if (cpu_is_omap16xx()) {
- wdev-armwdt_ck = clk_get(pdev-dev, armwdt_ck);
- if (IS_ERR(wdev-armwdt_ck)) {
- ret = PTR_ERR(wdev-armwdt_ck);
- wdev-armwdt_ck = NULL;
+ wdev-mpu_wdt_fck = clk_get(pdev-dev, armwdt_ck);
+ if (IS_ERR(wdev-mpu_wdt_fck)) {
+ ret = PTR_ERR(wdev-mpu_wdt_fck);
+ wdev-mpu_wdt_fck = NULL;
goto err_clk;
}
}
@@ -351,13 +344,10 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, wdev);
/* enable clocks for register access */
- if (cpu_is_omap16xx())
- clk_enable(wdev-armwdt_ck);/* Enable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
clk_enable(wdev-mpu_wdt_ick);/* Enable the interface clock
*/
- clk_enable(wdev-mpu_wdt_fck);/* Enable the functional
clock */
- }
+
+ clk_enable(wdev-mpu_wdt_fck);/* Enable the functional clock */
omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
@@ -379,13 +369,9 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
__raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
/* disable clocks since we don't need them now */
- if (cpu_is_omap16xx())
- clk_disable(wdev-armwdt_ck); /* Disable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
[APPLIED] regulator: enumerate voltages (v2)
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 278a2f75b0809c1242b65af61c9b1823e697a323 PatchWorks http://patchwork.kernel.org/patch/7/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=278a2f75b0809c1242b65af61c9b1823e697a323 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] regulator: twl4030 voltage enumeration (v2)
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 8b0f9499b13e61e3bd730f2f10d2cf20c693e36d PatchWorks http://patchwork.kernel.org/patch/8/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=8b0f9499b13e61e3bd730f2f10d2cf20c693e36d -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] regulator: twl4030 voltage enumeration (v2) cleanups
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: fd08b838200bb77a231468eb2fa1246525354c5c PatchWorks http://patchwork.kernel.org/patch/9/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=fd08b838200bb77a231468eb2fa1246525354c5c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] MMC: regulator utilities
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 4e1f2b829034be5383341dca9fa25062980c3b44 PatchWorks http://patchwork.kernel.org/patch/11120/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=4e1f2b829034be5383341dca9fa25062980c3b44 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] mmc-twl4030 uses regulator framework
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 3fe326511c66ab842ef0a09a1f4c564b1a8beecf PatchWorks http://patchwork.kernel.org/patch/11121/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=3fe326511c66ab842ef0a09a1f4c564b1a8beecf -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap] OMAP1: OMAP_TAG_USB buildfix (OSK)
* David Brownell davi...@pacbell.net [090311 03:44]:
From: David Brownell dbrown...@users.sourceforge.net
Build fix:
CC arch/arm/mach-omap1/board-osk.o
arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
arch/arm/mach-omap1/board-osk.c:512: error: implicit declaration of
function 'omap_usb_init'
make[1]: *** [arch/arm/mach-omap1/board-osk.o] Error 1
The error is twofold. First, USB is on the mainboard, not the Mistral card;
that's specific to the OSK. Second, header goofage -- hurts all OMAP1 boards.
I'm puzzled by the notion tha the OMAP1: get rid of OMAP_TAG_USB patch could
have been compile-tested.
Hmm, I built it on all boards, but maybe that was against the mainline
tree for omap-upstream patches. It's also possible that I hosed the osk
patch while refreshing the original patch.. Oh well, never trust me for
manually merging patches right :)
I'll apply this and update the omap-upstream patch accordingly.
Tony
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap1/board-osk.c |3 ++-
arch/arm/plat-omap/include/mach/usb.h | 10 +-
2 files changed, 7 insertions(+), 6 deletions(-)
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -509,7 +509,6 @@ static void __init osk_mistral_init(void
i2c_register_board_info(1, mistral_i2c_board_info,
ARRAY_SIZE(mistral_i2c_board_info));
- omap_usb_init(osk_usb_config);
platform_add_devices(mistral_devices, ARRAY_SIZE(mistral_devices));
}
#else
@@ -541,6 +540,8 @@ static void __init osk_init(void)
l |= (3 1);
omap_writel(l, USB_TRANSCEIVER_CTRL);
+ omap_usb_init(osk_usb_config);
+
/* irq for tps65010 chip */
/* bootloader effectively does: omap_cfg_reg(U19_1610_MPUIO1); */
if (gpio_request(OMAP_MPUIO(1), tps65010) == 0)
--- a/arch/arm/plat-omap/include/mach/usb.h
+++ b/arch/arm/plat-omap/include/mach/usb.h
@@ -33,9 +33,7 @@ extern void usb_musb_init(void);
static inline void usb_musb_init(void)
{
}
-#endif
-
-void omap_usb_init(struct omap_usb_config *pdata);
+#endif /* !OMAP1 !MUSB */
#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)
extern void usb_ehci_init(void);
@@ -43,9 +41,11 @@ extern void usb_ehci_init(void);
static inline void usb_ehci_init(void)
{
}
-#endif
+#endif /* !OMAP1 !EHCI */
-#endif
+#endif /* !OMAP1 */
+
+void omap_usb_init(struct omap_usb_config *pdata);
/*-*/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: OMAP: get rid of OMAP_TAG_USB, v2
* Tony Lindgren t...@atomide.com [090304 13:56]:
From: Felipe Balbi felipe.ba...@nokia.com
OMAP_TAGS should vanish soon since they're not generic arm tags.
Most of them can be converted to a platform_data or parsed
from a command line like e.g. serial tag.
For OMAP_TAG_USB we just let boards call omap_usb_init()
passing a pointer to omap_usb_config.
Patch updated by Tony for mainline, basically make
n770 and h4 compile.
Here's this one updated with a fix for OSK from Dave.
Tony
From 124fbfcb94e989916c5862c5d9bcbd281c09cdfa Mon Sep 17 00:00:00 2001
From: Felipe Balbi felipe.ba...@nokia.com
Date: Wed, 4 Mar 2009 10:54:44 -0800
Subject: [PATCH] ARM: OMAP: get rid of OMAP_TAG_USB, v2
OMAP_TAGS should vanish soon since they're not generic arm tags.
Most of them can be converted to a platform_data or parsed
from a command line like e.g. serial tag.
For OMAP_TAG_USB we just let boards call omap_usb_init()
passing a pointer to omap_usb_config.
Patch updated by Tony for mainline, basically make
n770 and h4 compile. Also folded in a fix for OSK
by David Brownell dbrown...@users.sourceforge.net.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 2e61839..8b40aac 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -175,7 +175,6 @@ static struct omap_usb_config ams_delta_usb_config __initdata = {
static struct omap_board_config_kernel ams_delta_config[] = {
{ OMAP_TAG_LCD, ams_delta_lcd_config },
{ OMAP_TAG_UART, ams_delta_uart_config },
- { OMAP_TAG_USB, ams_delta_usb_config },
};
static struct resource ams_delta_kp_resources[] = {
@@ -232,6 +231,7 @@ static void __init ams_delta_init(void)
/* Clear latch2 (NAND, LCD, modem enable) */
ams_delta_latch2_write(~0, 0);
+ omap_usb_init(ams_delta_usb_config);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
}
diff --git a/arch/arm/mach-omap1/board-generic.c b/arch/arm/mach-omap1/board-generic.c
index 7d26702..e724940 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -62,7 +62,6 @@ static struct omap_uart_config generic_uart_config __initdata = {
};
static struct omap_board_config_kernel generic_config[] __initdata = {
- { OMAP_TAG_USB, NULL },
{ OMAP_TAG_UART, generic_uart_config },
};
@@ -70,12 +69,12 @@ static void __init omap_generic_init(void)
{
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap15xx()) {
- generic_config[0].data = generic1510_usb_config;
+ omap_usb_init(generic1510_usb_config);
}
#endif
#if defined(CONFIG_ARCH_OMAP16XX)
if (!cpu_is_omap1510()) {
- generic_config[0].data = generic1610_usb_config;
+ omap_usb_init(generic1610_usb_config);
}
#endif
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 0d784a7..9f3b392 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -364,7 +364,6 @@ static struct omap_lcd_config h2_lcd_config __initdata = {
};
static struct omap_board_config_kernel h2_config[] __initdata = {
- { OMAP_TAG_USB, h2_usb_config },
{ OMAP_TAG_UART, h2_uart_config },
{ OMAP_TAG_LCD, h2_lcd_config },
};
@@ -413,6 +412,7 @@ static void __init h2_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, h2_i2c_board_info,
ARRAY_SIZE(h2_i2c_board_info));
+ omap_usb_init(h2_usb_config);
h2_mmc_init();
}
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index bf08b6a..a3c513d 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -418,7 +418,6 @@ static struct omap_lcd_config h3_lcd_config __initdata = {
};
static struct omap_board_config_kernel h3_config[] __initdata = {
- { OMAP_TAG_USB, h3_usb_config },
{ OMAP_TAG_UART, h3_uart_config },
{ OMAP_TAG_LCD, h3_lcd_config },
};
@@ -472,6 +471,7 @@ static void __init h3_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, h3_i2c_board_info,
ARRAY_SIZE(h3_i2c_board_info));
+ omap_usb_init(h3_usb_config);
h3_mmc_init();
}
diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c
index 071cd02..ed7ee07 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -370,7 +370,6 @@ static struct omap_uart_config innovator_uart_config __initdata = {
};
static struct omap_board_config_kernel innovator_config[] = {
- { OMAP_TAG_USB, NULL },
{ OMAP_TAG_LCD, NULL },
{ OMAP_TAG_UART, innovator_uart_config },
};
@@ -392,13 +391,13 @@ static void __init innovator_init(void)
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap1510()) {
- innovator_config[0].data = innovator1510_usb_config;
+ omap_usb_init(innovator1510_usb_config);
innovator_config[1].data = innovator1510_lcd_config;
}
#endif
#ifdef CONFIG_ARCH_OMAP16XX
if
[APPLIED] [patch 2.6.29-rc7-omap] OMAP1: OMAP_TAG_USB buildfix (OSK)
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 3a65a9be0aaeeb5a9d89d6c62657adc38995abc2 PatchWorks http://patchwork.kernel.org/patch/11107/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=3a65a9be0aaeeb5a9d89d6c62657adc38995abc2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [patch 2.6.29-rc7-omap] OMAP1: ASoC buildfix for OSK
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 67a0428c24896738e810fd0736ee78c031a5 PatchWorks http://patchwork.kernel.org/patch/11104/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=67a0428c24896738e810fd0736ee78c031a5 -- To unsubscribe from this list: send the line unsubscribe 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: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
Richard, -Original Message- From: Woodruff, Richard Sent: Wednesday, March 11, 2009 5:28 PM To: Menon, Nishanth; linux-omap@vger.kernel.org Cc: ext Paul Walmsley; Nayak, Rajendra; Gupta, Ramesh Subject: RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload driver as explained below. Looking for any advice to fix this issue :( Does it need DVFS enabled to fail? Is voltage high enough (to current DM)? There were some issues there. Yes, Rajendra's VDD change is merged in [1] pm branch. A side and possibly related note is the below 0x800 is way too high and will likely result in screen or other fifo related effects. The delay target should be around 5uS (for 26Mhz sysclk) and half of that for 13MHz sysclk. Given a value of 0xC8 with ARM at 125MHz, a vdd2-opp2 - vdd2-opp3 takes 105uS using current code. This it self is too high for some display fifos. 0x800 is out of the park high. End note is needs tuning for DVFS. configure_core_dpll: ldr r4, omap3_cm_clksel1_pll ldr r5, [r4] ldr r6, core_m2_mask_val@ modify m2 for core dpll and r5, r5, r6 orr r5, r5, r3, lsl #0x1B @ r3 contains the M2 val str r5, [r4] mov r5, #0x800 @ wait for the clock to stabilise cmp r3, #2 bne wait_clk_stable bx lr It does not make sense for clock notifier_registration to oops out.. it has'nt come out of init even.. This looks like list_del missing in clock_notifier unregistration function :(. I have a patch in place.. sending in a few mins Regards, Nishanth Menon [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=pm -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH v2] ARM: OMAP: Fix GPIO switch initial output state handling
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: cc2b459c066361098704c586f3134c3c3ac13be3 PatchWorks http://patchwork.kernel.org/patch/11128/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=cc2b459c066361098704c586f3134c3c3ac13be3 -- To unsubscribe from this list: send the line unsubscribe 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: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
From: Menon, Nishanth Sent: Wednesday, March 11, 2009 11:33 AM Does it need DVFS enabled to fail? Is voltage high enough (to current DM)? There were some issues there. Yes, Rajendra's VDD change is merged in [1] pm branch. Ok. It does not make sense for clock notifier_registration to oops out.. it has'nt come out of init even.. This looks like list_del missing in clock_notifier unregistration function :(. I have a patch in place.. sending in a few mins Yes. Side issue I pointed out will come up later. If notifier doesn't work there might be a few bugs its useable. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
-Original Message- From: Woodruff, Richard Sent: Wednesday, March 11, 2009 6:40 PM To: Menon, Nishanth; linux-omap@vger.kernel.org Cc: ext Paul Walmsley; Nayak, Rajendra; Gupta, Ramesh Subject: RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload It does not make sense for clock notifier_registration to oops out.. it has'nt come out of init even.. This looks like list_del missing in clock_notifier unregistration function :(. I have a patch in place.. sending in a few mins Yes. Side issue I pointed out will come up later. If notifier doesn't work there might be a few bugs its useable. Would this appear as the following crash (after 14-18 iterations now with my clk_notifer_unregister patch): Unable to handle kernel paging request at virtual address 80200800 pgd = c3eb8000 *pgd=[80200800] Internal error: Oops: 5 [#1] Modules linked in:Modules linked in: [last unloaded: bridgedriver] [last unloaded: bridgedriver] CPU: 0Not tainted (2.6.28-omap1-00211-gcb75442-dirty #6) PC is at vmap_page_range+0xe4/0x1c4 LR is at vmap_page_range+0x160/0x1c4 pc : [c0096fe8]lr : [c0097064]psr: 8013 snip Backtrace: Backtrace: [c0096f04] [c0096f04] (vmap_page_range+0x0/0x1c4) (vmap_page_range+0x0/0x1c4) from [c00970f0] from [c00970f0] (map_vm_area+0x28/0x40) (map_vm_area+0x28/0x40) [c00970c8] [c00970c8] (map_vm_area+0x0/0x40) (map_vm_area+0x0/0x40) from [c009720c] from [c009720c] (__vmalloc_area_node+0x104/0x130) (__vmalloc_area_node+0x104/0x130) r5:c39e1460 r5:c39e1460 r4:03a8 r4:03a8 [c0097108] [c0097108] (__vmalloc_area_node+0x0/0x130) (__vmalloc_area_node+0x0/0x130) from [c00972c8] from [c00972c8] (__vmalloc_node+0x90/0xa8) (__vmalloc_node+0x90/0xa8) [c0097238] [c0097238] (__vmalloc_node+0x0/0xa8) (__vmalloc_node+0x0/0xa8) from [c009733c] from [c009733c] (vmalloc+0x28/0x34) (vmalloc+0x28/0x34) r7: r7: r6:4023a000 r6:4023a000 r5:003a75f0 r5:003a75f0 r4:4023a000 r4:4023a000 [c0097314] [c0097314] (vmalloc+0x0/0x34) (vmalloc+0x0/0x34) from [c0077808] from [c0077808] (load_module+0x34/0x1468) (load_module+0x34/0x1468) [c00777d4] [c00777d4] (load_module+0x0/0x1468) (load_module+0x0/0x1468) from [c0078c90] from [c0078c90] (sys_init_module+0x54/0x188) (sys_init_module+0x54/0x188) [c0078c3c] [c0078c3c] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [c002dd80] from [c002dd80] (ret_fast_syscall+0x0/0x2c) (ret_fast_syscall+0x0/0x2c) r7:0080 r7:0080 r6: r6: r5:000b r5:000b r4: r4: Code: Code: 0a24 0a24 e51b1030 e51b1030 e51b303c e51b303c e0836101 e0836101 (e5952000) (e5952000) 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: [Linux-fbdev-devel] [PATCH] omapfb: Fix argument of blank operation.
Hi Felipe, On Fri, Dec 5, 2008 at 4:15 AM, Felipe Contreras felipe.contre...@gmail.com wrote: From: Felipe Contreras felipe.contre...@nokia.com The blank operation should receive FB_BLANK_POWERDOWN, not VESA_POWERDOWN. Thanks. Looks good. Signed-off-by: Trilok Soni soni.tri...@gmail.com -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line unsubscribe 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:clock: missing list_del for clk_notifier_unregister
From b30537e692ac7e72858479327935b16813ea3f56 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 11 Mar 2009 11:29:11 -0500
Subject: [PATCH] OMAP:clock: missing list_del for clk_notifier_unregister
Apologies on the spam.. looks like my git-send-email needs a bit more
tweaking :(.. sending from gmail..
clk_notifier_unregister should clean the list before
freeing clock notifier, else clk_notifier_list is
filled with dangling pointers
Issue seen while repetative loading/unloading of bridgedriver
Ref: http://marc.info/?t=12367832632r=1w=2
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/clock.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c8d9e96..523d1b0 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -725,8 +725,11 @@ int clk_notifier_unregister(struct clk *clk, struct
notifier_block *nb)
* XXX ugh, layering violation. there should be some
* support in the notifier code for this.
*/
-if (!cn-notifier_head.head)
+if (!cn-notifier_head.head) {
+/* Free up my clock node too */
+list_del(cn-node);
kfree(cn);
+}
} else {
r = -ENOENT;
--
1.5.4.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: Suspend/Resume support with Omap2fb
Thanks, Vaibhav Hiremath -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, March 11, 2009 6:20 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: RE: Suspend/Resume support with Omap2fb On Wed, 2009-03-11 at 11:47 +0100, ext Hiremath, Vaibhav wrote: How have you tested this? Have you also tested with echo mem /sys/power/state? Are you using Kevin's power management tree? What is default configuration of your kernel during this test? It's been some time since I tested it, but it did work on OMAP3 SDP with the pm-branch. Only changed needed were the get_last_off_on_transaction_id and omapfb - omapdss. I also tested echo mem I'll try to find time to test it again with latest trees. [Hiremath, Vaibhav] That would be great, I am also trying few things here at my end. Hopefully I will get something. Yeah, it works ok for me. I rebased my DSS2 tree to latest l-o, then merged pm-branch, and made the changes mentioned above. I get some warnings from getnstimeofday when resuming the kernel, but they seem to be unrelated to DSS, and the image is fine after resume. I used my dss_omap_3430sdp_defconfig and made the following commands to enable PM: echo 1 /sys/power/clocks_off_while_idle echo 1 /sys/power/enable_off_mode echo 1 /sys/power/voltage_off_while_idle echo 1 /sys/power/sleep_while_idle [Hiremath, Vaibhav] Tomi, I looked into your latest code base, and I can see that you have added suspend and resume functionality and as you mentioned it is working for you. The only difference I could point out here is, I am handling suspend at driver level (fb and v4l2) and you are handling it at DSS2 level. I can give try to your implementation; tomorrow morning after reaching to office first thing I will try this and let you know. Just to share with wider audience, I am seeing some abrupt behavior and I doubt some timing synchronization is causing problem. I could see suspend is working if I comment ovl-enable or if I call echo gfx e:0 /sys/devices/platform/omapfb/overlays. Although I have same implementation in omapfb_suspend and it does disables clock and overlay, system doesn't go to off state. It always gives error for dss_prwm. Tomi, Can you try enabling CONFIG_CPU_IDLE flag and see whether it is going to state5 or not? And I think it won't go due to obvious reasons, framebuffer will hold the clocks. You have to have something in your framebuffer driver to trigger display disable. I have implemented timer here to do that. I will send you the patch once I get rid of this issue. 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: [PATCH 2/2] OMAP: McBSP: Do not enable or disable clocks on failed path
Didn't check any deeply can clk_disable sleep in any case but anyway there is no need to cover it with spinlock so better to not hold the lock while disabling. Jarkko Actually, is there any room for the race? I remember someone saying the clk:s have counters, so: 1. If mcbsp is taken, clks on; - and at the same time, the previous mcbsp has been released, leaving clks off , clk counter decrements, nothing bad happens.. - Eero-- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc7-omap-git] Overo: MMC regulator configuration
From: David Brownell dbrown...@users.sourceforge.net
This patch hooks up the twl4030 MMC1 regulator on Overo,
as well as the MMC1 card detect signal. The WLAN chip
connected to MMC2 on some board versions has a dedicated
regulator.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Patches still needed for LDP/Zoom and Pandora...
arch/arm/mach-omap2/board-overo.c | 55
1 file changed, 37 insertions(+), 18 deletions(-)
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -267,10 +267,45 @@ static struct omap_uart_config overo_uar
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
+static struct twl4030_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {
+ .mmc= 2,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .transceiver= true,
+ .ocr_mask = 0x0010, /* 3.3V */
+ },
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply overo_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static int overo_twl_gpio_setup(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ /* gpio + 0 is mmc0_cd (input/IRQ) */
+ mmc[0].gpio_cd = gpio + 0;
+ twl4030_mmc_init(mmc);
+
+ overo_vmmc1_supply.dev = mmc[0].dev;
+
+ return 0;
+}
+
static struct twl4030_gpio_platform_data overo_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
+ .setup = overo_twl_gpio_setup,
};
static struct twl4030_usb_data overo_usb_data = {
@@ -287,6 +322,8 @@ static struct regulator_init_data overo_
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = overo_vmmc1_supply,
};
/* mmc2 (WLAN) and Bluetooth don't use twl4030 regulators */
@@ -343,23 +380,6 @@ static struct platform_device *overo_dev
overo_lcd_device,
};
-static struct twl4030_hsmmc_info mmc[] __initdata = {
- {
- .mmc= 1,
- .wires = 4,
- .gpio_cd= -EINVAL,
- .gpio_wp= -EINVAL,
- },
- {
- .mmc= 2,
- .wires = 4,
- .gpio_cd= -EINVAL,
- .gpio_wp= -EINVAL,
- .transceiver= true,
- },
- {} /* Terminator */
-};
-
static void __init overo_init(void)
{
overo_i2c_init();
@@ -367,7 +387,6 @@ static void __init overo_init(void)
omap_board_config = overo_config;
omap_board_config_size = ARRAY_SIZE(overo_config);
omap_serial_init();
- twl4030_mmc_init(mmc);
usb_musb_init();
usb_ehci_init();
overo_flash_init();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
On Tue, Mar 10, 2009 at 12:52:22AM +, Ben Dooks wrote: On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote: I have observed some Spurious IRQ's for I2C1 when all kernel hacking options (and thus LOCKDEP) are disabled. Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help but IRQF_DISABLED is needed for proper behaviour. Signed-off-by: Ari Kauppi ext-ari.kau...@nokia.com Acked-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/i2c/busses/i2c-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0c3ed41..18af43f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -847,7 +847,7 @@ omap_i2c_probe(struct platform_device *pdev) omap_i2c_init(dev); isr = (dev-rev OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr; - r = request_irq(dev-irq, isr, 0, pdev-name, dev); + r = request_irq(dev-irq, isr, IRQF_DISABLED, pdev-name, dev); Is disabling all IRQs on the system the right thing to do? if not we could fall into stack overflow, right ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
On Wed, Mar 11, 2009 at 10:58:29AM -0800, David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net This patch hooks up the twl4030 MMC1 regulator on Overo, as well as the MMC1 card detect signal. The WLAN chip connected to MMC2 on some board versions has a dedicated regulator. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- Patches still needed for LDP/Zoom and Pandora... with this patch I get: regulator: Unable to get requested regulator: vmmc_aux [ cut here ] WARNING: at drivers/regulator/core.c:1216 regulator_disable+0x64/0x90() unbalanced disables for supply mmci-omap-hs.0-vmmc Modules linked in: [c0363198] (dump_stack+0x0/0x14) from [c004f0fc] (warn_slowpath+0x6c/0x88) [c004f090] (warn_slowpath+0x0/0x88) from [c01b2694] (regulator_disable+0x64/0x90) r3:cf9deae0 r2:c0425c79 r7:cfa16e00 r6:cfa06c38 r5:cfa16e00 r4:fffb [c01b2630] (regulator_disable+0x0/0x90) from [c025ed6c] (mmc_regulator_set_ocr+0xb0/0xcc) r7:cfa16e00 r6:0001 r5: r4: [c025ecbc] (mmc_regulator_set_ocr+0x0/0xcc) from [c003af08] (twl_mmc1_set_power+0xc0/0xec) r7:cfa93538 r6: r5: r4:c04a5b58 [c003ae48] (twl_mmc1_set_power+0x0/0xec) from [c0267b34] (omap_mmc_set_ios+0x54/0x314) r7:cfa93538 r6:cfa935c0 r5:cfa93400 r4:cf9a93c0 [c0267ae0] (omap_mmc_set_ios+0x0/0x314) from [c025e54c] (mmc_power_off+0x90/0x9c) r7: r6: r5:cfa93400 r4: [c025e4bc] (mmc_power_off+0x0/0x9c) from [c025ea98] (mmc_start_host+0x14/0x24) r5: r4:cfa93400 [c025ea84] (mmc_start_host+0x0/0x24) from [c025fcbc] (mmc_add_host+0x64/0x70) r5: r4:cfa93400 [c025fc58] (mmc_add_host+0x0/0x70) from [c0021cac] (omap_mmc_probe+0x464/0x614) r5:cfa935c0 r4:cfa93470 [c0021848] (omap_mmc_probe+0x0/0x614) from [c01d7b60] (platform_drv_probe+0x20/0x24) [c01d7b40] (platform_drv_probe+0x0/0x24) from [c01d6d54] (driver_probe_device+0xd4/0x180) [c01d6c80] (driver_probe_device+0x0/0x180) from [c01d6e68] (__driver_attach+0x68/0x8c) r7:cfa15120 r6:c0499e34 r5:cfa06290 r4:cfa06208 [c01d6e00] (__driver_attach+0x0/0x8c) from [c01d65f8] (bus_for_each_dev+0x4c/0x80) r7:cfa15120 r6:c0499e34 r5:c01d6e00 r4: [c01d65ac] (bus_for_each_dev+0x0/0x80) from [c01d6b98] (driver_attach+0x20/0x28) r6:c0499e34 r5: r4: [c01d6b78] (driver_attach+0x0/0x28) from [c01d5ed4] (bus_add_driver+0xa4/0x20c) [c01d5e30] (bus_add_driver+0x0/0x20c) from [c01d708c] (driver_register+0x98/0x120) r8: r7:c002182c r6:c0499e34 r5: r4:c0028a58 [c01d6ff4] (driver_register+0x0/0x120) from [c01d8008] (platform_driver_register+0x6c/0x88) r9: r8: r7:c002182c r6: r5: r4:c0028a58 [c01d7f9c] (platform_driver_register+0x0/0x88) from [c0021840] (omap_mmc_init+0x14/0x1c) [c002182c] (omap_mmc_init+0x0/0x1c) from [c002d2bc] (__exception_text_end+0x5c/0x19c) [c002d260] (__exception_text_end+0x0/0x19c) from [c0008400] (kernel_init+0x80/0xf4) r8: r7: r6: r5: r4:c0028a58 [c0008380] (kernel_init+0x0/0xf4) from [c0051f50] (do_exit+0x0/0x6a4) r4: ---[ end trace e00c52255ce89b8f ]--- mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock regulator: Unable to get requested regulator: vmmc does this depend on any patch dave ? Using current omap HEAD. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
On Wednesday 11 March 2009, Felipe Balbi wrote: with this patch I get: regulator: Unable to get requested regulator: vmmc_aux That's completely safe; annoying and useless noise from the regulator core, that's all. [ cut here ] WARNING: at drivers/regulator/core.c:1216 regulator_disable+0x64/0x90() unbalanced disables for supply mmci-omap-hs.0-vmmc This is that bug in the regulator framework which Mark is so reluctant to fix ... the one whereby regulators aren't initialized into a known state. In this case, the Overo probably booted from MMC, and U-Boot left the MMC1 regulator on. The first thing the MMC stack does is force the regulator off, so Linux can properly enumerate the device. (Of course, some boards will boot from flash and not turn the regulator on...) I posted a patch to address that regulator framework bug earlier: http://marc.info/?l=linux-omapm=123654568330807w=2 I've appended a slightly simplified version of that patch below. Modules linked in: [c0363198] (dump_stack+0x0/0x14) from [c004f0fc] (warn_slowpath+0x6c/0x88) [c004f090] (warn_slowpath+0x0/0x88) from [c01b2694] (regulator_disable+0x64/0x90) r3:cf9deae0 r2:c0425c79 r7:cfa16e00 r6:cfa06c38 r5:cfa16e00 r4:fffb [c01b2630] (regulator_disable+0x0/0x90) from [c025ed6c] (mmc_regulator_set_ocr+0xb0/0xcc) r7:cfa16e00 r6:0001 r5: r4: [c025ecbc] (mmc_regulator_set_ocr+0x0/0xcc) from [c003af08] (twl_mmc1_set_power+0xc0/0xec) r7:cfa93538 r6: r5: r4:c04a5b58 [c003ae48] (twl_mmc1_set_power+0x0/0xec) from [c0267b34] (omap_mmc_set_ios+0x54/0x314) r7:cfa93538 r6:cfa935c0 r5:cfa93400 r4:cf9a93c0 [c0267ae0] (omap_mmc_set_ios+0x0/0x314) from [c025e54c] (mmc_power_off+0x90/0x9c) r7: r6: r5:cfa93400 r4: [c025e4bc] (mmc_power_off+0x0/0x9c) from [c025ea98] (mmc_start_host+0x14/0x24) r5: r4:cfa93400 [c025ea84] (mmc_start_host+0x0/0x24) from [c025fcbc] (mmc_add_host+0x64/0x70) r5: r4:cfa93400 [c025fc58] (mmc_add_host+0x0/0x70) from [c0021cac] (omap_mmc_probe+0x464/0x614) r5:cfa935c0 r4:cfa93470 [c0021848] (omap_mmc_probe+0x0/0x614) from [c01d7b60] (platform_drv_probe+0x20/0x24) [c01d7b40] (platform_drv_probe+0x0/0x24) from [c01d6d54] (driver_probe_device+0xd4/0x180) [c01d6c80] (driver_probe_device+0x0/0x180) from [c01d6e68] (__driver_attach+0x68/0x8c) r7:cfa15120 r6:c0499e34 r5:cfa06290 r4:cfa06208 [c01d6e00] (__driver_attach+0x0/0x8c) from [c01d65f8] (bus_for_each_dev+0x4c/0x80) r7:cfa15120 r6:c0499e34 r5:c01d6e00 r4: [c01d65ac] (bus_for_each_dev+0x0/0x80) from [c01d6b98] (driver_attach+0x20/0x28) r6:c0499e34 r5: r4: [c01d6b78] (driver_attach+0x0/0x28) from [c01d5ed4] (bus_add_driver+0xa4/0x20c) [c01d5e30] (bus_add_driver+0x0/0x20c) from [c01d708c] (driver_register+0x98/0x120) r8: r7:c002182c r6:c0499e34 r5: r4:c0028a58 [c01d6ff4] (driver_register+0x0/0x120) from [c01d8008] (platform_driver_register+0x6c/0x88) r9: r8: r7:c002182c r6: r5: r4:c0028a58 [c01d7f9c] (platform_driver_register+0x0/0x88) from [c0021840] (omap_mmc_init+0x14/0x1c) [c002182c] (omap_mmc_init+0x0/0x1c) from [c002d2bc] (__exception_text_end+0x5c/0x19c) [c002d260] (__exception_text_end+0x0/0x19c) from [c0008400] (kernel_init+0x80/0xf4) r8: r7: r6: r5: r4:c0028a58 [c0008380] (kernel_init+0x0/0xf4) from [c0051f50] (do_exit+0x0/0x6a4) r4: ---[ end trace e00c52255ce89b8f ]--- mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock regulator: Unable to get requested regulator: vmmc does this depend on any patch dave ? Using current omap HEAD. I was probably running with the patch appended below. - Dave == CUT HERE From: David Brownell dbrown...@users.sourceforge.net Make the regulator setup code simpler and more consistent: - The only difference between boot_on and always_on is that an always_on regulator won't be disabled. Both will be active (and usecount will be 1) on return from setup. - Regulators not marked as boot_on or always_on won't be active (and usecount will be 0) on return from setup. The exception to that simple policy is when there's a non-Linux interface to the regulator ... e.g. if either a DSP or the CPU running Linux can enable the regulator, and the DSP needs it to be on, then it will be on. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- drivers/regulator/core.c | 47 + 1 file changed, 31 insertions(+), 16 deletions(-) --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -711,6 +711,7 @@ static int set_machine_constraints(struc int ret = 0; const char *name; struct regulator_ops *ops = rdev-desc-ops; + int enable = 0; if (constraints-name) name = constraints-name; @@ -799,10 +800,6
Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
On Wed, Mar 11, 2009 at 12:34:59PM -0800, David Brownell wrote: On Wednesday 11 March 2009, Felipe Balbi wrote: with this patch I get: regulator: Unable to get requested regulator: vmmc_aux That's completely safe; annoying and useless noise from the regulator core, that's all. You're right. And the appended patch should probably get merged via Mark as it really makes sense when bootloader keeps the regulator on. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
On Wed, Mar 11, 2009 at 10:58:29AM -0800, David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
This patch hooks up the twl4030 MMC1 regulator on Overo,
as well as the MMC1 card detect signal. The WLAN chip
connected to MMC2 on some board versions has a dedicated
regulator.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Acked-by: Felipe Balbi felipe.ba...@nokia.com
---
Patches still needed for LDP/Zoom and Pandora...
arch/arm/mach-omap2/board-overo.c | 55
1 file changed, 37 insertions(+), 18 deletions(-)
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -267,10 +267,45 @@ static struct omap_uart_config overo_uar
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
+static struct twl4030_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {
+ .mmc= 2,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .transceiver= true,
+ .ocr_mask = 0x0010, /* 3.3V */
+ },
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply overo_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static int overo_twl_gpio_setup(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ /* gpio + 0 is mmc0_cd (input/IRQ) */
+ mmc[0].gpio_cd = gpio + 0;
+ twl4030_mmc_init(mmc);
+
+ overo_vmmc1_supply.dev = mmc[0].dev;
+
+ return 0;
+}
+
static struct twl4030_gpio_platform_data overo_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
+ .setup = overo_twl_gpio_setup,
};
static struct twl4030_usb_data overo_usb_data = {
@@ -287,6 +322,8 @@ static struct regulator_init_data overo_
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = overo_vmmc1_supply,
};
/* mmc2 (WLAN) and Bluetooth don't use twl4030 regulators */
@@ -343,23 +380,6 @@ static struct platform_device *overo_dev
overo_lcd_device,
};
-static struct twl4030_hsmmc_info mmc[] __initdata = {
- {
- .mmc= 1,
- .wires = 4,
- .gpio_cd= -EINVAL,
- .gpio_wp= -EINVAL,
- },
- {
- .mmc= 2,
- .wires = 4,
- .gpio_cd= -EINVAL,
- .gpio_wp= -EINVAL,
- .transceiver= true,
- },
- {} /* Terminator */
-};
-
static void __init overo_init(void)
{
overo_i2c_init();
@@ -367,7 +387,6 @@ static void __init overo_init(void)
omap_board_config = overo_config;
omap_board_config_size = ARRAY_SIZE(overo_config);
omap_serial_init();
- twl4030_mmc_init(mmc);
usb_musb_init();
usb_ehci_init();
overo_flash_init();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3: GPIO off-mode fixes
tero.kri...@nokia.com writes: The first patch in this set contains a small bug, missing kfree() for one of the dynamically reserved arrays during init in error path. Sending a fixed patch now. Thanks Tero. I will undo the first version and re-push with this version. Kevin -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 09 March, 2009 20:48 To: Kristo Tero (Nokia-D/Tampere) Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] OMAP3: GPIO off-mode fixes Tero Kristo tero.kri...@nokia.com writes: These two patches add fixes to GPIO off-mode handling. First patch is more important as it fixes a HW bug, second one just optimizes off-mode code a bit by removing a couple of unnecessary registers from the context save. Thanks, pushing both patches to PM branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux-fbdev-devel] [PATCH] omapfb: Fix argument of blank operation.
On Wed, 11 Mar 2009 22:47:41 +0530 Trilok Soni soni.tri...@gmail.com wrote: Hi Felipe, On Fri, Dec 5, 2008 at 4:15 AM, Felipe Contreras I bet he thought we'd forgotten. felipe.contre...@gmail.com wrote: From: Felipe Contreras felipe.contre...@nokia.com The blank operation should receive FB_BLANK_POWERDOWN, not VESA_POWERDOWN. Thanks. Looks good. Signed-off-by: Trilok Soni soni.tri...@gmail.com Unfortunately the changelog didn't give me any hint as to the seriousness of the problem which was fixed. So I queued it for 2.6.30, perhaps inappropriately. -- To unsubscribe from this list: send the line unsubscribe 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-fbdev-devel] [PATCH] omapfb: Fix argument of blank operation.
On Thu, Mar 12, 2009 at 12:20 AM, Andrew Morton a...@linux-foundation.org wrote: On Wed, 11 Mar 2009 22:47:41 +0530 Trilok Soni soni.tri...@gmail.com wrote: Hi Felipe, On Fri, Dec 5, 2008 at 4:15 AM, Felipe Contreras I bet he thought we'd forgotten. You bet correctly :) felipe.contre...@gmail.com wrote: From: Felipe Contreras felipe.contre...@nokia.com The blank operation should receive FB_BLANK_POWERDOWN, not VESA_POWERDOWN. Thanks. Looks good. Signed-off-by: Trilok Soni soni.tri...@gmail.com Unfortunately the changelog didn't give me any hint as to the seriousness of the problem which was fixed. So I queued it for 2.6.30, perhaps inappropriately. I noticed because of another bug in omapfb which required blanking in order to actually see something (PM stuff?). If user-space tries to blank the usual way, it wouldn't work. My guess is that it's not a big issue, in part because nobody has noticed, but perhaps I'm wrong. I was hoping the fbdev guys would know better. -- 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/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
Hello Ari et al., On Tue, 10 Mar 2009, Ben Dooks wrote: On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote: I have observed some Spurious IRQ's for I2C1 when all kernel hacking options (and thus LOCKDEP) are disabled. Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help but IRQF_DISABLED is needed for proper behaviour. Signed-off-by: Ari Kauppi ext-ari.kau...@nokia.com Acked-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/i2c/busses/i2c-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0c3ed41..18af43f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -847,7 +847,7 @@ omap_i2c_probe(struct platform_device *pdev) omap_i2c_init(dev); isr = (dev-rev OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr; - r = request_irq(dev-irq, isr, 0, pdev-name, dev); + r = request_irq(dev-irq, isr, IRQF_DISABLED, pdev-name, dev); Is disabling all IRQs on the system the right thing to do? Ben's right, there shouldn't be any need for this. This patch could cause some unnecessary interrupt service latency. Ari, are you seeing Spurious irq XX: , please flush posted write for irq messages? If so, the correct fix for this is to read from the device interrupt status register immediately after writing to it. This forces the ARM to wait until the write to the device is complete. Ari, could you make this change to i2c-omap.c:omap_i2c_isr() instead, and test whether this fixes the problem? + u32 tmp; ... omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat); + tmp = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); /* OCP barrier */ - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote: Ben's right, there shouldn't be any need for this. This patch could cause some unnecessary interrupt service latency. That's not what Thomas Gleixner thinks. How about the possibility of stack overflow ? According to Thomas (and Ingo, I'd say) all drivers should call request_irq() with IRQF_DISABLED and that's gonna be true as soon as the threaded irq handler support gets merged, if I'm not wrong. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] PM : cpuidle - Update statistics for correct state
Premi, Sanjeev pr...@ti.com writes:
I would gladly take a patch which uses the 'valid' field for
this and then the enter hook whould drop to the next lower
valid state if the state requested is not valid.
Kevin
[sp] I have not yet tested it (working offline for sometime).
But, wanted to share the changes for an early review.
Thanks, some comments below.
Initially, I was trying see if the CPUIDLE framework could
use .valid as an additional argument in cpuidle_state.
But, may be that's for later...
Yeah, I looked at that too, but it currently doesn't have a concept
of valid states, so for now I recommend we implement that in the
OMAP-specific code as you have done.
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx
index c25158c..9493553 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -88,16 +88,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
goto return_sleep_time;
/*
+* Check if the chosen idle state is valid.
+* If no, drop down to a lower valid state. Expects the lowest
+* state will always be active.
*/
+ if (!cx-valid) {
+ for (idx = (cx-type - 1); idx == 1; idx--) {
I think you mean idx = 1 here.
Also, while you're working on this, could you fix this up so the
omap3_power_states[] array is zero based insted of 1-based, it would
make this code and the other code walking this array easier to follow.
That means defining OMAP_STATE_C1 = 0 and so on.
+ if (omap3_power_states[idx].valid)
+ break;
}
+ state = (dev-states[idx]);
+ dev-last_state = state ;
+
+ cx = cpuidle_get_statedata(state);
}
current_cx_state = *cx;
@@ -150,6 +153,26 @@ static int omap3_enter_idle_bm(struct cpuidle_device
*dev,
return omap3_enter_idle(dev, new_state);
}
+/**
+ * omap3_toggle_off_states - Enable / Disable validity of idle states
+ * @flag: Enable/ Disable support for OFF mode
+ *
+ * Called as result of change to enable_off_mode.
+ */
+void omap3_toggle_off_states(unsigned short flag)
+{
How about calling this omap3_cpuidle_update_states() and taking
no arguments. Rather than the 'flag' argument, internally it
just checks the global 'enable_off_mode.'
This allows for potential further expansion down the road of other
reasons to update CPUidle valid states. For example, we've talked
about updating the CPUidle state latencies on the fly depending on
various other chip settings.
+ if (flag) {
+ omap3_power_states[OMAP3_STATE_C3].valid = 1;
+ omap3_power_states[OMAP3_STATE_C5].valid = 1;
+ omap3_power_states[OMAP3_STATE_C6].valid = 1;
+ }
+ else {
+ omap3_power_states[OMAP3_STATE_C3].valid = 0;
+ omap3_power_states[OMAP3_STATE_C5].valid = 0;
+ omap3_power_states[OMAP3_STATE_C6].valid = 0;
+ }
+}
+
Rather than set set specific OMAP3_STATE_Cx values, it would be better
to just walk the array, and check for [mpu|core]_state = PWRDM_POWER_OFF.
If the state has either set, then update the valid flag.
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
/* omap3_init_power_states - Initialises the OMAP3 specific C states.
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 61c6dfb..6785850 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -47,6 +47,8 @@ atomic_t sleep_block = ATOMIC_INIT(0);
static int vdd1_locked;
static int vdd2_locked;
+extern void omap3_toggle_off_states(unsigned short);
+
Move the definition into pm.h as omap3_cpuidle_update_states(void) as
described above.
static ssize_t idle_show(struct kobject *, struct kobj_attribute *, char *);
static ssize_t idle_store(struct kobject *k, struct kobj_attribute *,
const char *buf, size_t n);
@@ -112,6 +114,8 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_
} else if (attr == enable_off_mode_attr) {
enable_off_mode = value;
omap3_pm_off_mode_enable(enable_off_mode);
+ if (cpu_is_omap34xx())
+ omap3_toggle_off_states(value);
Then, don't modify pm.c, rather just call omap3_cpuidle_update_states() from
omap3_pm_off_mode_enable().
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.
Hi All,
Reloading the dspbridge several times I am getting a Segmentation
fault. Seeing the log it seems that the memory was exhausted
The error happens when ioremap is called
void MEM_ExtPhysPoolInit(u32 poolPhysBase, u32 poolSize)
{
u32 poolVirtBase;
/* get the virtual address for the physical memory pool passed */
poolVirtBase = (u32)ioremap(poolPhysBase, poolSize);
.
Putting some printk's and printing the address returned by ioremap, I realized
that address returned by ioremap each time I reload the dspbridge is different,
in fact the address is increasing. I also put a printk where iounmap is called
to make sure it is called and yes it is actually called. However testing with a
kernel + bridge for linux 23x I always get the same address for pool memory.
Any idea what the problem is? I have included the console output where you can
see the address increasing.
Regards,
Fernando.
The first 15 loads and unloads
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c800
Releasing External memory pool, address = c800
interation 2
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c900
Releasing External memory pool, address = c900
interation 3
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c980
Releasing External memory pool, address = c980
interation 4
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = ca80
Releasing External memory pool, address = ca80
interation 5
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cb00
Releasing External memory pool, address = cb00
interation 6
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cc00
Releasing External memory pool, address = cc00
interation 7
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cc80
Releasing External memory pool, address = cc80
interation 8
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c880
Releasing External memory pool, address = c880
interation 9
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = ca00
Releasing External memory pool, address = ca00
interation 10
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cd00
Releasing External memory pool, address = cd00
interation 11
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cd80
Releasing External memory pool, address = cd80
interation 12
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = ce80
Releasing External memory pool, address = ce80
interation 13
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cf00
Releasing External memory pool, address = cf00
interation 14
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = d000
Releasing External memory pool, address = d000
interation 15
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = d080
Releasing External memory pool, address = d080
...
and It crashes in the 33rd reload.
interation 32
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = d780
Releasing External memory pool, address = d780
interation 33
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
4vmap allocation failed: use vmalloc=size to increase size.
vmap allocation failed: use vmalloc=size to increase size.
[PHYS_POOL]Mapping External, address = 0
4coherent allocation too big
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
Hi Ari, One thing that I missed - On Wed, 11 Mar 2009, Paul Walmsley wrote: On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote: I have observed some Spurious IRQ's for I2C1 when all kernel hacking options (and thus LOCKDEP) are disabled. Ari, are you seeing Spurious irq XX: , please flush posted write for irq messages? If so, the correct fix for this is to read from the device interrupt status register immediately after writing to it. This forces the ARM to wait until the write to the device is complete. Ari, could you make this change to i2c-omap.c:omap_i2c_isr() instead, and test whether this fixes the problem? + u32 tmp; ... omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat); + tmp = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); /* OCP barrier */ You'll also want to make a similar change in omap_i2c_ack_stat(), to add a read immediately after that write. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
Hi Felipe, On Thu, 12 Mar 2009, Felipe Balbi wrote: On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote: Ben's right, there shouldn't be any need for this. This patch could cause some unnecessary interrupt service latency. That's not what Thomas Gleixner thinks. How about the possibility of stack overflow ? That sounds like a separate issue from the spurious IRQ problem that the patch was intended to fix. I'm not familiar with the discussion on the stack overflow issue. Could you send a link? According to Thomas (and Ingo, I'd say) all drivers should call request_irq() with IRQF_DISABLED and that's gonna be true as soon as the threaded irq handler support gets merged, if I'm not wrong. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
On Thu, Mar 12, 2009 at 1:59 AM, Felipe Balbi m...@felipebalbi.com wrote: On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote: Ben's right, there shouldn't be any need for this. This patch could cause some unnecessary interrupt service latency. That's not what Thomas Gleixner thinks. How about the possibility of stack overflow ? According to Thomas (and Ingo, I'd say) all drivers should call request_irq() with IRQF_DISABLED and that's gonna be true as soon as the threaded irq handler support gets merged, if I'm not wrong. That's my understanding too, but I think it has always been true: http://marc.info/?l=linux-kernelm=123607685804562w=2 -- 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/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
Paul Walmsley p...@pwsan.com writes: Hi Felipe, On Thu, 12 Mar 2009, Felipe Balbi wrote: On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote: Ben's right, there shouldn't be any need for this. This patch could cause some unnecessary interrupt service latency. That's not what Thomas Gleixner thinks. How about the possibility of stack overflow ? That sounds like a separate issue from the spurious IRQ problem that the patch was intended to fix. I agree. The IRQF_DISABLED happens to fix this issue, but it may be masking the real spurious issue as Paul suggested. I'm not familiar with the discussion on the stack overflow issue. Could you send a link? Here's one: http://marc.info/?l=linux-kernelm=123607359500596w=2 Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
On Wed, Mar 11, 2009 at 06:07:00PM -0600, Paul Walmsley wrote: Hi Felipe, On Thu, 12 Mar 2009, Felipe Balbi wrote: On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote: Ben's right, there shouldn't be any need for this. This patch could cause some unnecessary interrupt service latency. That's not what Thomas Gleixner thinks. How about the possibility of stack overflow ? That sounds like a separate issue from the spurious IRQ problem that the patch was intended to fix. I'm not familiar with the discussion on the stack overflow issue. Could you send a link? This is the link where Ingo discusses why !IRQF_DISABLED could cause stack overflow: http://lkml.org/lkml/2009/3/3/71 You probably wanna take a look at the whole thread to figure out the discussion, but basically Ingo and Peter (Zijlstra) believe !IRQF_DISABLED is a bug and drivers needing that probably should be using threaded irqs (which is not yet merged) or the hw is broken, and for those an IRQF_ENABLED flag will be created and a TAINT will also be placed. Once that gets merged, all drivers will be forced (at some point) to IRQF_DISABLED and those which don't want that will be moved gradually to threaded irq. This patch is also interesting: http://lkml.org/lkml/2009/3/2/33 -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
On Thu, Mar 12, 2009 at 02:11:17AM +0200, Felipe Contreras wrote: That's my understanding too, but I think it has always been true: http://marc.info/?l=linux-kernelm=123607685804562w=2 sure, not merged yet though. And still the threaded irq support can't handle twl4030 where the irq demuxing logic has to run in a thread due to the need of communicating via i2c. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.29-rc7 regulator-next] regulator: refcount fixes
From: David Brownell dbrown...@users.sourceforge.net
Fix some refcounting issues in the regulator framework, supporting
regulator_disable() for regulators that were enabled at boot time
via machine constraints:
- Update those regulators' usecounts after enabling, so they
can cleanly be disabled at that level.
- Remove the problematic per-consumer usecount, so there's
only one level of enable/disable.
Buggy consumers could notice different bug symptoms. The main
example would be refcounting bugs; also, any (out-of-tree) users
of the experimental regulator_set_optimum_mode() stuff which
don't call it when they're done using a regulator.
This is a net minor codeshrink.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Against the regulator-next tree; mainline has similar issues.
drivers/regulator/core.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -52,7 +52,6 @@ struct regulator {
int uA_load;
int min_uV;
int max_uV;
- int enabled; /* count of client enables */
char *supply_name;
struct device_attribute dev_attr;
struct regulator_dev *rdev;
@@ -811,6 +810,7 @@ static int set_machine_constraints(struc
rdev-constraints = NULL;
goto out;
}
+ rdev-use_count = 1;
}
print_constraints(rdev);
@@ -1066,10 +1066,6 @@ void regulator_put(struct regulator *reg
mutex_lock(regulator_list_mutex);
rdev = regulator-rdev;
- if (WARN(regulator-enabled, Releasing supply %s while enabled\n,
- regulator-supply_name))
- _regulator_disable(rdev);
-
/* remove any sysfs entries */
if (regulator-dev) {
sysfs_remove_link(rdev-dev.kobj, regulator-supply_name);
@@ -1144,12 +1140,7 @@ int regulator_enable(struct regulator *r
int ret = 0;
mutex_lock(rdev-mutex);
- if (regulator-enabled == 0)
- ret = _regulator_enable(rdev);
- else if (regulator-enabled 0)
- ret = -EIO;
- if (ret == 0)
- regulator-enabled++;
+ ret = _regulator_enable(rdev);
mutex_unlock(rdev-mutex);
return ret;
}
@@ -1160,6 +1151,11 @@ static int _regulator_disable(struct reg
{
int ret = 0;
+ if (WARN(rdev-use_count = 0,
+ unbalanced disables for %s\n,
+ rdev-desc-name))
+ return -EIO;
+
/* are we the last user and permitted to disable ? */
if (rdev-use_count == 1 !rdev-constraints-always_on) {
@@ -1208,16 +1204,7 @@ int regulator_disable(struct regulator *
int ret = 0;
mutex_lock(rdev-mutex);
- if (regulator-enabled == 1) {
- ret = _regulator_disable(rdev);
- if (ret == 0)
- regulator-uA_load = 0;
- } else if (WARN(regulator-enabled = 0,
- unbalanced disables for supply %s\n,
- regulator-supply_name))
- ret = -EIO;
- if (ret == 0)
- regulator-enabled--;
+ ret = _regulator_disable(rdev);
mutex_unlock(rdev-mutex);
return ret;
}
@@ -1264,7 +1251,6 @@ int regulator_force_disable(struct regul
int ret;
mutex_lock(regulator-rdev-mutex);
- regulator-enabled = 0;
regulator-uA_load = 0;
ret = _regulator_force_disable(regulator-rdev);
mutex_unlock(regulator-rdev-mutex);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
On Wednesday 11 March 2009, Felipe Balbi wrote: According to Thomas (and Ingo, I'd say) all drivers should call request_irq() with IRQF_DISABLED and that's gonna be true as soon as the threaded irq handler support gets merged, if I'm not wrong. Well, they're wrong. Folk like Dave Miller, Andrew Morton, Benjamin Herrenschmdit, and Alan Cox have come out on the saner side of 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
[patch 2.6.29-rc7 regulator-next] regulator: init fixes
From: David Brownell dbrown...@users.sourceforge.net
Make the regulator setup code cope more consistently with
regulators undesirably left enabled by the bootloader.
Building on the previous refcount patch:
* Unless the boot_on or always_on machine constraints
were set, disable() the regulator. This gives drivers
a clean start state: enable state matches usecount,
regardless of boot_on/always_on flag state.
* To help make some integration stages easier, add a new
devmode machine constraint where state the bootloader
left isn't touched, but enable state and usecount may
not match. (System boots but some drivers act odd ...
debuggable. System dies part way through booting ...
often painful.)
Consider a bootloader that leaves an MMC/SD regulator active
when it loads Linux from an SD card. It may take some time
before the MMC/SD driver gets loaded, if ever ... to save
power, that (LDO) regulator should be disabled ASAP. Then
later when the MMC driver starts up, the Linux MMC stack will
need to start from a power off state. It can't just
if (regulator_is_enabled(r))
regulator_disable(r);
unless enable state and usecount are matched ... but without
this patch, they *will* be mismatched whenever the bootloader
happens to have left that regulator active! Similar issues
can crop up with almost any regulator.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
drivers/regulator/core.c | 47 +---
include/linux/regulator/machine.h |3 +-
2 files changed, 40 insertions(+), 10 deletions(-)
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -799,18 +799,47 @@ static int set_machine_constraints(struc
}
}
- /* If the constraints say the regulator should be on at this point
-* and we have control then make sure it is enabled.
+ /* During integration, developers may need time to sort out what
+* to do with this regulator; leave the bootloader's setting alone.
+* Regulator consumers won't get consistent behavior.
+*
+* Else the constraints say whether it should be on or off; we
+* don't leave it in an unknown state.
*/
- if ((constraints-always_on || constraints-boot_on) ops-enable) {
- ret = ops-enable(rdev);
- if (ret 0) {
- printk(KERN_ERR %s: failed to enable %s\n,
- __func__, name);
- rdev-constraints = NULL;
- goto out;
+ if (constraints-devmode) {
+ char *label = unknown;
+
+ if (ops-is_enabled) {
+ ret = ops-is_enabled(rdev);
+ if (ret == 0)
+ label = disabled;
+ else if (ret 0)
+ label = enabled;
+ ret = 0;
+ }
+ pr_warning(%s: devmode regulator '%s' state is '%s'\n,
+ __func__, name, label);
+ } else if (constraints-always_on || constraints-boot_on) {
+ if (ops-enable) {
+ ret = ops-enable(rdev);
+ if (ret 0) {
+ pr_err(%s: failed enabling %s\n,
+ __func__, name);
+ rdev-constraints = NULL;
+ goto out;
+ }
}
rdev-use_count = 1;
+ } else {
+ if (ops-disable) {
+ ret = ops-disable(rdev);
+ if (ret 0) {
+ pr_err(%s: failed disabling %s\n,
+ __func__, name);
+ rdev-constraints = NULL;
+ goto out;
+ }
+ }
}
print_constraints(rdev);
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -117,7 +117,8 @@ struct regulation_constraints {
/* mode to set on startup */
unsigned int initial_mode;
- /* constriant flags */
+ /* constraint flags */
+ unsigned devmode:1; /* state after setup is indeterminate */
unsigned always_on:1; /* regulator never off when system is on */
unsigned boot_on:1; /* bootloader/firmware enabled regulator */
unsigned apply_uV:1;/* apply uV constraint iff min == max */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
Hi Felipe, On Thu, 12 Mar 2009, Felipe Balbi wrote: This is the link where Ingo discusses why !IRQF_DISABLED could cause stack overflow: http://lkml.org/lkml/2009/3/3/71 You probably wanna take a look at the whole thread to figure out the discussion, but basically Ingo and Peter (Zijlstra) believe !IRQF_DISABLED is a bug and drivers needing that probably should be using threaded irqs (which is not yet merged) or the hw is broken, and for those an IRQF_ENABLED flag will be created and a TAINT will also be placed. Once that gets merged, all drivers will be forced (at some point) to IRQF_DISABLED and those which don't want that will be moved gradually to threaded irq. This patch is also interesting: http://lkml.org/lkml/2009/3/2/33 Thanks for the links. Those issues are indeed distinct from the spurious IRQ problem that Ari is reporting. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] DSPBRIDGE Fix for image autoload
All, This patch set fixes an issue with dsp image autoloading while bridgedriver module intialization. This can be applied along with the other DSPBRIDGE patches, validated on OMAP3430 SDP. drivers/dsp/bridge/rmgr/drv_interface.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) Regards Ramesh Gupta 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
[PATCH 1/1] DSPBRIDGE Fix for image autoload
From fbbf5c9c308c2e1e90e70c57a48798c5d05a6b1d Mon Sep 17 00:00:00 2001
From: Ramesh Gupta x0023...@ti.com
Date: Thu, 12 Mar 2009 10:48:08 +0530
Subject: [PATCH 1/1] DSPBRIDGE Fix for image autoload.
This fixes the issue with the image autoloading while
installing the bridgedriver with install param base_img
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 9c82ef4..c5c9ee5 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -405,7 +405,7 @@ static int __init bridge_init(void)
REG_SetValue(NULL, NULL, AUTOSTART, REG_DWORD, (u8 *)temp,
sizeof(temp));
REG_SetValue(NULL, NULL, DEFEXEC, REG_SZ, (u8 *)base_img,
- strlen(base_img) + 1);
+ strlen(base_img) + 1);
} else {
temp = false;
REG_SetValue(NULL, NULL, AUTOSTART, REG_DWORD, (u8 *)temp,
@@ -413,7 +413,7 @@ static int __init bridge_init(void)
REG_SetValue(NULL, NULL, DEFEXEC, REG_SZ, (u8 *) \0, (u32)2);
}
REG_SetValue(NULL, NULL, NUMPROCS, REG_SZ, (u8 *) num_procs,
- strlen(num_procs) + 1);
+ strlen(num_procs) + 1);
if (shm_size = 0x1) { /* 64 KB */
initStatus = REG_SetValue(NULL, NULL, SHMSIZE, REG_DWORD,
@@ -455,15 +455,6 @@ static int __init bridge_init(void)
sizeof(tc_wordswapon));
}
if (DSP_SUCCEEDED(initStatus)) {
- driverContext = DSP_Init(initStatus);
- if (DSP_FAILED(initStatus)) {
- status = -1;
- GT_0trace(driverTrace, GT_7CLASS,
-DSP/BIOS Bridge initialization Failed\n);
- } else {
- GT_0trace(driverTrace, GT_5CLASS,
- DSP/BIOS Bridge driver loaded\n);
- }
#ifdef CONFIG_BRIDGE_DVFS
for (i = 0; i 5; i++)
pdata-mpu_speed[i] = vdd1_rate_table_bridge[i].rate;
@@ -484,6 +475,15 @@ static int __init bridge_init(void)
clk_notifier_register FAIL for iva2_ck \n);
}
#endif
+ driverContext = DSP_Init(initStatus);
+ if (DSP_FAILED(initStatus)) {
+ status = -1;
+ GT_0trace(driverTrace, GT_7CLASS,
+DSP/BIOS Bridge initialization Failed\n);
+ } else {
+ GT_0trace(driverTrace, GT_5CLASS,
+ DSP/BIOS Bridge driver loaded\n);
+ }
}
DBC_Assert(status == 0);
@@ -660,11 +660,11 @@ func_cont:
(struct DRV_OBJECT *)hDrvObject, pPctxt);
if (pPctxt != NULL) {
- /* Return PID instead of process handle */
- hProcess = current-pid;
+ /* Return PID instead of process handle */
+ hProcess = current-pid;
DRV_ProcUpdatestate(pPctxt, PROC_RES_ALLOCATED);
- DRV_ProcSetPID(pPctxt, hProcess);
+ DRV_ProcSetPID(pPctxt, hProcess);
}
#endif
--
1.5.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] DSPBRIDGE Fix for image autoload
Ramesh, -Original Message- From: Gupta, Ramesh Sent: Thursday, March 12, 2009 7:32 AM To: linux-omap@vger.kernel.org Cc: Menon, Nishanth; Kanigeri, Hari; Guzman Lugo, Fernando Subject: [PATCH 1/1] DSPBRIDGE Fix for image autoload From fbbf5c9c308c2e1e90e70c57a48798c5d05a6b1d Mon Sep 17 00:00:00 2001 From: Ramesh Gupta x0023...@ti.com Date: Thu, 12 Mar 2009 10:48:08 +0530 Subject: [PATCH 1/1] DSPBRIDGE Fix for image autoload. This fixes the issue with the image autoloading while installing the bridgedriver with install param base_img What is your code base? Omapzoom or gitorious? Could you send us the link to the git log of the branch you are sending this for? 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
