* [PATCH V4 2/4] ARM: Xilinx: Adding timer support to the platform
From: John Linn @ 2011-02-28 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228111156.GB8751@pulham.picochip.com>
> -----Original Message-----
> From: Jamie Iles [mailto:jamie at jamieiles.com]
> Sent: Monday, February 28, 2011 4:12 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; linux at arm.linux.org.uk;
> catalin.marinas at arm.com; glikely at secretlab.ca; jamie at jamieiles.com;
arnd at arndb.de; Kiran Sutariya
> Subject: Re: [PATCH V4 2/4] ARM: Xilinx: Adding timer support to the
platform
>
> On Fri, Feb 18, 2011 at 11:14:39AM -0700, John Linn wrote:
> > The timer driver supports the Xilinx PS Timer Counter IP.
> >
> > Signed-off-by: Kiran Sutariya <kiran.sutariya@einfochips.com>
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
>
> Looks nice to me. It may be worth adding sched_clock() support to get
> better scheduler resolution in the future but that could come as a
> separate patch.
Yes will do that as an update patch later, good suggestion.
Thanks,
John
>
> Jamie
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH V4 1/4] ARM: Xilinx: Adding Xilinx board support
From: John Linn @ 2011-02-28 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228110618.GA8751@pulham.picochip.com>
> -----Original Message-----
> From: Jamie Iles [mailto:jamie at jamieiles.com]
> Sent: Monday, February 28, 2011 4:06 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; linux at arm.linux.org.uk;
> catalin.marinas at arm.com; glikely at secretlab.ca; jamie at jamieiles.com;
arnd at arndb.de
> Subject: Re: [PATCH V4 1/4] ARM: Xilinx: Adding Xilinx board support
>
> Hi John,
>
> A couple of very pedantic nitpicks below, sorry I didn't spot them
> before!
>
> On Fri, Feb 18, 2011 at 11:14:38AM -0700, John Linn wrote:
> > The 1st board support is minimal to get a system up and running
> > on the Xilinx platform.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> >
> > V4 Changes
> > Minor cleanup based on input from Jamie Iles.
> >
> > V3 Changes
> >
> > Updates based on Russell Kings' comments
> > Changed headers to update the license info and remove
> > the address
> >
> > Changed the name of functions to include "xilinx" in
> > common.c and common.h
> >
> > Changed the Kconfig and Makefile to use MACH_XILINX which
> > matches the machine registered.
> >
> > V2 Changes
> >
> > Updates based on Russell King's comments
> > minor cleanups
> > cleaned up physical/virtual addresses in early i/o table
> >
> > arch/arm/mach-xilinx/Kconfig | 14 +++++
> > arch/arm/mach-xilinx/Makefile | 7 ++
> > arch/arm/mach-xilinx/Makefile.boot | 3 +
> > arch/arm/mach-xilinx/board_ep107.c | 82
++++++++++++++++++++++++++
> > arch/arm/mach-xilinx/common.c | 113
++++++++++++++++++++++++++++++++++++
> > arch/arm/mach-xilinx/common.h | 30 ++++++++++
> > 6 files changed, 249 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/mach-xilinx/Kconfig
> > create mode 100644 arch/arm/mach-xilinx/Makefile
> > create mode 100644 arch/arm/mach-xilinx/Makefile.boot
> > create mode 100644 arch/arm/mach-xilinx/board_ep107.c
> > create mode 100644 arch/arm/mach-xilinx/common.c
> > create mode 100644 arch/arm/mach-xilinx/common.h
> >
> > diff --git a/arch/arm/mach-xilinx/Kconfig
b/arch/arm/mach-xilinx/Kconfig
> > new file mode 100644
> > index 0000000..61532af
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/Kconfig
> > @@ -0,0 +1,14 @@
> > +if ARCH_XILINX
> > +
> > +choice
> > + prompt "Board Selection"
> > + default MACH_XILINX
> > +
> > +config MACH_XILINX
> > + bool "Xilinx EP107 Board"
> > + help
> > + Select if you are using a Xilinx EP107 board.
> > +
> > +endchoice
> > +
> > +endif
> > diff --git a/arch/arm/mach-xilinx/Makefile
b/arch/arm/mach-xilinx/Makefile
> > new file mode 100644
> > index 0000000..76e9e55
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/Makefile
> > @@ -0,0 +1,7 @@
> > +#
> > +# Makefile for the linux kernel.
> > +#
> > +
> > +# Common support
> > +obj-y := common.o
> > +obj-$(CONFIG_MACH_XILINX) += board_ep107.o
> > diff --git a/arch/arm/mach-xilinx/Makefile.boot
b/arch/arm/mach-xilinx/Makefile.boot
> > new file mode 100644
> > index 0000000..67039c3
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/Makefile.boot
> > @@ -0,0 +1,3 @@
> > + zreladdr-y := 0x00008000
> > +params_phys-y := 0x00000100
> > +initrd_phys-y := 0x00800000
> > diff --git a/arch/arm/mach-xilinx/board_ep107.c
b/arch/arm/mach-xilinx/board_ep107.c
> > new file mode 100644
> > index 0000000..a1635b5
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/board_ep107.c
> > @@ -0,0 +1,82 @@
> > +/* arch/arm/mach-xilinx/board_ep107.c
> > + *
> > + * This file contains code specific to the Xilinx EP107 board.
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * based on /arch/arm/mach-realview/core.c
> > + *
> > + * Copyright (C) 1999 - 2003 ARM Limited
> > + * Copyright (C) 2000 Deep Blue Solutions Ltd
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/platform_device.h>
> > +#include <asm/mach-types.h>
> > +#include <asm/mach/arch.h>
> > +#include <mach/xilinx_soc.h>
> > +#include <mach/irqs.h>
> > +#include <linux/clkdev.h>
> > +#include "common.h"
>
> Usual convention is to order these as the linux, then the asm, then
the
> mach includes.
Easy to fix :), thanks for pointing it out.
>
> > +
> > +/*
> > + * Fixed clocks for now
> > + */
> > +
> > +static struct clk ref50_clk = {
> > + .rate = 50000000,
> > +};
> > +
> > +/* Create all the platform devices for the board */
> > +
> > +static struct resource uart0[] = {
> > + {
> > + .start = UART0_PHYS,
> > + .end = UART0_PHYS + 0xFFF,
> > + .flags = IORESOURCE_MEM,
> > + }, {
> > + .start = IRQ_UART0,
> > + .end = IRQ_UART0,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > +};
> > +
> > +static struct platform_device uart_device0 = {
> > + .name = "xuartpss",
> > + .id = 0,
> > + .dev = {
> > + .platform_data = &ref50_clk.rate,
> > + },
> > + .resource = uart0,
> > + .num_resources = ARRAY_SIZE(uart0),
> > +};
> > +
> > +static struct platform_device *xilinx_pdevices[] __initdata = {
> > + &uart_device0,
> > +};
> > +
> > +/**
> > + * board_ep107_init - Board specific initialization for the Xilinx
EP107 board.
> > + *
> > + **/
> > +static void __init board_ep107_init(void)
> > +{
> > + xilinx_system_init();
> > + platform_add_devices(&xilinx_pdevices[0],
ARRAY_SIZE(xilinx_pdevices));
> > +}
> > +
> > +MACHINE_START(XILINX_EP107, "Xilinx EP107")
> > + .boot_params = PHYS_OFFSET + 0x00000100,
>
> Should this use PLAT_PHYS_OFFSET?
>
Yes, not sure why I didn't catch that.
Thanks,
John
> Jamie
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display
From: Russell King - ARM Linux @ 2011-02-28 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6BA558.5050700@ti.com>
On Mon, Feb 28, 2011 at 02:38:32PM +0100, Cousson, Benoit wrote:
> On 2/28/2011 1:13 PM, Russell King - ARM Linux wrote:
>> On Mon, Feb 28, 2011 at 02:10:26PM +0200, Tomi Valkeinen wrote:
>>> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>>>> Cannot you use a device hierarchy then to do that?
>>>> omap_dss/core
>>>> omap_dss/dsi
>>>> omap_dss/venc
>>>>
>>>> This is moreover the way the HW is done.
>>>
>>> Hmm, how would that work? The devices are platform devices, and they
>>> have a unique global name, which is used to match the driver for the
>>> device.
>>
>> And not forgetting that '/' is not permitted in device or driver names.
>
> I was not really considering naming the device with a '/'. The idea is
> that the devices will not longer be flat platform devices but something
> like dss devices that will have have a omap_dss parent.
>
> I do not know if that makes sense to store some kind of hierarchy in the
> device model, but encoding the hierarchy in the name like it is proposed
> looks like a hack to me.
Try:
tree -d /sys/devices/pci0000\:00
on your PC, taking special note of how pci-to-pci bridges are handled.
^ 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-02-28 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298900022-21516-7-git-send-email-will.deacon@arm.com>
On Mon, Feb 28, 2011 at 01:33:42PM +0000, Will Deacon wrote:
> The chained GPIO IRQ handler for the nomadik platform can be called
> with the GIC as its host chip on the mach-ux500 machines.
>
> This patch updates the code to use ->irq_eoi when it is available.
>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/plat-nomadik/gpio.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-nomadik/gpio.c b/arch/arm/plat-nomadik/gpio.c
> index 1e88ecb..51cc71b 100644
> --- a/arch/arm/plat-nomadik/gpio.c
> +++ b/arch/arm/plat-nomadik/gpio.c
> @@ -538,6 +538,8 @@ static void nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> }
>
> host_chip->irq_unmask(&desc->irq_data);
> + if (host_chip->irq_eoi)
> + host_chip->irq_eoi(&desc->irq_data);
I notice in some you delete the irq_unmask, others you leave it. Shouldn't
they all be similar?
Maybe we do something like:
static inline void chained_irq_exit(struct irq_chip *chip, struct irq_desc *desc)
{
if (chip->irq_eoi)
chip->irq_eoi(&desc->irq_data);
else
chip->irq_unmask(&desc->irq_data);
}
to cover these exit paths in a common way?
^ permalink raw reply
* [PATCH v10 05/18] OMAP2, 3 DSS2 Change driver name to omap_display
From: Cousson, Benoit @ 2011-02-28 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298895026.9809.27.camel@deskari>
On 2/28/2011 1:10 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>> Hi Tomi,
>>
>> On 2/28/2011 8:19 AM, Valkeinen, Tomi wrote:
>>> On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote:
>>>> Hi,
>>>>
>>>> On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
>>>>> On Thu, 2011-02-24 at 03:27 -0600, Tomi Valkeinen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 2011-01-24 at 11:51 +0530, ext Sumit Semwal wrote:
>>>>>>> From: Senthilvadivu Guruswamy<svadivu@ti.com>
>>>>>>>
>>>>>>> Change the driver name from omapdss to omap_display as the driver takes care of
>>>>>>> the display devices ie number of panels, type of panels available in the
>>>>>>> platform. Change the device name in the board files and 2420,2430,3xxx clock
>>>>>>> files from omapdss to omap_display to match the driver name.
>>>>>>
>>>>>> I just realized that changing the driver name will break all scripts and
>>>>>> applications using omapdss sysfs files.
>>>>>>
>>>>>> How does this sound:
>>>>>>
>>>>>> Let's leave the omapdss device name as it is. It represents a "super"
>>>>>> device, containing the dss sysfs files and upper level dss management.
>>
>> This is the case for all the drivers migrated to omap_device anyway due
>> to the change in the top level hierarchy. Everything is below
>> platform/omap now.
>
> The HW module drivers are under platform/omap/, but omapdss is in
> platform/. Do you mean that omapdss should also be under platform/omap/?
This is because you are probably not using omap_device yet. is should
happen when you will change your platform_device to be omap_device.
> The reason I'm unwilling to change omapdss name, or location, is that
> omapdss directory contains lots of DSS configuration files, used by
> scripts and programs.
Is that used for debug only?
>> That's why we are using that opportunity to clean and provide a
>> consistent naming for all devices.
>>
>>>>>> Name the HW module platform drivers as: omapdss_dss, omapdss_venc,
>>>>>> omapdss_dispc, etc. This would indicate them to be clearly parts of DSS,
>>>>>> and would also prevent any possible name conflict if there would happen
>>>>>> to be a, say, "dsi" block in some other HW component.
>>
>> Cannot you use a device hierarchy then to do that?
>> omap_dss/core
>> omap_dss/dsi
>> omap_dss/venc
>>
>> This is moreover the way the HW is done.
>
> Hmm, how would that work? The devices are platform devices, and they
> have a unique global name, which is used to match the driver for the
> device.
Practically, I don't really know :-) Please see the reply to Russell.
>>>>> Any comments on this?
>>>>
>>>> I also think we need to stick to the older name, "omapdss_dss" sounds a
>>>> bit confusing, and I think one of the previous versions had something
>>>> like "dss_dss" in it and it wasn't approved. Does something like
>>>> "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?
>>>
>>> It is confusing, but so is the hardware naming =). There is a DSS module
>>> inside the omap display subsystem. That's why I would like to name it
>>> "dss", not "core", so it's clear it refers to this DSS module.
>>>
>>> "dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly
>>> better in the sense that it doesn't repeat the same "dss", and there is
>>> an "omapdss" device, which acts like "manager" for these module devices.
>>> But yes, I wouldn't call it perfect either.
>>>
>>> "omapdss_dss_core" is one option. But then again, TRM doesn't speak of
>>> "core".
>>
>> We should not maintain silly names just because they are in the TRM, we
>> should just fix the TRM. This is exactly what we are going to do for
>> most HW names we introduced in OMAP4.
>>
>> So if we all agree that this name will avoid confusion and is much
>> better than the current one, we can change it right now with a comment
>> to explain the change and give the pointer to the current TRM naming.
>
> True. But I don't think there's a huge difference with omapdss_dss or
> omapdss_core.
You're right, at the end it is just a name. We are just trying to clean
a little bit the current devices name mess. So the convention we are
trying to enforce is to name omap devices omap_XXX.
> The name is used in only a few places inside the kernel, and never from
> userspace, so we can change that also later.
>
> The main issue I had was changing the omapdss device name, which would
> break the userspace.
That's why we'd better break it properly today once and for all :-)
At least when you will migrate to omap_device.
Benoit
^ permalink raw reply
* [PATCH V3 1/4] ARM: imx53_loco: add esdhc device support
From: Wolfram Sang @ 2011-02-28 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298892725-23672-1-git-send-email-Hong-Xing.Zhu@freescale.com>
On Mon, Feb 28, 2011 at 07:32:02PM +0800, Richard Zhu wrote:
> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/deaf223d/attachment.sig>
^ permalink raw reply
* [PATCH V5 6/6] pxa3xx_nand: clean the keep configure code
From: Artem Bityutskiy @ 2011-02-28 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298860335-18638-7-git-send-email-leiwen@marvell.com>
On Mon, 2011-02-28 at 10:32 +0800, Lei Wen wrote:
> Signed-off-by: Lei Wen <leiwen@marvell.com>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> ---
> arch/arm/plat-pxa/include/plat/pxa3xx_nand.h | 2 +-
> drivers/mtd/nand/pxa3xx_nand.c | 103 +++++++++-----------------
> 2 files changed, 36 insertions(+), 69 deletions(-)
Similarly, could you please improve the commit message a bit?
--
Best Regards,
Artem Bityutskiy (????? ????????)
^ permalink raw reply
* [PATCH V5 1/6] pxa3xx_nand: make scan procedure more clear
From: Artem Bityutskiy @ 2011-02-28 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298860335-18638-2-git-send-email-leiwen@marvell.com>
On Mon, 2011-02-28 at 10:32 +0800, Lei Wen wrote:
> Signed-off-by: Lei Wen <leiwen@marvell.com>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Could you please improve the commit message and make it explain why your
code makes "scan" more clear, what exactly you do to improve it?
--
Best Regards,
Artem Bityutskiy (????? ????????)
^ permalink raw reply
* [PATCH V3 1/4] ARM: imx53_loco: add esdhc device support
From: Richard Zhao @ 2011-02-28 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin1U=B3xnp0UGK_2iHK2k=o4Tda=6NzyoLFgUAv@mail.gmail.com>
On Mon, Feb 28, 2011 at 8:43 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Richard,
>
> On Mon, Feb 28, 2011 at 8:25 AM, Richard Zhu
> <Hong-Xing.Zhu@freescale.com> wrote:
>> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
>> ---
>> ?arch/arm/mach-mx5/Kconfig ? ? ? ? ? | ? ?1 +
>> ?arch/arm/mach-mx5/board-mx53_loco.c | ? ?2 ++
>> ?2 files changed, 3 insertions(+), 0 deletions(-)
>
> I think this patch should be the last one of the series.
Yes, but I don't think it matter much.
Thanks
Richard
>
> Regards,
>
> Fabio Estevam
>
^ permalink raw reply
* [PATCH v10 05/18] OMAP2, 3 DSS2 Change driver name to omap_display
From: Cousson, Benoit @ 2011-02-28 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228121321.GB30781@n2100.arm.linux.org.uk>
On 2/28/2011 1:13 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 28, 2011 at 02:10:26PM +0200, Tomi Valkeinen wrote:
>> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>>> Cannot you use a device hierarchy then to do that?
>>> omap_dss/core
>>> omap_dss/dsi
>>> omap_dss/venc
>>>
>>> This is moreover the way the HW is done.
>>
>> Hmm, how would that work? The devices are platform devices, and they
>> have a unique global name, which is used to match the driver for the
>> device.
>
> And not forgetting that '/' is not permitted in device or driver names.
I was not really considering naming the device with a '/'. The idea is
that the devices will not longer be flat platform devices but something
like dss devices that will have have a omap_dss parent.
I do not know if that makes sense to store some kind of hierarchy in the
device model, but encoding the hierarchy in the name like it is proposed
looks like a hack to me. The point is that the dsi instances might
potentially be in another part of the SoC. Having the device name based
on the hierarchy will not allow the driver to bind the device properly.
Please note, that I'm not really sure it is doable with the current
device model, hence the original question.
Benoit
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>
The chained GPIO IRQ handler for the nomadik platform can be called
with the GIC as its host chip on the mach-ux500 machines.
This patch updates the code to use ->irq_eoi when it is available.
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/plat-nomadik/gpio.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-nomadik/gpio.c b/arch/arm/plat-nomadik/gpio.c
index 1e88ecb..51cc71b 100644
--- a/arch/arm/plat-nomadik/gpio.c
+++ b/arch/arm/plat-nomadik/gpio.c
@@ -538,6 +538,8 @@ static void nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
}
host_chip->irq_unmask(&desc->irq_data);
+ if (host_chip->irq_eoi)
+ host_chip->irq_eoi(&desc->irq_data);
}
static int nmk_gpio_init_irq(struct nmk_gpio_chip *nmk_chip)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 5/6] ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>
The chained GPIO IRQ handler on MSM8x60 calls ->ack on the parent chip
after handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved
to using the fasteoi flow model.
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mach-msm/gpio-v2.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
index 0de19ec..90a968f 100644
--- a/arch/arm/mach-msm/gpio-v2.c
+++ b/arch/arm/mach-msm/gpio-v2.c
@@ -310,6 +310,7 @@ static int msm_gpio_irq_set_type(unsigned int irq, unsigned int flow_type)
static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)
{
unsigned long i;
+ struct irq_chip *chip = get_irq_desc_chip(desc);
for (i = find_first_bit(msm_gpio.enabled_irqs, NR_GPIO_IRQS);
i < NR_GPIO_IRQS;
@@ -318,7 +319,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)
generic_handle_irq(msm_gpio_to_irq(&msm_gpio.gpio_chip,
i));
}
- desc->chip->ack(irq);
+ chip->irq_eoi(&desc->irq_data);
}
static int msm_gpio_irq_set_wake(unsigned int irq, unsigned int on)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/6] ARM: s5pv310: update IRQ combiner to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>
The IRQ combiner code invokes the ->irq_{un}mask routines of the parent
chip.
This patch updates the cascaded handler to use EOI now that the GIC has
moved to using the fasteoi flow model.
Tested-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mach-s5pv310/irq-combiner.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-s5pv310/irq-combiner.c b/arch/arm/mach-s5pv310/irq-combiner.c
index 1ea4a9e..24d5604 100644
--- a/arch/arm/mach-s5pv310/irq-combiner.c
+++ b/arch/arm/mach-s5pv310/irq-combiner.c
@@ -59,9 +59,6 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
unsigned int cascade_irq, combiner_irq;
unsigned long status;
- /* primary controller ack'ing */
- chip->irq_ack(&desc->irq_data);
-
spin_lock(&irq_controller_lock);
status = __raw_readl(chip_data->base + COMBINER_INT_STATUS);
spin_unlock(&irq_controller_lock);
@@ -79,8 +76,8 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
generic_handle_irq(cascade_irq);
out:
- /* primary controller unmasking */
- chip->irq_unmask(&desc->irq_data);
+ /* primary controller EOI */
+ chip->irq_eoi(&desc->irq_data);
}
static struct irq_chip combiner_chip = {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/6] ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>
The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent
chip prior to handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved
to using the fasteoi flow model.
Acked-by: Colin Cross <ccross@android.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mach-tegra/gpio.c | 17 +----------------
1 files changed, 1 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
index ad80488..5019b01 100644
--- a/arch/arm/mach-tegra/gpio.c
+++ b/arch/arm/mach-tegra/gpio.c
@@ -219,9 +219,6 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
struct tegra_gpio_bank *bank;
int port;
int pin;
- int unmasked = 0;
-
- desc->irq_data.chip->irq_ack(&desc->irq_data);
bank = get_irq_data(irq);
@@ -233,23 +230,11 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
for_each_set_bit(pin, &sta, 8) {
__raw_writel(1 << pin, GPIO_INT_CLR(gpio));
-
- /* if gpio is edge triggered, clear condition
- * before executing the hander so that we don't
- * miss edges
- */
- if (lvl & (0x100 << pin)) {
- unmasked = 1;
- desc->irq_data.chip->irq_unmask(&desc->irq_data);
- }
-
generic_handle_irq(gpio_to_irq(gpio + pin));
}
}
- if (!unmasked)
- desc->irq_data.chip->irq_unmask(&desc->irq_data);
-
+ desc->irq_data.chip->irq_eoi(&desc->irq_data);
}
#ifdef CONFIG_PM
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/6] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>
On OMAP4, gpio_irq_handler can be chained to a physical interrupt using
the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
model, the chained handler must invoke ->irq_eoi once handling is
complete.
This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
for OMAP platforms. For OMAP implementations using other primary
interrupt controllers, the ->irq_ack call remains and is also made
conditional on the support offered by the controller.
Cc: Colin Cross <ccross@google.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-and-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/plat-omap/gpio.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 971d186..1d2d1c7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1144,7 +1144,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
u32 retrigger = 0;
int unmasked = 0;
- desc->irq_data.chip->irq_ack(&desc->irq_data);
+ if (desc->irq_data.chip->irq_ack)
+ desc->irq_data.chip->irq_ack(&desc->irq_data);
bank = get_irq_data(irq);
#ifdef CONFIG_ARCH_OMAP1
@@ -1238,6 +1239,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
exit:
if (!unmasked)
desc->irq_data.chip->irq_unmask(&desc->irq_data);
+ if (desc->irq_data.chip->irq_eoi)
+ desc->irq_data.chip->irq_eoi(&desc->irq_data);
}
static void gpio_irq_shutdown(struct irq_data *d)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/6] ARM: gic: use handle_fasteoi_irq for SPIs
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>
Currently, the gic uses handle_level_irq for handling SPIs (Shared
Peripheral Interrupts), requiring active interrupts to be masked at
the distributor level during IRQ handling.
On a virtualised system, only the CPU interfaces are virtualised in
hardware. Accesses to the distributor must be trapped by the
hypervisor, adding latency to the critical interrupt path in Linux.
This patch modifies the GIC code to use handle_fasteoi_irq for handling
interrupts, which only requires us to signal EOI to the CPU interface
when handling is complete. Cascaded IRQ handling is also updated so
that EOI is signalled after handling.
Note that commit 846afbd1 ("GIC: Dont disable INT in ack callback")
broke cascading interrupts by forgetting to add IRQ masking. This is
no longer an issue because the unmask call is now unnecessary.
Tested on Versatile Express and Realview EB (1176 w/ cascaded GICs).
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/common/gic.c | 23 +++++++++--------------
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 2243772..9def30b 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -71,13 +71,6 @@ static inline unsigned int gic_irq(struct irq_data *d)
/*
* Routines to acknowledge, disable and enable interrupts
*/
-static void gic_ack_irq(struct irq_data *d)
-{
- spin_lock(&irq_controller_lock);
- writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
- spin_unlock(&irq_controller_lock);
-}
-
static void gic_mask_irq(struct irq_data *d)
{
u32 mask = 1 << (d->irq % 32);
@@ -96,6 +89,11 @@ static void gic_unmask_irq(struct irq_data *d)
spin_unlock(&irq_controller_lock);
}
+static void gic_eoi_irq(struct irq_data *d)
+{
+ writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+}
+
static int gic_set_type(struct irq_data *d, unsigned int type)
{
void __iomem *base = gic_dist_base(d);
@@ -174,9 +172,6 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
unsigned int cascade_irq, gic_irq;
unsigned long status;
- /* primary controller ack'ing */
- chip->irq_ack(&desc->irq_data);
-
spin_lock(&irq_controller_lock);
status = readl(chip_data->cpu_base + GIC_CPU_INTACK);
spin_unlock(&irq_controller_lock);
@@ -192,15 +187,15 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
generic_handle_irq(cascade_irq);
out:
- /* primary controller unmasking */
- chip->irq_unmask(&desc->irq_data);
+ /* primary controller EOI */
+ chip->irq_eoi(&desc->irq_data);
}
static struct irq_chip gic_chip = {
.name = "GIC",
- .irq_ack = gic_ack_irq,
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
+ .irq_eoi = gic_eoi_irq,
.irq_set_type = gic_set_type,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
@@ -275,7 +270,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
for (i = irq_start; i < irq_limit; i++) {
set_irq_chip(i, &gic_chip);
set_irq_chip_data(i, gic);
- set_irq_handler(i, handle_level_irq);
+ set_irq_handler(i, handle_fasteoi_irq);
set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 0/6] Migrate GIC to fasteoi flow control
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This is version 2 of the patch series originally posted here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/043083.html
Changes since v1:
* Added plat-nomadik changes after related patch from Rabin
* Fixed msm changes to call irq_eoi correctly
* No longer in quoted-printable encoding (thanks Colin)
This is going to be a PITA to merge so any thoughts relating to that
are welcome.
Thanks,
Will
Will Deacon (6):
ARM: gic: use handle_fasteoi_irq for SPIs
ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
ARM: s5pv310: update IRQ combiner to use EOI in parent chip
ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
arch/arm/common/gic.c | 23 +++++++++--------------
arch/arm/mach-msm/gpio-v2.c | 3 ++-
arch/arm/mach-s5pv310/irq-combiner.c | 7 ++-----
arch/arm/mach-tegra/gpio.c | 17 +----------------
arch/arm/plat-nomadik/gpio.c | 2 ++
arch/arm/plat-omap/gpio.c | 5 ++++-
6 files changed, 20 insertions(+), 37 deletions(-)
^ permalink raw reply
* Linux support for Samsung S3C2510A Processor
From: Ben Dooks @ 2011-02-28 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinBZCQ7Q+BaSxhm62pKiZHhmVWAgNzxnm5jBhZy@mail.gmail.com>
On Mon, Feb 28, 2011 at 06:52:15PM +0530, Madhavi Manchala wrote:
> Dear All,
>
> Does Linux kernel supports the Samsung S3C2510A processor? Why am I
> asking this question is, when I looked into the arch/arm/ directory I
> did not find anything which is related to Samsung S3C2510A processor.
> There are other directories like mach-s3c24xx and mach-s3c64xx
> directories, but not mach-s3c25xx.
>
> Any ideas / hints will be appreciated.
I think this is a no-mmu version, and there is not a lot of ARM no-mmu
support at the moment.
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* Linux support for Samsung S3C2510A Processor
From: Madhavi Manchala @ 2011-02-28 13:22 UTC (permalink / raw)
To: linux-arm-kernel
Dear All,
Does Linux kernel supports the Samsung S3C2510A processor? Why am I
asking this question is, when I looked into the arch/arm/ directory I
did not find anything which is related to Samsung S3C2510A processor.
There are other directories like mach-s3c24xx and mach-s3c64xx
directories, but not mach-s3c25xx.
Any ideas / hints will be appreciated.
Thanks and Regards,
Madhavi M.
^ permalink raw reply
* [patch 2/2] efika mx/sb: enable watchdog
From: Arnaud Patard (Rtp) @ 2011-02-28 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228132132.654689676@rtp-net.org>
An embedded and charset-unspecified text was scrubbed...
Name: wdt.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/0e4de70b/attachment.ksh>
^ permalink raw reply
* [patch 1/2] mc13892: reboot on wdi event
From: Arnaud Patard (Rtp) @ 2011-02-28 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228132132.654689676@rtp-net.org>
An embedded and charset-unspecified text was scrubbed...
Name: mc13892_wdog_reboot.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/562257ca/attachment.ksh>
^ permalink raw reply
* [patch 0/2] Get watchdog reboot working on efika smartbook
From: Arnaud Patard (Rtp) @ 2011-02-28 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
With current patches in Sascha Hauer's tree, the efika smartbook is powering
off when rebooting. The cause of this bug is the default behaviour of the
mc13892 pmic. This patchset is configuring the pmic to reboot the system
as expected by imx system.c (the reboot is done throught watchdog) and enables
the watchdog on the efika mx/sb systems.
Arnaud
^ permalink raw reply
* One quick question about SMP on ARM
From: rocky @ 2011-02-28 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi, all
I am puzzled these day on three issues for SMP ARM in terms of hardware:
1: Is MMU global or per cpu ?
2: Is MicroTLB/MainTLB global or per cpu ?
I read the code, each cpu has to set its own pgd base addr into TBBR0,so I draw the conclusion MMU is per cpu;
ASID is shared between each cpu, while when ASID rollover from 0xff back to 0x0, each cpu has to call local_flush_tlb_all to invalidate I/D tlb; Does that mean MicroTLB/MainTLB is also per cpu; then why all cpu shared ASID from 0x0~0xff ?
I am really confused about this ? any tips
Thanks
rocky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/1bab0b01/attachment-0001.html>
^ permalink raw reply
* [PATCH v2 02/13] da850: pruss platform specific additions.
From: TK, Pratheesh Gangadhar @ 2011-02-28 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297435892-28278-3-git-send-email-subhasish@mistralsolutions.com>
Hi,
> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com
> [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf
> Of Subhasish Ghosh
> Sent: Friday, February 11, 2011 8:21 PM
> To: davinci-linux-open-source at linux.davincidsp.com
> Cc: sachi at mistralsolutions.com; Russell King; Kevin Hilman; Subhasish
> Ghosh; open list; Watkins, Melissa; linux-arm-kernel at lists.infradead.org
> Subject: [PATCH v2 02/13] da850: pruss platform specific additions.
>
> This patch adds the platform device and assignes the platform resources
> for the PRUSS mfd driver.
>
> Signed-off-by: Subhasish Ghosh <subhasish@mistralsolutions.com>
> ---
> +struct platform_device da8xx_pruss_dev = {
Can you please rename this to da8xx_pruss_mfddev?
> + .name = "da8xx_pruss",
Can you please rename name string as pruss_mfd? This will help to
base my UIO patches on top of yours.
> + .id = -1,
> + .num_resources = ARRAY_SIZE(da8xx_pruss_resources),
> + .resource = da8xx_pruss_resources,
> +};
> +
> +int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
Please rename this to da8xx_register_pruss_mfd
Thanks,
Pratheesh
^ permalink raw reply
* [PATCH 1/2] ARM: l2x0: Errata fix for flush by Way operationcan cause data corruption
From: Santosh Shilimkar @ 2011-02-28 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228101351.GA30781@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Monday, February 28, 2011 3:44 PM
> To: Santosh Shilimkar
> Cc: tony at atomide.com; catalin.marinas at arm.com; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/2] ARM: l2x0: Errata fix for flush by Way
> operationcan cause data corruption
>
> On Sun, Feb 27, 2011 at 12:00:21PM +0000, Russell King - ARM Linux
> wrote:
> > > +#else
> > > +/* Optimised out for non-errata case */
> > > +static inline void debug_writel(unsigned long val)
> > > +{
> > > }
> >
> > #define l2x0_set_debug NULL
> >
> > > +#endif
>
> I notice you got rid of the inline function. Have you tried
> building this without the errata enabled?
I accidently dropped the inline function while
incorporating the comment from you. :(
Fixed it. Updated version # 6770/1
Regards,
Santosh
^ 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