Re: [PATCH 1/5] ARM: OMAP2/3/4: Split OMAP2_IO_ADDRESS to L3 and L4

["Hemanth V" <hemanthv@ti.com>]

----- Original Message ----- 
From: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
>> ---
>> #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.

#define __IO_ADDRESS(pa) ((pa) >= L3_34XX_PHYS ?   ((pa) + L3_IO_OFFSET) : 
((pa) + IO_OFFSET))