All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: "Gupta, Pekon" <pekon@ti.com>,
	Javier Martinez Canillas <javier@dowhile0.org>
Cc: Tony Lindgren <tony@atomide.com>,
	Benoit Cousson <bcousson@baylibre.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	Minal Shah <minalkshah@gmail.com>
Subject: Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Date: Wed, 14 May 2014 12:17:52 +0300	[thread overview]
Message-ID: <537334C0.8040109@ti.com> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EACCDEA@DBDE04.ent.ti.com>

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)
>>
>> 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.

cheers,
-roger

  reply	other threads:[~2014-05-14  9:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 20:46 [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash Pekon Gupta
2014-05-09 20:46 ` [PATCH v4 4/6] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition Pekon Gupta
2014-05-10 17:02   ` Javier Martinez Canillas
2014-05-09 20:46 ` [PATCH v4 5/6] ARM: dts: am43x-epos-evm: fix reg and range property of GPMC NAND node Pekon Gupta
2014-05-13 17:32   ` Tony Lindgren
2014-05-09 20:46 ` [PATCH v4 6/6] ARM: dts: am335x-evm: " Pekon Gupta
2014-05-10 17:11   ` Javier Martinez Canillas
2014-05-12 19:44     ` Tony Lindgren
2014-05-10 17:57 ` [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash Javier Martinez Canillas
2014-05-12  7:03   ` Gupta, Pekon
2014-05-12  8:49     ` Javier Martinez Canillas
2014-05-12  9:05       ` Gupta, Pekon
2014-05-12  9:08         ` Javier Martinez Canillas
2014-05-14  8:25         ` Roger Quadros
2014-05-14  8:47           ` Gupta, Pekon
2014-05-14  9:00           ` Roger Quadros
2014-05-14  9:09             ` Gupta, Pekon
2014-05-14  9:17               ` Roger Quadros [this message]
2014-05-14  9:23                 ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537334C0.8040109@ti.com \
    --to=rogerq@ti.com \
    --cc=bcousson@baylibre.com \
    --cc=javier@dowhile0.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=minalkshah@gmail.com \
    --cc=pekon@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.