[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140329101903.65848c12@skate>
Date: Sat, 29 Mar 2014 10:19:03 +0100
From: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To: Boris BREZILLON <b.brezillon.dev@...il.com>
Cc: Rob Landley <rob@...dley.net>,
Nicolas Ferre <nicolas.ferre@...el.com>,
Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
Thomas Gleixner <tglx@...utronix.de>,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v2 07/10] irqchip: atmel-aic: document new dt
properties and children nodes
Dear Boris BREZILLON,
On Fri, 28 Mar 2014 18:59:05 +0100, Boris BREZILLON wrote:
> +Optional children nodes:
> +- muxed irq entries:
> + Required properties:
> + * compatible: Shall be
> + "atmel,aic-mux-1reg-irq": irq enable/disable/retrieve-status is done by
> + setting/clearing/reading flags in a specific register
> + or
> + "atmel,aic-mux-3reg-irq": irq enable/disable/retrieve-status is done
> + by writing/reading flags in specific enable/disable/mask registers
> + * reg: encode the interrupt control register.
> + The first cell encode the irq line.
> + The second cell encode the offset register within its iomem range
> + The last cell encode the iomem region size (should always be set to 0x4).
> + * atmel,aic-mux-reg-mask: define the mask used to disable the interrupts
> + generated by the muxed entry.
Can you describe in more details what are these muxed irqs? Are they
interrupts raised to the AIC that may actually be related to several
devices, like a shared interrupt?
If that's the case, then what you want is to implement separate
interrupt controller drivers to handle those shared interrupts, and
demux them into multiple separate interrupts.
Note that the way you use the "ranges" property seems wrong to me:
you're using it as a "hack" to define the base address of some
peripherals that are outside the AIC, while the ranges property is
normally used to describe the address translations between a child bus
and a parent bus. Which is not what you have here, as far as I can
understand.
So could you give more details about the design of the AIC and these
muxed interrupts, to see if the DT binding you're proposing is actually
the right way of representing the hardware?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists