----- Original Message -----
From: "Shilimkar, Santosh" <[email protected]>
---
#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))
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
