linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Mack <zonque@gmail.com>
To: Peter Korsgaard <jacmet@sunsite.dk>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	jon-hunter@ti.com, avinashphilip@ti.com, x0148406@ti.com,
	tony@atomide.com, paul@pwsan.com, nsekhar@ti.com"Philip,
	Avinash" <avinashphilip@ti.com>
Subject: Re: [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Date: Fri, 23 Nov 2012 11:36:31 +0100	[thread overview]
Message-ID: <50AF51AF.4050003@gmail.com> (raw)
In-Reply-To: <87zk2djox6.fsf@dell.be.48ers.dk>

Hi Peter,

On 19.11.2012 21:52, Peter Korsgaard wrote:
>>>>>> "D" == Daniel Mack <zonque@gmail.com> writes:
> 
> Hi,
> 
>  D> This patch adds basic DT bindings for OMAP GPMC.
>  D> The actual peripherals are instanciated from child nodes within the GPMC
> 
> s/instanciated/instantiated/

Thanks, fixed.

> 
>  D> node, and the only type of device that is currently supported is NAND.
> 
>  D> Code was added to parse the generic GPMC timing parameters and some
>  D> documentation with examples on how to use them.
> 
>  D> Successfully tested on an AM33xx board.
> 
>  D> Signed-off-by: Daniel Mack <zonque@gmail.com>
>  D> ---
>  D>  .../devicetree/bindings/mtd/gpmc-nand.txt          |  84 ++++++++++
>  D>  arch/arm/mach-omap2/gpmc.c                         | 170 +++++++++++++++++++++
>  D>  2 files changed, 254 insertions(+)
>  D>  create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> 
>  D> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>  D> new file mode 100644
>  D> index 0000000..20aa5b9
>  D> --- /dev/null
>  D> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>  D> @@ -0,0 +1,84 @@
>  D> +Device tree bindings for GPMC connected NANDs
>  D> +
>  D> +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
>  D> +the GPMC controller with a name of "nand".
>  D> +
>  D> +All timing relevant properties as well as generic gpmc child properties are
>  D> +explained in a separate documents - please refer to
>  D> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
> 
> Which this patch seems to be missing?

True - sorry for that. Will be back at v5.

>  D> +
>  D> +For NAND specific properties such as ECC modes or bus width, please refer to
>  D> +Documentation/devicetree/bindings/mtd/nand.txt
>  D> +
>  D> +
>  D> +Required properties:
>  D> +
>  D> + - reg:		The CS line the peripheral is connected to
>  D> +
>  D> +Optional properties:
>  D> +
>  D> + - nand-bus-width: 		Set this numeric value to 16 if the hardware
>  D> +				is wired that way. If not specified, a bus
>  D> +				width of 8 is assumed.
>  D> + - ti,nand-ecc-opt:		A string setting the ECC layout to use. One of:
>  D> +
>  D> +	Layouts for 1-bit ecc: stored at end of spare area:
>  D> +
>  D> +		"software"	Software method (default)
>  D> +		"hw"		Hardware method (let gpmc do the error detection)
> 
> Nit: why are you spelling out 'software' when everything else is shortened?

Right. Fixed.

> 
>  D> +
>  D> +	Layouts for 1-bit ecc: stored at beginning of spare area as romcode:
>  D> +
>  D> +		"hw-romcode"	gpmc method & romcode layout
>  D> +		"bch4"		4-bit BCH ecc code
>  D> +		"bch8"		8-bit BCH ecc code
>  D> +
> 
> These are not 1-bit - Well, romcode might be depending on SoC. Looking at
> omap2.c it seems to be an alias for hw, so that isn't really helpful on
> E.G. am33xx where you should select bch8 to have something compatible
> with the romcode.

Not sure whether I follow you here. drivers/mtd/nand/omap2.c handles
cases for pdata->ecc_opt == OMAP_ECC_BCH8_CODE_HW, so the DT bindings
need to offer a way to set it.

Or are you purely referring to the comments only?

>  D> + - ti,nand-ecc-use-elm:		Property without value to specify that the
>  D> +				hardware error correction mode should be used.
> 
> It's called the error location module. Like you pointed out yourself,
> this property isn't really nice. I haven't looked at the elm bindings in
> detail, but couldn't the nand driver automatically use the elm if the
> device tree provides a node for it? Perhaps the elm should be a subnode
> of the nand one?

That is to be discussed for the elm driver then. I'm not sure though
whether the elm should always be used when its DT node is present.

For now, I would leave it the way it is and have an optional
"ti,nand-ecc-use-elm". I just added some more lines of documenation to
describe the fact that the elm driver is needed in order to make it work.



Daniel


  reply	other threads:[~2012-11-23 10:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19 15:29 [PATCH v4 0/3] OMAP GPMC DT bindings Daniel Mack
2012-11-19 15:29 ` [PATCH v4 1/3] mtd: omap-nand: pass device_node in platform data Daniel Mack
2012-11-19 15:29 ` [PATCH v4 2/3] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs Daniel Mack
2012-11-19 15:29 ` [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND Daniel Mack
2012-11-19 20:52   ` Peter Korsgaard
2012-11-23 10:36     ` Daniel Mack [this message]
2012-11-23 10:47       ` Peter Korsgaard
2012-11-23 10:55         ` Daniel Mack
2012-11-23 11:06           ` Peter Korsgaard
2012-11-20 11:26   ` Philip, Avinash
2012-11-19 16:48 ` [PATCH v4 0/3] OMAP GPMC DT bindings Jon Hunter

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=50AF51AF.4050003@gmail.com \
    --to=zonque@gmail.com \
    --cc=avinashphilip@ti.com \
    --cc=jacmet@sunsite.dk \
    --cc=jon-hunter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=paul@pwsan.com \
    --cc=tony@atomide.com \
    --cc=x0148406@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).