| Message ID | 1417097929-17832-1-git-send-email-sr@denx.de |
|---|---|
| State | Accepted, archived |
| Commit | ed0215cc3b5292fc0f4af70e29dc61fa2d0aa76c |
| Headers | show |
On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: > This sentence "We support only one NAND chip now" is not true any more. > Multiple chips are supported. So lets remove this sentence to not The gpmi can only supports one chip. Of course, there are maybe two dies in this single chip. thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 28.11.2014 02:48, Huang Shijie wrote: > On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: >> This sentence "We support only one NAND chip now" is not true any more. >> Multiple chips are supported. So lets remove this sentence to not > > The gpmi can only supports one chip. Of course, there are maybe two dies > in this single chip. Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't "two dies in this single chip" not practically the same as connecting 2 (or more) chips (same device) to multiple chip selects of the SoC? Where is the difference here? Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: > On 28.11.2014 02:48, Huang Shijie wrote: > >On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: > >>This sentence "We support only one NAND chip now" is not true any more. > >>Multiple chips are supported. So lets remove this sentence to not > > > >The gpmi can only supports one chip. Of course, there are maybe two dies > >in this single chip. > > Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't > "two dies in this single chip" not practically the same as connecting 2 (or > more) chips (same device) to multiple chip selects of the SoC? Where is the > difference here? The "one chip" here is means the "one package" (TSOP or BGA ....). (In logic, "two dies in this single chip" is same as connecting 2 chips to the gpmi.) thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 29, 2014 at 10:40:50AM +0800, Huang Shijie wrote: > On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: > > On 28.11.2014 02:48, Huang Shijie wrote: > > >On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: > > >>This sentence "We support only one NAND chip now" is not true any more. > > >>Multiple chips are supported. So lets remove this sentence to not > > > > > >The gpmi can only supports one chip. Of course, there are maybe two dies > > >in this single chip. > > > > Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't > > "two dies in this single chip" not practically the same as connecting 2 (or > > more) chips (same device) to multiple chip selects of the SoC? Where is the > > difference here? > The "one chip" here is means the "one package" (TSOP or BGA ....). Then why is this even in the DT binding doc? Isn't that a board-level constraint (and not a chip property) which should be obvious to the user? If so, then should we just drop the language? Or at a minimum, make it more specific so it doesn't confuse readers. > (In logic, "two dies in this single chip" is same as connecting 2 chips > to the gpmi.) ...which means that logically, you can connect more than one chip to the GPMI, right? Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 29, 2014 at 10:53:26PM -0800, Brian Norris wrote: > On Sat, Nov 29, 2014 at 10:40:50AM +0800, Huang Shijie wrote: > > On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: > > > On 28.11.2014 02:48, Huang Shijie wrote: > > > >On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: > > > >>This sentence "We support only one NAND chip now" is not true any more. > > > >>Multiple chips are supported. So lets remove this sentence to not > > > > > > > >The gpmi can only supports one chip. Of course, there are maybe two dies > > > >in this single chip. > > > > > > Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't > > > "two dies in this single chip" not practically the same as connecting 2 (or > > > more) chips (same device) to multiple chip selects of the SoC? Where is the > > > difference here? > > The "one chip" here is means the "one package" (TSOP or BGA ....). > > Then why is this even in the DT binding doc? Isn't that a board-level > constraint (and not a chip property) which should be obvious to the > user? If so, then should we just drop the language? Or at a minimum, > make it more specific so it doesn't confuse readers. yes. It is okay to send a patch to make it more clear. > > > (In logic, "two dies in this single chip" is same as connecting 2 chips > > to the gpmi.) > > ...which means that logically, you can connect more than one chip to the > GPMI, right? The gpmi can only connect with one physical chip now, but there maybe two DIEs in this chip. thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 30.11.2014 16:42, Huang Shijie wrote: > On Sat, Nov 29, 2014 at 10:53:26PM -0800, Brian Norris wrote: >> On Sat, Nov 29, 2014 at 10:40:50AM +0800, Huang Shijie wrote: >>> On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: >>>> On 28.11.2014 02:48, Huang Shijie wrote: >>>>> On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: >>>>>> This sentence "We support only one NAND chip now" is not true any more. >>>>>> Multiple chips are supported. So lets remove this sentence to not >>>>> >>>>> The gpmi can only supports one chip. Of course, there are maybe two dies >>>>> in this single chip. >>>> >>>> Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't >>>> "two dies in this single chip" not practically the same as connecting 2 (or >>>> more) chips (same device) to multiple chip selects of the SoC? Where is the >>>> difference here? >>> The "one chip" here is means the "one package" (TSOP or BGA ....). >> >> Then why is this even in the DT binding doc? Isn't that a board-level >> constraint (and not a chip property) which should be obvious to the >> user? If so, then should we just drop the language? Or at a minimum, >> make it more specific so it doesn't confuse readers. > > yes. It is okay to send a patch to make it more clear. > >> >>> (In logic, "two dies in this single chip" is same as connecting 2 chips >>> to the gpmi.) >> >> ...which means that logically, you can connect more than one chip to the >> GPMI, right? > The gpmi can only connect with one physical chip now, but there maybe > two DIEs in this chip. I really fail to see why you make this distinction between two chips on a die and two external chips. For the SoC this should really look identical, right? Please explain again, why exactly only two chips on one die are supported. BTW: We have a custom i.MX6DL based board with 2 NAND chips connected. And Linux seems to support both chips just fine. Here the boot log: [ 1.085812] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc [ 1.092218] nand: Micron MT29F4G08ABADAH4 [ 1.096245] nand: 512MiB, SLC, page size: 2048, OOB size: 64 [ 1.102171] nand: 2 chips detected [ 1.106156] gpmi-nand 112000.gpmi-nand: enable the asynchronous EDO mode 5 [ 1.113094] Scanning device for bad blocks Comments welcome... Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 01, 2014 at 10:58:17AM +0100, Stefan Roese wrote: > On 30.11.2014 16:42, Huang Shijie wrote: > > On Sat, Nov 29, 2014 at 10:53:26PM -0800, Brian Norris wrote: > >> On Sat, Nov 29, 2014 at 10:40:50AM +0800, Huang Shijie wrote: > >>> On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: > >>>> On 28.11.2014 02:48, Huang Shijie wrote: > >>>>> On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: > >>>>>> This sentence "We support only one NAND chip now" is not true any more. > >>>>>> Multiple chips are supported. So lets remove this sentence to not > >>>>> > >>>>> The gpmi can only supports one chip. Of course, there are maybe two dies > >>>>> in this single chip. > >>>> > >>>> Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't > >>>> "two dies in this single chip" not practically the same as connecting 2 (or > >>>> more) chips (same device) to multiple chip selects of the SoC? Where is the > >>>> difference here? > >>> The "one chip" here is means the "one package" (TSOP or BGA ....). > >> > >> Then why is this even in the DT binding doc? Isn't that a board-level > >> constraint (and not a chip property) which should be obvious to the > >> user? If so, then should we just drop the language? Or at a minimum, > >> make it more specific so it doesn't confuse readers. > > > > yes. It is okay to send a patch to make it more clear. > > > >> > >>> (In logic, "two dies in this single chip" is same as connecting 2 chips > >>> to the gpmi.) > >> > >> ...which means that logically, you can connect more than one chip to the > >> GPMI, right? > > The gpmi can only connect with one physical chip now, but there maybe > > two DIEs in this chip. > > I really fail to see why you make this distinction between two chips on a die > and two external chips. For the SoC this should really look identical, right? > > Please explain again, why exactly only two chips on one die are supported. There are only 8 data lines for gpmi. I guess there may bugs in the gpmi driver to support the two external chips in such case: Two different processes access different NAND chips at the same time. I even did not have enough time to test the "two chips on a die" case very carefully before I left freescale. > > BTW: We have a custom i.MX6DL based board with 2 NAND chips connected. And Very good. Please test this board with the UBIFS in the multi processes case. (I ever used the bonnie++) > Linux seems to support both chips just fine. Here the boot log: > > [ 1.085812] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc > [ 1.092218] nand: Micron MT29F4G08ABADAH4 > [ 1.096245] nand: 512MiB, SLC, page size: 2048, OOB size: 64 > [ 1.102171] nand: 2 chips detected > [ 1.106156] gpmi-nand 112000.gpmi-nand: enable the asynchronous EDO mode 5 > [ 1.113094] Scanning device for bad blocks could you please post more log? thanks Huang Shijie > > Comments welcome... > > Thanks, > Stefan > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02.12.2014 01:38, Huang Shijie wrote: > On Mon, Dec 01, 2014 at 10:58:17AM +0100, Stefan Roese wrote: >> On 30.11.2014 16:42, Huang Shijie wrote: >>> On Sat, Nov 29, 2014 at 10:53:26PM -0800, Brian Norris wrote: >>>> On Sat, Nov 29, 2014 at 10:40:50AM +0800, Huang Shijie wrote: >>>>> On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: >>>>>> On 28.11.2014 02:48, Huang Shijie wrote: >>>>>>> On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: >>>>>>>> This sentence "We support only one NAND chip now" is not true any more. >>>>>>>> Multiple chips are supported. So lets remove this sentence to not >>>>>>> >>>>>>> The gpmi can only supports one chip. Of course, there are maybe two dies >>>>>>> in this single chip. >>>>>> >>>>>> Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't >>>>>> "two dies in this single chip" not practically the same as connecting 2 (or >>>>>> more) chips (same device) to multiple chip selects of the SoC? Where is the >>>>>> difference here? >>>>> The "one chip" here is means the "one package" (TSOP or BGA ....). >>>> >>>> Then why is this even in the DT binding doc? Isn't that a board-level >>>> constraint (and not a chip property) which should be obvious to the >>>> user? If so, then should we just drop the language? Or at a minimum, >>>> make it more specific so it doesn't confuse readers. >>> >>> yes. It is okay to send a patch to make it more clear. >>> >>>> >>>>> (In logic, "two dies in this single chip" is same as connecting 2 chips >>>>> to the gpmi.) >>>> >>>> ...which means that logically, you can connect more than one chip to the >>>> GPMI, right? >>> The gpmi can only connect with one physical chip now, but there maybe >>> two DIEs in this chip. >> >> I really fail to see why you make this distinction between two chips on a die >> and two external chips. For the SoC this should really look identical, right? >> >> Please explain again, why exactly only two chips on one die are supported. > There are only 8 data lines for gpmi. I guess there may bugs in the > gpmi driver to support the two external chips in such case: > Two different processes access different NAND chips at the same > time. I don't see why this should be a problem. All SoC's that support multiple NAND chips (I've seen so far) only use 8 data lines for this. > I even did not have enough time to test the "two chips on a die" case very carefully before > I left freescale. I see. Thanks for the hint. But this "two chips on a die" scenario did pass some basic tests, no? >> >> BTW: We have a custom i.MX6DL based board with 2 NAND chips connected. And > > Very good. Please test this board with the UBIFS in the multi processes > case. (I ever used the bonnie++) We'll do that. >> Linux seems to support both chips just fine. Here the boot log: >> >> [ 1.085812] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc >> [ 1.092218] nand: Micron MT29F4G08ABADAH4 >> [ 1.096245] nand: 512MiB, SLC, page size: 2048, OOB size: 64 >> [ 1.102171] nand: 2 chips detected >> [ 1.106156] gpmi-nand 112000.gpmi-nand: enable the asynchronous EDO mode 5 >> [ 1.113094] Scanning device for bad blocks > could you please post more log? Sure. ... [ 1.068580] loop: module loaded [ 1.085966] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc [ 1.092372] nand: Micron MT29F4G08ABADAH4 [ 1.096401] nand: 512MiB, SLC, page size: 2048, OOB size: 64 [ 1.102331] nand: 2 chips detected [ 1.106342] gpmi-nand 112000.gpmi-nand: enable the asynchronous EDO mode 5 [ 1.113279] Scanning device for bad blocks [ 1.126196] Bad eraseblock 58 at 0x000000740000 [ 1.131074] Bad eraseblock 60 at 0x000000780000 [ 1.515182] random: nonblocking pool is initialized [ 2.331738] 10 cmdlinepart partitions found on MTD device gpmi-nand [ 2.338028] Creating 10 MTD partitions on "gpmi-nand": [ 2.343210] 0x000000000000-0x000000e00000 : "spl" [ 2.351695] 0x000000e00000-0x000001000000 : "uboot" [ 2.359015] 0x000001000000-0x000001080000 : "env1" [ 2.366272] 0x000001080000-0x000001100000 : "env2" [ 2.373508] 0x000001100000-0x000020000000 : "ubi0" [ 2.381521] 0x000020000000-0x000020e00000 : "res0" [ 2.388781] 0x000020e00000-0x000021000000 : "res1" [ 2.396131] 0x000021000000-0x000021080000 : "res2" [ 2.403458] 0x000021080000-0x000021100000 : "res3" [ 2.410657] 0x000021100000-0x000040000000 : "ubi1" [ 2.418572] gpmi-nand 112000.gpmi-nand: driver registered. [ 2.428911] spi_imx 2008000.ecspi: probed ... Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 02, 2014 at 08:28:10AM +0100, Stefan Roese wrote: > On 02.12.2014 01:38, Huang Shijie wrote: > > On Mon, Dec 01, 2014 at 10:58:17AM +0100, Stefan Roese wrote: > >> On 30.11.2014 16:42, Huang Shijie wrote: > >>> On Sat, Nov 29, 2014 at 10:53:26PM -0800, Brian Norris wrote: > >>>> On Sat, Nov 29, 2014 at 10:40:50AM +0800, Huang Shijie wrote: > >>>>> On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: > >>>>>> On 28.11.2014 02:48, Huang Shijie wrote: > >>>>>>> On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: > >>>>>>>> This sentence "We support only one NAND chip now" is not true any more. > >>>>>>>> Multiple chips are supported. So lets remove this sentence to not > >>>>>>> > >>>>>>> The gpmi can only supports one chip. Of course, there are maybe two dies > >>>>>>> in this single chip. > >>>>>> > >>>>>> Now I'm a bit confused. The i.MX6 supports 4 chips select signals. And isn't > >>>>>> "two dies in this single chip" not practically the same as connecting 2 (or > >>>>>> more) chips (same device) to multiple chip selects of the SoC? Where is the > >>>>>> difference here? > >>>>> The "one chip" here is means the "one package" (TSOP or BGA ....). > >>>> > >>>> Then why is this even in the DT binding doc? Isn't that a board-level > >>>> constraint (and not a chip property) which should be obvious to the > >>>> user? If so, then should we just drop the language? Or at a minimum, > >>>> make it more specific so it doesn't confuse readers. > >>> > >>> yes. It is okay to send a patch to make it more clear. > >>> > >>>> > >>>>> (In logic, "two dies in this single chip" is same as connecting 2 chips > >>>>> to the gpmi.) > >>>> > >>>> ...which means that logically, you can connect more than one chip to the > >>>> GPMI, right? > >>> The gpmi can only connect with one physical chip now, but there maybe > >>> two DIEs in this chip. > >> > >> I really fail to see why you make this distinction between two chips on a die > >> and two external chips. For the SoC this should really look identical, right? > >> > >> Please explain again, why exactly only two chips on one die are supported. > > There are only 8 data lines for gpmi. I guess there may bugs in the > > gpmi driver to support the two external chips in such case: > > Two different processes access different NAND chips at the same > > time. > > I don't see why this should be a problem. All SoC's that support multiple > NAND chips (I've seen so far) only use 8 data lines for this. ok. If your test result can prove that the gpmi can support two chips. I can ack this patch. (I ever thought the gpmi needs an extra patch to support the multiple chips) > > > I even did not have enough time to test the "two chips on a die" case very carefully before > > I left freescale. > > I see. Thanks for the hint. But this "two chips on a die" scenario did > pass some basic tests, no? yes. It passed the bonnie++ test. thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 03, 2014 at 08:35:42AM +0800, Huang Shijie wrote: > On Tue, Dec 02, 2014 at 08:28:10AM +0100, Stefan Roese wrote: > > On 02.12.2014 01:38, Huang Shijie wrote: > > > On Mon, Dec 01, 2014 at 10:58:17AM +0100, Stefan Roese wrote: > > >> On 30.11.2014 16:42, Huang Shijie wrote: > > >>> On Sat, Nov 29, 2014 at 10:53:26PM -0800, Brian Norris wrote: > > >>>> On Sat, Nov 29, 2014 at 10:40:50AM +0800, Huang Shijie wrote: > > >>>>> On Fri, Nov 28, 2014 at 08:01:41AM +0100, Stefan Roese wrote: > > >>>>>> On 28.11.2014 02:48, Huang Shijie wrote: > > >>>>>>> On Thu, Nov 27, 2014 at 03:18:49PM +0100, Stefan Roese wrote: > > >>>>>>>> This sentence "We support only one NAND chip now" is not true any more. > > >>>>>>>> Multiple chips are supported. So lets remove this sentence to not > > >>>>>>> > > >>>>>>> The gpmi can only supports one chip. Of course, there are maybe two dies > > >>>>>>> in this single chip. [...] > If your test result can prove that the gpmi can support two chips. > > I can ack this patch. (I ever thought the gpmi needs an extra patch to > support the multiple chips) > > > > > > I even did not have enough time to test the "two chips on a die" case very carefully before > > > I left freescale. > > > > I see. Thanks for the hint. But this "two chips on a die" scenario did > > pass some basic tests, no? > yes. It passed the bonnie++ test. If there are no more concrete objections, I'll apply this patch. Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 16, 2014 at 05:17:57PM -0800, Brian Norris wrote:
> If there are no more concrete objections, I'll apply this patch.
Applied to l2-mtd.git/next.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt index a011fdf..d02acaf 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt @@ -1,7 +1,7 @@ * Freescale General-Purpose Media Interface (GPMI) The GPMI nand controller provides an interface to control the -NAND flash chips. We support only one NAND chip now. +NAND flash chips. Required properties: - compatible : should be "fsl,<chip>-gpmi-nand"
This sentence "We support only one NAND chip now" is not true any more. Multiple chips are supported. So lets remove this sentence to not confuse anyone. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Huang Shijie <b32955@freescale.com> Cc: Brian Norris <computersforpeace@gmail.com> --- Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)