[PATCH v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: zonque@gmail.com (Daniel Mack)
Date: 2012-12-12 09:13:42
Also in:
linux-devicetree, linux-omap
On 06.12.2012 17:19, Jon Hunter wrote:
On 12/05/2012 05:24 PM, Grant Likely wrote:quoted
On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter [off-list ref] wrote:quoted
Hi Grant, On 12/05/2012 04:22 PM, Grant Likely wrote:quoted
On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack [off-list ref] wrote:quoted
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 | 77 ++++++++++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 +++++++++ arch/arm/mach-omap2/gpmc.c | 171 ++++++++++++++++++++- 3 files changed, 323 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txtdiff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt new file mode 100644 index 0000000..7d2a645 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt@@ -0,0 +1,77 @@ +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"Please, be specific. Use something like "ti,am3340-gpmc" or "ti,omap3430-gpmc". The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine.We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have "ti,omap2-gpmc" implying all omap2+ based devices or should we have a compatible string for each device supported?Are they each register-level compatible with one another?They are not 100% register compatible. There are a couple fields in the binding that are only applicable to OMAP3+ devices.quoted
The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = "ti,am3358-gpmc", "ti,omap2420-gpmc"; Essentially, what this means is that "ti,omap2420-gpmc" is the generic value instead of "omap2-gpmc". The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device.Ok, gotcha! I will do a register comparison and may be recommend to Daniel which compatible strings we will need.
Any idea yet how we want to continue on this? I'm asking because I'm leaving for a longer trip by the end of this week, and so anything I haven't finished until then will have to be postponed until February or be taken over by someone else :) Thanks, Daniel