Re: [PATCH] omap_hsmmc: Fix for the db clock failure message
Madhusudhan Chikkature wrote:
This patch applies on top of the series [PATCH V2 0/32] mmc and omap_hsmmc
patches posted by Adrian Hunter.
-
This patch removes the error message Failed to get debounce clock.. printed
out by the HSMMC driver on OMAP3430. The debounce clock needs to be handled only
for OMAP2430.
I have a suggestion that may make it tidier.
What about renaming host-dbclk_enabled to host-got_dbclk and leaving it alone
after it is set in the probe function. Then create a macro to use in
conditions:
#define have_dbclk(host) (cpu_is_omap2430() (host)-got_dbclk)
So the following:
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
becomes:
- if (host-dbclk_enabled)
+ if (have_dbclk(host))
clk_disable(host-dbclk);
Or alternatively, forget the macro, and let the code always compile in:
- if (host-dbclk_enabled)
+ if (host-got_dbclk)
clk_disable(host-dbclk);
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 63 +++---
1 file changed, 41 insertions(+), 22 deletions(-)
Index: linux-2.6/drivers/mmc/host/omap_hsmmc.c
===
--- linux-2.6.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-2.6/drivers/mmc/host/omap_hsmmc.c
@@ -735,8 +735,10 @@ static int omap_hsmmc_switch_opcond(stru
/* Disable the clocks */
clk_disable(host-fclk);
clk_disable(host-iclk);
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
/* Turn the power off */
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
@@ -746,9 +748,14 @@ static int omap_hsmmc_switch_opcond(stru
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 1,
vdd);
clk_enable(host-iclk);
- if (host-dbclk_enabled)
- clk_enable(host-dbclk);
clk_enable(host-fclk);
+ if (cpu_is_omap2430() !host-dbclk_enabled) {
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling debounce
+clk failed\n);
+ else
+ host-dbclk_enabled = 1;
+ }
if (ret != 0)
goto err;
@@ -1697,18 +1704,21 @@ static int __init omap_hsmmc_probe(struc
goto err1;
}
- host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
- /*
-* MMC can still work without debounce clock.
-*/
- if (IS_ERR(host-dbclk))
- dev_warn(mmc_dev(host-mmc), Failed to get debounce clock\n);
- else
- if (clk_enable(host-dbclk) != 0)
- dev_dbg(mmc_dev(host-mmc), Enabling debounce
-clk failed\n);
+ if (cpu_is_omap2430()) {
+ host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
+ /*
+* MMC can still work without debounce clock.
+*/
+ if (IS_ERR(host-dbclk))
+ dev_warn(mmc_dev(host-mmc),
+ Failed to get debounce clock\n);
else
- host-dbclk_enabled = 1;
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling debounce
+clk failed\n);
+ else
+ host-dbclk_enabled = 1;
+ }
/* Since we do only SG emulation, we can have as many segs
* as we want. */
@@ -1825,8 +1835,9 @@ err_irq:
clk_disable(host-iclk);
clk_put(host-fclk);
clk_put(host-iclk);
- if (host-dbclk_enabled) {
- clk_disable(host-dbclk);
+ if (cpu_is_omap2430()) {
+ if (host-dbclk_enabled)
+ clk_disable(host-dbclk);
clk_put(host-dbclk);
}
@@ -1859,8 +1870,9 @@ static int omap_hsmmc_remove(struct plat
clk_disable(host-iclk);
clk_put(host-fclk);
clk_put(host-iclk);
- if (host-dbclk_enabled) {
- clk_disable(host-dbclk);
+ if (cpu_is_omap2430()) {
+ if (host-dbclk_enabled)
+ clk_disable(host-dbclk);
clk_put(host-dbclk);
}
@@ -1910,8 +1922,10 @@ static int omap_hsmmc_suspend(struct pla
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
Re: [PATCH 3/3] i2c-omap: Enable workaround for Errata 1.153 based on
On Mon, 17 Aug 2009, Moiz Sonasath wrote:
Silicon Errata 1.153 has been fixed on OMAP 3630|4430 with the use of a later
version of I2C IP block.
The errata impacts OMAP 2420|2430|3430, enable the workaround for these based
on I2C IP block revision number instead of OMAP CPU type
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Reviewed-by: Paul Walmsley p...@pwsan.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 16b39f4..827da08 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -784,7 +784,7 @@ complete:
* memory to the I2C interface.
*/
- if (cpu_is_omap34xx()) {
+ if (dev-rev = OMAP_I2C_REV_ON_3430) {
while (!(stat
OMAP_I2C_STAT_XUDF)) {
if (stat
(OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Wang Limei-E12499 e12...@motorola.com writes:
Seems like I did not submit the patch in the right way, before I setup
my mail correctly, attach the patches in the mail.
You're patches are still line-wrapped.
I strongly recommend using git-format-patch and git-send-email to
submit patches. Chunqiu was able to do this. Please consult him.
Also, no need to CC linux-omap-owner. linux-omap is all that is needed.
Thanks,
Kevin
PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch
From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Fri, 14 Aug 2009 17:34:32 +0800
Subject: [PATCH] Add per-resource mutex for OMAP resource framework
Current OMAP resource fwk uses a global res_mutex
for resource_request and resource_release calls
for all the available resources.It may cause dead
lock if resource_request/resource_release is called
recursively.
For current OMAP3 VDD1/VDD2 resource, the change_level
implementation is mach-omap2/resource34xx.c/set_opp(),
when using resource_release to remove vdd1 constraint,
this function may call resource_release again to release
Vdd2 constrait if target vdd1 level is less than OPP3.
in this scenario, the global res_mutex down operation
will be called again, this will cause the second
down operation hang there.
To fix the problem, per-resource mutex is added
to avoid hangup when resource_request/resource_release
is called recursively.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h |2 ++
arch/arm/plat-omap/resource.c | 27
+++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..d482fb8 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -46,6 +46,8 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ /* Protect each resource */
+ struct mutex resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..5eae4e8 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ mutex_init(resp-resource_mutex);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
*dev,
user-level = level;
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
/*
* Recompute and set the current level for the resource.
* NOTE: update_resource level moved out of spin_lock, as it may
call
@@ -371,6 +372,7 @@ res_unlock:
*/
if (!ret)
ret = update_resource_level(resp);
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +395,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +423,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_release);
@@ -438,15 +442,14 @@ int resource_get_level(const char *name)
struct shared_resource *resp;
u32 ret;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp =
Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Wang Limei-E12499 e12...@motorola.com writes:
Seems like I did not submit the patch in the right way, before I setup
my mail correctly, attach the patches in the mail.
You're patches are still line-wrapped.
I strongly recommend using git-format-patch and git-send-email to
submit patches. Chunqiu was able to do this. Please consult him.
Also, no need to CC linux-omap-owner. linux-omap is all that is needed.
Thanks,
Kevin
PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch
From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Fri, 14 Aug 2009 17:34:32 +0800
Subject: [PATCH] Add per-resource mutex for OMAP resource framework
Current OMAP resource fwk uses a global res_mutex
for resource_request and resource_release calls
for all the available resources.It may cause dead
lock if resource_request/resource_release is called
recursively.
For current OMAP3 VDD1/VDD2 resource, the change_level
implementation is mach-omap2/resource34xx.c/set_opp(),
when using resource_release to remove vdd1 constraint,
this function may call resource_release again to release
Vdd2 constrait if target vdd1 level is less than OPP3.
in this scenario, the global res_mutex down operation
will be called again, this will cause the second
down operation hang there.
To fix the problem, per-resource mutex is added
to avoid hangup when resource_request/resource_release
is called recursively.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h |2 ++
arch/arm/plat-omap/resource.c | 27
+++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..d482fb8 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -46,6 +46,8 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ /* Protect each resource */
+ struct mutex resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..5eae4e8 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ mutex_init(resp-resource_mutex);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
*dev,
user-level = level;
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
/*
* Recompute and set the current level for the resource.
* NOTE: update_resource level moved out of spin_lock, as it may
call
@@ -371,6 +372,7 @@ res_unlock:
*/
if (!ret)
ret = update_resource_level(resp);
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +395,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +423,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_release);
@@ -438,15 +442,14 @@ int resource_get_level(const char *name)
struct shared_resource *resp;
u32 ret;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp =
Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Wang Limei-E12499 e12...@motorola.com writes:
Seems like I did not submit the patch in the right way, before I setup
my mail correctly, attach the patches in the mail.
You're patches are still line-wrapped.
I strongly recommend using git-format-patch and git-send-email to
submit patches. Chunqiu was able to do this. Please consult him.
Also, no need to CC linux-omap-owner. linux-omap is all that is needed.
Thanks,
Kevin
PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch
From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Fri, 14 Aug 2009 17:34:32 +0800
Subject: [PATCH] Add per-resource mutex for OMAP resource framework
Current OMAP resource fwk uses a global res_mutex
for resource_request and resource_release calls
for all the available resources.It may cause dead
lock if resource_request/resource_release is called
recursively.
For current OMAP3 VDD1/VDD2 resource, the change_level
implementation is mach-omap2/resource34xx.c/set_opp(),
when using resource_release to remove vdd1 constraint,
this function may call resource_release again to release
Vdd2 constrait if target vdd1 level is less than OPP3.
in this scenario, the global res_mutex down operation
will be called again, this will cause the second
down operation hang there.
To fix the problem, per-resource mutex is added
to avoid hangup when resource_request/resource_release
is called recursively.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h |2 ++
arch/arm/plat-omap/resource.c | 27
+++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..d482fb8 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -46,6 +46,8 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ /* Protect each resource */
+ struct mutex resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..5eae4e8 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ mutex_init(resp-resource_mutex);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
*dev,
user-level = level;
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
/*
* Recompute and set the current level for the resource.
* NOTE: update_resource level moved out of spin_lock, as it may
call
@@ -371,6 +372,7 @@ res_unlock:
*/
if (!ret)
ret = update_resource_level(resp);
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +395,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +423,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_release);
@@ -438,15 +442,14 @@ int resource_get_level(const char *name)
struct shared_resource *resp;
u32 ret;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp =
Re: MUSB regression in 2.6.31-rc6
On Mon, 17 Aug 2009 17:27:09 -0400 (GMT-04:00) ewitcher ewitc...@mindspring.com wrote: Hello, The below referenced patch was helpful to me in resolving the 3twl4030_usb twl4030_usb: ldo init failed error. Examining the minicom.cap attachment, I can see that twl4030_usb is initialized before regulator. If you move the twl4030_usb initialization to after regulator, you should be ok. [PATCH] USB:otg:twl4030-usb.c: mark .init as subsys_initcall_sync http://marc.info/?l=linux-usbm=124913041802639w=2 Thanks! That patch and Felipe's patch to board-omap3beagle.c made it booting. http://marc.info/?l=linux-arm-kernelm=125007992121335w=2 However, I'm not able to get a bit going but at least now one is able to debug it. There is only this unexpected notification 03! seen on pc side when the cable is plugged in. Beagle: g_ether gadget: high speed config #1: CDC Ethernet (ECM) PC: usb0: register 'cdc_ether' at usb-:00:1d.7-1, CDC Ethernet Device, a6:9c:9f:d0:8a:65 usb0: CDC: unexpected notification 03! -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [090814 21:11]: Jon Hunter jon-hun...@ti.com writes: Kevin Hilman wrote: Jon, you're raising the bar and spoiling us with such descriptive changelogs. If everyone was as thorough as you, the world would be a merrier place. :) Thanks, pushing to PM branch and pm-2.6.29. Kevin No problem. You are welcome. Just an FYI, but for 2.6.29, I was doing some testing this morning and I found that I needed to make the following change to the patch to make it work for 2.6.29. You are probably aware already as this makes the patch similar to your original patch for mmc-reset. - dev_set_name(dev, musb_hdrc); - otg_clk = clk_get(dev, ick); + otg_clk = clk_get(dev, hsotgusb_ick); Ah yes, I thought of that when I first saw the patch but forgot to do that on pm-2.6.29. Thanks, pushing to pm-2.6.29. Where's the dependency with this patch to the PM branch? If there is a dependency, can it be removed for mainline? To me it looks like we should send a patch against the mainline tree via linux-usb list. No, this is a temporary patch until OTG support is added to omap_hwmod. 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: [PATCHv2] OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [090814 21:11]: Jon Hunter jon-hun...@ti.com writes: Kevin Hilman wrote: Jon, you're raising the bar and spoiling us with such descriptive changelogs. If everyone was as thorough as you, the world would be a merrier place. :) Thanks, pushing to PM branch and pm-2.6.29. Kevin No problem. You are welcome. Just an FYI, but for 2.6.29, I was doing some testing this morning and I found that I needed to make the following change to the patch to make it work for 2.6.29. You are probably aware already as this makes the patch similar to your original patch for mmc-reset. - dev_set_name(dev, musb_hdrc); - otg_clk = clk_get(dev, ick); + otg_clk = clk_get(dev, hsotgusb_ick); Ah yes, I thought of that when I first saw the patch but forgot to do that on pm-2.6.29. Thanks, pushing to pm-2.6.29. Where's the dependency with this patch to the PM branch? If there is a dependency, can it be removed for mainline? To me it looks like we should send a patch against the mainline tree via linux-usb list. No, this is a temporary patch until OTG support is added to omap_hwmod. 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][PM] ARM: OMAP34xx: Fix compilation warning
Aguirre Rodriguez, Sergio Alberto saagui...@ti.com writes: From: Sergio Aguirre saagui...@ti.com This fixes the following compilation warnings: In file included from arch/arm/mach-omap2/resource34xx.c:26: arch/arm/mach-omap2/resource34xx.h:32: warning: function declaration isn't a prototype arch/arm/mach-omap2/resource34xx.h:33: warning: function declaration isn't a prototype Signed-off-by: Sergio Aguirre saagui...@ti.com Thanks, will pull into PM branch and fold into original patch which introduced these functions. Kevin --- arch/arm/mach-omap2/resource34xx.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.h b/arch/arm/mach-omap2/resource34xx.h index 5b5618a..3c70eef 100644 --- a/arch/arm/mach-omap2/resource34xx.h +++ b/arch/arm/mach-omap2/resource34xx.h @@ -29,8 +29,8 @@ #include mach/omap34xx.h extern int sr_voltagescale_vcbypass(u32 t_opp, u32 c_opp, u8 t_vsel, u8 c_vsel); -extern void lock_scratchpad_sem(); -extern void unlock_scratchpad_sem(); +extern void lock_scratchpad_sem(void); +extern void unlock_scratchpad_sem(void); /* * mpu_latency/core_latency are used to control the cpuidle C state. -- 1.6.3.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
[PATCH] OMAP: Fix incorrect 730 vs 850 detection (Re: [PATCH] Fix mismatched ifdefs)
* Premi, Sanjeev pr...@ti.com [090817 17:56]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, August 17, 2009 8:15 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] Fix mismatched ifdefs * Sanjeev Premi pr...@ti.com [090817 13:59]: The #endif at end of the file was missing. However, an additional #else ... #endif was causing the compiler to keep going. The problem was found when compiler started reporting the newly added inline functions were being reported as redeclared by the compiler. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 11e73d9..4fbc6a9 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -317,8 +317,6 @@ IS_OMAP_TYPE(3430, 0x3430) # undef cpu_is_omap730 # define cpu_is_omap730() 1 # endif -#endif -#else Hmm, to me it looks like this should remove the second #endif, but keep the #else for the !MULTI_OMAP1 configurations. [sp] I did the maching as annotated in the snippet below: #if defined(MULTI_OMAP1) # if defined(CONFIG_ARCH_OMAP730) # undef cpu_is_omap730 # define cpu_is_omap730()is_omap730() # endif # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850()is_omap850() # endif #else /* sp - else for multi-omap1 */ # if defined(CONFIG_ARCH_OMAP730) # undef cpu_is_omap730 # define cpu_is_omap730()1 # endif #endif #else /* sp - seems like needed in the else path of MULTI_OMAP1 * else the symbol could go undefined. */ # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850()1 # endif #endif # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() 1 @@ -433,3 +431,5 @@ IS_OMAP_TYPE(3430, 0x3430) int omap_chip_is(struct omap_chip_id oci); void omap2_check_revision(void); + +#endif /* __ASM_ARCH_OMAP_CPU_H */ And this should not be needed. [sp] So where does this end: #ifndef __ASM_ARCH_OMAP_CPU_H #define __ASM_ARCH_OMAP_CPU_H I was hitting the problem possibly due to mutiple inclusion of cpu.h Any static inline function declared at bottom of cpu.h gets the errors like: arch/arm/plat-omap/include/mach/cpu.h:465: error: redefinition of 'omap3_has_iva' arch/arm/plat-omap/include/mach/cpu.h:465: error: previous definition of 'omap3_has_iva' was here Here's what I think is the right fix to this, the extra endif got introduced with the 850 patch. Removing that is not the right fix still, we just need to remove the special case for 730 as now we need to detect between 730 and 850. Can please you try the attached patch? Regards, Tony From 751797cca47c9ccb5443190a0f3d82924ee1eaeb Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Tue, 18 Aug 2009 12:57:06 +0300 Subject: [PATCH] OMAP: Fix incorrect 730 vs 850 detection Commit ae302f40 introduced support for omap850 but had a bug in ifdef handling of the non-multi-omap case for 730 and 850. Fix the problem by removing the non-multi-omap special handling, as we need to detect between omap730 and omap850 anyways. Problem reported by Sanjeev Premi pr...@ti.com. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 11e73d9..61dbe90 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -303,32 +303,21 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 -#if defined(MULTI_OMAP1) -# if defined(CONFIG_ARCH_OMAP730) -# undef cpu_is_omap730 -# define cpu_is_omap730() is_omap730() -# endif -# if defined(CONFIG_ARCH_OMAP850) -# undef cpu_is_omap850 -# define cpu_is_omap850() is_omap850() -# endif -#else -# if defined(CONFIG_ARCH_OMAP730) -# undef cpu_is_omap730 -# define cpu_is_omap730() 1 -# endif -#endif -#else -# if defined(CONFIG_ARCH_OMAP850) -# undef cpu_is_omap850 -# define cpu_is_omap850() 1 -# endif -#endif - /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish - * between 330 vs. 1510 and 1611B/5912 vs. 1710. + * between 730 vs 850, 330 vs. 1510 and 1611B/5912 vs. 1710. */ + +#if defined(CONFIG_ARCH_OMAP730) +# undef cpu_is_omap730 +# define cpu_is_omap730() is_omap730() +#endif + +#if defined(CONFIG_ARCH_OMAP850) +# undef cpu_is_omap850 +# define cpu_is_omap850() is_omap850() +#endif + #if defined(CONFIG_ARCH_OMAP15XX) # undef cpu_is_omap310 # undef cpu_is_omap1510
Re: [PATCH]OMAP4: McSPI Support for OMAP4430
David, This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Acked-by: Tony Lindgren t...@atomide.com Acked-by: David Brownell davi...@pacbell.net Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- Haven't seen any comment on my patch, but didn't see it in git either. Is there anything that I need to resolve? Else can this patch get merged. Could you please merge this patch, Since there are no comments. Regards, Syed Rafiuddin -- 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: [RESUBMIT][PATCH-v2][RFC] OMAP4: I2C Support for OMAP4430
Ben, On Fri, Jul 24, 2009 at 04:40:02PM +0530, Syed Rafiuddin wrote: Hi Ben, This patch adds OMAP4 support to the I2C driver. All I2C register addresses are different between OMAP1/2/3 and OMAP4. In order to not have #ifdef's at various places in code, as well as to support multi-OMAP build, Array's are created to hold the register addresses. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com --- No comment received on this patch, Is there anything that I need to resolve? Else can this patch get merged. sorry, been busy, will look at this in the next few days. Seems like no issues with the patch since no comments received from long time. Did you get a chance to look at the patch.Could you please merge this. Regards, Syed Rafiuddin -- 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: [help] 2.6.30 can't booting
On 8/17/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, we use these parameters for NFS booting: setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.95.102.32:/home/filesystems/tifs,nolock,vers=3,rsize=2048,wsize=2048, tcp dyntick=e ip=dhcp nohz=off or without DHCP: setenv bootargs console=ttyS2,115200n8 noinitrd,rw root=/dev/nfs nfsroot=10.95.102.32:/home/filesystems/tifs,nolock, mem=112M nohz=off ip=10.95.102.33:10.95.96.1:10.95.96.1:255.255.240.0:infba00798::off devfs=mount oke i try it in the another mailing list, the problem about different speed bootloader and linux kernel..if that's my problem..how i can fix that?thanks before Regards, Aldyth M and it works. Try it! Peter hmm,,i boot again and kernel panic cannot sync VFS because no respond from my nfs server... but i'm try to mount y nfs directory in the another computer, it's work..i don't know whre is the problem? On 8/16/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, I don't think that it's a problem with the filesystem, if you followed the tutorial then you have the filesystem on the second partition, and your bootargs are pointing there too. Do you have a DHCP server running somewhere? If you have DHCP, but the OMAP cannot use it for some reason, you can still try forcing a static IP instead of DHCPing, like discussed here: http://focus.ti.com/lit/an/spraaq0/spraaq0.pdf That is, add something like ip=clientIP:serverIP:gatewayIP:netMask:::off to your bootargs. More info about the meaning of the above here: http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt Peter thanks peter, i can boot but the kernel stop in the Sending DHCP Requests . 7hub 1-0:1.0 hub_suspend ... how to boot filesystems has installed from mmc?...thanks On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: thanks mr.peter i should try the command like that #nand unlock #nand ecc sw #setenv bootargs 'console=ttyS3,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 mem=256M init=/init' #setenv bootcmd 'mmcinit; fatload mmc 0 0x80c0 uImage; bootm 0x80c0' #saveenv #boot it is stop(like hang) and i must restart again On 8/16/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Dear Aldyth, u-boot stops and waits for your command to load and start the kernel, as the bootcmd is not doing it automatically with your setup (setting bootargs is not enough alone, you need to load the kernel image from the card and run it). You should try: mmcinit fatload mmc 0 8030 uImage bootm 8030 As described at eg: http://www.codeshogun.com/blog/2009/04/15/porting-android-to-beagle-board/ Hope this helps, Peter it is my step to build u-boot, x-loader and kernel i'm try linux 2.6.30 and using the omap3430sdp_defconfig to build the uImage my u-boot and x-loader using omap3430zoom2_config any idea to solve that problem?... regards, Aldyth M On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: i'm format mmc in the fat win95... i following step by step in the https://omapzoom.org/gf/project/omapkernel/wiki/?pagename=Getting+Stated+with+Linux+OMAP+Kernel why can't read? On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: i'm format mmc in the fat win95... i following step by step in the https://omapzoom.org/gf/project/omapkernel/wiki/?pagename=Getting+Stated+with+Linux+OMAP+Kernel why can't read? On 8/16/09, Felipe Balbi m...@felipebalbi.com wrote: Hi, On Sun, Aug 16, 2009 at 12:48:52PM -0400, Tar Gz wrote: Hi all,,i'm sorry if my english too bad i try to porting linux kernel 2.6.30 from kernel.org into omap 3430 i have the problem linux kernel can't booting i'm following step by step in the omapzoom.org $ setenv bootargs console=ttyS3,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 mem=256M init=/sbin/init $ saveenv $ bootd OMAP34XX LAB # print bootdelay=3 baudrate=115200 bootargs=console=ttyS3,115200n8 root=/dev/mmcblk0p2 rootdelay=1 mem=256M init=/sbin/init bootcmd=mmcinit bootfile=uImage if i'm type bootd i'm still in the konsole like this, OMAP34XX LAB # bootd OMAP34XX LAB # any idea? you're not reading the kernel image to memory. is your mmc formated with FAT32 or what ? You need to read kernel from mmc to memory and boot from there. -- 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 -- 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
Re: [help] 2.6.30 can't booting
if i not using nfs...how to mount the another partition in mmc? On 8/18/09, Tar Gz bsdraisefromh...@gmail.com wrote: On 8/17/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, we use these parameters for NFS booting: setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.95.102.32:/home/filesystems/tifs,nolock,vers=3,rsize=2048,wsize=2048, tcp dyntick=e ip=dhcp nohz=off or without DHCP: setenv bootargs console=ttyS2,115200n8 noinitrd,rw root=/dev/nfs nfsroot=10.95.102.32:/home/filesystems/tifs,nolock, mem=112M nohz=off ip=10.95.102.33:10.95.96.1:10.95.96.1:255.255.240.0:infba00798::off devfs=mount oke i try it in the another mailing list, the problem about different speed bootloader and linux kernel..if that's my problem..how i can fix that?thanks before Regards, Aldyth M and it works. Try it! Peter hmm,,i boot again and kernel panic cannot sync VFS because no respond from my nfs server... but i'm try to mount y nfs directory in the another computer, it's work..i don't know whre is the problem? On 8/16/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, I don't think that it's a problem with the filesystem, if you followed the tutorial then you have the filesystem on the second partition, and your bootargs are pointing there too. Do you have a DHCP server running somewhere? If you have DHCP, but the OMAP cannot use it for some reason, you can still try forcing a static IP instead of DHCPing, like discussed here: http://focus.ti.com/lit/an/spraaq0/spraaq0.pdf That is, add something like ip=clientIP:serverIP:gatewayIP:netMask:::off to your bootargs. More info about the meaning of the above here: http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt Peter thanks peter, i can boot but the kernel stop in the Sending DHCP Requests . 7hub 1-0:1.0 hub_suspend ... how to boot filesystems has installed from mmc?...thanks On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: thanks mr.peter i should try the command like that #nand unlock #nand ecc sw #setenv bootargs 'console=ttyS3,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 mem=256M init=/init' #setenv bootcmd 'mmcinit; fatload mmc 0 0x80c0 uImage; bootm 0x80c0' #saveenv #boot it is stop(like hang) and i must restart again On 8/16/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Dear Aldyth, u-boot stops and waits for your command to load and start the kernel, as the bootcmd is not doing it automatically with your setup (setting bootargs is not enough alone, you need to load the kernel image from the card and run it). You should try: mmcinit fatload mmc 0 8030 uImage bootm 8030 As described at eg: http://www.codeshogun.com/blog/2009/04/15/porting-android-to-beagle-board/ Hope this helps, Peter it is my step to build u-boot, x-loader and kernel i'm try linux 2.6.30 and using the omap3430sdp_defconfig to build the uImage my u-boot and x-loader using omap3430zoom2_config any idea to solve that problem?... regards, Aldyth M On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: i'm format mmc in the fat win95... i following step by step in the https://omapzoom.org/gf/project/omapkernel/wiki/?pagename=Getting+Stated+with+Linux+OMAP+Kernel why can't read? On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: i'm format mmc in the fat win95... i following step by step in the https://omapzoom.org/gf/project/omapkernel/wiki/?pagename=Getting+Stated+with+Linux+OMAP+Kernel why can't read? On 8/16/09, Felipe Balbi m...@felipebalbi.com wrote: Hi, On Sun, Aug 16, 2009 at 12:48:52PM -0400, Tar Gz wrote: Hi all,,i'm sorry if my english too bad i try to porting linux kernel 2.6.30 from kernel.org into omap 3430 i have the problem linux kernel can't booting i'm following step by step in the omapzoom.org $ setenv bootargs console=ttyS3,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 mem=256M init=/sbin/init $ saveenv $ bootd OMAP34XX LAB # print bootdelay=3 baudrate=115200 bootargs=console=ttyS3,115200n8 root=/dev/mmcblk0p2 rootdelay=1 mem=256M init=/sbin/init bootcmd=mmcinit bootfile=uImage if i'm type bootd i'm still in the konsole like this, OMAP34XX LAB # bootd OMAP34XX LAB # any idea? you're not reading the kernel image to memory. is your mmc formated with FAT32 or what ? You need to read kernel from mmc to memory and boot from there. -- 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 -- 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
Fwd: [help] 2.6.30 can't booting
-- Forwarded message -- From: Tar Gz bsdraisefromh...@gmail.com Date: Tue, 18 Aug 2009 04:47:21 -0700 Subject: Re: [help] 2.6.30 can't booting To: Kovacs Peter Tamas p.kov...@holografika.com, linux-omap linux-omap@vger.kernel.org On 8/17/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, we use these parameters for NFS booting: setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.95.102.32:/home/filesystems/tifs,nolock,vers=3,rsize=2048,wsize=2048, tcp dyntick=e ip=dhcp nohz=off or without DHCP: setenv bootargs console=ttyS2,115200n8 noinitrd,rw root=/dev/nfs nfsroot=10.95.102.32:/home/filesystems/tifs,nolock, mem=112M nohz=off ip=10.95.102.33:10.95.96.1:10.95.96.1:255.255.240.0:infba00798::off devfs=mount oke i try it in the another mailing list, the problem about different speed bootloader and linux kernel..if that's my problem..how i can fix that?thanks before Regards, Aldyth M and it works. Try it! Peter hmm,,i boot again and kernel panic cannot sync VFS because no respond from my nfs server... but i'm try to mount y nfs directory in the another computer, it's work..i don't know whre is the problem? On 8/16/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, I don't think that it's a problem with the filesystem, if you followed the tutorial then you have the filesystem on the second partition, and your bootargs are pointing there too. Do you have a DHCP server running somewhere? If you have DHCP, but the OMAP cannot use it for some reason, you can still try forcing a static IP instead of DHCPing, like discussed here: http://focus.ti.com/lit/an/spraaq0/spraaq0.pdf That is, add something like ip=clientIP:serverIP:gatewayIP:netMask:::off to your bootargs. More info about the meaning of the above here: http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt Peter thanks peter, i can boot but the kernel stop in the Sending DHCP Requests . 7hub 1-0:1.0 hub_suspend ... how to boot filesystems has installed from mmc?...thanks On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: thanks mr.peter i should try the command like that #nand unlock #nand ecc sw #setenv bootargs 'console=ttyS3,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 mem=256M init=/init' #setenv bootcmd 'mmcinit; fatload mmc 0 0x80c0 uImage; bootm 0x80c0' #saveenv #boot it is stop(like hang) and i must restart again On 8/16/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Dear Aldyth, u-boot stops and waits for your command to load and start the kernel, as the bootcmd is not doing it automatically with your setup (setting bootargs is not enough alone, you need to load the kernel image from the card and run it). You should try: mmcinit fatload mmc 0 8030 uImage bootm 8030 As described at eg: http://www.codeshogun.com/blog/2009/04/15/porting-android-to-beagle-board/ Hope this helps, Peter it is my step to build u-boot, x-loader and kernel i'm try linux 2.6.30 and using the omap3430sdp_defconfig to build the uImage my u-boot and x-loader using omap3430zoom2_config any idea to solve that problem?... regards, Aldyth M On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: i'm format mmc in the fat win95... i following step by step in the https://omapzoom.org/gf/project/omapkernel/wiki/?pagename=Getting+Stated+with+Linux+OMAP+Kernel why can't read? On 8/16/09, Tar Gz bsdraisefromh...@gmail.com wrote: i'm format mmc in the fat win95... i following step by step in the https://omapzoom.org/gf/project/omapkernel/wiki/?pagename=Getting+Stated+with+Linux+OMAP+Kernel why can't read? On 8/16/09, Felipe Balbi m...@felipebalbi.com wrote: Hi, On Sun, Aug 16, 2009 at 12:48:52PM -0400, Tar Gz wrote: Hi all,,i'm sorry if my english too bad i try to porting linux kernel 2.6.30 from kernel.org into omap 3430 i have the problem linux kernel can't booting i'm following step by step in the omapzoom.org $ setenv bootargs console=ttyS3,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 mem=256M init=/sbin/init $ saveenv $ bootd OMAP34XX LAB # print bootdelay=3 baudrate=115200 bootargs=console=ttyS3,115200n8 root=/dev/mmcblk0p2 rootdelay=1 mem=256M init=/sbin/init bootcmd=mmcinit bootfile=uImage if i'm type bootd i'm still in the konsole like this, OMAP34XX LAB # bootd OMAP34XX LAB # any idea? you're not reading the kernel image to memory. is your mmc formated with FAT32 or what ? You need to read kernel from mmc to memory and boot from there. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
Fwd: [help] 2.6.30 can't booting
-- Forwarded message -- From: Tar Gz bsdraisefromh...@gmail.com Date: Tue, 18 Aug 2009 04:47:21 -0700 Subject: Re: [help] 2.6.30 can't booting To: Kovacs Peter Tamas p.kov...@holografika.com, linux-omap linux-omap@vger.kernel.org On 8/17/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, we use these parameters for NFS booting: setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.95.102.32:/home/filesystems/tifs,nolock,vers=3,rsize=2048,wsize=2048, tcp dyntick=e ip=dhcp nohz=off or without DHCP: setenv bootargs console=ttyS2,115200n8 noinitrd,rw root=/dev/nfs nfsroot=10.95.102.32:/home/filesystems/tifs,nolock, mem=112M nohz=off ip=10.95.102.33:10.95.96.1:10.95.96.1:255.255.240.0:infba00798::off devfs=mount oke i try it in the another mailing list, the problem about different speed bootloader and linux kernel..if that's my problem..how i can fix that?thanks before Regards, Aldyth M -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/11] OMAP PM, clock, and SDRC updates for the 2.6.32 merge window
Hello, This second revision of this series drops the patch that ensures that OMAP clocks use unique names, and the patch that adds omap_clk_get_by_name(). The omap_hwmod code has been changed to use clk_get_sys(). - Paul -- This series contains power management, clock, and SDRC patches for the 2.6.32 merge window. All but the bugfix patches 1 and 3 are in use in Kevin's PM branch. The series includes: - several bugfixes (patches 1, 3, 4, 5); - introduces the OMAP PM interface (patch 6), used by core code and some device drivers (via platform_data function pointers) to communicate OMAP-specific PM requirements to OMAP core code; - introduces the omap_hwmod and omap_device layers (prereqs are patches 7, 8; core is patches 9, 10, 11); - and adds some missing SDRC registers that are used by other code in the PM branch (patch 2). For reference: Code that uses the OMAP PM interface is here: (despite the header text, this was not written by me; the header was simply copied from omap-pm-noop.c): http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=blob;f=arch/arm/plat-omap/omap-pm-srf.c;h=4350650b95090b2a5b503b09830bac42109dc262;hb=pm Code that uses the omap_hwmod/omap_device code is here: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=0ddd9080f3c20c32dadf40e12bee05b8cf6784bc http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=4d04506972aba09f21df3b956895fe59a9230697 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=9ef2c1a657621b10e0ea46f7824ebbc725cd2c26 regards, - Paul --- Paul Walmsley (9): OMAP: powerdomain: Fix overflow when doing powerdomain deps lookups. OMAP clock: associate MPU clocks with the mpu_clkdm OMAP3 clock: remove superfluous calls to omap2_init_clk_clkdm OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer OMAP2/3/4 PRCM: add module IDLEST wait code OMAP2/3 board-*.c files: read bootloader configuration earlier OMAP2/3/4: create omap_hwmod layer OMAP: omap_hwmod: call omap_hwmod init at boot; create interconnects OMAP2/3/4 core: create omap_device layer Sanjeev Premi (1): OMAP3 clock: Fixed processing of bootarg 'mpurate' Tero Kristo (1): OMAP: SDRC: Add several new register definitions Documentation/arm/OMAP/omap_pm| 129 ++ arch/arm/mach-omap2/Makefile |7 arch/arm/mach-omap2/board-2430sdp.c | 17 arch/arm/mach-omap2/board-3430sdp.c | 18 arch/arm/mach-omap2/board-apollon.c | 20 arch/arm/mach-omap2/board-generic.c | 14 arch/arm/mach-omap2/board-h4.c| 20 arch/arm/mach-omap2/board-ldp.c | 20 arch/arm/mach-omap2/board-omap3beagle.c | 26 arch/arm/mach-omap2/board-omap3evm.c | 14 arch/arm/mach-omap2/board-omap3pandora.c | 20 arch/arm/mach-omap2/board-overo.c | 20 arch/arm/mach-omap2/board-rx51.c |4 arch/arm/mach-omap2/board-zoom2.c | 18 arch/arm/mach-omap2/clock34xx.c | 17 arch/arm/mach-omap2/clock34xx.h | 21 arch/arm/mach-omap2/cm.c | 70 + arch/arm/mach-omap2/cm.h |4 arch/arm/mach-omap2/cm4xxx.c | 68 + arch/arm/mach-omap2/io.c | 23 arch/arm/mach-omap2/omap_hwmod.c | 1554 + arch/arm/mach-omap2/omap_hwmod_2420.h | 141 ++ arch/arm/mach-omap2/omap_hwmod_2430.h | 143 ++ arch/arm/mach-omap2/omap_hwmod_34xx.h | 168 +++ arch/arm/mach-omap2/powerdomain.c |4 arch/arm/mach-omap2/serial.c | 14 arch/arm/plat-omap/Kconfig| 13 arch/arm/plat-omap/Makefile |5 arch/arm/plat-omap/include/mach/omap-pm.h | 301 + arch/arm/plat-omap/include/mach/omap_device.h | 141 ++ arch/arm/plat-omap/include/mach/omap_hwmod.h | 447 +++ arch/arm/plat-omap/include/mach/sdrc.h|9 arch/arm/plat-omap/include/mach/serial.h |3 arch/arm/plat-omap/omap-pm-noop.c | 296 + arch/arm/plat-omap/omap_device.c | 687 +++ 35 files changed, 4337 insertions(+), 139 deletions(-) create mode 100644 Documentation/arm/OMAP/omap_pm create mode 100644 arch/arm/mach-omap2/cm.c create mode 100644 arch/arm/mach-omap2/cm4xxx.c create mode 100644 arch/arm/mach-omap2/omap_hwmod.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_2420.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_2430.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h create mode 100644 arch/arm/plat-omap/include/mach/omap-pm.h create mode 100644
[PATCH v2 01/11] OMAP: powerdomain: Fix overflow when doing powerdomain deps lookups.
At the end of the list pd is a pointer to a NULL struct, so checking
if the address == NULL doesn't help here. In fact the original code
will just keep running past the struct to read who knows what in
memory.
This case manifests itself when from clkdms_setup() when enabling auto
idle for a clock domain and the clockdomain usecount is greater than
0. When _clkdm_add_autodeps() tries to add the a dependency that does
not exist in the powerdomain-wkdep_srcs array the for loop will run
past the wkdep_srcs array.
Currently in linux-omap you won't hit this because the not found case
is never executed, unless you start modifying powerdomains and their
wakeup/sleep deps.
Signed-off-by: Mike Chan m...@android.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 983f1cb..66206b6 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -83,7 +83,7 @@ static struct powerdomain *_pwrdm_deps_lookup(struct
powerdomain *pwrdm,
if (!pwrdm || !deps || !omap_chip_is(pwrdm-omap_chip))
return ERR_PTR(-EINVAL);
- for (pd = deps; pd; pd++) {
+ for (pd = deps; pd-pwrdm_name; pd++) {
if (!omap_chip_is(pd-omap_chip))
continue;
@@ -96,7 +96,7 @@ static struct powerdomain *_pwrdm_deps_lookup(struct
powerdomain *pwrdm,
}
- if (!pd)
+ if (!pd-pwrdm_name)
return ERR_PTR(-ENOENT);
return pd-pwrdm;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/11] OMAP clock: associate MPU clocks with the mpu_clkdm
All MPU-related clocks should be in the mpu_clkdm. This is needed for the
upcoming omap_hwmod patches, which needs to know the clockdomain that arm_fck
is in.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock34xx.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 57cc272..9a823c3 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1020,6 +1020,7 @@ static struct clk arm_fck = {
.clksel_reg = OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_IDLEST_PLL),
.clksel_mask= OMAP3430_ST_MPU_CLK_MASK,
.clksel = arm_fck_clksel,
+ .clkdm_name = mpu_clkdm,
.recalc = omap2_clksel_recalc,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/11] OMAP2/3/4 PRCM: add module IDLEST wait code
After a hardware module's clocks are enabled, Linux must wait for it
to indicate readiness via its IDLEST bit before attempting to access
the device, otherwise register accesses to the device may trigger an
abort. This has traditionally been implemented in the clock
framework, but this is the wrong place for it: the clock framework
doesn't know which module clocks must be enabled for a module to leave
idle; and if a module is not in smart-idle mode, it may never leave
idle at all. This type of information is best stored in a
per-hardware module data structure (coming in a following patch),
rather than a per-clock data structure. The new code will use these new
functions to handle waiting for modules to enable.
Once hardware module data is filled in for all of the on-chip devices,
the clock framework code to handle IDLEST waiting can be removed.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |5 +++
arch/arm/mach-omap2/cm.c | 70 ++
arch/arm/mach-omap2/cm.h |4 ++
arch/arm/mach-omap2/cm4xxx.c | 68 +
4 files changed, 147 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/cm.c
create mode 100644 arch/arm/mach-omap2/cm4xxx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 735bae5..fa0f0db 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -35,6 +35,11 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
endif
+# PRCM
+obj-$(CONFIG_ARCH_OMAP2) += cm.o
+obj-$(CONFIG_ARCH_OMAP3) += cm.o
+obj-$(CONFIG_ARCH_OMAP4) += cm4xxx.o
+
# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o
obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o
diff --git a/arch/arm/mach-omap2/cm.c b/arch/arm/mach-omap2/cm.c
new file mode 100644
index 000..8eb2dab
--- /dev/null
+++ b/arch/arm/mach-omap2/cm.c
@@ -0,0 +1,70 @@
+/*
+ * OMAP2/3 CM module functions
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/delay.h
+#include linux/spinlock.h
+#include linux/list.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/io.h
+
+#include asm/atomic.h
+
+#include cm.h
+#include cm-regbits-24xx.h
+#include cm-regbits-34xx.h
+
+/* MAX_MODULE_READY_TIME: max milliseconds for module to leave idle */
+#define MAX_MODULE_READY_TIME 2
+
+static const u8 cm_idlest_offs[] = {
+ CM_IDLEST1, CM_IDLEST2, OMAP2430_CM_IDLEST3
+};
+
+/**
+ * omap2_cm_wait_idlest_ready - wait for a module to leave idle or standby
+ * @prcm_mod: PRCM module offset
+ * @idlest_id: CM_IDLESTx register ID (i.e., x = 1, 2, 3)
+ * @idlest_shift: shift of the bit in the CM_IDLEST* register to check
+ *
+ * XXX document
+ */
+int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id, u8 idlest_shift)
+{
+ int ena = 0, i = 0;
+ u8 cm_idlest_reg;
+ u32 mask;
+
+ if (!idlest_id || (idlest_id ARRAY_SIZE(cm_idlest_offs)))
+ return -EINVAL;
+
+ cm_idlest_reg = cm_idlest_offs[idlest_id - 1];
+
+ if (cpu_is_omap24xx())
+ ena = idlest_shift;
+ else if (cpu_is_omap34xx())
+ ena = 0;
+ else
+ BUG();
+
+ mask = 1 idlest_shift;
+
+ /* XXX should be OMAP2 CM */
+ while (((cm_read_mod_reg(prcm_mod, cm_idlest_reg) mask) != ena)
+ (i++ MAX_MODULE_READY_TIME))
+ udelay(1);
+
+ return (i MAX_MODULE_READY_TIME) ? 0 : -EBUSY;
+}
+
diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h
index f3c91a1..df435d1 100644
--- a/arch/arm/mach-omap2/cm.h
+++ b/arch/arm/mach-omap2/cm.h
@@ -98,6 +98,10 @@ extern u32 cm_read_mod_reg(s16 module, u16 idx);
extern void cm_write_mod_reg(u32 val, s16 module, u16 idx);
extern u32 cm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);
+extern int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id,
+ u8 idlest_shift);
+extern int omap4_cm_wait_module_ready(u32 prcm_mod, u8 prcm_dev_offs);
+
static inline u32 cm_set_mod_reg_bits(u32 bits, s16 module, s16 idx)
{
return cm_rmw_mod_reg_bits(bits, bits, module, idx);
diff --git a/arch/arm/mach-omap2/cm4xxx.c b/arch/arm/mach-omap2/cm4xxx.c
new file mode 100644
index 000..e4ebd6d
--- /dev/null
+++ b/arch/arm/mach-omap2/cm4xxx.c
@@ -0,0 +1,68 @@
+/*
+ * OMAP4 CM module functions
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the
[PATCH v2 10/11] OMAP: omap_hwmod: call omap_hwmod init at boot; create interconnects
Connect the omap_hwmod code to the kernel boot. Create some basic
interconnect and device structures for OMAP2/3 chips.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/io.c | 17 +++
arch/arm/mach-omap2/omap_hwmod.c |3 -
arch/arm/mach-omap2/omap_hwmod_2420.h | 141
arch/arm/mach-omap2/omap_hwmod_2430.h | 143
arch/arm/mach-omap2/omap_hwmod_34xx.h | 168 +
5 files changed, 469 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_2420.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_2430.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 470b1d1..7574b6f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -39,12 +39,16 @@
#include mach/omap-pm.h
#include mach/powerdomain.h
-
#include powerdomains.h
#include mach/clockdomain.h
#include clockdomains.h
#endif
+#include mach/omap_hwmod.h
+#include omap_hwmod_2420.h
+#include omap_hwmod_2430.h
+#include omap_hwmod_34xx.h
+
/*
* The machine specific code may provide the extra mapping besides the
* default mapping provided here.
@@ -281,6 +285,16 @@ static int __init _omap2_init_reprogram_sdrc(void)
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
+ struct omap_hwmod **hwmods = NULL;
+
+ if (cpu_is_omap2420())
+ hwmods = omap2420_hwmods;
+ else if (cpu_is_omap2430())
+ hwmods = omap2430_hwmods;
+ else if (cpu_is_omap34xx())
+ hwmods = omap34xx_hwmods;
+
+ omap_hwmod_init(hwmods);
omap2_mux_init();
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once the clkdev is ready */
/* The OPP tables have to be registered before a clk init */
@@ -289,6 +303,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
omap2_clk_init();
omap_serial_early_init();
+ omap_hwmod_late_init();
omap_pm_if_init();
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d1ef3ef..2324e0c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -765,8 +765,7 @@ static int _reset(struct omap_hwmod *oh)
WARN(1, omap_hwmod: %s: failed to reset in %d usec\n,
oh-name, MAX_MODULE_RESET_WAIT);
else
- pr_debug(omap_hwmod: %s: reset in %d usec\n, oh-name,
-MAX_MODULE_RESET_WAIT);
+ pr_debug(omap_hwmod: %s: reset in %d usec\n, oh-name, c);
/*
* XXX add _HWMOD_STATE_WEDGED for modules that don't come back from
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420.h
b/arch/arm/mach-omap2/omap_hwmod_2420.h
new file mode 100644
index 000..767e496
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_2420.h
@@ -0,0 +1,141 @@
+/*
+ * omap_hwmod_2420.h - hardware modules present on the OMAP2420 chips
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX handle crossbar/shared link difference for L3?
+ *
+ */
+#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_HWMOD2420_H
+#define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_HWMOD2420_H
+
+#ifdef CONFIG_ARCH_OMAP2420
+
+#include mach/omap_hwmod.h
+#include mach/irqs.h
+#include mach/cpu.h
+#include mach/dma.h
+
+#include prm-regbits-24xx.h
+
+static struct omap_hwmod omap2420_mpu_hwmod;
+static struct omap_hwmod omap2420_l3_hwmod;
+static struct omap_hwmod omap2420_l4_core_hwmod;
+
+/* L3 - L4_CORE interface */
+static struct omap_hwmod_ocp_if omap2420_l3__l4_core = {
+ .master = omap2420_l3_hwmod,
+ .slave = omap2420_l4_core_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* MPU - L3 interface */
+static struct omap_hwmod_ocp_if omap2420_mpu__l3 = {
+ .master = omap2420_mpu_hwmod,
+ .slave = omap2420_l3_hwmod,
+ .user = OCP_USER_MPU,
+};
+
+/* Slave interfaces on the L3 interconnect */
+static struct omap_hwmod_ocp_if *omap2420_l3_slaves[] = {
+ omap2420_mpu__l3,
+};
+
+/* Master interfaces on the L3 interconnect */
+static struct omap_hwmod_ocp_if *omap2420_l3_masters[] = {
+ omap2420_l3__l4_core,
+};
+
+/* L3 */
+static struct omap_hwmod omap2420_l3_hwmod = {
+ .name = l3_hwmod,
+ .masters= omap2420_l3_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
+ .slaves = omap2420_l3_slaves,
+ .slaves_cnt =
[PATCH v2 05/11] OMAP3 clock: remove superfluous calls to omap2_init_clk_clkdm
omap2_init_clk_clkdm() is called as part of the chip architecture-specific
initialization code, so calling it again from the struct clk init pointer
just wastes cycles.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock34xx.h | 20
1 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 9a823c3..c811978 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1156,7 +1156,6 @@ static struct clk gfx_cg1_ck = {
.name = gfx_cg1_ck,
.ops= clkops_omap2_dflt_wait,
.parent = gfx_l3_fck, /* REVISIT: correct? */
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_FCLKEN),
.enable_bit = OMAP3430ES1_EN_2D_SHIFT,
.clkdm_name = gfx_3430es1_clkdm,
@@ -1167,7 +1166,6 @@ static struct clk gfx_cg2_ck = {
.name = gfx_cg2_ck,
.ops= clkops_omap2_dflt_wait,
.parent = gfx_l3_fck, /* REVISIT: correct? */
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_FCLKEN),
.enable_bit = OMAP3430ES1_EN_3D_SHIFT,
.clkdm_name = gfx_3430es1_clkdm,
@@ -1211,7 +1209,6 @@ static struct clk sgx_ick = {
.name = sgx_ick,
.ops= clkops_omap2_dflt_wait,
.parent = l3_ick,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(OMAP3430ES2_SGX_MOD, CM_ICLKEN),
.enable_bit = OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_SHIFT,
.clkdm_name = sgx_clkdm,
@@ -1224,7 +1221,6 @@ static struct clk d2d_26m_fck = {
.name = d2d_26m_fck,
.ops= clkops_omap2_dflt_wait,
.parent = sys_ck,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430ES1_EN_D2D_SHIFT,
.clkdm_name = d2d_clkdm,
@@ -1235,7 +1231,6 @@ static struct clk modem_fck = {
.name = modem_fck,
.ops= clkops_omap2_dflt_wait,
.parent = sys_ck,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MODEM_SHIFT,
.clkdm_name = d2d_clkdm,
@@ -1623,7 +1618,6 @@ static struct clk core_l3_ick = {
.name = core_l3_ick,
.ops= clkops_null,
.parent = l3_ick,
- .init = omap2_init_clk_clkdm,
.clkdm_name = core_l3_clkdm,
.recalc = followparent_recalc,
};
@@ -1692,7 +1686,6 @@ static struct clk core_l4_ick = {
.name = core_l4_ick,
.ops= clkops_null,
.parent = l4_ick,
- .init = omap2_init_clk_clkdm,
.clkdm_name = core_l4_clkdm,
.recalc = followparent_recalc,
};
@@ -2090,7 +2083,6 @@ static struct clk dss_tv_fck = {
.name = dss_tv_fck,
.ops= clkops_omap2_dflt,
.parent = omap_54m_fck,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_TV_SHIFT,
.clkdm_name = dss_clkdm,
@@ -2101,7 +2093,6 @@ static struct clk dss_96m_fck = {
.name = dss_96m_fck,
.ops= clkops_omap2_dflt,
.parent = omap_96m_fck,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_TV_SHIFT,
.clkdm_name = dss_clkdm,
@@ -2112,7 +2103,6 @@ static struct clk dss2_alwon_fck = {
.name = dss2_alwon_fck,
.ops= clkops_omap2_dflt,
.parent = sys_ck,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_DSS2_SHIFT,
.clkdm_name = dss_clkdm,
@@ -2124,7 +2114,6 @@ static struct clk dss_ick_3430es1 = {
.name = dss_ick,
.ops= clkops_omap2_dflt,
.parent = l4_ick,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_ICLKEN),
.enable_bit = OMAP3430_CM_ICLKEN_DSS_EN_DSS_SHIFT,
.clkdm_name = dss_clkdm,
@@ -2136,7 +2125,6 @@ static struct clk dss_ick_3430es2 = {
.name = dss_ick,
.ops= clkops_omap3430es2_dss_usbhost_wait,
.parent = l4_ick,
- .init = omap2_init_clk_clkdm,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_ICLKEN),
.enable_bit =
[PATCH v2 03/11] OMAP3 clock: Fixed processing of bootarg 'mpurate'
From: Sanjeev Premi pr...@ti.com The argument 'mpurate' had no effect on the MPU frequency. This patch fixes the same. Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/clock34xx.c | 17 + 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index cd7819c..fafcd32 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -27,6 +27,7 @@ #include linux/limits.h #include linux/bitops.h +#include mach/cpu.h #include mach/clock.h #include mach/sram.h #include asm/div64.h @@ -1067,17 +1068,17 @@ static int __init omap2_clk_arch_init(void) return -EINVAL; /* REVISIT: not yet ready for 343x */ -#if 0 - if (clk_set_rate(virt_prcm_set, mpurate)) - printk(KERN_ERR Could not find matching MPU rate\n); -#endif + if (clk_set_rate(dpll1_ck, mpurate)) + printk(KERN_ERR *** Unable to set MPU rate\n); recalculate_root_clocks(); - printk(KERN_INFO Switched to new clocking rate (Crystal/DPLL3/MPU): + printk(KERN_INFO Switched to new clocking rate (Crystal/Core/MPU): %ld.%01ld/%ld/%ld MHz\n, - (osc_sys_ck.rate / 100), (osc_sys_ck.rate / 10) % 10, - (core_ck.rate / 100), (dpll1_fck.rate / 100)) ; + (osc_sys_ck.rate / 100), ((osc_sys_ck.rate / 10) % 10), + (core_ck.rate / 100), (arm_fck.rate / 100)) ; + + calibrate_delay(); return 0; } @@ -1136,7 +1137,7 @@ int __init omap2_clk_init(void) recalculate_root_clocks(); - printk(KERN_INFO Clocking rate (Crystal/DPLL/ARM core): + printk(KERN_INFO Clocking rate (Crystal/Core/MPU): %ld.%01ld/%ld/%ld MHz\n, (osc_sys_ck.rate / 100), (osc_sys_ck.rate / 10) % 10, (core_ck.rate / 100), (arm_fck.rate / 100)); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/11] OMAP: SDRC: Add several new register definitions
From: Tero Kristo tero.kri...@nokia.com
Add missing SDRC register offset macros.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
[p...@pwsan.com: added commit message]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/mach/sdrc.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h
b/arch/arm/plat-omap/include/mach/sdrc.h
index 0be18e4..8fff90a 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -21,19 +21,28 @@
/* SDRC register offsets - read/write with sdrc_{read,write}_reg() */
#define SDRC_SYSCONFIG 0x010
+#define SDRC_CS_CFG0x040
+#define SDRC_SHARING 0x044
+#define SDRC_ERR_TYPE 0x04C
#define SDRC_DLLA_CTRL 0x060
#define SDRC_DLLA_STATUS 0x064
#define SDRC_DLLB_CTRL 0x068
#define SDRC_DLLB_STATUS 0x06C
#define SDRC_POWER 0x070
+#define SDRC_MCFG_00x080
#define SDRC_MR_0 0x084
+#define SDRC_EMR2_00x08c
#define SDRC_ACTIM_CTRL_A_00x09c
#define SDRC_ACTIM_CTRL_B_00x0a0
#define SDRC_RFR_CTRL_00x0a4
+#define SDRC_MANUAL_0 0x0a8
+#define SDRC_MCFG_10x0B0
#define SDRC_MR_1 0x0B4
+#define SDRC_EMR2_10x0BC
#define SDRC_ACTIM_CTRL_A_10x0C4
#define SDRC_ACTIM_CTRL_B_10x0C8
#define SDRC_RFR_CTRL_10x0D4
+#define SDRC_MANUAL_1 0x0D8
/*
* These values represent the number of memory clock cycles between
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/11] OMAP2/3/4 core: create omap_device layer
The omap_device code provides a mapping of omap_hwmod structures into
the platform_device system, and includes some details on external
(board-level) integration. This allows drivers to enable, idle, and
shutdown on-chip device resources, including clocks, regulators, etc.
The resources enabled and idled are dependent on the device's maximum
wakeup latency constraint (if present).
At the moment, omap_device functions are intended to be called from
platform_data function pointers. Ideally in the future these
functions will be called from either subarchitecture-specific
platform_data activate, deactivate functions, or via an custom
bus/device type for OMAP.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Sakari Poussa sakari.pou...@nokia.com
Cc: Anand Sawant saw...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Eric Thomas etho...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
---
arch/arm/plat-omap/Makefile |4
arch/arm/plat-omap/include/mach/omap_device.h | 141 +
arch/arm/plat-omap/omap_device.c | 687 +
3 files changed, 832 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/omap_device.h
create mode 100644 arch/arm/plat-omap/omap_device.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 86ca86f..2ac109a 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -12,6 +12,10 @@ obj- :=
# OCPI interconnect support for 1710, 1610 and 5912
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
+# omap_device support (OMAP2+ only at the moment)
+obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
+
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
diff --git a/arch/arm/plat-omap/include/mach/omap_device.h
b/arch/arm/plat-omap/include/mach/omap_device.h
new file mode 100644
index 000..bd0e136
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/omap_device.h
@@ -0,0 +1,141 @@
+/*
+ * omap_device headers
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * Developed in collaboration with (alphabetical order): Benoit
+ * Cousson, Kevin Hilman, Tony Lindgren, Rajendra Nayak, Vikram
+ * Pandita, Sakari Poussa, Anand Sawant, Santosh Shilimkar, Richard
+ * Woodruff
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Eventually this type of functionality should either be
+ * a) implemented via arch-specific pointers in platform_device
+ * or
+ * b) implemented as a proper omap_bus/omap_device in Linux, no more
+ *platform_device
+ *
+ * omap_device differs from omap_hwmod in that it includes external
+ * (e.g., board- and system-level) integration details. omap_hwmod
+ * stores hardware data that is invariant for a given OMAP chip.
+ *
+ * To do:
+ * - GPIO integration
+ * - regulator integration
+ *
+ */
+#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H
+#define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H
+
+#include linux/kernel.h
+#include linux/platform_device.h
+
+#include mach/omap_hwmod.h
+
+/* omap_device._state values */
+#define OMAP_DEVICE_STATE_UNKNOWN 0
+#define OMAP_DEVICE_STATE_ENABLED 1
+#define OMAP_DEVICE_STATE_IDLE 2
+#define OMAP_DEVICE_STATE_SHUTDOWN 3
+
+/**
+ * struct omap_device - omap_device wrapper for platform_devices
+ * @pdev: platform_device
+ * @hwmods: (one .. many per omap_device)
+ * @hwmods_cnt: ARRAY_SIZE() of @hwmods
+ * @pm_lats: ptr to an omap_device_pm_latency table
+ * @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats
+ * @pm_lat_level: array index of the last odpl entry executed - -1 if never
+ * @dev_wakeup_lat: dev wakeup latency in microseconds
+ * @_dev_wakeup_lat_limit: dev wakeup latency limit in usec - set by OMAP PM
+ * @_state: one of OMAP_DEVICE_STATE_* (see above)
+ * @flags: device flags
+ *
+ * Integrates omap_hwmod data into Linux platform_device.
+ *
+ * Field names beginning with underscores are for the internal use of
+ * the omap_device code.
+ *
+ */
+struct omap_device {
+ struct platform_device pdev;
+ struct omap_hwmod **hwmods;
+ struct omap_device_pm_latency *pm_lats;
+ u32 dev_wakeup_lat;
+ u32 _dev_wakeup_lat_limit;
+ u8 pm_lats_cnt;
+ s8 pm_lat_level;
+ u8 hwmods_cnt;
+ u8 _state;
+};
+
+/* Device driver interface (call via platform_data fn ptrs) */
+
+int omap_device_enable(struct
[PATCH v2 08/11] OMAP2/3 board-*.c files: read bootloader configuration earlier
Most board-*.c files read configuration data from the bootloader in
their .init_machine() function. This needs to happen earlier, at some
point before omap2_init_common_hw() is called. This is because a
future patch will use the bootloader serial console port information
to enable the UART clocks earlier, immediately after omap2_clk_init().
This is in turn necessary since otherwise clock tree usecounts on
clocks like dpll4_m2x2_ck will be bogus, which can cause the
currently-active console UART clock to be disabled during boot.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/board-2430sdp.c | 17 -
arch/arm/mach-omap2/board-3430sdp.c | 18 +-
arch/arm/mach-omap2/board-apollon.c | 20 ++--
arch/arm/mach-omap2/board-generic.c | 14 +++---
arch/arm/mach-omap2/board-h4.c | 20 ++--
arch/arm/mach-omap2/board-ldp.c | 20 ++--
arch/arm/mach-omap2/board-omap3beagle.c | 26 +-
arch/arm/mach-omap2/board-omap3evm.c | 14 +++---
arch/arm/mach-omap2/board-omap3pandora.c | 20 ++--
arch/arm/mach-omap2/board-overo.c| 20 ++--
arch/arm/mach-omap2/board-rx51.c |4 ++--
arch/arm/mach-omap2/board-zoom2.c| 18 +-
arch/arm/mach-omap2/io.c |2 ++
arch/arm/mach-omap2/serial.c | 14 +-
arch/arm/plat-omap/include/mach/serial.h |3 +++
15 files changed, 123 insertions(+), 107 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 8ec2a13..06c644d 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -139,13 +139,6 @@ static inline void board_smc91x_init(void)
#endif
-static void __init omap_2430sdp_init_irq(void)
-{
- omap2_init_common_hw(NULL, NULL);
- omap_init_irq();
- omap_gpio_init();
-}
-
static struct omap_uart_config sdp2430_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
@@ -155,6 +148,14 @@ static struct omap_board_config_kernel sdp2430_config[] = {
{OMAP_TAG_LCD, sdp2430_lcd_config},
};
+static void __init omap_2430sdp_init_irq(void)
+{
+ omap_board_config = sdp2430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp2430_config);
+ omap2_init_common_hw(NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
static struct twl4030_gpio_platform_data sdp2430_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
@@ -205,8 +206,6 @@ static void __init omap_2430sdp_init(void)
omap2430_i2c_init();
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
- omap_board_config = sdp2430_config;
- omap_board_config_size = ARRAY_SIZE(sdp2430_config);
omap_serial_init();
twl4030_mmc_init(mmc);
usb_musb_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ac262cd..e51c124 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -167,13 +167,6 @@ static struct platform_device *sdp3430_devices[]
__initdata = {
sdp3430_lcd_device,
};
-static void __init omap_3430sdp_init_irq(void)
-{
- omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
- omap_init_irq();
- omap_gpio_init();
-}
-
static struct omap_uart_config sdp3430_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
@@ -187,6 +180,15 @@ static struct omap_board_config_kernel sdp3430_config[]
__initdata = {
{ OMAP_TAG_LCD, sdp3430_lcd_config },
};
+static void __init omap_3430sdp_init_irq(void)
+{
+ omap_board_config = sdp3430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
static int sdp3430_batt_table[] = {
/* 0 C*/
30800, 29500, 28300, 27100,
@@ -482,8 +484,6 @@ static void __init omap_3430sdp_init(void)
{
omap3430_i2c_init();
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
- omap_board_config = sdp3430_config;
- omap_board_config_size = ARRAY_SIZE(sdp3430_config);
if (omap_rev() OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index dcfc20d..8e063ba 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -248,14 +248,6 @@ out:
clk_put(gpmc_fck);
}
-static void __init omap_apollon_init_irq(void)
-{
- omap2_init_common_hw(NULL, NULL);
- omap_init_irq();
- omap_gpio_init();
- apollon_init_smc91x();
-}
-
static struct
Re: [help] 2.6.30 can't booting
if i'm using another partition?..how i mount partition that? On 8/18/09, Tar Gz bsdraisefromh...@gmail.com wrote: -- Forwarded message -- From: Tar Gz bsdraisefromh...@gmail.com Date: Tue, 18 Aug 2009 04:47:21 -0700 Subject: Re: [help] 2.6.30 can't booting To: Kovacs Peter Tamas p.kov...@holografika.com, linux-omap linux-omap@vger.kernel.org On 8/17/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, we use these parameters for NFS booting: setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.95.102.32:/home/filesystems/tifs,nolock,vers=3,rsize=2048,wsize=2048, tcp dyntick=e ip=dhcp nohz=off or without DHCP: setenv bootargs console=ttyS2,115200n8 noinitrd,rw root=/dev/nfs nfsroot=10.95.102.32:/home/filesystems/tifs,nolock, mem=112M nohz=off ip=10.95.102.33:10.95.96.1:10.95.96.1:255.255.240.0:infba00798::off devfs=mount oke i try it in the another mailing list, the problem about different speed bootloader and linux kernel..if that's my problem..how i can fix that?thanks before Regards, Aldyth M -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/11] OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer
The interface provides device drivers, CPUFreq, and DSPBridge with a means of controlling OMAP power management parameters that are not yet supported by the Linux PM PMQoS interface. Copious documentation is in the patch in Documentation/arm/OMAP/omap_pm and the interface header file, arch/arm/plat-omap/include/mach/omap-pm.h. Thanks to Rajendra Nayak rna...@ti.com for adding CORE (VDD2) OPP support and moving the OPP table initialization earlier in the event that the clock code needs them. Thanks to Tero Kristo tero.kri...@nokia.com for fixing the parameter check in omap_pm_set_min_bus_tput(). Jouni signed off on Tero's patch. Signed-off-by: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo tero.kri...@nokia.com Signed-off-by: Jouni Högander jouni.hogan...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Igor Stoppa igor.sto...@nokia.com Cc: Richard Woodruff r-woodru...@ti.com Cc: Anand Sawant saw...@ti.com Cc: Sakari Poussa sakari.pou...@nokia.com Cc: Veeramanikandan Raju ve...@ti.com Cc: Karthik Dasu karthik...@ti.com --- Documentation/arm/OMAP/omap_pm| 129 arch/arm/mach-omap2/io.c |4 arch/arm/plat-omap/Kconfig| 13 + arch/arm/plat-omap/Makefile |1 arch/arm/plat-omap/include/mach/omap-pm.h | 301 + arch/arm/plat-omap/omap-pm-noop.c | 296 + 6 files changed, 744 insertions(+), 0 deletions(-) create mode 100644 Documentation/arm/OMAP/omap_pm create mode 100644 arch/arm/plat-omap/include/mach/omap-pm.h create mode 100644 arch/arm/plat-omap/omap-pm-noop.c diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm new file mode 100644 index 000..5389440 --- /dev/null +++ b/Documentation/arm/OMAP/omap_pm @@ -0,0 +1,129 @@ + +The OMAP PM interface += + +This document describes the temporary OMAP PM interface. Driver +authors use these functions to communicate minimum latency or +throughput constraints to the kernel power management code. +Over time, the intention is to merge features from the OMAP PM +interface into the Linux PM QoS code. + +Drivers need to express PM parameters which: + +- support the range of power management parameters present in the TI SRF; + +- separate the drivers from the underlying PM parameter + implementation, whether it is the TI SRF or Linux PM QoS or Linux + latency framework or something else; + +- specify PM parameters in terms of fundamental units, such as + latency and throughput, rather than units which are specific to OMAP + or to particular OMAP variants; + +- allow drivers which are shared with other architectures (e.g., + DaVinci) to add these constraints in a way which won't affect non-OMAP + systems, + +- can be implemented immediately with minimal disruption of other + architectures. + + +This document proposes the OMAP PM interface, including the following +five power management functions for driver code: + +1. Set the maximum MPU wakeup latency: + (*pdata-set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t) + +2. Set the maximum device wakeup latency: + (*pdata-set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) + +3. Set the maximum system DMA transfer start latency (CORE pwrdm): + (*pdata-set_max_sdma_lat)(struct device *dev, long t) + +4. Set the minimum bus throughput needed by a device: + (*pdata-set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r) + +5. Return the number of times the device has lost context + (*pdata-get_dev_context_loss_count)(struct device *dev) + + +Further documentation for all OMAP PM interface functions can be +found in arch/arm/plat-omap/include/mach/omap-pm.h. + + +The OMAP PM layer is intended to be temporary +- + +The intention is that eventually the Linux PM QoS layer should support +the range of power management features present in OMAP3. As this +happens, existing drivers using the OMAP PM interface can be modified +to use the Linux PM QoS code; and the OMAP PM interface can disappear. + + +Driver usage of the OMAP PM functions +- + +As the 'pdata' in the above examples indicates, these functions are +exposed to drivers through function pointers in driver .platform_data +structures. The function pointers are initialized by the board-*.c +files to point to the corresponding OMAP PM functions: +.set_max_dev_wakeup_lat will point to +omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do +not support these functions should leave these function pointers set +to NULL. Drivers should use the following idiom: + +if (pdata-set_max_dev_wakeup_lat) +(*pdata-set_max_dev_wakeup_lat)(dev, t); + +The most common usage of these functions will probably be to specify +the
Re: [help] 2.6.30 can't booting
Hi, to mount SD card instead of NFS, use something like: setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p1 rw likewise, the second partition is /dev/mmcblk0p2 Hope this helps, Peter if i'm using another partition?..how i mount partition that? On 8/18/09, Tar Gz bsdraisefromh...@gmail.com wrote: -- Forwarded message -- From: Tar Gz bsdraisefromh...@gmail.com Date: Tue, 18 Aug 2009 04:47:21 -0700 Subject: Re: [help] 2.6.30 can't booting To: Kovacs Peter Tamas p.kov...@holografika.com, linux-omap linux-omap@vger.kernel.org On 8/17/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, we use these parameters for NFS booting: setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.95.102.32:/home/filesystems/tifs,nolock,vers=3,rsize=2048,wsize=2048, tcp dyntick=e ip=dhcp nohz=off or without DHCP: setenv bootargs console=ttyS2,115200n8 noinitrd,rw root=/dev/nfs nfsroot=10.95.102.32:/home/filesystems/tifs,nolock, mem=112M nohz=off ip=10.95.102.33:10.95.96.1:10.95.96.1:255.255.240.0:infba00798::off devfs=mount oke i try it in the another mailing list, the problem about different speed bootloader and linux kernel..if that's my problem..how i can fix that?thanks before Regards, Aldyth M -- 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 07/10] OMAP: PM: Add definitions for ETK pads and observability registers
Gadiyar, Anand gadi...@ti.com writes: From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/mach/control.h | 47 +++- 1 files changed, 45 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/control.h b/arch/arm/plat-omap/include/mach/control.h index 8140dbc..81afe26 100644 --- a/arch/arm/plat-omap/include/mach/control.h +++ b/arch/arm/plat-omap/include/mach/control.h @@ -141,8 +141,51 @@ #define OMAP343X_CONTROL_TEST_KEY_13(OMAP2_CONTROL_GENERAL + 0x00fc) #define OMAP343X_CONTROL_IVA2_BOOTADDR (OMAP2_CONTROL_GENERAL + 0x0190) #define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194) -#define OMAP343X_CONTROL_PBIAS_LITE (OMAP2_CONTROL_GENERAL + 0x02b0) -#define OMAP343X_CONTROL_TEMP_SENSOR(OMAP2_CONTROL_GENERAL + 0x02b4) +#define OMAP343X_CONTROL_DEBOBS(i) (OMAP2_CONTROL_GENERAL + 0x01B0 \ ++ ((i) 1) * 4 + (!(i 1)) * 2) +#define OMAP343X_CONTROL_PROG_IO0 (OMAP2_CONTROL_GENERAL + 0x01D4) +#define OMAP343X_CONTROL_PROG_IO1 (OMAP2_CONTROL_GENERAL + 0x01D8) +#define OMAP343X_CONTROL_DSS_DPLL_SPREADING (OMAP2_CONTROL_GENERAL + 0x01E0) +#define OMAP343X_CONTROL_CORE_DPLL_SPREADING(OMAP2_CONTROL_GENERAL + 0x01E4) +#define OMAP343X_CONTROL_PER_DPLL_SPREADING (OMAP2_CONTROL_GENERAL + 0x01E8) +#define OMAP343X_CONTROL_USBHOST_DPLL_SPREADING (OMAP2_CONTROL_GENERAL + 0x01EC) +#define OMAP343X_CONTROL_PBIAS_LITE (OMAP2_CONTROL_GENERAL + 0x02B0) +#define OMAP343X_CONTROL_TEMP_SENSOR(OMAP2_CONTROL_GENERAL + 0x02B4) +#define OMAP343X_CONTROL_SRAMLDO4 (OMAP2_CONTROL_GENERAL + 0x02B8) +#define OMAP343X_CONTROL_SRAMLDO5 (OMAP2_CONTROL_GENERAL + 0x02C0) +#define OMAP343X_CONTROL_CSI(OMAP2_CONTROL_GENERAL + 0x02C4) + + +/* 34xx PADCONF register offsets */ +#define OMAP343X_PADCONF_ETK(i) (OMAP2_CONTROL_PADCONFS + 0x5a8 + \ +(i)*2) +#define OMAP343X_PADCONF_ETK_CLKOMAP343X_PADCONF_ETK(0) +#define OMAP343X_PADCONF_ETK_CTLOMAP343X_PADCONF_ETK(1) +#define OMAP343X_PADCONF_ETK_D0 OMAP343X_PADCONF_ETK(2) +#define OMAP343X_PADCONF_ETK_D1 OMAP343X_PADCONF_ETK(3) +#define OMAP343X_PADCONF_ETK_D2 OMAP343X_PADCONF_ETK(4) +#define OMAP343X_PADCONF_ETK_D3 OMAP343X_PADCONF_ETK(5) +#define OMAP343X_PADCONF_ETK_D4 OMAP343X_PADCONF_ETK(6) +#define OMAP343X_PADCONF_ETK_D5 OMAP343X_PADCONF_ETK(7) +#define OMAP343X_PADCONF_ETK_D6 OMAP343X_PADCONF_ETK(8) +#define OMAP343X_PADCONF_ETK_D7 OMAP343X_PADCONF_ETK(9) +#define OMAP343X_PADCONF_ETK_D8 OMAP343X_PADCONF_ETK(10) +#define OMAP343X_PADCONF_ETK_D9 OMAP343X_PADCONF_ETK(11) +#define OMAP343X_PADCONF_ETK_D10OMAP343X_PADCONF_ETK(12) +#define OMAP343X_PADCONF_ETK_D11OMAP343X_PADCONF_ETK(13) +#define OMAP343X_PADCONF_ETK_D12OMAP343X_PADCONF_ETK(14) +#define OMAP343X_PADCONF_ETK_D13OMAP343X_PADCONF_ETK(15) +#define OMAP343X_PADCONF_ETK_D14OMAP343X_PADCONF_ETK(16) +#define OMAP343X_PADCONF_ETK_D15OMAP343X_PADCONF_ETK(17) I'm not sure if we need to use only these pads. There is an alternative set of pad that bring out the debobs signals. ... and they can be added in a separate patch when needed. 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
Pull request v2 for remaining OMAP PM, clock, SDRC 2.6.32 patches
Hello Russell, Here's the updated pull request for the eleven patches for 2.6.32, plus Hiroshi's OMAP clock debugfs error path fix. regards, - Paul The following changes since commit df4ecf1524c7793de3121b2d4e5fc6bcc0da3bfb: Linus Torvalds (1): Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus are available in the git repository at: git://git.pwsan.com/linux-2.6 2_6_32_merge Hiroshi DOYU (1): OMAP clock: use debugfs_remove_recursive() for rewinding Paul Walmsley (9): OMAP: powerdomain: Fix overflow when doing powerdomain deps lookups. OMAP clock: associate MPU clocks with the mpu_clkdm OMAP3 clock: remove superfluous calls to omap2_init_clk_clkdm OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer OMAP2/3/4 PRCM: add module IDLEST wait code OMAP2/3 board-*.c files: read bootloader configuration earlier OMAP2/3/4: create omap_hwmod layer OMAP: omap_hwmod: call omap_hwmod init at boot; create interconnects OMAP2/3/4 core: create omap_device layer Sanjeev Premi (1): OMAP3 clock: Fixed processing of bootarg 'mpurate' Tero Kristo (1): OMAP: SDRC: Add several new register definitions Documentation/arm/OMAP/omap_pm| 129 ++ arch/arm/mach-omap2/Makefile |7 +- arch/arm/mach-omap2/board-2430sdp.c | 17 +- arch/arm/mach-omap2/board-3430sdp.c | 18 +- arch/arm/mach-omap2/board-apollon.c | 20 +- arch/arm/mach-omap2/board-generic.c | 14 +- arch/arm/mach-omap2/board-h4.c| 20 +- arch/arm/mach-omap2/board-ldp.c | 20 +- arch/arm/mach-omap2/board-omap3beagle.c | 26 +- arch/arm/mach-omap2/board-omap3evm.c | 14 +- arch/arm/mach-omap2/board-omap3pandora.c | 20 +- arch/arm/mach-omap2/board-overo.c | 20 +- arch/arm/mach-omap2/board-rx51.c |4 +- arch/arm/mach-omap2/board-zoom2.c | 18 +- arch/arm/mach-omap2/clock34xx.c | 17 +- arch/arm/mach-omap2/clock34xx.h | 21 +- arch/arm/mach-omap2/cm.c | 70 ++ arch/arm/mach-omap2/cm.h |4 + arch/arm/mach-omap2/cm4xxx.c | 68 ++ arch/arm/mach-omap2/io.c | 23 +- arch/arm/mach-omap2/omap_hwmod.c | 1554 + arch/arm/mach-omap2/omap_hwmod_2420.h | 141 +++ arch/arm/mach-omap2/omap_hwmod_2430.h | 143 +++ arch/arm/mach-omap2/omap_hwmod_34xx.h | 168 +++ arch/arm/mach-omap2/powerdomain.c |4 +- arch/arm/mach-omap2/serial.c | 14 +- arch/arm/plat-omap/Kconfig| 13 + arch/arm/plat-omap/Makefile |5 + arch/arm/plat-omap/clock.c|2 +- arch/arm/plat-omap/include/mach/omap-pm.h | 301 + arch/arm/plat-omap/include/mach/omap_device.h | 141 +++ arch/arm/plat-omap/include/mach/omap_hwmod.h | 447 +++ arch/arm/plat-omap/include/mach/sdrc.h|9 + arch/arm/plat-omap/include/mach/serial.h |3 + arch/arm/plat-omap/omap-pm-noop.c | 296 + arch/arm/plat-omap/omap_device.c | 687 +++ 36 files changed, 4338 insertions(+), 140 deletions(-) create mode 100644 Documentation/arm/OMAP/omap_pm create mode 100644 arch/arm/mach-omap2/cm.c create mode 100644 arch/arm/mach-omap2/cm4xxx.c create mode 100644 arch/arm/mach-omap2/omap_hwmod.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_2420.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_2430.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h create mode 100644 arch/arm/plat-omap/include/mach/omap-pm.h create mode 100644 arch/arm/plat-omap/include/mach/omap_device.h create mode 100644 arch/arm/plat-omap/include/mach/omap_hwmod.h create mode 100644 arch/arm/plat-omap/omap-pm-noop.c create mode 100644 arch/arm/plat-omap/omap_device.c -- 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
SDP support seems broken in LO
LO seems broken on OMAP3430 SDP platform. I compile latest kernel with 'omap_3430sdp_defconfig' config options. Booting hangs after kernel uncompressed and last message which appears is 'booting the kernel' Thanks and regards, vimal See below log: ## Booting image at 8000 ... Image Name: Linux-2.6.31-rc5-omap1-05896-ge0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2520992 Bytes = 2.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. done, booting the kernel. -- 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: [help] 2.6.30 can't booting
i try that from omapzoom.org first partition contains uboot.bin, mlo and uImage and second partition contains filesystem i must mount what?..my filesystem just contains directory structure, not the operatign systems like android or maemo.. but i don't know why linux kernel stuck after Uncompressing Linux.. it's stop...:( On 8/18/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, to mount SD card instead of NFS, use something like: setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p1 rw likewise, the second partition is /dev/mmcblk0p2 Hope this helps, Peter if i'm using another partition?..how i mount partition that? On 8/18/09, Tar Gz bsdraisefromh...@gmail.com wrote: -- Forwarded message -- From: Tar Gz bsdraisefromh...@gmail.com Date: Tue, 18 Aug 2009 04:47:21 -0700 Subject: Re: [help] 2.6.30 can't booting To: Kovacs Peter Tamas p.kov...@holografika.com, linux-omap linux-omap@vger.kernel.org On 8/17/09, Kovacs Peter Tamas p.kov...@holografika.com wrote: Hi, we use these parameters for NFS booting: setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.95.102.32:/home/filesystems/tifs,nolock,vers=3,rsize=2048,wsize=2048, tcp dyntick=e ip=dhcp nohz=off or without DHCP: setenv bootargs console=ttyS2,115200n8 noinitrd,rw root=/dev/nfs nfsroot=10.95.102.32:/home/filesystems/tifs,nolock, mem=112M nohz=off ip=10.95.102.33:10.95.96.1:10.95.96.1:255.255.240.0:infba00798::off devfs=mount oke i try it in the another mailing list, the problem about different speed bootloader and linux kernel..if that's my problem..how i can fix that?thanks before Regards, Aldyth M -- 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: SDP support seems broken in LO
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of vimal singh Sent: Tuesday, August 18, 2009 5:49 PM To: linux-omap@vger.kernel.org Subject: SDP support seems broken in LO LO seems broken on OMAP3430 SDP platform. I compile latest kernel with 'omap_3430sdp_defconfig' config options. Booting hangs after kernel uncompressed and last message which appears is 'booting the kernel' Thanks and regards, vimal See below log: ## Booting image at 8000 ... Image Name: Linux-2.6.31-rc5-omap1-05896-ge0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2520992 Bytes = 2.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. .. .. done, booting the kernel. Mainly because of frame-buffer and musb. You can try disabling these two and see if it boots. Regards, Santosh -- 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: Pull request for OMAP PM, clock, SDRC 2.6.32 patches
Hello Russell, On Mon, 17 Aug 2009, Russell King - ARM Linux wrote: On Sun, Aug 16, 2009 at 07:45:59AM -0600, Paul Walmsley wrote: Hello Russell, Here's the pull request for the thirteen patches posted earlier, plus Hiroshi's clock debugfs error path fix. I'm afraid to say that I think you've left it far too late to send this. I did set a date of the 16th as being the final date to sort out stuff (which was flexible to a degree) but since these patches were only posted on Saturday, and they're still being discussed, I don't think it would make sense for me to pull it today. I've dropped the two patches that are being discussed and reposted the remainder. The updated series is here (et seq.): http://marc.info/?l=linux-arm-kernelm=125059872200340w=2 and the pull request is here: http://marc.info/?l=linux-arm-kernelm=125059845132331w=2 - Paul And this is likely to be the final day that I merge anything into my kernel tree for the next two weeks. regards, - Paul The following changes since commit 3b3119fc549c93df60316d28bdd77c2de3986588: Russell King (1): Merge branch 'ixp4xx-fixes' of git://git.kernel.org/.../chris/linux-2.6 That's stupid. Someone publishing _my_ tree, which I make no guarantees about the life of the commits, for other people to base their work on... That's definitely a big FAIL. Luckily for you though, that commit still exists in my tree, and I've asked Linus to pull that set; so essentially it became immutable only last night. Don't base patches on the contents of my tree without talking to me first please. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend][PATCH] Maintainers update for hsmmc driver
* Kevin Hilman khil...@deeprootsystems.com [090814 00:39]: Madhusudhan Chikkature madhu...@ti.com writes: Hi, Resending the patch after changing omap_hs* to omap_hsmmc.c. Regards, Madhu Update maintainers entry for TI OMAP HS MMC support. Signed-off-by: Madhusudhan Chikkature madhu...@ti.com Madhu is the right guy for the job. Acked-by: Kevin Hilman khil...@deeprootsystems.com This should go in via the new linux-...@vger.kernel.org list. Tony --- MAINTAINERS |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) Index: linux-omap-2.6/MAINTAINERS === --- linux-omap-2.6.orig/MAINTAINERS +++ linux-omap-2.6/MAINTAINERS @@ -3698,7 +3698,13 @@ OMAP MMC SUPPORT M: Jarkko Lavinen jarkko.lavi...@nokia.com L: linux-omap@vger.kernel.org S: Maintained -F: drivers/mmc/host/*omap* +F: drivers/mmc/host/omap.c + +OMAP HS MMC SUPPORT +M: Madhusudhan Chikkature madhu...@ti.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/mmc/host/omap_hsmmc.c OMAP RANDOM NUMBER GENERATOR SUPPORT M: Deepak Saxena dsax...@plexity.net -- 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 10/10] OMAP: PM: Added suspend target state control to debugfs for OMAP3
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@deeprootsystems.com [090813 19:54]:
From: Tero Kristo tero.kri...@nokia.com
Target state can be read / programmed via files under:
[debugfs]/pm_debug/[pwrdm]/suspend
Does this compile when CONFIG_DEBUG_FS is not set?
Yes. The relevant code is added to a section that is already
wrapped by #ifdef CONFIG_DEBUG_FS.
Kevin
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm-debug.c | 31 +--
arch/arm/mach-omap2/pm.h |3 +++
arch/arm/mach-omap2/pm34xx.c | 24
3 files changed, 56 insertions(+), 2 deletions(-)
mode change 100755 = 100644 arch/arm/mach-omap2/pm-debug.c
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
old mode 100755
new mode 100644
index 37b883b..eded6a4
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -24,6 +24,7 @@
#include linux/clk.h
#include linux/err.h
#include linux/io.h
+#include linux/module.h
#include mach/clock.h
#include mach/board.h
@@ -478,10 +479,28 @@ int pm_dbg_regset_init(int reg_set)
return 0;
}
-static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+static int pwrdm_suspend_get(void *data, u64 *val)
+{
+*val = omap3_pm_get_suspend_state((struct powerdomain *)data);
+
+if (*val = 0)
+return 0;
+return *val;
+}
+
+static int pwrdm_suspend_set(void *data, u64 val)
+{
+return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get,
+pwrdm_suspend_set, %llu\n);
+
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
{
int i;
s64 t;
+struct dentry *d;
t = sched_clock();
@@ -490,6 +509,14 @@ static int __init pwrdms_setup(struct powerdomain
*pwrdm, void *unused)
pwrdm-timer = t;
+if (strncmp(pwrdm-name, dpll, 4) == 0)
+return 0;
+
+d = debugfs_create_dir(pwrdm-name, (struct dentry *)dir);
+
+(void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d,
+(void *)pwrdm, pwrdm_suspend_fops);
+
return 0;
}
@@ -508,7 +535,7 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(time, S_IRUGO,
d, (void *)DEBUG_FILE_TIMERS, debug_fops);
-pwrdm_for_each(pwrdms_setup, NULL);
+pwrdm_for_each(pwrdms_setup, (void *)d);
pm_dbg_dir = debugfs_create_dir(registers, d);
if (IS_ERR(pm_dbg_dir))
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 8fa8567..8400f57 100755
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -13,6 +13,9 @@
#include mach/powerdomain.h
+extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
+extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
+
#ifdef CONFIG_PM_DEBUG
extern void omap2_pm_dump(int mode, int resume, unsigned int us);
extern int omap2_pm_debug;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 331dfca..26f2aca 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -664,6 +664,30 @@ static void __init prcm_setup_regs(void)
omap3_d2d_idle();
}
+int omap3_pm_get_suspend_state(struct powerdomain *pwrdm)
+{
+struct power_state *pwrst;
+
+list_for_each_entry(pwrst, pwrst_list, node) {
+if (pwrst-pwrdm == pwrdm)
+return pwrst-next_state;
+}
+return -EINVAL;
+}
+
+int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state)
+{
+struct power_state *pwrst;
+
+list_for_each_entry(pwrst, pwrst_list, node) {
+if (pwrst-pwrdm == pwrdm) {
+pwrst-next_state = state;
+return 0;
+}
+}
+return -EINVAL;
+}
+
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
--
1.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-arm 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: SDP support seems broken in LO
On Tue, Aug 18, 2009 at 5:53 PM, Shilimkar, Santoshsantosh.shilim...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of vimal singh Sent: Tuesday, August 18, 2009 5:49 PM To: linux-omap@vger.kernel.org Subject: SDP support seems broken in LO LO seems broken on OMAP3430 SDP platform. I compile latest kernel with 'omap_3430sdp_defconfig' config options. Booting hangs after kernel uncompressed and last message which appears is 'booting the kernel' Thanks and regards, vimal See below log: ## Booting image at 8000 ... Â Â Image Name: Â Linux-2.6.31-rc5-omap1-05896-ge0 Â Â Image Type: Â ARM Linux Kernel Image (uncompressed) Â Â Data Size: Â Â 2520992 Bytes = Â 2.4 MB Â Â Load Address: 80008000 Â Â Entry Point: Â 80008000 Â Â Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. .. .. done, booting the kernel. Mainly because of frame-buffer and musb. You can try disabling these two and see if it boots. I disabled frame-buffer and usb support fully: # CONFIG_FB is not set # CONFIG_USB_SUPPORT is not set I still get same message. -vimal Regards, Santosh -- 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: SDP support seems broken in LO
LO seems broken on OMAP3430 SDP platform. I compile latest kernel with 'omap_3430sdp_defconfig' config options. Booting hangs after kernel uncompressed and last message which appears is 'booting the kernel' Thanks and regards, vimal See below log: ## Booting image at 8000 ... Â Â Image Name: Â Linux-2.6.31-rc5-omap1-05896-ge0 Â Â Image Type: Â ARM Linux Kernel Image (uncompressed) Â Â Data Size: Â Â 2520992 Bytes = Â 2.4 MB Â Â Load Address: 80008000 Â Â Entry Point: Â 80008000 Â Â Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. .. .. done, booting the kernel. Mainly because of frame-buffer and musb. You can try disabling these two and see if it boots. I disabled frame-buffer and usb support fully: # CONFIG_FB is not set # CONFIG_USB_SUPPORT is not set I still get same message. -vimal Do you have CONFIG_DEBUG_LL enabled? If so, could you enable that please to see if we have a crash somewhere? - Anand -- 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: SDP support seems broken in LO
On Tue, Aug 18, 2009 at 6:30 PM, Gadiyar, Anandgadi...@ti.com wrote: LO seems broken on OMAP3430 SDP platform. I compile latest kernel with 'omap_3430sdp_defconfig' config options. Booting hangs after kernel uncompressed and last message which appears is 'booting the kernel' Thanks and regards, vimal See below log: ## Booting image at 8000 ... Â Â Image Name: Â Linux-2.6.31-rc5-omap1-05896-ge0 Â Â Image Type: Â ARM Linux Kernel Image (uncompressed) Â Â Data Size: Â Â 2520992 Bytes = Â 2.4 MB Â Â Load Address: 80008000 Â Â Entry Point: Â 80008000 Â Â Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. .. .. done, booting the kernel. Mainly because of frame-buffer and musb. You can try disabling these two and see if it boots. I disabled frame-buffer and usb support fully: # CONFIG_FB is not set # CONFIG_USB_SUPPORT is not set I still get same message. -vimal Do you have CONFIG_DEBUG_LL enabled? If so, could you enable that please to see if we have a crash somewhere? Here is the log after enabling 'CONFIG_DEBUG_LL': ## Booting image at 8000 ... Image Name: Linux-2.6.31-rc5-omap1-05896-ge0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2303384 Bytes = 2.2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux done, booting the kernel. 5Linux version 2.6.31-rc5-omap1-05896-ge087f6f-dirty (x0094...@omaplinux2) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #7 Tue Aug 18 18:38:47 IST 2009 CPU: ARMv7 Processor [411fc081] revision 1 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3430 3430SDP board Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 32768 7free_area_init_node: node 0, pgdat c048c700, node_mem_map c04da000 7 Normal zone: 256 pages used for memmap 7 Normal zone: 0 pages reserved 7 Normal zone: 32512 pages, LIFO batch:7 6OMAP3430 ES2.0 6SRAM: Mapped pa 0x4020 to va 0xe300 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 5Kernel command line: mem=128M console=ttyS0,115200n8 noinitrd root=/dev/nfs rw nfsroot=10.24.246.118:/home1/vimal_fs/newfs,nolock,tcp,rsize=1024,wsize=1024 ip=dhcp nohz=off PID hash table entries: 512 (order: 9, 2048 bytes) 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) 6Memory: 128MB = 128MB total 5Memory: 124828KB available (4132K code, 529K data, 128K init, 0K highmem) 6SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 6NR_IRQS:402 6Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz 6Reprogramming SDRC clock to 33200 Hz 6GPMC revision 5.0 6IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts 6Total of 96 interrupts on 1 active controller 6OMAP34xx GPIO hardware version 2.5 6OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 6Calibrating delay loop... -vimal - Anand -- 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: SDP support seems broken in LO
snip Here is the log after enabling 'CONFIG_DEBUG_LL': ## Booting image at 8000 ... Image Name: Linux-2.6.31-rc5-omap1-05896-ge0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2303384 Bytes = 2.2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. ... done, booting the kernel. 5Linux version 2.6.31-rc5-omap1-05896-ge087f6f-dirty (x0094...@omaplinux2) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #7 Tue Aug 18 18:38:47 IST 2009 And here's the problem - you're using CodeSourcery's 2007q3 toolchain. This has been discussed in the past on this list. I don't know exactly what causes the problem or what fixes this. Move to 2008q3 or 2009q1 as a workaround. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] OMAP1: AMS_DELTA: add modem support
Tony Lindgren wrote:
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
This patch adds support for modem device found on Amstrad E3 (Delta) board.
Based on earlier patch by Jonathan McDowell, available at
http://the.earth.li/pub/e3/2.6.19/ams-delta-modem.patch.
Modified after Ladislav Michl's arch/arm/mach-omap1/board-voiceblue.c.
This patch is dependent on 8250 driver changes getting accepted upstream:
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=7053133124d5cdf207c1168c7a0c582a18e12ea7
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-ams-delta.c | 38 +
1 files changed, 38 insertions(+), 0 deletions(-)
Russel,
Unlike all others from the series, this one got no single comment from
you, niether your OK nor anything else. I'm not sure what that could
mean, but if there is still something I can do to help getting it into
2.6.32, please let me know.
Thanks,
Janusz
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index db4d9a4..40dfa63 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -15,8 +15,11 @@
#include linux/kernel.h
#include linux/init.h
#include linux/input.h
+#include linux/interrupt.h
#include linux/platform_device.h
+#include linux/serial_8250.h
+#include asm/serial.h
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -234,6 +237,41 @@ static void __init ams_delta_init(void)
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
}
+static struct plat_serial8250_port ams_delta_modem_ports[] = {
+ {
+ .membase= (void *) AMS_DELTA_MODEM_VIRT,
+ .mapbase= AMS_DELTA_MODEM_PHYS,
+ .irq= -EINVAL, /* changed later */
+ .flags = UPF_BOOT_AUTOCONF,
+ .irqflags = IRQF_TRIGGER_RISING,
+ .iotype = UPIO_MEM,
+ .regshift = 1,
+ .uartclk= BASE_BAUD * 16,
+ },
+ { },
+};
+
+static struct platform_device ams_delta_modem_device = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM1,
+ .dev= {
+ .platform_data = ams_delta_modem_ports,
+ },
+};
+
+static int __init ams_delta_modem_init(void)
+{
+ omap_cfg_reg(M14_1510_GPIO2);
+ ams_delta_modem_ports[0].irq = gpio_to_irq(2);
+
+ ams_delta_latch2_write(
+ AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+
+ return platform_device_register(ams_delta_modem_device);
+}
+arch_initcall(ams_delta_modem_init);
+
static void __init ams_delta_map_io(void)
{
omap1_map_common_io();
--
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: SDP support seems broken in LO
Move to 2008q3 or 2009q1 as a workaround. Thanks Anand... it came up. :) -vimal - Anand -- 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
OMAPFB: LL pointer dereference because of uninitialized mutex
Hello, I'm trying to add support for a omap3 board. But I get a NULL pointer dereference during initialization of the lcd panel driver because framebufferInfo-mm_lock wasn't initialized. Code of the lcd driver: http://pastebin.com/m44ccc56d (nothing special) Stack trace: __mutex_lock_slowpath() mutex_lock() set_fb_fix() omapfb_do_probe() devkit8000_panel_probe() my probe function platform_drv_probe() ... It get's initialized in register_framebuffer() but in my case the probe function gets called before register_framebuffer(). Once I added the missing inits to framebuffer_alloc() (drivers/video/fbsysfs.c) it works fine: mutex_init(info-lock); mutex_init(info-mm_lock); How I'm intended to fix this? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 v3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter
Mark Brown wrote: On Mon, Aug 17, 2009 at 12:26:05PM +0300, Jarkko Nikula wrote: I'm fine with this 3rd version. Probably Mark would like to have git format-patch formatted version for avoiding manual commit log editing. Acked-by: Jarkko Nikula jhnik...@gmail.com Applied both 2-3, thanks. Jarkko, Mark, Thanks. And now, how is the patch 1/3 supposed to get into the mainline? Whom should I ping from time to time to get it integrated? If not then, as you know for sure, applying patch 2/3 whithout 1/3 will result in ASoC support for OMAP1510 broken. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Fix incorrect 730 vs 850 detection (Re: [PATCH] Fix mismatched ifdefs)
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, August 18, 2009 3:30 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: [PATCH] OMAP: Fix incorrect 730 vs 850 detection (Re: [PATCH] Fix mismatched ifdefs) * Premi, Sanjeev pr...@ti.com [090817 17:56]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, August 17, 2009 8:15 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] Fix mismatched ifdefs * Sanjeev Premi pr...@ti.com [090817 13:59]: The #endif at end of the file was missing. However, an additional #else ... #endif was causing the compiler to keep going. The problem was found when compiler started reporting the newly added inline functions were being reported as redeclared by the compiler. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 11e73d9..4fbc6a9 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -317,8 +317,6 @@ IS_OMAP_TYPE(3430, 0x3430) # undef cpu_is_omap730 # define cpu_is_omap730() 1 # endif -#endif -#else Hmm, to me it looks like this should remove the second #endif, but keep the #else for the !MULTI_OMAP1 configurations. [sp] I did the maching as annotated in the snippet below: #if defined(MULTI_OMAP1) # if defined(CONFIG_ARCH_OMAP730) # undef cpu_is_omap730 # define cpu_is_omap730() is_omap730() # endif # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() is_omap850() # endif #else /* sp - else for multi-omap1 */ # if defined(CONFIG_ARCH_OMAP730) # undef cpu_is_omap730 # define cpu_is_omap730() 1 # endif #endif #else /* sp - seems like needed in the else path of MULTI_OMAP1 * else the symbol could go undefined. */ # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() 1 # endif #endif # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() 1 @@ -433,3 +431,5 @@ IS_OMAP_TYPE(3430, 0x3430) int omap_chip_is(struct omap_chip_id oci); void omap2_check_revision(void); + +#endif /* __ASM_ARCH_OMAP_CPU_H */ And this should not be needed. [sp] So where does this end: #ifndef __ASM_ARCH_OMAP_CPU_H #define __ASM_ARCH_OMAP_CPU_H I was hitting the problem possibly due to mutiple inclusion of cpu.h Any static inline function declared at bottom of cpu.h gets the errors like: arch/arm/plat-omap/include/mach/cpu.h:465: error: redefinition of 'omap3_has_iva' arch/arm/plat-omap/include/mach/cpu.h:465: error: previous definition of 'omap3_has_iva' was here Here's what I think is the right fix to this, the extra endif got introduced with the 850 patch. Removing that is not the right fix still, we just need to remove the special case for 730 as now we need to detect between 730 and 850. Can please you try the attached patch? Tony, This patch is able to match the ifdefs locally where the OMAP5730 and OMAP850 is being done. However, the #ifndef in the beginning of the files is still not terminated. I mentioned this yesterday as well... Here is the snippet compiler error: from include/linux/interrupt.h:12, from include/linux/kernel_stat.h:8, from init/main.c:33: arch/arm/plat-omap/include/mach/cpu.h:30:1: error: unterminated #ifndef make[1]: *** [init/main.o] Error 1 The file needs an endif at bottom #endif /* __ASM_ARCH_OMAP_CPU_H */ Best regards, Sanjeev Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Wang Limei-E12499 e12...@motorola.com writes:
Seems like I did not submit the patch in the right way, before I setup
my mail correctly, attach the patches in the mail.
You're patches are still line-wrapped.
I strongly recommend using git-format-patch and git-send-email to
submit patches. Chunqiu was able to do this. Please consult him.
Also, no need to CC linux-omap-owner. linux-omap is all that is needed.
Thanks,
Kevin
PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch
From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Fri, 14 Aug 2009 17:34:32 +0800
Subject: [PATCH] Add per-resource mutex for OMAP resource framework
Current OMAP resource fwk uses a global res_mutex
for resource_request and resource_release calls
for all the available resources.It may cause dead
lock if resource_request/resource_release is called
recursively.
For current OMAP3 VDD1/VDD2 resource, the change_level
implementation is mach-omap2/resource34xx.c/set_opp(),
when using resource_release to remove vdd1 constraint,
this function may call resource_release again to release
Vdd2 constrait if target vdd1 level is less than OPP3.
in this scenario, the global res_mutex down operation
will be called again, this will cause the second
down operation hang there.
To fix the problem, per-resource mutex is added
to avoid hangup when resource_request/resource_release
is called recursively.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h |2 ++
arch/arm/plat-omap/resource.c | 27
+++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..d482fb8 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -46,6 +46,8 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ /* Protect each resource */
+ struct mutex resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..5eae4e8 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ mutex_init(resp-resource_mutex);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
*dev,
user-level = level;
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
/*
* Recompute and set the current level for the resource.
* NOTE: update_resource level moved out of spin_lock, as it may
call
@@ -371,6 +372,7 @@ res_unlock:
*/
if (!ret)
ret = update_resource_level(resp);
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +395,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +423,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_release);
@@ -438,15 +442,14 @@ int resource_get_level(const char *name)
struct shared_resource *resp;
u32 ret;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp =
Re: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Wang Limei-E12499 e12...@motorola.com writes:
Seems like I did not submit the patch in the right way, before I setup
my mail correctly, attach the patches in the mail.
You're patches are still line-wrapped.
I strongly recommend using git-format-patch and git-send-email to
submit patches. Chunqiu was able to do this. Please consult him.
Also, no need to CC linux-omap-owner. linux-omap is all that is needed.
Thanks,
Kevin
PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch
From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Fri, 14 Aug 2009 17:34:32 +0800
Subject: [PATCH] Add per-resource mutex for OMAP resource framework
Current OMAP resource fwk uses a global res_mutex
for resource_request and resource_release calls
for all the available resources.It may cause dead
lock if resource_request/resource_release is called
recursively.
For current OMAP3 VDD1/VDD2 resource, the change_level
implementation is mach-omap2/resource34xx.c/set_opp(),
when using resource_release to remove vdd1 constraint,
this function may call resource_release again to release
Vdd2 constrait if target vdd1 level is less than OPP3.
in this scenario, the global res_mutex down operation
will be called again, this will cause the second
down operation hang there.
To fix the problem, per-resource mutex is added
to avoid hangup when resource_request/resource_release
is called recursively.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h |2 ++
arch/arm/plat-omap/resource.c | 27
+++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..d482fb8 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -46,6 +46,8 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ /* Protect each resource */
+ struct mutex resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..5eae4e8 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ mutex_init(resp-resource_mutex);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
*dev,
user-level = level;
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
/*
* Recompute and set the current level for the resource.
* NOTE: update_resource level moved out of spin_lock, as it may
call
@@ -371,6 +372,7 @@ res_unlock:
*/
if (!ret)
ret = update_resource_level(resp);
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +395,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +423,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_release);
@@ -438,15 +442,14 @@ int resource_get_level(const char *name)
struct shared_resource *resp;
u32 ret;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp =
RE: [PATCH] omap_hsmmc: Fix for the db clock failure message
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, August 18, 2009 1:53 AM
To: Madhusudhan Chikkature
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk
Subject: Re: [PATCH] omap_hsmmc: Fix for the db clock failure message
Madhusudhan Chikkature wrote:
This patch applies on top of the series [PATCH V2 0/32] mmc and
omap_hsmmc
patches posted by Adrian Hunter.
-
This patch removes the error message Failed to get debounce clock..
printed
out by the HSMMC driver on OMAP3430. The debounce clock needs to be
handled only
for OMAP2430.
I have a suggestion that may make it tidier.
What about renaming host-dbclk_enabled to host-got_dbclk and leaving it
alone
after it is set in the probe function. Then create a macro to use in
conditions:
#define have_dbclk(host) (cpu_is_omap2430() (host)-got_dbclk)
So the following:
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
becomes:
- if (host-dbclk_enabled)
+ if (have_dbclk(host))
clk_disable(host-dbclk);
Or alternatively, forget the macro, and let the code always compile in:
- if (host-dbclk_enabled)
+ if (host-got_dbclk)
clk_disable(host-dbclk);
In both the cases how about the enable path? We want to enable the debounce
clock only for OMAP2430, Right? Otherwise we will still end up throwing an
error message for 3430 if we check the result of clk_enable for db clock.
Regards,
Madhu
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 63 +++---
1 file changed, 41 insertions(+), 22 deletions(-)
Index: linux-2.6/drivers/mmc/host/omap_hsmmc.c
===
--- linux-2.6.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-2.6/drivers/mmc/host/omap_hsmmc.c
@@ -735,8 +735,10 @@ static int omap_hsmmc_switch_opcond(stru
/* Disable the clocks */
clk_disable(host-fclk);
clk_disable(host-iclk);
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
/* Turn the power off */
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
@@ -746,9 +748,14 @@ static int omap_hsmmc_switch_opcond(stru
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 1,
vdd);
clk_enable(host-iclk);
- if (host-dbclk_enabled)
- clk_enable(host-dbclk);
clk_enable(host-fclk);
+ if (cpu_is_omap2430() !host-dbclk_enabled) {
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling debounce
+clk failed\n);
+ else
+ host-dbclk_enabled = 1;
+ }
if (ret != 0)
goto err;
@@ -1697,18 +1704,21 @@ static int __init omap_hsmmc_probe(struc
goto err1;
}
- host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
- /*
-* MMC can still work without debounce clock.
-*/
- if (IS_ERR(host-dbclk))
- dev_warn(mmc_dev(host-mmc), Failed to get debounce
clock\n);
- else
- if (clk_enable(host-dbclk) != 0)
- dev_dbg(mmc_dev(host-mmc), Enabling debounce
-clk failed\n);
+ if (cpu_is_omap2430()) {
+ host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
+ /*
+* MMC can still work without debounce clock.
+*/
+ if (IS_ERR(host-dbclk))
+ dev_warn(mmc_dev(host-mmc),
+ Failed to get debounce clock\n);
else
- host-dbclk_enabled = 1;
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling
debounce
+clk failed\n);
+ else
+ host-dbclk_enabled = 1;
+ }
/* Since we do only SG emulation, we can have as many segs
* as we want. */
@@ -1825,8 +1835,9 @@ err_irq:
clk_disable(host-iclk);
clk_put(host-fclk);
clk_put(host-iclk);
- if (host-dbclk_enabled) {
- clk_disable(host-dbclk);
+ if (cpu_is_omap2430()) {
+ if (host-dbclk_enabled)
+ clk_disable(host-dbclk);
clk_put(host-dbclk);
}
@@ -1859,8 +1870,9 @@ static int omap_hsmmc_remove(struct plat
RE: [Resend][PATCH] Maintainers update for hsmmc driver
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, August 18, 2009 7:43 AM To: Kevin Hilman Cc: Madhusudhan Chikkature; linux-omap@vger.kernel.org; jarkko.lavi...@nokia.com; adrian.hun...@nokia.com; felipe.ba...@nokia.com Subject: Re: [Resend][PATCH] Maintainers update for hsmmc driver * Kevin Hilman khil...@deeprootsystems.com [090814 00:39]: Madhusudhan Chikkature madhu...@ti.com writes: Hi, Resending the patch after changing omap_hs* to omap_hsmmc.c. Regards, Madhu Update maintainers entry for TI OMAP HS MMC support. Signed-off-by: Madhusudhan Chikkature madhu...@ti.com Madhu is the right guy for the job. Acked-by: Kevin Hilman khil...@deeprootsystems.com This should go in via the new linux-...@vger.kernel.org list. Tony Sure. I will post this patch to the linux-...@vger.kernel.org list. Regards, Madhu --- MAINTAINERS |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) Index: linux-omap-2.6/MAINTAINERS === --- linux-omap-2.6.orig/MAINTAINERS +++ linux-omap-2.6/MAINTAINERS @@ -3698,7 +3698,13 @@ OMAP MMC SUPPORT M: Jarkko Lavinen jarkko.lavi...@nokia.com L: linux-omap@vger.kernel.org S: Maintained -F: drivers/mmc/host/*omap* +F: drivers/mmc/host/omap.c + +OMAP HS MMC SUPPORT +M: Madhusudhan Chikkature madhu...@ti.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/mmc/host/omap_hsmmc.c OMAP RANDOM NUMBER GENERATOR SUPPORT M: Deepak Saxena dsax...@plexity.net -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Maintainers update for TI OMAP hsmmc driver
Update maintainers entry for TI OMAP HS MMC support. Signed-off-by: Madhusudhan Chikkature madhu...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com --- MAINTAINERS |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) Index: linux-omap-2.6/MAINTAINERS === --- linux-omap-2.6.orig/MAINTAINERS +++ linux-omap-2.6/MAINTAINERS @@ -3698,7 +3698,13 @@ OMAP MMC SUPPORT M: Jarkko Lavinen jarkko.lavi...@nokia.com L: linux-omap@vger.kernel.org S: Maintained -F: drivers/mmc/host/*omap* +F: drivers/mmc/host/omap.c + +OMAP HS MMC SUPPORT +M: Madhusudhan Chikkature madhu...@ti.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/mmc/host/omap_hsmmc.c OMAP RANDOM NUMBER GENERATOR SUPPORT M: Deepak Saxena dsax...@plexity.net -- 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] Runtime detection of OMAP35x devices
Add runtime check for these OMAP35x variations
based on the detected Si features:
OMAP3503, OMAP3515, OMAP3525 and OMA3530.
Also, delayed the call to pr_info() into actual
variant is detected in omap3_cpuinfo()
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c | 59 +++-
arch/arm/plat-omap/include/mach/cpu.h | 25 ++
2 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..f041d3b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -187,7 +187,6 @@ void __init omap3_check_revision(void)
u32 cpuid, idcode;
u16 hawkeye;
u8 rev;
- char *rev_name = ES1.0;
/*
* We cannot access revision registers on ES1.0.
@@ -197,7 +196,7 @@ void __init omap3_check_revision(void)
cpuid = read_cpuid(CPUID_ID);
if cpuid 4) 0xfff) == 0xc08) ((cpuid 0xf) == 0x0)) {
omap_revision = OMAP3430_REV_ES1_0;
- goto out;
+ return;
}
/*
@@ -214,29 +213,21 @@ void __init omap3_check_revision(void)
switch (rev) {
case 0:
omap_revision = OMAP3430_REV_ES2_0;
- rev_name = ES2.0;
break;
case 2:
omap_revision = OMAP3430_REV_ES2_1;
- rev_name = ES2.1;
break;
case 3:
omap_revision = OMAP3430_REV_ES3_0;
- rev_name = ES3.0;
break;
case 4:
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = ES3.1;
break;
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = Unknown revision\n;
}
}
-
-out:
- pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
}
#define OMAP3_SHOW_FEATURE(feat) \
@@ -248,6 +239,54 @@ out:
void __init omap3_cpuinfo(void)
{
+ u8 rev = GET_OMAP_REVISION();
+ char cpu_name[16], cpu_rev[16];
+
+ /* OMAP3430 and OMAP3530 are assumed to be same.
+*
+* OMAP3525, OMAP3515 and OMAP3503 can be detected only based
+* on available features. Upon detection, update the CPU id
+* and CPU class bits.
+*/
+ if (omap3_has_iva() omap3_has_sgx()) {
+ strcpy(cpu_name, 3430/3530);
+ }
+ else if (omap3_has_sgx()) {
+ omap_revision = OMAP3525_REV (rev);
+ strcpy(cpu_name, 3525);
+ }
+ else if (omap3_has_iva()) {
+ omap_revision = OMAP3515_REV (rev);
+ strcpy(cpu_name, 3515);
+ }
+ else {
+ omap_revision = OMAP3503_REV (rev);
+ strcpy(cpu_name, 3503);
+ }
+
+ switch (rev) {
+ case 0x10:
+ strcpy(cpu_rev, 2.0);
+ break;
+ case 0x20:
+ strcpy(cpu_rev, 2.1);
+ break;
+ case 0x30:
+ strcpy(cpu_rev, 3.0);
+ break;
+ case 0x40:
+ strcpy(cpu_rev, 3.1);
+ break;
+ default:
+ /* Use the latest known revision as default */
+ strcpy(cpu_rev, 3.1);
+ }
+
+ /*
+* Print verbose information
+*/
+ pr_info(OMAP%s ES%s\n, cpu_name, cpu_rev);
+
OMAP3_SHOW_FEATURE(l2cache);
OMAP3_SHOW_FEATURE(iva);
OMAP3_SHOW_FEATURE(sgx);
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index 4a04f77..a0dbbb4 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -57,6 +57,11 @@ struct omap_chip_id {
unsigned int omap_rev(void);
/*
+ * Get the CPU revision for OMAP devices
+ */
+#define GET_OMAP_REVISION()((omap_rev() 8) 0xff)
+
+/*
* Test if multicore OMAP support is needed
*/
#undef MULTI_OMAP1
@@ -360,7 +365,21 @@ IS_OMAP_TYPE(3430, 0x3430)
#if defined(CONFIG_ARCH_OMAP34XX)
# undef cpu_is_omap3430
+# undef cpu_is_omap3503
+# undef cpu_is_omap3515
+# undef cpu_is_omap3525
+# undef cpu_is_omap3530
# define cpu_is_omap3430() is_omap3430()
+# define cpu_is_omap3503 (cpu_is_omap3430() \
+ (!omap3_has_iva()) \
+ (!omap3_has_sgx()))
+# define cpu_is_omap3515 (cpu_is_omap3430() \
+ (omap3_has_iva()) \
+ (!omap3_has_sgx()))
+# define cpu_is_omap3525
Re: [PATCH 3/3 v3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter
On Tue, 18 Aug 2009 14:45:41 +0100 Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Aug 18, 2009 at 03:42:05PM +0200, Janusz Krzysztofik wrote: And now, how is the patch 1/3 supposed to get into the mainline? Whom should I ping from time to time to get it integrated? If not then, as you know for sure, applying patch 2/3 whithout 1/3 will result in ASoC support for OMAP1510 broken. Normally the OMAP tree, though that's possibly a bit tricky due to the ARM tree closing early. If Tony's OK with merging via the ALSA tree we could also apply the ARM patch there? I would say that it's better to keep in Tony's hand since otherwise there can be risk for DMA code being out-of-sync as there are quite frequent other PM, OMAP4, errata, etc. patches coming into it. Of course it means that OMAP1510 audio is broken until the patch 1/3 is merged but probably patch can be merged as a fix if merge window is missed. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap_hsmmc: Fix for the db clock failure message
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Madhusudhan
Sent: Tuesday, August 18, 2009 10:27 AM
To: 'Adrian Hunter'
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk
Subject: RE: [PATCH] omap_hsmmc: Fix for the db clock failure message
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, August 18, 2009 1:53 AM
To: Madhusudhan Chikkature
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk
Subject: Re: [PATCH] omap_hsmmc: Fix for the db clock failure message
Madhusudhan Chikkature wrote:
This patch applies on top of the series [PATCH V2 0/32] mmc and
omap_hsmmc
patches posted by Adrian Hunter.
-
This patch removes the error message Failed to get debounce clock..
printed
out by the HSMMC driver on OMAP3430. The debounce clock needs to be
handled only
for OMAP2430.
I have a suggestion that may make it tidier.
What about renaming host-dbclk_enabled to host-got_dbclk and leaving
it
alone
after it is set in the probe function. Then create a macro to use in
conditions:
#define have_dbclk(host) (cpu_is_omap2430() (host)-got_dbclk)
So the following:
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
becomes:
- if (host-dbclk_enabled)
+ if (have_dbclk(host))
clk_disable(host-dbclk);
Or alternatively, forget the macro, and let the code always compile in:
- if (host-dbclk_enabled)
+ if (host-got_dbclk)
clk_disable(host-dbclk);
In both the cases how about the enable path? We want to enable the
debounce
clock only for OMAP2430, Right? Otherwise we will still end up throwing an
error message for 3430 if we check the result of clk_enable for db clock.
Regards,
Madhu
I got your point after looking at the patch again. I guess you want to set
the host-got_dbclk only once in probe if the clk_get succeeds for db clk
and handle clk_enable/disable only based on got_dbclk. That should be fine.
I will resubmit the patch.
Regards,
Madhu
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 63 +++-
--
1 file changed, 41 insertions(+), 22 deletions(-)
Index: linux-2.6/drivers/mmc/host/omap_hsmmc.c
===
--- linux-2.6.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-2.6/drivers/mmc/host/omap_hsmmc.c
@@ -735,8 +735,10 @@ static int omap_hsmmc_switch_opcond(stru
/* Disable the clocks */
clk_disable(host-fclk);
clk_disable(host-iclk);
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
/* Turn the power off */
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
@@ -746,9 +748,14 @@ static int omap_hsmmc_switch_opcond(stru
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 1,
vdd);
clk_enable(host-iclk);
- if (host-dbclk_enabled)
- clk_enable(host-dbclk);
clk_enable(host-fclk);
+ if (cpu_is_omap2430() !host-dbclk_enabled) {
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling debounce
+ clk failed\n);
+ else
+ host-dbclk_enabled = 1;
+ }
if (ret != 0)
goto err;
@@ -1697,18 +1704,21 @@ static int __init omap_hsmmc_probe(struc
goto err1;
}
- host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
- /*
- * MMC can still work without debounce clock.
- */
- if (IS_ERR(host-dbclk))
- dev_warn(mmc_dev(host-mmc), Failed to get debounce
clock\n);
- else
- if (clk_enable(host-dbclk) != 0)
- dev_dbg(mmc_dev(host-mmc), Enabling debounce
- clk failed\n);
+ if (cpu_is_omap2430()) {
+ host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
+ /*
+ * MMC can still work without debounce clock.
+ */
+ if (IS_ERR(host-dbclk))
+ dev_warn(mmc_dev(host-mmc),
+ Failed to get debounce clock\n);
else
- host-dbclk_enabled = 1;
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling
debounce
+
FW: [patch 4/9] mmc: add the new linux-mmc mailing list to MAINTAINERS
-Original Message- From: Andrew Morton [mailto:a...@linux-foundation.org] Sent: Tuesday, August 18, 2009 5:17 PM To: Madhusudhan Cc: torva...@linux-foundation.org; haraldwe...@viatech.com; josephc...@via.com.tw; ben-li...@fluff.org; drz...@drzeus.cx; i...@mnementh.co.uk; jarkko.lavi...@nokia.com; linux-...@vger.kernel.org; manuel.la...@gmail.com; n...@cam.org; pp...@pikron.com; saschasom...@freenet.de Subject: Re: [patch 4/9] mmc: add the new linux-mmc mailing list to MAINTAINERS On Tue, 18 Aug 2009 17:08:40 -0500 Madhusudhan madhu...@ti.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of a...@linux-foundation.org Sent: Tuesday, August 18, 2009 4:11 PM To: torva...@linux-foundation.org Cc: a...@linux-foundation.org; haraldwe...@viatech.com; josephc...@via.com.tw; ben-li...@fluff.org; drz...@drzeus.cx; i...@mnementh.co.uk; jarkko.lavi...@nokia.com; linux- m...@vger.kernel.org; manuel.la...@gmail.com; n...@cam.org; pp...@pikron.com; saschasom...@freenet.de Subject: [patch 4/9] mmc: add the new linux-mmc mailing list to MAINTAINERS From: Andrew Morton a...@linux-foundation.org There are a number of individual MMC drivers listed in MAINTAINERS. I didn't modify those records. Perhaps I should have. Does this mean that the individual MMC drivers list needs to be changed to linux-...@vger.kernel.org? For e.g. the OMAP MMC support currently listed as L: linux-omap@vger.kernel.org Should now be changed as below? L: linux-...@vger.kernel.org I don't know - that's why I cc'ed all you guys. If you think that linux-mmc should be mentioned in your driver's MAINTAINERS record then please raise a patch to make that change. Hi Tony, Jarkko, What is your opinion? The patch I posted earlier today to linux-...@vger.kernel.org list for HSMMC updation did not make this change to the list name. If you guys agree with this change I can post it back combining the HS MMC entry. Regards, Madhu -- 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: Pull request for OMAP PM, clock, SDRC 2.6.32 patches
Hi Paul, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, August 18, 2009 7:36 AM To: Russell King - ARM Linux I'm afraid to say that I think you've left it far too late to send this. I did set a date of the 16th as being the final date to sort out stuff (which was flexible to a degree) but since these patches were only posted on Saturday, and they're still being discussed, I don't think it would make sense for me to pull it today. I've dropped the two patches that are being discussed and reposted the remainder. The updated series is here (et seq.): http://marc.info/?l=linux-arm-kernelm=125059872200340w=2 and the pull request is here: http://marc.info/?l=linux-arm-kernelm=125059845132331w=2 Does this series conflict with patches already submitted on OMAP4? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15488.html I'm not able to check now but its best to be careful here. Thanks, Richard W. -- 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: Pull request for OMAP PM, clock, SDRC 2.6.32 patches
Hello Richard, On Tue, 18 Aug 2009, Woodruff, Richard wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, August 18, 2009 7:36 AM To: Russell King - ARM Linux I've dropped the two patches that are being discussed and reposted the remainder. The updated series is here (et seq.): http://marc.info/?l=linux-arm-kernelm=125059872200340w=2 and the pull request is here: http://marc.info/?l=linux-arm-kernelm=125059845132331w=2 Does this series conflict with patches already submitted on OMAP4? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15488.html I'm not able to check now but its best to be careful here. The series cannot conflict with Rajendra's patches 1-3, since there are no files in common between the two series. As for patches 4-6, there are comments pending: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15568.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Pull request for OMAP PM, clock, SDRC 2.6.32 patches
From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, August 18, 2009 6:27 PM To: Woodruff, Richard The series cannot conflict with Rajendra's patches 1-3, since there are no files in common between the two series. As for patches 4-6, there are comments pending: OK, there are recent comments, good, but is it conflicting? Thanks for clarifying, I'm not able to do a check right now and am hoping they don't interfere. Hopefully the series are not all too inter-related. Seems like getting to multiple and smaller feature branches will reduce collisions. Any big branch carries more risk (and potential reward also I suppose). Regards, Richard W. -- 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] OMAP2/3: Add support for flash on SDP boards
Add support for flash on SDP boards. NAND, NOR and OneNAND are supported. Only tested on 3430SDP (ES2 and ES3.1), somebody please test on 2430SDP and check the chips select for 2430SDP. Also note that: For OneNAND: in the earlier 2430SDP code the kernel partition was set to only 1MB instead of 2MB on 3430SDP. If people want the old partition sizes back on 2430SDP, please provide a patch. For NAND: 'U-Boot', 'Boot Env' and 'Kernel' partitions sizes increased by few blocks to provide few spare blocks for NAND bab block management in u-boot. If people want old partition sizes, please provide a patch. Signed-off-by: Vimal Singh vimalsi...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Makefile |2 arch/arm/mach-omap2/board-2430sdp.c|2 arch/arm/mach-omap2/board-3430sdp.c|2 arch/arm/mach-omap2/board-sdp-flash.c | 326 + arch/arm/mach-omap2/board-sdp.h| 15 + arch/arm/plat-omap/include/mach/gpmc.h |2 6 files changed, 349 insertions(+) Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile === --- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile +++ linux-omap-2.6/arch/arm/mach-omap2/Makefile @@ -48,6 +48,7 @@ obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y) obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ @@ -61,6 +62,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-om obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ Index: linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-2430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c @@ -38,6 +38,7 @@ #include mach/usb.h #include mach/gpmc-smc91x.h +#include board-sdp.h #include mmc-twl4030.h #define SDP2430_CS0_BASE 0x0400 @@ -210,6 +211,7 @@ static void __init omap_2430sdp_init(voi twl4030_mmc_init(mmc); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); /* Turn off secondary LCD backlight */ ret = gpio_request(SECONDARY_LCD_GPIO, Secondary LCD backlight); Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c @@ -41,6 +41,7 @@ #include mach/keypad.h #include mach/gpmc-smc91x.h +#include board-sdp.h #include sdram-qimonda-hyb18m512160af-6.h #include mmc-twl4030.h @@ -494,6 +495,7 @@ static void __init omap_3430sdp_init(voi omap_serial_init(sdp3430_uart_config); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61); } Index: linux-omap-2.6/arch/arm/mach-omap2/board-sdp-flash.c === --- /dev/null +++ linux-omap-2.6/arch/arm/mach-omap2/board-sdp-flash.c @@ -0,0 +1,326 @@ +/* + * arch/arm/mach-omap2/board-sdp-flash.c + * + * Copyright (C) 2009 Nokia Corporation + * Copyright (C) 2009 Texas Instruments + * + * Modified from mach-omap2/board-3430sdp-flash.c + * Author: Vimal Singh vimalsi...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/kernel.h +#include linux/platform_device.h +#include linux/mtd/mtd.h +#include linux/mtd/partitions.h +#include linux/io.h + +#include asm/mach/flash.h +#include mach/onenand.h +#include mach/gpmc.h +#include mach/nand.h + +#define REG_FPGA_REV 0x10 +#define REG_FPGA_DIP_SWITCH_INPUT2 0x60 +#define MAX_SUPPORTED_GPMC_CONFIG 3 + +/* various memory sizes */ +#define FLASH_SIZE_SDPV1 SZ_64M +#define FLASH_SIZE_SDPV2 SZ_128M + +#define FLASH_BASE_SDPV1 0x0400 /* NOR flash (64 Meg aligned) */ +#define FLASH_BASE_SDPV2 0x1000 /* NOR flash (256 Meg aligned) */ + +#define DEBUG_BASE 0x0800 /* debug board */ +
Where is DSP Gateway
Hi All, We had been using dspgateway 3.3 on 2.6.16. Recently we changed our kernel to 2.6.29 and we found that the dspgateway driver has been removed from the tree ( http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2512fd29db4eb09e82d182596304c7aaf76d2c5c). What do I do, If I want to use the dspgateway on 2.6.29? I tried searching the patch for dspgateway on 2.6.29, but found none except this http://archive.netbsd.se/?ml=linux-kernela=2009-07m=11155350 Any pointers would be really helpful Thanks in advance, Suresh -- 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
linux-next: manual merge of the omap tree with the arm tree
Hi all,
Today's linux-next merge of the omap tree got a conflict in
arch/arm/mach-omap2/board-4430sdp.c between commit
085b54d99b8ee999e7905b8f16e201e0da8ba369 (ARM: OMAP4: Add UART4
support) from the arm tree and commit
4c29fa3e47342666e12e46f35f40dd90b12cd1a4 (OMAP: remove OMAP_TAG_UART)
from the omap tree.
Just context changes (I think). I fixed it up (see below) and can carry
the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-4430sdp.c
index 1b22307,646079f..000
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@@ -38,8 -38,8 +38,8 @@@ static struct platform_device *sdp4430_
sdp4430_lcd_device,
};
- static struct omap_uart_config sdp4430_uart_config __initdata = {
+ static struct omap_uart_platform_data sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 0) | (1 1) | (1 2),
+ .enabled_uarts = (1 0) | (1 1) | (1 2) | (1 3),
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
--
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
