On Thu, Dec 02, 2010 at 09:07:25AM -0800, Tony Lindgren wrote: > * G, Manjunath Kondaiah <manj...@ti.com> [101124 04:43]: > > Existing DMA API's are using cpu_*is_* checks for differentiating > > omap1 and omap2+ code and handle cpu_*is_* checks with DMA device > > attributes. > > > > Also, move OMAP1 and OMAP2+ specific API's into respective mach-omap > > dma driver files. > > This patch is unreadable and needs to be split.
I can split this patch as: 1. all chaining related API movement in one patch. 2. Rest of the changes in second patch. > > Also, why are you making duplicate copies of the same generic > functions? > > Now you've copied these into mach-omap1/dma.c: > > > +set_src_params(int lch, unsigned long src_start, int src_ei, int src_fi) > > +{ > > + dma_write(src_start, CSSA, lch); > > + > > + dma_write(src_ei, CSEI, lch); > > + dma_write(src_fi, CSFI, lch); > > +} > > + > > +static void set_dest_params(int lch, unsigned long dest_start, int dst_ei, > > + int dst_fi) > > +{ > > + dma_write(dest_start, CDSA, lch); > > + > > + dma_write(dst_ei, CDEI, lch); > > + dma_write(dst_fi, CDFI, lch); > > +} > ... > > And then again the same functions in mach-omap2/dma.c: Earlier, handling of CSSA and CDSA was different because 16 bit registers vs 32 bit registers. Now, with latest patch series, all the registers are handled inside functions, these API's can be retained in plat-omap. > > > +static void omap2_set_src_params(int lch, unsigned long src_start, int > > src_ei, > > + int src_fi) > > +{ > > + dma_write(src_start, CSSA, lch); > > + > > + dma_write(src_ei, CSEI, lch); > > + dma_write(src_fi, CSFI, lch); > > +} > > + > > +static void omap2_set_dest_params(int lch, unsigned long dest_start, int > > dst_ei, > > + int dst_fi) > > +{ > > + dma_write(dest_start, CDSA, lch); > > + > > + dma_write(dst_ei, CDEI, lch); > > + dma_write(dst_fi, CDFI, lch); > > +} > ... > > All the common functions should stay in plat-omap/dma.c. I agree. -Manjunath -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html