From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: dwmw2@infradead.org, computersforpeace@gmail.com,
matthias.bgg@gmail.com, robh@kernel.org,
linux-mtd@lists.infradead.org, xiaolei.li@mediatek.com,
daniel.thompson@linaro.org, erin.lo@mediatek.com,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v3 1/2] mtd: mediatek: device tree docs for MTK Smart Device Gen1 NAND
Date: Mon, 11 Apr 2016 21:17:37 -0400 [thread overview]
Message-ID: <570C4CB1.3080004@linaro.org> (raw)
In-Reply-To: <20160412011500.24b29157@bbrezillon>
On 04/11/2016 07:15 PM, Boris Brezillon wrote:
> On Mon, 11 Apr 2016 12:56:11 -0400
> Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> wrote:
>
>> This patch adds documentation support for Smart Device Gen1 type of
>> NAND controllers.
>>
>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
>> ---
>> Documentation/devicetree/bindings/mtd/mtk-nand.txt | 145 +++++++++++++++++++++
>> 1 file changed, 145 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/mtk-nand.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/mtk-nand.txt b/Documentation/devicetree/bindings/mtd/mtk-nand.txt
>> new file mode 100644
>> index 0000000..ca3cc95
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/mtk-nand.txt
>> @@ -0,0 +1,145 @@
>> +MTK SoCs NAND FLASH controller (NFC) DT binding
>> +
>> +This file documents the device tree bindings for MTK SoCs NAND controllers.
>> +The functional split of the controller requires two drivers to operate:
>> +the nand controller interface driver and the ECC engine driver.
>> +
>> +The hardware description for both devices must be captured as device
>> +tree nodes.
>> +
>> +1) NFC NAND Controller Interface (NFI):
>> +=======================================
>> +
>> +The first part of NFC is NAND Controller Interface (NFI) HW.
>> +Required NFI properties:
>> +- compatible: Should be "mediatek,mtxxxx-nfc".
>> +- reg: Base physical address and size of NFI.
>> +- interrupts: Interrupts of NFI.
>> +- clocks: NFI required clocks.
>> +- clock-names: NFI clocks internal name.
>> +- status: Disabled default. Then set "okay" by platform.
>> +- ecc-engine: Required ECC Engine node.
>> +- #address-cells: NAND chip index, should be 1.
>> +- #size-cells: Should be 0.
>> +
>> +Example:
>> +
>> + nandc: nfi@1100d000 {
>> + compatible = "mediatek,mt2701-nfc";
>> + reg = <0 0x1100d000 0 0x1000>;
>> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&pericfg CLK_PERI_NFI>,
>> + <&pericfg CLK_PERI_NFI_PAD>;
>> + clock-names = "nfi_clk", "pad_clk";
>> + status = "disabled";
>> + ecc-engine = <&bch>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> +Platform related properties, should be set in {platform_name}.dts:
>> +- children nodes: NAND chips.
>> +
>> +Children nodes properties:
>> +- reg: Chip Select Signal, default 0.
>> + Set as reg = <0>, <1> when need 2 CS.
>> +- spare_per_sector: Spare size of each sector.
> Do you really need this property? It should be deduced from ECC
> strength/step-size and oobsize info (or any other NFC/ECC constraints).
>
>
I think so.
the set of valid values for SPARE_PER_SECTOR is actually defined in the product
data sheet (NFI_PAGEFMT register bits 7:4)
the 16 valid values are (in Bytes) 16, 26, 27, 28, 32, 36, 40, 44, 48, 49, 50,
51, 52,62, 63 and 64.
I suppose we could do some maths (oobsize/step size) and approximate to these
values but we thought it would be simpler just to actually code the right value
in the device tree?
next prev parent reply other threads:[~2016-04-12 1:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-11 16:56 [PATCH v3 0/2] MTK Smart Device Gen1 NAND Driver Jorge Ramirez-Ortiz
2016-04-11 16:56 ` [PATCH v3 1/2] mtd: mediatek: device tree docs for MTK Smart Device Gen1 NAND Jorge Ramirez-Ortiz
2016-04-11 23:15 ` Boris Brezillon
2016-04-12 1:17 ` Jorge Ramirez-Ortiz [this message]
2016-04-11 16:56 ` [PATCH v3 2/2] mtd: mediatek: driver " Jorge Ramirez-Ortiz
2016-04-17 22:17 ` Boris Brezillon
2016-04-19 14:26 ` Jorge Ramirez-Ortiz
2016-04-19 16:42 ` Boris Brezillon
2016-04-19 22:39 ` Jorge Ramirez-Ortiz
2016-04-18 8:01 ` Boris Brezillon
2016-04-19 20:24 ` Boris Brezillon
2016-04-19 21:16 ` Jorge Ramirez-Ortiz
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=570C4CB1.3080004@linaro.org \
--to=jorge.ramirez-ortiz@linaro.org \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=daniel.thompson@linaro.org \
--cc=dwmw2@infradead.org \
--cc=erin.lo@mediatek.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=xiaolei.li@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;
as well as URLs for NNTP newsgroup(s).