On Mon, May 18, 2020 at 11:05:03PM -0500, Jassi Brar wrote: > On Mon, May 18, 2020 at 10:40 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > > > 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 > > :) > > > H/W is actually fine :) Its just that the driver is written to > _also_ support a platform (my original) that doesn't have shmem and > need to pass data via 32bit registers. > Frankly, I am not against the doorbell mode, I am against implementing > two modes in a driver. If it really helped (note the past tense) the > SCMI, we could implement the driver only in doorbell mode but > unfortunately SCMI would still be _broken_ for non-doorbell > controllers. Should be fine as the specification is designed to work with only shmem for any data transfer and mailbox is just a signal mechanism. I won't be too worried about that. -- Regards, Sudeep
