RFC: OMAP GPMC bindings

This patch adds basic DT bindings for OMAP GPMC.

The actual peripherals are instanciated 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.

Quoted 5 lines · Daniel Mack

This patch adds basic DT bindings for OMAP GPMC.

The actual peripherals are instanciated from child nodes within the GPMC node, and the only type of device that is currently supported is NAND.

Quoted 4 lines

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.

That's great, looks good to me. Please repost at least the binding patch with devicetree-discuss and Rob Herring cc:d so hopefully we'll get an ack for the binding.

Thanks for the review. I'll wait for feedback from Afzal next week and then repost. Wanted to see first if that goes in the right direction at all before bordering the DT people with binding details :)

Quoted 3 lines · Daniel Mack

Thanks for the review. I'll wait for feedback from Afzal next week and then repost. Wanted to see first if that goes in the right direction at all before bordering the DT people with binding details :)

I was thinking of a generic approach, where there won't be any check for peripheral device type.

But going that path would delay achieving DT, may be let's proceed with your approach to start with so that we can have a minimal level of DT support for GPMC and probably we can make it generic later. While adding new properties, it would be better to keep in mind that we need not change these later once gpmc DT is made generic.

Regarding the bindings, there are some generic nand properties like ecc already available, may be that be made use here.

Also perhaps memory size (and offset if needed) to be mapped for peripherals can go with reg property of child.

Quoted 3 lines · Afzal Mohammed

Also perhaps memory size (and offset if needed) to be mapped for peripherals can go with reg property of child.

Which detail are you referring to here? The only "size" property that is effective is the one of the generic GPMC block, and there it's in the "reg"-property.

Quoted 9 lines · Daniel Mack

Quoted 3 lines · Afzal Mohammed

Also perhaps memory size (and offset if needed) to be mapped for peripherals can go with reg property of child.

Which detail are you referring to here? The only "size" property that is effective is the one of the generic GPMC block, and there it's in the "reg"-property.

I was referring to that of child, now in gpmc_nand_init(), gpmc_cs_request() is being done, later on if we want to make it generic and remove gpmc_nand_init(), additional information that would be required from DT at least is the memory size to be reserved in gpmc address space for the connected peripheral (assuming gpmc_cs_request() would be done by gpmc driver generically later)

What I had in mind was example for external bus in [1], but I had not looked deep into this aspect yet.

Quoted 10 lines · Afzal Mohammed

I was referring to that of child, now in gpmc_nand_init(), gpmc_cs_request() is being done, later on if we want to make it generic and remove gpmc_nand_init(), additional information that would be required from DT at least is the memory size to be reserved in gpmc address space for the connected peripheral (assuming gpmc_cs_request() would be done by gpmc driver generically later)

What I had in mind was example for external bus in [1], but I had not looked deep into this aspect yet.

Ok, now I see what you mean.

I would say we can use the "reg" property in child node for CS numbers purely and if we want to get rid of the memory node allocation, we should use a property in the gpmc top-node for this, something like:

	gpmc: gpmc at 50000000 {
		compatible = "ti,gpmc";
		cs-regs =<0x51000000 0x10000000 ...>;

Changing the meaning of the reg property of children from "cs number" to "memory sub-region" later is something I would like to avoid.

This patch adds basic DT bindings for OMAP GPMC.

The actual peripherals are instanciated 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 <[email protected]>

---
 Documentation/devicetree/bindings/bus/gpmc.txt     |  59 +++++++++
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  65 ++++++++++
 arch/arm/mach-omap2/gpmc.c                         | 139 +++++++++++++++++++++
 3 files changed, 263 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

Documentation/devicetree/bindings/bus/gpmc.txt new file +0 -0

new file mode 100644
index 0000000..ef1c6e1

Documentation/devicetree/bindings/bus/gpmc.txt new file +52 -0

+
+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_CS_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
+
+
+Example for an AM33xx board:
+
+	gpmc: gpmc at 50000000 {
+		compatible = "ti,gpmc";
+		ti,hwmods = "gpmc";
+		reg = <0x50000000 0x1000000>;
+		interrupt-parent = <&intc>;
+		interrupts = <100>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		/* child nodes go here */
+	};
+
+
+
+
+

Documentation/devicetree/bindings/mtd/gpmc-nand.txt new file +1 -0

new file mode 100644
index 0000000..6790fcf
@@ -0,0 +1,65 @@
+Device tree bindings for GPMC connected NANDs

Documentation/devicetree/bindings/bus/gpmc.txt line 7

Quoted 13 lines · Daniel Mack

Documentation/devicetree/bindings/bus/gpmc.txt new file +7 -0

new file mode 100644
index 0000000..ef1c6e1
@@ -0,0 +1,59 @@
+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"

Is this the only required property? I think that "reg" and "ti,hwmods" are probably also required.

Also given that we are describing the hardware, I am wondering if the number of chip-selects and wait signals should be defined here too. I recall that different devices had different number of wait pins available.

Quoted 12 lines

Documentation/devicetree/bindings/mtd/gpmc-nand.txt new file +6 -0

new file mode 100644
index 0000000..6790fcf
@@ -0,0 +1,65 @@
+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 are explained in a separate documents - please

Documentation/devicetree/bindings/mtd/gpmc-nand.txt line 11

Quoted 5 lines

Documentation/devicetree/bindings/mtd/gpmc-nand.txt new file +5 -0

+refer to Documentation/devicetree/bindings/bus/gpmc.txt
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to

Is this the only required property? I would have thought that bus-width is needed too.

In general, I am wondering if this should be broken into two patches as you are creating the binding for the gpmc and nand here.

Hi Jon,

many thanks for your time to look at this.

Quoted 17 lines · Jon Hunter

Documentation/devicetree/bindings/bus/gpmc.txt line 7

Quoted 13 lines · Daniel Mack

Documentation/devicetree/bindings/bus/gpmc.txt new file +7 -0

new file mode 100644
index 0000000..ef1c6e1
@@ -0,0 +1,59 @@
+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"

Is this the only required property? I think that "reg" and "ti,hwmods" are probably also required.

Well yes, but at least "reg" is commonly omitted as it's part of a more "generic" set of properties. But ok, I can add these.

Quoted 3 lines

Also given that we are describing the hardware, I am wondering if the number of chip-selects and wait signals should be defined here too. I recall that different devices had different number of wait pins available.

Hmm, that number is currently hard-coded in GPMC_CS_NUM. It would take some effort to make that dynamic but I agree that this would be a good thing to have. Afzal?

Hmm, that number is currently hard-coded in GPMC_CS_NUM. It would take some effort to make that dynamic but I agree that this would be a good thing to have. Afzal?

This patch adds basic DT bindings for OMAP GPMC.

The actual peripherals are instanciated 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 <[email protected]>

---
 Documentation/devicetree/bindings/bus/gpmc.txt     |  59 +++++++++
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  65 ++++++++++
 arch/arm/mach-omap2/gpmc.c                         | 139 +++++++++++++++++++++
 3 files changed, 263 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

Documentation/devicetree/bindings/bus/gpmc.txt new file +37 -0

new file mode 100644
index 0000000..ef1c6e1
@@ -0,0 +1,59 @@
+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"
+
+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_CS_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

Documentation/devicetree/bindings/bus/gpmc.txt line 47

Quoted 6 lines · Daniel Mack

Documentation/devicetree/bindings/bus/gpmc.txt new file +6 -0

+Example for an AM33xx board:
+
+	gpmc: gpmc at 50000000 {
+		compatible = "ti,gpmc";
+		ti,hwmods = "gpmc";
+		reg = <0x50000000 0x1000000>;

Nit-pick, that size is quite large for a register range. I recommend looking at the HWMOD data file (arch/arm/mach-omap2/omap_hwmod_33xx_data.c) and see how much space is allocated for the registers (see structure am33xx_gpmc_addr_space).

Hi Jon,

Quoted 14 lines · Jon Hunter

Documentation/devicetree/bindings/bus/gpmc.txt line 47

Quoted 6 lines · Daniel Mack

Documentation/devicetree/bindings/bus/gpmc.txt new file +6 -0

+Example for an AM33xx board:
+
+	gpmc: gpmc at 50000000 {
+		compatible = "ti,gpmc";
+		ti,hwmods = "gpmc";
+		reg = <0x50000000 0x1000000>;

Nit-pick, that size is quite large for a register range. I recommend looking at the HWMOD data file (arch/arm/mach-omap2/omap_hwmod_33xx_data.c) and see how much space is allocated for the registers (see structure am33xx_gpmc_addr_space).

Yeah but reserving the entire memory as per the reference manual also prvents other from poking around in the same register space. Is there a scenario in which it would of disadvantage to reserve all that memory?