From: Lee Jones <lee.jones@linaro.org>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "angus.clark@st.com" <angus.clark@st.com>,
"kernel@stlinux.com" <kernel@stlinux.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC 13/47] mtd: nand: stm_nand_bch: provide Device Tree support
Date: Fri, 9 May 2014 11:03:04 +0100 [thread overview]
Message-ID: <20140509100304.GR5767@lee--X1> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EACA3F0@DBDE04.ent.ti.com>
> >> >+ of_property_read_u32(np, "st,bch-bitflip-threshold",
> >> >+ &pdata->bch_bitflip_threshold);
> >> >+
> >> mtd->bitflip_threshold is by default set to ecc.strength (unless a driver initializes it).
> >> And then can be re-configured for each MTD partition separately
> >> /sys/class/mtd/mtdX/bitflip_threshold
> >> Refer: $kernel/Documentation/ABI/testing/sysfs-class-mtd
> >> So, I don't think this is a HW parameter, and so should not be passed from DT.
> >
> >I think the bit-flip threshold is/can be chip specific, and as we know
> >which chip we're likely to be booting on, we can specify this via the
> >hardware description. Thus, I think it's perfectly viable for an
> >option to pass through DT to exist.
> >
> I don't think that’s the correct interpretation of bitflip_threshold.
>
> (1) bitflip_threshold is dependent on ecc.strength (ECC scheme) of your driver.
> MTD layers uses bitflip_threshold to warn above layers that number of
> correctable bit-flips have reached a dangerous level beyond which driver's
> ECC scheme may not be able to correct them. So above layers should start
> taking additional corrective action like scrubbing.
> @@drivers/mtd/mtdcore.c: mtd_read()
> return ret_code >= mtd->bitflip_threshold ? -EUCLEAN : 0;
>
> (2) Also, user-space may control it based on how your device ages on field.
> A fresh silicon may not show too many bitflips. But as device ages the
> probability of simultaneous bitflips will increase. So user-space may lower
> the bitflip_threshold to avoid accumulation of bitflips in a single page.
>
> Thus, bitflip_threshold should not be passed via DT.
> It's neither a hardware parameter, nor it’s a static constant.
Ah, I see. I will fixup, thanks for the explanation.
> >> >+struct device_node *stm_of_get_partitions_node(struct device_node *np,
> >> >+ int bank_nr)
> >> >+{
> >> >+ struct device_node *banksnp, *banknp, *partsnp = NULL;
> >> >+ char name[10];
> >> >+
> >> >+ banksnp = of_parse_phandle(np, "st,nand-banks", 0);
> >> >+ if (!banksnp)
> >> >+ return NULL;
> >> >+
> >> >+ sprintf(name, "bank%d", bank_nr);
> >> >+ banknp = of_get_child_by_name(banksnp, name);
> >> >+ if (banknp)
> >> >+ return NULL;
> >> >+
> >> >+ partsnp = of_get_child_by_name(banknp, "partitions");
> >> >+ of_node_put(banknp);
> >> >+
> >> Sorry, I'm bit confused here .. I think you don't need to find children of
> >> Your bank node. This should already taken care in default parser
> >> drivers/mtd/ofpart.c : parse_ofpart_partitions()
> >> And all you need to pass is 'of_node' of bank (device).
> >> Is my understanding correct ?
> >
> >We have 3 options here, you _can_ use parse_ofpart_partitions() if
> >your partition information conforms to its schema, but said schema
> >does not support banks and/or other information that we choose to
> >place within the bank node. The second option is to register a
> >parser. My personal view is that registering a parser is using the
> >framework for 'using the framework's' sake i.e. doesn't actually
> >achieve anything special. We've chosen the third option, which is to
> >parse and extract the information ourselves - which is actually fairly
> >trivial, and pass the required partition data in through the
> >mtd_device_parse_register() call - which is where the information
> >would be parsed in the case of the first two options.
> >
> Do you really want to have *custom* partition format ?
> If your previous code was non-DT (platform file based), then I think
> It's good point to move to unified generic partition format which others
> are following, as you make your driver DT compliant, and in mainline.
>
> I understand you primary objective would be to get ST driver work
> out of mainline asap, but if you upstream too many custom stuff you
> are only adding maintenance burden for your code. This is where
> most of my comments originate.
> However, I leave it to Brian to decide, if he is okay with these.
>
>
> with regards, pekon
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-05-09 10:10 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 8:19 [RFC 00/47] mtd: nand: Add new driver supporting ST's BCH h/w Lee Jones
2014-03-25 8:19 ` [RFC 01/47] mtd: nand: export useful functions from core driver Lee Jones
2014-03-25 12:57 ` Ezequiel Garcia
2014-03-25 14:58 ` Lee Jones
2014-03-25 8:19 ` [RFC 02/47] mtd: nand: add ONFI NAND Timing Mode Specifications Lee Jones
2014-03-25 17:01 ` Jason Gunthorpe
2014-03-25 8:19 ` [RFC 03/47] mtd: nand: add shared register defines for ST's NAND Controller drivers Lee Jones
2014-03-25 8:19 ` [RFC 04/47] mtd: nand: adding ST's BCH NAND Controller driver Lee Jones
2014-03-25 8:19 ` [RFC 05/47] mtd: nand: stm_nand_bch: IRQ support for " Lee Jones
2014-03-26 7:10 ` Gupta, Pekon
2014-03-25 8:19 ` [RFC 06/47] mtd: nand: stm_nand_bch: change between BCH and Hamming modes Lee Jones
2014-03-25 8:19 ` [RFC 07/47] mtd: nand: stm_nand_bch: initialise the BCH Controller Lee Jones
2014-03-26 10:25 ` Gupta, Pekon
2014-04-30 10:22 ` Lee Jones
2014-04-30 10:59 ` Gupta, Pekon
2014-04-30 12:29 ` Lee Jones
2014-03-25 8:19 ` [RFC 08/47] mtd: nand: stm_nand_bch: supply clock support Lee Jones
2014-03-26 7:15 ` Gupta, Pekon
2014-03-25 8:19 ` [RFC 09/47] mtd: nand: stm_nand_bch: introduce and initialise some important data structures Lee Jones
2014-03-25 8:19 ` [RFC 10/47] mtd: nand: stm_nand_bch: initialise the Hamming Controller Lee Jones
2014-03-25 8:19 ` [RFC 11/47] mtd: nand: stm_nand_bch: add Power Management Lee Jones
2014-03-25 8:19 ` [RFC 12/47] mtd: nand: stm_nand_bch: scan for NAND devices Lee Jones
2014-03-25 8:19 ` [RFC 13/47] mtd: nand: stm_nand_bch: provide Device Tree support Lee Jones
2014-03-26 9:18 ` Gupta, Pekon
2014-04-30 12:54 ` Lee Jones
2014-05-05 6:55 ` Gupta, Pekon
2014-05-09 10:03 ` Lee Jones [this message]
2014-05-09 10:32 ` Gupta, Pekon
2014-05-09 10:38 ` Lee Jones
2014-05-19 14:02 ` Lee Jones
2014-03-25 8:19 ` [RFC 14/47] mtd: nand: stm_nand_bch: configure BCH and FLEX by ONFI timing mode Lee Jones
2014-03-25 8:19 ` [RFC 15/47] mtd: nand: stm_nand_bch: add compatible page size check Lee Jones
2014-03-25 8:19 ` [RFC 16/47] mtd: nand: stm_nand_bch: derive some working variables for latter use Lee Jones
2014-03-25 8:19 ` [RFC 17/47] mtd: nand: stm_nand_bch: automatically set EEC mode if requested Lee Jones
2014-03-25 8:19 ` [RFC 18/47] mtd: nand: stm_nand_bch: ensure configuration is compatible with this driver Lee Jones
2014-03-25 8:19 ` [RFC 19/47] mtd: nand: stm_nand_bch: configure BCH read/write/erase programs Lee Jones
2014-03-25 8:19 ` [RFC 20/47] mtd: nand: stm_nand_bch: initialise working buffers Lee Jones
2014-03-25 8:19 ` [RFC 21/47] mtd: nand: stm_nand_bch: provide shared BCH operations Lee Jones
2014-03-25 8:19 ` [RFC 22/47] mtd: nand: stm_nand_bch: check erased page for zeros Lee Jones
2014-03-25 8:19 ` [RFC 23/47] mtd: nand: stm_nand_bch: read and write page (BCH) Lee Jones
2014-03-26 10:17 ` Gupta, Pekon
2014-04-30 11:19 ` Lee Jones
2014-03-25 8:19 ` [RFC 24/47] mtd: nand: stm_nand_bch: find IBBT signature Lee Jones
2014-03-25 8:19 ` [RFC 25/47] mtd: nand: stm_nand_bch: bad block marking helpers Lee Jones
2014-03-25 8:19 ` [RFC 26/47] mtd: nand: stm_nand_bch: populate IBBT BCH Header Lee Jones
2014-03-25 8:19 ` [RFC 27/47] mtd: nand: stm_nand_bch: write IBBT to Flash Lee Jones
2014-03-25 8:19 ` [RFC 28/47] mtd: nand: stm_nand_bch: update flash-resident BBT(s) Lee Jones
2014-03-25 8:19 ` [RFC 29/47] mtd: nand: stm_nand_bch: add Hamming-FLEX operations Lee Jones
2014-03-25 8:19 ` [RFC 30/47] mtd: nand: stm_nand_bch: read and write raw (FLEX) Lee Jones
2014-03-25 8:19 ` [RFC 31/47] mtd: nand: stm_nand_bch: scan block for BBM(s) according to specified BBT options Lee Jones
2014-03-25 8:19 ` [RFC 32/47] mtd: nand: stm_nand_bch: scan for BBMs and build memory-resident BBT Lee Jones
2014-03-25 8:19 ` [RFC 33/47] mtd: nand: stm_nand_bch: search for and load flash-resident BBT Lee Jones
2014-03-25 8:19 ` [RFC 34/47] mtd: nand: stm_nand_bch: " Lee Jones
2014-03-25 8:19 ` [RFC 35/47] mtd: nand: stm_nand_bch: dump bad blocks Lee Jones
2014-03-25 12:53 ` Ezequiel Garcia
2014-03-25 8:19 ` [RFC 36/47] mtd: nand: stm_nand_bch: parse partitions and register an MTD device Lee Jones
2014-03-25 8:19 ` [RFC 37/47] mtd: nand: stm_nand_bch: fetch the bit-flips threshold Lee Jones
2014-03-25 8:19 ` [RFC 38/47] mtd: nand: stm_nand_bch: check WP (FLEX) Lee Jones
2014-03-25 8:19 ` [RFC 39/47] mtd: nand: stm_nand_bch: read and write ops (FLEX) Lee Jones
2014-03-25 8:19 ` [RFC 40/47] mtd: nand: stm_nand_bch: MTD erase (BCH) Lee Jones
2014-03-25 8:19 ` [RFC 41/47] mtd: nand: stm_nand_bch: MTD mark and check for bad blocks (BCH) Lee Jones
2014-03-25 8:19 ` [RFC 42/47] mtd: nand: stm_nand_bch: add read and write OOB (BCH) Lee Jones
2014-03-25 8:20 ` [RFC 43/47] mtd: nand: stm_nand_bch: read and write functions (BCH) Lee Jones
2014-03-26 10:31 ` Gupta, Pekon
2014-04-30 9:19 ` Lee Jones
2014-03-25 8:20 ` [RFC 44/47] mtd: nand: stm_nand_bch: MTD read and write (BCH) Lee Jones
2014-03-25 8:20 ` [RFC 45/47] mtd: nand: stm_nand_bch: read and write buffers (FLEX) Lee Jones
2014-03-25 8:20 ` [RFC 46/47] mtd: nand: mtd_nand_bch: add remaining FLEX functions Lee Jones
2014-03-25 8:20 ` [RFC 47/47] mtd: nand: stm_nand_bch: catch unsupported calls Lee Jones
2014-03-25 12:50 ` [RFC 00/47] mtd: nand: Add new driver supporting ST's BCH h/w Ezequiel Garcia
2014-03-25 13:11 ` Lee Jones
2014-03-25 22:00 ` Ezequiel Garcia
2014-03-26 7:28 ` Brian Norris
2014-03-27 10:28 ` Lee Jones
2014-04-01 11:29 ` Lee Jones
2014-04-10 20:00 ` Brian Norris
2014-04-30 9:57 ` Lee Jones
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=20140509100304.GR5767@lee--X1 \
--to=lee.jones@linaro.org \
--cc=angus.clark@st.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=kernel@stlinux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.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;
as well as URLs for NNTP newsgroup(s).