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

[nsekhar@ti.com (Sekhar Nori)]

On 12/4/2012 1:43 AM, Cyril Chemparathy wrote:

> On 12/03/2012 09:41 AM, Sekhar Nori wrote:

>> On 12/1/2012 7:41 AM, Tivy, Robert wrote:

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

> Not sure if this solves your problem, but you could add a new clock type
> (PSC_LRESET?) as a child under the PSC clock node for the DSP. Something
> like:
> 
>   |
>   +-- PSC x (DSP0 clock)
>   |    |
>   |    +-- PSC-LRESET x (DSP0 reset control)
>   |
>   +-- PSC y (DSP1 clock)
>   |    |
>   |    +-- PSC-LRESET y (DSP1 reset control)
>   |
>   +-- PSC z (DSP2 clock)
>   |    |
>   |    +-- PSC-LRESET z (DSP2 reset control)
> 
> 
> The idea here being that if you enable the PSC clocks, you enable the
> clock gates, but leave the DSPs in reset.  On the other hand, if you
> enable the reset clock, the code implicitly enables the gate (via
> parent), and takes the DSP out of reset as well.
> 
> This is not quite the cleanest way to do it, considering that reset
> lines have no business in the clock tree, but then, this is probably the
> simplest way to fit in.  Thoughts?

This may work (on a technical level), but I am not really a fan of this
since this is essentially a hack, as you (almost) point out. It does not
model the hardware clock tree correctly and we are still struck with
using clock APIs for reset control.

I still think we need to find a better method of dealing with IP reset.
May be an acceptable method already exists. Some one needs to summarize
the problem statement well enough and I am sure finding the right
solution will not be too long drawn.

Thanks,
Sekhar