Re: [PATCH v4 07/11] Serial: OMAP: Add runtime pm support for omap-serial driver
On Fri, Sep 9, 2011 at 5:54 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Adapts omap-serial driver to use pm_runtime API's.
1.) Moving context_restore func to driver from serial.c
2.) Use runtime irq safe to use get_sync from irq context.
3.) autosuspend for port specific activities and put for reg access.
Re: autosuspend, it looks like the driver now has 2 mechanisms for
tracking activity. The runtime PM 'mark last busy' and the existing
'up-port_activity = jiffies' stuff. Do you think those could be
unified?
Is there a way where we can retrieve the last busy jiffie value
using runtime API? I don't find that available.
At first glance, it looks like most places with a _mark_last_busy() also
have a up-port_activity update. I'm not familiar enough with the
driver to make the call, but they look awfully similar.
Ok, I will check whether I can get rid if it.
4.) for earlyprintk usage the debug macro will write to console uart
so keep uart clocks active from boot, idle using hwmod API's re-enable
back
using runtime API's.
/me doesn't understand
I have added this reason in early mail reply to 04/11 patch review
[needed for earlyprintk option from low level debug ]
5.) Moving context restore to runtime suspend and using reg values from port
structure to restore the uart port context based on context_loss_count.
Maintain internal state machine for avoiding repeated enable/disable of
uart port wakeup mechanism.
6.) Add API to enable wakeup and check wakeup status.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 49 ++
arch/arm/plat-omap/include/plat/omap-serial.h | 10 ++
drivers/tty/serial/omap-serial.c | 211
++---
3 files changed, 250 insertions(+), 20 deletions(-)
[..]
+
+static void omap_uart_wakeup_enable(struct platform_device *pdev, bool
enable)
+{
+ struct omap_device *od;
+ struct omap_uart_port_info *up = pdev-dev.platform_data;
+
+ /* Set or clear wake-enable bit */
+ if (up-wk_en up-wk_mask) {
+ u32 v = __raw_readl(up-wk_en);
+ if (enable)
+ v |= up-wk_mask;
+ else
+ v = ~up-wk_mask;
+ __raw_writel(v, up-wk_en);
+ }
+
+ od = to_omap_device(pdev);
+ if (enable)
+ omap_hwmod_enable_wakeup(od-hwmods[0]);
+ else
+ omap_hwmod_disable_wakeup(od-hwmods[0]);
+}
+
Here again, this is difficult to review because you removed the code in
[4/11] and add it back here, but with rather different functionality
with no description as to why.
will move this change as part of 4/11 itself.
The previous version enabled wakeups at the PRCM and at the IO ring.
This version enables wakeups at the PRCM as well but instead of enabling
them at the IO ring, enables them at the module.
Since we are gating using prepare idle call I think
we can use this enable wake-up call as part of prepare idle call itself,
as done earlier.
struct omap_hwmod *omap_uart_hwmod_lookup(int num)
{
struct omap_hwmod *oh;
@@ -317,6 +363,9 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
pdata-uartclk = OMAP24XX_BASE_BAUD * 16;
pdata-flags = UPF_BOOT_AUTOCONF;
+ pdata-enable_wakeup = omap_uart_wakeup_enable;
+ pdata-chk_wakeup = omap_uart_chk_wakeup;
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
pdev = omap_device_build(name, bdata-id, oh, pdata,
sizeof(*pdata), omap_uart_latency,
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 06e3aa2..7fc63b8 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -67,6 +67,9 @@ struct omap_uart_port_info {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
+ void (*enable_wakeup)(struct platform_device *, bool);
+ bool (*chk_wakeup)(struct platform_device *);
+ u32 (*get_context_loss_count)(struct device *);
};
struct uart_omap_dma {
@@ -118,7 +121,14 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
char name[20];
unsigned long port_activity;
+ u32 context_loss_cnt;
+ u8 wake_status;
+
unsigned int errata;
+ unsigned int clocked;
This is a legacy from serial.c and should not be needed. Checking
pm_runtime_suspended() will provide the same info.
Yes will try to use that.
+ u8 console_locked;
+
+ bool (*chk_wakeup)(struct platform_device *);
s/chk/check/ please. It's not that much longer.
will change.
};
Re: [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers
On Thursday 08 September 2011 11:27 PM, Kevin Hilman wrote: From 8ad40f8c7f950105b25cc8d2cc35caa50871f86f Mon Sep 17 00:00:00 2001 From: Kevin Hilmankhil...@ti.com Date: Wed, 7 Sep 2011 12:04:44 -0700 Subject: [PATCH 1/2] OMAP2/3: PM: trigger CPU PM notifiers in idle and suspend path Add calls to CPU PM notifier core in the idle and suspend paths so any CPU PM notifiers are properly called. [add more description about the need to trigger notifiers only after next power states are programmed.] Signed-off-by: Kevin Hilmankhil...@ti.com --- arch/arm/mach-omap2/pm24xx.c |5 + arch/arm/mach-omap2/pm34xx.c |5 + 2 files changed, 10 insertions(+), 0 deletions(-) [...] diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 7255d9b..b167c7f 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -29,6 +29,7 @@ #includelinux/delay.h #includelinux/slab.h #includelinux/console.h +#includelinux/cpu_pm.h #includetrace/events/power.h #includeasm/suspend.h @@ -386,6 +387,8 @@ void omap_sram_idle(void) if (!console_trylock()) goto console_still_active; + cpu_pm_enter(); + I don't think you should blindly call CPU_PM notifiers. This should called if the MPU targeted state is OFF. With blind notifiers, CPU context like VFP or GIC or L2 will be saved and restored even if CPU/CPU cluster is not entering into low power. This is highly un-optimal for CPUIDLE and defeats the purpose of adding different CPU PM events. Looking at your UART driver notfier usage, you might need add new events instead of using the CPU and CPU cluster events. Even though on OMAP UART is idles as part of CPU, it's still an independent PD. E.g just to make a point, MPU is programmed to INACTIVE and let say PER PD is programmed to OFF. From MPU point of view the CPU_PM notifier change need not be called because, it's doesn't loose any context, but UART notifier needs to be executed since UART context must be saved. 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 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Fri, 9 Sep 2011, Santosh wrote: On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote: Santosh Shilimkarsantosh.shilim...@ti.com writes: OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating wakeup event from the incoming interrupts and enable bits. It is implemented in MPU always ON power domain. During normal operation, WakeupGen delivers external interrupts directly to the GIC. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Kevin Hilmankhil...@ti.com [...] +#ifdef CONFIG_PM +/* + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag, + * so no action is necessary in set_wake, but implement an empty handler + * here to prevent enable_irq_wake() returning an error. + * FIXME: Remove the dummy handler once gen irq code fix above. + */ Just curious... is there a fix for this pending for v3.2? I have sent a proposed change to Thomas but have not seen any response yet from him. http://www.spinics.net/lists/arm-kernel/msg134297.html diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 0a7840a..cd4bc01 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on) struct irq_desc *desc = irq_to_desc(irq); int ret = -ENXIO; + if (irq_desc_get_chip(desc)-flags IRQCHIP_MASK_ON_SUSPEND) + return 0; + if (desc-irq_data.chip-irq_set_wake) ret = desc-irq_data.chip-irq_set_wake(desc-irq_data, on); The flag says: MASK ON SUSPEND and it does not imply that you don't need a wake function. There might be cases where you want to setup stuff in that function in order to have the wakeup happen on that interrupt line despite of the mask on suspend. We either need a separate flag or a global dummy set_wake function in the core to avoid empty copies all over the place. Thanks, tglx -- 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 14/25] OMAP4: PM: Add CPUX OFF mode support
Hi Santosh, On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote: This patch adds the CPU0 and CPU1 off mode support. CPUX close switch retention (CSWR) is not supported by hardware design. The CPUx OFF mode isn't supported on OMAP4430 ES1.0 CPUx sleep code is common for hotplug, suspend and CPUilde. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/Makefile|3 +- arch/arm/mach-omap2/include/mach/omap-secure.h |8 + arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++ arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++ arch/arm/mach-omap2/omap-smp.c |6 + arch/arm/mach-omap2/omap4-sar-layout.h |9 + arch/arm/mach-omap2/pm44xx.c|6 + arch/arm/mach-omap2/sleep44xx.S | 213 +++ 8 files changed, 518 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c [...] diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 049f426..230ab8c 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -11,8 +11,221 @@ #include linux/linkage.h #include asm/system.h +#include asm/smp_scu.h +#include asm/memory.h +#include asm/hardware/cache-l2x0.h +#include plat/omap44xx.h #include mach/omap4-common.h +#include mach/omap-secure.h + +#include omap4-sar-layout.h + +#ifdef CONFIG_SMP + +.macro DO_SMC + dsb + smc #0 + dsb +.endm + +ppa_zero_params: + .word 0x0 + +/* + * = + * == CPU suspend finisher == + * = + * + * void omap4_finish_suspend(unsigned long cpu_state) + * + * This function code saves the CPU context and performs the CPU + * power down sequence. Calling WFI effectively changes the CPU + * power domains states to the desired target power state. + * + * @cpu_state : contains context save state (r0) + * 0 - No context lost + * 1 - CPUx L1 and logic lost: MPUSS CSWR + * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR + * 3 - CPUx L1 and logic lost + GIC + L2 lost: MPUSS OFF I was told by rmk that same as imx6q, omap44xx will retain L2 content across suspen/resume cycle. Then what does L2 lost mean here? Or what rmk meant is the case cpu_state == 2? -- Regards, Shawn -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote: On Fri, 9 Sep 2011, Santosh wrote: On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote: Santosh Shilimkarsantosh.shilim...@ti.com writes: OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating wakeup event from the incoming interrupts and enable bits. It is implemented in MPU always ON power domain. During normal operation, WakeupGen delivers external interrupts directly to the GIC. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Kevin Hilmankhil...@ti.com [...] +#ifdef CONFIG_PM +/* + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag, + * so no action is necessary in set_wake, but implement an empty handler + * here to prevent enable_irq_wake() returning an error. + * FIXME: Remove the dummy handler once gen irq code fix above. + */ Just curious... is there a fix for this pending for v3.2? I have sent a proposed change to Thomas but have not seen any response yet from him. http://www.spinics.net/lists/arm-kernel/msg134297.html diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 0a7840a..cd4bc01 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on) struct irq_desc *desc = irq_to_desc(irq); int ret = -ENXIO; + if (irq_desc_get_chip(desc)-flags IRQCHIP_MASK_ON_SUSPEND) + return 0; + if (desc-irq_data.chip-irq_set_wake) ret = desc-irq_data.chip-irq_set_wake(desc-irq_data, on); The flag says: MASK ON SUSPEND and it does not imply that you don't need a wake function. There might be cases where you want to setup stuff in that function in order to have the wakeup happen on that interrupt line despite of the mask on suspend. I see your point. We either need a separate flag or a global dummy set_wake function in the core to avoid empty copies all over the place. A flag is probably better since you mentioned that on some arch, there might be need to have actual set_wake() handler. Or if the global dummy can be over-ridden by platform, that's fine too. 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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote: This patch adds the CPU0 and CPU1 off mode support. CPUX close switch retention (CSWR) is not supported by hardware design. The CPUx OFF mode isn't supported on OMAP4430 ES1.0 CPUx sleep code is common for hotplug, suspend and CPUilde. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Kevin Hilmankhil...@ti.com --- arch/arm/mach-omap2/Makefile|3 +- arch/arm/mach-omap2/include/mach/omap-secure.h |8 + arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++ arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++ arch/arm/mach-omap2/omap-smp.c |6 + arch/arm/mach-omap2/omap4-sar-layout.h |9 + arch/arm/mach-omap2/pm44xx.c|6 + arch/arm/mach-omap2/sleep44xx.S | 213 +++ 8 files changed, 518 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c [...] diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 049f426..230ab8c 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -11,8 +11,221 @@ #includelinux/linkage.h #includeasm/system.h +#includeasm/smp_scu.h +#includeasm/memory.h +#includeasm/hardware/cache-l2x0.h +#includeplat/omap44xx.h #includemach/omap4-common.h +#includemach/omap-secure.h + +#include omap4-sar-layout.h + +#ifdef CONFIG_SMP + +.macro DO_SMC + dsb + smc #0 + dsb +.endm + +ppa_zero_params: + .word 0x0 + +/* + * = + * == CPU suspend finisher == + * = + * + * void omap4_finish_suspend(unsigned long cpu_state) + * + * This function code saves the CPU context and performs the CPU + * power down sequence. Calling WFI effectively changes the CPU + * power domains states to the desired target power state. + * + * @cpu_state : contains context save state (r0) + * 0 - No context lost + * 1 - CPUx L1 and logic lost: MPUSS CSWR + * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR + * 3 - CPUx L1 and logic lost + GIC + L2 lost: MPUSS OFF I was told by rmk that same as imx6q, omap44xx will retain L2 content across suspen/resume cycle. Then what does L2 lost mean here? Or what rmk meant is the case cpu_state == 2? Yes. The last case is entire SOC OFF. We call Device OFF in OMAP. All voltages will scale to 0 V. This isn't supported by this series. 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 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Fri, 9 Sep 2011, Santosh wrote:
On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
The flag says: MASK ON SUSPEND and it does not imply that you don't
need a wake function. There might be cases where you want to setup
stuff in that function in order to have the wakeup happen on that
interrupt line despite of the mask on suspend.
I see your point.
We either need a separate flag or a global dummy set_wake function in
the core to avoid empty copies all over the place.
A flag is probably better since you mentioned that on some arch, there
might be need to have actual set_wake() handler. Or if the global
dummy can be over-ridden by platform, that's fine too.
Global dummy would mean:
int irq_set_wake_dummy(...)
{
return 0;
}
And you just add it to your chip, but either way I don't care whether
it's a dummy function or a flag.
Thanks,
tglx
--
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: [PATCHv7 3/9] OMAP2+: hwmod: Add API to check IO PAD wakeup status
Hi Tero, Govindraj,
On Thu, Sep 8, 2011 at 5:22 PM, Tero Kristo t-kri...@ti.com wrote:
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c | 30
++
arch/arm/mach-omap2/mux.h | 13 +++
arch/arm/mach-omap2/omap_hwmod.c | 7 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c7fb22a..50ee806 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
return NULL;
}
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup event is set for pad else false
+ * if wakeup is not occured or pads are not avialable.
+ */
This comment is unclear wrt the code below.
IMO the code says:
Returns true if the wake-up capability is enabled and a wake-up event
occured on the pad; returns false otherwise.
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ int i;
+ unsigned int val;
+ u8 ret = false;
+
+ for (i = 0; i hmux-nr_pads; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
+
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ val = omap_mux_read(pad-partition,
+ pad-mux-reg_offset);
+ if (val OMAP_WAKEUP_EVENT) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
Regards,
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers
On 9 September 2011 05:29, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Jassi's suggestion was that we should have some magic to automatically generate defaults for the relevant device registrations to sidestep these issues. Perhaps there is some misunderstanding no witchcraft is involved here. To be clear, I suggested moving platform_device definition and registration from 12 board files to some common platform file and use machine_is_xxx() to assign names of those platform devices. Btw, omap_init_audio() is already called from an arch_initcall. Also please note that currently there's no platform_data needed to be passed. If that requirement arise in future, an optional set_asoc_platdata(void *pdata) could be defined beside platform_device creation. While the idea is not absolutely good, imho, it's certainly an improvement over this patch. Or am I overlooking something ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
On Friday 09 September 2011 01:48 PM, Thomas Gleixner wrote:
On Fri, 9 Sep 2011, Santosh wrote:
On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
The flag says: MASK ON SUSPEND and it does not imply that you don't
need a wake function. There might be cases where you want to setup
stuff in that function in order to have the wakeup happen on that
interrupt line despite of the mask on suspend.
I see your point.
We either need a separate flag or a global dummy set_wake function in
the core to avoid empty copies all over the place.
A flag is probably better since you mentioned that on some arch, there
might be need to have actual set_wake() handler. Or if the global
dummy can be over-ridden by platform, that's fine too.
Global dummy would mean:
int irq_set_wake_dummy(...)
{
return 0;
}
And you just add it to your chip, but either way I don't care whether
it's a dummy function or a flag.
Will below patch work for you then ?
Attaching the same in case mailer damages it.
Regards,
Santosh
From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 9 Sep 2011 13:59:35 +0530
Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of
dummy set_wake() handler.
Certain IRQCHIP's may not need to install the irq_set_wake() handler if
the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
enable_irq_wake() will return an error. That needs the IRQCHIP to install
an empty set_wake handler.
Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
irq code that irq_set_wake() handler is not necessary.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Thomas Gleixner t...@linutronix.de
---
include/linux/irq.h |2 ++
kernel/irq/manage.c |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 5951730..4b0d842 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -336,12 +336,14 @@ struct irq_chip {
* IRQCHIP_MASK_ON_SUSPEND:Mask non wake irqs in the suspend path
* IRQCHIP_ONOFFLINE_ENABLED: Only call irq_on/off_line callbacks
* when irq enabled
+ * IRQCHIP_SKIP_SET_WAKE: Skip chip.irq_set_wake(), for this IRQCHIP
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 0),
IRQCHIP_EOI_IF_HANDLED = (1 1),
IRQCHIP_MASK_ON_SUSPEND = (1 2),
IRQCHIP_ONOFFLINE_ENABLED = (1 3),
+ IRQCHIP_SKIP_SET_WAKE = (1 4),
};
/* This include will go away once we isolated irq_desc usage to core
code */
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 9b956fa..7e1a3ed 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq,
unsigned int on)
struct irq_desc *desc = irq_to_desc(irq);
int ret = -ENXIO;
+ if (irq_desc_get_chip(desc)-flags IRQCHIP_SKIP_SET_WAKE)
+ return 0;
+
if (desc-irq_data.chip-irq_set_wake)
ret = desc-irq_data.chip-irq_set_wake(desc-irq_data, on);
--
1.7.4.1
From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 9 Sep 2011 13:59:35 +0530
Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of dummy set_wake() handler.
Certain IRQCHIP's may not need to install the irq_set_wake() handler if
the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
enable_irq_wake() will return an error. That needs the IRQCHIP to install
an empty set_wake handler.
Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
irq code that irq_set_wake() handler is not necessary.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Thomas Gleixner t...@linutronix.de
---
include/linux/irq.h |2 ++
kernel/irq/manage.c |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 5951730..4b0d842 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -336,12 +336,14 @@ struct irq_chip {
* IRQCHIP_MASK_ON_SUSPEND: Mask non wake irqs in the suspend path
* IRQCHIP_ONOFFLINE_ENABLED: Only call irq_on/off_line callbacks
*when irq enabled
+ * IRQCHIP_SKIP_SET_WAKE: Skip chip.irq_set_wake(), for this IRQCHIP
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 0),
IRQCHIP_EOI_IF_HANDLED = (1 1),
IRQCHIP_MASK_ON_SUSPEND = (1 2),
IRQCHIP_ONOFFLINE_ENABLED = (1 3),
+ IRQCHIP_SKIP_SET_WAKE = (1 4),
};
/* This include will go away once we isolated irq_desc usage to core code */
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 9b956fa..7e1a3ed 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on)
struct irq_desc *desc =
Re: [PATCH 5/6 V4] OMAP4: Temperature sensor device support
Hi Keerthy,
On Wed, Aug 31, 2011 at 7:25 PM, Keerthy j-keer...@ti.com wrote:
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/temp_sensor_device.c | 188
++
arch/arm/plat-omap/Kconfig | 12 ++
3 files changed, 201 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor_device.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2d5d981..5812fb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
+obj-$(CONFIG_OMAP_TEMP_SENSOR) += temp_sensor_device.o
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
# SMP support ONLY available for OMAP4
diff --git a/arch/arm/mach-omap2/temp_sensor_device.c
b/arch/arm/mach-omap2/temp_sensor_device.c
new file mode 100644
index 000..12d6789
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor_device.c
@@ -0,0 +1,188 @@
+/*
+ * OMAP on die Temperature sensor device file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/delay.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/mutex.h
+#include linux/idr.h
+#include plat/omap_device.h
+#include pm.h
+#include plat/temperature_sensor.h
+
+
+int omap_temp_sensor_device_idle(struct omap_device *od)
+{
+ struct omap_temp_sensor_registers *registers;
+ struct resource *mem;
+ void __iomem *phy_base;
+ unsigned long timeout;
+ u32 ret = 0, temp;
+
+ mem = platform_get_resource(od-pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(od-pdev.dev, no mem resource\n);
+ ret = -EINVAL;
+ goto plat_res_err;
+ }
+
+ phy_base = ioremap(mem-start, resource_size(mem));
+
+ if (!phy_base) {
+ dev_err(od-pdev.dev, ioremap failed\n);
+ ret = -ENOMEM;
+ goto plat_res_err;
+ }
+
+ if (!strcmp(od-hwmods[0]-dev_attr, mpu))
+ registers = omap_mpu_temp_sensor_registers;
+
+ temp = __raw_readl(phy_base + registers-temp_sensor_ctrl);
+ temp |= registers-bgap_tempsoff_mask;
+
+ /* BGAP_TEMPSOFF should be set to 1 before gating clock */
+ __raw_writel(temp, phy_base + registers-temp_sensor_ctrl);
+ temp = __raw_readl(phy_base + registers-bgap_status);
+ timeout = jiffies + msecs_to_jiffies(5);
+
+ /* wait till the clean stop bit is set or till the timeout expires */
+ while (!(temp | registers-status_clean_stop_mask)
+ !(time_after(jiffies, timeout))) {
+ temp = __raw_readl(phy_base + registers-bgap_status);
+ usleep_range(500, 2000);
+ }
+
+ if (time_after(jiffies, timeout))
+ dev_err(od-pdev.dev, Clean stop bit not set\n);
+
+ ret = omap_device_idle_hwmods(od);
+ iounmap(phy_base);
+plat_res_err:
+ return ret;
+}
+
+int omap_temp_sensor_device_activate(struct omap_device *od)
+{
+ struct omap_temp_sensor_registers *registers;
+ struct resource *mem;
+ void __iomem *phy_base;
+ u32 ret = 0, temp;
+
+ ret = omap_device_enable_hwmods(od);
+ if (ret 0)
+ return ret;
+ mem = platform_get_resource(od-pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(od-pdev.dev, no mem resource\n);
+ return -EINVAL;
+ }
+
+ phy_base = ioremap(mem-start, resource_size(mem));
+ if (!phy_base) {
+ dev_err(od-pdev.dev, ioremap failed\n);
+ ret = -ENOMEM;
+ goto plat_res_err;
+ }
+
+ if (!strcmp(od-hwmods[0]-dev_attr,
Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers
On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote: On Fri, Sep 09, 2011 at 12:01:02AM +0100, Russell King - ARM Linux wrote: On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote: What will happen for device tree is that there will be a device in the device tree for the ASoC board. Sounds like you just solved the machine_is_xxx() problem in ASoC land too there. If you're _already_ going for separate devices to describe the ASoC stuff on the board, then there's no reason that couldn't have already been done to eliminate the machine_is_xxx() usage in ASoC - rather than complaining about machine_is_xxx() not being a very good solution. The problem is that someone has to manually go and add the device to every board that needs one and people find that tedious and slightly inelegant Sheesh. So now you're arguing against your statement above? Please stop wasting my 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 12/25] OMAP: Add support to allocate the memory for secure RAM
On Friday 09 September 2011 12:49 AM, Jean Pihet wrote: On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Allocate the memory to save secure ram context which needs to be done when MPU is hitting off mode. The ROM code expects a physical address to this memory and hence use memblock APIs to reserve this memory as part of .reserve() callback. Maximum possible size is allocated and can cater to OMAP3XXX / OMAP4XXX secure RAM size requirements. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com --- arch/arm/mach-omap2/include/mach/omap-secure.h |4 +++ arch/arm/mach-omap2/omap-secure.c | 29 arch/arm/plat-omap/common.c|3 ++ 3 files changed, 36 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h b/arch/arm/mach-omap2/include/mach/omap-secure.h index 26e7bcc..e2f95a0 100644 --- a/arch/arm/mach-omap2/include/mach/omap-secure.h +++ b/arch/arm/mach-omap2/include/mach/omap-secure.h @@ -26,6 +26,8 @@ #define FLAG_FIQ_ENABLE0x1 #define NO_FLAG0x0 +/* Maximum Secure memory storage size */ +#define OMAP_SECURE_RAM_STORAGE(88 * SZ_1K) Is this valid for all supported devices? How to differentiate variations in the size for new chips variants in the future? You don't have to. ROM code does that job. We should just ensure that maximum needed memory is made available to secure code. 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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Friday 09 September 2011 01:09 AM, Jean Pihet wrote:
On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
retention (CSWR) is not supported by hardware design.
The CPUx OFF mode isn't supported on OMAP4430 ES1.0
CPUx sleep code is common for hotplug, suspend and CPUilde.
Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Kevin Hilmankhil...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/include/mach/omap-secure.h |8 +
arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++
arch/arm/mach-omap2/omap-smp.c |6 +
arch/arm/mach-omap2/omap4-sar-layout.h |9 +
arch/arm/mach-omap2/pm44xx.c|6 +
arch/arm/mach-omap2/sleep44xx.S | 213 +++
8 files changed, 518 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b032c21..b4f2eeb 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,7 +63,8 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o sleep44xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o sleep44xx.o \
+ omap-mpuss-lowpower.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
index e2f95a0..0062d49 100644
--- a/arch/arm/mach-omap2/include/mach/omap-secure.h
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -35,10 +35,18 @@
#define OMAP4_HAL_SAVEALL_INDEX0x1c
#define OMAP4_HAL_SAVEGIC_INDEX0x1d
+/* Secure Monitor mode APIs */
+#define OMAP4_MON_SCU_PWR_INDEX0x108
+
+/* Secure PPA(Primary Protected Application) APIs */
+#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
+
+#ifndef __ASSEMBLER__
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
+#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 040dcf6..662f37c 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -45,5 +45,30 @@ extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32
clear_mask);
extern void omap_auxcoreboot_addr(u32 cpu_addr);
extern u32 omap_read_auxcoreboot0(void);
#endif
+
+#if defined(CONFIG_SMP) defined(CONFIG_PM)
+extern int omap4_mpuss_init(void);
+extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
+extern int omap4_finish_suspend(unsigned long cpu_state);
+extern void omap4_cpu_resume(void);
+#else
+static inline int omap4_enter_lowpower(unsigned int cpu,
+ unsigned int power_state)
+{
+ omap_do_wfi();
+ return 0;
+}
+
+static inline int omap4_mpuss_init(void)
+{
+ return 0;
+}
+
+static inline int omap4_finish_suspend(unsigned long cpu_state)
+{}
The int function should return something (0?)
Has the code been test compiled without SMP and/or PM?
+static inline void omap4_cpu_resume(void)
+{}
+#endif
+
#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP4_COMMON_H */
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
...
+/**
+ * omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
+ * The purpose of this function is to manage low power programming
+ * of OMAP4 MPUSS subsystem
+ * @cpu : CPU ID
+ * @power_state: Low power state.
+ */
+int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
+{
+ unsigned int save_state = 0;
+ unsigned int wakeup_cpu;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ return -ENXIO;
+
+ switch (power_state) {
+ case PWRDM_POWER_ON:
+ case PWRDM_POWER_INACTIVE:
+ save_state = 0;
+ break;
+ case PWRDM_POWER_OFF:
+ save_state = 1;
+ break;
+ case PWRDM_POWER_RET:
+ default:
+ /*
+* CPUx CSWR
[PATCH v3] ASoC: omap: convert per-board modules to platform drivers
This converts the per-board modules to platform drivers for a
device created by in main platform setup. These drivers call
snd_soc_register_card() directly instead of going via a soc-audio
device and the corresponding driver in soc-core.
Signed-off-by: Mans Rullgard mans.rullg...@linaro.org
---
This version uses a table to assign the device name in omap_init_audio().
It is certainly less ugly than the previous patch.
Again, tested only on Beagle.
---
arch/arm/mach-omap2/devices.c | 34 +++
sound/soc/omap/am3517evm.c| 55 +++---
sound/soc/omap/igep0020.c | 52 +++--
sound/soc/omap/n810.c | 73 ++---
sound/soc/omap/omap3beagle.c | 55 +++---
sound/soc/omap/omap3evm.c | 56 ---
sound/soc/omap/omap3pandora.c | 70 ---
sound/soc/omap/overo.c| 56 +++
sound/soc/omap/rx51.c | 55 +--
sound/soc/omap/sdp3430.c | 65 ++--
sound/soc/omap/sdp4430.c | 60 +
sound/soc/omap/zoom2.c| 68 +-
12 files changed, 458 insertions(+), 241 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5b8ca68..cfec01b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -299,6 +299,10 @@ static struct platform_device omap_pcm = {
.id = -1,
};
+static struct platform_device omap_soc_audio = {
+ .id = -1,
+};
+
/*
* OMAP2420 has 2 McBSP ports
* OMAP2430 has 5 McBSP ports
@@ -311,8 +315,30 @@ OMAP_MCBSP_PLATFORM_DEVICE(3);
OMAP_MCBSP_PLATFORM_DEVICE(4);
OMAP_MCBSP_PLATFORM_DEVICE(5);
+static struct {
+ int machine;
+ const char *name;
+} soc_device_names[] = {
+ { MACH_TYPE_OMAP3517EVM,am3517evm-soc-audio },
+ { MACH_TYPE_IGEP0020, igep2-soc-audio },
+ { MACH_TYPE_NOKIA_N810, n8x1-soc-audio},
+ { MACH_TYPE_NOKIA_N810_WIMAX, n8x1-soc-audio},
+ { MACH_TYPE_OMAP3_BEAGLE, omap3beagle-soc-audio },
+ { MACH_TYPE_DEVKIT8000, omap3beagle-soc-audio },
+ { MACH_TYPE_OMAP3EVM, omap3evm-soc-audio},
+ { MACH_TYPE_OMAP3_PANDORA, pandora-soc-audio },
+ { MACH_TYPE_OVERO, overo-soc-audio, },
+ { MACH_TYPE_CM_T35, overo-soc-audio, },
+ { MACH_TYPE_NOKIA_RX51, rx51-soc-audio, },
+ { MACH_TYPE_OMAP_3430SDP, sdp3430-soc-audio,},
+ { MACH_TYPE_OMAP_4430SDP, sdp4430-soc-audio,},
+ { MACH_TYPE_OMAP_ZOOM2, zoom2-soc-audio, },
+};
+
static void omap_init_audio(void)
{
+ int i;
+
platform_device_register(omap_mcbsp1);
platform_device_register(omap_mcbsp2);
if (cpu_is_omap243x() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
@@ -323,6 +349,14 @@ static void omap_init_audio(void)
platform_device_register(omap_mcbsp5);
platform_device_register(omap_pcm);
+
+ for (i = 0; i ARRAY_SIZE(soc_device_names); i++) {
+ if (machine_arch_type == soc_device_names[i].machine) {
+ omap_soc_audio.name = soc_device_names[i].name;
+ platform_device_register(omap_soc_audio);
+ break;
+ }
+ }
}
#else
diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c
index 73dde4a..75c8766 100644
--- a/sound/soc/omap/am3517evm.c
+++ b/sound/soc/omap/am3517evm.c
@@ -151,45 +151,60 @@ static struct snd_soc_card snd_soc_am3517evm = {
.num_links = 1,
};
-static struct platform_device *am3517evm_snd_device;
-
-static int __init am3517evm_soc_init(void)
+static int __devinit am3517evm_soc_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = snd_soc_am3517evm;
int ret;
- if (!machine_is_omap3517evm())
- return -ENODEV;
pr_info(OMAP3517 / AM3517 EVM SoC init\n);
- am3517evm_snd_device = platform_device_alloc(soc-audio, -1);
- if (!am3517evm_snd_device) {
- printk(KERN_ERR Platform device allocation failed\n);
- return -ENOMEM;
+ card-dev = pdev-dev;
+
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(pdev-dev, snd_soc_register_card() failed: %d\n,
+ ret);
+ return ret;
}
- platform_set_drvdata(am3517evm_snd_device, snd_soc_am3517evm);
+ return 0;
+}
- ret = platform_device_add(am3517evm_snd_device);
- if (ret)
- goto err1;
+static int __devexit am3517evm_soc_remove(struct platform_device *pdev)
+{
+ struct
Re: [PATCH v6 17/25] gpio/omap: use pm-runtime framework
[...]
+static const struct dev_pm_ops gpio_pm_ops = {
+ .suspend = omap_gpio_suspend,
+ .resume = omap_gpio_resume,
+};
Please use SET_SYSTEM_SLEEP_PM_OPS(). See linux/pm.h
We can use following macro to initialize .suspend and .resume callbacks.
But how do we initialize .runtime_suspend and .runtime_resume callbacks?
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
}
Do we have something similar to following where we can assign separate
pair of callbacks?
The following macro on the other hand assigns the same set of
callbacks to both and this not what I want!!!
#define UNIVERSAL_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
}
--
Tarun
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
.driver = {
.name = omap_gpio,
+ .pm = gpio_pm_ops,
},
};
[...]
--
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
Regression seen when HIGHMEM enabled with NFS on 3.1rc4 kernel
Hi,
A kernel crash is observed on 3.1rc4 kernel when HIGHMEM is enabled and
kernel is booted with a NFS on omap4430sdp. The issue happens in the
below
scenario.
In file net/sunrpc/xprtsock.c,
static int xs_send_pagedata( xxx, struct xdr_buf *xdr, ..)
{
Struct page **ppage;
.
ppage = xdr-pages + (base PAGE_SHIFT);
err = sock-ops-sendpage(sock, *ppage, base, len, flags);
...
}
1) In the above piece of code, the *ppage value from
ops-sendpage function is finally passed on to Kmap by the lower
level code to get the virtual address of the page.
2) In some corner cases the value of *ppage pointer is NULL.
3) When highmem is enabled and a NULL pointer is passed to
Kmap, then kmap finally crashes. But in the case when highmem
is disabled, then kmap returns a junk value for NULL pointer.
Highmem Enabled , kmap( NULL )- kernel crashes.
Highmem disabled, kmap( NULL )- junk value is
returned.
Subsequently this message
is observed on
the console.
RPC call returned error 14
4) Now the question is why is the value of *ppage = NULL is
passed
from the above piece of code to lower layers.
Should that not have handled *ppage = NULL? and kmap should not
have received a NULL pointer?
Thanks,
Sricharan
--
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 v6 17/25] gpio/omap: use pm-runtime framework
On Fri, Sep 9, 2011 at 6:02 PM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
[...]
+static const struct dev_pm_ops gpio_pm_ops = {
+ .suspend = omap_gpio_suspend,
+ .resume = omap_gpio_resume,
+};
Please use SET_SYSTEM_SLEEP_PM_OPS(). See linux/pm.h
We can use following macro to initialize .suspend and .resume callbacks.
But how do we initialize .runtime_suspend and .runtime_resume callbacks?
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
}
Do we have something similar to following where we can assign separate
pair of callbacks?
The following macro on the other hand assigns the same set of
callbacks to both and this not what I want!!!
#define UNIVERSAL_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
}
Ok, I saw an example... Thanks!!
--
Tarun
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
.driver = {
.name = omap_gpio,
+ .pm = gpio_pm_ops,
},
};
[...]
--
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 12/25] OMAP: Add support to allocate the memory for secure RAM
Santosh, On Fri, Sep 9, 2011 at 11:43 AM, Santosh santosh.shilim...@ti.com wrote: On Friday 09 September 2011 12:49 AM, Jean Pihet wrote: On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Allocate the memory to save secure ram context which needs to be done when MPU is hitting off mode. The ROM code expects a physical address to this memory and hence use memblock APIs to reserve this memory as part of .reserve() callback. Maximum possible size is allocated and can cater to OMAP3XXX / OMAP4XXX secure RAM size requirements. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com --- arch/arm/mach-omap2/include/mach/omap-secure.h | 4 +++ arch/arm/mach-omap2/omap-secure.c | 29 arch/arm/plat-omap/common.c | 3 ++ 3 files changed, 36 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h b/arch/arm/mach-omap2/include/mach/omap-secure.h index 26e7bcc..e2f95a0 100644 --- a/arch/arm/mach-omap2/include/mach/omap-secure.h +++ b/arch/arm/mach-omap2/include/mach/omap-secure.h @@ -26,6 +26,8 @@ #define FLAG_FIQ_ENABLE 0x1 #define NO_FLAG 0x0 +/* Maximum Secure memory storage size */ +#define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K) Is this valid for all supported devices? How to differentiate variations in the size for new chips variants in the future? You don't have to. ROM code does that job. We should just ensure that maximum needed memory is made available to secure code. The question was: what would be the code if tomorrow -for example- we have OMAP4460 with 88K of secure RAM, OMAP5432 with 128K and OMAP6667 with 132K? How to code the differences? Regards, Jean 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: [RFC PATCH 06/10] hwspinlock: OMAP4: Add spinlock support in DT
On Thursday 08 September 2011, Ohad Ben-Cohen wrote: On Thu, Sep 8, 2011 at 5:47 PM, Arnd Bergmann a...@arndb.de wrote: I think a number would work here but is not optimal for the device tree representation. I think a better binding would be to encode it like interrupt numbers, where every device that uses a hwspinlock will describe that as a combination of phandle to the hwspinlock controller and identifier to be used by that controller I'm not sure. This implies that devices are hardwired to the specific controller+identifier, which is true for interrupts, but not for hwspinlocks. As a result the hardware depicted by such representation would be imprecise and might unnecessarily limit the software. hwspinlock devices are really just a pool of locks, which are not inherently bound to any device: any master that can initiate read/write bus access can use any of the locks (hardware-wise). One just needs to make sure that ownership of the locks, even if determined dynamically at runtime, is managed correctly. ok I think the phandle+identifier approach is very elegant to achieve static allocation of the hwspinlocks, and some boards will definitely need it (e.g. those unlucky designs which arbiter i2c access using an hwspinlock). But wouldn't that limit us from providing dynamic allocation of hwspinlocks ? I was told about teams working on complex multimedia use cases which involves numerous object sharing and require actually more hwspinlocks than exist (so they're planning on multiplexing several logical locks on a single hwspinlock). They use dynamic allocation of hwspinlocks in order to allow different hwspinlocks users to co-exist (but naturally not run together at the same time). Good point. I guess we will need both static and dynamic allocation then. You need the static allocation for cases where the other user of the spinlock is not under the control of Linux, but is known at boot time. For dynamic allocation, my impression is that we don't need any link from the spinlock user device to the controller at all, but instead the controller should have a list of the available spinlocks. In a case where you have three operating systems running independently on the same hardware and each of the shares one spinlock with the other two, you want to be able to model in the device tree which spinlocks are already known to the other instances and therefore fixed, which ones are available to the local OS and which ones are not available. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Regression seen when HIGHMEM enabled with NFS on 3.1rc4 kernel
Sorry resending again. My mailer settings thrashed my earlier email.
Hi,
A kernel crash is observed on 3.1rc4 kernel when HIGHMEM is enabled and
kernel is booted with a NFS on omap4430sdp. The issue happens in the below
scenario.
In file net/sunrpc/xprtsock.c,
static int xs_send_pagedata( xxx, struct xdr_buf *xdr, ..)
{
Struct page **ppage;
.
ppage = xdr-pages + (base PAGE_SHIFT);
err = sock-ops-sendpage(sock, *ppage, base, len, flags);
...
}
1) In the above piece of code, the *ppage value from ops-sendpage
function is finally passed on to Kmap by the lower level code to
get the virtual address of the page.
2) In some corner cases the value of *ppage pointer is NULL.
3) When highmem is enabled and a NULL pointer is passed to
Kmap, then kmap finally crashes. But in the case when highmem
is disabled, then kmap returns a junk value for NULL pointer.
Highmem Enabled , kmap( NULL )- kernel crashes.
Highmem disabled, kmap( NULL )- junk value is returned.
Subsequently this message is observed on
the console.
RPC call returned error 14
4) Now the question is why is the value of *ppage = NULL is passed
from the above piece of code to lower layers.
Should that not have handled *ppage = NULL? and kmap should not
have received a NULL pointer?
Thanks,
Sricharan
--
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/6 v3] usb: musb: Adding support for ti81xx
This patch set adds support for musb interface for TI81XX platforms and are dependent on recent patch series from Hemant Pedanekar at [1] and [2]. TI81XX platform has dual musb instances, uses CPPI4.1 DMA and has built in usb PHY. The current set of patches supports only the first interface and in PIO mode. [1] http://marc.info/?l=linux-omapm=131247989220300w=2 [2] http://marc.info/?l=linux-omapm=131411961308438w=2 Changes from v2: - Fixed a typo in patch 3/6 - Used kmemdup for wrapper structure pointer in patch 6/6 Ajay Kumar Gupta (1): omap: musb: ti81xx: Add phy power function Ravi Babu (5): omap: musb: Adding hwmod data for ti81xx omap: musb: Adding support for ti81xx ti816evm: Add support for musb interface ti814evm: Add support for musb interface usb: musb: Add support for ti81xx platform arch/arm/mach-omap2/board-ti8148evm.c |9 + arch/arm/mach-omap2/board-ti8168evm.c |9 + arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 74 +++ arch/arm/mach-omap2/omap_phy_internal.c| 24 + arch/arm/mach-omap2/usb-musb.c |3 + arch/arm/plat-omap/include/plat/usb.h | 32 ++ drivers/usb/musb/Kconfig |6 + drivers/usb/musb/Makefile |1 + drivers/usb/musb/musb_core.c |4 +- drivers/usb/musb/musb_dsps.c | 693 10 files changed, 854 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/musb_dsps.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6 v3] omap: musb: ti81xx: Add phy power function
Adding ti81xx_musb_phy_power() which will be used by musb driver through
its function pointer in board_data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 24 +++
arch/arm/plat-omap/include/plat/usb.h | 32 +++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 58775e3..d5e8497 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -260,3 +260,27 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
+
+void ti81xx_musb_phy_power(u8 on)
+{
+ u32 usbphycfg = omap_ctrl_readl(USBCTRL0);
+
+ if (on) {
+ if (cpu_is_ti816x()) {
+ usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
+ usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
+ } else if (cpu_is_ti814x()) {
+ usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
+ | USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
+ | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
+ }
+ } else {
+ if (cpu_is_ti816x())
+ usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
+ else if (cpu_is_ti814x())
+ usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
+
+ }
+ omap_ctrl_writel(usbphycfg, USBCTRL0);
+}
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..c616385 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -114,6 +114,7 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
+extern void ti81xx_musb_phy_power(u8 on);
/*
* FIXME correct answer depends on hmc_mode,
@@ -273,6 +274,37 @@ static inline void omap2_usbfs_init(struct omap_usb_config
*pdata)
#define CONF2_OTGPWRDN (1 2)
#define CONF2_DATPOL (1 1)
+/* TI81XX specific definitions */
+#define USBCTRL0 0x620
+#define USBSTAT0 0x624
+
+/* TI816X PHY controls bits */
+#define TI816X_USBPHY0_NORMAL_MODE (1 0)
+#define TI816X_USBPHY_REFCLK_OSC (1 8)
+
+/* TI814X PHY controls bits */
+#define USBPHY_CM_PWRDN(1 0)
+#define USBPHY_OTG_PWRDN (1 1)
+#define USBPHY_CHGDET_DIS (1 2)
+#define USBPHY_CHGDET_RSTRT(1 3)
+#define USBPHY_SRCONDM (1 4)
+#define USBPHY_SINKONDP(1 5)
+#define USBPHY_CHGISINK_EN (1 6)
+#define USBPHY_CHGVSRC_EN (1 7)
+#define USBPHY_DMPULLUP(1 8)
+#define USBPHY_DPPULLUP(1 9)
+#define USBPHY_CDET_EXTCTL (1 10)
+#define USBPHY_GPIO_MODE (1 12)
+#define USBPHY_DPOPBUFCTL (1 13)
+#define USBPHY_DMOPBUFCTL (1 14)
+#define USBPHY_DPINPUT (1 15)
+#define USBPHY_DMINPUT (1 16)
+#define USBPHY_DPGPIO_PD (1 17)
+#define USBPHY_DMGPIO_PD (1 18)
+#define USBPHY_OTGVDET_EN (1 19)
+#define USBPHY_OTGSESSEND_EN (1 20)
+#define USBPHY_DATA_POLARITY (1 23)
+
#if defined(CONFIG_ARCH_OMAP1) defined(CONFIG_USB)
u32 omap1_usb0_init(unsigned nwires, unsigned is_device);
u32 omap1_usb1_init(unsigned nwires);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6 v3] ti814evm: Add support for musb interface
From: Ravi Babu ravib...@ti.com
Adding musb support in ti814 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/board-ti8148evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8148evm.c
b/arch/arm/mach-omap2/board-ti8148evm.c
index 588d6b7..7dbf115 100644
--- a/arch/arm/mach-omap2/board-ti8148evm.c
+++ b/arch/arm/mach-omap2/board-ti8148evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8148_evm_config[] __initdata = {
};
@@ -38,6 +46,7 @@ static void __init ti8148_evm_init(void)
omap_serial_init();
omap_board_config = ti8148_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8148_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8148_evm_map_io(void)
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx
From: Ravi Babu ravib...@ti.com
The usb subsystem (usbss) in ti81xx has two musb interfaces. There are three
irqs and three address spaces for usbss, musb0 and musb1 respectively. Created
one hwmod with three irq and memory resources.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Acked-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 74
1 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index e73a4c6..e960d70 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -194,6 +194,7 @@ static struct omap_hwmod ti81xx_timer4_hwmod;
static struct omap_hwmod ti81xx_timer5_hwmod;
static struct omap_hwmod ti81xx_timer6_hwmod;
static struct omap_hwmod ti81xx_timer7_hwmod;
+static struct omap_hwmod ti81xx_usbss_hwmod;
/* L4 SLOW - TIMER1 interface */
static struct omap_hwmod_addr_space ti81xx_timer1_addr_space[] = {
@@ -650,6 +651,78 @@ static struct omap_hwmod ti81xx_timer7_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_TI816X | CHIP_IS_TI814X)
};
+/* L3 SLOW - USBSS interface */
+static struct omap_hwmod_addr_space ti81xx_usbss_addr_space[] = {
+ {
+ .name = usbss,
+ .pa_start = 0x4740,
+ .pa_end = 0x4740 + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = musb0,
+ .pa_start = 0x47401000,
+ .pa_end = 0x47401000 + SZ_2K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = musb1,
+ .pa_start = 0x47401800,
+ .pa_end = 0x47401800 + SZ_2K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ },
+};
+
+static struct omap_hwmod_class_sysconfig ti81xx_usbhsotg_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x10,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class ti81xx_usbotg_class = {
+ .name = usbotg,
+ .sysc = ti81xx_usbhsotg_sysc,
+};
+
+static struct omap_hwmod_irq_info ti81xx_usbss_mpu_irqs[] = {
+ { .name = usbss-irq, .irq = 17, },
+ { .name = musb0-irq, .irq = 18, },
+ { .name = musb1-irq, .irq = 19, },
+ { .irq = -1, },
+};
+
+static struct omap_hwmod_ocp_if ti81xx_l3_slow__usbss = {
+ .master = ti81xx_l3_slow_hwmod,
+ .slave = ti81xx_usbss_hwmod,
+ .clk= usbotg_ick,
+ .addr = ti81xx_usbss_addr_space,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *ti81xx_usbss_slaves[] = {
+ ti81xx_l3_slow__usbss,
+};
+
+static struct omap_hwmod ti81xx_usbss_hwmod = {
+ .name = usb_otg_hs,
+ .mpu_irqs = ti81xx_usbss_mpu_irqs,
+ .main_clk = usbotg_ick,
+ .clkdm_name = default_usb_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = TI816X_CM_DEFAULT_USB_CLKCTRL_OFFSET,
+ },
+ },
+ .slaves = ti81xx_usbss_slaves,
+ .slaves_cnt = ARRAY_SIZE(ti81xx_usbss_slaves),
+ .class = ti81xx_usbotg_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_TI816X | CHIP_IS_TI814X)
+};
static __initdata struct omap_hwmod *ti81xx_hwmods[] = {
ti81xx_l3_fast_hwmod,
@@ -668,6 +741,7 @@ static __initdata struct omap_hwmod *ti81xx_hwmods[] = {
ti81xx_timer5_hwmod,
ti81xx_timer6_hwmod,
ti81xx_timer7_hwmod,
+ ti81xx_usbss_hwmod,
NULL,
};
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6 v3] ti816evm: Add support for musb interface
From: Ravi Babu ravib...@ti.com
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/board-ti8168evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index e516a04..5a4a6c8 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
};
@@ -38,6 +46,7 @@ static void __init ti8168_evm_init(void)
omap_serial_init();
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8168_evm_map_io(void)
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6 v3] usb: musb: Add support for ti81xx platform
From: Ravi Babu ravib...@ti.com TI81XX platform has two musb interfaces and uses CPPI4.1 DMA engine. It has builtin USB PHYs as AM35x. The current set of patches adds support for one instance and only in PIO mode. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com --- drivers/usb/musb/Kconfig |6 + drivers/usb/musb/Makefile|1 + drivers/usb/musb/musb_core.c |4 +- drivers/usb/musb/musb_dsps.c | 693 ++ 4 files changed, 703 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/musb_dsps.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 6192b45..444d106 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on USB USB_GADGET depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if SOC_OMAPTI81XX select TWL4030_USB if MACH_OMAP_3430SDP select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA select USB_OTG_UTILS @@ -57,6 +58,10 @@ config USB_MUSB_AM35X tristate AM35x depends on ARCH_OMAP +config USB_MUSB_DSPS + tristate TI DSPS platforms + depends on SOC_OMAPTI81XX + config USB_MUSB_BLACKFIN tristate Blackfin depends on (BF54x !BF544) || (BF52x ! BF522 !BF523) @@ -71,6 +76,7 @@ config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X + default SOC_OMAPTI81XX help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index d8fd9d0..d92d110 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -13,6 +13,7 @@ musb_hdrc-$(CONFIG_DEBUG_FS) += musb_debugfs.o # Hardware Glue Layer obj-$(CONFIG_USB_MUSB_OMAP2PLUS) += omap2430.o obj-$(CONFIG_USB_MUSB_AM35X) += am35x.o +obj-$(CONFIG_USB_MUSB_DSPS)+= musb_dsps.o obj-$(CONFIG_USB_MUSB_TUSB6010)+= tusb6010.o obj-$(CONFIG_USB_MUSB_DAVINCI) += davinci.o obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 20a2873..b04790d 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1014,7 +1014,9 @@ static void musb_shutdown(struct platform_device *pdev) || defined(CONFIG_USB_MUSB_OMAP2PLUS) \ || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\ || defined(CONFIG_USB_MUSB_AM35X) \ - || defined(CONFIG_USB_MUSB_AM35X_MODULE) + || defined(CONFIG_USB_MUSB_AM35X_MODULE)\ + || defined(CONFIG_USB_MUSB_DSPS)\ + || defined(CONFIG_USB_MUSB_DSPS_MODULE) static ushort __initdata fifo_mode = 4; #elif defined(CONFIG_USB_MUSB_UX500) \ || defined(CONFIG_USB_MUSB_UX500_MODULE) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c new file mode 100644 index 000..fb59e34 --- /dev/null +++ b/drivers/usb/musb/musb_dsps.c @@ -0,0 +1,693 @@ +/* + * Texas Instruments DSPS platforms glue layer + * + * Copyright (C) 2011, by Texas Instruments + * + * Based on the am35x glue layer code. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux is free software; you + * can redistribute it and/or modify it under the terms of the GNU + * General Public License version 2 as published by the Free Software + * Foundation. + * + * The Inventra Controller Driver for Linux 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 The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + * musb_dsps.c will be a common file for all the TI DSPS platforms + * such as dm64x, dm36x, dm35x, da8x, am35x and ti81x. + * For now only ti81x is using this and in future davinci.c, am35x.c + * da8xx.c would be merged to this file after testing. + */ + +#include linux/init.h +#include linux/io.h +#include linux/platform_device.h +#include linux/dma-mapping.h +#include linux/pm_runtime.h + +#include plat/usb.h + +#include musb_core.h + +/** + * avoid using musb_readx()/musb_writex() as glue layer should not be + * dependent on musb core layer symbols. + */ +static inline u8
[PATCH 2/6 v3] omap: musb: Adding support for ti81xx
From: Ravi Babu ravib...@ti.com
Added musb support for ti81xx platform which has two instances of musb
interface and uses CPPI4.1 DMA. The current patch set adds support for
single instance and in PIO mode only.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index a65145b..8bceeca 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -143,6 +143,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
if (cpu_is_omap3517() || cpu_is_omap3505()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
+ } else if (cpu_is_ti81xx()) {
+ oh_name = usb_otg_hs;
+ name = musb-ti81xx;
} else {
oh_name = usb_otg_hs;
name = musb-omap2430;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1
On Fri, Aug 12, 2011 at 8:43 PM, Buckley, Bryan bryan.buck...@ti.com wrote: On Fri, Jul 22, 2011 at 7:30 AM, Kishore Kadiyala kishorek.kadiy...@gmail.com wrote: On Fri, Jul 22, 2011 at 12:59 AM, Bryan Buckley bryan.buck...@ti.com wrote: Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance with the control module programming guide. This fixes a bug where if trying to use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be affected by a changing SDMMC1_VDDS. Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever SDMMC1_VDDS ramps up/down or changes for cell protection purposes. MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore they can operate independently. Signed-off-by: Bryan Buckley bryan.buck...@ti.com Good catch, Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com Any other comments from anyone else? Noticed that this commit isn't in any upstream branches. This patch will fix issues with people who want to use GPIO 98/99 AND MMC1 at the same time. Would be good to have this fix upstream. FWIW: Tested on OMAP4 Blaze Tested-by: Balaji T K balaj...@ti.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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote: This patch adds the CPU0 and CPU1 off mode support. CPUX close switch retention (CSWR) is not supported by hardware design. The CPUx OFF mode isn't supported on OMAP4430 ES1.0 CPUx sleep code is common for hotplug, suspend and CPUilde. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Kevin Hilmankhil...@ti.com --- arch/arm/mach-omap2/Makefile|3 +- arch/arm/mach-omap2/include/mach/omap-secure.h |8 + arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++ arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++ arch/arm/mach-omap2/omap-smp.c |6 + arch/arm/mach-omap2/omap4-sar-layout.h |9 + arch/arm/mach-omap2/pm44xx.c|6 + arch/arm/mach-omap2/sleep44xx.S | 213 +++ 8 files changed, 518 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c [...] diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 049f426..230ab8c 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -11,8 +11,221 @@ #includelinux/linkage.h #includeasm/system.h +#includeasm/smp_scu.h +#includeasm/memory.h +#includeasm/hardware/cache-l2x0.h +#includeplat/omap44xx.h #includemach/omap4-common.h +#includemach/omap-secure.h + +#include omap4-sar-layout.h + +#ifdef CONFIG_SMP + +.macro DO_SMC + dsb + smc #0 + dsb +.endm + +ppa_zero_params: + .word 0x0 + +/* + * = + * == CPU suspend finisher == + * = + * + * void omap4_finish_suspend(unsigned long cpu_state) + * + * This function code saves the CPU context and performs the CPU + * power down sequence. Calling WFI effectively changes the CPU + * power domains states to the desired target power state. + * + * @cpu_state : contains context save state (r0) + * 0 - No context lost + * 1 - CPUx L1 and logic lost: MPUSS CSWR + * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR + * 3 - CPUx L1 and logic lost + GIC + L2 lost: MPUSS OFF I was told by rmk that same as imx6q, omap44xx will retain L2 content across suspen/resume cycle. Then what does L2 lost mean here? Or what rmk meant is the case cpu_state == 2? Yes. The last case is entire SOC OFF. We call Device OFF in OMAP. All voltages will scale to 0 V. This isn't supported by this series. Then the second question would be what the following patch in this series is for. [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support I could have read the patch incorrectly, but it seems l2x_clean_inv will also be called for MPUSS OSWR in which case L2 is retained? Shouldn't L2 for this case have been handled by rmk's patch (ARM: pm: add L2 cache cleaning for suspend)? -- Regards, Shawn -- 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 12/25] OMAP: Add support to allocate the memory for secure RAM
On Fri, Sep 9, 2011 at 6:24 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Santosh, On Fri, Sep 9, 2011 at 11:43 AM, Santosh santosh.shilim...@ti.com wrote: On Friday 09 September 2011 12:49 AM, Jean Pihet wrote: On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Allocate the memory to save secure ram context which needs to be done when MPU is hitting off mode. The ROM code expects a physical address to this memory and hence use memblock APIs to reserve this memory as part of .reserve() callback. Maximum possible size is allocated and can cater to OMAP3XXX / OMAP4XXX secure RAM size requirements. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com --- arch/arm/mach-omap2/include/mach/omap-secure.h | 4 +++ arch/arm/mach-omap2/omap-secure.c | 29 arch/arm/plat-omap/common.c | 3 ++ 3 files changed, 36 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h b/arch/arm/mach-omap2/include/mach/omap-secure.h index 26e7bcc..e2f95a0 100644 --- a/arch/arm/mach-omap2/include/mach/omap-secure.h +++ b/arch/arm/mach-omap2/include/mach/omap-secure.h @@ -26,6 +26,8 @@ #define FLAG_FIQ_ENABLE 0x1 #define NO_FLAG 0x0 +/* Maximum Secure memory storage size */ +#define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K) Is this valid for all supported devices? How to differentiate variations in the size for new chips variants in the future? You don't have to. ROM code does that job. We should just ensure that maximum needed memory is made available to secure code. The question was: what would be the code if tomorrow -for example- we have OMAP4460 with 88K of secure RAM, OMAP5432 with 128K and OMAP6667 with 132K? How to code the differences? The size doesn't depend on silicon but depends on Secure software stack size. As I said, we will allocate maximum needed as per security team recommendation. If on newer security stack, if we need more, we will just increase it to maximum needed. -- 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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo shawn@freescale.com wrote: On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote: This patch adds the CPU0 and CPU1 off mode support. CPUX close switch retention (CSWR) is not supported by hardware design. The CPUx OFF mode isn't supported on OMAP4430 ES1.0 CPUx sleep code is common for hotplug, suspend and CPUilde. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Kevin Hilmankhil...@ti.com --- arch/arm/mach-omap2/Makefile | 3 +- arch/arm/mach-omap2/include/mach/omap-secure.h | 8 + arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++ arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++ arch/arm/mach-omap2/omap-smp.c | 6 + arch/arm/mach-omap2/omap4-sar-layout.h | 9 + arch/arm/mach-omap2/pm44xx.c | 6 + arch/arm/mach-omap2/sleep44xx.S | 213 +++ 8 files changed, 518 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c [...] diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 049f426..230ab8c 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -11,8 +11,221 @@ #includelinux/linkage.h #includeasm/system.h +#includeasm/smp_scu.h +#includeasm/memory.h +#includeasm/hardware/cache-l2x0.h +#includeplat/omap44xx.h #includemach/omap4-common.h +#includemach/omap-secure.h + +#include omap4-sar-layout.h + +#ifdef CONFIG_SMP + +.macro DO_SMC + dsb + smc #0 + dsb +.endm + +ppa_zero_params: + .word 0x0 + +/* + * = + * == CPU suspend finisher == + * = + * + * void omap4_finish_suspend(unsigned long cpu_state) + * + * This function code saves the CPU context and performs the CPU + * power down sequence. Calling WFI effectively changes the CPU + * power domains states to the desired target power state. + * + * @cpu_state : contains context save state (r0) + * 0 - No context lost + * 1 - CPUx L1 and logic lost: MPUSS CSWR + * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR + * 3 - CPUx L1 and logic lost + GIC + L2 lost: MPUSS OFF I was told by rmk that same as imx6q, omap44xx will retain L2 content across suspen/resume cycle. Then what does L2 lost mean here? Or what rmk meant is the case cpu_state == 2? Yes. The last case is entire SOC OFF. We call Device OFF in OMAP. All voltages will scale to 0 V. This isn't supported by this series. Then the second question would be what the following patch in this series is for. [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support I could have read the patch incorrectly, but it seems l2x_clean_inv will also be called for MPUSS OSWR in which case L2 is retained? Shouldn't L2 for this case have been handled by rmk's patch (ARM: pm: add L2 cache cleaning for suspend)? Yes you did read it wrongly :) It won't be called for OSWR -- 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/2] arm: omap: usb: enable I/O wakeups of ehci and ohci hwmods of omap4
From: Kishon Vijay Abraham kis...@ti.com
For ehci and ohci hwmods, the omap4 I/O wakeup capablity is enabled.
for ehci in phy mode,
- the DAT0 and DIR I/O pad is set as wakeup capable
for ohci in serial mode
- usbb*_mm_rxdp is set as I/O wakeup for 6 pin serial mode
- usbb*_mm_rxrcv is set as I/O wakeup for 4 pin serial mode
- usbb*_mm_txen is set as I/O wakeup for 3 pin serial mode
- usbb*_mm_txdat is set as I/O wakeup for 2 pin serial mode
Signed-off-by: Kishon Vijay Abraham kis...@ti.com
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 76 +--
1 files changed, 64 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 485341f..cf2e726 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -64,7 +64,12 @@ static struct omap_device_pad port1_phy_pads[] __initdata = {
},
{
.name = usbb1_ulpitll_dir.usbb1_ulpiphy_dir,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4 |
+ OMAP_WAKEUP_EN,
+
},
{
.name = usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt,
@@ -72,7 +77,12 @@ static struct omap_device_pad port1_phy_pads[] __initdata = {
},
{
.name = usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4 |
+ OMAP_WAKEUP_EN,
+
},
{
.name = usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1,
@@ -166,7 +176,11 @@ static struct omap_device_pad port2_phy_pads[] __initdata
= {
},
{
.name = usbb2_ulpitll_dir.usbb2_ulpiphy_dir,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4 |
+ OMAP_WAKEUP_EN,
},
{
.name = usbb2_ulpitll_nxt.usbb2_ulpiphy_nxt,
@@ -174,7 +188,12 @@ static struct omap_device_pad port2_phy_pads[] __initdata
= {
},
{
.name = usbb2_ulpitll_dat0.usbb2_ulpiphy_dat0,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4 |
+ OMAP_WAKEUP_EN,
+
},
{
.name = usbb2_ulpitll_dat1.usbb2_ulpiphy_dat1,
@@ -260,7 +279,11 @@ static struct omap_device_pad port2_tll_pads[] __initdata
= {
static struct omap_device_pad port1_6pin_pads[] __initdata = {
{
.name = usbb1_ulpitll_stp.usbb1_mm_rxdp,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5 |
+ OMAP_WAKEUP_EN,
},
{
.name = usbb1_ulpitll_nxt.usbb1_mm_rxdm,
@@ -287,7 +310,11 @@ static struct omap_device_pad port1_6pin_pads[] __initdata
= {
static struct omap_device_pad port1_4pin_pads[] __initdata = {
{
.name = usbb1_ulpitll_dat0.usbb1_mm_rxrcv,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5 |
+ OMAP_WAKEUP_EN,
},
{
.name = usbb1_ulpitll_dat3.usbb1_mm_txen,
@@ -306,7 +333,12 @@ static struct
[PATCH 2/2] arm: omap: usb: enable I/O wakeups of ehci and ohci hwmods of omap3
From: Keshava Munegowda keshava_mgo...@ti.com
For ehci and ohci hwmods, the omap3 I/O wakeup capablity is enabled.
for ehci in phy mode,
- the DAT0 and DIR I/O pad is set as wakeup capable
for ohci in serial mode
- usbb*_mm_rxdp is set as I/O wakeup for 6 pin serial mode
- usbb*_mm_rxrcv is set as I/O wakeup for 4 pin serial mode
- usbb*_mm_txen is set as I/O wakeup for 3 pin serial mode
- usbb*_mm_txdat is set as I/O wakeup for 2 pin serial mode
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 96 +---
1 files changed, 80 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index cf2e726..d3cb100 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -467,7 +467,11 @@ static struct omap_device_pad omap3_port1_phy_pads[]
__initdata = {
},
{
.name = etk_d8.hsusb1_dir,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3 |
+ OMAP_WAKEUP_EN,
},
{
.name = etk_d9.hsusb1_nxt,
@@ -475,7 +479,11 @@ static struct omap_device_pad omap3_port1_phy_pads[]
__initdata = {
},
{
.name = etk_d0.hsusb1_data0,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3 |
+ OMAP_WAKEUP_EN,
},
{
.name = etk_d1.hsusb1_data1,
@@ -569,7 +577,11 @@ static struct omap_device_pad omap3_port2_phy_pads[]
__initdata = {
},
{
.name = etk_d12.hsusb2_dir,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3 |
+ OMAP_WAKEUP_EN,
},
{
.name = etk_d13.hsusb2_nxt,
@@ -577,7 +589,11 @@ static struct omap_device_pad omap3_port2_phy_pads[]
__initdata = {
},
{
.name = etk_d14.hsusb2_data0,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3 |
+ OMAP_WAKEUP_EN,
},
{
.name = etk_d15.hsusb2_data1,
@@ -714,7 +730,11 @@ static struct omap_device_pad omap3_port3_tll_pads[]
__initdata = {
static struct omap_device_pad omap3_port1_6pin_pads[] __initdata = {
{
.name = etk_clk.mm1_rxdp,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5 |
+ OMAP_WAKEUP_EN,
},
{
.name = etk_d9.mm1_rxdm,
@@ -741,7 +761,11 @@ static struct omap_device_pad omap3_port1_6pin_pads[]
__initdata = {
static struct omap_device_pad omap3_port1_4pin_pads[] __initdata = {
{
.name = etk_d0.mm1_rxrcv,
- .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5,
+ .enable = (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5)
+ ~OMAP_WAKEUP_EN,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE5 |
+ OMAP_WAKEUP_EN,
},
{
.name = etk_d7.mm1_txen_n,
@@ -760,7 +784,11 @@ static struct omap_device_pad omap3_port1_4pin_pads[]
__initdata = {
static struct omap_device_pad omap3_port1_3pin_pads[] __initdata = {
{
.name = etk_d7.mm1_txen_n,
- .enable =
[PATCH 0/2] arm: omap: usb: enable I/O wakeups of ehci and ohci hwmods
From: Keshava Munegowda keshava_mgo...@ti.com For ehci and ohci hwmods, the omap3 and omap4 I/O wakeup capablity is enabled. In case of system global suspend, The ehci/ohci device connection/disconnection and remote wakeup wakesup the system. This patch series is based on 1. I/O pads initialization to ehci and ohci hwmod 2. Runtime PM support of usbhs of omap3 and omap4 These patches are avilable at branch kmg-usbhs-pm code repository : git://gitorious.org/~kmg/mirrors/kmg-usbhs-pm.git 3. Kevin's pm branch Keshava Munegowda (1): arm: omap: usb: enable I/O wakeups of ehci and ohci hwmods of omap3 Kishon Vijay Abraham (1): arm: omap: usb: enable I/O wakeups of ehci and ohci hwmods of omap4 arch/arm/mach-omap2/usb-host.c | 172 +--- 1 files changed, 144 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote:
On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo shawn@freescale.com wrote:
On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
Hi Santosh,
On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote:
This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
retention (CSWR) is not supported by hardware design.
The CPUx OFF mode isn't supported on OMAP4430 ES1.0
CPUx sleep code is common for hotplug, suspend and CPUilde.
Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Kevin Hilmankhil...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +-
arch/arm/mach-omap2/include/mach/omap-secure.h | 8 +
arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249
+++
arch/arm/mach-omap2/omap-smp.c | 6 +
arch/arm/mach-omap2/omap4-sar-layout.h | 9 +
arch/arm/mach-omap2/pm44xx.c | 6 +
arch/arm/mach-omap2/sleep44xx.S | 213
+++
8 files changed, 518 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
[...]
diff --git a/arch/arm/mach-omap2/sleep44xx.S
b/arch/arm/mach-omap2/sleep44xx.S
index 049f426..230ab8c 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -11,8 +11,221 @@
#includelinux/linkage.h
#includeasm/system.h
+#includeasm/smp_scu.h
+#includeasm/memory.h
+#includeasm/hardware/cache-l2x0.h
+#includeplat/omap44xx.h
#includemach/omap4-common.h
+#includemach/omap-secure.h
+
+#include omap4-sar-layout.h
+
+#ifdef CONFIG_SMP
+
+.macro DO_SMC
+ dsb
+ smc #0
+ dsb
+.endm
+
+ppa_zero_params:
+ .word 0x0
+
+/*
+ * =
+ * == CPU suspend finisher ==
+ * =
+ *
+ * void omap4_finish_suspend(unsigned long cpu_state)
+ *
+ * This function code saves the CPU context and performs the CPU
+ * power down sequence. Calling WFI effectively changes the CPU
+ * power domains states to the desired target power state.
+ *
+ * @cpu_state : contains context save state (r0)
+ * 0 - No context lost
+ * 1 - CPUx L1 and logic lost: MPUSS CSWR
+ * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
+ * 3 - CPUx L1 and logic lost + GIC + L2 lost: MPUSS OFF
I was told by rmk that same as imx6q, omap44xx will retain L2 content
across suspen/resume cycle. Then what does L2 lost mean here? Or
what rmk meant is the case cpu_state == 2?
Yes.
The last case is entire SOC OFF. We call Device OFF in OMAP.
All voltages will scale to 0 V. This isn't supported by this
series.
Then the second question would be what the following patch in this
series is for.
[PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
I could have read the patch incorrectly, but it seems l2x_clean_inv
will also be called for MPUSS OSWR in which case L2 is retained?
Shouldn't L2 for this case have been handled by rmk's patch (ARM: pm:
add L2 cache cleaning for suspend)?
Yes you did read it wrongly :)
It won't be called for OSWR
Come on, man. It's really hard for me who is still at entry level of
assembly to understand that. So please help me out.
The following is a copy from arch/arm/mach-omap2/sleep44xx.S after I
apply this patch series on v3.1-rc4.
/*
* =
* == CPU suspend finisher ==
* =
*
* void omap4_finish_suspend(unsigned long cpu_state)
*
* This function code saves the CPU context and performs the CPU
* power down sequence. Calling WFI effectively changes the CPU
* power domains states to the desired target power state.
*
* @cpu_state : contains context save state (r0)
So cpu_state is passed in r0.
*0 - No context lost
*1 - CPUx L1 and logic lost: MPUSS CSWR
*2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
*3 - CPUx L1 and logic lost + GIC + L2 lost: MPUSS OFF
* @return: This function never returns for CPU OFF and DORMANT power states.
* Post WFI, CPU transitions to DORMANT or OFF power state and on wake-up
* from this follows a full CPU reset path via ROM code to CPU restore code.
* It returns to the caller for CPU INACTIVE and ON power states or in case
* CPU failed to transition to targeted OFF/DORMANT state.
*/
ENTRY(omap4_finish_suspend)
stmfd sp!, {lr}
cmp r0, #0x0
beq do_WFI @ No lowpower state, jump to WFI
The case 0 is handled here.
/*
* Flush all data from the L1 data cache before disabling
* SCTLR.C bit.
*/
bl
[PATCH 5/5] ARM: omap4: Kill private do_wfi macro.
The do_wfi macro duplicates the functionality of the wfi macro in common
ARM code. Use the common version instead.
Signed-off-by: Nick Bowler nbow...@elliptictech.com
---
Compile tested in both ARM and Thumb-2 mode.
---
arch/arm/mach-omap2/include/mach/omap4-common.h | 11 ---
arch/arm/mach-omap2/omap-hotplug.c |7 +++
arch/arm/mach-omap2/pm44xx.c|4 +++-
3 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index e4bd87619..9e8c214 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -13,17 +13,6 @@
#ifndef OMAP_ARCH_OMAP4_COMMON_H
#define OMAP_ARCH_OMAP4_COMMON_H
-/*
- * wfi used in low power code. Directly opcode is used instead
- * of instruction to avoid mulit-omap build break
- */
-#ifdef CONFIG_THUMB2_KERNEL
-#define do_wfi() __asm__ __volatile__ (wfi : : : memory)
-#else
-#define do_wfi() \
- __asm__ __volatile__ (.word0xe320f003 : : : memory)
-#endif
-
#ifdef CONFIG_CACHE_L2X0
extern void __iomem *l2cache_base;
#endif
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
index 4976b93..3a43eb8 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -19,6 +19,8 @@
#include linux/smp.h
#include asm/cacheflush.h
+#include asm/system.h
+
#include mach/omap4-common.h
int platform_cpu_kill(unsigned int cpu)
@@ -42,10 +44,7 @@ void platform_cpu_die(unsigned int cpu)
printk(KERN_CRIT Secure clear status failed\n);
for (;;) {
- /*
-* Execute WFI
-*/
- do_wfi();
+ wfi();
if (omap_read_auxcoreboot0() == cpu) {
/*
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 59a870b..c741ad7 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -16,6 +16,8 @@
#include linux/err.h
#include linux/slab.h
+#include asm/system.h
+
#include powerdomain.h
#include mach/omap4-common.h
@@ -33,7 +35,7 @@ static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
{
- do_wfi();
+ wfi();
return 0;
}
--
1.7.3.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 0/5] Convert ARM subarchitectures to generic wfi macro.
This series cleans up all remaining ARM subarchitectures that I could find to use the generic wfi macro. As I don't have any of the boards in question, I've only compile-tested these patches to the extent that I was able. See the previous discussion in https://lkml.org/lkml/2011/8/19/433 for more background. Nick Bowler (5): ARM: realview: Use wfi macro in platform_do_lowpower. ARM: exynos4: Use wfi macro in platform_do_lowpower. ARM: shmobile: Use wfi macro in platform_cpu_die. ARM: tegra: Use wfi macro in platform_do_lowpower. ARM: omap4: Kill private do_wfi macro. arch/arm/mach-exynos4/hotplug.c |9 ++--- arch/arm/mach-omap2/include/mach/omap4-common.h | 11 --- arch/arm/mach-omap2/omap-hotplug.c |7 +++ arch/arm/mach-omap2/pm44xx.c|4 +++- arch/arm/mach-realview/hotplug.c|9 ++--- arch/arm/mach-shmobile/hotplug.c| 10 +++--- arch/arm/mach-tegra/hotplug.c |9 ++--- 7 files changed, 15 insertions(+), 44 deletions(-) -- 1.7.3.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 0/5] Convert ARM subarchitectures to generic wfi macro.
And after all that, I forgot to CC Russell on these patches. Oops. On 2011-09-09 11:26 -0400, Nick Bowler wrote: This series cleans up all remaining ARM subarchitectures that I could find to use the generic wfi macro. As I don't have any of the boards in question, I've only compile-tested these patches to the extent that I was able. See the previous discussion in https://lkml.org/lkml/2011/8/19/433 for more background. Nick Bowler (5): ARM: realview: Use wfi macro in platform_do_lowpower. ARM: exynos4: Use wfi macro in platform_do_lowpower. ARM: shmobile: Use wfi macro in platform_cpu_die. ARM: tegra: Use wfi macro in platform_do_lowpower. ARM: omap4: Kill private do_wfi macro. arch/arm/mach-exynos4/hotplug.c |9 ++--- arch/arm/mach-omap2/include/mach/omap4-common.h | 11 --- arch/arm/mach-omap2/omap-hotplug.c |7 +++ arch/arm/mach-omap2/pm44xx.c|4 +++- arch/arm/mach-realview/hotplug.c|9 ++--- arch/arm/mach-shmobile/hotplug.c| 10 +++--- arch/arm/mach-tegra/hotplug.c |9 ++--- 7 files changed, 15 insertions(+), 44 deletions(-) -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.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
[PATCH v2 1/8] OMAP: hwmod: Fix the addr spaces, irq, dma count APIs.
The address spaces, irqs and dma reqs count API returns the
number of corresponding entries in a hwmod including a additional
null value or a -1 terminator in the structure introduced
recently. More information here:
212738a4 (omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs
arrays)
78183f3f (omap_hwmod: use a null structure record to terminate
omap_hwmod_addr_space arrays)
bc614958 (omap_hwmod: use a terminator record with omap_hwmod_dma_info
arrays)
The devices which have multiple hwmods and use device_build_ss are
broken with this, as their resources are populated with a
extra null value, subsequently the probe fails. So fix the API not to
include the array terminator in the count.
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
[v1]
Initial version.
[v2]
1) Added the correction for irq and dma counts along with
addr spaces.
2) Changed the commit log.
arch/arm/mach-omap2/omap_hwmod.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..c69fbc2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -745,9 +745,9 @@ static int _count_mpu_irqs(struct omap_hwmod *oh)
if (!oh || !oh-mpu_irqs)
return 0;
- do {
- ohii = oh-mpu_irqs[i++];
- } while (ohii-irq != -1);
+ ohii = oh-mpu_irqs[i];
+ while (ohii-irq != -1)
+ ohii = oh-mpu_irqs[++i];
return i;
}
@@ -768,9 +768,9 @@ static int _count_sdma_reqs(struct omap_hwmod *oh)
if (!oh || !oh-sdma_reqs)
return 0;
- do {
- ohdi = oh-sdma_reqs[i++];
- } while (ohdi-dma_req != -1);
+ ohdi = oh-sdma_reqs[i];
+ while (ohdi-dma_req != -1)
+ ohdi = oh-sdma_reqs[++i];
return i;
}
@@ -791,9 +791,9 @@ static int _count_ocp_if_addr_spaces(struct
omap_hwmod_ocp_if *os)
if (!os || !os-addr)
return 0;
- do {
- mem = os-addr[i++];
- } while (mem-pa_start != mem-pa_end);
+ mem = os-addr[i];
+ while (mem-pa_start != mem-pa_end)
+ mem = os-addr[++i];
return i;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers
On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote: On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote: The problem is that someone has to manually go and add the device to every board that needs one and people find that tedious and slightly inelegant Sheesh. So now you're arguing against your statement above? Please stop wasting my time. There's two things going on here - what we are doing and what people would like to be able to do. What we are doing is explicitly adding devices, what people would like to do is infer the devices from the board type. Personally I'm totally happy with explicitly adding an audio device, but not everyone is and I do understand where they're coming from. -- 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 v3] ASoC: omap: convert per-board modules to platform drivers
On Fri, Sep 09, 2011 at 12:38:51PM +0100, Mans Rullgard wrote: This converts the per-board modules to platform drivers for a device created by in main platform setup. These drivers call snd_soc_register_card() directly instead of going via a soc-audio device and the corresponding driver in soc-core. Signed-off-by: Mans Rullgard mans.rullg...@linaro.org Acked-by: Mark Brown broo...@opensource.wolfsonmicro.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 0/5 v8] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
On Thu, Aug 25, 2011 at 12:31 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. these patches are rebased to kevin's pm branch and usbhs latest mainline kernel patches TODO: - Adding pad configurations to Hwmods - Aggressive clock cutting in usb bus suspends - Remote Wakeup implementation using irq-chaining Benoit Cousson (1): arm: omap: usb: ehci and ohci hwmod structures for omap4 Keshava Munegowda (4): arm: omap: usb: ehci and ohci hwmod structures for omap3 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs mfd: omap: usb: Runtime PM support arch/arm/mach-omap2/clock3xxx_data.c | 26 +- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 281 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247 ++ arch/arm/mach-omap2/usb-host.c | 114 ++--- arch/arm/plat-omap/include/plat/usb.h | 3 - drivers/mfd/omap-usb-host.c | 733 +++- drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 9 files changed, 891 insertions(+), 558 deletions(-) Hi Benoit Cousson please ack this series; I am waiting for your ack to lineup this USBHS runtime pm adaptions. 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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Friday 09 September 2011 08:57 PM, Shawn Guo wrote: On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote: On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guoshawn@freescale.com wrote: On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, [...] #ifdef CONFIG_CACHE_L2X0 /* * Clean and invalidate the L2 cache. * Common cache-l2x0.c functions can't be used here since it * uses spinlocks. We are out of coherency here with data cache * disabled. The spinlock implementation uses exclusive load/store * instruction which can fail without data cache being enabled. * OMAP4 hardware doesn't support exclusive monitor which can * overcome exclusive access issue. Because of this, CPU can * lead to deadlock. */ l2x_clean_inv: bl omap4_get_sar_ram_base mov r8, r0 mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR andsr5, r5, #0x0f ldreq r0, [r8, #L2X0_SAVE_OFFSET0] ldrne r0, [r8, #L2X0_SAVE_OFFSET1] cmp r0, #3 bne do_WFI It looks like you are bypassing L2 clean and invalidate for cases 1 and 2 here. But I really do not understand how you get r0 back here. The value which is passed in R0 is also stored in scratch patch memory and retrieved using L2X0_SAVE_OFFSET0. Simple :) 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 5/5] ARM: omap4: Kill private do_wfi macro.
On Friday 09 September 2011 08:56 PM, Nick Bowler wrote: The do_wfi macro duplicates the functionality of the wfi macro in common ARM code. Use the common version instead. Signed-off-by: Nick Bowlernbow...@elliptictech.com --- Compile tested in both ARM and Thumb-2 mode. Thanks but this is already handle in my PM series. https://patchwork.kernel.org/patch/624761/ 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 5/5] ARM: omap4: Kill private do_wfi macro.
On 2011-09-09 22:34 +0530, Santosh wrote: On Friday 09 September 2011 08:56 PM, Nick Bowler wrote: The do_wfi macro duplicates the functionality of the wfi macro in common ARM code. Use the common version instead. Signed-off-by: Nick Bowlernbow...@elliptictech.com --- Compile tested in both ARM and Thumb-2 mode. Thanks but this is already handle in my PM series. OK, I will drop this patch. Thanks, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.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 v6 17/25] gpio/omap: use pm-runtime framework
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
[...]
+static const struct dev_pm_ops gpio_pm_ops = {
+ .suspend = omap_gpio_suspend,
+ .resume = omap_gpio_resume,
+};
Please use SET_SYSTEM_SLEEP_PM_OPS(). See linux/pm.h
We can use following macro to initialize .suspend and .resume callbacks.
But how do we initialize .runtime_suspend and .runtime_resume callbacks?
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
}
Do we have something similar to following where we can assign separate
pair of callbacks?
SET_RUNTIME_PM_OPS()
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 07/11] Serial: OMAP: Add runtime pm support for omap-serial driver
Govindraj govindraj...@gmail.com writes:
On Fri, Sep 9, 2011 at 5:54 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Adapts omap-serial driver to use pm_runtime API's.
1.) Moving context_restore func to driver from serial.c
2.) Use runtime irq safe to use get_sync from irq context.
3.) autosuspend for port specific activities and put for reg access.
Re: autosuspend, it looks like the driver now has 2 mechanisms for
tracking activity. The runtime PM 'mark last busy' and the existing
'up-port_activity = jiffies' stuff. Do you think those could be
unified?
Is there a way where we can retrieve the last busy jiffie value
using runtime API? I don't find that available.
Not currently. The question is more along the lines of: what is the
port_activity jiffies used for, and can it be replaced by using
_mark_last_busy().
If it cannot, that's fine, but it should be described.
At first glance, it looks like most places with a _mark_last_busy() also
have a up-port_activity update. I'm not familiar enough with the
driver to make the call, but they look awfully similar.
Ok, I will check whether I can get rid if it.
4.) for earlyprintk usage the debug macro will write to console uart
so keep uart clocks active from boot, idle using hwmod API's re-enable
back
using runtime API's.
/me doesn't understand
I have added this reason in early mail reply to 04/11 patch review
[needed for earlyprintk option from low level debug ]
OK, but AFAIK, DEBUG_LL + earlyprintk do not use this driver. Instead
they use the debug macros, so any hacks to deal with that do not belong
in the driver.
If there are hacks required, they should be in a separate patch, with a
separate descriptive changelog.
5.) Moving context restore to runtime suspend and using reg values from port
structure to restore the uart port context based on context_loss_count.
Maintain internal state machine for avoiding repeated enable/disable of
uart port wakeup mechanism.
6.) Add API to enable wakeup and check wakeup status.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 49 ++
arch/arm/plat-omap/include/plat/omap-serial.h | 10 ++
drivers/tty/serial/omap-serial.c | 211
++---
3 files changed, 250 insertions(+), 20 deletions(-)
[..]
+
+static void omap_uart_wakeup_enable(struct platform_device *pdev, bool
enable)
+{
+ struct omap_device *od;
+ struct omap_uart_port_info *up = pdev-dev.platform_data;
+
+ /* Set or clear wake-enable bit */
+ if (up-wk_en up-wk_mask) {
+ u32 v = __raw_readl(up-wk_en);
+ if (enable)
+ v |= up-wk_mask;
+ else
+ v = ~up-wk_mask;
+ __raw_writel(v, up-wk_en);
+ }
+
+ od = to_omap_device(pdev);
+ if (enable)
+ omap_hwmod_enable_wakeup(od-hwmods[0]);
+ else
+ omap_hwmod_disable_wakeup(od-hwmods[0]);
+}
+
Here again, this is difficult to review because you removed the code in
[4/11] and add it back here, but with rather different functionality
with no description as to why.
will move this change as part of 4/11 itself.
The point was not just that the move was confusing, but that you changed
the functionality along with the move without any description.
The previous version enabled wakeups at the PRCM and at the IO ring.
This version enables wakeups at the PRCM as well but instead of enabling
them at the IO ring, enables them at the module.
Since we are gating using prepare idle call I think
we can use this enable wake-up call as part of prepare idle call itself,
as done earlier.
Not sure what that has to with my comment.
In moving this code, you removed the enable/disable of IO ring wakeups.
It probably continues to work because they're enabled by the bootloader,
but that is not correct and the driver should be managing the IO ring
wakeups as before.
[...]
}
static int __init
@@ -1065,22 +1123,33 @@ static struct uart_driver serial_omap_reg = {
.cons = OMAP_CONSOLE,
};
-static int
-serial_omap_suspend(struct platform_device *pdev, pm_message_t state)
+static int serial_omap_suspend(struct device *dev)
{
- struct uart_omap_port *up = platform_get_drvdata(pdev);
+ struct uart_omap_port *up = dev_get_drvdata(dev);
- if (up)
+ if (up) {
uart_suspend_port(serial_omap_reg, up-port);
+ if (up-port.line == up-port.cons-index
+ !is_console_locked())
+ up-console_locked = console_trylock();
+ }
+
Motiviation for console locking in this version of the series is not
clear, and not described in the changelog.
It's also present here in static suspend/resume but not in runtime
Re: [PATCH 1/2] arm: omap: usb: enable I/O wakeups of ehci and ohci hwmods of omap4
Keshava Munegowda keshava_mgo...@ti.com writes: From: Kishon Vijay Abraham kis...@ti.com For ehci and ohci hwmods, the omap4 I/O wakeup capablity is enabled. for ehci in phy mode, - the DAT0 and DIR I/O pad is set as wakeup capable for ohci in serial mode - usbb*_mm_rxdp is set as I/O wakeup for 6 pin serial mode - usbb*_mm_rxrcv is set as I/O wakeup for 4 pin serial mode - usbb*_mm_txen is set as I/O wakeup for 3 pin serial mode - usbb*_mm_txdat is set as I/O wakeup for 2 pin serial mode Signed-off-by: Kishon Vijay Abraham kis...@ti.com Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com What if the end user doesn't want this device to be a wakeup source? Currently, the IO pad wakeup for these pins is enabled unconditionally. While having it enabled as a wakeup source by default is fine, it should not generate wakeups if the user has disable them by doing: $ echo disabled /sys/devices/.../power/wakeup IOW, whether wakeups are enabled or not should depend on the driver checking device_may_wakeup() Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
Santosh santosh.shilim...@ti.com writes: On Friday 09 September 2011 08:57 PM, Shawn Guo wrote: On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote: On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guoshawn@freescale.com wrote: On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, [...] #ifdef CONFIG_CACHE_L2X0 /* * Clean and invalidate the L2 cache. * Common cache-l2x0.c functions can't be used here since it * uses spinlocks. We are out of coherency here with data cache * disabled. The spinlock implementation uses exclusive load/store * instruction which can fail without data cache being enabled. * OMAP4 hardware doesn't support exclusive monitor which can * overcome exclusive access issue. Because of this, CPU can * lead to deadlock. */ l2x_clean_inv: bl omap4_get_sar_ram_base mov r8, r0 mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR andsr5, r5, #0x0f ldreq r0, [r8, #L2X0_SAVE_OFFSET0] ldrne r0, [r8, #L2X0_SAVE_OFFSET1] cmp r0, #3 bne do_WFI It looks like you are bypassing L2 clean and invalidate for cases 1 and 2 here. But I really do not understand how you get r0 back here. The value which is passed in R0 is also stored in scratch patch memory and retrieved using L2X0_SAVE_OFFSET0. Simple :) Sounds like some in-code documentation needs to be added to make this a bit more understandable. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] OMAP3+: PM: VP: generalize PRM interrupt helpers
Jean Pihet jean.pi...@newoldbits.com writes: Mike, Kevin, On Thu, Jun 30, 2011 at 2:25 AM, Mike Turquette mturque...@ti.com wrote: From: Nishanth Menon n...@ti.com We have multiple interrupt status hidden in the PRM interrupt status reg. Make this handling generic to allow us to pull out LDO status such as those for ABB from it using the same data structure and indexing. We hence rename accordingly. I am not sure that the rename is needed. Kevin, Nishant, what is your opinion? Rename is mostly fine. I think the patch is correct, since the interrupts are technically for the the whole PRM, not just the VP. However, I don't like the s/vp_id/irq_id/ in the APIs, because the APIs are intended to be VP specific. I'll likely pull/fold the parts I agree with into the original patch in my VP cleanup series Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression seen when HIGHMEM enabled with NFS on 3.1rc4 kernel
On Fri, 2011-09-09 at 18:40 +0530, R, Sricharan wrote:
Sorry resending again. My mailer settings thrashed my earlier email.
Hi,
A kernel crash is observed on 3.1rc4 kernel when HIGHMEM is enabled and
kernel is booted with a NFS on omap4430sdp. The issue happens in the below
scenario.
In file net/sunrpc/xprtsock.c,
static int xs_send_pagedata( xxx, struct xdr_buf *xdr, ..)
{
Struct page **ppage;
.
ppage = xdr-pages + (base PAGE_SHIFT);
err = sock-ops-sendpage(sock, *ppage, base, len, flags);
...
}
1) In the above piece of code, the *ppage value from ops-sendpage
function is finally passed on to Kmap by the lower level code to
get the virtual address of the page.
2) In some corner cases the value of *ppage pointer is NULL.
3) When highmem is enabled and a NULL pointer is passed to
Kmap, then kmap finally crashes. But in the case when highmem
is disabled, then kmap returns a junk value for NULL pointer.
Highmem Enabled , kmap( NULL )- kernel crashes.
Highmem disabled, kmap( NULL )- junk value is returned.
Subsequently this message is observed on
the console.
RPC call returned error 14
4) Now the question is why is the value of *ppage = NULL is passed
from the above piece of code to lower layers.
Should that not have handled *ppage = NULL? and kmap should not
have received a NULL pointer?
I wouldn't expect *ppage to be NULL under any circumstances, so I'm
really curious as to what is happening here.
Could you perhaps add a printk() to that section of code to print out
the values of 'xdr-page_base', 'xdr-page_len', 'len' and 'remainder'
in the case where *ppage == NULL?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.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
Polling support in omap uart driver
Hello, Does omap serial driver (omap-serial.c) support polling? Without this, kgdboc won't work, is that correct? Thanks. Hemant-- 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 v6 17/25] gpio/omap: use pm-runtime framework
On Fri, Sep 9, 2011 at 11:34 PM, Kevin Hilman khil...@ti.com wrote:
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
[...]
+static const struct dev_pm_ops gpio_pm_ops = {
+ .suspend = omap_gpio_suspend,
+ .resume = omap_gpio_resume,
+};
Please use SET_SYSTEM_SLEEP_PM_OPS(). See linux/pm.h
We can use following macro to initialize .suspend and .resume callbacks.
But how do we initialize .runtime_suspend and .runtime_resume callbacks?
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
}
Do we have something similar to following where we can assign separate
pair of callbacks?
SET_RUNTIME_PM_OPS()
Yes, I have done this way:
static const struct dev_pm_ops gpio_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(omap_gpio_suspend, omap_gpio_resume)
SET_RUNTIME_PM_OPS(omap_gpio_runtime_suspend, omap_gpio_runtime_resume,
NULL)
};
--
Tarun
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 09/11] OMAP2+: Serial: Use prepare and resume calls to gate uart clocks
Govindraj.R govindraj.r...@ti.com writes:
Currently we are using uart prepare and resume calls to gate uart clocks
retaining the same method.
More details on reason to retain this design is provided here:
http://www.spinics.net/lists/linux-serial/msg04128.html
This type of thing can go after the '---' since it doesn't belong in the
permanent git history.
Since prepare and resume hooks are moved to driver itself we can just use
a single prepare and resume call. As in driver we traverse on number of uart
instance and handle it accordingly.
Some important functionality has been removed (and not documented.)
Namely, the current code checks the next power when deciding whether or
not to call prepare_idle, and vice versa for resume_idle.
It's quite possible that it is no longer needed with the runtime PM
In 34xx uart can wakeup using module level PM_WKEN or IO PAD wakeup use
resume_call from prcm irq handler to wakeup uart, based on chk_wakeup_status
from io_pad or PM_WKST.
IMO, this patch should just replace the mulitple calls with a single
call, but still in the idle path.
Using the PRCM IRQ handler should be a separate patch with it's own
changelog.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Also, moving these calls to the driver means that the driver cannot be
built as a module:
arch/arm/mach-omap2/built-in.o: In function `omap2_enter_full_retention':
/work/kernel/omap/pm/arch/arm/mach-omap2/pm24xx.c:141: undefined reference to
`omap_uart_prepare_idle'
/work/kernel/omap/pm/arch/arm/mach-omap2/pm24xx.c:148: undefined reference to
`omap_uart_resume_idle'
arch/arm/mach-omap2/built-in.o: In function `prcm_clear_mod_irqs':
/work/kernel/omap/pm/arch/arm/mach-omap2/pm34xx.c:213: undefined reference to
`omap_uart_resume_idle'
arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle':
/work/kernel/omap/pm/arch/arm/mach-omap2/pm34xx.c:390: undefined reference to
`omap_uart_prepare_idle'
---
arch/arm/mach-omap2/pm24xx.c |8 +
arch/arm/mach-omap2/pm34xx.c | 17 +---
arch/arm/plat-omap/include/plat/serial.h |4 +-
drivers/tty/serial/omap-serial.c | 40
++
4 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 39f26af..91eacef 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -138,18 +138,14 @@ static void omap2_enter_full_retention(void)
if (!console_trylock())
goto no_sleep;
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
- omap_uart_prepare_idle(2);
+ omap_uart_prepare_idle();
/* Jump to SRAM suspend code */
omap2_sram_suspend(sdrc_read_reg(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_POWER));
- omap_uart_resume_idle(2);
- omap_uart_resume_idle(1);
- omap_uart_resume_idle(0);
+ omap_uart_resume_idle();
if (!is_suspending())
console_unlock();
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9f3bf2c..26ddd56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -210,6 +210,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, grpsel_off);
+ c += omap_uart_resume_idle();
if (wkst) {
iclk = omap2_cm_read_mod_reg(module, iclk_off);
fclk = omap2_cm_read_mod_reg(module, fclk_off);
@@ -380,17 +381,19 @@ void omap_sram_idle(void)
}
/* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
+ if (!is_suspending()) {
if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
+ core_next_state PWRDM_POWER_ON) {
if (!console_trylock())
goto console_still_active;
+ else
+ omap_uart_prepare_idle();
+ }
+ }
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
- omap_uart_prepare_idle(2);
- omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_going_off);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
@@ -398,8 +401,6 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers
On Fri, Sep 09, 2011 at 09:11:52AM -0700, Mark Brown wrote: On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote: On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote: The problem is that someone has to manually go and add the device to every board that needs one and people find that tedious and slightly inelegant Sheesh. So now you're arguing against your statement above? Please stop wasting my time. There's two things going on here - what we are doing and what people would like to be able to do. What we are doing is explicitly adding devices, what people would like to do is infer the devices from the board type. Personally I'm totally happy with explicitly adding an audio device, but not everyone is and I do understand where they're coming from. Well, with DT, there won't be any 'board type' anymore. There won't be any 'machine_is_xxx()' to sort it out anymore. Using DT, all that will be history - it's all got to be sorted out by either devices or device properties. So, given that, I don't see the logic of having two methods - it might as well be dealt with by devices and [platform data for non-DT | DT properties], and which then means we have everything working the same way irrespective of what the backing data for the platform actually is. Therefore, as we are heading for DT, I'd definitely say that having machine_is_xxx() outside of arch/arm is a bug, no less and no more. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Convert ARM subarchitectures to generic wfi macro.
On Fri, Sep 09, 2011 at 11:42:54AM -0400, Nick Bowler wrote: And after all that, I forgot to CC Russell on these patches. Oops. Doesn't matter, I get them anyway (provided lakml is in the cc). -- 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 v3] ASoC: omap: convert per-board modules to platform drivers
On Fri, Sep 09, 2011 at 12:38:51PM +0100, Mans Rullgard wrote:
This converts the per-board modules to platform drivers for a
device created by in main platform setup. These drivers call
snd_soc_register_card() directly instead of going via a soc-audio
device and the corresponding driver in soc-core.
Signed-off-by: Mans Rullgard mans.rullg...@linaro.org
---
This version uses a table to assign the device name in omap_init_audio().
It is certainly less ugly than the previous patch.
Again, tested only on Beagle.
---
arch/arm/mach-omap2/devices.c | 34 +++
sound/soc/omap/am3517evm.c| 55 +++---
sound/soc/omap/igep0020.c | 52 +++--
sound/soc/omap/n810.c | 73
++---
sound/soc/omap/omap3beagle.c | 55 +++---
sound/soc/omap/omap3evm.c | 56 ---
sound/soc/omap/omap3pandora.c | 70 ---
sound/soc/omap/overo.c| 56 +++
sound/soc/omap/rx51.c | 55 +--
sound/soc/omap/sdp3430.c | 65 ++--
sound/soc/omap/sdp4430.c | 60 +
sound/soc/omap/zoom2.c| 68 +-
12 files changed, 458 insertions(+), 241 deletions(-)
I don't think this is an improvement. Just look at the diffstat - it almost
doubles the number of lines of code.
One thing here which is utterly silly is:
+static struct {
+ int machine;
+ const char *name;
+} soc_device_names[] = {
+ { MACH_TYPE_OMAP3517EVM,am3517evm-soc-audio },
+ { MACH_TYPE_IGEP0020, igep2-soc-audio },
+ { MACH_TYPE_NOKIA_N810, n8x1-soc-audio},
+ { MACH_TYPE_NOKIA_N810_WIMAX, n8x1-soc-audio},
+ { MACH_TYPE_OMAP3_BEAGLE, omap3beagle-soc-audio },
+ { MACH_TYPE_DEVKIT8000, omap3beagle-soc-audio },
+ { MACH_TYPE_OMAP3EVM, omap3evm-soc-audio},
+ { MACH_TYPE_OMAP3_PANDORA, pandora-soc-audio },
+ { MACH_TYPE_OVERO, overo-soc-audio, },
+ { MACH_TYPE_CM_T35, overo-soc-audio, },
+ { MACH_TYPE_NOKIA_RX51, rx51-soc-audio, },
+ { MACH_TYPE_OMAP_3430SDP, sdp3430-soc-audio,},
+ { MACH_TYPE_OMAP_4430SDP, sdp4430-soc-audio,},
+ { MACH_TYPE_OMAP_ZOOM2, zoom2-soc-audio, },
+};
So you're using the machine ID to select the name of the device.
(That's not really DT compatible.)
+static int __init am3517evm_soc_init(void)
+{
+ if (!machine_is_omap3517evm())
+ return -ENODEV;
But then you conditionalize the registration of the drivers on the
platform as well. Why? It's pointless. If you don't have the core
code register the struct device for this platform then this driver
won't be bound to a device, and therefore the probe function won't be
called.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/11] OMAP: Serial: Allow UART parameters to be configured from board file.
Govindraj.R govindraj.r...@ti.com writes: The following UART parameters are defined within the UART driver: 1). Whether the UART uses DMA (dma_enabled), by default set to 0 2). The size of dma buffer (set to 4096 bytes) 3). The time after which the dma should stop if no more data is received. 4). The auto suspend delay that will be passed for pm_runtime_autosuspend where uart will be disabled after timeout Different UARTs may be used for different purpose such as the console, for interfacing bluetooth chip, for interfacing to a modem chip, etc. Therefore, it is necessary to be able to customize the above settings for a given board on a per UART basis. This change allows these parameters to be configured from the board file and allows the parameters to be configured for each UART independently. If a board does not define its own custom parameters for the UARTs, then use the default parameters in the structure omap_serial_default_info. The default parameters are defined to be the same as the current settings in the UART driver to avoid breaking the UART for any board. By default, make all boards use the default UART parameters. Signed-off-by: Deepak K deepa...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com Who is the author of this patch? The first version says Jon[1], v2 says Deepak[2]. Either way, please ensure proper authorship is attributed using From: at the beginning of the changelog. (git-format-patch will do this for you when the authorship is correct in the git history.) Even better would be to summarize the changes since the first version after the '---' so it would be clearer why the authorship was changed. Only 1/3 of my comments from v3 were addressed in this version. Please re-read my comments there[3]. Kevin [1] http://marc.info/?l=linux-omapm=129890257812478w=2 [2] http://marc.info/?l=linux-omapm=130408096416887w=2 [3] http://marc.info/?l=linux-omapm=130896078622810w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers
On Fri, Sep 09, 2011 at 08:01:35PM +0100, Russell King - ARM Linux wrote: Well, with DT, there won't be any 'board type' anymore. There won't be any 'machine_is_xxx()' to sort it out anymore. Using DT, all that will be history - it's all got to be sorted out by either devices or device properties. There is a board type - there's a root compatible property for the board which fulfils this purpose - so the situation with and without device tree is essentially the same. -- 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] ASoC: omap: convert per-board modules to platform drivers
On Fri, Sep 09, 2011 at 12:30:11PM -0700, Mark Brown wrote: On Fri, Sep 09, 2011 at 08:01:35PM +0100, Russell King - ARM Linux wrote: Well, with DT, there won't be any 'board type' anymore. There won't be any 'machine_is_xxx()' to sort it out anymore. Using DT, all that will be history - it's all got to be sorted out by either devices or device properties. There is a board type - there's a root compatible property for the board which fulfils this purpose - so the situation with and without device tree is essentially the same. So instead of a table of machine id numbers and soc device strings, you're going to have a table of board 'compatible' strings and soc device strings, and you're going to have to manually create the struct device with that name. That's just twisted and utterly insane - adding more code for precisely zero benefit what so ever. Think about it - the device tree is *already* creating platform devices for entries in the device tree file. What's the point of having this special ASoC code look up the platform compatible property in a table of strings to find a different string to manually create a device with. Why not just _add_ the bloody device to the DT file in the first place? That's partly what DT is there for - to create platform specific struct devices. -- 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 v6 17/25] gpio/omap: use pm-runtime framework
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Fri, Sep 9, 2011 at 11:34 PM, Kevin Hilman khil...@ti.com wrote:
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
[...]
+static const struct dev_pm_ops gpio_pm_ops = {
+ .suspend = omap_gpio_suspend,
+ .resume = omap_gpio_resume,
+};
Please use SET_SYSTEM_SLEEP_PM_OPS(). See linux/pm.h
We can use following macro to initialize .suspend and .resume callbacks.
But how do we initialize .runtime_suspend and .runtime_resume callbacks?
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
}
Do we have something similar to following where we can assign separate
pair of callbacks?
SET_RUNTIME_PM_OPS()
Yes, I have done this way:
static const struct dev_pm_ops gpio_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(omap_gpio_suspend, omap_gpio_resume)
SET_RUNTIME_PM_OPS(omap_gpio_runtime_suspend,
omap_gpio_runtime_resume,
NULL)
Perfect.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] OMAP3+: PM: VP: generalize PRM interrupt helpers
Jean Pihet jean.pi...@newoldbits.com writes: Mike, Kevin, On Thu, Jun 30, 2011 at 2:25 AM, Mike Turquette mturque...@ti.com wrote: From: Nishanth Menon n...@ti.com We have multiple interrupt status hidden in the PRM interrupt status reg. Make this handling generic to allow us to pull out LDO status such as those for ABB from it using the same data structure and indexing. We hence rename accordingly. I am not sure that the rename is needed. Kevin, Nishant, what is your opinion? On second thought, I don't like the rename. The goal of the VP stuff in prm.c is to provide high-level functions for VP code where the register access stuff is contained in the PRM layer (since all registers for VP are in the PRM.) While it's currently only used for VP-related IRQs, this might be extended for other VP register accesses, if there are register differences between SoC revisions. So, in the end, I agree w/Jean. I don't think the rename is right. I will however pick up the sparse warning fix, and fold it into the original patch in my part A series where the problem was introduced: OMAP2+: add PRM VP functions for checking/clearing VP TX done status Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/22] OMAP2: add voltage domains and connect to powerdomains
Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: On Mon, Aug 29, 2011 at 7:35 PM, Kevin Hilman khil...@ti.com wrote: Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains with the newly created voltage domains. Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/Makefile | 3 +- arch/arm/mach-omap2/io.c | 2 + arch/arm/mach-omap2/powerdomains2xxx_data.c | 4 +++ arch/arm/mach-omap2/voltage.h | 1 + arch/arm/mach-omap2/voltagedomains2xxx_data.c | 32 + 5 files changed, 41 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/voltagedomains2xxx_data.c ... diff --git a/arch/arm/mach-omap2/voltagedomains2xxx_data.c b/arch/arm/mach-omap2/voltagedomains2xxx_data.c new file mode 100644 index 000..69ff261 --- /dev/null +++ b/arch/arm/mach-omap2/voltagedomains2xxx_data.c @@ -0,0 +1,32 @@ +/* + * OMAP3 voltage domain data + * + * Copyright (C) 2007, 2010 Texas Instruments, Inc. 2011? Yup, thanks for the review! Will update. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/22] OMAP2: add voltage domains and connect to powerdomains
Jean Pihet jean.pi...@newoldbits.com writes: Kevin, On Mon, Aug 29, 2011 at 7:35 PM, Kevin Hilman khil...@ti.com wrote: Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains with the newly created voltage domains. Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/Makefile | 3 +- arch/arm/mach-omap2/io.c | 2 + arch/arm/mach-omap2/powerdomains2xxx_data.c | 4 +++ arch/arm/mach-omap2/voltage.h | 1 + arch/arm/mach-omap2/voltagedomains2xxx_data.c | 32 + 5 files changed, 41 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/voltagedomains2xxx_data.c ... diff --git a/arch/arm/mach-omap2/voltagedomains2xxx_data.c b/arch/arm/mach-omap2/voltagedomains2xxx_data.c new file mode 100644 index 000..69ff261 --- /dev/null +++ b/arch/arm/mach-omap2/voltagedomains2xxx_data.c @@ -0,0 +1,32 @@ +/* + * OMAP3 voltage domain data + * + * Copyright (C) 2007, 2010 Texas Instruments, Inc. 2011? Thanks, will update. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/22] OMAP4: powerdomain data: add voltage domains
Jean Pihet jean.pi...@newoldbits.com writes: Hi, On Mon, Aug 29, 2011 at 7:35 PM, Kevin Hilman khil...@ti.com wrote: From: Benoit Cousson b-cous...@ti.com Add voltage domain name to indicate which voltagedomain each powerdomain is in. The fixed voltage domain like ldo_wakeup for emu and wkup power domain is added too. Update the TI copyright date to 2011. This seems to not be part of this patch. OK, dropping this part of the changelog. The new stuff (voltagedomain data) already has a 2011 copyright, and I'll just leave the powerdomain stuff for now. Ok for the rest of it. Thanks for the review. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/22] OMAP2+: voltage: keep track of powerdomains in each voltagedomain
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Kevin,
On Mon, Aug 29, 2011 at 7:35 PM, Kevin Hilman khil...@ti.com wrote:
When a powerdomain is registered and it has an associated voltage domain,
add the powerdomain to the voltagedomain using voltdm_add_pwrdm().
Also add voltagedomain iterator helper functions to iterate over all
registered voltagedomains and all powerdomains associated with a
voltagedomain.
Modeled after a similar relationship between clockdomains and powerdomains.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 2 +
arch/arm/mach-omap2/powerdomain.h | 2 +
arch/arm/mach-omap2/voltage.c | 80
+
arch/arm/mach-omap2/voltage.h | 10 +
4 files changed, 94 insertions(+), 0 deletions(-)
...
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 966aa88..b41d9f1 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -19,6 +19,8 @@
#include vc.h
#include vp.h
+struct powerdomain;
+
/* XXX document */
#define VOLTSCALE_VPFORCEUPDATE 1
#define VOLTSCALE_VCBYPASS 2
@@ -55,12 +57,15 @@ struct omap_vfsm_instance_data {
* @name: Name of the voltage domain which can be used as a unique
identifier.
* @scalable: Whether or not this voltage domain is scalable
* @node: list_head linking all voltage domains
+ * @pwrdm_node: list_head linking all powerdomains in this voltagedomain
* @vdd: to be removed
+ * @pwrdms: powerdomains in this voltagedomain
*/
struct voltagedomain {
char *name;
bool scalable;
struct list_head node;
+ struct list_head pwrdm_list;
struct omap_vdd_info *vdd;
};
The kerneldoc is not reflecting the code for struct voltagedomain.
hmm, looks like kerneldoc is out of sync in a few places.
Thanks for catching. Will fixup.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/22] OMAP2+: voltage: split voltage controller (VC) code into dedicated layer
Jean Pihet jean.pi...@newoldbits.com writes: Kevin, On Mon, Aug 29, 2011 at 7:35 PM, Kevin Hilman khil...@ti.com wrote: As part of the voltage layer cleanup, split out VC specific code into a dedicated VC layer. This patch primarily just moves VC code from voltage.c into vc.c, and adds prototypes to vc.h. No functional changes. For readability, each function was given a local 'vc' pointer: struct omap_vc_instance_data *vc = voltdm-vdd-vc_data; and a global replace of s/vdd-vc_data/vc/ was done. Also vc_init was renamed to vc_init_channel to reflect that this is per-VC channel initializtion. Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/vc.c | 276 + arch/arm/mach-omap2/vc.h | 12 ++ arch/arm/mach-omap2/voltage.c | 264 +-- 4 files changed, 293 insertions(+), 261 deletions(-) create mode 100644 arch/arm/mach-omap2/vc.c ... diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c new file mode 100644 index 000..98f5a4b --- /dev/null +++ b/arch/arm/mach-omap2/vc.c @@ -0,0 +1,276 @@ The copyright notice is missing. oops, will add. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
On Fri, Sep 09, 2011 at 10:29:49PM +0530, Santosh wrote: On Friday 09 September 2011 08:57 PM, Shawn Guo wrote: On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote: On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guoshawn@freescale.com wrote: On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, [...] #ifdef CONFIG_CACHE_L2X0 /* * Clean and invalidate the L2 cache. * Common cache-l2x0.c functions can't be used here since it * uses spinlocks. We are out of coherency here with data cache * disabled. The spinlock implementation uses exclusive load/store * instruction which can fail without data cache being enabled. * OMAP4 hardware doesn't support exclusive monitor which can * overcome exclusive access issue. Because of this, CPU can * lead to deadlock. */ l2x_clean_inv: bl omap4_get_sar_ram_base mov r8, r0 mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR andsr5, r5, #0x0f ldreq r0, [r8, #L2X0_SAVE_OFFSET0] ldrne r0, [r8, #L2X0_SAVE_OFFSET1] cmp r0, #3 bne do_WFI It looks like you are bypassing L2 clean and invalidate for cases 1 and 2 here. But I really do not understand how you get r0 back here. The value which is passed in R0 is also stored in scratch patch memory and retrieved using L2X0_SAVE_OFFSET0. Simple :) Aha, no wonder that I read it wrongly. The parameter passing in r0 is here simply for confusing people. Also, IMO, lable l2x_clean_inv should be put after the bne do_WFI. Otherwise, my original statement (it seems l2x_clean_inv will be called for case 2) stands correct :) -- Regards, Shawn -- 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 v6 00/25] gpio/omap: driver cleanup and fixes
[...] Please rebase onto that branch so these changes can be tested along with changes already queued for v3.2. Ok. I am not able to git pull git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Looks like there is problem with git.kernel.org? -- Tarun [...] -- 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 14/25] OMAP4: PM: Add CPUX OFF mode support
IOn Sat, Sep 10, 2011 at 5:04 AM, Shawn Guo shawn@freescale.com wrote: On Fri, Sep 09, 2011 at 10:29:49PM +0530, Santosh wrote: On Friday 09 September 2011 08:57 PM, Shawn Guo wrote: On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote: On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guoshawn@freescale.com wrote: On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, [...] #ifdef CONFIG_CACHE_L2X0 /* * Clean and invalidate the L2 cache. * Common cache-l2x0.c functions can't be used here since it * uses spinlocks. We are out of coherency here with data cache * disabled. The spinlock implementation uses exclusive load/store * instruction which can fail without data cache being enabled. * OMAP4 hardware doesn't support exclusive monitor which can * overcome exclusive access issue. Because of this, CPU can * lead to deadlock. */ l2x_clean_inv: bl omap4_get_sar_ram_base mov r8, r0 mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR ands r5, r5, #0x0f ldreq r0, [r8, #L2X0_SAVE_OFFSET0] ldrne r0, [r8, #L2X0_SAVE_OFFSET1] cmp r0, #3 bne do_WFI It looks like you are bypassing L2 clean and invalidate for cases 1 and 2 here. But I really do not understand how you get r0 back here. The value which is passed in R0 is also stored in scratch patch memory and retrieved using L2X0_SAVE_OFFSET0. Simple :) Aha, no wonder that I read it wrongly. The parameter passing in r0 is here simply for confusing people. No It's not. Same cod is used for CPUIDLE and we do have different C-states than just OSWR. ON and INACTIVE makes use of it. Also, IMO, lable l2x_clean_inv should be put after the bne do_WFI. Otherwise, my original statement (it seems l2x_clean_inv will be called for case 2) stands correct :) It's just a label. All L2 related code and checks for the valid state is kept under that by purpose. 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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Sat, Sep 10, 2011 at 12:04 AM, Kevin Hilman khil...@ti.com wrote: Santosh santosh.shilim...@ti.com writes: On Friday 09 September 2011 08:57 PM, Shawn Guo wrote: On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote: On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guoshawn@freescale.com wrote: On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: Hi Santosh, [...] #ifdef CONFIG_CACHE_L2X0 /* * Clean and invalidate the L2 cache. * Common cache-l2x0.c functions can't be used here since it * uses spinlocks. We are out of coherency here with data cache * disabled. The spinlock implementation uses exclusive load/store * instruction which can fail without data cache being enabled. * OMAP4 hardware doesn't support exclusive monitor which can * overcome exclusive access issue. Because of this, CPU can * lead to deadlock. */ l2x_clean_inv: bl omap4_get_sar_ram_base mov r8, r0 mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR ands r5, r5, #0x0f ldreq r0, [r8, #L2X0_SAVE_OFFSET0] ldrne r0, [r8, #L2X0_SAVE_OFFSET1] cmp r0, #3 bne do_WFI It looks like you are bypassing L2 clean and invalidate for cases 1 and 2 here. But I really do not understand how you get r0 back here. The value which is passed in R0 is also stored in scratch patch memory and retrieved using L2X0_SAVE_OFFSET0. Simple :) Sounds like some in-code documentation needs to be added to make this a bit more understandable. Will add a comment -- 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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Sat, Sep 10, 2011 at 09:08:16AM +0530, Shilimkar, Santosh wrote: IOn Sat, Sep 10, 2011 at 5:04 AM, Shawn Guo shawn@freescale.com wrote: [...] Also, IMO, lable l2x_clean_inv should be put after the bne do_WFI. Otherwise, my original statement (it seems l2x_clean_inv will be called for case 2) stands correct :) It's just a label. All L2 related code and checks for the valid state is kept under that by purpose. So for some case, you enter l2x_clean_inv but do not actually clean and invalidate L2. I do not see this label being used anywhere, so you may want to remove it to save the confusion to stupid people like me. Just my opinion. -- Regards, Shawn -- 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 14/25] OMAP4: PM: Add CPUX OFF mode support
On Saturday 10 September 2011 10:24 AM, Shawn Guo wrote: On Sat, Sep 10, 2011 at 09:08:16AM +0530, Shilimkar, Santosh wrote: IOn Sat, Sep 10, 2011 at 5:04 AM, Shawn Guoshawn@freescale.com wrote: [...] Also, IMO, lable l2x_clean_inv should be put after the bne do_WFI. Otherwise, my original statement (it seems l2x_clean_inv will be called for case 2) stands correct :) It's just a label. All L2 related code and checks for the valid state is kept under that by purpose. So for some case, you enter l2x_clean_inv but do not actually clean and invalidate L2. I do not see this label being used anywhere, so you may want to remove it to save the confusion to stupid people like me. Just my opinion. Will remove the label :) 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
