From: antoine.tenart@free-electrons.com (Antoine Tenart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 5/9] mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller
Date: Thu, 5 Mar 2015 14:08:43 +0100 [thread overview]
Message-ID: <20150305130843.GC5265@kwain> (raw)
In-Reply-To: <20150305140000.39081aa8@free-electrons.com>
Thomas,
On Thu, Mar 05, 2015 at 02:00:00PM +0100, Thomas Petazzoni wrote:
> 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?
I totally agree, this is one more thing wrong with this driver. Using a
ext id would solve the issue here.
If a NULL table is given to the nand_get_flash_type() function, then the
nand_flash_ids is used. This should be handled this way.
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-03-05 13:08 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
2015-03-05 13:08 ` Antoine Tenart [this message]
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=20150305130843.GC5265@kwain \
--to=antoine.tenart@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).