Re: [PATCH] OMAP: ARM: Change Some GPIO Funtions on LDP

2008-11-19 Thread David Brownell
I think there are still a bunch of patches from Jarkko outstanding
which solve this comprehensively ...

- 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


[PATCH] OMAP: ARM: Change Some GPIO Funtions on LDP

2008-11-19 Thread Ogeid Alavaz



0001-OMAP-ARM-Change-Some-GPIO-Funtions-on-LDP.patch
Description: Binary data


Re: OOPS in OMAP 1-wire driver

2008-11-19 Thread stanley.miao
It has been fixed and the patch was added to -mm tree.

Stanley.


From: "Stanley.Miao" <[EMAIL PROTECTED]>

OMAP LDP boot crash.  This is because w1 subsystem changed the search
interface, so update omap_hdq's search interface to follow the change.

Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]>
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 drivers/w1/masters/omap_hdq.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff -puN drivers/w1/masters/omap_hdq.c~w1-omap-fix-omap-ldp-boot-crash
drivers/w1/masters/omap_hdq.c
--- a/drivers/w1/masters/omap_hdq.c~w1-omap-fix-omap-ldp-boot-crash
+++ a/drivers/w1/masters/omap_hdq.c
@@ -86,8 +86,8 @@ static struct platform_driver omap_hdq_d
 static u8 omap_w1_read_byte(void *_hdq);
 static void omap_w1_write_byte(void *_hdq, u8 byte);
 static u8 omap_w1_reset_bus(void *_hdq);
-static void omap_w1_search_bus(void *_hdq, u8 search_type,
-   w1_slave_found_callback slave_found);
+static void omap_w1_search_bus(void *_hdq, struct w1_master
*master_dev,
+   u8 search_type, w1_slave_found_callback slave_found);
 
 
 static struct w1_bus_master omap_w1_master = {
@@ -231,8 +231,8 @@ static u8 omap_w1_reset_bus(void *_hdq)
 }
 
 /* W1 search callback function */
-static void omap_w1_search_bus(void *_hdq, u8 search_type,
-   w1_slave_found_callback slave_found)
+static void omap_w1_search_bus(void *_hdq, struct w1_master
*master_dev,
+   u8 search_type, w1_slave_found_callback slave_found)
 {
u64 module_id, rn_le, cs, id;
 
@@ -249,7 +249,7 @@ static void omap_w1_search_bus(void *_hd
cs = w1_calc_crc8((u8 *)&rn_le, 7);
id = (cs << 56) | module_id;
 
-   slave_found(_hdq, id);
+   slave_found(master_dev, id);
 }
 
 static int _omap_hdq_reset(struct hdq_data *hdq_data)
_
--
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: [Review Patch] V4L2 driver on Tomis DSS patches

2008-11-19 Thread Hiremath, Vaibhav


Thanks,
Vaibhav Hiremath

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-omap-
> [EMAIL PROTECTED] On Behalf Of Alexey Klimov
> Sent: Thursday, November 20, 2008 3:23 AM
> To: Shah, Hardik
> Cc: [EMAIL PROTECTED]; linux-omap@vger.kernel.org; linux-
> [EMAIL PROTECTED]
> Subject: Re: [Review Patch] V4L2 driver on Tomis DSS patches
>
> Hello, Hardik
>
> May i suggest few things here ?
>

[Hiremath, Vaibhav] Definitely, If we have some gaps or implementation issues 
then definitely we have to address.

> On Wed, 2008-11-19 at 12:18 +0530, Hardik Shah wrote:
> > This is the initial version of the V4L2 display driver
> > controlling the video pipelines of DSS.
> >
> > +
> > +   r = def_display->enable(def_display);
> > +   if (r) {
> > +   /* Here we are not considering a error as display may be
> > +  enabled by frame buffer driver */
> > +   printk(KERN_WARNING "Display already enabled\n");
>
> You use printk(KERN_WARNING ..) here. Few line above you use
> dev_err.
> Why didn't you use dev_warn(&pdev->dev, ..) instead of printk ?
> As i know using dev_* macro is more preferred if possible.
>
>
[Hiremath, Vaibhav] Valid point, taken.

> > +   }
> > +
> > +   /* set the update mode */
> > +   if (def_display->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
> > +#ifdef CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE
> > +   if (def_display->set_update_mode)
> > +   def_display->set_update_mode(def_display,
> > +   OMAP_DSS_UPDATE_AUTO);
> > +   if (def_display->enable_te)
> > +   def_display->enable_te(def_display, 1);
> > +#else
> > +   if (def_display->set_update_mode)
> > +   def_display->set_update_mode(def_display,
> > +   OMAP_DSS_UPDATE_MANUAL);
> > +   if (def_display->enable_te)
> > +   def_display->enable_te(def_display, 0);
> > +#endif
> > +   } else {
> > +   if (def_display->set_update_mode)
> > +   def_display->set_update_mode(def_display,
> > +   OMAP_DSS_UPDATE_AUTO);
> > +   }
> > +
> > +   for (i = 0; i < vid_dev->num_displays; i++) {
> > +   struct omap_display *display = vid_dev->displays[i];
> > +
> > +   if (display->update)
> > +   display->update(display,
> > +   0, 0,
> > +   display->x_res, display->y_res);
> > +   }
> > +   printk(KERN_INFO "display->updated\n");
> > +   return 0;
>
> and dev_info here ?
>
[Hiremath, Vaibhav] Valid point, taken.
> > +
> > +error0:
> > +   kfree(vid_dev);
> > +   return r;
> > +}
> > +
> > +static int omapvout_create_vout_devices(struct platform_device
> *pdev)
> > +{
> > +   int r = 0, i, k;
> > +   struct omap_vout_device *vout;
> > +   struct video_device *vfd;
> > +   struct v4l2_pix_format *pix;
> > +   u32 numbuffers;
> > +   int index_i, index_j;
> > +   struct omap2video_device *vid_dev =
> platform_get_drvdata(pdev);
> > +
> > +   for (k = 0; k < pdev->num_resources; k++) {
> > +   vout = kmalloc(sizeof(struct omap_vout_device),
> GFP_KERNEL);
> > +   if (!vout) {
> > +   printk(KERN_ERR VOUT_NAME ": could not allocate \
> > +   memory\n");
>
> As i know, using slash "\" isn't good way (may be i'm wrong). May be
> it's better to make smth like this:
>
>   if (!vout) {
>   printk(KERN_ERR VOUT_NAME
>   ": could not allocate memory\n");
>
>
>
[Hiremath, Vaibhav] Not sure on this. But still at-least code will be more 
readable. No harm in changing that.

> > +   return -ENOMEM;
> > +   }
> > +
> > +   memset(vout, 0, sizeof(struct omap_vout_device));
> > +   vout->vid = k + 1;
> > +
> > +   /* set the default pix */
> > +   pix = &vout->pix;
> > +
> > +   /* Set the default picture of QVGA  */
> > +   pix->width = QQVGA_WIDTH;
> > +   pix->height = QQVGA_HEIGHT;
> > +
> > +   /* Default pixel format is RGB 5-6-5 */
> > +   pix->pixelformat = V4L2_PIX_FMT_RGB565;
> > +   pix->field = V4L2_FIELD_ANY;
> > +   pix->bytesperline = pix->width * 2;
> > +   pix->sizeimage = pix->bytesperline * pix->height;
> > +   pix->priv = 0;
> > +   pix->colorspace = V4L2_COLORSPACE_JPEG;
> > +
> > +   vout->bpp = RGB565_BPP;
> > +
> > +   vout->fbuf.fmt.width = def_display->x_res;
> > +   vout->fbuf.fmt.height = def_display->y_res;
> > +
> > +   omap_vout_new_format(pix, &vout->fbuf, &vout->crop,
> &vout->win);
> > +
> > +   /* initialize the video_device struct */
> > +   vfd = vout->vfd = video_device_alloc();
> > +
> > +   if (!vfd) {
> > +   printk(KERN_ERR VOUT_NAME ": could not allocate
> video 

[patch 2.6.28-rc5 5/5] twl4030 cleanup symbols and OMAP dependency

2008-11-19 Thread David Brownell
From: David Brownell <[EMAIL PROTECTED]>

Finish removing dependency of TWL driver stack on platform-specific 
IRQ definitions ... and remove the build dependency on OMAP.

This lets the TWL4030 code be included in test builds for most
platforms, and will make it easier for non-OMAP folk to update
most of this code for new APIs etc.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
 drivers/mfd/Kconfig |2 +-
 include/linux/i2c/twl4030.h |   32 
 2 files changed, 1 insertion(+), 33 deletions(-)

--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -63,7 +63,7 @@ config UCB1400_CORE
 
 config TWL4030_CORE
bool "Texas Instruments TWL4030/TPS659x0 Support"
-   depends on I2C=y && GENERIC_HARDIRQS && (ARCH_OMAP2 || ARCH_OMAP3)
+   depends on I2C=y && GENERIC_HARDIRQS
help
  Say yes here if you have TWL4030 family chip on your board.
  This core driver provides register access and IRQ handling
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -363,33 +363,6 @@ struct twl4030_platform_data {
 
 int twl4030_sih_setup(int module);
 
-/*
- * FIXME completely stop using TWL4030_IRQ_BASE ... instead, pass the
- * IRQ data to subsidiary devices using platform device resources.
- */
-
-/* IRQ information-need base */
-#include 
-/* TWL4030 interrupts */
-
-/* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
-/* #define TWL4030_MODIRQ_KEYPAD   (TWL4030_IRQ_BASE + 1) */
-/* #define TWL4030_MODIRQ_BCI  (TWL4030_IRQ_BASE + 2) */
-/* #define TWL4030_MODIRQ_MADC (TWL4030_IRQ_BASE + 3) */
-/* #define TWL4030_MODIRQ_USB  (TWL4030_IRQ_BASE + 4) */
-/* #define TWL4030_MODIRQ_PWR  (TWL4030_IRQ_BASE + 5) */
-
-/* #define TWL4030_PWRIRQ_PWRBTN   (TWL4030_PWR_IRQ_BASE + 0) */
-/* #define TWL4030_PWRIRQ_CHG_PRES (TWL4030_PWR_IRQ_BASE + 1) */
-/* #define TWL4030_PWRIRQ_USB_PRES (TWL4030_PWR_IRQ_BASE + 2) */
-/* #define TWL4030_PWRIRQ_RTC  (TWL4030_PWR_IRQ_BASE + 3) */
-/* #define TWL4030_PWRIRQ_HOT_DIE  (TWL4030_PWR_IRQ_BASE + 4) */
-/* #define TWL4030_PWRIRQ_PWROK_TIMEOUT(TWL4030_PWR_IRQ_BASE + 5) */
-/* #define TWL4030_PWRIRQ_MBCHG(TWL4030_PWR_IRQ_BASE + 6) */
-/* #define TWL4030_PWRIRQ_SC_DETECT(TWL4030_PWR_IRQ_BASE + 7) */
-
-/* Rest are unsued currently*/
-
 /* Offsets to Power Registers */
 #define TWL4030_VDAC_DEV_GRP   0x3B
 #define TWL4030_VDAC_DEDICATED 0x3E
@@ -400,11 +373,6 @@ int twl4030_sih_setup(int module);
 #define TWL4030_VAUX3_DEV_GRP  0x1F
 #define TWL4030_VAUX3_DEDICATED0x22
 
-/* TWL4030 GPIO interrupt definitions */
-
-#define TWL4030_GPIO_IRQ_NO(n) (TWL4030_GPIO_IRQ_BASE + (n))
-
-
 #if defined(CONFIG_TWL4030_BCI_BATTERY) || \
defined(CONFIG_TWL4030_BCI_BATTERY_MODULE)
extern int twl4030charger_usb_en(int enable);
--
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-rc5 4/5] twl4030 power button irq

2008-11-19 Thread David Brownell
From: David Brownell <[EMAIL PROTECTED]>

Disable the TWL4030_PWRIRQ_PWRBTN symbol from the system headers;
initialization of the power button handler still needs work, so
an equivalent symbol is defined in its driver.

Power IRQs now properly handle trigger specs from request_irq();
stop goofing with registers reserved to the IRQ infrastructure.

Minor cleanup:  switch several messages to pr_debug().

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
 drivers/i2c/chips/twl4030-pwrbutton.c |   50 
 include/linux/i2c/twl4030.h   |2 -
 2 files changed, 15 insertions(+), 37 deletions(-)

--- a/drivers/i2c/chips/twl4030-pwrbutton.c
+++ b/drivers/i2c/chips/twl4030-pwrbutton.c
@@ -29,18 +29,16 @@
 #include 
 #include 
 
-#define PWR_ISR1 0
-#define PWR_IMR1 1
+
 #define PWR_PWRON_IRQ (1<<0)
 
-#define PWR_EDR1 5
-#define PWR_PWRON_RISING (1<<1)
-#define PWR_PWRON_FALLING  (1<<0)
-#define PWR_PWRON_BOTH (PWR_PWRON_RISING | PWR_PWRON_FALLING)
+#define STS_HW_CONDITIONS 0xf
 
-#define PWR_SIH_CTRL 7
 
-#define STS_HW_CONDITIONS 0xf
+/* FIXME have this constant delivered to us as part of the
+ * twl4030-core setup ...
+ */
+#define TWL4030_PWRIRQ_PWRBTN  (TWL4030_PWR_IRQ_BASE + 0)
 
 static struct input_dev *powerbutton_dev;
 
@@ -73,20 +71,19 @@ static irqreturn_t powerbutton_irq(int i
 static int __init twl4030_pwrbutton_init(void)
 {
int err = 0;
-   u8 value;
 
/* PWRBTN == PWRON */
-   if (request_irq(TWL4030_PWRIRQ_PWRBTN, powerbutton_irq, 0,
-   "PwrButton", NULL) < 0) {
-   printk(KERN_ERR "Unable to allocate IRQ for power button\n");
-   err = -EBUSY;
+   err = request_irq(TWL4030_PWRIRQ_PWRBTN, powerbutton_irq,
+   IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+   "PwrButton", NULL);
+   if (err < 0) {
+   pr_debug("Can't get IRQ for power button: %d\n", err);
goto out;
}
 
powerbutton_dev = input_allocate_device();
if (!powerbutton_dev) {
-   printk(KERN_ERR
-   "Unable to allocate input device for power button\n");
+   pr_debug("Can't allocate power button\n");
err = -ENOMEM;
goto free_irq_and_out;
}
@@ -97,26 +94,7 @@ static int __init twl4030_pwrbutton_init
 
err = input_register_device(powerbutton_dev);
if (err) {
-   input_free_device(powerbutton_dev);
-   goto free_irq_and_out;
-   }
-
-   /* FIXME just pass IRQF_EDGE_FALLING | IRQF_EDGE_RISING
-* to request_irq(), once MODULE_INT supports them...
-*/
-   err = twl4030_i2c_read_u8(TWL4030_MODULE_INT, &value, PWR_EDR1);
-   if (err) {
-   printk(KERN_WARNING "I2C error %d while reading TWL4030"
-   " INT PWR_EDR1 register\n", err);
-   goto free_input_dev;
-   }
-
-   err = twl4030_i2c_write_u8(TWL4030_MODULE_INT,
-  value | PWR_PWRON_BOTH, PWR_EDR1);
-
-   if (err) {
-   printk(KERN_WARNING "I2C error %d while writing TWL4030"
-   " INT PWR_EDR1 register\n", err);
+   pr_debug("Can't register power button: %d\n", err);
goto free_input_dev;
}
 
@@ -126,7 +104,7 @@ static int __init twl4030_pwrbutton_init
 
 
 free_input_dev:
-   input_unregister_device(powerbutton_dev);
+   input_free_device(powerbutton_dev);
 free_irq_and_out:
free_irq(TWL4030_PWRIRQ_PWRBTN, NULL);
 out:
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -379,7 +379,7 @@ int twl4030_sih_setup(int module);
 /* #define TWL4030_MODIRQ_USB  (TWL4030_IRQ_BASE + 4) */
 /* #define TWL4030_MODIRQ_PWR  (TWL4030_IRQ_BASE + 5) */
 
-#define TWL4030_PWRIRQ_PWRBTN  (TWL4030_PWR_IRQ_BASE + 0)
+/* #define TWL4030_PWRIRQ_PWRBTN   (TWL4030_PWR_IRQ_BASE + 0) */
 /* #define TWL4030_PWRIRQ_CHG_PRES (TWL4030_PWR_IRQ_BASE + 1) */
 /* #define TWL4030_PWRIRQ_USB_PRES (TWL4030_PWR_IRQ_BASE + 2) */
 /* #define TWL4030_PWRIRQ_RTC  (TWL4030_PWR_IRQ_BASE + 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 2.6.28-rc5 3/5] twl4030 MADC irq

2008-11-19 Thread David Brownell
From: David Brownell <[EMAIL PROTECTED]>

Disable the TWL4030_MODIRQ_MADC symbol and remove all its uses.
It's not needed any more now that platform_get_irq() works for
these MADC devices.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
 drivers/i2c/chips/twl4030-madc.c |4 ++--
 include/linux/i2c/twl4030.h  |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/i2c/chips/twl4030-madc.c
+++ b/drivers/i2c/chips/twl4030-madc.c
@@ -458,7 +458,7 @@ static int __init twl4030_madc_probe(str
ret = twl4030_i2c_write_u8(TWL4030_MODULE_MAIN_CHARGE,
   regval, TWL4030_BCI_BCICTL1);
 
-   ret = request_irq(TWL4030_MODIRQ_MADC, twl4030_madc_irq_handler,
+   ret = request_irq(platform_get_irq(pdev, 0), twl4030_madc_irq_handler,
  0, "twl4030_madc", madc);
if (ret) {
dev_dbg(&pdev->dev, "could not request irq\n");
@@ -489,7 +489,7 @@ static int __exit twl4030_madc_remove(st
 
twl4030_madc_set_power(madc, 0);
twl4030_madc_set_current_generator(madc, 0, 0);
-   free_irq(TWL4030_MODIRQ_MADC, madc);
+   free_irq(platform_get_irq(pdev, 0), madc);
cancel_work_sync(&madc->ws);
misc_deregister(&twl4030_madc_device);
 
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -375,7 +375,7 @@ int twl4030_sih_setup(int module);
 /* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
 /* #define TWL4030_MODIRQ_KEYPAD   (TWL4030_IRQ_BASE + 1) */
 /* #define TWL4030_MODIRQ_BCI  (TWL4030_IRQ_BASE + 2) */
-#define TWL4030_MODIRQ_MADC(TWL4030_IRQ_BASE + 3)
+/* #define TWL4030_MODIRQ_MADC (TWL4030_IRQ_BASE + 3) */
 /* #define TWL4030_MODIRQ_USB  (TWL4030_IRQ_BASE + 4) */
 /* #define TWL4030_MODIRQ_PWR  (TWL4030_IRQ_BASE + 5) */
 
--
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-rc5 2/5] twl4030 BCI irq and dependencies

2008-11-19 Thread David Brownell
From: David Brownell <[EMAIL PROTECTED]>

Disable the TWL4030_MODIRQ_BCI symbol and remove all its uses.
It's not needed any more now that platform_get_irq() works for
these BCI devices.

Also remove inappropriate board-specific Kconfig dependencies.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
 drivers/power/Kconfig   |3 +--
 drivers/power/twl4030_bci_battery.c |   18 +++---
 include/linux/i2c/twl4030.h |2 +-
 3 files changed, 13 insertions(+), 10 deletions(-)

--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -58,8 +58,7 @@ config BATTERY_TOSA
 
 config TWL4030_BCI_BATTERY
tristate "OMAP TWL4030 BCI Battery driver"
-   depends on (MACH_OMAP_2430SDP || MACH_OMAP_3430SDP || MACH_OMAP_LDP) && 
TWL4030_MADC
-   default y
+   depends on TWL4030_CORE && TWL4030_MADC
help
  Support for OMAP TWL4030 BCI Battery driver.
  This driver can give support for TWL4030 Battery Charge Interface.
--- a/drivers/power/twl4030_bci_battery.c
+++ b/drivers/power/twl4030_bci_battery.c
@@ -958,17 +958,17 @@ static int __init twl4030_bci_battery_pr
/* REVISIT do we need to request both IRQs ?? */
 
/* request BCI interruption */
-   ret = request_irq(TWL4030_MODIRQ_BCI, twl4030battery_interrupt,
+   irq = platform_get_irq(pdev, 1);
+   ret = request_irq(irq, twl4030battery_interrupt,
0, pdev->name, NULL);
if (ret) {
dev_dbg(&pdev->dev, "could not request irq %d, status %d\n",
-   TWL4030_MODIRQ_BCI, ret);
+   irq, ret);
goto batt_irq_fail;
}
 
-   irq = platform_get_irq(pdev, 0);
-
/* request Power interruption */
+   irq = platform_get_irq(pdev, 0);
ret = request_irq(irq, twl4030charger_interrupt,
0, pdev->name, di);
 
@@ -1005,7 +1005,8 @@ bk_batt_failed:
 batt_failed:
free_irq(irq, di);
 chg_irq_fail:
-   free_irq(TWL4030_MODIRQ_BCI, NULL);
+   irq = platform_get_irq(pdev, 1);
+   free_irq(irq, NULL);
 batt_irq_fail:
 voltage_setup_fail:
 temp_setup_fail:
@@ -1021,16 +1022,19 @@ temp_setup_fail:
 static int __exit twl4030_bci_battery_remove(struct platform_device *pdev)
 {
struct twl4030_bci_device_info *di = platform_get_drvdata(pdev);
-   int irq = platform_get_irq(pdev, 0);
+   int irq;
 
twl4030charger_ac_en(DISABLE);
twl4030charger_usb_en(DISABLE);
twl4030battery_hw_level_en(DISABLE);
twl4030battery_hw_presence_en(DISABLE);
 
-   free_irq(TWL4030_MODIRQ_BCI, NULL);
+   irq = platform_get_irq(pdev, 0);
free_irq(irq, di);
 
+   irq = platform_get_irq(pdev, 1);
+   free_irq(irq, NULL);
+
flush_scheduled_work();
power_supply_unregister(&di->bat);
power_supply_unregister(&di->bk_bat);
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -374,7 +374,7 @@ int twl4030_sih_setup(int module);
 
 /* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
 /* #define TWL4030_MODIRQ_KEYPAD   (TWL4030_IRQ_BASE + 1) */
-#define TWL4030_MODIRQ_BCI (TWL4030_IRQ_BASE + 2)
+/* #define TWL4030_MODIRQ_BCI  (TWL4030_IRQ_BASE + 2) */
 #define TWL4030_MODIRQ_MADC(TWL4030_IRQ_BASE + 3)
 /* #define TWL4030_MODIRQ_USB  (TWL4030_IRQ_BASE + 4) */
 /* #define TWL4030_MODIRQ_PWR  (TWL4030_IRQ_BASE + 5) */
--
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-rc5 1/5] twl4030 keypad irq & dependencies

2008-11-19 Thread David Brownell
From: David Brownell <[EMAIL PROTECTED]>

Disable the TWL4030_MODIRQ_KEYPAD symbol and remove all its uses.
It's not needed any more now that platform_get_irq() works for
these keypad devices.

Also remove inappropriate board-specific Kconfig dependencies.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/board-2430sdp.c |1 -
 arch/arm/mach-omap2/board-3430sdp.c |1 -
 arch/arm/mach-omap2/board-ldp.c |1 -
 arch/arm/mach-omap2/board-omap2evm.c|1 -
 arch/arm/mach-omap2/board-omap3evm.c|1 -
 drivers/input/keyboard/Kconfig  |2 +-
 drivers/input/keyboard/omap-twl4030keypad.c |2 +-
 include/linux/i2c/twl4030.h |3 +--
 8 files changed, 3 insertions(+), 9 deletions(-)

--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -182,7 +182,6 @@ static struct twl4030_keypad_data sdp243
.keymap = sdp2430_keymap,
.keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
-   .irq= TWL4030_MODIRQ_KEYPAD,
 };
 
 static int __init msecure_init(void)
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -118,7 +118,6 @@ static struct twl4030_keypad_data sdp343
.keymap = sdp3430_keymap,
.keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
-   .irq= TWL4030_MODIRQ_KEYPAD,
 };
 
 static int ts_gpio;
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -101,7 +101,6 @@ static struct twl4030_keypad_data ldp_kp
.keymap = ldp_twl4030_keymap,
.keymapsize = ARRAY_SIZE(ldp_twl4030_keymap),
.rep= 1,
-   .irq= TWL4030_MODIRQ_KEYPAD,
 };
 
 static struct gpio_keys_button ldp_gpio_keys_buttons[] = {
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -273,7 +273,6 @@ static struct twl4030_keypad_data omap2e
.keymap = omap2evm_keymap,
.keymapsize = ARRAY_SIZE(omap2evm_keymap),
.rep= 1,
-   .irq= TWL4030_MODIRQ_KEYPAD,
 };
 
 static void __init omap2_evm_init_irq(void)
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -125,7 +125,6 @@ static struct twl4030_keypad_data omap3e
.keymap = omap3evm_keymap,
.keymapsize = ARRAY_SIZE(omap3evm_keymap),
.rep= 1,
-   .irq= TWL4030_MODIRQ_KEYPAD,
 };
 
 static struct twl4030_madc_platform_data omap3evm_madc_data = {
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -261,7 +261,7 @@ config KEYBOARD_OMAP
 
 config KEYBOARD_TWL4030
tristate "TI TWL4030 keypad support"
-   depends on TWL4030_CORE && (MACH_OMAP_2430SDP || MACH_OMAP2EVM || 
MACH_OMAP_3430SDP || MACH_OMAP3EVM || MACH_OMAP_LDP)
+   depends on TWL4030_CORE
help
  Say Y here if you want to use the OMAP TWL4030 keypad.
 
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -269,7 +269,7 @@ static int __init omap_kp_probe(struct p
kp->keymapsize = pdata->keymapsize;
kp->n_rows = pdata->rows;
kp->n_cols = pdata->cols;
-   kp->irq = pdata->irq;
+   kp->irq = platform_get_irq(pdev, 0);
 
/* setup input device */
set_bit(EV_KEY, kp->omap_twl4030kp->evbit);
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -259,7 +259,6 @@ struct twl4030_keypad_data {
int rows;
int cols;
int *keymap;
-   int irq;
unsigned int keymapsize;
unsigned int rep:1;
 };
@@ -374,7 +373,7 @@ int twl4030_sih_setup(int module);
 /* TWL4030 interrupts */
 
 /* #define TWL4030_MODIRQ_GPIO (TWL4030_IRQ_BASE + 0) */
-#define TWL4030_MODIRQ_KEYPAD  (TWL4030_IRQ_BASE + 1)
+/* #define TWL4030_MODIRQ_KEYPAD   (TWL4030_IRQ_BASE + 1) */
 #define TWL4030_MODIRQ_BCI (TWL4030_IRQ_BASE + 2)
 #define TWL4030_MODIRQ_MADC(TWL4030_IRQ_BASE + 3)
 /* #define TWL4030_MODIRQ_USB  (TWL4030_IRQ_BASE + 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


[patch 2.6.28-rc5 0/5] twl4030 irq assignments

2008-11-19 Thread David Brownell
The following patches remove some needless dependencies from
TWL4030 support, supporting non-OMAP builds and in some cases,
non-SDP (etc) builds.

 - keypad driver ... use platform_get_irq(), no board dependencies
 - BCI driver ... likewise
 - MADC driver ... use platform_get_irq()
 - power button ... still pretty hacky, there's no device here
 - removes the now-dead symbols, and OMAP-dependency

Build-tested.

With this, I think the keypad driver becomes ready to go upstream,
after related twl4030-core updates.  At least, it's ready for review.
(Including:  Why pass the keypad module id to kpread/kpwrite, it's
the only one ever used?  Why does Kconfig mention GPIOs, since they
aren't used?)

The point of these patches is that last one, which lets non-OMAP
folk do test builds and easily make updates when APIs change.
Yeah, it's a strange notion, but not everyone does OMAP builds.  ;)

- 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


[ANNOUNCE] new PM branch: pm-20081119

2008-11-19 Thread Kevin Hilman
Hello,

A new PM branch is available named pm-20081119.  

This is mostly a new set of patches on top of the previous PM branch,
rather than a rebase.  We finally found the root cause of some DPLL
relocking bugs.  Special thanks to Paul Walmsley and Tero Kristo for
debugging and fixing this problem.  Now the DPLL fix that was reverted
in the previous PM branch is re-applied as well as some fixes on top
of it.  It also has some additional UART fixes, so I think the UART
idle work is ready to go to Tony.  Special thanks to Jouni Hogander
for the extra testing and fixes here.

The shortlog is below[1] and the root of the tree is still
v2.6.27-omap1 + T2 power patches from Peter.

This has primarily been tested on custom HW since I'm _still_ waiting
for my SDP to arrive.  I have boot tested on Beagle, but I think there
are still some problems with ES2 silicon.  On my ES2 Beagle, neither
DSS or IVA will leave the ON state, even when all clocks in their
powerdomains are off.  I have not debugged this further yet.

Functionally, this tree is in pretty good shape, so I will do some
bugfixes here when necessary, but will now spent some time focusing on
getting the patches in this branch merged into linux-omap.

Kevin


[1] git shortlog:

Amit Kucheria (2):
  OMAP: PM: Typo fix for clock_allow_idle
  HSMMC: Make driver support dynamic idle

Jouni Hogander (11):
  OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle 
loop
  OMAP3: Do not set mpu, core, neon states if cpuidle is used
  OMAP3: PM: Do not set next states sw to control those is available
  OMAP3: PM: Always return value in pwrdms_setup
  OMAP3: PM: Fix wrong sequence in suspend.
  OMAP3: UART: Make sure that uart clocks are enabled when needed
  OMAP3: PM: Check in set_pwrdm_state that target state is supported by 
pwrdm v2
  OMAP3: PM: Do not build suspend code if SUSPEND is not enabled
  OMAP: PM: Build fails if PM is not enabled
  OMAP2: PM: Fix omap2 build
  OMAP: MCSPI: Enable mcspi wake-up

Kalle Jokiniemi (4):
  OMAP: PM: sysfs interface for enabling voltage off in idle
  OMAP3: PM: Fix cpu idle init sequencing
  OMAP: SRF: Fixes to shared resource framework (Ver.3)
  OMAP3: I2C: Enable I2C wakeups

Kevin Hilman (16):
  OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
  OMAP3: PM: Allow UARTs to be unclocked when inactive
  8250: Allow platform to register PM hook
  8250: when waking, PM hook should be called before accessing port
  OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume
  OMAP3: PM: UART save/restore support for OFF-mode
  OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot
  OMAP3: PM: CPUidle: obey enable_off_mode flag
  OMAP3: PM: CPUidle: restrict C-states on UART activity
  OMAP3: PM: decouple PER and CORE context save and restore
  Revert "OMAP3 clock: fix non-CORE DPLL rate assignment bugs"
  Revert "OMAP3: PM: Do not set next states sw to control those is 
available"
  Revert "OMAP3: Do not set mpu, core, neon states if cpuidle is used"
  OMAP: PM: UART: fix can_sleep hook to return correct value
  OMAP: PM: UART: Only disable clocks in prepare-idle hook
  OMAP3: PM: Check for UART wakeups in 'resume_idle' hook

Paul Walmsley (14):
  OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op 
layer.
  OMAP2/3 omapdev: add basic omapdev structure
  OMAP242x omapdev: add OMAP242x omapdev records
  OMAP243x omapdev: add OMAP243x omapdev records
  OMAP3xxx omapdev: add OMAP3xxx omapdev records
  OMAP2/3 omapdev: add code to walk the omapdev records
  OMAP3 clock: fix non-CORE DPLL rate assignment bugs
  OMAP3 powerdomains: remove RET from SGX power states list
  OMAP3 powerdomains: remove RET from SGX power states list
  OMAP3 clock: remove unnecessary dpll_data dereferences
  OMAP3 clock: optimize DPLL rate rounding algorithm
  OMAP3 clock: avoid invalid FREQSEL values during DPLL rate rounding
  OMAP2/3 I2C: reprogram OCP_SYSCONFIG register after reset
  OMAP: I2C: convert 'rev1' flag to generic 'rev' u8

Peter 'p2' De Schrijver (9):
  OMAP: PM counter infrastructure.
  OMAP: PM: Hook into PM counters
  OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each.
  OMAP: PM: Add pm-debug counters
  OMAP: PM debug: make powerdomains use PM-debug counters
  OMAP: PM: Add definitions for ETK pads and observability registers
  OMAP: Debug observability and ETK padconf implementation
  OMAP: Add debug observablity (debobs) Kconfig item
  OMAP: PM: Implement get_last_off_on_transaction_id()

Rajendra Nayak (23):
  OMAP3: PM: GPMC context save/restore
  OMAP3: PM: GPIO context save/restore
  OMAP3: PM: I2C context save/restore
  OMAP3: PM: INTC context save/restore

OOPS in OMAP 1-wire driver

2008-11-19 Thread Juha Kuikka
I'm not sure this is the right place for 1-wire stuff but I remember
seeing patches for the OMAP 1w driver so maybe someone is interested.

Running git head on OMAP2430 SDP. Only OMAP master is built into the
kernel, no slave modules.
This happens on boot.

Driver for 1-wire Dallas network protocol.
omap_hdq omap_hdq.0: OMAP HDQ Hardware Rev 0.3. Driver in Interrupt mode
Unable to handle kernel NULL pointer dereference at virtual address 00f0
pgd = c0004000
[00f0] *pgd=
Internal error: Oops: 0 [#1] PREEMPT
Modules linked in:
CPU: 0Not tainted  (2.6.28-rc5-omap1 #21)
PC is at 0xf0
LR is at omap_w1_search_bus+0x64/0x70
pc : [<00f0>]lr : []psr: 6013
sp : c7957f68  ip : c7957f68  fp : c7957f8c
r10:   r9 :   r8 : 
r7 : 00f0  r6 : c7829160  r5 :   r4 : 0001
r3 : 3d00  r2 : 0001  r1 : 3d00  r0 : c7829160
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 00c5387f  Table: 80004000  DAC: 0017
Process w1_bus_master1 (pid: 263, stack limit = 0xc7956260)
Stack: (0xc7957f68 to 0xc7958000)
7f60:   0001  c01af304 00f0 c7956000 03e8
7f80: c7957fa4 c7957f90 c01aed58 c01af310 c7943a00 c7943a00 c7957fbc c7957fa8
7fa0: c01ad880 c01aed20 c7943a68 c7943a00 c7957fdc c7957fc0 c01ad958 c01ad830
7fc0: c7943a00 c01ad8fc   c7957ff4 c7957fe0 c0059fd0 c01ad908
7fe0:    c7957ff8 c0048104 c0059f88 ff00ff00 ff00ff00
Backtrace:
[] (omap_w1_search_bus+0x0/0x70) from []
(w1_search_devices+0x44/0x50)
 r7:03e8 r6:c7956000 r5:00f0 r4:c01af304
[] (w1_search_devices+0x0/0x50) from []
(w1_search_process+0x5c/0xd8)
 r5:c7943a00 r4:c7943a00
[] (w1_search_process+0x0/0xd8) from []
(w1_process+0x5c/0xe0)
 r5:c7943a00 r4:c7943a68
[] (w1_process+0x0/0xe0) from [] (kthread+0x54/0x80)
 r7: r6: r5:c01ad8fc r4:c7943a00
[] (kthread+0x0/0x80) from [] (do_exit+0x0/0x784)
 r5: r4:
Code: bad PC value.


-- 
Madness takes it's toll. Please have exact change.
--
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 section mismatch warning.

2008-11-19 Thread David Brownell
I know that Beagle and Overo get the same warnings, so this
isn't really a sufficient fix...


On Wednesday 19 November 2008, Sanjeev Premi wrote:
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -130,7 +130,7 @@ static struct twl4030_madc_platform_data 
> omap3evm_madc_data = {
> .irq_line   = 1,
>  };
>  
> -static struct twl4030_platform_data omap3evm_twldata = {
> +static struct twl4030_platform_data __initdata omap3evm_twldata = {

... and that's incorrect in any case, since that data is used
by probe() code that's doesn't sit in an init section.

I have the following in my patchset, currently disabled since
it conflicts with other patches.  And in any case, Beagle can't
reboot with these "generic" scripts for some TBD reason.

- Dave

= CUT HERE
---
 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
@@ -188,7 +188,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,
 };
 
 static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -140,7 +140,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 
 #include 
 #include 
@@ -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 
 
+#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] OMAP3 powerdomains: remove RET from SGX power states list

2008-11-19 Thread Kevin Hilman
"Steve Sakoman" <[EMAIL PROTECTED]> writes:

> On Wed, Nov 12, 2008 at 11:07 AM, Paul Walmsley <[EMAIL PROTECTED]> wrote:
>> Hi Jouni, Kevin,
>>
>> On Tue, 11 Nov 2008, Högander Jouni wrote:
>>
>>> I wouldn't add any flags for this. The goal is finally to set all
>>> next_states as OFF until someone has set some constraint which
>>> prevents OFF usage. For now we need to use RET as default, because
>>> drivers are not supporting OFF mode. Do you agree this?
>>
>> Yes.
>>
>>> Easiest way here would be to add own hook for SGX in pwrdms_setup? One
>>> more strcmp("*_pwrdm, pwrdm->name) :)
>>>
>>> What do you think?
>>
>> That is okay with me.  This seems to be an unusual case - I guess it's due
>> to an SGX firmware bug.
>>
>> So Kevin, if you have a strong opposition to that strcmp, maybe we should
>> use a powerdomain flag for the SGX pwrdm.  Otherwise, let's go with a
>> strcmp as Jouni suggested.  Thoughts?
>
> Has there been a final resolution on this?
>
> I am unable to boot reliably on Overo with 2.6.28-rc5 -- almost every
> boot attempt gives me:
>
> Power Management for TI OMAP3.
> Unable to set state of powerdomain: sgx_pwrdm
> Failed to setup powerdomains
> omap2|3_pm_init failed: -22
>

Hi Steve,

Tony just pushed the final version[1] of the fix for this issue.
Please let me know if your problem still persists.

Kevin


[1] see commit 7a54b0f6f39ea1e5dbff6bb47314bea228bf6e44
--
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 powerdomains: remove RET from SGX power states list

2008-11-19 Thread Steve Sakoman
On Wed, Nov 12, 2008 at 11:07 AM, Paul Walmsley <[EMAIL PROTECTED]> wrote:
> Hi Jouni, Kevin,
>
> On Tue, 11 Nov 2008, Högander Jouni wrote:
>
>> I wouldn't add any flags for this. The goal is finally to set all
>> next_states as OFF until someone has set some constraint which
>> prevents OFF usage. For now we need to use RET as default, because
>> drivers are not supporting OFF mode. Do you agree this?
>
> Yes.
>
>> Easiest way here would be to add own hook for SGX in pwrdms_setup? One
>> more strcmp("*_pwrdm, pwrdm->name) :)
>>
>> What do you think?
>
> That is okay with me.  This seems to be an unusual case - I guess it's due
> to an SGX firmware bug.
>
> So Kevin, if you have a strong opposition to that strcmp, maybe we should
> use a powerdomain flag for the SGX pwrdm.  Otherwise, let's go with a
> strcmp as Jouni suggested.  Thoughts?

Has there been a final resolution on this?

I am unable to boot reliably on Overo with 2.6.28-rc5 -- almost every
boot attempt gives me:

Power Management for TI OMAP3.
Unable to set state of powerdomain: sgx_pwrdm
Failed to setup powerdomains
omap2|3_pm_init failed: -22

Steve
--
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: [FYI] Rebase: tidspbridge-20081118

2008-11-19 Thread Tony Lindgren
* Hiroshi DOYU <[EMAIL PROTECTED]> [081117 05:37]:
> Hi,
> 
> The following changes since commit f23f23fb6bfd8ce4669070df35ec9b320983ac0c:
>   Grazvydas Ignotas (1):
> HSMMC: Add MMC configuration for pandora
> 
> are available in the git repository at:
> 
>   http://git.gitorious.org/lk/mainline.git tidspbridge-20081118

Great, I'm now also mirroring tidspbridge-20081118 branch at:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary

Tony




> 
> Axel Haslam (1):
>   BRIDGE: tiomap unmap fix
> 
> Fernando Guzman Lugo (5):
>   BRIDGE: Remove sparse warnings from wcd
>   BRIDGE: Module ISR removed
>   BRIDGE: PRCS wrappers removal
>   BRIDGE: Chnl module cleanup
>   BRIDGE: Sparse warnings cleanup
> 
> Hari Kanigeri (4):
>   BRIDGE Add preemption support to unprotected functions
>   BRIDGE Resource cleanup node delete fix
>   BRIDGE Memory leak fix
>   BRIDGE Handle Node messaging when DSP crashed
> 
> Hiroshi DOYU (23):
>   BRIDGE: Kconfig Entry
>   BRIDGE: Header files
>   BRIDGE: Doff image dynamic loader
>   BRIDGE: Generic Utilities
>   BRIDGE: Hardware Interfaces
>   BRIDGE: Platform Manager
>   BRIDGE: Resource Manager
>   BRIDGE: Services
>   BRIDGE: Mini driver
>   BRIDGE: README
>   BRIDGE: Fix header path
>   BRIDGE: Sync omapzoom bridge patches
>   BRIDGE: set 0 for phys_mempool_* as default
>   BRIDGE: Rename header file location
>   BRIDGE: Fix header path name to "arch/arm/plat-omap/include/dspbridge"
>   BRIDGE: Add 'dspbridge' dirname in header file inclusion
>   BRIDGE: Fix incorrect pathname
>   BRIDGE: Remove paths in header comment
>   BRIDGE: fix build error
>   BRIDGE: enable dspbridge in omap_3430sdp_defconfig
>   BRIDGE: use more detail name for interrupt claiming device
>   BRIDGE: Fix uninitialized spinlock
>   BRIDGE: Fix memory leak in PROC_Init()
> 
> Omar Ramirez Luna (11):
>   BRIDGE: Ceanup GT sparse warnings
>   BRIDGE: Cleanup static declarations warnings
>   BRIDGE: Remove unused clk structs
>   BRIDGE: Clean up unusedvariables
>   BRIDGE: Cosmetic changes reported from checkpatch
>   BRIDGE: Add wcd table end
>   BRIDGE: Checkpatch Cleanup
>   BRIDGE: OMAP CSL wrappers removed
>   BRIDGE: Remove CDECL macro
>   BRIDGE: GT mask for DSP traces
>   BRIDGE: MMUfault infinite timeout fix
> 
> Ramesh Gupta (4):
>   BRIDGE: Power management changes
>   BRIDGE: OMAP PM Bug softlockup fix
>   BRIDGE Power Management cleanup
>   BRIDGE Save mailbox settings for suspend-resume
> 
> Suman Anna (1):
>   BRIDGE: Fix bug in HW Mailbox messaging
> 
> Tony Lindgren (1):
>   DSPBRIDGE: Flush posted write when acking mailbox irq
> 
> ext Ramirez Luna, Omar (1):
>   BRIDGE: removing unnecesary OMAP3430 checks
> 
>  Documentation/tidspbridge/README   |   70 +
>  arch/arm/Kconfig   |1 +
>  arch/arm/configs/omap_3430sdp_defconfig|6 +-
>  arch/arm/plat-omap/include/dspbridge/_chnl_sm.h|  212 ++
>  arch/arm/plat-omap/include/dspbridge/_dcd.h|  187 ++
>  arch/arm/plat-omap/include/dspbridge/brddefs.h |   54 +
>  arch/arm/plat-omap/include/dspbridge/cfg.h |  339 ++
>  arch/arm/plat-omap/include/dspbridge/cfgdefs.h |  124 +
>  arch/arm/plat-omap/include/dspbridge/chnl.h|  170 +
>  arch/arm/plat-omap/include/dspbridge/chnl_sm.h |  210 ++
>  arch/arm/plat-omap/include/dspbridge/chnldefs.h|   92 +
>  arch/arm/plat-omap/include/dspbridge/chnlpriv.h|  136 +
>  arch/arm/plat-omap/include/dspbridge/clk.h |  155 +
>  arch/arm/plat-omap/include/dspbridge/cmm.h |  420 +++
>  arch/arm/plat-omap/include/dspbridge/cmmdefs.h |  135 +
>  arch/arm/plat-omap/include/dspbridge/cod.h |  433 +++
>  arch/arm/plat-omap/include/dspbridge/csl.h |  135 +
>  arch/arm/plat-omap/include/dspbridge/dbc.h |   66 +
>  arch/arm/plat-omap/include/dspbridge/dbdcd.h   |  388 +++
>  arch/arm/plat-omap/include/dspbridge/dbdcddef.h|   94 +
>  arch/arm/plat-omap/include/dspbridge/dbdefs.h  |  577 
>  arch/arm/plat-omap/include/dspbridge/dbg.h |  110 +
>  arch/arm/plat-omap/include/dspbridge/dbl.h |  354 ++
>  arch/arm/plat-omap/include/dspbridge/dbldefs.h |  155 +
>  arch/arm/plat-omap/include/dspbridge/dbll.h|   70 +
>  arch/arm/plat-omap/include/dspbridge/dblldefs.h|  509 +++
>  arch/arm/plat-omap/include/dspbridge/dbof.h|  117 +
>  arch/arm/plat-omap/include/dspbridge/dbreg.h   |  113 +
>  arch/arm/plat-omap/include/dspbridge/dbtype.h  |  103 +
>  arch/arm/plat-omap/include/dspbridge/dehdefs.h |   42 +
>  arch/arm/plat-omap/include/dspbridge/dev.h |  785 +
>  arch/arm/plat-omap/include/dspbridge/devdefs.h |   35 +
>  arch/arm/plat-omap/include/dspbridge/disp.h

Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly

2008-11-19 Thread Tony Lindgren
* Evgeniy Polyakov <[EMAIL PROTECTED]> [081119 11:35]:
> On Wed, Nov 19, 2008 at 11:14:20AM -0800, Tony Lindgren ([EMAIL PROTECTED]) 
> wrote:
> > Thanks! The rest of the omap w1 patche should be coming to you via LKML
> > then ;)
> 
> I've just pushed w1 patch (did I understand it right that there is only
> one in the given set, all others touch very different areas).

Yes, that's correct. The other patches are for LDP specific board support,
and will be merged with the arm patches.

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 PM-20081106] OMAP: PM: Few fixes to uart clock handling

2008-11-19 Thread Kevin Hilman
Jouni Hogander <[EMAIL PROTECTED]> writes:

> Omap3_can_sleep is not inside part of idle loop which is protected
> with irg disable. If some irq handler is trying dump out something
> after omap3_can_sleep and before irqs are disabled. It causes oops
> because uart clocks are disabled.
>
> Remove also some unused extra code from omap_uart_can_sleep
>
> Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
> ---
>  arch/arm/mach-omap2/serial.c |   11 +--
>  1 files changed, 1 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index ef30d8d..b06b797 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -314,21 +314,13 @@ void omap_uart_check_wakeup(void)
>  int omap_uart_can_sleep(void)
>  {
>   struct omap_uart_state *uart;
> - int can_sleep = 1;
>  
>   list_for_each_entry(uart, &uart_list, node) {
> - if (!uart->clocked)
> + if (!uart->clocked || !uart->can_sleep)
>   continue;
>  
> - if (!uart->can_sleep) {
> - can_sleep = 0;
> - continue;
> - }
> -
>   /* This UART can now safely sleep. */
>   omap_uart_allow_sleep(uart);
> - if (clocks_off_while_idle)
> - omap_uart_disable_clocks(uart);

If we remove this disable, then the fclks will have to be masked/ignored
in omap3_fclks_active() too.  This is what I was trying to avoid.

However, based on the potential race with ISRs you described, I think
this is the best option.

Kevin

>   }
>  
>   return 1;
> @@ -435,7 +427,6 @@ static void omap_uart_pm(struct uart_port *port,
>   break;
>   case 3: /* suspend */
>   omap_uart_allow_sleep(uart);
> - omap_uart_disable_clocks(uart);
>   break;
>   }
>  }
> -- 
> 1.6.0.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 v2 0/6] OMAP: Make OMAP LDP boot succussfuly

2008-11-19 Thread Evgeniy Polyakov
On Wed, Nov 19, 2008 at 11:14:20AM -0800, Tony Lindgren ([EMAIL PROTECTED]) 
wrote:
> Thanks! The rest of the omap w1 patche should be coming to you via LKML
> then ;)

I've just pushed w1 patch (did I understand it right that there is only
one in the given set, all others touch very different areas).

-- 
Evgeniy Polyakov
--
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 v2 0/6] OMAP: Make OMAP LDP boot succussfuly

2008-11-19 Thread Tony Lindgren
* Evgeniy Polyakov <[EMAIL PROTECTED]> [081119 10:55]:
> On Wed, Nov 19, 2008 at 10:13:08AM -0800, Tony Lindgren ([EMAIL PROTECTED]) 
> wrote:
> > > If w1 part does not depend on any upstream changes not yet in the tree,
> > > I will forward it for inclusing, but if it requires some external update
> > > to be pushed first, I would like to add w1 part into that merge.
> > 
> > Yes, please include it into your queue, it does not have any other
> > omap dependencies. And we are trying to move all the omap driver
> > development to the appropriate driver lists to get in sync with the
> > mainline tree.
> 
> Ok, I will push this patch series upstream.
> Thank you.

Thanks! The rest of the omap w1 patche should be coming to you via LKML
then ;)

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 v2 0/6] OMAP: Make OMAP LDP boot succussfuly

2008-11-19 Thread Evgeniy Polyakov
On Wed, Nov 19, 2008 at 10:13:08AM -0800, Tony Lindgren ([EMAIL PROTECTED]) 
wrote:
> > If w1 part does not depend on any upstream changes not yet in the tree,
> > I will forward it for inclusing, but if it requires some external update
> > to be pushed first, I would like to add w1 part into that merge.
> 
> Yes, please include it into your queue, it does not have any other
> omap dependencies. And we are trying to move all the omap driver
> development to the appropriate driver lists to get in sync with the
> mainline tree.

Ok, I will push this patch series upstream.
Thank you.

-- 
Evgeniy Polyakov
--
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 v2 0/6] OMAP: Make OMAP LDP boot succussfuly

2008-11-19 Thread Tony Lindgren
* Evgeniy Polyakov <[EMAIL PROTECTED]> [081114 03:29]:
> Hi Tony.
> 
> On Thu, Nov 13, 2008 at 02:40:54PM -0800, Tony Lindgren ([EMAIL PROTECTED]) 
> wrote:
> > Evgeniy, can you please confirm you're adding the Stanley's 1w patch to your
> > upstream queue? Or else let Stanley know if he needs to repost it to
> > LKML.
> 
> If w1 part does not depend on any upstream changes not yet in the tree,
> I will forward it for inclusing, but if it requires some external update
> to be pushed first, I would like to add w1 part into that merge.

Yes, please include it into your queue, it does not have any other
omap dependencies. And we are trying to move all the omap driver
development to the appropriate driver lists to get in sync with the
mainline tree.

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] OMAP3: PM: Check in set_pwrdm_state that target state is supported by pwrdm v2

2008-11-19 Thread Tony Lindgren
* Kevin Hilman <[EMAIL PROTECTED]> [081118 15:56]:
> Paul Walmsley <[EMAIL PROTECTED]> writes:
> 
> > On Mon, 17 Nov 2008, Jouni Hogander wrote:
> >
> >> Check that wanted sleep state is supported by powerdomain. If it is
> >> not supported, then use next lowest supported state.
> >> 
> >> Check also on suspend that state of pwrdm was lower or equal.
> >> 
> >> Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
> >
> > Acked-by: Paul Walmsley <[EMAIL PROTECTED]>
> >
> 
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>

Pushing this 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 PM-20081106] OMAP: PM: Few fixes to uart clock handling

2008-11-19 Thread Kevin Hilman
Jouni Hogander <[EMAIL PROTECTED]> writes:

> Omap3_can_sleep is not inside part of idle loop which is protected
> with irg disable. If some irq handler is trying dump out something
> after omap3_can_sleep and before irqs are disabled. It causes oops
> because uart clocks are disabled.
>
> Remove also some unused extra code from omap_uart_can_sleep
>
> Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
> ---
>  arch/arm/mach-omap2/serial.c |   11 +--
>  1 files changed, 1 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index ef30d8d..b06b797 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -314,21 +314,13 @@ void omap_uart_check_wakeup(void)
>  int omap_uart_can_sleep(void)
>  {
>   struct omap_uart_state *uart;
> - int can_sleep = 1;
>  
>   list_for_each_entry(uart, &uart_list, node) {
> - if (!uart->clocked)
> + if (!uart->clocked || !uart->can_sleep)
>   continue;
>  
> - if (!uart->can_sleep) {
> - can_sleep = 0;
> - continue;
> - }
> -

I don't think this part is quite right.  I think this block should
stay, and the function should 'return can_sleep' instead of return 1;

I'll fix that, and incorporate your other changes here into
pm-20081118.

Kevin

>   /* This UART can now safely sleep. */
>   omap_uart_allow_sleep(uart);
> - if (clocks_off_while_idle)
> - omap_uart_disable_clocks(uart);
>   }
>  
>   return 1;
> @@ -435,7 +427,6 @@ static void omap_uart_pm(struct uart_port *port,
>   break;
>   case 3: /* suspend */
>   omap_uart_allow_sleep(uart);
> - omap_uart_disable_clocks(uart);
>   break;
>   }
>  }
> -- 
> 1.6.0.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] i2c: i2c-omap: Fix BUFSTAT_REG reading

2008-11-19 Thread David Brownell
On Wednesday 19 November 2008, Eero Nurkkala wrote:
> On Fri, 2008-11-14 at 11:16 -0800, ext David Brownell wrote:

> > But if the issue is that the 2430 version of the FIFO
> > support works differently, please say so in the patch
> > commend and code...
>
> I checked against 2420, and there was no such register
> avaiable at all.  (no 2430 TRM access)

That code path couldn't be triggered on 2420; just 2430,
which has the FIFO (as evidently needed for highspeed I2C).

My default assumption would be that 2430 works just like
OMAP3 here, but obviously someone should check the 2430
TRM to see its I2C BUFSTAT_REG really works differently.

- 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] PM: Fix a bug with noncore dpll rate calculation

2008-11-19 Thread Kevin Hilman
Tero Kristo <[EMAIL PROTECTED]> writes:

> Noncore dpll can enter autoidle state, in which case the rate calculation
> fails. Fixed by checking dpll mode instead of idle status.
>
> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>

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

> ---
>  arch/arm/mach-omap2/clock.c   |   16 +++-
>  arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
>  2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 522ce6f..bbd3e82 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -212,9 +212,16 @@ u32 omap2_get_dpll_rate(struct clk *clk)
>   return 0;
>  
>   /* Return bypass rate if DPLL is bypassed */
> - v = cm_read_mod_reg(clk->prcm_mod, dd->idlest_reg);
> - v &= dd->idlest_mask;
> - v >>= __ffs(dd->idlest_mask);
> + if (cpu_is_omap34xx()) {
> + v = cm_read_mod_reg(clk->prcm_mod, dd->control_reg);
> + v &= dd->enable_mask;
> + v >>= __ffs(dd->enable_mask);
> + } else {
> + v = cm_read_mod_reg(clk->prcm_mod, dd->idlest_reg);
> + v &= dd->idlest_mask;
> + v >>= __ffs(dd->idlest_mask);
> + }
> +
>   if (cpu_is_omap24xx()) {
>  
>   if (v == ST_CORE_CLK_REF)
> @@ -224,9 +231,8 @@ u32 omap2_get_dpll_rate(struct clk *clk)
>  
>   } else if (cpu_is_omap34xx()) {
>  
> - if (!v)
> + if (v == OMAP3430_EN_MPU_DPLL_BYPASS)
>   return dd->bypass_clk->rate;
> -
>   }
>  
>   v = cm_read_mod_reg(clk->prcm_mod, dd->mult_div1_reg);
> diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h 
> b/arch/arm/mach-omap2/cm-regbits-34xx.h
> index 6f3f5a3..9995353 100644
> --- a/arch/arm/mach-omap2/cm-regbits-34xx.h
> +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
> @@ -112,6 +112,8 @@
>  #define OMAP3430_EN_MPU_DPLL_DRIFTGUARD_MASK (1 << 3)
>  #define OMAP3430_EN_MPU_DPLL_SHIFT   0
>  #define OMAP3430_EN_MPU_DPLL_MASK(0x7 << 0)
> +#define OMAP3430_EN_MPU_DPLL_LOCK(0x7 << 0)
> +#define OMAP3430_EN_MPU_DPLL_BYPASS  (0x5 << 0)
>  
>  /* CM_IDLEST_MPU */
>  #define OMAP3430_ST_MPU  (1 << 0)
> -- 
> 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


[PATCH][OMAPZOOM] padconfig for NEC WVGA lcd

2008-11-19 Thread leed . aguilar
From: Leed Aguilar <[EMAIL PROTECTED]>

This patch sets the proper padconfig value for wvga spi chip select.

Also ensures that dvi output is disable.

LCD data lines has been changed to 24 for Zoom2

Signed-off-by: Leed Aguilar <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/mux.c |   15 ---
 arch/arm/plat-omap/display.c  |4 ++--
 arch/arm/plat-omap/include/mach/mux.h |8 
 drivers/video/omap/omap_disp_out.c|   25 +
 4 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 0e650a4..cd6de1d 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -25,10 +25,11 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 
@@ -450,7 +451,7 @@ MUX_CFG_34XX("AD2_3430_USB3FS_PHY_MM3_TXDAT", 0x188,
 MUX_CFG_34XX("AC1_3430_USB3FS_PHY_MM3_TXEN_N", 0x18a,
OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
 
- /* UART3 */
+/* UART3 */
 MUX_CFG_34XX("R21_3430_UART3_CTS_RCTX",0x19a,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
 MUX_CFG_34XX("T21_3430_UART3_RTS_SD", 0x19c,
@@ -460,11 +461,15 @@ MUX_CFG_34XX("U21_3430_UART3_RX_IRRX", 0x19e,
 MUX_CFG_34XX("V21_3430_UART3_TX_IRTX", 0x1a0,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
 
- /* GPIO */
+/* GPIO */
 MUX_CFG_34XX("T21_3430_GPIO164", 0x19c,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLDOWN)
 MUX_CFG_34XX("V21_3430_GPIO166", 0x1a0,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX("AF21_3430_GPIO8", 0xa16,
+   OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("B23_3430_GPIO167", 0x130,
+   OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
 
 /* 34XX GPIO - bidirectional, unless the name has an "_OUT" suffix.
  * No internal pullup/pulldown without "_UP" or "_DOWN" suffix.
@@ -473,6 +478,10 @@ MUX_CFG_34XX("AH8_34XX_GPIO29", 0x5fa,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
 MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+
+/* McSPI */
+MUX_CFG_34XX("AB1_3430_McSPI1_CS2", 0x1d2,
+   OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
 };
 
 #define OMAP34XX_PINS_SZ   ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/display.c b/arch/arm/plat-omap/display.c
index 9ec7ff2..2fca7a9 100644
--- a/arch/arm/plat-omap/display.c
+++ b/arch/arm/plat-omap/display.c
@@ -1975,10 +1975,10 @@ omap2_disp_config_lcd(u32 clkdiv, u32 hbp, u32 hfp, u32 
hsw,
 #endif
dispc_reg_out(DISPC_DIVISOR, divisor);
control = dispc_reg_in(DISPC_CONTROL);
-#ifdef CONFIG_FB_OMAP_720P_STREAMING
+#if defined(CONFIG_FB_OMAP_720P_STREAMING) || defined(CONFIG_MACH_OMAP_ZOOM2)
control |= DISPC_CONTROL_TFTDATALINES_OALSB24B;
 #else
-#if defined(CONFIG_MACH_OMAP_LDP) || defined(CONFIG_MACH_OMAP_ZOOM2)
+#ifdef CONFIG_MACH_OMAP_LDP
control |= DISPC_CONTROL_TFTDATALINES_OALSB18B;
 #else
control |= DISPC_CONTROL_TFTDATALINES_OALSB16B;
diff --git a/arch/arm/plat-omap/include/mach/mux.h 
b/arch/arm/plat-omap/include/mach/mux.h
index 0447a78..4055763 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -785,8 +785,13 @@ enum omap34xx_index {
T21_3430_UART3_RTS_SD,
U21_3430_UART3_RX_IRRX,
V21_3430_UART3_TX_IRTX,
+
+   /* GPIO */
T21_3430_GPIO164,
V21_3430_GPIO166,
+   AF21_3430_GPIO8,
+   B23_3430_GPIO167,
+
/* 34xx GPIO
 *  - normally these are bidirectional, no internal pullup/pulldown
 *  - "_UP" suffix (GPIO3_UP) if internal pullup is configured
@@ -795,6 +800,9 @@ enum omap34xx_index {
 */
AH8_34XX_GPIO29,
J25_34XX_GPIO170,
+
+   /* McSPI */
+   AB1_3430_McSPI1_CS2,
 };
 
 struct omap_mux_cfg {
diff --git a/drivers/video/omap/omap_disp_out.c 
b/drivers/video/omap/omap_disp_out.c
index 62bf126..4dc818e 100755
--- a/drivers/video/omap/omap_disp_out.c
+++ b/drivers/video/omap/omap_disp_out.c
@@ -30,25 +30,29 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
-#include 
-#include 
+
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #if defined(CONFIG_MACH_OMAP_2430SDP) || defined (CONFIG_MACH_OMAP_3430SDP) ||\
 defined(CONFIG_MACH_OMAP_LDP) || defined(CONFIG_MACH_OMAP_ZOOM2)
 #include 
 #endif
-#include 
-#include 
-#include 
 #ifdef CONFIG_PM
 #include 
 #include 
 #endif
-#include 
 #ifdef CONFIG_FB_OMAP_LCD_WVGA
 #include 
 #endif
@@ -129,7 +133,7 @@
 #define LCD_PANEL_RESET_GPIO   55
 #define LCD_PANEL_QVGA_GPIO56
 #define LCD_PANEL_BACKLIGHT_GPIO   (7 + OMAP_MAX_GPIO_LINES)
-#define DVI_OUTPUT_GPIO8
+#define DVI_OUTPUT_GPIO8
 #define DVI_POWER_ON_GPIO  167
 #e

[PATCH] Fix section mismatch warning.

2008-11-19 Thread Sanjeev Premi
This warning is observed when building for OMAP3EVM with pm-20081106.

WARNING: vmlinux.o(.data+0x89d4): Section mismatch in reference from the 
variable omap3evm_twldata to the variable .init.data:generic3430_t2scripts_data
The variable omap3evm_twldata references
the variable __initdata generic3430_t2scripts_data
If the reference is valid then annotate the
variable with __init* (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

Signed-off-by: Sanjeev Premi <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/board-omap3evm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index a72772f..65e0bdc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -130,7 +130,7 @@ static struct twl4030_madc_platform_data omap3evm_madc_data 
= {
.irq_line   = 1,
 };
 
-static struct twl4030_platform_data omap3evm_twldata = {
+static struct twl4030_platform_data __initdata omap3evm_twldata = {
.irq_base   = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
 
-- 
1.5.6

--
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] omap3evm asoc

2008-11-19 Thread Arun KS
On Wed, Nov 19, 2008 at 6:07 PM, Mark Brown <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 05:57:55PM +0530, naveen krishna ch wrote:
>
>> Is there any previous work on audio ASOC for OMAP3EVM.
>> I have started working on OMAP3EVM + TWL4030 combination and audio is
>> working.
>
> Not that I'm aware of, though Arun just submitted a patch for the
> omap2evm.  CCing in linux-omap who are more likely to know.
Hi Naveen,

   See the link,

http://marc.info/?l=linux-omap&m=122690496617326&w=2

> ___
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
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] omap3evm asoc

2008-11-19 Thread Mark Brown
On Wed, Nov 19, 2008 at 05:57:55PM +0530, naveen krishna ch wrote:

> Is there any previous work on audio ASOC for OMAP3EVM.
> I have started working on OMAP3EVM + TWL4030 combination and audio is
> working.

Not that I'm aware of, though Arun just submitted a patch for the
omap2evm.  CCing in linux-omap who are more likely to know.
--
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 1/1] ASoC: Add support for omap2evm board

2008-11-19 Thread Mark Brown
On Wed, Nov 19, 2008 at 05:45:19PM +0530, Arun KS wrote:
> This patch adds twl4030 audio support on omap2evm
> 
> Signed-off-by: Arun KS <[EMAIL PROTECTED]>

Acked-by: Mark Brown <[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


RE: new PM branch: pm-20081106

2008-11-19 Thread Rajendra Nayak
 

> -Original Message-
> From: Kevin Hilman [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, November 11, 2008 10:51 PM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org
> Subject: Re: new PM branch: pm-20081106
> 
> "Rajendra Nayak" <[EMAIL PROTECTED]> writes:
> 
> > I am seeing a couple of issues on the 3430sdp with this latest pm
> > branch.  With the omap_3430sdp_min_defconfig I see a system freeze
> > after bootup after the debug UART inactivity. Also system wide
> > suspend seems to freeze.  The system wide suspend freeze is seen
> > even with the default (omap_3430sdp_defconfig) config.  I ran into
> > these issue while validating the DVFS patches and haven't really
> > looked further into what might be causing these. I have a ES3.0 GP
> > based SDP board.
> 
> Rajendra,
> 
> I just pushed another patch to pm-20081106 for you to try.  This
> reverts a commit[1] from linux-omap which is causing problems coming
> out of retention.
> 
> Could you update your PM branch, and also modify the 'enabled_uarts'
> settings in your board-3430sdp.c file so that only the console UART is
> enabled.  Doing this would help me understand what's working on SDP.
> 
> Until I get my SDP, I'll need to rely on you for this testing.
>

Hi Kevin,

Sorry for the delay in responding. The latest pm branch does seem 
to work fine on my SDP after taking in Jouni's patch
"[PATCH PM-20081106] OMAP3: UART: Make sure that uart clocks are enabled when 
needed"
and restricting the enabled_uarts to debug console.
I however did not see the VCORE led blink while hitting OFF.

regards,
Rajendra

> 
> [1] 2ac1da8c787f73f067e717408e631501ba60aabc
> 
> >> -Original Message-
> >> From: [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Hilman
> >> Sent: Friday, November 07, 2008 11:00 PM
> >> To: linux-omap@vger.kernel.org
> >> Subject: new PM branch: pm-20081106
> >> 
> >> For those who want to experiment with the latest PM 
> branch, it is now
> >> available in OMAP git as branch pm-20081106
> >> 
> >> The shortlog is below[1], but the significant thing for now is a
> >> rework of how UART handles its clocks and allows idle.  I also did
> >> quite a bit of reordering and some restructuring.
> >> 
> >> I've tested this on Nokia HW and the basic 
> retention-on-idle support
> >> on Beagle.  I'm still waiting for my SDP to arrive, so 
> haven't tested
> >> on SDP.
> >> 
> >> Kevin
> >> 
> >> [1]
> >> Amit Kucheria (2):
> >>   OMAP: PM: Typo fix for clock_allow_idle
> >>   HSMMC: Make driver support dynamic idle
> >> 
> >> Jouni Hogander (5):
> >>   OMAP3: PM: Use pwrdm_set_next_pwrst instead of 
> >> set_pwrdm_state in idle loop
> >>   OMAP3: Do not set mpu, core, neon states if cpuidle is used
> >>   OMAP3: PM: Do not set next states sw to control those 
> >> is available
> >>   OMAP3: PM: Always return value in pwrdms_setup
> >>   OMAP3: PM: Fix wrong sequence in suspend.
> >> 
> >> Kalle Jokiniemi (3):
> >>   OMAP: PM: sysfs interface for enabling voltage off in idle
> >>   OMAP3: PM: Fix cpu idle init sequencing
> >>   OMAP: SRF: Fixes to shared resource framework (Ver.3)
> >> 
> >> Kevin Hilman (10):
> >>   OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
> >>   OMAP3: PM: Allow UARTs to be unclocked when inactive
> >>   8250: Allow platform to register PM hook
> >>   8250: when waking, PM hook should be called before 
> >> accessing port
> >>   OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume
> >>   OMAP3: PM: UART save/restore support for OFF-mode
> >>   OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot
> >>   OMAP3: PM: CPUidle: obey enable_off_mode flag
> >>   OMAP3: PM: CPUidle: restrict C-states on UART activity
> >>   OMAP3: PM: decouple PER and CORE context save and restore
> >> 
> >> Paul Walmsley (6):
> >>   OMAP2/3 PM: create the OMAP PM interface and add a 
> >> default OMAP PM no-op layer.
> >>   OMAP2/3 omapdev: add basic omapdev structure
> >>   OMAP242x omapdev: add OMAP242x omapdev records
> >>   OMAP243x omapdev: add OMAP243x omapdev records
> >>   OMAP3xxx omapdev: add OMAP3xxx omapdev records
> >>   OMAP2/3 omapdev: add code to walk the omapdev records
> >> 
> >> Peter 'p2' De Schrijver (9):
> >>   OMAP: PM counter infrastructure.
> >>   OMAP: PM: Hook into PM counters
> >>   OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each.
> >>   OMAP: PM: Add pm-debug counters
> >>   OMAP: PM debug: make powerdomains use PM-debug counters
> >>   OMAP: PM: Add definitions for ETK pads and 
> >> observability registers
> >>   OMAP: Debug observability and ETK padconf implementation
> >>   OMAP: Add debug observablity (debobs) Kconfig item
> >>   OMAP: PM: Implement get_last_off_on_transaction_id()
> >> 
> >> Rajendra Nayak (23):
> >>   OMAP3: PM: GPMC context save/restore
> >>   OMAP3: PM: GPIO context save/restore
> >>   

Re: [PATCH] i2c: i2c-omap: Fix BUFSTAT_REG reading

2008-11-19 Thread Eero Nurkkala
On Fri, 2008-11-14 at 11:16 -0800, ext David Brownell wrote:
> On Friday 14 November 2008, [EMAIL PROTECTED] wrote:
> > The amount of bytes to receive is read from wrong
> > place. It is the 6 bits starting from the bit 8 from
> > BUFSTAT_REG that indicate this amount. Not the 8 LSB:s.
> > Only 6 LSB:s are used for the TX buffer. Also, with
> > omap 3430, only the 6 LSB:s are relevant for XDR.
> 
> So to summarize:  2430 and 3430 define this register
> differently?  Lacking 2430 docs, I can't verify that.
> 
> Agreed that 3430 has two 6-bit fields, RXSTAT at 8..13
> and TXSTAT at 0..5, so this code is wrong for 3430.
> 
> But if the issue is that the 2430 version of the FIFO
> support works differently, please say so in the patch
> commend and code...
> 
> - Dave
> 

I checked against 2420, and there was no such register avaiable at all.
(no 2430 TRM access)

--
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/1] ASoC: Add support for omap2evm board

2008-11-19 Thread Arun KS
This patch adds twl4030 audio support on omap2evm

Signed-off-by: Arun KS <[EMAIL PROTECTED]>
---
 sound/soc/omap/Kconfig|9 +++
 sound/soc/omap/Makefile   |2 +
 sound/soc/omap/omap2evm.c |  150 +
 3 files changed, 161 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/omap/omap2evm.c

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index cf40e42..6c56277 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -30,4 +30,13 @@ config SND_OMAP_SOC_OVERO
help
  Say Y if you want to add support for SoC audio on the Gumstix Overo.

+config SND_OMAP_SOC_OMAP2EVM
+   tristate "SoC Audio support for OMAP2EVM board"
+   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 board.
+
+

diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index fefc9be..f5da3cc 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -9,8 +9,10 @@ obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
 snd-soc-n810-objs := n810.o
 snd-soc-osk5912-objs := osk5912.o
 snd-soc-overo-objs := overo.o
+snd-soc-omap2evm-objs := omap2evm.o

 obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
 obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o
 obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
+obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o

diff --git a/sound/soc/omap/omap2evm.c b/sound/soc/omap/omap2evm.c
new file mode 100644
index 000..c376213
--- /dev/null
+++ b/sound/soc/omap/omap2evm.c
@@ -0,0 +1,150 @@
+/*
+ * omap2evm.c  --  SoC audio machine driver for omap2evm board
+ *
+ * Author: Arun KS <[EMAIL PROTECTED]>
+ *
+ * Based on sound/soc/omap/overo.c by Steve Sakoman
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "omap-mcbsp.h"
+#include "omap-pcm.h"
+#include "../codecs/twl4030.h"
+
+static int omap2evm_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *codec_dai = rtd->dai->codec_dai;
+   struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
+   int ret;
+
+   /* Set codec DAI configuration */
+   ret = snd_soc_dai_set_fmt(codec_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+   if (ret < 0) {
+   printk(KERN_ERR "can't set codec DAI configuration\n");
+   return ret;
+   }
+
+   /* Set cpu DAI configuration */
+   ret = snd_soc_dai_set_fmt(cpu_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+   if (ret < 0) {
+   printk(KERN_ERR "can't set cpu DAI configuration\n");
+   return ret;
+   }
+
+   /* Set the codec system clock for DAC and ADC */
+   ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600,
+   SND_SOC_CLOCK_IN);
+   if (ret < 0) {
+   printk(KERN_ERR "can't set codec system clock\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_ops omap2evm_ops = {
+   .hw_params = omap2evm_hw_params,
+};
+
+/* Digital audio interface glue - connects codec <--> CPU */
+static struct snd_soc_dai_link omap2evm_dai = {
+   .name = "TWL4030",
+   .stream_name = "TWL4030",
+   .cpu_dai = &omap_mcbsp_dai[0],
+   .codec_dai = &twl4030_dai,
+   .ops = &omap2evm_ops,
+};
+
+/* Audio machine driver */
+static struct snd_soc_machine snd_soc_machine_omap2evm = {
+   .name = "omap2evm",
+   .dai_link = &omap2evm_dai,
+   .num_links = 1,
+};
+
+/* Audio subsystem */
+static struct snd_soc_device omap2evm_snd_devdata = {
+   .machine = &snd_soc_machine_omap2evm,
+   .platform = &omap_soc_platform,
+   .codec_dev = &soc_codec_dev_twl4030,
+};
+
+static struct platform_device *omap2evm_snd_device;
+
+static int __ini

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

2008-11-19 Thread Eero Nurkkala
On Fri, 2008-11-14 at 11:45 -0800, ext David Brownell wrote:
> On Friday 14 November 2008, [EMAIL PROTECTED] wrote:
> > The prescalers for 100 kHz and 400 kHz mode
> > are wrong. The internal clock is the fclock
> > divided by the prescaler. The PSC is an 8 bit
> > field in omap3430. 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.
> 
> Should this fix the bug causing the need for that
> recent ZOOM patch slowing down twl4030 communication
> to 400 MHz?
> 
> And should it let at least some boards talk to their
> TWL chips at 3.4 MBit/sec (top speed for standard
> highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)?
> I've always wondered why all the boards configured
> those links to be seemingly slower than allowed ...
> 
> - Dave
> 

Well, this should not affect the High speed I2C at all.
Only fast and slow I2C (100 and 400 khz).


--
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 0/1] Save sram context after changing MPU, DSP or core clocks

2008-11-19 Thread Peter 'p2' De Schrijver
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.

Peter 'p2' De Schrijver (1):
  Save sram context after changing MPU, DSP or core clocks

 arch/arm/mach-omap2/clock34xx.c |3 +++
 1 files changed, 3 insertions(+), 0 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


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

2008-11-19 Thread Peter 'p2' De Schrijver

Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/clock34xx.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index d97d5a9..962ce56 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -911,6 +911,9 @@ printk("%s set to %luHz intended rate 
%luHz\n",dpll2_clk->name,clk_get_rate(dpll
clk_set_rate(dpll3_clk, prcm_vdd->rate);
curr_vdd2_prcm_set = prcm_vdd;
}
+
+   omap3_save_scratchpad_contents();
+
return 0;
 }
 
-- 
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


[PATCH PM-20081106] OMAP: PM: Few fixes to uart clock handling

2008-11-19 Thread Jouni Hogander
Omap3_can_sleep is not inside part of idle loop which is protected
with irg disable. If some irq handler is trying dump out something
after omap3_can_sleep and before irqs are disabled. It causes oops
because uart clocks are disabled.

Remove also some unused extra code from omap_uart_can_sleep

Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/serial.c |   11 +--
 1 files changed, 1 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ef30d8d..b06b797 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -314,21 +314,13 @@ void omap_uart_check_wakeup(void)
 int omap_uart_can_sleep(void)
 {
struct omap_uart_state *uart;
-   int can_sleep = 1;
 
list_for_each_entry(uart, &uart_list, node) {
-   if (!uart->clocked)
+   if (!uart->clocked || !uart->can_sleep)
continue;
 
-   if (!uart->can_sleep) {
-   can_sleep = 0;
-   continue;
-   }
-
/* This UART can now safely sleep. */
omap_uart_allow_sleep(uart);
-   if (clocks_off_while_idle)
-   omap_uart_disable_clocks(uart);
}
 
return 1;
@@ -435,7 +427,6 @@ static void omap_uart_pm(struct uart_port *port,
break;
case 3: /* suspend */
omap_uart_allow_sleep(uart);
-   omap_uart_disable_clocks(uart);
break;
}
 }
-- 
1.6.0.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


RE: [PATCH] PM: Added three PLL registers to the PRCM context save

2008-11-19 Thread Tero.Kristo
Hi,

Just an initial comment to this patch, this is somewhat experimental and
I think we should agree what registers will actually be saved here and
what should be left for drivers. CM_CLKSEL4 is for DPLL5 which is used
by USB. Two of the CLKEN registers are more interesting.

-Tero

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
>Sent: 19 November, 2008 11:32
>To: linux-omap@vger.kernel.org
>Subject: [PATCH] PM: Added three PLL registers to the PRCM context save
>
>These registers are now also saved:
>   CM_CLKSEL4
>   CM_CLKEN
>   CM_CLKEN2
>
>Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>---
> arch/arm/mach-omap2/prcm.c |   14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/prcm.c 
>b/arch/arm/mach-omap2/prcm.c index d5a1e4b..c64b668 100644
>--- a/arch/arm/mach-omap2/prcm.c
>+++ b/arch/arm/mach-omap2/prcm.c
>@@ -46,7 +46,10 @@ struct omap3_prcm_regs {
>   u32 emu_cm_clksel;
>   u32 emu_cm_clkstctrl;
>   u32 pll_cm_autoidle2;
>+  u32 pll_cm_clksel4;
>   u32 pll_cm_clksel5;
>+  u32 pll_cm_clken;
>+  u32 pll_cm_clken2;
>   u32 cm_polctrl;
>   u32 iva2_cm_fclken;
>   u32 core_cm_fclken1;
>@@ -233,8 +236,14 @@ void omap3_prcm_save_context(void)
>cm_read_mod_reg(OMAP3430_EMU_MOD, 
>CM_CLKSTCTRL);
>   prcm_context.pll_cm_autoidle2 =
>cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
>+  prcm_context.pll_cm_clksel4 =
>+  cm_read_mod_reg(PLL_MOD, 
>OMAP3430ES2_CM_CLKSEL4);
>   prcm_context.pll_cm_clksel5 =
>cm_read_mod_reg(PLL_MOD, 
>OMAP3430ES2_CM_CLKSEL5);
>+  prcm_context.pll_cm_clken =
>+  cm_read_mod_reg(PLL_MOD, CM_CLKEN);
>+  prcm_context.pll_cm_clken2 =
>+  cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
>   prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
>   prcm_context.iva2_cm_fclken =
>cm_read_mod_reg(OMAP3430_IVA2_MOD, 
>CM_FCLKEN); @@ -380,8 +389,13 @@ void omap3_prcm_restore_context(void)
>CM_CLKSTCTRL);
>   cm_write_mod_reg(prcm_context.pll_cm_autoidle2, PLL_MOD,
>CM_AUTOIDLE2);
>+  cm_write_mod_reg(prcm_context.pll_cm_clksel4, PLL_MOD,
>+  OMAP3430ES2_CM_CLKSEL4);
>   cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
>OMAP3430ES2_CM_CLKSEL5);
>+  cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
>+  cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
>+  OMAP3430ES2_CM_CLKEN2);
>   __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
>   cm_write_mod_reg(prcm_context.iva2_cm_fclken, OMAP3430_IVA2_MOD,
>CM_FCLKEN);
>--
>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


[PATCH] PM: Added three PLL registers to the PRCM context save

2008-11-19 Thread Tero Kristo
These registers are now also saved:
CM_CLKSEL4
CM_CLKEN
CM_CLKEN2

Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/prcm.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index d5a1e4b..c64b668 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -46,7 +46,10 @@ struct omap3_prcm_regs {
u32 emu_cm_clksel;
u32 emu_cm_clkstctrl;
u32 pll_cm_autoidle2;
+   u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
+   u32 pll_cm_clken;
+   u32 pll_cm_clken2;
u32 cm_polctrl;
u32 iva2_cm_fclken;
u32 core_cm_fclken1;
@@ -233,8 +236,14 @@ void omap3_prcm_save_context(void)
 cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSTCTRL);
prcm_context.pll_cm_autoidle2 =
 cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
+   prcm_context.pll_cm_clksel4 =
+   cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
prcm_context.pll_cm_clksel5 =
 cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
+   prcm_context.pll_cm_clken =
+   cm_read_mod_reg(PLL_MOD, CM_CLKEN);
+   prcm_context.pll_cm_clken2 =
+   cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
prcm_context.iva2_cm_fclken =
 cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_FCLKEN);
@@ -380,8 +389,13 @@ void omap3_prcm_restore_context(void)
 CM_CLKSTCTRL);
cm_write_mod_reg(prcm_context.pll_cm_autoidle2, PLL_MOD,
 CM_AUTOIDLE2);
+   cm_write_mod_reg(prcm_context.pll_cm_clksel4, PLL_MOD,
+   OMAP3430ES2_CM_CLKSEL4);
cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
 OMAP3430ES2_CM_CLKSEL5);
+   cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
+   cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
+   OMAP3430ES2_CM_CLKEN2);
__raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
cm_write_mod_reg(prcm_context.iva2_cm_fclken, OMAP3430_IVA2_MOD,
 CM_FCLKEN);
-- 
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] PM: Fix a bug with noncore dpll rate calculation

2008-11-19 Thread Tero Kristo
Noncore dpll can enter autoidle state, in which case the rate calculation
fails. Fixed by checking dpll mode instead of idle status.

Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/clock.c   |   16 +++-
 arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 522ce6f..bbd3e82 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -212,9 +212,16 @@ u32 omap2_get_dpll_rate(struct clk *clk)
return 0;
 
/* Return bypass rate if DPLL is bypassed */
-   v = cm_read_mod_reg(clk->prcm_mod, dd->idlest_reg);
-   v &= dd->idlest_mask;
-   v >>= __ffs(dd->idlest_mask);
+   if (cpu_is_omap34xx()) {
+   v = cm_read_mod_reg(clk->prcm_mod, dd->control_reg);
+   v &= dd->enable_mask;
+   v >>= __ffs(dd->enable_mask);
+   } else {
+   v = cm_read_mod_reg(clk->prcm_mod, dd->idlest_reg);
+   v &= dd->idlest_mask;
+   v >>= __ffs(dd->idlest_mask);
+   }
+
if (cpu_is_omap24xx()) {
 
if (v == ST_CORE_CLK_REF)
@@ -224,9 +231,8 @@ u32 omap2_get_dpll_rate(struct clk *clk)
 
} else if (cpu_is_omap34xx()) {
 
-   if (!v)
+   if (v == OMAP3430_EN_MPU_DPLL_BYPASS)
return dd->bypass_clk->rate;
-
}
 
v = cm_read_mod_reg(clk->prcm_mod, dd->mult_div1_reg);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h 
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6f3f5a3..9995353 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -112,6 +112,8 @@
 #define OMAP3430_EN_MPU_DPLL_DRIFTGUARD_MASK   (1 << 3)
 #define OMAP3430_EN_MPU_DPLL_SHIFT 0
 #define OMAP3430_EN_MPU_DPLL_MASK  (0x7 << 0)
+#define OMAP3430_EN_MPU_DPLL_LOCK  (0x7 << 0)
+#define OMAP3430_EN_MPU_DPLL_BYPASS(0x5 << 0)
 
 /* CM_IDLEST_MPU */
 #define OMAP3430_ST_MPU(1 << 0)
-- 
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