physmap_of and partitions (mtd concat support)

[Stefan Roese]

On Wednesday 25 March 2009, Grant Likely wrote:
> >> 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.
> >
> > *When* all are identical then this works, yes. But in the Intel P30 case
> > the 2 chips are not identical. And from my understanding this is not a
> > problem/bug in the physmap_of driver.
>
> To satisfy my own curiosity, why is physmap_of unable to probe
> multiple cfi chips that are non identical?  After detecting the first
> chip it and calculated then end address of it can it not do another
> full cfi probe for the rest of the reg range?

The "real" probing is done in the mtd core (cfi_probe). So it's nothing that 
could be changed in physmap_of. I have to admit that I didn't fully debug it.

> Regardless, even if it could the solution you have below is probably a
> better idea anyway than relying on probing.
>
> >> 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.
> >
> > So you are thinking of something like this?
> >
> >        flash at f0000000,0 {
> >                #address-cells = <1>;
> >                #size-cells = <1>;
> >                compatible = "cfi-flash";
> >                reg = <0 0x00000000 0x02000000
> >                       0 0x02000000 0x02000000>;
> >                bank-width = <2>;
> >                device-width = <2>;
> >                partition at 0 {
> >                        label = "test-part1";
> >                        reg = <0 0x04000000>;
> >                };
> >        };
>
> Yes, this looks good to me.  In fact, it is probably better to be
> explicit about multiple chips anyway in terms of providing the driver
> as much information as possible about where to probe for the chips.
> It also elegantly supports sparsely mapped flash chips (ie. if the
> board supports larger chips than is actually populated).

OK, then we have a solution. Grant, thanks for your input here.

Best regards,
Stefan