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? > > > > fl...@f0000000,0 { > > #address-cells = <1>; > > #size-cells = <1>; > > compatible = "cfi-flash"; > > reg = <0 0x00000000 0x02000000 > > 0 0x02000000 0x02000000>; > > bank-width = <2>; > > device-width = <2>; > > partit...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev