From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: ben@simtec.co.uk, linuxppc-dev@ozlabs.org,
Rune Torgersen <runet@innovsys.com>,
linux-mtd@lists.infradead.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: OF compatible MTD platform RAM driver ?
Date: Wed, 26 Mar 2008 15:53:21 +0300 [thread overview]
Message-ID: <47EA4741.2050402@ru.mvista.com> (raw)
In-Reply-To: <200803251914.24021.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>>>Regarding non-volatility nothing prevents a user from using a
>>>volatile RAM as an MTD device, but there's little point in doing so.
>>>Would it be acceptable for the "linear-nvram" specification
>>>not to include > volatile RAM ? ROM chips would be excluded too. Is
>>that an issue ?
>>We actually use a volatile ram (SRAM) as an MTD device. We use it to
>>store info from bootloader and system specific values between resets.
> So we're left with two main options.
> - Reusing the nvram device type from the Device Support Extensions. Volatile
> devices wouldn't be supported, and we'd need a separate device specification
> for linear-mapped volatile RAMs. I'm not very happy with that.
> - Using another device node with a compatible value set to "linear-ram" (or
> something similar). This would support both volatile and non-volatile
> devices, and a property could be added to specify if the device is volatile
> or not.
> I'd go for the second option, and I'd specify a "linear-rom" compatible value
> as well while we're at it.
> Both volatile and non-volatile RAMs can be handled by the physmap_of MTD
> driver. They both use the same map probe type ("map_ram"). Volatility isn't
> handled there.
> ROMs should be handled by the same driver and should use the "mtd_rom" map
> probe type.
OK, let's go with it.
> As all those devices use the physmap_of MTD driver, what about
> using "physmap-ram" and "physmap-rom" as compatibility names ?
Heh, we've gone thru "physmap" before -- it was labelled Linux-specific
name (well, I'd agree with that).
> Best regards,
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: ben@simtec.co.uk, linuxppc-dev@ozlabs.org,
linux-mtd@lists.infradead.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: OF compatible MTD platform RAM driver ?
Date: Wed, 26 Mar 2008 15:53:21 +0300 [thread overview]
Message-ID: <47EA4741.2050402@ru.mvista.com> (raw)
In-Reply-To: <200803251914.24021.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>>>Regarding non-volatility nothing prevents a user from using a
>>>volatile RAM as an MTD device, but there's little point in doing so.
>>>Would it be acceptable for the "linear-nvram" specification
>>>not to include > volatile RAM ? ROM chips would be excluded too. Is
>>that an issue ?
>>We actually use a volatile ram (SRAM) as an MTD device. We use it to
>>store info from bootloader and system specific values between resets.
> So we're left with two main options.
> - Reusing the nvram device type from the Device Support Extensions. Volatile
> devices wouldn't be supported, and we'd need a separate device specification
> for linear-mapped volatile RAMs. I'm not very happy with that.
> - Using another device node with a compatible value set to "linear-ram" (or
> something similar). This would support both volatile and non-volatile
> devices, and a property could be added to specify if the device is volatile
> or not.
> I'd go for the second option, and I'd specify a "linear-rom" compatible value
> as well while we're at it.
> Both volatile and non-volatile RAMs can be handled by the physmap_of MTD
> driver. They both use the same map probe type ("map_ram"). Volatility isn't
> handled there.
> ROMs should be handled by the same driver and should use the "mtd_rom" map
> probe type.
OK, let's go with it.
> As all those devices use the physmap_of MTD driver, what about
> using "physmap-ram" and "physmap-rom" as compatibility names ?
Heh, we've gone thru "physmap" before -- it was labelled Linux-specific
name (well, I'd agree with that).
> Best regards,
WBR, Sergei
next prev parent reply other threads:[~2008-03-26 12:51 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
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 [this message]
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=47EA4741.2050402@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=ben@simtec.co.uk \
--cc=david@gibson.dropbear.id.au \
--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.