On 12/04/2012 09:53 AM, Murali Karicheri wrote:
On 12/04/2012 12:58 AM, Sekhar Nori wrote:
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
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
I believe this is addressing the same issue. This is a DT based
solution, which I believe should add a framework and enhance it to
support DT.
Forgot to paste the link. Here we go
https://patchwork.kernel.org/patch/1635051/
Murali
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
