physmap_of and partitions (mtd concat support)

[Grant Likely]

On Tue, Mar 24, 2009 at 3:07 AM, Stefan Roese <sr at denx.de> wrote:
> On Monday 23 March 2009, Grant Likely wrote:
>> On Mon, Mar 23, 2009 at 4:51 AM, Stefan Roese <sr at denx.de> wrote:
>> > I just noticed that physmap_of can't handle multiple devices of different
>> > type described in one device node. For example the Intel P30 48F4400
>> > (64MByte) consists internally of 2 non-identical NOR chips. So a "simple"
>>
>> [...]
>>
>> > Now the real problem: How should I describe a partition in the device
>> > tree spanning over both devices (concat)?. The current physmap_of driver
>> > doesn't handle concat at all (physmap.c does). I already have some ideas
>> > on how to implement this concat support in physmap_of. But ideas about a
>> > device-tree syntax for such partitions are very welcome.
>>
>> Sounds to me like a physmap_of driver bug.  I don't think there is any
>> advantage in changing the partition syntax since concatenated flash
>> will always be used as a single device.  It doesn't make any sense to
>> try and span partitions over two nodes.
>
> Yes, I would really love to make this possible with only one flash node. But
> just think about the following system configuration:
>
> One Intel Strataflash (compatible = "cfi-flash") and one non-cfi compatible
> flash (e.g. compatible = "jedec-flash"). And the user wants to define a
> partition that spans over both flash chips. How could this be described in
> one flash node?
>
>> Do additional properties need to be added to describe the concat layout?
>
> Not sure. If we have multiple identical devices they can currently be
> described in one flash node. So with some changes to the physmap_of driver
> this configuration will work with concat as well. But more complex is a
> system configuration as described above. Meaning two or more non-identical
> chips. I don't see how this could be described in a sane way in one flash
> node.

Are there any such platforms?  Is there much likelihood that such a
platform will be created?  Would it even be a good idea to span
partitions across such an arrangement given that different devices
will behave differently?

I think just leave that arrangement as hypothetical until the
situation actually occurs.  If it does occur, then strongly recommend
to not span a partition across the boundary.  If someone really
insists on doing this then we can create a new binding for the
purpose; but leave the old binding as is.  Maybe something like:

mtd {
        #address-cells = <1>;
        #size-cells = <1>;
        compatibly = "weird-mtd-concat";
        devices = <&mtd1 &mtd2 &mtd3>;
        partition1 at 0 {
                reg = <0 0x100000>;
        };
        partition2 at 100000 {
                reg = <0x100000 0x100000>;
        };
}

Where mtd1, 2 & 3 point to real flash nodes.  That way the
concatenated MTD devices could be anything NAND, NOR, SRAM, whatever
and it doesn't have to try and overload the existing device bindings.

g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.