On Thu, Jun 6, 2019 at 7:51 AM Sudeep Holla <sudeep.ho...@arm.com> wrote:
> > > BTW, this is not going to be the end of SCMI troubles (I believe > > that's what his client is). SCMI will eventually have to be broken up > > in layers (protocol and transport) for many legit platforms to use it. > > That is mbox_send_message() will have to be replaced by, say, > > platform_mbox_send() in drivers/firmware/arm_scmi/driver.c OR the > > platforms have to have shmem and each mailbox controller driver (that > > could ever be used under scmi) will have to implement "doorbell > > emulation" mode. That is the reason I am not letting the way paved for > > such emulations. > > > > While I don't dislike or disagree with separate transport in SCMI which > I have invested time and realised that I will duplicate mailbox framework > at the end. > Can you please share the code? Or is it no more available? > So I am against it only because of duplication and extra > layer of indirection which has performance impact(we have this seen in > sched governor for DVFS). > I don't see why the overhead should increase noticeably. > So idea wise, it's good and I don't disagree > with practically seen performance impact. Hence I thought it's sane to > do something I am proposing. > Please suggest how is SCMI supposed to work on ~15 controllers upstream (except tegra-hsp) ? > It also avoids coming up with virtual DT > nodes for this layer of abstract which I am completely against. > I don't see why virtual DT nodes would be needed for platform layer.