On 9 May 2014 18:07, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Joachim Eastwood <manabian@xxxxxxxxx> [140509 05:58]: >> On 6 May 2014 02:12, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> > >> > OK sorry just noticed you're using it already while was about to >> > apply your patches. Care to update that series again to not use the >> > macro, or by adding the offsets? >> >> hm, I'd rather add offsets than remove the macro's now. >> >> How about we introduce a mask parameter in to the OMAP_IOPAD_OFFSET macro? >> Something like this: >> #define OMAP_IOPAD_OFFSET(pa, offset, mask) (((pa) & mask) - ((offset) & mask)) >> >> #define OMAP4_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0040, 0xfff) (val) >> >> #define OMAP4_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0xe040, 0xfff) (val) >> >> Of course we need to fix the other users as well. > > I was thinking that too initially, but then we would have macros that behave > in a different way: > > 1. Calculate the iopad offset from the iopad register area start based on > the iopad physical address > > 2. Calculate the iopad offset from the iopad register area start based on > the iopadd offset from the driver base address > >> One other possibility is to use my original patch in this mail or just >> create a OMAP4_IOPAD with offset 0x040 which will on OMAP4 work for >> both core and wkup. > > That also makes the macro behave in a different way depending on the > SoC which is not nice. > >> What do you think? > > I think it's best to add some new macros to avoid confusion. > I see. How about something like this then: /* * Macros to allow using the offset from the padconf physical address * instead of the offset from padconf base. */ #define OMAP_PADCONF_OFFSET(offset, base_offset) ((offset) - (base_offset)) #define OMAP4_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) #define OMAP5_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) The OMAP4/5 TRMs list address offsets from the padconf physical address (which is not driver base address) and not absolute physical address for padconf registers like some other OMAP TRMs. So create a new macro to avoid confusion between different OMAP parts. I can cook up a patch if you like the idea above. regards Joachim Eastwood -- 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