On Wed, Nov 24, 2010 at 3:47 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > 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? I think that's fine, this patch (with fixes to the comments I posted previously) fixes a bug. Clock gating the dma block on idle, if it's even necessary, is a separate feature. -- 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
