"G, Manjunath Kondaiah" <manjugk@xxxxxx> writes:
>> -----Original Message-----
>> From: Balbi, Felipe
>> Sent: Thursday, September 16, 2010 11:33 AM
>> 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
>>
>> Hi,
>>
>> On Wed, Sep 15, 2010 at 10:40:08PM -0500, G, Manjunath Kondaiah wrote:
>> >In that case, the dma_read/dma_write macros will be splitted into:
>> >
>> >static inline void omap1_dma_write(...); static inline void
>> >omap2_dma_write(...); static inline u32 omap1_dma_read(...); static
>> >inline u32 omap2_dma_read(...);
>> >
>> >i.e., Two macro definitions will expand into four internal functions.
>>
>> why do you need separate methods for omap1 and omap2 ??
>
> Current macro definition is:
>
> #define dma_read(reg) \
> ({ \
> u32 __val; \
> if (cpu_class_is_omap1()) \
> __val = __raw_readw(omap_dma_base + OMAP1_DMA_##reg); \
> else \
> __val = __raw_readl(omap_dma_base + OMAP_DMA4_##reg); \
> __val; \
> })
>
> Since we are expanding abbrevated register offsets into full macro, hence
> these macros should be used in respective read/write functions(omap1 and omap2plus).
>
> Any other better methods?
Yes.
This is a common problem and is handled in many OMAP drivers using
methods like Felipe described.
There are many examples, but a recent one is the i2c driver which has
different register map between omap2/3 and omap4. Have a look
at drivers/i2c/busses/i2c-omap.c
Kevin
--
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
