On Tue, Mar 24, 2009 at 9:39 AM, Stefan Roese <s...@denx.de> wrote: > 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).
OK >> 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. I agree. Same thing when two or more flash chips are put on a board in consecutive addresses. I've worked on plenty of these arrangements myself. This case really does sound like a driver bug and that the existing cfi-flash binding is sufficient to describe the hardware. IIUC, when all the flash chips are of the same type the physmap_of driver should be smart enough to detect each of the flash chips within the reg range. If I'm wrong and it cannot do this, then it would be a simple matter of adding an additional tuple to reg for each discrete chip. A simple, backwards compatible extension which doesn't require a new binding. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
