From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 2 Nov 2011 12:29:25 -0500 Subject: [U-Boot] [PATCH 1/2] nand_spl_simple: Add omap3 DMA usage to SPL In-Reply-To: <4EB113FD.7000005@gmail.com> References: <1318759804-18688-1-git-send-email-simonschwarzcor@gmail.com> <1318759804-18688-2-git-send-email-simonschwarzcor@gmail.com> <4EA6FEF9.6070208@freescale.com> <4EAE62D6.5030109@gmail.com> <4EAF11A7.6020304@freescale.com> <4EB113FD.7000005@gmail.com> Message-ID: <4EB17DF5.4050904@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/02/2011 04:57 AM, Simon Schwarz wrote: > Hi Scott > > On 10/31/2011 10:22 PM, Scott Wood wrote: > >> What would the semantics of a generic dma_wait_for_transfer() be? >> >> I just don't see how this is generic at all, whatever the name. >> > > Hm. It would be a check if the given DMA channel is active - and if it > is busy waiting for it. > > So, what would then be a generic interface for DMA? I see that this is a > verrry basic solution - but where do you see the actual problems > implementing this interface for other DMA controllers? Or do you think > that the interface is to simple? I'd stick with something closer to the read_buf() interface -- something like read_buf_async() and wait_for_async(). Let the controller driver deal with the details of how DMA is done. Parameter is the mtd pointer, not a channel number. Certainly all the DMA setup stuff in nand_spl_load_image() needs to go elsewhere. >>> A whole new driver is IMHO not the right thing as there is too much >>> duplicated code then. I think it can be done with less duplication than in this patch -- should only need some ifdefs in the current code. There's no need to support both modes of operation in one SPL image, right? -Scott