Hello, On Mon, 16 Jul 2018 09:27:34 -0600, Rob Herring wrote: > > +Required properties for the icu_nsr/icu_sei subnodes: > > + > > +- compatible: Should be "marvell,cp110-icu-nsr" or "marvell,cp110-icu-sei". > > + > > I raised this before and still don't understand. You had 4 types before > and now you only have 2 types? How do you handle SR and REI with the new > binding? As I replied to a different e-mail, the current binding pretended to support SR, SEI and REI, but it definitely could not. The ICU collects wired interrupts from the CP, and forwards them to the AP as MSIs. And contrary to what we thought when designing the current binding, the target of the MSIs is different depending on the type of interrupt. NSRs go to the GICP controller in the AP, SEIs go to a special SEI controller in the AP, REIs go to a special REI controller in the AP. In order to represent that in the Device Tree, you need to have a different msi-parent property for each of NSR, SEI and REI. This is not something that the current broken binding allows to express, and it's the reason why we're migrating to this new binding. So even if the current binding documents that it supports NSR, SEI, REI and SR, it definitely cannot support anything but NSR. Therefore, the introduction of the new binding by Miquèl does not introduce any regression in functionality: it simply allows to really support SEIs. Does this explanation clarify the situation, and what we're trying to achieve ? Thanks! Thomas -- Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- 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
