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

[Kevin Hilman]

Dave Gerlach <d-gerlach at ti.com> writes:

> On 08/09/2013 12:11 AM, Tony Lindgren wrote:
>> * Dave Gerlach <d-gerlach at ti.com> [130808 09:23]:
>>> On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
>>>> Lets address the above better. I don't see a need of 8 functions
>>>> exported doing one or 2 register writes.
>>>>
>>>> Look M3 based handling is going to be there on future SOCs
>>>> as well and this kind of handling of IPC is very short cited.
>>>>
>>>
>>> The idea here was to move all control module register accesses into
>>> one file in planning of implementing a driver for the control module
>>> itself in the future.
>>>
>>>> Probably we should have a separate driver for M3 in linux which
>>>> can have all this local code instead of all these exports.
>>>
>>> The wkup_m3 code has been moved to a small driver found in patch 8
>>> of this series, would it better to move this code there rather than
>>> with the rest of the control module code?
>>
>> Please make everything you can into regular device drivers.
>>
>> We still have some dependencies to mach-omap2 code for PRCM
>> for example, but we're trying to get all that to live in
>> drivers.
>>
>> So for new pieces, let's not add further dependencies to
>> complicate moving things to drivers.
>>
>> Regards,
>>
>> Tony
>>
>
> Ok I will go ahead and pull the control module code that handles IPC
> into the wkup_m3 driver. 

Any control module register access still needs to stay in control.c.

> The wkup_m3.c file is still present in mach-omap2 as the right
> location for it wasn't decided in the last RFC. Any thoughts on a good
> location for it?

I raised this also in earlier reviews, but don't remember the if it was
answered... 

Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of
creating another little driver that duplicates communication with the
M3.  Note also that the firmware load part would also be provided by
remoteproc/rpmsg.

Kevin