Russ Dill <russ.dill@xxxxxxxxx> writes: >>>> ARM world is also moving towards that by standardizing some of these >>>> through (read PSCI) and thats the way to go in general. >>> >>> Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms >>> that don't support it natively. Are you saying that the AM33xx firmware >>> should be converted to be PSCI compliant? Admittedly, I haven't read >>> the PSCI spec closely, but I'm wondering if the current role splitting >>> between MPU and M3 fits well with PSCI. >>> >> I didn't mean for the AM3XXX specifically because its current job is rather >> very limited. i.e suspend. My concern is that IPC is not viewed as >> an option for power management controllers like M3 which can abstract >> all the hardware gory details and export a simpled interface for OS >> in form of PSCI/ACPI. > > The IPC between the M3 and the A8 on the am335x is just a pair of > notification mechanisms (one from the A8, mailbox, and one from the > M3, sev) and a set of 8 32 bit registers. The 8 32 bit registers are > just a scratchpad and have no access rules or functionality beyond > being a scratchpad. How complicated do we want to make this? The OMAP IPC between the MPU and DSP (read: any other remote processor) is just a mailbox and some shared memory. No complicated, and works with remoteproc/rpmsg. What's more complicated? reusing existing frameworks or re-inventing them? Don't forget that "simple" drivers rarely stay that way. Also, this is not a hard stance on my part. I just need to be convinced. The fact is that there are existing frameworks for doing what is being proposed here. Either use the existing frameworks, or make a technical argument based on why those frameworks are not a good fit (ideally, after having tried to use those frameworks.) Once again, I'm pretty sure I mentioned this in earlier reviews of this series. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html