On 18-05-20, 18:29, Bjorn Andersson wrote: > On Thu 14 May 22:17 PDT 2020, Viresh Kumar wrote: > > This stuff has been doing rounds on the mailing list since several years > > now with no agreed conclusion by all the parties. And here is another > > attempt to get some feedback from everyone involved to close this once > > and for ever. Your comments will very much be appreciated. > > > > The ARM MHU is defined here in the TRM [1] for your reference, which > > states following: > > > > "The MHU drives the signal using a 32-bit register, with all 32 > > bits logically ORed together. The MHU provides a set of > > registers to enable software to set, clear, and check the status > > of each of the bits of this register independently. The use of > > 32 bits for each interrupt line enables software to provide more > > information about the source of the interrupt. For example, each > > bit of the register can be associated with a type of event that > > can contribute to raising the interrupt." > > > > Does this mean that there are 32 different signals and they are all ORed > into the same interrupt line to trigger software action when something > happens? > > Or does it mean that this register is used to pass multi-bit information > and when any such information is passed an interrupt will be triggered? > If so, what does that information mean? How is it tied into other Linux > drivers/subsystems? I have started to believe the hardware is written badly at this point :) The thing is that the register can be used to send a 32 bit data (which the driver already provides), or it can be used by writing different bits to the SET register concurrently, without corrupting the other bits as writing 0 to a bit has no effect, we have a separate CLEAR register for that. And so it says that all the bits are ORed together to generate the interrupt, i.e. any bit set will generate an interrupt. Which also means that you can't send data 0 with the register. -- viresh
