From: Sergio Prado <sergio.prado@e-labworks.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: dwmw2@infradead.org, computersforpeace@gmail.com,
robh+dt@kernel.org, mark.rutland@arm.com, kgene@kernel.org,
k.kozlowski@samsung.com, richard@nod.at,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH] mtd: s3c2410: add device tree support
Date: Sun, 25 Sep 2016 14:42:57 -0300 [thread overview]
Message-ID: <20160925174257.GA20238@sprado-desktop> (raw)
In-Reply-To: <20160917193123.762587d0@bbrezillon>
Hi Boris,
> > +Optional properties:
> > +- samsung,tacls : time for active CLE/ALE to nWE/nOE
> > +- samsung,twrph0 : active time for nWE/nOE
> > +- samsung,twrph1 : time for release CLE/ALE from nWE/nOE inactive
>
> Can you try to extract these information from the nand_sdr_timings
> struct instead of passing it in your DT?
I've tested and the nand chip I'm working on is not ONFI or JEDEC
compatible, so looks like it is not possible to extract the timing
information from nand_sdr_timings. Am I right?
> > + samsung,ignore_unset_ecc;
>
> Just discovered this ->ignore_unset_ecc property, and I don't
> understand why it's here for...
> Either you don't want to have ECC, and in this case you should set
> NAND_ECC_NONE, or you want to have ECC calculated, and in this case,
> the only valid situation where ECC bytes are 0xff is when the page is
> erased.
>
> If I'm right, please fix the driver instead of adding this DT property.
> If I'm wrong, could you explain in more detail when you have ECC bytes
> set to 0xff?
I think you are right but I am not an expert on flash devices and the
MTD sub-system. The commit message of this code says "If a block's ecc
field is all 0xff, then ignore the ECC correction. This is for systems
where some of the blocks, such as the initial cramfs are written without
ECC and need to be loaded on start.". Does it make sense?
> > + for_each_available_child_of_node(np, child) {
> > +
> > + sets->name = (char *)child->name;
> > + sets->of_node = child;
> > + sets->nr_chips = 1;
> > +
> > + if (!of_property_match_string(child, "nand-ecc-mode", "none"))
> > + sets->disable_ecc = 1;
> > +
> > + if (of_get_property(child, "nand-on-flash-bbt", NULL))
> > + sets->flash_bbt = 1;
> > +
>
> These properties are automatically extracted in nand_scan_ident(), why
> do you need to parse them twice?
>
You are right, there is no need to parse them twice. But taking a look
at the code I found a problem. Right now enabling hardware ECC is done
at compile time by enabling CONFIG_MTD_NAND_S3C2410_HWECC in the
menuconfig. Looks like this config option should be removed so we can
select ECC mode using nand-ecc-mode property in the device tree. But
this would break current boards that are not using a device tree. So it
would be necessary to add a ecc_mode field in the platform_data of these
boards and set them all to the default ECC mode (NAND_ECC_SOFT). Is this
the right approach?
Thanks!
--
Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
next prev parent reply other threads:[~2016-09-25 17:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20160917152404eucas1p2ca0ebfe59dd762f5cdd611a9dd3cd1a5@eucas1p2.samsung.com>
2016-09-17 15:22 ` [PATCH] mtd: s3c2410: add device tree support Sergio Prado
2016-09-17 17:31 ` Boris Brezillon
2016-09-20 2:08 ` Sergio Prado
2016-09-25 17:42 ` Sergio Prado [this message]
2016-09-25 18:05 ` Boris Brezillon
2016-09-19 9:11 ` Mark Rutland
2016-09-20 2:24 ` Sergio Prado
2016-09-19 10:44 ` Sylwester Nawrocki
[not found] ` <f8907616-0d6b-37ef-1419-f6aedf3ddbdc-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-09-20 2:31 ` Sergio Prado
2016-09-23 17:44 ` Rob Herring
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=20160925174257.GA20238@sprado-desktop \
--to=sergio.prado@e-labworks.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=k.kozlowski@samsung.com \
--cc=kgene@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.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).