On Tuesday 25 March 2008 18:56, Rune Torgersen wrote: > Laurent Pinchart wrote: > > On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote: > >> 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.
As all those devices use the physmap_of MTD driver, what about
using "physmap-ram" and "physmap-rom" as compatibility names ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpUqXLkuZAbu.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
