Re: [PATCH 2/2] DSPBRIDGE: New reserved memory accounting framework

[Felipe Contreras]

On Wed, Feb 17, 2010 at 4:05 AM, Guzman Lugo, Fernando x0095...@ti.com wrote:
  struct DSPHEAP_RES_OBJECT {
        s32            heapAllocated; /* DMM status */
 @@ -141,6 +150,10 @@ struct PROCESS_CONTEXT{
        /* DMM mapped memory resources */
        struct DMM_MAP_OBJECT *dmm_map_list;

 +       /* DMM reserved memory resources */
 +       struct list_head dmm_rsv_list;
 +       spinlock_t dmm_rsv_list_lock;
 +

Why rsv requires a spinlock, but not map?

I guess it would be needed if somehow PROC_UnReserveMemory() was
called by user-space at the same time than bridge_close, but is that
really possible? If it is, then the same danger is present with
PROC_UnMap() unless I'm missing something.

 No, that's not possible. However protection is still needed for PROC_ 
 ReserveMemory/UnReserveMemory and also for PROC_Map/UnMap.

Ok, then I guess it would make sense to have a patch for
DMM_RSV_OBJECT, and another one to add the protection to both
PROC_Map/UnMap/Reserve/UnReserve().

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

RE: [PATCH] omap: Remove DEBUGFS dependency for mux name checking

[Premi, Sanjeev]

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
 Lohithakshan, Ranjith
 Sent: Wednesday, February 17, 2010 11:48 AM
 To: linux-omap@vger.kernel.org
 Cc: t...@atomide.com; Lohithakshan, Ranjith
 Subject: [PATCH] omap: Remove DEBUGFS dependency for mux name checking
 
 The check for a valid mux name should be performed regardless 
 of whether
 DEBUGFS is enabled or not.
 
 This fixes the issue currently seen with boards not booting up
 if DEBUGFS is not enabled in defconfig.
 
 Signed-off-by: Ranjith Lohithakshan ranji...@ti.com
 ---
  arch/arm/mach-omap2/mux.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 

Ranjith,

For better readability, I suggest the following:

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 19001dd..7c0c4ad 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -960,16 +960,14 @@ static void __init omap_mux_init_list(struct omap_mux *sup
while (superset-reg_offset !=  OMAP_MUX_TERMINATOR) {
struct omap_mux *entry;

-#ifndef CONFIG_OMAP_MUX
-   /* Skip pins that are not muxed as GPIO by bootloader */
-   if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
+#ifdef CONFIG_OMAP_MUX
+   if (!superset-muxnames || !superset-muxnames[0]) {
superset++;
continue;
}
-#endif
-
-#if defined(CONFIG_OMAP_MUX)  defined(CONFIG_DEBUG_FS)
-   if (!superset-muxnames || !superset-muxnames[0]) {
+#else
+   /* Skip pins that are not muxed as GPIO by bootloader */
+   if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
superset++;
continue;
}

Best regards,
Sanjeev


 diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
 index 986077f..1a6ff8f 100644
 --- a/arch/arm/mach-omap2/mux.c
 +++ b/arch/arm/mach-omap2/mux.c
 @@ -969,7 +969,7 @@ static void __init 
 omap_mux_init_list(struct omap_mux *superset)
   }
  #endif
  
 -#if defined(CONFIG_OMAP_MUX)  defined(CONFIG_DEBUG_FS)
 +#ifdef CONFIG_OMAP_MUX
   if (!superset-muxnames || !superset-muxnames[0]) {
   superset++;
   continue;
 -- 
 1.6.2.4
 
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
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: OMAP Audio

[Peter Ujfalusi]

On Wednesday 17 February 2010 09:03:39 ext Jarkko Nikula wrote:
 On Tue, 16 Feb 2010 11:19:25 -0700
 
 Gary Thomas g...@mlbassoc.com wrote:
  I need to connect the OMAP (3530) to a 24bit CODEC.  So far
  my attempts at getting this to go have not gone well.  Then
  
  I ran across this comment in sound/soc/omap/omap-pcm.c:
  /*
  
   * Note: Regardless of interface data formats supported by OMAP McBSP
   * or EAC blocks, internal representation is always fixed 16-bit/sample
   */
  
  Does this mean that this setup is just not supported?  even though
  the hardware can handle it?
 
 Yep, comment is bit misleading but true until some patch will remove
 it. IRCC, the EAC was limited to 16-bit and also there wasn't need and
 HW to test other formats than S16_LE in McBSP DAI.
 
  Thanks for any pointers or ideas on how to get this going.
 
 I would first start adding support for the S32_LE into omap-pcm.c (DMA
 part). Worth to look this thread:
 
 http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024704.ht
 ml
 
 Then add support for this format to the omap-mcbsp.c (link
 configuration part).
 
 Next step would be to add support for the S24_LE on 4-byte boundaries.
 I.e. the DMA is moving 32-bit samples between the memory and McBSP but
 only 24-bits are transferred over the McBSP and codec.

Hmmm, I think this is a bit more complicated than that at least on OMAP3.
I think the DMA engine should also move 24 bit words.
This is dictated by the McBSP FIFO: it has a notion of word size, and it is 
expecting that the DMA engine will move THRESHOLD number of words. So if the 
McBSP is configured for 24 bit words, than the DMA word size has to match that.

Apart from this, the constraint set for the period bytes need to be changed 
since as you change the word size in McBSP you will have different amount of 
actual bytes for the FIFO (the FIFO size is in words, and the maximum word size 
is 32 bit).

-- 
Péter
--
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: OMAP Audio

[Gary Thomas]

On 02/17/2010 03:26 AM, Peter Ujfalusi wrote:

On Wednesday 17 February 2010 09:03:39 ext Jarkko Nikula wrote:

On Tue, 16 Feb 2010 11:19:25 -0700

Gary Thomasg...@mlbassoc.com  wrote:

I need to connect the OMAP (3530) to a 24bit CODEC.  So far
my attempts at getting this to go have not gone well.  Then

I ran across this comment in sound/soc/omap/omap-pcm.c:
/*

 * Note: Regardless of interface data formats supported by OMAP McBSP
 * or EAC blocks, internal representation is always fixed 16-bit/sample
 */

Does this mean that this setup is just not supported?  even though
the hardware can handle it?


Yep, comment is bit misleading but true until some patch will remove
it. IRCC, the EAC was limited to 16-bit and also there wasn't need and
HW to test other formats than S16_LE in McBSP DAI.


Thanks for any pointers or ideas on how to get this going.


I would first start adding support for the S32_LE into omap-pcm.c (DMA
part). Worth to look this thread:

http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024704.ht
ml

Then add support for this format to the omap-mcbsp.c (link
configuration part).

Next step would be to add support for the S24_LE on 4-byte boundaries.
I.e. the DMA is moving 32-bit samples between the memory and McBSP but
only 24-bits are transferred over the McBSP and codec.


Hmmm, I think this is a bit more complicated than that at least on OMAP3.
I think the DMA engine should also move 24 bit words.
This is dictated by the McBSP FIFO: it has a notion of word size, and it is
expecting that the DMA engine will move THRESHOLD number of words. So if the
McBSP is configured for 24 bit words, than the DMA word size has to match that.

Apart from this, the constraint set for the period bytes need to be changed
since as you change the word size in McBSP you will have different amount of
actual bytes for the FIFO (the FIFO size is in words, and the maximum word size
is 32 bit).



Thanks for the help.  I'm pretty sure I understand how to change
the McBSP code (omap-mcbsp.c) to handle the various formats, but
I'm a bit lost in the DMA setup (omap-pcm.c).  How do I identify
the code/width in omap_pcm_prepare()?

Has no one ever used the OMAP/McBSP with data sizes other than 16 bits??

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: [RESEND] [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists

[Ameya Palande]

Hi Fernando,

On Wed, 2010-02-10 at 09:32 +0100, ext Guzman Lugo, Fernando wrote:
 Please discard previous one.
 
 Regards,
 Fernando.
 
 From 6bcdc02f6265246e385194433775e75db7ad44cf Mon Sep 17 00:00:00 2001
 From: Fernando Guzman Lugo x0095...@ti.com
 Date: Wed, 10 Feb 2010 02:31:40 -0600
 Subject: [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists
 
 This patch protects the Resorce cleanup lists from
 concurrent access
 
 Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
 ---
  arch/arm/plat-omap/include/dspbridge/drv.h |3 +
  drivers/dsp/bridge/pmgr/wcd.c  |   16 ++-
  drivers/dsp/bridge/rmgr/drv.c  |   71 +++
  drivers/dsp/bridge/rmgr/drv_interface.c|8 ++-
  4 files changed, 83 insertions(+), 15 deletions(-)
 
 diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h 
 b/arch/arm/plat-omap/include/dspbridge/drv.h
 index b6a5fd2..b044291 100644
 --- a/arch/arm/plat-omap/include/dspbridge/drv.h
 +++ b/arch/arm/plat-omap/include/dspbridge/drv.h
 @@ -137,15 +137,18 @@ struct PROCESS_CONTEXT{
  
   /* DSP Node resources */
   struct NODE_RES_OBJECT *pNodeList;
 + struct mutex node_mutex;
  
   /* DMM resources */
   struct DMM_RES_OBJECT *pDMMList;
 + struct mutex dmm_mutex;
  
   /* DSP Heap resources */
   struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
  
   /* Stream resources */
   struct STRM_RES_OBJECT *pSTRMList;
 + struct mutex strm_mutex;
  } ;

Is there a specific reason for using mutex instead of spin_lock?

AFAIU these locks are help for very short time, for inserting / removing
elements from linked list, or traversing a linked list.

Cheers,
Ameya.

--
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] OMAP3: PM: Wakeup from TWL4030 keypad with OFF mode

[Premi, Sanjeev]

 

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com] 
 Sent: Wednesday, February 17, 2010 4:24 AM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 3/3] OMAP3: PM: Wakeup from TWL4030 
 keypad with OFF mode
 
 Premi, Sanjeev pr...@ti.com writes:
 
  -Original Message-
  From: Kevin Hilman [mailto:khil...@deeprootsystems.com] 
  Sent: Friday, February 05, 2010 3:22 AM
  To: Premi, Sanjeev
  Cc: linux-omap@vger.kernel.org
  Subject: Re: [PATCH 3/3] OMAP3: PM: Wakeup from TWL4030 
  keypad with OFF mode
  
  Sanjeev Premi pr...@ti.com writes:
  
   This patch allows wakeup from TWL4030 keypad when
   OFF mode is hit during suspend.
  
   Tested on OMAP3EVM.
  
   Signed-off-by: Sanjeev Premi pr...@ti.com
  
  The idea here looks good, but there is nothing realy EVM 
 specific here
  AFAICT, and this exact code could be used on any other board using
  the T2 keypad, right?  How about a common location?
 
  [sp] The EVM uses SYS_NIRQ for hooking up with the T2 keypad. Not
   sure of everyone would be doing so. Also, PADCONFs are more
   applicable for OMAP3, but T2 can be used with other processors
   as well...
 
   I did initially inplement these functions in:
   drivers/input/keyboard/twl4030_keypad.c
 
   ...but then moved to board specific file.
 
 I know at least SDP and EVM have these hooked up identically, 
 so some common
 way to set them up would be preferred.  Maybe a 
 mach-omap2/t2-keypad.c that
 could be shared between various board files.  The board files 
 would still
 configure the IRQ line and the padconfs used.

[sp] Yes. This can be done.

Best regards,
Sanjeev

 
 Kevin
 
 
 
  
  Also, after looking at this patch, I think the 'void 
 *pstate' member
  of struct twl4030_keypad_data should be renamed to 'void *data' to
  be more clear that it's just a pointer.
 
  [sp] Will make the change. However, will wait for your 
 response on the
   earlier comment before re-submit.
 
  ~sanjeev
 
  
  Kevin
  
  
 
  [snip]--[snip]
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] OMAP: DSS2: fix driver probe error handling

[Tomi Valkeinen]

If driver's probe failed, the uninit was not called.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/dss/core.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 967cbda..39b1a20 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -778,6 +778,7 @@ static int dss_driver_probe(struct device *dev)
 
if (r) {
DSSERR(driver probe failed: %d\n, r);
+   dss_uninit_device(core.pdev, dssdev);
return r;
}
 
-- 
1.6.5

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

[PATCH 1/4] OMAP: DSS2: remove sub-panel system

[Tomi Valkeinen]

The system to allow panel drivers to exists as attached to ctrl drivers
did never work very well. It is not useed, and this patch removes it to
make the driver cleaner.

For now, controller drivers need to include also the panel driver code. In
the future a proper mechanism for this should be developed, perhaps by
creating busses for controllers.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 arch/arm/plat-omap/include/plat/display.h |3 --
 drivers/video/omap2/dss/core.c|   35 ++--
 drivers/video/omap2/dss/display.c |   32 +
 3 files changed, 5 insertions(+), 65 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/display.h 
b/arch/arm/plat-omap/include/plat/display.h
index 8c3688b..0022f6c 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -431,14 +431,11 @@ struct omap_dss_device {
enum omap_panel_config config;
 
u8 recommended_bpp;
-
-   struct omap_dss_device *ctrl;
} panel;
 
struct {
u8 pixel_size;
struct rfbi_timings rfbi_timings;
-   struct omap_dss_device *panel;
} ctrl;
 
int reset_gpio;
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 72547df..967cbda 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -771,11 +771,8 @@ static int dss_driver_probe(struct device *dev)
 
dss_init_device(core.pdev, dssdev);
 
-   /* skip this if the device is behind a ctrl */
-   if (!dssdev-panel.ctrl) {
-   force = pdata-default_device == dssdev;
-   dss_recheck_connections(dssdev, force);
-   }
+   force = pdata-default_device == dssdev;
+   dss_recheck_connections(dssdev, force);
 
r = dssdrv-probe(dssdev);
 
@@ -861,8 +858,6 @@ static void omap_dss_dev_release(struct device *dev)
 int omap_dss_register_device(struct omap_dss_device *dssdev)
 {
static int dev_num;
-   static int panel_num;
-   int r;
 
WARN_ON(!dssdev-driver_name);
 
@@ -871,36 +866,12 @@ int omap_dss_register_device(struct omap_dss_device 
*dssdev)
dssdev-dev.parent = dss_bus;
dssdev-dev.release = omap_dss_dev_release;
dev_set_name(dssdev-dev, display%d, dev_num++);
-   r = device_register(dssdev-dev);
-   if (r)
-   return r;
-
-   if (dssdev-ctrl.panel) {
-   struct omap_dss_device *panel = dssdev-ctrl.panel;
-
-   panel-panel.ctrl = dssdev;
-
-   reset_device(panel-dev, 1);
-   panel-dev.bus = dss_bus_type;
-   panel-dev.parent = dssdev-dev;
-   panel-dev.release = omap_dss_dev_release;
-   dev_set_name(panel-dev, panel%d, panel_num++);
-   r = device_register(panel-dev);
-   if (r)
-   return r;
-   }
-
-   return 0;
+   return device_register(dssdev-dev);
 }
 
 void omap_dss_unregister_device(struct omap_dss_device *dssdev)
 {
device_unregister(dssdev-dev);
-
-   if (dssdev-ctrl.panel) {
-   struct omap_dss_device *panel = dssdev-ctrl.panel;
-   device_unregister(panel-dev);
-   }
 }
 
 /* BUS */
diff --git a/drivers/video/omap2/dss/display.c 
b/drivers/video/omap2/dss/display.c
index 3b92b84..3f345b8 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -591,10 +591,6 @@ struct omap_dss_device *omap_dss_get_next_device(struct 
omap_dss_device *from)
 
int match(struct device *dev, void *data)
{
-   /* skip panels connected to controllers */
-   if (to_dss_device(dev)-panel.ctrl)
-   return 0;
-
return 1;
}
 
@@ -626,45 +622,21 @@ EXPORT_SYMBOL(omap_dss_find_device);
 
 int omap_dss_start_device(struct omap_dss_device *dssdev)
 {
-   int r;
-
if (!dssdev-driver) {
DSSDBG(no driver\n);
-   r = -ENODEV;
-   goto err0;
-   }
-
-   if (dssdev-ctrl.panel  !dssdev-ctrl.panel-driver) {
-   DSSDBG(no panel driver\n);
-   r = -ENODEV;
-   goto err0;
+   return -ENODEV;
}
 
if (!try_module_get(dssdev-dev.driver-owner)) {
-   r = -ENODEV;
-   goto err0;
-   }
-
-   if (dssdev-ctrl.panel) {
-   if (!try_module_get(dssdev-ctrl.panel-dev.driver-owner)) {
-   r = -ENODEV;
-   goto err1;
-   }
+   return -ENODEV;
}
 
return 0;
-err1:
-   module_put(dssdev-dev.driver-owner);
-err0:
-   return r;
 }
 EXPORT_SYMBOL(omap_dss_start_device);
 
 void omap_dss_stop_device(struct omap_dss_device *dssdev)
 {
-   if (dssdev-ctrl.panel)
-   

[PATCH 4/4] OMAP: DSS2: OMAPFB: fix cleanup on dssdev enable error

[Tomi Valkeinen]

If enabling a dss device failed, omapfb didn't exit, leading to crash.

Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
---
 drivers/video/omap2/omapfb/omapfb-main.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
b/drivers/video/omap2/omapfb/omapfb-main.c
index 973bf79..6a383ab 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2176,9 +2176,11 @@ static int omapfb_probe(struct platform_device *pdev)
u16 w, h;
 #endif
r = def_display-enable(def_display);
-   if (r)
+   if (r) {
dev_warn(fbdev-dev, Failed to enable display '%s'\n,
def_display-name);
+   goto cleanup;
+   }
 
/* set the update mode */
if (def_display-caps  OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
-- 
1.6.5

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

Re: OMAP Audio

[Gary Thomas]

On 02/17/2010 04:17 AM, Peter Ujfalusi wrote:

On Wednesday 17 February 2010 12:43:56 ext Gary Thomas wrote:

On 02/17/2010 03:26 AM, Peter Ujfalusi wrote:

On Wednesday 17 February 2010 09:03:39 ext Jarkko Nikula wrote:

On Tue, 16 Feb 2010 11:19:25 -0700

Gary Thomasg...@mlbassoc.com   wrote:

I need to connect the OMAP (3530) to a 24bit CODEC.  So far
my attempts at getting this to go have not gone well.  Then

I ran across this comment in sound/soc/omap/omap-pcm.c:
/*

 * Note: Regardless of interface data formats supported by OMAP McBSP
 * or EAC blocks, internal representation is always fixed
 16-bit/sample */

Does this mean that this setup is just not supported?  even though
the hardware can handle it?


Yep, comment is bit misleading but true until some patch will remove
it. IRCC, the EAC was limited to 16-bit and also there wasn't need and
HW to test other formats than S16_LE in McBSP DAI.


Thanks for any pointers or ideas on how to get this going.


I would first start adding support for the S32_LE into omap-pcm.c (DMA
part). Worth to look this thread:

http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024704
.ht ml

Then add support for this format to the omap-mcbsp.c (link
configuration part).

Next step would be to add support for the S24_LE on 4-byte boundaries.
I.e. the DMA is moving 32-bit samples between the memory and McBSP but
only 24-bits are transferred over the McBSP and codec.


Hmmm, I think this is a bit more complicated than that at least on OMAP3.
I think the DMA engine should also move 24 bit words.
This is dictated by the McBSP FIFO: it has a notion of word size, and it
is expecting that the DMA engine will move THRESHOLD number of words. So
if the McBSP is configured for 24 bit words, than the DMA word size has
to match that.

Apart from this, the constraint set for the period bytes need to be
changed since as you change the word size in McBSP you will have
different amount of actual bytes for the FIFO (the FIFO size is in
words, and the maximum word size is 32 bit).


Thanks for the help.  I'm pretty sure I understand how to change
the McBSP code (omap-mcbsp.c) to handle the various formats, but
I'm a bit lost in the DMA setup (omap-pcm.c).  How do I identify
the code/width in omap_pcm_prepare()?


After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data
types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit
packed format.
I would go with a trial and error method and find it out how it is working...


Has no one ever used the OMAP/McBSP with data sizes other than 16 bits??


At least I can not recall. I have had a plan to add support for these, but it
got delayed and delayed ;)



How about sending padded data (24 bits in 32) which is what my
CODEC wants anyway?  Would this be easier to set up?  How?

(Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I
need to be moving 24 or 32 bit chunks)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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] dspbridge: proc: fix a double-free on 2 error paths

[Phil Carmody]

On 17/02/10 01:24 +0100, ext Omar Ramirez Luna wrote:
 On 2/12/2010 10:26 AM, Phil Carmody wrote:
  From: Phil Carmodyext-phil.2.carm...@nokia.com
 
  We free in the tail cleanup, so don't free before jumping there.
 
  Signed-off-by: Phil Carmodyext-phil.2.carm...@nokia.com
  ---
 
 [...]
  }
  +
  +   /* paranoid - must be able to kfree this on remaining error paths */
  +   pProcObject-g_pszLastCoff = NULL;
  +
 
 do we need this? afaik it should be NULL at this point, because of 
 kmalloc + memset (which btw should be replaced by kzalloc).

I suspected it wasn't. I confess I was a little bit rushed when
looking at that.

 i.e:
 MEM_AllocObject(pProcObject, struct PROC_OBJECT, PROC_SIGNATURE);
 - MEM_Calloc(sizeof(Obj), MEM_NONPAGED);
 -pMem = kmalloc(...)
   if (pMem)
   memset(pMem, 0, cBytes);

i.e. kzalloc().

  /* Get the default executable for this board... */
  DEV_GetDevType(hDevObject, (u32 *)devType);
  pProcObject-uProcessor = devType;
 [...]
 
 Regards,

I can resend without, if you like, whatever's simplest for you.

Phil
--
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] OMAP3EVM: PM: Update defconfig

[Sanjeev Premi]

This patch updates the omap3_evm_defconfig to
select CONFIG_PM_DEBUG and CONFIG_DEBUG_FS.

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 arch/arm/configs/omap3_evm_defconfig |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap3_evm_defconfig 
b/arch/arm/configs/omap3_evm_defconfig
index 86cc4be..b938507 100644
--- a/arch/arm/configs/omap3_evm_defconfig
+++ b/arch/arm/configs/omap3_evm_defconfig
@@ -333,7 +333,7 @@ CONFIG_BINFMT_MISC=y
 # Power management options
 #
 CONFIG_PM=y
-# CONFIG_PM_DEBUG is not set
+CONFIG_PM_DEBUG=y
 CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
@@ -1339,7 +1339,7 @@ CONFIG_ENABLE_MUST_CHECK=y
 CONFIG_FRAME_WARN=1024
 CONFIG_MAGIC_SYSRQ=y
 # CONFIG_UNUSED_SYMBOLS is not set
-# CONFIG_DEBUG_FS is not set
+CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
 # CONFIG_DEBUG_SHIRQ is not set
-- 
1.6.6.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

[PATCHv2] OMAP3EVM: PM: Update defconfig

[Sanjeev Premi]

This patch updates the omap3_evm_defconfig to
select these options:
  * CONFIG_PM_DEBUG
  * CONFIG_DEBUG_FS
  * CONFIG_OMAP_SMARTREFLEX

Signed-off-by: Sanjeev Premi pr...@ti.com
---

 Found that SmartReflex was disabled as well. Didn't
 feel need for a different patch for same.


 arch/arm/configs/omap3_evm_defconfig |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap3_evm_defconfig 
b/arch/arm/configs/omap3_evm_defconfig
index 86cc4be..e2ad859 100644
--- a/arch/arm/configs/omap3_evm_defconfig
+++ b/arch/arm/configs/omap3_evm_defconfig
@@ -187,6 +187,8 @@ CONFIG_ARCH_OMAP3=y
 #
 # OMAP Feature Selections
 #
+CONFIG_OMAP_SMARTREFLEX=y
+# CONFIG_OMAP_SMARTREFLEX_TESTING is not set
 # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set
 # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set
 CONFIG_OMAP_RESET_CLOCKS=y
@@ -333,7 +335,7 @@ CONFIG_BINFMT_MISC=y
 # Power management options
 #
 CONFIG_PM=y
-# CONFIG_PM_DEBUG is not set
+CONFIG_PM_DEBUG=y
 CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
@@ -1339,7 +1341,7 @@ CONFIG_ENABLE_MUST_CHECK=y
 CONFIG_FRAME_WARN=1024
 CONFIG_MAGIC_SYSRQ=y
 # CONFIG_UNUSED_SYMBOLS is not set
-# CONFIG_DEBUG_FS is not set
+CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
 # CONFIG_DEBUG_SHIRQ is not set
-- 
1.6.6.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: [PATCHv4] OMAP3: Serial: Improved sleep logic

[Tero.Kristo]

Grr, ktime_get() is not accessible during suspend, and thus this patch causes a 
WARN during wakeup from suspend. I'll convert the patch to use 
getrawmonotonic() instead, sending out a refreshed one soon.

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo 
Tero (Nokia-D/Tampere)
Sent: 12 February, 2010 20:23
To: linux-omap@vger.kernel.org
Subject: [PATCHv4] OMAP3: Serial: Improved sleep logic

From: Tero Kristo tero.kri...@nokia.com

This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this will prevent
  on-going transmission to be cut
- Smartidle is now enabled/disabled only while switching 
clocks, as having
  smartidle enabled while RX/TX prevents any wakeups from being
  received from UART module
- Sleep prevent timer is changed to use ktime_get() instead of 
a jiffy timer
  as jiffy timers are not valid within idle loop (tick 
scheduler is stopped)
- Added RX ignore timer for ignoring the first character 
received during
  first millisecond of wakeup, this prevents garbage character 
to be receive
  in low sleep states

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/serial.c |   79 
+++--
 1 files changed, 52 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c 
b/arch/arm/mach-omap2/serial.c
index 5f3035e..4be9ace 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -29,6 +29,8 @@
 #include plat/clock.h
 #include plat/control.h
 
+#include asm/div64.h
+
 #include prm.h
 #include pm.h
 #include prm-regbits-34xx.h
@@ -42,13 +44,14 @@
  * disabled via sysfs. This also causes that any deeper omap 
sleep states are
  * blocked. 
  */
-#define DEFAULT_TIMEOUT 0
+#define DEFAULT_TIMEOUT (0LL * NSEC_PER_SEC)
 
 struct omap_uart_state {
   int num;
   int can_sleep;
-  struct timer_list timer;
-  u32 timeout;
+  ktime_t expire_time;
+  ktime_t garbage_time;
+  u64 timeout;
 
   void __iomem *wk_st;
   void __iomem *wk_en;
@@ -243,6 +246,9 @@ static inline void 
omap_uart_save_context(struct omap_uart_state *uart) {}
 static inline void omap_uart_restore_context(struct 
omap_uart_state *uart) {}
 #endif /* CONFIG_PM  CONFIG_ARCH_OMAP3 */
 
+static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
+  int enable);
+
 static inline void omap_uart_enable_clocks(struct 
omap_uart_state *uart)
 {
   if (uart-clocked)
@@ -250,8 +256,12 @@ static inline void 
omap_uart_enable_clocks(struct omap_uart_state *uart)
 
   clk_enable(uart-ick);
   clk_enable(uart-fck);
+  omap_uart_smart_idle_enable(uart, 0);
   uart-clocked = 1;
   omap_uart_restore_context(uart);
+
+  /* Set up garbage timer to ignore RX during first 1ms */
+  uart-garbage_time = ktime_add_ns(ktime_get(), NSEC_PER_MSEC);
 }
 
 #ifdef CONFIG_PM
@@ -263,6 +273,7 @@ static inline void 
omap_uart_disable_clocks(struct omap_uart_state *uart)
 
   omap_uart_save_context(uart);
   uart-clocked = 0;
+  omap_uart_smart_idle_enable(uart, 1);
   clk_disable(uart-ick);
   clk_disable(uart-fck);
 }
@@ -320,12 +331,9 @@ static void omap_uart_block_sleep(struct 
omap_uart_state *uart)
 {
   omap_uart_enable_clocks(uart);
 
-  omap_uart_smart_idle_enable(uart, 0);
   uart-can_sleep = 0;
   if (uart-timeout)
-  mod_timer(uart-timer, jiffies + uart-timeout);
-  else
-  del_timer(uart-timer);
+  uart-expire_time = ktime_add_ns(ktime_get(), 
uart-timeout);
 }
 
 static void omap_uart_allow_sleep(struct omap_uart_state *uart)
@@ -338,16 +346,7 @@ static void omap_uart_allow_sleep(struct 
omap_uart_state *uart)
   if (!uart-clocked)
   return;
 
-  omap_uart_smart_idle_enable(uart, 1);
   uart-can_sleep = 1;
-  del_timer(uart-timer);
-}
-
-static void omap_uart_idle_timer(unsigned long data)
-{
-  struct omap_uart_state *uart = (struct omap_uart_state *)data;
-
-  omap_uart_allow_sleep(uart);
 }
 
 void omap_uart_prepare_idle(int num)
@@ -355,8 +354,14 @@ void omap_uart_prepare_idle(int num)
   struct omap_uart_state *uart;
 
   list_for_each_entry(uart, uart_list, node) {
+  if (num == uart-num  !uart-can_sleep  
uart-timeout)
+  if (ktime_get().tv64  uart-expire_time.tv64)
+  uart-can_sleep = 1;
+
   if (num == uart-num  uart-can_sleep) {
-  omap_uart_disable_clocks(uart);
+  if (serial_read_reg(uart-p, UART_LSR) 
+  UART_LSR_TEMT)
+  omap_uart_disable_clocks(uart);
   return;
   }
   }
@@ -404,6 +409,10 @@ int omap_uart_can_sleep(void)
   if 

[PATCHv5] OMAP3: Serial: Improved sleep logic

[Tero Kristo]

From: Tero Kristo tero.kri...@nokia.com

This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this will prevent
  on-going transmission to be cut
- Smartidle is now enabled/disabled only while switching clocks, as having
  smartidle enabled while RX/TX prevents any interrupts from being
  received from UART module
- Sleep prevent timer is changed to use timespec instead of a jiffy timer
  as jiffy timers are not valid within idle loop (tick scheduler is stopped)
- Added RX ignore timer for ignoring the first character received during
  first millisecond of wakeup, this prevents garbage character to be receive
  in low sleep states

Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
 arch/arm/mach-omap2/serial.c |   98 +
 1 files changed, 69 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5f3035e..f49c465 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -29,6 +29,8 @@
 #include plat/clock.h
 #include plat/control.h
 
+#include asm/div64.h
+
 #include prm.h
 #include pm.h
 #include prm-regbits-34xx.h
@@ -42,13 +44,14 @@
  * disabled via sysfs. This also causes that any deeper omap sleep states are
  * blocked. 
  */
-#define DEFAULT_TIMEOUT 0
+#define DEFAULT_TIMEOUT (0LL * NSEC_PER_SEC)
 
 struct omap_uart_state {
int num;
int can_sleep;
-   struct timer_list timer;
-   u32 timeout;
+   struct timespec expire_time;
+   struct timespec garbage_time;
+   u64 timeout;
 
void __iomem *wk_st;
void __iomem *wk_en;
@@ -243,6 +246,9 @@ static inline void omap_uart_save_context(struct 
omap_uart_state *uart) {}
 static inline void omap_uart_restore_context(struct omap_uart_state *uart) {}
 #endif /* CONFIG_PM  CONFIG_ARCH_OMAP3 */
 
+static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
+   int enable);
+
 static inline void omap_uart_enable_clocks(struct omap_uart_state *uart)
 {
if (uart-clocked)
@@ -250,8 +256,13 @@ static inline void omap_uart_enable_clocks(struct 
omap_uart_state *uart)
 
clk_enable(uart-ick);
clk_enable(uart-fck);
+   omap_uart_smart_idle_enable(uart, 0);
uart-clocked = 1;
omap_uart_restore_context(uart);
+
+   /* Set up garbage timer to ignore RX during first 1ms */
+   getrawmonotonic(uart-garbage_time);
+   timespec_add_ns(uart-garbage_time, NSEC_PER_MSEC);
 }
 
 #ifdef CONFIG_PM
@@ -263,6 +274,7 @@ static inline void omap_uart_disable_clocks(struct 
omap_uart_state *uart)
 
omap_uart_save_context(uart);
uart-clocked = 0;
+   omap_uart_smart_idle_enable(uart, 1);
clk_disable(uart-ick);
clk_disable(uart-fck);
 }
@@ -320,12 +332,11 @@ static void omap_uart_block_sleep(struct omap_uart_state 
*uart)
 {
omap_uart_enable_clocks(uart);
 
-   omap_uart_smart_idle_enable(uart, 0);
uart-can_sleep = 0;
-   if (uart-timeout)
-   mod_timer(uart-timer, jiffies + uart-timeout);
-   else
-   del_timer(uart-timer);
+   if (uart-timeout) {
+   getrawmonotonic(uart-expire_time);
+   timespec_add_ns(uart-expire_time, uart-timeout);
+   }
 }
 
 static void omap_uart_allow_sleep(struct omap_uart_state *uart)
@@ -338,25 +349,24 @@ static void omap_uart_allow_sleep(struct omap_uart_state 
*uart)
if (!uart-clocked)
return;
 
-   omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
-   del_timer(uart-timer);
-}
-
-static void omap_uart_idle_timer(unsigned long data)
-{
-   struct omap_uart_state *uart = (struct omap_uart_state *)data;
-
-   omap_uart_allow_sleep(uart);
 }
 
 void omap_uart_prepare_idle(int num)
 {
struct omap_uart_state *uart;
+   struct timespec t;
 
list_for_each_entry(uart, uart_list, node) {
+   if (num == uart-num  !uart-can_sleep  uart-timeout) {
+   getrawmonotonic(t);
+   if (timespec_compare(t, uart-expire_time)  0)
+   uart-can_sleep = 1;
+   }
if (num == uart-num  uart-can_sleep) {
-   omap_uart_disable_clocks(uart);
+   if (serial_read_reg(uart-p, UART_LSR) 
+   UART_LSR_TEMT)
+   omap_uart_disable_clocks(uart);
return;
}
}
@@ -381,6 +391,7 @@ void omap_uart_resume_idle(int num)
/* Check for normal UART wakeup */
if (__raw_readl(uart-wk_st)  uart-wk_mask)
omap_uart_block_sleep(uart);
+
return;
}
}
@@ -399,11 +410,18 @@ int omap_uart_can_sleep(void)
 

[PATCHv3 1/2] DSPBRIDGE: Rename DMM_RES_OBJECT to DMM_MAP_OBJECT

[Ameya Palande]

In its current state DMM_RES_OBJECT is not correctly tracking reserve and
unreserve but only map and unmap. So lets rename it to DMM_MAP_OBJECT to
clarify what it is really doing!

In addition to this, this patch also does some trivial code cleanup.

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Reviewed-by: Felipe Contreras felipe.contre...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/drv.h |   14 +++---
 drivers/dsp/bridge/rmgr/drv.c  |   69 ++--
 drivers/dsp/bridge/rmgr/drv_interface.c|2 +-
 3 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h 
b/arch/arm/plat-omap/include/dspbridge/drv.h
index b044291..d5f5277 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -90,15 +90,15 @@ struct NODE_RES_OBJECT {
struct NODE_RES_OBJECT *next;
 } ;
 
-/* New structure (member of process context) abstracts DMM resource info */
-struct DMM_RES_OBJECT {
+/* Abstracts DMM resource info */
+struct DMM_MAP_OBJECT {
s32dmmAllocated; /* DMM status */
u32   ulMpuAddr;
u32   ulDSPAddr;
u32   ulDSPResAddr;
-   u32   dmmSize;
+   u32   size;
HANDLE  hProcessor;
-   struct DMM_RES_OBJECT  *next;
+   struct DMM_MAP_OBJECT  *next;
 } ;
 
 /* New structure (member of process context) abstracts DMM resource info */
@@ -139,9 +139,9 @@ struct PROCESS_CONTEXT{
struct NODE_RES_OBJECT *pNodeList;
struct mutex node_mutex;
 
-   /* DMM resources */
-   struct DMM_RES_OBJECT *pDMMList;
-   struct mutex dmm_mutex;
+   /* DMM mapped memory resources */
+   struct DMM_MAP_OBJECT *dmm_map_list;
+   struct mutex dmm_map_mutex;
 
/* DSP Heap resources */
struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index e8b2c58..9b513e2 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -198,37 +198,37 @@ static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt)
 DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE hPCtxt)
 {
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
-   struct DMM_RES_OBJECT **pDMMRes = (struct DMM_RES_OBJECT **)hDMMRes;
+   struct DMM_MAP_OBJECT **pDMMRes = (struct DMM_MAP_OBJECT **)hDMMRes;
DSP_STATUS  status = DSP_SOK;
-   struct DMM_RES_OBJECT *pTempDMMRes = NULL;
+   struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
 
-   *pDMMRes = (struct DMM_RES_OBJECT *)
-   MEM_Calloc(1 * sizeof(struct DMM_RES_OBJECT), MEM_PAGED);
+   *pDMMRes = (struct DMM_MAP_OBJECT *)
+   MEM_Calloc(1 * sizeof(struct DMM_MAP_OBJECT), MEM_PAGED);
GT_0trace(curTrace, GT_ENTER, DRV_InsertDMMResElement: 1);
if (*pDMMRes == NULL) {
GT_0trace(curTrace, GT_5CLASS, DRV_InsertDMMResElement: 2);
status = DSP_EHANDLE;
}
if (DSP_SUCCEEDED(status)) {
-   if (mutex_lock_interruptible(pCtxt-dmm_mutex)) {
+   if (mutex_lock_interruptible(pCtxt-dmm_map_mutex)) {
kfree(*pDMMRes);
return DSP_EFAIL;
}
 
-   if (pCtxt-pDMMList != NULL) {
+   if (pCtxt-dmm_map_list) {
GT_0trace(curTrace, GT_5CLASS,
 DRV_InsertDMMResElement: 3);
-   pTempDMMRes = pCtxt-pDMMList;
-   while (pTempDMMRes-next != NULL)
+   pTempDMMRes = pCtxt-dmm_map_list;
+   while (pTempDMMRes-next)
pTempDMMRes = pTempDMMRes-next;
 
pTempDMMRes-next = *pDMMRes;
} else {
-   pCtxt-pDMMList = *pDMMRes;
+   pCtxt-dmm_map_list = *pDMMRes;
GT_0trace(curTrace, GT_5CLASS,
 DRV_InsertDMMResElement: 4);
}
-   mutex_unlock(pCtxt-dmm_mutex);
+   mutex_unlock(pCtxt-dmm_map_mutex);
}
GT_0trace(curTrace, GT_ENTER, DRV_InsertDMMResElement: 5);
return status;
@@ -239,15 +239,15 @@ DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE 
hPCtxt)
 DSP_STATUS DRV_RemoveDMMResElement(HANDLE hDMMRes, HANDLE hPCtxt)
 {
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
-   struct DMM_RES_OBJECT *pDMMRes = (struct DMM_RES_OBJECT *)hDMMRes;
-   struct DMM_RES_OBJECT *pTempDMMRes = NULL;
+   struct DMM_MAP_OBJECT *pDMMRes = (struct DMM_MAP_OBJECT *)hDMMRes;
+   struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
DSP_STATUS status = DSP_SOK;
 
-   if (mutex_lock_interruptible(pCtxt-dmm_mutex))
+   if 

[PATCHv3 0/2] DSPBRIDGE: Improved reserved memory cleanup

[Ameya Palande]

This patch series splits DMM_RES_OBJECT into DMM_MAP_OBJECT and DMM_RSV_OBJECT
which are used independently for mapped and reserved memory resources
accounting. This will help in cleanup of reserved memory resources which was
not handled properly before. With these patches resource cleanup mechanism
will work perfectly in a use case where a big chunk of memory is reserved and
then lot of mappings are created inside it.

Changes since v2:
1. Removed locking from DRV_RemoveAllDMMResElements()
2. Removed cleanup variable from PROC_UnReserveMemory()
   http://marc.info/?l=linux-omapm=126637211831587w=2
3. Rebased patchset on top of following commit:
   DSPBRIDGE: Remove conditional check from the InputMsg function

Changed since v1:
1. Reduced indentation
   http://marc.info/?l=linux-omapm=126624982331523w=2

Ameya Palande (2):
  DSPBRIDGE: Rename DMM_RES_OBJECT to DMM_MAP_OBJECT
  DSPBRIDGE: New reserved memory accounting framework

 arch/arm/plat-omap/include/dspbridge/drv.h  |   24 +--
 arch/arm/plat-omap/include/dspbridge/proc.h |4 +-
 drivers/dsp/bridge/pmgr/wcd.c   |7 +-
 drivers/dsp/bridge/rmgr/drv.c   |   87 ++-
 drivers/dsp/bridge/rmgr/drv_interface.c |4 +-
 drivers/dsp/bridge/rmgr/node.c  |5 +-
 drivers/dsp/bridge/rmgr/proc.c  |   52 +
 7 files changed, 116 insertions(+), 67 deletions(-)

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

[PATCHv3 2/2] DSPBRIDGE: New reserved memory accounting framework

[Ameya Palande]

DSP_RSV_OBJECT is introduced to track reserved memory accounting information.
This will allow us to do proper cleanup for memory reserved using
PROC_ReserveMemory().

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/drv.h  |   10 +
 arch/arm/plat-omap/include/dspbridge/proc.h |4 +-
 drivers/dsp/bridge/pmgr/wcd.c   |7 ++--
 drivers/dsp/bridge/rmgr/drv.c   |   18 ++
 drivers/dsp/bridge/rmgr/drv_interface.c |2 +
 drivers/dsp/bridge/rmgr/node.c  |5 ++-
 drivers/dsp/bridge/rmgr/proc.c  |   52 +--
 7 files changed, 73 insertions(+), 25 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h 
b/arch/arm/plat-omap/include/dspbridge/drv.h
index d5f5277..f7d0e3e 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -101,6 +101,12 @@ struct DMM_MAP_OBJECT {
struct DMM_MAP_OBJECT  *next;
 } ;
 
+/* Used for DMM reserved memory accounting */
+struct DMM_RSV_OBJECT {
+   struct  list_head   link;
+   u32 dsp_reserved_addr;
+};
+
 /* New structure (member of process context) abstracts DMM resource info */
 struct DSPHEAP_RES_OBJECT {
s32heapAllocated; /* DMM status */
@@ -143,6 +149,10 @@ struct PROCESS_CONTEXT{
struct DMM_MAP_OBJECT *dmm_map_list;
struct mutex dmm_map_mutex;
 
+   /* DMM reserved memory resources */
+   struct list_head dmm_rsv_list;
+   spinlock_t dmm_rsv_lock;
+
/* DSP Heap resources */
struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
 
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h 
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 8dbdaac..1ffe763 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -560,7 +560,7 @@
  *  Details:
  */
extern DSP_STATUS PROC_ReserveMemory(DSP_HPROCESSOR hProcessor,
-u32 ulSize, void **ppRsvAddr);
+   u32 ulSize, void **ppRsvAddr, struct PROCESS_CONTEXT *pr_ctxt);
 
 /*
  *   PROC_UnMap 
@@ -604,6 +604,6 @@
  *  Details:
  */
extern DSP_STATUS PROC_UnReserveMemory(DSP_HPROCESSOR hProcessor,
-  void *pRsvAddr);
+   void *pRsvAddr, struct PROCESS_CONTEXT *pr_ctxt);
 
 #endif /* PROC_ */
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index beea23b..1ef606e 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1054,12 +1054,13 @@ u32 PROCWRAP_ReserveMemory(union Trapped_Args *args, 
void *pr_ctxt)
 
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_ReserveMemory: entered\n);
status = PROC_ReserveMemory(args-ARGS_PROC_RSVMEM.hProcessor,
-  args-ARGS_PROC_RSVMEM.ulSize, pRsvAddr);
+  args-ARGS_PROC_RSVMEM.ulSize, pRsvAddr,
+  pr_ctxt);
if (DSP_SUCCEEDED(status)) {
if (put_user(pRsvAddr, args-ARGS_PROC_RSVMEM.ppRsvAddr)) {
status = DSP_EINVALIDARG;
PROC_UnReserveMemory(args-ARGS_PROC_RSVMEM.hProcessor,
-   pRsvAddr);
+   pRsvAddr, pr_ctxt);
}
}
return status;
@@ -1100,7 +1101,7 @@ u32 PROCWRAP_UnReserveMemory(union Trapped_Args *args, 
void *pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER,
 PROCWRAP_UnReserveMemory: entered\n);
status = PROC_UnReserveMemory(args-ARGS_PROC_UNRSVMEM.hProcessor,
-args-ARGS_PROC_UNRSVMEM.pRsvAddr);
+args-ARGS_PROC_UNRSVMEM.pRsvAddr, pr_ctxt);
return status;
 }
 
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 9b513e2..12ba7e0 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -298,25 +298,20 @@ DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt)
if (DSP_FAILED(status))
pr_debug(%s: PROC_UnMap failed! status =
 0x%xn, __func__, status);
-   status = PROC_UnReserveMemory(pDMMRes-hProcessor,
-(void *)pDMMRes-ulDSPResAddr);
-   if (DSP_FAILED(status))
-   pr_debug(%s: PROC_UnReserveMemory failed!
-status = 0x%xn, __func__, status);
pDMMRes-dmmAllocated = 0;
}
}
return status;
 }
 
-/* Release all DMM resources and its context
-* This is called from .bridge_release. */
+/* Release all Mapped and Reserved DMM resources */
 DSP_STATUS 

[PATCHv2] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes

[Ameya Palande]

This patch fixes following issues:
1. pDMMRes was dereferenced and modified when it was already freed by
   PROC_Ummap(). This results in memory corruption.
2. Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMap()
   which will not retrieve correct DMMRes element.

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
Changes since V1:
1. Rebased on top of:
   [PATCHv3 0/2] DSPBRIDGE: Improved reserved memory cleanup

 drivers/dsp/bridge/rmgr/drv.c |   12 ++--
 1 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 12ba7e0..b88b5a3 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -293,12 +293,12 @@ DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt)
pDMMRes = pDMMList;
pDMMList = pDMMList-next;
if (pDMMRes-dmmAllocated) {
+   /* PROC_UnMap will free pDMMRes pointer */
status = PROC_UnMap(pDMMRes-hProcessor,
-(void *)pDMMRes-ulDSPResAddr, pCtxt);
+(void *)pDMMRes-ulDSPAddr, pCtxt);
if (DSP_FAILED(status))
pr_debug(%s: PROC_UnMap failed! status =
 0x%xn, __func__, status);
-   pDMMRes-dmmAllocated = 0;
}
}
return status;
@@ -309,17 +309,9 @@ DSP_STATUS DRV_RemoveAllDMMResElements(HANDLE hPCtxt)
 {
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
DSP_STATUS status = DSP_SOK;
-   struct DMM_MAP_OBJECT *pTempDMMRes2 = NULL;
-   struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
struct DMM_RSV_OBJECT *temp, *rsv_obj;
 
DRV_ProcFreeDMMRes(pCtxt);
-   pTempDMMRes = pCtxt-dmm_map_list;
-   while (pTempDMMRes != NULL) {
-   pTempDMMRes2 = pTempDMMRes;
-   pTempDMMRes = pTempDMMRes-next;
-   kfree(pTempDMMRes2);
-   }
pCtxt-dmm_map_list = NULL;
 
/* Free DMM reserved memory resources */
-- 
1.6.3.3

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

[PATCHv2 1/2] McBSP: OMAP3: Add sidetone feature

[Ilkka Koskinen]

From: Eero Nurkkala ext-eero.nurkk...@nokia.com

Add sidetone feature to McBSP instances 2 and 3 on OMAP3 based devices.

Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
 arch/arm/mach-omap2/mcbsp.c |2 +
 arch/arm/plat-omap/include/plat/mcbsp.h |   63 +
 arch/arm/plat-omap/mcbsp.c  |  396 ++-
 3 files changed, 460 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index d601f94..be8fce3 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -136,6 +136,7 @@ static struct omap_mcbsp_platform_data 
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base  = OMAP34XX_MCBSP2_BASE,
+   .phys_base_st   = OMAP34XX_MCBSP2_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
@@ -145,6 +146,7 @@ static struct omap_mcbsp_platform_data 
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base  = OMAP34XX_MCBSP3_BASE,
+   .phys_base_st   = OMAP34XX_MCBSP3_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h 
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 4df957b..5db1653 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -49,6 +49,9 @@
 
 #define OMAP34XX_MCBSP1_BASE   0x48074000
 #define OMAP34XX_MCBSP2_BASE   0x49022000
+#define OMAP34XX_MCBSP2_ST_BASE0x49028000
+#define OMAP34XX_MCBSP3_BASE   0x49024000
+#define OMAP34XX_MCBSP3_ST_BASE0x4902A000
 #define OMAP34XX_MCBSP3_BASE   0x49024000
 #define OMAP34XX_MCBSP4_BASE   0x49026000
 #define OMAP34XX_MCBSP5_BASE   0x48096000
@@ -146,6 +149,15 @@
 #define OMAP_MCBSP_REG_WAKEUPEN0xA8
 #define OMAP_MCBSP_REG_XCCR0xAC
 #define OMAP_MCBSP_REG_RCCR0xB0
+#define OMAP_MCBSP_REG_SSELCR  0xBC
+
+#define OMAP_ST_REG_REV0x00
+#define OMAP_ST_REG_SYSCONFIG  0x10
+#define OMAP_ST_REG_IRQSTATUS  0x18
+#define OMAP_ST_REG_IRQENABLE  0x1C
+#define OMAP_ST_REG_SGAINCR0x24
+#define OMAP_ST_REG_SFIRCR 0x28
+#define OMAP_ST_REG_SSELCR 0x2C
 
 #define AUDIO_MCBSP_DATAWRITE  (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1)
 #define AUDIO_MCBSP_DATAREAD   (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1)
@@ -264,6 +276,24 @@
 #define ENAWAKEUP  0x0004
 #define SOFTRST0x0002
 
+/** McBSP SSELCR bit definitions ***/
+#define SIDETONEEN 0x0400
+
+/** McBSP Sidetone SYSCONFIG bit definitions ***/
+#define ST_AUTOIDLE0x0001
+
+/** McBSP Sidetone SGAINCR bit definitions */
+#define ST_CH1GAIN(value)  ((value16))   /* Bits 16:31 */
+#define ST_CH0GAIN(value)  (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SFIRCR bit definitions **/
+#define ST_FIRCOEFF(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SSELCR bit definitions **/
+#define ST_COEFFWRDONE 0x0004
+#define ST_COEFFWREN   0x0002
+#define ST_SIDETONEEN  0x0001
+
 /** McBSP DMA operating modes **/
 #define MCBSP_DMA_MODE_ELEMENT 0
 #define MCBSP_DMA_MODE_THRESHOLD   1
@@ -374,10 +404,25 @@ struct omap_mcbsp_platform_data {
u16 rx_irq, tx_irq;
struct omap_mcbsp_ops *ops;
 #ifdef CONFIG_ARCH_OMAP3
+   /* Sidetone block for McBSP 2 and 3 */
+   unsigned long phys_base_st;
u16 buffer_size;
 #endif
 };
 
+#define OMAP_MCBSP_ST_CHANNEL_0 (1  0)
+#define OMAP_MCBSP_ST_CHANNEL_1 (1  1)
+
+struct omap_mcbsp_st_data {
+   void __iomem *io_base_st;
+   bool running;
+   bool enabled;
+   s16 taps[128];  /* Sidetone filter coefficients */
+   int nr_taps;/* Number of filter coefficients in use */
+   s16 ch0gain;
+   s16 ch1gain;
+};
+
 struct omap_mcbsp {
struct device *dev;
unsigned long phys_base;
@@ -410,6 +455,7 @@ struct omap_mcbsp {
struct clk *iclk;
struct clk *fclk;
 #ifdef CONFIG_ARCH_OMAP3
+   struct omap_mcbsp_st_data *st_data;
int dma_op_mode;
u16 max_tx_thres;
u16 max_rx_thres;
@@ -459,4 +505,21 @@ int omap_mcbsp_pollread(unsigned int id, u16 * buf);
 int omap_mcbsp_pollwrite(unsigned int id, u16 buf);
 int omap_mcbsp_set_io_type(unsigned int id, omap_mcbsp_io_type_t io_type);
 
+#ifdef CONFIG_ARCH_OMAP3
+/* Sidetone specific API */
+int omap_st_set_chgain(unsigned int id, s16 ch0gain, s16 ch1gain, int 
channels);
+int omap_st_get_chgain(unsigned int id, s16 *ch0gain, s16 

Re: [PATCH 3/6] Mailbox: change mailbox version print to pr_debug

[Hiroshi DOYU]

Hi Fernand,

From: ext Guzman Lugo, Fernando x0095...@ti.com
Subject: [PATCH 3/6] Mailbox: change mailbox version print to pr_debug
Date: Sat, 13 Feb 2010 02:40:41 +0100

 From 60e21e76773de379deb41ff166f9679b7078276f Mon Sep 17 00:00:00 2001
 From: Fernando Guzman Lugo x0095...@ti.com
 Date: Wed, 10 Feb 2010 17:08:20 -0600
 Subject: [PATCH] Mailbox: change mailbox version print to pr_debug
 
 it is not useful printing the version every time mailbox is used
 instead change it to pr_debug in case someone needs to see the
 version can enable the print.

I just found that, if you put the line printing version into debug
mode, then mbox_read_reg(MAILBOX_REVISION) should be also done only
in debug mode. This value wouldn't be necessary if it didn't print.

Considering this printing again, this prints a message only when H/W
initialization is done correctly, most likely only *once* at
booting. This informs us of the result that a mailbox H/W itself is
set up and some mailbox related modules are loaded successfully. So
keeping this makes sense a little bit more rather than shutting this
completely silence.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] TWL6030 regulator fixes

[Nayak, Rajendra]

Hi,

This series contains fixes for the twl6030 regulator framework.
The series is generated against mainline kernel and the fixes
are validated on the OMAP4430sdp platform.

regards,
Rajendra

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

[PATCH 1/2] twl6030: regulator: Fix vsel calculations in set/get voltage apis

[Rajendra Nayak]

TWL6030 has a formula to be used to calculate the vsel values
to be programmed in the VREG_VOLTAGE registers.

Voltage(in mV) = 1000mv + 100mv * (vsel - 1)

Ex: if vsel = 0x9, mV = 1000 + 100 * (9 -1) = 1800mV.

Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
 drivers/regulator/twl-regulator.c |   23 +++
 1 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 7e67485..e7871d6 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -367,11 +367,17 @@ twlldo_set_voltage(struct regulator_dev *rdev, int 
min_uV, int max_uV)
/* REVISIT for VAUX2, first match may not be best/lowest */
 
/* use the first in-range value */
-   if (min_uV = uV  uV = max_uV)
+   if (min_uV = uV  uV = max_uV) {
+   if (twl_class_is_6030())
+   /*
+* Use the below formula to calculate vsel
+* mV = 1000mv + 100mv * (vsel - 1)
+*/
+   vsel = (LDO_MV(mV) - 1000)/100 + 1;
return twlreg_write(info, TWL_MODULE_PM_RECEIVER,
VREG_VOLTAGE, vsel);
+   }
}
-
return -EDOM;
 }
 
@@ -384,8 +390,17 @@ static int twlldo_get_voltage(struct regulator_dev *rdev)
if (vsel  0)
return vsel;
 
-   vsel = info-table_len - 1;
-   return LDO_MV(info-table[vsel]) * 1000;
+   if (twl_class_is_4030()) {
+   vsel = info-table_len - 1;
+   return LDO_MV(info-table[vsel]) * 1000;
+   } else if (twl_class_is_6030()) {
+   /*
+* Use the below formula to calculate vsel
+* mV = 1000mv + 100mv * (vsel - 1)
+*/
+   return (1000 + (100 * (vsel - 1))) * 1000;
+   }
+   return -EDOM;
 }
 
 static struct regulator_ops twlldo_ops = {
-- 
1.5.4.7

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

[PATCH 2/2] twl6030: regulator: Configure STATE register instead of REMAP

[Rajendra Nayak]

This is no REMAP register on twl6030, instead there is a STATE register
to drive a resource to a given state.
The state register can be used to specify what state the resource should
enter when its associated with a GRP.
Register Bit field description is as below. The patch programmes the
corresponding STATE registers for all LDO's to turn ON when assocaited
with GRP_P1.

STATE REG:
Bit7   |Bit6   |Bit5   |Bit4  |Bit3  |Bit2  |Bit1   |Bit0
P3_GRP |P2_GRP |P1_GRP |RES   |RES   |RES   |State1 |State0

State can be specified as below
00: OFF
01: ON
10: OFF
11: SLEEP

Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
 drivers/regulator/twl-regulator.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index e7871d6..f4c 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -534,16 +534,16 @@ static struct twlreg_info twl_regs[] = {
/* 6030 REG with base as PMC Slave Misc : 0x0030 */
/* Turnon-delay and remap configuration values for 6030 are not
   verified since the specification is not public */
-   TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1, 0, 0x08),
-   TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 2, 0, 0x08),
-   TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 3, 0, 0x08),
-   TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 4, 0, 0x08),
-   TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 5, 0, 0x08),
-   TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 7, 0, 0x08),
-   TWL6030_FIXED_LDO(VANA, 0x50, 2100, 15, 0, 0x08),
-   TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 16, 0, 0x08),
-   TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 17, 0, 0x08),
-   TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x08)
+   TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1, 0, 0x21),
+   TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 2, 0, 0x21),
+   TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 3, 0, 0x21),
+   TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 4, 0, 0x21),
+   TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 5, 0, 0x21),
+   TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 7, 0, 0x21),
+   TWL6030_FIXED_LDO(VANA, 0x50, 2100, 15, 0, 0x21),
+   TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 16, 0, 0x21),
+   TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 17, 0, 0x21),
+   TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21)
 };
 
 static int twlreg_probe(struct platform_device *pdev)
-- 
1.5.4.7

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

RE: [PATCH 0/2] TWL6030 regulator fixes

[Nayak, Rajendra]

Forgot to mention, I have stripped the patches from the series
here http://marc.info/?l=linux-omapm=126633460408606w=2 and
posted them seperately.

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nayak, Rajendra
 Sent: Wednesday, February 17, 2010 8:54 PM
 To: l...@slimlogic.co.uk; sa...@linux.intel.com; 
 broo...@opensource.wolfsonmicro.com
 Cc: linux-omap@vger.kernel.org
 Subject: [PATCH 0/2] TWL6030 regulator fixes
 
 Hi,
 
 This series contains fixes for the twl6030 regulator framework.
 The series is generated against mainline kernel and the fixes
 are validated on the OMAP4430sdp platform.
 
 regards,
 Rajendra
 
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths

[Omar Ramirez Luna]

On 2/17/2010 7:12 AM, Phil Carmody wrote:

On 17/02/10 01:24 +0100, ext Omar Ramirez Luna wrote:

On 2/12/2010 10:26 AM, Phil Carmody wrote:

From: Phil Carmodyext-phil.2.carm...@nokia.com

We free in the tail cleanup, so don't free before jumping there.

Signed-off-by: Phil Carmodyext-phil.2.carm...@nokia.com
---


[...]

}
+
+   /* paranoid - must be able to kfree this on remaining error paths */
+   pProcObject-g_pszLastCoff = NULL;
+


do we need this? afaik it should be NULL at this point, because of
kmalloc + memset (which btw should be replaced by kzalloc).


I suspected it wasn't. I confess I was a little bit rushed when
looking at that.


i.e:
MEM_AllocObject(pProcObject, struct PROC_OBJECT, PROC_SIGNATURE);
-  MEM_Calloc(sizeof(Obj), MEM_NONPAGED);
-   pMem = kmalloc(...)
if (pMem)
memset(pMem, 0, cBytes);


i.e. kzalloc().


/* Get the default executable for this board... */
DEV_GetDevType(hDevObject, (u32 *)devType);
pProcObject-uProcessor = devType;

[...]

Regards,


I can resend without, if you like, whatever's simplest for you.



No worries, I'll remove from original.

Regards,

Omar

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

RE: [PATCH v4] DSPBRIDGE: Fix to avoid possible recursive locking

[Menon, Nishanth]

Hi,

 From: Ameya Palande [mailto:ameya.pala...@nokia.com]
 Sent: Friday, February 12, 2010 12:21 AM
 To: Chitriki Rudramuni, Deepak
 Cc: linux-omap; Ramirez Luna, Omar; Menon, Nishanth
 Subject: Re: [PATCH v4] DSPBRIDGE: Fix to avoid possible recursive locking
 
 On Thu, 2010-02-11 at 22:54 +0100, ext Deepak Chitriki wrote:
  Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
  as NTFY_Notify() is already invoked in InputMsg().
 
  Cc: Ameya Palande ameya.pala...@nokia.com
  Cc: Omar Ramirez Luna omar.rami...@ti.com
  Cc: Nishanth Menon n...@ti.com
 
  Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
 
 Acked-by: Ameya Palande ameya.pala...@nokia.com

Could this patch be pushed if there are no more comments?

 
  ---
  Ref:
  v0:http://marc.info/?l=linux-omapm=126584779011493w=2
  v1:http://marc.info/?l=linux-omapm=126586224627725w=2
  v2:http://marc.info/?l=linux-omapm=126591341909124w=2
  v3:http://marc.info/?l=linux-omapm=126591743315572w=2
  v4:Comment fixes from v3
 
   drivers/dsp/bridge/wmd/msg_sm.c |   10 ++
   1 files changed, 2 insertions(+), 8 deletions(-)
 
  diff --git a/drivers/dsp/bridge/wmd/msg_sm.c
 b/drivers/dsp/bridge/wmd/msg_sm.c
  index 3a275f1..8475e20 100644
  --- a/drivers/dsp/bridge/wmd/msg_sm.c
  +++ b/drivers/dsp/bridge/wmd/msg_sm.c
  @@ -295,11 +295,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
 (struct list_head *)pMsgFrame);
  if (LST_IsEmpty(hMsgQueue-msgUsedList))
  SYNC_ResetEvent(hMsgQueue-hSyncEvent);
  -   else {
  -   NTFY_Notify(hMsgQueue-hNtfy,
  -   DSP_NODEMESSAGEREADY);
  +   else
  SYNC_SetEvent(hMsgQueue-hSyncEvent);
  -   }
 
  fGotMsg = true;
  }
  @@ -347,11 +344,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
  }
  hMsgQueue-refCount--;
  /* Reset the event if there are still queued messages */
  -   if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
  -   NTFY_Notify(hMsgQueue-hNtfy,
  -   DSP_NODEMESSAGEREADY);
  +   if (!LST_IsEmpty(hMsgQueue-msgUsedList))
  SYNC_SetEvent(hMsgQueue-hSyncEvent);
  -   }
  /* Exit critical section */
  (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
  }


Regards,
Nishanth Menon

Re: [PATCH 1/2] twl6030: regulator: Fix vsel calculations in set/get voltage apis

[Mark Brown]

On Wed, Feb 17, 2010 at 08:54:14PM +0530, Rajendra Nayak wrote:

   /* use the first in-range value */
 - if (min_uV = uV  uV = max_uV)
 + if (min_uV = uV  uV = max_uV) {
 + if (twl_class_is_6030())
 + /*
 +  * Use the below formula to calculate vsel
 +  * mV = 1000mv + 100mv * (vsel - 1)
 +  */
 + vsel = (LDO_MV(mV) - 1000)/100 + 1;
   return twlreg_write(info, TWL_MODULE_PM_RECEIVER,
   VREG_VOLTAGE, vsel);

This looks wrong - this code is inside a loop over vsel-voltage
mappings, if that mapping is wrong and needs to be ignored (which is
what this code is doing) then we shouldn't be looking at it at all.
--
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] twl6030: regulator: Configure STATE register instead of REMAP

[Mark Brown]

On Wed, Feb 17, 2010 at 08:54:15PM +0530, Rajendra Nayak wrote:
 This is no REMAP register on twl6030, instead there is a STATE register
 to drive a resource to a given state.
 The state register can be used to specify what state the resource should
 enter when its associated with a GRP.
 Register Bit field description is as below. The patch programmes the
 corresponding STATE registers for all LDO's to turn ON when assocaited
 with GRP_P1.

Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] omap: Remove DEBUGFS dependency for mux name checking

[Ranjith Lohithakshan]

Sanjeev,

On Wed, 17-Feb-10 3:46 PM +0530, Premi, Sanjeev wrote:
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
 Lohithakshan, Ranjith
 Sent: Wednesday, February 17, 2010 11:48 AM
 To: linux-omap@vger.kernel.org
 Cc: t...@atomide.com; Lohithakshan, Ranjith
 Subject: [PATCH] omap: Remove DEBUGFS dependency for mux name checking

 The check for a valid mux name should be performed regardless 
 of whether
 DEBUGFS is enabled or not.

 This fixes the issue currently seen with boards not booting up
 if DEBUGFS is not enabled in defconfig.

 Signed-off-by: Ranjith Lohithakshan ranji...@ti.com
 ---
  arch/arm/mach-omap2/mux.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 
 Ranjith,
 
 For better readability, I suggest the following:
 
 diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
 index 19001dd..7c0c4ad 100644
 --- a/arch/arm/mach-omap2/mux.c
 +++ b/arch/arm/mach-omap2/mux.c
 @@ -960,16 +960,14 @@ static void __init omap_mux_init_list(struct omap_mux 
 *sup
 while (superset-reg_offset !=  OMAP_MUX_TERMINATOR) {
 struct omap_mux *entry;
 
 -#ifndef CONFIG_OMAP_MUX
 -   /* Skip pins that are not muxed as GPIO by bootloader */
 -   if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
 +#ifdef CONFIG_OMAP_MUX
 +   if (!superset-muxnames || !superset-muxnames[0]) {
 superset++;
 continue;
 }
 -#endif
 -
 -#if defined(CONFIG_OMAP_MUX)  defined(CONFIG_DEBUG_FS)
 -   if (!superset-muxnames || !superset-muxnames[0]) {
 +#else
 +   /* Skip pins that are not muxed as GPIO by bootloader */
 +   if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
 superset++;
 continue;

Sounds good. I will issue an updated patch shortly.

 - Ranjith

 Best regards,
 Sanjeev
 
 
 diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
 index 986077f..1a6ff8f 100644
 --- a/arch/arm/mach-omap2/mux.c
 +++ b/arch/arm/mach-omap2/mux.c
 @@ -969,7 +969,7 @@ static void __init 
 omap_mux_init_list(struct omap_mux *superset)
  }
  #endif
  
 -#if defined(CONFIG_OMAP_MUX)  defined(CONFIG_DEBUG_FS)
 +#ifdef CONFIG_OMAP_MUX
  if (!superset-muxnames || !superset-muxnames[0]) {
  superset++;
  continue;
 -- 
 1.6.2.4

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

RE: [PATCH 1/2] omap: Disable TWL4030/5030 I2C1/I2C4 internal pull-ups

[Sonasath, Moiz]

Hello Eduardo,

 -Original Message-
 From: Eduardo Valentin [mailto:eduardo.valen...@nokia.com]
 Sent: Wednesday, February 17, 2010 1:46 AM
 To: Sonasath, Moiz
 Cc: linux-omap@vger.kernel.org; sa...@linux.intel.com; t...@atomide.com;
 Pais, Allen
 Subject: Re: [PATCH 1/2] omap: Disable TWL4030/5030 I2C1/I2C4 internal
 pull-ups
 
 Hello Moiz,
 
 On Wed, Feb 17, 2010 at 01:57:21AM +0100, ext Moiz Sonasath wrote:
  This patch disables TWL4030/5030 I2C1 adn I2C4(SR) internal pull-up, to
  use only the external HW resistor =470 Ohm for the assured
  functionality in HS mode.
 
  While testing the I2C in High Speed mode, it was discovered that
  without a proper pull-up resistor, there is data corruption during
  multi-byte transfer. RTC(time_set) test case was used for testing.
 
 Nice findings!
 
 
  From the analysis done, it was concluded that ideally we need a
  pull-up of 1.6k Ohm(recomended) or atleast 470 Ohm or greater for
  assured performance in HS mode.
 
  Signed-off-by: Moiz Sonasath m-sonas...@ti.com
  Signed-off-by: Allen Pais allen.p...@ti.com
  ---
   drivers/mfd/twl-core.c  |   13 +
   include/linux/i2c/twl.h |   15 +++
   2 files changed, 28 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
  index 2a76065..35ae2ee 100644
  --- a/drivers/mfd/twl-core.c
  +++ b/drivers/mfd/twl-core.c
  @@ -965,6 +965,7 @@ twl_probe(struct i2c_client *client, const struct
 i2c_device_id *id)
  int status;
  unsignedi;
  struct twl4030_platform_data*pdata = client-dev.platform_data;
  +   u8 temp;
 
  if (!pdata) {
  dev_dbg(client-dev, no platform data?\n);
  @@ -1032,6 +1033,18 @@ twl_probe(struct i2c_client *client, const struct
 i2c_device_id *id)
  goto fail;
  }
 
  +   /* Disable TWL4030/TWL5030 I2C Pull-up on I2C1 and I2C4(SR)
 interface.
  +* Program I2C_SCL_CTRL_PU(bit 0)=0, I2C_SDA_CTRL_PU (bit 2)=0,
  +* SR_I2C_SCL_CTRL_PU(bit 4)=0 and SR_I2C_SDA_CTRL_PU(bit 6)=0.
  +*/
  +
  +   if (twl_class_is_4030()) {
 
 Is this run time check sufficient enough to determine if this fix must be
 applied?
 From what you have described on you patch description, looks like it is
 supposed to be
 only for HS mode. I don't know, maybe if you bind this to a platform /
 board configuration
 flag would it be better? I mean, you create a flag inside the platform
 data to determine
 if this fix must be applied or not. At least for me, having an external pu
 resistor
 seams to be very board dependent.
 

From what I observed, having a smaller pull-up (470 OHM) resistor is 
affecting HS mode operation. Moreover, irrespective of whatever external 
pull-up value we have, if we have internal pull-up enabled, it comes in 
parallel to the external pull-up and thereby reduces the effective pull-up on 
the line. So it's safe to have a higher pull-up value instead rather than 
having the internal pull-up enabled (irrespective of whatever the external 
value is). Also, for all the OMAP boards that we have I think we always have 
an external pull-up typically 470 ohm and hence if we just depend on that 
external resistor without involving any of the internal pull-ups, HS/FS/LS 
should just work fine. That was the whole idea.

 
  +   twl_i2c_read_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
  +   temp = ~(SR_I2C_SDA_CTRL_PU | SR_I2C_SCL_CTRL_PU | \
  +   I2C_SDA_CTRL_PU | I2C_SCL_CTRL_PU);
  +   twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
  +   }
  +
  status = add_children(pdata, id-driver_data);
   fail:
  if (status  0)
  diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
  index bf1c5be..fd95eca 100644
  --- a/include/linux/i2c/twl.h
  +++ b/include/linux/i2c/twl.h
  @@ -239,6 +239,21 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
 
   /*-
 -*/
 
  +/*Interface Bit Register (INTBR) offsets
  + *(Use TWL_4030_MODULE_INTBR)
  + */
  +
  +#define REG_GPPUPDCTR1 0x0F
  +
  +/*I2C1 and I2C4(SR) SDA/SCL pull-up control bits */
  +
  +#define I2C_SCL_CTRL_PUBIT(0)
  +#define I2C_SDA_CTRL_PUBIT(2)
  +#define SR_I2C_SCL_CTRL_PU BIT(4)
  +#define SR_I2C_SDA_CTRL_PU BIT(6)
  +
  +/*-
 -*/
  +
   /*
* Keypad register offsets (use TWL4030_MODULE_KEYPAD)
* ... SIH/interrupt only
  --
  1.5.6.3
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-omap in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 --
 Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo 

[PATCH v2] omap: Remove DEBUGFS dependency for mux name checking

[Ranjith Lohithakshan]

The check for a valid mux name should be performed regardless of whether
DEBUGFS is enabled or not.

This fixes the issue currently seen with boards not booting up
if DEBUGFS is not enabled in defconfig.

Signed-off-by: Ranjith Lohithakshan ranji...@ti.com
---
 arch/arm/mach-omap2/mux.c |   12 +---
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 986077f..b4ca84e 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -961,16 +961,14 @@ static void __init omap_mux_init_list(struct omap_mux 
*superset)
while (superset-reg_offset !=  OMAP_MUX_TERMINATOR) {
struct omap_mux *entry;
 
-#ifndef CONFIG_OMAP_MUX
-   /* Skip pins that are not muxed as GPIO by bootloader */
-   if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
+#ifdef CONFIG_OMAP_MUX
+   if (!superset-muxnames || !superset-muxnames[0]) {
superset++;
continue;
}
-#endif
-
-#if defined(CONFIG_OMAP_MUX)  defined(CONFIG_DEBUG_FS)
-   if (!superset-muxnames || !superset-muxnames[0]) {
+#else
+   /* Skip pins that are not muxed as GPIO by bootloader */
+   if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
superset++;
continue;
}
-- 
1.6.2.4

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

Re: [PATCH 0/24] omap4 for 2.6.34

[Tony Lindgren]

* Shilimkar, Santosh santosh.shilim...@ti.com [100216 21:14]:
 
  2. Clock framework dummy_ck changes done against linux-omap master branch.
 This should leave out most of the driver changes in your series.
 Send to linux-omap list with linux-arm-kernel Cc'd.
 Will do. Some clock node names are changed and since we do clk_get based on 
 clock node
 names, such drivers need to change. 

Hmm, that does not sound right, the clock users need to stay generic.

Can't you use an alias for those clocks in omap44xx_clks[]?

Regards,

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

Re: [PATCH 24/24] omap4: multi-omap: Allow build to work

[Tony Lindgren]

* Gadiyar, Anand gadi...@ti.com [100217 01:09]:
 Shilimkar, Santosh wrote:
   From: Gadiyar, Anand
   Shilimkar, Santosh wrote:
The musb support is enable to omap3 platforms. For omap4 only board
support is available and the driver still isn't supported.
Because of this build with omap3_defconfig used for multi-omap
doesn't work on omap4430 sdp.
   
This patch hacks the musb probe to keep the multi-omap build
working on omap4430 sdp
   
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/usb/musb/musb_core.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)
   
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index bcce8e8..13b1c4a 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2124,6 +2124,10 @@ static int __init musb_probe(struct 
platform_device *pdev)
struct resource *iomem;
void __iomem*base;
   
+   /* FIXME: multi-omap build to work on omap4 */
+   if (cpu_is_omap44xx())
+   return 0;
+
   
   NAK. I'd prefer that we fix the driver issue correctly.
   
   I would have expected the driver to at least load on OMAP4
   even if it does not work. Could you please describe the
   failure?
   
  The probe fails because the register bases aren't mapped 
  for omap4. This is because Tony has lined-up musb board support
  for omap4 but corresponding usb driver patches are not yet lined
  up.
 
 I see the problem now - the platform support is lined up, but the
 driver is not queued up yet.
 
 This is easy to fix by removing the call to usb_musb_init from
 the 4430sdp board. How about doing this?

Yeah that's the way to go.

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

Re: [PATCH 13/24] omap4: clocks: Remove clock hacks from timer-gp.c

[Tony Lindgren]

* Shilimkar, Santosh santosh.shilim...@ti.com [100216 20:59]:
  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com]
  Sent: Wednesday, February 17, 2010 12:12 AM
  To: Shilimkar, Santosh
  Cc: linux-omap@vger.kernel.org; b...@fluff.org.uk; sa...@linux.intel.com; 
  l...@slimlogic.co.uk;
  p...@pwsan.com
  Subject: Re: [PATCH 13/24] omap4: clocks: Remove clock hacks from timer-gp.c
  
  * Santosh Shilimkar santosh.shilim...@ti.com [100216 07:55]:
   Now the omap4 clock framework is mainline and clk_get_rate()
   is functional. Hence reomve the hardcoded clock hacks.
  
  Should we send this as a fix for 2.6.33, or does this depend
  on other patches not yet in 2.6.33?

 This needs the gptimer clocks updates in dmtimer.

OK, so can't send it as a fix then.

Tony

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

RE: [PATCH 1/3] mmc: omap_hsmmc: use packet sync'd DMA

[Madhusudhan]

 -Original Message-
 From: David Vrabel [mailto:david.vra...@csr.com]
 Sent: Wednesday, February 10, 2010 5:52 AM
 To: linux-...@vger.kernel.org
 Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
 Subject: [PATCH 1/3] mmc: omap_hsmmc: use packet sync'd DMA
 
 Use packet sync'd DMA in the omap_hsmmc driver to avoid the
 restriction that transfers must be a multiple of the block size.  This
 is required for byte-mode transfers to SDIO cards.
 
What is the typical scenario here? Is it IO_RW_EXTENDED with block_mode
turned off? 

 Signed-off-by: David Vrabel david.vra...@csr.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   17 +
  1 files changed, 5 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 4b23225..e7142a2 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -114,6 +114,7 @@
 
  #define MMC_TIMEOUT_MS   20
  #define OMAP_MMC_MASTER_CLOCK9600
 +#define OMAP_HSMMC_FIFO_WORDS(512/4)
  #define DRIVER_NAME  mmci-omap-hs
 
  /* Timeouts for entering power saving states on inactivity, msec */
 @@ -887,12 +888,12 @@ static void omap_hsmmc_config_dma_params(struct
 omap_hsmmc_host *host,
   dma_ch = host-dma_ch;
   if (data-flags  MMC_DATA_WRITE) {
   omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
 - (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
 + (host-mapbase + OMAP_HSMMC_DATA), 0,
 OMAP_HSMMC_FIFO_WORDS);
   omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
   sg_dma_address(sgl), 0, 0);
   } else {
   omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
 - (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
 + (host-mapbase + OMAP_HSMMC_DATA), 0,
 OMAP_HSMMC_FIFO_WORDS);
   omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
   sg_dma_address(sgl), 0, 0);
   }
 @@ -901,7 +902,7 @@ static void omap_hsmmc_config_dma_params(struct
 omap_hsmmc_host *host,
   nblk = sg_dma_len(sgl) / blksz;
 
   omap_set_dma_transfer_params(dma_ch, OMAP_DMA_DATA_TYPE_S32,
 - blksz / 4, nblk, OMAP_DMA_SYNC_FRAME,
 + blksz / 4, nblk, OMAP_DMA_SYNC_PACKET,
   omap_hsmmc_get_dma_sync_dev(host, data),
   !(data-flags  MMC_DATA_WRITE));
 

How does this configuration help? Isn't the PACKET again a multiple of
blksz?
 
 @@ -944,17 +945,9 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
 void *data)
  static int omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
   struct mmc_request *req)
  {
 - int dma_ch = 0, ret = 0, err = 1, i;
 + int dma_ch = 0, ret = 0, err = 1;
   struct mmc_data *data = req-data;
 
 - /* Sanity check: all the SG entries must be aligned by block size.
 */
 - for (i = 0; i  data-sg_len; i++) {
 - struct scatterlist *sgl;
 -
 - sgl = data-sg + i;
 - if (sgl-length % data-blksz)
 - return -EINVAL;
 - }
   if ((data-blksz % 4) != 0)
   /* REVISIT: The MMC buffer increments only when MSB is
 written.
* Return error for blksz which is non multiple of four.
 --
 1.6.3.3


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

Re: OMAP Audio

[Jarkko Nikula]

On Wed, 17 Feb 2010 05:01:53 -0700
Gary Thomas g...@mlbassoc.com wrote:

  After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit 
  data
  types. So I'm not really sure how to configure McBSP and sDMA in case of 24 
  bit
  packed format.
  I would go with a trial and error method and find it out how it is 
  working...
 
So it looks that the memory representation must be 32-bit.

 How about sending padded data (24 bits in 32) which is what my
 CODEC wants anyway?  Would this be easier to set up?  How?
 
 (Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I
 need to be moving 24 or 32 bit chunks)
 
Internal representation and link configuration are separate things:

DMA - McBSP rx/tx reg - [FIFO] - McBSP receiver/transmitter

As Peter found, due the DMA and McBSP FIFO, the DMA configuration must
be 32-bit. But I suppose the McBSP receiver/ransmitter could be
configured to transmit only 24-bits.

The OMAP35x Applications Processor Multi-Channel Buffered Serial Port
(McBSP) TRM (SPRUFD1C) seems to have some examples for different data
lengths than internal word length. Worth to look and try with trial and
error method using oscilloscope :-)


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

Re: [PATCH 1/3] mmc: omap_hsmmc: use packet sync'd DMA

[David Vrabel]

Madhusudhan wrote:
 
 -Original Message-
 From: David Vrabel [mailto:david.vra...@csr.com]
 Sent: Wednesday, February 10, 2010 5:52 AM
 To: linux-...@vger.kernel.org
 Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
 Subject: [PATCH 1/3] mmc: omap_hsmmc: use packet sync'd DMA

 Use packet sync'd DMA in the omap_hsmmc driver to avoid the
 restriction that transfers must be a multiple of the block size.  This
 is required for byte-mode transfers to SDIO cards.

 What is the typical scenario here? Is it IO_RW_EXTENDED with block_mode
 turned off? 

This patch isn't necessary.  With byte mode transfers you get a single
sg element and the transfer's block size is set to the length of the
transfer so frame sync mode works fine.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
--
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: OMAP Audio

[Gary Thomas]

On 02/17/2010 10:45 AM, Jarkko Nikula wrote:

On Wed, 17 Feb 2010 05:01:53 -0700
Gary Thomasg...@mlbassoc.com  wrote:


After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data
types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit
packed format.
I would go with a trial and error method and find it out how it is working...


So it looks that the memory representation must be 32-bit.


How about sending padded data (24 bits in 32) which is what my
CODEC wants anyway?  Would this be easier to set up?  How?

(Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I
need to be moving 24 or 32 bit chunks)


Internal representation and link configuration are separate things:

DMA-  McBSP rx/tx reg- [FIFO] -  McBSP receiver/transmitter

As Peter found, due the DMA and McBSP FIFO, the DMA configuration must
be 32-bit. But I suppose the McBSP receiver/ransmitter could be
configured to transmit only 24-bits.

The OMAP35x Applications Processor Multi-Channel Buffered Serial Port
(McBSP) TRM (SPRUFD1C) seems to have some examples for different data
lengths than internal word length. Worth to look and try with trial and
error method using oscilloscope :-)


Thanks.  I'd really like to understand how to set things up to generate
the data I see in TRM:
  Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding 
bits at ‘0’.

This matches my CODEC.  Any clues?

BTW, I was able to set things up for 32 bit PCM data, based on
the email thread you pointed at.  Still need the funky 24 bit
stuff though.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: OMAP Audio

[Mark Brown]

On Wed, Feb 17, 2010 at 10:51:11AM -0700, Gary Thomas wrote:

 Thanks.  I'd really like to understand how to set things up to generate
 the data I see in TRM:
   Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding 
 bits at ?0?.

 This matches my CODEC.  Any clues?

Does your CODEC actually need the padding bits to be zero?  What you're
describing sounds an awful lot like 32 bit data that just has the LSB
ignored.
--
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: OMAP Audio

[Gary Thomas]

On 02/17/2010 10:56 AM, Mark Brown wrote:

On Wed, Feb 17, 2010 at 10:51:11AM -0700, Gary Thomas wrote:


Thanks.  I'd really like to understand how to set things up to generate
the data I see in TRM:
   Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding 
bits at ?0?.

This matches my CODEC.  Any clues?


Does your CODEC actually need the padding bits to be zero?  What you're
describing sounds an awful lot like 32 bit data that just has the LSB
ignored.


I don't think it matters.  The real problem is how to get 24 bits
of data aligned to the right place in the 32 bit frame.  TRM implies
that the hardware can do this, I've just not figured out the magic...

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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

[PATCHv4 1/4] DSPBRIDGE: Rename DMM_RES_OBJECT to DMM_MAP_OBJECT

[Ameya Palande]

In its current state DMM_RES_OBJECT is not correctly tracking reserve and
unreserve but only map and unmap. So lets rename it to DMM_MAP_OBJECT to
clarify what it is really doing!

In addition to this, this patch also does some trivial code cleanup.

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Reviewed-by: Felipe Contreras felipe.contre...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/drv.h |   14 +++---
 drivers/dsp/bridge/rmgr/drv.c  |   69 ++--
 drivers/dsp/bridge/rmgr/drv_interface.c|2 +-
 3 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h 
b/arch/arm/plat-omap/include/dspbridge/drv.h
index b044291..d5f5277 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -90,15 +90,15 @@ struct NODE_RES_OBJECT {
struct NODE_RES_OBJECT *next;
 } ;
 
-/* New structure (member of process context) abstracts DMM resource info */
-struct DMM_RES_OBJECT {
+/* Abstracts DMM resource info */
+struct DMM_MAP_OBJECT {
s32dmmAllocated; /* DMM status */
u32   ulMpuAddr;
u32   ulDSPAddr;
u32   ulDSPResAddr;
-   u32   dmmSize;
+   u32   size;
HANDLE  hProcessor;
-   struct DMM_RES_OBJECT  *next;
+   struct DMM_MAP_OBJECT  *next;
 } ;
 
 /* New structure (member of process context) abstracts DMM resource info */
@@ -139,9 +139,9 @@ struct PROCESS_CONTEXT{
struct NODE_RES_OBJECT *pNodeList;
struct mutex node_mutex;
 
-   /* DMM resources */
-   struct DMM_RES_OBJECT *pDMMList;
-   struct mutex dmm_mutex;
+   /* DMM mapped memory resources */
+   struct DMM_MAP_OBJECT *dmm_map_list;
+   struct mutex dmm_map_mutex;
 
/* DSP Heap resources */
struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index e8b2c58..9b513e2 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -198,37 +198,37 @@ static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt)
 DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE hPCtxt)
 {
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
-   struct DMM_RES_OBJECT **pDMMRes = (struct DMM_RES_OBJECT **)hDMMRes;
+   struct DMM_MAP_OBJECT **pDMMRes = (struct DMM_MAP_OBJECT **)hDMMRes;
DSP_STATUS  status = DSP_SOK;
-   struct DMM_RES_OBJECT *pTempDMMRes = NULL;
+   struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
 
-   *pDMMRes = (struct DMM_RES_OBJECT *)
-   MEM_Calloc(1 * sizeof(struct DMM_RES_OBJECT), MEM_PAGED);
+   *pDMMRes = (struct DMM_MAP_OBJECT *)
+   MEM_Calloc(1 * sizeof(struct DMM_MAP_OBJECT), MEM_PAGED);
GT_0trace(curTrace, GT_ENTER, DRV_InsertDMMResElement: 1);
if (*pDMMRes == NULL) {
GT_0trace(curTrace, GT_5CLASS, DRV_InsertDMMResElement: 2);
status = DSP_EHANDLE;
}
if (DSP_SUCCEEDED(status)) {
-   if (mutex_lock_interruptible(pCtxt-dmm_mutex)) {
+   if (mutex_lock_interruptible(pCtxt-dmm_map_mutex)) {
kfree(*pDMMRes);
return DSP_EFAIL;
}
 
-   if (pCtxt-pDMMList != NULL) {
+   if (pCtxt-dmm_map_list) {
GT_0trace(curTrace, GT_5CLASS,
 DRV_InsertDMMResElement: 3);
-   pTempDMMRes = pCtxt-pDMMList;
-   while (pTempDMMRes-next != NULL)
+   pTempDMMRes = pCtxt-dmm_map_list;
+   while (pTempDMMRes-next)
pTempDMMRes = pTempDMMRes-next;
 
pTempDMMRes-next = *pDMMRes;
} else {
-   pCtxt-pDMMList = *pDMMRes;
+   pCtxt-dmm_map_list = *pDMMRes;
GT_0trace(curTrace, GT_5CLASS,
 DRV_InsertDMMResElement: 4);
}
-   mutex_unlock(pCtxt-dmm_mutex);
+   mutex_unlock(pCtxt-dmm_map_mutex);
}
GT_0trace(curTrace, GT_ENTER, DRV_InsertDMMResElement: 5);
return status;
@@ -239,15 +239,15 @@ DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE 
hPCtxt)
 DSP_STATUS DRV_RemoveDMMResElement(HANDLE hDMMRes, HANDLE hPCtxt)
 {
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
-   struct DMM_RES_OBJECT *pDMMRes = (struct DMM_RES_OBJECT *)hDMMRes;
-   struct DMM_RES_OBJECT *pTempDMMRes = NULL;
+   struct DMM_MAP_OBJECT *pDMMRes = (struct DMM_MAP_OBJECT *)hDMMRes;
+   struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
DSP_STATUS status = DSP_SOK;
 
-   if (mutex_lock_interruptible(pCtxt-dmm_mutex))
+   if 

[PATCHv4 3/4] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes

[Ameya Palande]

This patch fixes following issues:
1. pDMMRes was dereferenced and modified when it was already freed by
   PROC_Ummap(). This results in memory corruption.
2. Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMap()
   which will not retrieve correct DMMRes element.

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
 drivers/dsp/bridge/rmgr/drv.c |   12 ++--
 1 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 12ba7e0..b88b5a3 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -293,12 +293,12 @@ DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt)
pDMMRes = pDMMList;
pDMMList = pDMMList-next;
if (pDMMRes-dmmAllocated) {
+   /* PROC_UnMap will free pDMMRes pointer */
status = PROC_UnMap(pDMMRes-hProcessor,
-(void *)pDMMRes-ulDSPResAddr, pCtxt);
+(void *)pDMMRes-ulDSPAddr, pCtxt);
if (DSP_FAILED(status))
pr_debug(%s: PROC_UnMap failed! status =
 0x%xn, __func__, status);
-   pDMMRes-dmmAllocated = 0;
}
}
return status;
@@ -309,17 +309,9 @@ DSP_STATUS DRV_RemoveAllDMMResElements(HANDLE hPCtxt)
 {
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
DSP_STATUS status = DSP_SOK;
-   struct DMM_MAP_OBJECT *pTempDMMRes2 = NULL;
-   struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
struct DMM_RSV_OBJECT *temp, *rsv_obj;
 
DRV_ProcFreeDMMRes(pCtxt);
-   pTempDMMRes = pCtxt-dmm_map_list;
-   while (pTempDMMRes != NULL) {
-   pTempDMMRes2 = pTempDMMRes;
-   pTempDMMRes = pTempDMMRes-next;
-   kfree(pTempDMMRes2);
-   }
pCtxt-dmm_map_list = NULL;
 
/* Free DMM reserved memory resources */
-- 
1.6.3.3

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

[PATCHv4 0/4] DSPBRIDGE: Improved reserved and mapped resource cleanup

[Ameya Palande]

This patch series splits DMM_RES_OBJECT into DMM_MAP_OBJECT and DMM_RSV_OBJECT
which are used independently for mapped and reserved memory resources
accounting. This will help in cleanup of reserved memory resources which was
not handled properly before. With these patches resource cleanup mechanism
will work perfectly in a use case where a big chunk of memory is reserved and
then lot of mappings are created inside it.

Changes since v3:
1. Improved mapped memory resource cleanup

Changes since v2:
1. Removed locking from DRV_RemoveAllDMMResElements()
2. Removed cleanup variable from PROC_UnReserveMemory()
   http://marc.info/?l=linux-omapm=126637211831587w=2
3. Rebased patchset on top of following commit:
   DSPBRIDGE: Remove conditional check from the InputMsg function

Changed since v1:
1. Reduced indentation
   http://marc.info/?l=linux-omapm=126624982331523w=2


Ameya Palande (4):
  DSPBRIDGE: Rename DMM_RES_OBJECT to DMM_MAP_OBJECT
  DSPBRIDGE: New reserved memory accounting framework
  DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes
  DSPBRIDGE: Improved mapped memory cleanup

 arch/arm/plat-omap/include/dspbridge/drv.h |   44 ++---
 arch/arm/plat-omap/include/dspbridge/proc.h|4 +-
 .../plat-omap/include/dspbridge/resourcecleanup.h  |   11 --
 drivers/dsp/bridge/pmgr/wcd.c  |7 +-
 drivers/dsp/bridge/rmgr/drv.c  |  176 +++-
 drivers/dsp/bridge/rmgr/drv_interface.c|5 +-
 drivers/dsp/bridge/rmgr/node.c |5 +-
 drivers/dsp/bridge/rmgr/proc.c |   85 +++---
 8 files changed, 114 insertions(+), 223 deletions(-)

--
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

[PATCHv4 2/4] DSPBRIDGE: New reserved memory accounting framework

[Ameya Palande]

DSP_RSV_OBJECT is introduced to track reserved memory accounting information.
This will allow us to do proper cleanup for memory reserved using
PROC_ReserveMemory().

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/drv.h  |   10 +
 arch/arm/plat-omap/include/dspbridge/proc.h |4 +-
 drivers/dsp/bridge/pmgr/wcd.c   |7 ++--
 drivers/dsp/bridge/rmgr/drv.c   |   18 ++
 drivers/dsp/bridge/rmgr/drv_interface.c |2 +
 drivers/dsp/bridge/rmgr/node.c  |5 ++-
 drivers/dsp/bridge/rmgr/proc.c  |   52 +--
 7 files changed, 73 insertions(+), 25 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h 
b/arch/arm/plat-omap/include/dspbridge/drv.h
index d5f5277..f7d0e3e 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -101,6 +101,12 @@ struct DMM_MAP_OBJECT {
struct DMM_MAP_OBJECT  *next;
 } ;
 
+/* Used for DMM reserved memory accounting */
+struct DMM_RSV_OBJECT {
+   struct  list_head   link;
+   u32 dsp_reserved_addr;
+};
+
 /* New structure (member of process context) abstracts DMM resource info */
 struct DSPHEAP_RES_OBJECT {
s32heapAllocated; /* DMM status */
@@ -143,6 +149,10 @@ struct PROCESS_CONTEXT{
struct DMM_MAP_OBJECT *dmm_map_list;
struct mutex dmm_map_mutex;
 
+   /* DMM reserved memory resources */
+   struct list_head dmm_rsv_list;
+   spinlock_t dmm_rsv_lock;
+
/* DSP Heap resources */
struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
 
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h 
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 8dbdaac..1ffe763 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -560,7 +560,7 @@
  *  Details:
  */
extern DSP_STATUS PROC_ReserveMemory(DSP_HPROCESSOR hProcessor,
-u32 ulSize, void **ppRsvAddr);
+   u32 ulSize, void **ppRsvAddr, struct PROCESS_CONTEXT *pr_ctxt);
 
 /*
  *   PROC_UnMap 
@@ -604,6 +604,6 @@
  *  Details:
  */
extern DSP_STATUS PROC_UnReserveMemory(DSP_HPROCESSOR hProcessor,
-  void *pRsvAddr);
+   void *pRsvAddr, struct PROCESS_CONTEXT *pr_ctxt);
 
 #endif /* PROC_ */
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index beea23b..1ef606e 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1054,12 +1054,13 @@ u32 PROCWRAP_ReserveMemory(union Trapped_Args *args, 
void *pr_ctxt)
 
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_ReserveMemory: entered\n);
status = PROC_ReserveMemory(args-ARGS_PROC_RSVMEM.hProcessor,
-  args-ARGS_PROC_RSVMEM.ulSize, pRsvAddr);
+  args-ARGS_PROC_RSVMEM.ulSize, pRsvAddr,
+  pr_ctxt);
if (DSP_SUCCEEDED(status)) {
if (put_user(pRsvAddr, args-ARGS_PROC_RSVMEM.ppRsvAddr)) {
status = DSP_EINVALIDARG;
PROC_UnReserveMemory(args-ARGS_PROC_RSVMEM.hProcessor,
-   pRsvAddr);
+   pRsvAddr, pr_ctxt);
}
}
return status;
@@ -1100,7 +1101,7 @@ u32 PROCWRAP_UnReserveMemory(union Trapped_Args *args, 
void *pr_ctxt)
GT_0trace(WCD_debugMask, GT_ENTER,
 PROCWRAP_UnReserveMemory: entered\n);
status = PROC_UnReserveMemory(args-ARGS_PROC_UNRSVMEM.hProcessor,
-args-ARGS_PROC_UNRSVMEM.pRsvAddr);
+args-ARGS_PROC_UNRSVMEM.pRsvAddr, pr_ctxt);
return status;
 }
 
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 9b513e2..12ba7e0 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -298,25 +298,20 @@ DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt)
if (DSP_FAILED(status))
pr_debug(%s: PROC_UnMap failed! status =
 0x%xn, __func__, status);
-   status = PROC_UnReserveMemory(pDMMRes-hProcessor,
-(void *)pDMMRes-ulDSPResAddr);
-   if (DSP_FAILED(status))
-   pr_debug(%s: PROC_UnReserveMemory failed!
-status = 0x%xn, __func__, status);
pDMMRes-dmmAllocated = 0;
}
}
return status;
 }
 
-/* Release all DMM resources and its context
-* This is called from .bridge_release. */
+/* Release all Mapped and Reserved DMM resources */
 DSP_STATUS 

[PATCHv4 4/4] DSPBRIDGE: Improved mapped memory cleanup

[Ameya Palande]

This patch improves current mapped memory cleanup mechanism by using linux
native list implementation. As a side effect we also get following benefits:

1. Unnecessary data members in DMM_MAP_OBJECT are removed which results in
   memory saving.

2. Following functions are removed as they are not needed anymore:
   DRV_ProcFreeDMMRes()
   DRV_UpdateDMMResElement()
   DRV_InsertDMMResElement()
   DRV_GetDMMResElement()
   DRV_RemoveDMMResElement()

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/drv.h |   30 +---
 .../plat-omap/include/dspbridge/resourcecleanup.h  |   11 --
 drivers/dsp/bridge/rmgr/drv.c  |  161 ++--
 drivers/dsp/bridge/rmgr/drv_interface.c|3 +-
 drivers/dsp/bridge/rmgr/proc.c |   33 +++--
 5 files changed, 44 insertions(+), 194 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h 
b/arch/arm/plat-omap/include/dspbridge/drv.h
index f7d0e3e..854923a 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -90,16 +90,11 @@ struct NODE_RES_OBJECT {
struct NODE_RES_OBJECT *next;
 } ;
 
-/* Abstracts DMM resource info */
+/* Used for DMM mapped memory accounting */
 struct DMM_MAP_OBJECT {
-   s32dmmAllocated; /* DMM status */
-   u32   ulMpuAddr;
-   u32   ulDSPAddr;
-   u32   ulDSPResAddr;
-   u32   size;
-   HANDLE  hProcessor;
-   struct DMM_MAP_OBJECT  *next;
-} ;
+   struct  list_head   link;
+   u32 dsp_addr;
+};
 
 /* Used for DMM reserved memory accounting */
 struct DMM_RSV_OBJECT {
@@ -146,8 +141,8 @@ struct PROCESS_CONTEXT{
struct mutex node_mutex;
 
/* DMM mapped memory resources */
-   struct DMM_MAP_OBJECT *dmm_map_list;
-   struct mutex dmm_map_mutex;
+   struct list_head dmm_map_list;
+   spinlock_t dmm_map_lock;
 
/* DMM reserved memory resources */
struct list_head dmm_rsv_list;
@@ -398,17 +393,4 @@ struct PROCESS_CONTEXT{
extern DSP_STATUS DRV_ReleaseResources(IN u32 dwContext,
   struct DRV_OBJECT *hDrvObject);
 
-/*
- *   DRV_ProcFreeDMMRes 
- *  Purpose:
- *   Actual DMM De-Allocation.
- *  Parameters:
- *  hPCtxt:  Path to the driver Registry Key.
- *  Returns:
- *  DSP_SOK if success;
- */
-
-
-   extern DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt);
-
 #endif /* DRV_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h 
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index ffbcf5e..2bb756a 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -48,17 +48,6 @@ extern DSP_STATUS DRV_RemoveNodeResElement(HANDLE nodeRes, 
HANDLE status);
 
 extern void DRV_ProcNodeUpdateStatus(HANDLE hNodeRes, s32 status);
 
-extern DSP_STATUS DRV_UpdateDMMResElement(HANDLE dmmRes, u32 pMpuAddr,
- u32 ulSize, u32 pReqAddr,
- u32 ppMapAddr, HANDLE hProcesso);
-
-extern DSP_STATUS DRV_InsertDMMResElement(HANDLE dmmRes, HANDLE pCtxt);
-
-extern DSP_STATUS DRV_GetDMMResElement(u32 pMapAddr, HANDLE dmmRes,
-  HANDLE pCtxt);
-
-extern DSP_STATUS DRV_RemoveDMMResElement(HANDLE dmmRes, HANDLE pCtxt);
-
 extern DSP_STATUS DRV_ProcUpdateSTRMRes(u32 uNumBufs, HANDLE STRMRes);
 
 extern DSP_STATUS DRV_ProcInsertSTRMResElement(HANDLE hStrm, HANDLE STRMRes,
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index b88b5a3..bb6c246 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -193,129 +193,27 @@ static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt)
return status;
 }
 
-/* Allocate the DMM resource element
-* This is called from Proc_Map. after the actual resource is allocated */
-DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE hPCtxt)
-{
-   struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
-   struct DMM_MAP_OBJECT **pDMMRes = (struct DMM_MAP_OBJECT **)hDMMRes;
-   DSP_STATUS  status = DSP_SOK;
-   struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
-
-   *pDMMRes = (struct DMM_MAP_OBJECT *)
-   MEM_Calloc(1 * sizeof(struct DMM_MAP_OBJECT), MEM_PAGED);
-   GT_0trace(curTrace, GT_ENTER, DRV_InsertDMMResElement: 1);
-   if (*pDMMRes == NULL) {
-   GT_0trace(curTrace, GT_5CLASS, DRV_InsertDMMResElement: 2);
-   status = DSP_EHANDLE;
-   }
-   if (DSP_SUCCEEDED(status)) {
-   if (mutex_lock_interruptible(pCtxt-dmm_map_mutex)) {
-   kfree(*pDMMRes);
-   return DSP_EFAIL;
-   }
-
-   if 

Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts

[David Vrabel]

David Vrabel wrote:
 
 +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
 +{
 + struct omap_hsmmc_host *host = mmc_priv(mmc);
 + u32 ie, con;
 + unsigned long flags;
 +
 + spin_lock_irqsave(host-irq_lock, flags);
 +
 + /*
 +  * When interrupts are enabled, CTPL must be set to enable
 +  * DAT1 input buffer (or the card interrupt is always
 +  * asserted) and FCLK must be enabled else wakeup does not
 +  * work.
 +  *
 +  * FIXME: the power save code probably shouldn't be playing
 +  * with FCLK and allow the clock subsystem to put it into
 +  * smart-idle mode instead.
 +  */
 + con = OMAP_HSMMC_READ(host-base, CON);
 + ie = OMAP_HSMMC_READ(host-base, IE);
 + if (enable) {
 + clk_enable(host-fclk);
 + ie |= CIRQ_ENABLE;
 + con |= CTPL;
 + } else {
 + clk_disable(host-fclk);
 + ie = ~CIRQ_ENABLE;
 + con = ~CTPL;
 + }
 + OMAP_HSMMC_WRITE(host-base, CON, con);
 + OMAP_HSMMC_WRITE(host-base, IE, ie);
 +
 + spin_unlock_irqrestore(host-irq_lock, flags);
 +}

This isn't doing a posted write flush but when it's added this ends up
looking like:

spin_lock_irqsave(host-lock, flags);

/*
 * When interrupts are enabled, CTPL must be set to enable
 * DAT1 input buffer (or the card interrupt is always
 * asserted) and FCLK must be enabled else wakeup does not
 * work.  Take care to disable FCLK after all the register
 * accesses as they might not complete if FCLK is off.
 *
 * FIXME: the power save code probably shouldn't be playing
 * with FCLK and allow the clock subsystem to put it into
 * smart-idle mode instead.
 */
con = OMAP_HSMMC_READ(host-base, CON);
ie = OMAP_HSMMC_READ(host-base, IE);
if (enable) {
clk_enable(host-fclk);
ie |= CIRQ_ENABLE;
con |= CTPL;
} else {
ie = ~CIRQ_ENABLE;
con = ~CTPL;
}
OMAP_HSMMC_WRITE(host-base, CON, con);
OMAP_HSMMC_WRITE(host-base, IE, ie);
OMAP_HSMMC_READ(host-base, IE); /* flush posted write */
if (!enable) {
clk_disable(host-fclk);
}

spin_unlock_irqrestore(host-lock, flags);

Could someone from TI could comment on why disabling FCLK affects
register read?

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
--
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] mmc: omap_hsmmc: enable SDIO card interrupts

[Madhusudhan]

 -Original Message-
 From: David Vrabel [mailto:david.vra...@csr.com]
 Sent: Wednesday, February 10, 2010 5:52 AM
 To: linux-...@vger.kernel.org
 Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
 Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
 
 Enable the use of SDIO card interrupts.  This requires setting ENAWAKEUP
 in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
 smart-idle mode.
 
 FCLK must be enabled while SDIO interrupts are enabled or the MMC block
 won't wake-up.
 

I am curious to know the system behavior with this patch. Does the FCLK
remain enabled forever if a SDIO card is detected on the bus?

The mmc_signal_sdio_irq fn seems to disable the irq and then wake up the
sdio_irq_thread which would result in enabling the FCLK back. Hence the
above question.

 The writes to STAT and ISE when starting a command are unnecessary and
 have been removed.
 
 Signed-off-by: David Vrabel david.vra...@csr.com
 ---
 As noted in the FIXME comment, I think the correct thing to do is to
 always leave FCLK enabled.  The clock/clockdomain subsystems should be
 configuring smart-idle mode making explicit calls to disable FCLK
 unnecessary.  I couldn't follow the clock subsystem to see if it was
 actually doing this, though.
 ---
  drivers/mmc/host/omap_hsmmc.c |   94 
 -
  1 files changed, 65 insertions(+), 29 deletions(-)
 
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index e6d8cb3..ad0f867 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -64,6 +64,7 @@
  #define SDVS_MASK0x0E00
  #define SDVSCLR  0xF1FF
  #define SDVSDET  0x0400
 +#define ENAWAKEUP(1  2)
  #define AUTOIDLE 0x1
  #define SDBP (1  8)
  #define DTO  0xe
 @@ -74,9 +75,11 @@
  #define CLKD_SHIFT   6
  #define DTO_MASK 0x000F
  #define DTO_SHIFT16
 +#define CIRQ_ENABLE  (1  8)
  #define INT_EN_MASK  0x307F0033
  #define BWR_ENABLE   (1  4)
  #define BRR_ENABLE   (1  5)
 +#define CTPL (1  11)
  #define INIT_STREAM  (1  1)
  #define DP_SELECT(1  21)
  #define DDIR (1  4)
 @@ -84,10 +87,12 @@
  #define MSBS (1  5)
  #define BCE  (1  1)
  #define FOUR_BIT (1  1)
 +#define IWE  (1  24)
  #define DW8  (1  5)
  #define CC   0x1
  #define TC   0x02
  #define OD   0x1
 +#define CIRQ (1  8)
  #define ERR  (1  15)
  #define CMD_TIMEOUT  (1  16)
  #define DATA_TIMEOUT (1  20)
 @@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
 omap_hsmmc_host *host)
   ;
 
   OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
 - OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
 + OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE |
 ENAWAKEUP);
 
   if (host-id == OMAP_MMC1_DEVID) {
   if (host-power_mode != MMC_POWER_OFF 
 @@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
 omap_hsmmc_host *host)
   }
 
   OMAP_HSMMC_WRITE(host-base, HCTL,
 - OMAP_HSMMC_READ(host-base, HCTL) | hctl);
 + OMAP_HSMMC_READ(host-base, HCTL) | hctl | IWE);
 
   OMAP_HSMMC_WRITE(host-base, CAPA,
   OMAP_HSMMC_READ(host-base, CAPA) | capa);
 @@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
 omap_hsmmc_host *host)
   ;
 
   OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
 - OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
 + OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK | CIRQ);
   OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
 
   /* Do not initialize card-specific things if the power is off */
 @@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
 *host, struct mmc_command *cmd,
   mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
   host-cmd = cmd;
 
 - /*
 -  * Clear status bits and enable interrupts
 -  */
 - OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
 - OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
 -
   if (host-use_dma)
   OMAP_HSMMC_WRITE(host-base, IE,
INT_EN_MASK  ~(BRR_ENABLE | BWR_ENABLE));
 @@ -638,18 +637,21 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
 *dev_id)
  {
   struct omap_hsmmc_host *host = dev_id;
   struct mmc_data *data;
 - int end_cmd = 0, end_trans = 0, status;
 + u32 status;
 + int end_cmd = 0, end_trans = 0;
 + bool card_irq = false;
 
   spin_lock(host-irq_lock);
 
 - if (host-mrq == NULL) {
 - OMAP_HSMMC_WRITE(host-base, STAT,
 - 

Re: [PATCH v2] omap: Remove DEBUGFS dependency for mux name checking

[Tony Lindgren]

* Ranjith Lohithakshan ranji...@ti.com [100217 09:14]:
 The check for a valid mux name should be performed regardless of whether
 DEBUGFS is enabled or not.
 
 This fixes the issue currently seen with boards not booting up
 if DEBUGFS is not enabled in defconfig.
 
 Signed-off-by: Ranjith Lohithakshan ranji...@ti.com

Thanks, I've updated the description a bit to include the error
and added the patch into omap-fixes-for-linus.

Updated patch below.

Regards,

Tony
From: Ranjith Lohithakshan ranji...@ti.com
Date: Wed, 17 Feb 2010 17:17:01 +
Subject: [PATCH] omap: Remove DEBUG_FS dependency for mux name checking

The check for a valid mux name should be performed regardless of whether
DEBUG_FS is enabled or not. Otherwise without DEBUG_FS, we get:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0004000
[] *pgd=
Internal error: Oops: 5 [#1]
last sysfs file:
Modules linked in:
CPU: 0Not tainted  (2.6.33-rc8 #10)
PC is at strcmp+0x18/0x40
LR is at omap_mux_init_signal+0x68/0x14c
...

This fixes the issue currently seen with boards not booting up
if DEBUG_FS is not enabled in defconfig.

Note that the earlier ifndef + ifdef now becomes simpler ifdef else:
If CONFIG_OMAP_MUX is selected, we use pin names. If it's not selected,
we only want the GPIO to mux register mapping.

Signed-off-by: Ranjith Lohithakshan ranji...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 5fedc50..5fef73f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -961,16 +961,14 @@ static void __init omap_mux_init_list(struct omap_mux *superset)
 	while (superset-reg_offset !=  OMAP_MUX_TERMINATOR) {
 		struct omap_mux *entry;
 
-#ifndef CONFIG_OMAP_MUX
-		/* Skip pins that are not muxed as GPIO by bootloader */
-		if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
+#ifdef CONFIG_OMAP_MUX
+		if (!superset-muxnames || !superset-muxnames[0]) {
 			superset++;
 			continue;
 		}
-#endif
-
-#if defined(CONFIG_OMAP_MUX)  defined(CONFIG_DEBUG_FS)
-		if (!superset-muxnames || !superset-muxnames[0]) {
+#else
+		/* Skip pins that are not muxed as GPIO by bootloader */
+		if (!OMAP_MODE_GPIO(omap_mux_read(superset-reg_offset))) {
 			superset++;
 			continue;
 		}

Re: linux-next: manual merge of the omap tree with the arm tree

[Tony Lindgren]

* Russell King rmk+l...@arm.linux.org.uk [100215 07:00]:
 On Thu, Feb 04, 2010 at 08:04:44PM -0800, Tony Lindgren wrote:
  Russell, can you please let me know if you have some static
  commit ID containing the patch above that I could use that as
  base for my patches?
 
 Right, when it eventually gets through linux-next, 4e6d488

Thanks, I have updated omap for-next based on that.

Regards,

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

Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts

[David Vrabel]

Madhusudhan wrote:



-Original Message-
From: David Vrabel [mailto:david.vra...@csr.com]
Sent: Wednesday, February 10, 2010 5:52 AM
To: linux-...@vger.kernel.org
Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts

Enable the use of SDIO card interrupts.  This requires setting ENAWAKEUP
in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
smart-idle mode.

FCLK must be enabled while SDIO interrupts are enabled or the MMC block
won't wake-up.



I am curious to know the system behavior with this patch. Does the FCLK
remain enabled forever if a SDIO card is detected on the bus?


Only if card interrupts are enabled.  The card irq is disabled when the 
sdio_irq_thread exits.


This is why I think that smart-idle mode needs to be used (it's turned
on by default on the MMC controller) but I don't understand the
clock/clockdomain code to see if that's doing the right thing.

If smart-idle mode is used then we don't need to disable FCLK manually 
to save power.  This will simplify the driver a bit.


David
--
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] mmc: omap_hsmmc: enable SDIO card interrupts

[Paul Walmsley]

On Wed, 17 Feb 2010, David Vrabel wrote:

 Madhusudhan wrote:
  
   -Original Message-
   From: David Vrabel [mailto:david.vra...@csr.com]
   Sent: Wednesday, February 10, 2010 5:52 AM
   To: linux-...@vger.kernel.org
   Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
   Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
   
   Enable the use of SDIO card interrupts.  This requires setting ENAWAKEUP
   in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
   smart-idle mode.
   
   FCLK must be enabled while SDIO interrupts are enabled or the MMC block
   won't wake-up.
   
  
  I am curious to know the system behavior with this patch. Does the FCLK
  remain enabled forever if a SDIO card is detected on the bus?
 
 Only if card interrupts are enabled.  The card irq is disabled when the
 sdio_irq_thread exits.
 
 This is why I think that smart-idle mode needs to be used (it's turned
 on by default on the MMC controller) but I don't understand the
 clock/clockdomain code to see if that's doing the right thing.

The easiest way to observe the operation of the clock and clockdomain code 
is to change the #undef DEBUG to #define DEBUG at the top of the clock 
or clockdomain code files that you're interested in observing, recompile 
the kernel, and boot it.  You'll want to use an ignore_loglevel kernel 
command line parameter or something similar.  This will alter the behavior 
of some power management situations, since the output of the debug 
messages will keep a UART active, but should be sufficient for the MMC 
work.

 If smart-idle mode is used then we don't need to disable FCLK manually to save
 power.  This will simplify the driver a bit.

Perhaps I'm misunderstanding what you're referring to, but it seems there 
is some confusion as to what target smart-idle mode does.  It's the PRCM 
that requests that the module enter idle.  This process is not dependent 
on the target idle mode bits, and happens when the PRCM concludes that 
clocks can potentially be disabled.  In the case of functional clocks, 
this process is triggered when some code (i.e., the clock code) disables 
the CM_FCLKEN_x.EN_y bit.

After the PRCM requests the module enter idle, depending on the 
OCP_SYSCONFIG.SIDLEMODE bits, the module either does not acknowledge the 
idle request (no-idle mode), always acknowledges the request (force-idle 
mode), or, acknowledges the idle request when the module believes it is 
internally quiescent (smart-idle mode).  This acknowledgement signal 
originates from the module and goes back to the PRCM.  Once this happens, 
the PRCM can switch off some clocks.  As can be seen in the HSMMC TRM 
docs, the HSMMC module expects the PRCM to disable both the interface and 
the functional clock when it acknowledges the idle request.

My point is that the target idle mode is unlikely to have any impact on 
the need to disable and enable the functional clock in software.

That said, I don't really know the details of the SDIO wakeup issue that 
you mention, but it might be worth observing that if your SDIO card 
doesn't generate its own internal clock, then it's unlikely to be able to 
provide an interrupt to wake up the controller when the HSMMC functional 
clock is off.  This is because the only other available clock for the card 
would come from the HSMMC's functional clock.

It seems to me that this issue could be diagnosed fairly easily by 
triggering the SDIO interrupt line by hand while the HSMMC functional 
clock is kept off.  If a wakeup is generated, then it's a card issue.  
Otherwise, you'll need to do some more intensive diagnostics.  For 
example, if the CORE powerdomain isn't on when you do the test, presumably 
you'll need to make sure that an IO ring wakeup is set for the SDIO card's 
interrupt line.  (In these situations, the interrupt response latency will 
be quite high, since the chip will need to boot from off-mode.  The driver 
can request a lower bound on the interrupt response latency via an OMAP PM 
layer function, which will likely keep the chip from entering off mode.)  

But if the CORE powerdomain is on or in retention when you do the test, 
then perhaps there is indeed some issue with the HSMMC controller where it 
cannot generate wakeups when its functional clock is off.  You'd want to 
verify that your HSMMC register settings are correct, though, before 
coming to that conclusion.


- 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 3/3] mmc: omap_hsmmc: enable SDIO card interrupts

[Cousson, Benoit]

From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of David Vrabel
Sent: Wednesday, February 17, 2010 7:10 PM

David Vrabel wrote:

 +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
 +{
 +struct omap_hsmmc_host *host = mmc_priv(mmc);
 +u32 ie, con;
 +unsigned long flags;
 +
 +spin_lock_irqsave(host-irq_lock, flags);
 +
 +/*
 + * When interrupts are enabled, CTPL must be set to enable
 + * DAT1 input buffer (or the card interrupt is always
 + * asserted) and FCLK must be enabled else wakeup does not
 + * work.
 + *
 + * FIXME: the power save code probably shouldn't be playing
 + * with FCLK and allow the clock subsystem to put it into
 + * smart-idle mode instead.
 + */
 +con = OMAP_HSMMC_READ(host-base, CON);
 +ie = OMAP_HSMMC_READ(host-base, IE);
 +if (enable) {
 +clk_enable(host-fclk);
 +ie |= CIRQ_ENABLE;
 +con |= CTPL;
 +} else {
 +clk_disable(host-fclk);
 +ie = ~CIRQ_ENABLE;
 +con = ~CTPL;
 +}
 +OMAP_HSMMC_WRITE(host-base, CON, con);
 +OMAP_HSMMC_WRITE(host-base, IE, ie);
 +
 +spin_unlock_irqrestore(host-irq_lock, flags);
 +}

This isn't doing a posted write flush but when it's added this ends up
looking like:

   spin_lock_irqsave(host-lock, flags);

   /*
* When interrupts are enabled, CTPL must be set to enable
* DAT1 input buffer (or the card interrupt is always
* asserted) and FCLK must be enabled else wakeup does not
* work.  Take care to disable FCLK after all the register
* accesses as they might not complete if FCLK is off.
*
* FIXME: the power save code probably shouldn't be playing
* with FCLK and allow the clock subsystem to put it into
* smart-idle mode instead.
*/
   con = OMAP_HSMMC_READ(host-base, CON);
   ie = OMAP_HSMMC_READ(host-base, IE);
   if (enable) {
   clk_enable(host-fclk);
   ie |= CIRQ_ENABLE;
   con |= CTPL;
   } else {
   ie = ~CIRQ_ENABLE;
   con = ~CTPL;
   }
   OMAP_HSMMC_WRITE(host-base, CON, con);
   OMAP_HSMMC_WRITE(host-base, IE, ie);
   OMAP_HSMMC_READ(host-base, IE); /* flush posted write */
if (!enable) {
clk_disable(host-fclk);
}

   spin_unlock_irqrestore(host-lock, flags);

Could someone from TI could comment on why disabling FCLK affects
register read?

Most IPs will require both iclk and fclk to be active in order to access them. 
Some simple IP can work with only an iclk.
Otherwise, accessing a register while enabling only iclk will lead to 
unpredictable behavior.

Regards,
Benoit

Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 
036 420 040 R.C.S Antibes. Capital de EUR 753.920



--
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 RFC]OMAP3430: hwmod FW for GPIO

[Kevin Hilman]

Varadarajan, Charulatha ch...@ti.com writes:

 From: Charulatha V ch...@ti.com

 This patch series makes the OMAP3430 GPIO module
 use hwmod framework.

 This patch series applies on top of pm branch
 and it requires my previous patch set which converts
 GPIO into an early init device. 

There's no reason this needs to depend on the PM branch.  

I have a WIP branch on my tree named 'pm-wip/hwmod' which already has
a set of hwmod updates (UART and MMC currently.)  This branch is based
on Tony's omap-for-linus branch.  

To best avoid conflicts with other hwmods, please base this series on
my pm-wip/hwmod branch.

Kevin

 They are boot tested on SDP 3430 and compile tested
 for OMAP 2420 and 2430.

 Charulatha V (2):
   OMAP3: hwmod: add GPIO hwmods for OMAP3430
   OMAP3: hwmod: Adapt HWMOD FW for GPIO OMAP3430

  arch/arm/mach-omap2/gpio.c |  901 
 
  arch/arm/mach-omap2/omap_hwmod_34xx.h  |  410 +++
  arch/arm/plat-omap/include/plat/gpio.h |   25 +-
  3 files changed, 533 insertions(+), 803 deletions(-)

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

[PATCH 0/7] OMAP PM updates for 2.6.34

[Kevin Hilman]

Here's a small series of PM updates destined for 2.6.34.

This branch is also available as 'pm-2.6.34' in my tree and is based
on Tony's omap-for-linus branch. This will be it for PM patches for
2.6.34 as the rest of the PM branch is under more significant rework.

Yes, this is a bit late, but hopefully better late than never for
these relatively minor changes.  Thes changes mainly affect CPUidle
and off-mode support, neither of which are currently enbled in
mainline default defconfigs.

Kalle Jokiniemi (2):
  OMAP3: cpuidle: Add valid field into C-state parameter passing
  OMAP3: RX-51: Pass cpu idle parameters

Kevin Hilman (2):
  OMAP3: cpuidle: configure latencies/thresholds from board file
  OMAP3: RX-51: support sleep indicator LEDs

Rajendra Nayak (1):
  OMAP3: PM: add scratchpad locking function

Sanjeev Premi (1):
  OMAP3: cpuidle: Update statistics for correct state

Tero Kristo (1):
  OMAP3: PM: Added support for L2 aux ctrl register save and restore

 arch/arm/mach-omap2/board-3430sdp.c |   20 +++
 arch/arm/mach-omap2/board-rx51.c|   44 +++
 arch/arm/mach-omap2/cpuidle34xx.c   |  226 +--
 arch/arm/mach-omap2/pm.h|   20 +++
 arch/arm/mach-omap2/pm34xx.c|4 +
 arch/arm/mach-omap2/sleep34xx.S |   59 +-
 arch/arm/plat-omap/Kconfig  |   17 +++
 7 files changed, 352 insertions(+), 38 deletions(-)

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

[PATCH 3/7] OMAP3: cpuidle: Add valid field into C-state parameter passing

[Kevin Hilman]

From: Kalle Jokiniemi kalle.jokini...@digia.com

Different boards benefit differently from the available
seven C-states for cpu idle. In most cases, only few,
properly spaced (in terms of consumption and latency)
C-states are required to make the power management
optimal. Hence we need a possibility to pass which
C-states are actually used for each board.

So added the valid field to cpuidle_params and added
support to 3430sdp, which uses the paramenter passing.

Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/board-3430sdp.c |   14 ++--
 arch/arm/mach-omap2/cpuidle34xx.c   |   37 +-
 arch/arm/mach-omap2/pm.h|1 +
 3 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 99f295e..d4647ab 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -61,19 +61,19 @@
 /* FIXME: These values need to be updated based on more profiling on 3430sdp*/
 static struct cpuidle_params omap3_cpuidle_params_table[] = {
/* C1 */
-   {2, 2, 5},
+   {1, 2, 2, 5},
/* C2 */
-   {10, 10, 30},
+   {1, 10, 10, 30},
/* C3 */
-   {50, 50, 300},
+   {1, 50, 50, 300},
/* C4 */
-   {1500, 1800, 4000},
+   {1, 1500, 1800, 4000},
/* C5 */
-   {2500, 7500, 12000},
+   {1, 2500, 7500, 12000},
/* C6 */
-   {3000, 8500, 15000},
+   {1, 3000, 8500, 15000},
/* C7 */
-   {1, 3, 30},
+   {1, 1, 3, 30},
 };
 
 static int board_keymap[] = {
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 597148e..3d3d035 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -71,19 +71,19 @@ struct powerdomain *mpu_pd, *core_pd;
  */
 static struct cpuidle_params cpuidle_params_table[] = {
/* C1 */
-   {2, 2, 5},
+   {1, 2, 2, 5},
/* C2 */
-   {10, 10, 30},
+   {1, 10, 10, 30},
/* C3 */
-   {50, 50, 300},
+   {1, 50, 50, 300},
/* C4 */
-   {1500, 1800, 4000},
+   {1, 1500, 1800, 4000},
/* C5 */
-   {2500, 7500, 12000},
+   {1, 2500, 7500, 12000},
/* C6 */
-   {3000, 8500, 15000},
+   {1, 3000, 8500, 15000},
/* C7 */
-   {1, 3, 30},
+   {1, 1, 3, 30},
 };
 
 static int omap3_idle_bm_check(void)
@@ -277,6 +277,8 @@ void omap3_pm_init_cpuidle(struct cpuidle_params 
*cpuidle_board_params)
return;
 
for (i = OMAP3_STATE_C1; i  OMAP3_MAX_STATES; i++) {
+   cpuidle_params_table[i].valid =
+   cpuidle_board_params[i].valid;
cpuidle_params_table[i].sleep_latency =
cpuidle_board_params[i].sleep_latency;
cpuidle_params_table[i].wake_latency =
@@ -301,7 +303,8 @@ void omap3_pm_init_cpuidle(struct cpuidle_params 
*cpuidle_board_params)
 void omap_init_power_states(void)
 {
/* C1 . MPU WFI + Core active */
-   omap3_power_states[OMAP3_STATE_C1].valid = 1;
+   omap3_power_states[OMAP3_STATE_C1].valid =
+   cpuidle_params_table[OMAP3_STATE_C1].valid;
omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
omap3_power_states[OMAP3_STATE_C1].sleep_latency =
cpuidle_params_table[OMAP3_STATE_C1].sleep_latency;
@@ -314,7 +317,8 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
 
/* C2 . MPU WFI + Core inactive */
-   omap3_power_states[OMAP3_STATE_C2].valid = 1;
+   omap3_power_states[OMAP3_STATE_C2].valid =
+   cpuidle_params_table[OMAP3_STATE_C2].valid;
omap3_power_states[OMAP3_STATE_C2].type = OMAP3_STATE_C2;
omap3_power_states[OMAP3_STATE_C2].sleep_latency =
cpuidle_params_table[OMAP3_STATE_C2].sleep_latency;
@@ -327,7 +331,8 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID;
 
/* C3 . MPU CSWR + Core inactive */
-   omap3_power_states[OMAP3_STATE_C3].valid = 1;
+   omap3_power_states[OMAP3_STATE_C3].valid =
+   cpuidle_params_table[OMAP3_STATE_C3].valid;
omap3_power_states[OMAP3_STATE_C3].type = OMAP3_STATE_C3;
omap3_power_states[OMAP3_STATE_C3].sleep_latency =
cpuidle_params_table[OMAP3_STATE_C3].sleep_latency;
@@ -341,7 +346,8 @@ void omap_init_power_states(void)
CPUIDLE_FLAG_CHECK_BM;
 
/* C4 . MPU OFF + Core inactive */
-   omap3_power_states[OMAP3_STATE_C4].valid = 1;
+   omap3_power_states[OMAP3_STATE_C4].valid =
+   

[PATCH 2/7] OMAP3: cpuidle: configure latencies/thresholds from board file

[Kevin Hilman]

The CPUidle C state latencies and thresholds are dependent on various
board specific details.  This patch makes it possible to configure
these values from the respective board files.

omap3_pm_init_cpuidle() can now be optionally called from board files
to pass board specific cpuidle parameters.  If the board files do not
use this function to pass the params default values are used which
might cause higher consumption dur to wrong state selection by the
governor.

This patch only updates the 3430sdp board files to use
omap3_pm_init_cpuidle().

From Kalle, in addition to original patch from Rajendra:

Building without CONFIG_CPU_IDLE or CONFIG_PM causes build to fail if
cpu idle parameters are tried to pass using omap3_pm_init_cpuidle
function.

Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/board-3430sdp.c |   20 +++
 arch/arm/mach-omap2/cpuidle34xx.c   |  105 ---
 arch/arm/mach-omap2/pm.h|   15 +
 3 files changed, 119 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 5adef51..99f295e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,6 +46,7 @@
 #include mux.h
 #include sdram-qimonda-hyb18m512160af-6.h
 #include hsmmc.h
+#include pm.h
 
 #define CONFIG_DISABLE_HFCLK 1
 
@@ -57,6 +58,24 @@
 
 #define TWL4030_MSECURE_GPIO 22
 
+/* FIXME: These values need to be updated based on more profiling on 3430sdp*/
+static struct cpuidle_params omap3_cpuidle_params_table[] = {
+   /* C1 */
+   {2, 2, 5},
+   /* C2 */
+   {10, 10, 30},
+   /* C3 */
+   {50, 50, 300},
+   /* C4 */
+   {1500, 1800, 4000},
+   /* C5 */
+   {2500, 7500, 12000},
+   /* C6 */
+   {3000, 8500, 15000},
+   /* C7 */
+   {1, 3, 30},
+};
+
 static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -307,6 +326,7 @@ static void __init omap_3430sdp_init_irq(void)
 {
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+   omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
omap_gpio_init();
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index ff1ad3d..597148e 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -62,6 +62,30 @@ struct omap3_processor_cx 
omap3_power_states[OMAP3_MAX_STATES];
 struct omap3_processor_cx current_cx_state;
 struct powerdomain *mpu_pd, *core_pd;
 
+/*
+ * The latencies/thresholds for various C states have
+ * to be configured from the respective board files.
+ * These are some default values (which might not provide
+ * the best power savings) used on boards which do not
+ * pass these details from the board file.
+ */
+static struct cpuidle_params cpuidle_params_table[] = {
+   /* C1 */
+   {2, 2, 5},
+   /* C2 */
+   {10, 10, 30},
+   /* C3 */
+   {50, 50, 300},
+   /* C4 */
+   {1500, 1800, 4000},
+   /* C5 */
+   {2500, 7500, 12000},
+   /* C6 */
+   {3000, 8500, 15000},
+   /* C7 */
+   {1, 3, 30},
+};
+
 static int omap3_idle_bm_check(void)
 {
if (!omap3_can_sleep())
@@ -245,6 +269,24 @@ void omap3_cpuidle_update_states(void)
}
 }
 
+void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
+{
+   int i;
+
+   if (!cpuidle_board_params)
+   return;
+
+   for (i = OMAP3_STATE_C1; i  OMAP3_MAX_STATES; i++) {
+   cpuidle_params_table[i].sleep_latency =
+   cpuidle_board_params[i].sleep_latency;
+   cpuidle_params_table[i].wake_latency =
+   cpuidle_board_params[i].wake_latency;
+   cpuidle_params_table[i].threshold =
+   cpuidle_board_params[i].threshold;
+   }
+   return;
+}
+
 /* omap3_init_power_states - Initialises the OMAP3 specific C states.
  *
  * Below is the desciption of each C state.
@@ -261,9 +303,12 @@ void omap_init_power_states(void)
/* C1 . MPU WFI + Core active */
omap3_power_states[OMAP3_STATE_C1].valid = 1;
omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
-   omap3_power_states[OMAP3_STATE_C1].sleep_latency = 2;
-   omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 2;
-   omap3_power_states[OMAP3_STATE_C1].threshold = 5;
+   omap3_power_states[OMAP3_STATE_C1].sleep_latency =
+   cpuidle_params_table[OMAP3_STATE_C1].sleep_latency;
+   omap3_power_states[OMAP3_STATE_C1].wakeup_latency =
+   cpuidle_params_table[OMAP3_STATE_C1].wake_latency;
+   

[PATCH 7/7] OMAP3: PM: Added support for L2 aux ctrl register save and restore

[Kevin Hilman]

From: Tero Kristo tero.kri...@nokia.com

This patch adds a save and restore mechanism for ARM L2 auxiliary control
register. The feature is enabled by default for GP devices, but for HS/EMU
devices the user must enable the service and define the PPA service ID to
be used for setting L2 aux ctrl, as this is not currently supported by the
bootloader. If nobody alters the contents of L2 aux ctrl from its reset
value, this feature is not needed.

Kconfig option to enable HS/EMU L2 aux save and restore:
- OMAP3_L2_AUX_SECURE_SAVE_RESTORE
Kconfig option to select HS/EMU PPA service for setting L2 aux ctrl:
- OMAP3_L2_AUX_SECURE_SERVICE_SET_ID

Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/sleep34xx.S |   26 --
 arch/arm/plat-omap/Kconfig  |   17 +
 2 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 12a8ba0..d522cd7 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -284,6 +284,21 @@ restore:
mcr p15, 0, r0, c7, c10, 5  @ data memory barrier
.word   0xE1600071  @ call SMI monitor (smi #1)
 
+#ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+   /* Restore L2 aux control register */
+   @ set service ID for PPA
+   mov r0, #CONFIG_OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
+   mov r12, r0 @ copy service ID in r12
+   mov r1, #0  @ set task ID for ROM code in r1
+   mov r2, #4  @ set some flags in r2, r6
+   mov r6, #0xff
+   ldr r4, scratchpad_base
+   ldr r3, [r4, #0xBC]
+   addsr3, r3, #8  @ r3 points to parameters
+   mcr p15, 0, r0, c7, c10, 4  @ data write barrier
+   mcr p15, 0, r0, c7, c10, 5  @ data memory barrier
+   .word   0xE1600071  @ call SMI monitor (smi #1)
+#endif
b   logic_l1_restore
 l2_inv_api_params:
.word   0x1, 0x00
@@ -297,6 +312,11 @@ smi:.word 0xE1600070   @ Call SMI monitor 
(smieq)
ldr r0, [r3,#4]
mov r12, #0x3
.word 0xE1600070@ Call SMI monitor (smieq)
+   ldr r4, scratchpad_base
+   ldr r3, [r4,#0xBC]
+   ldr r0, [r3,#12]
+   mov r12, #0x2
+   .word 0xE1600070@ Call SMI monitor (smieq)
 logic_l1_restore:
mov r1, #0
/* Invalidate all instruction caches to PoU
@@ -305,7 +325,7 @@ logic_l1_restore:
 
ldr r4, scratchpad_base
ldr r3, [r4,#0xBC]
-   addsr3, r3, #8
+   addsr3, r3, #16
ldmia   r3!, {r4-r6}
mov sp, r4
msr spsr_cxsf, r5
@@ -424,7 +444,9 @@ save_context_wfi:
mov r8, r0 /* Store SDRAM address in r8 */
mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
mov r4, #0x1@ Number of parameters for restore call
-   stmia   r8!, {r4-r5}
+   stmia   r8!, {r4-r5}@ Push parameters for restore call
+   mrc p15, 1, r5, c9, c0, 2   @ Read L2 AUX ctrl register
+   stmia   r8!, {r4-r5}@ Push parameters for restore call
 /* Check what that target sleep state is:stored in r1*/
 /* 1 - Only L1 and logic lost */
 /* 2 - Only L2 lost */
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 97d0c79..be9484a 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -135,6 +135,23 @@ config OMAP_32K_TIMER
 
 endchoice
 
+config OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+   bool OMAP3 HS/EMU save and restore for L2 AUX control register
+   depends on ARCH_OMAP3  PM
+   default n
+   help
+ Without this option, L2 Auxiliary control register contents are
+ lost during off-mode entry on HS/EMU devices. This feature
+ requires support from PPA / boot-loader in HS/EMU devices, which
+ currently does not exist by default.
+
+config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
+   int Service ID for the support routine to set L2 AUX control
+   depends on OMAP3_L2_AUX_SECURE_SAVE_RESTORE
+   default 43
+   help
+ PPA routine service ID for setting L2 auxiliary control register.
+
 config OMAP_32K_TIMER_HZ
int Kernel internal timer frequency for 32KHz timer
range 32 1024
-- 
1.6.6

--
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 4/7] OMAP3: RX-51: support sleep indicator LEDs

[Kevin Hilman]

The sleep indicator LEDs can be enabled/disabled by toggling GPIO162.
Use the LED GPIO class to export this LED functionality to userspace.

To enable:

  # echo 1  /sys/class/leds/sleep_ind/brightness

To disable:

  # echo 0  /sys/class/leds/sleep_ind/brightness

Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/board-rx51.c |   25 +
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 6a49f91..26b70da 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -16,6 +16,7 @@
 #include linux/clk.h
 #include linux/io.h
 #include linux/gpio.h
+#include linux/leds.h
 
 #include mach/hardware.h
 #include asm/mach-types.h
@@ -31,8 +32,30 @@
 
 #include mux.h
 
+#define RX51_GPIO_SLEEP_IND 162
+
 struct omap_sdrc_params *rx51_get_sdram_timings(void);
 
+static struct gpio_led gpio_leds[] = {
+   {
+   .name   = sleep_ind,
+   .gpio   = RX51_GPIO_SLEEP_IND,
+   },
+};
+
+static struct gpio_led_platform_data gpio_led_info = {
+   .leds   = gpio_leds,
+   .num_leds   = ARRAY_SIZE(gpio_leds),
+};
+
+static struct platform_device leds_gpio = {
+   .name   = leds-gpio,
+   .id = -1,
+   .dev= {
+   .platform_data  = gpio_led_info,
+   },
+};
+
 static struct omap_lcd_config rx51_lcd_config = {
.ctrl_name  = internal,
 };
@@ -88,6 +111,8 @@ static void __init rx51_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
+
+   platform_device_register(leds_gpio);
 }
 
 static void __init rx51_map_io(void)
-- 
1.6.6

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

[PATCH 1/7] OMAP3: cpuidle: Update statistics for correct state

[Kevin Hilman]

From: Sanjeev Premi pr...@ti.com

When 'enable_off_mode' is 0, the target power state for MPU
and CORE was locally changed to PWRDM_POWER_RET but, the
statistics are updated for idle state originally selected
by the governor.

This patch 'invalidates' the idle states that lead either of
MPU or Core to PWRDM_POWER_OFF state when 'enable_off_mode'
is '0'. The states are valid once 'enable_off_mode' is set
to '1'.

Added function next_valid_state() to check if current state
is valid; else get the next valid state. It is called from
omap3_enter_idle_bm().

Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/cpuidle34xx.c |   98 ++---
 arch/arm/mach-omap2/pm.h  |4 ++
 arch/arm/mach-omap2/pm34xx.c  |4 ++
 3 files changed, 98 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 12f0cbf..ff1ad3d 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -45,6 +45,8 @@
 #define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core RET */
 #define OMAP3_STATE_C7 6 /* C7 - MPU OFF + Core OFF */
 
+#define OMAP3_STATE_MAX OMAP3_STATE_C7
+
 struct omap3_processor_cx {
u8 valid;
u8 type;
@@ -104,13 +106,6 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
local_fiq_disable();
 
-   if (!enable_off_mode) {
-   if (mpu_state  PWRDM_POWER_RET)
-   mpu_state = PWRDM_POWER_RET;
-   if (core_state  PWRDM_POWER_RET)
-   core_state = PWRDM_POWER_RET;
-   }
-
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
 
@@ -141,6 +136,67 @@ return_sleep_time:
 }
 
 /**
+ * next_valid_state - Find next valid c-state
+ * @dev: cpuidle device
+ * @state: Currently selected c-state
+ *
+ * If the current state is valid, it is returned back to the caller.
+ * Else, this function searches for a lower c-state which is still
+ * valid (as defined in omap3_power_states[]).
+ */
+static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev,
+   struct cpuidle_state *curr)
+{
+   struct cpuidle_state *next = NULL;
+   struct omap3_processor_cx *cx;
+
+   cx = (struct omap3_processor_cx *)cpuidle_get_statedata(curr);
+
+   /* Check if current state is valid */
+   if (cx-valid) {
+   return curr;
+   } else {
+   u8 idx = OMAP3_STATE_MAX;
+
+   /*
+* Reach the current state starting at highest C-state
+*/
+   for (; idx = OMAP3_STATE_C1; idx--) {
+   if (dev-states[idx] == curr) {
+   next = dev-states[idx];
+   break;
+   }
+   }
+
+   /*
+* Should never hit this condition.
+*/
+   WARN_ON(next == NULL);
+
+   /*
+* Drop to next valid state.
+* Start search from the next (lower) state.
+*/
+   idx--;
+   for (; idx = OMAP3_STATE_C1; idx--) {
+   struct omap3_processor_cx *cx;
+
+   cx = cpuidle_get_statedata(dev-states[idx]);
+   if (cx-valid) {
+   next = dev-states[idx];
+   break;
+   }
+   }
+   /*
+* C1 and C2 are always valid.
+* So, no need to check for 'next==NULL' outside this loop.
+*/
+   }
+
+   return next;
+}
+
+/**
  * omap3_enter_idle_bm - Checks for any bus activity
  * @dev: cpuidle device
  * @state: The target state to be programmed
@@ -152,7 +208,7 @@ return_sleep_time:
 static int omap3_enter_idle_bm(struct cpuidle_device *dev,
   struct cpuidle_state *state)
 {
-   struct cpuidle_state *new_state = state;
+   struct cpuidle_state *new_state = next_valid_state(dev, state);
 
if ((state-flags  CPUIDLE_FLAG_CHECK_BM)  omap3_idle_bm_check()) {
BUG_ON(!dev-safe_state);
@@ -165,6 +221,30 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 
 DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 
+/**
+ * omap3_cpuidle_update_states - Update the cpuidle states.
+ *
+ * Currently, this function toggles the validity of idle states based upon
+ * the flag 'enable_off_mode'. When the flag is set all states are valid.
+ * Else, states leading to OFF state set to be invalid.
+ */
+void omap3_cpuidle_update_states(void)
+{
+   int i;
+
+   for (i = OMAP3_STATE_C1; i  OMAP3_MAX_STATES; i++) {
+   struct omap3_processor_cx *cx = omap3_power_states[i];
+
+  

[PATCH 5/7] OMAP3: RX-51: Pass cpu idle parameters

[Kevin Hilman]

From: Kalle Jokiniemi kalle.jokini...@digia.com

Pass cpuidle parameters for RX-51. Numbers based on
measurements made in October 2009 for PM optimized
kernel with CPU freq enabled. Assumes OPP2 (main
idle OPP, and worst case latencies).

Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/board-rx51.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 26b70da..acfb898 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -31,6 +31,7 @@
 #include plat/usb.h
 
 #include mux.h
+#include pm.h
 
 #define RX51_GPIO_SLEEP_IND 162
 
@@ -56,6 +57,23 @@ static struct platform_device leds_gpio = {
},
 };
 
+static struct cpuidle_params rx51_cpuidle_params[] = {
+   /* C1 */
+   {1, 110, 162, 5},
+   /* C2 */
+   {1, 106, 180, 309},
+   /* C3 */
+   {0, 107, 410, 46057},
+   /* C4 */
+   {0, 121, 3374, 46057},
+   /* C5 */
+   {1, 855, 1146, 46057},
+   /* C6 */
+   {0, 7580, 4134, 484329},
+   /* C7 */
+   {1, 7505, 15274, 484329},
+};
+
 static struct omap_lcd_config rx51_lcd_config = {
.ctrl_name  = internal,
 };
@@ -85,6 +103,7 @@ static void __init rx51_init_irq(void)
 
omap_board_config = rx51_config;
omap_board_config_size = ARRAY_SIZE(rx51_config);
+   omap3_pm_init_cpuidle(rx51_cpuidle_params);
sdrc_params = rx51_get_sdram_timings();
omap2_init_common_hw(sdrc_params, sdrc_params);
omap_init_irq();
-- 
1.6.6

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

[PATCH 6/7] OMAP3: PM: add scratchpad locking function

[Kevin Hilman]

From: Rajendra Nayak rna...@ti.com

This patch implements locking using the semaphore in scratchpad
memory preventing any concurrent access to scratchpad from OMAP
and Baseband/Modem processor.

Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/sleep34xx.S |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 22fcc14..12a8ba0 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -33,6 +33,8 @@
 #include prm.h
 #include sdrc.h
 
+#define SDRC_SCRATCHPAD_SEM_V  0xfa00291c
+
 #define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \
OMAP3430_PM_PREPWSTST)
 #define PM_PREPWSTST_CORE_P0x48306AE8
@@ -57,6 +59,37 @@
 #define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
 #define SDRC_DLLA_CTRL_V   OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
 
+.text
+/* Function to aquire the semaphore in scratchpad */
+ENTRY(lock_scratchpad_sem)
+   stmfd   sp!, {lr}   @ save registers on stack
+wait_sem:
+   mov r0,#1
+   ldr r1, sdrc_scratchpad_sem
+wait_loop:
+   ldr r2, [r1]@ load the lock value
+   cmp r2, r0  @ is the lock free ?
+   beq wait_loop   @ not free...
+   swp r2, r0, [r1]@ semaphore free so lock it and proceed
+   cmp r2, r0  @ did we succeed ?
+   beq wait_sem@ no - try again
+   ldmfd   sp!, {pc}   @ restore regs and return
+sdrc_scratchpad_sem:
+.word SDRC_SCRATCHPAD_SEM_V
+ENTRY(lock_scratchpad_sem_sz)
+.word   . - lock_scratchpad_sem
+
+.text
+/* Function to release the scratchpad semaphore */
+ENTRY(unlock_scratchpad_sem)
+   stmfd   sp!, {lr}   @ save registers on stack
+   ldr r3, sdrc_scratchpad_sem
+   mov r2,#0
+   str r2,[r3]
+   ldmfd   sp!, {pc}   @ restore regs and return
+ENTRY(unlock_scratchpad_sem_sz)
+.word   . - unlock_scratchpad_sem
+
.text
 /* Function call to get the restore pointer for resume from OFF */
 ENTRY(get_restore_pointer)
-- 
1.6.6

--
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 1/2] McBSP: OMAP3: Add sidetone feature

[Tony Lindgren]

* Ilkka Koskinen ilkka.koski...@nokia.com [100217 06:41]:
 From: Eero Nurkkala ext-eero.nurkk...@nokia.com
 
 Add sidetone feature to McBSP instances 2 and 3 on OMAP3 based devices.
 
 Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com

This one looks good to me and can be merged via Alsa list along with
the other patch.

Acked-by: Tony Lindgren t...@atomide.com


 ---
  arch/arm/mach-omap2/mcbsp.c |2 +
  arch/arm/plat-omap/include/plat/mcbsp.h |   63 +
  arch/arm/plat-omap/mcbsp.c  |  396 
 ++-
  3 files changed, 460 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
 index d601f94..be8fce3 100644
 --- a/arch/arm/mach-omap2/mcbsp.c
 +++ b/arch/arm/mach-omap2/mcbsp.c
 @@ -136,6 +136,7 @@ static struct omap_mcbsp_platform_data 
 omap34xx_mcbsp_pdata[] = {
   },
   {
   .phys_base  = OMAP34XX_MCBSP2_BASE,
 + .phys_base_st   = OMAP34XX_MCBSP2_ST_BASE,
   .dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
   .dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
   .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
 @@ -145,6 +146,7 @@ static struct omap_mcbsp_platform_data 
 omap34xx_mcbsp_pdata[] = {
   },
   {
   .phys_base  = OMAP34XX_MCBSP3_BASE,
 + .phys_base_st   = OMAP34XX_MCBSP3_ST_BASE,
   .dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
   .dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
   .rx_irq = INT_24XX_MCBSP3_IRQ_RX,
 diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h 
 b/arch/arm/plat-omap/include/plat/mcbsp.h
 index 4df957b..5db1653 100644
 --- a/arch/arm/plat-omap/include/plat/mcbsp.h
 +++ b/arch/arm/plat-omap/include/plat/mcbsp.h
 @@ -49,6 +49,9 @@
  
  #define OMAP34XX_MCBSP1_BASE 0x48074000
  #define OMAP34XX_MCBSP2_BASE 0x49022000
 +#define OMAP34XX_MCBSP2_ST_BASE  0x49028000
 +#define OMAP34XX_MCBSP3_BASE 0x49024000
 +#define OMAP34XX_MCBSP3_ST_BASE  0x4902A000
  #define OMAP34XX_MCBSP3_BASE 0x49024000
  #define OMAP34XX_MCBSP4_BASE 0x49026000
  #define OMAP34XX_MCBSP5_BASE 0x48096000
 @@ -146,6 +149,15 @@
  #define OMAP_MCBSP_REG_WAKEUPEN  0xA8
  #define OMAP_MCBSP_REG_XCCR  0xAC
  #define OMAP_MCBSP_REG_RCCR  0xB0
 +#define OMAP_MCBSP_REG_SSELCR0xBC
 +
 +#define OMAP_ST_REG_REV  0x00
 +#define OMAP_ST_REG_SYSCONFIG0x10
 +#define OMAP_ST_REG_IRQSTATUS0x18
 +#define OMAP_ST_REG_IRQENABLE0x1C
 +#define OMAP_ST_REG_SGAINCR  0x24
 +#define OMAP_ST_REG_SFIRCR   0x28
 +#define OMAP_ST_REG_SSELCR   0x2C
  
  #define AUDIO_MCBSP_DATAWRITE(OMAP24XX_MCBSP2_BASE + 
 OMAP_MCBSP_REG_DXR1)
  #define AUDIO_MCBSP_DATAREAD (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1)
 @@ -264,6 +276,24 @@
  #define ENAWAKEUP0x0004
  #define SOFTRST  0x0002
  
 +/** McBSP SSELCR bit definitions ***/
 +#define SIDETONEEN   0x0400
 +
 +/** McBSP Sidetone SYSCONFIG bit definitions ***/
 +#define ST_AUTOIDLE  0x0001
 +
 +/** McBSP Sidetone SGAINCR bit definitions */
 +#define ST_CH1GAIN(value)((value16))   /* Bits 16:31 */
 +#define ST_CH0GAIN(value)(value) /* Bits 0:15 */
 +
 +/** McBSP Sidetone SFIRCR bit definitions **/
 +#define ST_FIRCOEFF(value)   (value) /* Bits 0:15 */
 +
 +/** McBSP Sidetone SSELCR bit definitions **/
 +#define ST_COEFFWRDONE   0x0004
 +#define ST_COEFFWREN 0x0002
 +#define ST_SIDETONEEN0x0001
 +
  /** McBSP DMA operating modes **/
  #define MCBSP_DMA_MODE_ELEMENT   0
  #define MCBSP_DMA_MODE_THRESHOLD 1
 @@ -374,10 +404,25 @@ struct omap_mcbsp_platform_data {
   u16 rx_irq, tx_irq;
   struct omap_mcbsp_ops *ops;
  #ifdef CONFIG_ARCH_OMAP3
 + /* Sidetone block for McBSP 2 and 3 */
 + unsigned long phys_base_st;
   u16 buffer_size;
  #endif
  };
  
 +#define OMAP_MCBSP_ST_CHANNEL_0 (1  0)
 +#define OMAP_MCBSP_ST_CHANNEL_1 (1  1)
 +
 +struct omap_mcbsp_st_data {
 + void __iomem *io_base_st;
 + bool running;
 + bool enabled;
 + s16 taps[128];  /* Sidetone filter coefficients */
 + int nr_taps;/* Number of filter coefficients in use */
 + s16 ch0gain;
 + s16 ch1gain;
 +};
 +
  struct omap_mcbsp {
   struct device *dev;
   unsigned long phys_base;
 @@ -410,6 +455,7 @@ struct omap_mcbsp {
   struct clk *iclk;
   struct clk *fclk;
  #ifdef CONFIG_ARCH_OMAP3
 + struct omap_mcbsp_st_data *st_data;
   int dma_op_mode;
   u16 max_tx_thres;
   u16 max_rx_thres;
 @@ -459,4 +505,21 @@ int omap_mcbsp_pollread(unsigned int id, u16 * buf);
  int omap_mcbsp_pollwrite(unsigned int id, u16 buf);
  int 

RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts

[Madhusudhan]

 -Original Message-
 From: David Vrabel [mailto:david.vra...@csr.com]
 Sent: Wednesday, February 17, 2010 1:40 PM
 To: Madhusudhan
 Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
 Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
 
 Madhusudhan wrote:
 
  -Original Message-
  From: David Vrabel [mailto:david.vra...@csr.com]
  Sent: Wednesday, February 10, 2010 5:52 AM
  To: linux-...@vger.kernel.org
  Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
  Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
 
  Enable the use of SDIO card interrupts.  This requires setting
 ENAWAKEUP
  in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
  smart-idle mode.
 
  FCLK must be enabled while SDIO interrupts are enabled or the MMC block
  won't wake-up.
 
 
  I am curious to know the system behavior with this patch. Does the FCLK
  remain enabled forever if a SDIO card is detected on the bus?
 
 Only if card interrupts are enabled.  The card irq is disabled when the
 sdio_irq_thread exits.
 

Your patch sets up the capability to enable sdio irqs anyway. My question
was more related to the idle path. In a scenario where you start using the
SDIO functionality and after some time you leave the SDIO card idle, does
the FCLK still remain enabled? Or do you see that sdio_irq_thread exits and
disables the FCLK?

Regards,
Madhu


 This is why I think that smart-idle mode needs to be used (it's turned
 on by default on the MMC controller) but I don't understand the
 clock/clockdomain code to see if that's doing the right thing.
 
 If smart-idle mode is used then we don't need to disable FCLK manually
 to save power.  This will simplify the driver a bit.
 
 David

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

Re: [PATCH v2 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'

[Tony Lindgren]

* Vimal Singh vimal.neww...@gmail.com [100213 01:40]:
 On Fri, Feb 12, 2010 at 2:49 AM, Tony Lindgren t...@atomide.com wrote:
  * Tony Lindgren t...@atomide.com [100211 12:43]:
  * Vimal Singh vimal.neww...@gmail.com [100210 21:16]:
   From: Vimal Singh vimalsi...@ti.com
  
   This patch adds 'board-zoom-flash.c', which could be utilized
   by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
  
   This does initialization for NAND device based on the 'cs' number
   and partition information passed from board file (ex: board-zoom2.c).
  
   Signed-off-by: Vimal Singh vimalsi...@ti.com
   ---
    arch/arm/mach-omap2/board-zoom-flash.c        |   85 
   +
    arch/arm/mach-omap2/include/mach/board-zoom.h |   11 +++
    2 files changed, 96 insertions(+), 0 deletions(-)
    create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
  
   diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
   b/arch/arm/mach-omap2/board-zoom-flash.c
   new file mode 100644
   index 000..f2328a4
   --- /dev/null
   +++ b/arch/arm/mach-omap2/board-zoom-flash.c
   @@ -0,0 +1,85 @@
   +/*
   + * board-zoom-flash.c
   + *
   + * Copyright (C) 2009 Texas Instruments Inc.
   + * Vimal Singh vimalsi...@ti.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.
   + */
   +
   +#include linux/kernel.h
   +#include linux/delay.h
   +#include linux/platform_device.h
   +#include linux/mtd/nand.h
   +#include linux/types.h
   +#include linux/io.h
   +
   +#include asm/mach/flash.h
   +#include plat/board.h
   +#include plat/gpmc.h
   +#include plat/nand.h
   +
   +#include mach/board-zoom.h
   +
   +#if defined(CONFIG_MTD_NAND_OMAP2) || \
   +           defined(CONFIG_MTD_NAND_OMAP2_MODULE)
   +
   +/* Note that all values in this struct are in nanoseconds */
   +static struct gpmc_timings nand_timings = {
   +
   +   .sync_clk = 0,
   +
   +   .cs_on = 0,
   +   .cs_rd_off = 36,
   +   .cs_wr_off = 36,
   +
   +   .adv_on = 6,
   +   .adv_rd_off = 24,
   +   .adv_wr_off = 36,
   +
   +   .we_off = 30,
   +   .oe_off = 48,
   +
   +   .access = 54,
   +   .rd_cycle = 72,
   +   .wr_cycle = 72,
   +
   +   .wr_access = 30,
   +   .wr_data_mux_bus = 0,
   +};
   +
   +/* NAND chip access: 16 bit */
   +static struct omap_nand_platform_data zoom_nand_data = {
   +   .nand_setup     = NULL,
   +   .gpmc_t         = nand_timings,
   +   .dma_channel    = -1,   /* disable DMA in OMAP NAND driver */
   +   .dev_ready      = NULL,
   +   .devsize        = 1,    /* '0' for 8-bit, '1' for 16-bit device */
   +};
   +
   +/**
   + * zoom_flash_init - Identify devices connected to GPMC and register.
   + *
   + * @return - void.
   + */
   +void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], 
   int cs)
   +{
   +   u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
   +
   +   zoom_nand_data.cs               = cs;
   +   zoom_nand_data.parts            = zoom_nand_parts[0].parts;
   +   zoom_nand_data.nr_parts         = zoom_nand_parts[0].nr_parts;
   +   zoom_nand_data.gpmc_baseaddr    = (void *)(gpmc_base_add);
   +   zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
   +                                           GPMC_CS0_BASE +
   +                                           cs * GPMC_CS_SIZE);
 
  The gpmc_baseaddr and gpmc_cs_baseaddr should no longer be
  needed with gpmc-nand.c, right?
 
 As said earlier too these are needed by 'nand/omap2.c' driver not for
 gpmc.-nand.c, we still need to pass these.

Right..
 
 
  Yeah.. For now, I suggest you set the gpmc_baseaddr and
  gpmc_cs_baseaddr in gpmc_nand_init() based on the results from
  gpmc_cs_request.
 
  That will allow us to remove the insane hardcoded gpmc virtual
  addresses from all board-*.c files.
 
 OK

This change you can already make without changing the driver.
 
 
  And then we can finally fix gpmc-nand.c driver not to go tinker
 You mean omap2.c nand driver?
 
  with the GPMC registers directly. All of that should be in
  gpmc-nand.c using gpmc.c. The driver should be just a generic
  NAND driver.
 
 Yes, but that will take complete clean-up of omap2.c nand driver by
 moving all functions accessing GPMC registers from 'nand/omap2.c' to
 'gpmc-nand.c'. And we can take that work later.
 Once everything is working fine and is at proper place, clean-up will
 have more visibility.
 
 IMHO, you can still take patches for now. As, this is how already done
 for sdp boards too.

I'd rather get things fixed rather than merge obviously broken stuff.

The thing is that unless it's fixed to start with, nobody bothers to
fix it afterwards and then I need to deal with cleaning up the mess.

Regards,

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

[APPLIED] [PATCH 2/2-V3] AM3517: Enable I2C-GPIO Expander driver support for

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: for-next

Initial commit ID (Likely to change): 0a7253bced4bfabeeaad1d12cffdf4ad096a4792

PatchWorks
http://patchwork.kernel.org/patch/79181/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0a7253bced4bfabeeaad1d12cffdf4ad096a4792


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

[APPLIED] [PATCH 1/2] IGEPv2: Added WIFI support

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: for-next

Initial commit ID (Likely to change): ca634ecdd562e6e6dd647859ce3037b6261b51d5

PatchWorks
http://patchwork.kernel.org/patch/79312/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ca634ecdd562e6e6dd647859ce3037b6261b51d5


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

[APPLIED] [PATCH 2/2] IGEPv2: Use Red Led1 as Heartbeat if configured

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: for-next

Initial commit ID (Likely to change): 85ac89e2c373f6eef4908accf6afd5cbe2cd7c96

PatchWorks
http://patchwork.kernel.org/patch/79313/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=85ac89e2c373f6eef4908accf6afd5cbe2cd7c96


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

[APPLIED] [PATCHv2] OMAP3EVM: PM: Update defconfig

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: for-next

Initial commit ID (Likely to change): aec0adeb2fc250cfa66919adbc0a03a0b4634700

PatchWorks
http://patchwork.kernel.org/patch/79950/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=aec0adeb2fc250cfa66919adbc0a03a0b4634700


--
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 5/6] Mailbox: sleeping function called from invalid context fix

[Tony Lindgren]

* Guzman Lugo, Fernando x0095...@ti.com [100215 23:22]:
 
 Hi,
 
 -Original Message-
 From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
 Sent: Monday, February 15, 2010 7:49 AM
 To: Guzman Lugo, Fernando
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid
 context fix
 
 Hi Fernando,
 
 From: ext Guzman Lugo, Fernando x0095...@ti.com
 Subject: [PATCH 5/6] Mailbox: sleeping function called from invalid context
 fix
 Date: Sat, 13 Feb 2010 02:42:16 +0100
 
  From e06b2716824f225747c4dc83ed2623d0160ae132 Mon Sep 17 00:00:00 2001
  From: Fernando Guzman Lugo x0095...@ti.com
  Date: Fri, 29 Jan 2010 17:12:24 -0600
  Subject: [PATCH] Mailbox: sleeping function called from invalid context
 fix
 
  This patch fixes this bug:
  BUG: sleeping function called from invalid context
  Inside omap2_mbox_startup is called clk_get_sys that can sleep,
  therefore omap2_mbox_startup can sleep but it is call in an atomic
  context . So the spinlock is change for a semaphore.
 
 mboxes_lock is used to maintain the global list of mailbox
 instances, which belong to a single mailbox H/W module, but they are
 logical channels from S/W perspective. Both -ops-startup() and
 -ops-shutdown() are being executed against the above single H/W
 module, and a mailbox H/W module is totally __independent__ of the
 registration of logical mailboxes, which are (un)registered with
 
 Yes, they are independent of each other, and can be executed at the same 
 time. I am agreed with your patch; that should be the right solution, so you 
 can drop my patch.

Hiroshi  Fernando, if you want me to merge this series, please post
it one more time with right patches and ack's from Hiroshi. Please
Cc also linux-arm-kernel so it gets reviewed there. The merge window
is about to open, so we're running out of time..

Regards,

Tony


 
 Thanks and regards,
 Fernando.
 
 omap_mbox_(un)register(). IOW, a mbox instance can be registered at
 anytime(before/after) H/W initialization. This H/W initialization is
 taken care of by mbox_configured variable. So I might think that the
 right solution is to introduce a new mutex lock __just for__ h/w
 configuration as below:
 
  Modified arch/arm/plat-omap/mailbox.c
 diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
 index 8e90633..19530de 100644
 --- a/arch/arm/plat-omap/mailbox.c
 +++ b/arch/arm/plat-omap/mailbox.c
 @@ -32,6 +32,7 @@ static struct omap_mbox *mboxes;
  static DEFINE_RWLOCK(mboxes_lock);
 
  static int mbox_configured;
 +static DEFINE_MUTEX(mbox_configured_lock);
 
  /* Mailbox FIFO handle functions */
  static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
 @@ -247,16 +248,16 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
  struct omap_mbox_queue *mq;
 
  if (likely(mbox-ops-startup)) {
 -write_lock(mboxes_lock);
 +mutex_lock(mbox_configured_lock);
  if (!mbox_configured)
  ret = mbox-ops-startup(mbox);
 
  if (unlikely(ret)) {
 -write_unlock(mboxes_lock);
 +mutex_unlock(mbox_configured_lock);
  return ret;
  }
  mbox_configured++;
 -write_unlock(mboxes_lock);
 +mutex_unlock(mbox_configured_lock);
  }
 
  ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
 @@ -302,12 +303,12 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
  free_irq(mbox-irq, mbox);
 
  if (unlikely(mbox-ops-shutdown)) {
 -write_lock(mboxes_lock);
 +mutex_lock(mbox_configured_lock);
  if (mbox_configured  0)
  mbox_configured--;
  if (!mbox_configured)
  mbox-ops-shutdown(mbox);
 -write_unlock(mboxes_lock);
 +mutex_unlock(mbox_configured_lock);
  }
  }
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/23] omap updates for 2.6.34, part 3

[Tony Lindgren]

Hi all,

Sorry, was meaning to post these last week alread..

Here are the omap board-*.c file changes for review.

Regards,

Tony

---

Enric Balletbo i Serra (8):
  omap3: Add platform data for the twl4030_codec MFD on IGEP v2
  omap3: Fix typo on IGEP v2 board
  omap3: Add platform init code for EHCI driver on IGEP v2
  omap3: Enable DSS2 for IGEP v2 board
  omap3: Add support for flash on IGEP v2 board
  ARM: OMAP3: SDRC: add timing data for Numonyx M65KAM
  omap3: Use timing data for omap2_init_common_hw on IGEP v2
  omap3: Update defconfig for IGEP v2 to allow new drivers andfeatures

Grazvydas Ignotas (3):
  OMAP: pandora: add DSS2 support and related regulators
  omap3: pandora: update regulator setup
  omap3: pandora: update defconfig

Jonas Zetterberg (2):
  IGEPv2: Added WIFI support
  IGEPv2: Use Red Led1 as Heartbeat if configured

Sanjeev Premi (4):
  omap3evm: Add mux settings for keypad
  omap3evm: Fixes after moving to matrix_keypad
  omap3evm: Configure GPIO175 for touchscreen PEN_IRQ
  OMAP3EVM: PM: Update defconfig

Thomas Weber (2):
  Add minimal support for DevKit8000
  Add devkit8000_defconfig

Vaibhav Hiremath (3):
  AM3517: Enable basic I2C Support
  AM3517: Enable RTC driver support for AM3517EVM
  AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM

vikram pandita (1):
  omap: zoom3: enable ehci support


 arch/arm/configs/devkit8000_defconfig  | 1889 
 arch/arm/configs/igep0020_defconfig|  525 ---
 arch/arm/configs/omap3_evm_defconfig   |6 
 arch/arm/configs/omap3_pandora_defconfig   |  678 +++--
 arch/arm/mach-omap2/Kconfig|6 
 arch/arm/mach-omap2/Makefile   |2 
 arch/arm/mach-omap2/board-am3517evm.c  |   86 +
 arch/arm/mach-omap2/board-devkit8000.c |  691 +
 arch/arm/mach-omap2/board-igep0020.c   |  269 +++
 arch/arm/mach-omap2/board-omap3evm.c   |   33 
 arch/arm/mach-omap2/board-omap3pandora.c   |  180 ++
 arch/arm/mach-omap2/board-zoom3.c  |   14 
 arch/arm/mach-omap2/sdram-numonyx-m65kam.h |   51 +
 13 files changed, 4020 insertions(+), 410 deletions(-)
 create mode 100644 arch/arm/configs/devkit8000_defconfig
 create mode 100644 arch/arm/mach-omap2/board-devkit8000.c
 create mode 100644 arch/arm/mach-omap2/sdram-numonyx-m65kam.h

-- 
Signature
--
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 00/23] Series short description

[Tony Lindgren]

Hi all,

Looks like stg mail choked on a bad email addres, here's a retry.

These patches are against what I have sitting in omap-for-linus
branch in the linux-omap tree.

Regards,

Tony

---

Enric Balletbo i Serra (8):
  omap3: Add platform data for the twl4030_codec MFD on IGEP v2
  omap3: Fix typo on IGEP v2 board
  omap3: Add platform init code for EHCI driver on IGEP v2
  omap3: Enable DSS2 for IGEP v2 board
  omap3: Add support for flash on IGEP v2 board
  ARM: OMAP3: SDRC: add timing data for Numonyx M65KAM
  omap3: Use timing data for omap2_init_common_hw on IGEP v2
  omap3: Update defconfig for IGEP v2 to allow new drivers andfeatures

Grazvydas Ignotas (3):
  OMAP: pandora: add DSS2 support and related regulators
  omap3: pandora: update regulator setup
  omap3: pandora: update defconfig

Jonas Zetterberg (2):
  IGEPv2: Added WIFI support
  IGEPv2: Use Red Led1 as Heartbeat if configured

Sanjeev Premi (4):
  omap3evm: Add mux settings for keypad
  omap3evm: Fixes after moving to matrix_keypad
  omap3evm: Configure GPIO175 for touchscreen PEN_IRQ
  OMAP3EVM: PM: Update defconfig

Thomas Weber (2):
  Add minimal support for DevKit8000
  Add devkit8000_defconfig

Vaibhav Hiremath (3):
  AM3517: Enable basic I2C Support
  AM3517: Enable RTC driver support for AM3517EVM
  AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM

vikram pandita (1):
  omap: zoom3: enable ehci support


 arch/arm/configs/devkit8000_defconfig  | 1889 
 arch/arm/configs/igep0020_defconfig|  525 ---
 arch/arm/configs/omap3_evm_defconfig   |6 
 arch/arm/configs/omap3_pandora_defconfig   |  678 +++--
 arch/arm/mach-omap2/Kconfig|6 
 arch/arm/mach-omap2/Makefile   |2 
 arch/arm/mach-omap2/board-am3517evm.c  |   86 +
 arch/arm/mach-omap2/board-devkit8000.c |  691 +
 arch/arm/mach-omap2/board-igep0020.c   |  269 +++
 arch/arm/mach-omap2/board-omap3evm.c   |   33 
 arch/arm/mach-omap2/board-omap3pandora.c   |  180 ++
 arch/arm/mach-omap2/board-zoom3.c  |   14 
 arch/arm/mach-omap2/sdram-numonyx-m65kam.h |   51 +
 13 files changed, 4020 insertions(+), 410 deletions(-)
 create mode 100644 arch/arm/configs/devkit8000_defconfig
 create mode 100644 arch/arm/mach-omap2/board-devkit8000.c
 create mode 100644 arch/arm/mach-omap2/sdram-numonyx-m65kam.h

-- 
Signature
--
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 01/23] omap: zoom3: enable ehci support

[Tony Lindgren]

From: vikram pandita vikram.pand...@ti.com

Zoom3 board has omap3630 EHCI port2 connected to a ULPI phy.
GPIO_64 is connected to the PHY reset pin.

Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-zoom3.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom3.c 
b/arch/arm/mach-omap2/board-zoom3.c
index 5e20894..d3e3cd5 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -20,6 +20,7 @@
 
 #include plat/common.h
 #include plat/board.h
+#include plat/usb.h
 
 #include mux.h
 #include sdram-hynix-h8mbx00u0mer-0em.h
@@ -51,11 +52,24 @@ static struct omap_board_mux board_mux[] __initdata = {
 #define board_mux  NULL
 #endif
 
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+   .port_mode[0]   = EHCI_HCD_OMAP_MODE_UNKNOWN,
+   .port_mode[1]   = EHCI_HCD_OMAP_MODE_PHY,
+   .port_mode[2]   = EHCI_HCD_OMAP_MODE_UNKNOWN,
+   .phy_reset  = true,
+   .reset_gpio_port[0] = -EINVAL,
+   .reset_gpio_port[1] = 64,
+   .reset_gpio_port[2] = -EINVAL,
+};
+
 static void __init omap_zoom_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
zoom_debugboard_init();
+
+   omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+   usb_ehci_init(ehci_pdata);
 }
 
 MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board)

--
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 02/23] omap3evm: Add mux settings for keypad

[Tony Lindgren]

From: Sanjeev Premi pr...@ti.com

This patch sets SYS_NIRQ for keypad input. It also
sets the same as a wakeup event from OFF mode.

Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-omap3evm.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 45227f3..3b473cf 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -647,6 +647,10 @@ static struct ehci_hcd_omap_platform_data ehci_pdata 
__initconst = {
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
+   OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
+   OMAP_PIN_OFF_INPUT_PULLUP |
+   OMAP_PIN_OFF_WAKEUPENABLE),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else

--
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 03/23] omap3evm: Fixes after moving to matrix_keypad

[Tony Lindgren]

From: Sanjeev Premi pr...@ti.com

The keypad was not working properly after migrating
to matrix_keypad.

Swapped the row, col fields of the KEY() macro in
the keymap definition to get it working again.

Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-omap3evm.c |   27 +++
 1 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 3b473cf..34655a6 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -448,20 +448,23 @@ static struct twl4030_usb_data omap3evm_usb_data = {
 
 static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
-   KEY(0, 1, KEY_RIGHT),
-   KEY(0, 2, KEY_A),
-   KEY(0, 3, KEY_B),
-   KEY(1, 0, KEY_DOWN),
+   KEY(0, 1, KEY_DOWN),
+   KEY(0, 2, KEY_ENTER),
+   KEY(0, 3, KEY_M),
+
+   KEY(1, 0, KEY_RIGHT),
KEY(1, 1, KEY_UP),
-   KEY(1, 2, KEY_E),
-   KEY(1, 3, KEY_F),
-   KEY(2, 0, KEY_ENTER),
-   KEY(2, 1, KEY_I),
+   KEY(1, 2, KEY_I),
+   KEY(1, 3, KEY_N),
+
+   KEY(2, 0, KEY_A),
+   KEY(2, 1, KEY_E),
KEY(2, 2, KEY_J),
-   KEY(2, 3, KEY_K),
-   KEY(3, 0, KEY_M),
-   KEY(3, 1, KEY_N),
-   KEY(3, 2, KEY_O),
+   KEY(2, 3, KEY_O),
+
+   KEY(3, 0, KEY_B),
+   KEY(3, 1, KEY_F),
+   KEY(3, 2, KEY_K),
KEY(3, 3, KEY_P)
 };
 

--
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 05/23] OMAP: pandora: add DSS2 support and related regulators

[Tony Lindgren]

From: Grazvydas Ignotas nota...@gmail.com

This patch adds configuration data for DSS2 and sets up
display related regulators.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Acked-by: Tomi Valkeinen tomi.valkei...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-omap3pandora.c |  111 ++
 1 files changed, 111 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index 9967b5d..7ea3894 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -40,6 +40,7 @@
 #include mach/hardware.h
 #include plat/mcspi.h
 #include plat/usb.h
+#include plat/display.h
 
 #include mux.h
 #include sdram-micron-mt46h32m32lf-6.h
@@ -192,6 +193,61 @@ static struct twl4030_keypad_data pandora_kp_data = {
.rep= 1,
 };
 
+static struct omap_dss_device pandora_lcd_device = {
+   .name   = lcd,
+   .driver_name= tpo_td043mtea1_panel,
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 24,
+   .reset_gpio = 157,
+};
+
+static struct omap_dss_device pandora_tv_device = {
+   .name   = tv,
+   .driver_name= venc,
+   .type   = OMAP_DISPLAY_TYPE_VENC,
+   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static struct omap_dss_device *pandora_dss_devices[] = {
+   pandora_lcd_device,
+   pandora_tv_device,
+};
+
+static struct omap_dss_board_info pandora_dss_data = {
+   .num_devices= ARRAY_SIZE(pandora_dss_devices),
+   .devices= pandora_dss_devices,
+   .default_device = pandora_lcd_device,
+};
+
+static struct platform_device pandora_dss_device = {
+   .name   = omapdss,
+   .id = -1,
+   .dev= {
+   .platform_data = pandora_dss_data,
+   },
+};
+
+static struct regulator_consumer_supply pandora_vcc_lcd_supply = {
+   .supply = vcc,
+   .dev= pandora_lcd_device.dev,
+};
+
+static struct regulator_consumer_supply pandora_vdda_dac_supply = {
+   .supply = vdda_dac,
+   .dev= pandora_dss_device.dev,
+};
+
+static struct regulator_consumer_supply pandora_vdds_supplies[] = {
+   {
+   .supply = vdds_sdi,
+   .dev= pandora_dss_device.dev,
+   },
+   {
+   .supply = vdds_dsi,
+   .dev= pandora_dss_device.dev,
+   },
+};
+
 static struct omap2_hsmmc_info omap3pandora_mmc[] = {
{
.mmc= 1,
@@ -277,6 +333,51 @@ static struct regulator_init_data pandora_vmmc2 = {
.consumer_supplies  = pandora_vmmc2_supply,
 };
 
+/* VDAC for DSS driving S-Video */
+static struct regulator_init_data pandora_vdac = {
+   .constraints = {
+   .min_uV = 180,
+   .max_uV = 180,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = 1,
+   .consumer_supplies  = pandora_vdda_dac_supply,
+};
+
+/* VPLL2 for digital video outputs */
+static struct regulator_init_data pandora_vpll2 = {
+   .constraints = {
+   .min_uV = 180,
+   .max_uV = 180,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(pandora_vdds_supplies),
+   .consumer_supplies  = pandora_vdds_supplies,
+};
+
+/* VAUX1 for LCD */
+static struct regulator_init_data pandora_vaux1 = {
+   .constraints = {
+   .min_uV = 300,
+   .max_uV = 300,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = 1,
+   .consumer_supplies  = pandora_vcc_lcd_supply,
+};
+
 static struct twl4030_usb_data omap3pandora_usb_data = {
.usb_mode   = T2_USB_MODE_ULPI,
 };
@@ -298,6 +399,9 @@ static struct twl4030_platform_data omap3pandora_twldata = {

[PATCH 06/23] omap3: pandora: update regulator setup

[Tony Lindgren]

From: Grazvydas Ignotas nota...@gmail.com

Update pandora's regulator setup:
- add new regulators: VAUX2, VAUX4 and VSIM
- add new consumers: ads7846, nub controllers, USB PHY, audio DAC
- use dev names instead of struct device pointers

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-omap3pandora.c |  111 +-
 1 files changed, 78 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index 7ea3894..a0acf8d 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -227,27 +227,6 @@ static struct platform_device pandora_dss_device = {
},
 };
 
-static struct regulator_consumer_supply pandora_vcc_lcd_supply = {
-   .supply = vcc,
-   .dev= pandora_lcd_device.dev,
-};
-
-static struct regulator_consumer_supply pandora_vdda_dac_supply = {
-   .supply = vdda_dac,
-   .dev= pandora_dss_device.dev,
-};
-
-static struct regulator_consumer_supply pandora_vdds_supplies[] = {
-   {
-   .supply = vdds_sdi,
-   .dev= pandora_dss_device.dev,
-   },
-   {
-   .supply = vdds_dsi,
-   .dev= pandora_dss_device.dev,
-   },
-};
-
 static struct omap2_hsmmc_info omap3pandora_mmc[] = {
{
.mmc= 1,
@@ -273,14 +252,6 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
{}  /* Terminator */
 };
 
-static struct regulator_consumer_supply pandora_vmmc1_supply = {
-   .supply = vmmc,
-};
-
-static struct regulator_consumer_supply pandora_vmmc2_supply = {
-   .supply = vmmc,
-};
-
 static int omap3pandora_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
 {
@@ -289,10 +260,6 @@ static int omap3pandora_twl_gpio_setup(struct device *dev,
omap3pandora_mmc[1].gpio_cd = gpio + 1;
omap2_hsmmc_init(omap3pandora_mmc);
 
-   /* link regulators to MMC adapters */
-   pandora_vmmc1_supply.dev = omap3pandora_mmc[0].dev;
-   pandora_vmmc2_supply.dev = omap3pandora_mmc[1].dev;
-
return 0;
 }
 
@@ -303,6 +270,36 @@ static struct twl4030_gpio_platform_data 
omap3pandora_gpio_data = {
.setup  = omap3pandora_twl_gpio_setup,
 };
 
+static struct regulator_consumer_supply pandora_vmmc1_supply =
+   REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
+
+static struct regulator_consumer_supply pandora_vmmc2_supply =
+   REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+static struct regulator_consumer_supply pandora_vdda_dac_supply =
+   REGULATOR_SUPPLY(vdda_dac, omapdss);
+
+static struct regulator_consumer_supply pandora_vdds_supplies[] = {
+   REGULATOR_SUPPLY(vdds_sdi, omapdss),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss),
+};
+
+static struct regulator_consumer_supply pandora_vcc_lcd_supply =
+   REGULATOR_SUPPLY(vcc, display0);
+
+static struct regulator_consumer_supply pandora_usb_phy_supply =
+   REGULATOR_SUPPLY(hsusb0, ehci-omap.0);
+
+/* ads7846 on SPI and 2 nub controllers on I2C */
+static struct regulator_consumer_supply pandora_vaux4_supplies[] = {
+   REGULATOR_SUPPLY(vcc, spi1.0),
+   REGULATOR_SUPPLY(vcc, 3-0066),
+   REGULATOR_SUPPLY(vcc, 3-0067),
+};
+
+static struct regulator_consumer_supply pandora_adac_supply =
+   REGULATOR_SUPPLY(vcc, soc-audio);
+
 /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
 static struct regulator_init_data pandora_vmmc1 = {
.constraints = {
@@ -378,6 +375,51 @@ static struct regulator_init_data pandora_vaux1 = {
.consumer_supplies  = pandora_vcc_lcd_supply,
 };
 
+/* VAUX2 for USB host PHY */
+static struct regulator_init_data pandora_vaux2 = {
+   .constraints = {
+   .min_uV = 180,
+   .max_uV = 180,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = 1,
+   .consumer_supplies  = pandora_usb_phy_supply,
+};
+
+/* VAUX4 for ads7846 and nubs */
+static struct regulator_init_data pandora_vaux4 = {
+   .constraints = {
+   .min_uV = 280,
+   .max_uV = 280,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | 

[PATCH 07/23] omap3: pandora: update defconfig

[Tony Lindgren]

From: Grazvydas Ignotas nota...@gmail.com

Enable DSS2 and update defconfig for current kernel.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/omap3_pandora_defconfig |  678 +++---
 1 files changed, 513 insertions(+), 165 deletions(-)

diff --git a/arch/arm/configs/omap3_pandora_defconfig 
b/arch/arm/configs/omap3_pandora_defconfig
index f74eb9a..5d08e0b 100644
--- a/arch/arm/configs/omap3_pandora_defconfig
+++ b/arch/arm/configs/omap3_pandora_defconfig
@@ -1,15 +1,14 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.28-rc7
-# Fri Dec  5 11:54:09 2008
+# Linux kernel version: 2.6.33-rc6
+# Sat Feb  6 20:25:41 2010
 #
 CONFIG_ARM=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
 CONFIG_GENERIC_GPIO=y
 CONFIG_GENERIC_TIME=y
 CONFIG_GENERIC_CLOCKEVENTS=y
-CONFIG_MMU=y
-# CONFIG_NO_IOPORT is not set
+CONFIG_HAVE_PROC_CPU=y
 CONFIG_GENERIC_HARDIRQS=y
 CONFIG_STACKTRACE_SUPPORT=y
 CONFIG_HAVE_LATENCYTOP_SUPPORT=y
@@ -18,13 +17,13 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y
 CONFIG_HARDIRQS_SW_RESEND=y
 CONFIG_GENERIC_IRQ_PROBE=y
 CONFIG_RWSEM_GENERIC_SPINLOCK=y
-# CONFIG_ARCH_HAS_ILOG2_U32 is not set
-# CONFIG_ARCH_HAS_ILOG2_U64 is not set
+CONFIG_ARCH_HAS_CPUFREQ=y
 CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_CALIBRATE_DELAY=y
 CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
 CONFIG_VECTORS_BASE=0x
 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+CONFIG_CONSTRUCTORS=y
 
 #
 # General setup
@@ -32,8 +31,15 @@ CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
 CONFIG_EXPERIMENTAL=y
 CONFIG_BROKEN_ON_SMP=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_CROSS_COMPILE=
 CONFIG_LOCALVERSION=
 CONFIG_LOCALVERSION_AUTO=y
+CONFIG_HAVE_KERNEL_GZIP=y
+CONFIG_HAVE_KERNEL_LZO=y
+CONFIG_KERNEL_GZIP=y
+# CONFIG_KERNEL_BZIP2 is not set
+# CONFIG_KERNEL_LZMA is not set
+# CONFIG_KERNEL_LZO is not set
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 CONFIG_SYSVIPC_SYSCTL=y
@@ -42,24 +48,33 @@ CONFIG_BSD_PROCESS_ACCT=y
 # CONFIG_BSD_PROCESS_ACCT_V3 is not set
 # CONFIG_TASKSTATS is not set
 # CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_TREE_RCU=y
+# CONFIG_TREE_PREEMPT_RCU is not set
+# CONFIG_TINY_RCU is not set
+# CONFIG_RCU_TRACE is not set
+CONFIG_RCU_FANOUT=32
+# CONFIG_RCU_FANOUT_EXACT is not set
+# CONFIG_TREE_RCU_TRACE is not set
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=14
 # CONFIG_CGROUPS is not set
-CONFIG_GROUP_SCHED=y
-CONFIG_FAIR_GROUP_SCHED=y
-# CONFIG_RT_GROUP_SCHED is not set
-CONFIG_USER_SCHED=y
-# CONFIG_CGROUP_SCHED is not set
-# CONFIG_SYSFS_DEPRECATED=y is not set
-# CONFIG_SYSFS_DEPRECATED_V2=y is not set
-
+# CONFIG_SYSFS_DEPRECATED_V2 is not set
 # CONFIG_RELAY is not set
 # CONFIG_NAMESPACES is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE=
+CONFIG_RD_GZIP=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_LZO is not set
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 CONFIG_SYSCTL=y
+CONFIG_ANON_INODES=y
 CONFIG_EMBEDDED=y
 CONFIG_UID16=y
 # CONFIG_SYSCTL_SYSCALL is not set
@@ -70,31 +85,41 @@ CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-CONFIG_COMPAT_BRK=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
-CONFIG_ANON_INODES=y
 CONFIG_EPOLL=y
 CONFIG_SIGNALFD=y
 CONFIG_TIMERFD=y
 CONFIG_EVENTFD=y
 CONFIG_SHMEM=y
 CONFIG_AIO=y
+CONFIG_HAVE_PERF_EVENTS=y
+CONFIG_PERF_USE_VMALLOC=y
+
+#
+# Kernel Performance Events And Counters
+#
+# CONFIG_PERF_EVENTS is not set
+# CONFIG_PERF_COUNTERS is not set
 CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_COMPAT_BRK=y
 CONFIG_SLAB=y
 # CONFIG_SLUB is not set
 # CONFIG_SLOB is not set
 # CONFIG_PROFILING is not set
-# CONFIG_MARKERS is not set
 CONFIG_HAVE_OPROFILE=y
 # CONFIG_KPROBES is not set
 CONFIG_HAVE_KPROBES=y
 CONFIG_HAVE_KRETPROBES=y
 CONFIG_HAVE_CLK=y
+
+#
+# GCOV-based kernel profiling
+#
+CONFIG_SLOW_WORK=y
 CONFIG_HAVE_GENERIC_DMA_COHERENT=y
 CONFIG_SLABINFO=y
 CONFIG_RT_MUTEXES=y
-# CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
 CONFIG_MODULES=y
 # CONFIG_MODULE_FORCE_LOAD is not set
@@ -102,11 +127,8 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_MODULE_FORCE_UNLOAD is not set
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
-CONFIG_KMOD=y
 CONFIG_BLOCK=y
-# CONFIG_LBD is not set
-# CONFIG_BLK_DEV_IO_TRACE is not set
-# CONFIG_LSF is not set
+CONFIG_LBDAF=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_BLK_DEV_INTEGRITY is not set
 
@@ -114,33 +136,62 @@ CONFIG_BLOCK=y
 # IO Schedulers
 #
 CONFIG_IOSCHED_NOOP=y
-CONFIG_IOSCHED_AS=y
 CONFIG_IOSCHED_DEADLINE=y
 CONFIG_IOSCHED_CFQ=y
-CONFIG_DEFAULT_AS=y
 # CONFIG_DEFAULT_DEADLINE is not set
-# CONFIG_DEFAULT_CFQ is not set
+CONFIG_DEFAULT_CFQ=y
 # CONFIG_DEFAULT_NOOP is not set
-CONFIG_DEFAULT_IOSCHED=anticipatory
-CONFIG_CLASSIC_RCU=y
+CONFIG_DEFAULT_IOSCHED=cfq
+# CONFIG_INLINE_SPIN_TRYLOCK is not set
+# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
+# CONFIG_INLINE_SPIN_LOCK is not set
+# CONFIG_INLINE_SPIN_LOCK_BH is not set
+# CONFIG_INLINE_SPIN_LOCK_IRQ 

[PATCH 08/23] omap3: Add platform data for the twl4030_codec MFD on IGEP v2

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

Add platform data for the twl4030_codec MFD on IGEP v2

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index adc1b46..71488b2 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -173,12 +173,22 @@ static void __init igep2_init_irq(void)
omap_gpio_init();
 }
 
+static struct twl4030_codec_audio_data igep2_audio_data = {
+   .audio_mclk = 2600,
+};
+
+static struct twl4030_codec_data igep2_codec_data = {
+   .audio_mclk = 2600,
+   .audio = igep2_audio_data,
+};
+
 static struct twl4030_platform_data igep2_twldata = {
.irq_base   = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
 
/* platform_data for children goes here */
.usb= igep2_usb_data,
+   .codec  = igep2_codec_data,
.gpio   = igep2_gpio_data,
.vmmc1  = igep2_vmmc1,
 

--
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 09/23] omap3: Fix typo on IGEP v2 board

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

Fix typo on IGEP v2 board

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f90b225..2e81a6e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -131,7 +131,7 @@ config MACH_CM_T35
select OMAP_MUX
 
 config MACH_IGEP0020
-   bool IGEP0020
+   bool IGEP v2 board
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
 

--
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 10/23] omap3: Add platform init code for EHCI driver on IGEP v2

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

Add platform init code for EHCI driver on IGEP v2

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 71488b2..f6102c7 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -213,6 +213,17 @@ static int __init igep2_i2c_init(void)
return 0;
 }
 
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+   .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+   .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+   .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+   .phy_reset = true,
+   .reset_gpio_port[0] = -EINVAL,
+   .reset_gpio_port[1] = IGEP2_GPIO_USBH_NRESET,
+   .reset_gpio_port[2] = -EINVAL,
+};
+
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -227,6 +238,7 @@ static void __init igep2_init(void)
igep2_i2c_init();
omap_serial_init();
usb_musb_init();
+   usb_ehci_init(ehci_pdata);
 
igep2_init_smsc911x();
 

--
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 11/23] omap3: Enable DSS2 for IGEP v2 board

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |   75 ++
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index f6102c7..f6899f9 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -28,6 +28,7 @@
 #include plat/common.h
 #include plat/gpmc.h
 #include plat/usb.h
+#include plat/display.h
 
 #include mux.h
 #include hsmmc.h
@@ -38,6 +39,7 @@
 #define IGEP2_GPIO_LED0_RED26
 #define IGEP2_GPIO_LED0_GREEN  27
 #define IGEP2_GPIO_LED1_RED28
+#define IGEP2_GPIO_DVI_PUP 170
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
 
@@ -164,6 +166,76 @@ static struct twl4030_usb_data igep2_usb_data = {
.usb_mode   = T2_USB_MODE_ULPI,
 };
 
+static int igep2_enable_dvi(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(IGEP2_GPIO_DVI_PUP, 1);
+
+   return 0;
+}
+
+static void igep2_disable_dvi(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(IGEP2_GPIO_DVI_PUP, 0);
+}
+
+static struct omap_dss_device igep2_dvi_device = {
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .name   = dvi,
+   .driver_name= generic_panel,
+   .phy.dpi.data_lines = 24,
+   .platform_enable= igep2_enable_dvi,
+   .platform_disable   = igep2_disable_dvi,
+};
+
+static struct omap_dss_device *igep2_dss_devices[] = {
+   igep2_dvi_device
+};
+
+static struct omap_dss_board_info igep2_dss_data = {
+   .num_devices= ARRAY_SIZE(igep2_dss_devices),
+   .devices= igep2_dss_devices,
+   .default_device = igep2_dvi_device,
+};
+
+static struct platform_device igep2_dss_device = {
+   .name   = omapdss,
+   .id = -1,
+   .dev= {
+   .platform_data = igep2_dss_data,
+   },
+};
+
+static struct regulator_consumer_supply igep2_vpll2_supply = {
+   .supply = vdds_dsi,
+   .dev= igep2_dss_device.dev,
+};
+
+static struct regulator_init_data igep2_vpll2 = {
+   .constraints = {
+   .name   = VDVI,
+   .min_uV = 180,
+   .max_uV = 180,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = 1,
+   .consumer_supplies  = igep2_vpll2_supply,
+};
+
+static void __init igep2_display_init(void)
+{
+   if (gpio_request(IGEP2_GPIO_DVI_PUP, GPIO_DVI_PUP) 
+   gpio_direction_output(IGEP2_GPIO_DVI_PUP, 1))
+   pr_err(IGEP v2: Could not obtain gpio GPIO_DVI_PUP\n);
+}
+
+static struct platform_device *igep2_devices[] __initdata = {
+   igep2_dss_device,
+};
+
 static void __init igep2_init_irq(void)
 {
omap_board_config = igep2_config;
@@ -191,6 +263,7 @@ static struct twl4030_platform_data igep2_twldata = {
.codec  = igep2_codec_data,
.gpio   = igep2_gpio_data,
.vmmc1  = igep2_vmmc1,
+   .vpll2  = igep2_vpll2,
 
 };
 
@@ -236,10 +309,12 @@ static void __init igep2_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
igep2_i2c_init();
+   platform_add_devices(igep2_devices, ARRAY_SIZE(igep2_devices));
omap_serial_init();
usb_musb_init();
usb_ehci_init(ehci_pdata);
 
+   igep2_display_init();
igep2_init_smsc911x();
 
/* GPIO userspace leds */

--
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 12/23] omap3: Add support for flash on IGEP v2 board

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

This patch adds support for flashes on IGEP v2 boards. For now
only OneNAND is supported.

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |  101 ++
 1 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index f6899f9..8ed935c 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -29,6 +29,7 @@
 #include plat/gpmc.h
 #include plat/usb.h
 #include plat/display.h
+#include plat/onenand.h
 
 #include mux.h
 #include hsmmc.h
@@ -41,6 +42,105 @@
 #define IGEP2_GPIO_LED1_RED28
 #define IGEP2_GPIO_DVI_PUP 170
 
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+   defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+
+#define ONENAND_MAP 0x2000
+
+/* NAND04GR4E1A ( x2 Flash built-in COMBO POP MEMORY )
+ * Since the device is equipped with two DataRAMs, and two-plane NAND
+ * Flash memory array, these two component enables simultaneous program
+ * of 4KiB. Plane1 has only even blocks such as block0, block2, block4
+ * while Plane2 has only odd blocks such as block1, block3, block5.
+ * So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
+ */
+
+static struct mtd_partition igep2_onenand_partitions[] = {
+   {
+   .name   = X-Loader,
+   .offset = 0,
+   .size   = 2 * (64*(2*2048))
+   },
+   {
+   .name   = U-Boot,
+   .offset = MTDPART_OFS_APPEND,
+   .size   = 6 * (64*(2*2048)),
+   },
+   {
+   .name   = Environment,
+   .offset = MTDPART_OFS_APPEND,
+   .size   = 2 * (64*(2*2048)),
+   },
+   {
+   .name   = Kernel,
+   .offset = MTDPART_OFS_APPEND,
+   .size   = 12 * (64*(2*2048)),
+   },
+   {
+   .name   = File System,
+   .offset = MTDPART_OFS_APPEND,
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+static int igep2_onenand_setup(void __iomem *onenand_base, int freq)
+{
+   /* nothing is required to be setup for onenand as of now */
+   return 0;
+}
+
+static struct omap_onenand_platform_data igep2_onenand_data = {
+   .parts = igep2_onenand_partitions,
+   .nr_parts = ARRAY_SIZE(igep2_onenand_partitions),
+   .onenand_setup = igep2_onenand_setup,
+   .dma_channel= -1,   /* disable DMA in OMAP OneNAND driver */
+};
+
+static struct platform_device igep2_onenand_device = {
+   .name   = omap2-onenand,
+   .id = -1,
+   .dev = {
+   .platform_data = igep2_onenand_data,
+   },
+};
+
+void __init igep2_flash_init(void)
+{
+   u8  cs = 0;
+   u8  onenandcs = GPMC_CS_NUM + 1;
+
+   while (cs  GPMC_CS_NUM) {
+   u32 ret = 0;
+   ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+   /* Check if NAND/oneNAND is configured */
+   if ((ret  0xC00) == 0x800)
+   /* NAND found */
+   pr_err(IGEP v2: Unsupported NAND found\n);
+   else {
+   ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
+   if ((ret  0x3F) == (ONENAND_MAP  24))
+   /* ONENAND found */
+   onenandcs = cs;
+   }
+   cs++;
+   }
+   if (onenandcs  GPMC_CS_NUM) {
+   pr_err(IGEP v2: Unable to find configuration in GPMC\n);
+   return;
+   }
+
+   if (onenandcs  GPMC_CS_NUM) {
+   igep2_onenand_data.cs = onenandcs;
+   if (platform_device_register(igep2_onenand_device)  0)
+   pr_err(IGEP v2: Unable to register OneNAND device\n);
+   }
+}
+
+#else
+void __init igep2_flash_init(void) {}
+#endif
+
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
 
 #include linux/smsc911x.h
@@ -314,6 +414,7 @@ static void __init igep2_init(void)
usb_musb_init();
usb_ehci_init(ehci_pdata);
 
+   igep2_flash_init();
igep2_display_init();
igep2_init_smsc911x();
 

--
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 13/23] ARM: OMAP3: SDRC: add timing data for Numonyx M65KxxxxAM

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

Add timing data for the Numonyx M65KAM SDRAM chip, used on the
IGEP v2 board.

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/sdram-numonyx-m65kam.h |   51 
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/sdram-numonyx-m65kam.h

diff --git a/arch/arm/mach-omap2/sdram-numonyx-m65kam.h 
b/arch/arm/mach-omap2/sdram-numonyx-m65kam.h
new file mode 100644
index 000..cd43529
--- /dev/null
+++ b/arch/arm/mach-omap2/sdram-numonyx-m65kam.h
@@ -0,0 +1,51 @@
+/*
+ * SDRC register values for the Numonyx M65KAM
+ *
+ * Copyright (C) 2009 Integration Software and Electronic Engineering.
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_SDRAM_NUMONYX_M65KAM
+#define __ARCH_ARM_MACH_OMAP2_SDRAM_NUMONYX_M65KAM
+
+#include plat/sdrc.h
+
+/* Numonyx  M65KAM */
+static struct omap_sdrc_params m65kam_sdrc_params[] = {
+   [0] = {
+   .rate   = 2,
+   .actim_ctrla= 0xe321d4c6,
+   .actim_ctrlb= 0x00022328,
+   .rfr_ctrl   = 0x0005e601,
+   .mr = 0x0032,
+   },
+   [1] = {
+   .rate   = 16600,
+   .actim_ctrla= 0xba9dc485,
+   .actim_ctrlb= 0x00022321,
+   .rfr_ctrl   = 0x0004dc01,
+   .mr = 0x0032,
+   },
+   [2] = {
+   .rate   = 13300,
+   .actim_ctrla= 0x9a19b485,
+   .actim_ctrlb= 0x0002231b,
+   .rfr_ctrl   = 0x0003de01,
+   .mr = 0x0032,
+   },
+   [3] = {
+   .rate   = 8300,
+   .actim_ctrla= 0x594ca242,
+   .actim_ctrlb= 0x00022310,
+   .rfr_ctrl   = 0x00025501,
+   .mr = 0x0032,
+   },
+   [4] = {
+   .rate   = 0
+   },
+};
+
+#endif

--
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 14/23] omap3: Use timing data for omap2_init_common_hw on IGEP v2

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 8ed935c..3d1fde7 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -33,6 +33,7 @@
 
 #include mux.h
 #include hsmmc.h
+#include sdram-numonyx-m65kam.h
 
 #define IGEP2_SMSC911X_CS   5
 #define IGEP2_SMSC911X_GPIO 176
@@ -340,7 +341,7 @@ static void __init igep2_init_irq(void)
 {
omap_board_config = igep2_config;
omap_board_config_size = ARRAY_SIZE(igep2_config);
-   omap2_init_common_hw(NULL, NULL);
+   omap2_init_common_hw(m65kam_sdrc_params, m65kam_sdrc_params);
omap_init_irq();
omap_gpio_init();
 }

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

[PATCH 15/23] omap3: Update defconfig for IGEP v2 to allow new drivers andfeatures

[Tony Lindgren]

From: Enric Balletbo i Serra eballe...@iseebcn.com

Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/igep0020_defconfig |  525 +--
 1 files changed, 309 insertions(+), 216 deletions(-)

diff --git a/arch/arm/configs/igep0020_defconfig 
b/arch/arm/configs/igep0020_defconfig
index a192248..e7940a9 100644
--- a/arch/arm/configs/igep0020_defconfig
+++ b/arch/arm/configs/igep0020_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.32-rc6
-# Fri Nov 13 12:01:17 2009
+# Linux kernel version: 2.6.33-rc3
+# Thu Jan  7 16:14:55 2010
 #
 CONFIG_ARM=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
@@ -46,6 +46,7 @@ CONFIG_BSD_PROCESS_ACCT=y
 #
 CONFIG_TREE_RCU=y
 # CONFIG_TREE_PREEMPT_RCU is not set
+# CONFIG_TINY_RCU is not set
 # CONFIG_RCU_TRACE is not set
 CONFIG_RCU_FANOUT=32
 # CONFIG_RCU_FANOUT_EXACT is not set
@@ -126,14 +127,41 @@ CONFIG_LBDAF=y
 # IO Schedulers
 #
 CONFIG_IOSCHED_NOOP=y
-CONFIG_IOSCHED_AS=y
 CONFIG_IOSCHED_DEADLINE=y
 CONFIG_IOSCHED_CFQ=y
-CONFIG_DEFAULT_AS=y
 # CONFIG_DEFAULT_DEADLINE is not set
-# CONFIG_DEFAULT_CFQ is not set
+CONFIG_DEFAULT_CFQ=y
 # CONFIG_DEFAULT_NOOP is not set
-CONFIG_DEFAULT_IOSCHED=anticipatory
+CONFIG_DEFAULT_IOSCHED=cfq
+# CONFIG_INLINE_SPIN_TRYLOCK is not set
+# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
+# CONFIG_INLINE_SPIN_LOCK is not set
+# CONFIG_INLINE_SPIN_LOCK_BH is not set
+# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
+# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
+CONFIG_INLINE_SPIN_UNLOCK=y
+# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
+CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
+# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
+# CONFIG_INLINE_READ_TRYLOCK is not set
+# CONFIG_INLINE_READ_LOCK is not set
+# CONFIG_INLINE_READ_LOCK_BH is not set
+# CONFIG_INLINE_READ_LOCK_IRQ is not set
+# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
+CONFIG_INLINE_READ_UNLOCK=y
+# CONFIG_INLINE_READ_UNLOCK_BH is not set
+CONFIG_INLINE_READ_UNLOCK_IRQ=y
+# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
+# CONFIG_INLINE_WRITE_TRYLOCK is not set
+# CONFIG_INLINE_WRITE_LOCK is not set
+# CONFIG_INLINE_WRITE_LOCK_BH is not set
+# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
+# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
+CONFIG_INLINE_WRITE_UNLOCK=y
+# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
+CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
+# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
+# CONFIG_MUTEX_SPIN_ON_OWNER is not set
 # CONFIG_FREEZER is not set
 
 #
@@ -162,6 +190,7 @@ CONFIG_MMU=y
 # CONFIG_ARCH_IXP2000 is not set
 # CONFIG_ARCH_IXP4XX is not set
 # CONFIG_ARCH_L7200 is not set
+# CONFIG_ARCH_DOVE is not set
 # CONFIG_ARCH_KIRKWOOD is not set
 # CONFIG_ARCH_LOKI is not set
 # CONFIG_ARCH_MV78XX0 is not set
@@ -184,6 +213,7 @@ CONFIG_MMU=y
 # CONFIG_ARCH_DAVINCI is not set
 CONFIG_ARCH_OMAP=y
 # CONFIG_ARCH_BCMRING is not set
+# CONFIG_ARCH_U8500 is not set
 
 #
 # TI OMAP Implementations
@@ -197,12 +227,8 @@ CONFIG_ARCH_OMAP3=y
 #
 # OMAP Feature Selections
 #
-# CONFIG_OMAP_DEBUG_POWERDOMAIN is not set
-# CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set
-# CONFIG_OMAP_RESET_CLOCKS is not set
-CONFIG_OMAP_MUX=y
-CONFIG_OMAP_MUX_DEBUG=y
-CONFIG_OMAP_MUX_WARNINGS=y
+CONFIG_OMAP_RESET_CLOCKS=y
+# CONFIG_OMAP_MUX is not set
 CONFIG_OMAP_MCBSP=y
 # CONFIG_OMAP_MBOX_FWK is not set
 # CONFIG_OMAP_MPU_TIMER is not set
@@ -217,6 +243,7 @@ CONFIG_OMAP_LL_DEBUG_UART3=y
 CONFIG_OMAP_PM_NOOP=y
 CONFIG_ARCH_OMAP34XX=y
 CONFIG_ARCH_OMAP3430=y
+CONFIG_OMAP_PACKAGE_CBB=y
 
 #
 # OMAP Board Type
@@ -227,13 +254,16 @@ CONFIG_ARCH_OMAP3430=y
 # CONFIG_MACH_OMAP3EVM is not set
 # CONFIG_MACH_OMAP3517EVM is not set
 # CONFIG_MACH_OMAP3_PANDORA is not set
+# CONFIG_MACH_OMAP3_TOUCHBOOK is not set
 # CONFIG_MACH_OMAP_3430SDP is not set
 # CONFIG_MACH_NOKIA_RX51 is not set
 # CONFIG_MACH_OMAP_ZOOM2 is not set
-# CONFIG_MACH_CM_T35 is not set
 # CONFIG_MACH_OMAP_ZOOM3 is not set
-# CONFIG_MACH_OMAP_3630SDP is not set
+# CONFIG_MACH_CM_T35 is not set
 CONFIG_MACH_IGEP0020=y
+# CONFIG_MACH_OMAP_3630SDP is not set
+# CONFIG_OMAP3_EMU is not set
+# CONFIG_OMAP3_SDRC_AC_TIMING is not set
 
 #
 # Processor Type
@@ -305,8 +335,6 @@ CONFIG_SPLIT_PTLOCK_CPUS=4
 # CONFIG_PHYS_ADDR_T_64BIT is not set
 CONFIG_ZONE_DMA_FLAG=0
 CONFIG_VIRT_TO_BUS=y
-CONFIG_HAVE_MLOCK=y
-CONFIG_HAVE_MLOCKED_PAGE_BIT=y
 # CONFIG_KSM is not set
 CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
 # CONFIG_LEDS is not set
@@ -440,35 +468,35 @@ CONFIG_BT_HIDP=m
 #
 # Bluetooth device drivers
 #
-CONFIG_BT_HCIBTUSB=m
+# CONFIG_BT_HCIBTUSB is not set
 # CONFIG_BT_HCIBTSDIO is not set
 CONFIG_BT_HCIUART=m
 CONFIG_BT_HCIUART_H4=y
 CONFIG_BT_HCIUART_BCSP=y
 CONFIG_BT_HCIUART_LL=y
-CONFIG_BT_HCIBCM203X=m
-CONFIG_BT_HCIBPA10X=m
-CONFIG_BT_HCIBFUSB=m
+# CONFIG_BT_HCIBCM203X is not set
+# CONFIG_BT_HCIBPA10X is not set
+# CONFIG_BT_HCIBFUSB is not set
 CONFIG_BT_HCIVHCI=m
 CONFIG_BT_MRVL=m
 CONFIG_BT_MRVL_SDIO=m
 # CONFIG_AF_RXRPC is 

[PATCH 16/23] IGEPv2: Added WIFI support

[Tony Lindgren]

From: Jonas Zetterberg j...@jozz.se

Enabled VMMC2 LDO voltage regulator on TWL4030.
Added GPIO's (power down and reset) for WIFI chip.

Signed-off-by: Anders Hedlund anders.j.hedl...@gmail.com
Signed-off-by: Jonas Zetterberg j...@jozz.se
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |   40 ++
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 3d1fde7..4a5d663 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -42,6 +42,8 @@
 #define IGEP2_GPIO_LED0_GREEN  27
 #define IGEP2_GPIO_LED1_RED28
 #define IGEP2_GPIO_DVI_PUP 170
+#define IGEP2_GPIO_WIFI_NPD94
+#define IGEP2_GPIO_WIFI_NRESET 95
 
 #if defined(CONFIG_MTD_ONENAND_OMAP2) || \
defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
@@ -209,6 +211,10 @@ static struct regulator_consumer_supply igep2_vmmc1_supply 
= {
.supply = vmmc,
 };
 
+static struct regulator_consumer_supply igep2_vmmc2_supply = {
+   .supply = vmmc,
+};
+
 /* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
 static struct regulator_init_data igep2_vmmc1 = {
.constraints = {
@@ -224,6 +230,21 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies  = igep2_vmmc1_supply,
 };
 
+/* VMMC2 for OMAP VDD_MMC2 (i/o) and MMC2 WIFI */
+static struct regulator_init_data igep2_vmmc2 = {
+   .constraints = {
+   .min_uV = 185,
+   .max_uV = 315,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+   | REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = 1,
+   .consumer_supplies  = igep2_vmmc2_supply,
+};
+
 static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -251,6 +272,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
 * regulators will be set up only *after* we return.
*/
igep2_vmmc1_supply.dev = mmc[0].dev;
+   igep2_vmmc2_supply.dev = mmc[1].dev;
 
return 0;
 };
@@ -364,6 +386,7 @@ static struct twl4030_platform_data igep2_twldata = {
.codec  = igep2_codec_data,
.gpio   = igep2_gpio_data,
.vmmc1  = igep2_vmmc1,
+   .vmmc2  = igep2_vmmc2,
.vpll2  = igep2_vpll2,
 
 };
@@ -440,6 +463,23 @@ static void __init igep2_init(void)
gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
} else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
+
+   /* GPIO W-LAN + Bluetooth combo module */
+   if ((gpio_request(IGEP2_GPIO_WIFI_NPD, GPIO_WIFI_NPD) == 0) 
+   (gpio_direction_output(IGEP2_GPIO_WIFI_NPD, 1) == 0)) {
+   gpio_export(IGEP2_GPIO_WIFI_NPD, 0);
+/* gpio_set_value(IGEP2_GPIO_WIFI_NPD, 0); */
+   } else
+   pr_warning(IGEP v2: Could not obtain gpio GPIO_WIFI_NPD\n);
+
+   if ((gpio_request(IGEP2_GPIO_WIFI_NRESET, GPIO_WIFI_NRESET) == 0) 
+   (gpio_direction_output(IGEP2_GPIO_WIFI_NRESET, 1) == 0)) {
+   gpio_export(IGEP2_GPIO_WIFI_NRESET, 0);
+   gpio_set_value(IGEP2_GPIO_WIFI_NRESET, 0);
+   udelay(10);
+   gpio_set_value(IGEP2_GPIO_WIFI_NRESET, 1);
+   } else
+   pr_warning(IGEP v2: Could not obtain gpio GPIO_WIFI_NRESET\n);
 }
 
 static void __init igep2_map_io(void)

--
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 17/23] IGEPv2: Use Red Led1 as Heartbeat if configured

[Tony Lindgren]

From: Jonas Zetterberg j...@jozz.se

If not configured it will be exported as normal GPIO led.

Signed-off-by: Jonas Zetterberg j...@jozz.se
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |   30 --
 1 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 4a5d663..748f418 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -16,6 +16,7 @@
 #include linux/clk.h
 #include linux/io.h
 #include linux/gpio.h
+#include linux/leds.h
 #include linux/interrupt.h
 
 #include linux/regulator/machine.h
@@ -354,9 +355,34 @@ static void __init igep2_display_init(void)
gpio_direction_output(IGEP2_GPIO_DVI_PUP, 1))
pr_err(IGEP v2: Could not obtain gpio GPIO_DVI_PUP\n);
 }
+#ifdef CONFIG_LEDS_TRIGGERS
+static struct gpio_led gpio_leds[] = {
+   {
+   .name = GPIO_LED1_RED,
+   .default_trigger = heartbeat,
+   .gpio = IGEP2_GPIO_LED1_RED,
+   },
+};
+
+static struct gpio_led_platform_data gpio_leds_info = {
+   .leds   = gpio_leds,
+   .num_leds   = ARRAY_SIZE(gpio_leds),
+};
+
+static struct platform_device leds_gpio = {
+.name   = leds-gpio,
+.id = -1,
+.dev= {
+.platform_data  =  gpio_leds_info,
+   },
+};
+#endif
 
 static struct platform_device *igep2_devices[] __initdata = {
igep2_dss_device,
+#ifdef CONFIG_LEDS_TRIGGERS
+   leds_gpio,
+#endif
 };
 
 static void __init igep2_init_irq(void)
@@ -456,14 +482,14 @@ static void __init igep2_init(void)
gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
} else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n);
-
+#ifndef CONFIG_LEDS_TRIGGERS
if ((gpio_request(IGEP2_GPIO_LED1_RED, GPIO_LED1_RED) == 0) 
(gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED1_RED, 0);
gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
} else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
-
+#endif
/* GPIO W-LAN + Bluetooth combo module */
if ((gpio_request(IGEP2_GPIO_WIFI_NPD, GPIO_WIFI_NPD) == 0) 
(gpio_direction_output(IGEP2_GPIO_WIFI_NPD, 1) == 0)) {

--
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 18/23] AM3517: Enable basic I2C Support

[Tony Lindgren]

From: Vaibhav Hiremath hvaib...@ti.com

Add basic I2C board Hook-up support, where all the 3 I2C instances
are getting registered.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-am3517evm.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index ad323b4..af99faf 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -38,6 +38,15 @@
 #define LCD_PANEL_BKLIGHT_PWR  182
 #define LCD_PANEL_PWM  181
 
+static int __init am3517_evm_i2c_init(void)
+{
+   omap_register_i2c_bus(1, 400, NULL, 0);
+   omap_register_i2c_bus(2, 400, NULL, 0);
+   omap_register_i2c_bus(3, 400, NULL, 0);
+
+   return 0;
+}
+
 static int lcd_enabled;
 static int dvi_enabled;
 
@@ -216,6 +225,8 @@ static struct omap_board_mux board_mux[] __initdata = {
 
 static void __init am3517_evm_init(void)
 {
+   am3517_evm_i2c_init();
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
platform_add_devices(am3517_evm_devices,
ARRAY_SIZE(am3517_evm_devices));

--
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 19/23] AM3517: Enable RTC driver support for AM3517EVM

[Tony Lindgren]

From: Vaibhav Hiremath hvaib...@ti.com

Add platform hook-up interface to support RTC driver (S35390A).

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-am3517evm.c |   39 +
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index af99faf..fe2446d 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -38,6 +38,39 @@
 #define LCD_PANEL_BKLIGHT_PWR  182
 #define LCD_PANEL_PWM  181
 
+static struct i2c_board_info __initdata am3517evm_i2c_boardinfo[] = {
+   {
+   I2C_BOARD_INFO(s35390a, 0x30),
+   .type   = s35390a,
+   },
+};
+
+/*
+ * RTC - S35390A
+ */
+#define GPIO_RTCS35390A_IRQ55
+
+static void __init am3517_evm_rtc_init(void)
+{
+   int r;
+
+   omap_mux_init_gpio(GPIO_RTCS35390A_IRQ, OMAP_PIN_INPUT_PULLUP);
+   r = gpio_request(GPIO_RTCS35390A_IRQ, rtcs35390a-irq);
+   if (r  0) {
+   printk(KERN_WARNING failed to request GPIO#%d\n,
+   GPIO_RTCS35390A_IRQ);
+   return;
+   }
+   r = gpio_direction_input(GPIO_RTCS35390A_IRQ);
+   if (r  0) {
+   printk(KERN_WARNING GPIO#%d cannot be configured as input\n,
+   GPIO_RTCS35390A_IRQ);
+   gpio_free(GPIO_RTCS35390A_IRQ);
+   return;
+   }
+   am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
+}
+
 static int __init am3517_evm_i2c_init(void)
 {
omap_register_i2c_bus(1, 400, NULL, 0);
@@ -235,6 +268,12 @@ static void __init am3517_evm_init(void)
usb_ehci_init(ehci_pdata);
/* DSS */
am3517_evm_display_init();
+
+   /* RTC - S35390A */
+   am3517_evm_rtc_init();
+
+   i2c_register_board_info(1, am3517evm_i2c_boardinfo,
+   ARRAY_SIZE(am3517evm_i2c_boardinfo));
 }
 
 static void __init am3517_evm_map_io(void)

--
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 20/23] AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM

[Tony Lindgren]

From: Vaibhav Hiremath hvaib...@ti.com

Add platform hook-up interface to support I2C based GPIo expander
(TCA6416).

There are 3 instances of I2C Expander on AM3517EVM,
- One is over I2C-2 mounted on Base board
- Two are over I2C3 mounted on UI Card

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-am3517evm.c |   40 +++--
 1 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index fe2446d..e6b8967 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,7 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/gpio.h
+#include linux/i2c/pca953x.h
 
 #include mach/hardware.h
 #include mach/am35xx.h
@@ -71,11 +72,46 @@ static void __init am3517_evm_rtc_init(void)
am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
 }
 
+/*
+ * I2C GPIO Expander - TCA6416
+ */
+
+/* Mounted on Base-Board */
+static struct pca953x_platform_data am3517evm_gpio_expander_info_0 = {
+   .gpio_base  = OMAP_MAX_GPIO_LINES,
+};
+static struct i2c_board_info __initdata am3517evm_tca6516_info_0[] = {
+   {
+   I2C_BOARD_INFO(tca6416, 0x21),
+   .platform_data = am3517evm_gpio_expander_info_0,
+   },
+};
+
+/* Mounted on UI Card */
+static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_1 = {
+   .gpio_base  = OMAP_MAX_GPIO_LINES + 16,
+};
+static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_2 = {
+   .gpio_base  = OMAP_MAX_GPIO_LINES + 32,
+};
+static struct i2c_board_info __initdata am3517evm_ui_tca6516_info[] = {
+   {
+   I2C_BOARD_INFO(tca6416, 0x20),
+   .platform_data = am3517evm_ui_gpio_expander_info_1,
+   },
+   {
+   I2C_BOARD_INFO(tca6416, 0x21),
+   .platform_data = am3517evm_ui_gpio_expander_info_2,
+   },
+};
+
 static int __init am3517_evm_i2c_init(void)
 {
omap_register_i2c_bus(1, 400, NULL, 0);
-   omap_register_i2c_bus(2, 400, NULL, 0);
-   omap_register_i2c_bus(3, 400, NULL, 0);
+   omap_register_i2c_bus(2, 400, am3517evm_tca6516_info_0,
+   ARRAY_SIZE(am3517evm_tca6516_info_0));
+   omap_register_i2c_bus(3, 400, am3517evm_ui_tca6516_info,
+   ARRAY_SIZE(am3517evm_ui_tca6516_info));
 
return 0;
 }

--
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 21/23] Add minimal support for DevKit8000

[Tony Lindgren]

From: Thomas Weber we...@corscience.de

These patches add board support for the Timll DevKit8000.

The DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.

Signed-off-by: Thomas Weber we...@corscience.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/Kconfig|4 
 arch/arm/mach-omap2/Makefile   |2 
 arch/arm/mach-omap2/board-devkit8000.c |  691 
 3 files changed, 697 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-devkit8000.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2e81a6e..a8a3d1e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -58,6 +58,10 @@ config MACH_OMAP3_BEAGLE
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
 
+config MACH_DEVKIT8000
+bool DEVKIT8000 board
+depends on ARCH_OMAP3
+
 config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dfc49a0..d3e54da 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -91,6 +91,8 @@ obj-$(CONFIG_MACH_OMAP_2430SDP)   += 
board-2430sdp.o \
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
   hsmmc.o
+obj-$(CONFIG_MACH_DEVKIT8000)  += board-devkit8000.o \
+   hsmmc.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
   hsmmc.o
 obj-$(CONFIG_MACH_OVERO)   += board-overo.o \
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
new file mode 100644
index 000..89a55f1
--- /dev/null
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -0,0 +1,691 @@
+/*
+ * board-devkit8000.c - TimLL Devkit8000
+ *
+ * Copyright (C) 2009 Kim Botherway
+ * Copyright (C) 2010 Thomas Weber
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * 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/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/input.h
+#include linux/gpio_keys.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
+#include linux/regulator/machine.h
+#include linux/i2c/twl.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/flash.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/usb.h
+#include plat/timer-gp.h
+#include plat/display.h
+
+#include plat/mcspi.h
+#include linux/input/matrix_keypad.h
+#include linux/spi/spi.h
+#include linux/spi/ads7846.h
+#include linux/usb/otg.h
+#include linux/dm9000.h
+#include linux/interrupt.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+
+#include mux.h
+#include hsmmc.h
+
+#define GPMC_CS0_BASE  0x60
+#define GPMC_CS_SIZE   0x30
+
+#define NAND_BLOCK_SIZESZ_128K
+
+#define OMAP_DM9000_GPIO_IRQ   25
+#define OMAP3_DEVKIT_TS_GPIO   27
+
+static struct mtd_partition devkit8000_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = X-Loader,
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = U-Boot,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = U-Boot Env,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = Kernel,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = File System,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+static struct omap_nand_platform_data devkit8000_nand_data = 

[PATCH 22/23] Add devkit8000_defconfig

[Tony Lindgren]

From: Thomas Weber we...@corscience.de

This patch adds a default config for the Timll Devkit8000.

Signed-off-by: Thomas Weber we...@corscience.de
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/devkit8000_defconfig | 1889 +
 1 files changed, 1889 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/configs/devkit8000_defconfig

diff --git a/arch/arm/configs/devkit8000_defconfig 
b/arch/arm/configs/devkit8000_defconfig
new file mode 100644
index 000..61a817e
--- /dev/null
+++ b/arch/arm/configs/devkit8000_defconfig
@@ -0,0 +1,1889 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.33-rc6
+# Thu Feb  4 15:42:56 2010
+#
+CONFIG_ARM=y
+CONFIG_SYS_SUPPORTS_APM_EMULATION=y
+CONFIG_GENERIC_GPIO=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
+CONFIG_HARDIRQS_SW_RESEND=y
+CONFIG_GENERIC_IRQ_PROBE=y
+CONFIG_RWSEM_GENERIC_SPINLOCK=y
+CONFIG_ARCH_HAS_CPUFREQ=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
+CONFIG_VECTORS_BASE=0x
+CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+CONFIG_CONSTRUCTORS=y
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_HAVE_KERNEL_GZIP=y
+CONFIG_HAVE_KERNEL_LZO=y
+CONFIG_KERNEL_GZIP=y
+# CONFIG_KERNEL_BZIP2 is not set
+# CONFIG_KERNEL_LZMA is not set
+# CONFIG_KERNEL_LZO is not set
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+# CONFIG_POSIX_MQUEUE is not set
+CONFIG_BSD_PROCESS_ACCT=y
+# CONFIG_BSD_PROCESS_ACCT_V3 is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_TREE_RCU=y
+# CONFIG_TREE_PREEMPT_RCU is not set
+# CONFIG_TINY_RCU is not set
+# CONFIG_RCU_TRACE is not set
+CONFIG_RCU_FANOUT=32
+# CONFIG_RCU_FANOUT_EXACT is not set
+# CONFIG_TREE_RCU_TRACE is not set
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_GROUP_SCHED=y
+CONFIG_FAIR_GROUP_SCHED=y
+# CONFIG_RT_GROUP_SCHED is not set
+CONFIG_USER_SCHED=y
+# CONFIG_CGROUP_SCHED is not set
+# CONFIG_CGROUPS is not set
+# CONFIG_SYSFS_DEPRECATED_V2 is not set
+# CONFIG_RELAY is not set
+# CONFIG_NAMESPACES is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=
+CONFIG_RD_GZIP=y
+CONFIG_RD_BZIP2=y
+CONFIG_RD_LZMA=y
+# CONFIG_RD_LZO is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL=y
+CONFIG_ANON_INODES=y
+CONFIG_EMBEDDED=y
+CONFIG_UID16=y
+# CONFIG_SYSCTL_SYSCALL is not set
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+CONFIG_KALLSYMS_EXTRA_PASS=y
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_AIO=y
+
+#
+# Kernel Performance Events And Counters
+#
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_COMPAT_BRK=y
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_CLK=y
+
+#
+# GCOV-based kernel profiling
+#
+# CONFIG_SLOW_WORK is not set
+CONFIG_HAVE_GENERIC_DMA_COHERENT=y
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+CONFIG_MODVERSIONS=y
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_BLOCK=y
+CONFIG_LBDAF=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+# CONFIG_DEFAULT_DEADLINE is not set
+CONFIG_DEFAULT_CFQ=y
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED=cfq
+# CONFIG_INLINE_SPIN_TRYLOCK is not set
+# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
+# CONFIG_INLINE_SPIN_LOCK is not set
+# CONFIG_INLINE_SPIN_LOCK_BH is not set
+# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
+# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
+CONFIG_INLINE_SPIN_UNLOCK=y
+# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
+CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
+# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
+# CONFIG_INLINE_READ_TRYLOCK is not set
+# CONFIG_INLINE_READ_LOCK is not set
+# CONFIG_INLINE_READ_LOCK_BH is not set
+# CONFIG_INLINE_READ_LOCK_IRQ is not set
+# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
+CONFIG_INLINE_READ_UNLOCK=y
+# CONFIG_INLINE_READ_UNLOCK_BH is not set
+CONFIG_INLINE_READ_UNLOCK_IRQ=y
+# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
+# CONFIG_INLINE_WRITE_TRYLOCK is not set
+# CONFIG_INLINE_WRITE_LOCK is not set
+# CONFIG_INLINE_WRITE_LOCK_BH is not set
+# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
+# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set

[PATCH 23/23] OMAP3EVM: PM: Update defconfig

[Tony Lindgren]

From: Sanjeev Premi pr...@ti.com

This patch updates the omap3_evm_defconfig to
select these options:
  * CONFIG_PM_DEBUG
  * CONFIG_DEBUG_FS
  * CONFIG_OMAP_SMARTREFLEX

Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/omap3_evm_defconfig |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap3_evm_defconfig 
b/arch/arm/configs/omap3_evm_defconfig
index 86cc4be..e2ad859 100644
--- a/arch/arm/configs/omap3_evm_defconfig
+++ b/arch/arm/configs/omap3_evm_defconfig
@@ -187,6 +187,8 @@ CONFIG_ARCH_OMAP3=y
 #
 # OMAP Feature Selections
 #
+CONFIG_OMAP_SMARTREFLEX=y
+# CONFIG_OMAP_SMARTREFLEX_TESTING is not set
 # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set
 # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set
 CONFIG_OMAP_RESET_CLOCKS=y
@@ -333,7 +335,7 @@ CONFIG_BINFMT_MISC=y
 # Power management options
 #
 CONFIG_PM=y
-# CONFIG_PM_DEBUG is not set
+CONFIG_PM_DEBUG=y
 CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
@@ -1339,7 +1341,7 @@ CONFIG_ENABLE_MUST_CHECK=y
 CONFIG_FRAME_WARN=1024
 CONFIG_MAGIC_SYSRQ=y
 # CONFIG_UNUSED_SYMBOLS is not set
-# CONFIG_DEBUG_FS is not set
+CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
 # CONFIG_DEBUG_SHIRQ is not set

--
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: [PATCHv4 2/4] DSPBRIDGE: New reserved memory accounting framework

[Guzman Lugo, Fernando]

Hi,

-Original Message-
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Sent: Wednesday, February 17, 2010 12:06 PM
To: linux-omap@vger.kernel.org
Cc: felipe.contre...@nokia.com; Menon, Nishanth; Chitriki Rudramuni,
Deepak; Guzman Lugo, Fernando; Ramirez Luna, Omar
Subject: [PATCHv4 2/4] DSPBRIDGE: New reserved memory accounting framework

DSP_RSV_OBJECT is introduced to track reserved memory accounting
information.
This will allow us to do proper cleanup for memory reserved using
PROC_ReserveMemory().

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/drv.h  |   10 +
 arch/arm/plat-omap/include/dspbridge/proc.h |4 +-
 drivers/dsp/bridge/pmgr/wcd.c   |7 ++--
 drivers/dsp/bridge/rmgr/drv.c   |   18 ++
 drivers/dsp/bridge/rmgr/drv_interface.c |2 +
 drivers/dsp/bridge/rmgr/node.c  |5 ++-
 drivers/dsp/bridge/rmgr/proc.c  |   52 +--

 7 files changed, 73 insertions(+), 25 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h b/arch/arm/plat-
omap/include/dspbridge/drv.h
index d5f5277..f7d0e3e 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -101,6 +101,12 @@ struct DMM_MAP_OBJECT {
   struct DMM_MAP_OBJECT  *next;
 } ;

+/* Used for DMM reserved memory accounting */
+struct DMM_RSV_OBJECT {
+  struct  list_head   link;
+  u32 dsp_reserved_addr;
+};
+
 /* New structure (member of process context) abstracts DMM resource info
*/
 struct DSPHEAP_RES_OBJECT {
   s32heapAllocated; /* DMM status */
@@ -143,6 +149,10 @@ struct PROCESS_CONTEXT{
   struct DMM_MAP_OBJECT *dmm_map_list;
   struct mutex dmm_map_mutex;

+  /* DMM reserved memory resources */
+  struct list_head dmm_rsv_list;
+  spinlock_t dmm_rsv_lock;
+
   /* DSP Heap resources */
   struct DSPHEAP_RES_OBJECT *pDSPHEAPList;

diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h b/arch/arm/plat-
omap/include/dspbridge/proc.h
index 8dbdaac..1ffe763 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -560,7 +560,7 @@
  *  Details:
  */
   extern DSP_STATUS PROC_ReserveMemory(DSP_HPROCESSOR hProcessor,
-   u32 ulSize, void **ppRsvAddr);
+  u32 ulSize, void **ppRsvAddr, struct PROCESS_CONTEXT *pr_ctxt);

 /*
  *   PROC_UnMap 
@@ -604,6 +604,6 @@
  *  Details:
  */
   extern DSP_STATUS PROC_UnReserveMemory(DSP_HPROCESSOR hProcessor,
- void *pRsvAddr);
+  void *pRsvAddr, struct PROCESS_CONTEXT *pr_ctxt);

 #endif/* PROC_ */
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index beea23b..1ef606e 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1054,12 +1054,13 @@ u32 PROCWRAP_ReserveMemory(union Trapped_Args
*args, void *pr_ctxt)

   GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_ReserveMemory:
entered\n);
   status = PROC_ReserveMemory(args-ARGS_PROC_RSVMEM.hProcessor,
- args-ARGS_PROC_RSVMEM.ulSize, pRsvAddr);
+ args-ARGS_PROC_RSVMEM.ulSize, pRsvAddr,
+ pr_ctxt);
   if (DSP_SUCCEEDED(status)) {
   if (put_user(pRsvAddr, args-ARGS_PROC_RSVMEM.ppRsvAddr)) {
   status = DSP_EINVALIDARG;
   PROC_UnReserveMemory(args-ARGS_PROC_RSVMEM.hProcessor,
-  pRsvAddr);
+  pRsvAddr, pr_ctxt);
   }
   }
   return status;
@@ -1100,7 +1101,7 @@ u32 PROCWRAP_UnReserveMemory(union Trapped_Args
*args, void *pr_ctxt)
   GT_0trace(WCD_debugMask, GT_ENTER,
PROCWRAP_UnReserveMemory: entered\n);
   status = PROC_UnReserveMemory(args-ARGS_PROC_UNRSVMEM.hProcessor,
-   args-ARGS_PROC_UNRSVMEM.pRsvAddr);
+   args-ARGS_PROC_UNRSVMEM.pRsvAddr, pr_ctxt);
   return status;
 }

diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 9b513e2..12ba7e0 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -298,25 +298,20 @@ DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt)
   if (DSP_FAILED(status))
   pr_debug(%s: PROC_UnMap failed! status =
0x%xn, __func__, status);
-  status = PROC_UnReserveMemory(pDMMRes-hProcessor,
-   (void *)pDMMRes-ulDSPResAddr);
-  if (DSP_FAILED(status))
-  pr_debug(%s: PROC_UnReserveMemory failed!
-   

RE: [PATCHv4 4/4] DSPBRIDGE: Improved mapped memory cleanup

[Guzman Lugo, Fernando]

Hi,

-Original Message-
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Sent: Wednesday, February 17, 2010 12:06 PM
To: linux-omap@vger.kernel.org
Cc: felipe.contre...@nokia.com; Menon, Nishanth; Chitriki Rudramuni,
Deepak; Guzman Lugo, Fernando; Ramirez Luna, Omar
Subject: [PATCHv4 4/4] DSPBRIDGE: Improved mapped memory cleanup

This patch improves current mapped memory cleanup mechanism by using linux
native list implementation. As a side effect we also get following
benefits:

1. Unnecessary data members in DMM_MAP_OBJECT are removed which results in
   memory saving.

2. Following functions are removed as they are not needed anymore:
   DRV_ProcFreeDMMRes()
   DRV_UpdateDMMResElement()
   DRV_InsertDMMResElement()
   DRV_GetDMMResElement()
   DRV_RemoveDMMResElement()

Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/drv.h |   30 +---
 .../plat-omap/include/dspbridge/resourcecleanup.h  |   11 --
 drivers/dsp/bridge/rmgr/drv.c  |  161 ++--

 drivers/dsp/bridge/rmgr/drv_interface.c|3 +-
 drivers/dsp/bridge/rmgr/proc.c |   33 +++--
 5 files changed, 44 insertions(+), 194 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h b/arch/arm/plat-
omap/include/dspbridge/drv.h
index f7d0e3e..854923a 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -90,16 +90,11 @@ struct NODE_RES_OBJECT {
   struct NODE_RES_OBJECT *next;
 } ;

-/* Abstracts DMM resource info */
+/* Used for DMM mapped memory accounting */
 struct DMM_MAP_OBJECT {
-  s32dmmAllocated; /* DMM status */
-  u32   ulMpuAddr;
-  u32   ulDSPAddr;
-  u32   ulDSPResAddr;
-  u32   size;
-  HANDLE  hProcessor;
-  struct DMM_MAP_OBJECT  *next;
-} ;
+  struct  list_head   link;
+  u32 dsp_addr;
+};

 /* Used for DMM reserved memory accounting */
 struct DMM_RSV_OBJECT {
@@ -146,8 +141,8 @@ struct PROCESS_CONTEXT{
   struct mutex node_mutex;

   /* DMM mapped memory resources */
-  struct DMM_MAP_OBJECT *dmm_map_list;
-  struct mutex dmm_map_mutex;
+  struct list_head dmm_map_list;
+  spinlock_t dmm_map_lock;

   /* DMM reserved memory resources */
   struct list_head dmm_rsv_list;
@@ -398,17 +393,4 @@ struct PROCESS_CONTEXT{
   extern DSP_STATUS DRV_ReleaseResources(IN u32 dwContext,
  struct DRV_OBJECT *hDrvObject);

-/*
- *   DRV_ProcFreeDMMRes 
- *  Purpose:
- *   Actual DMM De-Allocation.
- *  Parameters:
- *  hPCtxt:  Path to the driver Registry Key.
- *  Returns:
- *  DSP_SOK if success;
- */
-
-
-  extern DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt);
-
 #endif/* DRV_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index ffbcf5e..2bb756a 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -48,17 +48,6 @@ extern DSP_STATUS DRV_RemoveNodeResElement(HANDLE
nodeRes, HANDLE status);

 extern void DRV_ProcNodeUpdateStatus(HANDLE hNodeRes, s32 status);

-extern DSP_STATUS DRV_UpdateDMMResElement(HANDLE dmmRes, u32 pMpuAddr,
-u32 ulSize, u32 pReqAddr,
-u32 ppMapAddr, HANDLE hProcesso);
-
-extern DSP_STATUS DRV_InsertDMMResElement(HANDLE dmmRes, HANDLE pCtxt);
-
-extern DSP_STATUS DRV_GetDMMResElement(u32 pMapAddr, HANDLE dmmRes,
- HANDLE pCtxt);
-
-extern DSP_STATUS DRV_RemoveDMMResElement(HANDLE dmmRes, HANDLE pCtxt);
-
 extern DSP_STATUS DRV_ProcUpdateSTRMRes(u32 uNumBufs, HANDLE STRMRes);

 extern DSP_STATUS DRV_ProcInsertSTRMResElement(HANDLE hStrm, HANDLE
STRMRes,
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index b88b5a3..bb6c246 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -193,129 +193,27 @@ static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt)
   return status;
 }

-/* Allocate the DMM resource element
-* This is called from Proc_Map. after the actual resource is allocated */
-DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE hPCtxt)
-{
-  struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
-  struct DMM_MAP_OBJECT **pDMMRes = (struct DMM_MAP_OBJECT **)hDMMRes;
-  DSP_STATUS  status = DSP_SOK;
-  struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
-
-  *pDMMRes = (struct DMM_MAP_OBJECT *)
-  MEM_Calloc(1 * sizeof(struct DMM_MAP_OBJECT), MEM_PAGED);
-  GT_0trace(curTrace, GT_ENTER, DRV_InsertDMMResElement: 1);
-  if (*pDMMRes == NULL) {
-  GT_0trace(curTrace, GT_5CLASS, 

RE: [RESEND] [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists

[Guzman Lugo, Fernando]

Hi,

-Original Message-
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Sent: Wednesday, February 17, 2010 4:55 AM
To: Guzman Lugo, Fernando
Cc: linux-omap@vger.kernel.org; Doyu Hiroshi (Nokia-D/Helsinki); Contreras
Felipe (Nokia-D/Helsinki)
Subject: Re: [RESEND] [PATCH] DSPBRIDGE: Adding protection Resource cleanup
linked lists

Hi Fernando,

On Wed, 2010-02-10 at 09:32 +0100, ext Guzman Lugo, Fernando wrote:
 Please discard previous one.

 Regards,
 Fernando.

 From 6bcdc02f6265246e385194433775e75db7ad44cf Mon Sep 17 00:00:00 2001
 From: Fernando Guzman Lugo x0095...@ti.com
 Date: Wed, 10 Feb 2010 02:31:40 -0600
 Subject: [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked
lists

 This patch protects the Resorce cleanup lists from
 concurrent access

 Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
 ---
  arch/arm/plat-omap/include/dspbridge/drv.h |3 +
  drivers/dsp/bridge/pmgr/wcd.c  |   16 ++-
  drivers/dsp/bridge/rmgr/drv.c  |   71
+++
  drivers/dsp/bridge/rmgr/drv_interface.c|8 ++-
  4 files changed, 83 insertions(+), 15 deletions(-)

 diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h b/arch/arm/plat-
omap/include/dspbridge/drv.h
 index b6a5fd2..b044291 100644
 --- a/arch/arm/plat-omap/include/dspbridge/drv.h
 +++ b/arch/arm/plat-omap/include/dspbridge/drv.h
 @@ -137,15 +137,18 @@ struct PROCESS_CONTEXT{

  /* DSP Node resources */
  struct NODE_RES_OBJECT *pNodeList;
 +struct mutex node_mutex;

  /* DMM resources */
  struct DMM_RES_OBJECT *pDMMList;
 +struct mutex dmm_mutex;

  /* DSP Heap resources */
  struct DSPHEAP_RES_OBJECT *pDSPHEAPList;

  /* Stream resources */
  struct STRM_RES_OBJECT *pSTRMList;
 +struct mutex strm_mutex;
  } ;

Is there a specific reason for using mutex instead of spin_lock?

AFAIU these locks are help for very short time, for inserting / removing
elements from linked list, or traversing a linked list.

Yes, changing mutex to spinlocks would help in performance. Let me send a patch 
to change them.

Regards,
Fernando.


Cheers,
Ameya.

--
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 5/6] Mailbox: sleeping function called from invalid context fix

[Hiroshi DOYU]

From: ext Tony Lindgren t...@atomide.com
Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid context 
fix
Date: Thu, 18 Feb 2010 02:05:10 +0100

 * Guzman Lugo, Fernando x0095...@ti.com [100215 23:22]:
 
 Hi,
 
 -Original Message-
 From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
 Sent: Monday, February 15, 2010 7:49 AM
 To: Guzman Lugo, Fernando
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid
 context fix
 
 Hi Fernando,
 
 From: ext Guzman Lugo, Fernando x0095...@ti.com
 Subject: [PATCH 5/6] Mailbox: sleeping function called from invalid context
 fix
 Date: Sat, 13 Feb 2010 02:42:16 +0100
 
  From e06b2716824f225747c4dc83ed2623d0160ae132 Mon Sep 17 00:00:00 2001
  From: Fernando Guzman Lugo x0095...@ti.com
  Date: Fri, 29 Jan 2010 17:12:24 -0600
  Subject: [PATCH] Mailbox: sleeping function called from invalid context
 fix
 
  This patch fixes this bug:
  BUG: sleeping function called from invalid context
  Inside omap2_mbox_startup is called clk_get_sys that can sleep,
  therefore omap2_mbox_startup can sleep but it is call in an atomic
  context . So the spinlock is change for a semaphore.
 
 mboxes_lock is used to maintain the global list of mailbox
 instances, which belong to a single mailbox H/W module, but they are
 logical channels from S/W perspective. Both -ops-startup() and
 -ops-shutdown() are being executed against the above single H/W
 module, and a mailbox H/W module is totally __independent__ of the
 registration of logical mailboxes, which are (un)registered with
 
 Yes, they are independent of each other, and can be executed at the same 
 time. I am agreed with your patch; that should be the right solution, so you 
 can drop my patch.
 
 Hiroshi  Fernando, if you want me to merge this series, please post
 it one more time with right patches and ack's from Hiroshi. Please
 Cc also linux-arm-kernel so it gets reviewed there. The merge window
 is about to open, so we're running out of time..

Ok, I'll take care of them.
--
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 5/6] Mailbox: sleeping function called from invalid context fix

[Guzman Lugo, Fernando]

Hi,

-Original Message-
From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
Sent: Wednesday, February 17, 2010 11:11 PM
To: t...@atomide.com
Cc: Guzman Lugo, Fernando; linux-omap@vger.kernel.org
Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid
context fix

From: ext Tony Lindgren t...@atomide.com
Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid
context fix
Date: Thu, 18 Feb 2010 02:05:10 +0100

 * Guzman Lugo, Fernando x0095...@ti.com [100215 23:22]:

 Hi,

 -Original Message-
 From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
 Sent: Monday, February 15, 2010 7:49 AM
 To: Guzman Lugo, Fernando
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid
 context fix
 
 Hi Fernando,
 
 From: ext Guzman Lugo, Fernando x0095...@ti.com
 Subject: [PATCH 5/6] Mailbox: sleeping function called from invalid
context
 fix
 Date: Sat, 13 Feb 2010 02:42:16 +0100
 
  From e06b2716824f225747c4dc83ed2623d0160ae132 Mon Sep 17 00:00:00
2001
  From: Fernando Guzman Lugo x0095...@ti.com
  Date: Fri, 29 Jan 2010 17:12:24 -0600
  Subject: [PATCH] Mailbox: sleeping function called from invalid
context
 fix
 
  This patch fixes this bug:
  BUG: sleeping function called from invalid context
  Inside omap2_mbox_startup is called clk_get_sys that can sleep,
  therefore omap2_mbox_startup can sleep but it is call in an atomic
  context . So the spinlock is change for a semaphore.
 
 mboxes_lock is used to maintain the global list of mailbox
 instances, which belong to a single mailbox H/W module, but they are
 logical channels from S/W perspective. Both -ops-startup() and
 -ops-shutdown() are being executed against the above single H/W
 module, and a mailbox H/W module is totally __independent__ of the
 registration of logical mailboxes, which are (un)registered with

 Yes, they are independent of each other, and can be executed at the same
time. I am agreed with your patch; that should be the right solution, so
you can drop my patch.

 Hiroshi  Fernando, if you want me to merge this series, please post
 it one more time with right patches and ack's from Hiroshi. Please
 Cc also linux-arm-kernel so it gets reviewed there. The merge window
 is about to open, so we're running out of time..

Ok, I'll take care of them.

Let me send the set of patches again.

Regards,
Fernando.

--
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/6] Mailbox: change mailbox version print to pr_debug

[Guzman Lugo, Fernando]

-Original Message-
From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
Sent: Wednesday, February 17, 2010 9:14 AM
To: Guzman Lugo, Fernando
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/6] Mailbox: change mailbox version print to pr_debug

Hi Fernand,

From: ext Guzman Lugo, Fernando x0095...@ti.com
Subject: [PATCH 3/6] Mailbox: change mailbox version print to pr_debug
Date: Sat, 13 Feb 2010 02:40:41 +0100

 From 60e21e76773de379deb41ff166f9679b7078276f Mon Sep 17 00:00:00 2001
 From: Fernando Guzman Lugo x0095...@ti.com
 Date: Wed, 10 Feb 2010 17:08:20 -0600
 Subject: [PATCH] Mailbox: change mailbox version print to pr_debug

 it is not useful printing the version every time mailbox is used
 instead change it to pr_debug in case someone needs to see the
 version can enable the print.

I just found that, if you put the line printing version into debug
mode, then mbox_read_reg(MAILBOX_REVISION) should be also done only
in debug mode. This value wouldn't be necessary if it didn't print.

Considering this printing again, this prints a message only when H/W
initialization is done correctly, most likely only *once* at
booting. This informs us of the result that a mailbox H/W itself is
set up and some mailbox related modules are loaded successfully. So
keeping this makes sense a little bit more rather than shutting this
completely silence.

The thing was that the tests I ran does a lot of install and uninstall bridge 
module that why I saw a lot of this print, but yes you are right in normal 
operation it should be printed once. On the other hand if this is used to state 
loaded successfully maybe the print should be changed to more meaningfully like
mailbox revision4.0 running or loaded

But, let drop this patch in this moment. I will send all the patches again.

Regards,
Fernando.

--
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