linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: zonque@gmail.com (Daniel Mack)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Date: Thu, 29 Nov 2012 21:56:18 +0100	[thread overview]
Message-ID: <50B7CBF2.3040908@gmail.com> (raw)
In-Reply-To: <50B7C57C.3070701@ti.com>

On 29.11.2012 21:28, Jon Hunter wrote:
> 
> On 11/29/2012 10:01 AM, Daniel Mack wrote:
>> This patch adds basic DT bindings for OMAP GPMC.
>>
>> The actual peripherals are instantiated from child nodes within the GPMC
>> node, and the only type of device that is currently supported is NAND.
>>
>> Code was added to parse the generic GPMC timing parameters and some
>> documentation with examples on how to use them.
>>
>> Successfully tested on an AM33xx board.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>> ---
>>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +++++++++
>>  .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
>>  arch/arm/mach-omap2/gpmc.c                         | 171 ++++++++++++++++++++-
>>  3 files changed, 322 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
>>  create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>>
>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> new file mode 100644
>> index 0000000..ba3d6a5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> @@ -0,0 +1,76 @@
>> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
>> +
>> +The actual devices are instantiated from the child nodes of a GPMC node.
>> +
>> +Required properties:
>> +
>> + - compatible:		Should be set to "ti,gpmc"
>> + - reg:			A resource specifier for the register space
>> +			(see the example below)
>> + - ti,hwmods:		Should be set to "ti,gpmc" until the DT transition is
>> +			completed.
>> + - #address-cells:	Must be set to 2 to allow memory address translation
>> + - #size-cells:		Must be set to 1 to allow CS address passing
>> + - num-cs:		The maximum number of chip-select lines that controller
>> +			can support.
>> + - num-waitpins:	The maximum number of wait pins that controller can
>> +			support.
>> + - ranges:		Must be set up to reflect the memory layout with four
>> +			integer values for each chip-select line in use:
>> +
>> +			   <cs-number> 0 <physical address of mapping> <size>
>> +
>> +			Note that this property is not currently parsed.
>> +			Calculated values derived from the contents of the
>> +			per-CS register GPMC_CONFIG7 (as set up by the
>> +			bootloader) are used. That will change in the future,
>> +			so be sure to fill the correct values here.
>> +
>> +Timing properties for child nodes. All are optional and default to 0.
>> +
>> + - gpmc,sync-clk:	Minimum clock period for synchronous mode, in picoseconds
>> +
>> + Chip-select signal timings corresponding to GPMC_CONFIG2:
>> + - gpmc,cs-on:		Assertion time
>> + - gpmc,cs-rd-off:	Read deassertion time
>> + - gpmc,cs-wr-off:	Write deassertion time
>> +
>> + ADV signal timings corresponding to GPMC_CONFIG3:
>> + - gpmc,adv-on:		Assertion time
>> + - gpmc,adv-rd-off:	Read deassertion time
>> + - gpmc,adv-wr-off:	Write deassertion time
>> +
>> + WE signals timings corresponding to GPMC_CONFIG4:
>> + - gpmc,we-on:		Assertion time
>> + - gpmc,we-off:		Deassertion time
>> +
>> + OE signals timings corresponding to GPMC_CONFIG4:
>> + - gpmc,oe-on:		Assertion time
>> + - gpmc,oe-off:		Deassertion time
>> +
>> + Access time and cycle time timings corresponding to GPMC_CONFIG5:
>> + - gpmc,page-burst-access: Multiple access word delay
>> + - gpmc,access:		Start-cycle to first data valid delay
>> + - gpmc,rd-cycle:	Total read cycle time
>> + - gpmc,wr-cycle:	Total write cycle time
>> +
>> +The following are only on OMAP3430:
>> + - gpmc,wr-access
>> + - gpmc,wr-data-mux-bus
> 
> Actually, these are applicable to AM335x as well. I believe that the
> comment should be "applicable to OMAP3+ and AM335x". The gpmc driver was
> updated to set the flags for these features based upon gpmc version ID.
> 
>> +
>> +
>> +Example for an AM33xx board:
>> +
>> +	gpmc: gpmc at 50000000 {
>> +		compatible = "ti,gpmc";
>> +		ti,hwmods = "gpmc";
>> +		reg = <0x50000000 0x2000>;
>> +		interrupts = <100>;
>> +
>> +		num-cs = <8>;
>> +		#address-cells = <2>;
>> +		#size-cells = <1>;
>> +		ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
> 
> Nit, you have num-wait pins as a required property but not shown here in
> the example.
> 
>> +
>> +		/* child nodes go here */
>> +	};
>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> new file mode 100644
>> index 0000000..58c876f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> @@ -0,0 +1,76 @@
>> +Device tree bindings for GPMC connected NANDs
>> +
>> +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
>> +the GPMC controller with a name of "nand".
>> +
>> +All timing relevant properties as well as generic gpmc child properties are
>> +explained in a separate documents - please refer to
>> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> +
>> +For NAND specific properties such as ECC modes or bus width, please refer to
>> +Documentation/devicetree/bindings/mtd/nand.txt
>> +
>> +
>> +Required properties:
>> +
>> + - reg:		The CS line the peripheral is connected to
>> +
>> +Optional properties:
>> +
>> + - nand-bus-width: 		Set this numeric value to 16 if the hardware
>> +				is wired that way. If not specified, a bus
>> +				width of 8 is assumed.
>> +
>> + - ti,nand-ecc-opt:		A string setting the ECC layout to use. One of:
>> +
>> +		"sw"		Software method (default)
>> +		"hw"		Hardware method
>> +		"hw-romcode"	gpmc hamming mode method & romcode layout
>> +		"bch4"		4-bit BCH ecc code
>> +		"bch8"		8-bit BCH ecc code
>> +
>> +For inline partiton table parsing (optional):
>> +
>> + - #address-cells: should be set to 1
>> + - #size-cells: should be set to 1
>> +
>> +Example for an AM33xx board:
>> +
>> +	gpmc: gpmc at 50000000 {
>> +		compatible = "ti,gpmc";
>> +		ti,hwmods = "gpmc";
>> +		reg = <0x50000000 0x1000000>;
> 
> Nit, good to make reg size consistent with the above example.
> 
>> +		interrupts = <100>;
>> +		num-cs = <8>;
>> +		num-waitpins = <8>;
> 
> Nit, AM335x only has 2 wait-pins. Number of wait-pins is typically less
> than number of CS pins.
> 
> Other than these minor comments, looks good to me. Thanks for updating.

Thanks for these remarks! All fixed locally. I can send out a v7 tomorrow.


Best,
Daniel

      reply	other threads:[~2012-11-29 20:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-29 16:01 [PATCH v6 0/5] OMAP GPMC DT bindings Daniel Mack
2012-11-29 16:01 ` [PATCH v6 1/5] ARM: OMAP: gpmc: don't create devices from initcall on DT Daniel Mack
2012-11-29 18:00   ` Jon Hunter
2012-11-29 16:01 ` [PATCH v6 2/5] mtd: omap-nand: pass device_node in platform data Daniel Mack
2012-11-29 16:01 ` [PATCH v6 3/5] ARM: OMAP: gpmc-nand: drop __init annotation Daniel Mack
2012-11-29 16:01 ` [PATCH v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs Daniel Mack
2012-11-29 19:59   ` Jon Hunter
2012-11-29 20:32     ` Jon Hunter
2012-11-29 20:42       ` Daniel Mack
2012-11-29 20:59         ` Jon Hunter
2012-12-05 13:04           ` Daniel Mack
2012-12-05 17:19             ` Tony Lindgren
2012-12-05 17:26               ` Daniel Mack
2012-12-05 17:41                 ` Tony Lindgren
2012-12-05 18:19                   ` Jon Hunter
2012-12-05 18:33                     ` Tony Lindgren
2012-12-05 18:40                       ` Daniel Mack
2012-12-05 19:11                         ` Jon Hunter
2012-12-05 18:43                   ` Daniel Mack
2012-11-29 16:01 ` [PATCH v6 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND Daniel Mack
2012-11-29 20:28   ` Jon Hunter
2012-11-29 20:56     ` Daniel Mack [this message]

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=50B7CBF2.3040908@gmail.com \
    --to=zonque@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).