Erik Gilling wrote: > Sent: Wednesday, November 24, 2010 4:17 PM > > On Wed, Nov 24, 2010 at 2:17 PM, Colin Cross <ccross@xxxxxxxxxx> wrote: > > tegra_get_clock_by_name is private to the clock implementation, it > > should not be used outside clock.c and tegra2_clocks.c. Use > > clk_get_sys. Also, after a recent change in the Tegra tree, DMA is > > initialized before clocks, and this introduces a dependency loop: > > Reading fuses requires dma (hw bug), dma requires clocks, and clocks > > has to read the fuses to determine how fast the cpu can go. I'll have > > to fix that in the fuse API. > > Aside from said dependency loop, why does the dma code not handle > clock enable/disable on it's own? That's what this change currently adds, although I asked whether the clock should be blanket enabled at boot time like many other clocks. Or, do you mean that when initiating a new DMA, the code should enable the clock if currently disabled, and later disable the clock after all DMAs are complete (or some timeout thereafter), much like nvhost_module_busy/powerdown_handler does for graphics? -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
