> > On Wed, Apr 17, 2019 at 02:30:53PM +0000, Jacky Bai wrote: > > > > Hi Lucas, > > > > Either SCMI or SCPI, I think it is initially designed for SOC that has > > dedicated SCP to manage the SOC resource, but for i.MX8M, we don't > > have such support. so just for the power domain support, do you have > > other suggestion for it. > > > > I disagree, I thought it was clear from my earlier email. All OSPM like Linux > kernel cares is conformance to the interface. And SCMI/SCPI kind of interface > doesn't mandate how to implement either at the hardware (you may or may > not have dedicated processor) or software level(can do it in TF-A through SMC, > or some remote process through mailbox) > For the current SCMI/SCPI driver in mainline kernel, no SCMI/SCPI over SMC support, right? If we want to make SCMI over SMC as a standard support, does ARM have some suggestion or plan? :) > I am clearly against the custom SMC: > > 1. It will never end and it's put together without much design thoughts > just to address specific need of the hour. > 2. It gets obsolete very soon, mainly because of (1) 3. Very platform and > vendor specific and soon we will find ourselves > in ocean of such custom calls > > And I can definitely continue the list, but I have made the point. > I think we already have enough of those custom SMC already now and it's > high time to stop that non-sense for OSPM. > >From the ARM SMC calling convention, the SIP service call is designed to provide SOC specific service, for example, Secure platform initialization, configuration and some power control. I am confused if upstream kernel will never accept SIP service patch. >From the SCMI spec, it provide the clock management for enable/disable/set_rate, But don't have set_parent support, for i.MX8M platform, we have the requirement to set clock parent explicitly. If we move to use SCMI framework, how do handle the set parent? > -- > Regards, > Sudeep