mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Antoine Tenart <antoine.tenart@free-electrons.com>
Cc: sebastian.hesselbarth@gmail.com,
	ezequiel.garcia@free-electrons.com, dwmw2@infradead.org,
	computersforpeace@gmail.com, boris.brezillon@free-electrons.com,
	zmxu@marvell.com, jszhang@marvell.com,
	linux-arm-kernel@lists.infradead.org,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/9] mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller
Date: Thu, 5 Mar 2015 14:00:00 +0100	[thread overview]
Message-ID: <20150305140000.39081aa8@free-electrons.com> (raw)
In-Reply-To: <1425555085-29531-6-git-send-email-antoine.tenart@free-electrons.com>

Dear Antoine Tenart,

On Thu,  5 Mar 2015 12:31:21 +0100, Antoine Tenart wrote:

>  struct pxa3xx_nand_host {
> @@ -253,6 +258,12 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
>  { "512MiB 8-bit",  0xdc2c,  64, 2048,  8,  8, 4096 },
>  { "512MiB 16-bit", 0xcc2c,  64, 2048, 16, 16, 4096 },
>  { "256MiB 16-bit", 0xba20,  64, 2048, 16, 16, 2048 },
> +{ }
> +};
> +
> +static struct pxa3xx_nand_flash berlin_builtin_flash_types[] = {
> +{ "4GiB 8-bit",    0xd7ec, 128, 8192,  8,  8, 4096 },
> +{ },

This looks fishy. You know have two different definitions for the exact
same chip_id. In the builtin_flash_types[] array:

{ "4GiB 8-bit",    0xd7ec, 128, 4096,  8,  8, 8192 },

and in your new berlin_builtin_flash_types[] array:

{ "4GiB 8-bit",    0xd7ec, 128, 8192,  8,  8, 4096 },

So you have twice a big pages, and twice as less blocks. Are you sure
about your definition of the 0xd7ec NAND chip_id ?

Why cannot you use the same data for both the Berlin platform and the
platforms already supported by the driver? Are you sure your NAND isn't
using 4k pages ? Or maybe the 0xd7ec entry in builtin_flash_types[] is
incorrect?

Or maybe like
http://lists.infradead.org/pipermail/linux-mtd/2010-June/031159.html,
the NAND chip_id is the same, but the NAND ext id is different.

Is there no common NAND mechanism to handle this, rather than having
this specifically in the driver?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2015-03-05 13:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-05 11:31 [PATCH v3 0/9] ARM: berlin: add nand support Antoine Tenart
2015-03-05 11:31 ` [PATCH v3 1/9] mtd: pxa3xx_nand: add a non mandatory ECC clock Antoine Tenart
2015-03-05 11:31 ` [PATCH v3 2/9] Documentation: bindings: document the clocks for pxa3xx-nand Antoine Tenart
2015-03-05 11:31 ` [PATCH v3 3/9] mtd: pxa3xx_nand: add a default chunk size Antoine Tenart
2015-03-05 11:31 ` [PATCH v3 4/9] mtd: pxa3xx_nand: rework timings setup Antoine Tenart
2015-03-05 12:50   ` Thomas Petazzoni
2015-03-05 12:55     ` Antoine Tenart
2015-03-09 13:37   ` Ezequiel Garcia
2015-03-05 11:31 ` [PATCH v3 5/9] mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller Antoine Tenart
2015-03-05 13:00   ` Thomas Petazzoni [this message]
2015-03-05 13:08     ` Antoine Tenart
2015-03-07  3:18   ` Ezequiel Garcia
2015-03-08 17:14     ` Robert Jarzmik
2015-03-08 20:22       ` Ezequiel Garcia
2015-03-08 22:19         ` Robert Jarzmik
2015-03-09 11:37           ` Ezequiel Garcia
2015-03-09 20:15             ` Robert Jarzmik
2015-03-05 11:31 ` [PATCH v3 6/9] Documentation: bindings: add the Berlin nand controller compatible Antoine Tenart
2015-03-05 11:31 ` [PATCH v3 7/9] mtd: nand: let Marvell Berlin SoCs select the pxa3xx driver Antoine Tenart
2015-03-05 11:31 ` [PATCH v3 8/9] ARM: berlin: add BG2Q node for the nand Antoine Tenart
2015-03-05 11:31 ` [PATCH v3 9/9] ARM: berlin: enable flash on the BG2Q DMP Antoine Tenart

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=20150305140000.39081aa8@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=antoine.tenart@free-electrons.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=zmxu@marvell.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

Powered by JetHome