On Sat, Nov 6, 2010 at 2:11 PM, Cousson, Benoit <b-cous...@ti.com> wrote: > On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: >> >> iommu driver is meant to provide control of mmu hardware blocks > > A dot is missing here, and a capital letter should follow.
Actually it is a comma, it is meant to be part of the same paragraph. > >> its current users (MMUs) are part of larger subsystems and do not >> have a dedicated clock as the one they use is shared with the >> entire subsystem, it doesn't make sense to enable/disable on each >> register read/write operation as the driver using its interface >> should also be handling the same clock. >> >> iommu should only enable/disable the clock on mmu request/free from >> the driver wanting to use it. > > Mmm, I'm not necessarily convinced by that explanation. > If in a next revision, we change the clock partitioning and provide a > dedicated clock for the mmu, it will not work anymore. > I don't thing you should assume anything about the current partitioning. HW wise, only one clock feeds the mmu, iva2_ck is used to generate three clocks but this inside the IVA2 module. I'm assuming omap4 dsp is the same. ISP also depends on cam_ick (among others), and mmu is inside ISP module afaik. >From what I have checked on omap4 TRM it is the same, mmu doesn't have a direct clock, it relies on the main ipu clock to function, but it is my first glance to omap4 and I might be wrong. > That being said, when you will change that code to switch to runtime PM, you > will end up managing the module state in the ISR context. Mainly this patch was sent on my laziness to add device enable/disable calls on all the parts the code is using clk disable/enable, given that they are not really needed. Regards, Omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
