linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Marek Vasut <marex@denx.de>,
	Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Scott Wood <scottwood@freescale.com>, Josh Wu <josh.wu@atmel.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Han Xu <han.xu@freescale.com>,
	Huang Shijie <shijie.huang@arm.com>
Subject: Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node
Date: Thu, 29 Oct 2015 21:28:01 +0100	[thread overview]
Message-ID: <87wpu5ifn2.fsf@belgarion.home> (raw)
In-Reply-To: <20151029183421.5d2c73cf@bbrezillon> (Boris Brezillon's message of "Thu, 29 Oct 2015 18:34:21 +0100")

Boris Brezillon <boris.brezillon@free-electrons.com> writes:

> On Thu, 29 Oct 2015 18:23:47 +0100
> Marek Vasut <marex@denx.de> wrote:
> Except it's now how devices supporting 16 bits data bus are supposed to
> work, which means your NAND controller will probably not be able to
> send the command/address value on the higher 8 bits...
Correct.

>> > 2/ NAND chips can have bad blocks, so even if you were able to address
>> > 2 chips (which according to #1 is impossible), you might try to write
>> > on a bad block on the chip connected on the MSB side of the data bus.
>> 
>> This one is a valid problem. The other valid issue here is where the
>> command might fail on one chip and pass on the other.
Probably the bad block wins, and the command is reported as a failure.

>> > 3/ There probably are plenty of other reasons why this is not
>> > possible ;-).
>> 
>> It's possible, implementable, but a really bad idea.
>
> Possible and implementable, maybe with an adapted software stack
> and a customized NAND controller. I know you're working on emulating
> flash devices using FPGA, so the next step is to create a new NAND
> controller IP supporting that kind of stuff and adding support for
> this feature to the NAND framework ;-).
> Anyway, it"s definitely a bad idea.
I agree, a bad idea.

Just to finish the discussion, let me quote the pxa3xx developper manual volume
2, chapter 3.7.6.1 "Flash Memory Data Width when Two Flash Devices Connect to
the Same Chip" :
    When NDCR[DWIDTH_C] = 1 and NDCR[DWIDTH_M] = 0, two flash devices are
    connected to the same chip select with DF_IO<7:0> interfacing to one device,
    and DF_IO<15:8> interfacing to the second device. In this scenario, since
    two devices are accessed simultaneously, the command and address are
    replicated between the lower and upper byte of the interface.

Now, regardless of this, please continue with your patches, this corner case is
not important, at least I don't care at all.

Cheers.

-- 
Robert

  reply	other threads:[~2015-10-29 20:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-27  2:31 [PATCH 0/5] mtd: migrate 'of_node' handling to core, not in mtd_part_parser_data Brian Norris
2015-10-27  2:31 ` [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node Brian Norris
2015-10-27  7:42   ` Boris Brezillon
2015-10-27 17:54     ` Brian Norris
2015-10-28  1:01       ` Brian Norris
2015-10-28  8:02         ` Boris Brezillon
2015-10-28  7:58       ` Boris Brezillon
2015-10-28 16:11         ` Marek Vasut
2015-10-28 16:32           ` Boris Brezillon
2015-10-28 17:14             ` Brian Norris
2015-10-28 20:55               ` Robert Jarzmik
2015-10-28 22:47                 ` Marek Vasut
2015-10-29  6:32                   ` Robert Jarzmik
2015-10-29  7:24                     ` Boris Brezillon
2015-10-29 17:23                       ` Marek Vasut
2015-10-29 17:34                         ` Boris Brezillon
2015-10-29 20:28                           ` Robert Jarzmik [this message]
2015-10-28 20:38             ` Marek Vasut
2015-10-27  2:31 ` [PATCH 2/5] mtd: nand: drop unnecessary partition parser data Brian Norris
2015-10-27  7:52   ` Boris Brezillon
2015-10-28  0:45   ` Brian Norris
2015-10-27  2:31 ` [PATCH 3/5] mtd: spi-nor: " Brian Norris
2015-10-27  2:31 ` [PATCH 4/5] mtd: " Brian Norris
2015-10-27  2:31 ` [PATCH 5/5] mtd: drop 'of_node' " 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=87wpu5ifn2.fsf@belgarion.home \
    --to=robert.jarzmik@free.fr \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=han.xu@freescale.com \
    --cc=josh.wu@atmel.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.de \
    --cc=scottwood@freescale.com \
    --cc=shijie.huang@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).