From: Stefan Roese <sr@denx.de>
To: Huang Shijie <shijie8@gmail.com>,
Brian Norris <computersforpeace@gmail.com>
Cc: devicetree@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] mtd: gpmi: Remove "We support only one NAND chip" from bindings doc
Date: Mon, 01 Dec 2014 10:58:17 +0100 [thread overview]
Message-ID: <547C3BB9.1010706@denx.de> (raw)
In-Reply-To: <20141130154255.GB14834@localhost.localdomain>
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
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
To: Huang Shijie <shijie8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Brian Norris
<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] mtd: gpmi: Remove "We support only one NAND chip" from bindings doc
Date: Mon, 01 Dec 2014 10:58:17 +0100 [thread overview]
Message-ID: <547C3BB9.1010706@denx.de> (raw)
In-Reply-To: <20141130154255.GB14834-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-12-01 9:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 14:18 [PATCH] mtd: gpmi: Remove "We support only one NAND chip" from bindings doc Stefan Roese
2014-11-27 14:18 ` Stefan Roese
2014-11-28 1:48 ` Huang Shijie
2014-11-28 1:48 ` Huang Shijie
2014-11-28 7:01 ` Stefan Roese
2014-11-28 7:01 ` Stefan Roese
2014-11-29 2:40 ` Huang Shijie
2014-11-29 2:40 ` Huang Shijie
2014-11-30 6:53 ` Brian Norris
2014-11-30 6:53 ` Brian Norris
2014-11-30 15:42 ` Huang Shijie
2014-11-30 15:42 ` Huang Shijie
2014-12-01 9:58 ` Stefan Roese [this message]
2014-12-01 9:58 ` Stefan Roese
2014-12-02 0:38 ` Huang Shijie
2014-12-02 0:38 ` Huang Shijie
2014-12-02 7:28 ` Stefan Roese
2014-12-02 7:28 ` Stefan Roese
2014-12-03 0:35 ` Huang Shijie
2014-12-03 0:35 ` Huang Shijie
2014-12-17 1:17 ` Brian Norris
2014-12-17 1:17 ` Brian Norris
2014-12-18 2:45 ` Brian Norris
2014-12-18 2:45 ` Brian Norris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=547C3BB9.1010706@denx.de \
--to=sr@denx.de \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=shijie8@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.