[PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
khilman at linaro.org
Tue Aug 13 15:11:05 EDT 2013
Russ Dill <russ.dill at gmail.com> 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
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
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
More information about the linux-arm-kernel