> -----Original Message----- > From: V, Hemanth > Sent: Monday, August 24, 2009 11:40 AM > To: Shilimkar, Santosh; Pandita, Vikram; tony@xxxxxxxxxxx; > khilman@xxxxxxxxxxxxxxxxxxx > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and > L4 > > ----- Original Message ----- > From: "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> > >> --- > >> #define L3_IO_OFFSET 0x90000000 > >> #define __L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3 */ > >> #define __OMAP2_L3_IO_ADDRESS(pa) ((pa) + L3_IO_OFFSET)/* Works for L3 > >> */ > >> #define l3_io_v2p(va) ((va) - L3_IO_OFFSET)/* Works for L3 */ > >> > >> #define IO_OFFSET 0xb2000000 > >> #define __IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L4 */ > >> #define __OMAP2_IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L4 */ > >> #define io_v2p(va) ((va) - IO_OFFSET)/* Works for L4*/ > >> --- > >> > >> This way you don't have to introduce new L4 macro at all => much lesser > >> code impact. > > Initially I thought about this but later preferred to split it. The only > > change what you are suggesting is instead of calling > > "OMAP2_L4_IO_ADDRESS", we keep >that as "OMAP2_IO_ADDRESS". But the idea > > was to differentiate between various IO accesses because at some point > of > > time all these has to be removed in > > favor of ioremap() + read*()/write*() one by one and that time this > would > > be beneficial. > > Does that mean all drivers, including the ones in other trees like camera, > dss etc need to be modified if they are using IO_ADDRESS macros. The idea > of > having a macro as below was to reduce this impact. Going forward yes. Refer the mailing thread comments from Tony/Kevin/Richard on below thread. http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg14015.html Regards, Santosh -- 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
