* [PATCH 00/11] OMAP2+: clock: add clockfw autoidle for iclks, OMAP2xxx
From: Kevin Hilman @ 2011-03-01 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216065030.22089.61217.stgit@twilight.localdomain>
Paul Walmsley <paul@pwsan.com> writes:
> Hello,
>
> This patch series adds clock framework-controlled autoidle support for
> the OMAP2xxx DPLL, APLLs, and OMAP2/3 interface clocks. The old
> direct register writes in the PM code to enable clock autoidle have been
> removed.
>
> This series also ensures that all clock autoidle is disabled during
> boot and only re-enabled if CONFIG_PM is enabled.
>
> The series applies on the 'clk_autoidle_a_2.6.39' branch of
> git://git.pwsan.com/linux-2.6.
>
> Boot-tested on N800, and dynamic idle-tested on OMAP3430 Beagleboard.
> Compile-tested with omap1_defconfig, omap2plus_defconfig, a 5912
> OSK-only config, an N8x0-only config, an OMAP3-only config, and an OMAP4-only
> config.
Reviewed-by: Kevin Hilman <khilman@ti.com>
Feel free to merge the various pm*.c changes via your tree.
Kevin
^ permalink raw reply
* [PATCH v2 2/4] ASoC: Fix burstsize and DSP_B format problems in imx-ssi.
From: Liam Girdwood @ 2011-03-01 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298988128-11520-3-git-send-email-javier.martin@vista-silicon.com>
On Tue, 2011-03-01 at 15:02 +0100, Javier Martin wrote:
> When choosing IMX_DMA flag, burtsizes are set to its default
> value (0) which leads to driver malfunction. Change them to 4.
>
> DSP_B interface needs additional flag to match DSP_B formats
> as described in several codecs as wm8741 and aic3205.
>
> Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Please CC both Mark and I on all ASoC patches otherwise I may not see
them.
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
^ permalink raw reply
* [PATCH] ARM: mx5: forbid building i.MX51 with any of i.MX50 or i.MX53
From: Uwe Kleine-König @ 2011-03-01 21:07 UTC (permalink / raw)
To: linux-arm-kernel
A config supporting all three SoCs compiles just fine, but the image
is broken because of different PHYS_OFFSETs.
This fix is a bit ugly because the i.MX50/i.MX53 machines simply
disappear in the config system when the first i.MX51 machine is
selected, but the upside is that no additional Kconfig symbol is
needed which would break more configs than this change.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mx5/Kconfig | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index f065a0d..4419f76 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -135,6 +135,11 @@ config MACH_MX51_EFIKASB
Include support for Genesi Efika Smartbook. This includes specific
configurations for the board and its peripherals.
+# i.MX51 uses a different PHYS_OFFSET than i.MX50 and i.MX53, so until this is
+# supported in a single kernel forbid selecting i.MX50/i.MX53 bases machines
+# when a i.MX51 based one is already selected.
+if !SOC_IMX51
+
config MACH_MX53_EVK
bool "Support MX53 EVK platforms"
select SOC_IMX53
@@ -180,3 +185,5 @@ config MACH_MX50_RDP
includes specific configurations for the board and its peripherals.
endif
+
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH v6 1/1] PRUSS UIO driver support
From: TK, Pratheesh Gangadhar @ 2011-03-01 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301183334.GC20497@local>
Hi,
> -----Original Message-----
> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> Sent: Wednesday, March 02, 2011 12:04 AM
> To: TK, Pratheesh Gangadhar
> Cc: Hans J. Koch; linux-kernel at vger.kernel.org; gregkh at suse.de;
> tglx at linutronix.de; sshtylyov at mvista.com; arnd at arndb.de; Chatterjee, Amit;
> davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v6 1/1] PRUSS UIO driver support
>
> On Tue, Mar 01, 2011 at 10:15:27AM +0530, TK, Pratheesh Gangadhar wrote:
> > Hi,
> >
> > > -----Original Message-----
> > > From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> > > Sent: Tuesday, March 01, 2011 2:57 AM
> > > To: TK, Pratheesh Gangadhar
> > > Cc: linux-kernel at vger.kernel.org; hjk at hansjkoch.de; gregkh at suse.de;
> > > tglx at linutronix.de; sshtylyov at mvista.com; arnd at arndb.de; Chatterjee,
> Amit;
> > > davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: [PATCH v6 1/1] PRUSS UIO driver support
> > >
> > > On Tue, Mar 01, 2011 at 02:31:35AM +0530, Pratheesh Gangadhar wrote:
> > > > +
> > > > + /* Register PRUSS IRQ lines */
> > > > + p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
> > > > + p->handler = pruss_handler;
> > > > +
> > > > + ret = uio_register_device(&dev->dev, p);
> > > > +
> > > > + if (ret < 0)
> > > > + goto out_free;
> > > > + }
> > > > +
> > > > + spin_lock_init(&lock);
> > >
> > > That's too late. uio_register_device() enables the irq, and your
> spin_lock
> > > is not ready at that time.
> >
> > This is ok in this context as "modprobe uio_pruss" is pre-requisite for
> > running PRUSS firmware and without firmware running PRUSS won't
> > generate interrupts. Actually PRUSS INTC is not setup till we start
> > user application.
>
> What if the user application is stopped, UIO driver module unloaded
> and loaded again?
>
This is a possible scenario - may be a buggy application. Normally when
application is stopped, PRUs are stopped by exit handler.
> Anyway, please don't use that kind of argumentation. The next newbie
> developer might copy your work as a basis for his new driver, and there
> it probably won't work.
>
> Simply put the spin_lock_init before the loop.
>
Agree, will fix this in next version.
Thanks,
Pratheesh
^ permalink raw reply
* [PATCH 2/2] ARM: mx3/pcm043: fix build failure
From: Fabio Estevam @ 2011-03-01 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299011459-18200-2-git-send-email-u.kleine-koenig@pengutronix.de>
Hallo Uwe,
2011/3/1 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Commit
>
> ? ? ? ?530aca5 (arm: mach-mx3: pcm043: add write-protect and card-detect for SD1)
>
> assigned a non-existing member .cd_gpio in a struct esdhc_platform_data.
> Though I expect this to change soon I remove it for now to unbreak the
> autobuilders.
Same error happens on mx25_3ds. Would you like me to send a patch for
fixing it for mx25_3ds too?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v7 0/1] Add PRUSS UIO driver support
From: Pratheesh Gangadhar @ 2011-03-01 21:28 UTC (permalink / raw)
To: linux-arm-kernel
This patch series add support for PRUSS (Programmable Real-time Unit Sub
System) UIO driver in Texas Instruments DA850, AM18xx and OMAP-L138 processors.
PRUSS is programmable RISC core which can be used to implement Soft IPs
(eg:- DMA, CAN, UART,SmartCard) and Industrial communications data link layers
(eg:- PROFIBUS). UIO driver exposes PRUSS resources like memory and interrupts
to user space application.PRUSS UIO application API can be used to control PRUs
in PRUSS, setup PRU INTC, load firmware to PRUs and implement IPC between Host
processor and PRUs. More information on PRUSS and UIO linux user space API
available in the links below
http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide
Platform/board specific portion of this patch depends on Mistral patches below
[PATCH 1/1] davinci: changed SRAM allocator to shared ram :
https://patchwork.kernel.org/patch/549351/
[PATCH 1/1] da830: macro rename DA8XX_LPSC0_DMAX to DA8XX_LPSC0_PRUSS :
https://patchwork.kernel.org/patch/549331/
[PATCH v2 01/13] mfd: pruss mfd driver :
https://patchwork.kernel.org/patch/549531/
[PATCH v2 02/13] da850: pruss platform specific additions :
https://patchwork.kernel.org/patch/549521/
I will submit a seperate patch set on top of these patches to support PRUSS
UIO driver.
Pratheesh Gangadhar (1):
PRUSS UIO driver support
drivers/uio/Kconfig | 17 +++
drivers/uio/Makefile | 1 +
drivers/uio/uio_pruss.c | 257 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_pruss.c
^ permalink raw reply
* [PATCH v7 1/1] PRUSS UIO driver support
From: Pratheesh Gangadhar @ 2011-03-01 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299014895-2022-1-git-send-email-pratheesh@ti.com>
This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
processors which is efficient in performing embedded tasks that
require manipulation of packed memory mapped data structures and
handling system events that have tight real time constraints. This
driver is currently supported on Texas Instruments DA850, AM18xx and
OMAP-L138 devices.
For example, PRUSS runs firmware for real-time critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.
Signed-off-by: Pratheesh Gangadhar <pratheesh@ti.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
drivers/uio/Kconfig | 17 +++
drivers/uio/Makefile | 1 +
drivers/uio/uio_pruss.c | 257 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_pruss.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index bb44079..6f3ea9b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -94,4 +94,21 @@ config UIO_NETX
To compile this driver as a module, choose M here; the module
will be called uio_netx.
+config UIO_PRUSS
+ tristate "Texas Instruments PRUSS driver"
+ depends on ARCH_DAVINCI_DA850
+ help
+ PRUSS driver for OMAPL138/DA850/AM18XX devices
+ PRUSS driver requires user space components, examples and user space
+ driver is available from below SVN repo - you may use anonymous login
+
+ https://gforge.ti.com/gf/project/pru_sw/
+
+ More info on API is available at below wiki
+
+ http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
+
+ To compile this driver as a module, choose M here: the module
+ will be called uio_pruss.
+
endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..d4dd9a5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC) += uio_aec.o
obj-$(CONFIG_UIO_SERCOS3) += uio_sercos3.o
obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
+obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
new file mode 100644
index 0000000..e636d56
--- /dev/null
+++ b/drivers/uio/uio_pruss.c
@@ -0,0 +1,257 @@
+/*
+ * Programmable Real-Time Unit Sub System (PRUSS) UIO driver (uio_pruss)
+ *
+ * This driver exports PRUSS host event out interrupts and PRUSS, L3 RAM,
+ * and DDR RAM to user space for applications interacting with PRUSS firmware
+ *
+ * Copyright (C) 2010-11 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 as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <mach/sram.h>
+
+
+#define DRV_NAME "pruss_uio"
+#define DRV_VERSION "0.50"
+
+
+static int sram_pool_sz = SZ_16K;
+module_param(sram_pool_sz, int, 0);
+MODULE_PARM_DESC(sram_pool_sz, "sram pool size to allocate ");
+
+static int extram_pool_sz = SZ_256K;
+module_param(extram_pool_sz, int, 0);
+MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
+
+
+/*
+ * Host event IRQ numbers from PRUSS - PRUSS can generate upto 8 interrupt
+ * events to AINTC of ARM host processor - which can be used for IPC b/w PRUSS
+ * firmware and user space application, async notification from PRU firmware
+ * to user space application
+ * 3 PRU_EVTOUT0
+ * 4 PRU_EVTOUT1
+ * 5 PRU_EVTOUT2
+ * 6 PRU_EVTOUT3
+ * 7 PRU_EVTOUT4
+ * 8 PRU_EVTOUT5
+ * 9 PRU_EVTOUT6
+ * 10 PRU_EVTOUT7
+*/
+
+#define MAX_PRUSS_EVT 8
+
+#define PINTC_HIPIR 0x4900
+#define HIPIR_NOPEND 0x80000000
+#define PINTC_HIER 0x5500
+
+static DEFINE_SPINLOCK(lock);
+static struct clk *pruss_clk;
+static struct uio_info *info;
+static dma_addr_t sram_paddr, ddr_paddr;
+static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
+
+static irqreturn_t pruss_handler(int irq, struct uio_info *info)
+{
+ int intr_bit = (irq - IRQ_DA8XX_EVTOUT0 + 2);
+ int val, intr_mask = (1 << intr_bit);
+ void __iomem *base = info->mem[0].internal_addr;
+ void __iomem *intren_reg = base + PINTC_HIER;
+ void __iomem *intrstat_reg = base + PINTC_HIPIR + (intr_bit << 2);
+
+ spin_lock_irq(&lock);
+ val = ioread32(intren_reg);
+ /* Is interrupt enabled and active ? */
+ if (!(val & intr_mask) && (ioread32(intrstat_reg) & HIPIR_NOPEND)) {
+ spin_unlock_irq(&lock);
+ return IRQ_NONE;
+ }
+
+ /* Disable interrupt */
+ iowrite32((val & ~intr_mask), intren_reg);
+ spin_unlock_irq(&lock);
+ return IRQ_HANDLED;
+}
+
+static int pruss_irqcontrol(struct uio_info *info, s32 irq_on)
+{
+ int intr_bit = info->irq - IRQ_DA8XX_EVTOUT0 + 2;
+ int val, intr_mask = (1 << intr_bit);
+ void __iomem *base = info->mem[0].internal_addr;
+ void __iomem *intren_reg = base + PINTC_HIER;
+
+ spin_lock_irq(&lock);
+ val = ioread32(intren_reg);
+ if (irq_on)
+ iowrite32((val | intr_mask), intren_reg);
+ else
+ iowrite32((val & ~intr_mask), intren_reg);
+ spin_unlock_irq(&lock);
+
+ return 0;
+}
+
+static void pruss_cleanup(struct platform_device *dev, struct uio_info *info)
+{
+ struct uio_info *p = info;
+ int cnt;
+
+ for (cnt = 0; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+ uio_unregister_device(p);
+ kfree(p->name);
+ }
+ iounmap(prussio_vaddr);
+ if (ddr_vaddr) {
+ dma_free_coherent(&dev->dev, extram_pool_sz, ddr_vaddr,
+ ddr_paddr);
+ }
+ if (sram_vaddr)
+ sram_free(sram_vaddr, sram_pool_sz);
+ kfree(info);
+ clk_put(pruss_clk);
+}
+
+static int __devinit pruss_probe(struct platform_device *dev)
+{
+ struct uio_info *p;
+ int ret = -ENODEV, cnt = 0, len;
+ struct resource *regs_prussio;
+
+ info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVT, GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+ /* Power on PRU in case its not done as part of boot-loader */
+ pruss_clk = clk_get(&dev->dev, "pruss");
+ if (IS_ERR(pruss_clk)) {
+ dev_err(&dev->dev, "Failed to get clock\n");
+ kfree(info);
+ ret = PTR_ERR(pruss_clk);
+ return ret;
+ } else {
+ clk_enable(pruss_clk);
+ }
+
+ regs_prussio = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ if (!regs_prussio) {
+ dev_err(&dev->dev, "No PRUSS I/O resource specified\n");
+ goto out_free;
+ }
+
+ if (!regs_prussio->start) {
+ dev_err(&dev->dev, "Invalid memory resource\n");
+ goto out_free;
+ }
+
+ sram_vaddr = sram_alloc(sram_pool_sz, &sram_paddr);
+ if (!sram_vaddr) {
+ dev_err(&dev->dev, "Could not allocate SRAM pool\n");
+ goto out_free;
+ }
+
+ ddr_vaddr = dma_alloc_coherent(&dev->dev, extram_pool_sz, &ddr_paddr,
+ GFP_KERNEL | GFP_DMA);
+ if (!ddr_vaddr) {
+ dev_err(&dev->dev, "Could not allocate external memory\n");
+ goto out_free;
+ }
+
+ len = resource_size(regs_prussio);
+ prussio_vaddr = ioremap(regs_prussio->start, len);
+ if (!prussio_vaddr) {
+ dev_err(&dev->dev, "Can't remap PRUSS I/O address range\n");
+ goto out_free;
+ }
+
+ spin_lock_init(&lock);
+
+ for (cnt = 0, p = info; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+ p->mem[0].internal_addr = prussio_vaddr;
+ p->mem[0].addr = regs_prussio->start;
+ p->mem[0].size = resource_size(regs_prussio);
+ p->mem[0].memtype = UIO_MEM_PHYS;
+
+ p->mem[1].internal_addr = sram_vaddr;
+ p->mem[1].addr = sram_paddr;
+ p->mem[1].size = sram_pool_sz;
+ p->mem[1].memtype = UIO_MEM_PHYS;
+
+ p->mem[2].internal_addr = ddr_vaddr;
+ p->mem[2].addr = ddr_paddr;
+ p->mem[2].size = extram_pool_sz;
+ p->mem[2].memtype = UIO_MEM_PHYS;
+
+ p->name = kasprintf(GFP_KERNEL, "pruss_evt%d", cnt);
+ p->version = "0.50";
+
+ /* Register PRUSS IRQ lines */
+ p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
+ p->handler = pruss_handler;
+ p->irqcontrol = pruss_irqcontrol;
+
+ ret = uio_register_device(&dev->dev, p);
+
+ if (ret < 0)
+ goto out_free;
+ }
+
+ platform_set_drvdata(dev, info);
+ return 0;
+
+out_free:
+ pruss_cleanup(dev, info);
+ return ret;
+}
+
+static int __devexit pruss_remove(struct platform_device *dev)
+{
+ struct uio_info *info = platform_get_drvdata(dev);
+
+ pruss_cleanup(dev, info);
+ platform_set_drvdata(dev, NULL);
+ return 0;
+}
+
+static struct platform_driver pruss_driver = {
+ .probe = pruss_probe,
+ .remove = __devexit_p(pruss_remove),
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init pruss_init_module(void)
+{
+ return platform_driver_register(&pruss_driver);
+}
+
+module_init(pruss_init_module);
+
+static void __exit pruss_exit_module(void)
+{
+ platform_driver_unregister(&pruss_driver);
+}
+
+module_exit(pruss_exit_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Amit Chatterjee <amit.chatterjee@ti.com>");
+MODULE_AUTHOR("Pratheesh Gangadhar <pratheesh@ti.com>");
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/4] msm: scm: Fix improper register assignment
From: Saravana Kannan @ 2011-03-01 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298975837.7828.9.camel@e102144-lin.cambridge.arm.com>
On 03/01/2011 02:37 AM, Will Deacon wrote:
> Hi Nicolas,
>
> On Sat, 2011-02-26 at 20:04 +0000, Nicolas Pitre wrote:
>> Right. A minimal test case may look like this if someone feels like
>> filling a gcc bug report:
>>
>> extern int foo(int x);
>>
>> int bar(int x)
>> {
>> register int a asm("r0") = 1;
>> x = foo(x);
>> asm ("add %0, %1, %2" : "=r" (x) : "r" (a), "r" (x));
>> return x;
>> }
>>
>> And the produced code is:
>>
>> bar:
>> stmfd sp!, {r3, lr}
>> bl foo
>> #APP
>> add r0, r0, r0
>> ldmfd sp!, {r3, pc}
>>
>> So this is clearly bogus.
>>
>
> I agree that this is wrong, but the compiler people may try and argue
> the other way. I'll ask some of the compiler guys at ARM and see what
> they think.
Nicolas and Will,
Thanks for the sample bug code and thanks for checking with the compiler
guys and validating (in another thread) that this is indeed a bug in
GCC. Glad to know we weren't doing something stupid.
>>> In any case, fortunately it works with the fix.
>>
>> Please add a comment in your patch to explain the issue.
>>
>
> Perhaps a more robust fix would be to remove the register int
> declarations and handle the parameter marshalling in the same asm block
> that contains the smc?
I was thinking the same, but the opposing idea I heard was that not
doing it inside the asm block would allow GCC to be make better use of
the registers. Didn't have a strong opinion either way, so we went with
the implementation that was sent out.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Thomas Gleixner @ 2011-03-01 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301201904.GA27107@n2100.arm.linux.org.uk>
On Tue, 1 Mar 2011, Russell King - ARM Linux wrote:
> On Tue, Mar 01, 2011 at 11:57:48AM +0100, Thomas Gleixner wrote:
> > On Mon, 28 Feb 2011, Russell King - ARM Linux wrote:
> >
> > > On Mon, Feb 28, 2011 at 08:16:25PM +0100, Thomas Gleixner wrote:
> > > > So what's the gain of a barebone chained handler over a regular
> > > > interrupt:
> > > >
> > > > - 100 instructions less
> > > > - lack of statistics
> > >
> > > We don't want statistics. Don't care how many times we go to look
> > > at the interrupt controller - and actually it's really wrong to count
> > > them in the first place. Counting them means that you double-count
> > > these interrupt events, and the more layers of interrupt controllers
> > > there are the worse that problem gets.
> > >
> > > So no, that's a definite argument *for* chained handers.
> >
> > Errm, why do you double account them ? The accounting goes to
> > different irq numbers, but we could exclude them from accounting and
> > showing up in proc/interrupts easily.
>
> We don't want the parent interrupt counted because the interrupt sum
> which is exported from the kernel via the various statistics interface
> will be screwed by this. For N levels of classical interrupt handlers,
> causing I interrupts, you end up with I*N interrupts reported.
>
> So if you have a 100Hz interrupt coming from a timer on a 2nd level IRQ
> controller, you'll end up seeing a 200Hz interrupt rate, which is quite
> obviously wrong.
Fair enough.
> > > Don't want affinity for them, as setting their affinity means that
> > > you then end up forcing the affinity for the sub-interrupts too.
> > > How you do cope with the high-level interrupt having affinity to
> > > CPU0 but a lower level interrupt being affine to CPU1 only?
> > >
> > > It's non-sensible, and is broken. So no, again this isn't an
> > > argument for not using chained handlers. It's an argument *for*
> > > them.
> >
> > Well, moving the whole group to a particular cpu is sensible and the
> > sub interrupts don't have a set_affinity function anyway as they are
> > always called on the cpu on which the primary interrupt is handled.
>
> Not quite correct - there's systems with two GICs chained one after each
> other. The second GIC will not have a NULL set_affinity function.
> However, it is meaningless to set the affinity for the second GIC as it
> is not multi-CPU aware.
Right. It's pointless for the secondary chip, but seeting the affinity
of the primary interrupt can be still useful..
> > > Sorry, but I think this stuff is right, and chained handlers like
> > > these have their place.
> >
> > I'm not against chained handlers per se. I'm against creating a
> > necessarity to make a chained handler deal with various different
> > underlying primary irq chips and their oddities. That's simply wrong
> > and broken.
>
> That wasn't a problem before genirq came along and invented many more
> different ways for 'flow' handlers to call into the lower level IRQ
> specific code.
It added merily two new flow handlers. One of them is fasteoi, which
was not necessary in the original ARM implementation. So where is the
point?
> > I don't say you have to use the existing flow handlers, if they are
> > too heavy weight for your purpose, but pushing conditional flow
> > handling into the chained handler is violating all principles of
> > layering.
>
> Chained handlers *are* a *direct* replacement for flow handlers because
> the normal flow handler is *meaningless* for chained handlers. Trying
> to separate them into different layers is a mistake in itself.
Did you even look at the separation I suggested?
> Chained handlers require the parent to behave differently. Eg, in the
> case of a level IRQ input, you don't want IRQs to be masked just because
> we're in the middle of servicing a down-stream interrupt. You want it
> left enabled so that if the ultimate device handler decides it needs to
> have IRQs enabled, then all interrupts are serviced in a fair manner.
>
> If you mask the parent interrupt, then only primary level interrupts
> get serviced and fairness goes out the window.
Errm. I did never say that we disable the parent interrupt by any
means except when the chained handler explicitely wants to do that,
which is pretty much pointlesss nowadays, as we run all interrupt
handlers with interrupts disabled.
> Maybe you never got that point when you decided to create genirq from
> my work, but that's *your* problem, not mine. And it seems you're
I pretty well understand the reasoning behind it and you know that.
Sigh, I explained it more than once: The chained handlers as they are,
are completely fine and not going away.
The only point where we disagree is an implementation detail:
The problem at hand which started this discussion wants to have
chained handlers which are able to deal with different underlying
primary irq chips.
My point is that having a chained handler which does:
if (chip->irq_ack)
chip->irq_ack();
demux_interrupts();
if (chip->irq_eoi)
chip->irq_eoi();
or whatever abnominations you come up with is wrong.
Such a demux handler should be agnostic of the underlying chip to
avoid wreckage like the one which is currently discussed which is
caused by a change to the underlying primary chip.
So my take on this is to have very simplistic primary flow handlers
which are selected by the primary chip implementation to allow the
underlying demux handler to be agnostic of the primary chip. They
don't have anything to do with the normal handle_irq_* flow handlers
and should be explicitely named different. They even should be
implemented in the arch/ chip implmentation and not be part of the
generic handlers as long as they are not identified as repeated
patterns.
Can you please take the time and explain me the difference of the
following:
irqchip1.c
struct irq_chip1;
handle_primary_irq(int irq, struct irq_desc *desc)
{
chip->irq_ack();
desc->demux();
}
init()
{
irq_set_chip(PRIMARY_IRQ, &irq_chip1);
irq_set_primary_handler(PRIMARY_IRQ, handle_primary_irq);
}
irqchip2.c
struct irq_chip2;
handle_primary_irq(int irq, struct irq_desc *desc)
{
desc->demux();
chip->irq_eoi();
}
init()
{
irq_set_chip(PRIMARY_IRQ, &irq_chip2);
irq_set_primary_handler(PRIMARY_IRQ, handle_primary_irq);
}
demux.c
demux_handler(...)
{
for_each_secondary_irq(irq)
generic_handle_irq(irq);
}
init()
{
irq_set_demux_handler(PRIMARY_IRQ, demux_handler);
}
versus:
irqchip1.c
struct irq_chip1;
init()
{
irq_set_chip(PRIMARY_IRQ, &irq_chip1);
}
irqchip2.c
struct irq_chip2;
init()
{
irq_set_chip(PRIMARY_IRQ, &irq_chip2);
}
demux.c
demux_handler(...)
{
if (chip->irq_ack())
chip->irq_ack();
for_each_secondary_irq(irq)
generic_handle_irq(irq);
if (chip->irq_eoi())
chip->irq_eoi();
}
init()
{
irq_set_chained_handler(PRIMARY_IRQ, demux_handler);
}
Both are functionally equivivalent except that
- my solution adds an indirect call
- your solution requires explicit knowledge about the underlying
possible primary irq chips
Now go to the above examples and add irq_chip3.c which requires
another different method of treating the primary interrupt. Lets
assume irq_chip3 is some oddball hardware.
My solution will look like this:
irqchip3.c
struct irq_chip3;
handle_primary_irq(int irq, struct irq_desc *desc)
{
fiddle_with_some_special_register();
desc->demux();
chip->irq_eoi();
}
init()
{
irq_set_chip(PRIMARY_IRQ, &irq_chip3);
irq_set_primary_handler(PRIMARY_IRQ, handle_primary_irq);
}
Yours will look like:
irqchip3.c
struct irq_chip3;
init()
{
irq_set_chip(PRIMARY_IRQ, &irq_chip3);
}
And change all affected demux handlers to:
demux_handler(...)
{
if (running_on_irq_chip3)
fiddle_with_some_special_register();
if (chip->irq_ack())
chip->irq_ack();
for_each_secondary_irq(irq)
generic_handle_irq(irq);
if (chip->irq_eoi())
chip->irq_eoi();
}
If you are still convinced that adding that extra stuff to the demux
handlers is the right way to go, I'm not in the way. I merily tried to
provide a generic solution to this, which avoid adding all this extra
knowledge into the demux handlers.
> hell bent on breaking this for ARM. So, I say again - if you persist
> with this, I'll replace the ARM IRQ implementation and stop using genirq
> because you're taking it in a direction which will cause problems for
> ARM. And I *really* mean that.
You are not threatening me with that. You are threatening your ARM
users as they rely on much more than the f*cking chained handler
details.
Thanks,
tglx
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-03-01 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201103012051.13768.arnd@arndb.de>
On Tue, Mar 1, 2011 at 1:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 01 March 2011 20:15:30 Jens Axboe wrote:
>> Thanks for the recap. One way to handle this would be to have a dm
>> target that ensures that requests are never built up to violate any of
>> the above items. Doing splitting is a little silly, when you can prevent
>> it from happening in the first place.
>
> Ok, that sounds good. I didn't know that it's possible to prevent
> bios from getting created that violate this.
>
Wouldn't someone still be able to perform a generic_make_request that
would violate the conditions (i.e. cross alignment boundary while
performing unaligned write)? You could prevent the merges that would
result in violating the conditions, sure, but you would need to handle
single unaligned accesses correctly too... Sorry, I'm just groping my
way around the block layer...a lot I'm still trying to draw a mental
picture for.
P.S. I've submitted for review the first 3 patches. Tear into them :).
A
^ permalink raw reply
* [PATCH v6 1/1] PRUSS UIO driver support
From: Thomas Gleixner @ 2011-03-01 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BF36683@dbde02.ent.ti.com>
On Wed, 2 Mar 2011, TK, Pratheesh Gangadhar wrote:
> Hi,
> > -----Original Message-----
> > From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> > Sent: Wednesday, March 02, 2011 12:04 AM
> > To: TK, Pratheesh Gangadhar
> > Cc: Hans J. Koch; linux-kernel at vger.kernel.org; gregkh at suse.de;
> > tglx at linutronix.de; sshtylyov at mvista.com; arnd at arndb.de; Chatterjee, Amit;
> > davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH v6 1/1] PRUSS UIO driver support
Sigh, can you please use a mailer which does not repeat the headers
for no value and just has a single line like this:
> > On Tue, Mar 01, 2011 at 10:15:27AM +0530, TK, Pratheesh Gangadhar wrote:
> > Anyway, please don't use that kind of argumentation. The next newbie
> > developer might copy your work as a basis for his new driver, and there
> > it probably won't work.
> >
> > Simply put the spin_lock_init before the loop.
> >
> Agree, will fix this in next version.
As I said before, we want stuff initialized when it is possibly
used. But first of all we ant people to use the proper mechanisms to
achive that.
If that's a module global lock then it needs to be instantiated by
static DEFINE_SPINLOCK(lock);
which implies the initialization of the lock.
If it's a lock which is in allocated memory then the
spin_lock_init(&lock);
wants to be before it can be possibly used.
So in your case DEFINE_SPINLOCK is the correct solution.
Thanks,
tglx
^ permalink raw reply
* [PATCH v7 1/1] PRUSS UIO driver support
From: Thomas Gleixner @ 2011-03-01 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299014895-2022-2-git-send-email-pratheesh@ti.com>
On Wed, 2 Mar 2011, Pratheesh Gangadhar wrote:
> +
> +static DEFINE_SPINLOCK(lock);
> +static struct clk *pruss_clk;
> +static struct uio_info *info;
> +static dma_addr_t sram_paddr, ddr_paddr;
> +static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
> +
> +static irqreturn_t pruss_handler(int irq, struct uio_info *info)
> +{
> + int intr_bit = (irq - IRQ_DA8XX_EVTOUT0 + 2);
> + int val, intr_mask = (1 << intr_bit);
> + void __iomem *base = info->mem[0].internal_addr;
> + void __iomem *intren_reg = base + PINTC_HIER;
> + void __iomem *intrstat_reg = base + PINTC_HIPIR + (intr_bit << 2);
> +
> + spin_lock_irq(&lock);
No, I said: spin_lock() is sufficient.
> + val = ioread32(intren_reg);
> + /* Is interrupt enabled and active ? */
> + if (!(val & intr_mask) && (ioread32(intrstat_reg) & HIPIR_NOPEND)) {
> + spin_unlock_irq(&lock);
You unconditinally enable interrupts here where you are not supposed
to do so.
> + return IRQ_NONE;
> + }
> +
> + /* Disable interrupt */
> + iowrite32((val & ~intr_mask), intren_reg);
> + spin_unlock_irq(&lock);
> + return IRQ_HANDLED;
> +}
> +
> +static int pruss_irqcontrol(struct uio_info *info, s32 irq_on)
> +{
> + int intr_bit = info->irq - IRQ_DA8XX_EVTOUT0 + 2;
> + int val, intr_mask = (1 << intr_bit);
> + void __iomem *base = info->mem[0].internal_addr;
> + void __iomem *intren_reg = base + PINTC_HIER;
> +
> + spin_lock_irq(&lock);
This one is correct, as this is always called from non interrupt
disabled context.
> + val = ioread32(intren_reg);
> + if (irq_on)
> + iowrite32((val | intr_mask), intren_reg);
> + else
> + iowrite32((val & ~intr_mask), intren_reg);
> + spin_unlock_irq(&lock);
> +
> + return 0;
> +}
> +
> + spin_lock_init(&lock);
Sigh. DEFINE_SPINLOCK(lock); already initializes the lock.
It's not the purpose of a review to tell you what you need to change
mechanically. Reviewers hint to a correct solution and you are
supposed to lookup what that solution means and act accordingly. If
you do not understand the hint or its implications please ask _before_
sending a new patch set.
Thanks,
tglx
^ permalink raw reply
* [PATCH] OMAP2+: PM: Warn users of sleep_while_idle if !CONFIG_CPU_IDLE
From: Kevin Hilman @ 2011-03-01 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297857860-3713-1-git-send-email-rnayak@ti.com>
Rajendra Nayak <rnayak@ti.com> writes:
> This should help users who do a
> 'echo 1 > /debug/pm_debug/sleep_while_idle' with a
> config which has !CONFIG_CPU_IDLE and wonder
> why OMAP is'nt sleeping in idle.
This isn't quite right, as 'sleep_while_idle' is actually a flag for
whether or not to call omap_sram_idle() at all.
Even without CPUidle, WFI will still be attempted.
Kevin
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> arch/arm/mach-omap2/pm-debug.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 125f565..1e722a0 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -569,6 +569,10 @@ static int option_get(void *data, u64 *val)
>
> *val = *option;
>
> +#ifndef CONFIG_CPU_IDLE
> + if (option == &sleep_while_idle)
> + pr_warn("CONFIG_CPU_IDLE is not enabled\n");
> +#endif
> return 0;
> }
>
> @@ -581,6 +585,11 @@ static int option_set(void *data, u64 val)
>
> *option = val;
>
> +#ifndef CONFIG_CPU_IDLE
> + if (option == &sleep_while_idle)
> + pr_warn("CONFIG_CPU_IDLE is not enabled\n");
> +#endif
> +
> if (option == &enable_off_mode) {
> if (val)
> omap_pm_enable_off_mode();
^ permalink raw reply
* [patch v1 2/3] arm: pmu: support pmu irq routed from CTI
From: Will Deacon @ 2011-03-01 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298998711-8165-3-git-send-email-tom.leiming@gmail.com>
Hi Ming Lei,
It's good to see somebody looking at OMAP4 since I've been hearing from
people having trouble getting perf going on the PandaBoard.
On Tue, 2011-03-01 at 16:58 +0000, tom.leiming at gmail.com wrote:
> From: Ming Lei <tom.leiming@gmail.com>
>
> This patch introduces pmu_platform_data struct to
> support pmu irq routed from CTI, such as implemented
> on OMAP4.
>
> Generally speaking, clearing cti irq should be done in
> irq handler, also enabling cti module after calling
> request_irq and disabling cti module before calling
> free_irq.
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> arch/arm/include/asm/pmu.h | 12 +++++++++
> arch/arm/kernel/perf_event.c | 57 ++++++++++++++++++++++++++++++-----------
> 2 files changed, 53 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
> index 7544ce6..6162aaf 100644
> --- a/arch/arm/include/asm/pmu.h
> +++ b/arch/arm/include/asm/pmu.h
> @@ -13,20 +13,32 @@
> #define __ARM_PMU_H__
>
> #include <linux/interrupt.h>
> +#include <asm/cti.h>
>
> enum arm_pmu_type {
> ARM_PMU_DEVICE_CPU = 0,
> ARM_NUM_PMU_DEVICES,
> };
>
> +#define MAX_CTI_NUM 4
Why is this in the PMU header file rather than the CTI one?
> /*
> * struct arm_pmu_platdata - ARM PMU platform data
> *
> + * @use_cti_irq: pmu irq is routed from cti
> + * @cti_cnt: cti counts used for pmu irq routing
> + * @cti: cti instances used to help access cti registers
> * @handle_irq: an optional handler which will be called from the 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.
> + *
> + * If pmu irq is routed from CTI, @use_cti_irq, @cti_cnt and
> + * @cti must be initialized and passed to pmu driver.
> */
> struct arm_pmu_platdata {
> + int use_cti_irq;
> + int cti_cnt;
> + struct cti cti[MAX_CTI_NUM];
> +
> irqreturn_t (*handle_irq)(int irq, void *dev,
> irq_handler_t pmu_handler);
> };
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 22e194eb..9027a8f 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -377,18 +377,39 @@ validate_group(struct perf_event *event)
> return 0;
> }
>
> -static irqreturn_t armpmu_platform_irq(int irq, void *dev)
> +static inline int cti_irq(struct arm_pmu_platdata *data)
> {
> - struct arm_pmu_platdata *plat = dev_get_platdata(&pmu_device->dev);
> + return data && data->use_cti_irq;
> +}
> +
> +static inline struct cti *irq_to_cti(struct arm_pmu_platdata *data,
> + int irq)
> +{
> + int idx;
>
> - return plat->handle_irq(irq, dev, armpmu->handle_irq);
> + for(idx = 0; idx < data->cti_cnt; idx++)
> + if (data->cti[idx].irq == irq)
> + return &data->cti[idx];
> + return NULL;
> +}
Hmm, since OMAP is the only platform using this, I'm not especially
happy sticking this directly in the PMU code.
> +static inline irqreturn_t armpmu_handle_irq(int irq_num, void *dev)
> +{
> + struct arm_pmu_platdata *plat = dev;
> +
> + if (cti_irq(plat))
> + cti_irq_ack(irq_to_cti(plat, irq_num));
> +
> + if (plat && plat->handle_irq)
> + return plat->handle_irq(irq_num, dev, armpmu->handle_irq);
> + else
> + return armpmu->handle_irq(irq_num, NULL);
> }
>
You can use the new arm_pmu_platdata.handle_irq function to register
your own IRQ callback. I don't think we should define the handler here.
> static int
> armpmu_reserve_hardware(void)
> {
> struct arm_pmu_platdata *plat;
> - irq_handler_t handle_irq;
> int i, err = -ENODEV, irq;
>
> pmu_device = reserve_pmu(ARM_PMU_DEVICE_CPU);
> @@ -399,11 +420,7 @@ armpmu_reserve_hardware(void)
>
> init_pmu(ARM_PMU_DEVICE_CPU);
>
> - plat = dev_get_platdata(&pmu_device->dev);
> - if (plat && plat->handle_irq)
> - handle_irq = armpmu_platform_irq;
> - else
> - handle_irq = armpmu->handle_irq;
> + plat = platform_get_drvdata(pmu_device);
>
> if (pmu_device->num_resources < 1) {
> pr_err("no irqs for PMUs defined\n");
> @@ -415,21 +432,25 @@ armpmu_reserve_hardware(void)
> if (irq < 0)
> continue;
>
> - err = request_irq(irq, handle_irq,
> + err = request_irq(irq, armpmu_handle_irq,
> IRQF_DISABLED | IRQF_NOBALANCING,
> - "armpmu", NULL);
> + "armpmu", plat);
> if (err) {
> pr_warning("unable to request IRQ%d for ARM perf "
> "counters\n", irq);
> break;
> - }
> + } else if (cti_irq(plat))
> + cti_enable(irq_to_cti(plat, irq));
> }
>
> if (err) {
> for (i = i - 1; i >= 0; --i) {
> irq = platform_get_irq(pmu_device, i);
> - if (irq >= 0)
> - free_irq(irq, NULL);
> + if (irq >= 0) {
> + if (cti_irq(plat))
> + cti_disable(irq_to_cti(plat, irq));
> + free_irq(irq, plat);
> + }
> }
> release_pmu(pmu_device);
> pmu_device = NULL;
> @@ -442,11 +463,15 @@ static void
> armpmu_release_hardware(void)
> {
> int i, irq;
> + struct arm_pmu_platdata *plat = platform_get_drvdata(pmu_device);
>
> for (i = pmu_device->num_resources - 1; i >= 0; --i) {
> irq = platform_get_irq(pmu_device, i);
> - if (irq >= 0)
> - free_irq(irq, NULL);
> + if (irq >= 0) {
> + if (cti_irq(plat))
> + cti_disable(irq_to_cti(plat, irq));
> + free_irq(irq, plat);
> + }
> }
> armpmu->stop();
>
Right, so I think a better way to do this is to put all the CTI stuff in
its own file. Whether this lives in the OMAP BSP is up to you (perhaps
the best place for it at the moment, until other platforms use it too).
Then we can add ->enable and ->disable hooks in the platdata which are
not CTI-specific and may also be useful for other platforms and PMU
implementations.
Does that work for you?
Cheers,
Will
^ permalink raw reply
* [PATCH v7 1/1] PRUSS UIO driver support
From: Hans J. Koch @ 2011-03-01 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103012238360.2701@localhost6.localdomain6>
On Tue, Mar 01, 2011 at 10:45:25PM +0100, Thomas Gleixner wrote:
>
> > +
> > + spin_lock_init(&lock);
>
> Sigh. DEFINE_SPINLOCK(lock); already initializes the lock.
>
> It's not the purpose of a review to tell you what you need to change
> mechanically. Reviewers hint to a correct solution and you are
> supposed to lookup what that solution means and act accordingly. If
> you do not understand the hint or its implications please ask _before_
> sending a new patch set.
Correct. But I'm to blame here, too, since I suggested the wrong solution.
Sorry for that, Gangadhar!
Thanks,
Hans
^ permalink raw reply
* [GIT PULL] omap fixes for v2.6.38-rc6
From: Kevin Hilman @ 2011-03-01 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.1.10.1103011931380.27610@esdhcp041196.research.nokia.com>
Aaro Koskinen <aaro.koskinen@nokia.com> writes:
> Hi,
>
> On Mon, 28 Feb 2011, Tony Lindgren wrote:
>> Please pull omap fixes from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus
>>
>> This contains one more timer regression fix, a DPLL rate fix,
>> and a mailbox NULL pointer fix that would be good to get
>> in for 2.6.38. The series also removes world-writable flag for
>> some debugfs entries.
>>
>> Other than I believe that's it for omap fixes for v2.6.38.
>
> I wonder what happened to this patch:
>
> http://marc.info/?l=linux-omap&m=129772313519005&w=2
>
I have it queued with some other PM fixes that I haven't (yet) pushed to
Tony due to being on vacation.
Will take care of that today or tomorrow at the latest.
Kevin
^ permalink raw reply
* [PATCH 0/2] OMAP3: cpuidle: prevent CORE pwrdm from entering low-power state when DSS active
From: Paul Walmsley @ 2011-03-01 22:49 UTC (permalink / raw)
To: linux-arm-kernel
This series prevents the OMAP3 CPUIdle code from programming the CORE
powerdomain to enter any power state lower than ON when the DSS power domain
is ON. (The assumption is that in this case, the DSS is active, DMA'ing
lines from RAM and displaying them somewhere.)
Tero, please don't hesitate to comment on the patch from you if I got the
commit message wrong.
- Paul
---
Tero Kristo (1):
OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on
Paul Walmsley (1):
OMAP3: cpuidle: add more details to the DSS-related CORE power domain state restriction
arch/arm/mach-omap2/cpuidle34xx.c | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on
From: Paul Walmsley @ 2011-03-01 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301220833.32613.54669.stgit@twilight.localdomain>
From: Tero Kristo <tero.kristo@nokia.com>
Prevent the CORE power domain from entering RETENTION or OFF when DSS
is on. Otherwise, the display FIFO(s) may underflow due to the time
needed for the CORE to wake back up, causing tearing and unnecessary
interrupts.
Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
[paul at pwsan.com: wrote commit message]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 0335cd8..d1b7789 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -9,8 +9,9 @@
* Copyright (C) 2007 Texas Instruments, Inc.
* Karthik Dasu <karthik-dp@ti.com>
*
- * Copyright (C) 2006 Nokia Corporation
+ * Copyright (C) 2006, 2011 Nokia Corporation
* Tony Lindgren <tony@atomide.com>
+ * Tero Kristo <tero.kristo@nokia.com>
*
* Copyright (C) 2005 Texas Instruments, Inc.
* Richard Woodruff <r-woodruff2@ti.com>
@@ -268,6 +269,12 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
goto select_state;
}
+ /* If DSS is active, prevent CORE RET/OFF */
+ dss_state = pwrdm_read_pwrst(dss_pd);
+ if (dss_state == PWRDM_POWER_ON &&
+ core_next_state != PWRDM_POWER_ON)
+ core_next_state = PWRDM_POWER_INACTIVE;
+
/*
* Prevent PER off if CORE is not in retention or off as this
* would disable PER wakeups completely.
@@ -288,7 +295,6 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
iva2_state = pwrdm_read_pwrst(iva2_pd);
sgx_state = pwrdm_read_pwrst(sgx_pd);
usb_state = pwrdm_read_pwrst(usb_pd);
- dss_state = pwrdm_read_pwrst(dss_pd);
if (cam_state > PWRDM_POWER_OFF ||
dss_state > PWRDM_POWER_OFF ||
^ permalink raw reply related
* [PATCH 2/2] OMAP3: cpuidle: add more details to the DSS-related CORE power domain state restriction
From: Paul Walmsley @ 2011-03-01 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301220833.32613.54669.stgit@twilight.localdomain>
Provide some more details about the rationale behind the CORE power domain
state restriction while DSS is enabled -- hopefully, enough to enable others
to implement an approach based on the DSS's required wakeup latency,
which can vary based on quite a few parameters.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
Cc: Sumit Semwal <sumit.semwal@ti.com>
Cc: Jean Pihet <j-pihet@ti.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index d1b7789..6bdbb33 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -269,7 +269,33 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
goto select_state;
}
- /* If DSS is active, prevent CORE RET/OFF */
+ /*
+ * If DSS is active, prevent any CORE power domain transition
+ * to RETENTION or lower. This is because we don't currently
+ * have the infrastructure in the DSS driver or kernel to
+ * enter CORE RET without causing DSS FIFO underflows. When
+ * the DSS FIFO underflows, the screen image can be distorted,
+ * because the CORE may not be able to come back on-line
+ * quickly enough to service DSS requests to the SDRAM
+ * framebuffer. The DSS may also interrupt the MPU when the
+ * FIFO underflows, potentially wasting power.
+ *
+ * The approach below is easy to implement, but potentially
+ * wastes power, especially with screens that don't require a
+ * backlight. Probably the best long-term way to fix this is
+ * for the DSS driver to constrain the CORE and SDRAM minimum
+ * power state with omap_pm_set_max_dev_wakeup_lat(), based on
+ * the DSS FIFO size(s), watermark levels, drain rate, and
+ * refill time. Based on that constraint, the OMAP PM code
+ * should adjust the CORE maximum power state, CORE DPLL
+ * autoidle mode, CORE_CLK rate, and voltage scaling to ensure
+ * the required wakeup latency at the lowest power
+ * consumption.
+ *
+ * (More information on the DSS low-power refresh mode can be
+ * found in _Using Display Low-Power Refresh on the OMAP3430
+ * Device_, TI Application Report, SWPA158 - October 2008.)
+ */
dss_state = pwrdm_read_pwrst(dss_pd);
if (dss_state == PWRDM_POWER_ON &&
core_next_state != PWRDM_POWER_ON)
^ permalink raw reply related
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Russell King - ARM Linux @ 2011-03-01 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103012133530.2701@localhost6.localdomain6>
On Tue, Mar 01, 2011 at 10:29:37PM +0100, Thomas Gleixner wrote:
> Can you please take the time and explain me the difference of the
> following:
Can you please take the time to realise that sometimes the combination
between the primary and secondary interrupt controller is so tied that
this kind of thing can't happen?
Sometimes the secondary interrupt controller *must* mask the parent
interrupt because it has no masking capability of its own.
Sometimes the secondary interrupt controller *must* cause the primary
controller to ack the interrupt status *before* the secondary handler
reads the status.
You can not say "the primary controller behaves like X so we always do
X" because the action required on the primary is a combination of how
the primary behaves *and* how the secondary behaves.
Consider for example an edge triggered interrupt connected to a secondary
controller - yes, we have that combination. When you read the secondary
status register and clear those interrupts which are pending, the
secondary controller resets to inactive its output. If there's still
pending interrupts, it re-asserts the output causing a new edge.
If your primary 'flow' handler were to acknowledge the interrupt *after*
the demux, you'd lose interrupts.
However, if the very same primary interrupt controller is connected to
a FPGA based oring of several interrupt sources, this has to ack before
reading the status, read the status, process *all* interrupts, re-ack,
re-read the status and repeat until the status register indicates no
further interrupts are pending.
You can't deal with these two situations if you tie all the primary
flow handling outside of the secondary demux handler. And it's
*wrong* to do so. The behaviour required for the primary controller
inherently depends on the secondary controller.
It may not be clean from a software point of view, but that's hardware
for you, and we have to make this work. You *can't* do that by
separating the primary flow from the demux.
^ permalink raw reply
* [GIT PULL] OMAP PM fixes for 2.6.38-rc
From: Kevin Hilman @ 2011-03-01 23:14 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Here's a final batch of PM fixes for the 2.6.38-rc cycle.
Kevin
The following changes since commit f5412be599602124d2bdd49947b231dd77c0bf99:
Linux 2.6.38-rc6 (2011-02-21 17:25:52 -0800)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_2.6.38/pm-fixes
Aaro Koskinen (1):
arm: mach-omap2: smartreflex: fix another memory leak
Shweta Gulati (1):
OMAP2+: PM: SmartReflex: fix memory leaks in Smartreflex driver
Vasiliy Kulikov (3):
mach-omap2: mux: world-writable debugfs files
mach-omap2: pm: world-writable debugfs timer files
mach-omap2: smartreflex: world-writable debugfs voltage files
arch/arm/mach-omap2/mux.c | 2 +-
arch/arm/mach-omap2/pm-debug.c | 8 ++++----
arch/arm/mach-omap2/smartreflex.c | 37 +++++++++++++++++--------------------
3 files changed, 22 insertions(+), 25 deletions(-)
^ permalink raw reply
* [PATCH v2 2/4] ASoC: Fix burstsize and DSP_B format problems in imx-ssi.
From: Mark Brown @ 2011-03-01 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298988128-11520-3-git-send-email-javier.martin@vista-silicon.com>
On Tue, Mar 01, 2011 at 03:02:06PM +0100, Javier Martin wrote:
> When choosing IMX_DMA flag, burtsizes are set to its default
> value (0) which leads to driver malfunction. Change them to 4.
>
> DSP_B interface needs additional flag to match DSP_B formats
> as described in several codecs as wm8741 and aic3205.
>
> Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Thomas Gleixner @ 2011-03-01 23:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301231432.GG27107@n2100.arm.linux.org.uk>
On Tue, 1 Mar 2011, Russell King - ARM Linux wrote:
> On Tue, Mar 01, 2011 at 10:29:37PM +0100, Thomas Gleixner wrote:
> > Can you please take the time and explain me the difference of the
> > following:
>
> Can you please take the time to realise that sometimes the combination
> between the primary and secondary interrupt controller is so tied that
> this kind of thing can't happen?
>
> Sometimes the secondary interrupt controller *must* mask the parent
> interrupt because it has no masking capability of its own.
>
> Sometimes the secondary interrupt controller *must* cause the primary
> controller to ack the interrupt status *before* the secondary handler
> reads the status.
>
> You can not say "the primary controller behaves like X so we always do
> X" because the action required on the primary is a combination of how
> the primary behaves *and* how the secondary behaves.
>
> Consider for example an edge triggered interrupt connected to a secondary
> controller - yes, we have that combination. When you read the secondary
> status register and clear those interrupts which are pending, the
> secondary controller resets to inactive its output. If there's still
> pending interrupts, it re-asserts the output causing a new edge.
>
> If your primary 'flow' handler were to acknowledge the interrupt *after*
> the demux, you'd lose interrupts.
>
> However, if the very same primary interrupt controller is connected to
> a FPGA based oring of several interrupt sources, this has to ack before
> reading the status, read the status, process *all* interrupts, re-ack,
> re-read the status and repeat until the status register indicates no
> further interrupts are pending.
>
> You can't deal with these two situations if you tie all the primary
> flow handling outside of the secondary demux handler. And it's
> *wrong* to do so. The behaviour required for the primary controller
> inherently depends on the secondary controller.
>
> It may not be clean from a software point of view, but that's hardware
> for you, and we have to make this work. You *can't* do that by
> separating the primary flow from the demux.
You are talking about very specific cases, where the demux handler is
tighlty integrated into the primary chip implementation. No discussion
about that. I do not want to change anything there. Period.
The problem which caused that discussion has nothing to do with the
above. It's about bog standard nested controllers which do not have a
tight coupling to the the primary chip. But changing the primary chip
from ack based to eoi based requires to touch multiple demux handlers
while a primary chip agnostic solution for these cases would avoid
that. W/O any negative side effects.
Your oddball FPGA example has nothing to do with that and can happily
use the existing model. Such a demux handler will never have to deal
with different primary chips.
Thanks,
tglx
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Russell King - ARM Linux @ 2011-03-01 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103020033080.2701@localhost6.localdomain6>
On Wed, Mar 02, 2011 at 12:44:05AM +0100, Thomas Gleixner wrote:
> The problem which caused that discussion has nothing to do with the
> above. It's about bog standard nested controllers which do not have a
> tight coupling to the the primary chip. But changing the primary chip
> from ack based to eoi based requires to touch multiple demux handlers
> while a primary chip agnostic solution for these cases would avoid
> that. W/O any negative side effects.
If you think its soo damned simple, maybe you should put the effort in
and fix all this up, get it tested as fully working on the affected
platforms, and show the patches then.
^ permalink raw reply
* [PATCH 2/4] msm: scm: Fix improper register assignment
From: Nicolas Pitre @ 2011-03-02 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D652A.5050502@codeaurora.org>
On Tue, 1 Mar 2011, Saravana Kannan wrote:
> On 03/01/2011 02:37 AM, Will Deacon wrote:
> > Perhaps a more robust fix would be to remove the register int
> > declarations and handle the parameter marshalling in the same asm block
> > that contains the smc?
>
> I was thinking the same, but the opposing idea I heard was that not doing it
> inside the asm block would allow GCC to be make better use of the registers.
Indeed. And a significant body of code out there does rely on this gcc
feature, so it has to minimally work.
> Didn't have a strong opinion either way, so we went with the implementation
> that was sent out.
ACK.
Nicolas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox