[PATCH] omap: 4430sdp board support for proximity sensor

2010-09-01 Thread Shubhrajyoti D
omap 4430sdp board support for the  proximity sensor via GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
- Making the default state of the sensor off at bootup
- The init is called before platform_add_devices

Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 arch/arm/mach-omap2/board-4430sdp.c |   61 +++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..f31d68e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
 #include linux/usb/otg.h
 #include linux/spi/spi.h
 #include linux/i2c/twl.h
+#include linux/gpio_keys.h
 #include linux/regulator/machine.h
 #include linux/leds.h
 
@@ -40,6 +41,8 @@
 #define ETH_KS8851_IRQ 34
 #define ETH_KS8851_POWER_ON48
 #define ETH_KS8851_QUART   138
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO   184
+#define OMAP4_SFH7741_ENABLE_GPIO  188
 
 static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -77,11 +80,47 @@ static struct gpio_led sdp4430_gpio_leds[] = {
 
 };
 
+static struct gpio_keys_button sdp4430_gpio_keys[] = {
+   {
+   .desc   = Proximity Sensor,
+   .type   = EV_SW,
+   .code   = SW_FRONT_PROXIMITY,
+   .gpio   = OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
+   .active_low = 0,
+   }
+};
+
 static struct gpio_led_platform_data sdp4430_led_data = {
.leds   = sdp4430_gpio_leds,
.num_leds   = ARRAY_SIZE(sdp4430_gpio_leds),
 };
 
+static int omap_prox_activate(struct device *dev)
+{
+   gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
+   return 0;
+}
+
+static void omap_prox_deactivate(struct device *dev)
+{
+   gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
+}
+
+static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
+   .buttons= sdp4430_gpio_keys,
+   .nbuttons   = ARRAY_SIZE(sdp4430_gpio_keys),
+   .enable = omap_prox_activate,
+   .disable= omap_prox_deactivate,
+};
+
+static struct platform_device sdp4430_gpio_keys_device = {
+   .name   = gpio-keys,
+   .id = -1,
+   .dev= {
+   .platform_data  = sdp4430_gpio_keys_data,
+   },
+};
+
 static struct platform_device sdp4430_leds_gpio = {
.name   = leds-gpio,
.id = -1,
@@ -161,6 +200,7 @@ static struct platform_device sdp4430_lcd_device = {
 
 static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+   sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
 };
 
@@ -426,11 +466,32 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
 }
+
+static void __init omap_sfh7741prox_init(void)
+{
+   int  error;
+
+   error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+   if (error  0) {
+   pr_err(%s:failed to request GPIO %d, error %d\n,
+   __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+   return;
+   }
+
+   error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 0);
+   if (error  0) {
+   pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,
+__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+   gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+   }
+}
+
 static void __init omap_4430sdp_init(void)
 {
int status;
 
omap4_i2c_init();
+   omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] omap: 4430sdp board support for the the GPIO keys

2010-09-01 Thread Datta, Shubhrajyoti


 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Tuesday, August 31, 2010 9:32 PM
 To: Datta, Shubhrajyoti
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH] omap: 4430sdp board support for the the GPIO keys
 
 Shubhrajyoti D shubhrajy...@ti.com writes:
 
  omap 4430sdp board support for the GPIO keys.
  The proximity sensor is connected to GPIO and is registered as a
  GPIO key.
  - Making the default state of the sensor off at bootup
  - The init is called before platform_add_devices
 
  Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 
 I still think the subject is wrong:  You're adding support for the
 proximity sensor *using* GPIO keys, not adding support for GPIO keys:
 
 OMAP: 4430SDP: add proximity sensor via GPIO keys
 
 or something like that.
Yes agree just sent a patch attempting to correct it.
Thanks,
 
 Kevin

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


[PATCH] V4L/DVB: OMAP_VOUT: Remove unneseccasry code in omap_vout_calculate_offset

2010-09-01 Thread Archit Taneja
In omap_vout_calculate_offset(), cur_display is assigned ovl-manager-device, 
but
isn't used for anything. The corresponding code is removed.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/video/omap/omap_vout.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 929073e..255cd99
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -506,11 +506,9 @@ static int v4l2_rot_to_dss_rot(int v4l2_rotation,
  */
 static int omap_vout_calculate_offset(struct omap_vout_device *vout)
 {
-   struct omap_overlay *ovl;
enum dss_rotation rotation;
struct omapvideo_info *ovid;
bool mirroring = vout-mirror;
-   struct omap_dss_device *cur_display;
struct v4l2_rect *crop = vout-crop;
struct v4l2_pix_format *pix = vout-pix;
int *cropped_offset = vout-cropped_offset;
@@ -518,12 +516,6 @@ static int omap_vout_calculate_offset(struct 
omap_vout_device *vout)
int offset = 0, ctop = 0, cleft = 0, line_length = 0;
 
ovid = vout-vid_info;
-   ovl = ovid-overlays[0];
-   /* get the display device attached to the overlay */
-   if (!ovl-manager || !ovl-manager-device)
-   return -1;
-
-   cur_display = ovl-manager-device;
rotation = calc_rotation(vout);
 
if (V4L2_PIX_FMT_YUYV == pix-pixelformat ||
-- 
1.7.0.4

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


[PATCH v3] OMAP4: pm.c extensions for OMAP4 support

2010-09-01 Thread Thara Gopinath
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.

Signed-off-by: Thara Gopinath th...@ti.com
---
v2: Removed fixing of l3_main hwmod for OMAP4 as Benoit has
already submitted a pach fixing the same.
v3: Put OMAP4 check across dsp_dev init so that on other
OMAP's this init does not throw a warn.

 arch/arm/mach-omap2/pm.c |   20 +++-
 arch/arm/plat-omap/include/plat/common.h |3 ++-
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 68f9f2e..c93921d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -21,8 +21,9 @@
 static struct omap_device_pm_latency *pm_lats;
 
 static struct device *mpu_dev;
-static struct device *dsp_dev;
+static struct device *iva_dev;
 static struct device *l3_dev;
+static struct device *dsp_dev;
 
 struct device *omap2_get_mpuss_device(void)
 {
@@ -30,10 +31,10 @@ struct device *omap2_get_mpuss_device(void)
return mpu_dev;
 }
 
-struct device *omap2_get_dsp_device(void)
+struct device *omap2_get_iva_device(void)
 {
-   WARN_ON_ONCE(!dsp_dev);
-   return dsp_dev;
+   WARN_ON_ONCE(!iva_dev);
+   return iva_dev;
 }
 
 struct device *omap2_get_l3_device(void)
@@ -42,6 +43,13 @@ struct device *omap2_get_l3_device(void)
return l3_dev;
 }
 
+struct device *omap4_get_dsp_device(void)
+{
+   WARN_ON_ONCE(!dsp_dev);
+   return dsp_dev;
+}
+EXPORT_SYMBOL(omap4_get_dsp_device);
+
 /* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
 static int _init_omap_device(char *name, struct device **new_dev)
 {
@@ -69,7 +77,9 @@ static int _init_omap_device(char *name, struct device 
**new_dev)
 static void omap2_init_processor_devices(void)
 {
_init_omap_device(mpu, mpu_dev);
-   _init_omap_device(iva, dsp_dev);
+   _init_omap_device(iva, iva_dev);
+   if (cpu_is_omap44xx())
+   _init_omap_device(dsp, dsp_dev);
_init_omap_device(l3_main, l3_dev);
 }
 
diff --git a/arch/arm/plat-omap/include/plat/common.h 
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..c45dbb9 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -91,7 +91,8 @@ void omap3_map_io(void);
 })
 
 extern struct device *omap2_get_mpuss_device(void);
-extern struct device *omap2_get_dsp_device(void);
+extern struct device *omap2_get_iva_device(void);
 extern struct device *omap2_get_l3_device(void);
+extern struct device *omap4_get_dsp_device(void);
 
 #endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
-- 
1.7.0.4

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


Re: [PATCH] I2C: Fix for suspend/resume issue in i2c-core

2010-09-01 Thread Jean Delvare
On Wed, 1 Sep 2010 01:12:11 +0200, Rafael J. Wysocki wrote:
 On Tuesday, August 31, 2010, Mark Brown wrote:
  On Mon, Aug 30, 2010 at 11:43:23AM -0700, Kevin Hilman wrote:
   Vishwanath BS vishwanath...@ti.com writes:
   
In current i2c core driver, pm_runtime_set_active call from 
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from 
i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the 
child_count of
the device's parent. However, matching pm_runtime_set_suspended is not 
called
in suspend routine because of which child_count of the device's parent
is not balanced, preventing the parent device to idle.
Issue has been fixed by adding pm_runtime_set_suspended call inside 
suspend
reoutine which will make sure that child_counts are balanced.
This fix has been tested on OMAP4430.
   
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
   
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
   
   Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
  
  Also Jean Delvare who maintains the I2C core.  To be honest Rafael did
  all the actual work here (and has since rewritten the code anyway).
 
 Sorry for the delay.
 
 The fix looks reasonable to me.

I take this as an Acked-by. Patch applied, thanks.

 
---
 drivers/i2c/i2c-core.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)
   
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..3146bff
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -196,14 +196,22 @@ static int i2c_legacy_resume(struct device *dev)
 static int i2c_device_pm_suspend(struct device *dev)
 {
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : 
NULL;
+   int ret;
 
if (pm_runtime_suspended(dev))
return 0;
 
if (pm)
-   return pm-suspend ? pm-suspend(dev) : 0;
+   ret = pm-suspend ? pm-suspend(dev) : 0;
+   else
+   ret = i2c_legacy_suspend(dev, PMSG_SUSPEND);
 
-   return i2c_legacy_suspend(dev, PMSG_SUSPEND);
+   if (!ret) {
+   pm_runtime_disable(dev);
+   pm_runtime_set_suspended(dev);
+   pm_runtime_enable(dev);
+   }
+   return ret;
 }
 
 static int i2c_device_pm_resume(struct device *dev)
  
  
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-i2c in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


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


RE: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration

2010-09-01 Thread DebBarma, Tarun Kanti
Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Tuesday, August 24, 2010 5:41 AM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Nayak,
 Rajendra; Paul Walmsley; Tony Lindgren
 Subject: Re: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration
 
 Tarun Kanti DebBarma tarun.ka...@ti.com writes:
 
  +/**
  +* omap2_dm_timer_early_init - top level early timer initialization
  +* called in the last part of omap2_init_common_hw
  +*
  +* uses dedicated hwmod api to parse through hwmod database for
  +* given class name and then build and register the timer device.
  +* at the end driver is registered and early probe initiated.
  +**/
  +void __init omap2_dm_timer_early_init(void)
  +{
  +   omap_hwmod_for_each_by_class(timer_1ms,
  +   omap_dm_timer_early_init, NULL);
  +   omap2_dm_timer_setup();
  +   early_platform_driver_register_all(earlytimer);
  +   early_platform_driver_probe(earlytimer, early_timer_count + 1, 0);
  +}
 
 It's not clear (or documented) why on the 1ms timers should be the only
 earlydevices.
 
 For example, GPT12 is used as the system timer on Beagle due to a board
 bug in early revs of the board.  That will no longer function with this
 approach.

OK, I will change the design so that any timers could be used as early timers.
 
 Kevin
 

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


RE: [PATCHv2 8/13] dmtimer: OMAP: multi-platform register access support

2010-09-01 Thread DebBarma, Tarun Kanti
Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Tuesday, August 24, 2010 5:49 AM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org; Basak, Partha; Shilimkar, Santosh;
 Gopinath, Thara; Paul Walmsley; Tony Lindgren
 Subject: Re: [PATCHv2 8/13] dmtimer: OMAP: multi-platform register access
 support
 
 Tarun Kanti DebBarma tarun.ka...@ti.com writes:
 
  This patch uses the new register structures and mappings in functions
  in order to access register offsets thereby supporting multi-platform
  environment.
 
  Signed-off-by: Partha Basak p-bas...@ti.com
  Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
  Signed-off-by: Thara Gopinath th...@ti.com
  Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Kevin Hilman khil...@deeprootsystems.com
  Cc: Tony Lindgren t...@atomide.com
  ---
   arch/arm/plat-omap/dmtimer.c |   51 ---
 ---
   1 files changed, 39 insertions(+), 12 deletions(-)
 
  diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
  index 14a20e0..24ca283 100755
  --- a/arch/arm/plat-omap/dmtimer.c
  +++ b/arch/arm/plat-omap/dmtimer.c
  @@ -154,6 +154,7 @@ struct omap_dm_timer {
  unsigned long fclk_rate;
  int irq;
  void __iomem *io_base;
  +   u32 *regs;
  unsigned reserved:1;
  unsigned enabled:1;
  unsigned posted:1;
  @@ -174,13 +175,14 @@ static DEFINE_SPINLOCK(dm_timer_lock);
* pending bit must be checked. Otherwise a read of a non completed
 write
* will produce an error.
**/
  -static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer,
 u32 reg)
  +static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer,
 int reg)
 
 'reg' could stay unsigned, it's a non-zero index.  If anything, you
 could change it to a u8.
I will change. Thanks.

 
   {
  if (timer-posted)
  -   while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG 
 0xff))
  -(reg  WPSHIFT))
  +   while (readl(timer-io_base + \
 
 '\' is not needed
 
I will change.

thanks,
tarun

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


RE: [PATCHv2 0/13] OMAP: dmtimer: hwmod

2010-09-01 Thread DebBarma, Tarun Kanti
Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Tuesday, August 24, 2010 5:52 AM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCHv2 0/13] OMAP: dmtimer: hwmod
 
 Tarun Kanti DebBarma tarun.ka...@ti.com writes:
 
  This patch series contains:
  (*) most of the comments provided in v1 implemented and
  (*) OMAP4 timers support
 
  The comment details are availabe in respective patch series.
 
  The comment regarding usage of dmtimer name will be resolved
  after final round of consultation with members.
 
  Baseline: origin/pm-wip/hwmods-omap4
 
 This branch has no hwmods for OMAP4 timers.  Please rebase to recent
 version of same brach and include OMAP4 hwmod data.
 
  Test info: Tested on OMAP4430SDP, OMAP3630SDP
 
 Any 3430 testing?
 
Not yet, I will.

 Please also test on OMAP2 and OMAP1.
 
OK.

-tarun

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


RE: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration

2010-09-01 Thread DebBarma, Tarun Kanti
Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Tuesday, August 24, 2010 5:37 AM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Nayak,
 Rajendra; Paul Walmsley; Tony Lindgren
 Subject: Re: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration

 Tarun Kanti DebBarma tarun.ka...@ti.com writes:

  From: Thara Gopinath th...@ti.com
 
  This patch converts dmtimers into platform devices using omap hwmod,
  omap device and runtime pm frameworks. It also allows GPTIMER1 and
  GPTIMER2 and GPTIMER10 to be registered as early devices. This allows
  any one of the these three to be registered as system timer very early
  during system boot sequence. Later during normal plaform_device_register
  these are converted to normal platform device.

 What about GPT12 which is used as system timer on Beagle due to a board
 bug on early revs of board?

Will modify design to incorporate any of the timers as an early timer.

  comments incorporated:
  (1) registration of devices through automatic learning from hwmod
 database
  (2) enabling functionality both with and without pm_runtime
  (3) extract device id from hwmod structure's name field.
  (4) free platform data at the end of successful platform device
 registration

 I still don't like the way early devices are implemented.   My comments
 from the first time I reviewed this series appear to have been ignored.

 It is not at all clear why the separate pdata functions are needed for
 early and normal devices.  Many more questions/comments on this below...

Will merge the two and embed them within pdata.

  Signed-off-by: Partha Basak p-bas...@ti.com
  Signed-off-by: Thara Gopinath th...@ti.com
  Signed-off-by: Rajendra Nayak rna...@ti.com
  Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Kevin Hilman khil...@deeprootsystems.com
  Cc: Tony Lindgren t...@atomide.com
  ---
   arch/arm/mach-omap2/Makefile   |2 +-
   arch/arm/mach-omap2/dmtimer.c  |  403
 
   arch/arm/mach-omap2/dmtimer.h  |   19 ++
   arch/arm/mach-omap2/io.c   |2 +
   arch/arm/mach-omap2/timer-gp.c |1 -
   5 files changed, 425 insertions(+), 2 deletions(-)
   create mode 100755 arch/arm/mach-omap2/dmtimer.c
   create mode 100755 arch/arm/mach-omap2/dmtimer.h
   mode change 100644 = 100755 arch/arm/mach-omap2/io.c
 
  diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
  index 9b44773..c54f6e8 100644
  --- a/arch/arm/mach-omap2/Makefile
  +++ b/arch/arm/mach-omap2/Makefile
  @@ -3,7 +3,7 @@
   #
 
   # Common support
  -obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
 pm.o
  +obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
 pm.o dmtimer.o
 
   omap-2-3-common= irq.o sdrc.o
   hwmod-common   = omap_hwmod.o \
  diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-
 omap2/dmtimer.c
  new file mode 100755
  index 000..2c40a9b
  --- /dev/null
  +++ b/arch/arm/mach-omap2/dmtimer.c
  @@ -0,0 +1,403 @@
  +/**
  + * linux/arch/arm/mach-omap2/dmtimer.c
  + *
  + * Copyright (C) 2010 Texas Instruments, Inc.
  + * Thara Gopinath th...@ti.com
  + * Tarun Kanti DebBarma tarun.ka...@ti.com
  + * - Highlander ip support on omap4
  + * - hwmod support
  + *
  + * OMAP2 Dual-Mode Timers
  + * 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.
  + */
  +#include linux/clk.h
  +#include linux/delay.h
  +#include linux/io.h
  +#include linux/err.h
  +#include linux/slab.h
  +
  +#include mach/irqs.h
  +#include plat/dmtimer.h
  +#include plat/omap_hwmod.h
  +#include plat/omap_device.h
  +#include linux/pm_runtime.h
  +
  +static int early_timer_count __initdata;
  +static int is_early_init __initdata = 1;
  +
  +static char *omap2_dm_source_names[] __initdata = {
  +   sys_ck,
  +   func_32k_ck,
  +   alt_ck,
  +   NULL
  +};
  +static struct clk *omap2_dm_source_clocks[3];
 
  +static char *omap3_dm_source_names[] __initdata = {
  +   sys_ck,
  +   omap_32k_fck,
  +   NULL
  +};
  +static struct clk *omap3_dm_source_clocks[2];
  +
  +static char *omap4_dm_source_names[] __initdata = {
  +   sys_clkin_ck,
  +   sys_32k_ck,
  +   syc_clk_div_ck,
  +   NULL
  +};
  +static struct clk *omap4_dm_source_clocks[3];
  +
  +static struct clk **omap_dm_source_clocks;

 The clock names should all be part of pdata too.   There is no reason
 to keep these SoC specifics in the driver.

OK, I will change.

  +static void omap2_dm_timer_enable(struct platform_device *pdev)
  +{
  +   if (!pdev) {
  +   dev_err(pdev-dev, %s: invalid pdev\n, __func__);
  +   return;
  +   }
  +   pm_runtime_get_sync(pdev-dev);
  +}
  +
  +static void 

RE: [PATCHv2 5/13] dmtimer: hwmod: OMAP: conversion to platform driver

2010-09-01 Thread DebBarma, Tarun Kanti
Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Tuesday, August 24, 2010 4:59 AM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Nayak,
 Rajendra; Paul Walmsley; Tony Lindgren
 Subject: Re: [PATCHv2 5/13] dmtimer: hwmod: OMAP: conversion to platform
 driver

 Tarun Kanti DebBarma tarun.ka...@ti.com writes:

  From: Thara Gopinath th...@ti.com
 
  This essentially involves moving out interrupt and base address
  related info from plat-omap/dmtimer.c and making certain clock related
  functions platform data. This patch also initializes dmtimer driver
  as a earlydriver. This is to enable early timer devices required during
  system boot initialized early.

 no need for 'hwmod' in $SUBJECT

Will change in the next posts!

  incorporated comments:
  (1) use list instead of array to manage timers
  (2) introduced appropriate cleanup in failure paths of probe function
  (3) made spinlock a static variable initialized at bootup so that it
  is available both during early init and later.
  (4) pm_runtime support
  (5) corrected un-even number of pm_runtime_enable() associated with
  early millisecond timers

 This patch needs to be broken up into more pieces.

 The conversion to platform_device should be patch on its own.  The
 addition of runtime PM support followed by the addition of the new timer
 types should also be separate patches.
Will organize better in the next posts!


  Signed-off-by: Partha Basak p-bas...@ti.com
  Signed-off-by: Thara Gopinath th...@ti.com
  Signed-off-by: Rajendra Nayak rna...@ti.com
  Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Kevin Hilman khil...@deeprootsystems.com
  Cc: Tony Lindgren t...@atomide.com
  ---
   arch/arm/plat-omap/dmtimer.c  |  549 +-
 ---
   arch/arm/plat-omap/include/plat/dmtimer.h |   10 +-
   2 files changed, 255 insertions(+), 304 deletions(-)
   mode change 100644 = 100755 arch/arm/plat-omap/dmtimer.c
 
  diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
  index 44bafda..0915a37
  --- a/arch/arm/plat-omap/dmtimer.c
  +++ b/arch/arm/plat-omap/dmtimer.c
  @@ -10,6 +10,12 @@
* Copyright (C) 2009 Texas Instruments
* Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
*
  + * Copyright (C) 2010 Texas Instruments, Inc.
  + * Thara Gopinath th...@ti.com
  + * Tarun Kanti DebBarma tarun.ka...@ti.com
  + * - hwmod support
  + * - omap4 support
  + *
* 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
  @@ -37,9 +43,13 @@
   #include linux/delay.h
   #include linux/io.h
   #include linux/module.h
  +#include linux/slab.h
   #include mach/hardware.h
  +#include linux/pm_runtime.h
   #include plat/dmtimer.h
  +#include plat/omap_device.h
   #include mach/irqs.h
  +#include linux/interrupt.h
 
   /* register offsets */
   #define _OMAP_TIMER_ID_OFFSET  0x00
  @@ -151,144 +161,30 @@
  (_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR  WPSHIFT))
 
   struct omap_dm_timer {
  -   unsigned long phys_base;
  +   int id;
  +   unsigned long fclk_rate;
  int irq;
  -#ifdef CONFIG_ARCH_OMAP2PLUS
  -   struct clk *iclk, *fclk;
  -#endif
  void __iomem *io_base;
  unsigned reserved:1;
  unsigned enabled:1;
  unsigned posted:1;
  +   unsigned is_initialized:1;
  +   struct platform_device *pdev;
  +   struct list_head node;
   };
 
  -static int dm_timer_count;
  -
  -#ifdef CONFIG_ARCH_OMAP1
  -static struct omap_dm_timer omap1_dm_timers[] = {
  -   { .phys_base = 0xfffb1400, .irq = INT_1610_GPTIMER1 },
  -   { .phys_base = 0xfffb1c00, .irq = INT_1610_GPTIMER2 },
  -   { .phys_base = 0xfffb2400, .irq = INT_1610_GPTIMER3 },
  -   { .phys_base = 0xfffb2c00, .irq = INT_1610_GPTIMER4 },
  -   { .phys_base = 0xfffb3400, .irq = INT_1610_GPTIMER5 },
  -   { .phys_base = 0xfffb3c00, .irq = INT_1610_GPTIMER6 },
  -   { .phys_base = 0xfffb7400, .irq = INT_1610_GPTIMER7 },
  -   { .phys_base = 0xfffbd400, .irq = INT_1610_GPTIMER8 },
  -};
  -
  -static const int omap1_dm_timer_count = ARRAY_SIZE(omap1_dm_timers);
  -
  -#else
  -#define omap1_dm_timersNULL
  -#define omap1_dm_timer_count   0
  -#endif /* CONFIG_ARCH_OMAP1 */
  -
  -#ifdef CONFIG_ARCH_OMAP2
  -static struct omap_dm_timer omap2_dm_timers[] = {
  -   { .phys_base = 0x48028000, .irq = INT_24XX_GPTIMER1 },
  -   { .phys_base = 0x4802a000, .irq = INT_24XX_GPTIMER2 },
  -   { .phys_base = 0x48078000, .irq = INT_24XX_GPTIMER3 },
  -   { .phys_base = 0x4807a000, .irq = INT_24XX_GPTIMER4 },
  -   { .phys_base = 0x4807c000, .irq = INT_24XX_GPTIMER5 },
  -   { .phys_base = 0x4807e000, .irq = INT_24XX_GPTIMER6 },
  -   { .phys_base = 0x4808, .irq 

Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling

2010-09-01 Thread Adrian Hunter

kishore kadiyala wrote:

OMAP4 not only have newly added hsmmc registers but also
have registers which were there in OMAP3 and which doesn't
have a common offset deviation compared to OMAP3.

For generic handling, OMAP3 and OMAP4 has different array's of
register offset maintained and right one is choosen during run time.

Cc: Tony Lindgren t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
 arch/arm/mach-omap2/devices.c |   30 +++--
 arch/arm/mach-omap2/hsmmc.c   |6 +
 arch/arm/plat-omap/include/plat/mmc.h |   78 ++-
 drivers/mmc/host/omap_hsmmc.c |  251 +++--
 4 files changed, 218 insertions(+), 147 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..03add6e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -506,6 +506,8 @@ static inline void omap_init_sham(void) { }
 #define MMCHS_SYSCONFIG_SWRESET(1  1)
 #define MMCHS_SYSSTATUS0x0014
 #define MMCHS_SYSSTATUS_RESETDONE  (1  0)
+#define OMAP4_MMCHS_SYSCONFIG_SWRESET  (1  0)
+#define OMAP4_MMCHS_OFFSET 0x100

 static struct platform_device dummy_pdev = {
.dev = {
@@ -528,6 +530,8 @@ static struct platform_device dummy_pdev = {
 static void __init omap_hsmmc_reset(void)
 {
u32 i, nr_controllers;
+   u32 reg_val = 0;
+   u32 reg_off = 0;

if (cpu_is_omap242x())
return;
@@ -562,9 +566,6 @@ static void __init omap_hsmmc_reset(void)
break;
}

-   if (cpu_is_omap44xx())
-   base += OMAP4_MMC_REG_OFFSET;
-
dummy_pdev.id = i;
dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
iclk = clk_get(dev, ick);
@@ -582,9 +583,18 @@ static void __init omap_hsmmc_reset(void)
break;
}

-   omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
-   v = omap_readl(base + MMCHS_SYSSTATUS);
-   while (!(omap_readl(base + MMCHS_SYSSTATUS) 
+   if (cpu_is_omap44xx())
+   reg_val = MMCHS_SYSCONFIG_SWRESET;


Should this be OMAP4_MMCHS_SYSCONFIG_SWRESET?



+   else
+   reg_val = MMCHS_SYSCONFIG_SWRESET;
+   omap_writel(reg_val, base + MMCHS_SYSCONFIG);
+
+   reg_off = MMCHS_SYSSTATUS;
+   if (cpu_is_omap44xx())
+   reg_off += OMAP4_MMCHS_OFFSET;
+   v = omap_readl(base + reg_off);
+
+   while (!(omap_readl(base + reg_off) 
 MMCHS_SYSSTATUS_RESETDONE))
cpu_relax();

@@ -745,13 +755,13 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data 
**mmc_data,
case 3:
if (!cpu_is_omap44xx())
return;
-   base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+   base = OMAP4_MMC4_BASE;
irq = OMAP44XX_IRQ_MMC4;
break;
case 4:
if (!cpu_is_omap44xx())
return;
-   base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+   base = OMAP4_MMC5_BASE;
irq = OMAP44XX_IRQ_MMC5;
break;
default:
@@ -762,10 +772,8 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data 
**mmc_data,
size = OMAP2420_MMC_SIZE;
name = mmci-omap;
} else if (cpu_is_omap44xx()) {
-   if (i  3) {
-   base += OMAP4_MMC_REG_OFFSET;
+   if (i  3)
irq += OMAP44XX_IRQ_GIC_START;
-   }
size = OMAP4_HSMMC_SIZE;
name = mmci-omap-hs;
} else {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c8f647b..d93b704 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -262,6 +262,12 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info 
*controllers)
mmc-slots[0].internal_clock = !c-ext_clock;
mmc-dma_mask = 0x;

+   /* Register offset Mapping */
+   if (cpu_is_omap44xx())
+   mmc-regs_map = (u16 *) omap4_mmc_reg_map;
+   else
+   mmc-regs_map = (u16 *) omap3_mmc_reg_map;
+
mmc-get_context_loss_count = hsmmc_get_context_loss;

mmc-slots[0].switch_pin = c-gpio_cd;
diff --git 

Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling

2010-09-01 Thread kishore kadiyala
On Wed, Sep 1, 2010 at 5:56 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
 kishore kadiyala wrote:

 OMAP4 not only have newly added hsmmc registers but also
 have registers which were there in OMAP3 and which doesn't
 have a common offset deviation compared to OMAP3.

 For generic handling, OMAP3 and OMAP4 has different array's of
 register offset maintained and right one is choosen during run time.

 Cc: Tony Lindgren t...@atomide.com
 Cc: Adrian Hunter adrian.hun...@nokia.com
 Cc: Madhusudhan Chikkature madhu...@ti.com
 Cc: Andrew Morton a...@linux-foundation.org
 Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
 ---
  arch/arm/mach-omap2/devices.c         |   30 +++--
  arch/arm/mach-omap2/hsmmc.c           |    6 +
  arch/arm/plat-omap/include/plat/mmc.h |   78 ++-
  drivers/mmc/host/omap_hsmmc.c         |  251
 +++--
  4 files changed, 218 insertions(+), 147 deletions(-)

 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index 2dbb265..03add6e 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -506,6 +506,8 @@ static inline void omap_init_sham(void) { }
  #define MMCHS_SYSCONFIG_SWRESET                (1  1)
  #define MMCHS_SYSSTATUS                        0x0014
  #define MMCHS_SYSSTATUS_RESETDONE      (1  0)
 +#define OMAP4_MMCHS_SYSCONFIG_SWRESET  (1  0)
 +#define OMAP4_MMCHS_OFFSET             0x100

  static struct platform_device dummy_pdev = {
        .dev = {
 @@ -528,6 +530,8 @@ static struct platform_device dummy_pdev = {
  static void __init omap_hsmmc_reset(void)
  {
        u32 i, nr_controllers;
 +       u32 reg_val = 0;
 +       u32 reg_off = 0;

        if (cpu_is_omap242x())
                return;
 @@ -562,9 +566,6 @@ static void __init omap_hsmmc_reset(void)
                        break;
                }

 -               if (cpu_is_omap44xx())
 -                       base += OMAP4_MMC_REG_OFFSET;
 -
                dummy_pdev.id = i;
                dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
                iclk = clk_get(dev, ick);
 @@ -582,9 +583,18 @@ static void __init omap_hsmmc_reset(void)
                        break;
                }

 -               omap_writel(MMCHS_SYSCONFIG_SWRESET, base +
 MMCHS_SYSCONFIG);
 -               v = omap_readl(base + MMCHS_SYSSTATUS);
 -               while (!(omap_readl(base + MMCHS_SYSSTATUS) 
 +               if (cpu_is_omap44xx())
 +                       reg_val = MMCHS_SYSCONFIG_SWRESET;

 Should this be OMAP4_MMCHS_SYSCONFIG_SWRESET?

Yes, it should be as mentioned [Late night post's take's away quality :) ] ,
will correct it and repost .

snip

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


Re: [PATCH 2/2] OMAP: omap_device: make all devices a child of a new omap_bus device

2010-09-01 Thread Kevin Hilman
Gopinath, Thara th...@ti.com writes:

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Wednesday, September 01, 2010 5:33 AM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com
Subject: [PATCH 2/2] OMAP: omap_device: make all devices a child of a new 
omap_bus device

From: Kevin Hilman khil...@ti.com

In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new omap_bus device.

Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.

Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.

In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform

 Hello Kevin,

 Couple of minor queries/comments below.

Hi Thara, 

Thanks for the review.


Signed-off-by: Kevin Hilman khil...@ti.com
---
 arch/arm/plat-omap/include/plat/omap_device.h |2 ++
 arch/arm/plat-omap/omap_device.c  |   18 ++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-
omap/include/plat/omap_device.h
index bad4c3d..26d0c10 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -36,6 +36,8 @@

 #include plat/omap_hwmod.h

+extern struct device omap_bus;
+

 Why is this extern declaration needed? Is it later on
 to check in runtime pm code pdev-dev.parent == omap_bus??

Yes.

 /* omap_device._state values */
 #define OMAP_DEVICE_STATE_UNKNOWN   0
 #define OMAP_DEVICE_STATE_ENABLED   1
diff --git a/arch/arm/plat-omap/omap_device.c 
b/arch/arm/plat-omap/omap_device.c
index 7f05f49..3e215fa 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -463,8 +463,11 @@ int omap_early_device_register(struct omap_device *od)
  */
 int omap_device_register(struct omap_device *od)
 {
+struct platform_device *pdev = od-pdev;
+
 pr_debug(omap_device: %s: registering\n, od-pdev.name);

+pdev-dev.parent = omap_bus;

 What if device_register(omap_bus) has returned an
 error? Do we still go ahead with assigning omap_bus
 as parent?

Good point.  I followed the lead of the platform_bus here which does the
same thing, and bascially assumes that device_register() does not fail.

I'll take a look to see if this could be handled cleaner.  Thanks.

 return platform_device_register(od-pdev);
 }

@@ -737,3 +740,18 @@ int omap_device_enable_clocks(struct omap_device *od)
 /* XXX pass along return value here? */
 return 0;
 }
+
+struct device omap_bus = {
+.init_name  = omap,
+};
+
+static int __init omap_device_init(void)
+{
+int error = 0;

 Is the initialization to 0 needed?

Nope

+
+printk(%s:\n, __func__);

 Spurious printk???

Yup.

Oops, I cleaned those two up locally but sent the wrong version.

Thanks for catching,

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


Re: [PATCHv2 6/13] dmtimer: hwmod: OMAP2PLUS: device registration

2010-09-01 Thread Kevin Hilman
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:

[...]

  +static void omap2_dm_timer_enable(struct platform_device *pdev)
  +{
  +   if (!pdev) {
  +   dev_err(pdev-dev, %s: invalid pdev\n, __func__);
  +   return;
  +   }
  +   pm_runtime_get_sync(pdev-dev);
  +}
  +
  +static void omap2_dm_timer_disable(struct platform_device *pdev)
  +{
  +   if (!pdev) {
  +   dev_err(pdev-dev, %s: invalid pdev\n, __func__);
  +   return;
  +   }
  +   pm_runtime_put_sync(pdev-dev);
  +}

 There is no need for these functions.  Driver should be calling runtime
 PM API directly.


 In that case, driver will have to make call by directly accessing
 acquired timer's internal variables as shown below.
 pm_runtime_put_sync(timer-pdev-dev); 

 However, I believe we would like other drivers' perform all operations
 on acquired timers through exported APIs and keep the
 pm_runtime_put_sync() call internal to exported APIs as is the case
 current implementation.

 Let me know if I am missing anything here!!

These new functions are not part of the exported API.  You have made
them static, and part of the device layer.

These are created as wrappers to pm_runtime_* API which are then called
by the driver layer.  What I suggest is not creating these functions
(and the pdata- function pointers to wrap them) but instead calling the
runtime PM api directly instead of using the pdata- function pointers.

Kevin

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


Re: [PATCH] I2C: Fix for suspend/resume issue in i2c-core

2010-09-01 Thread Kevin Hilman
[removed non-OMAP folks]

Vishwanath BS vishwanath...@ti.com writes:

 In current i2c core driver, pm_runtime_set_active call from 
 i2c_device_pm_resume
 is not balanced by pm_runtime_set_suspended call from i2c_device_pm_suspend.
 pm_runtime_set_active called from resume path will increase the child_count of
 the device's parent. However, matching pm_runtime_set_suspended is not called
 in suspend routine because of which child_count of the device's parent
 is not balanced, preventing the parent device to idle.
 Issue has been fixed by adding pm_runtime_set_suspended call inside suspend
 reoutine which will make sure that child_counts are balanced.
 This fix has been tested on OMAP4430.

FYI... for OMAP folks.  Now that this is queued for upstream, it will be
included in my pm-backports branch[1] and included in the PM branch until
it gets merged upstream.

Thanks Vishwa/Partha for getting this merged upstream.

Kevin

[1] for a description of the various branches that make up the PM
branch, please see 'What makes up the PM branch' section of the OMAP PM
wiki:

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


Re: [PATCH] OMAP: hwmod: separate list locking and hwmod hardware locking

2010-09-01 Thread Paul Walmsley
On Wed, 11 Aug 2010, Kevin Hilman wrote:

 From: Kevin Hilman khil...@ti.com
 
 Currently omap_hwmod_mutex is being used to protect both the list
 access/modification and concurrent access to hwmod functions.  This
 patch separates these two types of locking.
 
 First, omap_hwmod_mutex is used only to protect access and
 modification of omap_hwmod_list.  Also cleaned up some comments
 referring to this mutex that are no longer needed.
 
 Then, for protecting concurrent access to hwmod functions, use a
 per-hwmod mutex.  This protects concurrent access to a single hwmod,
 but would allow concurrent access to different hwmods.
 
 Signed-off-by: Kevin Hilman khil...@deeprootsystems.com

I've added some structure kerneldoc for the new field, prefixed its name 
with an underscore (to indicate that it is an internal structure field 
that should not be externally initialized or touched), fixed a whitespace 
problem, and queued this patch for 2.6.36 in my 'hwmod_2.6.36' branch.  
Updated patch below.

Thanks Kevin,


- Paul

From b6394ba8ff2ffcd1a6dd0e680d29c5ce9f850dd5 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Wed, 1 Sep 2010 11:07:11 -0600
Subject: [PATCH] [PATCH] OMAP: hwmod: separate list locking and hwmod hardware 
locking

Currently omap_hwmod_mutex is being used to protect both the list
access/modification and concurrent access to hwmod functions.  This
patch separates these two types of locking.

First, omap_hwmod_mutex is used only to protect access and
modification of omap_hwmod_list.  Also cleaned up some comments
referring to this mutex that are no longer needed.

Then, for protecting concurrent access to hwmod functions, use a
per-hwmod mutex.  This protects concurrent access to a single hwmod,
but would allow concurrent access to different hwmods.

Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
[p...@pwsan.com: added structure documentation; changed mutex variable
 name]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/omap_hwmod.c |   62 -
 arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +
 2 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5bb25e3..6676fdd 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -767,10 +767,10 @@ static struct omap_hwmod *_lookup(const char *name)
  * @data: not used; pass NULL
  *
  * Called by omap_hwmod_late_init() (after omap2_clk_init()).
- * Resolves all clock names embedded in the hwmod.  Must be called
- * with omap_hwmod_mutex held.  Returns -EINVAL if the omap_hwmod
- * has not yet been registered or if the clocks have already been
- * initialized, 0 on success, or a non-zero error on failure.
+ * Resolves all clock names embedded in the hwmod.  Returns -EINVAL if
+ * the omap_hwmod has not yet been registered or if the clocks have
+ * already been initialized, 0 on success, or a non-zero error on
+ * failure.
  */
 static int _init_clocks(struct omap_hwmod *oh, void *data)
 {
@@ -838,10 +838,9 @@ static int _wait_target_ready(struct omap_hwmod *oh)
  * @oh: struct omap_hwmod *
  *
  * Resets an omap_hwmod @oh via the OCP_SYSCONFIG bit.  hwmod must be
- * enabled for this to work.  Must be called with omap_hwmod_mutex
- * held.  Returns -EINVAL if the hwmod cannot be reset this way or if
- * the hwmod is in the wrong state, -ETIMEDOUT if the module did not
- * reset in time, or 0 upon success.
+ * enabled for this to work.  Returns -EINVAL if the hwmod cannot be
+ * reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
+ * the module did not reset in time, or 0 upon success.
  */
 static int _reset(struct omap_hwmod *oh)
 {
@@ -891,9 +890,8 @@ static int _reset(struct omap_hwmod *oh)
  * @oh: struct omap_hwmod *
  *
  * Enables an omap_hwmod @oh such that the MPU can access the hwmod's
- * register target.  Must be called with omap_hwmod_mutex held.
- * Returns -EINVAL if the hwmod is in the wrong state or passes along
- * the return value of _wait_target_ready().
+ * register target.  Returns -EINVAL if the hwmod is in the wrong
+ * state or passes along the return value of _wait_target_ready().
  */
 int _omap_hwmod_enable(struct omap_hwmod *oh)
 {
@@ -1004,11 +1002,10 @@ static int _shutdown(struct omap_hwmod *oh)
  * @skip_setup_idle_p: do not idle hwmods at the end of the fn if 1
  *
  * Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh
- * OCP_SYSCONFIG register.  Must be called with omap_hwmod_mutex held.
- * @skip_setup_idle is intended to be used on a system that will not
- * call omap_hwmod_enable() to enable devices (e.g., a system without
- * PM runtime).  Returns -EINVAL if the hwmod is in the wrong state or
- * returns 0.
+ * OCP_SYSCONFIG register.  @skip_setup_idle is intended to be used on
+ * a system that will not call omap_hwmod_enable() to enable devices
+ * (e.g., a system without PM runtime).  Returns 

[PATCH v2 1/2] Revert OMAP: omap_device: add omap_device_is_valid()

2010-09-01 Thread Kevin Hilman
From: Kevin Hilman khil...@ti.com

This reverts commit 0007122ad85cc36b1c18c0b59344093ca210d206.

The dereference method of checking for a valid omap_device when
wrapping a platform_device is rather unsafe and dangerous.

Instead, a better way of checking for a valid omap-device is
to use a common parent device for all omap_devices, then a check
can simply be made using the device parent.  The only user of this
API was the initial version of the runtime PM core for OMAP.  This
has now been switched to check device parent, so there are no more
users of this API.

Signed-off-by: Kevin Hilman khil...@ti.com
---
 arch/arm/plat-omap/include/plat/omap_device.h |2 --
 arch/arm/plat-omap/omap_device.c  |   20 
 2 files changed, 0 insertions(+), 22 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
b/arch/arm/plat-omap/include/plat/omap_device.h
index 25cd9ac..bad4c3d 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -62,7 +62,6 @@
  *
  */
 struct omap_device {
-   u32 magic;
struct platform_device  pdev;
struct omap_hwmod   **hwmods;
struct omap_device_pm_latency   *pm_lats;
@@ -82,7 +81,6 @@ int omap_device_shutdown(struct platform_device *pdev);
 
 /* Core code interface */
 
-bool omap_device_is_valid(struct omap_device *od);
 int omap_device_count_resources(struct omap_device *od);
 int omap_device_fill_resources(struct omap_device *od, struct resource *res);
 
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..7f05f49 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -90,12 +90,6 @@
 #define USE_WAKEUP_LAT 0
 #define IGNORE_WAKEUP_LAT  1
 
-/*
- * OMAP_DEVICE_MAGIC: used to determine whether a struct omap_device
- * obtained via container_of() is in fact a struct omap_device
- */
-#define OMAP_DEVICE_MAGIC   0xf00dcafe
-
 /* Private functions */
 
 /**
@@ -414,8 +408,6 @@ struct omap_device *omap_device_build_ss(const char 
*pdev_name, int pdev_id,
od-pm_lats = pm_lats;
od-pm_lats_cnt = pm_lats_cnt;
 
-   od-magic = OMAP_DEVICE_MAGIC;
-
if (is_early_device)
ret = omap_early_device_register(od);
else
@@ -627,18 +619,6 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
 }
 
 /**
- * omap_device_is_valid - Check if pointer is a valid omap_device
- * @od: struct omap_device *
- *
- * Return whether struct omap_device pointer @od points to a valid
- * omap_device.
- */
-bool omap_device_is_valid(struct omap_device *od)
-{
-   return (od  od-magic == OMAP_DEVICE_MAGIC);
-}
-
-/**
  * omap_device_get_pwrdm - return the powerdomain * associated with @od
  * @od: struct omap_device *
  *
-- 
1.7.2.1

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


[PATCH v2 2/2] OMAP: omap_device: make all devices a child of a new omap_bus device

2010-09-01 Thread Kevin Hilman
From: Kevin Hilman khil...@ti.com

In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new omap_bus device.

Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.

Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.

In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform

Signed-off-by: Kevin Hilman khil...@ti.com
---
since v1:
- misc. cleanup as suggested by Thara.  But, chose to leave out 
  the handling of a failed device_register(), since the failure
  of a parent-less device_register() is extrememly unlikely and
  is not handled for the platform_bus either.  


 arch/arm/plat-omap/include/plat/omap_device.h |2 ++
 arch/arm/plat-omap/omap_device.c  |   11 +++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
b/arch/arm/plat-omap/include/plat/omap_device.h
index bad4c3d..26d0c10 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -36,6 +36,8 @@
 
 #include plat/omap_hwmod.h
 
+extern struct device omap_bus;
+
 /* omap_device._state values */
 #define OMAP_DEVICE_STATE_UNKNOWN  0
 #define OMAP_DEVICE_STATE_ENABLED  1
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7f05f49..8b8f006 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -465,6 +465,7 @@ int omap_device_register(struct omap_device *od)
 {
pr_debug(omap_device: %s: registering\n, od-pdev.name);
 
+   od-pdev.dev.parent = omap_bus;
return platform_device_register(od-pdev);
 }
 
@@ -737,3 +738,13 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
 }
+
+struct device omap_bus = {
+   .init_name  = omap,
+};
+
+static int __init omap_device_init(void)
+{
+   return device_register(omap_bus);
+}
+core_initcall(omap_device_init);
-- 
1.7.2.1

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


Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-09-01 Thread mike
On Tue, Aug 31, 2010 at 09:59:44AM +0100, David Vrabel wrote:
 On 27/08/2010 20:22, Chris Ball wrote:
  Hi David,
  
  On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote:
  These patches add support for SDIO cards to the omap_hsmmc driver.
  Power management changes to prevent SDIO cards from being turned off
  and losing all state, and card interrupts.
 
  I've been unable to test these exact patches as I only have an N900 for 
  testing and the N900 support in mainline is incomplete.
 
  Changes since v1:
  - (hopefully) get all cards working again by removing a second call to
read MMCi_STAT in the interrupt handler.
  - flush posted writes after enabling/disabling SDIO interrupts.
  - tweak the FIXME commit on disabling FCLK to better match what really
going on (at least I think so anyway).
 
  David Vrabel (2):
mmc: omap_hsmmc: don't turn SDIO cards off when idle
mmc: omap_hsmmc: enable SDIO card interrupts
  
  Looks like this patchset wasn't merged.  Mike Rapoport replied with a 
  fix for libertas.  Would you like to resubmit it?
 
 I thought Madhu had picked this up and was going to submit it.
 
 Regardless of whether that is the case, I think it needs to be submitted
 by someone who can run mainline kernels (I can't) and ideally someone
 who can test it with SDIO cards.

I'll try to update it to the recent kernel in the next few days.

 David

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


[PATCH v5 0/7] native wl1271 support on ZOOM

2010-09-01 Thread Ohad Ben-Cohen
This patchset adds wl1271 support on ZOOM2/3 boards.

Only basic support is included; MMC power manipulation part is submitted 
separately as Runtime PM migration.

Changes since v4:
- Introduce a simple (yet safe) mechanism to pass platform-specific data to the 
driver, as suggested by Russell King. Currently only a single device is 
supported; multi-device support will be introduced only when/if required

Patches are based on 2.6.36-rc3 and tested on ZOOM3.

Thanks,

Ohad Ben-Cohen (7):
  wireless: wl1271: make wl12xx.h common to both spi and sdio
  wireless: wl1271: support return value for the set power func
  wireless: wl12xx: add platform data passing support
  wireless: wl1271: take irq info from private board data
  wireless: wl1271: make ref_clock configurable by board
  omap: zoom: add fixed regulator device for wlan
  omap: zoom: add mmc3/wl1271 device support

 arch/arm/mach-omap2/board-zoom-peripherals.c   |   54 
 drivers/net/wireless/Makefile  |2 +
 drivers/net/wireless/wl12xx/Kconfig|5 ++-
 drivers/net/wireless/wl12xx/wl1251_sdio.c  |2 +-
 drivers/net/wireless/wl12xx/wl1251_spi.c   |2 +-
 drivers/net/wireless/wl12xx/wl1271.h   |3 +-
 drivers/net/wireless/wl12xx/wl1271_boot.c  |9 ++--
 drivers/net/wireless/wl12xx/wl1271_boot.h  |1 -
 drivers/net/wireless/wl12xx/wl1271_io.h|9 ++-
 drivers/net/wireless/wl12xx/wl1271_main.c  |4 +-
 drivers/net/wireless/wl12xx/wl1271_sdio.c  |   19 ---
 drivers/net/wireless/wl12xx/wl1271_spi.c   |8 ++-
 drivers/net/wireless/wl12xx/wl12xx_platform_data.c |   31 +++
 include/linux/spi/wl12xx.h |   34 
 include/linux/wl12xx.h |   38 ++
 15 files changed, 164 insertions(+), 57 deletions(-)
 create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c
 delete mode 100644 include/linux/spi/wl12xx.h
 create mode 100644 include/linux/wl12xx.h

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


[PATCH v5 1/7] wireless: wl1271: make wl12xx.h common to both spi and sdio

2010-09-01 Thread Ohad Ben-Cohen
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
 drivers/net/wireless/wl12xx/wl1251_spi.c  |2 +-
 drivers/net/wireless/wl12xx/wl1271_spi.c  |2 +-
 include/linux/spi/wl12xx.h|   34 -
 include/linux/wl12xx.h|   34 +
 5 files changed, 37 insertions(+), 37 deletions(-)
 delete mode 100644 include/linux/spi/wl12xx.h
 create mode 100644 include/linux/wl12xx.h

diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c 
b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index b901b61..a319df1 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -24,7 +24,7 @@
 #include linux/mmc/sdio_func.h
 #include linux/mmc/sdio_ids.h
 #include linux/platform_device.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
 #include linux/irq.h
 
 #include wl1251.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c 
b/drivers/net/wireless/wl12xx/wl1251_spi.c
index 27fdfaa..a6faf3e 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -26,7 +26,7 @@
 #include linux/slab.h
 #include linux/crc7.h
 #include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
 
 #include wl1251.h
 #include wl1251_reg.h
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c 
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 4cb99c5..c3fdab7 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -25,7 +25,7 @@
 #include linux/module.h
 #include linux/crc7.h
 #include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
 #include linux/slab.h
 
 #include wl1271.h
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
deleted file mode 100644
index a223ecb..000
--- a/include/linux/spi/wl12xx.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * This file is part of wl12xx
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Kalle Valo kalle.v...@nokia.com
- *
- * 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
- *
- */
-
-#ifndef _LINUX_SPI_WL12XX_H
-#define _LINUX_SPI_WL12XX_H
-
-struct wl12xx_platform_data {
-   void (*set_power)(bool enable);
-   /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
-   int irq;
-   bool use_eeprom;
-};
-
-#endif
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
new file mode 100644
index 000..137ac89
--- /dev/null
+++ b/include/linux/wl12xx.h
@@ -0,0 +1,34 @@
+/*
+ * This file is part of wl12xx
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Contact: Kalle Valo kalle.v...@nokia.com
+ *
+ * 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
+ *
+ */
+
+#ifndef _LINUX_WL12XX_H
+#define _LINUX_WL12XX_H
+
+struct wl12xx_platform_data {
+   void (*set_power)(bool enable);
+   /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
+   int irq;
+   bool use_eeprom;
+};
+
+#endif
-- 
1.7.0.4

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


[PATCH v5 2/7] wireless: wl1271: support return value for the set power func

2010-09-01 Thread Ohad Ben-Cohen
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as bringing up
(and down) sdio functions.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 drivers/net/wireless/wl12xx/wl1271.h  |2 +-
 drivers/net/wireless/wl12xx/wl1271_io.h   |9 ++---
 drivers/net/wireless/wl12xx/wl1271_main.c |4 +++-
 drivers/net/wireless/wl12xx/wl1271_sdio.c |4 +++-
 drivers/net/wireless/wl12xx/wl1271_spi.c  |4 +++-
 5 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/wl12xx/wl1271.h 
b/drivers/net/wireless/wl12xx/wl1271.h
index dd3cee6..faa5925 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -313,7 +313,7 @@ struct wl1271_if_operations {
 bool fixed);
void (*reset)(struct wl1271 *wl);
void (*init)(struct wl1271 *wl);
-   void (*power)(struct wl1271 *wl, bool enable);
+   int (*power)(struct wl1271 *wl, bool enable);
struct device* (*dev)(struct wl1271 *wl);
void (*enable_irq)(struct wl1271 *wl);
void (*disable_irq)(struct wl1271 *wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_io.h 
b/drivers/net/wireless/wl12xx/wl1271_io.h
index bc806c7..c1f92e6 100644
--- a/drivers/net/wireless/wl12xx/wl1271_io.h
+++ b/drivers/net/wireless/wl12xx/wl1271_io.h
@@ -144,10 +144,13 @@ static inline void wl1271_power_off(struct wl1271 *wl)
clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
 }
 
-static inline void wl1271_power_on(struct wl1271 *wl)
+static inline int wl1271_power_on(struct wl1271 *wl)
 {
-   wl-if_ops-power(wl, true);
-   set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+   int ret = wl-if_ops-power(wl, true);
+   if (ret == 0)
+   set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+
+   return ret;
 }
 
 
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c 
b/drivers/net/wireless/wl12xx/wl1271_main.c
index 9d68f00..e6e0852 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -621,7 +621,9 @@ static int wl1271_chip_wakeup(struct wl1271 *wl)
int ret = 0;
 
msleep(WL1271_PRE_POWER_ON_SLEEP);
-   wl1271_power_on(wl);
+   ret = wl1271_power_on(wl);
+   if (ret  0)
+   goto out;
msleep(WL1271_POWER_ON_SLEEP);
wl1271_io_reset(wl);
wl1271_io_init(wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c 
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 7059b5c..c41293a 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -152,7 +152,7 @@ static void wl1271_sdio_raw_write(struct wl1271 *wl, int 
addr, void *buf,
 
 }
 
-static void wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
 {
struct sdio_func *func = wl_to_func(wl);
 
@@ -167,6 +167,8 @@ static void wl1271_sdio_set_power(struct wl1271 *wl, bool 
enable)
sdio_disable_func(func);
sdio_release_host(func);
}
+
+   return 0;
 }
 
 static struct wl1271_if_operations sdio_ops = {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c 
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index c3fdab7..de56d8d 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -312,10 +312,12 @@ static irqreturn_t wl1271_irq(int irq, void *cookie)
return IRQ_HANDLED;
 }
 
-static void wl1271_spi_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_spi_set_power(struct wl1271 *wl, bool enable)
 {
if (wl-set_power)
wl-set_power(enable);
+
+   return 0;
 }
 
 static struct wl1271_if_operations spi_ops = {
-- 
1.7.0.4

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


[PATCH v5 3/7] wireless: wl12xx: add platform data passing support

2010-09-01 Thread Ohad Ben-Cohen
Add a simple mechanism to pass platform data to the
SDIO instances of wl12xx.

This way there is no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.

Originally proposed by Russell King.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 drivers/net/wireless/Makefile  |2 +
 drivers/net/wireless/wl12xx/Kconfig|5 ++-
 drivers/net/wireless/wl12xx/wl12xx_platform_data.c |   31 
 include/linux/wl12xx.h |3 ++
 4 files changed, 40 insertions(+), 1 deletions(-)
 create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c

diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 5d4ce4d..85af697 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -50,5 +50,7 @@ obj-$(CONFIG_ATH_COMMON)  += ath/
 obj-$(CONFIG_MAC80211_HWSIM)   += mac80211_hwsim.o
 
 obj-$(CONFIG_WL12XX)   += wl12xx/
+# small builtin driver bit
+obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
 
 obj-$(CONFIG_IWM)  += iwmc3200wifi/
diff --git a/drivers/net/wireless/wl12xx/Kconfig 
b/drivers/net/wireless/wl12xx/Kconfig
index 2f98058..4a8bb25 100644
--- a/drivers/net/wireless/wl12xx/Kconfig
+++ b/drivers/net/wireless/wl12xx/Kconfig
@@ -74,4 +74,7 @@ config WL1271_SDIO
  If you choose to build a module, it'll be called
  wl1271_sdio. Say N if unsure.
 
-
+config WL12XX_PLATFORM_DATA
+   bool
+   depends on WL1271_SDIO != n
+   default y
diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c 
b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
new file mode 100644
index 000..e00973b
--- /dev/null
+++ b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
@@ -0,0 +1,31 @@
+#include linux/module.h
+#include linux/wl12xx.h
+
+static struct wl12xx_platform_data *platform_data;
+
+int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
+{
+   if (platform_data)
+   return -EBUSY;
+   if (!data)
+   return -EINVAL;
+
+   platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+   if (!platform_data)
+   return -ENOMEM;
+
+   return 0;
+}
+
+int wl12xx_get_platform_data(struct wl12xx_platform_data *data)
+{
+   if (!platform_data)
+   return -ENODEV;
+   if (!data)
+   return -EINVAL;
+
+   memcpy(data, platform_data, sizeof(*data));
+
+   return 0;
+}
+EXPORT_SYMBOL(wl12xx_get_platform_data);
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 137ac89..3e33ae1 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -31,4 +31,7 @@ struct wl12xx_platform_data {
bool use_eeprom;
 };
 
+int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
+int wl12xx_get_platform_data(struct wl12xx_platform_data *data);
+
 #endif
-- 
1.7.0.4

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


[PATCH v5 4/7] wireless: wl1271: take irq info from private board data

2010-09-01 Thread Ohad Ben-Cohen
Remove the hard coded irq information, and instead take
the irq information from the board's platform data.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 drivers/net/wireless/wl12xx/wl1271_sdio.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c 
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index c41293a..7f4461c 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -29,14 +29,12 @@
 #include linux/mmc/sdio_ids.h
 #include linux/mmc/card.h
 #include linux/gpio.h
+#include linux/wl12xx.h
 
 #include wl1271.h
 #include wl12xx_80211.h
 #include wl1271_io.h
 
-
-#define RX71_WL1271_IRQ_GPIO   42
-
 #ifndef SDIO_VENDOR_ID_TI
 #define SDIO_VENDOR_ID_TI  0x0097
 #endif
@@ -186,6 +184,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
struct ieee80211_hw *hw;
+   struct wl12xx_platform_data wlan_data;
struct wl1271 *wl;
int ret;
 
@@ -205,13 +204,14 @@ static int __devinit wl1271_probe(struct sdio_func *func,
/* Grab access to FN0 for ELP reg. */
func-card-quirks |= MMC_QUIRK_LENIENT_FN0;
 
-   wl-irq = gpio_to_irq(RX71_WL1271_IRQ_GPIO);
-   if (wl-irq  0) {
-   ret = wl-irq;
-   wl1271_error(could not get irq!);
+   ret = wl12xx_get_platform_data(wlan_data);
+   if (ret) {
+   wl1271_error(missing wlan data (needed for irq/ref_clk)!);
goto out_free;
}
 
+   wl-irq = wlan_data.irq;
+
ret = request_irq(wl-irq, wl1271_irq, 0, DRIVER_NAME, wl);
if (ret  0) {
wl1271_error(request_irq() failed: %d, ret);
-- 
1.7.0.4

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


[PATCH v5 5/7] wireless: wl1271: make ref_clock configurable by board

2010-09-01 Thread Ohad Ben-Cohen
The wl1271 device is using a reference clock that may change
between board to board.

Make the ref_clock parameter configurable by the board
files that set up the device, instead of having a hard coded
value in the driver source itself.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 drivers/net/wireless/wl12xx/wl1271.h  |1 +
 drivers/net/wireless/wl12xx/wl1271_boot.c |9 +
 drivers/net/wireless/wl12xx/wl1271_boot.h |1 -
 drivers/net/wireless/wl12xx/wl1271_sdio.c |1 +
 drivers/net/wireless/wl12xx/wl1271_spi.c  |2 ++
 include/linux/wl12xx.h|1 +
 6 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/wl12xx/wl1271.h 
b/drivers/net/wireless/wl12xx/wl1271.h
index faa5925..4134f44 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -330,6 +330,7 @@ struct wl1271 {
 
void (*set_power)(bool enable);
int irq;
+   int ref_clock;
 
spinlock_t wl_lock;
 
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c 
b/drivers/net/wireless/wl12xx/wl1271_boot.c
index f36430b..95c636a 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -457,17 +457,18 @@ int wl1271_boot(struct wl1271 *wl)
 {
int ret = 0;
u32 tmp, clk, pause;
+   int ref_clock = wl-ref_clock;
 
wl1271_boot_hw_version(wl);
 
-   if (REF_CLOCK == 0 || REF_CLOCK == 2 || REF_CLOCK == 4)
+   if (ref_clock == 0 || ref_clock == 2 || ref_clock == 4)
/* ref clk: 19.2/38.4/38.4-XTAL */
clk = 0x3;
-   else if (REF_CLOCK == 1 || REF_CLOCK == 3)
+   else if (ref_clock == 1 || ref_clock == 3)
/* ref clk: 26/52 */
clk = 0x5;
 
-   if (REF_CLOCK != 0) {
+   if (ref_clock != 0) {
u16 val;
/* Set clock type (open drain) */
val = wl1271_top_reg_read(wl, OCP_REG_CLK_TYPE);
@@ -516,7 +517,7 @@ int wl1271_boot(struct wl1271 *wl)
wl1271_debug(DEBUG_BOOT, clk2 0x%x, clk);
 
/* 2 */
-   clk |= (REF_CLOCK  1)  4;
+   clk |= (ref_clock  1)  4;
wl1271_write32(wl, DRPW_SCRATCH_START, clk);
 
wl1271_set_partition(wl, part_table[PART_WORK]);
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.h 
b/drivers/net/wireless/wl12xx/wl1271_boot.h
index f829699..f73b0b1 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.h
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.h
@@ -46,7 +46,6 @@ struct wl1271_static_data {
 /* delay between retries */
 #define INIT_LOOP_DELAY 50
 
-#define REF_CLOCK2
 #define WU_COUNTER_PAUSE_VAL 0x3FF
 #define WELP_ARM_COMMAND_VAL 0x4
 
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c 
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 7f4461c..824b9e8 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -211,6 +211,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
}
 
wl-irq = wlan_data.irq;
+   wl-ref_clock = wlan_data.board_ref_clock;
 
ret = request_irq(wl-irq, wl1271_irq, 0, DRIVER_NAME, wl);
if (ret  0) {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c 
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index de56d8d..ced0a9e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -372,6 +372,8 @@ static int __devinit wl1271_probe(struct spi_device *spi)
goto out_free;
}
 
+   wl-ref_clock = pdata-board_ref_clock;
+
wl-irq = spi-irq;
if (wl-irq  0) {
wl1271_error(irq missing in platform data);
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 3e33ae1..0116d88 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -29,6 +29,7 @@ struct wl12xx_platform_data {
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
+   int board_ref_clock;
 };
 
 int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
-- 
1.7.0.4

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


[PATCH v5 7/7] omap: zoom: add mmc3/wl1271 device support

2010-09-01 Thread Ohad Ben-Cohen
Add MMC3 support on ZOOM, which is hardwired to the wl1271 device.

The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 arch/arm/mach-omap2/board-zoom-peripherals.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c 
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index de88635..7ee5663 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -17,6 +17,7 @@
 #include linux/i2c/twl.h
 #include linux/regulator/machine.h
 #include linux/regulator/fixed.h
+#include linux/wl12xx.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -29,6 +30,7 @@
 #include hsmmc.h
 
 #define OMAP_ZOOM_WLAN_PMENA_GPIO  (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
 
 /* Zoom2 has Qwerty keyboard*/
 static int board_keymap[] = {
@@ -185,6 +187,12 @@ static struct platform_device omap_vwlan_device = {
},
 };
 
+struct wl12xx_platform_data omap_zoom_wlan_data = {
+   .irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+   /* ZOOM ref clock is 26 MHz */
+   .board_ref_clock = 1,
+};
+
 static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name   = external,
@@ -202,6 +210,14 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable   = true,
.power_saving   = true,
},
+   {
+   .name   = wl1271,
+   .mmc= 3,
+   .wires  = 4,
+   .gpio_wp= -EINVAL,
+   .gpio_cd= -EINVAL,
+   .nonremovable   = true,
+   },
{}  /* Terminator */
 };
 
@@ -313,6 +329,9 @@ static void enable_board_wakeup_source(void)
 
 void __init zoom_peripherals_init(void)
 {
+   if (wl12xx_set_platform_data(omap_zoom_wlan_data))
+   pr_err(error setting wl12xx data\n);
+
omap_i2c_init();
platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
-- 
1.7.0.4

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


[PATCH v5 6/7] omap: zoom: add fixed regulator device for wlan

2010-09-01 Thread Ohad Ben-Cohen
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.

Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
 arch/arm/mach-omap2/board-zoom-peripherals.c |   35 ++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c 
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..de88635 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
 #include linux/gpio.h
 #include linux/i2c/twl.h
 #include linux/regulator/machine.h
+#include linux/regulator/fixed.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -27,6 +28,8 @@
 #include mux.h
 #include hsmmc.h
 
+#define OMAP_ZOOM_WLAN_PMENA_GPIO  (101)
+
 /* Zoom2 has Qwerty keyboard*/
 static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,11 @@ static struct regulator_consumer_supply zoom_vmmc2_supply 
= {
.supply = vmmc,
 };
 
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+   .supply = vmmc,
+   .dev_name   = mmci-omap-hs.2,
+};
+
 /* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
 static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +159,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies  = zoom_vsim_supply,
 };
 
+static struct regulator_init_data zoom_vmmc3 = {
+   .constraints = {
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies = 1,
+   .consumer_supplies = zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+   .supply_name = vwl1271,
+   .microvolts = 180, /* 1.8V */
+   .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+   .startup_delay = 7, /* 70msec */
+   .enable_high = 1,
+   .enabled_at_boot = 0,
+   .init_data = zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+   .name   = reg-fixed-voltage,
+   .id = 1,
+   .dev = {
+   .platform_data = zoom_vwlan,
+   },
+};
+
 static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name   = external,
@@ -280,6 +314,7 @@ static void enable_board_wakeup_source(void)
 void __init zoom_peripherals_init(void)
 {
omap_i2c_init();
+   platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
 }
-- 
1.7.0.4

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


Re: [PATCH 3/3] OMAP: hwmod: Force a softreset during _setup

2010-09-01 Thread Paul Walmsley
On Mon, 23 Aug 2010, Cousson, Benoit wrote:

 Here is a small patch that should fix that issue:
 The approach is quite basic, I'm just enabling all the optional clocks if the
 flag is set.
 
 Could you give it a try?

This approach seems good.  Maybe we should add a flags field in 
struct omap_hwmod_opt_clks to indicate that a particular clock needs to be 
enabled during the reset process?  That way the specific clocks that are 
necessary can be enabled, rather than all of the clocks.

One other general comment on an earlier part of this discussion: the goal 
is to reset almost every module during boot: this is to clear any bogus 
configurations that the bootloader may have written to the hardware.  The 
goal is to have a consistent, known hardware configuration in the kernel, 
independent of the bootloader.

Partha, does this patch work for you?

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


Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.

2010-09-01 Thread Kevin Hilman
Thara Gopinath th...@ti.com writes:

 This patch introduces a user list of devices associated with each
 voltage domain instance. The user list is implemented using plist
 structure with priority node populated with the voltage values.
 This patch also adds an API which will take in a device and
 requested voltage as parameters, adds the info to the user list
 and returns back the maximum voltage requested by all the user
 devices. This can be used anytime to get the voltage that the
 voltage domain instance can be transitioned into.

 Signed-off-by: Thara Gopinath th...@ti.com

Looking closer at this, keeping track of a list of devices and
constraints is what the regulator framework does as well.  

Before we get too far down this path, we need to start working with
Thomas Petazzoni to better understand how we can use the regulator
framework for much of the management levels of the voltage layer.

I'd rather not re-invent some of the management/constraints management
that could be done by the regulator framework.

Basically, I think

  r = regulator_get(dev, voltdm-name)
  regulator_set_voltage(r, volt)

would basially be the equivalent of

  omap_voltage_add_userreq(voldm, dev, volt);
  omap_scale_voltage(voltdm, volt)

The regulator framework not only provides management of the users and
constraints, but also provides post-change notifiers where things like
dependent voltages could be handled.

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


Re: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain

2010-09-01 Thread Kevin Hilman
Thara Gopinath th...@ti.com writes:

 This patch adds an API in the opp layer that
 can be used by the voltage layer to get a list of all the
 scalable devices belonging to a particular voltage domain.
 This API is to be typically called only once by the voltage
 layer per voltage domain instance and the device list should
 be stored. This approach makes it easy during dvfs to scale
 all the devices associated with a voltage domain and then
 scale the voltage domain.

 Signed-off-by: Thara Gopinath th...@ti.com

I don't think the OPP layer is the right place for this after all.

How about something like this in the voltage layer:

  omap_voltage_add_device(struct voltagedomain *voltdm, struct device *dev)

During omap_device_build(), if the hwmod has a voltage domain, it
calls this function to register it with the voltage layer.

This function then creates a list (internal to voltage layer) of all the
devices in a voltage domain rather than having to query the OPP layer
for it.

Kevin

 ---
  arch/arm/plat-omap/include/plat/opp.h |9 +
  arch/arm/plat-omap/opp.c  |   28 
  2 files changed, 37 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/plat-omap/include/plat/opp.h 
 b/arch/arm/plat-omap/include/plat/opp.h
 index 0e580ed..a4c1669 100644
 --- a/arch/arm/plat-omap/include/plat/opp.h
 +++ b/arch/arm/plat-omap/include/plat/opp.h
 @@ -18,6 +18,7 @@
  #include linux/cpufreq.h
  
  #include plat/common.h
 +#include plat/voltage.h
  
  /**
   * struct omap_opp_def - OMAP OPP Definition
 @@ -86,6 +87,9 @@ int opp_disable(struct omap_opp *opp);
  
  void opp_init_cpufreq_table(struct device *dev,
   struct cpufreq_frequency_table **table);
 +
 +struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
 + int *dev_count);
  #else
  static inline unsigned long opp_get_voltage(const struct omap_opp *opp)
  {
 @@ -149,5 +153,10 @@ void opp_init_cpufreq_table(struct omap_opp *opps,
  {
  }
  
 +static inline struct device **opp_init_voltage_params(
 + struct voltagedomain *voltdm, int *dev_count)
 +{
 +}
 +
  #endif   /* CONFIG_PM */
  #endif   /* __ASM_ARM_OMAP_OPP_H */
 diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
 index a3dea82..72dd62a 100644
 --- a/arch/arm/plat-omap/opp.c
 +++ b/arch/arm/plat-omap/opp.c
 @@ -502,3 +502,31 @@ void opp_init_cpufreq_table(struct device *dev,
  
   *table = freq_table[0];
  }
 +
 +struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
 + int *dev_count)
 +{
 + struct device_opp *dev_opp;
 + struct device **dev_list;
 + int count = 0, i = 0;
 +
 + list_for_each_entry(dev_opp, dev_opp_list, node) {
 + if (!dev_opp-oh-vdd_name)
 + continue;
 +
 + if (!strcmp(dev_opp-oh-vdd_name, voltdm-name)) {
 + dev_opp-oh-voltdm = voltdm;
 + count++;
 + }
 + }
 +
 + dev_list = kzalloc(sizeof(struct device *) * count, GFP_KERNEL);
 +
 + list_for_each_entry(dev_opp, dev_opp_list, node) {
 + if (dev_opp-oh-voltdm == voltdm)
 + dev_list[i++] = dev_opp-dev;
 + }
 +
 + *dev_count = count;
 + return dev_list;
 +}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAP: Fix TI Innovator 1510/1610 LCD regression

2010-09-01 Thread David Barksdale
This patch fixes a regression introduced by the OMAP: UART: drop
OMAP_TAG_UART, enable all UARTs, auto-disabled on idle patch.

Signed-off-by: David Barksdale amatus.amon...@gmail.com
---
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index 3daf87a..2ee8a70 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -423,13 +423,13 @@ static void __init innovator_init(void)
 #ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap1510()) {
omap1_usb_init(innovator1510_usb_config);
-   innovator_config[1].data = innovator1510_lcd_config;
+   innovator_config[0].data = innovator1510_lcd_config;
}
 #endif
 #ifdef CONFIG_ARCH_OMAP16XX
if (cpu_is_omap1610()) {
omap1_usb_init(h2_usb_config);
-   innovator_config[1].data = innovator1610_lcd_config;
+   innovator_config[0].data = innovator1610_lcd_config;
}
 #endif
omap_board_config = innovator_config;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html