diff for duplicates of <200903251514.01817.sr@denx.de> diff --git a/a/1.txt b/N1/1.txt index 94d8550..cb87daf 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,6 +1,6 @@ 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. =A0IIUC, when +> >> 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. @@ -14,34 +14,32 @@ On Wednesday 25 March 2009, Grant Likely wrote: > 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 tha= -t=20 -could be changed in physmap_of. I have to admit that I didn't fully debug i= -t. +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. =A0A +> >> 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? > > -> > =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}; +> > flash@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@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 diff --git a/a/content_digest b/N1/content_digest index a814057..ebaaf24 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,17 +1,18 @@ "ref\0200903231151.10373.sr@denx.de\0" "ref\0200903251035.28074.sr@denx.de\0" "ref\0fa686aa40903250628t1e5e97c0q340746dd78e61c83@mail.gmail.com\0" - "From\0Stefan Roese <sr@denx.de>\0" + "ref\0fa686aa40903250628t1e5e97c0q340746dd78e61c83-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org\0" + "From\0Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>\0" "Subject\0Re: physmap_of and partitions (mtd concat support)\0" "Date\0Wed, 25 Mar 2009 15:14:01 +0100\0" - "To\0Grant Likely <grant.likely@secretlab.ca>\0" - "Cc\0linuxppc-dev@ozlabs.org" - " devicetree-discuss list <devicetree-discuss@ozlabs.org>\0" + "To\0Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>\0" + "Cc\0linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org" + " devicetree-discuss list <devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>\0" "\00:1\0" "b\0" "On Wednesday 25 March 2009, Grant Likely wrote:\n" "> >> This case really does sound like a driver bug and that the existing\n" - "> >> cfi-flash binding is sufficient to describe the hardware. =A0IIUC, when\n" + "> >> cfi-flash binding is sufficient to describe the hardware. \302\240IIUC, when\n" "> >> all the flash chips are of the same type the physmap_of driver should\n" "> >> be smart enough to detect each of the flash chips within the reg\n" "> >> range.\n" @@ -25,34 +26,32 @@ "> chip it and calculated then end address of it can it not do another\n" "> full cfi probe for the rest of the reg range?\n" "\n" - "The \"real\" probing is done in the mtd core (cfi_probe). So it's nothing tha=\n" - "t=20\n" - "could be changed in physmap_of. I have to admit that I didn't fully debug i=\n" - "t.\n" + "The \"real\" probing is done in the mtd core (cfi_probe). So it's nothing that \n" + "could be changed in physmap_of. I have to admit that I didn't fully debug it.\n" "\n" "> Regardless, even if it could the solution you have below is probably a\n" "> better idea anyway than relying on probing.\n" ">\n" "> >> If I'm wrong and it cannot do this, then it would be a simple matter\n" - "> >> of adding an additional tuple to reg for each discrete chip. =A0A\n" + "> >> of adding an additional tuple to reg for each discrete chip. \302\240A\n" "> >> simple, backwards compatible extension which doesn't require a new\n" "> >> binding.\n" "> >\n" "> > So you are thinking of something like this?\n" "> >\n" - "> > =A0 =A0 =A0 =A0flash@f0000000,0 {\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D \"cfi-flash\";\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x00000000 0x02000000\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 0x02000000 0x02000000>;\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bank-width =3D <2>;\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device-width =3D <2>;\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0partition@0 {\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0label =3D \"test-part1\";\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x04000000>;\n" - "> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};\n" - "> > =A0 =A0 =A0 =A0};\n" + "> > \302\240 \302\240 \302\240 \302\240flash@f0000000,0 {\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240#address-cells = <1>;\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240#size-cells = <1>;\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240compatible = \"cfi-flash\";\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240reg = <0 0x00000000 0x02000000\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 0 0x02000000 0x02000000>;\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240bank-width = <2>;\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240device-width = <2>;\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240partition@0 {\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240label = \"test-part1\";\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240reg = <0 0x04000000>;\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240};\n" + "> > \302\240 \302\240 \302\240 \302\240};\n" ">\n" "> Yes, this looks good to me. In fact, it is probably better to be\n" "> explicit about multiple chips anyway in terms of providing the driver\n" @@ -65,4 +64,4 @@ "Best regards,\n" Stefan -2ee2ca4e5c22ae8a592a021a6d8d9add8424774a00c785039083b0943f1d2208 +434e7e8c984b7e2a31da132e1aea8ee3a0cc8ab55b99c73358d4a276e76e594b
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.