From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-mtd@lists.infradead.org,
Laurent Monat <laurent.monat@idquantique.com>,
thorsten.christiansson@idquantique.com,
Enrico Jorns <ejo@pengutronix.de>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
Dinh Nguyen <dinguyen@kernel.org>,
Marek Vasut <marek.vasut@gmail.com>,
Graham Moore <grmoore@opensource.altera.com>,
David Woodhouse <dwmw2@infradead.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Chuanxiao Dong <chuanxiao.dong@intel.com>,
Jassi Brar <jaswinder.singh@linaro.org>,
devicetree@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Brian Norris <computersforpeace@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [RESEND PATCH v2 26/53] mtd: nand: denali: support 1024 byte ECC step size
Date: Fri, 24 Mar 2017 09:02:26 +0100 [thread overview]
Message-ID: <20170324090226.112b2a2f@bbrezillon> (raw)
In-Reply-To: <CAK7LNAT3nVvTWUb9bCB_7XN-wb4k+XrHn-f6FHHoU9gcVeytrg@mail.gmail.com>
On Fri, 24 Mar 2017 12:23:01 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> >
> >>
> >>
> >> It is unrelated to the chips' requirements.
> >
> > It is related to the chip requirements.
> > Say you have a chip that requires a minimum of 4bits/512bytes. If you
> > want to convert that to a 1024byte block setting it's perfectly fine,
> > but then you'll have to meet (2 * ->ecc_strength_ds) for the
> > ecc.strength parameter.
>
> I think this example case is always fine from the
> "bigger ecc.size uses ECC more efficiently" we agreed.
> If 4bits/512bytes is achievable, 8bits/1024bytes is always met.
>
>
> The reverse is not always true.
> If the chip requires 8bits/1024bytes then controller uses 4bit/512bytes,
> this could be a reliability problem.
Yes. In this case, you can choose 8bits/512byte if your controller
supports it and the NAND has enough OOB bytes to store the ECC.
Otherwise, you try to do you best and pick 4bits/512bytes even if it's
a bit less reliable than 8bits/1024bytes.
>
>
>
> > The nand-ecc-strength and nand-ecc-step DT properties are here to
> > override the chip requirements and force a specific setting. This is
> > for example needed when the bootloader hardcodes an ECC setting without
> > taking the NAND chip requirements into account, and since you want to
> > read/write from both the bootloader and linux, you'll have to force this
> > specific ECC setting, but this case should be the exception, not the
> > default behavior.
>
> Yes, I also thought the case where the boot-loader hardcodes an ECC setting.
>
> Moreover, the Boot ROM really hard-codes (hard-wires)
> the ECC setting in some cases. On some Socionext UniPhier boards,
> users have no freedom to change the ECC settings.
Okay, in this case there's nothing you can choose indeed.
>
> So, DT property need to be supported somehow.
There's a difference between supporting the DT props and making them
mandatory. I never suggested to get rid of DT settings, just to use
NAND requirements when nothing is specified in the DT.
Anyway, if you want to keep this behavior, you should state in the
bindings doc that nand-ecc-step-size is mandatory for controllers
where the ECC block size is configurable (unless you don't support
such controllers yet).
next prev parent reply other threads:[~2017-03-24 8:02 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 20:06 [RESEND PATCH v2 00/53] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 01/53] mtd: nand: allow to set only one of ECC size and ECC strength from DT Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 02/53] mtd: nand: use read_oob() instead of cmdfunc() for bad block check Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 03/53] mtd: nand: denali: remove unused CONFIG option and macros Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 04/53] mtd: nand: denali: remove redundant define of BANK(x) Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 05/53] mtd: nand: denali: remove more unused struct members Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 06/53] mtd: nand: denali: fix comment of denali_nand_info::flash_mem Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 07/53] mtd: nand: denali: consolidate INTR_STATUS__* and INTR_EN__* macros Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 08/53] mtd: nand: denali: introduce capability flag Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 09/53] mtd: nand: denali: use int where no reason to use fixed width variable Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 10/53] mtd: nand: denali: fix erased page checking Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 11/53] mtd: nand: denali: fix bitflips calculation in handle_ecc() Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 12/53] mtd: nand: denali: support HW_ECC_FIXUP capability Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 13/53] mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant Masahiro Yamada
2017-03-29 2:00 ` Rob Herring
2017-03-22 20:07 ` [RESEND PATCH v2 14/53] mtd: nand: denali: support 64bit capable DMA engine Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 15/53] mtd: nand: denali_dt: remove dma-mask DT property Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 16/53] mtd: nand: denali_dt: use pdev instead of ofdev for platform_device Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 17/53] mtd: nand: denali: allow to override revision number Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 18/53] mtd: nand: denali: use nand_chip to hold frequently accessed data Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 19/53] mtd: nand: denali: call nand_set_flash_node() to set DT node Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 20/53] mtd: nand: denali: do not set mtd->name Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 21/53] mtd: nand: denali: move multi device fixup code to a helper function Masahiro Yamada
2017-03-27 16:13 ` Boris Brezillon
2017-03-22 20:07 ` [RESEND PATCH v2 22/53] mtd: nand: denali: simplify multi device fixup code Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 23/53] mtd: nand: denali: set DEVICES_CONNECTED 1 if not set Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 24/53] mtd: nand: denali: remove meaningless writes to read-only registers Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 25/53] mtd: nand: denali: remove unnecessary writes to ECC_CORRECTION Masahiro Yamada
2017-03-22 20:07 ` [RESEND PATCH v2 26/53] mtd: nand: denali: support 1024 byte ECC step size Masahiro Yamada
2017-03-22 21:32 ` Boris Brezillon
2017-03-23 6:53 ` Masahiro Yamada
2017-03-23 8:39 ` Boris Brezillon
2017-03-24 3:23 ` Masahiro Yamada
2017-03-24 8:02 ` Boris Brezillon [this message]
2017-03-22 21:35 ` [RESEND PATCH v2 00/53] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb Boris Brezillon
2017-03-23 1:54 ` Masahiro Yamada
2017-03-24 20:13 ` Boris Brezillon
2017-03-25 14:40 ` Masahiro Yamada
2017-03-28 20:14 ` Boris Brezillon
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=20170324090226.112b2a2f@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=chuanxiao.dong@intel.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@atmel.com \
--cc=devicetree@vger.kernel.org \
--cc=dinguyen@kernel.org \
--cc=dwmw2@infradead.org \
--cc=ejo@pengutronix.de \
--cc=grmoore@opensource.altera.com \
--cc=jaswinder.singh@linaro.org \
--cc=laurent.monat@idquantique.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=thorsten.christiansson@idquantique.com \
--cc=yamada.masahiro@socionext.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