Re: MFD USB host: prevents CORE retention in idle
On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin Ok, I will test this. regards keshava -- 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] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the latency of the low power code.
How much do we really save doing this? I understand what you are doing
by looking at the patch but the changelog seems very confusing.
What the patch does is get rid of a few function indirection
and assumes there is only *one* clkdm for mpu and core. Is that right?
regards,
Rajendra
The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 2e2f1c6..e6ae3fe 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -77,20 +77,6 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_deny_idle(clkdm);
- return 0;
-}
-
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -108,8 +94,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
}
/*
@@ -131,8 +117,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Re-allow idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
}
return_sleep_time:
--
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] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayak rna...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the latency of the low power code.
How much do we really save doing this? I understand what you are doing
by looking at the patch but the changelog seems very confusing.
The gain is on the registers accesses and the internal PRCM state machine.
If needed the changelog can be updated.
What the patch does is get rid of a few function indirection
and assumes there is only *one* clkdm for mpu and core. Is that right?
Not exactly. The patch does not assume that there is only one clkdm
per power domain. It just allows or denies only one clkdm to idle,
which has the same effect at the power domain level.
Thanks for reviewing,
Jean
regards,
Rajendra
The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 2e2f1c6..e6ae3fe 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -77,20 +77,6 @@ static struct omap3_idle_statedata omap3_idle_data[] =
{
static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_deny_idle(clkdm);
- return 0;
-}
-
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -108,8 +94,8 @@ static int __omap3_enter_idle(struct cpuidle_device
*dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
}
/*
@@ -131,8 +117,8 @@ static int __omap3_enter_idle(struct cpuidle_device
*dev,
/* Re-allow idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
}
return_sleep_time:
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: new cache maintenance api for iommu mem flush
On Tue, Jun 19, 2012 at 04:51:07PM +0530, Gupta, Ramesh wrote: From 785a1f2854002ce7c1c8880bc5d8d92a7868bf1c Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Fri, 15 Jun 2012 16:37:20 +0530 Subject: [PATCH v2 1/4] ARM: new cache maintenance api for iommu mem flush non-coherent IOMMUs need to make sure that the data held in the caches need to be visible for the MMU hardware. A new L1 cache maintenance api has been created to handle this. Thanks to RMK's suggestions on creating a dedicated API for this purpose. ref: http://marc.info/?l=linux-kernelm=131316512713815w=2 Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/include/asm/cacheflush.h | 17 + arch/arm/include/asm/glue-cache.h |1 + arch/arm/mm/proc-macros.S |1 + 3 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h index d5d8d5c..2b4f5aa 100644 --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -84,6 +84,11 @@ * - kaddr - page address * - size - region size * + * flush_mem(start, end) + * + * Clean and invalidate the specified virtual address range. + * - start - virtual start address + * - end- virtual end address You're missing a blank line here. Also, flush_mem is a very lame name - it tells us nothing about what the purpose of this new API is. Should it be used for when the CPU MMU TLB entries are changed? What about if we're suspending, should it be used then? What about if we're performing DMA - should it be used for that memory too? Please, give it a better name which describes what it is for. diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S index 2d8ff3a..f48a5ab 100644 --- a/arch/arm/mm/proc-macros.S +++ b/arch/arm/mm/proc-macros.S @@ -307,6 +307,7 @@ ENTRY(\name\()_cache_fns) .long \name\()_dma_map_area .long \name\()_dma_unmap_area .long \name\()_dma_flush_range + .long \name\()_flush_mem .size \name\()_cache_fns, . - \name\()_cache_fns .endm This will immediately break the kernel compilation. Therefore, your patch is incomplete and unsuitable for applying. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: add flush_mem api for ARMv6
On Tue, Jun 19, 2012 at 04:51:16PM +0530, Gupta, Ramesh wrote: From 630a3a8f341eb7f58f9a63bf786d732b5bdfd01e Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Fri, 15 Jun 2012 16:39:21 +0530 Subject: [PATCH v2 2/4] ARM: add flush_mem api for ARMv6 Added flush_mem cache maintenance api for ARMv6. The implementation is based on dma_flush_range. And what about all the other users of the define_cache_functions macro? This series is incomplete, and therefore entirely unsuitable for upstreaming. -- 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] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote:
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayakrna...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the latency of the low power code.
How much do we really save doing this? I understand what you are doing
by looking at the patch but the changelog seems very confusing.
The gain is on the registers accesses and the internal PRCM state machine.
If needed the changelog can be updated.
Can you explain a bit more on which register accesses are you talking
about? and some more on the PRCM state machine.
What the patch does is get rid of a few function indirection
and assumes there is only *one* clkdm for mpu and core. Is that right?
Not exactly. The patch does not assume that there is only one clkdm
per power domain. It just allows or denies only one clkdm to idle,
which has the same effect at the power domain level.
Ok, so lets assume mpu on OMAP3 has 2 clkdms, and you allow only one
of them to idle. Will that have the same effect at the power domain
level?
The first line of the change log says For a power domain to idle *all*
the clock domains in it must idle and now you say allowing only *one*
clkdm to idle should have the same effect at the power domain level.
I am confused.
Thanks for reviewing,
Jean
regards,
Rajendra
The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 2e2f1c6..e6ae3fe 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -77,20 +77,6 @@ static struct omap3_idle_statedata omap3_idle_data[] =
{
static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_deny_idle(clkdm);
- return 0;
-}
-
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -108,8 +94,8 @@ static int __omap3_enter_idle(struct cpuidle_device
*dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
}
/*
@@ -131,8 +117,8 @@ static int __omap3_enter_idle(struct cpuidle_device
*dev,
/* Re-allow idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
}
return_sleep_time:
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: serial: Change MAX_HSUART_PORTS to 6
Extends the maximum number of UART ports to 6 from 4 because AM335X device have six UART ports. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/plat-omap/include/plat/omap-serial.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index 1a52725..71eca9c 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -54,7 +54,7 @@ #define OMAP_UART_DMA_CH_FREE -1 -#define OMAP_MAX_HSUART_PORTS 4 +#define OMAP_MAX_HSUART_PORTS 6 #define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
Hi Jean,
On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote:
On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote:
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayakrna...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the latency of the low power code.
How much do we really save doing this? I understand what you are doing
by looking at the patch but the changelog seems very confusing.
The gain is on the registers accesses and the internal PRCM state
machine.
If needed the changelog can be updated.
Can you explain a bit more on which register accesses are you talking
about? and some more on the PRCM state machine.
never mind, I looked at the patch again and then the cpuidle code and
figured what you are doing. Makes sense to me now :-)
regards,
Rajendra
What the patch does is get rid of a few function indirection
and assumes there is only *one* clkdm for mpu and core. Is that right?
Not exactly. The patch does not assume that there is only one clkdm
per power domain. It just allows or denies only one clkdm to idle,
which has the same effect at the power domain level.
Ok, so lets assume mpu on OMAP3 has 2 clkdms, and you allow only one
of them to idle. Will that have the same effect at the power domain
level?
The first line of the change log says For a power domain to idle *all*
the clock domains in it must idle and now you say allowing only *one*
clkdm to idle should have the same effect at the power domain level.
I am confused.
Thanks for reviewing,
Jean
regards,
Rajendra
The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 2e2f1c6..e6ae3fe 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -77,20 +77,6 @@ static struct omap3_idle_statedata
omap3_idle_data[] =
{
static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_deny_idle(clkdm);
- return 0;
-}
-
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -108,8 +94,8 @@ static int __omap3_enter_idle(struct cpuidle_device
*dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
}
/*
@@ -131,8 +117,8 @@ static int __omap3_enter_idle(struct cpuidle_device
*dev,
/* Re-allow idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
}
return_sleep_time:
--
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] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
Jean, On Wednesday 20 June 2012 02:22 PM, Rajendra Nayak wrote: Hi Jean, On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote: On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote: Hi Rajendra, On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayakrna...@ti.com wrote: Hi Jean, On Friday 01 June 2012 08:41 PM, Jean Pihet wrote: For a power domain to idle all the clock domains in it must idle. This patch implements an optimization of the cpuidle code by denying and later allowing only the first registered clock domain of a power domain, and so optimizes the latency of the low power code. How much do we really save doing this? I understand what you are doing by looking at the patch but the changelog seems very confusing. The gain is on the registers accesses and the internal PRCM state machine. If needed the changelog can be updated. Can you explain a bit more on which register accesses are you talking about? and some more on the PRCM state machine. never mind, I looked at the patch again and then the cpuidle code and figured what you are doing. Makes sense to me now :-) How do you like this updated changelog, I just added one more line. For a power domain to idle all the clock domains in it must idle. Denying just *one* clkdm in a pwrdm from idling should have the same effect as denying *all*. This patch implements an optimization of the cpuidle code by denying and later allowing only the first registered clock domain of a power domain, and so optimizes the latency of the low power code. regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: new cache maintenance api for iommu mem flush
Hi Russell, On Wed, Jun 20, 2012 at 2:13 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 19, 2012 at 04:51:07PM +0530, Gupta, Ramesh wrote: From 785a1f2854002ce7c1c8880bc5d8d92a7868bf1c Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Fri, 15 Jun 2012 16:37:20 +0530 Subject: [PATCH v2 1/4] ARM: new cache maintenance api for iommu mem flush non-coherent IOMMUs need to make sure that the data held in the caches need to be visible for the MMU hardware. A new L1 cache maintenance api has been created to handle this. Thanks to RMK's suggestions on creating a dedicated API for this purpose. ref: http://marc.info/?l=linux-kernelm=131316512713815w=2 Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/include/asm/cacheflush.h | 17 + arch/arm/include/asm/glue-cache.h | 1 + arch/arm/mm/proc-macros.S | 1 + 3 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h index d5d8d5c..2b4f5aa 100644 --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -84,6 +84,11 @@ * - kaddr - page address * - size - region size * + * flush_mem(start, end) + * + * Clean and invalidate the specified virtual address range. + * - start - virtual start address + * - end - virtual end address You're missing a blank line here. I will fix it. Also, flush_mem is a very lame name - it tells us nothing about what the purpose of this new API is. Should it be used for when the CPU MMU TLB entries are changed? What about if we're suspending, should it be used then? What about if we're performing DMA - should it be used for that memory too? Please, give it a better name which describes what it is for. I agree, will choose a better name to describe the api. diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S index 2d8ff3a..f48a5ab 100644 --- a/arch/arm/mm/proc-macros.S +++ b/arch/arm/mm/proc-macros.S @@ -307,6 +307,7 @@ ENTRY(\name\()_cache_fns) .long \name\()_dma_map_area .long \name\()_dma_unmap_area .long \name\()_dma_flush_range + .long \name\()_flush_mem .size \name\()_cache_fns, . - \name\()_cache_fns .endm This will immediately break the kernel compilation. Therefore, your patch is incomplete and unsuitable for applying. I was checking only with panda configuration, I will update the patch set to take care of this. Thank you for review comments. -- regards Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: add flush_mem api for ARMv6
Hi Russell, On Wed, Jun 20, 2012 at 2:15 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 19, 2012 at 04:51:16PM +0530, Gupta, Ramesh wrote: From 630a3a8f341eb7f58f9a63bf786d732b5bdfd01e Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Fri, 15 Jun 2012 16:39:21 +0530 Subject: [PATCH v2 2/4] ARM: add flush_mem api for ARMv6 Added flush_mem cache maintenance api for ARMv6. The implementation is based on dma_flush_range. And what about all the other users of the define_cache_functions macro? I initially added only for ARMv6/7 and I will add this for the other users. This series is incomplete, and therefore entirely unsuitable for upstreaming. I will send an updated patch set. Thank you for the comments. Regards Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] ARM: OMAP3EVM: Add NAND flash definition
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Zumeng Chen zumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c | 39 ++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..0b83d0e 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -24,6 +24,10 @@
#include linux/leds.h
#include linux/interrupt.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl.h
@@ -43,6 +47,7 @@
#include plat/board.h
#include plat/usb.h
+#include plat/nand.h
#include common.h
#include plat/mcspi.h
#include video/omapdss.h
@@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] =
{
REGULATOR_SUPPLY(vdd33a, smsc911x.0),
};
+static struct mtd_partition omap3evm_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader,
+ .offset = 0,
+ .size = 4*(SZ_128K),
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = U-Boot,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 14*(SZ_128K),
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = U-Boot Env,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2*(SZ_128K)
+ },
+ {
+ .name = Kernel,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 40*(SZ_128K)
+ },
+ {
+ .name = File system,
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND,
+ },
+};
+
static void __init omap3_evm_init(void)
{
struct omap_board_mux *obm;
@@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
}
usb_musb_init(musb_board_data);
usbhs_init(usbhs_bdata);
+ omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
+ARRAY_SIZE(omap3evm_nand_partitions));
+
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
omap3_evm_display_init();
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] ARM OMAP3530evm misc fixes
The series is based upon the latest linux-omap master branch from Tony (3.5-rc2). V3 Changes : 1. [patch 5/5] Leave driver/input/touchscreen as-is. some changes on arch/arm/mach-omap2/common-board-devices.c, please see the shortlog for more information. 2. For the first patch, I noticed GPMC driver conversion v5, so this is decided by Tony, we can drop it, and I'll create a new one if needed, but obviously I'm not very proper candidate for it. Thanks all comments :-) Zumeng Chen (5): ARM: OMAP3EVM: Add NAND flash definition ARM: OMAP3EVM: Adding USB internal LDOs board file ARM: omap3evm: enable VBUS switch for EHCI tranceiver ARM: OMAP3EVM: cosmetic fixes for parent clk set ARM: OMAP3530evm: set pendown_state and debounce time for ads7846 arch/arm/mach-omap2/board-omap3evm.c | 74 +++- arch/arm/mach-omap2/common-board-devices.c | 18 ++- arch/arm/mach-omap2/common-board-devices.h |1 + arch/arm/plat-omap/clock.c |4 ++ drivers/mfd/omap-usb-host.c|2 +- 5 files changed, 95 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: OMAP3EVM: Adding USB internal LDOs board file
EHCI PHY requires these regulators:
EVM Rev =E -- VAUX2
EVM Rev E -- VUSB1V5, VUSB1V8
Adding USB internal LDOs (vusb1v5 vusb1v8) and VAUX2 to omap3evm
board file. Also removing vaux2_{1/2/3} supplies as they are not
used on omap3 evm.
But we need not to add vaux2 in twl4030_platform_data since it will
be added conditionally.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 0b83d0e..1bfbe42 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -466,6 +466,28 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata
= {
};
#endif
+/* VAUX2 for USB */
+static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(VDD_CSIPHY1, omap3isp),/* OMAP ISP */
+ REGULATOR_SUPPLY(VDD_CSIPHY2, omap3isp),/* OMAP ISP */
+ REGULATOR_SUPPLY(hsusb1, ehci-omap.0),
+ REGULATOR_SUPPLY(vaux2, NULL),
+};
+
+static struct regulator_init_data omap3evm_vaux2 = {
+ .constraints = {
+ .min_uV = 280,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3evm_vaux2_supplies),
+ .consumer_supplies = omap3evm_vaux2_supplies,
+};
+
static struct twl4030_platform_data omap3evm_twldata = {
/* platform_data for children goes here */
.keypad = omap3evm_kp_data,
@@ -659,6 +681,9 @@ static void __init omap3_evm_init(void)
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
omap_hsmmc_init(mmc);
+ if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
+ omap3evm_twldata.vaux2 = omap3evm_vaux2;
+
omap3_evm_i2c_init();
omap_display_init(omap3_evm_dss_data);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver
This was chosen by following the trace on the schematic from component U131
and U134 to the CPEN pin on the USB3320 device.
TWL4030.GPIO2-...-(T2_GPIO2_3V3)U131-..nUSB2_EN-..U134-..EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.
This will set TWL4030.GPIO2 as output pin to drive EHCI tranceiver.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 1bfbe42..02d8047 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -360,6 +360,15 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
platform_device_register(leds_gpio);
+ /* Enable VBUS switch by setting TWL4030.GPIO2DIR as output
+* for starting USB tranceiver
+*/
+ if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
+ u8 val;
+ twl_i2c_read_u8(TWL4030_MODULE_GPIO, val, REG_GPIODATADIR1);
+ val |= 0x04; /* TWL4030.GPIO2DIR BIT at GPIODATADIR1(0x9B) */
+ twl_i2c_write_u8(TWL4030_MODULE_GPIO, val, REG_GPIODATADIR1);
+ }
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: OMAP3EVM: cosmetic fixes for parent clk set
Since it's no more sense to set parent for dummy clock,
so we can just ignore it to mute failed message.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
arch/arm/plat-omap/clock.c |4
drivers/mfd/omap-usb-host.c |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 62ec5c4..c7e26e4 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -149,6 +149,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
if (!arch_clock || !arch_clock-clk_set_parent)
return ret;
+ /* If the clock is a dummy clock just return */
+ if (clk == dummy_ck)
+ return 0;
+
spin_lock_irqsave(clockfw_lock, flags);
if (clk-usecount == 0) {
ret = arch_clock-clk_set_parent(clk, parent);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..c9d27c4 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -699,7 +699,7 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
+ /* for OMAP3 , the clk set parent fails */
ret = clk_set_parent(omap-utmi_p1_fck,
omap-xclk60mhsp1_ck);
if (ret != 0)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: OMAP3530evm: set pendown_state and debounce time for ads7846
Currently most ads7846 config definitions for OMAP3 series boards have
been moved to common-board-devices.c, and it is transparent for init.
And it's no very proper to do gpio_request based on get_pendown_state
since omap_ads7846_init knows everything about ads7846_config.
So it's more fit to request gpio according to the right gpio_pendown
and set debounce time conditionally. If we don't set proper debouce
time, there are flooded interrupt counters of ads7846 responding to
one time touch on screen, then the driver couldn't work very well.
This patch has been validated on 3530evm.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c |1 -
arch/arm/mach-omap2/common-board-devices.c | 18 --
arch/arm/mach-omap2/common-board-devices.h |1 +
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 02d8047..834cfc0 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -58,7 +58,6 @@
#include hsmmc.h
#include common-board-devices.h
-#define OMAP3_EVM_TS_GPIO 175
#define OMAP3_EVM_EHCI_VBUS22
#define OMAP3_EVM_EHCI_SELECT 61
diff --git a/arch/arm/mach-omap2/common-board-devices.c
b/arch/arm/mach-omap2/common-board-devices.c
index 1706ebc..4ba070e 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -35,6 +35,16 @@ static struct omap2_mcspi_device_config ads7846_mcspi_config
= {
.turbo_mode = 0,
};
+/*
+ * ADS7846 driver maybe request a gpio according to the value
+ * of pdata-get_pendown_state, but we have done this. So set
+ * get_pendown_state to avoid twice gpio requesting.
+ */
+static int omap3_get_pendown_state(void)
+{
+ return !gpio_get_value(OMAP3_EVM_TS_GPIO);
+}
+
static struct ads7846_platform_data ads7846_config = {
.x_max = 0x0fff,
.y_max = 0x0fff,
@@ -45,6 +55,7 @@ static struct ads7846_platform_data ads7846_config = {
.debounce_rep = 1,
.gpio_pendown = -EINVAL,
.keep_vref_on = 1,
+ .get_pendown_state = omap3_get_pendown_state,
};
static struct spi_board_info ads7846_spi_board_info __initdata = {
@@ -63,14 +74,17 @@ void __init omap_ads7846_init(int bus_num, int
gpio_pendown, int gpio_debounce,
struct spi_board_info *spi_bi = ads7846_spi_board_info;
int err;
- if (board_pdata board_pdata-get_pendown_state) {
+ if (gpio_pendown) {
err = gpio_request_one(gpio_pendown, GPIOF_IN, TSPenDown);
if (err) {
pr_err(Couldn't obtain gpio for TSPenDown: %d\n, err);
return;
}
- gpio_export(gpio_pendown, 0);
+ /* TS GPIOPendown doesn't allow user to change the direction */
+ gpio_export(gpio_pendown, false);
+
+ /* Set proper debouce time for ads7846. */
if (gpio_debounce)
gpio_set_debounce(gpio_pendown, gpio_debounce);
}
diff --git a/arch/arm/mach-omap2/common-board-devices.h
b/arch/arm/mach-omap2/common-board-devices.h
index a0b4a428..4c4ef6a 100644
--- a/arch/arm/mach-omap2/common-board-devices.h
+++ b/arch/arm/mach-omap2/common-board-devices.h
@@ -4,6 +4,7 @@
#include twl-common.h
#define NAND_BLOCK_SIZESZ_128K
+#define OMAP3_EVM_TS_GPIO 175
struct mtd_partition;
struct ads7846_platform_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] ARM: OMAP2+: PM: protect the power domain state change by a mutex
On Thursday 14 June 2012 08:23 PM, Jean Pihet wrote:
omap_set_pwrdm_state is intented to be the only API for changing
a power domain state.
Yes, but there are others which are used to _read_ the power domain
state. Shouldn't those be protected too?
This patch protects the power domains settings and structs from
concurrent accesses to the function by using a mutex.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/pm.c |8 ++--
arch/arm/mach-omap2/powerdomain.c |1 +
arch/arm/mach-omap2/powerdomain.h |3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..a05f00c 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -100,15 +100,17 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
pwrst)
if (!pwrdm || IS_ERR(pwrdm))
return -EINVAL;
+ mutex_lock(pwrdm-lock);
+
while (!(pwrdm-pwrsts (1 pwrst))) {
if (pwrst == PWRDM_POWER_OFF)
- return ret;
+ goto out;
pwrst--;
}
next_pwrst = pwrdm_read_next_pwrst(pwrdm);
if (next_pwrst == pwrst)
- return ret;
+ goto out;
curr_pwrst = pwrdm_read_pwrst(pwrdm);
if (curr_pwrst PWRDM_POWER_ON) {
@@ -141,6 +143,8 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
pwrst)
break;
}
+out:
+ mutex_unlock(pwrdm-lock);
return ret;
}
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9611490..1641e72 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -102,6 +102,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
INIT_LIST_HEAD(pwrdm-voltdm_node);
voltdm_add_pwrdm(voltdm, pwrdm);
+ mutex_init(pwrdm-lock);
list_add(pwrdm-node,pwrdm_list);
/* Initialize the powerdomain's state counter */
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 8f88d65..bab84fc 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -19,7 +19,7 @@
#includelinux/types.h
#includelinux/list.h
-
+#includelinux/mutex.h
#includelinux/atomic.h
#includeplat/cpu.h
@@ -116,6 +116,7 @@ struct powerdomain {
struct clockdomain *pwrdm_clkdms[PWRDM_MAX_CLKDMS];
struct list_head node;
struct list_head voltdm_node;
+ struct mutex lock;
int state;
unsigned state_counter[PWRDM_MAX_PWRSTS];
unsigned ret_logic_off_counter;
--
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: MFD USB host: prevents CORE retention in idle
On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM. but I can see that core retention in suspend/resume is not working . Apply , DSS fixes patch has resolved the the crash in suspend/resume, but retention is not entering. regards keshava -- 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
Oops on boot for omap3xxx, EHCI fails.
[PATCH] Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes an oops on boot for all omap3xxx platforms that use usbhs_omap for EHCI. The actual oops seems to come from faulty ehci-omap cleanup, but the failure caused by the change is evidenced here: [3.655059] ehci-omap ehci-omap.0: utmi_p1_gfclk failed error:-2 [3.661376] ehci-omap: probe of ehci-omap.0 failed with error -2 The problem is the call: omap-utmi_p1_fck = clk_get(dev, utmi_p1_gfclk); Where dev here is ehci-omap. As shown below, clk_get will fail with dev_id ehci-omap and clk_id utmi_p1_gfclk (but succeed on omap44xx). arch/arm/mach-omap2/clock3xxx_data.c: CLK(usbhs_omap, utmi_p1_gfclk, arch/arm/mach-omap2/clock44xx_data.c: CLK(NULL, utmi_p1_gfclk, The oops caused by bad cleanup is shown below: [3.951934] Unable to handle kernel NULL pointer dereference at virtual address [3.960418] pgd = c0004000 [3.963256] [] *pgd= [3.967010] Internal error: Oops: 5 [#1] SMP ARM [3.971801] Modules linked in: [3.975006] CPU: 0Not tainted (3.5.0-rc1-ktest-00040-g354ab85 #401) [3.981964] PC is at hub_port_init+0x28c/0x968 [3.986602] LR is at hub_port_init+0xc4/0x968 [3.991119] pc : [c03304f8]lr : [c0330330]psr: 6013 [3.991119] sp : de11deb8 ip : c05eae4c fp : [4.003082] r10: r9 : de38ac00 r8 : 0032 [4.008514] r7 : de388800 r6 : 0002 r5 : r4 : de391800 [4.015289] r3 : r2 : c05de444 r1 : c05de468 r0 : de391868 [4.022094] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [4.029693] Control: 10c5387d Table: 80004019 DAC: 0017 [4.035675] Process khubd (pid: 242, stack limit = 0xde11c2f8) [4.041748] Stack: (0xde11deb8 to 0xde11e000) [4.046264] dea0: 0002 de38ac00 [4.054779] dec0: 0002 0004 c00891b0 0001 0002 0003 de378000 [4.063293] dee0: c0479d28 0001 de391800 de388800 de378000 de378018 de38ac00 [4.071807] df00: 0002 0002 c0333d68 0501 c05df1b0 c069d600 [4.080322] df20: 10a5bb6a de38ac08 de388420 de38889c de388400 0004 de38ac70 de38ac01 [4.088806] df40: de388800 de38ac68 de388800 de388420 de378000 0009 de11df8c c0064834 [4.097320] df60: de11c000 de11f440 c005c75c de11df74 de11df74 [4.105834] df80: 0501 c00891b0 de02ff18 de02fef0 c03336fc 0013 [4.114349] dfa0: c005c064 [4.122863] dfc0: dead4ead c0747830 c0597cd0 [4.131378] dfe0: de11dfe0 de11dfe0 de02fef0 c005bfe0 c0014154 c0014154 0200 [4.139892] [c03304f8] (hub_port_init+0x28c/0x968) from [c0333d68] (hub_thread+0x66c/0x13d8) [4.149047] [c0333d68] (hub_thread+0x66c/0x13d8) from [c005c064] (kthread+0x84/0x90) [4.157501] [c005c064] (kthread+0x84/0x90) from [c0014154] (kernel_thread_exit+0x0/0x8) [4.166168] Code: e59f2690 e5933080 e2840068 e59f1688 (e593e000) [4.172607] ---[ end trace f11541c260e8a205 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 02/11] ARM: OMAP: expose control.h to mach area
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]: This patch exposes the definitions under control.h to drivers outside the machine code. As discussed earlier, this will likely lead into misuse of these registers that will be a big mess to clean up. Can't you make these private to the driver(s)? 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: [RFC PATCH v2 03/11] mfd: omap: control: core system control driver
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
+++ linux-2.6/drivers/mfd/omap-control-core.c
...
+u32 omap_control_readl(u16 offset)
+{
+ return __raw_readl(omap_control_base + (offset));
+}
+
+void omap_control_writel(u32 val, u16 offset)
+{
+ __raw_writel(val, omap_control_base + (offset));
+}
There should not be any need to have the individual drivers use
these. Please instead just set up something where individual drivers
register with the control module core, and get their own iobase
returned so they can use readl/writel and behave like normal device
drivers.
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: [RFC PATCH v2 04/11] OMAP2+: use control module mfd driver in omap_type
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/arm/mach-omap2/id.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/id.c
+++ linux-2.6/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/mfd/omap_control.h
#include asm/cputype.h
@@ -38,6 +39,8 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+u32 omap_control_readl(u16 offset);
+
int omap_type(void)
{
u32 val = 0;
@@ -49,7 +52,7 @@ int omap_type(void)
} else if (cpu_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ val = omap_control_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
Please just set up a function in the ctrl module core to return the
status so you can get rid of omap_control_readl here.
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: [RFC PATCH v2 06/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]: OMAP4460 specific temperature sensor register bit fields are added. Existing OMAP4 entries are renamed to OMAP4430. Signed-off-by: Keerthy j-keer...@ti.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/mach-omap2/include/mach/control.h | 116 1 files changed, 116 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h index cf42764..171b504 100644 --- a/arch/arm/mach-omap2/include/mach/control.h +++ b/arch/arm/mach-omap2/include/mach/control.h @@ -230,6 +230,122 @@ /* OMAP44xx control McBSP padconf */ #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP 0x061c +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK (1 12) +#define OMAP4430_BGAP_TSHUT_SHIFT11 +#define OMAP4430_BGAP_TSHUT_MASK (1 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK (1 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT 9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK (1 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK (1 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT 11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK (1 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK(1 31) +#define OMAP4460_MASK_HOT_SHIFT 1 +#define OMAP4460_MASK_HOT_MASK (1 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK (1 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK(0xff 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK (0x3ff 16) +#define OMAP4460_T_COLD_SHIFT0 +#define OMAP4460_T_COLD_MASK (0x3ff 0) These should be all private to the bandgap driver. The same applies for other driver specific registers for other drivers. 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: [PATCHv8 03/13] I2C: OMAP: Remove reset at init
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]: The reset in the driver at init is not needed anymore as the following patch has removed the HWMOD_INIT_NO_RESET flag. 6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup] This patch does the following -removes the reset from the probe and implements a omap_i2c_reset function to reset. - Reset is removed from omap_i2c_init, which was called not only during probe, but also after time out and error handling. omap_i2c_reset is added in those places to effect the reset. See the comments regarding driver specific resets in hwmod code. The way to set this up is to have a shared inline function in i2c-omap.h that both the driver and hwmod code can use. Eventually hwmod code will do the reset only in late initcall if no driver is loaded for the device in question. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] ARM: OMAP2+: PM QoS: manage the per-device latency constraints in hwmod
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote: Call the per-device PM QoS functions of the power domain code from the hwmod layer, in order to apply the constraints requested to a device. While at it, correct the functions kerneldoc. Shouldn't this patch be just merged with PATCH 02/10? Signed-off-by: Jean Pihetj-pi...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 22 ++ 1 files changed, 6 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index cc173d9..4f43e0c 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -3302,15 +3302,13 @@ ohsps_unlock: } /** - * omap_hwmod_set_wakeuplat_constraint - set/release a wake-up latency + * omap_hwmod_set_wakeuplat_constraint - Set or update a wake-up latency * constraint * @oh: struct omap_hwmod* to which the target device belongs to. * @cookie: identifier of the constraints list for @oh. * @min_latency: the minimum allowed wake-up latency for @oh. * - * Sets a wakeup latency contraint. (To remove a wakeup latency - * constraint, call omap_hwmod_remove_wakeuplat_constraint()). - * Returns the return value from pwrdm_wakeuplat_remove_constraint(), + * Returns the return value from pwrdm_wakeuplat_update_constraint(), * or -EINVAL in case of invalid parameters. */ int omap_hwmod_set_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie, @@ -3321,21 +3319,17 @@ int omap_hwmod_set_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie, if (!pwrdm) return -EINVAL; - /* -* XXX Update to use pwrdm_wakeuplat_update_constraint() when -* that code is ready -*/ - return -EINVAL; + return pwrdm_wakeuplat_update_constraint(pwrdm, cookie, min_latency); } /** - * omap_hwmod_remove_wakeuplat_constraint - release a wake-up latency + * omap_hwmod_remove_wakeuplat_constraint - Release a wake-up latency * constraint * @oh: struct omap_hwmod* to which the target device belongs to. * @cookie: identifier of the constraints list for @oh. * * Removes a wakeup latency contraint. Returns the return value from - * pwrdm_wakeuplat_update_constraint(), or -EINVAL in case of invalid + * pwrdm_wakeuplat_remove_constraint(), or -EINVAL in case of invalid * parameters. */ int omap_hwmod_remove_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie) @@ -3345,11 +3339,7 @@ int omap_hwmod_remove_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie) if (!pwrdm) return -EINVAL; - /* -* XXX Update to use pwrdm_wakeuplat_remove_constraint() when -* that code is ready -*/ - return -EINVAL; + return pwrdm_wakeuplat_remove_constraint(pwrdm, cookie); } /** -- 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: [PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
...
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
Having to patch all over the place for these revision defines leads
into unmaintainable code as new SoCs get added.
Please instead just check the revision once during init, then set
up some feature bits like I2C_OMAP_NEEDS_XYZ_RESET that the runtime
code can check.
@@ -1055,7 +1055,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1073,7 +1073,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
That way the code does not need to change when new SoC revisions
get added.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] ARM: OMAP: omap_device: register to the per-device PM QoS framework
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihetj-pi...@ti.com
Reviewed-by: Kevin Hilmankhil...@ti.com
[p...@pwsan.com: modified to work with omap_devices with large numbers of
hwmods; moved code to mach-omap2/omap_device.c; added documentation; use
notifier return codes]
Signed-off-by: Paul Walmsleyp...@pwsan.com
---
arch/arm/plat-omap/omap_device.c | 81 +-
1 files changed, 80 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..241705b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -3,6 +3,7 @@
* omap_device implementation
*
* Copyright (C) 2009-2010 Nokia Corporation
+ * Copyright (C) 2011 Texas Instruments, Inc.
2012?
* Paul Walmsley, Kevin Hilman
*
* Developed in collaboration with (alphabetical order): Benoit
@@ -89,6 +90,7 @@
#includelinux/pm_runtime.h
#includelinux/of.h
#includelinux/notifier.h
+#includelinux/pm_qos.h
#includeplat/omap_device.h
#includeplat/omap_hwmod.h
@@ -401,6 +403,72 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
return NOTIFY_DONE;
}
+/**
+ * _omap_device_pm_qos_handler - interface to the per-device PM QoS framework
+ * @nb: pointer to omap_device_pm_qos_nb (not used)
+ * @new_value: new maximum wakeup latency constraint for @req-dev (in us)
+ * @req: struct dev_pm_qos_request * passed by the Linux PM QoS code
+ *
+ * Called by the Linux core device PM QoS code to alter the maximum
+ * wakeup latency constraint on a device. If the underlying device is
+ * an omap_device, then this code will pass the constraint on to the
+ * underlying hwmods. Returns -EINVAL if this code can't handle the
+ * constraint for some reason, or passes along the return code from the
+ * hwmod wakeup latency constraint functions.
+ */
+static int _omap_device_pm_qos_handler(struct notifier_block *nb,
+ unsigned long new_value,
+ void *req)
+{
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ struct dev_pm_qos_request *dev_pm_qos_req = req;
+ int ret = NOTIFY_OK;
+ int r, i;
+
+ pr_debug(OMAP PM constraints: req@0x%p, new_value=%lu\n,
+req, new_value);
+
+ /* Look for the platform device for the constraint target device */
+ pdev = to_platform_device(dev_pm_qos_req-dev);
+
+ /* Try to catch non platform devices */
+ if (pdev-name == NULL) {
Is this a safe way to catch non platform devices?
regards,
Rajendra
+ pr_err(%s: Error: platform device for device %s not valid\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return NOTIFY_DONE;
+ }
+
+ /* Find the associated omap_device for dev */
+ od = to_omap_device(pdev);
+ if (od == NULL) {
+ pr_err(%s: Error: no omap_device for device %s\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return NOTIFY_DONE;
+ }
+
+ pr_debug(OMAP PM constraints: req@0x%p, dev=0x%p, new_value=%lu\n,
+req, dev_pm_qos_req-dev, new_value);
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+ oh = od-hwmods[i];
+ if (new_value == PM_QOS_DEV_LAT_DEFAULT_VALUE)
+ r = omap_hwmod_remove_wakeuplat_constraint(
+ oh,
+ dev_pm_qos_req);
+ else
+ r = omap_hwmod_set_wakeuplat_constraint(
+ oh,
+ dev_pm_qos_req,
+ new_value);
+
+ if (!r)
+ ret = NOTIFY_BAD;
+ }
+
+ return ret;
+}
/* Public functions for use by core code */
@@ -1115,13 +1183,24 @@ int omap_device_enable_clocks(struct omap_device *od)
return 0;
}
+static struct notifier_block omap_device_pm_qos_nb = {
+ .notifier_call = _omap_device_pm_qos_handler,
+};
+
static struct notifier_block platform_nb = {
.notifier_call = _omap_device_notifier_call,
};
static int __init omap_device_init(void)
{
+ int ret;
+
bus_register_notifier(platform_bus_type,platform_nb);
- return 0;
+
+ ret = dev_pm_qos_add_global_notifier(omap_device_pm_qos_nb);
+ if (ret)
+
Re: [RFC PATCH 3/3] arm: omap: phy: remove unused functions from omap-phy-internal.c
* Kishon Vijay Abraham I kis...@ti.com [120530 07:38]: All the unnessary functions in omap-phy-internal is removed. These functionality are now handled by omap-usb2 phy driver. Glad to see these move to live under drivers. Up to Felipe to merge via linux-usb once the driver parts are finished: Acked-by: Tony Lindgren t...@atomide.com -- 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] ARM: OMAP3: update cpuidle latency and threshold figures
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
{
.enter= omap3_enter_idle_bm,
- .exit_latency = 3000 + 8500,
- .target_residency = 15000,
+ .exit_latency = 4080 + 801,
+ .target_residency = 215000,
.flags= CPUIDLE_FLAG_TIME_VALID,
.name = C6,
.desc = MPU OFF + CORE RET,
},
{
.enter= omap3_enter_idle_bm,
- .exit_latency = 1 + 3,
- .target_residency = 3,
+ .exit_latency = 4300 + 13000,
+ .target_residency = 215000,
Is the target_residency same for both these states?
.flags= CPUIDLE_FLAG_TIME_VALID,
.name = C7,
.desc = MPU OFF + CORE OFF,
--
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] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
Hi Rajendra, On Wed, Jun 20, 2012 at 10:57 AM, Rajendra Nayak rna...@ti.com wrote: Jean, On Wednesday 20 June 2012 02:22 PM, Rajendra Nayak wrote: Hi Jean, On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote: On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote: Hi Rajendra, On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayakrna...@ti.com wrote: Hi Jean, On Friday 01 June 2012 08:41 PM, Jean Pihet wrote: For a power domain to idle all the clock domains in it must idle. This patch implements an optimization of the cpuidle code by denying and later allowing only the first registered clock domain of a power domain, and so optimizes the latency of the low power code. How much do we really save doing this? I understand what you are doing by looking at the patch but the changelog seems very confusing. The gain is on the registers accesses and the internal PRCM state machine. If needed the changelog can be updated. Can you explain a bit more on which register accesses are you talking about? and some more on the PRCM state machine. never mind, I looked at the patch again and then the cpuidle code and figured what you are doing. Makes sense to me now :-) Ok! How do you like this updated changelog, I just added one more line. For a power domain to idle all the clock domains in it must idle. Denying just *one* clkdm in a pwrdm from idling should have the same effect as denying *all*. This patch implements an optimization of the cpuidle code by denying and later allowing only the first registered clock domain of a power domain, and so optimizes the latency of the low power code. That looks great! Kevin, Can you take this change still in your for_3.6/pm/performance branch? Thanks regards, Jean regards, Rajendra -- 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 03/10] ARM: OMAP2+: PM QoS: manage the per-device latency constraints in hwmod
Rajendra, On Wed, Jun 20, 2012 at 12:29 PM, Rajendra Nayak rna...@ti.com wrote: On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote: Call the per-device PM QoS functions of the power domain code from the hwmod layer, in order to apply the constraints requested to a device. While at it, correct the functions kerneldoc. Shouldn't this patch be just merged with PATCH 02/10? Ideally yes! Paul, Is this possiblr or is the patch 02/10 already scheduled for inclusion in l-o or mainline? Regards, Jean Signed-off-by: Jean Pihetj-pi...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 22 ++ 1 files changed, 6 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index cc173d9..4f43e0c 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -3302,15 +3302,13 @@ ohsps_unlock: } /** - * omap_hwmod_set_wakeuplat_constraint - set/release a wake-up latency + * omap_hwmod_set_wakeuplat_constraint - Set or update a wake-up latency * constraint * @oh: struct omap_hwmod* to which the target device belongs to. * @cookie: identifier of the constraints list for @oh. * @min_latency: the minimum allowed wake-up latency for @oh. * - * Sets a wakeup latency contraint. (To remove a wakeup latency - * constraint, call omap_hwmod_remove_wakeuplat_constraint()). - * Returns the return value from pwrdm_wakeuplat_remove_constraint(), + * Returns the return value from pwrdm_wakeuplat_update_constraint(), * or -EINVAL in case of invalid parameters. */ int omap_hwmod_set_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie, @@ -3321,21 +3319,17 @@ int omap_hwmod_set_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie, if (!pwrdm) return -EINVAL; - /* - * XXX Update to use pwrdm_wakeuplat_update_constraint() when - * that code is ready - */ - return -EINVAL; + return pwrdm_wakeuplat_update_constraint(pwrdm, cookie, min_latency); } /** - * omap_hwmod_remove_wakeuplat_constraint - release a wake-up latency + * omap_hwmod_remove_wakeuplat_constraint - Release a wake-up latency * constraint * @oh: struct omap_hwmod* to which the target device belongs to. * @cookie: identifier of the constraints list for @oh. * * Removes a wakeup latency contraint. Returns the return value from - * pwrdm_wakeuplat_update_constraint(), or -EINVAL in case of invalid + * pwrdm_wakeuplat_remove_constraint(), or -EINVAL in case of invalid * parameters. */ int omap_hwmod_remove_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie) @@ -3345,11 +3339,7 @@ int omap_hwmod_remove_wakeuplat_constraint(struct omap_hwmod *oh, void *cookie) if (!pwrdm) return -EINVAL; - /* - * XXX Update to use pwrdm_wakeuplat_remove_constraint() when - * that code is ready - */ - return -EINVAL; + return pwrdm_wakeuplat_remove_constraint(pwrdm, cookie); } /** -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Rajendra Nayak rna...@ti.com [120606 22:33]: Hi Tony, On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120601 05:13]: The data is autogenerated using the OMAP autogeneration scripts (python scripts). Thanks to Mike Turquette for the initial efforts in updating the script which was later updated by me. All data is added into a new cclock44xx_data.c file, a later patch will get rid of clock44xx_data.c file. Signed-off-by: Rajendra Nayakrna...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++ arch/arm/mach-omap2/clock.h | 17 + arch/arm/mach-omap2/clock_common_data.c | 14 + arch/arm/mach-omap2/scrm44xx.h |2 + 4 files changed, 2635 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? Sorry, I missed out on responding to this one. We won't be able to move just the new data but will need all clkops handling around clksel/dpll etc also to be moved, and I was thinking we might end up with 2 issues doing that. We should sort out those issues, sounds like we're missing few interfaces.. -1- We have low level PRM/CM headers and apis used across multiple frameworks for clocks/clockdomains/powerdomains and also some low level PM code. This might get duplicated in drivers/clk and mach-omap2/ Well the PM code should be a loadable module using standard driver interfaces.. Maybe all it takes is adding few functions that both drivers/clk and mach-omap2 code can use without exposing all the registers? Then we may have a better idea what infrastructure pieces are missing. -2- We still need to control clockdomains along with clocks atleast for OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers start using omap_device/runtime) and I am not sure how to do it with the clockdomain framework residing in mach-omap2/ Maybe clockdomains could be also handled with some functions without exposing all the registers in the headers? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: OMAP3: update cpuidle latency and threshold figures
On Wed, Jun 20, 2012 at 1:01 PM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
{
.enter = omap3_enter_idle_bm,
- .exit_latency = 3000 + 8500,
- .target_residency = 15000,
+ .exit_latency = 4080 + 801,
+ .target_residency = 215000,
.flags = CPUIDLE_FLAG_TIME_VALID,
.name = C6,
.desc = MPU OFF + CORE RET,
},
{
.enter = omap3_enter_idle_bm,
- .exit_latency = 1 + 3,
- .target_residency = 3,
+ .exit_latency = 4300 + 13000,
+ .target_residency = 215000,
Is the target_residency same for both these states?
Yes it is. The details are found in the omappedia wiki page.
Thanks,
Jean
.flags = CPUIDLE_FLAG_TIME_VALID,
.name = C7,
.desc = MPU OFF + CORE OFF,
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±¢f©{ayº ÊÚë,j¢f£¢·hàz¹ ®w¥¢¸
¢·¦j:+v¨wèjØm¶ÿ¾«êçzZ+ùÝ¢jú!¶i
Re: [PATCH 04/29] ARM: omap: clk: use clk_prepare_enable and clk_disable_unprepare
* Rajendra Nayak rna...@ti.com [120614 22:01]: On Friday 15 June 2012 12:41 AM, Mike Turquette wrote: On 20120614-18:16, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Based on initial changes from Mike turquette. Sounds like these kind of patches should be a separate series to prepare for the common clk fwk conversion? It seems these could already get merged separately? 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
[PATCH V2] ARM: OMAP: TLL driver implementation for USB host driver
The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In V2: - covered review comments from linux omap and usb community - rebased on top Russ dil's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Build the USB HOST TLL omap device ARM: OMAP: USB: Remove TLL specific code ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: change the USB TLL clocks device name arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: OMAP: USB: Remove TLL specific code
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 231 ++-
1 file changed, 10 insertions(+), 221 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 41088ec..c1baf20 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -36,63 +36,6 @@
/* OMAP USBHOST Register addresses */
-/* TLL Register Set */
-#defineOMAP_USBTLL_REVISION(0x00)
-#defineOMAP_USBTLL_SYSCONFIG (0x10)
-#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
-#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
-#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
-#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
-#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
-
-#defineOMAP_USBTLL_SYSSTATUS (0x14)
-#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
-
-#defineOMAP_USBTLL_IRQSTATUS (0x18)
-#defineOMAP_USBTLL_IRQENABLE (0x1C)
-
-#defineOMAP_TLL_SHARED_CONF(0x30)
-#defineOMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6)
-#defineOMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5)
-#defineOMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2)
-#defineOMAP_TLL_SHARED_CONF_FCLK_REQ (1 1)
-#defineOMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0)
-
-#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004
* num)
-#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24
-#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11)
-#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10)
-#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9)
-#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8)
-#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1 1)
-#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 0)
-
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DAT_SE0 0x0
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DP_DM 0x1
-#define OMAP_TLL_FSLSMODE_3PIN_PHY 0x2
-#define OMAP_TLL_FSLSMODE_4PIN_PHY 0x3
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DAT_SE0 0x4
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DP_DM 0x5
-#define OMAP_TLL_FSLSMODE_3PIN_TLL 0x6
-#define OMAP_TLL_FSLSMODE_4PIN_TLL 0x7
-#define OMAP_TLL_FSLSMODE_2PIN_TLL_DAT_SE0 0xA
-#define OMAP_TLL_FSLSMODE_2PIN_DAT_DP_DM 0xB
-
-#defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)(0x804 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INTERFACE_CTRL(num) (0x807 + 0x100
* num)
-#defineOMAP_TLL_ULPI_OTG_CTRL(num) (0x80A + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_RISE(num) (0x80D + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_FALL(num) (0x810 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_STATUS(num) (0x813 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_LATCH(num)(0x814 + 0x100
* num)
-#defineOMAP_TLL_ULPI_DEBUG(num)(0x815 + 0x100
* num)
-#defineOMAP_TLL_ULPI_SCRATCH_REGISTER(num) (0x816 + 0x100
* num)
-
-#define OMAP_TLL_CHANNEL_COUNT 3
-#define OMAP_TLL_CHANNEL_1_EN_MASK (1 0)
-#define OMAP_TLL_CHANNEL_2_EN_MASK (1 1)
-#define OMAP_TLL_CHANNEL_3_EN_MASK (1 2)
-
/* UHH Register Set */
#defineOMAP_UHH_REVISION (0x00)
#defineOMAP_UHH_SYSCONFIG (0x10)
@@ -132,8 +75,6 @@
#define OMAP4_P2_MODE_TLL (1 18)
#define OMAP4_P2_MODE_HSIC (3 18)
-#define OMAP_REV2_TLL_CHANNEL_COUNT2
-
#defineOMAP_UHH_DEBUG_CSR (0x44)
/* Values of UHH_REVISION - Note: these are not given in the TRM */
@@ -153,15 +94,12 @@ struct usbhs_hcd_omap {
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
struct clk *usbhost_p1_fck;
- struct clk *usbtll_p1_fck;
struct clk *utmi_p2_fck;
struct clk *usbhost_p2_fck;
- struct clk *usbtll_p2_fck;
[PATCH V2] ARM: OMAP: USB: Build the USB HOST TLL omap device
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index dde8a11..b2a2dd7 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -35,10 +35,12 @@
#ifdef CONFIG_MFD_OMAP_USB_HOST
#define OMAP_USBHS_DEVICE usbhs_omap
+#define OMAP_USBTLL_DEVICE usbhs_tll
#defineUSBHS_UHH_HWMODNAME usb_host_hs
#define USBHS_TLL_HWMODNAMEusb_tll_hs
static struct usbhs_omap_platform_data usbhs_data;
+static struct usbtll_omap_platform_datausbtll_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
@@ -487,13 +489,14 @@ void __init setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- struct omap_hwmod *oh[2];
+ struct omap_hwmod *uhh_hwm, *tll_hwm;
struct platform_device *pdev;
int bus_id = -1;
int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
+ usbtll_data.port_mode[i] = pdata-port_mode[i];
ohci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.reset_gpio_port[i] = pdata-reset_gpio_port[i];
@@ -512,25 +515,35 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
setup_4430ohci_io_mux(pdata-port_mode);
}
- oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
- if (!oh[0]) {
+ uhh_hwm = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!uhh_hwm) {
pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
return;
}
- oh[1] = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
- if (!oh[1]) {
+ tll_hwm = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
+ if (!tll_hwm) {
pr_err(Could not look up %s\n, USBHS_TLL_HWMODNAME);
return;
}
- pdev = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
- (void *)usbhs_data, sizeof(usbhs_data),
+ pdev = omap_device_build(OMAP_USBTLL_DEVICE, bus_id, tll_hwm,
+ usbtll_data, sizeof(usbtll_data),
omap_uhhtll_latency,
ARRAY_SIZE(omap_uhhtll_latency), false);
if (IS_ERR(pdev)) {
- pr_err(Could not build hwmod devices %s,%s\n,
- USBHS_UHH_HWMODNAME, USBHS_TLL_HWMODNAME);
+ pr_err(Could not build hwmod device %s\n,
+ USBHS_TLL_HWMODNAME);
+ return;
+ }
+
+ pdev = omap_device_build(OMAP_USBHS_DEVICE, bus_id, uhh_hwm,
+ usbhs_data, sizeof(usbhs_data),
+ omap_uhhtll_latency,
+ ARRAY_SIZE(omap_uhhtll_latency), false);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build hwmod devices %s\n,
+ USBHS_UHH_HWMODNAME);
return;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: OMAP: USB: HOST TLL platform driver
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
platform driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |6 +
drivers/mfd/Kconfig |2 +-
drivers/mfd/Makefile |2 +-
drivers/mfd/omap-usb-tll.c| 471 +
4 files changed, 479 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-usb-tll.c
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 762eeb0..b8a9d5e 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -62,6 +62,10 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
};
+
+struct usbtll_omap_platform_data {
+ enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
+};
/*-*/
#define OMAP1_OTG_BASE 0xfffb0400
@@ -100,6 +104,8 @@ enum musb_interface{MUSB_INTERFACE_ULPI,
MUSB_INTERFACE_UTMI};
extern void usb_musb_init(struct omap_musb_board_data *board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
+extern int omap_tll_enable(void);
+extern int omap_tll_disable(void);
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e129c82..74abd60 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -823,7 +823,7 @@ config MFD_WL1273_CORE
audio codec.
config MFD_OMAP_USB_HOST
- bool Support OMAP USBHS core driver
+ bool Support OMAP USBHS core and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
default y
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 75f6ed6..6de605d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855)+= vx855.o
obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
-obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o
+obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
new file mode 100644
index 000..516059b
--- /dev/null
+++ b/drivers/mfd/omap-usb-tll.c
@@ -0,0 +1,471 @@
+/**
+ * omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Keshava Munegowda keshava_mgo...@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 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include plat/usb.h
+#include linux/pm_runtime.h
+
+#define USBTLL_DRIVER_NAME usbhs_tll
+
+/* TLL Register Set */
+#defineOMAP_USBTLL_REVISION(0x00)
+#defineOMAP_USBTLL_SYSCONFIG (0x10)
+#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
+#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
+#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
+#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
+#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
+
+#defineOMAP_USBTLL_SYSSTATUS (0x14)
+#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
+
+#defineOMAP_USBTLL_IRQSTATUS (0x18)
+#defineOMAP_USBTLL_IRQENABLE
[PATCH V2] ARM: OMAP: change the USB TLL clocks device name
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |8
arch/arm/mach-omap2/clock44xx_data.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..300ca51 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3306,7 +3306,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3342,7 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3397,9 +3397,9 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..d60e8d6 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3328,7 +3328,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_tll_hs_usb_ch2_clk,
usb_tll_hs_usb_ch2_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch0_clk,
usb_tll_hs_usb_ch0_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch1_clk,
usb_tll_hs_usb_ch1_clk,CK_443X),
- CLK(usbhs_omap, usbtll_ick, usb_tll_hs_ick,
CK_443X),
+ CLK(usbhs_tll,usbtll_ick, usb_tll_hs_ick,
CK_443X),
CLK(NULL, usim_ck, usim_ck,
CK_443X),
CLK(NULL, usim_fclk,usim_fclk,
CK_443X),
CLK(NULL, usim_fck, usim_fck,
CK_443X),
@@ -3378,7 +3378,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_ick,dummy_ck,
CK_443X),
CLK(NULL, uart4_ick,dummy_ck,
CK_443X),
CLK(usbhs_omap, usbhost_ick, dummy_ck,
CK_443X),
- CLK(usbhs_omap, usbtll_fck, dummy_ck,
CK_443X),
+ CLK(usbhs_tll,usbtll_fck, dummy_ck,
CK_443X),
CLK(omap_wdt, ick, dummy_ck,
CK_443X),
CLK(omap_timer.1, 32k_ck, sys_32k_ck,CK_443X),
CLK(omap_timer.2, 32k_ck, sys_32k_ck,CK_443X),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/mfd/omap-usb-host.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index b8a9d5e..8eac78c 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -4,6 +4,7 @@
#define__ASM_ARCH_OMAP_USB_H
#include linux/io.h
+#include linux/platform_device.h
#include linux/usb/musb.h
#include plat/board.h
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index c1baf20..23cec57 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -21,7 +21,6 @@
#include linux/types.h
#include linux/slab.h
#include linux/delay.h
-#include linux/platform_device.h
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
@@ -287,6 +286,7 @@ static int usbhs_runtime_resume(struct device *dev)
return -ENODEV;
}
+ omap_tll_enable();
spin_lock_irqsave(omap-lock, flags);
if (omap-ehci_logic_fck !IS_ERR(omap-ehci_logic_fck))
@@ -332,6 +332,7 @@ static int usbhs_runtime_suspend(struct device *dev)
clk_disable(omap-ehci_logic_fck);
spin_unlock_irqrestore(omap-lock, flags);
+ omap_tll_disable();
return 0;
}
@@ -699,8 +700,10 @@ static int __init omap_usbhs_drvinit(void)
* init before ehci and ohci drivers;
* The usbhs core driver should be initialized much before
* the omap ehci and ohci probe functions are called.
+ * This usbhs core driver should be initialized after
+ * usb tll driver
*/
-fs_initcall(omap_usbhs_drvinit);
+fs_initcall_sync(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/5] ARM: OMAP: TLL driver implementation for USB host driver
The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In V2: - covered review comments from linux omap and usb community - rebased on top Russ dil's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Build the USB HOST TLL omap device ARM: OMAP: USB: Remove TLL specific code ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: change the USB TLL clocks device name arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 4/5] ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/mfd/omap-usb-host.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index b8a9d5e..8eac78c 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -4,6 +4,7 @@
#define__ASM_ARCH_OMAP_USB_H
#include linux/io.h
+#include linux/platform_device.h
#include linux/usb/musb.h
#include plat/board.h
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index c1baf20..23cec57 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -21,7 +21,6 @@
#include linux/types.h
#include linux/slab.h
#include linux/delay.h
-#include linux/platform_device.h
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
@@ -287,6 +286,7 @@ static int usbhs_runtime_resume(struct device *dev)
return -ENODEV;
}
+ omap_tll_enable();
spin_lock_irqsave(omap-lock, flags);
if (omap-ehci_logic_fck !IS_ERR(omap-ehci_logic_fck))
@@ -332,6 +332,7 @@ static int usbhs_runtime_suspend(struct device *dev)
clk_disable(omap-ehci_logic_fck);
spin_unlock_irqrestore(omap-lock, flags);
+ omap_tll_disable();
return 0;
}
@@ -699,8 +700,10 @@ static int __init omap_usbhs_drvinit(void)
* init before ehci and ohci drivers;
* The usbhs core driver should be initialized much before
* the omap ehci and ohci probe functions are called.
+ * This usbhs core driver should be initialized after
+ * usb tll driver
*/
-fs_initcall(omap_usbhs_drvinit);
+fs_initcall_sync(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/5] ARM: OMAP: USB: Build the USB HOST TLL omap device
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index dde8a11..b2a2dd7 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -35,10 +35,12 @@
#ifdef CONFIG_MFD_OMAP_USB_HOST
#define OMAP_USBHS_DEVICE usbhs_omap
+#define OMAP_USBTLL_DEVICE usbhs_tll
#defineUSBHS_UHH_HWMODNAME usb_host_hs
#define USBHS_TLL_HWMODNAMEusb_tll_hs
static struct usbhs_omap_platform_data usbhs_data;
+static struct usbtll_omap_platform_datausbtll_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
@@ -487,13 +489,14 @@ void __init setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- struct omap_hwmod *oh[2];
+ struct omap_hwmod *uhh_hwm, *tll_hwm;
struct platform_device *pdev;
int bus_id = -1;
int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
+ usbtll_data.port_mode[i] = pdata-port_mode[i];
ohci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.reset_gpio_port[i] = pdata-reset_gpio_port[i];
@@ -512,25 +515,35 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
setup_4430ohci_io_mux(pdata-port_mode);
}
- oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
- if (!oh[0]) {
+ uhh_hwm = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!uhh_hwm) {
pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
return;
}
- oh[1] = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
- if (!oh[1]) {
+ tll_hwm = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
+ if (!tll_hwm) {
pr_err(Could not look up %s\n, USBHS_TLL_HWMODNAME);
return;
}
- pdev = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
- (void *)usbhs_data, sizeof(usbhs_data),
+ pdev = omap_device_build(OMAP_USBTLL_DEVICE, bus_id, tll_hwm,
+ usbtll_data, sizeof(usbtll_data),
omap_uhhtll_latency,
ARRAY_SIZE(omap_uhhtll_latency), false);
if (IS_ERR(pdev)) {
- pr_err(Could not build hwmod devices %s,%s\n,
- USBHS_UHH_HWMODNAME, USBHS_TLL_HWMODNAME);
+ pr_err(Could not build hwmod device %s\n,
+ USBHS_TLL_HWMODNAME);
+ return;
+ }
+
+ pdev = omap_device_build(OMAP_USBHS_DEVICE, bus_id, uhh_hwm,
+ usbhs_data, sizeof(usbhs_data),
+ omap_uhhtll_latency,
+ ARRAY_SIZE(omap_uhhtll_latency), false);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build hwmod devices %s\n,
+ USBHS_UHH_HWMODNAME);
return;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/5] ARM: OMAP: USB: Remove TLL specific code
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 231 ++-
1 file changed, 10 insertions(+), 221 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 41088ec..c1baf20 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -36,63 +36,6 @@
/* OMAP USBHOST Register addresses */
-/* TLL Register Set */
-#defineOMAP_USBTLL_REVISION(0x00)
-#defineOMAP_USBTLL_SYSCONFIG (0x10)
-#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
-#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
-#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
-#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
-#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
-
-#defineOMAP_USBTLL_SYSSTATUS (0x14)
-#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
-
-#defineOMAP_USBTLL_IRQSTATUS (0x18)
-#defineOMAP_USBTLL_IRQENABLE (0x1C)
-
-#defineOMAP_TLL_SHARED_CONF(0x30)
-#defineOMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6)
-#defineOMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5)
-#defineOMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2)
-#defineOMAP_TLL_SHARED_CONF_FCLK_REQ (1 1)
-#defineOMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0)
-
-#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004
* num)
-#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24
-#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11)
-#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10)
-#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9)
-#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8)
-#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1 1)
-#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 0)
-
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DAT_SE0 0x0
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DP_DM 0x1
-#define OMAP_TLL_FSLSMODE_3PIN_PHY 0x2
-#define OMAP_TLL_FSLSMODE_4PIN_PHY 0x3
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DAT_SE0 0x4
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DP_DM 0x5
-#define OMAP_TLL_FSLSMODE_3PIN_TLL 0x6
-#define OMAP_TLL_FSLSMODE_4PIN_TLL 0x7
-#define OMAP_TLL_FSLSMODE_2PIN_TLL_DAT_SE0 0xA
-#define OMAP_TLL_FSLSMODE_2PIN_DAT_DP_DM 0xB
-
-#defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)(0x804 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INTERFACE_CTRL(num) (0x807 + 0x100
* num)
-#defineOMAP_TLL_ULPI_OTG_CTRL(num) (0x80A + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_RISE(num) (0x80D + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_FALL(num) (0x810 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_STATUS(num) (0x813 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_LATCH(num)(0x814 + 0x100
* num)
-#defineOMAP_TLL_ULPI_DEBUG(num)(0x815 + 0x100
* num)
-#defineOMAP_TLL_ULPI_SCRATCH_REGISTER(num) (0x816 + 0x100
* num)
-
-#define OMAP_TLL_CHANNEL_COUNT 3
-#define OMAP_TLL_CHANNEL_1_EN_MASK (1 0)
-#define OMAP_TLL_CHANNEL_2_EN_MASK (1 1)
-#define OMAP_TLL_CHANNEL_3_EN_MASK (1 2)
-
/* UHH Register Set */
#defineOMAP_UHH_REVISION (0x00)
#defineOMAP_UHH_SYSCONFIG (0x10)
@@ -132,8 +75,6 @@
#define OMAP4_P2_MODE_TLL (1 18)
#define OMAP4_P2_MODE_HSIC (3 18)
-#define OMAP_REV2_TLL_CHANNEL_COUNT2
-
#defineOMAP_UHH_DEBUG_CSR (0x44)
/* Values of UHH_REVISION - Note: these are not given in the TRM */
@@ -153,15 +94,12 @@ struct usbhs_hcd_omap {
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
struct clk *usbhost_p1_fck;
- struct clk *usbtll_p1_fck;
struct clk *utmi_p2_fck;
struct clk *usbhost_p2_fck;
- struct clk *usbtll_p2_fck;
[PATCH V2 1/5] ARM: OMAP: USB: HOST TLL platform driver
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
platform driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |6 +
drivers/mfd/Kconfig |2 +-
drivers/mfd/Makefile |2 +-
drivers/mfd/omap-usb-tll.c| 471 +
4 files changed, 479 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-usb-tll.c
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 762eeb0..b8a9d5e 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -62,6 +62,10 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
};
+
+struct usbtll_omap_platform_data {
+ enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
+};
/*-*/
#define OMAP1_OTG_BASE 0xfffb0400
@@ -100,6 +104,8 @@ enum musb_interface{MUSB_INTERFACE_ULPI,
MUSB_INTERFACE_UTMI};
extern void usb_musb_init(struct omap_musb_board_data *board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
+extern int omap_tll_enable(void);
+extern int omap_tll_disable(void);
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e129c82..74abd60 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -823,7 +823,7 @@ config MFD_WL1273_CORE
audio codec.
config MFD_OMAP_USB_HOST
- bool Support OMAP USBHS core driver
+ bool Support OMAP USBHS core and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
default y
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 75f6ed6..6de605d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855)+= vx855.o
obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
-obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o
+obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
new file mode 100644
index 000..516059b
--- /dev/null
+++ b/drivers/mfd/omap-usb-tll.c
@@ -0,0 +1,471 @@
+/**
+ * omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Keshava Munegowda keshava_mgo...@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 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include plat/usb.h
+#include linux/pm_runtime.h
+
+#define USBTLL_DRIVER_NAME usbhs_tll
+
+/* TLL Register Set */
+#defineOMAP_USBTLL_REVISION(0x00)
+#defineOMAP_USBTLL_SYSCONFIG (0x10)
+#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
+#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
+#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
+#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
+#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
+
+#defineOMAP_USBTLL_SYSSTATUS (0x14)
+#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
+
+#defineOMAP_USBTLL_IRQSTATUS (0x18)
+#defineOMAP_USBTLL_IRQENABLE
[PATCH V2 5/5] ARM: OMAP: change the USB TLL clocks device name
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |8
arch/arm/mach-omap2/clock44xx_data.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..300ca51 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3306,7 +3306,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3342,7 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3397,9 +3397,9 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..d60e8d6 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3328,7 +3328,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_tll_hs_usb_ch2_clk,
usb_tll_hs_usb_ch2_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch0_clk,
usb_tll_hs_usb_ch0_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch1_clk,
usb_tll_hs_usb_ch1_clk,CK_443X),
- CLK(usbhs_omap, usbtll_ick, usb_tll_hs_ick,
CK_443X),
+ CLK(usbhs_tll,usbtll_ick, usb_tll_hs_ick,
CK_443X),
CLK(NULL, usim_ck, usim_ck,
CK_443X),
CLK(NULL, usim_fclk,usim_fclk,
CK_443X),
CLK(NULL, usim_fck, usim_fck,
CK_443X),
@@ -3378,7 +3378,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_ick,dummy_ck,
CK_443X),
CLK(NULL, uart4_ick,dummy_ck,
CK_443X),
CLK(usbhs_omap, usbhost_ick, dummy_ck,
CK_443X),
- CLK(usbhs_omap, usbtll_fck, dummy_ck,
CK_443X),
+ CLK(usbhs_tll,usbtll_fck, dummy_ck,
CK_443X),
CLK(omap_wdt, ick, dummy_ck,
CK_443X),
CLK(omap_timer.1, 32k_ck, sys_32k_ck,CK_443X),
CLK(omap_timer.2, 32k_ck, sys_32k_ck,CK_443X),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver
Hello.
On 20-06-2012 13:14, Zumeng Chen wrote:
This was chosen by following the trace on the schematic from component U131
and U134 to the CPEN pin on the USB3320 device.
TWL4030.GPIO2-...-(T2_GPIO2_3V3)U131-..nUSB2_EN-..U134-..EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.
This will set TWL4030.GPIO2 as output pin to drive EHCI tranceiver.
Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 1bfbe42..02d8047 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -360,6 +360,15 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
platform_device_register(leds_gpio);
+ /* Enable VBUS switch by setting TWL4030.GPIO2DIR as output
+* for starting USB tranceiver
+*/
+ if (get_omap3_evm_rev()= OMAP3EVM_BOARD_GEN_2) {
+ u8 val;
Empty line after declaration block wouldn't hurt...
+ twl_i2c_read_u8(TWL4030_MODULE_GPIO,val, REG_GPIODATADIR1);
+ val |= 0x04; /* TWL4030.GPIO2DIR BIT at GPIODATADIR1(0x9B) */
+ twl_i2c_write_u8(TWL4030_MODULE_GPIO, val, REG_GPIODATADIR1);
+ }
return 0;
}
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5 V2 RESEND] ARM: OMAP: TLL driver implementation for USB host driver
The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In V2: - covered review comments from linux omap and usb community - rebased on top Russ dil's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Build the USB HOST TLL omap device ARM: OMAP: USB: Remove TLL specific code ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: change the USB TLL clocks device name arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 V2 RESEND] ARM: OMAP: USB: HOST TLL platform driver
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
platform driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |6 +
drivers/mfd/Kconfig |2 +-
drivers/mfd/Makefile |2 +-
drivers/mfd/omap-usb-tll.c| 471 +
4 files changed, 479 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-usb-tll.c
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 762eeb0..b8a9d5e 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -62,6 +62,10 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
};
+
+struct usbtll_omap_platform_data {
+ enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
+};
/*-*/
#define OMAP1_OTG_BASE 0xfffb0400
@@ -100,6 +104,8 @@ enum musb_interface{MUSB_INTERFACE_ULPI,
MUSB_INTERFACE_UTMI};
extern void usb_musb_init(struct omap_musb_board_data *board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
+extern int omap_tll_enable(void);
+extern int omap_tll_disable(void);
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e129c82..74abd60 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -823,7 +823,7 @@ config MFD_WL1273_CORE
audio codec.
config MFD_OMAP_USB_HOST
- bool Support OMAP USBHS core driver
+ bool Support OMAP USBHS core and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
default y
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 75f6ed6..6de605d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855)+= vx855.o
obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
-obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o
+obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
new file mode 100644
index 000..516059b
--- /dev/null
+++ b/drivers/mfd/omap-usb-tll.c
@@ -0,0 +1,471 @@
+/**
+ * omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Keshava Munegowda keshava_mgo...@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 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include plat/usb.h
+#include linux/pm_runtime.h
+
+#define USBTLL_DRIVER_NAME usbhs_tll
+
+/* TLL Register Set */
+#defineOMAP_USBTLL_REVISION(0x00)
+#defineOMAP_USBTLL_SYSCONFIG (0x10)
+#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
+#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
+#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
+#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
+#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
+
+#defineOMAP_USBTLL_SYSSTATUS (0x14)
+#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
+
+#defineOMAP_USBTLL_IRQSTATUS (0x18)
+#defineOMAP_USBTLL_IRQENABLE
[PATCH 4/5 V2 RESEND] ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/mfd/omap-usb-host.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index b8a9d5e..8eac78c 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -4,6 +4,7 @@
#define__ASM_ARCH_OMAP_USB_H
#include linux/io.h
+#include linux/platform_device.h
#include linux/usb/musb.h
#include plat/board.h
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index c1baf20..23cec57 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -21,7 +21,6 @@
#include linux/types.h
#include linux/slab.h
#include linux/delay.h
-#include linux/platform_device.h
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
@@ -287,6 +286,7 @@ static int usbhs_runtime_resume(struct device *dev)
return -ENODEV;
}
+ omap_tll_enable();
spin_lock_irqsave(omap-lock, flags);
if (omap-ehci_logic_fck !IS_ERR(omap-ehci_logic_fck))
@@ -332,6 +332,7 @@ static int usbhs_runtime_suspend(struct device *dev)
clk_disable(omap-ehci_logic_fck);
spin_unlock_irqrestore(omap-lock, flags);
+ omap_tll_disable();
return 0;
}
@@ -699,8 +700,10 @@ static int __init omap_usbhs_drvinit(void)
* init before ehci and ohci drivers;
* The usbhs core driver should be initialized much before
* the omap ehci and ohci probe functions are called.
+ * This usbhs core driver should be initialized after
+ * usb tll driver
*/
-fs_initcall(omap_usbhs_drvinit);
+fs_initcall_sync(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5 V2 RESEND] ARM: OMAP: USB: Remove TLL specific code
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 231 ++-
1 file changed, 10 insertions(+), 221 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 41088ec..c1baf20 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -36,63 +36,6 @@
/* OMAP USBHOST Register addresses */
-/* TLL Register Set */
-#defineOMAP_USBTLL_REVISION(0x00)
-#defineOMAP_USBTLL_SYSCONFIG (0x10)
-#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
-#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
-#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
-#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
-#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
-
-#defineOMAP_USBTLL_SYSSTATUS (0x14)
-#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
-
-#defineOMAP_USBTLL_IRQSTATUS (0x18)
-#defineOMAP_USBTLL_IRQENABLE (0x1C)
-
-#defineOMAP_TLL_SHARED_CONF(0x30)
-#defineOMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6)
-#defineOMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5)
-#defineOMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2)
-#defineOMAP_TLL_SHARED_CONF_FCLK_REQ (1 1)
-#defineOMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0)
-
-#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004
* num)
-#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24
-#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11)
-#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10)
-#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9)
-#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8)
-#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1 1)
-#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 0)
-
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DAT_SE0 0x0
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DP_DM 0x1
-#define OMAP_TLL_FSLSMODE_3PIN_PHY 0x2
-#define OMAP_TLL_FSLSMODE_4PIN_PHY 0x3
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DAT_SE0 0x4
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DP_DM 0x5
-#define OMAP_TLL_FSLSMODE_3PIN_TLL 0x6
-#define OMAP_TLL_FSLSMODE_4PIN_TLL 0x7
-#define OMAP_TLL_FSLSMODE_2PIN_TLL_DAT_SE0 0xA
-#define OMAP_TLL_FSLSMODE_2PIN_DAT_DP_DM 0xB
-
-#defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)(0x804 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INTERFACE_CTRL(num) (0x807 + 0x100
* num)
-#defineOMAP_TLL_ULPI_OTG_CTRL(num) (0x80A + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_RISE(num) (0x80D + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_FALL(num) (0x810 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_STATUS(num) (0x813 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_LATCH(num)(0x814 + 0x100
* num)
-#defineOMAP_TLL_ULPI_DEBUG(num)(0x815 + 0x100
* num)
-#defineOMAP_TLL_ULPI_SCRATCH_REGISTER(num) (0x816 + 0x100
* num)
-
-#define OMAP_TLL_CHANNEL_COUNT 3
-#define OMAP_TLL_CHANNEL_1_EN_MASK (1 0)
-#define OMAP_TLL_CHANNEL_2_EN_MASK (1 1)
-#define OMAP_TLL_CHANNEL_3_EN_MASK (1 2)
-
/* UHH Register Set */
#defineOMAP_UHH_REVISION (0x00)
#defineOMAP_UHH_SYSCONFIG (0x10)
@@ -132,8 +75,6 @@
#define OMAP4_P2_MODE_TLL (1 18)
#define OMAP4_P2_MODE_HSIC (3 18)
-#define OMAP_REV2_TLL_CHANNEL_COUNT2
-
#defineOMAP_UHH_DEBUG_CSR (0x44)
/* Values of UHH_REVISION - Note: these are not given in the TRM */
@@ -153,15 +94,12 @@ struct usbhs_hcd_omap {
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
struct clk *usbhost_p1_fck;
- struct clk *usbtll_p1_fck;
struct clk *utmi_p2_fck;
struct clk *usbhost_p2_fck;
- struct clk *usbtll_p2_fck;
[PATCH 5/5 V2 RESEND] ARM: OMAP: change the USB TLL clocks device name
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |8
arch/arm/mach-omap2/clock44xx_data.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..300ca51 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3306,7 +3306,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3342,7 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3397,9 +3397,9 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..d60e8d6 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3328,7 +3328,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_tll_hs_usb_ch2_clk,
usb_tll_hs_usb_ch2_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch0_clk,
usb_tll_hs_usb_ch0_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch1_clk,
usb_tll_hs_usb_ch1_clk,CK_443X),
- CLK(usbhs_omap, usbtll_ick, usb_tll_hs_ick,
CK_443X),
+ CLK(usbhs_tll,usbtll_ick, usb_tll_hs_ick,
CK_443X),
CLK(NULL, usim_ck, usim_ck,
CK_443X),
CLK(NULL, usim_fclk,usim_fclk,
CK_443X),
CLK(NULL, usim_fck, usim_fck,
CK_443X),
@@ -3378,7 +3378,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_ick,dummy_ck,
CK_443X),
CLK(NULL, uart4_ick,dummy_ck,
CK_443X),
CLK(usbhs_omap, usbhost_ick, dummy_ck,
CK_443X),
- CLK(usbhs_omap, usbtll_fck, dummy_ck,
CK_443X),
+ CLK(usbhs_tll,usbtll_fck, dummy_ck,
CK_443X),
CLK(omap_wdt, ick, dummy_ck,
CK_443X),
CLK(omap_timer.1, 32k_ck, sys_32k_ck,CK_443X),
CLK(omap_timer.2, 32k_ck, sys_32k_ck,CK_443X),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5 V2 RESEND] ARM: OMAP: USB: Build the USB HOST TLL omap device
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index dde8a11..b2a2dd7 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -35,10 +35,12 @@
#ifdef CONFIG_MFD_OMAP_USB_HOST
#define OMAP_USBHS_DEVICE usbhs_omap
+#define OMAP_USBTLL_DEVICE usbhs_tll
#defineUSBHS_UHH_HWMODNAME usb_host_hs
#define USBHS_TLL_HWMODNAMEusb_tll_hs
static struct usbhs_omap_platform_data usbhs_data;
+static struct usbtll_omap_platform_datausbtll_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
@@ -487,13 +489,14 @@ void __init setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- struct omap_hwmod *oh[2];
+ struct omap_hwmod *uhh_hwm, *tll_hwm;
struct platform_device *pdev;
int bus_id = -1;
int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
+ usbtll_data.port_mode[i] = pdata-port_mode[i];
ohci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.reset_gpio_port[i] = pdata-reset_gpio_port[i];
@@ -512,25 +515,35 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
setup_4430ohci_io_mux(pdata-port_mode);
}
- oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
- if (!oh[0]) {
+ uhh_hwm = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!uhh_hwm) {
pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
return;
}
- oh[1] = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
- if (!oh[1]) {
+ tll_hwm = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
+ if (!tll_hwm) {
pr_err(Could not look up %s\n, USBHS_TLL_HWMODNAME);
return;
}
- pdev = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
- (void *)usbhs_data, sizeof(usbhs_data),
+ pdev = omap_device_build(OMAP_USBTLL_DEVICE, bus_id, tll_hwm,
+ usbtll_data, sizeof(usbtll_data),
omap_uhhtll_latency,
ARRAY_SIZE(omap_uhhtll_latency), false);
if (IS_ERR(pdev)) {
- pr_err(Could not build hwmod devices %s,%s\n,
- USBHS_UHH_HWMODNAME, USBHS_TLL_HWMODNAME);
+ pr_err(Could not build hwmod device %s\n,
+ USBHS_TLL_HWMODNAME);
+ return;
+ }
+
+ pdev = omap_device_build(OMAP_USBHS_DEVICE, bus_id, uhh_hwm,
+ usbhs_data, sizeof(usbhs_data),
+ omap_uhhtll_latency,
+ ARRAY_SIZE(omap_uhhtll_latency), false);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build hwmod devices %s\n,
+ USBHS_UHH_HWMODNAME);
return;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
...
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
-} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+} else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
Having to patch all over the place for these revision defines leads
into unmaintainable code as new SoCs get added.
Please instead just check the revision once during init, then set
up some feature bits like I2C_OMAP_NEEDS_XYZ_RESET that the runtime
code can check.
Even now at probe
dev-rev is set by reading the rev register.
The (macro)name used to identify is only changed.
Also all the ips need reset the difference is that 2430 has less bits eg only
autoidle and reset.
So a flag needs reset may not be meaningful.
@@ -1055,7 +1055,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
-if (dev-rev = OMAP_I2C_REV_ON_3430)
+if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1073,7 +1073,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
-if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
That way the code does not need to change when new SoC revisions
get added.
I think it might still not need to change because of = .
I have just renamed
OMAP_I2C_REV_ON_3530_4430 as 3530 rev is not the same as 4430 that the name
implies.
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: [RESEND PATCH V3 2/2] arm/dts: OMAP2: Fix interrupt controller binding
* Jon Hunter jon-hun...@ti.com [120612 17:45]:
When booting with device-tree on an OMAP2420H4, the kernel is hanging when
initialising the interrupts and following kernel dumps is seen ...
[0.00] [ cut here ]
[0.00] WARNING: at arch/arm/mach-omap2/irq.c:271
omap_intc_of_init+0x50/0xb4()
[0.00] unable to get intc registers
[0.00] Modules linked in:
[0.00] [c001befc] (unwind_backtrace+0x0/0xf4) from [c0040c34]
(warn_slowpath_common+0x4c/0x64)
[0.00] [c0040c34] (warn_slowpath_common+0x4c/0x64) from
[c0040ce0] (warn_slowpath_fmt+0x30/0x40)
[0.00] [c0040ce0] (warn_slowpath_fmt+0x30/0x40) from [c066b8a4]
(omap_intc_of_init+0x50/0xb4)
[0.00] [c066b8a4] (omap_intc_of_init+0x50/0xb4) from [c0688b70]
(of_irq_init+0x144/0x288)
[0.00] [c0688b70] (of_irq_init+0x144/0x288) from [c0663294]
(init_IRQ+0x14/0x1c)
[0.00] [c0663294] (init_IRQ+0x14/0x1c) from [c06607fc]
(start_kernel+0x198/0x304)
[0.00] [c06607fc] (start_kernel+0x198/0x304) from [80008044]
(0x80008044)
[0.00] ---[ end trace 1b75b31a2719ed1c ]---
[0.00] of_irq_init: children remain, but no parents
The OMAP2 interrupt controller binding is missing the number of interrupts and
interrupt controller register address. Adding these fixes the problem.
Thanks this is a good one, applying into fixes.
Tony
This is based upon latest linux-omap master (3.5-rc1) git tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index f2ab4ea..581cb08 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -44,6 +44,8 @@
compatible = ti,omap2-intc;
interrupt-controller;
#interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x480FE000 0x1000;
};
uart1: serial@4806a000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: omap: dmtimer: set non-posted mode if iclk less than 4*fck
* DebBarma, Tarun Kanti tarun.ka...@ti.com [120606 04:15]: On Wed, May 30, 2012 at 2:51 AM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: Timers in PER domain periodically report old time from TCRR in posted mode if ick 4*fck. Therefore, set timer to non-posted whenever ick 4*fck for all timers. Is there an erratum assocaited with this? Yes, but it has not yet got into the document. Right now what we have is a hardware defect. Does this problem affect every SoC? Not quite sure about OMAP2 but it affects OMAP3+. This seems not too urgent and OK to queue into fixes-non-critical? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: omap: dmtimer: set non-posted mode if iclk less than 4*fck
Tony, On Wed, Jun 20, 2012 at 6:43 PM, Tony Lindgren t...@atomide.com wrote: * DebBarma, Tarun Kanti tarun.ka...@ti.com [120606 04:15]: On Wed, May 30, 2012 at 2:51 AM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: Timers in PER domain periodically report old time from TCRR in posted mode if ick 4*fck. Therefore, set timer to non-posted whenever ick 4*fck for all timers. Is there an erratum assocaited with this? Yes, but it has not yet got into the document. Right now what we have is a hardware defect. Does this problem affect every SoC? Not quite sure about OMAP2 but it affects OMAP3+. This seems not too urgent and OK to queue into fixes-non-critical? Lets hold on this entire series. We are thinking of better WA especially to avoid static dependencies. So just ignore this series all together for now. 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: [PATCH] arm: OMAP depends on MMU
* mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120607 17:55]: From: Arnd Bergmann a...@arndb.de There is no way to build OMAP kernels without an MMU at this point because of dependencies on MMU-only functions. As long as nobody is interested in fixing this, let's just disable this platforms for nommu kernels. Thanks, applying into fixes non-critical. Tony Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 84449dd..4b1fc0d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -934,6 +934,7 @@ config ARCH_DAVINCI config ARCH_OMAP bool TI OMAP + depends on MMU select HAVE_CLK select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
* Mohammed, Afzal af...@ti.com [120616 02:19]: Hi Tony, On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120615 03:26]: Here clock is required even before driver is probed, i.e for platform to calculate timings, that has to be passed through platform data. Eventually we should be able to move the gpmc registration to the driver probe, especially with device tree. There's no need to set up gpmc before the driver probe runs for the device using gpmc. Just how the gpmc init gets called from the driver probe is still a bit open though.. Sorry, I did not get you, can you please clarify OK, I'll try :) By gpmc registration, if you meant registering platform device for gpmc peripherals, for a board that uses the new gpmc driver interface*, it will be done in probe only. I was thinking when the gpmc needs to be initialized, and there should not be any need to do it earlier than at the gpmc using driver probe time. With device tree that is, as there's no need to stuff the gpmc timings into a board-*.c file. All the responsibilities of old gpmc init is now taken care by probe; probe in addition does setting up gpmc for each peripheral, registering platform device (if the board makes use of new driver interface). If a board uses new gpmc driver interface, gpmc for that device is not setup before gpmc probe. OK It may require some bus level hooks, or wrapper drivers for the generic device drivers like smsc911x. This too, not sure whether I follow you Well smsc911x has device tree binding, and is a generic driver. How do we trigger the gpmc initialization from a generic driver probe? I understand the necessity for clk rate information in driver, but seems unless we have a generic way to scale timings for all the kinds of peripheral, having it may not be of much help. We should not need to pass clock handles around. It's better to export some helper functions in the gpmc code for the calculation. Currently we have helper function in gpmc.c for the same, were you referring those ? Yes something that let's the driver call gpmc code to do the calculation. The other option would be to just add gpmc clock as a clock fwk node, and then the driver could clk_get() it as ick. Regards, Tony *: [1] converts omap3evm beagle board to use new interface, in addition to [1], similar to it, one more series would be posted to convert remaining boards also to use the new gpmc driver interface. As these cannot be tested by me and as it depends on final shape of this basic driver conversion series (or the present series), they have not yet been converted [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69917.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 RESEND] usb: otg: OMAP4: Fix the omap4430_phy_set_clk function
* Ruslan Bilovol ruslan.bilo...@ti.com [120612 10:42]:
If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.
Fix this - so now if we try to enable already enabled clocks
it works correctly.
Sounds like Felipe is on vacation. Trying to figure out if this
is something for the fixes branch:
What happens if this not fixed, do you get some error?
Was this caused by some recent commit?
Regards,
Tony
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0196683 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -97,7 +97,7 @@ int omap4430_phy_set_clk(struct device *dev, int on)
clk_enable(clk48m);
clk_enable(clk32k);
state = 1;
- } else if (state) {
+ } else if (!on state) {
/* Disable the phy clocks */
clk_disable(phyclk);
clk_disable(clk48m);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: Beagle: fix TFP410 powerdown GPIO init
* Tomi Valkeinen tomi.valkei...@ti.com [120614 05:25]:
On Thu, 2012-06-14 at 04:40 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 1:13 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Thu, 2012-06-14 at 00:59 -0700, Russ Dill wrote:
On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2012-06-13 at 23:58 -0700, Russ Dill wrote:
On Wed, Jun 13, 2012 at 2:20 AM, Tomi Valkeinen
tomi.valkei...@ti.com wrote:
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO handling for DVI output) moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver.
One
gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved
in
the Beagle board file. This causes the tfp410 driver to fail to
request
the gpio on Beagle, causing the driver to fail and thus the DVI
output
doesn't work.
Can you take the one I sent earlier instead?
http://www.spinics.net/lists/linux-omap/msg69913.html
Hmm, that probably doesn't apply. The power-down GPIO is now handled in
the tfp410 driver, not in the board files.
Give me a branch to rebase it onto and I will.
v3.5-rc2
This one (v4) already applies to v3.5-rc2
http://www.spinics.net/lists/linux-omap/msg70042.html
My ack for v4:
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
And I'd reword the description, fix instead of cleanup. The boot
warnings are errors. I don't think the DVI output works at all with
beagle in the current mainline.
Btw, please cc me when sending patches related to display.
Applying the following version into fixes. Took the first paragraph
with the regression info from Tomi's patch.
Regards,
Tony
From: Russ Dill russ.d...@ti.com
Date: Wed, 9 May 2012 15:15:03 -0700
Subject: [PATCH] ARM: OMAP: Fix Beagleboard DVI reset gpio
Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 (OMAP: board-files:
remove custom PD GPIO handling for DVI output) moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver. One
gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
the Beagle board file. This causes the tfp410 driver to fail to request
the gpio on Beagle, causing the driver to fail and thus the DVI output
doesn't work.
This patch removes several boot errors from board-omap3beagle.c:
- gpio_request: gpio--22 (DVI reset) status -22
- Unable to get DVI reset GPIO
There is a combination of leftover code and revision confusion.
Additionally, xM support is currently a hack.
For original Beagleboard this removes the double initialization of GPIO
170, properly configures it as an output, and wraps the initialization
in an if block so that xM does not attempt to request it.
For Beagleboard xM it removes reference to GPIO 129 which was part
of rev A1 and A2 designs, but never functioned. It then properly assigns
beagle_dvi_device.reset_gpio in beagle_twl_gpio_setup and removes the
hack of initializing it high. Additionally, it uses
gpio_set_value_cansleep since this GPIO is connected through i2c.
Unfortunately, there is no way to tell the difference between xM A2 and
A3. However, GPIO 129 does not function on rev A1 and A2, and the TWL
GPIO used on A3 and beyond is not used on rev A1 and A2, there are no
problems created by this fix.
Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
Signed-off-by: Russ Dill russ.d...@ti.com
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 79c6909..580fd17 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -81,13 +81,13 @@ static u8 omap3_beagle_version;
static struct {
int mmc1_gpio_wp;
int usb_pwr_level;
- int reset_gpio;
+ int dvi_pd_gpio;
int usr_button_gpio;
int mmc_caps;
} beagle_config = {
.mmc1_gpio_wp = -EINVAL,
.usb_pwr_level = GPIOF_OUT_INIT_LOW,
- .reset_gpio = 129,
+ .dvi_pd_gpio = -EINVAL,
.usr_button_gpio = 4,
.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
};
@@ -126,21 +126,21 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO OMAP3 Beagle Rev: Ax/Bx\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_AXBX;
beagle_config.mmc1_gpio_wp = 29;
- beagle_config.reset_gpio = 170;
+ beagle_config.dvi_pd_gpio = 170;
beagle_config.usr_button_gpio = 7;
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_C1_3;
beagle_config.mmc1_gpio_wp = 23;
- beagle_config.reset_gpio = 170;
+ beagle_config.dvi_pd_gpio = 170;
beagle_config.usr_button_gpio
Re: [RFC PATCH v2 03/11] mfd: omap: control: core system control driver
Hi, Tony.
On 06/20/2012 02:22 PM, Tony Lindgren wrote:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
+++ linux-2.6/drivers/mfd/omap-control-core.c
...
+u32 omap_control_readl(u16 offset)
+{
+return __raw_readl(omap_control_base + (offset));
+}
+
+void omap_control_writel(u32 val, u16 offset)
+{
+__raw_writel(val, omap_control_base + (offset));
+}
There should not be any need to have the individual drivers use
these. Please instead just set up something where individual drivers
register with the control module core, and get their own iobase
returned so they can use readl/writel and behave like normal device
drivers.
IIUC one of the reasons drivers/mfd/omap-control-core.c introduction is
replacement of arch/arm/mach-omap2/control.c. control.c provides
omap_ctrl_readl/omap_ctrl_writel API which are heavily used in
arch/arm/mach-omap2/:
arch/arm/mach-omap2/hsmmc.c
arch/arm/mach-omap2/usb-fs.c
arch/arm/mach-omap2/sr_device.c
arch/arm/mach-omap2/id.c
...
So,the same API set (omap_control_readl/omap_control_writel) was added to
omap-control-core.c.
If omap-control-core.c should only service users from driver/ directory, than I
agree - we can remove
omap_control_readl/omap_control_writel from omap-control-core.c.
But IIUC you are agree to switch arch/arm/mach-omap2/id.c from control.c to
omap-control-core.c. If arch/arm/mach-omap2/id.c is switched to control.c, then
I guess all arch/arm/mach-omap2/*.c should be switched to omap-control-core.c
as well. But this means that omap-control-core.c should provide
omap_control_readl/omap_control_writel API.
BR,
Konstantin Baydarov.
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
--
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: [PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
* Shubhrajyoti shubhrajy...@ti.com [120620 06:06]:
On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has
the
same I2C revision as OMAP4. Correct the revision definition to reflect
this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
...
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
Having to patch all over the place for these revision defines leads
into unmaintainable code as new SoCs get added.
Please instead just check the revision once during init, then set
up some feature bits like I2C_OMAP_NEEDS_XYZ_RESET that the runtime
code can check.
Even now at probe
dev-rev is set by reading the rev register.
The (macro)name used to identify is only changed.
Also all the ips need reset the difference is that 2430 has less bits eg only
autoidle and reset.
So a flag needs reset may not be meaningful.
Hmm OK so this is a cosmetic/readability fix..
..but your earlier patch now spreads the checking of revision
to the new non-init function omap_i2c_reset.
Why don't you just do this cosmetic/readability rename fix
before your 03/13 patch? Then set the already existing
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE during init for some
revisions and use that instead of the rev check in
omap_i2c_reset?
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: omap: dmtimer: set non-posted mode if iclk less than 4*fck
* Shilimkar, Santosh santosh.shilim...@ti.com [120620 06:21]: Tony, On Wed, Jun 20, 2012 at 6:43 PM, Tony Lindgren t...@atomide.com wrote: * DebBarma, Tarun Kanti tarun.ka...@ti.com [120606 04:15]: On Wed, May 30, 2012 at 2:51 AM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: Timers in PER domain periodically report old time from TCRR in posted mode if ick 4*fck. Therefore, set timer to non-posted whenever ick 4*fck for all timers. Is there an erratum assocaited with this? Yes, but it has not yet got into the document. Right now what we have is a hardware defect. Does this problem affect every SoC? Not quite sure about OMAP2 but it affects OMAP3+. This seems not too urgent and OK to queue into fixes-non-critical? Lets hold on this entire series. We are thinking of better WA especially to avoid static dependencies. So just ignore this series all together for now. OK 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: MFD USB host: prevents CORE retention in idle
Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM. I suggested using l-o master as a baseline, not -rc2. I just pushed a branch with this baseline so we are sure to be testing the same baseline. Please use the 'tmp/test/usb-host' branch from my tree[1] as the starting point. Build using omap2plus_defconfig, boot, then suspend/resume and send the output of 'cat /debug/pm_debug/count' This baseline is working fine for me on 3430/n900, 3530/Overo and 3630/Beagle-xM. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git -- 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: board_onenand_init() build error in linux-next
* Joe Woodward j...@terrafix.co.uk [120615 05:51]: Someone may have spotted this already... But if you build todays linux-next (next-20120615) without CONFIG_MTD_ONENAND_OMAP2 or CONFIG_MTD_ONENAND_OMAP2_MODULE then board_onenand_init() is defined in two places (in board-flash.c:102 as an empty function, and board-flash.h:56 as a static inline). This causes the build to fail as board-flash.c includes board-flash.h: CC arch/arm/mach-omap2/board-flash.o arch/arm/mach-omap2/board-flash.c:102:8: error: redefinition of 'board_onenand_init' arch/arm/mach-omap2/board-flash.h:56:20: note: previous definition of 'board_onenand_init' was here make[1]: *** [arch/arm/mach-omap2/board-flash.o] Error 1 I'm fairly sure this isn't right!? Yeah sounds like a bug, got a patch for it? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2: twl-common: Fix compiler warning
* Peter Ujfalusi peter.ujfal...@ti.com [120615 06:38]:
If the kernel is built only for OMAP2 the following warning will show up:
arch/arm/mach-omap2/twl-common.c:52: warning: ‘twl_set_voltage’ defined but
not used
arch/arm/mach-omap2/twl-common.c:58: warning: ‘twl_get_voltage’ defined but
not used
The twl_set/get_voltage callbacks only used when OMAP3/4 is selected.
Thanks applying into fixes.
Tony
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 119d5a9..5447c13 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -48,6 +48,7 @@ static struct i2c_board_info __initdata
omap4_i2c1_board_info[] = {
},
};
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static int twl_set_voltage(void *data, int target_uV)
{
struct voltagedomain *voltdm = (struct voltagedomain *)data;
@@ -59,6 +60,7 @@ static int twl_get_voltage(void *data)
struct voltagedomain *voltdm = (struct voltagedomain *)data;
return voltdm_get_voltage(voltdm);
}
+#endif
void __init omap_pmic_init(int bus, u32 clkrate,
const char *pmic_type, int pmic_irq,
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] OMAP: beagle: Set USB Host Port 1 to OMAP_USBHS_PORT_MODE_UNUSED
* Brian Austin brian.aus...@cirrus.com [120619 07:29]:
The beagleboard USB Host Port that is used is Port 2. The platform driver
sets MODE_PHY for port 1 causing pin muxing to override the pins on the
expansion
connector P17 when using board_mux[]. Since USBHS Port 1 is not connected
remove the case for muxing the USB Port1 pins by default.
Patch is based off of 3.5-rc2 from ASoC for-next branch
Tested with BeagleBoard xM revC and checked the userguides for Beagle xM and
revC to be sure USB Port2 is what is used.
Thanks applying into fixes.
Tony
Signed-off-by: Brian Austin brian.aus...@cirrus.com
---
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 79c6909..75eb88a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -435,7 +435,7 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
- .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Tony, On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120616 02:19]: On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote: By gpmc registration, if you meant registering platform device for gpmc peripherals, for a board that uses the new gpmc driver interface*, it will be done in probe only. I was thinking when the gpmc needs to be initialized, and there should not be any need to do it earlier than at the gpmc using driver probe time. With device tree that is, as there's no need to stuff the gpmc timings into a board-*.c file. I believe by gpmc needs to be initialized, you meant calculating gpmc timings, determining configuration, the things that are done in functions like gpmc_smsc911x_update etc. as in [1] and not initializing gpmc at hardware level. With the above assumption, I feel we need to have a way first to generalize gpmc timing calculation for different peripherals as suggested by Jon as well as have logic to handle timings that depends on cycles too. It may require some bus level hooks, or wrapper drivers for the generic device drivers like smsc911x. This too, not sure whether I follow you Well smsc911x has device tree binding, and is a generic driver. How do we trigger the gpmc initialization from a generic driver probe? Not sure whether device tree have capability to represent something like child devices, if non bus devices can have child devices, then we can have peripherals connected to gpmc as childs, but may be this will remain only as a dream; I need to get into DT to find things out We should not need to pass clock handles around. It's better to export some helper functions in the gpmc code for the calculation. Currently we have helper function in gpmc.c for the same, were you referring those ? Yes something that let's the driver call gpmc code to do the calculation. The other option would be to just add gpmc clock as a clock fwk node, and then the driver could clk_get() it as ick. For gpmc driver to calculate timings rather than platform code doing it, we first need to have a generalized way to calculate gpmc timings for all peripherals as well as have a logic to calculate timings based on time cycles, correct ? (to make sure we are talking the same thing) Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69926.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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
* Mohammed, Afzal af...@ti.com [120620 07:57]:
Hi Tony,
On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120616 02:19]:
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
By gpmc registration, if you meant registering platform device for
gpmc peripherals, for a board that uses the new gpmc driver interface*,
it will be done in probe only.
I was thinking when the gpmc needs to be initialized, and there should
not be any need to do it earlier than at the gpmc using driver probe
time. With device tree that is, as there's no need to stuff the gpmc
timings into a board-*.c file.
I believe by gpmc needs to be initialized, you meant calculating gpmc
timings, determining configuration, the things that are done in functions
like gpmc_smsc911x_update etc. as in [1] and not initializing gpmc at
hardware level. With the above assumption, I feel we need to have a way
first to generalize gpmc timing calculation for different peripherals as
suggested by Jon as well as have logic to handle timings that depends on
cycles too.
Yup. We'll be only getting the timings from device tree. Ideally the gpmc
code would just do all the calculations, but it sounds like device timings
may require some calculation on the gpmc consumer driver side too.
It may require some bus level hooks, or wrapper drivers for the generic
device drivers like smsc911x.
This too, not sure whether I follow you
Well smsc911x has device tree binding, and is a generic driver. How do
we trigger the gpmc initialization from a generic driver probe?
Not sure whether device tree have capability to represent something like
child devices, if non bus devices can have child devices, then we
can have peripherals connected to gpmc as childs, but may be this will
remain only as a dream; I need to get into DT to find things out
Yes the that's there set up automatically. But for the timings we
could have something like this to associate the following invented
gpmc timings with smsc911x:
/* in omap[234].dtsi */
gpmc: gpmc@480121234 {
compatible = ti,gpmc;
reg = 0x480121234 0x1234;
#address-cells = 0;
#size-cells = 0;
};
...
/* in some board *.dts file */
gpmc {
gpmc_cs1: gpmc_cs1_timings {
...
};
};
net@48001234 {
compatible = smsc,lan91c111;
reg = 0x48001234 0x1;
interrupts = 12;
gpmc_timings = gpmc_cs1;
};
We should not need to pass clock handles around. It's better to
export some helper functions in the gpmc code for the calculation.
Currently we have helper function in gpmc.c for the same, were you
referring those ?
Yes something that let's the driver call gpmc code to do the calculation.
The other option would be to just add gpmc clock as a clock fwk node,
and then the driver could clk_get() it as ick.
For gpmc driver to calculate timings rather than platform code doing it,
we first need to have a generalized way to calculate gpmc timings for
all peripherals as well as have a logic to calculate timings based on
time cycles, correct ? (to make sure we are talking the same thing)
Yes that might be tricky..
Tony
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69926.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: OMAP3EVM: cosmetic fixes for parent clk set
On 06/20/2012 04:14 AM, Zumeng Chen wrote:
Since it's no more sense to set parent for dummy clock,
so we can just ignore it to mute failed message.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
---
arch/arm/plat-omap/clock.c |4
drivers/mfd/omap-usb-host.c |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 62ec5c4..c7e26e4 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -149,6 +149,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
if (!arch_clock || !arch_clock-clk_set_parent)
return ret;
+ /* If the clock is a dummy clock just return */
+ if (clk == dummy_ck)
+ return 0;
+
spin_lock_irqsave(clockfw_lock, flags);
if (clk-usecount == 0) {
ret = arch_clock-clk_set_parent(clk, parent);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..c9d27c4 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -699,7 +699,7 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
+ /* for OMAP3 , the clk set parent fails */
Can't we remove this comment now with the above fix? It is no longer
relevant, right?
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Afzal,
On 06/19/2012 12:57 AM, Mohammed, Afzal wrote:
Hi Jon,
On Mon, Jun 18, 2012 at 21:31:46, Hunter, Jon wrote:
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
if (err)
return err;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
Sorry if I was not clear, but I was still thinking that we keep the
above instance of setting async mode.
:
static int gpmc_onenand_setup(void __iomem *onenand_base, int *freq_ptr)
{
struct device *dev = gpmc_onenand_device.dev;
+ u32 reg;
+
+ /* Ensure sync read and sync write are disabled */
+ reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
... and here we should just call omap2_onenand_set_async_mode(), ...
If omap2_onenand_set_async_mode is called from gpmc_onenand_setup removed
from gpmc_onenand_init, when using new gpmc driver interface, i.e. using
gpmc_onenand_update [1], we lost opportunity to provide gpmc driver with
configuration details for async mode causing a big warning about each
timings configurations that was left by bootloader (which is meant only
for cases where Kernel can't configure GPMC). Of course, we can put
omap2_onenand_set_async_mode in gpmc_onenand_update too, but then
unnecessarily, omap2_onenand_sey_async_mode would be called twice.
Please note that gpmc_onenand_setup is a callback by onenand driver.
Ok, I see your point. So today the _set_async_mode() is really doing two
things ...
1. It is calculating the timings
2. Programming the timings and setting async mode.
I think that it would be best if we were to make _set_async_mode() into
two functions, for example ...
1. omap2_onenand_get_async_timings()
2. omap2_onenand_set_async_timings()
Where the omap2_onenand_get_async_timings() calculates the timings and
can be used in both legacy mode and with the driver. Then
omap2_onenand_set_sync_timings() is just used in the legacy mode where
we don't have the driver to configure the chip-select.
Do you think that could work?
We could also do the same for omap2_onenand_set_sync_mode().
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data
As per the OMAP4 documentation, audio over HDMI should be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses
no-idle/force-idle settings instead of smart-idle mode.
This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..0cd6ee1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -865,6 +865,11 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ /*
+* HDMI audio requires to use no-idle mode. Hence,
+* set idle mode by software.
+*/
+ .flags = HWMOD_SWSUP_SIDLE,
};
/*
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
On 06/20/2012 10:12 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120620 07:57]:
Hi Tony,
On Wed, Jun 20, 2012 at 18:58:49, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120616 02:19]:
On Fri, Jun 15, 2012 at 18:15:20, Tony Lindgren wrote:
By gpmc registration, if you meant registering platform device for
gpmc peripherals, for a board that uses the new gpmc driver interface*,
it will be done in probe only.
I was thinking when the gpmc needs to be initialized, and there should
not be any need to do it earlier than at the gpmc using driver probe
time. With device tree that is, as there's no need to stuff the gpmc
timings into a board-*.c file.
I believe by gpmc needs to be initialized, you meant calculating gpmc
timings, determining configuration, the things that are done in functions
like gpmc_smsc911x_update etc. as in [1] and not initializing gpmc at
hardware level. With the above assumption, I feel we need to have a way
first to generalize gpmc timing calculation for different peripherals as
suggested by Jon as well as have logic to handle timings that depends on
cycles too.
Yup. We'll be only getting the timings from device tree. Ideally the gpmc
code would just do all the calculations, but it sounds like device timings
may require some calculation on the gpmc consumer driver side too.
It may require some bus level hooks, or wrapper drivers for the generic
device drivers like smsc911x.
This too, not sure whether I follow you
Well smsc911x has device tree binding, and is a generic driver. How do
we trigger the gpmc initialization from a generic driver probe?
Not sure whether device tree have capability to represent something like
child devices, if non bus devices can have child devices, then we
can have peripherals connected to gpmc as childs, but may be this will
remain only as a dream; I need to get into DT to find things out
Yes the that's there set up automatically. But for the timings we
could have something like this to associate the following invented
gpmc timings with smsc911x:
/* in omap[234].dtsi */
gpmc: gpmc@480121234 {
compatible = ti,gpmc;
reg = 0x480121234 0x1234;
#address-cells = 0;
#size-cells = 0;
};
...
/* in some board *.dts file */
gpmc {
gpmc_cs1: gpmc_cs1_timings {
...
};
};
net@48001234 {
compatible = smsc,lan91c111;
reg = 0x48001234 0x1;
interrupts = 12;
gpmc_timings = gpmc_cs1;
};
The above make sense to me, but I am struggling to see how we can make
the above work with the proposed driver Afzal has created. The problem
is how devices are getting registered with Afzal's driver in comparison
to how device tree will register them.
In Afzal's driver the gpmc_probe() is going to request and configure the
chip-selects and if successful, then call platform_device_register() to
register the child devices. So all child devices get registered during
the gpmc_probe() itself.
With device tree, my understanding is that, it will first register the
gpmc device and then the children afterwards. In other words, the
gpmc_probe will be called first and the children registered/probed after.
Therefore, I am wondering if Afzal's driver needs to register the gpmc
devices outside of the gpmc_probe() and add the devices as children. Or
maybe we tackle that when we migrate it to DT.
We should not need to pass clock handles around. It's better to
export some helper functions in the gpmc code for the calculation.
Currently we have helper function in gpmc.c for the same, were you
referring those ?
Yes something that let's the driver call gpmc code to do the calculation.
The other option would be to just add gpmc clock as a clock fwk node,
and then the driver could clk_get() it as ick.
For gpmc driver to calculate timings rather than platform code doing it,
we first need to have a generalized way to calculate gpmc timings for
all peripherals as well as have a logic to calculate timings based on
time cycles, correct ? (to make sure we are talking the same thing)
Yes that might be tricky..
I am wondering more and more if we need to do a clean-up of the timing
calculations prior to driver migration ...
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver
于 2012年06月20日 20:05, Sergei Shtylyov 写道:
Hello.
On 20-06-2012 13:14, Zumeng Chen wrote:
This was chosen by following the trace on the schematic from
component U131
and U134 to the CPEN pin on the USB3320 device.
TWL4030.GPIO2-...-(T2_GPIO2_3V3)U131-..nUSB2_EN-..U134-..EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.
This will set TWL4030.GPIO2 as output pin to drive EHCI tranceiver.
Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
---
arch/arm/mach-omap2/board-omap3evm.c | 9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 1bfbe42..02d8047 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -360,6 +360,15 @@ static int omap3evm_twl_gpio_setup(struct device
*dev,
platform_device_register(leds_gpio);
+ /* Enable VBUS switch by setting TWL4030.GPIO2DIR as output
+ * for starting USB tranceiver
+ */
+ if (get_omap3_evm_rev()= OMAP3EVM_BOARD_GEN_2) {
+ u8 val;
Empty line after declaration block wouldn't hurt...
Yes, Agreed.
Regards,
Zumeng
+ twl_i2c_read_u8(TWL4030_MODULE_GPIO,val, REG_GPIODATADIR1);
+ val |= 0x04; /* TWL4030.GPIO2DIR BIT at GPIODATADIR1(0x9B) */
+ twl_i2c_write_u8(TWL4030_MODULE_GPIO, val, REG_GPIODATADIR1);
+ }
return 0;
}
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: OMAP3EVM: cosmetic fixes for parent clk set
于 2012年06月21日 00:00, Jon Hunter 写道:
On 06/20/2012 04:14 AM, Zumeng Chen wrote:
Since it's no more sense to set parent for dummy clock,
so we can just ignore it to mute failed message.
Signed-off-by: Jon Hunterjon-hun...@ti.com
Signed-off-by: Zumeng Chenzumeng.c...@gmail.com
---
arch/arm/plat-omap/clock.c |4
drivers/mfd/omap-usb-host.c |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 62ec5c4..c7e26e4 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -149,6 +149,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
if (!arch_clock || !arch_clock-clk_set_parent)
return ret;
+ /* If the clock is a dummy clock just return */
+ if (clk ==dummy_ck)
+ return 0;
+
spin_lock_irqsave(clockfw_lock, flags);
if (clk-usecount == 0) {
ret = arch_clock-clk_set_parent(clk, parent);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..c9d27c4 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -699,7 +699,7 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
+ /* for OMAP3 , the clk set parent fails */
Can't we remove this comment now with the above fix? It is no longer
relevant, right?
Yes, NP.
Regards,
Zumeng
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: cleanups for v3.5
On Thu, 14 Jun 2012 23:24:10 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 14, 2012 at 5:45 AM, NeilBrown ne...@suse.de wrote:
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
Hi.
I'm not sure if it was this series or the following cleanups which broke
things for me, but I've been trying 3.5-rc2 on my GTA04 and the serial
console (ttyO2) dies as soon as the omap-gpio driver initialises.
After some digging I came up with this patch to gpio-omap.c
@@ -1124,6 +1124,9 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ if (bank-get_context_loss_count)
+ bank-context_loss_count =
+ bank-get_context_loss_count(bank-dev);
pm_runtime_enable(bank-dev);
pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
which fixes it.
What was happening was that when omap_gpio_probe calls pm_runtime_get_sync,
it calls
_od_runtime_resume - pm_generic_runtime_resume - omap_gpio_runtime_resume
- omap_gpio_restore_context
and then the serial port stops.
I reasoned that the context probably hadn't been set up yet, so restoring
from it broke things.
Initialising bank-context_loss_count seems sensible and would ensure that
we didn't try to restore the context until it has actually been lost.
I thought the following code exactly does that. That is context_lost_cnt_after
would be zero until there is context loss. The bank-context_loss_count is
zero
at the beginning. So, (context_lost_cnt_after != bank-context_loss_count)
would
be false and hence context restore should NOT happen? Not sure if I am
over looking
anything here
omap_gpio_runtime_resume(...)
{
...
if (bank-get_context_loss_count) {
context_lost_cnt_after =
bank-get_context_loss_count(bank-dev);
if (context_lost_cnt_after != bank-context_loss_count) {
omap_gpio_restore_context(bank);
} else {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
}
...
}
Hi,
I've looked more closely at this now.
The problem is that the initial context loss count is *not* zero. Not always.
The context loss count is the sum of
count = pwrdm-state_counter[PWRDM_POWER_OFF];
count += pwrdm-ret_logic_off_counter;
for (i = 0; i pwrdm-banks; i++)
count += pwrdm-ret_mem_off_counter[i];
(from pwrdm_get_context_loss_count()).
These are initlialised in _pwrdm_register
/* Initialize the powerdomain's state counter */
for (i = 0; i PWRDM_MAX_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
pwrdm-ret_logic_off_counter = 0;
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
What I'm seeing is that for wkup_pwrdm and dpll{3,4,5}_pwrdm,
the state that pwrdm_read_pwrst returns is PWRDM_POWER_OFF.
So that state_counter gets initialised to '1', and so the initial
context_loss_count, which includes that counter, is also '1'.
I think it is the wkup_pwrdm that covers the GPIOs that are causing problems
for me.
So either there is something seriously wrong with pwrdm_read_pwrst and it
shouldn't be reporting that the wkup_pwrdm is off, or we need to initialise
bank-context_loss_count like my patch does.
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH v8 8/8] x86/tlb: do flush_tlb_kernel_range by 'invlpg'
On 06/14/2012 09:26 AM, Alex Shi wrote:
On 06/14/2012 09:10 AM, Alex Shi wrote:
On 06/13/2012 10:56 PM, Andi Kleen wrote:
On Tue, Jun 12, 2012 at 05:06:45PM +0800, Alex Shi wrote:
This patch do flush_tlb_kernel_range by 'invlpg'. The performance pay
and gain was analysed in my patch (x86/flush_tlb: try flush_tlb_single
one by one in flush_tlb_range). Now we move this logical into kernel
part. The pay is multiple 'invlpg' execution cost, that is same. but
the gain(cost reducing of TLB entries refilling) is absolutely
increased.
The subtle point is whether INVLPG flushes global pages or not.
After some digging I found a sentence in the SDM that says it does.
So it may be safe.
Many thanks for your time!
What does it improve?
I just write a rough kernel modules that alloc some page arrays in kernel and
then map to vaddr by 'vmap'.
Then my macro benchmark inject a 'unmap_kernel_range' request from a sysfs
interface, and doing random memory access in user level during the time.
On my NHM EP 2P * 4 Cores * HT.
Without this patch, the memory access with 4 threads is ~12ns/time.
With this patch, the memory access with 4 threads is ~9ns/time.
With threads number increasing the benefit becomes small and nearly disappeared
after thread number up to 256.
But no any regression.
The rough user macro-benchmark and kernel module is here:
--- kernel module--
#include linux/init.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/kernel.h
#include linux/spinlock.h
#include linux/slab.h
#include linux/vmalloc.h
#include linux/gfp.h
#include linux/fs.h
#include linux/mman.h
#include linux/uaccess.h
#include linux/sysfs.h
#include linux/hrtimer.h
#include linux/device.h
#include linux/cpu.h
MODULE_LICENSE(Dual BSD/GPL);
/*
* $cat Makefile
* obj-m := modvmalloc.o
*
* compile command:
* #cd linux; make /home/alexs/exec/modules/modvmalloc.ko
*/
#define NR_PAGES(4)
#define NR_BLOCKS (1024)
struct block {
struct page ** page_array;
void *vaddr;
int page_count;
};
struct block *block;
static int blocks = NR_BLOCKS;
module_param(blocks, uint, 0400);
MODULE_PARM_DESC(blocks, map unmap blocks number );
static struct page **relay_alloc_page_array(unsigned int nr_pages)
{
const size_t pa_size = NR_PAGES * sizeof(struct page *);
if (pa_size PAGE_SIZE)
return vzalloc(pa_size);
return kzalloc(pa_size, GFP_KERNEL);
}
static void relay_free_page_array(struct page **array)
{
if (is_vmalloc_addr(array))
vfree(array);
else
kfree(array);
}
static void vmap_unmap(void)
{
//purge_vmap_area_lazy();
//vm_unmap_aliases();
int i;
for (i=0; i blocks; i++)
unmap_kernel_range((unsigned long)(block-vaddr),
NR_PAGES*PAGE_SIZE);
}
// ---
long vmap_num = 0;
static ssize_t __vmap_num_store(const char *buf,
size_t count, int smt)
{
long factor = 0;
long i;
unsigned long start, stop;
if (sscanf(buf, %ld, factor) != 1)
return -EINVAL;
vmap_num = factor;
start = ktime_to_ns(ktime_get());
vmap_unmap();
stop = ktime_to_ns(ktime_get());
i = blocks;
printk(KERN_ERR vunmap %ld times cost %ld ns/time\n,
i, (stop - start)/i);
return count;
}
static ssize_t vmap_num_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
return sprintf(buf, %ld\n, vmap_num);
}
static ssize_t vmap_num_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
return __vmap_num_store(buf, count, 0);
}
DEVICE_ATTR(vmap_num, 0644,
vmap_num_show,
vmap_num_store);
int create_sysfs_vmap_num(struct device *dev)
{
return device_create_file(dev, dev_attr_vmap_num);
}
static int mapunmap_init(void){
long i,j,k;
create_sysfs_vmap_num(cpu_subsys.dev_root);
block = kmalloc(sizeof(struct block)*blocks, GFP_KERNEL);
for (k=0; k blocks; k++) {
block[k].page_count = 0;
block[k].page_array = relay_alloc_page_array(NR_PAGES);
if (!block[k].page_array)
return -1;
for (i = 0; i NR_PAGES; i++) {
block[k].page_array[i] = alloc_page(GFP_KERNEL);
if (unlikely(!block[k].page_array[i])) {
printk(KERN_ERR \talloc page error \n);
goto depopulate;
}
}
if (i!=NR_PAGES)goto depopulate;
block[k].page_count = i;
block[k].vaddr = vmap(block[k].page_array, NR_PAGES, VM_MAP,
PAGE_KERNEL);
if
Re: [PATCH 04/29] ARM: omap: clk: use clk_prepare_enable and clk_disable_unprepare
On Wednesday 20 June 2012 05:11 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120614 22:01]: On Friday 15 June 2012 12:41 AM, Mike Turquette wrote: On 20120614-18:16, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Based on initial changes from Mike turquette. Sounds like these kind of patches should be a separate series to prepare for the common clk fwk conversion? It seems these could already get merged separately? yes, I will post them out separately as a preparatory series for CCF conversion. I also have some to get rid of the omap_clk_get_by_name() usage and direct dereferencing of 'struct clk'. Paul, are you ok to look at them as preparatory patches for CCF conversion too? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/29] ARM: omap: clk: use clk_prepare_enable and clk_disable_unprepare
On Thu, 21 Jun 2012, Rajendra Nayak wrote: Paul, are you ok to look at them as preparatory patches for CCF conversion too? Yes. Also it looks like some of these patches should go through Mike since they add features to the CCF, so it's probably best to break those out into a separate series too. - 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: [PATCH 04/29] ARM: omap: clk: use clk_prepare_enable and clk_disable_unprepare
On Thursday 21 June 2012 11:13 AM, Paul Walmsley wrote: On Thu, 21 Jun 2012, Rajendra Nayak wrote: Paul, are you ok to look at them as preparatory patches for CCF conversion too? Yes. Also it looks like some of these patches should go through Mike since they add features to the CCF, so it's probably best to break those out into a separate series too. ok, thanks will do. - 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
