Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart <laurentp@cse-semaphore.com>]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]