public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: xiaolei li <xiaolei.li@mediatek.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: <richard@nod.at>, <linux-mediatek@lists.infradead.org>,
	<linux-mtd@lists.infradead.org>, <srv_heupstream@mediatek.com>
Subject: Re: [PATCH 3/8] mtd: rawnand: mtk: Add DT property mtk,fdm-ecc-size
Date: Thu, 12 Apr 2018 13:36:52 +0800	[thread overview]
Message-ID: <1523511412.14673.21.camel@mhfsdcap03> (raw)
In-Reply-To: <20180411211308.436d19c0@bbrezillon>

Hi Boris,

On Wed, 2018-04-11 at 21:13 +0200, Boris Brezillon wrote:
> On Wed, 11 Apr 2018 11:41:53 +0800
> Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> 
> > For some MTK NAND chips, BootROM may access more than one byte
> > ECC protected FDM data, but now we fix ECC protected FDM byte as 1.
> > This will make some chips be failed to boot up.
> > 
> > With this DT property setting, different MTK NAND chips with the same
> > NAND controller IP can work well.
> > 
> > Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
> > ---
> >  Documentation/devicetree/bindings/mtd/mtk-nand.txt |  6 ++++++
> >  drivers/mtd/nand/raw/mtk_nand.c                    | 25 ++++++++++++++++------
> >  2 files changed, 24 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/mtk-nand.txt b/Documentation/devicetree/bindings/mtd/mtk-nand.txt
> > index ef786568..a8e4136 100644
> > --- a/Documentation/devicetree/bindings/mtd/mtk-nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/mtk-nand.txt
> > @@ -47,6 +47,12 @@ Children nodes properties:
> >  - reg:			Chip Select Signal, default 0.
> >  			Set as reg = <0>, <1> when need 2 CS.
> >  Optional:
> > +- mtk,fdm-ecc-size:	Integer representing ECC protected FDM bytes.
> > +			Should be in the range [1,8], if not present 1.
> > +			On some MTK NAND chips, BootROM may access more than
> > +			one byte ECC protected FDM data. Different MTK chips
> > +			with the same NAND controller IP will work well with
> > +			this properity setting.
> 
> Is this something that changes on a per-SoC basis, or can a specific
> SoC have a different behavior depending on the version of the BootROM
> it embeds (that would be quite tricky to deal with since that would
> mean having different dts if you start using newer revisions of the same
> SoC).
> 
> If it's on a per-SoC basis, I'd recommend defining new compatibles
> instead of adding this property.
> 
Thanks for your advice. I will change to add new compatibles for this
setting next patch.

Thanks,
Xiaolei
> 

  reply	other threads:[~2018-04-12  5:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-11  3:41 [PATCH 0/8] Improve MTK NAND driver and ->calc_ecc_bytes() hook Xiaolei Li
2018-04-11  3:41 ` [PATCH 1/8] dt-bindings: mtd: mtk-nand: Update properties description Xiaolei Li
2018-04-11  3:41 ` [PATCH 2/8] MAINTAINERS: Add entry for Mediatek NAND controller driver Xiaolei Li
2018-04-11  3:41 ` [PATCH 3/8] mtd: rawnand: mtk: Add DT property mtk,fdm-ecc-size Xiaolei Li
2018-04-11 19:13   ` Boris Brezillon
2018-04-12  5:36     ` xiaolei li [this message]
2018-04-11  3:41 ` [PATCH 4/8] mtd: rawnand: mtk: Remove max_sector_size from struct mtk_nfc_caps Xiaolei Li
2018-04-11  3:41 ` [PATCH 5/8] mtd: rawnand: Modify ->calc_ecc_bytes() hook in nand_ecc_caps Xiaolei Li
2018-04-11 18:57   ` Boris Brezillon
2018-04-12  5:44     ` xiaolei li
2018-04-11  3:41 ` [PATCH 6/8] mtd: rawnand: mtk: Introduce mtk_ecc_calc_parity_bytes() function Xiaolei Li
2018-04-11  3:41 ` [PATCH 7/8] mtd: rawnand: mtk: Introduce mtk_ecc_get_strength_num(), mtk_ecc_get_strength() Xiaolei Li
2018-04-11  3:41 ` [PATCH 8/8] mtd: rawnand: mtk: Use generic helpers to calculate ecc size and strength Xiaolei Li
2018-04-11 19:05   ` Boris Brezillon
2018-04-12  5:43     ` xiaolei li

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=1523511412.14673.21.camel@mhfsdcap03 \
    --to=xiaolei.li@mediatek.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=srv_heupstream@mediatek.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