Re: Configurable interrupt sources, and DT bindings

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

On Fri, Dec 02, 2011 at 11:27:22AM +0000, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 04:38:14PM +1100, David Gibson wrote:
> > On Thu, Dec 01, 2011 at 11:07:39AM +0000, Mark Brown wrote:
> 
> > > Right, but you could stuff those in an enormous array or whatever - the
> > > point was to describe the per interrupt information.
> 
> > Well, ok, but that's not what you proposed.  In any case putting
> 
> Please stop claiming this, it's incredibly irritating.  At *no* point
> have I suggested making the interrupt type a global property of the
> interrupt controller, that would be silly.  What I did do was mistakenly
> assume that the binding would be something more device tree like than a
> table of magic numbers which you then projected into a desire to make
> this a global property of the interrupt controller.

No, you suggested it be a global property of the interrupt source.
Same problem, just less so.

> > important irq type information anywhere othrt than the irq specifers
> > listed in the 'interrupts' property is not a good idea.  It would be
> > breakin to overall model of the DT interrupt tree with poor
> > justification.
> 
> I do think there's a reasonable case for just creatinng a new version of
> the binding which is more readable but perhaps that's just me.
> 
> > > Well, then it'd be good if we could get that written up as a spec and
> > > factor out the parsing code then start pushing back very strongly on any
> > > new bindings that don't follow the spec.  
> 
> > Well, write up a best practice document and get it up on
> > devicetree.org.  I think you overestimate the problem though.  The
> > specific case you've described can be handled with an in-kernel
> > mechanism for the irq controller driver to advertise the irq type back
> > to the irq source's driver - no DT change necessary, and it even
> > handles all the legacy cases.
> 
> The in kernel bit of this is already fine, the problem is on the device
> tree side.
> 
> > > I don't think so really - it seems like what you're saying is "there's a
> > > place where people could put this information in a device specific
> > > fashion" and I'm looking for something that's not device specific as
> > > this is a general need and we shouldn't have to be doing device specific 
> > > things here.
> 
> > It'd be nice, but it's just not worth breaking away from existing
> > practice to achieve it.  Remember that more or less by definition, we
> > *already have* code to interpret the device specific tokens (in the
> > irq controller driver).
> 
> Not in the real world, in the real world we don't have device tree
> bindings for most of the interrupt controllers out there and therefore
> no code exists to parse them.  There's a fairly small set of current
> systems using device tree and a very large set of systems which have
> never used it before and are currently working on implementing it.

If we support the PIC at all, it must know how to determine the
interrupt types.  When DT support is added to the PIC, that will
include determining the type from the interrupt specifiers.  If we
don't support the PIC, we don't care.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson