On 06/07/17 15:37, Jassi Brar wrote: > On Thu, Jul 6, 2017 at 3:03 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: [...] >> >> I said it *may not be used*, currently it is used. >> > SCPI provides more than what SCMI currently does - dvfs, clock, sensor. Not sure what you mean by that, but that's not true. > I see no reason why you must have SCPI and SCMI both running. > We can still have 2 different protocols using same MHU channel with different doorbells, what's wrong with that ? > And even then there is a solution - a shim arbitrator. Other > platforms, those share a channel, do that. No big deal. > Example please ? Please remember these protocols are generic and we can't add any platform specific code into them. > 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. Why ? Clearly you have not made a since technical argument so far as why MHU doorbell is not correct way even when MHU specification is clearly allows it. I have given example of ST mailbox which has this doorbell kind of support. > I see your confusion in the form of some issues in the SCMI > implementation, please CC me on the next revision. > Care to elaborate on what's my confusion or at-least what you think so ? Also if you have concern on implementation, ok we can discuss further. But can you make it clear as what your objections are for the doorbell MHU binding. How will I get the bit assigned for different protocols which are platform specific ? I still need some binding , right ? -- Regards, Sudeep -- 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
