Thought I'd comment too on the interrupt question for the block-level (not portal-level) node;
> -----Original Message----- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: October-23-14 7:26 AM > To: Medve Emilian-EMMEDVE1 > > [...] > > > > You also seem to have an interrupt in the example. How many do you > > > expect, and what are their their logical functions? > > > > That's the error interrupt and hopefully it never triggers. I didn't > add > > [many] words about it as it's a standard property > > While the interrupts property is standard, it is only standard in the > sense that the name and format are standard. Not every bidning has an > interrupts property, and the set of interrupts described are specific > to > the binding. Please describe the set of interrupts you expect. > > Does the device only have the error interrupt, or is that the only > interrupt you care about? So as with the portals, the blocks themselves each have a single interrupt line, but a number of the (CCSR) registers are related to that interrupt to capture the codes and attributes of the various error conditions being reported, because a wide variety of events and information can be conveyed through that interrupt line. In general, yes, this interrupt line is only for "errors", but some errors are more equal than others. Eg. there is the usual class of catastrophic DMA-failure, ECC, hardware-internal-inconsistency types of errors that devices tend to shout about. But there are also threshold-based "resource starvation" types of "errors" too, which are not really errors per se, unless the system configuration and use-case is explicitly engineered and constrained such that the thresholds shouldn't ever get tripped. So the handling of the interrupt involves interrogating registers to classify the why, how, and what, and the reaction to it (whether a write-to-clear is needed, whether it should be masked, whether functionality should be halted, ...) is also a fairly elaborate question. I don't know what the expectations are for these "bindings" docs, but the request to "describe the set of interrupts you expect" does risk opening a fairly elaborate can of worms (that may be better confined to the driver). Unless I misunderstood the request, which is always quite possible before my second coffee... Cheers, Geoff _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
