[PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP

[Sekhar Nori]

Hi Rob,

On 12/1/2012 7:41 AM, Tivy, Robert wrote:
> Hi Sekhar,
> 
>> -----Original Message-----
>> From: Nori, Sekhar
>> Sent: Friday, November 30, 2012 2:51 AM
>> To: Tivy, Robert
>> Cc: davinci-linux-open-source at linux.davincidsp.com; linux-arm-
>> kernel at lists.infradead.org; Ring, Chris; Grosen, Mark
>> Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for
>> OMAP-L138 DSP
>>
>> Hi Rob,
>>
>> On 11/29/2012 7:08 AM, Tivy, Robert wrote:
>>> Hi Sekhar,
>>>
>>> Please see comments and noob questions below...
>>>
>>>> -----Original Message-----
>>>> From: Nori, Sekhar
>>>> Sent: Tuesday, November 20, 2012 4:27 AM
>>>> To: Tivy, Robert
>>>> Cc: davinci-linux-open-source at linux.davincidsp.com; linux-arm-
>>>> kernel at lists.infradead.org; Ring, Chris; Grosen, Mark
>>>> Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support
>>>> for
>>>> OMAP-L138 DSP
>>>>
>>>> On 11/14/2012 6:03 AM, Robert Tivy wrote:
>>>>> Requires CMA services.
>>>>>
>>>>> New 'clk_reset()' API added so that the DSP's reset state can be
>>>>> toggled separately from its enable/disable operation.
>>>>
>>>> But we cannot add a private clk_ API without it being defined in
>>>> include/linux/clk.h. So, this requires wider alignment.
>>>>
>>>> And I am not sure clock API should be extended to support reset
>> since
>>>> "resetting a clock" does not make a lot of sense. On DaVinci, clock
>>>> gating and reset are handled by the same module, but that need not
>>>> always be the case.
>>>>
>>>> What you need is a way to reset an IP. I do not know of an existing
>>>> framework to do this; likely a new API needs to be created. I am
>>>> guessing this never existed so far because most of the IPs can be
>>>> reset internally (by writing a bit within its own register space). I
>>>> guess DSP is different since its actually a co-processor and may not
>>>> have such a bit.
>>>>
>>>> How about simulating a reset by making the DSP jump to its reset
>>>> address. While I am sure its not quite the same as resetting the DSP
>>>> using PSC, may be it could be used while you wait for consensus
>>>> around handling module reset in kernel?
>>>
>>> Since the ARM can't write the DSP's program counter I suspect such a
>> temporary solution is not possible.
>>
>> Okay. I think the way forward on this is to start a separate thread
>> including the ARM list, LKML and the remoteproc folks to see if it
>> makes sense to create a reset API in kernel. You can describe the
>> usecase you have.
> 
> Instead of fighting that fight, I thought of another way.  The da8xx_dsp platform_device has private data registered in its device struct.  This private data can contain a function pointer for a "DSP reset" function, and davinci_remoteproc.c can call the registered function.  Does that sound OK?

Passing function pointers from platform code will not work when
converting to device tree (DT). DA850 will gain DT boot with v3.8 and
there is work ongoing on converting drivers to be DT-aware. Adding a new
driver which is DT-incompatible will not be right. Hence, I will not
recommend this now.

Thanks,
Sekhar