On Sun, 24 Nov 2013 17:04:52 +1000, Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx> wrote: > On Wed, Nov 13, 2013 at 4:14 PM, Grant Likely <grant.likely@xxxxxxxxxx> wrote: > > On Wed, 13 Nov 2013 09:17:01 +1000, Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx> wrote: > >> It's going to get a little verbose once you start making multiple > >> connections as you need one mux per wire. Perhaps it could be cleaned > >> up by making the foo_irq_mux node(s) a child of foo? > > > > It could, but then you need some way of attaching a driver to that node, > > and that would require building knowledge into the driver again. > > > > Can you boil it down to a couple of concrete examples? What is a > > specific example of how the platform should decide which interrupt line > > to use? > > > > So i've spent some time playing with this. I now have a booting kernel > with multiple root interrupt controllers and peripheral devices > multiply-connected to both root controllers. But only one on of the > controllers is used by Linux (as linux being able to use multiple > intcs is a non-trivial problem). So the scheme I am using is to have > one of these root intc's marked as disabled via Multiple intc's should be a solved problem. What issue are you seeing? Or is this a microblaze specific problem? > Working with Michal to get my patches in a list-ready state. Can you > suggest a candidate tree we should base of for contributions to > drivers/of/irq.c given your recent work? Linux-next. It is always linux-next. :-) g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
