Hi Vinod, On Monday 15 December 2014 14:43:14 Vinod Koul wrote: > On Mon, Dec 15, 2014 at 09:31:01AM +0100, Geert Uytterhoeven wrote: > > Please let me summarize... > > Thanks :) > > > During probe of a DMA client driver, the DMA engine driver may not be > > available, causing dma_request_slave_channel*() to return -EPROBE-DEFER. > > There are actually two different reasons that the DMA engine driver may > > not be available: > > > > 1. The DMA engine driver hasn't been initialized yet, due to probe order. > > This is more likely to happen with i2c client drivers, as they are > > initialized from subsys_initcall() instead of module_init() (E.g. I > > never saw it with the spi-rspi driver). > > => The DMA client driver wants to return -EPROBE_DEFER too, and > > retry later. > > > > 2. The DMA engine driver is not included in the kernel build. > > => The DMA client driver wants to fall back to PIO. > > > > Now, how to distinguish between the two cases above? > > Quite right, this is a good question. Today we cannot distinguish between > the two. Should we improve the deferred probe to tell us when the init is > complete and all the modules have been initialized? I don't think that's possible, as you can never know when a module will be loaded. > If we ever have such a mechanism to check then we know no modules are to be > inserted then we can fall back to PIO mode. Without that we should use some > timeout counter to fall back on, say try requesting 5 times and give up and > move to PIO after that That could be a performance improvement, but I wonder whether it's worth it. If DT specifies DMA channels for the I2C controller, and the DMA core is compiled in, and the DMA engine driver is compiled as a module and never loaded, then yes, there will be a small overhead for each I2C transaction, but I'd argue that such a combination of conditions is asking for trouble anyway :-) > > Currently, e.g. i2c-sh_mobile always returns -EPROBE_DEFER, never falling > > back to PIO, breaking case 2. While e.g. spi-rspi always falls back to > > PIO, which is suboptimal in case 1 (but I never encountered that case with > > spi). > > > > Solutions under consideration: > > 1. Wolfram posted a patch to make i2c-sh_mobile fall back to PIO, and > > retry DMA initialization in every request, so it will switch to DMA > > when it becomes available. But this is suboptimal, as it adds overhead > > to every request (and DMA may never become available in case 2). > > > > 2. Delay i2c initialization, by moving from subsys_initcall() to > > module_init(), in the hope the i2c client driver will be initialized > > after the DMA engine. > > > > This is being discussed in the thread you quoted above. > > > > I hope this explains the problem well. > > Yes and it has nothing to do with channels being exhausted, the problem I > assumed earlier!! -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
