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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux