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. There is a handful of different clients each using these doorbells to inform the other side that something has happened (often that some piece of shared memory has been filled with data). Over the years (platforms) this register has moved around as such multiple implementations exists. You can see an example of this in drivers/mailbox/qcom-apcs-ipc-mailbox.c and e.g. drivers/rpmsg/qcom_glink_native.c (qcom_glink_rpm.c prior to v4.14). I'm struggling to figure out exactly how your case looks like, but if your doorbell exists in only one instance and there is only one client then I would suggest that it's overkill to create another driver for it. Regards, Bjorn -- 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
