Re: physmap_of and partitions (mtd concat support)

On Wed, Mar 25, 2009 at 3:35 AM, Stefan Roese [off-list ref] wrote:

On Tuesday 24 March 2009, Grant Likely wrote:

quoted

quoted

OK, in the example above such a spanning partition is not so likely. B=

ut

quoted

quoted

think about my original example, the Intel P30 with two different cfi
compatible chips on one die. Here a partition spanning over both devic=

es

quoted

quoted

is very likely.

I agree. =A0Same thing when two or more flash chips are put on a board
in consecutive addresses. =A0I've worked on plenty of these arrangements
myself.

Yes, multiple identical devices are no problem at all. This is handled
correctly with the current code and device tree syntax.

quoted

This case really does sound like a driver bug and that the existing
cfi-flash binding is sufficient to describe the hardware. =A0IIUC, 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?

Regardless, even if it could the solution you have below is probably a
better idea anyway than relying on probing.

quoted

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. =A0A
simple, backwards compatible extension which doesn't require a new
binding.

So you are thinking of something like this?

=A0 =A0 =A0 =A0flash@f0000000,0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "cfi-flash";
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x00000000 0x02000000
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 0x02000000 0x02000000>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bank-width =3D <2>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device-width =3D <2>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0partition@0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0label =3D "test-part1";
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x04000000>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
=A0 =A0 =A0 =A0};

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

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.