On Fri, Oct 13, 2017 at 7:12 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > Hi Bjorn, > > Thanks for taking a look at this. Much appreciated. > > On 12/10/17 22:03, Bjorn Andersson wrote: >> On Fri, Oct 6, 2017 at 6:51 AM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: >>> >>> >>> On 06/10/17 14:47, Jassi Brar wrote: >>>> On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: >> [..] >>>>> Again that's not the point, doorbell is more common feature and that can >>>>> be supported. As SCMI expects doorbell feature in the specification, it >>>>> just need to support that class of controllers. >>>>> >>>> NO. All SCMI expects is SHMEM and a signal reaching the other end. >>>> The signal mechanism need not necessarily be "doorbell". >>>> >>> >>> Agreed, but creating an abstraction ro do something as generic as >>> doorbell and writing shim layer for each controller to use SCMI also >>> sounds bad. >>> >> >> In the Qualcomm platform we have a single register that exposes 32 >> doorbells, wired to interrupts on the various processors/co-processors >> in the SoC. >> > > It's exactly same even on ARM MHU controller. > This has been a big problem in our communication. You start with "exactly same..." and go on telling the difference. And that difference is important. In MHU the 32bits are tied together and all go to one target processor. Whereas on QCom, each bit corresponds to independent signal going to a different target processor. IOW, QCom has 32 channels per register whereas MHU has one. The current drivers reflect that reality and hence I am against any change in MHU driver. Not to mean even changing the MHU driver will fix the core issue - which is https://lkml.org/lkml/2017/7/7/465 and this patchset tries to address that. -- 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
