OF compatible MTD platform RAM driver ?

Sergei Shtylyov sshtylyov at ru.mvista.com
Wed Mar 26 23:53:21 EST 2008


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




More information about the Linuxppc-dev mailing list