On Wed, May 14, 2014 at 11:17 AM, Roger Quadros <[email protected]> wrote:
> On 05/14/2014 12:09 PM, Gupta, Pekon wrote:
>>> From: Quadros, Roger
>> [...]
>>
>>>>> For now, I'll use GPMC address-space size = 0x380 as it matches with
>>>>> actual hardware and is working.
>>>>
>>>> How did you get 0x380?
>>>>
>>>> From DRA7 TRM, GPMC address range is 0x5000 0000 : 0x5000 02D0
>>>> So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
>>>> wide)
>>>
arch/arm/boot/dts/omap3.dtsi is using reg = <0x6e000000 0x02d0> so
that should be fixed to 0x2d4 too.
>>> Sorry for the noise.
>>> Just figured out that the register space is not numerically arranged in the
>>> TRM.
>>>
>>> The last register is P GPMC_BCH_RESULT6_i
>>> 0x5000 0308 + (0x0000 0010 * i)
>>> i = 0 to 7
>>>
>>> So size should be 0x37C.
>>>
>> Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
>> so I aligned the last address to 0x380 boundary. Hope leaving room for
>> extra 4 bytes (0x380 - 0x37C) will not matter much?
>
> Functionally it won't matter but it always good to describe the hardware as
> accurately as possible and avoid confusion to future developers as to why
> extra 4 bytes were used in the device tree.
>
I don't think that aligning makes too much sense since in practice
ioremap() will map a complete page anyways so if we are not using
0x1000 (e.g: PAGE_SIZE on ARM) is just because we want the DT to
strictly model what the hardware registers address size really is.
Best regards,
Javier
--
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
