RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
> I agree, the check should be in proc map, and should be optional. > However, I would prefer it to be an all-or-nothing option, > how about in kconfig? > -- One other way is we can use a bit mask in map attributes argument in DSP Proc Map function to enforce the check on the buffer. What are the reasons as why you want to make it all-or-nothing option ? Thank you, Best regards, Hari > -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Monday, June 08, 2009 4:19 PM > To: Kanigeri, Hari > Cc: Hiroshi DOYU; Ramirez Luna, Omar; > ameya.pala...@nokia.com; linux-omap@vger.kernel.org > Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for > unlocked_ioctl > > On Mon, Jun 8, 2009 at 11:49 PM, Kanigeri, > Hari wrote: > > Hi Doyu-san, > > > > Regarding > > > >> http://marc.info/?l=linux-omap&m=124201773423892&w=2 > >> I think that the first one should be merged into d.o-z.org > now, but > >> for the second one about 128 byte alignment. let me know your > >> thought/plan on it. > > > > -- I think you sent this patch as a probable fix for the > slab corruption that was observed in Bridge driver, but then > we found that slab corruption was due to some other issue in > Bridge driver and not due to the cache alignment. > > > > Irrespective of above point, I think it is good to enforce > the cache alignment check, but I think the check should be in > Proc Map function and to start with the check should be under > a flag so as not to affect some MM applications that use > padding to get over the alignment issue. > > I agree, the check should be in proc map, and should be optional. > However, I would prefer it to be an all-or-nothing option, > how about in kconfig? > > -- > Felipe Contreras > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3] DSPBRIDGE: Buffer size warning fixes
Hi Ameya,
This patch looks good, Thanks.
Regards,
Fernando.
-Original Message-
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Sent: Friday, June 05, 2009 8:03 AM
To: linux-omap@vger.kernel.org
Cc: Guzman Lugo, Fernando; Kanigeri, Hari
Subject: [PATCHv3] DSPBRIDGE: Buffer size warning fixes
Signed-off-by: Ameya Palande
---
drivers/dsp/bridge/pmgr/cod.c|3 ++-
drivers/dsp/bridge/rmgr/drv.c|5 +++--
drivers/dsp/bridge/services/regsup.c |6 --
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/cod.c b/drivers/dsp/bridge/pmgr/cod.c
index 6363f1e..2da46bd 100644
--- a/drivers/dsp/bridge/pmgr/cod.c
+++ b/drivers/dsp/bridge/pmgr/cod.c
@@ -628,7 +628,8 @@ DSP_STATUS COD_OpenBase(struct COD_MANAGER *hMgr, IN char
*pszCoffPath,
} else {
/* hang onto the library for subsequent sym table usage */
hMgr->baseLib = lib;
- strncpy(hMgr->szZLFile, pszCoffPath, COD_MAXPATHLENGTH);
+ strncpy(hMgr->szZLFile, pszCoffPath, COD_MAXPATHLENGTH - 1);
+ hMgr->szZLFile[COD_MAXPATHLENGTH - 1] = '\0';
}
return status;
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index a1ba19e..66e4a4d 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1508,8 +1508,9 @@ DSP_STATUS DRV_RequestResources(u32 dwContext, u32
*pDevNodeString)
pszdevNode = MEM_Calloc(sizeof(struct DRV_EXT), MEM_NONPAGED);
if (pszdevNode) {
LST_InitElem(&pszdevNode->link);
- strncpy((char *) pszdevNode->szString,
-(char *)dwContext, MAXREGPATHLENGTH);
+ strncpy(pszdevNode->szString,
+(char *)dwContext, MAXREGPATHLENGTH - 1);
+ pszdevNode->szString[MAXREGPATHLENGTH - 1] = '\0';
/* Update the Driver Object List */
*pDevNodeString = (u32)pszdevNode->szString;
LST_PutTail(pDRVObject->devNodeString,
diff --git a/drivers/dsp/bridge/services/regsup.c
b/drivers/dsp/bridge/services/regsup.c
index 5251b68..bec8e92 100644
--- a/drivers/dsp/bridge/services/regsup.c
+++ b/drivers/dsp/bridge/services/regsup.c
@@ -238,8 +238,10 @@ DSP_STATUS regsupSetValue(char *valName, void *pBuf, u32
dataSize)
/* No match, need to make a new entry */
/* First check to see if we can make any more entries. */
if (pRegKey->numValueEntries < BRIDGE_MAX_NUM_REG_ENTRIES) {
- strncpy(pRegKey->values[pRegKey->numValueEntries].name,
- valName, BRIDGE_MAX_NAME_SIZE);
+ char *tmp_name =
+ pRegKey->values[pRegKey->numValueEntries].name;
+ strncpy(tmp_name, valName, BRIDGE_MAX_NAME_SIZE - 1);
+ tmp_name[BRIDGE_MAX_NAME_SIZE - 1] = '\0';
pRegKey->values[pRegKey->numValueEntries].pData =
MEM_Alloc(dataSize, MEM_NONPAGED);
if (pRegKey->values[pRegKey->numValueEntries].pData !=
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What does CONFIG_SYSFS_DEPRECATED do?
Hi, I get the following message during boot up using linux-omap3-2.6.29 recipe with android-2.6.29 patches, and all of kevin's latest linux- omap-pm patches. Starting udevudev: starting version 141 udev: deprecated sysfs layout; update the kernel or disable CONFIG_SYSFS_DEPRECATED; some udev features will not work correctly Should I disable CONFIG_SYSFS_DEPRECATED for this version? Best regards, Elvis On Jun 8, 2009, at 6:15 PM, Koen Kooi wrote: Op 8 jun 2009, om 16:06 heeft Elvis Dowson het volgende geschreven: Hi, What does CONFIG_SYSFS_DEPRECATED do? CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y if you have a recent userspace it will break udev. 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: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
On Mon, Jun 8, 2009 at 11:49 PM, Kanigeri, Hari wrote: > Hi Doyu-san, > > Regarding > >> http://marc.info/?l=linux-omap&m=124201773423892&w=2 >> I think that the first one should be merged into d.o-z.org now, but >> for the second one about 128 byte alignment. let me know your >> thought/plan on it. > > -- I think you sent this patch as a probable fix for the slab corruption that > was observed in Bridge driver, but then we found that slab corruption was due > to some other issue in Bridge driver and not due to the cache alignment. > > Irrespective of above point, I think it is good to enforce the cache > alignment check, but I think the check should be in Proc Map function and to > start with the check should be under a flag so as not to affect some MM > applications that use padding to get over the alignment issue. I agree, the check should be in proc map, and should be optional. However, I would prefer it to be an all-or-nothing option, how about in kconfig? -- 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 0/3] OMAP3:WDT:Enable IVA, SECURE and minor bugfixes
This patch series enables support for IVA and SECURE WDTs, available on omap34xx. For omap34xx devices the WDT will be accessible (when present) through: SECURE:/dev/watchdog1 MPU: /dev/watchdog2 IVA: /dev/watchdog3 For devices older than omap34xx only MPU WDT is present and will be accessible through /dev/watchdog The series also fixes two bugs: 1) Correct timeout value is not loaded upon opening the watchdog device. 2) clks are not enabled when accessing registers in probe b/arch/arm/mach-omap2/clock34xx.c | 12 ++--- b/arch/arm/plat-omap/devices.c| 79 ++ b/drivers/watchdog/omap_wdt.c | 42 ++ 3 files changed, 112 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP3:WDT:Enable support for IVA and SECURE
This patch enables the IVA and SECURE WDTs in the omap_wdt
driver for omap34xx family. SECURE will be available as /dev/watchdog1
HS/EMU devices and IVA will be available as /dev/watchdog3.
MPU will be available as /dev/watchdog2
For omap versions earlier than 34xx only MPU watchdog is present and
will be available as /dev/watchdog for backwards compatibility.
Signed-off-by: Ulrik Bech Hald
---
drivers/watchdog/omap_wdt.c | 42 +++---
1 files changed, 35 insertions(+), 7 deletions(-)
mode change 100644 => 100755 drivers/watchdog/omap_wdt.c
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
old mode 100644
new mode 100755
index f271385..26935c7
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -47,7 +47,9 @@
#include "omap_wdt.h"
-static struct platform_device *omap_wdt_dev;
+#define NUM_WDTS 3
+
+static struct platform_device *omap_wdt_dev[NUM_WDTS];
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
@@ -139,8 +141,26 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
*/
static int omap_wdt_open(struct inode *inode, struct file *file)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
- void __iomem *base = wdev->base;
+ struct omap_wdt_dev *wdev;
+ void __iomem *base;
+
+ /* by default MPU wdt is present across omap family */
+ wdev = platform_get_drvdata(omap_wdt_dev[1]);
+
+ /* if multiple wdts, find match between device node and wdt device */
+ if (cpu_is_omap34xx()) {
+ int i;
+ for (i = 0; i < NUM_WDTS; i++) {
+ if (omap_wdt_dev[i]) {
+ wdev = platform_get_drvdata(omap_wdt_dev[i]);
+ if (iminor(inode)
+ == wdev->omap_wdt_miscdev.minor)
+ break;
+ }
+ }
+ }
+
+ base = wdev->base;
if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
return -EBUSY;
@@ -263,6 +283,7 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
struct resource *res, *mem;
struct omap_wdt_dev *wdev;
int ret;
+ static char wdt_name[32];
/* reserve static register mappings */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -271,7 +292,7 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
goto err_get_resource;
}
- if (omap_wdt_dev) {
+ if (omap_wdt_dev[pdev->id-1]) {
ret = -EBUSY;
goto err_busy;
}
@@ -318,8 +339,14 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
wdev->omap_wdt_miscdev.parent = &pdev->dev;
wdev->omap_wdt_miscdev.minor = WATCHDOG_MINOR;
- wdev->omap_wdt_miscdev.name = "watchdog";
wdev->omap_wdt_miscdev.fops = &omap_wdt_fops;
+ wdev->omap_wdt_miscdev.name = "watchdog";
+ if (cpu_is_omap34xx()) {
+ snprintf(wdt_name, sizeof(wdt_name), "watchdog%d", pdev->id);
+ wdev->omap_wdt_miscdev.name = wdt_name;
+ if (pdev->id != 2)
+ wdev->omap_wdt_miscdev.minor = MISC_DYNAMIC_MINOR;
+ }
ret = misc_register(&(wdev->omap_wdt_miscdev));
if (ret)
@@ -332,7 +359,8 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
/* autogate OCP interface clock */
__raw_writel(0x01, wdev->base + OMAP_WATCHDOG_SYS_CONFIG);
- omap_wdt_dev = pdev;
+ /* keep track of the wdt platform devices in local device array */
+ omap_wdt_dev[pdev->id - 1] = pdev;
return 0;
@@ -384,7 +412,7 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
iounmap(wdev->base);
kfree(wdev);
- omap_wdt_dev = NULL;
+ omap_wdt_dev[pdev->id-1] = NULL;
return 0;
}
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP3:WDT:Enable clk in probe, trigger timer reload
This patch contains two bugfixes: 1)In omap_wdt_probe() the watchdog is reset and disabled. This requires register access and the clks needs to be enabled temporarily 2)In omap_wdt_open() the timer register needs to be reloaded to trigger a new timer value (the default of 60s) Signed-off-by: Ulrik Bech Hald --- drivers/watchdog/omap_wdt.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 26935c7..cb580a8 100755 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -179,6 +179,7 @@ static int omap_wdt_open(struct inode *inode, struct file *file) file->private_data = (void *) wdev; omap_wdt_set_timeout(wdev); + omap_wdt_ping(wdev); /* trigger loading of new timeout value */ omap_wdt_enable(wdev); return nonseekable_open(inode, file); @@ -334,6 +335,9 @@ static int __devinit omap_wdt_probe(struct platform_device *pdev) platform_set_drvdata(pdev, wdev); + clk_enable(wdev->ick); + clk_enable(wdev->fck); + omap_wdt_disable(wdev); omap_wdt_adjust_timeout(timer_margin); @@ -359,6 +363,9 @@ static int __devinit omap_wdt_probe(struct platform_device *pdev) /* autogate OCP interface clock */ __raw_writel(0x01, wdev->base + OMAP_WATCHDOG_SYS_CONFIG); + clk_disable(wdev->ick); + clk_disable(wdev->fck); + /* keep track of the wdt platform devices in local device array */ omap_wdt_dev[pdev->id - 1] = pdev; -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP3:WDT:Register IVA,SECURE, make clks accessible
Enabling registration of IVA and SECURE WDT devices. Making
ick and fck for IVA and SECURE WDTs accessible.
Signed-off-by: Ulrik Bech Hald
---
arch/arm/mach-omap2/clock34xx.c | 12 +++---
arch/arm/plat-omap/devices.c| 79 +++---
2 files changed, 70 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index ba05aa4..fe43d73 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -212,11 +212,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "gpt1_fck", &gpt1_fck, CK_343X),
CLK(NULL, "wkup_32k_fck", &wkup_32k_fck, CK_343X),
CLK(NULL, "gpio1_dbck", &gpio1_dbck,CK_343X),
- CLK("omap_wdt", "fck", &wdt2_fck, CK_343X),
+ CLK("omap_wdt.2", "fck",&wdt2_fck, CK_343X),
CLK(NULL, "wkup_l4_ick", &wkup_l4_ick, CK_343X),
CLK(NULL, "usim_ick", &usim_ick, CK_3430ES2),
- CLK("omap_wdt", "ick", &wdt2_ick, CK_343X),
- CLK(NULL, "wdt1_ick", &wdt1_ick, CK_343X),
+ CLK("omap_wdt.2", "ick",&wdt2_ick, CK_343X),
+ CLK("omap_wdt.1", "ick",&wdt1_ick, CK_343X),
CLK(NULL, "gpio1_ick",&gpio1_ick, CK_343X),
CLK(NULL, "omap_32ksync_ick", &omap_32ksync_ick, CK_343X),
CLK(NULL, "gpt12_ick",&gpt12_ick, CK_343X),
@@ -238,14 +238,14 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "gpio4_dbck", &gpio4_dbck,CK_343X),
CLK(NULL, "gpio3_dbck", &gpio3_dbck,CK_343X),
CLK(NULL, "gpio2_dbck", &gpio2_dbck,CK_343X),
- CLK(NULL, "wdt3_fck", &wdt3_fck, CK_343X),
+ CLK("omap_wdt.3", "fck",&wdt3_fck, CK_343X),
CLK(NULL, "per_l4_ick", &per_l4_ick,CK_343X),
CLK(NULL, "gpio6_ick",&gpio6_ick, CK_343X),
CLK(NULL, "gpio5_ick",&gpio5_ick, CK_343X),
CLK(NULL, "gpio4_ick",&gpio4_ick, CK_343X),
CLK(NULL, "gpio3_ick",&gpio3_ick, CK_343X),
CLK(NULL, "gpio2_ick",&gpio2_ick, CK_343X),
- CLK(NULL, "wdt3_ick", &wdt3_ick, CK_343X),
+ CLK("omap_wdt.3", "ick",&wdt3_ick, CK_343X),
CLK(NULL, "uart3_ick",&uart3_ick, CK_343X),
CLK(NULL, "gpt9_ick", &gpt9_ick, CK_343X),
CLK(NULL, "gpt8_ick", &gpt8_ick, CK_343X),
@@ -272,7 +272,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "sr_l4_ick",&sr_l4_ick, CK_343X),
CLK(NULL, "secure_32k_fck", &secure_32k_fck, CK_343X),
CLK(NULL, "gpt12_fck",&gpt12_fck, CK_343X),
- CLK(NULL, "wdt1_fck", &wdt1_fck, CK_343X),
+ CLK("omap_wdt.1", "fck",&wdt1_fck, CK_343X),
};
/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 87fb7ff..2a1b806 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -288,36 +288,85 @@ static inline void omap_init_uwire(void) {}
#ifdefined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-static struct resource wdt_resources[] = {
+#defineOMAP34XX_WDT1_BASE 0x4830c000
+#defineOMAP34XX_WDT2_BASE 0x48314000
+#defineOMAP34XX_WDT3_BASE 0x4903
+#defineOMAP2430_WDT_BASE 0x49016000
+#defineOMAP2420_WDT_BASE 0x48022000
+#defineOMAP16XX_WDT_BASE 0xfffeb000
+
+static struct resource wdt1_resources[] = {
{
- .flags = IORESOURCE_MEM,
+ .flags = IORESOURCE_MEM,
},
};
-static struct platform_device omap_wdt_device = {
- .name = "omap_wdt",
- .id = -1,
- .num_resources = ARRAY_SIZE(wdt_resources),
- .resource = wdt_resources,
+static struct resource wdt2_resources[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct resource wdt3_resources[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+/* SECURE WDT */
+static struct platform_device omap_wdt1_device = {
+ .name = "omap_wdt",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(wdt1_resources),
+ .resource = wdt1_resources,
+};
+
+/* MPU WDT */
+static struct platform_device omap_wdt2_device = {
+ .name = "omap_wdt",
+ .id = 2,
+ .num_resources = ARRAY_SIZE(wdt2_resources),
+ .resource = wdt2_resources,
+};
+
+/* IVA WDT */
+static struct platform_device omap_wdt3_device = {
+ .name = "omap_wdt",
+ .id = 3,
+ .num_resources = ARRAY_SIZE(wdt3_resources),
+ .resource = wdt3_resources,
};
static void omap_init_wdt(void)
{
RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
Hi Doyu-san,
Regarding
> http://marc.info/?l=linux-omap&m=124201773423892&w=2
> I think that the first one should be merged into d.o-z.org now, but
> for the second one about 128 byte alignment. let me know your
> thought/plan on it.
-- I think you sent this patch as a probable fix for the slab corruption that
was observed in Bridge driver, but then we found that slab corruption was due
to some other issue in Bridge driver and not due to the cache alignment.
Irrespective of above point, I think it is good to enforce the cache alignment
check, but I think the check should be in Proc Map function and to start with
the check should be under a flag so as not to affect some MM applications that
use padding to get over the alignment issue.
Thank you,
Best regards,
Hari
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU
> Sent: Monday, June 08, 2009 6:34 AM
> To: Ramirez Luna, Omar
> Cc: ameya.pala...@nokia.com; linux-omap@vger.kernel.org;
> felipe.contre...@gmail.com
> Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
>
> From: "ext Ramirez Luna, Omar"
> Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
> Date: Mon, 8 Jun 2009 08:49:03 +0200
>
> > >From: Ameya Palande [mailto:ameya.pala...@nokia.com]
> > >Subject: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
> > >
> > >From: Ameya Palande
> > >
> > >Signed-off-by: Ameya Palande
> > >---
> > > drivers/dsp/bridge/rmgr/drv_interface.c |2 +-
> > > drivers/dsp/bridge/rmgr/drv_interface.h |2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > >diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
> b/drivers/dsp/bridge/rmgr/drv_interface.c
> > >index c3d8a02..f41e153 100644
> > >--- a/drivers/dsp/bridge/rmgr/drv_interface.c
> > >+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
> > >@@ -665,7 +665,7 @@ static int bridge_release(struct inode *ip, struct
> file *filp)
> > > }
> > >
> > > /* This function provides IO interface to the bridge driver. */
> > >-static int bridge_ioctl(struct file *filp, unsigned int code,
> > >+static long bridge_ioctl(struct file *filp, unsigned int code,
> > > unsigned long args)
> > > {
> > > int status;
> > >diff --git a/drivers/dsp/bridge/rmgr/drv_interface.h
> b/drivers/dsp/bridge/rmgr/drv_interface.h
> > >index 3e77ed0..dc49210 100644
> > >--- a/drivers/dsp/bridge/rmgr/drv_interface.h
> > >+++ b/drivers/dsp/bridge/rmgr/drv_interface.h
> > >@@ -34,7 +34,7 @@ static int __init bridge_init(void); /* Initialize
> bridge */
> > > static void __exit bridge_exit(void); /* Opposite of initialize */
> > > static int bridge_open(struct inode *, struct file *);/* Open */
> > > static int bridge_release(struct inode *, struct file *); /*
> Release */
> > >-static int bridge_ioctl(struct file *, unsigned int,
> > >+static long bridge_ioctl(struct file *, unsigned int,
> > > unsigned long);
> > > static int bridge_mmap(struct file *filp, struct vm_area_struct *vma);
> > > #endif/* ifndef _DRV_INTERFACE_H_ */
> > >--
> > >1.6.2.4
> > >
> >
> > Pushed to bridge tree on dev.omapzoom.org
>
> Thanks. Also there still seems to remain 2 patches:
>
> http://marc.info/?l=linux-omap&m=124201773423895&w=2
> http://marc.info/?l=linux-omap&m=124201773423892&w=2
>
> I think that the first one should be merged into d.o-z.org now, but
> for the second one about 128 byte alignment. let me know your
> thought/plan on it.
>
> >
> > - omar
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> 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: Require long touchscreen press to get system to resume
Hi Kevin, This time around, I get a new info in the console window: domain: automatic idle transitions cannot be disabled on cm_clkdm What could the reason be for this message & why does the touchscreen become unresponsive ? Best regards, Elvis Suspending console(s) (use no_console_suspend to debug) domain: automatic idle transitions cannot be disabled on cm_clkdm mmc1: mmc_rescan - card ocr from io_op=0x, err = -110 PM: resume devices took 0.554 seconds Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 1 chg evt request_suspend_state: wakeup (3->0) at 85620483447 (2000-01-01 00:10:05.532745363 UTC) done. suspend: exit suspend, ret = 0 (2000-01-01 00:10:05.558013920 UTC) D/SurfaceFlinger( 919): Screen about to return, flinger = 0x16f308 Spurious irq 95: 0xffdf, please flush posted write for irq 29 Spurious irq 95: 0xffdf, please flush posted write for irq 29 -- 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] Fix brf6510 cleanup code
The brf6150 driver is missing several necessary cleanup steps to allow
module unloading. Add them.
Signed-off-by: Andrew de Quincey
commit bf0e4cba53819df5590a88d551b35a2e79f4de75
Author: Andrew de Quincey
Date: Sat May 30 18:01:58 2009 +0100
Fix brf6150 init/shutdown cleanup
diff --git a/drivers/bluetooth/brf6150.c b/drivers/bluetooth/brf6150.c
index f29caf5..4f0112a 100644
--- a/drivers/bluetooth/brf6150.c
+++ b/drivers/bluetooth/brf6150.c
@@ -312,7 +312,7 @@ static int brf6150_send_negotiation(struct brf6150_info *info)
skb = brf6150_read_fw_cmd(info, GFP_KERNEL);
if (!skb) {
- printk(KERN_WARNING "Cannot read negoatiation message");
+ printk(KERN_WARNING "Cannot read negotiation message");
return -1;
}
@@ -873,6 +873,7 @@ static int brf6150_register_hdev(struct brf6150_info *info)
hdev->owner = THIS_MODULE;
if (hci_register_dev(hdev) < 0) {
+ hci_free_dev(hdev);
printk(KERN_WARNING "brf6150: Can't register HCI device %s.\n", hdev->name);
return -ENODEV;
}
@@ -885,10 +886,9 @@ static int __init brf6150_init(void)
struct brf6150_info *info;
int irq, err;
- info = kmalloc(sizeof(struct brf6150_info), GFP_KERNEL);
+ info = kzalloc(sizeof(struct brf6150_info), GFP_KERNEL);
if (!info)
return -ENOMEM;
- memset(info, 0, sizeof(struct brf6150_info));
brf6150_device.dev.driver_data = info;
init_completion(&info->init_completion);
@@ -906,8 +906,11 @@ static int __init brf6150_init(void)
exit_info = NULL;
info->btinfo = omap_get_config(OMAP_TAG_NOKIA_BT, struct omap_bluetooth_config);
- if (info->btinfo == NULL)
+ if (info->btinfo == NULL) {
+ tasklet_kill(&info->tx_task);
+ kfree(info);
return -1;
+ }
NBT_DBG("RESET gpio: %d\n", info->btinfo->reset_gpio);
NBT_DBG("BTWU gpio: %d\n", info->btinfo->bt_wakeup_gpio);
@@ -920,6 +923,7 @@ static int __init brf6150_init(void)
{
printk(KERN_WARNING "Cannot get GPIO line %d",
info->btinfo->reset_gpio);
+ tasklet_kill(&info->tx_task);
kfree(info);
return err;
}
@@ -930,6 +934,7 @@ static int __init brf6150_init(void)
printk(KERN_WARNING "Cannot get GPIO line 0x%d",
info->btinfo->bt_wakeup_gpio);
gpio_free(info->btinfo->reset_gpio);
+ tasklet_kill(&info->tx_task);
kfree(info);
return err;
}
@@ -941,6 +946,7 @@ static int __init brf6150_init(void)
info->btinfo->host_wakeup_gpio);
gpio_free(info->btinfo->reset_gpio);
gpio_free(info->btinfo->bt_wakeup_gpio);
+ tasklet_kill(&info->tx_task);
kfree(info);
return err;
}
@@ -1027,6 +1033,7 @@ cleanup:
gpio_free(info->btinfo->reset_gpio);
gpio_free(info->btinfo->bt_wakeup_gpio);
gpio_free(info->btinfo->host_wakeup_gpio);
+ tasklet_kill(&info->tx_task);
kfree(info);
return err;
@@ -1035,12 +1042,16 @@ cleanup:
static void __exit brf6150_exit(void)
{
brf6150_hci_close(exit_info->hdev);
+ hci_unregister_dev(exit_info->hdev);
hci_free_dev(exit_info->hdev);
gpio_free(exit_info->btinfo->reset_gpio);
gpio_free(exit_info->btinfo->bt_wakeup_gpio);
gpio_free(exit_info->btinfo->host_wakeup_gpio);
free_irq(exit_info->irq, (void *)exit_info);
free_irq(gpio_to_irq(exit_info->btinfo->host_wakeup_gpio), (void *)exit_info);
+ tasklet_kill(&exit_info->tx_task);
+ platform_device_unregister(&brf6150_device);
+ platform_driver_unregister(&brf6150_driver);
kfree(exit_info);
}
Require long touchscreen press to get system to resume
Hi Kevin, After following your instructions, setting CONFIG_OMAP_RESET_CLOCKS, and applying all the 204 omap-pm patches, I don't get any more error messages on the console. So this is a very big improvement since I started incorporating the omap-pm patches for my android-2.6.29 port to the overo platform. Now there is only one issue left, which is you need to press the touchscreen for a long time (around 3 secs) for it to get the system to resume. There are no error messages now, but because it take a long time to wake up from suspend mode, it gives the impression that the system is un-responsive or stuck in suspend mode. Sometimes it doesnt come out of suspend mode at all. Here is the output from the console window: request_suspend_state: wakeup (3->0) at 15586914111 (2000-01-01 00:00:14.131500245 UTC) request_suspend_state: sleep (0->3) at 90151855487 (2000-01-01 00:01:28.696441621 UTC) PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) n 0 loops wakeup wake lock: mmc_delayed_work mmc1: mmc_rescan - card ocr from io_op=0x, err = -110 PM: resume devices took 0.554 seconds Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 1 chg evt # done. suspend: exit suspend, ret = 0 (2000-01-01 00:01:34.529602052 UTC) PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) mmc1: mmc_rescan - card ocr from io_op=0x, err = -110 PM: resume devices took 0.820 seconds Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 1 chg evt request_suspend_state: wakeup (3->0) at 92972961452 (2000-01-01 00:01:51.524871827 UTC) done. suspend: exit suspend, ret = 0 (2000-01-01 00:01:51.550201418 UTC) Best regards, Elvis -- 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] Convert cbus driver code to use platform APIs consistently
Recent changes in the drivers/base/platform.c exposed an inconsistency in the cbus drivers; they weren't matching platform_divers with platform_devices, which causes all sorts of structure casting issues within the base platform code since it assumes this. Signed-off-by: Andrew de Quincey -- 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: Init/shutdown correctness fixes for drivers/cbus/tahvo*
Quoting Tony Lindgren : * Andrew de Quincey [090525 16:22]: This is a companion review patch to the cbus one that fixes init/shutdown correctness in drivers/cbus/tahvo* This one is missing Signed-off-by also. Hi, just catching up: Signed-off-by: Andrew de Quincey -- 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: What does CONFIG_SYSFS_DEPRECATED do?
Op 8 jun 2009, om 16:06 heeft Elvis Dowson het volgende geschreven: Hi, What does CONFIG_SYSFS_DEPRECATED do? CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y if you have a recent userspace it will break udev. regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
Jean Pihet writes:
> Hi Kevin,
>
> On Monday 08 June 2009 13:01:18 Grazvydas Ignotas wrote:
>> > static void __init omap3pandora_init_irq(void)
>> > {
>> > - omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
>> > + omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
>> > + mt46h32m32lf6_sdrc_params,
>> > NULL, NULL, NULL);
>>
>> Hm, since pandora uses OMAP3530, maybe it should also have
>> omap3_*_rate_table args passed? Could also be true for Overo, at least
>> for omap3_mpu_rate_table and omap3_l3_rate_table, as some models use
>> OMAP3503 without the DSP.
>
> Which table rates shall we pass for Overo and Pandora?
> I will update the patch set with the needed ones.
>
Let's leave any rate table changes out of this series. That is an
unrelated change.
The Pandora/Overo folks should do some testing with the current rate
tables and DVFS/CPUfreq to see if they work for them.
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: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
Jean Pihet writes:
> On Monday 08 June 2009 16:59:36 Kevin Hilman wrote:
>> Jean Pihet writes:
>> > Paul,
>> >
>> > Here is the updated patch that fixes the Overo build as well.
>> > Can you check it?
>> >
>> > Kevin, can you push it if it is correct?
>>
>> Can you run it through checkpatch, fix the errors and also merge Tero's
>> RX51 patch if it looks good to you.
> Ok. I will check. The cause might be the mailer.
>
> I think we need the omap_cfg_reg calls in the RX51 board file as
> well, even if the bootloader has the mux setting already right. That
> way a warning will be issued in case of a faulty bootloader. Do you
> agree?
I agree.
Kevin
>>
>> Below are the checkpatch errors I get: looks lik your mailer is
>> probably wrapping the patch and there is also one error to fix.
>>
>> Kevin
>
> Regards,
> Jean
>>
>> ERROR: patch seems to be corrupt (line wrapped?)
>> #306: FILE: arch/arm/mach-omap2/clock34xx.c:477:
>> unsigned long rate)
>>
>> ERROR: trailing whitespace
>> #494: FILE: arch/arm/mach-omap2/sdrc.c:128:
>> + * @sdrc_cs[01]: pointers to a null-terminated list of struct $
>>
>> total: 2 errors, 0 warnings, 648 lines checked
>>
>> Your patch has style problems, please review. If any of these errors
>> are false positives report them to the maintainer, see
>> CHECKPATCH in MAINTAINERS.
>>
>> > Regards,
>> > Jean
>> >
>> > From ebe57354b0de059e1f042e0c488f761853f0 Mon Sep 17 00:00:00 2001
>> > From: Jean Pihet
>> > Date: Fri, 5 Jun 2009 17:19:00 +0200
>> > Subject: OMAP3: add support for 2 SDRAM chip selects
>> >
>> > Some boards (Beagle Cx, Overo) have 2 SDRAM parts
>> > connected to the SDRC.
>> >
>> > This patch adds the following:
>> > - ensure that the CKE signals mux settings are correct
>> > - add a new argument of type omap_sdrc_params struct*
>> > to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
>> > - adapted the OMAP boards files to the new prototype of
>> > omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
>> > - adapt the sram sleep code to configure the SDRC for the 2nd CS
>> >
>> > Note: If the 2nd param to omap2_init_common_hw is NULL, then the
>> > parameters are not programmed into the SDRC CS1 registers
>> >
>> > Tested on 3430 SDP and Beagleboard rev C2 and B5, with
>> > suspend/resume and frequency changes (cpufreq).
>> >
>> > Thanks to Paul Walmsley and Kevin Hilman for the suggestions
>> > and code reviews.
>> >
>> > Signed-off-by: Jean Pihet
>> > ---
>> > arch/arm/mach-omap2/board-2430sdp.c |2 +-
>> > arch/arm/mach-omap2/board-3430sdp.c |6 +-
>> > arch/arm/mach-omap2/board-apollon.c |2 +-
>> > arch/arm/mach-omap2/board-generic.c |2 +-
>> > arch/arm/mach-omap2/board-h4.c |2 +-
>> > arch/arm/mach-omap2/board-ldp.c |2 +-
>> > arch/arm/mach-omap2/board-n800.c |2 +-
>> > arch/arm/mach-omap2/board-omap2evm.c |2 +-
>> > arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
>> > arch/arm/mach-omap2/board-omap3evm.c |6 +-
>> > arch/arm/mach-omap2/board-omap3pandora.c |3 +-
>> > arch/arm/mach-omap2/board-overo.c|9 ++-
>> > arch/arm/mach-omap2/board-rx51.c |6 +-
>> > arch/arm/mach-omap2/clock34xx.c | 37 ++--
>> > arch/arm/mach-omap2/io.c |5 +-
>> > arch/arm/mach-omap2/mux.c|6 ++
>> > arch/arm/mach-omap2/sdrc.c | 63 +-
>> > arch/arm/mach-omap2/sram34xx.S | 137
>> > +++---
>> > arch/arm/plat-omap/include/mach/io.h |3 +-
>> > arch/arm/plat-omap/include/mach/mux.h|4 +
>> > arch/arm/plat-omap/include/mach/sdrc.h |8 +-
>> > arch/arm/plat-omap/include/mach/sram.h | 23 +++--
>> > arch/arm/plat-omap/sram.c| 34 +---
>> > 23 files changed, 267 insertions(+), 108 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/board-2430sdp.c
>> > b/arch/arm/mach-omap2/board-2430sdp.c
>> > index aa5df72..4cb7bc5 100644
>> > --- a/arch/arm/mach-omap2/board-2430sdp.c
>> > +++ b/arch/arm/mach-omap2/board-2430sdp.c
>> > @@ -322,7 +322,7 @@ out:
>> >
>> > static void __init omap_2430sdp_init_irq(void)
>> > {
>> > - omap2_init_common_hw(NULL);
>> > + omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
>> >omap_init_irq();
>> >omap_gpio_init();
>> >sdp2430_init_smc91x();
>> > diff --git a/arch/arm/mach-omap2/board-3430sdp.c
>> > b/arch/arm/mach-omap2/board-3430sdp.c
>> > index 195b749..24e2728 100644
>> > --- a/arch/arm/mach-omap2/board-3430sdp.c
>> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
>> > @@ -302,8 +302,10 @@ static inline void __init sdp3430_init_smc91x(void)
>> >
>> > static void __init omap_3430sdp_init_irq(void)
>> > {
>> > - omap2_init_common_hw(hyb18m512160af6_sdrc_params, omap3_mpu_rate_table,
>> > - omap3_dsp_rate_table, omap3_l3_rate_table);
>> > + omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
>>
Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
Hi Kevin,
On Monday 08 June 2009 13:01:18 Grazvydas Ignotas wrote:
> > static void __init omap3pandora_init_irq(void)
> > {
> > - omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
> > + omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
> > + mt46h32m32lf6_sdrc_params,
> > NULL, NULL, NULL);
>
> Hm, since pandora uses OMAP3530, maybe it should also have
> omap3_*_rate_table args passed? Could also be true for Overo, at least
> for omap3_mpu_rate_table and omap3_l3_rate_table, as some models use
> OMAP3503 without the DSP.
Which table rates shall we pass for Overo and Pandora?
I will update the patch set with the needed ones.
Regards,
Jean
--
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] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
On Monday 08 June 2009 16:59:36 Kevin Hilman wrote:
> Jean Pihet writes:
> > Paul,
> >
> > Here is the updated patch that fixes the Overo build as well.
> > Can you check it?
> >
> > Kevin, can you push it if it is correct?
>
> Can you run it through checkpatch, fix the errors and also merge Tero's
> RX51 patch if it looks good to you.
Ok. I will check. The cause might be the mailer.
I think we need the omap_cfg_reg calls in the RX51 board file as well, even if
the bootloader has the mux setting already right. That way a warning will be
issued in case of a faulty bootloader. Do you agree?
>
> Below are the checkpatch errors I get: looks lik your mailer is
> probably wrapping the patch and there is also one error to fix.
>
> Kevin
Regards,
Jean
>
> ERROR: patch seems to be corrupt (line wrapped?)
> #306: FILE: arch/arm/mach-omap2/clock34xx.c:477:
> unsigned long rate)
>
> ERROR: trailing whitespace
> #494: FILE: arch/arm/mach-omap2/sdrc.c:128:
> + * @sdrc_cs[01]: pointers to a null-terminated list of struct $
>
> total: 2 errors, 0 warnings, 648 lines checked
>
> Your patch has style problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>
> > Regards,
> > Jean
> >
> > From ebe57354b0de059e1f042e0c488f761853f0 Mon Sep 17 00:00:00 2001
> > From: Jean Pihet
> > Date: Fri, 5 Jun 2009 17:19:00 +0200
> > Subject: OMAP3: add support for 2 SDRAM chip selects
> >
> > Some boards (Beagle Cx, Overo) have 2 SDRAM parts
> > connected to the SDRC.
> >
> > This patch adds the following:
> > - ensure that the CKE signals mux settings are correct
> > - add a new argument of type omap_sdrc_params struct*
> > to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
> > - adapted the OMAP boards files to the new prototype of
> > omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
> > - adapt the sram sleep code to configure the SDRC for the 2nd CS
> >
> > Note: If the 2nd param to omap2_init_common_hw is NULL, then the
> > parameters are not programmed into the SDRC CS1 registers
> >
> > Tested on 3430 SDP and Beagleboard rev C2 and B5, with
> > suspend/resume and frequency changes (cpufreq).
> >
> > Thanks to Paul Walmsley and Kevin Hilman for the suggestions
> > and code reviews.
> >
> > Signed-off-by: Jean Pihet
> > ---
> > arch/arm/mach-omap2/board-2430sdp.c |2 +-
> > arch/arm/mach-omap2/board-3430sdp.c |6 +-
> > arch/arm/mach-omap2/board-apollon.c |2 +-
> > arch/arm/mach-omap2/board-generic.c |2 +-
> > arch/arm/mach-omap2/board-h4.c |2 +-
> > arch/arm/mach-omap2/board-ldp.c |2 +-
> > arch/arm/mach-omap2/board-n800.c |2 +-
> > arch/arm/mach-omap2/board-omap2evm.c |2 +-
> > arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
> > arch/arm/mach-omap2/board-omap3evm.c |6 +-
> > arch/arm/mach-omap2/board-omap3pandora.c |3 +-
> > arch/arm/mach-omap2/board-overo.c|9 ++-
> > arch/arm/mach-omap2/board-rx51.c |6 +-
> > arch/arm/mach-omap2/clock34xx.c | 37 ++--
> > arch/arm/mach-omap2/io.c |5 +-
> > arch/arm/mach-omap2/mux.c|6 ++
> > arch/arm/mach-omap2/sdrc.c | 63 +-
> > arch/arm/mach-omap2/sram34xx.S | 137
> > +++---
> > arch/arm/plat-omap/include/mach/io.h |3 +-
> > arch/arm/plat-omap/include/mach/mux.h|4 +
> > arch/arm/plat-omap/include/mach/sdrc.h |8 +-
> > arch/arm/plat-omap/include/mach/sram.h | 23 +++--
> > arch/arm/plat-omap/sram.c| 34 +---
> > 23 files changed, 267 insertions(+), 108 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-2430sdp.c
> > b/arch/arm/mach-omap2/board-2430sdp.c
> > index aa5df72..4cb7bc5 100644
> > --- a/arch/arm/mach-omap2/board-2430sdp.c
> > +++ b/arch/arm/mach-omap2/board-2430sdp.c
> > @@ -322,7 +322,7 @@ out:
> >
> > static void __init omap_2430sdp_init_irq(void)
> > {
> > - omap2_init_common_hw(NULL);
> > + omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
> > omap_init_irq();
> > omap_gpio_init();
> > sdp2430_init_smc91x();
> > diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> > b/arch/arm/mach-omap2/board-3430sdp.c
> > index 195b749..24e2728 100644
> > --- a/arch/arm/mach-omap2/board-3430sdp.c
> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
> > @@ -302,8 +302,10 @@ static inline void __init sdp3430_init_smc91x(void)
> >
> > static void __init omap_3430sdp_init_irq(void)
> > {
> > - omap2_init_common_hw(hyb18m512160af6_sdrc_params, omap3_mpu_rate_table,
> > -omap3_dsp_rate_table, omap3_l3_rate_table);
> > + omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
> > +omap3_mpu_rate_table,
> > +omap3_dsp_rate_table,
> > +omap3_l3_rate_table);
> >
RE: [PATCH] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
On Mon, Jun 8, 2009 at 5:08 PM, Tony Lindgren wrote:
> * Singh, Vimal
> [090605
> 05:00]:
>>
>>
>> On Thu, Jun 4, 2009 at 8:58 PM, Tony Lindgren wrote:
>> > * vimal singh [090604 02:34]:
>> >> On Wed, Jun 3, 2009 at 10:03 PM, Tony Lindgren wrote:
>> >> > * Singh, Vimal
>> >> [090602
>> >> 23:46]:
>> >> >>
>> >> >> On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren wrote:
>> >> >> > * vimal singh [090602 05:40]:
>> >> >> >> This patch adds prefetch support to access nand flash in both mpu
>> >> >> >> and dma
>> >> mode.
>> >> >> >> This patch also adds 8-bit nand support (omap_read/write_buf8).
>> >> >> >> Prefetch can be used for both 8- and 16-bit devices.
>> >> >> >
>> >> >> > This should be reviewed on the linux-omap@vger.kernel.org list for
>> >> >> > sure.
>> >> >> > One other comment below.
>> >> >> >
>> >> >> >> Signed-off-by: Vimal Singh
>> >> >> >> ---
>> >> >> >> I prepared this patch on top of "OMAP2 / OMAP3 NAND driver" patch:
>> >> >> >> http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
>> >> >> >>
>> >> >> >> ---
>> >> >> >> arch/arm/mach-omap2/gpmc.c | 102 ++
>> >> >> >> arch/arm/plat-omap/include/mach/gpmc.h |4
>> >> >> >> drivers/mtd/nand/Kconfig | 17 +
>> >> >> >> drivers/mtd/nand/omap2.c | 308
>> >> -
>> >> >> >> 4 files changed, 422 insertions(+), 9 deletions(-)
>> >> >> >>
>> >> >> >> Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
>> >> >> >> ===
>> >> >> >> --- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
>> >> >> >> +++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
>> >> >> >> @@ -54,6 +54,12 @@
>> >> >> >> #define GPMC_CHUNK_SHIFT 24 /* 16 MB */
>> >> >> >> #define GPMC_SECTION_SHIFT 28 /* 128 MB */
>> >> >> >>
>> >> >> >> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
>> >> >> >> +#define CS_NUM_SHIFT 24
>> >> >> >> +#define ENABLE_PREFETCH 7
>> >> >> >> +#define DMA_MPU_MODE 2
>> >> >> >> +#endif
>> >> >> >> +
>> >> >> >> static struct resource gpmc_mem_root;
>> >> >> >> static struct resource gpmc_cs_mem[GPMC_CS_NUM];
>> >> >> >> static DEFINE_SPINLOCK(gpmc_mem_lock);
>> >> >> >> @@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
>> >> >> >> }
>> >> >> >> EXPORT_SYMBOL(gpmc_cs_free);
>> >> >> >>
>> >> >> >> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
>> >> >> >> +/**
>> >> >> >> + * gpmc_prefetch_init - configures default configuration for
>> >> >> >> prefetch
>> >> engine
>> >> >> >> + */
>> >> >> >> +static void gpmc_prefetch_init(void)
>> >> >> >> +{
>> >> >> >> + /* Setting the default threshold to 64 */
>> >> >> >> + gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
>> >> >> >> + gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 << 8);
>> >> >> >> + gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
>> >> >> >> +}
>> >> >> >
>> >> >> > Why would you want to have NAND specific init code int gpmc.c?
>> >> >> >
>> >> >> > The purpose if gpmc.c is to provide access to configuring the
>> >> >> > General Purpose Memory Controller (GPMC). You should just provide
>> >> >> > functions in gpmc.c for the platform init code to use, and then
>> >> >> > the drivers can stay platform independent.
>> >> >>
>> >> >> In my understanding, this 'prefetch' engine is part of GPMC itself, it
>> >> >> is a
>> >> >> kind of feature provided by GPMC which can be utilized by NAND driver.
>> >> >> So, to me, it makes sens to get initialized prefetch by GPMC itself so
>> >> >> that
>> >> >> NAND driver can use it.
>> >> >
>> >> > But it should not have a dependency to NAND.
>> >>
>> >> This engine, in GPMC, is dedicated for NAND devices only.
>> >>
>> >> >
>> >> >> Another reason was that all read / write to GPMC register are done by
>> >> >> functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
>> >> >> 'static' in nature.
>> >> >
>> >> > That's why you need to provide a generic function in gpmc.c to enable
>> >> > prefetch that the platform code for any driver can use.
>> >>
>> >> Exactly, and whenever a platform code uses gpmc init call, gpmc
>> >> initializes
>> >> this engine too. Since prefetch engine is the part of GPMC, IMHOP, it
>> >> should
>> >> get initialized as part of GPMC initialization.
>> >
>> > No, the driver needing it should initialize it. There should not be any
>> > ifdefs needed in the gpmc.c for that.
>>
>> Are you suggesting to move gpmc prefetch specific code to
>> 'drivers/mtd/nand/omap2.c'?
>> This can be done but then, we will be accessing gpmc registers outside
>> gpmc.c. Is that ok?
>
> Well I'm thinking that you just basically need something like this in
> gpmc.c:
>
> int gpmc_prefetch_request(int cs);
> int gpmc_prefetch_enable(int cs);
> int gpmc_prefetch_reset(int cs);
> ...
>
> And gpmc_prefetch_request would then return an error if already taken.
> No need then to tinker with the GPMC prefetch registers in the NAND
> driver.
This
[PATCH] DSPBRIDGE: Various compile warning fixes
From: Mika Kukkonen
This patch cleans up various warnings uncovered with extra warning flags:
- empty if() bodies
- bad comparison of pointer value
- pointless check of unsigned value being smaller than zero
- keyword 'extern' has to be first one in variable declaration
- indentation fixes
Signed-off-by: Mika Kukkonen
Signed-off-by: Ameya Palande
---
arch/arm/plat-omap/include/dspbridge/dbc.h |6 +-
arch/arm/plat-omap/include/dspbridge/dbg.h |4 +-
arch/arm/plat-omap/include/dspbridge/gt.h | 16 ---
arch/arm/plat-omap/include/dspbridge/mem.h |2 +-
drivers/dsp/bridge/wmd/io_sm.c | 72 ++--
drivers/dsp/bridge/wmd/ue_deh.c|2 +-
6 files changed, 52 insertions(+), 50 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dbc.h
b/arch/arm/plat-omap/include/dspbridge/dbc.h
index 0e6a67d..ec55c1d 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbc.h
@@ -57,9 +57,9 @@
#else
-#define DBC_Assert(exp)
-#define DBC_Require(exp)
-#define DBC_Ensure(exp)
+#define DBC_Assert(exp) {}
+#define DBC_Require(exp) {}
+#define DBC_Ensure(exp) {}
#endif /* DEBUG */
diff --git a/arch/arm/plat-omap/include/dspbridge/dbg.h
b/arch/arm/plat-omap/include/dspbridge/dbg.h
index 7f44ff9..442955c 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbg.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbg.h
@@ -101,9 +101,9 @@
extern DSP_STATUS DBG_Trace(IN u8 bLevel, IN char *pstrFormat, ...);
#else
-#define DBG_Exit(void)
+#define DBG_Exit(void) do {} while (0)
#define DBG_Init(void) true
-#define DBG_Trace(bLevel, pstrFormat, args...)
+#define DBG_Trace(bLevel, pstrFormat, args...) do {} while (0)
#endif /* (defined(DEBUG) || defined(DDSP_DEBUG_PRODUCT)) && GT_TRACE */
diff --git a/arch/arm/plat-omap/include/dspbridge/gt.h
b/arch/arm/plat-omap/include/dspbridge/gt.h
index 456c866..72ef42d 100644
--- a/arch/arm/plat-omap/include/dspbridge/gt.h
+++ b/arch/arm/plat-omap/include/dspbridge/gt.h
@@ -261,13 +261,15 @@ extern struct GT_Config _GT_params;
#define GT_query(mask, class) false
-#define GT_0trace(mask, class, format)
-#define GT_1trace(mask, class, format, arg1)
-#define GT_2trace(mask, class, format, arg1, arg2)
-#define GT_3trace(mask, class, format, arg1, arg2, arg3)
-#define GT_4trace(mask, class, format, arg1, arg2, arg3, arg4)
-#define GT_5trace(mask, class, format, arg1, arg2, arg3, arg4, arg5)
-#define GT_6trace(mask, class, format, arg1, arg2, arg3, arg4, arg5, arg6)
+#define GT_0trace(mask, class, format) do {} while (0)
+#define GT_1trace(mask, class, format, arg1) do {} while (0)
+#define GT_2trace(mask, class, format, arg1, arg2) do {} while (0)
+#define GT_3trace(mask, class, format, arg1, arg2, arg3) do {} while (0)
+#define GT_4trace(mask, class, format, arg1, arg2, arg3, arg4) do {} while (0)
+#define GT_5trace(mask, class, format, arg1, arg2, arg3, arg4, arg5) \
+ do {} while (0)
+#define GT_6trace(mask, class, format, arg1, arg2, arg3, arg4, arg5, arg6) \
+ do {} while (0)
#else /* GT_TRACE == 1 */
diff --git a/arch/arm/plat-omap/include/dspbridge/mem.h
b/arch/arm/plat-omap/include/dspbridge/mem.h
index 535ac3a..cc79047 100644
--- a/arch/arm/plat-omap/include/dspbridge/mem.h
+++ b/arch/arm/plat-omap/include/dspbridge/mem.h
@@ -317,7 +317,7 @@
* Ensures:
* - pBaseAddr no longer points to a valid linear address.
*/
-#define MEM_UnmapLinearAddress(pBaseAddr)
+#define MEM_UnmapLinearAddress(pBaseAddr) {}
/*
* MEM_ExtPhysPoolInit
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 6f7e338..39c34f7 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -204,7 +204,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
struct CFG_HOSTRES hostRes;
struct CFG_DEVNODE *hDevNode;
struct CHNL_MGR *hChnlMgr;
- static int ref_count;
+ static int ref_count;
u32 devType;
/* Check DBC requirements: */
DBC_Require(phIOMgr != NULL);
@@ -215,31 +215,30 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
DBC_Require(status != DSP_EHANDLE);
DBC_Require(hChnlMgr != NULL);
DBC_Require(hChnlMgr->hIOMgr == NULL);
-/* Message manager will be created when a file is loaded, since
-* size of message buffer in shared memory is configurable in
-* the base image. */
+ /*
+* Message manager will be created when a file is loaded, since
+* size of message buffer in shared memory is configurable in
+* the base image.
+*/
DEV_GetWMDContext(hDevObject, &hWmdContext);
DBC_Assert(hWmdContext);
DEV_GetDevType(hDevObject, &devType);
- /* DSP shared memory area will get set properly when
-* a program is loaded. They a
Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
Jean Pihet writes:
> Paul,
>
> Here is the updated patch that fixes the Overo build as well.
> Can you check it?
>
> Kevin, can you push it if it is correct?
Can you run it through checkpatch, fix the errors and also merge Tero's
RX51 patch if it looks good to you.
Below are the checkpatch errors I get: looks lik your mailer is
probably wrapping the patch and there is also one error to fix.
Kevin
ERROR: patch seems to be corrupt (line wrapped?)
#306: FILE: arch/arm/mach-omap2/clock34xx.c:477:
unsigned long rate)
ERROR: trailing whitespace
#494: FILE: arch/arm/mach-omap2/sdrc.c:128:
+ * @sdrc_cs[01]: pointers to a null-terminated list of struct $
total: 2 errors, 0 warnings, 648 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
>
> Regards,
> Jean
>
> From ebe57354b0de059e1f042e0c488f761853f0 Mon Sep 17 00:00:00 2001
> From: Jean Pihet
> Date: Fri, 5 Jun 2009 17:19:00 +0200
> Subject: OMAP3: add support for 2 SDRAM chip selects
>
> Some boards (Beagle Cx, Overo) have 2 SDRAM parts
> connected to the SDRC.
>
> This patch adds the following:
> - ensure that the CKE signals mux settings are correct
> - add a new argument of type omap_sdrc_params struct*
> to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
> - adapted the OMAP boards files to the new prototype of
> omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
> - adapt the sram sleep code to configure the SDRC for the 2nd CS
>
> Note: If the 2nd param to omap2_init_common_hw is NULL, then the
> parameters are not programmed into the SDRC CS1 registers
>
> Tested on 3430 SDP and Beagleboard rev C2 and B5, with
> suspend/resume and frequency changes (cpufreq).
>
> Thanks to Paul Walmsley and Kevin Hilman for the suggestions
> and code reviews.
>
> Signed-off-by: Jean Pihet
> ---
> arch/arm/mach-omap2/board-2430sdp.c |2 +-
> arch/arm/mach-omap2/board-3430sdp.c |6 +-
> arch/arm/mach-omap2/board-apollon.c |2 +-
> arch/arm/mach-omap2/board-generic.c |2 +-
> arch/arm/mach-omap2/board-h4.c |2 +-
> arch/arm/mach-omap2/board-ldp.c |2 +-
> arch/arm/mach-omap2/board-n800.c |2 +-
> arch/arm/mach-omap2/board-omap2evm.c |2 +-
> arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
> arch/arm/mach-omap2/board-omap3evm.c |6 +-
> arch/arm/mach-omap2/board-omap3pandora.c |3 +-
> arch/arm/mach-omap2/board-overo.c|9 ++-
> arch/arm/mach-omap2/board-rx51.c |6 +-
> arch/arm/mach-omap2/clock34xx.c | 37 ++--
> arch/arm/mach-omap2/io.c |5 +-
> arch/arm/mach-omap2/mux.c|6 ++
> arch/arm/mach-omap2/sdrc.c | 63 +-
> arch/arm/mach-omap2/sram34xx.S | 137
> +++---
> arch/arm/plat-omap/include/mach/io.h |3 +-
> arch/arm/plat-omap/include/mach/mux.h|4 +
> arch/arm/plat-omap/include/mach/sdrc.h |8 +-
> arch/arm/plat-omap/include/mach/sram.h | 23 +++--
> arch/arm/plat-omap/sram.c| 34 +---
> 23 files changed, 267 insertions(+), 108 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c
> b/arch/arm/mach-omap2/board-2430sdp.c
> index aa5df72..4cb7bc5 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -322,7 +322,7 @@ out:
>
> static void __init omap_2430sdp_init_irq(void)
> {
> - omap2_init_common_hw(NULL);
> + omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
> omap_init_irq();
> omap_gpio_init();
> sdp2430_init_smc91x();
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index 195b749..24e2728 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -302,8 +302,10 @@ static inline void __init sdp3430_init_smc91x(void)
>
> static void __init omap_3430sdp_init_irq(void)
> {
> - omap2_init_common_hw(hyb18m512160af6_sdrc_params, omap3_mpu_rate_table,
> - omap3_dsp_rate_table, omap3_l3_rate_table);
> + omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
> + omap3_mpu_rate_table,
> + omap3_dsp_rate_table,
> + omap3_l3_rate_table);
> omap_init_irq();
> omap_gpio_init();
> sdp3430_init_smc91x();
> diff --git a/arch/arm/mach-omap2/board-apollon.c
> b/arch/arm/mach-omap2/board-apollon.c
> index 2e24812..2dd1350 100644
> --- a/arch/arm/mach-omap2/board-apollon.c
> +++ b/arch/arm/mach-omap2/board-apollon.c
> @@ -323,7 +323,7 @@ out:
>
> static void __init omap_apollon_init_irq(void)
> {
> - omap2_init_common_hw(NULL, NULL, NULL, NULL);
> + omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
> omap_init_irq();
>
Re: [PATCH 0/4]ARM: OMAP4: SMP: Patch series
On Wed, May 27, 2009 at 09:52:38PM +0530, Shilimkar, Santosh wrote: > I have rebased this series on top of your arm-smp patches and my earlier > basic omap4 patches. Can you please rebase your patches on commit c7f7ff1 in my tree (it's in my devel branch) and I'll merge them in. (Please don't base patches on the top of the devel branch - you may notice it's a merge of 'devel-unstable' which is... unstable stuff.) Thanks. -- 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
List of kernel config options for correct pm operation
Hi Kevin, Would you happen to have a list of recommend kernel config options for correct functioning for linux-omap-pm ? I'm working with the linux-omap3-2.6.29 kernel bitbake recipe and android-2.6.29. For, example till now I did not have CONFIG_OMAP_RESET_CLOCKS set, and that caused some issues earlier, which you pointed out should be set. The thing is I don't know what else I'm missing. Here is a partial listing, I don't know if I have to set some other options through # # OMAP Feature Selections # # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set # CONFIG_OMAP_SMARTREFLEX is not set # CONFIG_OMAP_SMARTREFLEX_TESTING is not set CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y # CONFIG_OMAP_COMPONENT_VERSION is not set # CONFIG_OMAP_GPIO_SWITCH is not set # CONFIG_OMAP_MUX is not set CONFIG_OMAP_MCBSP=y # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y # CONFIG_OMAP3_DEBOBS is not set CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_TICK_GPTIMER=1 CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set CONFIG_OMAP_LL_DEBUG_UART3=y # CONFIG_OMAP_PM_NONE is not set # CONFIG_OMAP_PM_NOOP is not set CONFIG_OMAP_PM_SRF=y CONFIG_ARCH_OMAP34XX=y CONFIG_ARCH_OMAP3430=y # # Power management options # CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_VERBOSE=y CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_PM_TEST_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HAS_WAKELOCK=y CONFIG_HAS_EARLYSUSPEND=y CONFIG_WAKELOCK=y CONFIG_WAKELOCK_STAT=y CONFIG_USER_WAKELOCK=y CONFIG_EARLYSUSPEND=y # CONFIG_NO_USER_SPACE_SCREEN_ACCESS_CONTROL is not set # CONFIG_CONSOLE_EARLYSUSPEND is not set CONFIG_FB_EARLYSUSPEND=y CONFIG_APM_EMULATION=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_NET=y Best regards, Elvis -- 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
What does CONFIG_SYSFS_DEPRECATED do?
Hi, What does CONFIG_SYSFS_DEPRECATED do? CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y Best regards, Elvis -- 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] RX51: Add support for SDRAM chip select 1
>-Original Message-
>From: ext Jean Pihet [mailto:jpi...@mvista.com]
>Sent: 08 June, 2009 16:06
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] RX51: Add support for SDRAM chip select 1
>
>Hi Tero,
>
>You should also ensure that the CKE signals mux settings are
>correct cf. an example for Overo at
>http://patchwork.kernel.org/patch/28598/.
Our bootloader configures the pads, I just double checked that it also changes
CKE pads to proper config.
The patch looks good otherwise? I tested this on RX51 HW and it works ok.
-Tero
>
>Note: the config option CONFIG_OMAP_MUX must be set for the
>omap_cfg* functions to have any effect.
>
>Regards,
>Jean
>
>On Monday 08 June 2009 14:03:23 Tero Kristo wrote:
>> From: Tero Kristo
>>
>> Applies on top of PM branch.
>>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/board-rx51.c |6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-rx51.c
>> b/arch/arm/mach-omap2/board-rx51.c index 3e4b7f8..7ab8a74 100644
>> --- a/arch/arm/mach-omap2/board-rx51.c
>> +++ b/arch/arm/mach-omap2/board-rx51.c
>> @@ -61,7 +61,11 @@ static struct omap_bluetooth_config
>rx51_bt_config
>> = {
>>
>> static void __init rx51_init_irq(void) {
>> -omap2_init_common_hw(rx51_get_sdram_timings(), NULL,
>> +struct omap_sdrc_params *sdrc_params;
>> +
>> +sdrc_params = rx51_get_sdram_timings();
>> +
>> +omap2_init_common_hw(sdrc_params, sdrc_params,
>> omap3_mpu_rate_table,
>> omap3_dsp_rate_table,
>> omap3_l3_rate_table);
>
>
>--
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] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
* Singh, Vimal
[090605
05:00]:
>
>
> On Thu, Jun 4, 2009 at 8:58 PM, Tony Lindgren wrote:
> > * vimal singh [090604 02:34]:
> >> On Wed, Jun 3, 2009 at 10:03 PM, Tony Lindgren wrote:
> >> > * Singh, Vimal
> >> [090602
> >> 23:46]:
> >> >>
> >> >> On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren wrote:
> >> >> > * vimal singh [090602 05:40]:
> >> >> >> This patch adds prefetch support to access nand flash in both mpu
> >> >> >> and dma
> >> mode.
> >> >> >> This patch also adds 8-bit nand support (omap_read/write_buf8).
> >> >> >> Prefetch can be used for both 8- and 16-bit devices.
> >> >> >
> >> >> > This should be reviewed on the linux-omap@vger.kernel.org list for
> >> >> > sure.
> >> >> > One other comment below.
> >> >> >
> >> >> >> Signed-off-by: Vimal Singh
> >> >> >> ---
> >> >> >> I prepared this patch on top of "OMAP2 / OMAP3 NAND driver" patch:
> >> >> >> http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
> >> >> >>
> >> >> >> ---
> >> >> >> arch/arm/mach-omap2/gpmc.c | 102 ++
> >> >> >> arch/arm/plat-omap/include/mach/gpmc.h |4
> >> >> >> drivers/mtd/nand/Kconfig | 17 +
> >> >> >> drivers/mtd/nand/omap2.c | 308
> >> -
> >> >> >> 4 files changed, 422 insertions(+), 9 deletions(-)
> >> >> >>
> >> >> >> Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
> >> >> >> ===
> >> >> >> --- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
> >> >> >> +++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
> >> >> >> @@ -54,6 +54,12 @@
> >> >> >> #define GPMC_CHUNK_SHIFT 24 /* 16 MB */
> >> >> >> #define GPMC_SECTION_SHIFT 28 /* 128 MB */
> >> >> >>
> >> >> >> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
> >> >> >> +#define CS_NUM_SHIFT 24
> >> >> >> +#define ENABLE_PREFETCH 7
> >> >> >> +#define DMA_MPU_MODE 2
> >> >> >> +#endif
> >> >> >> +
> >> >> >> static struct resource gpmc_mem_root;
> >> >> >> static struct resource gpmc_cs_mem[GPMC_CS_NUM];
> >> >> >> static DEFINE_SPINLOCK(gpmc_mem_lock);
> >> >> >> @@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
> >> >> >> }
> >> >> >> EXPORT_SYMBOL(gpmc_cs_free);
> >> >> >>
> >> >> >> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
> >> >> >> +/**
> >> >> >> + * gpmc_prefetch_init - configures default configuration for
> >> >> >> prefetch
> >> engine
> >> >> >> + */
> >> >> >> +static void gpmc_prefetch_init(void)
> >> >> >> +{
> >> >> >> + /* Setting the default threshold to 64 */
> >> >> >> + gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
> >> >> >> + gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 << 8);
> >> >> >> + gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
> >> >> >> +}
> >> >> >
> >> >> > Why would you want to have NAND specific init code int gpmc.c?
> >> >> >
> >> >> > The purpose if gpmc.c is to provide access to configuring the
> >> >> > General Purpose Memory Controller (GPMC). You should just provide
> >> >> > functions in gpmc.c for the platform init code to use, and then
> >> >> > the drivers can stay platform independent.
> >> >>
> >> >> In my understanding, this 'prefetch' engine is part of GPMC itself, it
> >> >> is a
> >> >> kind of feature provided by GPMC which can be utilized by NAND driver.
> >> >> So, to me, it makes sens to get initialized prefetch by GPMC itself so
> >> >> that
> >> >> NAND driver can use it.
> >> >
> >> > But it should not have a dependency to NAND.
> >>
> >> This engine, in GPMC, is dedicated for NAND devices only.
> >>
> >> >
> >> >> Another reason was that all read / write to GPMC register are done by
> >> >> functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
> >> >> 'static' in nature.
> >> >
> >> > That's why you need to provide a generic function in gpmc.c to enable
> >> > prefetch that the platform code for any driver can use.
> >>
> >> Exactly, and whenever a platform code uses gpmc init call, gpmc initializes
> >> this engine too. Since prefetch engine is the part of GPMC, IMHOP, it
> >> should
> >> get initialized as part of GPMC initialization.
> >
> > No, the driver needing it should initialize it. There should not be any
> > ifdefs needed in the gpmc.c for that.
>
> Are you suggesting to move gpmc prefetch specific code to
> 'drivers/mtd/nand/omap2.c'?
> This can be done but then, we will be accessing gpmc registers outside
> gpmc.c. Is that ok?
Well I'm thinking that you just basically need something like this in
gpmc.c:
int gpmc_prefetch_request(int cs);
int gpmc_prefetch_enable(int cs);
int gpmc_prefetch_reset(int cs);
...
And gpmc_prefetch_request would then return an error if already taken.
No need then to tinker with the GPMC prefetch registers in the NAND
driver.
> >
> >> And then there are prefetch start, stop and status functions calls have
> >> been
> >> provided to be used by NAND driver.
> >
> > These should really be done in the platform init code f
Re: [PATCH] RX51: Add support for SDRAM chip select 1
Hi Tero,
You should also ensure that the CKE signals mux settings are correct cf. an
example for Overo at http://patchwork.kernel.org/patch/28598/.
Note: the config option CONFIG_OMAP_MUX must be set for the omap_cfg*
functions to have any effect.
Regards,
Jean
On Monday 08 June 2009 14:03:23 Tero Kristo wrote:
> From: Tero Kristo
>
> Applies on top of PM branch.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/board-rx51.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51.c
> b/arch/arm/mach-omap2/board-rx51.c index 3e4b7f8..7ab8a74 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -61,7 +61,11 @@ static struct omap_bluetooth_config rx51_bt_config = {
>
> static void __init rx51_init_irq(void)
> {
> - omap2_init_common_hw(rx51_get_sdram_timings(), NULL,
> + struct omap_sdrc_params *sdrc_params;
> +
> + sdrc_params = rx51_get_sdram_timings();
> +
> + omap2_init_common_hw(sdrc_params, sdrc_params,
>omap3_mpu_rate_table,
>omap3_dsp_rate_table,
>omap3_l3_rate_table);
--
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] RX51: Add support for SDRAM chip select 1
From: Tero Kristo
Applies on top of PM branch.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/board-rx51.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 3e4b7f8..7ab8a74 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -61,7 +61,11 @@ static struct omap_bluetooth_config rx51_bt_config = {
static void __init rx51_init_irq(void)
{
- omap2_init_common_hw(rx51_get_sdram_timings(), NULL,
+ struct omap_sdrc_params *sdrc_params;
+
+ sdrc_params = rx51_get_sdram_timings();
+
+ omap2_init_common_hw(sdrc_params, sdrc_params,
omap3_mpu_rate_table,
omap3_dsp_rate_table,
omap3_l3_rate_table);
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU > Sent: Monday, June 08, 2009 6:34 AM > To: Ramirez Luna, Omar > Cc: ameya.pala...@nokia.com; linux-omap@vger.kernel.org; > felipe.contre...@gmail.com > Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl > http://marc.info/?l=linux-omap&m=124201773423892&w=2 > > for the second one about 128 byte alignment. let me know your > thought/plan on it. How about enabling this[1] under a configurable option? Though this is a strong check, currently components such as ti-openmax IL does a padded allocation to ignore overwrite of buffer region which might be at risk. The check is desirable, but should have an option to disable it, if so desired. Regards, Nishanth Menon Ref: [1] http://marc.info/?l=linux-omap&m=124201773423892&w=2 -- 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: Compiler wanrning fix for unlocked_ioctl
From: "ext Ramirez Luna, Omar"
Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
Date: Mon, 8 Jun 2009 08:49:03 +0200
> >From: Ameya Palande [mailto:ameya.pala...@nokia.com]
> >Subject: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
> >
> >From: Ameya Palande
> >
> >Signed-off-by: Ameya Palande
> >---
> > drivers/dsp/bridge/rmgr/drv_interface.c |2 +-
> > drivers/dsp/bridge/rmgr/drv_interface.h |2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
> >b/drivers/dsp/bridge/rmgr/drv_interface.c
> >index c3d8a02..f41e153 100644
> >--- a/drivers/dsp/bridge/rmgr/drv_interface.c
> >+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
> >@@ -665,7 +665,7 @@ static int bridge_release(struct inode *ip, struct file
> >*filp)
> > }
> >
> > /* This function provides IO interface to the bridge driver. */
> >-static int bridge_ioctl(struct file *filp, unsigned int code,
> >+static long bridge_ioctl(struct file *filp, unsigned int code,
> > unsigned long args)
> > {
> > int status;
> >diff --git a/drivers/dsp/bridge/rmgr/drv_interface.h
> >b/drivers/dsp/bridge/rmgr/drv_interface.h
> >index 3e77ed0..dc49210 100644
> >--- a/drivers/dsp/bridge/rmgr/drv_interface.h
> >+++ b/drivers/dsp/bridge/rmgr/drv_interface.h
> >@@ -34,7 +34,7 @@ static int __init bridge_init(void); /* Initialize
> >bridge */
> > static void __exit bridge_exit(void); /* Opposite of initialize */
> > static int bridge_open(struct inode *, struct file *); /* Open */
> > static int bridge_release(struct inode *, struct file *); /* Release */
> >-static int bridge_ioctl(struct file *, unsigned int,
> >+static long bridge_ioctl(struct file *, unsigned int,
> > unsigned long);
> > static int bridge_mmap(struct file *filp, struct vm_area_struct *vma);
> > #endif /* ifndef _DRV_INTERFACE_H_ */
> >--
> >1.6.2.4
> >
>
> Pushed to bridge tree on dev.omapzoom.org
Thanks. Also there still seems to remain 2 patches:
http://marc.info/?l=linux-omap&m=124201773423895&w=2
http://marc.info/?l=linux-omap&m=124201773423892&w=2
I think that the first one should be merged into d.o-z.org now, but
for the second one about 128 byte alignment. let me know your
thought/plan on it.
>
> - omar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
On Mon, Jun 8, 2009 at 12:02 PM, Jean Pihet wrote:
> Paul, Gražvydas,
>
> Ok, thanks!
>
> Here is a patch that addresses the Pandora's use of 2 SDRAM chip selects.
> It applies on top of 'OMAP3: add support for 2 SDRAM chip selects'.
>
> Is that OK? It has been build tested only.
thanks!
>
> Regards,
> Jean
>
> From 297a0b09267fc1a0ae4428771ff54b73b27d5bbe Mon Sep 17 00:00:00 2001
> From: Jean Pihet
> Date: Mon, 8 Jun 2009 10:49:53 +0200
> Subject: OMAP3 Pandora: add support for 2 SDRAM chip selects
>
> This allows the self refresh to work correctly on
> Pandora.
>
> Signed-off-by: Jean Pihet
> ---
> arch/arm/mach-omap2/board-omap3pandora.c | 8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
> b/arch/arm/mach-omap2/board-omap3pandora.c
> index 05ab99e..ba015b4 100644
> --- a/arch/arm/mach-omap2/board-omap3pandora.c
> +++ b/arch/arm/mach-omap2/board-omap3pandora.c
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -220,7 +221,8 @@ static int __init omap3pandora_i2c_init(void)
>
> static void __init omap3pandora_init_irq(void)
> {
> - omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
> + omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
> + mt46h32m32lf6_sdrc_params,
> NULL, NULL, NULL);
Hm, since pandora uses OMAP3530, maybe it should also have
omap3_*_rate_table args passed? Could also be true for Overo, at least
for omap3_mpu_rate_table and omap3_l3_rate_table, as some models use
OMAP3503 without the DSP.
> omap_init_irq();
> omap_gpio_init();
> @@ -307,6 +309,10 @@ static void __init omap3pandora_init(void)
> usb_ehci_init();
> omap3pandora_flash_init();
> omap3pandora_ads7846_init();
> +
> + /* Ensure SDRC pins are mux'd for self-refresh */
> + omap_cfg_reg(H16_34XX_SDRC_CKE0);
> + omap_cfg_reg(H17_34XX_SDRC_CKE1);
> }
>
> static void __init omap3pandora_map_io(void)
> --
> 1.6.2.5.168.g3823
>
>
> On Saturday 06 June 2009 12:50:42 Grazvydas Ignotas wrote:
>> On Fri, Jun 5, 2009 at 10:14 PM, Paul Walmsley wrote:
>> > Hi Jean,
>> >
>> > On Fri, 5 Jun 2009, Jean Pihet wrote:
>> >> Some notes:
>> >> - all calls to omap2_init_common_hw have been adapted in the board
>> >> files. it looks like 2430SDP and Pandora board files are broken since
>> >> they use only one param. Can that be checked on those boards?
>> >
>> > Yep, builds with those two boards are broken on the PM branch, and it
>> > looks like your patch fixes both.
>> >
>> > Gražyvdas, looks like Pandora might use 2 SDRAM chipselects also?
>>
>> Yes it does, it uses different part than Beagle rev C (256/512
>> RAM/NAND instead of 256/256), but RAM portion should be identical I
>> guess.
>>
>>
>> Gražvydas
>
>
>
--
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: Solution: N810 keyboard regression
Hi, On Sun, Jun 07, 2009 at 01:15:35AM +0200, ext Luke-Jr wrote: > > did you try changing that keysize calculation ? > > No, I wanted to get the opinion of someone who knows how that code actually > is > supposed to work before I try randomly changing things I don't understand. > > > Do you see irqs comming? Any debugging messages ? > > There were no debugging messages when the broken keys were pressed, nor did a > dbg I added to the driver get triggered for them. looks like we're gonna need one of the original writes to take a look at this. I don't know the chip that well and don't have enough time to look for the docs... but I still suggest you try changing that line and see what happens though -- 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: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
Paul, Gražvydas,
Ok, thanks!
Here is a patch that addresses the Pandora's use of 2 SDRAM chip selects.
It applies on top of 'OMAP3: add support for 2 SDRAM chip selects'.
Is that OK? It has been build tested only.
Regards,
Jean
>From 297a0b09267fc1a0ae4428771ff54b73b27d5bbe Mon Sep 17 00:00:00 2001
From: Jean Pihet
Date: Mon, 8 Jun 2009 10:49:53 +0200
Subject: OMAP3 Pandora: add support for 2 SDRAM chip selects
This allows the self refresh to work correctly on
Pandora.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/board-omap3pandora.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 05ab99e..ba015b4 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -220,7 +221,8 @@ static int __init omap3pandora_i2c_init(void)
static void __init omap3pandora_init_irq(void)
{
- omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
+mt46h32m32lf6_sdrc_params,
NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
@@ -307,6 +309,10 @@ static void __init omap3pandora_init(void)
usb_ehci_init();
omap3pandora_flash_init();
omap3pandora_ads7846_init();
+
+ /* Ensure SDRC pins are mux'd for self-refresh */
+ omap_cfg_reg(H16_34XX_SDRC_CKE0);
+ omap_cfg_reg(H17_34XX_SDRC_CKE1);
}
static void __init omap3pandora_map_io(void)
--
1.6.2.5.168.g3823
On Saturday 06 June 2009 12:50:42 Grazvydas Ignotas wrote:
> On Fri, Jun 5, 2009 at 10:14 PM, Paul Walmsley wrote:
> > Hi Jean,
> >
> > On Fri, 5 Jun 2009, Jean Pihet wrote:
> >> Some notes:
> >> - all calls to omap2_init_common_hw have been adapted in the board
> >> files. it looks like 2430SDP and Pandora board files are broken since
> >> they use only one param. Can that be checked on those boards?
> >
> > Yep, builds with those two boards are broken on the PM branch, and it
> > looks like your patch fixes both.
> >
> > Gražyvdas, looks like Pandora might use 2 SDRAM chipselects also?
>
> Yes it does, it uses different part than Beagle rev C (256/512
> RAM/NAND instead of 256/256), but RAM portion should be identical I
> guess.
>
>
> Gražvydas
--
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] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
Paul,
Here is the updated patch that fixes the Overo build as well.
Can you check it?
Kevin, can you push it if it is correct?
Regards,
Jean
>From ebe57354b0de059e1f042e0c488f761853f0 Mon Sep 17 00:00:00 2001
From: Jean Pihet
Date: Fri, 5 Jun 2009 17:19:00 +0200
Subject: OMAP3: add support for 2 SDRAM chip selects
Some boards (Beagle Cx, Overo) have 2 SDRAM parts
connected to the SDRC.
This patch adds the following:
- ensure that the CKE signals mux settings are correct
- add a new argument of type omap_sdrc_params struct*
to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
- adapt the sram sleep code to configure the SDRC for the 2nd CS
Note: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registers
Tested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume and frequency changes (cpufreq).
Thanks to Paul Walmsley and Kevin Hilman for the suggestions
and code reviews.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |6 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-n800.c |2 +-
arch/arm/mach-omap2/board-omap2evm.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
arch/arm/mach-omap2/board-omap3evm.c |6 +-
arch/arm/mach-omap2/board-omap3pandora.c |3 +-
arch/arm/mach-omap2/board-overo.c|9 ++-
arch/arm/mach-omap2/board-rx51.c |6 +-
arch/arm/mach-omap2/clock34xx.c | 37 ++--
arch/arm/mach-omap2/io.c |5 +-
arch/arm/mach-omap2/mux.c|6 ++
arch/arm/mach-omap2/sdrc.c | 63 +-
arch/arm/mach-omap2/sram34xx.S | 137
+++---
arch/arm/plat-omap/include/mach/io.h |3 +-
arch/arm/plat-omap/include/mach/mux.h|4 +
arch/arm/plat-omap/include/mach/sdrc.h |8 +-
arch/arm/plat-omap/include/mach/sram.h | 23 +++--
arch/arm/plat-omap/sram.c| 34 +---
23 files changed, 267 insertions(+), 108 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index aa5df72..4cb7bc5 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -322,7 +322,7 @@ out:
static void __init omap_2430sdp_init_irq(void)
{
- omap2_init_common_hw(NULL);
+ omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
sdp2430_init_smc91x();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 195b749..24e2728 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,8 +302,10 @@ static inline void __init sdp3430_init_smc91x(void)
static void __init omap_3430sdp_init_irq(void)
{
- omap2_init_common_hw(hyb18m512160af6_sdrc_params, omap3_mpu_rate_table,
-omap3_dsp_rate_table, omap3_l3_rate_table);
+ omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
+omap3_mpu_rate_table,
+omap3_dsp_rate_table,
+omap3_l3_rate_table);
omap_init_irq();
omap_gpio_init();
sdp3430_init_smc91x();
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 2e24812..2dd1350 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -323,7 +323,7 @@ out:
static void __init omap_apollon_init_irq(void)
{
- omap2_init_common_hw(NULL, NULL, NULL, NULL);
+ omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
apollon_init_smc91x();
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index be763a9..763329b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -33,7 +33,7 @@
static void __init omap_generic_init_irq(void)
{
- omap2_init_common_hw(NULL, NULL, NULL, NULL);
+ omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
}
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 8f54939..17c3599 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -348,7 +348,7 @@ static void __init h4_init_flash(void)
static void __init omap_h4_init_irq(void)
{
- omap2_init_common_hw(NULL, NULL, NULL, NULL);
+ omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
VS: [PATCH] OMAP3: PM: Fix the pwrdm_enable/disable_hdwr_sar funcs
Lähettäjä: Kevin Hilman [khil...@deeprootsystems.com] Lähetetty: 6. kesäkuuta 2009 1:53 Vastaanottaja: Paul Walmsley Kopio: Rajendra Nayak; Jokiniemi Kalle; linux-omap@vger.kernel.org Aihe: Re: [PATCH] OMAP3: PM: Fix the pwrdm_enable/disable_hdwr_sar funcs Paul Walmsley writes: >> On Fri, 5 Jun 2009, Kevin Hilman wrote: >> >>> Rajendra Nayak writes: >>> >>> > The pwrdm_enable_hdwr_sar/pwrdm_disable_hdwr_sar do not >>> > actually set/reset the SAVEANDRESTORE bit in the PWSTCTRL >>> > register but modify some other bit instead. >>> > This happens due to the OMAP3430ES2_SAVEANDRESTORE_SHIFT >>> > being defined as (1 << 4) instead of just 4. >>> > >>> > Signed-off-by: Rajendra Nayak >>> >>> Thanks, pushing to PM branch. >>> >>> I'll wait to hear from Kalle if we can revert his previous patch >>> for this. >> >> I think Kalle covered this one already: >> >> http://patchwork.kernel.org/patch/15586/ > > ... but was missing from PM branch. Remedied now. > > But we also have a patch in the PM branch[1] which disables the > USBHOST SAR by removing the HAS_HDWR_SAR flag for the pwrdm. > > I'm gessing/hoping that fixing this shift value allows us to > revert that patch and am hoping for some confirmation from > Kalle. The above shift fix enabled both USBHOST and USBTLL saverestores. Unfortunately, the USBHOST saverestore seems to cause the USBHOST power domain to hang in active state after toggling /sys/power/enable_off_mode 0 -> 1-> 0. This was observed at least on RX-51. Haven't tested this on other hardware though. USBTLL saverestore works ok on ES3.1 and later devices. I think the conclusion from discussion with Richard W. was that using SW triggered power domain state transition for USBHOST would make the USBHOST SAR work. The problem with just disabling USBHOST SAR is that it leaves ES3.0 devices open for the dreaded "cold reset issue" (as USBTLL SAR won't work on ES3.0). We are currently using all ES3.1 devices, so there is no push to get a better fix for this. If anyone wants to take a shot at the problem, feel free to do so. - Kalle > > Kevin > > [1] > http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=942fc93ce6b5ec7999f7864f6bb088cc8f308f45 >-- 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] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
>-Original Message-
>From: ext Paul Walmsley [mailto:p...@pwsan.com]
>Sent: 05 June, 2009 21:11
>To: Jean Pihet; Kristo Tero (Nokia-D/Tampere)
>Cc: Kevin Hilman; linux-omap
>Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip
>selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
>
>Hi Jean,
>
>On Fri, 5 Jun 2009, Jean Pihet wrote:
>
>> Here is the new patch that includes all the remarks and suggestion.
>> The description is here below.
>>
>> Some notes:
>> - all calls to omap2_init_common_hw have been adapted in the board
>> files. it looks like 2430SDP and Pandora board files are
>broken since
>> they use only one param. Can that be checked on those boards?
>> - it is assumed that RX51 only uses 1 CS. Is that correct?
>>
>> Can you review it and possibly merge?
>
>Looks great.
>
>Tero, does RX51 use two SDRC chipselects!
Yes, I'll take a look at this and post a patch on top of this. I did this for
the earlier version already, but need to re-check this one.
-Tero
>
>Acked-by: Paul Walmsley
>
>
>>
>> Thanks & regards,
>> Jean
>>
>> --
>> From 097a640997b74638e0e7200ecd5834205204c956 Mon Sep 17
>00:00:00 2001
>> From: Jean Pihet
>> Date: Fri, 5 Jun 2009 17:19:00 +0200
>> Subject: [PATCH] [PATCH] OMAP3: add support for 2 SDRAM chip selects
>>
>> Some boards (Beagle Cx, Overo) have 2 SDRAM parts connected to the
>> SDRC.
>>
>> This patch adds the following:
>> - ensure that the CKE signals mux settings are correct
>> - add a new argument of type omap_sdrc_params struct* to
>> omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
>> - adapted the OMAP boards files to the new prototype of
>> omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
>> - adapt the sram sleep code to configure the SDRC for the 2nd CS
>>
>> Note: If the 2nd param to omap2_init_common_hw is NULL, then the
>> parameters are not programmed into the SDRC CS1 registers
>>
>> Tested on 3430 SDP and Beagleboard rev C2 and B5, with
>suspend/resume
>> and frequency changes (cpufreq).
>>
>> Thanks to Paul Walmsley and Kevin Hilman for the suggestions
>and code
>> reviews.
>>
>> Signed-off-by: Jean Pihet
>> ---
>> arch/arm/mach-omap2/board-2430sdp.c |2 +-
>> arch/arm/mach-omap2/board-3430sdp.c |6 +-
>> arch/arm/mach-omap2/board-apollon.c |2 +-
>> arch/arm/mach-omap2/board-generic.c |2 +-
>> arch/arm/mach-omap2/board-h4.c |2 +-
>> arch/arm/mach-omap2/board-ldp.c |2 +-
>> arch/arm/mach-omap2/board-n800.c |2 +-
>> arch/arm/mach-omap2/board-omap2evm.c |2 +-
>> arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
>> arch/arm/mach-omap2/board-omap3evm.c |6 +-
>> arch/arm/mach-omap2/board-omap3pandora.c |3 +-
>> arch/arm/mach-omap2/board-overo.c|8 ++-
>> arch/arm/mach-omap2/board-rx51.c |6 +-
>> arch/arm/mach-omap2/clock34xx.c | 37 ++--
>> arch/arm/mach-omap2/io.c |5 +-
>> arch/arm/mach-omap2/mux.c|6 ++
>> arch/arm/mach-omap2/sdrc.c | 63 +-
>> arch/arm/mach-omap2/sram34xx.S | 137
>> +++---
>> arch/arm/plat-omap/include/mach/io.h |3 +-
>> arch/arm/plat-omap/include/mach/mux.h|4 +
>> arch/arm/plat-omap/include/mach/sdrc.h |8 +-
>> arch/arm/plat-omap/include/mach/sram.h | 23 +++--
>> arch/arm/plat-omap/sram.c| 34 +---
>> 23 files changed, 266 insertions(+), 108 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c
>> b/arch/arm/mach-omap2/board-2430sdp.c
>> index aa5df72..4cb7bc5 100644
>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>> @@ -322,7 +322,7 @@ out:
>>
>> static void __init omap_2430sdp_init_irq(void) {
>> -omap2_init_common_hw(NULL);
>> +omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
>> omap_init_irq();
>> omap_gpio_init();
>> sdp2430_init_smc91x();
>> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
>> b/arch/arm/mach-omap2/board-3430sdp.c
>> index 195b749..24e2728 100644
>> --- a/arch/arm/mach-omap2/board-3430sdp.c
>> +++ b/arch/arm/mach-omap2/board-3430sdp.c
>> @@ -302,8 +302,10 @@ static inline void __init
>> sdp3430_init_smc91x(void)
>>
>> static void __init omap_3430sdp_init_irq(void) {
>> -omap2_init_common_hw(hyb18m512160af6_sdrc_params,
>omap3_mpu_rate_table,
>> - omap3_dsp_rate_table, omap3_l3_rate_table);
>> +omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
>> + omap3_mpu_rate_table,
>> + omap3_dsp_rate_table,
>> + omap3_l3_rate_table);
>> omap_init_irq();
>> omap_gpio_init();
>> sdp3430_init_smc91x();
>> diff --git a/arch/arm/mach-omap2/board-apollon.c
>> b/arch/arm/mach-omap2/board-apollon.c
>> index 2e24812..2dd1350 100644
>> --- a/arch/arm/mach-omap2/boa
