From: x0148406@ti•com (Afzal Mohammed)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Date: Mon, 29 Oct 2012 18:26:04 +0530 [thread overview]
Message-ID: <508E7CE4.9070802@ti.com> (raw)
In-Reply-To: <508E7767.40804@gmail.com>
Hi Daniel,
On Monday 29 October 2012 06:02 PM, Daniel Mack wrote:
> On 29.10.2012 12:28, Afzal Mohammed wrote:
>> I was referring to that of child, now in gpmc_nand_init(),
>> gpmc_cs_request() is being done, later on if we want to
>> make it generic and remove gpmc_nand_init(), additional
>> information that would be required from DT at least is the
>> memory size to be reserved in gpmc address space for
>> the connected peripheral (assuming gpmc_cs_request()
>> would be done by gpmc driver generically later)
>>
>> What I had in mind was example for external bus in [1],
>> but I had not looked deep into this aspect yet.
> Ok, now I see what you mean.
>
> I would say we can use the "reg" property in child node for CS numbers
> purely and if we want to get rid of the memory node allocation, we
> should use a property in the gpmc top-node for this, something like:
>
> gpmc: gpmc at 50000000 {
> compatible = "ti,gpmc";
> cs-regs =<0x51000000 0x10000000 ...>;
I think you meant cs-regs = <0x00000000 ..>
0x0 - 0x1fffffff is gpmc external memory address space, while
0x50000000 to plus 16MB is gpmc configuration address space.
You may refer other gpmc peripheral init's that are NOR type.
> Changing the meaning of the reg property of children from "cs number" to
> "memory sub-region" later is something I would like to avoid.
Changing any of the properties later is something we have
to avoid. Let us get feedback from DT maintainers.
Regards
Afzal
next prev parent reply other threads:[~2012-10-29 12:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 19:55 [PATCH 0/4] RFC: OMAP GPMC bindings Daniel Mack
2012-10-22 19:55 ` [PATCH 1/4] mtd: omap-nand: pass device_node in platform data Daniel Mack
2012-10-22 19:55 ` [PATCH 2/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs Daniel Mack
2012-10-22 19:55 ` [PATCH 3/4] ARM: OMAP: gpmc: don't create devices from initcall on DT Daniel Mack
2012-10-22 19:55 ` [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND Daniel Mack
2012-10-24 23:27 ` Tony Lindgren
2012-10-24 23:31 ` Daniel Mack
2012-10-29 8:10 ` Afzal Mohammed
2012-10-29 11:15 ` Daniel Mack
2012-10-29 11:28 ` Afzal Mohammed
2012-10-29 12:32 ` Daniel Mack
2012-10-29 12:56 ` Afzal Mohammed [this message]
2012-10-25 1:28 ` Jon Hunter
2012-10-25 8:00 ` Daniel Mack
2012-10-25 13:16 ` Jon Hunter
2012-10-29 8:09 ` Afzal Mohammed
2012-10-25 1:53 ` Jon Hunter
2012-10-25 9:43 ` Daniel Mack
2012-10-25 13:22 ` Jon Hunter
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=508E7CE4.9070802@ti.com \
--to=x0148406@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox