Re: [PATCH 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
On Wed, Mar 21, 2012 at 7:58 PM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's As this affects multiple SoCs, please report what SoCs it was tested on as well. Sorry I for got to add that, here are details on what was tested. 1.) OMAP2430 SDP : Boot tested with uart1 as console. 2.) OMAP3430 SDP: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 3.) OMAP3630 - Beagle XM: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 4.) OMAP4430 - PANDA: Boot test, suspend/resume tests 5.) OMAP4460 - PANDA: Boot test. -- Thanks, Govindraj.R Thanks, Kevin Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h | 8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 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
Re: [PATCH 08/13] Add dummy smsc911x regulators to ldp.
Op 22 mrt. 2012, om 06:19 heeft Russ Dill het volgende geschreven:
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-ldp.c |7 +++
arch/arm/mach-omap2/board-omap3evm.c |9 +
Is that evm hunk intentional?
regards,
Koen
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d50a562a..1b60495 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/spi/spi.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
#include linux/io.h
@@ -410,8 +411,14 @@ static struct mtd_partition ldp_nand_partitions[] = {
};
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap_ldp_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
ldp_init_smsc911x();
omap_i2c_init();
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 548e1ef..a659e19 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,6 +114,15 @@ static struct omap_smsc911x_platform_data smsc911x_cfg =
{
static inline void __init omap3evm_init_smsc911x(void)
{
+ struct clk *l3ck;
+ unsigned int rate;
+
+ l3ck = clk_get(NULL, l3_ck);
+ if (IS_ERR(l3ck))
+ rate = 1;
+ else
+ rate = clk_get_rate(l3ck);
+
/* Configure ethernet controller reset gpio */
if (cpu_is_omap3430()) {
if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] Add dummy smsc911x regulators to omap3evm.
Op 22 mrt. 2012, om 06:19 heeft Russ Dill het volgende geschreven:
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a659e19..6a5e57c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,15 +114,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg =
{
static inline void __init omap3evm_init_smsc911x(void)
{
- struct clk *l3ck;
- unsigned int rate;
-
- l3ck = clk_get(NULL, l3_ck);
- if (IS_ERR(l3ck))
- rate = 1;
- else
- rate = clk_get_rate(l3ck);
The above hunk gets added/removed multiple times during this patch series, a
rebase -i mishap?
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 09/13] Add dummy smsc911x regulators to omap3evm.
On Thu, Mar 22, 2012 at 12:07 AM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 22 mrt. 2012, om 06:19 heeft Russ Dill het volgende geschreven:
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a659e19..6a5e57c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -114,15 +114,6 @@ static struct omap_smsc911x_platform_data smsc911x_cfg
= {
static inline void __init omap3evm_init_smsc911x(void)
{
- struct clk *l3ck;
- unsigned int rate;
-
- l3ck = clk_get(NULL, l3_ck);
- if (IS_ERR(l3ck))
- rate = 1;
- else
- rate = clk_get_rate(l3ck);
The above hunk gets added/removed multiple times during this patch series, a
rebase -i mishap?
Yes, its a rebase -i mishap. I have no idea how it did that as all I
was doing was rewording. I can resend the series
--
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 RFC] usb: musb: omap: fix the error check for pm_runtime_get_sync
pm_runtime_get_sync returns a signed integer.In case of errors
it returns a negative value.This patch fixes the error check
by making it signed instead of unsigned thus preventing register
access if get_sync_fails. Also passes the error cause to the
debug message.
Cc: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Compile tested only
drivers/usb/musb/omap2430.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2ae0bb3..e5dd18f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -282,7 +282,8 @@ static void musb_otg_notifier_work(struct work_struct
*data_notifier_work)
static int omap2430_musb_init(struct musb *musb)
{
- u32 l, status = 0;
+ u32 l;
+ int status = 0;
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *plat = dev-platform_data;
struct omap_musb_board_data *data = plat-board_data;
@@ -301,7 +302,7 @@ static int omap2430_musb_init(struct musb *musb)
status = pm_runtime_get_sync(dev);
if (status 0) {
- dev_err(dev, pm_runtime_get_sync FAILED);
+ dev_err(dev, pm_runtime_get_sync FAILED %d \n,status);
goto err1;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 RESEND 0/7] gpio/omap: Some more driver fixes
On Tue, 20 Mar 2012 10:46:57 -0700, Kevin Hilman khil...@ti.com wrote: Hi Grant, Grant Likely grant.lik...@secretlab.ca writes: On Tue, 20 Mar 2012 16:23:12 +0530, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: This series excludes the cleanup patches as suggested by Kevin from the previously posted series. The fixes include correction of _set_gpio_irqenable() implementation, missing wakeup_en register update in set_gpio_wakeup(), type mismatch of gpio trigger parameter in set_gpio_trigger(), incorrect dataout register update in set_gpio_dataout_() and few corrections in context save logic. It is baselined on top of: git://git.secretlab.ca/git/linux-2.6.git gpio/next Commit: 81b279d80a63628e580c71a31d30a8c3b3047ad4 Series is available here for reference: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_more_fixes Merged; thanks Can you hold off slightly before merging this. I haven't been through v4 yet or tested the fixes alone now that they're separated from the other cleanups. Expect a pull request from me when ready. Okay. It's in linux-next at the moment, but I'll pull it back out. g. -- 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 RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026
Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619
pm_runtime_enable is being called after omap2430_musb_init. Hence
pm_runtime_get_sync in omap2430_musb_init does not have any effect (does
not enable clocks) resulting in a crash during register access. It is
fixed here.
Cc: sta...@vger.kernel.org
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Tested MUSB in 4430SDP.
drivers/usb/musb/omap2430.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2ae0bb3..73bd5ed 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -452,14 +452,14 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
goto err2;
}
+ pm_runtime_enable(pdev-dev);
+
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
goto err2;
}
- pm_runtime_enable(pdev-dev);
-
return 0;
err2:
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/13] Remove non-existent parameter from fixed-helper.c kernel doc.
On Wed, Mar 21, 2012 at 10:19:45PM -0700, Russ Dill wrote: Signed-off-by: Russ Dill russ.d...@ti.com I'll apply this once -rc1 comes out, it's totally orthogonal to the rest of the series. signature.asc Description: Digital signature
Re: [PATCH 13/13] Add dummy smsc911x regulators to zoom-debugboard.
On Wed, Mar 21, 2012 at 10:19:54PM -0700, Russ Dill wrote:
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
Why do none of these boards use -1 as the ID for the device?
signature.asc
Description: Digital signature
Suspend broken on 3.3?
Is system suspend broken on stock 3.3? I have a working stock 3.2 (with patches to fix runtime_pm for DSS2), and system suspend works just fine! This is running on a variety of GUMSTIX boards (both OMAP3530 and AM3703-based). I've just updated to stock 3.3 and suspend returns immediately when entered: # echo mem /sys/power/state [ 72.391693] PM: Syncing filesystems ... done. [ 72.397003] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 72.425201] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 72.456451] Suspending console(s) (use no_console_suspend to debug) [ 72.581695] PM: suspend of devices complete after 115.977 msecs [ 72.584594] PM: late suspend of devices complete after 2.868 msecs [ 72.612060] Successfully put all powerdomains to target state [ 72.613983] PM: early resume of devices complete after 1.770 msecs [ 72.941894] PM: resume of devices complete after 326.630 msecs [ 72.975677] Restarting tasks ... done. I've looked in the debugfs and see: # cat suspend_stats success: 1 fail: 0 failed_freeze: 0 failed_prepare: 0 failed_suspend: 0 failed_suspend_noirq: 0 failed_resume: 0 failed_resume_noirq: 0 failures: last_failed_dev: last_failed_errno:0 0 last_failed_step: # cat wakeup_sources nameactive_countevent_count hit_count active_since total_time max_timelast_change gpio-keys 0 0 0 0 0 0 0 (null) 0 0 0 0 0 0 0 (null) 0 0 0 0 0 0 0 1-0048 0 0 0 0 0 0 0 omap_uart.3 0 0 0 0 0 0 0 omap_uart.2 0 0 0 0 0 0 0 So have no idea what is causing the wakeup. How should I go about debugging this further? Has anyone else tried suspend on 3.3? I've tried this both with my custom defconfig and omap2plus_defconfig. I do have some modifications to the GUMSTIX overo board file (minor changes like defining some extra buttons, and setting the correct LCD parameters), but I'm fairly certain these shouldn't be causing any problems... Cheers, Joe -- 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 RFC] usb: musb: omap: fix the error check for pm_runtime_get_sync
Hello.
On 22-03-2012 11:18, Shubhrajyoti D wrote:
pm_runtime_get_sync returns a signed integer.In case of errors
it returns a negative value.This patch fixes the error check
by making it signed instead of unsigned thus preventing register
access if get_sync_fails. Also passes the error cause to the
debug message.
Cc: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
Compile tested only
You haven't run it thru scripts/checkpatch.pl either, I guess?
drivers/usb/musb/omap2430.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2ae0bb3..e5dd18f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
[...]
@@ -301,7 +302,7 @@ static int omap2430_musb_init(struct musb *musb)
status = pm_runtime_get_sync(dev);
if (status 0) {
- dev_err(dev, pm_runtime_get_sync FAILED);
+ dev_err(dev, pm_runtime_get_sync FAILED %d \n,status);
If I don't mistake, scripts/checkpatch.pl should warn about unneeded
spaces before '\n'. And also about missing spaces after commas.
WBR, Sergei
--
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 RFC] usb: musb: omap: fix the error check for pm_runtime_get_sync
On Thu, Mar 22, 2012 at 04:42:21PM +0400, Sergei Shtylyov wrote:
Hello.
On 22-03-2012 11:18, Shubhrajyoti D wrote:
pm_runtime_get_sync returns a signed integer.In case of errors
it returns a negative value.This patch fixes the error check
by making it signed instead of unsigned thus preventing register
access if get_sync_fails. Also passes the error cause to the
debug message.
Cc: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
Compile tested only
You haven't run it thru scripts/checkpatch.pl either, I guess?
drivers/usb/musb/omap2430.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2ae0bb3..e5dd18f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
[...]
@@ -301,7 +302,7 @@ static int omap2430_musb_init(struct musb *musb)
status = pm_runtime_get_sync(dev);
if (status 0) {
-dev_err(dev, pm_runtime_get_sync FAILED);
+dev_err(dev, pm_runtime_get_sync FAILED %d \n,status);
If I don't mistake, scripts/checkpatch.pl should warn about
unneeded spaces before '\n'. And also about missing spaces after
commas.
I fixed in my branch, thanks
--
balbi
signature.asc
Description: Digital signature
RE: Occasional crashes in suspend-resume with MMC transactions
On Thu, Mar 22, 2012 at 09:53:23, Bedia, Vaibhav wrote: Hi, I am trying to do suspend-resume test with a file copy on MMC/SD going on in the background. The test involves simply copying a 450MB file on an ext3 partition to the same partition under a different name. This is on an AM335x board which uses the omap_hsmmc driver. The kernel is v3.2 and I have also applied the following patch [...] I found that whenever this issue crops up, mmc_host_suspend() is not able to claim the host And returns -EBUSY. omap_hsmmc driver does not pass on this error code to the PM core and hence the suspend process continues. When the driver is made to return -EBUSY, the suspend process gets aborted and the user can try suspending again. I am not sure whether this sort of suspend failure is acceptable or the driver is doing something wrong. The following workaround is what I came up with. Do this look a reasonable thing to do? --- From a4040dd1869b351a5fa29dacd08facf6e24df609 Mon Sep 17 00:00:00 2001 From: Vaibhav Bedia vaibhav.be...@ti.com Date: Thu, 22 Mar 2012 17:14:49 +0530 Subject: [PATCH 1/1] mmc: omap_hsmmc: Pass on the suspend failure to the PM core In some cases mmc_host_suspend() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com --- drivers/mmc/host/omap_hsmmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 3d8dbbb..1f938d9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2238,6 +2238,7 @@ static int omap_hsmmc_suspend(struct device *dev) dev_dbg(mmc_dev(host-mmc), Unmask interrupt failed\n); } + ret = -EBUSY; goto err; } -- 1.7.0.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
[PATCH RFC v2] usb: musb: omap: fix the error check for pm_runtime_get_sync
pm_runtime_get_sync returns a signed integer.In case of errors
it returns a negative value.This patch fixes the error check
by making it signed instead of unsigned thus preventing register
access if get_sync_fails. Also passes the error cause to the
debug message.
Cc : Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Compile tested only
drivers/usb/musb/omap2430.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2ae0bb3..e5dd18f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -282,7 +282,8 @@ static void musb_otg_notifier_work(struct work_struct
*data_notifier_work)
static int omap2430_musb_init(struct musb *musb)
{
- u32 l, status = 0;
+ u32 l;
+ int status = 0;
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *plat = dev-platform_data;
struct omap_musb_board_data *data = plat-board_data;
@@ -301,7 +302,7 @@ static int omap2430_musb_init(struct musb *musb)
status = pm_runtime_get_sync(dev);
if (status 0) {
- dev_err(dev, pm_runtime_get_sync FAILED);
+ dev_err(dev, pm_runtime_get_sync FAILED %d\n, status);
goto err1;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] usb: musb: omap: fix the error check for pm_runtime_get_sync
You haven't run it thru scripts/checkpatch.pl either, I guess?
Actually modified the patch a little afterwards.
drivers/usb/musb/omap2430.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2ae0bb3..e5dd18f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
[...]
@@ -301,7 +302,7 @@ static int omap2430_musb_init(struct musb *musb)
status = pm_runtime_get_sync(dev);
if (status 0) {
- dev_err(dev, pm_runtime_get_sync FAILED);
+ dev_err(dev, pm_runtime_get_sync FAILED %d \n,status);
If I don't mistake, scripts/checkpatch.pl should warn about
unneeded spaces before '\n'. And also about missing spaces after
commas.
I fixed in my branch, thanks
Thanks Felipe,
Anyways resent the patch.
--
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: Occasional crashes in suspend-resume with MMC transactions
On Thu, Mar 22, 2012 at 6:50 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Thu, Mar 22, 2012 at 09:53:23, Bedia, Vaibhav wrote: Hi, I am trying to do suspend-resume test with a file copy on MMC/SD going on in the background. The test involves simply copying a 450MB file on an ext3 partition to the same partition under a different name. This is on an AM335x board which uses the omap_hsmmc driver. The kernel is v3.2 and I have also applied the following patch [...] I found that whenever this issue crops up, mmc_host_suspend() is not able to claim the host And returns -EBUSY. omap_hsmmc driver does not pass on this error code to the PM core and hence the suspend process continues. When the driver is made to return -EBUSY, the suspend process gets aborted and the user can try suspending again. I am not sure whether this sort of suspend failure is acceptable or the driver is doing something wrong. The following workaround is what I came up with. Do this look a reasonable thing to do? --- From a4040dd1869b351a5fa29dacd08facf6e24df609 Mon Sep 17 00:00:00 2001 From: Vaibhav Bedia vaibhav.be...@ti.com Date: Thu, 22 Mar 2012 17:14:49 +0530 Subject: [PATCH 1/1] mmc: omap_hsmmc: Pass on the suspend failure to the PM core In some cases mmc_host_suspend() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 3d8dbbb..1f938d9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2238,6 +2238,7 @@ static int omap_hsmmc_suspend(struct device *dev) dev_dbg(mmc_dev(host-mmc), Unmask interrupt failed\n); } + ret = -EBUSY; goto err; } -- 1.7.0.4 I see (in 3.3) that the host controller driver does a return ret and that means the errors is propagated. Where is the return code lost /overridden ? -- 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 RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
On Thu, Mar 22, 2012 at 04:05:45PM +0530, Kishon Vijay Abraham I wrote: Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619 snip formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter -- 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: Occasional crashes in suspend-resume with MMC transactions
On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
[...]
I see (in 3.3) that the host controller driver does a return ret and
that means the errors is propagated.
Where is the return code lost /overridden ?
The return code gets overridden due to the call to host-pdata-resume()
which always returns 0.
static int omap_hsmmc_resume_cdirq(struct device *dev, int slot)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
enable_irq(mmc-slots[0].card_detect_irq);
return 0;
}
Regards,
Vaibhav
--
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: [GIT PULL] OMAP DSS for v3.4
Arnd, On 03/19/2012 04:24 PM, Arnd Bergmann wrote: I've looked at the specific conflicts again, and it seems that the only conflicting commit in arm-soc is 2e3ee9f45b ARM: OMAP1: Move most of plat/io.h into local iomap.h. I'm planning to send that one very early, as soon as Russell has his first set up patches merged, so I don't actually have to resolve the conflict here unless Florian is also there early. just for your info, I am going to send my pull request today. As I didn't find any pull request from you until now, I didn't pull any of the branches below. Best regards, Florian Tobias Schandinat Florian, if I end up being faster than you, feel free to pull the omap/cleanup branch from git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git if you want to get a conflict resolution using the minimum set of patches from upstream. Alternatively, pulling cleanup from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap should give you the same. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-fbdev 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: [GIT PULL] OMAP DSS for v3.4
On Thursday 22 March 2012, Florian Tobias Schandinat wrote: On 03/19/2012 04:24 PM, Arnd Bergmann wrote: I've looked at the specific conflicts again, and it seems that the only conflicting commit in arm-soc is 2e3ee9f45b ARM: OMAP1: Move most of plat/io.h into local iomap.h. I'm planning to send that one very early, as soon as Russell has his first set up patches merged, so I don't actually have to resolve the conflict here unless Florian is also there early. just for your info, I am going to send my pull request today. As I didn't find any pull request from you until now, I didn't pull any of the branches below. Ok, thanks for the notification. I'm still waiting for Russell to go first, so I'll pull in your branch. Arnd -- 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: Occasional crashes in suspend-resume with MMC transactions
On Thu, Mar 22, 2012 at 8:13 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
[...]
I see (in 3.3) that the host controller driver does a return ret and
that means the errors is propagated.
Where is the return code lost /overridden ?
The return code gets overridden due to the call to host-pdata-resume()
which always returns 0.
Thanks - I see what you mean. But the patch is clunky.
A clean fix would be to not capture the return code of resume() in
ret and let the old
value of ret be propagated as is.
static int omap_hsmmc_resume_cdirq(struct device *dev, int slot)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
enable_irq(mmc-slots[0].card_detect_irq);
return 0;
}
Regards,
Vaibhav
--
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] ARM: OMAP: Add support for AM35xx UART4/ttyO3
On 18/10/2011 20:47, Kyle Manna wrote: Add hwmod support to enable access to UART4 of the AM35xx series of chips. The UART4 device referenced from the TRM will show up as ttyO3. This was tested on an AM3505. Signed-off-by: Kyle Manna kyle.ma...@fuel7.com --- Hi Kyle, arch/arm/mach-omap2/clock3xxx_data.c | 11 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 52 arch/arm/mach-omap2/prcm-common.h |2 + arch/arm/plat-omap/include/plat/irqs.h |2 +- arch/arm/plat-omap/include/plat/serial.h |1 + 5 files changed, 67 insertions(+), 1 deletions(-) Can I gently ask you which pinmux setup do you use to test your patch ? I am trying to make uart4 working on a am3517 with mainline kernel (3.3+, your patch is merged). However, on my board the uart4 pins are shared with the camera, and not with SD, as maybe is more common. I set the pinmux to switch the pins (gpio_95 / gpio_96 / gpio_97 /gpio_98) to the uart4, and ttyO3 is registered and available, and thanks your patch both clocks iclk and fclk are active. However, I cannot see activity on the tx line if I try to send some characters. Maybe do you use the same pinmux and am I forgetting something else ? Thanks, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 RESEND 0/7] gpio/omap: Some more driver fixes
Grant Likely grant.lik...@secretlab.ca writes: On Tue, 20 Mar 2012 10:46:57 -0700, Kevin Hilman khil...@ti.com wrote: Hi Grant, Grant Likely grant.lik...@secretlab.ca writes: On Tue, 20 Mar 2012 16:23:12 +0530, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: This series excludes the cleanup patches as suggested by Kevin from the previously posted series. The fixes include correction of _set_gpio_irqenable() implementation, missing wakeup_en register update in set_gpio_wakeup(), type mismatch of gpio trigger parameter in set_gpio_trigger(), incorrect dataout register update in set_gpio_dataout_() and few corrections in context save logic. It is baselined on top of: git://git.secretlab.ca/git/linux-2.6.git gpio/next Commit: 81b279d80a63628e580c71a31d30a8c3b3047ad4 Series is available here for reference: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_more_fixes Merged; thanks Can you hold off slightly before merging this. I haven't been through v4 yet or tested the fixes alone now that they're separated from the other cleanups. Expect a pull request from me when ready. Okay. It's in linux-next at the moment, but I'll pull it back out. Thanks. I've been through this series now, pull request coming shortly. Hopefully it can still make it for v3.4 since this fixes some regressions introduced by the previous series. :( 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: [PATCH] ARM: OMAP: Add support for AM35xx UART4/ttyO3
On 22/03/2012 18:00, Kyle Manna wrote: My pin mux is configured in u-boot and is as follows: /* CCDC_FIELD: gpio_95, uP-TXD4 */ \ MUX_VAL(CP(CCDC_FIELD), (IDIS | PTD | DIS | M2)) \ /* CCDC_HD: gpio_96, uP-RTS4# */ \ MUX_VAL(CP(CCDC_HD),(IDIS | PTD | DIS | M2)) \ /* CCDC_VD: gpio_97, uP-CTS4# */ \ MUX_VAL(CP(CCDC_VD),(IEN | PTD | EN | M2)) \ /* CCDC_WEN: gpio_98, uP-RXD4 */ \ MUX_VAL(CP(CCDC_WEN), (IEN | PTD | DIS | M2)) \ Well, we are using the same pins ! I've just validated my AM3505 board does in fact toggle the TX line and writes valid data. The running kernel is based on a linux-omap-3.1 and was the source for that patch. Since it sounds like you have the same pinmux, perhaps something changed elsewhere in the kernel? Maybe, but registers looks good - and tracing the serial driver I have not seen anything wrong. Have you tried validating that your hardware can toggle the pin as a GPIO first to eliminate any possibility of shorts? I will do it now. Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = -- 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] ARM: OMAP: Add support for AM35xx UART4/ttyO3
On 03/22/2012 11:03 AM, Stefano Babic wrote: On 18/10/2011 20:47, Kyle Manna wrote: Add hwmod support to enable access to UART4 of the AM35xx series of chips. The UART4 device referenced from the TRM will show up as ttyO3. This was tested on an AM3505. Signed-off-by: Kyle Mannakyle.ma...@fuel7.com --- Hi Kyle, arch/arm/mach-omap2/clock3xxx_data.c | 11 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 52 arch/arm/mach-omap2/prcm-common.h |2 + arch/arm/plat-omap/include/plat/irqs.h |2 +- arch/arm/plat-omap/include/plat/serial.h |1 + 5 files changed, 67 insertions(+), 1 deletions(-) Can I gently ask you which pinmux setup do you use to test your patch ? I am trying to make uart4 working on a am3517 with mainline kernel (3.3+, your patch is merged). However, on my board the uart4 pins are shared with the camera, and not with SD, as maybe is more common. I set the pinmux to switch the pins (gpio_95 / gpio_96 / gpio_97 /gpio_98) to the uart4, and ttyO3 is registered and available, and thanks your patch both clocks iclk and fclk are active. However, I cannot see activity on the tx line if I try to send some characters. Maybe do you use the same pinmux and am I forgetting something else ? My pin mux is configured in u-boot and is as follows: /* CCDC_FIELD: gpio_95, uP-TXD4 */ \ MUX_VAL(CP(CCDC_FIELD), (IDIS | PTD | DIS | M2)) \ /* CCDC_HD: gpio_96, uP-RTS4# */ \ MUX_VAL(CP(CCDC_HD),(IDIS | PTD | DIS | M2)) \ /* CCDC_VD: gpio_97, uP-CTS4# */ \ MUX_VAL(CP(CCDC_VD),(IEN | PTD | EN | M2)) \ /* CCDC_WEN: gpio_98, uP-RXD4 */ \ MUX_VAL(CP(CCDC_WEN), (IEN | PTD | DIS | M2)) \ I've just validated my AM3505 board does in fact toggle the TX line and writes valid data. The running kernel is based on a linux-omap-3.1 and was the source for that patch. Since it sounds like you have the same pinmux, perhaps something changed elsewhere in the kernel? Have you tried validating that your hardware can toggle the pin as a GPIO first to eliminate any possibility of shorts? - Kyle -- 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: Suspend broken on 3.3?
Joe Woodward j...@terrafix.co.uk writes: Is system suspend broken on stock 3.3? I hope not. :) It *should* work, I'm using it regularily here, and it works for me (I'm sure that's just what you want to hear.) :) I have a working stock 3.2 (with patches to fix runtime_pm for DSS2), and system suspend works just fine! This is running on a variety of GUMSTIX boards (both OMAP3530 and AM3703-based). I currently only have a 3530-based Gumstix Overo (although a AM3xxx-based one is on the way, thanks Gumstix!), but it's working fine for me on my Overo. Stock v3.3 won't boot on Overo because of the smsc911x regulator issues recently discusssed, so if you're using Overo, you also need the patch in Tony's fix-smsc911x-regulator branch. After that, suspend/resume is working fine for me using omap2plus_defconfig. I tried both with initramfs and with MMC rootfs. Can you try without your board file changes, using vanilla v3.3 + smsc911x fix above and using omap2plus_defconfig? Also, please share the kernel command-line you're using. Thanks, 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: [PATCH RFC v2] usb: musb: omap: fix the error check for pm_runtime_get_sync
Shubhrajyoti D shubhrajy...@ti.com writes:
pm_runtime_get_sync returns a signed integer.In case of errors
it returns a negative value.This patch fixes the error check
by making it signed instead of unsigned thus preventing register
access if get_sync_fails. Also passes the error cause to the
debug message.
Cc : Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Compile tested only
drivers/usb/musb/omap2430.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2ae0bb3..e5dd18f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -282,7 +282,8 @@ static void musb_otg_notifier_work(struct work_struct
*data_notifier_work)
static int omap2430_musb_init(struct musb *musb)
{
- u32 l, status = 0;
+ u32 l;
+ int status = 0;
nit: you might as well drop the '= 0' assignment since it's not needed.
Otherwise, looks right to me.
Acked-by: Kevin Hilman khil...@ti.com
Kevin
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *plat = dev-platform_data;
struct omap_musb_board_data *data = plat-board_data;
@@ -301,7 +302,7 @@ static int omap2430_musb_init(struct musb *musb)
status = pm_runtime_get_sync(dev);
if (status 0) {
- dev_err(dev, pm_runtime_get_sync FAILED);
+ dev_err(dev, pm_runtime_get_sync FAILED %d\n, status);
goto err1;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/13] Add dummy smsc911x regulators to zoom-debugboard.
On Thu, Mar 22, 2012 at 4:37 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Wed, Mar 21, 2012 at 10:19:54PM -0700, Russ Dill wrote:
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
Why do none of these boards use -1 as the ID for the device?
Commit 21b42731 (omap: convert boards that use SMSC911x to use
gpmc-smsc911x) changed several board files to use the gpmc-smsc911x.c
common code rather than register the device themselves, in the process
it changed many of the id's from -1 to 0. This happened in the 3.0
merge window. I can certainly change it back.
--
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 04/13] Remove non-existent parameter from fixed-helper.c kernel doc.
On Thu, Mar 22, 2012 at 4:36 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Mar 21, 2012 at 10:19:45PM -0700, Russ Dill wrote: Signed-off-by: Russ Dill russ.d...@ti.com I'll apply this once -rc1 comes out, it's totally orthogonal to the rest of the series. I'll drop it from the patch series on the next resend then. -- 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 0/7] OMAP4 cpuidle cleanup
Daniel Lezcano daniel.lezc...@linaro.org writes:
On 03/21/2012 10:54 PM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
On 03/21/2012 02:43 PM, Jean Pihet wrote:
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
This patchset is a proposition to improve a bit the code.
The changes are code cleanup and does not change the behavior of the
driver itself.
A couple a things call my intention. Why the cpuidle device is set for
cpu0 only
and why the WFI is not used ?
Daniel Lezcano (7):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle - Declare the states with the driver declaration
ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot
time
The series looks fine to me in general. This clean-up is applicable
for OMAP3 cpuidle code as well.
Great!
However OMAP3 has a few specific things that cannot be removed as easily:
- the 'valid' flag is used because only certain combinations of power
domains states are possible,
When I look the board-rx51 code I see:
static struct cpuidle_params rx51_cpuidle_params[] = {
/* C1 */
{110 + 162, 5 , 1},
/* C2 */
{106 + 180, 309, 1},
/* C3 */
{107 + 410, 46057, 0},
/* C4 */
{121 + 3374, 46057, 0},
/* C5 */
{855 + 1146, 46057, 1},
/* C6 */
{7580 + 4134, 484329, 0},
/* C7 */
{7505 + 15274, 484329, 1},
};
If C3, C4, C6 are not valid, so AFAICS never used in the cpuidle code
why the values are 'exit_latency' and 'target_residency' specified ? I
mean why don't we have { 0, 0, 0 } ? Is it just for information ?
Yes, because getting those numbers were based on some board-specific
measurements, and we don't want those values to be lost. Also, some
usage patterns might want to (re)enable those states.
When you say re-enable you mean for a custom kernel ?
Yes.
I understand the purpose of this code but it looks a bit tricky and
hard to factor out. Is it acceptable to create a new cpuidle driver
for rx51 then we factor out the code between omap3, omap4 and rx51
when all the code consistent ?
I don't like that idea. All the code is the same, the only thing we
need is the ability to pass in board-specific latency numbers for the
C-states.
Sorry I was not clear, I was not saying duplicating the code. What I
meant is to create a driver:
struct cpuidle_driver rx51_idle_driver = {
.name = rx51_idle,
.owner =THIS_MODULE,
.states = {
{
/* What is in rx51_cpuidle_params */
}
};
We put in there only the valid fields and we keep in a comment the
table with the latency numbers.
Ah, OK. I misunderstood.
Assuming the valid field is for handling the table overwritting, we
can then remove it. By this way, we simplify the next_valid_state
function.
probably we can remove next_valid_state all together after 3.4 since the
new sysfs entry for that feature looks to be queued in linux-next.
Depending if we have rx51 or not, we register the rx51 driver or the
omap3 driver in the init function. That has also the benefit to group
the cpuidle code in the cpuidle34xx file.
yes, but with board-specific data in SoC-specific code, which is not a
clean separation IMO. How would you plan to pass which board it's
running on?
These latency numbers are obviously quite significant when it comes to
the final power consumption, and these values often depend on
board-specific settings. Until there are generic frameworks for
defining all the latencies involved, passing these values in from board
files is absolutly needed.
Yes but before creating the generic framework, we have to do a
transversal cpuidle consolidation across the SoC, factor out the code
when possible, and ensure the consistency between the different
platform and see a common pattern to emerge from this work.
Agreed, but if that means ignoring platform-specific customization, and
not putting in other mechanisms to configure platform specific details,
it is throwing away useful infrastructure.
IMO, any consolidated framework needs some way to customize or pass in
latencies from platform-specific code. Long term, I suppose this needs
to be DT based.
That being said, I do want to see this consolidation happen, so...
In OMAP land, we are in the middle of putting in place a better
framework for defining/tracking the various latencies involved in PM
transitions (using per-device PM Qos.) After that, we will likely be
reworking and revalidating these latency numbers for all
[GIT PULL] gpio/omap: more fixes for v3.4
Hi Grant, Please pull these OMAP GPIO fixes for v3.4. These fix some rather serious regressions introduced by the cleanup and runtime PM conversion series which is also queued for v3.4. This branch is based on your gpio/next branch. This version is functionally the same as the version you previously merged (and I asked you to back it out), but this version has some better changlogs, and I added reviewed-by and s-o-b from me as well. Thanks, Kevin The following changes since commit 81b279d80a63628e580c71a31d30a8c3b3047ad4: gpio/davinci: fix enabling unbanked GPIO IRQs (2012-03-12 11:53:33 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/fixes/gpio-2 for you to fetch changes up to 7fcca715de3438b8fc3c8a144702f3a95c8ff63c: gpio/omap: fix redundant decoding of gpio offset (2012-03-21 10:21:24 +0530) Tarun Kanti DebBarma (7): gpio/omap: fix wakeup_en register update in _set_gpio_wakeup() gpio/omap: fix trigger type to unsigned gpio/omap: fix _set_gpio_irqenable implementation gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_* gpio/omap: fix incorrect update to context.irqenable1 gpio/omap: fix redundant decoding of gpio offset drivers/gpio/gpio-omap.c | 47 -- 1 file changed, 25 insertions(+), 22 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
Re: [PATCH RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
Hi Greg, On Thu, Mar 22, 2012 at 8:03 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Mar 22, 2012 at 04:05:45PM +0530, Kishon Vijay Abraham I wrote: Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619 snip formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter I really couldn't get what I'm missing after reading the Documentation/stable_kernel_rules.txt :-( Can you kindly let me know what I'm missing here? Thanks Kishon -- 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 RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
On Fri, Mar 23, 2012 at 03:04:04AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi Greg, On Thu, Mar 22, 2012 at 8:03 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Mar 22, 2012 at 04:05:45PM +0530, Kishon Vijay Abraham I wrote: Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619 snip formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter I really couldn't get what I'm missing after reading the Documentation/stable_kernel_rules.txt :-( Can you kindly let me know what I'm missing here? Read the version of that file in the 3.3 kernel release, it should explain what you are forgetting (hint, do you really want it applied to the 2.4 kernel tree?) greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
On Fri, Mar 23, 2012 at 03:59:32AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi Greg, On Fri, Mar 23, 2012 at 3:09 AM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Mar 23, 2012 at 03:04:04AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi Greg, On Thu, Mar 22, 2012 at 8:03 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Mar 22, 2012 at 04:05:45PM +0530, Kishon Vijay Abraham I wrote: Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619 snip formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter I really couldn't get what I'm missing after reading the Documentation/stable_kernel_rules.txt :-( Can you kindly let me know what I'm missing here? Read the version of that file in the 3.3 kernel release, it should explain what you are forgetting (hint, do you really want it applied to the 2.4 kernel tree?) I actually intended this patch to be back-ported to previous releases which will have the issue. I'm not sure if it is right? And what releases are those? Hint, you need to tell us exactly what trees you want your patch applied to, otherwise we will just guess, and usually, incorrectly. Be specific. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] usb: musb: omap: fix crash when musb glue (omap) gets initialized
Hi Greg, On Fri, Mar 23, 2012 at 3:09 AM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Mar 23, 2012 at 03:04:04AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi Greg, On Thu, Mar 22, 2012 at 8:03 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Mar 22, 2012 at 04:05:45PM +0530, Kishon Vijay Abraham I wrote: Upstream Commit: 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 Upstream Kernel Tag: v2.6.38-rc5-94-g7acc619 snip formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter I really couldn't get what I'm missing after reading the Documentation/stable_kernel_rules.txt :-( Can you kindly let me know what I'm missing here? Read the version of that file in the 3.3 kernel release, it should explain what you are forgetting (hint, do you really want it applied to the 2.4 kernel tree?) I actually intended this patch to be back-ported to previous releases which will have the issue. I'm not sure if it is right? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 RESEND 6/7] gpio/omap: fix incorrect update to context.irqenable1
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
In _enable_gpio_irqbank() when bank-regs-set_irqenable is TRUE,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must avoid overwriting it with
gpio_mask at the end of the function. Instead, update irqenable1
appropriately by OR'ing with gpio_mask.
For the case where bank-regs-set_irqenable is FALSE, irqenable1
can be directly overwritten with 'l' which holds correct computed
value.
if (bank-regs-set_irqenable) {
reg += bank-regs-set_irqenable;
l = gpio_mask;
} else {
reg += bank-regs-irqenable;
l = __raw_readl(reg);
if (bank-regs-irqenable_inv)
l = ~gpio_mask;
else
l |= gpio_mask;
}
Make similar change for _disable_gpio_irqbank().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Updated change log as per Kevin's suggestion.
Thanks for the update. I've queued the updated version of this series,
and sent pull request to Grant.
Thanks Tarun,
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: [PATCH] ARM: OMAP3+: fix oops triggered in omap_prcm_register_chain_handler(v1)
Ming Lei tom.leim...@gmail.com writes: This patch fixes the oops below[1]. Obviously, the count of struct irq_chip_generic instances to be allocated and setup should be irq_setup-nr_regs instead of irq_setup-nr_regs plus one, so just fix the iterator to avoid the oops. [...] --- v1: -add a bit more description to the changelog as suggested by Tero and Kevin. Thanks for the updated version. Queuing as a fix for v3.4-rc (branch: for_3.4/fixes/pm) 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: [PATCH 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
Hi On Thu, 22 Mar 2012, Raja, Govindraj wrote: Sorry I for got to add that, here are details on what was tested. 1.) OMAP2430 SDP : Boot tested with uart1 as console. 2.) OMAP3430 SDP: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 3.) OMAP3630 - Beagle XM: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 4.) OMAP4430 - PANDA: Boot test, suspend/resume tests 5.) OMAP4460 - PANDA: Boot test. What kernel .config was used for these tests? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
