On Thu, Jun 06, 2019 at 04:40:45PM +0100, Sudeep Holla wrote: > On Thu, Jun 06, 2019 at 10:20:40AM -0500, Jassi Brar wrote: > > 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. > > > > Simple, if 2 protocols share the same channel, then the requests are > serialised. E.g. if bits 0 and 1 are allocated for protocol#1 > and bits 2 and 3 for protocol#2 and protocol#1 has higher latency > requirements like sched-governor DVFS and there are 3-4 pending requests > on protocol#2, then the incoming request for protocol#1 is blocked. >
Any idea on addressing the above with abstraction layer above the driver ? And the bit allotment without the virtual channel representation in DT. These 2 are main issues that needs to be resolved. -- Regards, Sudeep
