[PATCH] dspbridge: use linux memory allocator directly

[Andy Shevchenko]

From: Andy Shevchenko ext-andriy.shevche...@nokia.com

Instead of MEM_Calloc()/MEM_Free() use kzalloc()/kfree() calls. Thus we get rid
of mem.h dependency.

Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/list.h |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/list.h 
b/arch/arm/plat-omap/include/dspbridge/list.h
index c9d9e49..cda1d21 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -49,8 +49,8 @@
 #define LIST_
 
 #include dspbridge/host_os.h
-/* MEM_Calloc(), MEM_NONPAGED, MEM_Free() */
-#include dspbridge/mem.h
+#include linux/types.h
+#include linux/slab.h
 #include linux/list.h
 
 #define LST_ELEMlist_head
@@ -85,9 +85,9 @@ struct LST_LIST {
 static inline struct LST_LIST *LST_Create(void)
 {
struct LST_LIST *pList;
+   gfp_t flags = (in_atomic()) ? GFP_ATOMIC : GFP_KERNEL;
 
-   pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
-   MEM_NONPAGED);
+   pList = (struct LST_LIST *) kzalloc(sizeof(struct LST_LIST), flags);
if (pList != NULL)
INIT_LIST_HEAD(pList-head);
 
@@ -116,7 +116,7 @@ static inline struct LST_LIST *LST_Create(void)
  */
 static inline void LST_Delete(struct LST_LIST *pList)
 {
-   MEM_Free(pList);
+   kfree(pList);
 }
 
 /*
-- 
1.5.6.5

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

Re: [PATCH] dspbridge: use linux memory allocator directly

[Felipe Balbi]

Hi,

On Thu, Sep 03, 2009 at 08:48:58AM +0200, ext Andy Shevchenko wrote:
 @@ -85,9 +85,9 @@ struct LST_LIST {
  static inline struct LST_LIST *LST_Create(void)
  {
   struct LST_LIST *pList;
 + gfp_t flags = (in_atomic()) ? GFP_ATOMIC : GFP_KERNEL;
  
 - pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
 - MEM_NONPAGED);
 + pList = (struct LST_LIST *) kzalloc(sizeof(struct LST_LIST), flags);

no need for casting either :-)

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

Re: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL

[Felipe Contreras]

On Wed, Sep 02, 2009 at 06:16:26PM +0200, Hari Kanigeri wrote:
 The initial idea behind DSPProcessor_ReserveMemory call was to provide
 the User's the option of doing DSP buffer management for a pool of
 memory by themselves. So, call Reserve one time, and do map/unmap
 multiple times within that region, and call Unreserve only once you
 are done using the Buffer. But obviously that's not how this is being
 used.

And they still would be able to do that because the old ioctls are not
be removed (yet).

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

[PATCH 2/4] DSPBRIDGE: Get rid of services/list.c (step 2)

[Andy Shevchenko]

From: Andy Shevchenko ext-andriy.shevche...@nokia.com

* Use native list_empty() method instead of LST_IsEmpty() inside list.c. Remove
  extra local variables.
* Move methods from list.c as inline functions in the list.h. Get rid of list.c
  at all.
* Use list_head natively instead of LST_ELEM in the list.h.

Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/list.h |   86 ++---
 drivers/dsp/bridge/Kbuild   |2 +-
 drivers/dsp/bridge/services/list.c  |  187 ---
 3 files changed, 70 insertions(+), 205 deletions(-)
 delete mode 100644 drivers/dsp/bridge/services/list.c

diff --git a/arch/arm/plat-omap/include/dspbridge/list.h 
b/arch/arm/plat-omap/include/dspbridge/list.h
index f9bbd13..c9d9e49 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -49,14 +49,16 @@
 #define LIST_
 
 #include dspbridge/host_os.h
+/* MEM_Calloc(), MEM_NONPAGED, MEM_Free() */
+#include dspbridge/mem.h
 #include linux/list.h
 
 #define LST_ELEMlist_head
 #define LST_IsEmpty(l)  list_empty((l)-head)
 
-   struct LST_LIST {
-   struct LST_ELEM head;
-   } ;
+struct LST_LIST {
+   struct list_head head;
+};
 
 /*
  *   LST_Create 
@@ -80,7 +82,17 @@
  *  empty element, because its next and prev pointers point at
  *  the same location (the element itself).
  */
-   extern struct LST_LIST *LST_Create(void);
+static inline struct LST_LIST *LST_Create(void)
+{
+   struct LST_LIST *pList;
+
+   pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
+   MEM_NONPAGED);
+   if (pList != NULL)
+   INIT_LIST_HEAD(pList-head);
+
+   return pList;
+}
 
 /*
  *   LST_Delete 
@@ -102,7 +114,10 @@
  *  chain of list elements.  Calling this function on a non-empty list
  *  will cause a memory leak.
  */
-   extern void LST_Delete(IN struct LST_LIST *pList);
+static inline void LST_Delete(struct LST_LIST *pList)
+{
+   MEM_Free(pList);
+}
 
 /*
  *   LST_First 
@@ -118,7 +133,12 @@
  *  - pList != NULL.
  *  Ensures:
  */
-   extern struct LST_ELEM *LST_First(IN struct LST_LIST *pList);
+static inline struct list_head *LST_First(struct LST_LIST *pList)
+{
+   if (!list_empty(pList-head))
+   return pList-head.next;
+   return NULL;
+}
 
 /*
  *   LST_GetHead 
@@ -148,7 +168,19 @@
  *  the head of the list, and the head of the list points backward (its
  *  prev pointer) to the tail of the list, this list is circular.
  */
-   extern struct LST_ELEM *LST_GetHead(IN struct LST_LIST *pList);
+static inline struct list_head *LST_GetHead(struct LST_LIST *pList)
+{
+   struct list_head *pElem;
+
+   if (list_empty(pList-head))
+   return NULL;
+
+   pElem = pList-head.next;
+   pList-head.next = pElem-next;
+   pElem-next-prev = pList-head;
+
+   return pElem;
+}
 
 /*
  *   LST_InitElem 
@@ -166,7 +198,13 @@
  *  of a list chain -- that would break the chain.
  *
  */
-   extern void LST_InitElem(IN struct LST_ELEM *pListElem);
+static inline void LST_InitElem(struct list_head *pElem)
+{
+   if (pElem) {
+   pElem-next = NULL;
+   pElem-prev = NULL;
+   }
+}
 
 /*
  *   LST_InsertBefore 
@@ -184,9 +222,12 @@
  *  - pElemExisting != NULL.
  *  Ensures:
  */
-   extern void LST_InsertBefore(IN struct LST_LIST *pList,
-IN struct LST_ELEM *pElem,
-IN struct LST_ELEM *pElemExisting);
+static inline void LST_InsertBefore(struct LST_LIST *pList,
+   struct list_head *pElem,
+   struct list_head *pElemExisting)
+{
+   list_add_tail(pElem, pElemExisting);
+}
 
 /*
  *   LST_Next 
@@ -204,8 +245,13 @@
  *  - pCurElem != NULL.
  *  Ensures:
  */
-   extern struct LST_ELEM *LST_Next(IN struct LST_LIST *pList,
-IN struct LST_ELEM *pCurElem);
+static inline struct list_head *LST_Next(struct LST_LIST *pList,
+struct list_head *pCurElem)
+{
+   if (!list_empty(pList-head)  (pCurElem-next != pList-head))
+   return pCurElem-next;
+   return NULL;
+}
 
 /*
  *   LST_PutTail 
@@ -235,8 +281,10 @@
  *  tail's next pointer points at the head of the list, and the head's
  *  prev pointer points at the tail of the list), the list is circular.
  */
-   extern void LST_PutTail(IN struct LST_LIST *pList,
-   IN struct LST_ELEM *pListElem);
+static inline void LST_PutTail(struct LST_LIST *pList, struct list_head *pElem)
+{
+   list_add_tail(pElem, pList-head);
+}
 

dspbridge rfc: get rid of services/list.c (try 2)

[Andy Shevchenko]

Hello.

Here are two patches which change driver's own circular linked list
implementation to native one in linux kernel. The initial idea was come from
Hiroshi Doyu.

This version includes corrections which I got from Imre and Felipe.
Additionally the fourth patch changes LST_ELEM name to native list_head in
whole dsp bridge driver.

--
With Best Regards,
Andy Shevchenko

--
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/4] dspbridge: use linux memory allocator directly

[Andy Shevchenko]

From: Andy Shevchenko ext-andriy.shevche...@nokia.com

Instead of MEM_Calloc()/MEM_Free() use kzalloc()/kfree() calls. Thus we get rid
of mem.h dependency.

Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/list.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/list.h 
b/arch/arm/plat-omap/include/dspbridge/list.h
index c9d9e49..9efbe9c 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -49,8 +49,8 @@
 #define LIST_
 
 #include dspbridge/host_os.h
-/* MEM_Calloc(), MEM_NONPAGED, MEM_Free() */
-#include dspbridge/mem.h
+#include linux/types.h
+#include linux/slab.h
 #include linux/list.h
 
 #define LST_ELEMlist_head
@@ -85,9 +85,9 @@ struct LST_LIST {
 static inline struct LST_LIST *LST_Create(void)
 {
struct LST_LIST *pList;
+   gfp_t flags = (in_atomic()) ? GFP_ATOMIC : GFP_KERNEL;
 
-   pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
-   MEM_NONPAGED);
+   pList = kzalloc(sizeof(*pList), flags);
if (pList != NULL)
INIT_LIST_HEAD(pList-head);
 
@@ -116,7 +116,7 @@ static inline struct LST_LIST *LST_Create(void)
  */
 static inline void LST_Delete(struct LST_LIST *pList)
 {
-   MEM_Free(pList);
+   kfree(pList);
 }
 
 /*
-- 
1.5.6.5

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

[PATCH 1/4] DSPBRIDGE: Get rid of services/list.c (step 1)

[Andy Shevchenko]

From: Andy Shevchenko ext-andriy.shevche...@nokia.com

* Remove LST_Init() and LST_Exit() calls because they are doing nothing except
  tracing, Thus, remove tracing as well.

* Remove DBC_* calls. It's internal kernel business whether to have those
  assertions.

* Switch to list_head structure instead of LST_ELEM. Remove redudant code that
  uses head-self pointer.

* Use native list methods where it's possible in the list.c.

Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/list.h |   43 +--
 drivers/dsp/bridge/services/list.c  |  108 +-
 drivers/dsp/bridge/services/mem.c   |2 -
 drivers/dsp/bridge/services/services.c  |9 +--
 4 files changed, 10 insertions(+), 152 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/list.h 
b/arch/arm/plat-omap/include/dspbridge/list.h
index 2e3f995..f9bbd13 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -24,11 +24,9 @@
  *  Public Functions:
  *  LST_Create
  *  LST_Delete
- *  LST_Exit
  *  LST_First
  *  LST_GetHead
  *  LST_InitElem
- *  LST_Init
  *  LST_InsertBefore
  *  LST_IsEmpty
  *  LST_Next
@@ -51,14 +49,10 @@
 #define LIST_
 
 #include dspbridge/host_os.h
+#include linux/list.h
 
-#define LST_IsEmpty(l)  (((l)-head.next == (l)-head))
-
-   struct LST_ELEM {
-   struct LST_ELEM *next;
-   struct LST_ELEM *prev;
-   struct LST_ELEM *self;
-   } ;
+#define LST_ELEMlist_head
+#define LST_IsEmpty(l)  list_empty((l)-head)
 
struct LST_LIST {
struct LST_ELEM head;
@@ -111,20 +105,6 @@
extern void LST_Delete(IN struct LST_LIST *pList);
 
 /*
- *   LST_Exit 
- *  Purpose:
- *  Discontinue usage of module; free resources when reference count
- *  reaches 0.
- *  Parameters:
- *  Returns:
- *  Requires:
- *  LST initialized.
- *  Ensures:
- *  Resources used by module are freed when cRef reaches zero.
- */
-   extern void LST_Exit(void);
-
-/*
  *   LST_First 
  *  Purpose:
  *  Returns a pointer to the first element of the list, or NULL if the list
@@ -160,7 +140,6 @@
  *  Pointer to element that was at the head of the list (success)
  *  NULL  No elements in list
  *  Requires:
- *  - head.self must be correctly set to head.
  *  - LST initialized.
  *  - pList != NULL.
  *  Ensures:
@@ -172,19 +151,6 @@
extern struct LST_ELEM *LST_GetHead(IN struct LST_LIST *pList);
 
 /*
- *   LST_Init 
- *  Purpose:
- *  Initializes private state of LST module.
- *  Parameters:
- *  Returns:
- *  TRUE if initialized; FALSE otherwise.
- *  Requires:
- *  Ensures:
- *  LST initialized.
- */
-   extern bool LST_Init(void);
-
-/*
  *   LST_InitElem 
  *  Purpose:
  *  Initializes a list element to default (cleared) values
@@ -262,15 +228,12 @@
  *  Void
  *  Requires:
  *  *pElem and *pList must both exist.
- *  pElem-self = pElem before pElem is passed to this function.
  *  LST initialized.
  *  Ensures:
  *  Notes:
  *  Because the tail is always just before the head of the list (the
  *  tail's next pointer points at the head of the list, and the head's
  *  prev pointer points at the tail of the list), the list is circular.
- *  Warning: if pElem-self is not set beforehand, LST_GetHead() will
- *  return an erroneous pointer when it is called for this element.
  */
extern void LST_PutTail(IN struct LST_LIST *pList,
IN struct LST_ELEM *pListElem);
diff --git a/drivers/dsp/bridge/services/list.c 
b/drivers/dsp/bridge/services/list.c
index 7fa3e76..b215b68 100644
--- a/drivers/dsp/bridge/services/list.c
+++ b/drivers/dsp/bridge/services/list.c
@@ -23,10 +23,8 @@
  *  Public Functions:
  *  LST_Create
  *  LST_Delete
- *  LST_Exit
  *  LST_First
  *  LST_GetHead
- *  LST_Init
  *  LST_InitElem
  *  LST_InsertBefore
  *  LST_Next
@@ -51,21 +49,12 @@
 #include dspbridge/std.h
 #include dspbridge/dbdefs.h
 
-/*  --- Trace  Debug */
-#include dspbridge/dbc.h
-#include dspbridge/gt.h
-
 /*  --- OS Adaptation Layer */
 #include dspbridge/mem.h
 
 /*  --- This */
 #include dspbridge/list.h
 
-/*  --- Globals */
-#if GT_TRACE
-static struct GT_Mask LST_debugMask = { NULL, NULL };  /* GT trace var. */
-#endif
-
 /*
  *   LST_Create 
  *  Purpose:
@@ -75,14 +64,10 @@ struct LST_LIST *LST_Create(void)
 {
struct LST_LIST *pList;
 
-   GT_0trace(LST_debugMask, GT_ENTER, LST_Create: entered\n);
-
pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),

[PATCH 4/4] dspbridge: Change LST_ELEM to list_head entirely

[Andy Shevchenko]

From: Andy Shevchenko ext-andriy.shevche...@nokia.com

* Change struct LST_ELEM to struct list_head in whole dsp bridge driver
* Remove useless commentaries
* Minor change in the services/mem.c:
  ...
struct list_head *last = mMan.lst.head;
struct list_head *curr = last-next; /* was: mMan.lst.head.next */
  ...

Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |2 +-
 arch/arm/plat-omap/include/dspbridge/list.h |1 -
 arch/arm/plat-omap/include/dspbridge/proc.h |2 +-
 drivers/dsp/bridge/pmgr/cmm.c   |   55 +++
 drivers/dsp/bridge/pmgr/dev.c   |8 ++--
 drivers/dsp/bridge/rmgr/drv.c   |   14 +++---
 drivers/dsp/bridge/rmgr/node.c  |   10 ++--
 drivers/dsp/bridge/rmgr/rmm.c   |   16 +++---
 drivers/dsp/bridge/services/cfg.c   |2 +-
 drivers/dsp/bridge/services/mem.c   |   24 +-
 drivers/dsp/bridge/services/ntfy.c  |   12 +++---
 drivers/dsp/bridge/wmd/_msg_sm.h|4 +-
 drivers/dsp/bridge/wmd/chnl_sm.c|8 ++--
 drivers/dsp/bridge/wmd/io_sm.c  |   10 ++--
 drivers/dsp/bridge/wmd/msg_sm.c |   18 
 15 files changed, 92 insertions(+), 94 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h 
b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
index 28af799..cc768c9 100644
--- a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
@@ -197,7 +197,7 @@ struct loadMonStruct {
 
 /* I/O Request/completion packet: */
struct CHNL_IRP {
-   struct LST_ELEM link;   /* Link to next CHIRP in queue. */
+   struct list_head link;  /* Link to next CHIRP in queue.  */
/* Buffer to be filled/emptied. (User)   */
u8 *pHostUserBuf;
/* Buffer to be filled/emptied. (System) */
diff --git a/arch/arm/plat-omap/include/dspbridge/list.h 
b/arch/arm/plat-omap/include/dspbridge/list.h
index 9efbe9c..2e9eee5 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -53,7 +53,6 @@
 #include linux/slab.h
 #include linux/list.h
 
-#define LST_ELEMlist_head
 #define LST_IsEmpty(l)  list_empty((l)-head)
 
 struct LST_LIST {
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h 
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 1936a4e..3a6f820 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -68,7 +68,7 @@
 
 /* The PROC_OBJECT structure.   */
 struct PROC_OBJECT {
-   struct LST_ELEM link;   /* Link to next PROC_OBJECT */
+   struct list_head link;  /* Link to next PROC_OBJECT */
u32 dwSignature;/* Used for object validation */
struct DEV_OBJECT *hDevObject;  /* Device this PROC represents */
u32 hProcess;   /* Process owning this Processor */
diff --git a/drivers/dsp/bridge/pmgr/cmm.c b/drivers/dsp/bridge/pmgr/cmm.c
index 7dea18c..56a69f5 100644
--- a/drivers/dsp/bridge/pmgr/cmm.c
+++ b/drivers/dsp/bridge/pmgr/cmm.c
@@ -199,7 +199,7 @@ static struct CMM_XLATORATTRS CMM_DFLTXLATORATTRS = {
 
 /* SM node representing a block of memory. */
 struct CMM_MNODE {
-   struct LST_ELEM link;   /* must be 1st element */
+   struct list_head link;  /* must be 1st element */
u32 dwPA;   /* Phys addr */
u32 dwVA;   /* Virtual address in device process context */
u32 ulSize; /* SM block size in bytes */
@@ -289,7 +289,7 @@ void *CMM_CallocBuf(struct CMM_OBJECT *hCmmMgr, u32 uSize,
 
/* put our node on InUse list */
LST_PutTail(pAllocator-pInUseListHead,
-  (struct LST_ELEM *)pNode);
+  (struct list_head *) pNode);
pBufPA = (void *)pNode-dwPA;   /* physical address */
/* clear mem */
pByte = (u8 *)pNode-dwVA;
@@ -428,8 +428,6 @@ DSP_STATUS CMM_Destroy(struct CMM_OBJECT *hCmmMgr, bool 
bForce)
if (pCmmMgr-pNodeFreeListHead != NULL) {
/* Free the free nodes */
while (!LST_IsEmpty(pCmmMgr-pNodeFreeListHead)) {
-   /* (struct LST_ELEM*) pNode =
-* LST_GetHead(pCmmMgr-pNodeFreeListHead);*/
pNode = (struct CMM_MNODE *)LST_GetHead(pCmmMgr-
 pNodeFreeListHead);
MEM_Free(pNode);
@@ -496,7 +494,7 @@ DSP_STATUS CMM_FreeBuf(struct CMM_OBJECT *hCmmMgr, void 
*pBufPA, u32 ulSegId)
if ((u32)pBufPA == pCurNode-dwPA) {
/* 

Re: [PATCH 4/4] dspbridge: Change LST_ELEM to list_head entirely

[Artem Bityutskiy]

On Thu, 2009-09-03 at 12:06 +0300, Andy Shevchenko wrote:
 @@ -590,7 +589,7 @@ DSP_STATUS CMM_GetInfo(struct CMM_OBJECT *hCmmMgr,
   /* next node. */
   pCurNode = (struct CMM_MNODE *)LST_Next(pAltr-
   pInUseListHead,
 - (struct LST_ELEM *)pCurNode);
 + (struct list_head *) pCurNode);

I do not completely agree with this change. Please do not put space
between the cast and the variable. The cast kind of belongs to the
variable, so it is nicer to have no space there.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
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 4/4] dspbridge: Change LST_ELEM to list_head entirely

[Andy Shevchenko]

On Thu, Sep 3, 2009 at 12:17 PM, Artem Bityutskiydedeki...@gmail.com wrote:
 On Thu, 2009-09-03 at 12:06 +0300, Andy Shevchenko wrote:
 @@ -590,7 +589,7 @@ DSP_STATUS CMM_GetInfo(struct CMM_OBJECT *hCmmMgr,
                               /* next node. */
                               pCurNode = (struct CMM_MNODE *)LST_Next(pAltr-
                                       pInUseListHead,
 -                                     (struct LST_ELEM *)pCurNode);
 +                                     (struct list_head *) pCurNode);

 I do not completely agree with this change. Please do not put space
 between the cast and the variable. The cast kind of belongs to the
 variable, so it is nicer to have no space there.
Partially code is written in  way w/o spaces, partially in way with
space. The style of whole driver is awful.
Just for information, in our kernel:
sh-3.2$ git grep -n 'list_head *)[^ ]' | wc
110 5198630
sh-3.2$ git grep -n 'list_head *) ' | wc
 43 2363345

So, probably I will agree with you.

-- 
With Best Regards,
Andy Shevchenko
--
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 4/4] dspbridge: Change LST_ELEM to list_head entirely

[Andy Shevchenko]

On Thu, Sep 3, 2009 at 12:31 PM, Andy
Shevchenkoandy.shevche...@gmail.com wrote:
 On Thu, Sep 3, 2009 at 12:17 PM, Artem Bityutskiydedeki...@gmail.com wrote:
 On Thu, 2009-09-03 at 12:06 +0300, Andy Shevchenko wrote:
 @@ -590,7 +589,7 @@ DSP_STATUS CMM_GetInfo(struct CMM_OBJECT *hCmmMgr,
                               /* next node. */
                               pCurNode = (struct CMM_MNODE 
 *)LST_Next(pAltr-
                                       pInUseListHead,
 -                                     (struct LST_ELEM *)pCurNode);
 +                                     (struct list_head *) pCurNode);

 I do not completely agree with this change. Please do not put space
 between the cast and the variable. The cast kind of belongs to the
 variable, so it is nicer to have no space there.
 Partially code is written in  way w/o spaces, partially in way with
 space. The style of whole driver is awful.
 Just for information, in our kernel:
 sh-3.2$ git grep -n 'list_head *)[^ ]' | wc
    110     519    8630
 sh-3.2$ git grep -n 'list_head *) ' | wc
     43     236    3345
Oh, wrong regexp :-)

sh-3.2$ git grep -n 'list_head \*) ' | wc
 80 4506440
sh-3.2$ git grep -n 'list_head \*)[^ ]' | wc
 28 1702202

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

Re: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL

[Hiroshi DOYU]

Hi Hari,

From: ext Kanigeri, Hari h-kanige...@ti.com
Subject: RE: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL
Date: Wed, 2 Sep 2009 18:16:26 +0200

 The initial idea behind DSPProcessor_ReserveMemory call was to
 provide the User's the option of doing DSP buffer management for a
 pool of memory by themselves. So, call Reserve one time, and do
 map/unmap multiple times within that region, and call Unreserve only
 once you are done using the Buffer. But obviously that's not how
 this is being used.

Would it be possible to explan a little bit more about the advantage
of above use case, where it reserves onece, and maps/unmaps multiple
times?
--
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: Beagleboard B6 woes

[Mikko Rapeli]

On Mon, Aug 31, 2009 at 11:24:58AM -0500, Jon Hunter wrote:
 If UNWIND is breaking it, then the most likely cause is that you are  
 using an older toolchain, such as code-sourcery 2007q3. If you are using  
  2007q3, upgrade to a 2008 or 2009 release. More details here:

 http://marc.info/?l=linux-omapm=124175324604568w=2

I'm using Maemo SDK so cs2007q3-glibc2.5-arm7 it is. I'll give newer tool
chains a try.

 On the other hand, setting ARM_UNWIND to n which falls back to FRAME_POINTERs
 work until 84e250ffa76dddc1bad84e04248a27f442c25986 musb: proper 
 hookup to transceiver drivers.

 You could trying enabling CONFIG_TWL4030_USB to see if this helps.

This is already set and doesn't help.

Well, at least v2.6.29-omap1 from linux-omap tree works on my Beagle.

Thanks.

-Mikko
--
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] dspbridge: Change LST_ELEM to list_head entirely

[Andy Shevchenko]

From: Andy Shevchenko ext-andriy.shevche...@nokia.com

* Change struct LST_ELEM to struct list_head in whole dsp bridge driver
* Remove useless commentaries
* Minor change in the services/mem.c:
  ...
struct list_head *last = mMan.lst.head;
struct list_head *curr = last-next; /* was: mMan.lst.head.next */
  ...

Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
 arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |2 +-
 arch/arm/plat-omap/include/dspbridge/list.h |1 -
 arch/arm/plat-omap/include/dspbridge/proc.h |2 +-
 drivers/dsp/bridge/pmgr/cmm.c   |   55 +++
 drivers/dsp/bridge/pmgr/dev.c   |8 ++--
 drivers/dsp/bridge/rmgr/drv.c   |   14 +++---
 drivers/dsp/bridge/rmgr/node.c  |   10 ++--
 drivers/dsp/bridge/rmgr/rmm.c   |   16 +++---
 drivers/dsp/bridge/services/cfg.c   |2 +-
 drivers/dsp/bridge/services/mem.c   |   26 +-
 drivers/dsp/bridge/services/ntfy.c  |   12 +++---
 drivers/dsp/bridge/wmd/_msg_sm.h|4 +-
 drivers/dsp/bridge/wmd/chnl_sm.c|   12 +++---
 drivers/dsp/bridge/wmd/io_sm.c  |   10 ++--
 drivers/dsp/bridge/wmd/msg_sm.c |   21 -
 15 files changed, 96 insertions(+), 99 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h 
b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
index 28af799..cc768c9 100644
--- a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
@@ -197,7 +197,7 @@ struct loadMonStruct {
 
 /* I/O Request/completion packet: */
struct CHNL_IRP {
-   struct LST_ELEM link;   /* Link to next CHIRP in queue. */
+   struct list_head link;  /* Link to next CHIRP in queue.  */
/* Buffer to be filled/emptied. (User)   */
u8 *pHostUserBuf;
/* Buffer to be filled/emptied. (System) */
diff --git a/arch/arm/plat-omap/include/dspbridge/list.h 
b/arch/arm/plat-omap/include/dspbridge/list.h
index 9efbe9c..2e9eee5 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -53,7 +53,6 @@
 #include linux/slab.h
 #include linux/list.h
 
-#define LST_ELEMlist_head
 #define LST_IsEmpty(l)  list_empty((l)-head)
 
 struct LST_LIST {
diff --git a/arch/arm/plat-omap/include/dspbridge/proc.h 
b/arch/arm/plat-omap/include/dspbridge/proc.h
index 1936a4e..3a6f820 100644
--- a/arch/arm/plat-omap/include/dspbridge/proc.h
+++ b/arch/arm/plat-omap/include/dspbridge/proc.h
@@ -68,7 +68,7 @@
 
 /* The PROC_OBJECT structure.   */
 struct PROC_OBJECT {
-   struct LST_ELEM link;   /* Link to next PROC_OBJECT */
+   struct list_head link;  /* Link to next PROC_OBJECT */
u32 dwSignature;/* Used for object validation */
struct DEV_OBJECT *hDevObject;  /* Device this PROC represents */
u32 hProcess;   /* Process owning this Processor */
diff --git a/drivers/dsp/bridge/pmgr/cmm.c b/drivers/dsp/bridge/pmgr/cmm.c
index 7dea18c..51b5127 100644
--- a/drivers/dsp/bridge/pmgr/cmm.c
+++ b/drivers/dsp/bridge/pmgr/cmm.c
@@ -199,7 +199,7 @@ static struct CMM_XLATORATTRS CMM_DFLTXLATORATTRS = {
 
 /* SM node representing a block of memory. */
 struct CMM_MNODE {
-   struct LST_ELEM link;   /* must be 1st element */
+   struct list_head link;  /* must be 1st element */
u32 dwPA;   /* Phys addr */
u32 dwVA;   /* Virtual address in device process context */
u32 ulSize; /* SM block size in bytes */
@@ -289,7 +289,7 @@ void *CMM_CallocBuf(struct CMM_OBJECT *hCmmMgr, u32 uSize,
 
/* put our node on InUse list */
LST_PutTail(pAllocator-pInUseListHead,
-  (struct LST_ELEM *)pNode);
+  (struct list_head *)pNode);
pBufPA = (void *)pNode-dwPA;   /* physical address */
/* clear mem */
pByte = (u8 *)pNode-dwVA;
@@ -428,8 +428,6 @@ DSP_STATUS CMM_Destroy(struct CMM_OBJECT *hCmmMgr, bool 
bForce)
if (pCmmMgr-pNodeFreeListHead != NULL) {
/* Free the free nodes */
while (!LST_IsEmpty(pCmmMgr-pNodeFreeListHead)) {
-   /* (struct LST_ELEM*) pNode =
-* LST_GetHead(pCmmMgr-pNodeFreeListHead);*/
pNode = (struct CMM_MNODE *)LST_GetHead(pCmmMgr-
 pNodeFreeListHead);
MEM_Free(pNode);
@@ -496,7 +494,7 @@ DSP_STATUS CMM_FreeBuf(struct CMM_OBJECT *hCmmMgr, void 
*pBufPA, u32 ulSegId)
if ((u32)pBufPA == pCurNode-dwPA) {
/* 

RE: [RFC] Common mechanism to identify Si revision

[Premi, Sanjeev]

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
 Sent: Thursday, September 03, 2009 4:14 PM
 To: linux-omap@vger.kernel.org
 Subject: [RFC] Common mechanism to identify Si revision
 
 Hi,
 
 Currently there are multiple mechanisms for identifying the 
 si revisions.
 
 Most places the comparison is against omap_rev() as a whole 
 number. Example:
 
 arch/arm/mach-omap2/board-3430sdp.c:695:if (omap_rev()  
 OMAP3430_REV_ES1_0)
 arch/arm/mach-omap2/board-3430sdp.c:728:if (omap_rev()  
 OMAP3430_REV_ES1_0)
 
 Then, there are custom macros. Example (cpu.h):
 
 #define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1)
 #define CHIP_GE_OMAP3430ES3   (CHIP_IS_OMAP3430ES3_0 | \
CHIP_GE_OMAP3430ES3_1)
 #define CHIP_GE_OMAP3430ES2   (CHIP_IS_OMAP3430ES2 | \
CHIP_GE_OMAP3430ES3)
 
 The problem with comparing against a whole number is that 
 comparison is invalid
 for another processor series. E.g. OMAP3430 and OMAP3517.
 
 Here, I am proposing a common mechanism to identify the si 
 revision; that focuses
 on the revision bits alone. (See code below)
 
 The usage would then be (example):
 
if (omap_rev()  OMAP3430_REV_ES1_0)
 
 To
 
if (cpu_is_omap34xx()  OMAP_REV_GT(OMAP_ES_1_0)
 
 
 Though I have not looked at the OMAP1 directory, I am 
 assuming similar case there.
 Since there aren't any new devices in the OMAP1 category, 
 this may not appear as
 a need. But consistency could help.
 
 Few items that I feel need to be looked at:
 - Possible differences in the MASK defined for Si revision.
   Irrespective of (possible) difference in the HW, the bits 
 in 'omap_revision' can
   be same.
 
 - How to phase in the change - one shot OR in steps.
 
 I am not sending this as patch, for now; just to get the 
 discussion started.
 
 Best regards,
 Sanjeev
 

[sp] sorry, missed the return statement in the inline functions below:
 ... perils of writing code in mail :)

~sanjeev

 
 (cpu.h)
 
 /*
  * Identify silicon revision.
  */
 #define OMAP_REV_MASK 0xff00
 
 #define OMAP_ES_1_0   0x00
 #define OMAP_ES_2_0   0x10
 #define OMAP_ES_2_1   0x20
 #define OMAP_ES_3_0   0x30
 #define OMAP_ES_3_1   0x40
 
 #define OMAP_REV_IS(revid)
   \
 static inline u8 omap_rev_is_ ##revid (void)  
   \
 { 
   \
   (((omap_rev()  OMAP_REV_MASK)  8) == revid) ? 1 : 0 
 ; \
 }
 
 #define OMAP_REV_LT(revid)
   \
 static inline u8 omap_rev_lt_ ##revid (void)  
   \
 { 
   \
   (((omap_rev()  OMAP_REV_MASK)  8)  revid) ? 1 : 0 ; \
 }
 
 #define OMAP_REV_LE(revid)
   \
 static inline u8 omap_rev_le_ ##revid (void)  
   \
 { 
   \
   (((omap_rev()  OMAP_REV_MASK)  8) = revid) ? 1 : 0 
 ; \
 }
 
 #define OMAP_REV_GE(revid)
   \
 static inline u8 omap_rev_ge_ ##revid (void)  
   \
 { 
   \
   (((omap_rev()  OMAP_REV_MASK)  8) = revid) ? 1 : 0 
 ; \
 }
 
 #define OMAP_REV_GT(revid)
   \
 static inline u8 omap_rev_gt_ ##revid (void)  
   \
 { 
   \
   (((omap_rev()  OMAP_REV_MASK)  8)  revid) ? 1 : 0 ; \
 }
 
 OMAP_REV_IS(OMAP_ES_1_0)
 OMAP_REV_LT(OMAP_ES_1_0)
 OMAP_REV_LE(OMAP_ES_1_0)
 OMAP_REV_GT(OMAP_ES_1_0)
 OMAP_REV_GE(OMAP_ES_1_0)
 
 OMAP_REV_IS(OMAP_ES_2_0)
 OMAP_REV_LT(OMAP_ES_2_0)
 OMAP_REV_LE(OMAP_ES_2_0)
 OMAP_REV_GT(OMAP_ES_2_0)
 OMAP_REV_GE(OMAP_ES_2_0)
 
 OMAP_REV_IS(OMAP_ES_2_1)
 OMAP_REV_LT(OMAP_ES_2_1)
 OMAP_REV_LE(OMAP_ES_2_1)
 OMAP_REV_GT(OMAP_ES_2_1)
 OMAP_REV_GE(OMAP_ES_2_1)
 
 OMAP_REV_IS(OMAP_ES_3_0)
 OMAP_REV_LT(OMAP_ES_3_0)
 OMAP_REV_LE(OMAP_ES_3_0)
 OMAP_REV_GT(OMAP_ES_3_0)
 OMAP_REV_GE(OMAP_ES_3_0)
 
 OMAP_REV_IS(OMAP_ES_3_1)
 OMAP_REV_LT(OMAP_ES_3_1)
 OMAP_REV_LE(OMAP_ES_3_1)
 OMAP_REV_GT(OMAP_ES_3_1)
 OMAP_REV_GE(OMAP_ES_3_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
 
 --
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 00/18] OMAP: DSS2: Intro

[Tomi Valkeinen]

Hi,

On Thu, 2009-09-03 at 00:11 +0200, ext Andrew Morton wrote:
 On Tue, 01 Sep 2009 10:10:19 +0300
 Artem Bityutskiy dedeki...@gmail.com wrote:
 
  Andrew,
  
  could you please help with merging this piece of (well written) code?
  Could you give your blessing to include it into linux-next now, and
  merge this during the next merge window?
 
 I'll merge them (after I've looked through them, which I'll do now).  
 
 But there are more rejects than I'm prepared to cope with.  The various
 arch/arm files have undergone some changes in linux-next which yield
 more breakage than I'm prepared to try to fix.  For example,
 arch/arm/mach-omap2/board-3430sdp.c:sdp3430_config[] ends up being an
 empty array!

I rebased the patches on top of linux-next. The tree is at
http://gitorious.org/linux-omap-dss2/linux , in branch linux-next-dss.

The only conflict was in board-3430sdp, and yes, sdp3430_config is
supposed to end up as an empty array. 

 Then there's the matter of these patches, already in -mm:
 
 omapfb-add-support-for-the-apollon-lcd.patch
 omapfb-add-support-for-mipi-dcs-compatible-lcds.patch
 omapfb-add-support-for-the-amstrad-delta-lcd.patch
 omapfb-add-support-for-the-2430sdp-lcd.patch
 omapfb-add-support-for-the-omap2evm-lcd.patch
 omapfb-add-support-for-the-3430sdp-lcd.patch
 omapfb-add-support-for-the-omap3-evm-lcd.patch
 omapfb-add-support-for-the-omap3-beagle-dvi-output.patch
 omapfb-add-support-for-the-gumstix-overo-lcd.patch
 omapfb-add-support-for-the-zoom-mdk-lcd.patch
 omapfb-add-support-for-rotation-on-the-blizzard-lcd-ctrl.patch
 n770-enable-lcd-mipi-dcs-in-kconfig.patch
 omapfb-dispc-various-typo-fixes.patch
 omapfb-dispc-disable-iface-clocks-along-with-func-clocks.patch
 omapfb-dispc-enable-wake-up-capability.patch
 omapfb-dispc-allow-multiple-external-irq-handlers.patch
 omapfb-suspend-resume-only-if-fb-device-is-already-initialized.patch
 omapfb-fix-coding-style-remove-dead-line.patch
 omapfb-add-fb-manual-update-option-to-kconfig.patch
 omapfb-hwa742-fix-pointer-to-be-const.patch

These are not in linux-next, I think. They are for the old OMAP display
subsystem, and may cause some conflicts with DSS2. I think those patches
should go in also, as the old driver is used for OMAP1 and fo all the
other boards that have not been ported to use DSS2.

Should I rebase DSS2 on top of -mm and solve the conflicts? If so, where
can I find your tree?

 Tomi


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

[PATCH] DSPBRIDGE: remove unsed piece of code

[Andy Shevchenko]

From: Andy Shevchenko ext-andriy.shevche...@nokia.com

I doubt about usefulness of removed piece of code. But it seems to be not used
because of unchanged value of bJustWokeDSP.

Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
 drivers/dsp/bridge/rmgr/node.c |   17 -
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index e213b22..a156182 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -1278,7 +1278,6 @@ DSP_STATUS NODE_Create(struct NODE_OBJECT *hNode)
enum NODE_TYPE nodeType;
DSP_STATUS status = DSP_SOK;
DSP_STATUS status1 = DSP_SOK;
-   bool bJustWokeDSP = false;
struct DSP_CBDATA cbData;
u32 procId = 255;
struct DSP_PROCESSORSTATE procStatus;
@@ -1429,22 +1428,6 @@ func_cont2:
/* Put back in NODE_ALLOCATED state if error occurred */
NODE_SetState(hNode, NODE_ALLOCATED);
}
-   if (procId == DSP_UNIT) {
-   /* If node create failed, see if should sleep DSP now */
-   if (bJustWokeDSP == true) {
-   /* Check to see if partial create happened on DSP */
-   if (hNode-nodeEnv == (u32)NULL) {
-   /* No environment allocated on DSP, re-sleep
-* DSP now */
-   PROC_Ctrl(hNode-hProcessor, WMDIOCTL_DEEPSLEEP,
-cbData);
-   } else {
-   /* Increment count, sleep later when node fully
-* deleted */
-   hNodeMgr-uNumCreated++;
-   }
-   }
-   }
 func_cont:
/* Free access to node dispatcher */
(void)SYNC_LeaveCS(hNodeMgr-hSync);
-- 
1.5.6.5

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

[PATCH] musb: Add context save and restore support

[Ajay Kumar Gupta]

Adding support for MUSB register save and restore during system
suspend and resume.

Changes:
- Added musb_save/restore_context() functions
- Added platform specific musb_platform_save/restore_context()
  to handle platform specific jobs.
- Maintaining BlackFin compatibility by adding read/write
  functions for registers which are not available in BlackFin

Tested system suspend and resume on OMAP3EVM board.

Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
 drivers/usb/musb/musb_core.c |  157 +-
 drivers/usb/musb/musb_core.h |   39 ++
 drivers/usb/musb/musb_regs.h |   90 
 drivers/usb/musb/omap2430.c  |   16 
 4 files changed, 300 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c7c1ca0..4797e21 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2167,20 +2167,169 @@ static int __devexit musb_remove(struct 
platform_device *pdev)
 
 #ifdef CONFIG_PM
 
+static struct musb_context_registers musb_context;
+
+void musb_save_context(void __iomem *musb_base)
+{
+   int i;
+
+   musb_platform_save_context(musb_context);
+
+   musb_context.faddr = musb_readb(musb_base, MUSB_FADDR);
+   musb_context.power = musb_readb(musb_base, MUSB_POWER);
+   musb_context.intrtx = musb_readw(musb_base, MUSB_INTRTX);
+   musb_context.intrrx = musb_readw(musb_base, MUSB_INTRRX);
+   musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
+   musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE);
+   musb_context.intrusb = musb_readb(musb_base, MUSB_INTRUSB);
+   musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);
+   musb_context.frame = musb_readw(musb_base, MUSB_FRAME);
+   musb_context.index = musb_readb(musb_base, MUSB_INDEX);
+   musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE);
+   musb_context.devctl = musb_readb(musb_base, MUSB_DEVCTL);
+
+   for (i = 0; i  MUSB_C_NUM_EPS; ++i) {
+   musb_writeb(musb_base, MUSB_INDEX, i);
+   musb_context.index_regs[i].txmaxp =
+   musb_readw(musb_base, 0x10 + MUSB_TXMAXP);
+   musb_context.index_regs[i].txcsr =
+   musb_readw(musb_base, 0x10 + MUSB_TXCSR);
+   musb_context.index_regs[i].rxmaxp =
+   musb_readw(musb_base, 0x10 + MUSB_RXMAXP);
+   musb_context.index_regs[i].rxcsr =
+   musb_readw(musb_base, 0x10 + MUSB_RXCSR);
+   musb_context.index_regs[i].rxcount =
+   musb_readw(musb_base, 0x10 + MUSB_RXCOUNT);
+   musb_context.index_regs[i].txtype =
+   musb_readb(musb_base, 0x10 + MUSB_TXTYPE);
+   musb_context.index_regs[i].txinterval =
+   musb_readb(musb_base, 0x10 + MUSB_TXINTERVAL);
+   musb_context.index_regs[i].rxtype =
+   musb_readb(musb_base, 0x10 + MUSB_RXTYPE);
+   musb_context.index_regs[i].rxinterval =
+   musb_readb(musb_base, 0x10 + MUSB_RXINTERVAL);
+
+   musb_context.index_regs[i].txfifoadd =
+   musb_read_txfifoadd(musb_base);
+   musb_context.index_regs[i].rxfifoadd =
+   musb_read_rxfifoadd(musb_base);
+   musb_context.index_regs[i].txfifosz =
+   musb_read_txfifosz(musb_base);
+   musb_context.index_regs[i].rxfifosz =
+   musb_read_rxfifosz(musb_base);
+
+   musb_context.index_regs[i].txfunaddr =
+   musb_read_txfunaddr(musb_base, i);
+   musb_context.index_regs[i].txhubaddr =
+   musb_read_txhubaddr(musb_base, i);
+   musb_context.index_regs[i].txhubport =
+   musb_read_txhubport(musb_base, i);
+
+   musb_context.index_regs[i].rxfunaddr =
+   musb_read_rxfunaddr(musb_base, i);
+   musb_context.index_regs[i].rxhubaddr =
+   musb_read_rxhubaddr(musb_base, i);
+   musb_context.index_regs[i].rxhubport =
+   musb_read_rxhubport(musb_base, i);
+   }
+
+   musb_writeb(musb_base, MUSB_INDEX, musb_context.index);
+}
+
+void musb_restore_context(void __iomem *musb_base)
+{
+   int i;
+   void __iomem *ep_target_regs;
+
+   musb_writeb(musb_base, MUSB_FADDR, musb_context.faddr);
+   musb_writeb(musb_base, MUSB_POWER, musb_context.power);
+   musb_writew(musb_base, MUSB_INTRTX, musb_context.intrtx);
+   musb_writew(musb_base, MUSB_INTRRX, musb_context.intrrx);
+   musb_writew(musb_base, MUSB_INTRTXE, musb_context.intrtxe);
+   musb_writew(musb_base, 

Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)

[Kevin Hilman]

Mike Chan m...@android.com writes:

 On Tue, Aug 18, 2009 at 8:04 AM, Kevin
 Hilmankhil...@deeprootsystems.com wrote:
 Wang Limei-E12499 e12...@motorola.com writes:

 Seems like I did not submit the patch in the right way, before I setup
 my mail correctly, attach the patches in the mail.

 You're patches are still line-wrapped.

 I strongly recommend using git-format-patch and git-send-email to
 submit patches. Chunqiu was able to do this.  Please consult him.

 Also, no need to CC linux-omap-owner.  linux-omap is all that is needed.


 This patch has been reviewed and merged into our android-omap-2.6.29 tree
 http://android.git.kernel.org/?p=kernel/omap.git;a=commit;h=0b6a9b6514c7ccfa0c76e4defdaea3dcbc617633

Hmm, I don't see any other review/signoff that the authors on that
link.

 Kevin if you're having line wrap problems feel free to pull it from
 here, assuming everyone's feedback has been addressed

It's not me who has the line-wrap problem. I could unwrap pretty
easily myself, but it gets very old working around various email
client problems, so I choose to reject patches until they can be sent
in a usable form. 

I'm still waiting for this so it can get a full review on-list.

Thanks,

Kevin


 Thanks,

 Kevin


 PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch

 From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
 From: Chunqiu Wang cqw...@motorola.com
 Date: Fri, 14 Aug 2009 17:34:32 +0800
 Subject: [PATCH] Add per-resource mutex for OMAP resource framework

 Current OMAP resource fwk uses a global res_mutex
 for resource_request and resource_release calls
 for all the available resources.It may cause dead
 lock if resource_request/resource_release is called
 recursively.

 For current OMAP3 VDD1/VDD2 resource, the change_level
 implementation is mach-omap2/resource34xx.c/set_opp(),
 when using resource_release to remove vdd1 constraint,
 this function may call resource_release again to release
 Vdd2 constrait if target vdd1 level is less than OPP3.
 in this scenario, the global res_mutex down operation
 will be called again, this will cause the second
 down operation hang there.

 To fix the problem, per-resource mutex is added
 to avoid hangup when resource_request/resource_release
 is called recursively.

 Signed-off-by: Chunqiu Wang cqw...@motorola.com
 ---
  arch/arm/plat-omap/include/mach/resource.h |    2 ++
  arch/arm/plat-omap/resource.c              |   27
 +++
  2 files changed, 17 insertions(+), 12 deletions(-)

 diff --git a/arch/arm/plat-omap/include/mach/resource.h
 b/arch/arm/plat-omap/include/mach/resource.h
 index f91d8ce..d482fb8 100644
 --- a/arch/arm/plat-omap/include/mach/resource.h
 +++ b/arch/arm/plat-omap/include/mach/resource.h
 @@ -46,6 +46,8 @@ struct shared_resource {
       /* Shared resource operations */
       struct shared_resource_ops *ops;
       struct list_head node;
 +     /* Protect each resource */
 +     struct mutex resource_mutex;
  };

  struct shared_resource_ops {
 diff --git a/arch/arm/plat-omap/resource.c
 b/arch/arm/plat-omap/resource.c
 index ec31727..5eae4e8 100644
 --- a/arch/arm/plat-omap/resource.c
 +++ b/arch/arm/plat-omap/resource.c
 @@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
               return -EEXIST;

       INIT_LIST_HEAD(resp-users_list);
 +     mutex_init(resp-resource_mutex);

       down(res_mutex);
       /* Add the resource to the resource list */
 @@ -326,14 +327,14 @@ int resource_request(const char *name, struct
 device *dev,
       struct  users_list *user;
       int     found = 0, ret = 0;

 -     down(res_mutex);
 -     resp = _resource_lookup(name);
 +     resp = resource_lookup(name);
       if (!resp) {
               printk(KERN_ERR resource_request: Invalid resource
 name\n);
               ret = -EINVAL;
 -             goto res_unlock;
 +             goto ret;
       }

 +     mutex_lock(resp-resource_mutex);
       /* Call the resource specific validate function */
       if (resp-ops-validate_level) {
               ret = resp-ops-validate_level(resp, level);
 @@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
 *dev,
       user-level = level;

  res_unlock:
 -     up(res_mutex);
 +     mutex_unlock(resp-resource_mutex);
       /*
        * Recompute and set the current level for the resource.
        * NOTE: update_resource level moved out of spin_lock, as it may
 call
 @@ -371,6 +372,7 @@ res_unlock:
        */
       if (!ret)
               ret = update_resource_level(resp);
 +ret:
       return ret;
  }
  EXPORT_SYMBOL(resource_request);
 @@ -393,14 +395,14 @@ int resource_release(const char *name, struct
 device *dev)
       struct users_list *user;
       int found = 0, ret = 0;

 -     down(res_mutex);
 -     resp = _resource_lookup(name);
 +     resp = resource_lookup(name);
       if (!resp) {
               printk(KERN_ERR resource_release: Invalid resource
 name\n);
               ret = 

Re: RT tests on OMAP3

[Kevin Hilman]

Cliff Brake cliff.br...@gmail.com writes:

 On Mon, Aug 31, 2009 at 11:16 PM, Cliff Brakecliff.br...@gmail.com wrote:

 Applying

 http://cgit.openembedded.org/cgit.cgi/openembedded/diff/recipes/linux/linux-omap-2.6.29/0001-implement-TIF_RESTORE_SIGMASK-support-and-enable-the.patch?id=1f0d91e152f16fbd40bb2fb3c44a30d774d4dede

 Seems to fix or mask the udev problems.  But, with preempt-rt, and
 EHCI enabled, I still get messages continually scrolling:

 A few more notes, the above patch is not required to make the PXA270
 work.  Without EHCI enabled, the system boots and performs fairly
 normal (I'm able to log in, etc).

This looks to me like a case of poor (or non-existent) locking in the
USB/EHCI driver, resulting in some corruption since the PC is at a
bogus address (0x14).

Does your PXA270 use the same EHCI driver?  I assume not.

I've been using -rt on a basic OMAP3 kernel, but have not enabled
EHCI so haven't seen this.

Might be useful to enable some of the in-kernel lock debugging to
see if it turns up anything.

Kevin

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

Re: RT tests on OMAP3

[Koen Kooi]

Op 1 sep 2009, om 05:16 heeft Cliff Brake het volgende geschreven:

On Mon, Aug 31, 2009 at 4:50 PM, Cliff Brakecliff.br...@gmail.com  
wrote:

Hello,

I'm trying to run 2.6.31-rc8-rt9-omap1 on a OMAP3 cpu.  So far, it
seems fairly unstable:

http://www.bec-systems.com/omap-rt-tests/

2.6.31-rc8-rt9 boots and runs well on a PXA270.

The following mail also references udev failures:
http://lkml.org/lkml/2009/8/11/250


A few more observations:

Applying

http://cgit.openembedded.org/cgit.cgi/openembedded/diff/recipes/linux/linux-omap-2.6.29/0001-implement-TIF_RESTORE_SIGMASK-support-and-enable-the.patch?id=1f0d91e152f16fbd40bb2fb3c44a30d774d4dede


If people want to push that upstream, please do so, I only updated the  
patch to a more recent kernel but don't have the time nor skills to  
make it suitable for upstream.


regards,

KOen
--
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] mfd: restoring twl4030 power-off and power-button capabilities

[vimal singh]

This patch series restores the TWL Power-button and Power-off capabilities.
Which were removed in REMOVE OMAP LEGACY CODE patches.

Patches are compile tested only.

[PATCH 1/2]: twl4030: register twl4030-pwrbuttonas a child of twl4030-core.c
[PATCH 2/2]: twl4030: initialization of pm_power_off in twl4030-core.c

Both patches are based on Felipe Balbi's patches posted earlier.
http://lkml.org/lkml/2009/2/28/88
http://markmail.org/message/ts4if3553qnauket

--
Vimal




--
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]: twl4030: register twl4030-pwrbuttonas a child of twl4030-core.c

[vimal singh]

'twl4030-pwrbutton' was already made as a platform_driver so it can
be registered as a child of twl4030-core.c.

But adding twl4030-pwrbutton as our child in twl4030-core is missing
currently. This patch adds it.

Signed-off-by: Vimal Singh vimalsi...@ti.com
CC: Felipe Balbi felipe.ba...@nokia.com
Cc: Samuel Ortiz sa...@openedhand.com
Cc: David Brownell dbrown...@users.sourceforge.net
---
This patch is compile tested only.
This patch is based on Felipe Balbi's patch posted earlier:
http://lkml.org/lkml/2009/2/28/88

 drivers/mfd/twl4030-core.c |   14 ++
 1 files changed, 14 insertions(+)

Index: linux-omap-2.6/drivers/mfd/twl4030-core.c
===
--- linux-omap-2.6.orig/drivers/mfd/twl4030-core.c
+++ linux-omap-2.6/drivers/mfd/twl4030-core.c
@@ -108,6 +108,13 @@
 #define twl_has_watchdog()false
 #endif

+#if defined(CONFIG_INPUT_TWL4030_PWRBUTTON) \
+   || defined(CONFIG_INPUT_TWL4030_PWRBUTTON_MODULE)
+#define twl_has_pwrbutton()true
+#else
+#define twl_has_pwrbutton()false
+#endif
+
 /* Triton Core internal information (BEGIN) */

 /* Last - for index max*/
@@ -538,6 +545,13 @@ add_children(struct twl4030_platform_dat
return PTR_ERR(child);
}

+   if (twl_has_pwrbutton()) {
+   child = add_child(1, twl4030_pwrbutton,
+   NULL, 0, true, pdata-irq_base + 8 + 0, 0);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
+   }
+
if (twl_has_regulator()) {
/*
child = add_regulator(TWL4030_REG_VPLL1, pdata-vpll1);


--
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]: twl4030: initialize pm_power_off in twl4030-core.c

[vimal singh]

'twl4030-poweroff' module was removed sometime back. This patch adds back
this capability.
We don't really need a whole new driver just for initializing one pointer.
Initialize pm_power_off in twl4030-core.c

Signed-off-by: Vimal Singh vimalsi...@ti.com
CC: Felipe Balbi felipe.ba...@nokia.com
---
This patch is compile tested only.
This patch is based on Felipe Balbi's patch posted earlier:
http://markmail.org/message/ts4if3553qnauket

 drivers/mfd/twl4030-core.c |   31 +++
 1 files changed, 31 insertions(+)

Index: linux-omap-2.6/drivers/mfd/twl4030-core.c
===
--- linux-omap-2.6.orig/drivers/mfd/twl4030-core.c
+++ linux-omap-2.6/drivers/mfd/twl4030-core.c
@@ -178,6 +178,10 @@
 #define TWL4030_VAUX2  BIT(0)  /* pre-5030 voltage ranges */
 #define TPS_SUBSET BIT(1)  /* tps659[23]0 have fewer LDOs */

+/* for pm_power_off */
+#define PWR_P1_SW_EVENTS   0x10
+#define PWR_DEVOFF (1  0)
+
 /*--*/

 /* is driver active, bound to a chip? */
@@ -754,6 +758,30 @@ static int twl4030_remove(struct i2c_cli
return 0;
 }

+static void twl4030_poweroff(void)
+{
+   int err;
+   u8 val;
+
+   err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_MASTER, val,
+ PWR_P1_SW_EVENTS);
+   if (err) {
+   pr_err(%s: i2c error %d while reading TWL4030
+   PM_MASTER P1_SW_EVENTS\n,
+   DRIVER_NAME, err);
+   return;
+   }
+
+   val |= PWR_DEVOFF;
+
+   err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, val,
+  PWR_P1_SW_EVENTS);
+   if (err)
+   pr_err(%s: i2c error %d while writing TWL4030
+   PM_MASTER P1_SW_EVENTS\n,
+   DRIVER_NAME, err);
+}
+
 /* NOTE:  this driver only handles a single twl4030/tps659x0 chip */
 static int
 twl4030_probe(struct i2c_client *client, const struct i2c_device_id *id)
@@ -811,6 +839,9 @@ twl4030_probe(struct i2c_client *client,
goto fail;
}

+   /* initialize pm_power_off routine */
+   pm_power_off = twl4030_poweroff;
+
status = add_children(pdata, id-driver_data);
 fail:
if (status  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

Re: RT tests on OMAP3

[Cliff Brake]

On Thu, Sep 3, 2009 at 10:44 AM, Koen Kooik.k...@student.utwente.nl wrote:

 http://cgit.openembedded.org/cgit.cgi/openembedded/diff/recipes/linux/linux-omap-2.6.29/0001-implement-TIF_RESTORE_SIGMASK-support-and-enable-the.patch?id=1f0d91e152f16fbd40bb2fb3c44a30d774d4dede

 If people want to push that upstream, please do so, I only updated the patch
 to a more recent kernel but don't have the time nor skills to make it
 suitable for upstream.

I think this is already queued:

http://www.spinics.net/lists/arm-kernel/msg72676.html

Cliff
--
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] OMAP4: MMC driver support on OMAP4

[kishore kadiyala]

On Wed, Sep 2, 2009 at 10:00 PM, Madhusudhan madhu...@ti.com wrote:


  -Original Message-
  From: kishore kadiyala [mailto:kishore.kadiy...@ti.com]
  Sent: Wednesday, September 02, 2009 8:30 AM
  To: linux-ker...@vger.kernel.org
  Cc: linux-omap@vger.kernel.org; jarkko.lavi...@nokia.com; madhu...@ti.com
  Subject: Re: [PATCH] OMAP4: MMC driver support on OMAP4
 
  Resending the patch, CC'ing LO.
 
  --Kishore
 
  This Patch adds basic support for all 5 MMC controllers on OMAP4.
 
  Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
  ---
  This patch doesn't include mmc-regulator support

 What is the specific reason? How are MMC4 and MMC5 powered up then?
 Does MMC1 and MMC2 work with mmctwl4030 wrapper?

OMAP4 uses twl6030 instead of twl4030 and the MMC1  MMC2 doesn't
work as it is with the mmc-twl4030 . I will be sending a Patch for mmc-regulator
which will have dependency on regulator patches  from Rajendra Nayak.

 
   arch/arm/mach-omap2/devices.c  |   42
  +
   arch/arm/plat-omap/include/mach/irqs.h |2 +
   arch/arm/plat-omap/include/mach/mmc.h  |9 ++-
   drivers/mmc/host/Kconfig   |6 ++--
   drivers/mmc/host/omap_hsmmc.c  |   10 +++
   5 files changed, 60 insertions(+), 9 deletions(-)
 
  Index: kernel-omap4-base/arch/arm/mach-omap2/devices.c
  ===
  --- kernel-omap4-base.orig/arch/arm/mach-omap2/devices.c
  +++ kernel-omap4-base/arch/arm/mach-omap2/devices.c
  @@ -397,7 +397,7 @@ static inline void omap_init_sha1_md5(vo
 
   /*---
  --*/
 
  -#ifdef CONFIG_ARCH_OMAP3
  +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
 
   #define MMCHS_SYSCONFIG  0x0010
   #define MMCHS_SYSCONFIG_SWRESET  (1  1)
  @@ -424,8 +424,8 @@ static struct platform_device dummy_pdev
**/
   static void __init omap_hsmmc_reset(void)
   {
  - u32 i, nr_controllers = cpu_is_omap34xx() ? OMAP34XX_NR_MMC :
  - OMAP24XX_NR_MMC;
  + u32 i, nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
  + (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
 
for (i = 0; i  nr_controllers; i++) {
u32 v, base = 0;
  @@ -442,8 +442,21 @@ static void __init omap_hsmmc_reset(void
case 2:
base = OMAP3_MMC3_BASE;
break;
  + case 3:
  + if (!cpu_is_omap44xx())
  + return;
  + base = OMAP4_MMC4_BASE;
  + break;
  + case 4:
  + if (!cpu_is_omap44xx())
  + return;
  + base = OMAP4_MMC5_BASE;
  + break;
}
 
  + if (cpu_is_omap44xx())
  + base += OMAP4_MMC_REG_OFFSET;
  +
dummy_pdev.id = i;
dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
iclk = clk_get(dev, ick);
  @@ -540,11 +553,23 @@ void __init omap2_init_mmc(struct omap_m
irq = INT_24XX_MMC2_IRQ;
break;
case 2:
  - if (!cpu_is_omap34xx())
  + if (!cpu_is_omap44xx()  !cpu_is_omap34xx())
return;
base = OMAP3_MMC3_BASE;
irq = INT_34XX_MMC3_IRQ;
break;
  + case 3:
  + if (!cpu_is_omap44xx())
  + return;
  + base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;

 The reset fn sets up the base as OMAP4_MMC4_BASE. Why add the OFFSET here?

Check in reset fn , if it is omap44xx its adding OFFSET there as well.

  + irq = INT_44XX_MMC4_IRQ;
  + break;
  + case 4:
  + if (!cpu_is_omap44xx())
  + return;
  + base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
 Ditto
  + irq = INT_44XX_MMC5_IRQ;
  + break;
default:
continue;
}
  @@ -552,8 +577,15 @@ void __init omap2_init_mmc(struct omap_m
if (cpu_is_omap2420()) {
size = OMAP2420_MMC_SIZE;
name = mmci-omap;
  + } else if (cpu_is_omap44xx()) {
  + if (i  3) {
  + base += OMAP4_MMC_REG_OFFSET;
  + irq += IRQ_GIC_START;
 Why base is updated at multiple places within this fn?

For OMAP3 mmc controllers to support OMAP4 the OFFSET is added here and these
avoids adding the offset to all controller registers in omap_hsmmc.c .
For new OMAP4 mmc 

Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)

[Mike Chan]

On Thu, Sep 3, 2009 at 7:01 AM, Kevin Hilmankhil...@deeprootsystems.com wrote:
 Mike Chan m...@android.com writes:

 On Tue, Aug 18, 2009 at 8:04 AM, Kevin
 Hilmankhil...@deeprootsystems.com wrote:
 Wang Limei-E12499 e12...@motorola.com writes:

 Seems like I did not submit the patch in the right way, before I setup
 my mail correctly, attach the patches in the mail.

 You're patches are still line-wrapped.

 I strongly recommend using git-format-patch and git-send-email to
 submit patches. Chunqiu was able to do this.  Please consult him.

 Also, no need to CC linux-omap-owner.  linux-omap is all that is needed.


 This patch has been reviewed and merged into our android-omap-2.6.29 tree
 http://android.git.kernel.org/?p=kernel/omap.git;a=commit;h=0b6a9b6514c7ccfa0c76e4defdaea3dcbc617633

 Hmm, I don't see any other review/signoff that the authors on that
 link.


Apologies, I was not aware of the reviewed-by policy but will keep
that in mind for future patches we pull into our branch. In general
any patches that have been applied to the android-omap-2.6.29 tree
have gone under some review/testing.

 Kevin if you're having line wrap problems feel free to pull it from
 here, assuming everyone's feedback has been addressed

 It's not me who has the line-wrap problem. I could unwrap pretty
 easily myself, but it gets very old working around various email
 client problems, so I choose to reject patches until they can be sent
 in a usable form.

 I'm still waiting for this so it can get a full review on-list.


Very understandable, if Chunqiu is still having problems I can push
one out to l-o for review on behalf of Chinqiu. Its in our best
interest to get this into mainline so we have less 1-off's to
maintain.

--Mike

 Thanks,

 Kevin


 Thanks,

 Kevin


 PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch

 From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
 From: Chunqiu Wang cqw...@motorola.com
 Date: Fri, 14 Aug 2009 17:34:32 +0800
 Subject: [PATCH] Add per-resource mutex for OMAP resource framework

 Current OMAP resource fwk uses a global res_mutex
 for resource_request and resource_release calls
 for all the available resources.It may cause dead
 lock if resource_request/resource_release is called
 recursively.

 For current OMAP3 VDD1/VDD2 resource, the change_level
 implementation is mach-omap2/resource34xx.c/set_opp(),
 when using resource_release to remove vdd1 constraint,
 this function may call resource_release again to release
 Vdd2 constrait if target vdd1 level is less than OPP3.
 in this scenario, the global res_mutex down operation
 will be called again, this will cause the second
 down operation hang there.

 To fix the problem, per-resource mutex is added
 to avoid hangup when resource_request/resource_release
 is called recursively.

 Signed-off-by: Chunqiu Wang cqw...@motorola.com
 ---
  arch/arm/plat-omap/include/mach/resource.h |    2 ++
  arch/arm/plat-omap/resource.c              |   27
 +++
  2 files changed, 17 insertions(+), 12 deletions(-)

 diff --git a/arch/arm/plat-omap/include/mach/resource.h
 b/arch/arm/plat-omap/include/mach/resource.h
 index f91d8ce..d482fb8 100644
 --- a/arch/arm/plat-omap/include/mach/resource.h
 +++ b/arch/arm/plat-omap/include/mach/resource.h
 @@ -46,6 +46,8 @@ struct shared_resource {
       /* Shared resource operations */
       struct shared_resource_ops *ops;
       struct list_head node;
 +     /* Protect each resource */
 +     struct mutex resource_mutex;
  };

  struct shared_resource_ops {
 diff --git a/arch/arm/plat-omap/resource.c
 b/arch/arm/plat-omap/resource.c
 index ec31727..5eae4e8 100644
 --- a/arch/arm/plat-omap/resource.c
 +++ b/arch/arm/plat-omap/resource.c
 @@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
               return -EEXIST;

       INIT_LIST_HEAD(resp-users_list);
 +     mutex_init(resp-resource_mutex);

       down(res_mutex);
       /* Add the resource to the resource list */
 @@ -326,14 +327,14 @@ int resource_request(const char *name, struct
 device *dev,
       struct  users_list *user;
       int     found = 0, ret = 0;

 -     down(res_mutex);
 -     resp = _resource_lookup(name);
 +     resp = resource_lookup(name);
       if (!resp) {
               printk(KERN_ERR resource_request: Invalid resource
 name\n);
               ret = -EINVAL;
 -             goto res_unlock;
 +             goto ret;
       }

 +     mutex_lock(resp-resource_mutex);
       /* Call the resource specific validate function */
       if (resp-ops-validate_level) {
               ret = resp-ops-validate_level(resp, level);
 @@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
 *dev,
       user-level = level;

  res_unlock:
 -     up(res_mutex);
 +     mutex_unlock(resp-resource_mutex);
       /*
        * Recompute and set the current level for the resource.
        * NOTE: update_resource level moved out of spin_lock, as it may
 

RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature

[S, Venkatraman]

 -Original Message-
 From: Shilimkar, Santosh 
 Sent: Monday, August 31, 2009 11:41 PM
 To: S, Venkatraman; linux-omap@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Subject: RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor 
 autoloading feature
 
 Venkat,
 Few comments other wise patch looks fine to me.

I am sending a new version with the changes. Can you please Ack ?
Thanks,

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

RE: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)

[Wang Limei-E12499]

 


Hi Mike,

Actually chunqiu and I still have this problem, if you can push out the patch, 
that will be good.  
 
Thanks,
Limei

-Original Message-
From: Mike Chan [mailto:m...@android.com] 
Sent: Thursday, September 03, 2009 12:45 PM
To: Kevin Hilman
Cc: Wang Limei-E12499; linux-omap@vger.kernel.org; Wang Sawsd-A24013
Subject: Re: Linux-omap PM: Fix dead lock condition in 
resource_release(vdd1_opp)

On Thu, Sep 3, 2009 at 7:01 AM, Kevin Hilmankhil...@deeprootsystems.com wrote:
 Mike Chan m...@android.com writes:

 On Tue, Aug 18, 2009 at 8:04 AM, Kevin 
 Hilmankhil...@deeprootsystems.com wrote:
 Wang Limei-E12499 e12...@motorola.com writes:

 Seems like I did not submit the patch in the right way, before I 
 setup my mail correctly, attach the patches in the mail.

 You're patches are still line-wrapped.

 I strongly recommend using git-format-patch and git-send-email to 
 submit patches. Chunqiu was able to do this.  Please consult him.

 Also, no need to CC linux-omap-owner.  linux-omap is all that is needed.


 This patch has been reviewed and merged into our android-omap-2.6.29 
 tree
 http://android.git.kernel.org/?p=kernel/omap.git;a=commit;h=0b6a9b651
 4c7ccfa0c76e4defdaea3dcbc617633

 Hmm, I don't see any other review/signoff that the authors on that 
 link.


Apologies, I was not aware of the reviewed-by policy but will keep that in mind 
for future patches we pull into our branch. In general any patches that have 
been applied to the android-omap-2.6.29 tree have gone under some 
review/testing.

 Kevin if you're having line wrap problems feel free to pull it from 
 here, assuming everyone's feedback has been addressed

 It's not me who has the line-wrap problem. I could unwrap pretty 
 easily myself, but it gets very old working around various email 
 client problems, so I choose to reject patches until they can be sent 
 in a usable form.

 I'm still waiting for this so it can get a full review on-list.


Very understandable, if Chunqiu is still having problems I can push one out to 
l-o for review on behalf of Chinqiu. Its in our best interest to get this into 
mainline so we have less 1-off's to maintain.

--Mike

 Thanks,

 Kevin


 Thanks,

 Kevin


 PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patc
 h

 From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 
 2001
 From: Chunqiu Wang cqw...@motorola.com
 Date: Fri, 14 Aug 2009 17:34:32 +0800
 Subject: [PATCH] Add per-resource mutex for OMAP resource framework

 Current OMAP resource fwk uses a global res_mutex for 
 resource_request and resource_release calls for all the available 
 resources.It may cause dead lock if 
 resource_request/resource_release is called recursively.

 For current OMAP3 VDD1/VDD2 resource, the change_level 
 implementation is mach-omap2/resource34xx.c/set_opp(),
 when using resource_release to remove vdd1 constraint, this 
 function may call resource_release again to release
 Vdd2 constrait if target vdd1 level is less than OPP3.
 in this scenario, the global res_mutex down operation will be 
 called again, this will cause the second down operation hang there.

 To fix the problem, per-resource mutex is added to avoid hangup 
 when resource_request/resource_release is called recursively.

 Signed-off-by: Chunqiu Wang cqw...@motorola.com
 ---
  arch/arm/plat-omap/include/mach/resource.h |    2 ++
  arch/arm/plat-omap/resource.c              |   27
 +++
  2 files changed, 17 insertions(+), 12 deletions(-)

 diff --git a/arch/arm/plat-omap/include/mach/resource.h
 b/arch/arm/plat-omap/include/mach/resource.h
 index f91d8ce..d482fb8 100644
 --- a/arch/arm/plat-omap/include/mach/resource.h
 +++ b/arch/arm/plat-omap/include/mach/resource.h
 @@ -46,6 +46,8 @@ struct shared_resource {
       /* Shared resource operations */
       struct shared_resource_ops *ops;
       struct list_head node;
 +     /* Protect each resource */
 +     struct mutex resource_mutex;
  };

  struct shared_resource_ops {
 diff --git a/arch/arm/plat-omap/resource.c 
 b/arch/arm/plat-omap/resource.c index ec31727..5eae4e8 100644
 --- a/arch/arm/plat-omap/resource.c
 +++ b/arch/arm/plat-omap/resource.c
 @@ -264,6 +264,7 @@ int resource_register(struct shared_resource 
 *resp)
               return -EEXIST;

       INIT_LIST_HEAD(resp-users_list);
 +     mutex_init(resp-resource_mutex);

       down(res_mutex);
       /* Add the resource to the resource list */ @@ -326,14 
 +327,14 @@ int resource_request(const char *name, struct device 
 *dev,
       struct  users_list *user;
       int     found = 0, ret = 0;

 -     down(res_mutex);
 -     resp = _resource_lookup(name);
 +     resp = resource_lookup(name);
       if (!resp) {
               printk(KERN_ERR resource_request: Invalid resource 
 name\n);
               ret = -EINVAL;
 -             goto res_unlock;
 +             goto ret;
       }

 +     mutex_lock(resp-resource_mutex);
       /* Call the resource specific 

[PATCH v3] OMAP4: sDMA driver: descriptor autoloading feature

[S, Venkatraman]

Comments received and fixed after previous posts
http://marc.info/?l=linux-omapm=125012097403050w=2  (v1)
http://marc.info/?l=linux-omapm=125137152606644w=2  (v2)

Summary:
OMAP sDMA driver changes for descriptor autoloading feature.
Signed-off-by: Venkatraman S svenk...@ti.com

---
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..3a75272 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -29,6 +29,7 @@
 #include linux/interrupt.h
 #include linux/irq.h
 #include linux/io.h
+#include linux/dma-mapping.h

 #include asm/system.h
 #include mach/hardware.h
@@ -46,13 +47,42 @@ enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE, 
DMA_CH_STARTED,
 enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
 #endif

+/* CDP Register bitmaps */
+#define DMA_LIST_CDP_DST_VALID (BIT(0))
+#define DMA_LIST_CDP_SRC_VALID (BIT(2))
+#define DMA_LIST_CDP_TYPE1 (BIT(4))
+#define DMA_LIST_CDP_TYPE2 (BIT(5))
+#define DMA_LIST_CDP_TYPE3 (BIT(4) | BIT(5))
+#define DMA_LIST_CDP_PAUSEMODE (BIT(7))
+#define DMA_LIST_CDP_LISTMODE  (BIT(8))
+#define DMA_LIST_CDP_FASTMODE  (BIT(10))
+/* CAPS register bitmaps */
+#define DMA_CAPS_SGLIST_SUPPORT(BIT(20))
+
+#define DMA_LIST_DESC_PAUSE(BIT(0))
+#define DMA_LIST_DESC_SRC_VALID(BIT(24))
+#define DMA_LIST_DESC_DST_VALID(BIT(26))
+#define DMA_LIST_DESC_BLK_END  (BIT(28))
+
 #define OMAP_DMA_ACTIVE0x01
 #define OMAP_DMA_CCR_EN(1  7)
 #define OMAP2_DMA_CSR_CLEAR_MASK   0xffe

 #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
+#define OMAP_DMA_INVALID_FRAME_COUNT   (0x)
+#define OMAP_DMA_INVALID_ELEM_COUNT(0xff)
+#define OMAP_DMA_INVALID_DESCRIPTOR_POINTER(0xfffc)

 static int enable_1510_mode;
+static int dma_caps0_status;
+
+struct omap_dma_list_config_params {
+   int chid;
+   int num_elem;
+   struct omap_dma_sglist_node *sghead;
+   int sgheadphy;
+   int pausenode;
+};

 struct omap_dma_lch {
int next_lch;
@@ -72,6 +102,8 @@ struct omap_dma_lch {

int status;
 #endif
+
+   void *list_config;
long flags;
 };

@@ -209,6 +241,12 @@ static void clear_lch_regs(int lch)
__raw_writew(0, lch_base + i);
 }

+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+  int value)
+{
+   node-num_of_elem |= ((value)  29);
+}
+
 void omap_set_dma_priority(int lch, int dst_port, int priority)
 {
unsigned long reg;
@@ -1787,6 +1825,269 @@ EXPORT_SYMBOL(omap_get_dma_chain_src_pos);
 #endif /* ifndef CONFIG_ARCH_OMAP1 */

 
/**/
+int omap_request_dma_sglist(int dev_id, const char *dev_name,
+   void (*callback) (int channel_id, u16 ch_status, void *data),
+   int *listid, int nelem, struct omap_dma_sglist_node **elems)
+{
+   struct omap_dma_list_config_params *lcfg;
+   struct omap_dma_sglist_node *desc;
+   int dma_lch;
+   int rc, i;
+
+   if (unlikely((dma_caps0_status  DMA_CAPS_SGLIST_SUPPORT) == 0)) {
+   printk(KERN_ERR omap DMA: sglist feature not supported\n);
+   return -EPERM;
+   }
+   if (unlikely(nelem = 2)) {
+   printk(KERN_ERR omap DMA: Need 2 elements in the list\n);
+   return -EINVAL;
+   }
+   rc = omap_request_dma(dev_id, dev_name,
+ callback, NULL, dma_lch);
+   if (rc  0) {
+   printk(KERN_ERR omap_dma_list: Request failed %d\n, rc);
+   return rc;
+   }
+   *listid = dma_lch;
+   dma_chan[dma_lch].state = DMA_CH_NOTSTARTED;
+   lcfg = kmalloc(sizeof(*lcfg), GFP_KERNEL);
+   if (NULL == lcfg)
+   goto error1;
+   dma_chan[dma_lch].list_config = lcfg;
+
+   lcfg-num_elem = nelem;
+
+   *elems = desc = lcfg-sghead = dma_alloc_coherent(NULL,
+   sizeof(*desc), (lcfg-sgheadphy), 0);
+   if (NULL == desc)
+   goto error1;
+
+   for (i = 1; i  nelem; i++) {
+   desc-next = dma_alloc_coherent(NULL,
+   sizeof(*(desc-next)), (desc-next_desc_add_ptr), 0);
+   if (NULL == desc-next)
+   goto error1;
+   desc = desc-next;
+   desc-next = NULL;
+   }
+   desc-next_desc_add_ptr = OMAP_DMA_INVALID_DESCRIPTOR_POINTER;
+
+   dma_write(0, CCDN(dma_lch)); /* Reset List index numbering */
+   /* Initialize frame and element counters to invalid values */
+   dma_write(OMAP_DMA_INVALID_FRAME_COUNT, CCFN(dma_lch));
+   dma_write(OMAP_DMA_INVALID_ELEM_COUNT, CCEN(dma_lch));
+   return 0;
+
+error1:
+   omap_release_dma_sglist(dma_lch);
+   return -ENOMEM;
+
+}
+EXPORT_SYMBOL(omap_request_dma_sglist);
+
+/* The client can choose to not preconfigure the DMA registers
+ * In fast mode,the DMA 

RE: [PATCH 2/2] OMAP3: Add support for NAND on ZOOM2/LDP boards

[Pandita, Vikram]

Vimal/Tony

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of vimal
singh
Sent: Tuesday, September 01, 2009 4:29 AM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com
Subject: [PATCH 2/2] OMAP3: Add support for NAND on ZOOM2/LDP boards

Adding NAND support for ZOOM2 and LDP board. I have tested it for ZOOM2
boards, someone can verify it for LDP, hopefully it should not have any
problem.

I will repost this series with LDP name replaced by ZOOM.
The LDP board is actually Zoom1 and future platforms of this family will be 
called Zoom2/3/4.

So I will post V2 of this series with 3 patches.

Patch 1 - no change
Patch 2 - change ldp name to zoom
Patch 3 (new) - Add Zoom2 defconfig patch to update NAND partitions

I have tested this series on Zoom2 board and works fine now on Zoom2.


The size of the U-Boot environment partition was increased to 1.25MB.

Singned-off-by: Vimal Singh vimalsi...@ti.com
---
 arch/arm/mach-omap2/Makefile|2
 arch/arm/mach-omap2/board-ldp-flash.c   |  196 
 
 arch/arm/mach-omap2/board-ldp.c |2
 arch/arm/mach-omap2/board-zoom2.c   |2
 arch/arm/plat-omap/include/mach/board-ldp.h |   36 +
 arch/arm/plat-omap/include/mach/nand.h  |1
 6 files changed, 239 insertions(+)

Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON)  += boar
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)   += board-omap3beagle.o \
  mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_LDP)   += board-ldp.o \
+ board-ldp-flash.o \
  mmc-twl4030.o
 obj-$(CONFIG_MACH_OVERO)  += board-overo.o \
  mmc-twl4030.o
@@ -69,6 +70,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51)+= board-
  board-rx51-peripherals.o \
  mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-ldp-flash.o \
  mmc-twl4030.o \
  board-zoom-debugboard.o

Index: linux-omap-2.6/arch/arm/mach-omap2/board-ldp-flash.c
===
--- /dev/null
+++ linux-omap-2.6/arch/arm/mach-omap2/board-ldp-flash.c
@@ -0,0 +1,196 @@
+/*
+ * arch/arm/mach-omap2/board-ldp-flash.c
+ *
+ * Copyright (C) 2008-09 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-2430sdp-flash.c
+ * Author(s): Rohit Choraria rohi...@ti.com
+ *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/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include mach/board.h
+#include mach/gpmc.h
+#include mach/nand.h
+
+#include mach/board-ldp.h
+
+#define NAND_CMD_UNLOCK1  0x23
+#define NAND_CMD_UNLOCK2  0x24
+/**
+ * @brief platform specific unlock function
+ *
+ * @param mtd - mtd info
+ * @param ofs - offset to start unlock from
+ * @param len - length to unlock
+ *
+ * @return - unlock status
+ */
+static int omap_ldp_nand_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+  int ret = 0;
+  int chipnr;
+  int status;
+  unsigned long page;
+  struct nand_chip *this = mtd-priv;
+  printk(KERN_INFO nand_unlock: start: %08x, length: %d!\n,
+  (int)ofs, (int)len);
+
+  /* select the NAND device */
+  chipnr = (int)(ofs  this-chip_shift);
+  this-select_chip(mtd, chipnr);
+  /* check the WP bit */
+  this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+  if ((this-read_byte(mtd)  0x80) == 0) {
+  printk(KERN_ERR nand_unlock: Device is write protected!\n);
+  ret = -EINVAL;
+  goto out;
+  }
+
+  if ((ofs  (mtd-writesize - 1)) != 0) {
+  printk(KERN_ERR nand_unlock: Start address must be
+  beginning of nand page!\n);
+  ret = -EINVAL;
+  goto out;
+  }
+
+  if (len == 0 || (len  (mtd-writesize - 1)) != 0) {
+  printk(KERN_ERR nand_unlock: Length must be a multiple of 
+  nand page size!\n);
+  ret = -EINVAL;
+  goto out;
+  }
+
+  /* 

[PATCH-v2 0/3] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards

[Vikram Pandita]

This patch series adds flash support for NAND (in sdp, zoom2 and ldp),
OneNAND and NOR (in sdp)

Tested on Zoom2 by Vikram, On SDP by Vimal

Vikram Pandita (1):
  OMAP: Zoom2: Enable NAND in defconfig

Vimal Singh (2):
  OMAP2/3: Add support for flash on SDP boards
  OMAP3: Add support for NAND on ZOOM2/LDP boards

 arch/arm/configs/omap_zoom2_defconfig|  224 +-
 arch/arm/mach-omap2/Makefile |4 +
 arch/arm/mach-omap2/board-2430sdp.c  |2 +
 arch/arm/mach-omap2/board-3430sdp.c  |2 +
 arch/arm/mach-omap2/board-ldp.c  |2 +
 arch/arm/mach-omap2/board-sdp-flash.c|  326 ++
 arch/arm/mach-omap2/board-sdp.h  |   15 ++
 arch/arm/mach-omap2/board-zoom-flash.c   |  196 
 arch/arm/mach-omap2/board-zoom2.c|2 +
 arch/arm/plat-omap/include/mach/board-zoom.h |   36 +++
 arch/arm/plat-omap/include/mach/gpmc.h   |2 +
 arch/arm/plat-omap/include/mach/nand.h   |1 +
 12 files changed, 748 insertions(+), 64 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c
 create mode 100644 arch/arm/mach-omap2/board-sdp.h
 create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
 create mode 100644 arch/arm/plat-omap/include/mach/board-zoom.h

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

[PATCH-v2 1/3 ] OMAP2/3: Add support for flash on SDP boards

[Vikram Pandita]

From: Vimal Singh vimalsi...@ti.com

Add support for flash on SDP boards. NAND, NOR and OneNAND
are supported.

Only tested on 3430SDP (ES2 and ES3.1), somebody please test on
2430SDP and check the chips select for 2430SDP.

Also note that:
For OneNAND: in the earlier 2430SDP code the kernel partition
was set to only 1MB instead of 2MB on 3430SDP. If people want
the old partition sizes back on 2430SDP, please provide a patch.

For NAND: 'U-Boot', 'Boot Env' and 'Kernel' partitions sizes increased
by few blocks to provide few spare blocks for NAND bab block management
in u-boot. If people want old partition sizes, please provide a patch.

Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/Makefile   |2 +
 arch/arm/mach-omap2/board-2430sdp.c|2 +
 arch/arm/mach-omap2/board-3430sdp.c|2 +
 arch/arm/mach-omap2/board-sdp-flash.c  |  326 
 arch/arm/mach-omap2/board-sdp.h|   15 ++
 arch/arm/plat-omap/include/mach/gpmc.h |2 +
 6 files changed, 349 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c
 create mode 100644 arch/arm/mach-omap2/board-sdp.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index abaaead..ebe882b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_OMAP_IOMMU)  += $(iommu-y)
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
 obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \
+  board-sdp-flash.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
@@ -61,6 +62,7 @@ obj-$(CONFIG_MACH_OMAP3EVM)   += board-omap3evm.o \
 obj-$(CONFIG_MACH_OMAP3_PANDORA)   += board-omap3pandora.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
+  board-sdp-flash.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)  += board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RX51)  += board-rx51.o \
diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index c693668..39fcb36 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -38,6 +38,7 @@
 #include mach/usb.h
 #include mach/gpmc-smc91x.h
 
+#include board-sdp.h
 #include mmc-twl4030.h
 
 #define SDP2430_CS0_BASE   0x0400
@@ -210,6 +211,7 @@ static void __init omap_2430sdp_init(void)
twl4030_mmc_init(mmc);
usb_musb_init();
board_smc91x_init();
+   sdp_flash_init();
 
/* Turn off secondary LCD backlight */
ret = gpio_request(SECONDARY_LCD_GPIO, Secondary LCD backlight);
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index c71417f..1675c02 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -41,6 +41,7 @@
 #include mach/keypad.h
 #include mach/gpmc-smc91x.h
 
+#include board-sdp.h
 #include sdram-qimonda-hyb18m512160af-6.h
 #include mmc-twl4030.h
 
@@ -494,6 +495,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init(sdp3430_uart_config);
usb_musb_init();
board_smc91x_init();
+   sdp_flash_init();
usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
 }
 
diff --git a/arch/arm/mach-omap2/board-sdp-flash.c 
b/arch/arm/mach-omap2/board-sdp-flash.c
new file mode 100644
index 000..1b992cc
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
@@ -0,0 +1,326 @@
+/*
+ * arch/arm/mach-omap2/board-sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ * Author: 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/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include mach/onenand.h
+#include mach/gpmc.h
+#include mach/nand.h
+
+#define REG_FPGA_REV   0x10
+#define REG_FPGA_DIP_SWITCH_INPUT2 0x60
+#define MAX_SUPPORTED_GPMC_CONFIG  3
+
+/* various memory sizes */
+#define FLASH_SIZE_SDPV1   SZ_64M
+#define FLASH_SIZE_SDPV2   SZ_128M
+
+#define FLASH_BASE_SDPV1   0x0400 /* NOR flash (64 Meg aligned) */
+#define FLASH_BASE_SDPV2   0x1000 /* NOR flash (256 Meg aligned) */
+

[PATCH-v2 2/3] OMAP3: Add support for NAND on ZOOM2/LDP boards

[Vikram Pandita]

From: Vimal Singh vimalsi...@ti.com

Adding NAND support for ZOOM2 and LDP board. I have tested it for ZOOM2
boards, someone can verify it for LDP, hopefully it should not have any
problem.

The size of the U-Boot environment partition was increased to 1.25MB.

Vikram: Changed ldp name to zoom.
Future boards will be called Zoom2/3/4 etc.
LDP is a Zoom1. Somhow the LDP name got stuck to that.

Singned-off-by: Vimal Singh vimalsi...@ti.com
Singned-off-by: Vikram Pandita vikram.pand...@ti.com
---
 arch/arm/mach-omap2/Makefile |2 +
 arch/arm/mach-omap2/board-ldp.c  |2 +
 arch/arm/mach-omap2/board-zoom-flash.c   |  196 ++
 arch/arm/mach-omap2/board-zoom2.c|2 +
 arch/arm/plat-omap/include/mach/board-zoom.h |   36 +
 arch/arm/plat-omap/include/mach/nand.h   |1 +
 6 files changed, 239 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
 create mode 100644 arch/arm/plat-omap/include/mach/board-zoom.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ebe882b..182861d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON)   += 
board-apollon.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
+  board-zoom-flash.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_OVERO)   += board-overo.o \
   mmc-twl4030.o
@@ -69,6 +70,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
   board-rx51-peripherals.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_ZOOM2)  += board-zoom2.o \
+  board-zoom-flash.o \
   mmc-twl4030.o \
   board-zoom-debugboard.o
 
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 4a4b300..88bd54f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -42,6 +42,7 @@
 #include mach/control.h
 #include mach/usb.h
 #include mach/keypad.h
+#include mach/board-zoom.h
 
 #include mmc-twl4030.h
 
@@ -385,6 +386,7 @@ static void __init omap_ldp_init(void)
ads7846_dev_init();
omap_serial_init(ldp_uart_config);
usb_musb_init();
+   zoom_flash_init();
 
twl4030_mmc_init(mmc);
/* link regulators to MMC adapters */
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..1007e5d
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,196 @@
+/*
+ * arch/arm/mach-omap2/board-zoom-flash.c
+ *
+ * Copyright (C) 2008-09 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-2430sdp-flash.c
+ * Author(s): Rohit Choraria rohi...@ti.com
+ *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/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include mach/board.h
+#include mach/gpmc.h
+#include mach/nand.h
+
+#include mach/board-zoom.h
+
+#define NAND_CMD_UNLOCK1   0x23
+#define NAND_CMD_UNLOCK2   0x24
+/**
+ * @brief platform specific unlock function
+ *
+ * @param mtd - mtd info
+ * @param ofs - offset to start unlock from
+ * @param len - length to unlock
+ *
+ * @return - unlock status
+ */
+static int omap_zoom_nand_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+   int ret = 0;
+   int chipnr;
+   int status;
+   unsigned long page;
+   struct nand_chip *this = mtd-priv;
+   printk(KERN_INFO nand_unlock: start: %08x, length: %d!\n,
+   (int)ofs, (int)len);
+
+   /* select the NAND device */
+   chipnr = (int)(ofs  this-chip_shift);
+   this-select_chip(mtd, chipnr);
+   /* check the WP bit */
+   this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+   if ((this-read_byte(mtd)  0x80) == 0) {
+   printk(KERN_ERR nand_unlock: Device is write protected!\n);
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if ((ofs  (mtd-writesize - 1)) != 0) {
+   printk(KERN_ERR nand_unlock: Start address must be
+   beginning of nand page!\n);
+   ret = -EINVAL;
+   goto 

[PATCH-v2 3/3] OMAP: Zoom2: Enable NAND in defconfig

[Vikram Pandita]

Enable NAND options by default in zoom2_defconfig file
Other changes in defconfig come from make menuconfig syncup

Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
 arch/arm/configs/omap_zoom2_defconfig |  224 +++--
 1 files changed, 160 insertions(+), 64 deletions(-)

diff --git a/arch/arm/configs/omap_zoom2_defconfig 
b/arch/arm/configs/omap_zoom2_defconfig
index f1739fa..b16a38c 100644
--- a/arch/arm/configs/omap_zoom2_defconfig
+++ b/arch/arm/configs/omap_zoom2_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.30-omap1
-# Fri Jun 12 17:25:46 2009
+# Linux kernel version: 2.6.31-rc8-omap1
+# Thu Sep  3 13:52:59 2009
 #
 CONFIG_ARM=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
@@ -9,7 +9,6 @@ CONFIG_GENERIC_GPIO=y
 CONFIG_GENERIC_TIME=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_MMU=y
-# CONFIG_NO_IOPORT is not set
 CONFIG_GENERIC_HARDIRQS=y
 CONFIG_STACKTRACE_SUPPORT=y
 CONFIG_HAVE_LATENCYTOP_SUPPORT=y
@@ -18,13 +17,12 @@ 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_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
@@ -77,7 +75,6 @@ CONFIG_UID16=y
 CONFIG_KALLSYMS=y
 # CONFIG_KALLSYMS_ALL is not set
 CONFIG_KALLSYMS_EXTRA_PASS=y
-# CONFIG_STRIP_ASM_SYMS is not set
 CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
@@ -90,7 +87,12 @@ CONFIG_TIMERFD=y
 CONFIG_EVENTFD=y
 CONFIG_SHMEM=y
 CONFIG_AIO=y
+
+#
+# Performance Counters
+#
 CONFIG_VM_EVENT_COUNTERS=y
+# CONFIG_STRIP_ASM_SYMS is not set
 CONFIG_COMPAT_BRK=y
 CONFIG_SLAB=y
 # CONFIG_SLUB is not set
@@ -102,6 +104,10 @@ CONFIG_HAVE_OPROFILE=y
 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
@@ -114,7 +120,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_BLOCK=y
-# CONFIG_LBD is not set
+CONFIG_LBDAF=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_BLK_DEV_INTEGRITY is not set
 
@@ -141,13 +147,14 @@ CONFIG_FREEZER=y
 # CONFIG_ARCH_VERSATILE is not set
 # CONFIG_ARCH_AT91 is not set
 # CONFIG_ARCH_CLPS711X is not set
+# CONFIG_ARCH_GEMINI is not set
 # CONFIG_ARCH_EBSA110 is not set
 # CONFIG_ARCH_EP93XX is not set
-# CONFIG_ARCH_GEMINI is not set
 # CONFIG_ARCH_FOOTBRIDGE is not set
+# CONFIG_ARCH_MXC is not set
+# CONFIG_ARCH_STMP3XXX is not set
 # CONFIG_ARCH_NETX is not set
 # CONFIG_ARCH_H720X is not set
-# CONFIG_ARCH_IMX is not set
 # CONFIG_ARCH_IOP13XX is not set
 # CONFIG_ARCH_IOP32X is not set
 # CONFIG_ARCH_IOP33X is not set
@@ -156,25 +163,25 @@ CONFIG_FREEZER=y
 # CONFIG_ARCH_IXP4XX is not set
 # CONFIG_ARCH_L7200 is not set
 # CONFIG_ARCH_KIRKWOOD is not set
-# CONFIG_ARCH_KS8695 is not set
-# CONFIG_ARCH_NS9XXX is not set
 # CONFIG_ARCH_LOKI is not set
 # CONFIG_ARCH_MV78XX0 is not set
-# CONFIG_ARCH_MXC is not set
 # CONFIG_ARCH_ORION5X is not set
+# CONFIG_ARCH_MMP is not set
+# CONFIG_ARCH_KS8695 is not set
+# CONFIG_ARCH_NS9XXX is not set
+# CONFIG_ARCH_W90X900 is not set
 # CONFIG_ARCH_PNX4008 is not set
 # CONFIG_ARCH_PXA is not set
-# CONFIG_ARCH_MMP is not set
+# CONFIG_ARCH_MSM is not set
 # CONFIG_ARCH_RPC is not set
 # CONFIG_ARCH_SA1100 is not set
 # CONFIG_ARCH_S3C2410 is not set
 # CONFIG_ARCH_S3C64XX is not set
 # CONFIG_ARCH_SHARK is not set
 # CONFIG_ARCH_LH7A40X is not set
+# CONFIG_ARCH_U300 is not set
 # CONFIG_ARCH_DAVINCI is not set
 CONFIG_ARCH_OMAP=y
-# CONFIG_ARCH_MSM is not set
-# CONFIG_ARCH_W90X900 is not set
 
 #
 # TI OMAP Implementations
@@ -209,13 +216,13 @@ CONFIG_ARCH_OMAP3430=y
 #
 # OMAP Board Type
 #
-# CONFIG_MACH_NOKIA_RX51 is not set
-# CONFIG_MACH_OMAP_LDP is not set
-# CONFIG_MACH_OMAP_3430SDP is not set
-# CONFIG_MACH_OMAP3EVM is not set
 # CONFIG_MACH_OMAP3_BEAGLE is not set
+# CONFIG_MACH_OMAP_LDP is not set
 # CONFIG_MACH_OVERO is not set
+# CONFIG_MACH_OMAP3EVM is not set
 # CONFIG_MACH_OMAP3_PANDORA is not set
+# CONFIG_MACH_OMAP_3430SDP is not set
+# CONFIG_MACH_NOKIA_RX51 is not set
 CONFIG_MACH_OMAP_ZOOM2=y
 
 #
@@ -244,7 +251,6 @@ CONFIG_ARM_THUMB=y
 # CONFIG_CPU_DCACHE_DISABLE is not set
 # CONFIG_CPU_BPREDICT_DISABLE is not set
 CONFIG_HAS_TLS_REG=y
-# CONFIG_OUTER_CACHE is not set
 # CONFIG_ARM_ERRATA_430973 is not set
 # CONFIG_ARM_ERRATA_458693 is not set
 # CONFIG_ARM_ERRATA_460075 is not set
@@ -272,7 +278,6 @@ CONFIG_PAGE_OFFSET=0xC000
 CONFIG_HZ=128
 CONFIG_AEABI=y
 CONFIG_OABI_COMPAT=y
-# CONFIG_ARCH_HAS_HOLES_MEMORYMODEL is not set
 # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
 # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
 # CONFIG_HIGHMEM is not set
@@ -287,11 +292,12 @@ 

[PATCH] omap: resource: Fix race in register_resource()

[Mike Chan]

Checking if the resource is already registered and adding to the list
must be atomic or bad things can happen.

Signed-off-by: Mike Chan m...@android.com
---
 arch/arm/plat-omap/resource.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
index e9ace13..9d20249 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -253,6 +253,7 @@ int resource_refresh(void)
  */
 int resource_register(struct shared_resource *resp)
 {
+   int ret = 0;
if (!resp)
return -EINVAL;
 
@@ -260,13 +261,15 @@ int resource_register(struct shared_resource *resp)
return -EINVAL;
 
/* Verify that the resource is not already registered */
-   if (resource_lookup(resp-name))
-   return -EEXIST;
+   down(res_mutex);
+   if (_resource_lookup(resp-name)) {
+   ret = -EEXIST;
+   goto out;
+   }
 
INIT_LIST_HEAD(resp-users_list);
mutex_init(resp-resource_mutex);
 
-   down(res_mutex);
/* Add the resource to the resource list */
list_add(resp-node, res_list);
 
@@ -274,10 +277,11 @@ int resource_register(struct shared_resource *resp)
if (resp-ops-init)
resp-ops-init(resp);
 
-   up(res_mutex);
pr_debug(resource: registered %s\n, resp-name);
 
-   return 0;
+out:
+   up(res_mutex);
+   return ret;
 }
 EXPORT_SYMBOL(resource_register);
 
-- 
1.5.4.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: RT tests on OMAP3

[Cliff Brake]

On Thu, Sep 3, 2009 at 10:28 AM, Kevin
Hilmankhil...@deeprootsystems.com wrote:

 I've been using -rt on a basic OMAP3 kernel, but have not enabled
 EHCI so haven't seen this.

What kernel version are you running, and what are you using for your
timer config?

# CONFIG_OMAP_MBOX_FWK is not set
# CONFIG_OMAP_MPU_TIMER is not set
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_32K_TIMER_HZ=128
CONFIG_OMAP_DM_TIMER=y

Thanks,
Cliff
--
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] [ARM] omap: resource: Make resource_refresh() thread safe.

[Mike Chan]

Need to lock the res_mutex when traversing the res_list.

Signed-off-by: Mike Chan m...@android.com
---
 arch/arm/plat-omap/resource.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
index 25072cd..4631912 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -234,11 +234,13 @@ int resource_refresh(void)
struct shared_resource *resp = NULL;
int ret = 0;
 
+   down(res_mutex);
list_for_each_entry(resp, res_list, node) {
ret = update_resource_level(resp);
if (ret)
break;
}
+   up(res_mutex);
return ret;
 }
 
-- 
1.5.4.5

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

RE: [PATCH] OMAP4: MMC driver support on OMAP4

[Madhusudhan]

 -Original Message-
 From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
 Sent: Thursday, September 03, 2009 11:04 AM
 To: Madhusudhan
 Cc: kishore kadiyala; linux-ker...@vger.kernel.org; linux-
 o...@vger.kernel.org; jarkko.lavi...@nokia.com
 Subject: Re: [PATCH] OMAP4: MMC driver support on OMAP4
 
 On Wed, Sep 2, 2009 at 10:00 PM, Madhusudhan madhu...@ti.com wrote:
 
 
   -Original Message-
   From: kishore kadiyala [mailto:kishore.kadiy...@ti.com]
   Sent: Wednesday, September 02, 2009 8:30 AM
   To: linux-ker...@vger.kernel.org
   Cc: linux-omap@vger.kernel.org; jarkko.lavi...@nokia.com;
 madhu...@ti.com
   Subject: Re: [PATCH] OMAP4: MMC driver support on OMAP4
  
   Resending the patch, CC'ing LO.
  
   --Kishore
  
   This Patch adds basic support for all 5 MMC controllers on OMAP4.
  
   Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
   ---
   This patch doesn't include mmc-regulator support
 
  What is the specific reason? How are MMC4 and MMC5 powered up then?
  Does MMC1 and MMC2 work with mmctwl4030 wrapper?
 
 OMAP4 uses twl6030 instead of twl4030 and the MMC1  MMC2 doesn't
 work as it is with the mmc-twl4030 . I will be sending a Patch for mmc-
 regulator
 which will have dependency on regulator patches  from Rajendra Nayak.

Which of the OMAP4 controllers become useable with this patch?
I guess you might be supporting only one-bit bus width with this patch.
It would be good if your patch header describes what is supported with this
patch.

Please CC linux-...@vger.kernel.org.



 
  
arch/arm/mach-omap2/devices.c  |   42
   +
arch/arm/plat-omap/include/mach/irqs.h |2 +
arch/arm/plat-omap/include/mach/mmc.h  |9 ++-
drivers/mmc/host/Kconfig   |6 ++--
drivers/mmc/host/omap_hsmmc.c  |   10 +++
5 files changed, 60 insertions(+), 9 deletions(-)
  
   Index: kernel-omap4-base/arch/arm/mach-omap2/devices.c
   ===
   --- kernel-omap4-base.orig/arch/arm/mach-omap2/devices.c
   +++ kernel-omap4-base/arch/arm/mach-omap2/devices.c
   @@ -397,7 +397,7 @@ static inline void omap_init_sha1_md5(vo
  
/*---
 
   --*/
  
   -#ifdef CONFIG_ARCH_OMAP3
   +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
  
#define MMCHS_SYSCONFIG  0x0010
#define MMCHS_SYSCONFIG_SWRESET  (1  1)
   @@ -424,8 +424,8 @@ static struct platform_device dummy_pdev
 **/
static void __init omap_hsmmc_reset(void)
{
   - u32 i, nr_controllers = cpu_is_omap34xx() ? OMAP34XX_NR_MMC :
   - OMAP24XX_NR_MMC;
   + u32 i, nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
   + (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
  
 for (i = 0; i  nr_controllers; i++) {
 u32 v, base = 0;
   @@ -442,8 +442,21 @@ static void __init omap_hsmmc_reset(void
 case 2:
 base = OMAP3_MMC3_BASE;
 break;
   + case 3:
   + if (!cpu_is_omap44xx())
   + return;
   + base = OMAP4_MMC4_BASE;
   + break;
   + case 4:
   + if (!cpu_is_omap44xx())
   + return;
   + base = OMAP4_MMC5_BASE;
   + break;
 }
  
   + if (cpu_is_omap44xx())
   + base += OMAP4_MMC_REG_OFFSET;
   +
 dummy_pdev.id = i;
 dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
 iclk = clk_get(dev, ick);
   @@ -540,11 +553,23 @@ void __init omap2_init_mmc(struct omap_m
 irq = INT_24XX_MMC2_IRQ;
 break;
 case 2:
   - if (!cpu_is_omap34xx())
   + if (!cpu_is_omap44xx()  !cpu_is_omap34xx())
 return;
 base = OMAP3_MMC3_BASE;
 irq = INT_34XX_MMC3_IRQ;
 break;
   + case 3:
   + if (!cpu_is_omap44xx())
   + return;
   + base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
 
  The reset fn sets up the base as OMAP4_MMC4_BASE. Why add the OFFSET
 here?
 
 Check in reset fn , if it is omap44xx its adding OFFSET there as well.
 
   + irq = INT_44XX_MMC4_IRQ;
   + break;
   + case 4:
   + if (!cpu_is_omap44xx())
   + return;
   + base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
  Ditto
   + irq = INT_44XX_MMC5_IRQ;
   + break;
  

Re: [RFC][PATCH] ARM: OMAP: McBSP: Use register cache

[Eero Nurkkala]

Hello,

Register values should not get corrupted. Could you please point out the
registers that may get corrupted? Do they get corrupted during audio
play? I haven't seen corrupted register values.

- Eero

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

Re: [PATCH-v2 2/3] OMAP3: Add support for NAND on ZOOM2/LDP boards

[kishore kadiyala]

On Fri, Sep 4, 2009 at 12:56 AM, Vikram Panditavikram.pand...@ti.com wrote:
 From: Vimal Singh vimalsi...@ti.com

 Adding NAND support for ZOOM2 and LDP board. I have tested it for ZOOM2
 boards, someone can verify it for LDP, hopefully it should not have any
 problem.

 The size of the U-Boot environment partition was increased to 1.25MB.

 Vikram: Changed ldp name to zoom.
        Future boards will be called Zoom2/3/4 etc.
        LDP is a Zoom1. Somhow the LDP name got stuck to that.

 Singned-off-by: Vimal Singh vimalsi...@ti.com
 Singned-off-by: Vikram Pandita vikram.pand...@ti.com

Typo error: Singned - Signed

 ---
  arch/arm/mach-omap2/Makefile                 |    2 +
  arch/arm/mach-omap2/board-ldp.c              |    2 +
  arch/arm/mach-omap2/board-zoom-flash.c       |  196 
 ++
  arch/arm/mach-omap2/board-zoom2.c            |    2 +
  arch/arm/plat-omap/include/mach/board-zoom.h |   36 +
  arch/arm/plat-omap/include/mach/nand.h       |    1 +
  6 files changed, 239 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
  create mode 100644 arch/arm/plat-omap/include/mach/board-zoom.h

 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index ebe882b..182861d 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -54,6 +54,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON)               += 
 board-apollon.o
  obj-$(CONFIG_MACH_OMAP3_BEAGLE)                += board-omap3beagle.o \
                                           mmc-twl4030.o
  obj-$(CONFIG_MACH_OMAP_LDP)            += board-ldp.o \
 +                                          board-zoom-flash.o \
                                           mmc-twl4030.o
  obj-$(CONFIG_MACH_OVERO)               += board-overo.o \
                                           mmc-twl4030.o
 @@ -69,6 +70,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51)         += board-rx51.o \
                                           board-rx51-peripherals.o \
                                           mmc-twl4030.o
  obj-$(CONFIG_MACH_OMAP_ZOOM2)          += board-zoom2.o \
 +                                          board-zoom-flash.o \
                                           mmc-twl4030.o \
                                           board-zoom-debugboard.o

 diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
 index 4a4b300..88bd54f 100644
 --- a/arch/arm/mach-omap2/board-ldp.c
 +++ b/arch/arm/mach-omap2/board-ldp.c
 @@ -42,6 +42,7 @@
  #include mach/control.h
  #include mach/usb.h
  #include mach/keypad.h
 +#include mach/board-zoom.h

  #include mmc-twl4030.h

 @@ -385,6 +386,7 @@ static void __init omap_ldp_init(void)
        ads7846_dev_init();
        omap_serial_init(ldp_uart_config);
        usb_musb_init();
 +       zoom_flash_init();

        twl4030_mmc_init(mmc);
        /* link regulators to MMC adapters */
 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..1007e5d
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-zoom-flash.c
 @@ -0,0 +1,196 @@
 +/*
 + * arch/arm/mach-omap2/board-zoom-flash.c
 + *
 + * Copyright (C) 2008-09 Texas Instruments Inc.
 + *
 + * Modified from mach-omap2/board-2430sdp-flash.c
 + * Author(s): Rohit Choraria rohi...@ti.com
 + *            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/mtd.h
 +#include linux/mtd/partitions.h
 +#include linux/mtd/nand.h
 +#include linux/types.h
 +#include linux/io.h
 +
 +#include asm/mach/flash.h
 +#include mach/board.h
 +#include mach/gpmc.h
 +#include mach/nand.h
 +
 +#include mach/board-zoom.h
 +
 +#define NAND_CMD_UNLOCK1       0x23
 +#define NAND_CMD_UNLOCK2       0x24
 +/**
 + * @brief platform specific unlock function
 + *
 + * @param mtd - mtd info
 + * @param ofs - offset to start unlock from
 + * @param len - length to unlock
 + *
 + * @return - unlock status
 + */
 +static int omap_zoom_nand_unlock(struct mtd_info *mtd, loff_t ofs, size_t 
 len)
 +{
 +       int ret = 0;
 +       int chipnr;
 +       int status;
 +       unsigned long page;
 +       struct nand_chip *this = mtd-priv;
 +       printk(KERN_INFO nand_unlock: start: %08x, length: %d!\n,
 +                       (int)ofs, (int)len);
 +
 +       /* select the NAND device */
 +       chipnr = (int)(ofs  this-chip_shift);
 +       this-select_chip(mtd, chipnr);
 +       /* check the WP bit */
 +       this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
 +       if ((this-read_byte(mtd)  0x80) == 0) {
 +               printk(KERN_ERR nand_unlock: Device is write protected!\n);
 +               ret = -EINVAL;
 +               goto out;
 +       }
 +
 +