From: Heiko Schocher <hs@denx.de>
To: Scott Wood <scottwood@freescale.com>
Cc: davinci-linux-open-source@linux.davincidsp.com,
devicetree-discuss@lists.ozlabs.org, Sekhar Nori <nsekhar@ti.com>,
linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
Date: Fri, 27 Jan 2012 07:40:00 +0100 [thread overview]
Message-ID: <4F2246C0.6020905@denx.de> (raw)
In-Reply-To: <4F21B8AC.40002@freescale.com>
Hello Scott,
Scott Wood wrote:
> On 01/25/2012 01:09 AM, Heiko Schocher wrote:
>> Scott Wood wrote:
>> I found the following used options:
>>
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
>>
>> bbt_options:
>> NAND_BBT_USE_FLASH
>>
>> ecc_bits:
>> 1
>> 4
>>
>> options:
>> NAND_BUSWIDTH_16
>>
>>>>> Do all of these properties really belong here? I can see providing some
>>>> I think so, because this values come from existing platform code
>>>> (grep for struct davinci_nand_pdata)
>>> The standards are a bit stricter for the device tree, since it's a more
>>> stable interface across components -- at least that's how we've used it
>>> on a lot of powerpc targets. I'm not sure if that's the intent here,
>>> but I have seen U-Boot patches for ARM hardware using them as well.
>> Ok, so, should I introduce instead properties for the above
>> needed parameters?
>
> Yes.
Ok, I change this.
>> (As this are not davinci specific parameters, are there somewhere such definitions for them?)
>
> It's controller-specific which options are changeable, and whether
> there's a better source of information. Most controllers don't seem to
> need this. I'd keep the definitions davinci specific for now. If
> there's enough of a common need, a common definition could be considered.
Ok, a proposal for the properties names and values:
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
"ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome"
>> bbt_options:
>> NAND_BBT_USE_FLASH
"ti,davinci-nand-bbt-options" = "use_flash"
>> ecc_bits:
>> 1
>> 4
"ti,davinci-nand-ecc-bits" = "1" or "4"
>> options:
>> NAND_BUSWIDTH_16
"ti,davinci-nand-options" = "buswidth-16"
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
WARNING: multiple messages have this Message-ID (diff)
From: hs@denx.de (Heiko Schocher)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
Date: Fri, 27 Jan 2012 07:40:00 +0100 [thread overview]
Message-ID: <4F2246C0.6020905@denx.de> (raw)
In-Reply-To: <4F21B8AC.40002@freescale.com>
Hello Scott,
Scott Wood wrote:
> On 01/25/2012 01:09 AM, Heiko Schocher wrote:
>> Scott Wood wrote:
>> I found the following used options:
>>
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
>>
>> bbt_options:
>> NAND_BBT_USE_FLASH
>>
>> ecc_bits:
>> 1
>> 4
>>
>> options:
>> NAND_BUSWIDTH_16
>>
>>>>> Do all of these properties really belong here? I can see providing some
>>>> I think so, because this values come from existing platform code
>>>> (grep for struct davinci_nand_pdata)
>>> The standards are a bit stricter for the device tree, since it's a more
>>> stable interface across components -- at least that's how we've used it
>>> on a lot of powerpc targets. I'm not sure if that's the intent here,
>>> but I have seen U-Boot patches for ARM hardware using them as well.
>> Ok, so, should I introduce instead properties for the above
>> needed parameters?
>
> Yes.
Ok, I change this.
>> (As this are not davinci specific parameters, are there somewhere such definitions for them?)
>
> It's controller-specific which options are changeable, and whether
> there's a better source of information. Most controllers don't seem to
> need this. I'd keep the definitions davinci specific for now. If
> there's enough of a common need, a common definition could be considered.
Ok, a proposal for the properties names and values:
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
"ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome"
>> bbt_options:
>> NAND_BBT_USE_FLASH
"ti,davinci-nand-bbt-options" = "use_flash"
>> ecc_bits:
>> 1
>> 4
"ti,davinci-nand-ecc-bits" = "1" or "4"
>> options:
>> NAND_BUSWIDTH_16
"ti,davinci-nand-options" = "buswidth-16"
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org,
Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
Date: Fri, 27 Jan 2012 07:40:00 +0100 [thread overview]
Message-ID: <4F2246C0.6020905@denx.de> (raw)
In-Reply-To: <4F21B8AC.40002-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Hello Scott,
Scott Wood wrote:
> On 01/25/2012 01:09 AM, Heiko Schocher wrote:
>> Scott Wood wrote:
>> I found the following used options:
>>
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
>>
>> bbt_options:
>> NAND_BBT_USE_FLASH
>>
>> ecc_bits:
>> 1
>> 4
>>
>> options:
>> NAND_BUSWIDTH_16
>>
>>>>> Do all of these properties really belong here? I can see providing some
>>>> I think so, because this values come from existing platform code
>>>> (grep for struct davinci_nand_pdata)
>>> The standards are a bit stricter for the device tree, since it's a more
>>> stable interface across components -- at least that's how we've used it
>>> on a lot of powerpc targets. I'm not sure if that's the intent here,
>>> but I have seen U-Boot patches for ARM hardware using them as well.
>> Ok, so, should I introduce instead properties for the above
>> needed parameters?
>
> Yes.
Ok, I change this.
>> (As this are not davinci specific parameters, are there somewhere such definitions for them?)
>
> It's controller-specific which options are changeable, and whether
> there's a better source of information. Most controllers don't seem to
> need this. I'd keep the definitions davinci specific for now. If
> there's enough of a common need, a common definition could be considered.
Ok, a proposal for the properties names and values:
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
"ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome"
>> bbt_options:
>> NAND_BBT_USE_FLASH
"ti,davinci-nand-bbt-options" = "use_flash"
>> ecc_bits:
>> 1
>> 4
"ti,davinci-nand-ecc-bits" = "1" or "4"
>> options:
>> NAND_BUSWIDTH_16
"ti,davinci-nand-options" = "buswidth-16"
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2012-01-27 6:40 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-02-02 4:54 ` Grant Likely
2012-02-02 4:54 ` Grant Likely
2012-02-06 6:36 ` Heiko Schocher
2012-02-06 6:36 ` Heiko Schocher
2012-02-14 7:15 ` Heiko Schocher
2012-02-14 7:15 ` Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 2/7 v2] ARM: davinci: configure davinci aemif chipselects through OF Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 3/7] ARM: davinci: mux: add OF support Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: " Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 19:20 ` Anatoly Sivov
2012-01-23 19:20 ` Anatoly Sivov
2012-01-24 6:14 ` Heiko Schocher
2012-01-24 6:14 ` Heiko Schocher
2012-01-30 20:22 ` Grant Likely
2012-01-30 20:22 ` Grant Likely
2012-01-31 11:27 ` Heiko Schocher
2012-01-31 11:27 ` Heiko Schocher
2012-02-02 0:19 ` Grant Likely
2012-02-02 0:19 ` Grant Likely
[not found] ` <1327308967-8092-1-git-send-email-hs-ynQEQJNshbs@public.gmane.org>
2012-01-23 8:56 ` [RFC PATCH 5/7] ARM: davinci: i2c: " Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
[not found] ` <1327308967-8092-6-git-send-email-hs-ynQEQJNshbs@public.gmane.org>
2012-01-23 20:35 ` Sylwester Nawrocki
2012-01-23 20:35 ` Sylwester Nawrocki
[not found] ` <4F1DC480.4010603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-01-24 7:18 ` Heiko Schocher
2012-01-24 7:18 ` Heiko Schocher
[not found] ` <4F1E5B44.4090200-ynQEQJNshbs@public.gmane.org>
2012-01-24 9:51 ` Sylwester Nawrocki
2012-01-24 9:51 ` Sylwester Nawrocki
[not found] ` <4F1E7F36.50505-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-01-30 20:13 ` Grant Likely
2012-01-30 20:13 ` Grant Likely
[not found] ` <20120130201307.GV28397-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2012-01-31 7:31 ` Heiko Schocher
2012-01-31 7:31 ` Heiko Schocher
2012-02-05 20:44 ` Sylwester Nawrocki
2012-02-05 20:44 ` Sylwester Nawrocki
2012-01-30 20:04 ` Grant Likely
2012-01-30 20:04 ` Grant Likely
[not found] ` <20120130200436.GU28397-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2012-01-31 7:14 ` Heiko Schocher
2012-01-31 7:14 ` Heiko Schocher
2012-02-13 23:37 ` Ben Dooks
2012-02-13 23:37 ` Ben Dooks
[not found] ` <20120213233726.GK2999-RazCHl0VsYgkUSuvROHNpA@public.gmane.org>
2012-02-14 7:16 ` Heiko Schocher
2012-02-14 7:16 ` Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
[not found] ` <1327308967-8092-8-git-send-email-hs-ynQEQJNshbs@public.gmane.org>
2012-01-30 20:32 ` Grant Likely
2012-01-30 20:32 ` Grant Likely
2012-01-30 20:32 ` Grant Likely
[not found] ` <20120130203252.GX28397-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2012-01-31 13:04 ` Heiko Schocher
2012-01-31 13:04 ` Heiko Schocher
2012-01-31 13:04 ` Heiko Schocher
[not found] ` <4F27E6E0.1050608-ynQEQJNshbs@public.gmane.org>
2012-02-01 10:20 ` Sergei Shtylyov
2012-02-01 10:20 ` Sergei Shtylyov
2012-02-01 10:20 ` Sergei Shtylyov
[not found] ` <4F2911DD.6010405-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
2012-02-02 0:17 ` Grant Likely
2012-02-02 0:17 ` Grant Likely
2012-02-02 0:17 ` Grant Likely
2012-01-23 8:56 ` [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` Heiko Schocher
2012-01-23 23:59 ` Scott Wood
2012-01-23 23:59 ` Scott Wood
2012-01-23 23:59 ` Scott Wood
2012-01-24 7:23 ` Heiko Schocher
2012-01-24 7:23 ` Heiko Schocher
2012-01-24 7:23 ` Heiko Schocher
2012-01-24 19:45 ` Scott Wood
2012-01-24 19:45 ` Scott Wood
2012-01-24 19:45 ` Scott Wood
2012-01-25 7:09 ` Heiko Schocher
2012-01-25 7:09 ` Heiko Schocher
2012-01-25 7:09 ` Heiko Schocher
2012-01-26 20:33 ` Scott Wood
2012-01-26 20:33 ` Scott Wood
2012-01-26 20:33 ` Scott Wood
2012-01-27 6:40 ` Heiko Schocher [this message]
2012-01-27 6:40 ` Heiko Schocher
2012-01-27 6:40 ` Heiko Schocher
2012-01-27 17:02 ` Scott Wood
2012-01-27 17:02 ` Scott Wood
2012-01-27 17:02 ` Scott Wood
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=4F2246C0.6020905@denx.de \
--to=hs@denx.de \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nsekhar@ti.com \
--cc=scottwood@freescale.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.