On Thu, Nov 5, 2020 at 10:13 AM Rob Herring wrote: > > On Wed, Nov 4, 2020 at 4:04 PM Jim Quinlan wrote: > > > > On Wed, Nov 4, 2020 at 4:50 PM Rob Herring wrote: > > > > > > On Thu, Oct 29, 2020 at 03:59:06PM -0400, Jim Quinlan wrote: > > > > Bindings are added. Only one interrupt is needed because > > > > we do not yet employ the SCMI p2a channel. > > > > > > I still don't understand what this is. To repeat from v1: I thought SCMI > > > was a mailbox consumer, not provider? > > > > Hi Rob, > > > > I'm not sure where I am implying that SCMI is a mailbox provider? > > Should I not mention "SCMI" in the subject line? > > > > This is just a mailbox driver, "consumed" by SCMI. Our SCMI DT node > > looks like this: > > > > brcm_scmi_mailbox: brcm_scmi_mailbox@0 { > > #mbox-cells = <1>; > > compatible = "brcm,brcmstb-mbox"; > > }; > > > > brcm_scmi@0 { > > compatible = "arm,scmi"; > > mboxes = <&brcm_scmi_mailbox 0>;; > > mbox-names = "tx"; > > shmem = <&NWMBOX>; > > /* ... */ > > }; > > Okay, that makes more sense. Though it seems like this is just adding > a pointless level of indirection to turn an interrupt into a mailbox. > There's nothing more to 'the mailbox' is there? Correct. Although you can see that it uses both interrupts and SMC calls to get the job done. > So why not either > allow SCMI to have an interrupt directly Not sure here -- perhaps the SCMI folks have an answer? > or have a generic irq mailbox > driver? The SCMI implementation doesn't offer a generic irq mailbox driver AFAICT. The SCMI folks recently provided an "smc transport" driver in "drivers/firmware/arm_scmi/smc.c" -- it is close to what we need but is missing interrupts. Regards, Jim Quinlan Broadcom STB > > Rob