>-----Original Message----- > >From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of > >Shilimkar, Santosh > >Sent: Sunday, August 23, 2009 8:35 AM > >To: tony@xxxxxxxxxxx; khilman@xxxxxxxxxxxxxxxxxxx > >Cc: linux-omap@xxxxxxxxxxxxxxx; Shilimkar, Santosh > >Subject: [PATCH 1/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4 > > That sure is a big cleanup patch and would take patience to complete!! > > > > >This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and > >OMAP2_L4_IO_ADDRESS to reclaim more IO space. > > There is no reclaim of space with this patch. Its done with [2/5] Yes comment is valid. I wanted to put - "This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and OMAP2_L4_IO_ADDRESS to enable freeing up of more IO space. > This patch only changes the macro definitions but the offsets are still > the same as in old code. > So the description needs to be more explicit as to why you introduced > L3/L4 macro split. > > Another suggestion to minimize the so intrusive code change: As per the > wiki approach: [1] > Lot of code will remain un-touched if you re-used the existing IO_OFFSET > macro as follows --- > --- > #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. -- 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
