[PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs

[Kevin Hilman]

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
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