From: David Gibson <david@gibson.dropbear.id.au>
To: Rune Torgersen <runet@innovsys.com>
Cc: Laurent Pinchart <laurentp@cse-semaphore.com>,
linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
ben@simtec.co.uk
Subject: Re: OF compatible MTD platform RAM driver ?
Date: Tue, 11 Mar 2008 11:45:45 +1100 [thread overview]
Message-ID: <20080311004545.GI11559@localhost.localdomain> (raw)
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0418505E@ismail.innsys.innovsys.com>
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
> > Hi everybody,
> >
> > as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> > looking for an
> > OpenFirmware compatible way to handle a RAM-based MTD device.
> >
> > On the platform_device based ppc architecture, the
> > drivers/mtd/maps/plat-ram.c
> > driver handled "mtd-ram" platform devices. There is no such
> > driver for the
> > OF-based powerpc architecture.
> >
> > As a temporary workaround I hacked the physmap_of driver to
> > handle "direct-mapped" OF devices oh type "ram" by adding a
> > corresponding entry in the of_flash_match[] array. This seems to work
> > fine.
> >
> > What would be the preferred way to handle OF-compatible RAM-based MTD
> > devices ? The 3 ways I can think of are
> >
> > 1. porting the plat-ram driver to OF (the driver isn't used
> > in the kernel tree
> > but I suspect it is used by out-of-tree boards)
> >
> > 2. creating a new plat-ram-of driver, much like the
> > physmap_of driver comes
> > from the physmap driver
> >
> > 3. extending the physmap_of driver to handle RAM devices (in
> > which case
> > references to "flash" in the function names should probably
> > be replaced
> > by "mtd")
> >
> > I live option 3 better so far.
> >
> > Has anyone already worked on this ? Is there any defined
> > device tree mapping
> > for MTD RAM devices ?
>
> We ran ito the same issue.
> We did option 3, as it was efinetly the easiest,
I think this is the best option in principle.
> here is the sram entry in our dts:
Except that your implementation of it is not good.
You're relying on the old obsolete flash binding with the "probe-type"
field. The solution should be adapted to the new approach which uses
values in the "compatible" field to indicate various sorts of flash
device.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Rune Torgersen <runet@innovsys.com>
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org, ben@simtec.co.uk
Subject: Re: OF compatible MTD platform RAM driver ?
Date: Tue, 11 Mar 2008 11:45:45 +1100 [thread overview]
Message-ID: <20080311004545.GI11559@localhost.localdomain> (raw)
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0418505E@ismail.innsys.innovsys.com>
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
> > Hi everybody,
> >
> > as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> > looking for an
> > OpenFirmware compatible way to handle a RAM-based MTD device.
> >
> > On the platform_device based ppc architecture, the
> > drivers/mtd/maps/plat-ram.c
> > driver handled "mtd-ram" platform devices. There is no such
> > driver for the
> > OF-based powerpc architecture.
> >
> > As a temporary workaround I hacked the physmap_of driver to
> > handle "direct-mapped" OF devices oh type "ram" by adding a
> > corresponding entry in the of_flash_match[] array. This seems to work
> > fine.
> >
> > What would be the preferred way to handle OF-compatible RAM-based MTD
> > devices ? The 3 ways I can think of are
> >
> > 1. porting the plat-ram driver to OF (the driver isn't used
> > in the kernel tree
> > but I suspect it is used by out-of-tree boards)
> >
> > 2. creating a new plat-ram-of driver, much like the
> > physmap_of driver comes
> > from the physmap driver
> >
> > 3. extending the physmap_of driver to handle RAM devices (in
> > which case
> > references to "flash" in the function names should probably
> > be replaced
> > by "mtd")
> >
> > I live option 3 better so far.
> >
> > Has anyone already worked on this ? Is there any defined
> > device tree mapping
> > for MTD RAM devices ?
>
> We ran ito the same issue.
> We did option 3, as it was efinetly the easiest,
I think this is the best option in principle.
> here is the sram entry in our dts:
Except that your implementation of it is not good.
You're relying on the old obsolete flash binding with the "probe-type"
field. The solution should be adapted to the new approach which uses
values in the "compatible" field to indicate various sorts of flash
device.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2008-03-11 1:28 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-10 15:06 OF compatible MTD platform RAM driver ? Laurent Pinchart
2008-03-10 17:00 ` Rune Torgersen
2008-03-10 17:00 ` Rune Torgersen
2008-03-11 0:45 ` David Gibson [this message]
2008-03-11 0:45 ` David Gibson
2008-03-11 10:39 ` Laurent Pinchart
2008-03-11 10:39 ` Laurent Pinchart
2008-03-11 22:40 ` David Gibson
2008-03-25 14:36 ` Laurent Pinchart
2008-03-25 15:29 ` Sergei Shtylyov
2008-03-25 15:51 ` Laurent Pinchart
2008-03-25 16:23 ` Sergei Shtylyov
2008-03-25 16:44 ` Laurent Pinchart
2008-03-25 17:02 ` Sergei Shtylyov
2008-03-25 17:23 ` Laurent Pinchart
2008-03-25 17:37 ` Sergei Shtylyov
2008-03-25 17:56 ` Rune Torgersen
2008-03-25 17:56 ` Rune Torgersen
2008-03-25 18:14 ` Laurent Pinchart
2008-03-25 18:14 ` Laurent Pinchart
2008-03-26 12:53 ` Sergei Shtylyov
2008-03-26 12:53 ` Sergei Shtylyov
2008-03-27 9:13 ` Laurent Pinchart
2008-03-27 9:13 ` Laurent Pinchart
2008-03-27 10:03 ` David Gibson
2008-03-27 10:03 ` David Gibson
2008-03-27 12:23 ` Sergei Shtylyov
2008-03-27 12:23 ` Sergei Shtylyov
2008-03-28 0:07 ` David Gibson
2008-03-28 0:07 ` David Gibson
2008-03-28 12:31 ` Sergei Shtylyov
2008-03-28 12:31 ` Sergei Shtylyov
2008-03-27 14:31 ` Laurent Pinchart
2008-03-27 14:31 ` Laurent Pinchart
2008-03-28 0:09 ` David Gibson
2008-03-30 18:15 ` Segher Boessenkool
2008-03-30 18:15 ` Segher Boessenkool
2008-03-30 21:16 ` Paul Mackerras
2008-03-30 22:39 ` Segher Boessenkool
2008-03-31 0:42 ` Paul Mackerras
2008-03-31 0:59 ` Segher Boessenkool
2008-03-31 1:24 ` Segher Boessenkool
2008-03-31 8:21 ` Laurent Pinchart
2008-03-31 8:21 ` Laurent Pinchart
2008-03-31 12:21 ` Segher Boessenkool
2008-03-26 15:06 ` Segher Boessenkool
2008-03-26 15:06 ` Segher Boessenkool
2008-03-26 15:40 ` Sergei Shtylyov
2008-03-26 15:40 ` Sergei Shtylyov
2008-03-27 9:24 ` Laurent Pinchart
2008-03-27 9:24 ` Laurent Pinchart
2008-03-30 18:12 ` Segher Boessenkool
2008-03-30 18:12 ` Segher Boessenkool
2008-03-26 15:09 ` Segher Boessenkool
2008-03-26 15:09 ` Segher Boessenkool
2008-03-11 15:00 ` Rune Torgersen
2008-03-11 15:00 ` Rune Torgersen
2008-03-11 22:41 ` David Gibson
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=20080311004545.GI11559@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=ben@simtec.co.uk \
--cc=laurentp@cse-semaphore.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=runet@innovsys.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.