On Sat, Apr 13, 2013 at 10:33:22PM +0100, Grant Likely wrote:
> On Tue, 5 Mar 2013 09:28:49 +, Mark Rutland wrote:
> > On Mon, Mar 04, 2013 at 02:51:14AM +, Grant Likely wrote:
> > > I could use some more context for how this will be used. Do device
> > > drivers need to be aware of which
On Tue, 5 Mar 2013 09:28:49 +, Mark Rutland wrote:
> On Mon, Mar 04, 2013 at 02:51:14AM +, Grant Likely wrote:
> > I could use some more context for how this will be used. Do device
> > drivers need to be aware of which CPU can handle an interrupt for a
> > device, or is it the sort of thi
On Mon, Mar 04, 2013 at 02:51:14AM +, Grant Likely wrote:
> On Thu, 13 Dec 2012 16:49:26 +, Mark Rutland wrote:
> > [This is an updated version of my previous RFC, which can be found at
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/128205.html]
> >
> > Current dev
On Thu, 13 Dec 2012 16:49:26 +, Mark Rutland wrote:
> [This is an updated version of my previous RFC, which can be found at
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/128205.html]
>
> Current devicetree bindings for devices which use cpu-affine shared interrupts
> as
[This is an updated version of my previous RFC, which can be found at
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/128205.html]
Current devicetree bindings for devices which use cpu-affine shared interrupts
assume that interrupts are listed in ascending order of physical cpu
