Erik Gilling wrote: > Sent: Wednesday, November 24, 2010 4:27 PM > > On Wed, Nov 24, 2010 at 3:25 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > >> 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? > > Yes. Pretty much every driver will enable the clock when it has work > to do and disable it when idle. That makes sense. Right now, I think APB DMA works in Android because the bootloader turns this clock on, and the kernel doesn't turn it off, because there's no entry in tegra_list_clks[] for it. For ChromeOS, U-Boot doesn't turn this clock on, hence APB DMA doesn't work. Does it make sense to check in the change to have the kernel enable this clock as a first step, in tegra_dma_init as I wrote it (updated to use the correct APIs though). That would not be a power regression for Android, but would enable the driver to work on ChromeOS (really, U-Boot). Then, make a later change to enhance the driver to turn the clock on/off only when it's needed? Thanks. -- 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
