On Thu, Jul 6, 2017 at 3:03 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > On 06/07/17 10:27, Jassi Brar wrote: >> On Thu, Jul 6, 2017 at 2:48 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: >>> Hi Jassi, >>> >>> On 06/07/17 07:28, Jassi Brar wrote: >>>> On Wed, Jul 5, 2017 at 11:32 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: >>>> >>>>> >>>>> I have posted the SCMI patches now[1], >>>>> >>>> I wish I was CC'ed on that. Now LKML seems too busy to forward it. >>>> >>> >>> Yes, my mistake, I should have cc-ed you. >>> >>>>> please let me know how to get >>>>> both SCPI and SCMI working together with different doorbell bits on the >>>>> same channel. >>>>> >>>> You say in the cover letter : >>>> "Let me begin admitting that we are introducing yet another protocol to >>>> achieve same things as many existing protocols like ARM SCPI, TI SCI, >>>> QCOM RPM, Nvidia Tegra BPMP, and so on" >>>> >>>> So SCMI is supposed to replace SCPI, SCI, RPM and BPMP or SCMI is >>>> to be used for future platforms. >>>> If SCPI and SCMI achieve the same, why have them both active simultaneously? >>>> >>> >>> Yes it may not be used, but the firmware might support both for backward >>> compatibility. E.g. on Juno, we still may continue supporting SCPI while >>> we transition to SCMI. So both old and new DTs must work. >>> >> Sure, but still there is no reason to have both SCMI and SCPI active >> during _runtime_. >> Either SCMI or SCPI should be populated by DT, not both. >> >>>> Assuming there really is some sane excuse :- >>> >>> Yes as I mentioned above. >>> >> If you specify only one of SCPI/SCMI, you wouldn't need the shim arbitrator. >> > > I said it *may not be used*, currently it is used. > SCPI provides more than what SCMI currently does - dvfs, clock, sensor. I see no reason why you must have SCPI and SCMI both running. And even then there is a solution - a shim arbitrator. Other platforms, those share a channel, do that. No big deal. BTW, I hope you realise that we need a 'transport layer' which will be the platform specific glue between mailbox controller specifics and the generic SCMI code. I see your confusion in the form of some issues in the SCMI implementation, please CC me on the next revision. Thanks. -- 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
