Re: RT tests on OMAP3
On Mon, Aug 31, 2009 at 11:16 PM, Cliff Brake 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). 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: RT tests on OMAP3
On Mon, Aug 31, 2009 at 4:50 PM, Cliff Brake 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 Seems to fix or mask the udev problems. But, with preempt-rt, and EHCI enabled, I still get messages continually scrolling: <7>ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 27 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 28 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 29 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 30 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 31 ehci-omap ehci-omap.0: devpath 2.1 ep2in 3strikes ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 1 ehci-oeteehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 27 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 28 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 29 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 30 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 31 ehci-omap ehci-omap.0: devpath 2.1 ep2in 3strikes ehci-omap ehci-omap.0: detected XactErr -omap.0: detected XactErr len 0/2048 retry 8 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 9 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 10 ehci-omap ehci-omap.0: detected XactErr len 0/2048 retry 11 The same hardware works fine without the RT patch. I got the following message early in the boot sequence: Starting udevusb%d: Error reading RX_CTL register: ffb9 usb%d: Failed to write RX_CTL mode to 0x: ffb9 asix: probe of 2-2.1:1.0 failed with error -71 hub 2-2:1.0: hub_port_status failed (err = -71) hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling... usb 2-2: USB disconnect, address 2 usb 2-2.1: USB disconnect, address 3 Unable to handle kernel NULL pointer dereference at virtual address 0014 usb 2-2: new high speed USB device using ehci-omap and address 4 pgd = cf05 [0014] *pgd=8f040031, *pte=, *ppte= Internal error: Oops: 0 [#1] PREEMPT Modules linked in: CPU: 0Not tainted (2.6.31-rc8-rt9-omap1 #12) PC is at 0x14 LR is at block_nodename+0x24/0x2c pc : [<0014>]lr : []psr: 2033 sp : cfaafe98 ip : 0007 fp : r10: c054dd28 r9 : cf024620 r8 : cf80cb60 r7 : cf983658 r6 : cf983650 r5 : cfaafebc r4 : cf983650 r3 : 0015 r2 : cf983600 r1 : cfaafebc r0 : cf983600 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user Control: 10c5387d Table: 8f050019 DAC: 0015 Process udevadm (pid: 606, stack limit = 0xcfaae2f0) Stack: (0xcfaafe98 to 0xcfab) fe80: c0234ed0 fea0: cf983658 cf983650 cf8c6000 cf8c6000 cf983658 c0234fc4 cf983650 fec0: c01dfc10 0003 c01dfc78 cfaafee0 c03d6aac fee0: c048d034 c0497048 cfaafef8 cf8bbec4 cf983650 ff00: 0003 cf95b160 cf983658 c054dd68 cf95b178 cfaaff80 0001eb30 c0235128 ff20: cf08c6e0 cf95b178 0003 cfb64758 c02346ac cfb64758 c0113908 ff40: cf08c6e0 0001df0c cfaaff80 0001df0c 0003 cfaae000 00026df0 c00c9070 ff60: cf564d00 0020 cf08c6e0 0001df0c 0003 c00c91d4 ff80: 0002cf58 0003 bef8b178 0004 ffa0: c0033084 c0032f00 0002cf58 0003 0003 0001df0c 0003 ffc0: 0002cf58 0003 bef8b178 0004 00026df4 00027008 00026df0 0001eb30 ffe0: 0001df0c bef8b168 0001a888 400d8bfc 4010 0003 41ffcf00 00fbcf00 Code: bad PC value. usb 2-2: udev 4, busnum 2, minor = 131 usb 2-2: New USB device found, idVendor=2001, idProduct=f103 usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 2-2: uevent It makes sense that enabling EHCI may trigger some more udev activity. 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: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path
Hi, On Mon, Aug 31, 2009 at 09:50:30PM +0200, ext Guzman Lugo, Fernando wrote: > >As far as I see this is not the dsp status but just a word to collect > >errors. More logical in this piece of your code is to use result word > >instead of status. > > Maybe you did not see far enough, but variable initStatus it the one use to > store DSPBridge errors, the variable status is use to collect the status > from calls to kernel functions. So I think we don't need two variables to > collect error from kernel, so we should use one, it could be status or > results it does not matters. What do you think? yes, this has to be cleaned up, but it should be an extra patch and not in this one. -- 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
RT tests on OMAP3
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 Any suggestions on how to debug this? I'd be glad to do testing, etc. The OMAP3 is superscaler where the PXA270 is not. 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
RE: [PATCH 2/8] dspbridge: Drop useless memory allocation
Hi,
Good finding.
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 2/8] dspbridge: Drop useless memory allocation
>
>From: Andy Shevchenko
>
>strcmp() should do the job without additional memory allocation and
>strncpy()/strcmp() calls.
>
>Additionally fix spelling.
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/rmgr/node.c | 15 ---
> 1 files changed, 4 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/dsp/bridge/rmgr/node.c
>b/drivers/dsp/bridge/rmgr/node.c
>index d3f0e34..e213b22 100644
>--- a/drivers/dsp/bridge/rmgr/node.c
>+++ b/drivers/dsp/bridge/rmgr/node.c
>@@ -404,7 +404,6 @@ DSP_STATUS NODE_Allocate(struct PROC_OBJECT
>*hProcessor,
> DSP_STATUS status = DSP_SOK;
> struct CMM_OBJECT *hCmmMgr = NULL; /* Shared memory manager hndl */
> u32 procId;
>- char *label;
> u32 pulValue;
> u32 dynextBase;
> u32 offSet = 0;
>@@ -691,18 +690,16 @@ func_cont2:
> }
> }
>
>- /* Comapare value read from Node Properties and check if it is same
>as
>+ /* Compare value read from Node Properties and check if it is same as
>* STACKSEGLABEL, if yes read the Address of STACKSEGLABEL, calculate
>* GPP Address, Read the value in that address and override the
>* uStackSeg value in task args */
> if (DSP_SUCCEEDED(status) &&
> (char *)pNode->dcdProps.objData.nodeObj.ndbProps.uStackSegName !=
> NULL) {
>- label = MEM_Calloc(sizeof(STACKSEGLABEL)+1, MEM_PAGED);
>- strncpy(label, STACKSEGLABEL, sizeof(STACKSEGLABEL)+1);
>-
>- if (strcmp((char *)pNode->dcdProps.objData.nodeObj.
>- ndbProps.uStackSegName, label) == 0) {
>+ if (strcmp((char *)
>+ pNode->dcdProps.objData.nodeObj.ndbProps.uStackSegName,
>+ STACKSEGLABEL) == 0) {
> status = hNodeMgr->nldrFxns.pfnGetFxnAddr(pNode->
>hNldrNode, "DYNEXT_BEG", &dynextBase);
> if (DSP_FAILED(status)) {
>@@ -744,10 +741,6 @@ func_cont2:
> ulStackSegVal;
>
> }
>-
>- if (label)
>- MEM_Free(label);
>-
> }
>
>
>--
>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
--
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 8/8] dspbridge: Check pointer before usage
Hi,
Please see my comments below.
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 8/8] dspbridge: Check pointer before usage
>
>From: Andy Shevchenko
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/rmgr/drv.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
>index d21071c..491dd39 100644
>--- a/drivers/dsp/bridge/rmgr/drv.c
>+++ b/drivers/dsp/bridge/rmgr/drv.c
>@@ -1545,6 +1545,10 @@ DSP_STATUS DRV_ReleaseResources(u32 dwContext,
>struct DRV_OBJECT *hDrvObject)
> for (pszdevNode = (struct DRV_EXT *)DRV_GetFirstDevExtension();
> pszdevNode != NULL; pszdevNode = (struct DRV_EXT *)
> DRV_GetNextDevExtension((u32)pszdevNode)) {
>+ if (!pDRVObject->devNodeString) {
>+ /* When this could happen? */
>+ continue;
>+ }
The function DSP_STATUS DRV_ReleaseResources is only called after call
DRV_Create where the list is created:
...
/* Create and Initialize List of device Extension */
pDRVObject->devNodeString = LST_Create();
...
If the list creation fails DRV_ReleaseResources is never call neither. Even if
it was possible pDRVObject->devNodeString is not changing between "for"
iterations so if you put a "continue" it will enter to the "for" loop and check
again pDRVObject->devNodeString what will be still null, so I think is should
be a "break" instead of "continue". What do you think?
> if ((u32)pszdevNode == dwContext) {
> /* Found it */
> /* Delete from the Driver object list */
>--
>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
Regards,
Fernando.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 7/8] DSPBRIDGE: Check return value
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 7/8] DSPBRIDGE: Check return value
>
>From: Andy Shevchenko
>
>PROC_GetProcessorId() potentially could return different to DSP_SOK status.
>We
>need to check it.
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/rmgr/drv.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
>index 44d7f2d..d21071c 100644
>--- a/drivers/dsp/bridge/rmgr/drv.c
>+++ b/drivers/dsp/bridge/rmgr/drv.c
>@@ -990,8 +990,12 @@ static DSP_STATUS PrintProcessInformation(void)
> spin_lock(&pCtxtList->proc_list_lock);
> list_for_each_entry(proc_obj_ptr, &pCtxtList->processor_list,
> proc_object) {
>- PROC_GetProcessorId(proc_obj_ptr, &procID);
>- if (procID == DSP_UNIT) {
>+ DSP_STATUS status2 = PROC_GetProcessorId(proc_obj_ptr,
>+ &procID);
>+ if (DSP_FAILED(status2)) {
>+ GT_0trace(curTrace, GT_7CLASS, "\n***ERROR:"
>+"Unable to get Processor Id***\n");
>+ } else if (procID == DSP_UNIT) {
> GT_0trace(curTrace, GT_4CLASS,
> "\nProcess connected to"
> " DSP Processor\n");
>--
>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
--
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 6/8] dspbridge: Check status before use return value
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 6/8] dspbridge: Check status before use return value
>
>From: Andy Shevchenko
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/rmgr/drv.c | 14 --
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
>index bedc34c..44d7f2d 100644
>--- a/drivers/dsp/bridge/rmgr/drv.c
>+++ b/drivers/dsp/bridge/rmgr/drv.c
>@@ -825,7 +825,13 @@ DSP_STATUS DRV_ProcDisplayResInfo(u8 *pBuf1, u32
>*pSize)
> u32 tempStrLen = 0, tempStrLen2 = 0;
> DSP_STATUS status = DSP_SOK;
>
>- CFG_GetObject((u32 *)&hDrvObject, REG_DRV_OBJECT);
>+ if (DSP_FAILED(CFG_GetObject((u32 *)&hDrvObject, REG_DRV_OBJECT))) {
>+ /* Should we print something? */
>+ *pBuf1 = 0;
>+ *pSize = 0;
>+ return DSP_EHANDLE;
>+ }
>+
> DRV_GetProcCtxtList(&pCtxt, (struct DRV_OBJECT *)hDrvObject);
> GT_0trace(curTrace, GT_ENTER, "*"
>"DRV_ProcDisplayResourceInfo:*\n");
>@@ -954,8 +960,12 @@ static DSP_STATUS PrintProcessInformation(void)
> u32 tempCount;
> u32 procID;
>
>+ if (DSP_FAILED(CFG_GetObject((u32 *)&hDrvObject, REG_DRV_OBJECT))) {
>+ /* Should we print something? */
>+ return DSP_EHANDLE;
>+ }
>+
> /* Get the Process context list */
>- CFG_GetObject((u32 *)&hDrvObject, REG_DRV_OBJECT);
> DRV_GetProcCtxtList(&pCtxtList, hDrvObject);
> GT_0trace(curTrace, GT_4CLASS, "\n### Debug information"
> " for DSP bridge ##\n");
>--
>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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/8] dspbridge: Check pointer before dereferencing it
It looks good.
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 5/8] dspbridge: Check pointer before dereferencing it
>
>From: Andy Shevchenko
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/rmgr/nldr.c | 15 ++-
> 1 files changed, 14 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/dsp/bridge/rmgr/nldr.c
>b/drivers/dsp/bridge/rmgr/nldr.c
>index 79f7505..8c162a1 100644
>--- a/drivers/dsp/bridge/rmgr/nldr.c
>+++ b/drivers/dsp/bridge/rmgr/nldr.c
>@@ -1560,6 +1560,13 @@ static DSP_STATUS LoadOvly(struct NLDR_NODEOBJECT
>*hNldrNode,
> }
>
> DBC_Assert(i < hNldr->nOvlyNodes);
>+
>+ if (!pONode) {
>+ /* Should we print warning here? */
>+ status = DSP_ENOTFOUND;
>+ goto func_end;
>+ }
>+
> switch (phase) {
> case NLDR_CREATE:
> pRefCount = &(pONode->createRef);
>@@ -1877,6 +1884,13 @@ static void UnloadOvly(struct NLDR_NODEOBJECT
>*hNldrNode, enum NLDR_PHASE phase)
> }
>
> DBC_Assert(i < hNldr->nOvlyNodes);
>+
>+ if (!pONode) {
>+ /* Should we print warning here? */
>+ status = DSP_ENOTFOUND;
>+ goto func_end;
>+ }
>+
> switch (phase) {
> case NLDR_CREATE:
> pRefCount = &(pONode->createRef);
>@@ -1917,7 +1931,6 @@ static void UnloadOvly(struct NLDR_NODEOBJECT
>*hNldrNode, enum NLDR_PHASE phase)
> }
> if (pOtherRef && *pOtherRef == 0)
> FreeSects(hNldr, pOtherSects, nOtherAlloc);
>-
> }
>
> /*
>--
>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
--
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/8] dspbridge: Check pointer returned by MEM_Calloc()
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 4/8] dspbridge: Check pointer returned by MEM_Calloc()
>
>From: Andy Shevchenko
>
>In case of NULL return DSP_EMEMORY status instead of DSP_SOK.
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/rmgr/drv.c | 23 +--
> 1 files changed, 13 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
>index 691c727..bedc34c 100644
>--- a/drivers/dsp/bridge/rmgr/drv.c
>+++ b/drivers/dsp/bridge/rmgr/drv.c
>@@ -1571,17 +1571,18 @@ static DSP_STATUS RequestBridgeResources(u32
>dwContext, s32 bRequest)
> /* Releasing resources by deleting the registry key */
> dwBuffSize = sizeof(struct CFG_HOSTRES);
> pResources = MEM_Calloc(dwBuffSize, MEM_NONPAGED);
>- if (DSP_FAILED(REG_GetValue(NULL, (char *)driverExt->szString,
>- CURRENTCONFIG, (u8 *)pResources, &dwBuffSize))) {
>- status = CFG_E_RESOURCENOTAVAIL;
>- GT_0trace(curTrace, GT_1CLASS,
>- "REG_GetValue Failed \n");
>- } else {
>- GT_0trace(curTrace, GT_1CLASS,
>- "REG_GetValue Succeeded \n");
>- }
>-
> if (pResources != NULL) {
>+ if (DSP_FAILED(REG_GetValue(NULL,
>+ (char *) driverExt->szString,
>+ CURRENTCONFIG, (u8 *) pResources, &dwBuffSize))) {
>+ status = CFG_E_RESOURCENOTAVAIL;
>+ GT_0trace(curTrace, GT_1CLASS,
>+ "REG_GetValue Failed \n");
>+ } else {
>+ GT_0trace(curTrace, GT_1CLASS,
>+ "REG_GetValue Succeeded \n");
>+ }
>+
> dwBuffSize = sizeof(shm_size);
> status = REG_GetValue(NULL, CURRENTCONFIG, SHMSIZE,
> (u8 *)&shm_size, &dwBuffSize);
>@@ -1646,6 +1647,8 @@ static DSP_STATUS RequestBridgeResources(u32
>dwContext, s32 bRequest)
>(u32)dwBuffSize);
> /* Set all the other entries to NULL */
> MEM_Free(pResources);
>+ } else {
>+ status = DSP_EMEMORY;
> }
> GT_0trace(curTrace, GT_ENTER, " <- RequestBridgeResources \n");
> return status;
>--
>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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/8] DSPBRIDGE: Check input value
Hi,
Good finding.
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 3/8] DSPBRIDGE: Check input value
>
>From: Andy Shevchenko
>
>Check input value before dereferencing it.
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/wmd/tiomap3430.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
>b/drivers/dsp/bridge/wmd/tiomap3430.c
>index db48c49..4cb78c7 100644
>--- a/drivers/dsp/bridge/wmd/tiomap3430.c
>+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
>@@ -1266,11 +1266,16 @@ static DSP_STATUS WMD_DEV_Destroy(struct
>WMD_DEV_CONTEXT *hDevContext)
> DSP_STATUS status = DSP_SOK;
> struct WMD_DEV_CONTEXT *pDevContext = (struct WMD_DEV_CONTEXT *)
> hDevContext;
>+
>+ /* It should never happen */
>+ if (!hDevContext)
>+ return DSP_EHANDLE;
>+
> DBG_Trace(DBG_ENTER, "Entering WMD_DEV_Destroy:n hDevContext
>::0x%x\n",
> hDevContext);
> /* first put the device to stop state */
> WMD_BRD_Delete(pDevContext);
>- if (pDevContext && pDevContext->pPtAttrs) {
>+ if (pDevContext->pPtAttrs) {
> pPtAttrs = pDevContext->pPtAttrs;
> if (pPtAttrs->hCSObj)
> SYNC_DeleteCS(pPtAttrs->hCSObj);
>--
>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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/8] dspbridge: Remove useless check
Hi,
Looks good.
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
>Sent: Thursday, August 27, 2009 7:19 AM
>To: linux-omap@vger.kernel.org
>Cc: Andy Shevchenko
>Subject: [PATCH 1/8] dspbridge: Remove useless check
>
>From: Andy Shevchenko
>
>Before this check zlLib already dereferenced on one hand and DBC_Require()
>checks for NULL on other hand.
>
>Signed-off-by: Andy Shevchenko
>---
> drivers/dsp/bridge/pmgr/dbll.c | 34 --
> 1 files changed, 16 insertions(+), 18 deletions(-)
>
>diff --git a/drivers/dsp/bridge/pmgr/dbll.c
>b/drivers/dsp/bridge/pmgr/dbll.c
>index 7c3cd40..e655f89 100644
>--- a/drivers/dsp/bridge/pmgr/dbll.c
>+++ b/drivers/dsp/bridge/pmgr/dbll.c
>@@ -909,26 +909,24 @@ void DBLL_unload(struct DBLL_LibraryObj *lib, struct
>DBLL_Attrs *attrs)
> goto func_end;
>
> zlLib->pTarget->attrs = *attrs;
>- if (zlLib != NULL) {
>- if (zlLib->mHandle) {
>- err = Dynamic_Unload_Module(zlLib->mHandle,
>- &zlLib->symbol.dlSymbol,
>- &zlLib->allocate.dlAlloc, &zlLib->init.dlInit);
>- if (err != 0) {
>- GT_1trace(DBLL_debugMask, GT_5CLASS,
>- "Dynamic_Unload_Module "
>- "failed: 0x%x\n", err);
>- }
>- }
>- /* remove symbols from symbol table */
>- if (zlLib->symTab != NULL) {
>- GH_delete(zlLib->symTab);
>- zlLib->symTab = NULL;
>+ if (zlLib->mHandle) {
>+ err = Dynamic_Unload_Module(zlLib->mHandle,
>+ &zlLib->symbol.dlSymbol,
>+ &zlLib->allocate.dlAlloc, &zlLib->init.dlInit);
>+ if (err != 0) {
>+ GT_1trace(DBLL_debugMask, GT_5CLASS,
>+ "Dynamic_Unload_Module "
>+ "failed: 0x%x\n", err);
> }
>- /* delete DOFF desc since it holds *lots* of host OS
>- * resources */
>- dofClose(zlLib);
> }
>+ /* remove symbols from symbol table */
>+ if (zlLib->symTab != NULL) {
>+ GH_delete(zlLib->symTab);
>+ zlLib->symTab = NULL;
>+ }
>+ /* delete DOFF desc since it holds *lots* of host OS
>+ * resources */
>+ dofClose(zlLib);
> func_end:
> DBC_Ensure(zlLib->loadRef >= 0);
> }
>--
>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
--
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: [DSPBRIGDE PATCH 3/6] dsp: bridge: rename Kbuild to Makefile
Acked-by: Fernando Guzman Lugo
>-Original Message-
>From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
>Sent: Friday, August 21, 2009 5:24 AM
>To: Hiroshi DOYU
>Cc: Ameya Palande; Guzman Lugo, Fernando; Linux OMAP Mailing List; Felipe
>Balbi
>Subject: [DSPBRIGDE PATCH 3/6] dsp: bridge: rename Kbuild to Makefile
>
>we all use Makefile, let's keep the name.
>
>Signed-off-by: Felipe Balbi
>---
> drivers/dsp/bridge/{Kbuild => Makefile} |0
> 1 files changed, 0 insertions(+), 0 deletions(-)
> rename drivers/dsp/bridge/{Kbuild => Makefile} (100%)
>
>diff --git a/drivers/dsp/bridge/Kbuild b/drivers/dsp/bridge/Makefile
>similarity index 100%
>rename from drivers/dsp/bridge/Kbuild
>rename to drivers/dsp/bridge/Makefile
>--
>1.6.3.3.385.g60647
>
--
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: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path
Hi, >-Original Message- >From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] >Sent: Saturday, August 29, 2009 2:19 AM >To: Guzman Lugo, Fernando >Cc: Felipe Balbi; Hiroshi DOYU; Ameya Palande; Linux OMAP Mailing List >Subject: Re: [DSPBRIGDE PATCH 6/6] dsp: bridge: beautify erro path > >On Sat, Aug 29, 2009 at 1:31 AM, Guzman Lugo, Fernando >wrote: > >>>result = status, isn't is? >>>or change status to result on previous lines. >> Yes, we need to assigned status to result, in order to report the error, >however I think we can get rid of result and use status instead, what do >you think? > >As far as I see this is not the dsp status but just a word to collect >errors. More logical in this piece of your code is to use result word >instead of status. Maybe you did not see far enough, but variable initStatus it the one use to store DSPBridge errors, the variable status is use to collect the status from calls to kernel functions. So I think we don't need two variables to collect error from kernel, so we should use one, it could be status or results it does not matters. What do you think? Regards, Fernando. > >-- >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 v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature
Venkat,
Few comments other wise patch looks fine to me.
> -Original Message-
> From: S, Venkatraman
> Sent: Thursday, August 27, 2009 4:42 PM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; Shilimkar, Santosh
> Subject: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading
> feature
>
> (Updated version of previous patch: http://marc.info/?l=linux-
> omap&m=125012097403050&w=2)
> Add sDMA driver support for descriptor autoloading feature.
> Descriptor autoloading is OMAP4 sDMA hardware capability that can be
> exploited for scatter gather scenarios.
>
> The feature works as described below
> 1) A sDMA channel is programmed to be in 'linked list' mode
> 2) The client (sDMA user) provides a list of descriptors in a linked list
> format
> 3) Each of the 'descriptor' (element in the linked list) contains an
> updated set of DMA configuration register values
> 4) Client starts DMA transfer
> 5) sDMA controller loads the first element to its register configuration
> memory and executes the transfer
> 6) After completion, loads the next element (in linked list) to
> configuration memory and executes the transfer, without MCU intervention.
> 7) Interrupt is generated after all transfers are completed; this can be
> configured to be done differently.
>
> Configurations and additional features
> 1) Fast mode & non-fast mode
>Fast mode/non-fast decides on how the first transfer begins. In
> non-fast mode, the first element in the linked list is loaded only after
> completing the transfer according to the configurations already in the
> sDMA channel registers. In fast mode, the loading of the first element
> precedes the transfer.
>
> 2) Pause / resume of transfers
>A transfer can be paused after a descriptor set has been loaded,
> provided the 'pause bit' is set in the linked list element.
> An ongoing transfer cannot be paused. If the 'pause bit' is set, transfer
> is not started after loading the register set from memory.
> Such a transfer can be resumed later.
Would it be good if we move this description just above those APIs. Even though
this information is good to be here but later once merged, this would go in
commit history.
Somebody reading code also would benefit from this info. I leave that decision
to you.
> 3) Descriptor types
>3 possible configurations of descriptors (initialized as linked
> list elements) are possible. Type 1 provides the maximum flexibility,
> which contains most register definitions of a DMA logical channel. Fewer
> options are present in type 2. Type 3 can just modify source/destinations
> address of transfers. In all transfers, unmodified registers settings are
> maintained for the next transfer.
This information too should be in source code somewhere.
> Patch provides options / API for
> 1) Setting up a descriptor loading for DMA channel for sg type transfers
> 2) configuration with linked list elements
> 3) Starting / pause and resume of the said transfers, query state
> 4) Closing/Releasing the DMA channel
>
> The patches are generated against kernel 2.6.31-rc1, tested on OMAP4
> simulator platform.
>
> Summary:
> OMAP sDMA driver changes for descriptor autoloading feature.
> Signed-off-by: Venkatraman S
>
> ---
> arch/arm/plat-omap/dma.c | 303
> +
> arch/arm/plat-omap/include/mach/dma.h | 98 +++
> 2 files changed, 401 insertions(+), 0 deletions(-)
>
> 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
> #include
> #include
> +#include
>
> #include
> #include
> @@ -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_ACTIVE 0x01
> #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;
FW: [RFC][PATCH]: Adding support for omap-serail driver
Resend to linux-omap
-Original Message-
From: HU TAO-TGHK48
Sent: Monday, August 31, 2009 7:50 PM
To: 'vimal singh'; linux-omap@vger.kernel.org; LKML;
linux-ser...@vger.kernel.org
Cc: Ye Yuan.Bo-A22116; Chen Xiaolong-A21785
Subject: RE: [RFC][PATCH]: Adding support for omap-serail driver
1. Shall we cleanup PM related stuff in arch/arm/mach-omap2/serial.c as
well?
Originally serail.c register UART IRQ to decide if UART idle for a
while and is able to enter low power mode (e.g. retention).
To work with original 8250 driver, it is probably the only way since
8250 is not aware of OMAP PM.
However it would be more reasonable to merge PM stuff to
omap-serial.c. since the new driver is already OMAP specific
2. There is an issue for DMA with current implementation in serial.c
When Rx DMA is active NO Rx IRQ will be generated.
So serial.c will easily set uart->can_sleep with "1" even there is
Rx DMA ongoing
+ if ((iir & 0x4) && up->use_dma) {
+ up->ier &= ~UART_IER_RDI;
+ serial_out(up, UART_IER, up->ier
In my view, the best way is to do the idle detection in
omap_serial.c.
3. Can a flag be added to enable auto-RTS and auto-CRT individually?
OMAP HW supports independent auto-RTS and auto-CTS.
And we had a case that only auto-RTS can be enabled due to HW design.
Below is the idea.
In arch/arm/mach-omap2/serial.c
static struct plat_serialomap_port serial_platform_data[] = {
{
.membase= IO_ADDRESS(OMAP_UART1_BASE),
.irq= 72,
.regshift = 2,
+ .rtscts = UART_EFR_RTS
In omap_serial.c
+static int serial_omap_probe(struct platform_device *pdev) {
struct plat_serialomap_port *pdata = pdev->dev.platform_data; ... ...
+ up->rtscts = pdata->rtscts;
serial_omap_set_termios(struct uart_port *port, struct ktermios
*termios,
struct ktermios *old)
{
... ...
if (termios->c_cflag & CRTSCTS)
+ efr |= up->rtscts;
Thanks
Tao Hu
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of vimal singh
Sent: Friday, August 28, 2009 9:50 PM
To: linux-omap@vger.kernel.org; LKML; linux-ser...@vger.kernel.org
Subject: [RFC][PATCH]: Adding support for omap-serail driver
From: Govindraj R
This patch adds support for OMAP3430-HIGH SPEED UART Controller.
It currently adds support for the following features.
1. Supports Interrupt Mode for all three UARTs on SDP/ZOOM2.
2. Supports DMA Mode for all three UARTs on SDP/ZOOM2.
3. Supports Hardware flow control (CTS/RTS) on SDP/ZOOM2.
4. Supports 3.6Mbps baudrate on SDP/ZOOM2.
5. Debug Console support on all UARTs on SDP/ZOOM2.
6. Support for quad uart on ZOOM2 board.
The reason for adding this new driver alternative to 8250 is to avoid
polluting 8250 driver with too many omap specific data as 8250 already
supports more than 16 different uart controllers and may need too many
omap-platform checks to implement feature like DMA support.
Signed-off-by: Govindraj R
---
arch/arm/plat-omap/include/mach/omap-serial.h | 84 +
drivers/serial/Kconfig| 92 +
drivers/serial/Makefile |1
drivers/serial/omap-serial.c | 1431
++
4 files changed, 1608 insertions(+)
diff --git a/arch/arm/plat-omap/include/mach/omap-serial.h
b/arch/arm/plat-omap/include/mach/omap-serial.h
new file mode 100644
index 000..d1b0bf2
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/omap-serial.h
@@ -0,0 +1,84 @@
+/*
+ * arch/arm/plat-omap/include/mach/omap-serial.h
+ *
+ * Driver for OMAP3430 UART controller.
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * Authors:
+ * Thara Gopinath
+ * Govindraj R
+ *
+ * This file is licensed under the terms of the GNU General Public
+License
+ * version 2. This program is licensed "as is" without any warranty of
+any
+ * kind, whether express or implied.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include
+#include
+
+/* TI OMAP CONSOLE */
+#define PORT_OMAP 86
+
+#define DRIVER_NAME"omap-hsuart"
+
+/*
+ * We default to IRQ0 for the "no irq" hack. Some
+ * machine types want others as well - they're free
+ * to redefine this in their header file.
+ */
+#define is_real_interrupt(irq) ((irq) != 0)
+
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ #endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+#define OMAP_MDR1_DISABLE 0x07
+#define OMAP_MDR1_MODE13X 0x03
+#define OMAP_MDR1_MODE16X 0x00
+#define OMAP_MODE13X_SPEED 230400
+#endif
+
+#define CONSOLE_NAME "console="
+
+#define UART_CLK (4800)
+#define QUART_CLK (1843200)
+
+/* UART NUMBERS */
+#define UART1 (0x0)
+#define UART2 (
Re: [PATCH 1/3] MFD: TWL4030: Add support for TWL4030/5030 dynamic power switching
Hi Amit, On Mon, Aug 31, 2009 at 01:53:32PM +0300, Amit Kucheria wrote: > On Fri, Aug 28, 2009 at 8:47 PM, Samuel Ortiz wrote: > > Hi Amit, > > > > On Mon, Aug 17, 2009 at 05:01:46PM +0300, Amit Kucheria wrote: > >> + > >> +#include > > You'll have to make your Kconfig entry depend on ARM if you want to include > > this file. Too bad you need it just for the special sdp and ldp cases, but I > > guess there's no other solution. > > > > Cheers, > > Samuel. > > Hi Samuel, > > Modified patch with ARM dependency attached. Thanks. All 3 patches finally applied to my for-next branch, thanks for your work. Cheers, Samuel. > Regards, > Amit > From ee0a4fefed7b1867234d96db6acbf62bbd60c0c0 Mon Sep 17 00:00:00 2001 > From: Amit Kucheria > Date: Mon, 6 Jul 2009 16:42:37 +0300 > Subject: [PATCH 1/3] MFD: TWL4030: Add support for TWL4030/5030 dynamic power > switching > > The TWL4030/5030 family of multifunction devices allows board-specific > control of the the various regulators, clock and reset lines through > 'scripts' that are loaded into its memory. This allows for Dynamic Power > Switching (DPS). > > Implement board-independent core support for DPS that is then used by > board-specific code to load custom DPS scripts. > > Signed-off-by: Amit Kucheria > Cc: sa...@linux.intel.com > Cc: dbrown...@users.sourceforge.net > Cc: linux-ker...@vger.kernel.org > Cc: linux-omap@vger.kernel.org > --- > drivers/mfd/Kconfig | 13 ++ > drivers/mfd/Makefile|1 + > drivers/mfd/twl4030-core.c | 10 + > drivers/mfd/twl4030-power.c | 466 > +++ > include/linux/i2c/twl4030.h | 94 - > 5 files changed, 574 insertions(+), 10 deletions(-) > create mode 100644 drivers/mfd/twl4030-power.c > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 491ac0f..c0f1695 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -108,6 +108,19 @@ config TWL4030_CORE > high speed USB OTG transceiver, an audio codec (on most > versions) and many other features. > > +config TWL4030_POWER > + bool "Support power resources on TWL4030 family chips" > + depends on TWL4030_CORE && ARM > + help > + Say yes here if you want to use the power resources on the > + TWL4030 family chips. Most of these resources are regulators, > + which have a separate driver; some are control signals, such > + as clock request handshaking. > + > + This driver uses board-specific data to initialize the resources > + and load scripts controling which resources are switched off/on > + or reset when a sleep, wakeup or warm reset event occurs. > + > config MFD_TMIO > bool > default n > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 6f8a9a1..84b9eda 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -23,6 +23,7 @@ obj-$(CONFIG_TPS65010) += tps65010.o > obj-$(CONFIG_MENELAUS) += menelaus.o > > obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-irq.o > +obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o > > obj-$(CONFIG_MFD_CORE) += mfd-core.o > > diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c > index ca54996..28a45a3 100644 > --- a/drivers/mfd/twl4030-core.c > +++ b/drivers/mfd/twl4030-core.c > @@ -89,6 +89,12 @@ > #define twl_has_madc() false > #endif > > +#ifdef CONFIG_TWL4030_POWER > +#define twl_has_power()true > +#else > +#define twl_has_power()false > +#endif > + > #if defined(CONFIG_RTC_DRV_TWL4030) || defined(CONFIG_RTC_DRV_TWL4030_MODULE) > #define twl_has_rtc()true > #else > @@ -788,6 +794,10 @@ twl4030_probe(struct i2c_client *client, const struct > i2c_device_id *id) > /* setup clock framework */ > clocks_init(&client->dev); > > + /* load power event scripts */ > + if (twl_has_power() && pdata->power) > + twl4030_power_init(pdata->power); > + > /* Maybe init the T2 Interrupt subsystem */ > if (client->irq > && pdata->irq_base > diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c > new file mode 100644 > index 000..e7688b0 > --- /dev/null > +++ b/drivers/mfd/twl4030-power.c > @@ -0,0 +1,466 @@ > +/* > + * linux/drivers/i2c/chips/twl4030-power.c > + * > + * Handle TWL4030 Power initialization > + * > + * Copyright (C) 2008 Nokia Corporation > + * Copyright (C) 2006 Texas Instruments, Inc > + * > + * Written byKalle Jokiniemi > + * Peter De Schrijver > + * Several fixes by Amit Kucheria > + * > + * This file is subject to the terms and conditions of the GNU General > + * Public License. See the file "COPYING" in the main directory of this > + * archive for more details. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTA
Re: Beagleboard B6 woes
Mikko Rapeli wrote: Hello, I'd like to test out newer kernel on a Beagleboard B6 but latest trees from Linus, linux-omap and linux-omap/for-next seem to be failing at early boot [1] with omap3_beagle_defconfig. Some bisecting shows that ARM_UNWIND broke something in the defconfig since kernels before adf8b37bafc1495393201a2ae4235846371870d0 "[ARM] 5386/2: unwind: Add Makefile and Kconfig entries for ARM stack unwinding" work. 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-omap&m=124175324604568&w=2 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. Jon -- 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
* Hiremath, Vaibhav [090831 07:44]: > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim > > Sent: Monday, August 31, 2009 8:11 PM > > To: Steve Sakoman; Artem Bityutskiy; linux-ker...@vger.kernel.org; > > linux-omap@vger.kernel.org Mailing List > > Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen > > Subject: RE: [PATCH 00/18] OMAP: DSS2: Intro > > > > > > > > > -Original Message- > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Steve > > > Sakoman > > > Sent: Monday, August 31, 2009 7:50 PM > > > To: Artem Bityutskiy > > > Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen; linux- > > ker...@vger.kernel.org; linux- > > > o...@vger.kernel.org Mailing List > > > Subject: Re: [PATCH 00/18] OMAP: DSS2: Intro > > > > > > On Mon, Aug 31, 2009 at 2:23 AM, Artem > > Bityutskiy wrote: > > > > > > > We are using DSS2 in Nokia for about a year already. N900 is > > using this > > > > code, for example. Other (non-Nokia) projects are using DSS2 as > > well. > > > > The code was public for long time and was sent several times for > > review. > > > > > > > > In any case, > > > > > > > > Tested-by: Artem Bityutskiy > > > > > > Gumstix has also been shipping with DSS2 on their Overo product > > for > > > many months now. > > > > > > Tested-by: Steve Sakoman > > > > If there is a concern on OMAP2 support, I can confirm that there is > > no difference between OMAP2 and OMAP3 Display Subsystem from > > Register level. So what ever works on OMAP3 DSS2 should straight > > away work for OMAP2 as well. > > > > I agree with rest of the folks here, we should get DSS2 merged in > > mainline. It is being extensively used on all OMAP3 platforms. > > > [Hiremath, Vaibhav] I am also agreeing with the point that we should merge > the DSS2; it's now almost year we have migrated to DSS2. Most of our > customers are based out of it. Yeh I agree this should get merged. I think it's best to merge this via the fb list and I've acked the patches that I'm concerned with already. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/18] OMAP: DSS2: Intro
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim > Sent: Monday, August 31, 2009 8:11 PM > To: Steve Sakoman; Artem Bityutskiy; linux-ker...@vger.kernel.org; > linux-omap@vger.kernel.org Mailing List > Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen > Subject: RE: [PATCH 00/18] OMAP: DSS2: Intro > > > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Steve > > Sakoman > > Sent: Monday, August 31, 2009 7:50 PM > > To: Artem Bityutskiy > > Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen; linux- > ker...@vger.kernel.org; linux- > > o...@vger.kernel.org Mailing List > > Subject: Re: [PATCH 00/18] OMAP: DSS2: Intro > > > > On Mon, Aug 31, 2009 at 2:23 AM, Artem > Bityutskiy wrote: > > > > > We are using DSS2 in Nokia for about a year already. N900 is > using this > > > code, for example. Other (non-Nokia) projects are using DSS2 as > well. > > > The code was public for long time and was sent several times for > review. > > > > > > In any case, > > > > > > Tested-by: Artem Bityutskiy > > > > Gumstix has also been shipping with DSS2 on their Overo product > for > > many months now. > > > > Tested-by: Steve Sakoman > > If there is a concern on OMAP2 support, I can confirm that there is > no difference between OMAP2 and OMAP3 Display Subsystem from > Register level. So what ever works on OMAP3 DSS2 should straight > away work for OMAP2 as well. > > I agree with rest of the folks here, we should get DSS2 merged in > mainline. It is being extensively used on all OMAP3 platforms. > [Hiremath, Vaibhav] I am also agreeing with the point that we should merge the DSS2; it's now almost year we have migrated to DSS2. Most of our customers are based out of it. Thanks, Vaibhav > Regards, > Khasim > -- > 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
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Steve > Sakoman > Sent: Monday, August 31, 2009 7:50 PM > To: Artem Bityutskiy > Cc: Andrew Morton; Tony Lindgren; Tomi Valkeinen; > linux-ker...@vger.kernel.org; linux- > o...@vger.kernel.org Mailing List > Subject: Re: [PATCH 00/18] OMAP: DSS2: Intro > > On Mon, Aug 31, 2009 at 2:23 AM, Artem Bityutskiy wrote: > > > We are using DSS2 in Nokia for about a year already. N900 is using this > > code, for example. Other (non-Nokia) projects are using DSS2 as well. > > The code was public for long time and was sent several times for review. > > > > In any case, > > > > Tested-by: Artem Bityutskiy > > Gumstix has also been shipping with DSS2 on their Overo product for > many months now. > > Tested-by: Steve Sakoman If there is a concern on OMAP2 support, I can confirm that there is no difference between OMAP2 and OMAP3 Display Subsystem from Register level. So what ever works on OMAP3 DSS2 should straight away work for OMAP2 as well. I agree with rest of the folks here, we should get DSS2 merged in mainline. It is being extensively used on all OMAP3 platforms. Regards, Khasim -- 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
On Mon, Aug 31, 2009 at 2:23 AM, Artem Bityutskiy wrote: > We are using DSS2 in Nokia for about a year already. N900 is using this > code, for example. Other (non-Nokia) projects are using DSS2 as well. > The code was public for long time and was sent several times for review. > > In any case, > > Tested-by: Artem Bityutskiy Gumstix has also been shipping with DSS2 on their Overo product for many months now. Tested-by: Steve Sakoman -- 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
Op 31 aug 2009, om 11:23 heeft Artem Bityutskiy het volgende geschreven: On 08/28/2009 03:25 PM, Tomi Valkeinen wrote: This patch set implement new display subsystem driver (DSS2) and omapfb driver for OMAP2/3. The patches have been reviewed on linux-omap and linux- fbdev-devel mailing lists. The patches can also be found from http://gitorious.org/linux-omap-dss2/linux The patches include DSS documentation patch that includes more instructions for module parameters, sysfs files etc. The patches enable DSS2 for OMAP3430 SDP board. DSS2 is used in various boards, for example Nokia N900, Beagle Board and Overo. I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2 and the possible fixes needed should be minimal. OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards. DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav Hiremath, and perhaps some others that I have forgotten =). Tony, Andrew, how could we merge this code (unless there are requests to change something, which does not seem to be the case.). It seems like there is no maintainer who could merge this. Or there is? Would Tomi need to send a direct pull request to Linus, or this could got via Tony? We are using DSS2 in Nokia for about a year already. N900 is using this code, for example. Other (non-Nokia) projects are using DSS2 as well. The code was public for long time and was sent several times for review. With my beagleboard hat on: I agree with Artem, let's get this merged. I hope other TI folk can put their TI hat on and say something nice about dss2 as well :) 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
RE: [RFC][PATCH]: Adding support for omap-serail driver
1. Shall we cleanup PM related stuff in arch/arm/mach-omap2/serial.c as
well?
Originally serail.c register UART IRQ to decide if UART idle for a
while and is able to enter low power mode (e.g. retention).
To work with original 8250 driver, it is probably the only way since
8250 is not aware of OMAP PM.
However it would be more reasonable to merge PM stuff to
omap-serial.c. since the new driver is already OMAP specific
2. There is an issue for DMA with current implementation in serial.c
When Rx DMA is active NO Rx IRQ will be generated.
So serial.c will easily set uart->can_sleep with "1" even there is
Rx DMA ongoing
+ if ((iir & 0x4) && up->use_dma) {
+ up->ier &= ~UART_IER_RDI;
+ serial_out(up, UART_IER, up->ier
In my view, the best way is to do the idle detection in
omap_serial.c.
3. Can a flag be added to enable auto-RTS and auto-CRT individually?
OMAP HW supports independent auto-RTS and auto-CTS.
And we had a case that only auto-RTS can be enabled due to HW design.
Below is the idea.
In arch/arm/mach-omap2/serial.c
static struct plat_serialomap_port serial_platform_data[] = {
{
.membase= IO_ADDRESS(OMAP_UART1_BASE),
.irq= 72,
.regshift = 2,
+ .rtscts = UART_EFR_RTS
In omap_serial.c
+static int serial_omap_probe(struct platform_device *pdev) {
struct plat_serialomap_port *pdata = pdev->dev.platform_data;
... ...
+ up->rtscts = pdata->rtscts;
serial_omap_set_termios(struct uart_port *port, struct ktermios
*termios,
struct ktermios *old)
{
... ...
if (termios->c_cflag & CRTSCTS)
+ efr |= up->rtscts;
Thanks
Tao Hu
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of vimal singh
Sent: Friday, August 28, 2009 9:50 PM
To: linux-omap@vger.kernel.org; LKML; linux-ser...@vger.kernel.org
Subject: [RFC][PATCH]: Adding support for omap-serail driver
From: Govindraj R
This patch adds support for OMAP3430-HIGH SPEED UART Controller.
It currently adds support for the following features.
1. Supports Interrupt Mode for all three UARTs on SDP/ZOOM2.
2. Supports DMA Mode for all three UARTs on SDP/ZOOM2.
3. Supports Hardware flow control (CTS/RTS) on SDP/ZOOM2.
4. Supports 3.6Mbps baudrate on SDP/ZOOM2.
5. Debug Console support on all UARTs on SDP/ZOOM2.
6. Support for quad uart on ZOOM2 board.
The reason for adding this new driver alternative to 8250 is to avoid
polluting 8250 driver with too many omap specific data as 8250 already
supports more than 16 different uart controllers and may need too many
omap-platform checks to implement feature like DMA support.
Signed-off-by: Govindraj R
---
arch/arm/plat-omap/include/mach/omap-serial.h | 84 +
drivers/serial/Kconfig| 92 +
drivers/serial/Makefile |1
drivers/serial/omap-serial.c | 1431
++
4 files changed, 1608 insertions(+)
diff --git a/arch/arm/plat-omap/include/mach/omap-serial.h
b/arch/arm/plat-omap/include/mach/omap-serial.h
new file mode 100644
index 000..d1b0bf2
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/omap-serial.h
@@ -0,0 +1,84 @@
+/*
+ * arch/arm/plat-omap/include/mach/omap-serial.h
+ *
+ * Driver for OMAP3430 UART controller.
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * Authors:
+ * Thara Gopinath
+ * Govindraj R
+ *
+ * This file is licensed under the terms of the GNU General Public
+License
+ * version 2. This program is licensed "as is" without any warranty of
+any
+ * kind, whether express or implied.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include
+#include
+
+/* TI OMAP CONSOLE */
+#define PORT_OMAP 86
+
+#define DRIVER_NAME"omap-hsuart"
+
+/*
+ * We default to IRQ0 for the "no irq" hack. Some
+ * machine types want others as well - they're free
+ * to redefine this in their header file.
+ */
+#define is_real_interrupt(irq) ((irq) != 0)
+
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ #endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+#define OMAP_MDR1_DISABLE 0x07
+#define OMAP_MDR1_MODE13X 0x03
+#define OMAP_MDR1_MODE16X 0x00
+#define OMAP_MODE13X_SPEED 230400
+#endif
+
+#define CONSOLE_NAME "console="
+
+#define UART_CLK (4800)
+#define QUART_CLK (1843200)
+
+/* UART NUMBERS */
+#define UART1 (0x0)
+#define UART2 (0x1)
+#define UART3 (0x2)
+#define QUART (0x3)
+
+#ifdef CONFIG_MACH_OMAP_ZOOM2
+#define MAX_UARTS QUART
+#else
+#define MAX_UARTS UART3
+#endif
+
+#define UART_BASE(uart_no) (uart_no == UART1) ?
OMAP_UART1_BASE :\
+ (uart_
Re: [PATCH 1/3] MFD: TWL4030: Add support for TWL4030/5030 dynamic power switching
On Fri, Aug 28, 2009 at 8:47 PM, Samuel Ortiz wrote: > Hi Amit, > > On Mon, Aug 17, 2009 at 05:01:46PM +0300, Amit Kucheria wrote: >> + >> +#include > You'll have to make your Kconfig entry depend on ARM if you want to include > this file. Too bad you need it just for the special sdp and ldp cases, but I > guess there's no other solution. > > Cheers, > Samuel. Hi Samuel, Modified patch with ARM dependency attached. Regards, Amit From ee0a4fefed7b1867234d96db6acbf62bbd60c0c0 Mon Sep 17 00:00:00 2001 From: Amit Kucheria Date: Mon, 6 Jul 2009 16:42:37 +0300 Subject: [PATCH 1/3] MFD: TWL4030: Add support for TWL4030/5030 dynamic power switching The TWL4030/5030 family of multifunction devices allows board-specific control of the the various regulators, clock and reset lines through 'scripts' that are loaded into its memory. This allows for Dynamic Power Switching (DPS). Implement board-independent core support for DPS that is then used by board-specific code to load custom DPS scripts. Signed-off-by: Amit Kucheria Cc: sa...@linux.intel.com Cc: dbrown...@users.sourceforge.net Cc: linux-ker...@vger.kernel.org Cc: linux-omap@vger.kernel.org --- drivers/mfd/Kconfig | 13 ++ drivers/mfd/Makefile|1 + drivers/mfd/twl4030-core.c | 10 + drivers/mfd/twl4030-power.c | 466 +++ include/linux/i2c/twl4030.h | 94 - 5 files changed, 574 insertions(+), 10 deletions(-) create mode 100644 drivers/mfd/twl4030-power.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 491ac0f..c0f1695 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -108,6 +108,19 @@ config TWL4030_CORE high speed USB OTG transceiver, an audio codec (on most versions) and many other features. +config TWL4030_POWER + bool "Support power resources on TWL4030 family chips" + depends on TWL4030_CORE && ARM + help + Say yes here if you want to use the power resources on the + TWL4030 family chips. Most of these resources are regulators, + which have a separate driver; some are control signals, such + as clock request handshaking. + + This driver uses board-specific data to initialize the resources + and load scripts controling which resources are switched off/on + or reset when a sleep, wakeup or warm reset event occurs. + config MFD_TMIO bool default n diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 6f8a9a1..84b9eda 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_TPS65010) += tps65010.o obj-$(CONFIG_MENELAUS) += menelaus.o obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-irq.o +obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o obj-$(CONFIG_MFD_CORE) += mfd-core.o diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c index ca54996..28a45a3 100644 --- a/drivers/mfd/twl4030-core.c +++ b/drivers/mfd/twl4030-core.c @@ -89,6 +89,12 @@ #define twl_has_madc() false #endif +#ifdef CONFIG_TWL4030_POWER +#define twl_has_power()true +#else +#define twl_has_power()false +#endif + #if defined(CONFIG_RTC_DRV_TWL4030) || defined(CONFIG_RTC_DRV_TWL4030_MODULE) #define twl_has_rtc() true #else @@ -788,6 +794,10 @@ twl4030_probe(struct i2c_client *client, const struct i2c_device_id *id) /* setup clock framework */ clocks_init(&client->dev); + /* load power event scripts */ + if (twl_has_power() && pdata->power) + twl4030_power_init(pdata->power); + /* Maybe init the T2 Interrupt subsystem */ if (client->irq && pdata->irq_base diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c new file mode 100644 index 000..e7688b0 --- /dev/null +++ b/drivers/mfd/twl4030-power.c @@ -0,0 +1,466 @@ +/* + * linux/drivers/i2c/chips/twl4030-power.c + * + * Handle TWL4030 Power initialization + * + * Copyright (C) 2008 Nokia Corporation + * Copyright (C) 2006 Texas Instruments, Inc + * + * Written by Kalle Jokiniemi + * Peter De Schrijver + * Several fixes by Amit Kucheria + * + * This file is subject to the terms and conditions of the GNU General + * Public License. See the file "COPYING" in the main directory of this + * archive for more details. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include + +#include + +static u8 twl4030_start_script_address = 0x2b; + +#define PWR_P1_SW_EVENTS 0x10 +#define PWR_DEVOFF (1<<0) + +#define PHY_TO_OFF_PM_MASTER(p) (p - 0x36) +#define PHY_TO_OFF_PM_RECEIVER(p) (p - 0x5b) + +/* resource - hfclk */ +#define R_HFCLKOU
RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support
OSWR stands for Open Switch With Retention. This is one of the target power states where logic is lost for all the modules in the power domain except for the ones with Built in retention Flip Flops. This is the main difference between OFF and OSWR mode. Because of this feature, wake up latency for OSWR is lesser than OFF mode but more than CSWR (Closed Switch With Retention - where module logic retained). Vishwa -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, August 28, 2009 9:37 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH][RFC] OMAP3: PM: Adding OSWR support * Thara Gopinath [090827 09:54]: > This patch adds OSWR support for MPU/CORE domains in CPUidle. > Two new C states are being added to the existing C states > which makes the new states look like below. Please explain what OSWR means, the patch description should be clear to everybody. I guess you mean Open SWitch Retention? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
Beagleboard B6 woes
Hello, I'd like to test out newer kernel on a Beagleboard B6 but latest trees from Linus, linux-omap and linux-omap/for-next seem to be failing at early boot [1] with omap3_beagle_defconfig. Some bisecting shows that ARM_UNWIND broke something in the defconfig since kernels before adf8b37bafc1495393201a2ae4235846371870d0 "[ARM] 5386/2: unwind: Add Makefile and Kconfig entries for ARM stack unwinding" work. On the other hand, setting ARM_UNWIND to n which falls back to FRAME_POINTERs work until 84e250ffa76dddc1bad84e04248a27f442c25986 "musb: proper hookup to transceiver drivers". So, is this just a broken config thing? Does anyone have a working Beagleboard config for linux-2.6 or linux-omap trees? Thanks, -Mikko [1] early boot failing example on Beagleboard: ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-2.6.31-rc8-00021-g36d568e- Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1760556 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. -- 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
On 08/28/2009 03:25 PM, Tomi Valkeinen wrote: This patch set implement new display subsystem driver (DSS2) and omapfb driver for OMAP2/3. The patches have been reviewed on linux-omap and linux-fbdev-devel mailing lists. The patches can also be found from http://gitorious.org/linux-omap-dss2/linux The patches include DSS documentation patch that includes more instructions for module parameters, sysfs files etc. The patches enable DSS2 for OMAP3430 SDP board. DSS2 is used in various boards, for example Nokia N900, Beagle Board and Overo. I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2 and the possible fixes needed should be minimal. OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards. DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav Hiremath, and perhaps some others that I have forgotten =). Tony, Andrew, how could we merge this code (unless there are requests to change something, which does not seem to be the case.). It seems like there is no maintainer who could merge this. Or there is? Would Tomi need to send a direct pull request to Linus, or this could got via Tony? We are using DSS2 in Nokia for about a year already. N900 is using this code, for example. Other (non-Nokia) projects are using DSS2 as well. The code was public for long time and was sent several times for review. In any case, Tested-by: Artem Bityutskiy -- 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
