On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but that will cut me from email as I use it as
On Fri, May 03, 2013 at 12:37:20AM +0200, Sebastian Hesselbarth wrote:
(@Jason C: Are you sure that I should merge dove and orion
irqchip patches? I doubt that anything touching generic irq
will not go through irq tree.)
Putting them in the same patch series does not imply they have to go
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note: This patch
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove,
On Thu, May 02, 2013 at 08:54:20PM +0200, Sebastian Hesselbarth wrote:
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main
On 05/02/13 20:56, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:54:20PM +0200, Sebastian Hesselbarth wrote:
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth
On 05/02/13 20:53, Jason Gunthorpe wrote:
On Thu, May 02, 2013 at 08:25:04PM +0200, Sebastian Hesselbarth wrote:
+
+static void __iomem *orion_irq_base[ORION_MAX_IRQREG];
+static unsigned int orion_irq_regs;
+static struct irq_domain *orion_irq_domain;
+
+asmlinkage void __exception_irq_entry
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string? Looks to me
like either the new driver or
On Thu, May 02, 2013 at 08:25:04PM +0200, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by:
On 05/02/2013 09:11 PM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string?
On Thu, May 02, 2013 at 09:05:38PM +0200, Sebastian Hesselbarth wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string? Looks to me
like either
On Thu, May 02, 2013 at 09:34:30PM +0200, Sebastian Hesselbarth wrote:
The compatible string should change if the binding changes in an
incomptible way, and we should try not to change it unless it's
fundamentally flawed.
Well, there is no _fundamental_ change in the binding syntax as it
On 05/02/2013 09:34 PM, Sebastian Hesselbarth wrote:
On 05/02/2013 09:11 PM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but that will cut me from email as I use it as
relay server ;) Maybe I can turn it into a test bed for a while.
There
On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but that will cut me from email as I use it as
On 05/02/2013 10:02 PM, Andrew Lunn wrote:
On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but
Sebastian,
please do not take the rant below personally. You just happen to
trigger it.
On Thu, 2 May 2013, Sebastian Hesselbarth wrote:
+static void orion_irq_mask(struct irq_data *irqd)
+{
+ unsigned int irq = irqd_to_hwirq(irqd);
+ unsigned int irq_off = irq % 32;
+ int reg
On 05/02/2013 11:34 PM, Thomas Gleixner wrote:
please do not take the rant below personally. You just happen to
trigger it.
Thomas,
it is okay for me - but thanks for the notice! I will comment below.
On Thu, 2 May 2013, Sebastian Hesselbarth wrote:
+static void orion_irq_mask(struct
On Thursday 02 May 2013, Sebastian Hesselbarth wrote:
Just look at the various implementations in drivers/irqchip/ and find
out how similar they are. Moving code to drivers/irqchip/ does not
make an excuse for reestablishing the mess which was addressed by the
generic irq chip
On 05/03/2013 12:09 AM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Sebastian Hesselbarth wrote:
Just look at the various implementations in drivers/irqchip/ and find
out how similar they are. Moving code to drivers/irqchip/ does not
make an excuse for reestablishing the mess which was
22 matches
Mail list logo
