On 21 April 2014 18:12, Joachim Eastwood <manabian@xxxxxxxxx> wrote: > On 21 April 2014 17:35, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> * Joachim Eastwood <manabian@xxxxxxxxx> [140419 09:25]: >>> On 19 April 2014 18:14, Joachim Eastwood <manabian@xxxxxxxxx> wrote: >>> > This was introduced in 43a348ea53eb5fd79 but hasn't caused >>> > any harm since it don't have any users yet. >>> >>> Or maybe I am confused about this macro. >>> >>> Tony which offset from the OMAP4 TRM should be used? >>> >>> Under section 18.6.8 there are is a column with address offset. Is >>> this the number you want in the macro? >> >> Oh I see, the offsets in the TRM in this case are from the base >> of the wkup module padconf base instead of listing the physical >> address for the register. Ideally the value would be what the >> documentation lists in the "Table 18-9. Device Wake-Up Control >> Module Pad Configuration Register Fields" with 2 added to it for >> the upper registers as we're using 16-bit register address. >> In any case something that's relatively easy to verify against >> the documentation. But that seems to vary between the physical >> address and the offset, so we need to specify some mask there. >> >> Something like below (untested) should do the trick as long as >> we never have padconf reg areas larger than 0xfff. We may want to >> allow defining a custom mask for the macro if needed depending >> how the documentation is defining the mux tables for. >> >> --- a/include/dt-bindings/pinctrl/omap.h >> +++ b/include/dt-bindings/pinctrl/omap.h >> @@ -51,9 +51,9 @@ >> >> /* >> * Macros to allow using the absolute physical address instead of the >> - * padconf registers instead of the offset from padconf base. >> + * padconf register offset from padconf register base. >> */ >> -#define OMAP_IOPAD_OFFSET(pa, offset) (((pa) & 0xffff) - (offset)) >> +#define OMAP_IOPAD_OFFSET(pa, offset) (((pa) & 0xfff) - ((offset) & 0xfff)) >> >> #define OMAP2420_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0030) (val) >> #define OMAP2430_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2030) (val) > > This give the same result as my patch so it's okay for me. Checked the > resulting dtb's and they are equivalent. > > Your patch will also have an effect on some of the others macros but I > assume that is okey. For reference my var-som-om44.dtsi now looks like this: http://slexy.org/raw/s213OvSZfF > Will this be sent as a fix for 3.15? > > 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
