physmap_of and partitions (mtd concat support)

[Stefan Roese]

On Tuesday 24 March 2009, Grant Likely wrote:
> >> 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?

Yes, I know some. Even though they are currently not used with a partition 
spanning over those multiple chips (jedec and cfi).

> 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?

OK, in the example above such a spanning partition is not so likely. But think 
about my original example, the Intel P30 with two different cfi compatible 
chips on one die. Here a partition spanning over both devices is very likely.

As a sidenote: All this (concat over different chips) is possible with the 
physmap.c mapping driver which was used on most of my platforms in the "old" 
arch/ppc days.

> 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.

I think I like this idea. If nobody objects or has a better idea then I could 
start implementing it this way in a while.

Thanks.

Best regards,
Stefan