devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Afzal Mohammed <x0148406@ti.com>
To: Daniel Mack <zonque@gmail.com>
Cc: Afzal Mohammed <afzal@ti.com>, Tony Lindgren <tony@atomide.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	"Nori, Sekhar" <nsekhar@ti.com>, Paul Walmsley <paul@pwsan.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	"Hunter, Jon" <jon-hunter@ti.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: Representation of external memory-mapped devices in DT (gpmc)
Date: Tue, 30 Oct 2012 16:20:53 +0530	[thread overview]
Message-ID: <508FB10D.9030906@ti.com> (raw)
In-Reply-To: <508EBB47.8070405@gmail.com>

Hi Daniel,

On Monday 29 October 2012 10:52 PM, Daniel Mack wrote:
> On 29.10.2012 16:09, Rob Herring wrote:

>> You may want a CS0 node with nand as a child node of that.

> Hmm, I don't see what that would buy us. The question is which way is
> feasible for storing both the memory region and the cs number in the
> device tree. The CS number should certainly go to the child node, no?
>
> IOW, would it be a good idea to have something like the following layout?
>
> 	gpmc: gpmc@50000000 {
> 		compatible = "ti,gpmc";
> 		ti,hwmods = "gpmc";
> 		reg =<0x50000000 0x2000>;
>
> 		/* cs-reg stores the setup of the controller's
> 		   memory map */
>
> 			/* offset	size */
> 		cs-reg =<0x0		0x1000000
> 			  ....		.....
> 			  ....		.....>;
>
> 		nand: child@0 {
> 			/* timings */
> 			/* peripheral specifics */
> 		};
> 	};
>
> I would actually much prefer that approach.
>
> Afzal, because because that way, we can leave the code as-is for now and
> add the "cs-reg" property once the code is switched to dynamic handling.
> What do you think?

I don't know what to say, don't have a good grasp on DT to give
right suggestion.

It seems offset field may not be necessary. memory for connected
peripherals is not fixed, only CS is fixed (as CS pin is hard-wired).
Physical memory can be anywhere between 0-512MB (with
alignment constraints depending on size, refer GPMC_CONFIG7
register), even though right now memory region for peripheral
seems to be fixed (for boards supported in mainline it will be
what bootloader configures), it is possible to have it in a different
region for those peripherals.

And this memory should be presented to child device as resource,
say for smsc911x ethernet driver.

I see some similarity with PCI - BAR's, where address space
is configured (here a difference would be that size needs to
be known while configuring). Size here would be based on
connected peripheral (but no auto detection)

Regards
Afzal

  parent reply	other threads:[~2012-10-30 10:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-29 14:39 Representation of external memory-mapped devices in DT (gpmc) Daniel Mack
     [not found] ` <508E9513.7050106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-29 15:09   ` Rob Herring
     [not found]     ` <508E9C42.10907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-29 17:22       ` Daniel Mack
     [not found]         ` <508EBB47.8070405-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-29 21:49           ` Rob Herring
     [not found]             ` <508EF9E3.5090507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-10-29 22:37               ` Daniel Mack
2012-10-30 10:50         ` Afzal Mohammed [this message]
     [not found]           ` <508FB10D.9030906-l0cyMroinI0@public.gmane.org>
2012-11-01  0:08             ` Daniel Mack
     [not found]               ` <5091BD7C.7040105-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-01  0:21                 ` Rob Herring

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=508FB10D.9030906@ti.com \
    --to=x0148406@ti.com \
    --cc=afzal@ti.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jon-hunter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nsekhar@ti.com \
    --cc=paul@pwsan.com \
    --cc=tony@atomide.com \
    --cc=zonque@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).