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

[Russ Dill]

On Wed, Aug 14, 2013 at 10:27 AM, Suman Anna <s-anna at ti.com> wrote:
> Kevin, Santosh, Dave, Russ,
>
> On 08/13/2013 02:11 PM, Kevin Hilman wrote:
>> 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.
>
> I had to catch up on all the threads before I responded, but here are my
> notes regarding using remoteproc/rpmsg infrastructure for WkupM3. It
> definitely brings in lot more complexity than what's present today. The
> WkupM3 in AM335x does not have the same feature set as the Cortex-M3s
> used within the IPU in OMAP4+ SoCs. It does not have an MMU and
> peripheral accesses seems to be limited to just those in L4_Wkup domain.
>
> A lot actually depends on whether the WkupM3 can use DDR. I am not sure
> if there are any restrictions on WkupM3 from where it could run the code
> or access data from. From what I can gather from the TRM (there's no big
> separate chapter on WkupM3), it has just 16K UMEM and a 8K DMEM, and its
> not much. The current firmware is loaded directly into the WkupM3's
> internal UMem space and a check is being performed to make sure the
> firmware is less than  16K, so that it can fit into UMem.

Even if the WkupM3 could access DMEM, it would defeat the whole
purpose of using it, as it lives to do things like enable VTP, but the
EMIF clocks into bypass, turn off the power domain the EMIF is
contained in, etc.

> The remoteproc infrastructure is currently tied closely with the
> virtio/rpmsg framework, and the boot requires that there are virtio
> devices present in the resource table from the firmware image. The rpmsg
> shared memory buffers are currently kinda fixed (512 buffers of 512
> bytes each) and requires 3 pages just for the vring structures for this
> many buffers. So, if there are restrictions on DDR access, then this
> pretty much rules out remoteproc/rpmsg infrastructure.
>
> If the DDR access is ok, then there are other challenges that needs to
> be met. The current firmware definitely requires the addition of the
> resource table and the lower level code for handling the virtio_ring
> transport for receiving messages. It would also need its own remoteproc
> driver for handling the firmware binary format and the signalling
> required to trigger the rpmsg buffer processing. The firmware binary
> format needs to be adapted to something that this driver would
> understand. It definitely doesn't look like ELF currently, so something
> on the lines of ste_modem_rproc needs to be done. Also, the
> remoteproc/rpmsg infrastructure can support multiple vring transport
> channels between the processor, and depending on how many are supported,
> we either need to exchange the vq_id (like OMAP remoteproc), or process
> the known virtqueues always (like DA8xx remoteproc). The former requires
> that a message payload is used, and mandates the usage of the IPC data
> registers in the control module given that WkupM3 on AM335 cannot access
> any mailbox registers. Any usage of IPC data registers depends on where
> we do it. If all the accesses were to be done within
> mach-omap2/control.c, then there is no easy way for using this API from
> drivers/remoteproc, until we have the control module driver. I do feel
> that this needs to be done within the wkup_m3 driver currently. This
> would be no different to the crossbar driver example on DRA7, which also
> has to deal with registers in Control module. The IPC data registers do
> not have any associated interrupts by itself, so just making this a
> standalone driver is also not possible. Also, the dependencies with
> using the omap_device API for dealing with the hard reset lines needs to
> be dealt with.
>
> The current communication uses the IPC data registers, and sometimes
> uses them as plain status registers. There's certain registers used for
> sharing status, version etc which are shared by both the processors.
> Using rpmsg would require communicating every single message, and if
> there were to be some shared variables to be used simultaneously, then
> this has to be exchanged through a new remoteproc resource type.
>
> One additional aspect is that the current remoteproc core does not have
> the necessary runtime pm support, but in general the approach would be
> to treat the remoteprocs as true slave devices. I would imagine the
> driver core to put the remoteprocs into reset state, after asking them
> to save their context during suspend.
>
> regards
> Suman
>