linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org,
	devicetree-discuss list <devicetree-discuss@ozlabs.org>
Subject: Re: physmap_of and partitions (mtd concat support)
Date: Tue, 24 Mar 2009 10:07:51 +0100	[thread overview]
Message-ID: <200903241007.51321.sr@denx.de> (raw)
In-Reply-To: <fa686aa40903230837w52a9f764n29b3f9cf4c95cc57@mail.gmail.com>

On Monday 23 March 2009, Grant Likely wrote:
> On Mon, Mar 23, 2009 at 4:51 AM, Stefan Roese <sr@denx.de> wrote:
> > I just noticed that physmap_of can't handle multiple devices of different
> > type described in one device node. For example the Intel P30 48F4400
> > (64MByte) consists internally of 2 non-identical NOR chips. So a "simple"
>
> [...]
>
> > Now the real problem: How should I describe a partition in the device
> > tree spanning over both devices (concat)?. The current physmap_of driver
> > doesn't handle concat at all (physmap.c does). I already have some ideas
> > on how to implement this concat support in physmap_of. But ideas about a
> > device-tree syntax for such partitions are very welcome.
>
> Sounds to me like a physmap_of driver bug.  I don't think there is any
> advantage in changing the partition syntax since concatenated flash
> will always be used as a single device.  It doesn't make any sense to
> try and span partitions over two nodes.

Yes, I would really love to make this possible with only one flash node. But 
just think about the following system configuration:

One Intel Strataflash (compatible = "cfi-flash") and one non-cfi compatible 
flash (e.g. compatible = "jedec-flash"). And the user wants to define a 
partition that spans over both flash chips. How could this be described in 
one flash node?

> Do additional properties need to be added to describe the concat layout?

Not sure. If we have multiple identical devices they can currently be 
described in one flash node. So with some changes to the physmap_of driver 
this configuration will work with concat as well. But more complex is a 
system configuration as described above. Meaning two or more non-identical 
chips. I don't see how this could be described in a sane way in one flash 
node.

Best regards,
Stefan

  reply	other threads:[~2009-03-24  9:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-23 10:51 physmap_of and partitions (mtd concat support) Stefan Roese
2009-03-23 15:37 ` Grant Likely
2009-03-24  9:07   ` Stefan Roese [this message]
2009-03-24 14:57     ` Grant Likely
2009-03-24 15:39       ` Stefan Roese
2009-03-24 16:28         ` Grant Likely
2009-03-25  9:35           ` Stefan Roese
2009-03-25 13:28             ` Grant Likely
2009-03-25 14:14               ` Stefan Roese

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=200903241007.51321.sr@denx.de \
    --to=sr@denx.de \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    /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).