[PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Joachim Eastwood]

This was introduced in 43a348ea53eb5fd79 but hasn't caused
any harm since it don't have any users yet.

Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
Hello,

This one had me puzzled for a while. Wondering why USB
suddenly disappeared and suspecting by convert script.

 -JE

 include/dt-bindings/pinctrl/omap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h
index b04528cd033c..251d1bd17e35 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -63,7 +63,7 @@
 #define OMAP3_WKUP_IOPAD(pa, val)	OMAP_IOPAD_OFFSET((pa), 0x2a00) (val)
 #define AM33XX_IOPAD(pa, val)		OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
 #define OMAP4_CORE_IOPAD(pa, val)	OMAP_IOPAD_OFFSET((pa), 0x0040) (val)
-#define OMAP4_WKUP_IOPAD(pa, val)	OMAP_IOPAD_OFFSET((pa), 0xe040) (val)
+#define OMAP4_WKUP_IOPAD(pa, val)	OMAP_IOPAD_OFFSET((pa), 0x0040) (val)
 #define AM4372_IOPAD(pa, val)		OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
 #define OMAP5_CORE_IOPAD(pa, val)	OMAP_IOPAD_OFFSET((pa), 0x2840) (val)
 #define OMAP5_WKUP_IOPAD(pa, val)	OMAP_IOPAD_OFFSET((pa), 0xc840) (val)
-- 
1.8.0

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Joachim Eastwood]

On 19 April 2014 18:14, Joachim Eastwood <manabian@gmail.com> 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?

regards
Joachim Eastwood

> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> Hello,
>
> This one had me puzzled for a while. Wondering why USB
> suddenly disappeared and suspecting by convert script.
>
>  -JE
>
>  include/dt-bindings/pinctrl/omap.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h
> index b04528cd033c..251d1bd17e35 100644
> --- a/include/dt-bindings/pinctrl/omap.h
> +++ b/include/dt-bindings/pinctrl/omap.h
> @@ -63,7 +63,7 @@
>  #define OMAP3_WKUP_IOPAD(pa, val)      OMAP_IOPAD_OFFSET((pa), 0x2a00) (val)
>  #define AM33XX_IOPAD(pa, val)          OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
>  #define OMAP4_CORE_IOPAD(pa, val)      OMAP_IOPAD_OFFSET((pa), 0x0040) (val)
> -#define OMAP4_WKUP_IOPAD(pa, val)      OMAP_IOPAD_OFFSET((pa), 0xe040) (val)
> +#define OMAP4_WKUP_IOPAD(pa, val)      OMAP_IOPAD_OFFSET((pa), 0x0040) (val)
>  #define AM4372_IOPAD(pa, val)          OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
>  #define OMAP5_CORE_IOPAD(pa, val)      OMAP_IOPAD_OFFSET((pa), 0x2840) (val)
>  #define OMAP5_WKUP_IOPAD(pa, val)      OMAP_IOPAD_OFFSET((pa), 0xc840) (val)
> --
> 1.8.0
>

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140419 09:25]:
> On 19 April 2014 18:14, Joachim Eastwood <manabian@gmail.com> 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)

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Joachim Eastwood]

On 21 April 2014 17:35, Tony Lindgren <tony@atomide.com> wrote:
> * Joachim Eastwood <manabian@gmail.com> [140419 09:25]:
>> On 19 April 2014 18:14, Joachim Eastwood <manabian@gmail.com> 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.

Will this be sent as a fix for 3.15?

regards
Joachim Eastwood

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Joachim Eastwood]

On 21 April 2014 18:12, Joachim  Eastwood <manabian@gmail.com> wrote:
> On 21 April 2014 17:35, Tony Lindgren <tony@atomide.com> wrote:
>> * Joachim Eastwood <manabian@gmail.com> [140419 09:25]:
>>> On 19 April 2014 18:14, Joachim Eastwood <manabian@gmail.com> 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

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Tony Lindgren]

Hi,

Sorry for dropping the ball on this one, got distracted with various
other fixes for a while.

* Joachim Eastwood <manabian@gmail.com> [140421 09:16]:
> On 21 April 2014 18:12, Joachim  Eastwood <manabian@gmail.com> wrote:
> > On 21 April 2014 17:35, Tony Lindgren <tony@atomide.com> wrote:
> >> * Joachim Eastwood <manabian@gmail.com> [140419 09:25]:
> >>> On 19 April 2014 18:14, Joachim Eastwood <manabian@gmail.com> 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.

Yeah looks like the above won't work as the padconf value can easily
be larger than the 0xfff masked offset.. For example OMAP3_CORE1_IOPAD
at 0x48002030 would become 0x030 and the value for it can be up to
0x238. And we really want the macros to behave the same way for
everything rather than obfuscate the calculation even further.

I guess we could add few new macros, but looks like am335x is using
yet another way of documenting these so it may be endless patching.
 
> For reference my var-som-om44.dtsi now looks like this:
> http://slexy.org/raw/s213OvSZfF

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? 
 
> > Will this be sent as a fix for 3.15?

No since it won't work properly :)

Regards,

Tony

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Joachim Eastwood]

On 6 May 2014 02:12, Tony Lindgren <tony@atomide.com> wrote:
> Hi,
>
> Sorry for dropping the ball on this one, got distracted with various
> other fixes for a while.
>
> * Joachim Eastwood <manabian@gmail.com> [140421 09:16]:
>> On 21 April 2014 18:12, Joachim  Eastwood <manabian@gmail.com> wrote:
>> > On 21 April 2014 17:35, Tony Lindgren <tony@atomide.com> wrote:
>> >> * Joachim Eastwood <manabian@gmail.com> [140419 09:25]:
>> >>> On 19 April 2014 18:14, Joachim Eastwood <manabian@gmail.com> 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.
>
> Yeah looks like the above won't work as the padconf value can easily
> be larger than the 0xfff masked offset.. For example OMAP3_CORE1_IOPAD
> at 0x48002030 would become 0x030 and the value for it can be up to
> 0x238. And we really want the macros to behave the same way for
> everything rather than obfuscate the calculation even further.
>
> I guess we could add few new macros, but looks like am335x is using
> yet another way of documenting these so it may be endless patching.
>
>> For reference my var-som-om44.dtsi now looks like this:
>> http://slexy.org/raw/s213OvSZfF
>
> 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.


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.

What do you think?

regards
Joachim Eastwood

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140509 05:58]:
> On 6 May 2014 02:12, Tony Lindgren <tony@atomide.com> 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.

Regards,

Tony

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Joachim Eastwood]

On 9 May 2014 18:07, Tony Lindgren <tony@atomide.com> wrote:
> * Joachim Eastwood <manabian@gmail.com> [140509 05:58]:
>> On 6 May 2014 02:12, Tony Lindgren <tony@atomide.com> 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

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140511 10:28]:
> On 9 May 2014 18:07, Tony Lindgren <tony@atomide.com> wrote:
> >
> > 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.
> 
> 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.

Sure sounds good to me. The offset is different for at least omap3
instances, so those should use OMAP3_*_IOPAD macros.

Regards,

Tony

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Joachim Eastwood]

On 12 May 2014 18:16, Tony Lindgren <tony@atomide.com> wrote:
> * Joachim Eastwood <manabian@gmail.com> [140511 10:28]:
>> On 9 May 2014 18:07, Tony Lindgren <tony@atomide.com> wrote:
>> >
>> > 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.
>>
>> 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.
>
> Sure sounds good to me. The offset is different for at least omap3
> instances, so those should use OMAP3_*_IOPAD macros.

So you are okey with just OMAP4_IOPAD for both core and wkup pads?

If so I'll send out a patch with the stuff above for OMAP4 and 5.

Then I'll update my patch set, rebase it on your omap-for-v3.16/dt
branch and post it the list.

regards
Joachim Eastwood

Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140512 09:27]:
> 
> So you are okey with just OMAP4_IOPAD for both core and wkup pads?

Well if we ever wanted to add range checking, the macro would have
to have size of the iopad range in it too. But that's probably
out of the scope for these macros anyways and is already done by
the driver.
 
> If so I'll send out a patch with the stuff above for OMAP4 and 5.
> 
> Then I'll update my patch set, rebase it on your omap-for-v3.16/dt
> branch and post it the list.

OK thanks.

Tony