> -----Original Message----- > From: Balbi, Felipe > Sent: Tuesday, September 14, 2010 5:27 PM > To: G, Manjunath Kondaiah > Cc: Balbi, Felipe; Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx; > Cousson, Benoit; Shilimkar, Santosh > Subject: Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device > registration > > On Tue, Sep 14, 2010 at 06:44:01AM -0500, G, Manjunath Kondaiah wrote: > > > > > >> -----Original Message----- > >> From: Balbi, Felipe > >> Sent: Tuesday, September 14, 2010 3:54 PM > >> To: G, Manjunath Kondaiah > >> Cc: Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx; Cousson, > >> Benoit; Shilimkar, Santosh > >> Subject: Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device > >> registration > >> > >> Hi, > >> > >> On Tue, Sep 14, 2010 at 05:18:52AM -0500, G, Manjunath > Kondaiah wrote: > >> >How static inline functions are better than this? > >> > >> static inline function will at least give you type checking ?? > > > >If so, even inline function has certain disadvantages such as, A. > >somtimes the compiler may not be able to inline as many functions as > >the programmer indicates. > > show me one such example. There are several places in kernel code (ex: tools/perf/util/include/linux/bitops.h:static __always_inline int test_bit(unsigned int nr, const unsigned long *addr)) which are using __always_inline attribute to make sure functions are inlined. > > > B. Inline functions might increcase compilation time > > it's possible, for sure. But for the case you just showed the > arguments > are even constant, so there's more room for compile-time optimization. > In the end, GCC will replace your calls with: > > address = value; > > or, when reading: > > return address > > >The issue in DMA driver is, if I replace dma_read/dma_write > macros with > >inline functions, I need to remove OMAP_DMA4_##reg macro in dma_read > >and dma write functions and I have to expand the register names all > >over the place in DMA driver(like instead of CAPS0, it should be > >OMAP_DMA4_CAPS0, having only CAPS0 will be easier to read). > > it might be easier to read but this is a recipe for disaster. Avoid > using those macros for part of the actual symbol/define/whatever name > like that. If someone later decides to change something, it will be a > pain. With those macros you also kill any possibility of using > ctags/cscope for source code cross-referencing. When a developers > searchs for the definition of CAPS0, he won't find it, as it's called > OMAP_DMA4_CAPS0. So remove those silly things and change the > defines to > static inline functions. Ok, Agreed. We can have inline functions and expanding all macros in mach-omap dma driver code. However, there is common dma driver(in plat-omap) which has code for both omap1 and omap2plus which uses this macro. -Manjunath-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
