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