Re: [CFT 11/11] Add feature removal of old OMAP private DMA implementation
On Thu, Jun 7, 2012 at 4:39 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/feature-removal-schedule.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 56000b3..1f7ba35 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -612,3 +612,14 @@ When: June 2013 Why: Unsupported/unmaintained/unused since 2.6 + +What: OMAP private DMA implementation +When: 2013 +Why: We have a DMA engine implementation; all users should be updated + to use this rather than persisting with the old APIs. The old APIs + block merging the old DMA engine implementation into the DMA + engine driver. +Who: Russell King li...@arm.linux.org.uk, + Santosh Shilimkar santosh.shilim...@ti.com + + -- Acked-by: Santosh Shilimkar santosh.shilim...@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: [CFT 01/11] dmaengine: add OMAP DMA engine driver
On Thu, Jun 7, 2012 at 4:36 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Tested-by: Tony Lindgren t...@atomide.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Have scanned mainly the OMAP DMA related features in the patch and they look fine to me. Acked-by: Santosh Shilimkar santosh.shilim...@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 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
* Paul Walmsley p...@pwsan.com [120607 15:09]:
On Thu, 7 Jun 2012, Tony Lindgren wrote:
Until we have something generic in place to deal with stuff like unused
driver
reset and idle, how about we set up the driver specific reset parts as
inline
functions in the driver header?
You're referring to the driver integration header files in
arch/arm/plat-omap/include/ and arch/arm/mach-omap2/, right? That would
avoid the need for sideways includes from drivers/.
That way the hwmod code can include those functions using the driver
register
defines. Something like:
static inline int xyz_driver_reset(void __iomem *base, int flags)
{
...
}
Then instead of having a separate platform init file for each driver,
we could just have a list of reset functions:
static int hwmod_xyz_driver_reset(void __iomem *base, int flags)
This should probably be passed a struct omap_hwmod * instead of base so
it can call the existing hwmod bus related reset functions like
omap_hwmod_softreset(). Or were you thinking about open-coding those into
this reset function?
Oh OK yeah makes sense as that's hwmod internal function. Then the driver
specific part should use just void __iomem *base and use readl/writel and
live under include/linux/platform_data/omap-usb.h.
Just as an aside, this function will probably need to be marked
__maybe_unused, so the compiler doesn't warn when other files include this
header, but don't call the function.
Yeah probably.
{
int res;
/* do bus related reset here */
...
/* call the driver reset */
res = xyz_driver_reset(base, flags)
/* do more bus related reset here */
...
}
That's fine with me. It doesn't matter to me where that code lives as
long as it makes technical sense.
OK good. That way we can separate the driver specific part from the bus
code. And the driver maintainers can review the driver specific part of the
idle/reset function. And maybe at some point we'll have device_reset and
device_idle functions and some generic framework in place for it..
I'm hoping that in the near future that we can get rid of these
hwmod_xyz_driver_reset() functions. Instead it should be possible to have
the hwmod reset code call functions like xyz_driver_reset_pre_wait() and
xyz_driver_reset_post_ocpreset() via optional function pointers at
different points in the reset process. That should allow us to remove the
omap_hwmod function calls from the I2C, MSDI, etc. reset functions, and
also remove some needlessly duplicated code.
Sounds good to me. Also sounds like that does not need changes to the
driver specific xyz_driver_reset functions.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes for v3.5-rc1
The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f: Linux 3.5-rc1 (2012-06-02 18:29:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-for-v3.5-rc1 for you to fetch changes up to febe9e02d63ed8a42e7e9c75ea16117821f90f07: ARM: OMAP2+: Fix compile for CONFIG_TIDSPBRIDGE platform init code (2012-06-06 01:42:20 -0700) The biggest fix here is the long pending patch mux UART pins so PM retention idle works again. Also included are few other PM wake-up related fixes, and removal of dead cpu detection code. The other fixes are trivial build and randconfig related fixes. Govindraj.R (1): OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup Kevin Hilman (3): ARM: OMAP3: PM: fix shared PRCM interrupts: leave disabled at boot ARM: OMAP3: clock data: cleanup AM3[35]x SoC detection ARM: OMAP: SoC detection: remove unused cpu_is macros Mark A. Greer (1): arm: omap3: am35x: Don't mark missing features as present NeilBrown (1): ARM: OMAP2+: INTC: fix suspend abort, set IRQCHIP_SKIP_SET_WAKE Tony Lindgren (6): Merge branch 'for_3.5/fixes/pm' of git://git.kernel.org/.../khilman/linux-omap-pm into fixes Merge branch 'for_3.5/cleanup/am3xxx-cpu-is-leftovers' of git://git.kernel.org/.../khilman/linux-omap-pm into fixes ARM: OMAP: Fix lis3lv02d accelerometer to use gpio_to_irq ARM: OMAP: Fix MMC_OMAP build when only MMC_OMAP_HS is selected ARM: OMAP3: Fix omap3_l3_block_irq warning when CONFIG_BUG is not set ARM: OMAP2+: Fix compile for CONFIG_TIDSPBRIDGE platform init code arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/dsp.c|3 ++ arch/arm/mach-omap2/id.c | 11 + arch/arm/mach-omap2/irq.c|1 + arch/arm/mach-omap2/mux.c|3 +- arch/arm/mach-omap2/mux.h| 11 + arch/arm/mach-omap2/omap_l3_smx.c|3 +- arch/arm/mach-omap2/pm34xx.c |1 + arch/arm/mach-omap2/prm2xxx_3xxx.c | 14 -- arch/arm/mach-omap2/serial.c | 67 -- arch/arm/plat-omap/include/plat/cpu.h| 33 - arch/arm/plat-omap/include/plat/mmc.h|4 +- 13 files changed, 110 insertions(+), 49 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 V4 05/12] ARM: OMAP2+: HWMOD: Correct timer device attributes
Paul,
* Jon Hunter jon-hun...@ti.com [120605 10:39]:
Fix the following issues with the timer device attributes for OMAP2+ devices:
1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 and timer12 are in an ALWAYS-ON power domain.
3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but
is in an always-on power domain.
Care to review and potentially ack the hwmod parts of this series?
We should try to merge this early into linux-omap master for testing.
Regards,
Tony
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |7 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
3 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 83eafd9..7814e83 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -257,7 +257,6 @@ struct omap_hwmod omap2xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT2_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -276,7 +275,6 @@ struct omap_hwmod omap2xxx_timer3_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT3_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -295,7 +293,6 @@ struct omap_hwmod omap2xxx_timer4_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT4_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -314,7 +311,6 @@ struct omap_hwmod omap2xxx_timer5_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT5_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -333,7 +329,6 @@ struct omap_hwmod omap2xxx_timer6_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT6_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -352,7 +347,6 @@ struct omap_hwmod omap2xxx_timer7_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT7_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -371,7 +365,6 @@ struct omap_hwmod omap2xxx_timer8_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT8_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b26d3c9..7b33094 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -150,7 +150,7 @@ static struct omap_hwmod_class omap3xxx_timer_hwmod_class
= {
/* secure timers dev attribute */
static struct omap_timer_capability_dev_attr capability_secure_dev_attr = {
- .timer_capability = OMAP_TIMER_SECURE,
+ .timer_capability = OMAP_TIMER_ALWON | OMAP_TIMER_SECURE,
};
/* always-on timers dev attribute */
@@ -195,7 +195,6 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT2_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap3xxx_timer_1ms_hwmod_class,
};
@@ -213,7 +212,6 @@ static struct omap_hwmod omap3xxx_timer3_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT3_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap3xxx_timer_hwmod_class,
};
@@ -231,7 +229,6 @@ static struct omap_hwmod omap3xxx_timer4_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT4_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap3xxx_timer_hwmod_class,
};
@@ -249,7 +246,6 @@ static struct omap_hwmod omap3xxx_timer5_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT5_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class =
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi On Thu, 7 Jun 2012, Rajendra Nayak wrote: Yes, I can include this as part of the common clock conversion series. What I was trying to say is that neither the clock framework not any other OMAP PM layer today makes any use of this information except for gate clocks. The only 2 places in the clock framework this is used is in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which are nops for non gate clocks. So I don;t fully understand what you mean by our current low-level PM design being based on this assumption that every clock belongs to a clockdomain. Did I miss anything else our PM frameworks do with the clock-clkdm association? The reason I am asking is because I am doing a lot of changes around based on this assumption and would really like to know if I am missing something. Well I guess the best thing to do is for you to do PM tests with the converted code and data to make sure it works. That's what I'm worried most about right now for the CCF conversion; it's the most time-consuming part of what I do. If the conversion works without them and everything is relatively clean then I probably won't have many issues with it. ... BTW, just to continue on the clk-clkdm topic: while we might be able to get rid of the clk-clkdm association for OMAP4 soon, and maybe someday for OMAP2/3, it looks like we'll need to keep it around for at least one AM335x clock -- this CLKDIV32K clock. Definitely something to keep in mind... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Hi Paul, On Friday 08 June 2012 01:10 PM, Paul Walmsley wrote: Hi On Thu, 7 Jun 2012, Rajendra Nayak wrote: Yes, I can include this as part of the common clock conversion series. What I was trying to say is that neither the clock framework not any other OMAP PM layer today makes any use of this information except for gate clocks. The only 2 places in the clock framework this is used is in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which are nops for non gate clocks. So I don;t fully understand what you mean by our current low-level PM design being based on this assumption that every clock belongs to a clockdomain. Did I miss anything else our PM frameworks do with the clock-clkdm association? The reason I am asking is because I am doing a lot of changes around based on this assumption and would really like to know if I am missing something. Well I guess the best thing to do is for you to do PM tests with the converted code and data to make sure it works. That's what I'm worried most about right now for the CCF conversion; it's the most time-consuming part of what I do. If the conversion works without them and everything is relatively clean then I probably won't have many issues with it. The more I read your response, the more I feel you have mistaken what this patch is doing and what I am proposing. This patch only gets rid of clkdm assocation from *non gate* clocks. And what I am trying to say is that, this information in not used at all (for non gate clocks) in any of the frameworks today including clock framework. So why should getting rid of some *unused* data have any testing overhead? I did propose sometime back about getting rid of *all* clk- clkdm assocation for OMAP2/3 and my testing also showed some positive results, but that was just preliminary testing and I know to be able to do that we need to much more testing, so thats definitely not what I am doing here. All the gate clocks still have the clk-clkdm association. Even if you look at my common clk conversion series, I have retained all clk-clkdm associations for all gate clocks across OMAP2 and OMAP3. For any other form of clock it was never used and hence I am getting rid of them. regards, Rajendra ... BTW, just to continue on the clk-clkdm topic: while we might be able to get rid of the clk-clkdm association for OMAP4 soon, and maybe someday for OMAP2/3, it looks like we'll need to keep it around for at least one AM335x clock -- this CLKDIV32K clock. Definitely something to keep in mind... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v3.5-rc1
On Fri, Jun 8, 2012 at 12:32 AM, Tony Lindgren t...@atomide.com wrote: The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f: Linux 3.5-rc1 (2012-06-02 18:29:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-for-v3.5-rc1 Thanks, pulled. -Olof -- 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: [CFT] PL08x patches
On Thu, Jun 7, 2012 at 12:45 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Here's the PL08x patches. I've tested the entire set: first the three patches splitting out the virtual channels, then the remaining 31 patches on PL08x. The test was performed on a Nomadik S8815 which has a pretty much vanilla PL08x block. The DMAengine memcpy test completes just fine and behave like before. Tested-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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: [CFT 07/11] spi: omap2-mcspi: add DMA engine support
On Thu, Jun 7, 2012 at 1:08 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Add DMA engine support to the OMAP SPI driver. This supplements the private DMA API implementation contained within this driver, and the driver can be independently switched at build time between using DMA engine and the private DMA API for the transmit and receive sides. Tested-by: Shubhrajyoti shubhrajy...@ti.com Acked-by: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk This looks very good, Acked-by: Linus Walleij linus.wall...@linaro.org Thanks, Linus Walleij -- 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: [CFT 04/11] mmc: omap: add DMA engine support
On Thu, Jun 7, 2012 at 1:07 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Add DMA engine support to the OMAP driver. This supplements the private DMA API implementation contained within this driver, and the driver can be switched at build time between using DMA engine and the private DMA API. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk This looks good as well: Acked-by: Linus Walleij linus.wall...@linaro.org Thanks, Linus Walleij -- 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: [CFT 02/11] mmc: omap_hsmmc: add DMA engine support
On Thu, Jun 7, 2012 at 1:06 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Add DMA engine support to the OMAP HSMMC driver. This supplements the private DMA API implementation contained within this driver, and the driver can be switched at build time between using DMA engine and the private DMA API. Tested-by: Grazvydas Ignotas nota...@gmail.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Looks good: Acked-by: Linus Walleij linus.wall...@linaro.org Thanks, Linus Walleij -- 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: [CFT 01/11] dmaengine: add OMAP DMA engine driver
On Thu, Jun 07, 2012 at 12:06:32PM +0100, Russell King wrote:
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/Kconfig |6 +
drivers/dma/Makefile |1 +
drivers/dma/omap-dma.c | 522
++
include/linux/omap-dma.h | 24 ++
4 files changed, 553 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/omap-dma.c
create mode 100644 include/linux/omap-dma.h
There is a bug in here which no one has spotted... I just noticed it.
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 500bc71..02eb2fd 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -130,14 +130,13 @@ static void omap_dma_callback(int ch, u16 status, void
*data)
spin_lock_irqsave(c-vc.lock, flags);
d = c-desc;
- if (!d)
- return;
-
- if (++c-sgidx d-sglen) {
- omap_dma_start_sg(c, d, c-sgidx);
- } else {
- omap_dma_start_desc(c);
- vchan_cookie_complete(d-vd);
+ if (d) {
+ if (++c-sgidx d-sglen) {
+ omap_dma_start_sg(c, d, c-sgidx);
+ } else {
+ omap_dma_start_desc(c);
+ vchan_cookie_complete(d-vd);
+ }
}
spin_unlock_irqrestore(c-vc.lock, flags);
}
--
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 01/10] ARM: PMU: Add runtime PM Support
Hi Jon,
On Thu, Jun 07, 2012 at 10:22:03PM +0100, Jon Hunter wrote:
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 186c8cb..00adb98 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#include asm/cputype.h
#include asm/irq.h
@@ -367,8 +368,6 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
{
int i, irq, irqs;
struct platform_device *pmu_device = armpmu-plat_device;
- struct arm_pmu_platdata *plat =
- dev_get_platdata(pmu_device-dev);
irqs = min(pmu_device-num_resources, num_possible_cpus());
@@ -376,14 +375,12 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
if (!cpumask_test_and_clear_cpu(i, armpmu-active_irqs))
continue;
irq = platform_get_irq(pmu_device, i);
- if (irq = 0) {
- if (plat plat-disable_irq)
- plat-disable_irq(irq);
+ if (irq = 0)
free_irq(irq, armpmu);
- }
}
release_pmu(armpmu-type);
+ pm_runtime_put_sync(armpmu-plat_device-dev);
We probably want to suspend the device before releasing it, otherwise we
could race against somebody else trying to initialise the PMU again.
static int
@@ -403,6 +400,8 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
return err;
}
+ pm_runtime_get_sync(armpmu-plat_device-dev);
Better pass pmu_device-dev instead (similarly in release).
+
plat = dev_get_platdata(pmu_device-dev);
if (plat plat-handle_irq)
handle_irq = armpmu_platform_irq;
@@ -440,8 +439,7 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
irq);
armpmu_release_hardware(armpmu);
return err;
- } else if (plat plat-enable_irq)
- plat-enable_irq(irq);
+ }
cpumask_set_cpu(i, armpmu-active_irqs);
}
@@ -584,6 +582,28 @@ static void armpmu_disable(struct pmu *pmu)
armpmu-stop();
}
There are potential failure paths in the reservation code here where we
don't `put' the PMU back. Can you move the pm_runtime_get_sync call later in
the function, or does it have to called before we enable the IRQ line?
+#ifdef CONFIG_PM_RUNTIME
+static int armpmu_runtime_resume(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_resume)
I think you need to check plat too since it may be NULL on other platforms.
+ return plat-runtime_resume(dev);
+
+ return 0;
+}
+
+static int armpmu_runtime_suspend(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_suspend)
Same here.
Will
--
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: [CFT 01/11] dmaengine: add OMAP DMA engine driver
On Fri, Jun 8, 2012 at 2:32 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jun 07, 2012 at 12:06:32PM +0100, Russell King wrote:
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/Kconfig | 6 +
drivers/dma/Makefile | 1 +
drivers/dma/omap-dma.c | 522
++
include/linux/omap-dma.h | 24 ++
4 files changed, 553 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/omap-dma.c
create mode 100644 include/linux/omap-dma.h
There is a bug in here which no one has spotted... I just noticed it.
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 500bc71..02eb2fd 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -130,14 +130,13 @@ static void omap_dma_callback(int ch, u16 status, void
*data)
spin_lock_irqsave(c-vc.lock, flags);
d = c-desc;
- if (!d)
- return;
-
- if (++c-sgidx d-sglen) {
- omap_dma_start_sg(c, d, c-sgidx);
- } else {
- omap_dma_start_desc(c);
- vchan_cookie_complete(d-vd);
+ if (d) {
+ if (++c-sgidx d-sglen) {
+ omap_dma_start_sg(c, d, c-sgidx);
+ } else {
+ omap_dma_start_desc(c);
+ vchan_cookie_complete(d-vd);
+ }
}
spin_unlock_irqrestore(c-vc.lock, flags);
}
You mean the lock release, right ?
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: [CFT 01/11] dmaengine: add OMAP DMA engine driver
On Fri, Jun 08, 2012 at 03:30:23PM +0530, Shilimkar, Santosh wrote:
On Fri, Jun 8, 2012 at 2:32 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jun 07, 2012 at 12:06:32PM +0100, Russell King wrote:
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/Kconfig | 6 +
drivers/dma/Makefile | 1 +
drivers/dma/omap-dma.c | 522
++
include/linux/omap-dma.h | 24 ++
4 files changed, 553 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/omap-dma.c
create mode 100644 include/linux/omap-dma.h
There is a bug in here which no one has spotted... I just noticed it.
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 500bc71..02eb2fd 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -130,14 +130,13 @@ static void omap_dma_callback(int ch, u16 status,
void *data)
spin_lock_irqsave(c-vc.lock, flags);
d = c-desc;
- if (!d)
- return;
-
- if (++c-sgidx d-sglen) {
- omap_dma_start_sg(c, d, c-sgidx);
- } else {
- omap_dma_start_desc(c);
- vchan_cookie_complete(d-vd);
+ if (d) {
+ if (++c-sgidx d-sglen) {
+ omap_dma_start_sg(c, d, c-sgidx);
+ } else {
+ omap_dma_start_desc(c);
+ vchan_cookie_complete(d-vd);
+ }
}
spin_unlock_irqrestore(c-vc.lock, flags);
}
You mean the lock release, right ?
Yes, if c-desc is NULL, we exit this function with the lock held,
which will lead to a lockup.
--
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
suspend broken on 3.5-rc1?
Hi, I don;t seem to be able to get suspend to work on 3.5-rc1 on my 4430 panda. I am not sure if its UART wakeups that are an issue or suspend itself is broken. Is there anything more than setting '/sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup' to 'enabled' that I need to do to get UART to be wakeup capable? 3.4 major works just fine for me. regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend broken on 3.5-rc1?
* Rajendra Nayak rna...@ti.com [120608 03:40]: Hi, I don;t seem to be able to get suspend to work on 3.5-rc1 on my 4430 panda. I am not sure if its UART wakeups that are an issue or suspend itself is broken. Is there anything more than setting '/sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup' to 'enabled' that I need to do to get UART to be wakeup capable? 3.4 major works just fine for me. Can you try with the fixes branch that Olof just merged? If it's the UART wake-up events, there's a patch that should help. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend broken on 3.5-rc1?
On Friday 08 June 2012 04:26 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120608 03:40]: Hi, I don;t seem to be able to get suspend to work on 3.5-rc1 on my 4430 panda. I am not sure if its UART wakeups that are an issue or suspend itself is broken. Is there anything more than setting '/sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup' to 'enabled' that I need to do to get UART to be wakeup capable? 3.4 major works just fine for me. Can you try with the fixes branch that Olof just merged? I tried merging the fixes branch on 3.5-rc1 as well as latest mainline and both didn't work. If it's the UART wake-up events, there's a patch that should help. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend broken on 3.5-rc1?
On Fri, 2012-06-08 at 17:55 +0530, Rajendra Nayak wrote: On Friday 08 June 2012 04:26 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120608 03:40]: Hi, I don;t seem to be able to get suspend to work on 3.5-rc1 on my 4430 panda. I am not sure if its UART wakeups that are an issue or suspend itself is broken. Is there anything more than setting '/sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup' to 'enabled' that I need to do to get UART to be wakeup capable? 3.4 major works just fine for me. Can you try with the fixes branch that Olof just merged? I tried merging the fixes branch on 3.5-rc1 as well as latest mainline and both didn't work. If it's the UART wake-up events, there's a patch that should help. Tony The patch referenced here helps: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69596.html DSS crashes during wakeup from suspend. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
On 6/8/2012 3:11 AM, Paul Walmsley wrote: On Thu, 7 Jun 2012, Cousson, Benoit wrote: Indeed, what I did not mention is that potentially the whole device init should be done ondemand as well. Meaning the whole hwmod setup phase should be done only when the driver will probe the device. That means if no driver exists for an IP block, or if the driver isn't using PM runtime, the IP block won't be reset. And somehow we still are missing drivers in mainline. We also still have drivers that aren't yet PM runtime converted. No the point is still the same as before. You let the drivers do the job if they are there, and then do a pass at very late time during the boot process to handle the ones that were not probed by any driver. At least you will avoid the enable - reset - idle - enable sequence we are doing right now for most of the active drivers when it is not necessary. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend broken on 3.5-rc1?
On Friday 08 June 2012 06:35 PM, Tero Kristo wrote: On Fri, 2012-06-08 at 17:55 +0530, Rajendra Nayak wrote: On Friday 08 June 2012 04:26 PM, Tony Lindgren wrote: * Rajendra Nayakrna...@ti.com [120608 03:40]: Hi, I don;t seem to be able to get suspend to work on 3.5-rc1 on my 4430 panda. I am not sure if its UART wakeups that are an issue or suspend itself is broken. Is there anything more than setting '/sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup' to 'enabled' that I need to do to get UART to be wakeup capable? 3.4 major works just fine for me. Can you try with the fixes branch that Olof just merged? I tried merging the fixes branch on 3.5-rc1 as well as latest mainline and both didn't work. If it's the UART wake-up events, there's a patch that should help. Tony The patch referenced here helps: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69596.html DSS crashes during wakeup from suspend. great, thats what I found too with no_console_suspend, didn't know a fix already exists. Thanks. [ 10.086334] Device name omapdss_dss [ 10.089996] Device name omapdss_dispc [ 10.093872] Device name omapdss_rfbi [ 10.097625] Device name omapdss_venc [ 10.101379] Device name omapdss_dsi.0 [ 10.105224] Device name omapdss_dsi.1 [ 10.109069] Device name omapdss_hdmi [ 10.112854] Device name omapdss_dpi [ 10.116516] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 10.125030] pgd = ee6ac000 [ 10.127868] [0018] *pgd=ae6c3831, *pte=, *ppte= [ 10.134490] Internal error: Oops: 17 [#1] SMP ARM [ 10.139434] Modules linked in: [ 10.142608] CPU: 0Not tainted (3.5.0-rc1-00143-ge8126d1-dirty #5) [ 10.149475] PC is at _od_resume_noirq+0x28/0x74 [ 10.154235] LR is at _od_resume_noirq+0x28/0x74 [ 10.158966] pc : [c003be7c]lr : [c003be7c]psr: 2113 [ 10.158966] sp : ee737e78 ip : c073fd80 fp : 0006 [ 10.171020] r10: ef1848b8 r9 : c0703010 r8 : c003be54 [ 10.176483] r7 : r6 : ef184800 r5 : r4 : ef184808 [ 10.183349] r3 : ef12d4c0 r2 : r1 : ef12d950 r0 : 0017 [ 10.190185] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 10.197662] Control: 10c53c7d Table: ae6ac04a DAC: 0015 [ 10.203674] Process sh (pid: 627, stack limit = 0xee7362f8) [ 10.209533] Stack: (0xee737e78 to 0xee738000) [ 10.214111] 7e60: ef184808 ef184808 [ 10.222686] 7e80: c02be138 c0702fb4 c0702fd4 ef184808 c0c69364 [ 10.231262] 7ea0: 0010 c0702fa8 c0703008 c02beccc 52d639d6 0002 52d639d6 0002 [ 10.239837] 7ec0: c06eb3f8 0010 0003 c0719f1c c06a8244 [ 10.248413] 7ee0: c02bf568 c072f9e8 c0080240 0003 c059933c 0004 [ 10.256988] 7f00: c04af304 ef041440 c0080584 ef38f000 0003 c059933c c007f788 [ 10.265563] 7f20: ef2dc8c0 ef2dc8d8 ee737f80 ef097e00 c0264728 c0264740 0004 c016aa44 [ 10.274139] 7f40: ef0d4cc0 0004 b6f05000 ee737f80 c01096f4 [ 10.282714] 7f60: c0014400 ef12d4c0 ef0d4cc0 b6f05000 0004 0004 c0109848 [ 10.291290] 7f80: b6e325e8 0004 b6f05000 b6e325e8 c00144a8 [ 10.299865] 7fa0: ee736000 c00142e0 0004 b6f05000 0001 b6f05000 0004 [ 10.308441] 7fc0: 0004 b6f05000 b6e325e8 0004 0004 0964 000a [ 10.317016] 7fe0: b6f05000 beecb5d0 b6d70c70 b6dc0abc 6110 0001 af6fe821 af6fec21 [ 10.325622] [c003be7c] (_od_resume_noirq+0x28/0x74) from [c02be138] (dpm_run_callback+0x2c/0x74) [ 10.335205] [c02be138] (dpm_run_callback+0x2c/0x74) from [c02beccc] (dpm_resume_noirq+0xdc/0x2f4) [ 10.344879] [c02beccc] (dpm_resume_noirq+0xdc/0x2f4) from [c02bf568] (dpm_resume_start+0xc/0x18) [ 10.354461] [c02bf568] (dpm_resume_start+0xc/0x18) from [c0080240] (suspend_devices_and_enter+0x114/0x2d8) [ 10.364959] [c0080240] (suspend_devices_and_enter+0x114/0x2d8) from [c0080584] (pm_suspend+0x180/0x1fc) [ 10.375183] [c0080584] (pm_suspend+0x180/0x1fc) from [c007f788] (state_store+0x90/0x124) [ 10.384063] [c007f788] (state_store+0x90/0x124) from [c0264740] (kobj_attr_store+0x18/0x1c) [ 10.393188] [c0264740] (kobj_attr_store+0x18/0x1c) from [c016aa44] (sysfs_write_file+0xfc/0x180) [ 10.402770] [c016aa44] (sysfs_write_file+0xfc/0x180) from [c01096f4] (vfs_write+0xb0/0x134) [ 10.411895] [c01096f4] (vfs_write+0xb0/0x134) from [c0109848] (sys_write+0x40/0x70) [ 10.420318] [c0109848] (sys_write+0x40/0x70) from [c00142e0] (ret_fast_syscall+0x0/0x3c) [ 10.429168] Code: e1a04000 05901008 e59f0048 eb112432 (e5d53018) [ 10.435607] ---[ end trace 0cf97fb0a3cafe35 ]--- -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH 05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hi Paul,
There's a bug in this patch, see below.
clip
{
@@ -1141,8 +1143,26 @@ static void _enable_sysc(struct omap_hwmod *oh)
sf = oh-class-sysc-sysc_flags;
if (sf SYSC_HAS_SIDLEMODE) {
- idlemode = (oh-flags HWMOD_SWSUP_SIDLE) ?
- HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ if (oh-flags HWMOD_SWSUP_SIDLE) {
+ /*
+ * IP blocks without smart idle should be left
+ * in force-idle. Currently this only applies
+ * to 32k sync timer which is guaranteed to
+ * be accessible when the kernel is running.
+ * HWMOD_SWSUP_IDLE must also be set on these
+ * IP blocks to indicate a hardware problem.
+ * XXX Not an ideal workaround.
+ */
+ if (oh-class-sysc-idlemodes
+ (SIDLE_NO | SIDLE_FORCE)
+ !(oh-class-sysc-idlemodes
+ (SIDLE_SMART || SIDLE_SMART_WKUP)))
There should by binary or, not logical here.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
On Fri, 8 Jun 2012, Cousson, Benoit wrote: On 6/8/2012 3:11 AM, Paul Walmsley wrote: On Thu, 7 Jun 2012, Cousson, Benoit wrote: Indeed, what I did not mention is that potentially the whole device init should be done ondemand as well. Meaning the whole hwmod setup phase should be done only when the driver will probe the device. That means if no driver exists for an IP block, or if the driver isn't using PM runtime, the IP block won't be reset. And somehow we still are missing drivers in mainline. We also still have drivers that aren't yet PM runtime converted. No the point is still the same as before. You let the drivers do the job if they are there, and then do a pass at very late time during the boot process to handle the ones that were not probed by any driver. Ah, I see what you mean. Above you wrote that the the hwmod setup phase would be done only when the driver will probe the device. But you also mean that it should also be done for the remaining devices before starting userspace. At least you will avoid the enable - reset - idle - enable sequence we are doing right now for most of the active drivers when it is not necessary. It must not be widely known, but early reset was implemented intentionally. The goal was to keep any configuration damage from out-of-date or broken bootloaders or previous OSes to a minimum length of time during the boot process. I don't really have a huge problem with switching to a late reset, but there are disadvantages to it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc
Hi Paul,
Tested this set on top of v3.5-rc1 with omap3 / omap4 suspend + my omap4
core retention / dev-off patches. There are a couple of minor issues,
like the bug in patch 5, and the fact that counter_32k hwmod data is
broken for omap4. This fix is needed on omap4 to fix the counter_32k, if
this is not done, device off does not work:
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 66da92d..6ad64c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -397,8 +397,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_counter_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0004,
.sysc_flags = SYSC_HAS_SIDLEMODE,
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- SIDLE_SMART_WKUP),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
.sysc_fields= omap_hwmod_sysc_type1,
};
-Tero
--
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/7] arm/dts: omap4: Add entry for OMAP McPDM IP
McPDM is used on OMAP4 based boards to communicate with an external audio
codec (twl6040).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..4c43f3b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,14 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ mcpdm: mcpdm@40132000 {
+ compatible = ti,omap4-mcpdm;
+ reg = 0x40132000 0x7f, /* MPU private access */
+ 0x49032000 0x7f; /* L3 Interconnect */
+ interrupts = 0 112 0x4;
+ interrupt-parent = gic;
+ ti,hwmods = mcpdm;
+ };
};
};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] arm/dts: omap4: Add entry for OMAP DMIC IP
DMIC IP is used to connect up to 6 digital microphones directly to OMAP.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c43f3b..fb0287d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -281,5 +281,14 @@
interrupt-parent = gic;
ti,hwmods = mcpdm;
};
+
+ dmic: dmic@4012e000 {
+ compatible = ti,omap4-dmic;
+ reg = 0x4012e000 0x7f, /* MPU private access */
+ 0x4902e000 0x7f; /* L3 Interconnect */
+ interrupts = 0 114 0x4;
+ interrupt-parent = gic;
+ ti,hwmods = dmic;
+ };
};
};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] arm/dts: omap4-sdp: Enable audio support via device tree
On OMAP4 SDP the audio setup includes the twl6040 codec and digital
microphones.
Since OMAP4 SDP is a reference board it has all possible audio interfaces
connected. This information is passed via the ti,audio-routing
property.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index f09d1f5..964f8ec 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -88,6 +88,41 @@
gpios = gpio5 11 0; /* 139 */
};
};
+
+ sound {
+ compatible = ti,abe-twl6040;
+ ti,model = SDP4430;
+
+ ti,jack-detection = 1;
+ ti,mclk-freq = 3840;
+
+ ti,mcpdm = mcpdm;
+ ti,dmic = dmic;
+
+ ti,twl6040 = twl6040;
+
+ /* Audio routing */
+ ti,audio-routing =
+ Headset Stereophone, HSOL,
+ Headset Stereophone, HSOR,
+ Earphone Spk, EP,
+ Ext Spk, HFL,
+ Ext Spk, HFR,
+ Line Out, AUXL,
+ Line Out, AUXR,
+ Vibrator, VIBRAL,
+ Vibrator, VIBRAR,
+ HSMIC, Headset Mic,
+ Headset Mic, Headset Mic Bias,
+ MAINMIC, Main Handset Mic,
+ Main Handset Mic, Main Mic Bias,
+ SUBMIC, Sub Handset Mic,
+ Sub Handset Mic, Main Mic Bias,
+ AFML, Line In,
+ AFMR, Line In,
+ DMic, Digital Mic,
+ Digital Mic, Digital Mic1 Bias;
+ };
};
i2c1 {
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] arm/dts: omap4-sdp: Add fixed regulator to represent VBAT
There are devices connected to VBAT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index e55d42a..4b51611 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -38,6 +38,14 @@
regulator-boot-on;
};
+ vbat: fixedregulator@2 {
+ compatible = regulator-fixed;
+ regulator-name = VBAT;
+ regulator-min-microvolt = 375;
+ regulator-max-microvolt = 375;
+ regulator-boot-on;
+ };
+
leds {
compatible = gpio-leds;
debug0 {
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] arm/dts: omap4-sdp: Add support for twl6040
The twl6040 provides the audio and vibra support on OMAP4 SDP boards.
It is connected to i2c1 bus with 0x4b address.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 4b51611..f09d1f5 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -99,6 +99,31 @@
interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
interrupt-parent = gic;
};
+
+ twl6040: twl@4b {
+ compatible = ti,twl6040;
+ reg = 0x4b;
+ /* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
+ interrupts = 0 119 4; /* IRQ_SYS_2N cascaded to gic */
+ interrupt-parent = gic;
+ ti,audpwron-gpio = gpio4 31 0; /* gpio line 127 */
+
+ vio-supply = v1v8;
+ v2v1-supply = v2v1;
+ enable-active-high;
+
+ /* regulators for vibra motor */
+ vddvibl-supply = vbat;
+ vddvibr-supply = vbat;
+
+ vibra {
+ /* Vibra driver, motor resistance parameters */
+ ti,vibldrv-res = 8;
+ ti,vibrdrv-res = 3;
+ ti,viblmotor-res = 10;
+ ti,vibrmotor-res = 10;
+ };
+ };
};
/include/ twl6030.dtsi
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] arm/dts: omap4-panda: Audio support for PandaBoard 4430
PandaBoard uses twl6040 connected via McPDM for audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..f57f5e8 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -32,6 +32,30 @@
linux,default-trigger = mmc0;
};
};
+
+ sound: sound {
+ compatible = ti,abe-twl6040;
+ ti,model = PandaBoard;
+
+ ti,mclk-freq = 3840;
+
+ ti,mcpdm = mcpdm;
+
+ ti,twl6040 = twl6040;
+
+ /* Audio routing */
+ ti,audio-routing =
+ Headset Stereophone, HSOL,
+ Headset Stereophone, HSOR,
+ Ext Spk, HFL,
+ Ext Spk, HFR,
+ Line Out, AUXL,
+ Line Out, AUXR,
+ HSMIC, Headset Mic,
+ Headset Mic, Headset Mic Bias,
+ AFML, Line In,
+ AFMR, Line In;
+ };
};
i2c1 {
@@ -43,6 +67,19 @@
interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
interrupt-parent = gic;
};
+
+ twl6040: twl@4b {
+ compatible = ti,twl6040;
+ reg = 0x4b;
+ /* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
+ interrupts = 0 119 4; /* IRQ_SYS_2N cascaded to gic */
+ interrupt-parent = gic;
+ ti,audpwron-gpio = gpio4 31 0; /* gpio line 127 */
+
+ vio-supply = v1v8;
+ v2v1-supply = v2v1;
+ enable-active-high;
+ };
};
/include/ twl6030.dtsi
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] arm/dts: New dts file for PandaBoardES (4460)
The 4430 and 4460 version of PandaBoard mostly the same with
exception at least in audio setup.
Use the omap4-panda.dts file as a base and only override the differences
between the revisions.
For audio it is the name of the sound card and the routing information.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-pandaES.dts | 24
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-pandaES.dts
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts
b/arch/arm/boot/dts/omap4-pandaES.dts
new file mode 100644
index 000..d4ba43a
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-pandaES.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ omap4-panda.dts
+
+/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
+sound {
+ ti,model = PandaBoardES;
+
+ /* Audio routing */
+ ti,audio-routing =
+ Headset Stereophone, HSOL,
+ Headset Stereophone, HSOR,
+ Ext Spk, HFL,
+ Ext Spk, HFR,
+ Line Out, AUXL,
+ Line Out, AUXR,
+ AFML, Line In,
+ AFMR, Line In;
+};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] arm/dts: Audio support for OMAP4 devices (SDP, PandaBoard)
Hello, The following series enable the audio functionality on OMAP4 based devices using twl6040 as audio codec. The series adds the needed bindings in the dts for the OMAP IPs, twl6040 MFD device and for the audio connection on the board. To be able to differentiate between PandaBoard and PandaBoardES (they have a bit different audio configuration) a new dts file has been created which only changes the audio properties different between the two boards. Patches for the drivers involved and the documentation related to dts sections has been either in 3.5 or heading for 3.6. Regards, Peter --- Peter Ujfalusi (7): arm/dts: omap4: Add entry for OMAP McPDM IP arm/dts: omap4: Add entry for OMAP DMIC IP arm/dts: omap4-sdp: Add fixed regulator to represent VBAT arm/dts: omap4-sdp: Add support for twl6040 arm/dts: omap4-sdp: Enable audio support via device tree arm/dts: omap4-panda: Audio support for PandaBoard 4430 arm/dts: New dts file for PandaBoardES (4460) arch/arm/boot/dts/omap4-panda.dts | 37 +++ arch/arm/boot/dts/omap4-pandaES.dts | 24 arch/arm/boot/dts/omap4-sdp.dts | 68 +++ arch/arm/boot/dts/omap4.dtsi| 18 + 4 files changed, 147 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-pandaES.dts -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap: drop unused IRQ defines
twl[46]030 have been converted to sparse IRQ
already, so we can remove the unused defines
and drop some code from board-files.
compile tested with omap2plus_defconfig.
Signed-off-by: Felipe Balbi ba...@ti.com
---
patch mostly generated with:
$ sed -i '/.irq_\(base\|end\).*TWL4030_\(GPIO_\|\)IRQ_\(BASE\|END\),/d'
arch/arm/mach-omap2/*.c
When building omap2plus_defconfig, found a few section
mismatches:
drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words':
include/linux/mtd/map.h:331:11: warning: 'r$x$0' may be used uninitialized in
this function
WARNING: drivers/mmc/host/built-in.o(.devinit.text+0x2fc): Section mismatch in
reference from the function mmc_omap_probe() to the function
.init.text:mmc_omap_new_slot()
The function __devinit mmc_omap_probe() references
a function __init mmc_omap_new_slot().
If mmc_omap_new_slot is only used by mmc_omap_probe then
annotate mmc_omap_new_slot with a matching annotation.
WARNING: drivers/mmc/built-in.o(.devinit.text+0x2fc): Section mismatch in
reference from the function mmc_omap_probe() to the function
.init.text:mmc_omap_new_slot()
The function __devinit mmc_omap_probe() references
a function __init mmc_omap_new_slot().
If mmc_omap_new_slot is only used by mmc_omap_probe then
annotate mmc_omap_new_slot with a matching annotation.
fs/ubifs/dir.c: In function 'ubifs_rename':
fs/ubifs/dir.c:972:15: warning: 'saved_nlink' may be used uninitialized in this
function
net/mac80211/mlme.c: In function 'ieee80211_prep_connection':
net/mac80211/mlme.c:3017:19: warning: 'sta' may be used uninitialized in this
function
WARNING: drivers/built-in.o(.devinit.text+0x73d4): Section mismatch in
reference from the function mmc_omap_probe() to the function
.init.text:mmc_omap_new_slot()
The function __devinit mmc_omap_probe() references
a function __init mmc_omap_new_slot().
If mmc_omap_new_slot is only used by mmc_omap_probe then
annotate mmc_omap_new_slot with a matching annotation.
WARNING: vmlinux.o(.devinit.text+0x7f08): Section mismatch in reference from
the function mmc_omap_probe() to the function .init.text:mmc_omap_new_slot()
The function __devinit mmc_omap_probe() references
a function __init mmc_omap_new_slot().
If mmc_omap_new_slot is only used by mmc_omap_probe then
annotate mmc_omap_new_slot with a matching annotation.
not sure if they were already fixed.
arch/arm/mach-omap2/board-2430sdp.c |4 ---
arch/arm/mach-omap2/board-3430sdp.c |2 --
arch/arm/mach-omap2/board-cm-t35.c |2 --
arch/arm/mach-omap2/board-devkit8000.c |2 --
arch/arm/mach-omap2/board-igep0020.c |2 --
arch/arm/mach-omap2/board-ldp.c |2 --
arch/arm/mach-omap2/board-omap3beagle.c |2 --
arch/arm/mach-omap2/board-omap3evm.c |2 --
arch/arm/mach-omap2/board-omap3logic.c |4 ---
arch/arm/mach-omap2/board-omap3pandora.c |2 --
arch/arm/mach-omap2/board-omap3stalker.c |2 --
arch/arm/mach-omap2/board-omap3touchbook.c |2 --
arch/arm/mach-omap2/board-overo.c|2 --
arch/arm/mach-omap2/board-rm680.c|2 --
arch/arm/mach-omap2/board-rx51-peripherals.c |2 --
arch/arm/mach-omap2/board-zoom-peripherals.c |2 --
arch/arm/mach-omap2/twl-common.c |9 --
arch/arm/plat-omap/include/plat/irqs.h | 41 ++
include/linux/i2c/twl.h |2 --
19 files changed, 2 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 99ca6ba..dcb6475 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -213,13 +213,9 @@ static struct regulator_init_data sdp2430_vmmc1 = {
static struct twl4030_gpio_platform_data sdp2430_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
- .irq_base = TWL4030_GPIO_IRQ_BASE,
- .irq_end= TWL4030_GPIO_IRQ_END,
};
static struct twl4030_platform_data sdp2430_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
.gpio = sdp2430_gpio_data,
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index a98c688..a91abfa 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -234,8 +234,6 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
- .irq_base = TWL4030_GPIO_IRQ_BASE,
- .irq_end= TWL4030_GPIO_IRQ_END,
.pulldowns = BIT(2) | BIT(6) | BIT(8) | BIT(13)
| BIT(16) | BIT(17),
.setup = sdp3430_twl_gpio_setup,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
Hi Will,
On 06/08/2012 04:47 AM, Will Deacon wrote:
Hi Jon,
On Thu, Jun 07, 2012 at 10:22:03PM +0100, Jon Hunter wrote:
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 186c8cb..00adb98 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#include asm/cputype.h
#include asm/irq.h
@@ -367,8 +368,6 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
{
int i, irq, irqs;
struct platform_device *pmu_device = armpmu-plat_device;
-struct arm_pmu_platdata *plat =
-dev_get_platdata(pmu_device-dev);
irqs = min(pmu_device-num_resources, num_possible_cpus());
@@ -376,14 +375,12 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
if (!cpumask_test_and_clear_cpu(i, armpmu-active_irqs))
continue;
irq = platform_get_irq(pmu_device, i);
-if (irq = 0) {
-if (plat plat-disable_irq)
-plat-disable_irq(irq);
+if (irq = 0)
free_irq(irq, armpmu);
-}
}
release_pmu(armpmu-type);
+pm_runtime_put_sync(armpmu-plat_device-dev);
We probably want to suspend the device before releasing it, otherwise we
could race against somebody else trying to initialise the PMU again.
Good point, will change that.
static int
@@ -403,6 +400,8 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
return err;
}
+pm_runtime_get_sync(armpmu-plat_device-dev);
Better pass pmu_device-dev instead (similarly in release).
Ok.
+
plat = dev_get_platdata(pmu_device-dev);
if (plat plat-handle_irq)
handle_irq = armpmu_platform_irq;
@@ -440,8 +439,7 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
irq);
armpmu_release_hardware(armpmu);
return err;
-} else if (plat plat-enable_irq)
-plat-enable_irq(irq);
+}
cpumask_set_cpu(i, armpmu-active_irqs);
}
@@ -584,6 +582,28 @@ static void armpmu_disable(struct pmu *pmu)
armpmu-stop();
}
There are potential failure paths in the reservation code here where we
don't `put' the PMU back. Can you move the pm_runtime_get_sync call later in
the function, or does it have to called before we enable the IRQ line?
Yes we can move that. It does not need to be before we enable the IRQ line.
+#ifdef CONFIG_PM_RUNTIME
+static int armpmu_runtime_resume(struct device *dev)
+{
+struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+if (plat-runtime_resume)
I think you need to check plat too since it may be NULL on other platforms.
Ah, good point. I will add that.
+return plat-runtime_resume(dev);
+
+return 0;
+}
+
+static int armpmu_runtime_suspend(struct device *dev)
+{
+struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+if (plat-runtime_suspend)
Same here.
Ok, yes. Thanks for the feedback!
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
On Fri, 8 Jun 2012, Rajendra Nayak wrote:
This patch only gets rid of clkdm assocation from *non gate* clocks.
And what I am trying to say is that, this information in not
used at all (for non gate clocks) in any of the frameworks today
including clock framework.
So why should getting rid of some *unused* data have any testing
overhead?
Your definition of 'unused' seems to be different than mine:
$ egrep -rn 'c(lk|)-clkdm' arch/arm/
arch/arm/mach-omap2/omap_hwmod.c:560: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:563: return
clkdm_add_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
arch/arm/mach-omap2/omap_hwmod.c:584: if (oh-_clk-clkdm
oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
arch/arm/mach-omap2/omap_hwmod.c:587: return
clkdm_del_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
arch/arm/mach-omap2/omap_hwmod.c:612: if (!oh-_clk-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:2998: if (!c-clkdm)
arch/arm/mach-omap2/omap_hwmod.c:3001: return c-clkdm-pwrdm.ptr;
arch/arm/mach-omap2/clock.c:96: if (!clk-clkdm_name)
arch/arm/mach-omap2/clock.c:99: clkdm = clkdm_lookup(clk-clkdm_name);
arch/arm/mach-omap2/clock.c:102: clk-name,
clk-clkdm_name);
arch/arm/mach-omap2/clock.c:103:clk-clkdm = clkdm;
arch/arm/mach-omap2/clock.c:106: clkdm %s\n,
clk-name, clk-clkdm_name);
arch/arm/mach-omap2/clock.c:292:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:293:clkdm_clk_disable(clk-clkdm,
clk);
arch/arm/mach-omap2/clock.c:332:if (clkdm_control clk-clkdm) {
arch/arm/mach-omap2/clock.c:333:ret =
clkdm_clk_enable(clk-clkdm, clk);
arch/arm/mach-omap2/clock.c:336: %d\n, clk-name,
clk-clkdm-name, ret);
arch/arm/mach-omap2/clock.c:354:if (clkdm_control clk-clkdm)
arch/arm/mach-omap2/clock.c:355:clkdm_clk_disable(clk-clkdm,
clk);
arch/arm/mach-omap2/clock.c:441:if (clk-clkdm != NULL)
arch/arm/mach-omap2/clock.c:442:
pwrdm_state_switch(clk-clkdm-pwrdm.ptr);
That is just the result of a casual grep, not even a code analysis.
Removing this data is not like removing some macros where one can get a
compiler error if they turn out to be needed. Problems with this ares
only likely to show up at runtime.
By the way, I hope you're testing the patches that you send to the lists,
at the very least to the minimal PM testing that I do that is documented
e.g. here:
http://www.pwsan.com/omap/bootlogs/20120508/prcm_devel_a_3.5__0135f6a04642c192bdf4b36e06937d3387e174ff/
Otherwise the testing burden is just getting pushed to other people who
already have too much to do.
...
So to repeat myself on this:
1. The patch that removes some of the struct clk clkdm_name strings should
be part of or otherwise grouped with the CCF conversion patch series
2. The CCF conversion patch series needs to be fully PM-tested
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
Hi Will,
On 06/08/2012 04:47 AM, Will Deacon wrote:
Hi Jon,
On Thu, Jun 07, 2012 at 10:22:03PM +0100, Jon Hunter wrote:
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 186c8cb..00adb98 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#include asm/cputype.h
#include asm/irq.h
@@ -367,8 +368,6 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
{
int i, irq, irqs;
struct platform_device *pmu_device = armpmu-plat_device;
-struct arm_pmu_platdata *plat =
-dev_get_platdata(pmu_device-dev);
irqs = min(pmu_device-num_resources, num_possible_cpus());
@@ -376,14 +375,12 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
if (!cpumask_test_and_clear_cpu(i, armpmu-active_irqs))
continue;
irq = platform_get_irq(pmu_device, i);
-if (irq = 0) {
-if (plat plat-disable_irq)
-plat-disable_irq(irq);
+if (irq = 0)
free_irq(irq, armpmu);
-}
}
release_pmu(armpmu-type);
+pm_runtime_put_sync(armpmu-plat_device-dev);
We probably want to suspend the device before releasing it, otherwise we
could race against somebody else trying to initialise the PMU again.
static int
@@ -403,6 +400,8 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
return err;
}
+pm_runtime_get_sync(armpmu-plat_device-dev);
Better pass pmu_device-dev instead (similarly in release).
+
plat = dev_get_platdata(pmu_device-dev);
if (plat plat-handle_irq)
handle_irq = armpmu_platform_irq;
@@ -440,8 +439,7 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
irq);
armpmu_release_hardware(armpmu);
return err;
-} else if (plat plat-enable_irq)
-plat-enable_irq(irq);
+}
cpumask_set_cpu(i, armpmu-active_irqs);
}
@@ -584,6 +582,28 @@ static void armpmu_disable(struct pmu *pmu)
armpmu-stop();
}
There are potential failure paths in the reservation code here where we
don't `put' the PMU back. Can you move the pm_runtime_get_sync call later in
the function, or does it have to called before we enable the IRQ line?
+#ifdef CONFIG_PM_RUNTIME
+static int armpmu_runtime_resume(struct device *dev)
+{
+struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+if (plat-runtime_resume)
I think you need to check plat too since it may be NULL on other platforms.
+return plat-runtime_resume(dev);
+
+return 0;
+}
+
+static int armpmu_runtime_suspend(struct device *dev)
+{
+struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+if (plat-runtime_suspend)
Same here.
Here is an updated version. I was going to send out a V3, but I wanted
to wait to see if others had more comments first.
Cheers
Jon
From c53dcbe091928d293f14e890c2b38be57692ccca Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Thu, 31 May 2012 13:05:20 -0500
Subject: [PATCH] ARM: PMU: Add runtime PM Support
Add runtime PM support to the ARM PMU driver so that devices such as OMAP
supporting dynamic PM can use the platform-runtime_* hooks to initialise
hardware at runtime. Without having these runtime PM hooks in place any
configuration of the PMU hardware would be lost when low power states are
entered and hence would prevent PMU from working.
This change also replaces the PMU platform functions enable_irq and disable_irq
added by Ming Lei with runtime_resume and runtime_suspend funtions. Ming had
added the enable_irq and disable_irq functions as a method to configure the
cross trigger interface on OMAP4 for routing the PMU interrupts. By adding
runtime PM support, we can move the code called by enable_irq and disable_irq
into the runtime PM callbacks runtime_resume and runtime_suspend.
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/include/asm/pmu.h | 20
arch/arm/kernel/perf_event.c | 41 +
2 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 90114fa..77b023b 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -31,18 +31,22 @@ enum arm_pmu_type {
* interrupt and passed the address of the low level handler,
* and can be used to implement any platform specific handling
* before or after calling it.
- * @enable_irq: an optional
Re: [CFT 11/11] Add feature removal of old OMAP private DMA implementation
On 06/07/2012 06:09 AM, Russell King wrote: Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/feature-removal-schedule.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 56000b3..1f7ba35 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -612,3 +612,14 @@ When:June 2013 Why: Unsupported/unmaintained/unused since 2.6 + +What:OMAP private DMA implementation +When:2013 +Why: We have a DMA engine implementation; all users should be updated + to use this rather than persisting with the old APIs. The old APIs + block merging the old DMA engine implementation into the DMA + engine driver. +Who: Russell King li...@arm.linux.org.uk, + Santosh Shilimkar santosh.shilim...@ti.com + + Whose tree do feature-removal-schedule patches go in through? (They're not really documentation, they're design coordination/logistics.) Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. -- 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 1/2] of: Add generic device tree DMA helpers
Hi Stephen, Arnd, Been a while ;-) On 05/21/2012 03:32 PM, Stephen Warren wrote: On 05/21/2012 12:18 PM, Arnd Bergmann wrote: On Monday 21 May 2012, Stephen Warren wrote: The point with the direction was that it covers most cases and makes them rather simple, while for the rare case where you need more than two channels, you just use the otherwise optional named interface rather than the numbered one. My feeling is that this also makes a lot of sense at the driver API level: most dirvers just ask for the read and write channels using a very simple interface, and those drivers that have more than two will want to name them anyway. How are you thinking of representing the direction in DT - as part of the DMA request specifier, so in a DMAC-specific way? If so, that seems a little odd; you have to request a DMA channel for TX, but then end up having the common code check all the entries in the dmas property since it can't know which are TX, and then have the wrong ones almost accidentally fail, since the DMAC will then determine that it can't support TX on the RX DMA request IDs. I think the direction must be encoded in a way that does not depend on the binding for the specific controller. There are two ways I can see how we might do it: 1. have separate property names for tx and rx channels, and probably one for combined rx/tx channels 2. define the second cell in each channel specifier to be the direction in a predefined format, followed by the other (controller specific) attributes, if any. In this option, lets say bit 0 is 0==TX, 1==RX (or perhaps 2 bits if combined TX/RX is needed) Then, we could reserve say bits 7:1 as client DMA request ID. And then have bits 31:8 as DMAC specific data. Wouldn't that allow us to have our cake and eat it? Sorry for not responding sooner. It seems to me we were pretty close on alignment. In fact, I was quite happy with Steven's 2nd to last proposal of ... simple 1 req: dmas = 0 dmac1 xxx; simple 2 req: dmas = 0 dmac1 xxx 1 dmac1 yyy; multiple dmacs: dmas = 0 dmac1 xxx 0 dmac2 zzz 1 dmac1 yyy; Arnd, I know that you had some concerns. However, in the above case I would expect that the 3rd parameter be optional and it can be some sort of match variable. In other words, we don't care how the 32-bits are encoded or what they represent but they would be used appropriately by the xlate function being used. So the xlate and this match variable would have to speak the same language. I think that I prefer the idea of having a 3rd optional match variable than encoding the DMA request ID and match data together in 1 32-bit variable. However, not a big deal either way. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On Fri, Jun 08, 2012 at 01:33:46, Paul Walmsley wrote: Hi On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote: I couldn't finish my testing today, got into continuous meetings. No worries, I understand. Tomorrow, I will test it and update you on this. That would be great. I took a look at SPRUH73F and sure enough, at least one module (CONTROL) doesn't support smart-idle -- per Table 14-217 CONTROL Register Field Descriptions. I'd guess that the PRCM won't idle-req this IP block until the kernel is not running, so we might be able to get away with the existing approach; but the TRM also says: By definition, initiator may generate read/write transaction as long as it is out of IDLE state. Which pretty much matches my understanding too of the implicit interface contract here. So I think we'd better go back to the flag approach as implemented in this patch: http://www.spinics.net/lists/arm-kernel/msg176836.html The WBU 32k sync timer's behavior is what relies on quirks of the integration that are hard to identify via other means, so it seems to be safest to tag it explicitly. Paul, I tested it on AM335x platform just now, it booted up to the Linux prompt, but I am sure it is going to impact low power state usecases on AM33xx. So, I also feel that, flag based approach should be used here. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
On Fri, Jun 08, 2012 at 18:58:51, Paul Walmsley wrote: On Fri, 8 Jun 2012, Cousson, Benoit wrote: On 6/8/2012 3:11 AM, Paul Walmsley wrote: On Thu, 7 Jun 2012, Cousson, Benoit wrote: Indeed, what I did not mention is that potentially the whole device init should be done ondemand as well. Meaning the whole hwmod setup phase should be done only when the driver will probe the device. That means if no driver exists for an IP block, or if the driver isn't using PM runtime, the IP block won't be reset. And somehow we still are missing drivers in mainline. We also still have drivers that aren't yet PM runtime converted. No the point is still the same as before. You let the drivers do the job if they are there, and then do a pass at very late time during the boot process to handle the ones that were not probed by any driver. Ah, I see what you mean. Above you wrote that the the hwmod setup phase would be done only when the driver will probe the device. But you also mean that it should also be done for the remaining devices before starting userspace. At least you will avoid the enable - reset - idle - enable sequence we are doing right now for most of the active drivers when it is not necessary. It must not be widely known, but early reset was implemented intentionally. The goal was to keep any configuration damage from out-of-date or broken bootloaders or previous OSes to a minimum length of time during the boot process. I don't really have a huge problem with switching to a late reset, but there are disadvantages to it. I was reading all these discussion and was holding myself back, so that I digest before adding another flavor to this discussion, In case of AM33xx, recently I came across similar issue (rather more than this) with CPSW module. The issue is, We have observed that, in order to disable the CPSW module (MODULEMODE=0x0), We have to assert OCP level reset, before disabling it; else module enters into unknown state, where register status shows, MODULEMODE turns 0x0, but idlests says module is busy. This has to be done everytime you try to disable the module. The worst part here is, CPSW has 4 submodules (SS, SL1, SL2, CPDMA), We have to assert reset signal to each submodules. So the approach I had taken is, I had implemented almost similar function specific to cpsw and introduced flag called HWMOD_SWSUP_RESET_BEFORE_IDLE. Now the question here would be, should we consider this IP bug or integration bug? If it is integration bug, then isn't this device issue? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AM335x CPSW reset (was RE: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb))
Hi On Fri, 8 Jun 2012, Hiremath, Vaibhav wrote: In case of AM33xx, recently I came across similar issue (rather more than this) with CPSW module. The issue is, We have observed that, in order to disable the CPSW module (MODULEMODE=0x0), We have to assert OCP level reset, before disabling it; else module enters into unknown state, where register status shows, MODULEMODE turns 0x0, but idlests says module is busy. This has to be done everytime you try to disable the module. The worst part here is, CPSW has 4 submodules (SS, SL1, SL2, CPDMA), We have to assert reset signal to each submodules. So the approach I had taken is, I had implemented almost similar function specific to cpsw and introduced flag called HWMOD_SWSUP_RESET_BEFORE_IDLE. Why SWSUP ? Now the question here would be, should we consider this IP bug or integration bug? If it is integration bug, then isn't this device issue? I don't know if it's a bug in either place, but it sounds like something that needs to be handled in the _am335x_disable_module() code in mach-omap2/omap_hwmod.c. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On Fri, 8 Jun 2012, Tero Kristo wrote: There's a bug in this patch, see below. ... There should by binary or, not logical here. Thanks for reporting this, I've added some credit in the patch description. This has been fixed by switching back to using a flag-based approach based on some comments from Vaibhav Hiremath. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Friday 08 June 2012, Jon Hunter wrote: On 05/21/2012 03:32 PM, Stephen Warren wrote: On 05/21/2012 12:18 PM, Arnd Bergmann wrote: On Monday 21 May 2012, Stephen Warren wrote: If so, that seems a little odd; you have to request a DMA channel for TX, but then end up having the common code check all the entries in the dmas property since it can't know which are TX, and then have the wrong ones almost accidentally fail, since the DMAC will then determine that it can't support TX on the RX DMA request IDs. I think the direction must be encoded in a way that does not depend on the binding for the specific controller. There are two ways I can see how we might do it: 1. have separate property names for tx and rx channels, and probably one for combined rx/tx channels 2. define the second cell in each channel specifier to be the direction in a predefined format, followed by the other (controller specific) attributes, if any. In this option, lets say bit 0 is 0==TX, 1==RX (or perhaps 2 bits if combined TX/RX is needed) Then, we could reserve say bits 7:1 as client DMA request ID. And then have bits 31:8 as DMAC specific data. Wouldn't that allow us to have our cake and eat it? Sorry for not responding sooner. It seems to me we were pretty close on alignment. In fact, I was quite happy with Steven's 2nd to last proposal of ... simple 1 req: dmas = 0 dmac1 xxx; simple 2 req: dmas = 0 dmac1 xxx 1 dmac1 yyy; multiple dmacs: dmas = 0 dmac1 xxx 0 dmac2 zzz 1 dmac1 yyy; Arnd, I know that you had some concerns. However, in the above case I would expect that the 3rd parameter be optional and it can be some sort of match variable. In other words, we don't care how the 32-bits are encoded or what they represent but they would be used appropriately by the xlate function being used. So the xlate and this match variable would have to speak the same language. I would at least put the dmac part first to be consistent with other bindings that refer to some node. That controller should then be able to specify the number of additional cells used to describe the dma request. We can define that the first cell after the controller phandle is always the same thing, e.g. the direction (in/out/inout) or a client-specific ID or a combination of that with other predefined bits that are not dependent on dma controller specifics. As I said previously, I think just encoding the direction but not the client specific ID (meaning we would have to disambiguate the more complex cases that Stephen mentioned using a dma-names property) would be the best because it keeps the common case simple, but I could live with other things going in there too. I think that I prefer the idea of having a 3rd optional match variable than encoding the DMA request ID and match data together in 1 32-bit variable. However, not a big deal either way. I agree on that part, I would usually prefer to encode different things in separate cells rather than putting them together into a single cell just because they require less than 32 bits combined. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc
Hi Tero,
On Fri, 8 Jun 2012, Tero Kristo wrote:
Tested this set on top of v3.5-rc1 with omap3 / omap4 suspend + my omap4
core retention / dev-off patches. There are a couple of minor issues,
like the bug in patch 5, and the fact that counter_32k hwmod data is
broken for omap4. This fix is needed on omap4 to fix the counter_32k, if
this is not done, device off does not work:
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 66da92d..6ad64c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -397,8 +397,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_counter_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0004,
.sysc_flags = SYSC_HAS_SIDLEMODE,
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-SIDLE_SMART_WKUP),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
.sysc_fields= omap_hwmod_sysc_type1,
};
Thanks, Benoît mentioned this too. Just added a patch for this to the
second version of this fixes series.
- Paul
Re: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)
On Thu, 7 Jun 2012, Tony Lindgren wrote: Oh OK yeah makes sense as that's hwmod internal function. Then the driver specific part should use just void __iomem *base and use readl/writel and live under include/linux/platform_data/omap-usb.h. This sounds like something that might be flame-bait, since these functions aren't platform_data. How about putting these functions in arch/arm/plat-omap/include/plat? Drivers are able to include those files easily. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
