On Tue, 2011-12-20 at 20:54 +0800, Shawn Guo wrote: > On Tue, Dec 20, 2011 at 02:54:04PM +0530, Vinod Koul wrote: > > On Tue, 2011-12-13 at 23:48 +0800, Shawn Guo wrote: > > > I have been working on -rc recently, and have not noticed the failure > > > until I ran next tree today. The mxs-mmc driver is broken on next > > > tree because the DMA_NONE was left over from the dma_transfer_direction > > > migration for mxs-dma and its client drivers. > > > > > For DMA transfer, the NONE direction makes no sense? > > > > In your conetext, what are you trying to achieve? > > > The mxs-dma controller has a feature to program peripheral registers > with given values (mxs-dma PIO mode). This is designed to pipeline > the operations. For example, we can put mxs-mmc controller register > values into scatter list as one element together with actual data. > Triggering the mxs-dma, the dma will program the values into mxs-mmc > controller register to set up and enable mxs-mmc, and then dma > continue transfer data from/to mxs-mmc. All these get done in one > dmaengine_submit(). > > And DMA_NONE was used to let mxs-dma know this is a PIO operation. Sorry am little lost here. Why would DMA driver bother with a PIO mode, that is something only peripheral driver would know about, mmc in your case. So what you are saying is the your dma has the capability to program the peripheral registers in case of PIO mode, but why wouldn't the peripheral driver do that instead? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
