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>;
> partiti...@0 {
> reg = <0 0x100000>;
> };
> partiti...@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
