ARM : OMAP: Pass logical DMA channel number always to callback handlers

2008-11-26 Thread Shilimkar, Santosh
Hi Jarkko\Tony ,

Recently during some debugging, I observed this patch.
http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f31b799565c9ee85d42bd163f80

As per your description,it improves the debugging. Can you elaborate more on 
this ?

For users this change is little confusing, if they go as per the signatures of 
the 'omap_request_dma_chain' and 'omap_request_dma' APIs. Also separating the 
callbacks for chained and non-chained transfers seems to be the practical usage 
in most of the cases. Also users would be only interested in 'chain_id' and not 
'channel number' in case of chaining.  

So if it improves only debugging and some what complicates the usage, I suggest 
we should revert this patch.

Regards,
Santosh Shilimkar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PWM drivers for TWL4030

2008-11-26 Thread Grazvydas Ignotas
On Wed, Nov 26, 2008 at 3:42 AM, David Brownell [EMAIL PROTECTED] wrote:
 On Tuesday 25 November 2008, Grazvydas Ignotas wrote:
  If they're using the LEDA or LEDB PWMs, providing and exporting
  a brightness control would be easy.  If they're using the other
  two PWMs, it'd be more work.

 The configuration is as follows:
 LEDA - keypad backlight
 LEDB - power LED
 PWM0 - LCD backlight
 PWM1 - charger LED

 Might have been better to use LEDA and LEDB for backlights,
 you probably could have saved some external hardware ... those
 pins are high drive.  :)
LEDB probably wasn't used for LCD backlight because it doesn't provide
enough power (60mA only). Don't know for sure, it wasn't me who
designed the hardware.

 Right, start as gpio leds.  Since I've already looked at it,
 I may take a whack at exposing LEDA/LEDB PWMs ... expecting to
 use thhe same interface for PWM0/PWM1.
That would be great, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ARM : OMAP: Pass logical DMA channel number always to callback handlers

2008-11-26 Thread Jarkko Nikula
On Wed, 26 Nov 2008 14:43:02 +0530
ext Shilimkar, Santosh [EMAIL PROTECTED] wrote:

 Hi Jarkko\Tony ,
 
 Recently during some debugging, I observed this patch.
 http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=538528de0cb256f65716ab2e9613d9e920f97fe2;hp=29e8c3c304b62f31b799565c9ee85d42bd163f80
 
 As per your description,it improves the debugging. Can you elaborate more on 
 this ?
 
Honestly don't remember what I meant for easier debugging, probably
just watching how the logical channels are rotating during the transfer
or something like that.

 For users this change is little confusing, if they go as per the signatures 
 of the 'omap_request_dma_chain' and 'omap_request_dma' APIs. Also separating 
 the callbacks for chained and non-chained transfers seems to be the practical 
 usage in most of the cases. Also users would be only interested in 'chain_id' 
 and not 'channel number' in case of chaining.  
 
As commit log says, user can pass the chain_id via callback data if
needed. I think chained dma callback may also find more use for logical
channel number than chain_id e.g. when modifying the transfer
parameters etc.

And uniform, smaller API set is always better than bloated one.


Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread Mark Brown
On Wed, Nov 26, 2008 at 06:47:58PM +0800, Stanley.Miao wrote:
 Add a shared omap SoC driver to avoid reduplicate code among omap soc drivers.

It's really good to see work on this but I've got some concerns with the
approach being taken here.

 +
 +config SND_OMAP_SOC_OVERO
 + tristate SoC Audio support for Gumstix Overo
 + depends on SND_OMAP_SOC  MACH_OVERO

This won't apply - this and several of the other machines are already
present.

 +#ifdef CONFIG_SND_OMAP_SOC_N810
 +#include ../codecs/tlv320aic3x.h
 +#define CODEC_SYS_CLOCK  1200
 +#define CODEC_NAME   TLV320AIC33
 +#define STREAM_NAME  AIC33
 +#define CODEC_DEV(soc_codec_dev_aic3x)
 +#define CODEC_DAI(aic3x_dai)
 +#define CODEC_SETUP_DATA (n810_aic33_setup)
 +#define DAI_LINK_INIT(n810_aic33_init)
 +#define SOC_OPS_STARTUP  (n810_startup)
 +#define SOC_OPS_SHUTDOWN (n810_shutdown)

Please change this to use a platform data based approach rather than
these ifdefs: it's not a good approach for readability and it prevents
building multiple board drivers in one kernel which isn't good for
distributions.  The s3c24xx_uda134x.c provides an example of how this
can be done.  It may be more sensible to have a separate driver per
codec.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread Jarkko Nikula
On Wed, 26 Nov 2008 11:08:55 +
ext Mark Brown [EMAIL PROTECTED] wrote:

  +#ifdef CONFIG_SND_OMAP_SOC_N810
  +#include ../codecs/tlv320aic3x.h
  +#define CODEC_SYS_CLOCK1200
  +#define CODEC_NAME TLV320AIC33
  +#define STREAM_NAMEAIC33
  +#define CODEC_DEV  (soc_codec_dev_aic3x)
  +#define CODEC_DAI  (aic3x_dai)
  +#define CODEC_SETUP_DATA   (n810_aic33_setup)
  +#define DAI_LINK_INIT  (n810_aic33_init)
  +#define SOC_OPS_STARTUP(n810_startup)
  +#define SOC_OPS_SHUTDOWN   (n810_shutdown)
 
 Please change this to use a platform data based approach rather than
 these ifdefs: it's not a good approach for readability and it prevents
 building multiple board drivers in one kernel which isn't good for
 distributions.  The s3c24xx_uda134x.c provides an example of how this
 can be done.  It may be more sensible to have a separate driver per
 codec.
 --
And as a first step, I recommend to start merging only those EVM  SDP
boards with Beagle since they seems to be most close to each other.

Even the Overo seems to be close also, it was discussed earlier to keep
it separated now since Steve was going to send some new features into
it.


Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAP3: Fixes for suspend / resume GPIO wake-up handling

2008-11-26 Thread Tero Kristo
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
 arch/arm/plat-omap/gpio.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f4ec3af..62349fd 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1585,7 +1585,7 @@ static int omap_gpio_suspend(struct sys_device *dev, 
pm_message_t mesg)
 #endif
 #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
case METHOD_GPIO_24XX:
-   wake_status = bank-base + OMAP24XX_GPIO_SETWKUENA;
+   wake_status = bank-base + OMAP24XX_GPIO_WAKE_EN;
wake_clear = bank-base + OMAP24XX_GPIO_CLEARWKUENA;
wake_set = bank-base + OMAP24XX_GPIO_SETWKUENA;
break;
@@ -1608,7 +1608,7 @@ static int omap_gpio_resume(struct sys_device *dev)
 {
int i;
 
-   if (!cpu_is_omap24xx()  !cpu_is_omap16xx())
+   if (!cpu_class_is_omap2()  !cpu_is_omap16xx())
return 0;
 
for (i = 0; i  gpio_bank_count; i++) {
-- 
1.5.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] i2c: i2c-omap: Fix standard and fast mode prescalers

2008-11-26 Thread ext-eero . nurkkala
From: Eero Nurkkala [EMAIL PROTECTED]

The prescalers for 100 kHz and 400 kHz mode
are wrong for omap 3430 and omap 2430. The
internal clock is the fclock divided by the
prescaler. The PSC is an 8 bit field in
omap3430 and omap2430. Moreover, the scll and
sclh values should be adjusted properly.
Having the correct prescaler is important in
the process of getting a finite i2c clock. In
addition, the prescaler is used in the process
of activating the correct noise filter and thus,
lets more error resilient i2c communications.

Signed-off-by: Eero Nurkkala [EMAIL PROTECTED]
---
 drivers/i2c/busses/i2c-omap.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 630702c..c21af3f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -337,7 +337,13 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
 
/* HSI2C controller internal clk rate should be 19.2 Mhz */
-   internal_clk = 19200;
+   if (dev-speed  400)
+   internal_clk = 19200;
+   else if (dev-speed  100)
+   internal_clk = 9600;
+   else
+   internal_clk = 4000;
+
fclk_rate = clk_get_rate(dev-fclk) / 1000;
 
/* Compute prescaler divisor */
@@ -355,8 +361,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
hssclh = fclk_rate / (dev-speed * 2) - 6;
} else {
/* To handle F/S modes */
-   fsscll = internal_clk / (dev-speed * 2) - 6;
-   fssclh = internal_clk / (dev-speed * 2) - 6;
+   fsscll = internal_clk / (dev-speed * 2) - 3;
+   fssclh = internal_clk / (dev-speed * 2) - 9;
}
scll = (hsscll  OMAP_I2C_SCLL_HSSCLL) | fsscll;
sclh = (hssclh  OMAP_I2C_SCLH_HSSCLH) | fssclh;
-- 
1.6.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ARM : OMAP: Pass logical DMA channel number always to callback handlers

2008-11-26 Thread Jarkko Nikula
On Wed, 26 Nov 2008 16:26:42 +0530
ext Shilimkar, Santosh [EMAIL PROTECTED] wrote:

  As commit log says, user can pass the chain_id via callback data if
  needed. 
 Yes there are few ways you can achieve this if you don't want to pass the 
 chain_id as part of the callback. But in that case the 
 'omap_request_dma_chain' callback signature should have been also cleaned ( 
 'ch' instead of 'chain_id').
 
Ah, yeah, then it was missing from my patch and have to send a patch
changing it.

 I think chained dma callback may also find more use 
  for logical channel number than chain_id e.g. when modifying the transfer
  parameters etc.
 When user wants to use chaining,they expects that the chain internals ( free 
 channel allocation etc) should be managed by DMA library. So even user wants 
 to modify the parameters, it can directly use 'omap_modify_dma_chain_params' 
 api and just provide 'chain_id'. For which channel the parameters should be 
 changed will be decided by the DMA library internally depending on free 
 channels from chain.

This approach doesn't work e.g. with audio. Let's assume you would like
to use DMA chaining with ALSA (been there, done that, until found a
better solution. See sound/soc/omap-pcm.c).

ALSA application may ask to use e.g. 100 periods, which is more than
n.o. logical DMA channels in OMAP so chain length is have to be shorter
than n.o. periods. Which then means that channel parameters are have to
modify while the chain is running.

omap_modify_dma_chain_params is setting parameters for all channels in
a chain, and more over, function header of it says Dont do this while
dma is running!!.

  And uniform, smaller API set is always better than bloated one.
 This change any way don't reduce a single API so not sure what you mean by 
 'smaller API set is always better than bloated one'. It may reduce a callback 
 for a user in
  
IMO, API is a one step bigger if DMA callback has different arguments
depending is it in non-chained vs. chained configuration.

 So I still don't see a real benefit of this patch. Because of above mentioned 
 reasons I think  we should revert this patch.
 
Probably you would like to show/share opposite example?


Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] PM: Added suspend target state control to debugfs for OMAP3

2008-11-26 Thread Tero Kristo
Target state can be read / programmed via files under:
  [debugfs]/pm_debug/[pwrdm]/suspend

Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/pm-debug.c |   30 --
 arch/arm/mach-omap2/pm.h   |4 
 arch/arm/mach-omap2/pm34xx.c   |   24 
 3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 82219f4..ac61d15 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -26,6 +26,7 @@
 #include linux/clk.h
 #include linux/err.h
 #include linux/io.h
+#include linux/module.h
 
 #include mach/clock.h
 #include mach/board.h
@@ -511,11 +512,28 @@ int pm_dbg_regset_init(int reg_set)
return 0;
 }
 
-static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+static int pwrdm_suspend_get(void *data, u64 *val)
+{
+   *val = omap3_pm_get_suspend_state((struct powerdomain *)data);
+
+   if (*val = 0)
+   return 0;
+   return *val;
+}
+
+static int pwrdm_suspend_set(void *data, u64 val)
+{
+   return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get, 
pwrdm_suspend_set, %llu\n);
+
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
 {
int i;
s64 t;
struct timespec now;
+   struct dentry *d;
 
getnstimeofday(now);
t = timespec_to_ns(now);
@@ -525,6 +543,14 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, 
void *unused)
 
pwrdm-timer = t;
 
+   if (strncmp(pwrdm-name, dpll, 4) == 0)
+   return 0;
+
+   d = debugfs_create_dir(pwrdm-name, (struct dentry *)dir);
+
+   (void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d,
+   (void *)pwrdm, pwrdm_suspend_fops);
+
return 0;
 }
 
@@ -545,7 +571,7 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(time, S_IRUGO,
d, (void *)DEBUG_FILE_TIMERS, debug_fops);
 
-   pwrdm_for_each(pwrdms_setup, NULL);
+   pwrdm_for_each(pwrdms_setup, (void *)d);
 
pm_dbg_dir = debugfs_create_dir(registers, d);
if (IS_ERR(pm_dbg_dir))
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4b1ba7c..78fde57 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -34,8 +34,12 @@ extern void omap2_block_sleep(void);
 extern void omap2_allow_sleep(void);
 #ifdef CONFIG_ARCH_OMAP3
 extern void omap3_pm_off_mode_enable(int);
+extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
+extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
 #else
 #define omap3_pm_off_mode_enable(int) do {} while (0);
+#define omap3_pm_get_suspend_state(pwrdm) do {} while (0);
+#define omap3_pm_set_suspend_state(pwrdm,state) do {} while (0);
 #endif
 extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 191299c..73ac22c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -780,6 +780,30 @@ void omap3_pm_off_mode_enable(int enable)
}
 }
 
+int omap3_pm_get_suspend_state(struct powerdomain *pwrdm)
+{
+   struct power_state *pwrst;
+
+   list_for_each_entry(pwrst, pwrst_list, node) {
+   if (pwrst-pwrdm == pwrdm)
+   return pwrst-next_state;
+   }
+   return -EINVAL;
+}
+
+int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state)
+{
+   struct power_state *pwrst;
+
+   list_for_each_entry(pwrst, pwrst_list, node) {
+   if (pwrst-pwrdm == pwrdm) {
+   pwrst-next_state = state;
+   return 0;
+   }
+   }
+   return -EINVAL;
+}
+
 static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 {
struct power_state *pwrst;
-- 
1.5.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Fix crash on non-3430SDP platforms with DVFS/CPUFreq

2008-11-26 Thread Rajendra Nayak
The SRF/DVFS + CPUFreq patches had issues booting on
non-3430SDP platforms as reported by Kevin Hilman.
This patch puts non-NULL checks in place for mpu_opps/dsp_opps
/l3_opps before accessing them and fixes the issue.

This fix/patch can be applied on top of 
pm-20081119 branch 
+ [PATCH 00/08] OMAP3 SRF: OPP and Frequency resources
+ [PATCH 00/03] OMAP3 PM: CPUFreq driver for OMAP3

Signed-off-by: Rajendra Nayak [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/clock34xx.c|   33 -
 arch/arm/mach-omap2/pm.h   |   18 ---
 arch/arm/mach-omap2/resource34xx.c |   21 ++
 arch/arm/plat-omap/cpu-omap.c  |6 +
 arch/arm/plat-omap/include/mach/omap34xx.h |   18 +++
 5 files changed, 64 insertions(+), 32 deletions(-)

Index: linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock34xx.c 2008-11-26 
17:43:12.011090533 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c  2008-11-26 
17:47:40.551795371 +0530
@@ -666,6 +666,9 @@ void omap2_clk_init_cpufreq_table(struct
struct omap_opp *prcm;
int i = 0;
 
+   if (!mpu_opps)
+   return;
+
/* Avoid registering the 120% Overdrive with CPUFreq */
prcm = mpu_opps + MAX_VDD1_OPP - 1;
for (; prcm-rate; prcm--) {
@@ -798,20 +801,24 @@ int __init omap2_clk_init(void)
dpll3_clk = clk_get(NULL, dpll3_m2_ck);
 
mpu_speed = dpll1_clk-rate;
-   prcm_vdd = mpu_opps + MAX_VDD1_OPP;
-   for (; prcm_vdd-rate; prcm_vdd--) {
-   if (prcm_vdd-rate = mpu_speed) {
-   curr_vdd1_prcm_set = prcm_vdd;
-   break;
+   if (mpu_opps) {
+   prcm_vdd = mpu_opps + MAX_VDD1_OPP;
+   for (; prcm_vdd-rate; prcm_vdd--) {
+   if (prcm_vdd-rate = mpu_speed) {
+   curr_vdd1_prcm_set = prcm_vdd;
+   break;
+   }
}
}
 
core_speed = dpll3_clk-rate;
-   prcm_vdd = l3_opps + MAX_VDD2_OPP;
-   for (; prcm_vdd-rate; prcm_vdd--) {
-   if (prcm_vdd-rate = core_speed) {
-   curr_vdd2_prcm_set = prcm_vdd;
-   break;
+   if (l3_opps) {
+   prcm_vdd = l3_opps + MAX_VDD2_OPP;
+   for (; prcm_vdd-rate; prcm_vdd--) {
+   if (prcm_vdd-rate = core_speed) {
+   curr_vdd2_prcm_set = prcm_vdd;
+   break;
+   }
}
}
 
@@ -878,6 +885,9 @@ static long omap3_round_to_table_rate(st
if ((clk != virt_vdd1_prcm_set)  (clk != virt_vdd2_prcm_set))
return -EINVAL;
 
+   if (!mpu_opps || !dsp_opps || !l3_opps)
+   return -EINVAL;
+
highest_rate = -EINVAL;
 
if (clk == virt_vdd1_prcm_set)
@@ -904,6 +914,9 @@ static int omap3_select_table_rate(struc
if ((clk != virt_vdd1_prcm_set)  (clk != virt_vdd2_prcm_set))
return -EINVAL;
 
+   if (!mpu_opps || !dsp_opps || !l3_opps)
+   return -EINVAL;
+
if (clk == virt_vdd1_prcm_set) {
prcm_vdd = mpu_opps + MAX_VDD1_OPP;
index = MAX_VDD1_OPP;
Index: linux-omap-2.6/arch/arm/mach-omap2/pm.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/pm.h2008-11-26 
17:43:12.011090533 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/pm.h 2008-11-26 17:47:40.552795340 
+0530
@@ -39,24 +39,6 @@ extern void omap3_pm_off_mode_enable(int
 #endif
 extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 
-
-/* VDD1 OPPS */
-#define VDD1_OPP1  0x1
-#define VDD1_OPP2  0x2
-#define VDD1_OPP3  0x3
-#define VDD1_OPP4  0x4
-#define VDD1_OPP5  0x5
-
-/* VDD2 OPPS */
-#define VDD2_OPP1  0x1
-#define VDD2_OPP2  0x2
-#define VDD2_OPP3  0x3
-
-#define MIN_VDD1_OPP   VDD1_OPP1
-#define MAX_VDD1_OPP   VDD1_OPP5
-#define MIN_VDD2_OPP   VDD2_OPP1
-#define MAX_VDD2_OPP   VDD2_OPP3
-
 #ifdef CONFIG_PM_DEBUG
 extern u32 omap2_read_32k_sync_counter(void);
 extern void omap2_pm_dump(int mode, int resume, unsigned int us);
Index: linux-omap-2.6/arch/arm/mach-omap2/resource34xx.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/resource34xx.c  2008-11-26 
17:43:12.011090533 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/resource34xx.c   2008-11-26 
18:16:28.376582736 +0530
@@ -144,6 +144,10 @@ static struct device dummy_dsp_dev;
 void init_opp(struct shared_resource *resp)
 {
resp-no_of_users = 0;
+   
+   if (!mpu_opps || !dsp_opps || !l3_opps)
+   return 0;
+
/* Initialize the current 

[PATCH] OMAP general SOC driver.

2008-11-26 Thread Stanley.Miao
Add a shared omap SoC driver to avoid reduplicate code among omap soc drivers.

Signed-off-by: Stanley.Miao [EMAIL PROTECTED]
---
 sound/soc/omap/Kconfig|   49 +
 sound/soc/omap/Makefile   |   13 
 sound/soc/omap/omap-general.c |  155 +
 sound/soc/omap/omap-general.h |   70 ++
 4 files changed, 287 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/omap/omap-general.c
 create mode 100644 sound/soc/omap/omap-general.h

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 8b7766b..92a557f 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -14,6 +14,14 @@ config SND_OMAP_SOC_N810
help
  Say Y if you want to add support for SoC audio on Nokia N810.
 
+config SND_OMAP_SOC_OMAP3_BEAGLE
+   tristate SoC Audio support for OMAP3 Beagle
+   depends on SND_OMAP_SOC  MACH_OMAP3_BEAGLE
+   select SND_OMAP_SOC_MCBSP
+   select SND_SOC_TWL4030
+   help
+ Say Y if you want to add support for SoC audio on the Beagleboard.
+
 config SND_OMAP_SOC_OSK5912
tristate SoC Audio support for omap osk5912
depends on SND_OMAP_SOC  MACH_OMAP_OSK
@@ -21,3 +29,44 @@ config SND_OMAP_SOC_OSK5912
select SND_SOC_TLV320AIC23
help
  Say Y if you want to add support for SoC audio on osk5912.
+
+config SND_OMAP_SOC_OVERO
+   tristate SoC Audio support for Gumstix Overo
+   depends on SND_OMAP_SOC  MACH_OVERO
+   select SND_OMAP_SOC_MCBSP
+   select SND_SOC_TWL4030
+   help
+ Say Y if you want to add support for SoC audio on the Gumstix Overo.
+
+config SND_OMAP_SOC_3430SDP
+   tristate SoC Audio support for OMAP 3430SDP
+   depends on SND_OMAP_SOC  MACH_OMAP_3430SDP
+   select SND_OMAP_SOC_MCBSP
+   select SND_SOC_TWL4030
+   help
+ Say Y if you want to add support for SoC audio on the OMAP 3430SDP.
+
+config SND_OMAP_SOC_LDP
+   tristate SoC Audio support for OMAP ZOOM SDK
+   depends on SND_OMAP_SOC  MACH_OMAP_LDP
+   select SND_OMAP_SOC_MCBSP
+   select SND_SOC_TWL4030
+   help
+ Say Y if you want to add support for SoC audio on the OMAP ZOOM MDK.
+
+config SND_OMAP_SOC_OMAP2EVM
+   tristate SoC Audio support for OMAP2EVM
+   depends on SND_OMAP_SOC  MACH_OMAP2EVM
+   select SND_OMAP_SOC_MCBSP
+   select SND_SOC_TWL4030
+   help
+ Say Y if you want to add support for SoC audio on the OMAP2EVM.
+
+config SND_OMAP_SOC_OMAP3EVM
+   tristate SoC Audio support for OMAP3EVM
+   depends on SND_OMAP_SOC  MACH_OMAP3EVM
+   select SND_OMAP_SOC_MCBSP
+   select SND_SOC_TWL4030
+   help
+ Say Y if you want to add support for SoC audio on the OMAP3EVM.
+
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index e09d1f2..de9163b 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -7,7 +7,20 @@ obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
 
 # OMAP Machine Support
 snd-soc-n810-objs := n810.o
+snd-soc-omap3beagle-objs := omap-general.o
 snd-soc-osk5912-objs := osk5912.o
+snd-soc-overo-objs := omap-general.o
+snd-soc-3430sdp-objs := omap-general.o
+snd-soc-ldp-objs := omap-general.o
+snd-soc-omap2evm-objs := omap-general.o
+snd-soc-omap3evm-objs := omap-general.o
 
 obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
+obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
 obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o
+obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
+obj-$(CONFIG_SND_OMAP_SOC_3430SDP) += snd-soc-3430sdp.o
+obj-$(CONFIG_SND_OMAP_SOC_LDP) += snd-soc-ldp.o
+obj-$(CONFIG_SND_OMAP_SOC_OMAP2EVM) += snd-soc-omap2evm.o
+obj-$(CONFIG_SND_OMAP_SOC_OMAP3EVM) += snd-soc-omap3evm.o
+
diff --git a/sound/soc/omap/omap-general.c b/sound/soc/omap/omap-general.c
new file mode 100644
index 000..a3fa647
--- /dev/null
+++ b/sound/soc/omap/omap-general.c
@@ -0,0 +1,155 @@
+/*
+ * omap-general.c  --  OMAP SoC general machine file.
+ *
+ * Author: Stanley Miao [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/clk.h
+#include linux/platform_device.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+
+#include asm/mach-types.h
+#include mach/hardware.h
+#include 

Re: Please fix or remove OMAP2 onenand driver

2008-11-26 Thread Russell King - ARM Linux
On Mon, Nov 24, 2008 at 02:44:36PM +0200, Adrian Hunter wrote:
 From: Adrian Hunter [EMAIL PROTECTED]
 Date: Mon, 24 Nov 2008 13:34:53 +0200
 Subject: [PATCH] MTD: OMAP: OneNAND: header file relocation
 
 Signed-off-by: Adrian Hunter [EMAIL PROTECTED]

Great.

Acked-by: Russell King [EMAIL PROTECTED]

David, can you merge this patch for 2.6.28 please?

 ---
 drivers/mtd/onenand/omap2.c |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
 index e39b21d..a7e4d98 100644
 --- a/drivers/mtd/onenand/omap2.c
 +++ b/drivers/mtd/onenand/omap2.c
 @@ -32,19 +32,18 @@
 #include linux/platform_device.h
 #include linux/interrupt.h
 #include linux/delay.h
 +#include linux/dma-mapping.h
 +#include linux/io.h
 
 -#include asm/io.h
 #include asm/mach/flash.h
 -#include asm/arch/gpmc.h
 -#include asm/arch/onenand.h
 -#include asm/arch/gpio.h
 -#include asm/arch/pm.h
 +#include mach/gpmc.h
 +#include mach/onenand.h
 +#include mach/gpio.h
 +#include mach/pm.h
 
 -#include linux/dma-mapping.h
 -#include asm/dma-mapping.h
 -#include asm/arch/dma.h
 +#include mach/dma.h
 
 -#include asm/arch/board.h
 +#include mach/board.h
 
 #define DRIVER_NAME omap2-onenand
 
 -- 
 1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread Tony Lindgren
* Stanley.Miao [EMAIL PROTECTED] [081126 02:42]:
 Add a shared omap SoC driver to avoid reduplicate code among omap soc drivers.
 
 Signed-off-by: Stanley.Miao [EMAIL PROTECTED]
 ---
  sound/soc/omap/Kconfig|   49 +
  sound/soc/omap/Makefile   |   13 
  sound/soc/omap/omap-general.c |  155 
 +
  sound/soc/omap/omap-general.h |   70 ++
  4 files changed, 287 insertions(+), 0 deletions(-)
  create mode 100644 sound/soc/omap/omap-general.c
  create mode 100644 sound/soc/omap/omap-general.h
 

snip

 --- /dev/null
 +++ b/sound/soc/omap/omap-general.h
 @@ -0,0 +1,70 @@
 +/*
 + * omap-general.h
 + *
 + * Copyright (C) 2008 Wind River Systems, Inc.
 + *
 + * Author: Stanley Miao [EMAIL PROTECTED]
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 + * 02110-1301 USA
 + *
 + */
 +
 +#ifdef CONFIG_SND_OMAP_SOC_N810
 +#include ../codecs/tlv320aic3x.h
 +#define CODEC_SYS_CLOCK  1200
 +#define CODEC_NAME   TLV320AIC33
 +#define STREAM_NAME  AIC33
 +#define CODEC_DEV(soc_codec_dev_aic3x)
 +#define CODEC_DAI(aic3x_dai)
 +#define CODEC_SETUP_DATA (n810_aic33_setup)
 +#define DAI_LINK_INIT(n810_aic33_init)
 +#define SOC_OPS_STARTUP  (n810_startup)
 +#define SOC_OPS_SHUTDOWN (n810_shutdown)
 +#else
 +#include ../codecs/twl4030.h
 +#define CODEC_SYS_CLOCK  2600
 +#define CODEC_NAME   TWL4030
 +#define STREAM_NAME  TWL4030
 +#define CODEC_DEV(soc_codec_dev_twl4030)
 +#define CODEC_DAI(twl4030_dai)
 +#define CODEC_SETUP_DATA NULL
 +#define DAI_LINK_INITNULL
 +#define SOC_OPS_STARTUP  NULL
 +#define SOC_OPS_SHUTDOWN NULL
 +#endif /* CONFIG_SND_OMAP_SOC_N810 */
 +
 +#ifdef CONFIG_SND_OMAP_SOC_N810
 +#define MACHINE_IS_OMAP_GENERAL (machine_is_nokia_n810() || 
 machine_is_nokia_n810_wimax())
 +#elif defined(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE)
 +#define MACHINE_IS_OMAP_GENERAL machine_is_omap3_beagle()
 +#elif defined(CONFIG_SND_OMAP_SOC_OVERO)
 +#define MACHINE_IS_OMAP_GENERAL machine_is_overo()
 +#elif defined(CONFIG_SND_OMAP_SOC_3430SDP)
 +#define MACHINE_IS_OMAP_GENERAL machine_is_omap_3430sdp()
 +#elif defined(CONFIG_SND_OMAP_SOC_LDP)
 +#define MACHINE_IS_OMAP_GENERAL machine_is_omap_ldp()
 +#elif defined(CONFIG_SND_OMAP_SOC_OMAP2EVM)
 +#define MACHINE_IS_OMAP_GENERAL machine_is_omap2evm()
 +#elif defined(CONFIG_SND_OMAP_SOC_OMAP3EVM)
 +#define MACHINE_IS_OMAP_GENERAL machine_is_omapevm()
 +#endif

Please also remove these ifdef elsif stuff above to compile in support
for multiple boards. The best way to to do it is to pass the
necessary info in platform_data, so you should not need to use
machine_is_omap() or cpu_is_omap() in the actual driver code.

Regards,

Tony


 +#ifndef omap_board_soc_init
 +#define omap_board_soc_init(x) 0
 +#endif
 +#ifndef omap_board_soc_exit
 +#define omap_board_soc_exit
 +#endif
 +
 -- 
 1.5.6.3
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] Add Input/Output related ioctl support

2008-11-26 Thread Hans Verkuil
On Wednesday 26 November 2008 18:04:39 [EMAIL PROTECTED] wrote:
 From: Vaibhav Hiremath [EMAIL PROTECTED]

 Note - Resending again with TVP driver for completeness.

 Added ioctl support for query std, set std, enum input,
 get input, set input, enum output, get output and set output.

 For sensor kind of slave drivers v4l2-int-device.h provides
 necessary ioctl support, but the ioctls required to interface
 with decoders and encoders are missing. Most of the decoders
 and encoders supports multiple inputs and outputs, like
 S-Video or Composite.

 With these ioctl''s user can select the specific input/output.

 Signed-off-by: Brijesh Jadav [EMAIL PROTECTED]
 Signed-off-by: Hardik Shah [EMAIL PROTECTED]
 Signed-off-by: Manjunath Hadli [EMAIL PROTECTED]
 Signed-off-by: R Sivaraj [EMAIL PROTECTED]
 Signed-off-by: Vaibhav Hiremath [EMAIL PROTECTED]
 Signed-off-by: Karicheri Muralidharan [EMAIL PROTECTED]
 ---
  include/media/v4l2-int-device.h |   17 +
  1 files changed, 17 insertions(+), 0 deletions(-)

 diff --git a/include/media/v4l2-int-device.h
 b/include/media/v4l2-int-device.h index 9c2df41..2325b2a 100644
 --- a/include/media/v4l2-int-device.h
 +++ b/include/media/v4l2-int-device.h
 @@ -102,6 +102,7 @@ enum v4l2_power {
   V4L2_POWER_OFF = 0,
   V4L2_POWER_ON,
   V4L2_POWER_STANDBY,
 + V4L2_POWER_RESUME,
  };

Why is POWER_RESUME added? In an earlier discussion with Sakari Ailus it 
was decided not to add this (see the video4linux thread with 
subject [PATCH 4/6] V4L: Int if: Define new power state changes).

It also wasn't in your original patch.

Regards,

Hans


  /* Slave interface type. */
 @@ -183,6 +184,14 @@ enum v4l2_int_ioctl_num {
   vidioc_int_s_crop_num,
   vidioc_int_g_parm_num,
   vidioc_int_s_parm_num,
 + vidioc_int_querystd_num,
 + vidioc_int_s_std_num,
 + vidioc_int_enum_input_num,
 + vidioc_int_g_input_num,
 + vidioc_int_s_input_num,
 + vidioc_int_enumoutput_num,
 + vidioc_int_g_output_num,
 + vidioc_int_s_output_num,

   /*
*
 @@ -284,6 +293,14 @@ V4L2_INT_WRAPPER_1(g_crop, struct v4l2_crop, *);
  V4L2_INT_WRAPPER_1(s_crop, struct v4l2_crop, *);
  V4L2_INT_WRAPPER_1(g_parm, struct v4l2_streamparm, *);
  V4L2_INT_WRAPPER_1(s_parm, struct v4l2_streamparm, *);
 +V4L2_INT_WRAPPER_1(querystd, v4l2_std_id, *);
 +V4L2_INT_WRAPPER_1(s_std, v4l2_std_id, *);
 +V4L2_INT_WRAPPER_1(enum_input, struct v4l2_input, *);
 +V4L2_INT_WRAPPER_1(g_input, int, *);
 +V4L2_INT_WRAPPER_1(s_input, int, );
 +V4L2_INT_WRAPPER_1(enumoutput, struct v4l2_output, *);
 +V4L2_INT_WRAPPER_1(g_output, int, *);
 +V4L2_INT_WRAPPER_1(s_output, int, );

  V4L2_INT_WRAPPER_0(dev_init);
  V4L2_INT_WRAPPER_0(dev_exit);
 --
 1.5.6

 --
 video4linux-list mailing list
 Unsubscribe
 mailto:[EMAIL PROTECTED]
 https://www.redhat.com/mailman/listinfo/video4linux-list


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] [PATCH] OMAP general SOC driver.

2008-11-26 Thread Mark Brown
On Wed, Nov 26, 2008 at 09:24:03AM -0800, Steve Sakoman wrote:

 I'm all for factoring out common code, but I think that this approach
 will become a maintenance nightmare over time.

I had formed the impression that an awful lot of the boards had very
similar audio subsystems and that even with DAPM support it'd be fairly
straightforward to do standard drivers for certain classes of system.
If that's not the case then doing this sort of shared machine driver
probably isn't worth it at all.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap3evm LCD red-tint workaround

2008-11-26 Thread Tony Lindgren
* Koen Kooi [EMAIL PROTECTED] [081102 14:00]:

 Op 2 nov 2008, om 20:56 heeft Grazvydas Ignotas het volgende geschreven:

 PS: TS is still unusable with the 16x16 pixel resolution
 This is also the case for Pandora. The patch below fixes the problem,
 but as I have no other boards to test this on, I haven't sent it.
 See if it helps you.

 This fixes the problem on the EVM as well, thanks!

Guys, please take this discussion to fbdev mailing list and cc
linux-omap list. I'm not going to push any more omap fbdev patches,
so please send the patches against mainline kernel to fbdev list.

Regards,

Tony



 regards,

 Koen





 From 91f3af26bbf751b846e6265d86387e81be7c1364 Mon Sep 17 00:00:00 2001
 From: Grazvydas Ignotas [EMAIL PROTECTED]
 Date: Tue, 28 Oct 2008 22:01:42 +0200
 Subject: [PATCH] OMAP3: fix McSPI transfers

 Currently on OMAP3 if both write and read is set up for a transfer,
 the first byte returned on read is corrupted. Work around this by
 disabling channel between reads and writes, instead of transfers.
 ---
 drivers/spi/omap2_mcspi.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

 diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
 index 454a271..4890b6c 100644
 --- a/drivers/spi/omap2_mcspi.c
 +++ b/drivers/spi/omap2_mcspi.c
 @@ -710,7 +710,6 @@ static void omap2_mcspi_work(struct work_struct  
 *work)
  spi = m-spi;
  cs = spi-controller_state;

 -omap2_mcspi_set_enable(spi, 1);
  list_for_each_entry(t, m-transfers, transfer_list) {
  if (t-tx_buf == NULL  t-rx_buf == NULL  t-len) {
  status = -EINVAL;
 @@ -741,6 +740,8 @@ static void omap2_mcspi_work(struct work_struct  
 *work)
  if (t-len) {
  unsignedcount;

 +omap2_mcspi_set_enable(spi, 1);
 +
  /* RX_ONLY mode needs dummy data in TX reg */
  if (t-tx_buf == NULL)
  __raw_writel(0, cs-base
 @@ -752,6 +753,8 @@ static void omap2_mcspi_work(struct work_struct  
 *work)
  count = omap2_mcspi_txrx_pio(spi, t);
  m-actual_length += count;

 +omap2_mcspi_set_enable(spi, 0);
 +
  if (count != t-len) {
  status = -EIO;
  break;
 @@ -777,8 +780,6 @@ static void omap2_mcspi_work(struct work_struct  
 *work)
  if (cs_active)
  omap2_mcspi_force_cs(spi, 0);

 -omap2_mcspi_set_enable(spi, 0);
 -
  m-status = status;
  m-complete(m-context);

 -- 
 1.5.4.3

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap 
 in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Fix for dispc's error omapfb omapfb: irq error status 4020

2008-11-26 Thread Tony Lindgren
* Tomi Valkeinen [EMAIL PROTECTED] [081113 06:06]:
 Hi,
 
 On Fri, 2008-11-07 at 12:55 -0800, ext Rick Bronson wrote:
  Folks,
  
Please take a look at this change to drivers/video/omap/dispc.c.  It
  addresses a problem seen on some boots of OMAP's.  On about 1 in 30
  boots one gets an endless stream of interrupts from the
  DISPC_IRQ_SYNC_LOST bit in the DISPC_IRQSTATUS register.  The
  following messages are printed.
  
   omapfb omapfb: irq error status 4020
 
 Can you try the patch below if it fixes this problem for you? On my new
 display subsystem adding a sleep between enabling clocks and doing the
 soft reset removed the problem.
 
 I tried a bit with different sleep times. With 1ms sleep I still got
 sync losts. With 10ms I didn't, but I went safe and put 40ms.

Here's my canned fbdev reply for this tread too:

Guys, please take this discussion to fbdev mailing list and cc
linux-omap list. I'm not going to push any more omap fbdev patches,
so please send the patches against mainline kernel to fbdev list.

Regards,

Tony

 
  Tomi
 
 
 
 diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
 index c140c21..bdfda0c 100644
 --- a/drivers/video/omap/dispc.c
 +++ b/drivers/video/omap/dispc.c
 @@ -24,6 +24,7 @@
  #include linux/vmalloc.h
  #include linux/clk.h
  #include linux/io.h
 +#include linux/delay.h
  
  #include mach/sram.h
  #include mach/omapfb.h
 @@ -1402,6 +1403,10 @@ static int omap_dispc_init(struct omapfb_device 
 *fbdev, int ext_mode,
 /* Reset monitoring works only w/ the 54M clk */
 enable_digit_clocks(1);
  
 +   /* We need to wait here a bit, otherwise we sometimes start 
 to get
 +* synclost errors. */
 +   msleep(40);
 +
 /* Soft reset */
 MOD_REG_FLD(DISPC_SYSCONFIG, 1  1, 1  1);
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] omapfb: Fix argument of blank operation.

2008-11-26 Thread Tony Lindgren
* Felipe Contreras [EMAIL PROTECTED] [081125 11:24]:
 The blank operation should receive FB_BLANK_POWERDOWN, not
 VESA_POWERDOWN.

Here's my canned fbdev reply for this tread too:

Guys, please take this discussion to fbdev mailing list and cc
linux-omap list. I'm not going to push any more omap fbdev patches,
so please send the patches against mainline kernel to fbdev list.

Regards,

Tony


 Signed-off-by: Felipe Contreras [EMAIL PROTECTED]
 ---
  drivers/video/omap/omapfb_main.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/video/omap/omapfb_main.c 
 b/drivers/video/omap/omapfb_main.c
 index 3bb4247..c8db8b2 100644
 --- a/drivers/video/omap/omapfb_main.c
 +++ b/drivers/video/omap/omapfb_main.c
 @@ -348,7 +348,7 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
  
   omapfb_rqueue_lock(fbdev);
   switch (blank) {
 - case VESA_NO_BLANKING:
 + case FB_BLANK_UNBLANK:
   if (fbdev-state == OMAPFB_SUSPENDED) {
   if (fbdev-ctrl-resume)
   fbdev-ctrl-resume();
 @@ -359,7 +359,7 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
   do_update = 1;
   }
   break;
 - case VESA_POWERDOWN:
 + case FB_BLANK_POWERDOWN:
   if (fbdev-state == OMAPFB_ACTIVE) {
   fbdev-panel-disable(fbdev-panel);
   if (fbdev-ctrl-suspend)
 @@ -1842,7 +1842,7 @@ static int omapfb_suspend(struct platform_device *pdev, 
 pm_message_t mesg)
   struct omapfb_device *fbdev = platform_get_drvdata(pdev);
  
   if (fbdev != NULL)
 - omapfb_blank(VESA_POWERDOWN, fbdev-fb_info[0]);
 + omapfb_blank(FB_BLANK_POWERDOWN, fbdev-fb_info[0]);
   return 0;
  }
  
 @@ -1852,7 +1852,7 @@ static int omapfb_resume(struct platform_device *pdev)
   struct omapfb_device *fbdev = platform_get_drvdata(pdev);
  
   if (fbdev != NULL)
 - omapfb_blank(VESA_NO_BLANKING, fbdev-fb_info[0]);
 + omapfb_blank(FB_BLANK_UNBLANK, fbdev-fb_info[0]);
   return 0;
  }
  
 -- 
 1.6.0.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PWM drivers for TWL4030

2008-11-26 Thread David Brownell
On Wednesday 26 November 2008, Grazvydas Ignotas wrote:
 
  Might have been better to use LEDA and LEDB for backlights,
  you probably could have saved some external hardware ... those
  pins are high drive.  :)

 LEDB probably wasn't used for LCD backlight because it doesn't provide
 enough power (60mA only). Don't know for sure, it wasn't me who
 designed the hardware.

LEDA, at 160 mA, is the one to use to use for that then.
LEDB, at 60 mA, is indeed less hefty.

Though I suppose if both backlights are high current, you'd
end up hurting anyway.

- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Fix omap-gpio warnings when compiling for ARCH_OMAP15XX

2008-11-26 Thread Tony Lindgren
* Jonathan McDowell [EMAIL PROTECTED] [08 15:44]:
 When compiling for ARCH_OMAP15XX I get the following compiler warning in
 gpio.c:
 
 arch/arm/plat-omap/gpio.c: In function ‘_set_gpio_wakeup’:
 arch/arm/plat-omap/gpio.c:848: warning: unused variable ‘flags’
 
 Simple patch below fixes this.

Sorry for the delay on responding to this.. Let's rather start
splitting the gpio code into common code and processor specific code
to fix issues like this for good. In this case, we would only register
set_wakeup functions for 16xx, 24xx, and 34xx.

Regards,

Tony

 
 Signed-off-by: Jonathan McDowell [EMAIL PROTECTED]
 
 -
 diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
 index 8bb4542..bfbe366 100644
 --- a/arch/arm/plat-omap/gpio.c
 +++ b/arch/arm/plat-omap/gpio.c
 @@ -845,7 +845,10 @@ static inline void _set_gpio_irqenable(struct gpio_bank 
 *bank, int gpio, int ena
   */
  static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
  {
 +#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP24XX) || \
 + defined(CONFIG_ARCH_OMAP34XX)
   unsigned long flags;
 +#endif
  
   switch (bank-method) {
  #ifdef CONFIG_ARCH_OMAP16XX
 -
 
 J.
 
 -- 
 Web [   Asking whether machines can think is like asking whether   ]
 site: http:// [   submarines can swim.   ]   Made by
 www.earth.li/~noodles/  [  ] HuggieTag 0.0.23
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread David Brownell
On Wednesday 26 November 2008, Jarkko Nikula wrote:
 And as a first step, I recommend to start merging only those EVM  SDP
 boards with Beagle since they seems to be most close to each other.
 
 Even the Overo seems to be close also, it was discussed earlier to keep
 it separated now since Steve was going to send some new features into
 it.

This seems to focus on just the McBSP channel out of the OMAP ...
except that it hides (in that nasty #ifdeffery) the codec data.

The fact that it doesn't allow EAC or a McBSP successor says
to me it's not really general.  Heck ... it even hard-wires
McBSP2, preventing another channel from being used.  So IMO
a different name would be appropriate...

Re TWL4030 codec configuration ... I count three microphone
input channels not used on Beagle, plus a speaker output
and some other stuff.  So it's obvious that something which
works on Beagle won't handle more interesting configurations
of that audio support.  


Plus, if there's going to be a board-specific platform device
created, and stuffed with data like codec descriptions and
configuration data ... that's what arch/arm/mach-*/board-*.c
files are for.

I'm told that the ASoC stuff should go in a separate ASoC
area for some reason.  That still makes no good sense to me,
so if there's a brief explanation as to why it's done that
way, please fling me a URL.  :)

- Dave

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Fix omap-gpio warnings when compiling for ARCH_OMAP15XX

2008-11-26 Thread David Brownell
On Wednesday 26 November 2008, Tony Lindgren wrote:
 Let's rather start
 splitting the gpio code into common code and processor specific code
 to fix issues like this for good.

Working on that.  :)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 02/10] omap mailbox: add initial omap3 support

2008-11-26 Thread Tony Lindgren
* Hiroshi DOYU [EMAIL PROTECTED] [081125 16:10]:
 Hi Tony,
 
 From: ext Tony Lindgren [EMAIL PROTECTED]
 Subject: Re: [PATCH 02/10] omap mailbox: add initial omap3 support
 Date: Tue, 25 Nov 2008 13:54:14 -0800
 
  * Hiroshi DOYU [EMAIL PROTECTED] [081125 01:40]:
   Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
   ---
arch/arm/mach-omap2/devices.c  |   24 +++---
arch/arm/mach-omap2/mailbox.c  |   46 
   ++--
arch/arm/plat-omap/Kconfig |2 +-
arch/arm/plat-omap/include/mach/irqs.h |1 +
arch/arm/plat-omap/include/mach/omap34xx.h |2 +-
5 files changed, 52 insertions(+), 23 deletions(-)
   
   diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
   index 241e418..d385f0f 100644
   --- a/arch/arm/mach-omap2/devices.c
   +++ b/arch/arm/mach-omap2/devices.c
   @@ -84,13 +84,15 @@ static inline void omap_init_camera(void)
}
#endif

   -#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
   -#define OMAP2_MBOX_BASE  IO_ADDRESS(OMAP24XX_MAILBOX_BASE)
   +#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
   +
   +#define MBOX_REG_SIZE0x120

static struct resource mbox_resources[] = {
   +#if defined(CONFIG_ARCH_OMAP2420)
 {
   - .start  = OMAP2_MBOX_BASE,
   - .end= OMAP2_MBOX_BASE + 0x11f,
   + .start  = OMAP24XX_MAILBOX_BASE,
   + .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
 .flags  = IORESOURCE_MEM,
 },
 { @@ -101,6 +103,18 @@ static struct resource mbox_resources[] = {
 .start  = INT_24XX_MAIL_U3_MPU,
 .flags  = IORESOURCE_IRQ,
 },
   +/* FIXME: if multiple architecture support is necessary */
   +#elif  defined(CONFIG_ARCH_OMAP3)
   + {
   + .start  = OMAP34XX_MAILBOX_BASE,
   + .end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
   + .flags  = IORESOURCE_MEM,
   + },
   + {
   + .start  = INT_34XX_MAIL_U0_MPU,
   + .flags  = IORESOURCE_IRQ,
   + },
   +#endif
};

static struct platform_device mbox_device = {
  
  How about setting up omap2_mbox_resources[] and omap3_mbox_resources[]
  above instead? Then just select the right one to use during init.
  
  We should not need to use ifdefs in any of the code for detecting the
  omap cpu type, please use cpu_is_omap24xx() and cpu_is_omap34xx()
  instead.
 
 Agreed and updated as below.

Thanks, since this is a large series, can you please send your series for
RMK to integrate to LAKML? Make sure it also applies against mainline
first :) Please feel free to add my Ack to your patches.

 Also, the latest patchset is available in the git repository at:
 
   http://git.gitorious.org/lk/mainline.git mailbox

Thanks, I've added mirroring for this branch to my kernel.org tree.
Let's wait for ack from RMK before integrating it to l-o.

BTW, we should move dspgateway also into a separate branch like
tidspbridge as it's not in the mainline tree. Do you want to keep the
original for that on your git server too?

Regards,

Tony


 From 7b62c1b04ae50adf2827fb3ca1ec8a3e72349d14 Mon Sep 17 00:00:00 2001
 From: Hiroshi DOYU [EMAIL PROTECTED]
 Date: Sat, 22 Nov 2008 02:28:36 +0200
 Subject: [PATCH 02/10] omap mailbox: add initial omap3 support
 
 Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
 ---
  arch/arm/mach-omap2/devices.c  |   36 +-
  arch/arm/mach-omap2/mailbox.c  |   46 
 ++--
  arch/arm/plat-omap/Kconfig |2 +-
  arch/arm/plat-omap/include/mach/irqs.h |1 +
  arch/arm/plat-omap/include/mach/omap34xx.h |2 +-
  5 files changed, 61 insertions(+), 26 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index 241e418..ea37f37 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -84,13 +84,14 @@ static inline void omap_init_camera(void)
  }
  #endif
  
 -#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
 -#define OMAP2_MBOX_BASE  IO_ADDRESS(OMAP24XX_MAILBOX_BASE)
 +#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
  
 -static struct resource mbox_resources[] = {
 +#define MBOX_REG_SIZE0x120
 +
 +static struct resource omap2_mbox_resources[] = {
   {
 - .start  = OMAP2_MBOX_BASE,
 - .end= OMAP2_MBOX_BASE + 0x11f,
 + .start  = OMAP24XX_MAILBOX_BASE,
 + .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
   .flags  = IORESOURCE_MEM,
   },
   {
 @@ -103,20 +104,39 @@ static struct resource mbox_resources[] = {
   },
  };
  
 +static struct resource omap3_mbox_resources[] = {
 + {
 + 

Re: [PATCH 2/2] OMAP2/3 GPTIMER: skip unnecessary TLDR write during non-autoreload

2008-11-26 Thread Kevin Hilman
Woodruff, Richard [EMAIL PROTECTED] writes:

 * Woodruff, Richard [EMAIL PROTECTED] [081014 12:47]:
 omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load);
   - omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
 omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
}
 
  I seem to recall there was a missed interrupt condition which this worked
 around.
 
  IIRC, the original code didn't bother with the load I added back as a work
 around as a way to get posted mode working.

 Well these seem to be working based on some quick timer tests.
 Pushing so we can verify it ;)

 This kind of change might be better tested on the PM branch.  It's
 the kind of thing more likely to work with PM disabled.  Testing in
 both is good, PM for many things is less forgiving...

I validated these patches on the PM branch.

I used cyclictest to test lots of timer reprogramming, and also tested
in both RET-while-idle and OFF-while-idle for low frequency timer
reprogramming.

Acked-by: Kevin Hilman [EMAIL PROTECTED]


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH][OMAPZOOM][2/2] Disable OV3640 sensor support in omap_zoom2_defconfig file

2008-11-26 Thread Aguilar Pena, Leed
OV3640 smart sensor is not supported on zoom2 platform.

Signed-off-by: Leed Aguilar [EMAIL PROTECTED]
Ack-by: Dominic Curran [EMAIL PROTECTED]
---
 arch/arm/configs/omap_zoom2_defconfig |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/omap_zoom2_defconfig 
b/arch/arm/configs/omap_zoom2_defconfig
index cf73335..fd8377c 100644
--- a/arch/arm/configs/omap_zoom2_defconfig
+++ b/arch/arm/configs/omap_zoom2_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.27-omap1
-# Fri Nov  7 13:16:24 2008
+# Wed Nov 26 12:18:23 2008
 #
 CONFIG_ARM=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
@@ -957,8 +957,7 @@ CONFIG_VIDEO_CAPTURE_DRIVERS=y
 # CONFIG_VIDEO_OV9640 is not set
 # CONFIG_VIDEO_MT9P012 is not set
 # CONFIG_VIDEO_DW9710 is not set
-CONFIG_VIDEO_OV3640=y
-CONFIG_VIDEO_OV3640_CSI2=y
+# CONFIG_VIDEO_OV3640 is not set
 # CONFIG_VIDEO_SAA711X is not set
 # CONFIG_VIDEO_SAA717X is not set
 # CONFIG_VIDEO_TVP5150 is not set
-- 
1.6.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP: MCSPI: Enable mcspi wake-up v2.

2008-11-26 Thread David Brownell
On Wednesday 26 November 2008, Tony Lindgren wrote:
 * Jouni Hogander [EMAIL PROTECTED] [081118 23:48]:
  Currently mcspi wake-ups are not enabled. This might cause case where
  OMAP is not waking up on mcspi events.
 
 Dave, I assume you're picking these for your SPI queue? Will only
 apply to l-o if you ack and tell me so.

OK... I'm not totally caught up there.  Is this needed for
a 2.6.28-final merge?  I'm guessing not; so it'd be OK to
queue for 2.6.29-final and have it in l-o until 29-rc1 gets
pulled down.

- Dave


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] OMAP2/3 GPTIMER: skip unnecessary TLDR write during non-autoreload

2008-11-26 Thread Tony Lindgren
* Kevin Hilman [EMAIL PROTECTED] [081126 10:39]:
 Woodruff, Richard [EMAIL PROTECTED] writes:
 
  * Woodruff, Richard [EMAIL PROTECTED] [081014 12:47]:
  omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load);
- omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
  omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
 }
  
   I seem to recall there was a missed interrupt condition which this worked
  around.
  
   IIRC, the original code didn't bother with the load I added back as a 
   work
  around as a way to get posted mode working.
 
  Well these seem to be working based on some quick timer tests.
  Pushing so we can verify it ;)
 
  This kind of change might be better tested on the PM branch.  It's
  the kind of thing more likely to work with PM disabled.  Testing in
  both is good, PM for many things is less forgiving...
 
 I validated these patches on the PM branch.
 
 I used cyclictest to test lots of timer reprogramming, and also tested
 in both RET-while-idle and OFF-while-idle for low frequency timer
 reprogramming.
 
 Acked-by: Kevin Hilman [EMAIL PROTECTED]

Thanks for testing, pushing them to l-o today and adding to
omap2-upstream queue.

Regards,

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


Re: [PATCH 0/1] Save sram context after changing MPU, DSP or core clocks

2008-11-26 Thread Kevin Hilman
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes:

 This patch saves the sram context again after a MPU,DSP or core clock
 frequency change. This is necessary so the rom code can restore the correct
 DPLL settings when resuming from off mode. Thanks to Rajendra Nayak for
 suggesting the problem and coming up with the same fix at about the same time.


Thanks, pulling into next PM branch.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] PM: Added suspend target state control to debugfs for OMAP3

2008-11-26 Thread Kevin Hilman
Tero Kristo [EMAIL PROTECTED] writes:

 Target state can be read / programmed via files under:
   [debugfs]/pm_debug/[pwrdm]/suspend

 Signed-off-by: Tero Kristo [EMAIL PROTECTED]

Thanks, pulling into next PM branch.

Kevin

 ---
  arch/arm/mach-omap2/pm-debug.c |   30 --
  arch/arm/mach-omap2/pm.h   |4 
  arch/arm/mach-omap2/pm34xx.c   |   24 
  3 files changed, 56 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
 index 82219f4..ac61d15 100644
 --- a/arch/arm/mach-omap2/pm-debug.c
 +++ b/arch/arm/mach-omap2/pm-debug.c
 @@ -26,6 +26,7 @@
  #include linux/clk.h
  #include linux/err.h
  #include linux/io.h
 +#include linux/module.h
  
  #include mach/clock.h
  #include mach/board.h
 @@ -511,11 +512,28 @@ int pm_dbg_regset_init(int reg_set)
   return 0;
  }
  
 -static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 +static int pwrdm_suspend_get(void *data, u64 *val)
 +{
 + *val = omap3_pm_get_suspend_state((struct powerdomain *)data);
 +
 + if (*val = 0)
 + return 0;
 + return *val;
 +}
 +
 +static int pwrdm_suspend_set(void *data, u64 val)
 +{
 + return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
 +}
 +
 +DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get, 
 pwrdm_suspend_set, %llu\n);
 +
 +static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
  {
   int i;
   s64 t;
   struct timespec now;
 + struct dentry *d;
  
   getnstimeofday(now);
   t = timespec_to_ns(now);
 @@ -525,6 +543,14 @@ static int __init pwrdms_setup(struct powerdomain 
 *pwrdm, void *unused)
  
   pwrdm-timer = t;
  
 + if (strncmp(pwrdm-name, dpll, 4) == 0)
 + return 0;
 +
 + d = debugfs_create_dir(pwrdm-name, (struct dentry *)dir);
 +
 + (void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d,
 + (void *)pwrdm, pwrdm_suspend_fops);
 +
   return 0;
  }
  
 @@ -545,7 +571,7 @@ static int __init pm_dbg_init(void)
   (void) debugfs_create_file(time, S_IRUGO,
   d, (void *)DEBUG_FILE_TIMERS, debug_fops);
  
 - pwrdm_for_each(pwrdms_setup, NULL);
 + pwrdm_for_each(pwrdms_setup, (void *)d);
  
   pm_dbg_dir = debugfs_create_dir(registers, d);
   if (IS_ERR(pm_dbg_dir))
 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
 index 4b1ba7c..78fde57 100644
 --- a/arch/arm/mach-omap2/pm.h
 +++ b/arch/arm/mach-omap2/pm.h
 @@ -34,8 +34,12 @@ extern void omap2_block_sleep(void);
  extern void omap2_allow_sleep(void);
  #ifdef CONFIG_ARCH_OMAP3
  extern void omap3_pm_off_mode_enable(int);
 +extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
 +extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
  #else
  #define omap3_pm_off_mode_enable(int) do {} while (0);
 +#define omap3_pm_get_suspend_state(pwrdm) do {} while (0);
 +#define omap3_pm_set_suspend_state(pwrdm,state) do {} while (0);
  #endif
  extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
  
 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 191299c..73ac22c 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -780,6 +780,30 @@ void omap3_pm_off_mode_enable(int enable)
   }
  }
  
 +int omap3_pm_get_suspend_state(struct powerdomain *pwrdm)
 +{
 + struct power_state *pwrst;
 +
 + list_for_each_entry(pwrst, pwrst_list, node) {
 + if (pwrst-pwrdm == pwrdm)
 + return pwrst-next_state;
 + }
 + return -EINVAL;
 +}
 +
 +int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state)
 +{
 + struct power_state *pwrst;
 +
 + list_for_each_entry(pwrst, pwrst_list, node) {
 + if (pwrst-pwrdm == pwrdm) {
 + pwrst-next_state = state;
 + return 0;
 + }
 + }
 + return -EINVAL;
 +}
 +
  static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
  {
   struct power_state *pwrst;
 -- 
 1.5.4.3

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP3: Fixes for suspend / resume GPIO wake-up handling

2008-11-26 Thread Kevin Hilman
Tero Kristo [EMAIL PROTECTED] writes:

 Signed-off-by: Tero Kristo [EMAIL PROTECTED]
 ---
  arch/arm/plat-omap/gpio.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

Thanks, I'll pull this into the next PM branch, and this
can go straight into linux-omap.

Signed-off-by: Kevin Hilman [EMAIL PROTECTED]

 diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
 index f4ec3af..62349fd 100644
 --- a/arch/arm/plat-omap/gpio.c
 +++ b/arch/arm/plat-omap/gpio.c
 @@ -1585,7 +1585,7 @@ static int omap_gpio_suspend(struct sys_device *dev, 
 pm_message_t mesg)
  #endif
  #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
   case METHOD_GPIO_24XX:
 - wake_status = bank-base + OMAP24XX_GPIO_SETWKUENA;
 + wake_status = bank-base + OMAP24XX_GPIO_WAKE_EN;
   wake_clear = bank-base + OMAP24XX_GPIO_CLEARWKUENA;
   wake_set = bank-base + OMAP24XX_GPIO_SETWKUENA;
   break;
 @@ -1608,7 +1608,7 @@ static int omap_gpio_resume(struct sys_device *dev)
  {
   int i;
  
 - if (!cpu_is_omap24xx()  !cpu_is_omap16xx())
 + if (!cpu_class_is_omap2()  !cpu_is_omap16xx())
   return 0;
  
   for (i = 0; i  gpio_bank_count; i++) {
 -- 
 1.5.4.3

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/9] OMAP: HSMMC: Make fclk disable request driven.

2008-11-26 Thread Tony Lindgren
* Adrian Hunter [EMAIL PROTECTED] [081121 01:16]:
 Start idle timer only at the end of request or request like operation
 such card detect, set_ios, probe, or resume. This will ensure the fclk is
 disable quickly after the operation is done, but never too early.

From merging into mainline point of view, maybe this should be merged into
the earlier patch for adding the idle timer?

Tony

 Signed-off-by: Jarkko Lavinen [EMAIL PROTECTED]
 ---
 drivers/mmc/host/omap_hsmmc.c |   15 ++-
 1 files changed, 10 insertions(+), 5 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 2eed691..a134f76 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -122,7 +122,7 @@
   __raw_writel((val), (base) + OMAP_HSMMC_##reg)

 enum {OFF = 0, ON};
 -#define IDLE_TIMEOUT (5*HZ)
 +#define IDLE_TIMEOUT (jiffies_to_msecs(10))

 struct mmc_omap_host {
   struct  device  *dev;
 @@ -165,6 +165,7 @@ static int mmc_omap_fclk_state(struct mmc_omap_host 
 *host, unsigned int state)
   int ret = 0;

   spin_lock_irqsave(host-clk_lock, flags);
 + del_timer(host-idle_timer);
   if (host-fclk_enabled != state) {
   if (state == ON) {
   ret = clk_enable(host-fclk);
 @@ -172,13 +173,9 @@ static int mmc_omap_fclk_state(struct mmc_omap_host 
 *host, unsigned int state)
   goto err_out;

   dev_dbg(mmc_dev(host-mmc), mmc_fclk: enabled\n);
 - /* Revisit: Change the timer bump based on real
 -MMC usage characteristics */
 - mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);
   } else {
   clk_disable(host-fclk);
   dev_dbg(mmc_dev(host-mmc), mmc_fclk: disabled\n);
 - del_timer(host-idle_timer);
   }
   host-fclk_enabled = state;
   }
 @@ -335,6 +332,7 @@ mmc_omap_xfer_done(struct mmc_omap_host *host, struct 
 mmc_data *data)

   if (!data-stop) {
   host-mrq = NULL;
 + mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);
   mmc_request_done(host-mmc, data-mrq);
   return;
   }
 @@ -363,6 +361,7 @@ mmc_omap_cmd_done(struct mmc_omap_host *host, struct 
 mmc_command *cmd)
   }
   if (host-data == NULL || cmd-error) {
   host-mrq = NULL;
 + mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);
   mmc_request_done(host-mmc, cmd-mrq);
   }
 }
 @@ -575,6 +574,7 @@ static void mmc_omap_detect(struct work_struct *work)
   while (OMAP_HSMMC_READ(host-base, SYSCTL)  SRD) ;
   mmc_detect_change(host-mmc, (HZ * 50) / 1000);
   }
 + mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);
 }

 /*
 @@ -874,6 +874,8 @@ static void omap_mmc_set_ios(struct mmc_host *mmc, struct 
 mmc_ios *ios)

   if (ios-power_mode == MMC_POWER_OFF)
   mmc_omap_fclk_state(host, OFF);
 + else
 + mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);
 }

 static int omap_hsmmc_get_cd(struct mmc_host *mmc)
 @@ -1088,6 +1090,7 @@ static int __init omap_mmc_probe(struct platform_device 
 *pdev)
   if (ret  0)
   goto err_cover_switch;
   }
 + mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);

   return 0;

 @@ -1250,6 +1253,8 @@ static int omap_mmc_resume(struct platform_device *pdev)
   ret = mmc_resume_host(host-mmc);
   if (ret == 0)
   host-suspended = 0;
 +
 + mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);
   }

   return ret;
 -- 
 1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/9] OMAP: HSMMC: Make driver support dynamic idle

2008-11-26 Thread Tony Lindgren
* Adrian Hunter [EMAIL PROTECTED] [081121 01:15]:
 Add a timer that is kept active by MMC requests. FCLK is disabled on timeout

Let's keep these patches on hold until we have the hsmmc.c driver in
mainline, then get them integrated via LKML.

Meanwhile, maybe you want to set up a git branch for hsmmc to queue these?
And then I could mirror your hsmmc branch.

Regards,

Tony


 Signed-off-by: Amit Kucheria [EMAIL PROTECTED]
 ---
 drivers/mmc/host/omap_hsmmc.c |   73 +---
 1 files changed, 60 insertions(+), 13 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 0df6841..ee21a64 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -121,6 +121,9 @@
 #define OMAP_HSMMC_WRITE(base, reg, val) \
   __raw_writel((val), (base) + OMAP_HSMMC_##reg)

 +enum {OFF = 0, ON};
 +#define IDLE_TIMEOUT (5*HZ)
 +
 struct mmc_omap_host {
   struct  device  *dev;
   struct  mmc_host*mmc;
 @@ -148,9 +151,50 @@ struct mmc_omap_host {
   int initstr;
   int slot_id;
   int dbclk_enabled;
 +
 + struct timer_list   idle_timer;
 + spinlock_t  clk_lock; /* for changing enabled state */
 + int fclk_enabled:1;
 +
   struct  omap_mmc_platform_data  *pdata;
 };

 +int mmc_omap_fclk_state(struct mmc_omap_host *host, unsigned int state)
 +{
 + unsigned long flags;
 + int ret;
 +
 + spin_lock_irqsave(host-clk_lock, flags);
 + if (host-fclk_enabled != state) {
 + if (state == ON) {
 + if (host-fclk_enabled == OFF) {
 + ret = clk_enable(host-fclk);
 + if (ret != 0)
 + return ret;
 + dev_dbg(mmc_dev(host-mmc),
 + mmc_fclk: enabled\n);
 + }
 + /* Revisit: Change the timer bump based on real
 +MMC usage characteristics */
 + mod_timer(host-idle_timer, jiffies + IDLE_TIMEOUT);
 + } else {
 + clk_disable(host-fclk);
 + dev_dbg(mmc_dev(host-mmc), mmc_fclk: disabled\n);
 + del_timer(host-idle_timer);
 + }
 + host-fclk_enabled = state;
 + }
 + spin_unlock_irqrestore(host-clk_lock, flags);
 + return 0;
 +}
 +
 +static void mmc_omap_idle_timer(unsigned long data)
 +{
 + struct mmc_omap_host *host = (struct mmc_omap_host *) data;
 +
 + mmc_omap_fclk_state(host, OFF);
 +}
 +
 /*
  * Stop clock to the card
  */
 @@ -457,7 +501,7 @@ static int omap_mmc_switch_opcond(struct mmc_omap_host 
 *host, int vdd)
   int ret;

   /* Disable the clocks */
 - clk_disable(host-fclk);
 + mmc_omap_fclk_state(host, OFF);
   clk_disable(host-iclk);
   clk_disable(host-dbclk);

 @@ -471,7 +515,7 @@ static int omap_mmc_switch_opcond(struct mmc_omap_host 
 *host, int vdd)
   if (ret != 0)
   goto err;

 - clk_enable(host-fclk);
 + mmc_omap_fclk_state(host, ON);
   clk_enable(host-iclk);
   clk_enable(host-dbclk);

 @@ -742,10 +786,10 @@ static void omap_mmc_request(struct mmc_host *mmc, 
 struct mmc_request *req)
   WARN_ON(host-mrq != NULL);
   host-mrq = req;
   mmc_omap_prepare_data(host, req);
 + mmc_omap_fclk_state(host, ON);
   mmc_omap_start_command(host, req-cmd, req-data);
 }

 -
 /* Routine to configure clock values. Exposed API to core */
 static void omap_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 {
 @@ -824,6 +868,7 @@ static void omap_mmc_set_ios(struct mmc_host *mmc, struct 
 mmc_ios *ios)
   if (ios-bus_mode == MMC_BUSMODE_OPENDRAIN)
   OMAP_HSMMC_WRITE(host-base, CON,
   OMAP_HSMMC_READ(host-base, CON) | OD);
 +
 }

 static int omap_hsmmc_get_cd(struct mmc_host *mmc)
 @@ -860,7 +905,7 @@ static int __init omap_mmc_probe(struct platform_device 
 *pdev)
   struct mmc_host *mmc;
   struct mmc_omap_host *host = NULL;
   struct resource *res;
 - int ret = 0, irq;
 + int ret = 0, irq, reg;
   u32 hctl, capa;

   if (pdata == NULL) {
 @@ -925,14 +970,17 @@ static int __init omap_mmc_probe(struct platform_device 
 *pdev)
   goto err1;
   }

 - if (clk_enable(host-fclk) != 0) {
 + spin_lock_init(host-clk_lock);
 + setup_timer(host-idle_timer, mmc_omap_idle_timer,
 + (unsigned long) host);
 +
 + if (mmc_omap_fclk_state(host, ON) != 0) {
   clk_put(host-iclk);
   clk_put(host-fclk);
   goto err1;
   }
 -
   if (clk_enable(host-iclk) != 0) {
 - clk_disable(host-fclk);
 + mmc_omap_fclk_state(host, OFF);
   clk_put(host-iclk);

Re: [PATCH] OMAP3: PM: readability fix for IVA2 DPLL autoidle

2008-11-26 Thread Tony Lindgren
* Paul Walmsley [EMAIL PROTECTED] [081125 09:07]:
 On Tue, 25 Nov 2008, Kevin Hilman wrote:
 
  No functional change, just a readability fix.
  
  The symbolic name of the shift value used in writing
  CM_AUTOIDLE_PLL_IVA2 referred values in the CM_CLKSTCTRL_IVA2
  register.  Fix this to use the AUTOIDLE fields.
  
  Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
 
 Acked-by: Paul Walmsley [EMAIL PROTECTED]

Pushing today.

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


Re: [PATCH] Fix crash on non-3430SDP platforms with DVFS/CPUFreq

2008-11-26 Thread Kevin Hilman
Rajendra Nayak [EMAIL PROTECTED] writes:

 The SRF/DVFS + CPUFreq patches had issues booting on
 non-3430SDP platforms as reported by Kevin Hilman.
 This patch puts non-NULL checks in place for mpu_opps/dsp_opps
 /l3_opps before accessing them and fixes the issue.

 This fix/patch can be applied on top of 
 pm-20081119 branch 
 + [PATCH 00/08] OMAP3 SRF: OPP and Frequency resources
 + [PATCH 00/03] OMAP3 PM: CPUFreq driver for OMAP3

Thanks, I'll pull this fix along with the above two series into 
the next PM branch (which should be out later today.)

Kevin

 Signed-off-by: Rajendra Nayak [EMAIL PROTECTED]
 ---
  arch/arm/mach-omap2/clock34xx.c|   33 
 -
  arch/arm/mach-omap2/pm.h   |   18 ---
  arch/arm/mach-omap2/resource34xx.c |   21 ++
  arch/arm/plat-omap/cpu-omap.c  |6 +
  arch/arm/plat-omap/include/mach/omap34xx.h |   18 +++
  5 files changed, 64 insertions(+), 32 deletions(-)

 Index: linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c
 ===
 --- linux-omap-2.6.orig/arch/arm/mach-omap2/clock34xx.c   2008-11-26 
 17:43:12.011090533 +0530
 +++ linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c2008-11-26 
 17:47:40.551795371 +0530
 @@ -666,6 +666,9 @@ void omap2_clk_init_cpufreq_table(struct
   struct omap_opp *prcm;
   int i = 0;
  
 + if (!mpu_opps)
 + return;
 +
   /* Avoid registering the 120% Overdrive with CPUFreq */
   prcm = mpu_opps + MAX_VDD1_OPP - 1;
   for (; prcm-rate; prcm--) {
 @@ -798,20 +801,24 @@ int __init omap2_clk_init(void)
   dpll3_clk = clk_get(NULL, dpll3_m2_ck);
  
   mpu_speed = dpll1_clk-rate;
 - prcm_vdd = mpu_opps + MAX_VDD1_OPP;
 - for (; prcm_vdd-rate; prcm_vdd--) {
 - if (prcm_vdd-rate = mpu_speed) {
 - curr_vdd1_prcm_set = prcm_vdd;
 - break;
 + if (mpu_opps) {
 + prcm_vdd = mpu_opps + MAX_VDD1_OPP;
 + for (; prcm_vdd-rate; prcm_vdd--) {
 + if (prcm_vdd-rate = mpu_speed) {
 + curr_vdd1_prcm_set = prcm_vdd;
 + break;
 + }
   }
   }
  
   core_speed = dpll3_clk-rate;
 - prcm_vdd = l3_opps + MAX_VDD2_OPP;
 - for (; prcm_vdd-rate; prcm_vdd--) {
 - if (prcm_vdd-rate = core_speed) {
 - curr_vdd2_prcm_set = prcm_vdd;
 - break;
 + if (l3_opps) {
 + prcm_vdd = l3_opps + MAX_VDD2_OPP;
 + for (; prcm_vdd-rate; prcm_vdd--) {
 + if (prcm_vdd-rate = core_speed) {
 + curr_vdd2_prcm_set = prcm_vdd;
 + break;
 + }
   }
   }
  
 @@ -878,6 +885,9 @@ static long omap3_round_to_table_rate(st
   if ((clk != virt_vdd1_prcm_set)  (clk != virt_vdd2_prcm_set))
   return -EINVAL;
  
 + if (!mpu_opps || !dsp_opps || !l3_opps)
 + return -EINVAL;
 +
   highest_rate = -EINVAL;
  
   if (clk == virt_vdd1_prcm_set)
 @@ -904,6 +914,9 @@ static int omap3_select_table_rate(struc
   if ((clk != virt_vdd1_prcm_set)  (clk != virt_vdd2_prcm_set))
   return -EINVAL;
  
 + if (!mpu_opps || !dsp_opps || !l3_opps)
 + return -EINVAL;
 +
   if (clk == virt_vdd1_prcm_set) {
   prcm_vdd = mpu_opps + MAX_VDD1_OPP;
   index = MAX_VDD1_OPP;
 Index: linux-omap-2.6/arch/arm/mach-omap2/pm.h
 ===
 --- linux-omap-2.6.orig/arch/arm/mach-omap2/pm.h  2008-11-26 
 17:43:12.011090533 +0530
 +++ linux-omap-2.6/arch/arm/mach-omap2/pm.h   2008-11-26 17:47:40.552795340 
 +0530
 @@ -39,24 +39,6 @@ extern void omap3_pm_off_mode_enable(int
  #endif
  extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
  
 -
 -/* VDD1 OPPS */
 -#define VDD1_OPP10x1
 -#define VDD1_OPP20x2
 -#define VDD1_OPP30x3
 -#define VDD1_OPP40x4
 -#define VDD1_OPP50x5
 -
 -/* VDD2 OPPS */
 -#define VDD2_OPP10x1
 -#define VDD2_OPP20x2
 -#define VDD2_OPP30x3
 -
 -#define MIN_VDD1_OPP VDD1_OPP1
 -#define MAX_VDD1_OPP VDD1_OPP5
 -#define MIN_VDD2_OPP VDD2_OPP1
 -#define MAX_VDD2_OPP VDD2_OPP3
 -
  #ifdef CONFIG_PM_DEBUG
  extern u32 omap2_read_32k_sync_counter(void);
  extern void omap2_pm_dump(int mode, int resume, unsigned int us);
 Index: linux-omap-2.6/arch/arm/mach-omap2/resource34xx.c
 ===
 --- linux-omap-2.6.orig/arch/arm/mach-omap2/resource34xx.c2008-11-26 
 17:43:12.011090533 +0530
 +++ linux-omap-2.6/arch/arm/mach-omap2/resource34xx.c 2008-11-26 
 18:16:28.376582736 +0530
 @@ -144,6 +144,10 @@ static struct device dummy_dsp_dev;
  void init_opp(struct 

Re: [PATCH] Add OMAP2 camera driver

2008-11-26 Thread Hans Verkuil
On Wednesday 26 November 2008 19:44:51 Trilok Soni wrote:
 This patch was living at linux-omap GIT tree from long time and seem
 to survive the testing. It is also used in N800/N810 Internet Tablet.
 Sakari Ailus can give more information about this. I am not able to
 submit this patch as inline one due to my git-send-email
 configuration with Gmail.

Hi Trilok,

I found a few problems with this patch:

1) The makefile isn't right: it compiles omap24xxcam.c and 
omap24xxcam-dma.c as two modules, but I suspect you want only one since 
the symbols that omap24xxcam.c needs from omap24xxcam-dma.c are not 
exported. See e.g. the msp3400 driver in the Makefile for how to do it.

2) The Kconfig is probably missing a ARCH_OMAP dependency (sounds 
reasonable, at least), so now it also compiles for the i686 but that 
architecture doesn't have a clk_get function.

3) I was wondering whether Sakari also wants to add a Signed-off-by 
line? Looking at the comments it seems that he was involved as well.

4) I get a bunch of compile warnings (admittedly when compiling for 
i686) that you might want to look at. Compiled against the 2.6.27 
kernel with gcc-4.3.1. It might be bogus since I didn't compile for the 
omap architecture.

  CC [M]  /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.o
In file included 
from /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.c:42:
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In 
function 'omap24xxcam_reg_in':
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:549: warning: passing 
argument 1 of 'readl' makes pointer from integer without a cast
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In 
function 'omap24xxcam_reg_out':
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:555: warning: passing 
argument 2 of 'writel' makes pointer from integer without a cast
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In 
function 'omap24xxcam_reg_merge':
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:563: warning: passing 
argument 1 of 'readl' makes pointer from integer without a cast
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:565: warning: passing 
argument 2 of 'writel' makes pointer from integer without a cast
  CC [M]  /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.o
In file included 
from /home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c:32:
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In 
function 'omap24xxcam_reg_in':
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:549: warning: passing 
argument 1 of 'readl' makes pointer from integer without a cast
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In 
function 'omap24xxcam_reg_out':
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:555: warning: passing 
argument 2 of 'writel' makes pointer from integer without a cast
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h: In 
function 'omap24xxcam_reg_merge':
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:563: warning: passing 
argument 1 of 'readl' makes pointer from integer without a cast
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam.h:565: warning: passing 
argument 2 of 'writel' makes pointer from integer without a cast
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c: In 
function 'omap24xxcam_dma_hwinit':
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c:357: warning: 
passing argument 1 of '_spin_lock_irqsave' discards qualifiers from 
pointer target type
/home/hans/work/src/v4l/v4l-dvb/v4l/omap24xxcam-dma.c:361: warning: 
passing argument 1 of '_spin_unlock_irqrestore' discards qualifiers 
from pointer target type


Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread Koen Kooi


Op 26 nov 2008, om 21:07 heeft Mark Brown het volgende geschreven:


On Wed, Nov 26, 2008 at 10:34:41AM -0800, David Brownell wrote:


Re TWL4030 codec configuration ... I count three microphone
input channels not used on Beagle, plus a speaker output
and some other stuff.  So it's obvious that something which
works on Beagle won't handle more interesting configurations
of that audio support.


Can someone post an overview of what the hardware configurations of
these boards are, please?  It's starting to sound like they're not  
very

similar at all.


On the codec level all these board use a variant of the TWL4030. The  
variants differ slightly in what kind of extra goodies they provide.  
On the board level not every feature of the TWL familiy is used, the  
beagle only analog in and analog out, the overo exposes more  
interfaces, etc.


Other people can fill in the details, but these are the differences I  
can think of.


regards,

Koen 


PGP.sig
Description: This is a digitally signed message part


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread David Brownell
On Wednesday 26 November 2008, Mark Brown wrote:
 Can someone post an overview of what the hardware configurations of
 these boards are, please?  It's starting to sound like they're not very
 similar at all.

I only have schematics for Beagle ... which makes VERY minimal
use of the twl4030 audio capabilities:

 - stereo headset output, without its mic
 - stereo aux-in

Other twl4030 family boards *could* have:

 - microphone input for that headset
 - stereo hands-off speakers
 - mono earpiece output
 - two other microphone input channels

And maybe more; that's just me summarizing unconnected pins,
not the datasheet.  There are also cost-reduced parts with
less audio capability.

I make no claim about audio expertise -- the nearest I come
to it is observing a few years back that there was a huge
framework hole, which ASoC seems to fill -- but I wonder if
it shouldn't suffice just to provide a mask of capabilities
that are wired up on a given board.

- Dave

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread David Brownell
On Wednesday 26 November 2008, Mark Brown wrote:
  I'm told that the ASoC stuff should go in a separate ASoC
  area for some reason.  That still makes no good sense to me,
  so if there's a brief explanation as to why it's done that
  way, please fling me a URL.  :)
 
 The move is in the direction you want but we're not there yet.  The fact
 that things are now decomposed enough for us to be able to think about
 it is a good sign here.
 
 The biggest part of it is that the degree of coupling between the
 various ASoC components is high - this is particularly obvious with v1
 where the entire card is probed at once.  This includes coupling between
 the drivers and the core where the degree of churn is very high right
 now due to v2 merging.  It doesn't feel right to give architectures an
 API that they can't rely on from one merge window to the next yet,

OK, that seems to be the key point.  And it makes a lot of sense;
I wouldn't call the driver structure here simple, so it deserves
some iteration on multiple disparate hardware platforms just to make
sure the interfaces is adequate to the problem.

Let me insert a minor plug from the PM perspective that it would be
good to find a way that the codecs can sit in the proper places in
the driver model tree.  Example with twl4030:  it's an I2C device
and thus should be a child of something like

   /sys/devices/platform/i2c_omap.1/i2c-adapter/i2c-1/1-0049

to guarantee that for example nothing touches that codec after its
parent I2C controller gets suspended.

- Dave


 partly from the point of view of isolating the code for review purposes
 and also due to the merge issues which would doubtless crop up.
 
 Another part of it is that some machine drivers can get involved enough
 to sit on or cross the boundary from platform data to being drivers for
 substantial distinct hardware but that's very much not the case for
 everything.
 
 I've been spending time this week working on getting the ability to load
 platform and codec drivers independantly merged.  That will at least
 allow the instantiation of the ASoC drivers for those to be pushed out
 into the architecture code, which is a start and should substantially
 reduce the size of most machine drivers.  At the point where that's been
 done it's probably worth looking again at the simpler machine drivers.
 


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[patch 2.6.28-rc6-omap] twl4030-power: minor cleanup

2008-11-26 Thread David Brownell
From: David Brownell [EMAIL PROTECTED]

Minor cleanups to the twl4030 power script support:  move its
init code out of the add children call (it adds no children!),
and move the power bus messages earlier in the header file to
unclutter the platform data section and since they're not used
only for those scripts.

Signed-off-by: David Brownell [EMAIL PROTECTED]
---
 drivers/mfd/twl4030-core.c  |7 +--
 include/linux/i2c/twl4030.h |   94 +-
 2 files changed, 53 insertions(+), 48 deletions(-)

--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -503,9 +503,6 @@ add_children(struct twl4030_platform_dat
return PTR_ERR(child);
}
 
-   if (twl_has_power()  pdata-power)
-   twl4030_power_init(pdata-power);
-
if (twl_has_rtc()) {
/*
 * REVISIT platform_data here currently might expose the
@@ -788,6 +785,10 @@ twl4030_probe(struct i2c_client *client,
/* setup clock framework */
clocks_init();
 
+   /* load power event scripts */
+   if (twl_has_power()  pdata-power)
+   twl4030_power_init(pdata-power);
+
/* Maybe init the T2 Interrupt subsystem */
if (client-irq
 pdata-irq_base
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -168,7 +168,7 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
 /*--*/
 
 /*
- * Multichannel ADC register offsets (use TWL4030_MODULE_MADC)
+ * Monitoring ADC register offsets (use TWL4030_MODULE_MADC)
  * ... SIH/interrupt only
  */
 
@@ -218,6 +218,53 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
 
 /*--*/
 
+/* Power bus message definitions */
+
+#define DEV_GRP_NULL   0x0
+#define DEV_GRP_P1 0x1
+#define DEV_GRP_P2 0x2
+#define DEV_GRP_P3 0x4
+
+#define RES_GRP_RES0x0
+#define RES_GRP_PP 0x1
+#define RES_GRP_RC 0x2
+#define RES_GRP_PP_RC  0x3
+#define RES_GRP_PR 0x4
+#define RES_GRP_PP_PR  0x5
+#define RES_GRP_RC_PR  0x6
+#define RES_GRP_ALL0x7
+
+#define RES_TYPE2_R0   0x0
+
+#define RES_TYPE_ALL   0x7
+
+#define RES_STATE_WRST 0xF
+#define RES_STATE_ACTIVE   0xE
+#define RES_STATE_SLEEP0x8
+#define RES_STATE_OFF  0x0
+
+/*
+ * Power Bus Message Format ... these can be sent individually by Linux,
+ * but are usually part of downloaded scripts that are run when various
+ * power events are triggered.
+ *
+ *  Broadcast Message (16 Bits):
+ *DEV_GRP[15:13] MT[12]  RES_GRP[11:9]  RES_TYPE2[8:7] RES_TYPE[6:4]
+ *RES_STATE[3:0]
+ *
+ *  Singular Message (16 Bits):
+ *DEV_GRP[15:13] MT[12]  RES_ID[11:4]  RES_STATE[3:0]
+ */
+
+#define MSG_BROADCAST(devgrp, grp, type, type2, state) \
+   ( (devgrp)  13 | 1  12 | (grp)  9 | (type2)  7 \
+   | (type)  4 | (state))
+
+#define MSG_SINGULAR(devgrp, id, state) \
+   ((devgrp)  13 | 0  12 | (id)  4 | (state))
+
+/*--*/
+
 struct twl4030_bci_platform_data {
int *battery_tmp_tbl;
unsigned int tblsize;
@@ -281,60 +328,17 @@ struct twl4030_script {
struct twl4030_ins *script;
unsigned size;
u8 flags;
-};
 #define TRITON_WRST_SCRIPT (10)
 #define TRITON_WAKEUP12_SCRIPT (11)
 #define TRITON_WAKEUP3_SCRIPT  (12)
 #define TRITON_SLEEP_SCRIPT(13)
+};
 
 struct twl4030_power_data {
struct twl4030_script **scripts;
unsigned size;
 };
 
-/* Power bus message definitions */
-
-#define DEV_GRP_NULL   0x0
-#define DEV_GRP_P1 0x1
-#define DEV_GRP_P2 0x2
-#define DEV_GRP_P3 0x4
-
-#define RES_GRP_RES0x0
-#define RES_GRP_PP 0x1
-#define RES_GRP_RC 0x2
-#define RES_GRP_PP_RC  0x3
-#define RES_GRP_PR 0x4
-#define RES_GRP_PP_PR  0x5
-#define RES_GRP_RC_PR  0x6
-#define RES_GRP_ALL0x7
-
-#define RES_TYPE2_R0   0x0
-
-#define RES_TYPE_ALL   0x7
-
-#define RES_STATE_WRST 0xF
-#define RES_STATE_ACTIVE   0xE
-#define RES_STATE_SLEEP0x8
-#define RES_STATE_OFF  0x0
-
-/*
-*  Power Bus Message Format
-*
-*  Broadcast Message (16 Bits)
-*  DEV_GRP[15:13] MT[12]  RES_GRP[11:9]  RES_TYPE2[8:7] RES_TYPE[6:4]
-*  RES_STATE[3:0]
-*
-*  Singular Message (16 Bits)
-*  DEV_GRP[15:13] MT[12]  RES_ID[11:4]  RES_STATE[3:0]
-*
-*/
-
-#define MSG_BROADCAST(devgrp, grp, type, type2, state) \
-   (devgrp  13 | 1  12 | grp  9 | type2  7 | type  4 | state)
-
-#define MSG_SINGULAR(devgrp, id, state) \
-   (devgrp  13 | 0  12 | id  4 | state)
-
 struct twl4030_platform_data {
unsigned   

[patch 2.6.28-rc6-omap] twl4030: linkage fix for generic power scripts

2008-11-26 Thread David Brownell
From: David Brownell [EMAIL PROTECTED]

Section fixes for generic twl4030 power scripts.

NOTE:  doesn't fix the bug whereby Beagle won't reset when
these scripts are loaded.  Or fix SDP section warnings.

Signed-off-by: David Brownell [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/board-omap3beagle.c   |2 +-
 arch/arm/mach-omap2/board-omap3evm.c  |2 +-
 arch/arm/mach-omap2/board-overo.c |2 +-
 arch/arm/mach-omap2/twl4030-generic-scripts.c |3 +++
 arch/arm/mach-omap2/twl4030-generic-scripts.h |5 +
 5 files changed, 11 insertions(+), 3 deletions(-)

--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -206,7 +206,7 @@ static struct twl4030_platform_data beag
/* platform_data for children goes here */
.usb= beagle_usb_data,
.gpio   = beagle_gpio_data,
-   .power  = generic3430_t2scripts_data,
+   .power  = GENERIC3430_T2SCRIPTS_DATA,
.vmmc1  = beagle_vmmc1,
.vsim   = beagle_vsim,
.vdac   = beagle_vdac,
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -139,7 +139,7 @@ static struct twl4030_platform_data omap
.keypad = omap3evm_kp_data,
.madc   = omap3evm_madc_data,
.usb= omap3evm_usb_data,
-   .power  = generic3430_t2scripts_data,
+   .power  = GENERIC3430_T2SCRIPTS_DATA,
.gpio   = omap3evm_gpio_data,
 };
 
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -162,7 +162,7 @@ static struct twl4030_platform_data over
.irq_end= TWL4030_IRQ_END,
.gpio   = overo_gpio_data,
.usb= overo_usb_data,
-   .power  = generic3430_t2scripts_data,
+   .power  = GENERIC3430_T2SCRIPTS_DATA,
 };
 
 static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
--- a/arch/arm/mach-omap2/twl4030-generic-scripts.c
+++ b/arch/arm/mach-omap2/twl4030-generic-scripts.c
@@ -23,6 +23,8 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#ifdef CONFIG_TWL4030_POWER
+
 #include linux/kernel.h
 #include linux/device.h
 #include linux/init.h
@@ -76,3 +78,4 @@ struct twl4030_power_data generic3430_t2
 };
 
 
+#endif /* CONFIG_TWL4030_POWER */
--- a/arch/arm/mach-omap2/twl4030-generic-scripts.h
+++ b/arch/arm/mach-omap2/twl4030-generic-scripts.h
@@ -3,6 +3,11 @@
 
 #include linux/i2c/twl4030.h
 
+#ifdef CONFIG_TWL4030_POWER
 extern struct twl4030_power_data generic3430_t2scripts_data;
+#define GENERIC3430_T2SCRIPTS_DATA generic3430_t2scripts_data
+#else
+#define GENERIC3430_T2SCRIPTS_DATA NULL
+#endif /* CONFIG_TWL4030_POWER */
 
 #endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread Mark Brown
On Wed, Nov 26, 2008 at 12:33:12PM -0800, David Brownell wrote:

 And maybe more; that's just me summarizing unconnected pins,
 not the datasheet.  There are also cost-reduced parts with
 less audio capability.

...

 I make no claim about audio expertise -- the nearest I come
 to it is observing a few years back that there was a huge
 framework hole, which ASoC seems to fill -- but I wonder if
 it shouldn't suffice just to provide a mask of capabilities
 that are wired up on a given board.

It's possible - if the differences can be handled by marking some pins
as connected or disconnected and possible specifying a different system
clock rate to the chip then that approach was what I was expecting.
If there is more substantial differences such as having the clocking
arranged differently then separate drivers start to make more sense.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP general SOC driver.

2008-11-26 Thread Mark Brown
On Wed, Nov 26, 2008 at 12:44:33PM -0800, David Brownell wrote:

 Let me insert a minor plug from the PM perspective that it would be
 good to find a way that the codecs can sit in the proper places in
 the driver model tree.  Example with twl4030:  it's an I2C device
 and thus should be a child of something like

This is exactly what I'm saying about allowing the machine, codec and
platform drivers to probe separately.  It's the major benefit of v2.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP3: Fixes for suspend / resume GPIO wake-up handling

2008-11-26 Thread Tony Lindgren
* Kevin Hilman [EMAIL PROTECTED] [081126 10:56]:
 Tero Kristo [EMAIL PROTECTED] writes:
 
  Signed-off-by: Tero Kristo [EMAIL PROTECTED]
  ---
   arch/arm/plat-omap/gpio.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
 Thanks, I'll pull this into the next PM branch, and this
 can go straight into linux-omap.

 Signed-off-by: Kevin Hilman [EMAIL PROTECTED]

Pushing to l-o and adding to omap-fixes queue.

Tony


  diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
  index f4ec3af..62349fd 100644
  --- a/arch/arm/plat-omap/gpio.c
  +++ b/arch/arm/plat-omap/gpio.c
  @@ -1585,7 +1585,7 @@ static int omap_gpio_suspend(struct sys_device *dev, 
  pm_message_t mesg)
   #endif
   #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
  case METHOD_GPIO_24XX:
  -   wake_status = bank-base + OMAP24XX_GPIO_SETWKUENA;
  +   wake_status = bank-base + OMAP24XX_GPIO_WAKE_EN;
  wake_clear = bank-base + OMAP24XX_GPIO_CLEARWKUENA;
  wake_set = bank-base + OMAP24XX_GPIO_SETWKUENA;
  break;
  @@ -1608,7 +1608,7 @@ static int omap_gpio_resume(struct sys_device *dev)
   {
  int i;
   
  -   if (!cpu_is_omap24xx()  !cpu_is_omap16xx())
  +   if (!cpu_class_is_omap2()  !cpu_is_omap16xx())
  return 0;
   
  for (i = 0; i  gpio_bank_count; i++) {
  -- 
  1.5.4.3
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-omap in
  the body of a message to [EMAIL PROTECTED]
  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 [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch 2.6.28-rc6-omap] twl4030: linkage fix for generic power scripts

2008-11-26 Thread Tony Lindgren
* David Brownell [EMAIL PROTECTED] [081126 13:09]:
 From: David Brownell [EMAIL PROTECTED]
 
 Section fixes for generic twl4030 power scripts.
 
 NOTE:  doesn't fix the bug whereby Beagle won't reset when
 these scripts are loaded.  Or fix SDP section warnings.

Pushing to l-o tree.

Tony


 Signed-off-by: David Brownell [EMAIL PROTECTED]
 ---
  arch/arm/mach-omap2/board-omap3beagle.c   |2 +-
  arch/arm/mach-omap2/board-omap3evm.c  |2 +-
  arch/arm/mach-omap2/board-overo.c |2 +-
  arch/arm/mach-omap2/twl4030-generic-scripts.c |3 +++
  arch/arm/mach-omap2/twl4030-generic-scripts.h |5 +
  5 files changed, 11 insertions(+), 3 deletions(-)
 
 --- a/arch/arm/mach-omap2/board-omap3beagle.c
 +++ b/arch/arm/mach-omap2/board-omap3beagle.c
 @@ -206,7 +206,7 @@ static struct twl4030_platform_data beag
   /* platform_data for children goes here */
   .usb= beagle_usb_data,
   .gpio   = beagle_gpio_data,
 - .power  = generic3430_t2scripts_data,
 + .power  = GENERIC3430_T2SCRIPTS_DATA,
   .vmmc1  = beagle_vmmc1,
   .vsim   = beagle_vsim,
   .vdac   = beagle_vdac,
 --- a/arch/arm/mach-omap2/board-omap3evm.c
 +++ b/arch/arm/mach-omap2/board-omap3evm.c
 @@ -139,7 +139,7 @@ static struct twl4030_platform_data omap
   .keypad = omap3evm_kp_data,
   .madc   = omap3evm_madc_data,
   .usb= omap3evm_usb_data,
 - .power  = generic3430_t2scripts_data,
 + .power  = GENERIC3430_T2SCRIPTS_DATA,
   .gpio   = omap3evm_gpio_data,
  };
  
 --- a/arch/arm/mach-omap2/board-overo.c
 +++ b/arch/arm/mach-omap2/board-overo.c
 @@ -162,7 +162,7 @@ static struct twl4030_platform_data over
   .irq_end= TWL4030_IRQ_END,
   .gpio   = overo_gpio_data,
   .usb= overo_usb_data,
 - .power  = generic3430_t2scripts_data,
 + .power  = GENERIC3430_T2SCRIPTS_DATA,
  };
  
  static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
 --- a/arch/arm/mach-omap2/twl4030-generic-scripts.c
 +++ b/arch/arm/mach-omap2/twl4030-generic-scripts.c
 @@ -23,6 +23,8 @@
   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
   */
  
 +#ifdef CONFIG_TWL4030_POWER
 +
  #include linux/kernel.h
  #include linux/device.h
  #include linux/init.h
 @@ -76,3 +78,4 @@ struct twl4030_power_data generic3430_t2
  };
  
  
 +#endif /* CONFIG_TWL4030_POWER */
 --- a/arch/arm/mach-omap2/twl4030-generic-scripts.h
 +++ b/arch/arm/mach-omap2/twl4030-generic-scripts.h
 @@ -3,6 +3,11 @@
  
  #include linux/i2c/twl4030.h
  
 +#ifdef CONFIG_TWL4030_POWER
  extern struct twl4030_power_data generic3430_t2scripts_data;
 +#define GENERIC3430_T2SCRIPTS_DATA generic3430_t2scripts_data
 +#else
 +#define GENERIC3430_T2SCRIPTS_DATA NULL
 +#endif /* CONFIG_TWL4030_POWER */
  
  #endif
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch 2.6.28-rc6-omap] twl4030-power: minor cleanup

2008-11-26 Thread Tony Lindgren
* David Brownell [EMAIL PROTECTED] [081126 13:09]:
 From: David Brownell [EMAIL PROTECTED]
 
 Minor cleanups to the twl4030 power script support:  move its
 init code out of the add children call (it adds no children!),
 and move the power bus messages earlier in the header file to
 unclutter the platform data section and since they're not used
 only for those scripts.

Pushing to l-o tree.

Tony

 Signed-off-by: David Brownell [EMAIL PROTECTED]
 ---
  drivers/mfd/twl4030-core.c  |7 +--
  include/linux/i2c/twl4030.h |   94 +-
  2 files changed, 53 insertions(+), 48 deletions(-)
 
 --- a/drivers/mfd/twl4030-core.c
 +++ b/drivers/mfd/twl4030-core.c
 @@ -503,9 +503,6 @@ add_children(struct twl4030_platform_dat
   return PTR_ERR(child);
   }
  
 - if (twl_has_power()  pdata-power)
 - twl4030_power_init(pdata-power);
 -
   if (twl_has_rtc()) {
   /*
* REVISIT platform_data here currently might expose the
 @@ -788,6 +785,10 @@ twl4030_probe(struct i2c_client *client,
   /* setup clock framework */
   clocks_init();
  
 + /* load power event scripts */
 + if (twl_has_power()  pdata-power)
 + twl4030_power_init(pdata-power);
 +
   /* Maybe init the T2 Interrupt subsystem */
   if (client-irq
pdata-irq_base
 --- a/include/linux/i2c/twl4030.h
 +++ b/include/linux/i2c/twl4030.h
 @@ -168,7 +168,7 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
  /*--*/
  
  /*
 - * Multichannel ADC register offsets (use TWL4030_MODULE_MADC)
 + * Monitoring ADC register offsets (use TWL4030_MODULE_MADC)
   * ... SIH/interrupt only
   */
  
 @@ -218,6 +218,53 @@ int twl4030_i2c_read(u8 mod_no, u8 *valu
  
  /*--*/
  
 +/* Power bus message definitions */
 +
 +#define DEV_GRP_NULL 0x0
 +#define DEV_GRP_P1   0x1
 +#define DEV_GRP_P2   0x2
 +#define DEV_GRP_P3   0x4
 +
 +#define RES_GRP_RES  0x0
 +#define RES_GRP_PP   0x1
 +#define RES_GRP_RC   0x2
 +#define RES_GRP_PP_RC0x3
 +#define RES_GRP_PR   0x4
 +#define RES_GRP_PP_PR0x5
 +#define RES_GRP_RC_PR0x6
 +#define RES_GRP_ALL  0x7
 +
 +#define RES_TYPE2_R0 0x0
 +
 +#define RES_TYPE_ALL 0x7
 +
 +#define RES_STATE_WRST   0xF
 +#define RES_STATE_ACTIVE 0xE
 +#define RES_STATE_SLEEP  0x8
 +#define RES_STATE_OFF0x0
 +
 +/*
 + * Power Bus Message Format ... these can be sent individually by Linux,
 + * but are usually part of downloaded scripts that are run when various
 + * power events are triggered.
 + *
 + *  Broadcast Message (16 Bits):
 + *DEV_GRP[15:13] MT[12]  RES_GRP[11:9]  RES_TYPE2[8:7] RES_TYPE[6:4]
 + *RES_STATE[3:0]
 + *
 + *  Singular Message (16 Bits):
 + *DEV_GRP[15:13] MT[12]  RES_ID[11:4]  RES_STATE[3:0]
 + */
 +
 +#define MSG_BROADCAST(devgrp, grp, type, type2, state) \
 + ( (devgrp)  13 | 1  12 | (grp)  9 | (type2)  7 \
 + | (type)  4 | (state))
 +
 +#define MSG_SINGULAR(devgrp, id, state) \
 + ((devgrp)  13 | 0  12 | (id)  4 | (state))
 +
 +/*--*/
 +
  struct twl4030_bci_platform_data {
   int *battery_tmp_tbl;
   unsigned int tblsize;
 @@ -281,60 +328,17 @@ struct twl4030_script {
   struct twl4030_ins *script;
   unsigned size;
   u8 flags;
 -};
  #define TRITON_WRST_SCRIPT   (10)
  #define TRITON_WAKEUP12_SCRIPT   (11)
  #define TRITON_WAKEUP3_SCRIPT(12)
  #define TRITON_SLEEP_SCRIPT  (13)
 +};
  
  struct twl4030_power_data {
   struct twl4030_script **scripts;
   unsigned size;
  };
  
 -/* Power bus message definitions */
 -
 -#define DEV_GRP_NULL 0x0
 -#define DEV_GRP_P1   0x1
 -#define DEV_GRP_P2   0x2
 -#define DEV_GRP_P3   0x4
 -
 -#define RES_GRP_RES  0x0
 -#define RES_GRP_PP   0x1
 -#define RES_GRP_RC   0x2
 -#define RES_GRP_PP_RC0x3
 -#define RES_GRP_PR   0x4
 -#define RES_GRP_PP_PR0x5
 -#define RES_GRP_RC_PR0x6
 -#define RES_GRP_ALL  0x7
 -
 -#define RES_TYPE2_R0 0x0
 -
 -#define RES_TYPE_ALL 0x7
 -
 -#define RES_STATE_WRST   0xF
 -#define RES_STATE_ACTIVE 0xE
 -#define RES_STATE_SLEEP  0x8
 -#define RES_STATE_OFF0x0
 -
 -/*
 -*Power Bus Message Format
 -*
 -*Broadcast Message (16 Bits)
 -*DEV_GRP[15:13] MT[12]  RES_GRP[11:9]  RES_TYPE2[8:7] RES_TYPE[6:4]
 -*RES_STATE[3:0]
 -*
 -*Singular Message (16 Bits)
 -*DEV_GRP[15:13] MT[12]  RES_ID[11:4]  RES_STATE[3:0]
 -*
 -*/
 -
 -#define MSG_BROADCAST(devgrp, grp, type, type2, state) \
 - (devgrp  13 | 

[PATCH] ARM: OMAP: Remove broken LCD driver for SX1

2008-11-26 Thread Tony Lindgren
From 7953031da4200323ab5d85bd514054ca4ba9d225 Mon Sep 17 00:00:00 2001
From: Tony Lindgren [EMAIL PROTECTED]
Date: Mon, 24 Nov 2008 18:11:16 -0800
Subject: [PATCH] ARM: OMAP: Remove broken LCD driver for SX1

Recently the omap McBSP code was cleaned up to get rid of
direct McBSP register tinkering by the drivers. Looks like
lcd_sx1.c never got converted, and now it breaks builds.

It seems the lcd_sx1.c driver is attempting SPI mode, but
doing it in a different way compared to omap_mcbsp_set_spi_mode().

Remove the broken driver, patches welcome to add it back when
done properly by patching both mcbsp.c and lcd_sx1.c.

Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
 drivers/video/omap/Makefile  |1 -
 drivers/video/omap/lcd_sx1.c |  327 --
 2 files changed, 0 insertions(+), 328 deletions(-)
 delete mode 100644 drivers/video/omap/lcd_sx1.c

diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 99da8b6..ed13889 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -23,7 +23,6 @@ objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
 objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
 objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
 objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
-objs-y$(CONFIG_MACH_SX1) += lcd_sx1.o
 
 omapfb-objs := $(objs-yy)
 
diff --git a/drivers/video/omap/lcd_sx1.c b/drivers/video/omap/lcd_sx1.c
deleted file mode 100644
index e55de20..000
--- a/drivers/video/omap/lcd_sx1.c
+++ /dev/null
@@ -1,327 +0,0 @@
-/*
- * LCD panel support for the Siemens SX1 mobile phone
- *
- * Current version : [EMAIL PROTECTED], great help from FCA0
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/io.h
-
-#include mach/gpio.h
-#include mach/omapfb.h
-#include mach/mcbsp.h
-#include mach/mux.h
-
-/*
- * OMAP310 GPIO registers
- */
-#define GPIO_DATA_INPUT0xfffce000
-#define GPIO_DATA_OUTPUT   0xfffce004
-#define GPIO_DIR_CONTROL   0xfffce008
-#define GPIO_INT_CONTROL   0xfffce00c
-#define GPIO_INT_MASK  0xfffce010
-#define GPIO_INT_STATUS0xfffce014
-#define GPIO_PIN_CONTROL   0xfffce018
-
-
-#define A_LCD_SSC_RD   3
-#define A_LCD_SSC_SD   7
-#define _A_LCD_RESET   9
-#define _A_LCD_SSC_CS  12
-#define _A_LCD_SSC_A0  13
-
-#define DSP_REG0xE1017024
-
-const unsigned char INIT_1[12] = {
-   0x1C, 0x02, 0x88, 0x00, 0x1E, 0xE0, 0x00, 0xDC, 0x00, 0x02, 0x00
-};
-
-const unsigned char INIT_2[127] = {
-   0x15, 0x00, 0x29, 0x00, 0x3E, 0x00, 0x51, 0x00,
-   0x65, 0x00, 0x7A, 0x00, 0x8D, 0x00, 0xA1, 0x00,
-   0xB6, 0x00, 0xC7, 0x00, 0xD8, 0x00, 0xEB, 0x00,
-   0xFB, 0x00, 0x0B, 0x01, 0x1B, 0x01, 0x27, 0x01,
-   0x34, 0x01, 0x41, 0x01, 0x4C, 0x01, 0x55, 0x01,
-   0x5F, 0x01, 0x68, 0x01, 0x70, 0x01, 0x78, 0x01,
-   0x7E, 0x01, 0x86, 0x01, 0x8C, 0x01, 0x94, 0x01,
-   0x9B, 0x01, 0xA1, 0x01, 0xA4, 0x01, 0xA9, 0x01,
-   0xAD, 0x01, 0xB2, 0x01, 0xB7, 0x01, 0xBC, 0x01,
-   0xC0, 0x01, 0xC4, 0x01, 0xC8, 0x01, 0xCB, 0x01,
-   0xCF, 0x01, 0xD2, 0x01, 0xD5, 0x01, 0xD8, 0x01,
-   0xDB, 0x01, 0xE0, 0x01, 0xE3, 0x01, 0xE6, 0x01,
-   0xE8, 0x01, 0xEB, 0x01, 0xEE, 0x01, 0xF1, 0x01,
-   0xF3, 0x01, 0xF8, 0x01, 0xF9, 0x01, 0xFC, 0x01,
-   0x00, 0x02, 0x03, 0x02, 0x07, 0x02, 0x09, 0x02,
-   0x0E, 0x02, 0x13, 0x02, 0x1C, 0x02, 0x00
-};
-
-const unsigned char INIT_3[15] = {
-   0x14, 0x26, 0x33, 0x3D, 0x45, 0x4D, 0x53, 0x59,
-   0x5E, 0x63, 0x67, 0x6D, 0x71, 0x78, 0xFF
-};
-
-static void epson_sendbyte(int flag, unsigned char byte)
-{
-   int i, shifter = 0x80;
-
-   if (!flag)
-   gpio_set_value(_A_LCD_SSC_A0, 0);
-   mdelay(2);
-   gpio_set_value(A_LCD_SSC_RD, 1);
-
-   gpio_set_value(A_LCD_SSC_SD, flag);
-
-   OMAP_MCBSP_WRITE(OMAP1510_MCBSP3_BASE, PCR0, 0x2200);
-   OMAP_MCBSP_WRITE(OMAP1510_MCBSP3_BASE, PCR0, 0x2202);
-   for (i = 0; i  8; i++) {
-   OMAP_MCBSP_WRITE(OMAP1510_MCBSP3_BASE, PCR0, 0x2200);
-   gpio_set_value(A_LCD_SSC_SD, shifter  byte);
-

[PATCH] ARM: OMAP: Typo fix for clock_allow_idle

2008-11-26 Thread Tony Lindgren
From 147dcf5489fb86c4bfe400520186f9f11b304783 Mon Sep 17 00:00:00 2001
From: Amit Kucheria [EMAIL PROTECTED]
Date: Tue, 25 Nov 2008 15:11:12 -0800
Subject: [PATCH] ARM: OMAP: Typo fix for clock_allow_idle

The second clk_deny_idle instance should be clk_allow_idle instead.

Signed-off-by: Amit Kucheria [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
 arch/arm/plat-omap/include/mach/pm.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/mach/pm.h 
b/arch/arm/plat-omap/include/mach/pm.h
index 768eb6e..2a9c27a 100644
--- a/arch/arm/plat-omap/include/mach/pm.h
+++ b/arch/arm/plat-omap/include/mach/pm.h
@@ -128,7 +128,7 @@ void clk_deny_idle(struct clk *clk);
  * clk_allow_idle - Counters previous clk_deny_idle
  * @clk: clock signal handle
  */
-void clk_deny_idle(struct clk *clk);
+void clk_allow_idle(struct clk *clk);
 
 extern void omap_pm_idle(void);
 extern void omap_pm_suspend(void);
-- 
1.5.6.rc3.21.g8c6b5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: OMAP: Fixes for suspend / resume GPIO wake-up handling

2008-11-26 Thread Tony Lindgren
From 723fdb781abfe78d8ba7d911abbb581722348aa7 Mon Sep 17 00:00:00 2001
From: Tero Kristo [EMAIL PROTECTED]
Date: Wed, 26 Nov 2008 14:35:16 -0800
Subject: [PATCH] ARM: OMAP: Fixes for suspend / resume GPIO wake-up handling

Use the correct wake-up enable register, and make it
work with 34xx also.

Signed-off-by: Tero Kristo [EMAIL PROTECTED]
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
 arch/arm/plat-omap/gpio.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 8679fbc..424049d 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -101,6 +101,7 @@
 #define OMAP24XX_GPIO_IRQSTATUS2   0x0028
 #define OMAP24XX_GPIO_IRQENABLE2   0x002c
 #define OMAP24XX_GPIO_IRQENABLE1   0x001c
+#define OMAP24XX_GPIO_WAKE_EN  0x0020
 #define OMAP24XX_GPIO_CTRL 0x0030
 #define OMAP24XX_GPIO_OE   0x0034
 #define OMAP24XX_GPIO_DATAIN   0x0038
@@ -1551,7 +1552,7 @@ static int omap_gpio_suspend(struct sys_device *dev, 
pm_message_t mesg)
 #endif
 #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
case METHOD_GPIO_24XX:
-   wake_status = bank-base + OMAP24XX_GPIO_SETWKUENA;
+   wake_status = bank-base + OMAP24XX_GPIO_WAKE_EN;
wake_clear = bank-base + OMAP24XX_GPIO_CLEARWKUENA;
wake_set = bank-base + OMAP24XX_GPIO_SETWKUENA;
break;
@@ -1574,7 +1575,7 @@ static int omap_gpio_resume(struct sys_device *dev)
 {
int i;
 
-   if (!cpu_is_omap24xx()  !cpu_is_omap16xx())
+   if (!cpu_class_is_omap2()  !cpu_is_omap16xx())
return 0;
 
for (i = 0; i  gpio_bank_count; i++) {
-- 
1.5.6.rc3.21.g8c6b5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot

2008-11-26 Thread Kevin Hilman
The bootloader may leave the MMC in a state which prevents hitting
retention.  Even when MMC is not compiled in, each MMC module needs to
be forced into reset.

Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/devices.c |   76 +
 1 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 241e418..196de4e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -14,6 +14,7 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/io.h
+#include linux/clk.h
 
 #include mach/hardware.h
 #include asm/mach-types.h
@@ -358,6 +359,80 @@ static inline void omap_init_sha1_md5(void) { }
 
 /*-*/
 
+#ifdef CONFIG_ARCH_OMAP3
+
+#define MMCHS1 (L4_34XX_BASE + 0x9C000)
+#define MMCHS2 (L4_34XX_BASE + 0xB4000)
+#define MMCHS3 (L4_34XX_BASE + 0xAD000)
+#define MAX_MMC3
+#define MMCHS_SYSCONFIG0x0010
+#define MMCHS_SYSCONFIG_SWRESET(1  1)
+#define MMCHS_SYSSTATUS0x0014
+#define MMCHS_SYSSTATUS_RESETDONE  (1  0)
+
+static struct platform_device dummy_pdev = {
+   .dev = {
+   .bus = platform_bus_type,
+   },
+};
+
+/**
+ * omap_hsmmc_reset() - Full reset of each HS-MMC controller
+ *
+ * Ensure that each MMC controller is fully reset.  Controllers
+ * left in an unknown state (by bootloaer) may prevent retention
+ * or OFF-mode.  This is especially important in cases where the
+ * MMC driver is not enabled, _or_ built as a module.
+ *
+ * In order for reset to work, interface, functional and debounce
+ * clocks must be enabled.  The debounce clock comes from func_32k_clk
+ * and is not under SW control, so we only enable i- and f-clocks.
+ **/
+static void __init omap_hsmmc_reset(void)
+{
+   u32 i, base[MAX_MMC] = {MMCHS1, MMCHS2, MMCHS3};
+
+   for (i = 0; i  MAX_MMC; i++) {
+   u32 v;
+   struct clk *iclk, *fclk;
+   struct device *dev = dummy_pdev.dev;
+
+   dummy_pdev.id = i;
+   iclk = clk_get(dev, mmchs_ick);
+   if (iclk  clk_enable(iclk))
+   iclk = NULL;
+
+   fclk = clk_get(dev, mmchs_fck);
+   if (fclk  clk_enable(fclk))
+   fclk = NULL;
+
+   if (!iclk || !fclk) {
+   printk(KERN_WARNING
+  %s: Unable to enable clocks for MMC%d, 
+  cannot reset.\n,  __func__, i);
+   break;
+   }
+
+   omap_writel(MMCHS_SYSCONFIG_SWRESET, base[i] + MMCHS_SYSCONFIG);
+   v = omap_readl(base[i] + MMCHS_SYSSTATUS);
+   while (!(omap_readl(base[i] + MMCHS_SYSSTATUS) 
+MMCHS_SYSSTATUS_RESETDONE))
+   cpu_relax();
+
+   if (fclk) {
+   clk_disable(fclk);
+   clk_put(fclk);
+   }
+   if (iclk) {
+   clk_disable(iclk);
+   clk_put(iclk);
+   }
+   }
+}
+#else
+static inline void omap_hsmmc_reset(void) {}
+#endif
+
 #if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
 
@@ -477,6 +552,7 @@ static int __init omap2_init_devices(void)
/* please keep these calls, and their implementations above,
 * in alphabetical order so they're easier to sort through.
 */
+   omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
-- 
1.6.0.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/5] OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init

2008-11-26 Thread Kevin Hilman
Add D2D clocks (modem_fck, sad2d_ick, mad2d_ick) to clock framework,
and also ensure that auto-idle bits are set for these clocks during
PRCM init.

Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/clock34xx.h   |   37 +++-
 arch/arm/mach-omap2/cm-regbits-34xx.h |   14 
 arch/arm/mach-omap2/pm34xx.c  |4 ++-
 3 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 0b95fcb..78504ce 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1330,6 +1330,38 @@ static struct clk d2d_26m_fck = {
.recalc = followparent_recalc,
 };
 
+static struct clk modem_fck = {
+   .name   = modem_fck,
+   .parent = sys_ck,
+   .prcm_mod   = CORE_MOD,
+   .enable_reg = CM_FCLKEN1,
+   .enable_bit = OMAP3430_EN_MODEM_SHIFT,
+   .flags  = CLOCK_IN_OMAP343X,
+   .clkdm  = { .name = d2d_clkdm },
+   .recalc = followparent_recalc,
+};
+
+static struct clk sad2d_ick = {
+   .name   = sad2d_ick,
+   .parent = sys_ck,
+   .prcm_mod   = CORE_MOD,
+   .enable_reg = CM_ICLKEN1,
+   .enable_bit = OMAP3430_EN_SAD2D_SHIFT,
+   .flags  = CLOCK_IN_OMAP343X,
+   .clkdm  = { .name = d2d_clkdm },
+   .recalc = followparent_recalc,
+};
+
+static struct clk mad2d_ick = {
+   .name   = mad2d_ick,
+   .parent = sys_ck,
+   .prcm_mod   = CORE_MOD,
+   .enable_reg = CM_ICLKEN3,
+   .enable_bit = OMAP3430_EN_MAD2D_SHIFT,
+   .flags  = CLOCK_IN_OMAP343X,
+   .clkdm  = { .name = d2d_clkdm },
+   .recalc = followparent_recalc,
+};
 static const struct clksel omap343x_gpt_clksel[] = {
{ .parent = omap_32k_fck, .rates = gpt_32k_rates },
{ .parent = sys_ck,   .rates = gpt_sys_rates },
@@ -2241,8 +2273,6 @@ static struct clk usb_l4_ick = {
.recalc = omap2_clksel_recalc,
 };
 
-/* XXX MDM_INTC_ICK, SAD2D_ICK ?? */
-
 /* SECURITY_L4_ICK2 based clocks */
 
 static struct clk security_l4_ick2 = {
@@ -3460,6 +3490,9 @@ static struct clk *onchip_34xx_clks[] __initdata = {
sgx_fck,
sgx_ick,
d2d_26m_fck,
+   modem_fck,
+   sad2d_ick,
+   mad2d_ick,
gpt10_fck,
gpt11_fck,
cpefuse_fck,
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h 
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6f3f5a3..6923deb 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -145,6 +145,8 @@
 #define OMAP3430_CLKACTIVITY_MPU_MASK  (1  0)
 
 /* CM_FCLKEN1_CORE specific bits */
+#define OMAP3430_EN_MODEM  (1  31)
+#define OMAP3430_EN_MODEM_SHIFT31
 
 /* CM_ICLKEN1_CORE specific bits */
 #define OMAP3430_EN_ICR(1  29)
@@ -161,6 +163,8 @@
 #define OMAP3430_EN_MAILBOXES_SHIFT7
 #define OMAP3430_EN_OMAPCTRL   (1  6)
 #define OMAP3430_EN_OMAPCTRL_SHIFT 6
+#define OMAP3430_EN_SAD2D  (1  3)
+#define OMAP3430_EN_SAD2D_SHIFT3
 #define OMAP3430_EN_SDRC   (1  1)
 #define OMAP3430_EN_SDRC_SHIFT 1
 
@@ -176,6 +180,10 @@
 #define OMAP3430_EN_DES1   (1  0)
 #define OMAP3430_EN_DES1_SHIFT 0
 
+/* CM_ICLKEN3_CORE */
+#define OMAP3430_EN_MAD2D_SHIFT3
+#define OMAP3430_EN_MAD2D  (1  3)
+
 /* CM_FCLKEN3_CORE specific bits */
 #define OMAP3430ES2_EN_TS_SHIFT1
 #define OMAP3430ES2_EN_TS_MASK (1  1)
@@ -231,6 +239,8 @@
 #define OMAP3430ES2_ST_CPEFUSE_MASK(1  0)
 
 /* CM_AUTOIDLE1_CORE */
+#define OMAP3430_AUTO_MODEM(1  31)
+#define OMAP3430_AUTO_MODEM_SHIFT  31
 #define OMAP3430ES2_AUTO_MMC3  (1  30)
 #define OMAP3430ES2_AUTO_MMC3_SHIFT30
 #define OMAP3430ES2_AUTO_ICR   (1  29)
@@ -287,6 +297,8 @@
 #define OMAP3430_AUTO_HSOTGUSB_SHIFT   4
 #define OMAP3430ES1_AUTO_D2D   (1  3)
 #define OMAP3430ES1_AUTO_D2D_SHIFT 3
+#define OMAP3430_AUTO_SAD2D(1  3)
+#define OMAP3430_AUTO_SAD2D_SHIFT  3
 #define OMAP3430_AUTO_SSI  (1  0)
 #define OMAP3430_AUTO_SSI_SHIFT0
 
@@ -308,6 +320,8 @@
 #defineOMAP3430ES2_AUTO_USBTLL (1  2)
 #define OMAP3430ES2_AUTO_USBTLL_SHIFT   

[PATCH 4/5] OMAP3: PM: D2D clockdomain supports SW supervised transitions

2008-11-26 Thread Kevin Hilman
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/clockdomains.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains.h 
b/arch/arm/mach-omap2/clockdomains.h
index bafa650..49a5774 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -198,7 +198,7 @@ static struct clockdomain sgx_clkdm = {
 static struct clockdomain d2d_clkdm = {
.name   = d2d_clkdm,
.pwrdm  = { .name = core_pwrdm },
-   .flags  = CLKDM_CAN_HWSUP,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES1_CLKTRCTRL_D2D_MASK,
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 };
-- 
1.6.0.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/5] OMAP3: PM: Ensure modem is reset during PRCM init

2008-11-26 Thread Kevin Hilman
Rogue bootloaders may enable the modem and thus keep the
D2D power- and clock-domains from going into retention.
Reset modem on boot to be sure it is in known state.

Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/pm34xx.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7c5577a..e22a11f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -418,6 +418,12 @@ static void __init omap3_iva_idle(void)
 
 static void __init prcm_setup_regs(void)
 {
+   /* reset modem */
+   prm_write_mod_reg(OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RSTPWRON |
+ OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RST,
+ CORE_MOD, RM_RSTCTRL);
+   prm_write_mod_reg(0, CORE_MOD, RM_RSTCTRL);
+
/* XXX Reset all wkdeps. This should be done when initializing
 * powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
-- 
1.6.0.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] 8250: Allow platform to register PM hook

2008-11-26 Thread Kevin Hilman
Allow platform code to register a PM hook with the 8250 driver.  This
enables platform specific code to be run for suspend/resume events.

Since the per-port PM hook is local to the 8250 driver ('struct
uart_port' doesn't have a PM hook) I pass the pm hook from the
platform probe via serial8250_register_port().

Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
 drivers/serial/8250.c   |7 +--
 include/linux/serial_8250.h |7 ++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 5f383d8..993a242 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2842,7 +2842,7 @@ static int __devinit serial8250_probe(struct 
platform_device *dev)
port.dev= dev-dev;
if (share_irqs)
port.flags |= UPF_SHARE_IRQ;
-   ret = serial8250_register_port(port);
+   ret = serial8250_register_port(port, p-pm);
if (ret  0) {
dev_err(dev-dev, unable to register port at index %d 

(IO%lx MEM%llx IRQ%d): %d\n, i,
@@ -2966,7 +2966,9 @@ static struct uart_8250_port 
*serial8250_find_match_or_unused(struct uart_port *
  *
  * On success the port is ready to use and the line number is returned.
  */
-int serial8250_register_port(struct uart_port *port)
+int serial8250_register_port(struct uart_port *port,
+void (*pm)(struct uart_port *, unsigned int state,
+   unsigned int oldstate))
 {
struct uart_8250_port *uart;
int ret = -ENOSPC;
@@ -2990,6 +2992,7 @@ int serial8250_register_port(struct uart_port *port)
uart-port.flags= port-flags | UPF_BOOT_AUTOCONF;
uart-port.mapbase  = port-mapbase;
uart-port.private_data = port-private_data;
+   uart-pm = pm;
if (port-dev)
uart-port.dev = port-dev;
 
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 3d37c94..97723c5 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -28,6 +28,9 @@ struct plat_serial8250_port {
unsigned char   iotype; /* UPIO_* */
unsigned char   hub6;
upf_t   flags;  /* UPF_* flags */
+
+   void(*pm)(struct uart_port *, unsigned int state,
+ unsigned int oldstate);
 };
 
 /*
@@ -57,7 +60,9 @@ enum {
  */
 struct uart_port;
 
-int serial8250_register_port(struct uart_port *);
+int serial8250_register_port(struct uart_port *,
+void (*pm)(struct uart_port *, unsigned int state,
+   unsigned int oldstate));
 void serial8250_unregister_port(int line);
 void serial8250_suspend_port(int line);
 void serial8250_resume_port(int line);
-- 
1.6.0.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] 8250: when waking, PM hook should be called before accessing port

2008-11-26 Thread Kevin Hilman
The UART suspend hook may have disabled the UART clocks such that
accesses to the port may fail.  So before accessing the port
call the PM hook so it has a chance to enable clocks.

Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
 drivers/serial/8250.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 993a242..a181667 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2334,10 +2334,18 @@ serial8250_pm(struct uart_port *port, unsigned int 
state,
  unsigned int oldstate)
 {
struct uart_8250_port *p = (struct uart_8250_port *)port;
+   int sleep = state != 0;
 
-   serial8250_set_sleep(p, state != 0);
+   /* If we're waking up, call the PM hook before waking up
+* so port can be properly activated/enabled if necessary */
+   if (p-pm  !sleep)
+   p-pm(port, state, oldstate);
+
+   serial8250_set_sleep(p, sleep);
 
-   if (p-pm)
+   /* If we're going to sleep, PM hook should be called after
+* to deactivate/disable port */
+   if (p-pm  sleep)
p-pm(port, state, oldstate);
 }
 
-- 
1.6.0.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot

2008-11-26 Thread Tony Lindgren
* Kevin Hilman [EMAIL PROTECTED] [081126 16:07]:
 The bootloader may leave the MMC in a state which prevents hitting
 retention.  Even when MMC is not compiled in, each MMC module needs to
 be forced into reset.
 
 Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
 ---
  arch/arm/mach-omap2/devices.c |   76 
 +
  1 files changed, 76 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index 241e418..196de4e 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -14,6 +14,7 @@
  #include linux/init.h
  #include linux/platform_device.h
  #include linux/io.h
 +#include linux/clk.h
  
  #include mach/hardware.h
  #include asm/mach-types.h
 @@ -358,6 +359,80 @@ static inline void omap_init_sha1_md5(void) { }
  
  /*-*/
  
 +#ifdef CONFIG_ARCH_OMAP3
 +
 +#define MMCHS1   (L4_34XX_BASE + 0x9C000)
 +#define MMCHS2   (L4_34XX_BASE + 0xB4000)
 +#define MMCHS3   (L4_34XX_BASE + 0xAD000)

These are already in plat-omap/include/mach/mmc.h, how about just
include it? Then you can have a switch statement like we already have
for omap2_init_mmc?

 +#define MAX_MMC  3

This too

 +#define MMCHS_SYSCONFIG  0x0010
 +#define MMCHS_SYSCONFIG_SWRESET  (1  1)
 +#define MMCHS_SYSSTATUS  0x0014
 +#define MMCHS_SYSSTATUS_RESETDONE(1  0)
 +
 +static struct platform_device dummy_pdev = {
 + .dev = {
 + .bus = platform_bus_type,
 + },
 +};
 +
 +/**
 + * omap_hsmmc_reset() - Full reset of each HS-MMC controller
 + *
 + * Ensure that each MMC controller is fully reset.  Controllers
 + * left in an unknown state (by bootloaer) may prevent retention
 + * or OFF-mode.  This is especially important in cases where the
 + * MMC driver is not enabled, _or_ built as a module.

Should say bootloader above :)

Regards,

Tony


 + * In order for reset to work, interface, functional and debounce
 + * clocks must be enabled.  The debounce clock comes from func_32k_clk
 + * and is not under SW control, so we only enable i- and f-clocks.
 + **/
 +static void __init omap_hsmmc_reset(void)
 +{
 + u32 i, base[MAX_MMC] = {MMCHS1, MMCHS2, MMCHS3};
 +
 + for (i = 0; i  MAX_MMC; i++) {
 + u32 v;
 + struct clk *iclk, *fclk;
 + struct device *dev = dummy_pdev.dev;
 +
 + dummy_pdev.id = i;
 + iclk = clk_get(dev, mmchs_ick);
 + if (iclk  clk_enable(iclk))
 + iclk = NULL;
 +
 + fclk = clk_get(dev, mmchs_fck);
 + if (fclk  clk_enable(fclk))
 + fclk = NULL;
 +
 + if (!iclk || !fclk) {
 + printk(KERN_WARNING
 +%s: Unable to enable clocks for MMC%d, 
 +cannot reset.\n,  __func__, i);
 + break;
 + }
 +
 + omap_writel(MMCHS_SYSCONFIG_SWRESET, base[i] + MMCHS_SYSCONFIG);
 + v = omap_readl(base[i] + MMCHS_SYSSTATUS);
 + while (!(omap_readl(base[i] + MMCHS_SYSSTATUS) 
 +  MMCHS_SYSSTATUS_RESETDONE))
 + cpu_relax();
 +
 + if (fclk) {
 + clk_disable(fclk);
 + clk_put(fclk);
 + }
 + if (iclk) {
 + clk_disable(iclk);
 + clk_put(iclk);
 + }
 + }
 +}
 +#else
 +static inline void omap_hsmmc_reset(void) {}
 +#endif
 +
  #if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
   defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
  
 @@ -477,6 +552,7 @@ static int __init omap2_init_devices(void)
   /* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
 + omap_hsmmc_reset();
   omap_init_camera();
   omap_init_mbox();
   omap_init_mcspi();
 -- 
 1.6.0.3
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[patch 2.6.28-rc6-omap-git 1/2] twl4030-usb: cleanup debug code

2008-11-26 Thread David Brownell
From: David Brownell [EMAIL PROTECTED]

Remove some debug code from twl4030-usb which 'checkpatch.pl' warned
about.  Turn some other messages into debug code; and add some debug
messages in the write verify paths (so we can see if they matter).
This gives about 25% codespace shrinkage.

Signed-off-by: David Brownell [EMAIL PROTECTED]
---
 drivers/i2c/chips/twl4030-usb.c |   29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)

--- a/drivers/i2c/chips/twl4030-usb.c
+++ b/drivers/i2c/chips/twl4030-usb.c
@@ -285,13 +285,18 @@ static int twl4030_i2c_write_u8_verify(s
(twl4030_i2c_read_u8(module, check, address) = 0) 
(check == data))
return 0;
+   dev_dbg(twl-dev, Write%d[%d,0x%x] wrote %02x but read %02x\n,
+   1, module, address, check, data);
+
/* Failed once: Try again */
if ((twl4030_i2c_write_u8(module, data, address) = 0) 
(twl4030_i2c_read_u8(module, check, address) = 0) 
(check == data))
return 0;
-   /* Failed again: Return error */
+   dev_dbg(twl-dev, Write%d[%d,0x%x] wrote %02x but read %02x\n,
+   2, module, address, check, data);
 
+   /* Failed again: Return error */
return -EBUSY;
 }
 
@@ -304,23 +309,9 @@ static inline int twl4030_usb_write(stru
int ret = 0;
 
ret = twl4030_i2c_write_u8(TWL4030_MODULE_USB, data, address);
-   if (ret = 0) {
-#if 0  /* debug */
-   u8 data1;
-   if (twl4030_i2c_read_u8(TWL4030_MODULE_USB, data1,
-   address)  0)
-   dev_err(twl-dev, re-read failed\n);
-   else
-   dev_dbg(twl-dev,
-  Write %s wrote %x read %x from reg %x\n,
-  (data1 == data) ? succeed : mismatch,
-  data, data1, address);
-#endif
-   } else {
-   dev_warn(twl-dev,
+   if (ret  0)
+   dev_dbg(twl-dev,
TWL4030:USB:Write[0x%x] Error %d\n, address, ret);
-   }
-
return ret;
 }
 
@@ -333,7 +324,7 @@ static inline int twl4030_readb(struct t
if (ret = 0)
ret = data;
else
-   dev_warn(twl-dev,
+   dev_dbg(twl-dev,
TWL4030:readb[0x%x,0x%x] Error %d\n,
module, address, ret);
 
@@ -655,7 +646,7 @@ static int __init twl4030_usb_probe(stru
return -ENOMEM;
 
if (!pdata) {
-   dev_info(pdev-dev, platform_data not available\n);
+   dev_dbg(pdev-dev, platform_data not available\n);
return -EINVAL;
}
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] extra module resets to ensure full-chip idle

2008-11-26 Thread Kevin Hilman
Dirk Behme [EMAIL PROTECTED] writes:

 Kevin Hilman wrote:
 Various bootloaders have been known to leave modules in a state
 which prevents full-chip retention.  

 Does it make sense to check if

 [PATCH 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot
 [PATCH 2/5] OMAP3: PM: Force IVA2 into idle during bootup

 can be done in U-Boot, too? If yes, I would have a look to it.

Yes, ideally u-boot or whatever bootloader isused should 
be leaving these modules in a known reset/idle state.

However, there are many bootloaders for many platforms out there so
until there is some sort of standard on bootloaders, I think the
kernel will have to ensure this is done.

Kevin


 This series forces
 MMC, IVA2 and D2D/modem into known reset/idle states so that
 the OMAP3 can hit full-chip idle.

 Tested on OMAP3 Beagle, and custom OMAP3 hardware.

 NOTE: this is similar to the set I posted for the PM branch
   but this series is rebased onto linux-omap and includes
   the MMC reset.

 Kevin Hilman (5):
   OMAP3: PM: HSMMC: force MMC module reset on boot
   OMAP3: PM: Force IVA2 into idle during bootup
   OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init
   OMAP3: PM: D2D clockdomain supports SW supervised transitions
   OMAP3: PM: Ensure modem is reset during PRCM init

  arch/arm/mach-omap2/clock34xx.h   |   37 +-
  arch/arm/mach-omap2/clockdomains.h|2 +-
  arch/arm/mach-omap2/cm-regbits-34xx.h |   14 +
  arch/arm/mach-omap2/devices.c |   76 
 +
  arch/arm/mach-omap2/pm34xx.c  |   65 -
  arch/arm/plat-omap/include/mach/control.h |5 ++
  6 files changed, 195 insertions(+), 4 deletions(-)

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add OMAP2 camera driver

2008-11-26 Thread Trilok Soni
Hi Hans,


 1) The makefile isn't right: it compiles omap24xxcam.c and
 omap24xxcam-dma.c as two modules, but I suspect you want only one since
 the symbols that omap24xxcam.c needs from omap24xxcam-dma.c are not
 exported. See e.g. the msp3400 driver in the Makefile for how to do it.

I will make this change.


 2) The Kconfig is probably missing a ARCH_OMAP dependency (sounds
 reasonable, at least), so now it also compiles for the i686 but that
 architecture doesn't have a clk_get function.

I will add this dependency.


 3) I was wondering whether Sakari also wants to add a Signed-off-by
 line? Looking at the comments it seems that he was involved as well.

I CCed from the first e-mail, so that he can review and give
Signed-off-by to this patch.


 4) I get a bunch of compile warnings (admittedly when compiling for
 i686) that you might want to look at. Compiled against the 2.6.27
 kernel with gcc-4.3.1. It might be bogus since I didn't compile for the
 omap architecture.

I will update my toolchain to gcc-4.3.x for ARM and see if it
generates the warnings like below. But I think we are fine once we add
ARCH_OMAP dependency to this driver.

Thanks for the review comments. I will resubmit the patch.

-- 
---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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Provide the set_power at TWL4030 MMC

2008-11-26 Thread Kyungmin Park
Custom board powered by VAUX2 and VAUX4 for MMC instead of VMMC
Also it uses VMMC for MMC core power not voltage.

MMC1: uses VMMC1(voltage) and VMMC2(Vdd)
MMC2: uses VAUX2(voltage) and VAUX4(Vdd)

To address this issue, platform uses its custom power function.

Signed-off-by: Kyungmin Park [EMAIL PROTECTED]
---
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c 
b/arch/arm/mach-omap2/mmc-twl4030.c
index 626d668..571b7b0 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -27,28 +27,6 @@
 
 #if 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_260V 0x08
-#define VMMC2_185V 0x06
-#define VMMC2_DEDICATED0x2E
-
-#define VMMC_DEV_GRP_P10x20
-
 static u16 control_pbias_offset;
 static u16 control_devconf1_offset;
 
@@ -385,14 +363,21 @@ void __init hsmmc_init(struct twl4030_hsmmc_info 
*controllers)
/* NOTE:  we assume OMAP's MMC1 and MMC2 use
 * the TWL4030's VMMC1 and VMMC2, respectively;
 * and that OMAP's MMC3 isn't used.
+* or provided by a platform.
 */
 
switch (c-mmc) {
case 1:
-   mmc-slots[0].set_power = twl_mmc1_set_power;
+   if (c-set_power)
+   mmc-slots[0].set_power = c-set_power;
+   else
+   mmc-slots[0].set_power = twl_mmc1_set_power;
break;
case 2:
-   mmc-slots[0].set_power = twl_mmc2_set_power;
+   if (c-set_power)
+   mmc-slots[0].set_power = c-set_power;
+   else
+   mmc-slots[0].set_power = twl_mmc2_set_power;
break;
default:
pr_err(MMC%d configuration not supported!\n, c-mmc);
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h 
b/arch/arm/mach-omap2/mmc-twl4030.h
index e2d58a2..25a08ed 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -6,12 +6,55 @@
  * published by the Free Software Foundation.
  */
 
+#define VAUX2_DEV_GRP  0x1B
+#define VAUX2_315V 0x0C
+#define VAUX2_300V 0x0B
+#define VAUX2_285V 0x0A
+#define VAUX2_260V 0x08
+#define VAUX2_185V 0x06
+#define VAUX2_180V 0x05
+#define VAUX2_DEDICATED0x1E
+
+#define VAUX4_DEV_GRP  0x23
+#define VAUX4_315V 0x0C
+#define VAUX4_300V 0x0B
+#define VAUX4_285V 0x0A
+#define VAUX4_260V 0x08
+#define VAUX4_185V 0x06
+#define VAUX4_DEDICATED0x26
+
+#define VAUX_DEV_GRP_P10x20
+
+#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  0x00
+#define VMMC2_315V 0x0c
+#define VMMC2_300V 0x0b
+#define VMMC2_285V 0x0a
+#define VMMC2_260V 0x08
+#define VMMC2_185V 0x06
+#define VMMC2_DEDICATED0x2E
+
+#define VMMC_DEV_GRP_P10x20
+
 struct twl4030_hsmmc_info {
u8  mmc;/* controller 1/2/3 */
u8  wires;  /* 1/4/8 wires */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
int ext_clock:1;/* use external pin for input clock */
+   int (*set_power)(struct device *dev, int slot,
+   int power_on, int vdd);
 };
 
 #ifdefined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html