On Fri, Nov 30, 2012 at 08:54:32AM +0200, Terje Bergström wrote: > On 29.11.2012 20:34, Stephen Warren wrote: > > On 11/29/2012 03:21 AM, Terje Bergström wrote: > >> True. I might also as well delete the general interrupt altogether, as > >> we don't use it for any real purpose. > > > > Do make sure the interrupts still are part of the DT binding though, so > > that the binding fully describes the HW, and the interrupt is available > > to retrieve if we ever do use it in the future. > > Sure, I will just not use the generic irq in DT, but it won't require > any changes in DT bindings. > > > You can still create tables of clocks inside the driver and loop over > > them. So, loop unrolling isn't related to my comments at least. It's > > just that clk_get() shouldn't take its parameters from platform data. > > > > But if these are clocks for (arbitrary) child modules (that may or may > > not exist dynamically), why aren't the drivers for the child modules > > managing them? > > There are actually two things here that I mixed, and because of that I > probably confused everybody else. > > Let's rip out the ACM. ACM is generic to all modules, and in nvhost owns > the clocks. That's why list of clocks and their frequency policies have > been part of the device description in nvhost. ACM is being replaced > with runtime PM in downstream kernel, but it still requires rigorous > testing and analysis of power profile before we can move to it. > > Then, the second thing is that nvhost_probe() has had its own loop to go > through the clocks of host1x module. It's copy-paste of what ACM did, > which is just bad design. That's easily replaceable with static code, as > nvhost_probe() is just for host1x. I'll do that, and as I rip out the > generic power management code, I'll also make 2D and host1x drivers > enable the clocks at probe with static code. > > So I think we have a solution that resonates with all proposals. Yes, that sounds good to me. Thierry
Attachment:
pgpv7Nug412Pq.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
