[PATCH v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

[Daniel Mack]

Hi Jon,

On 06.12.2012 17:19, Jon Hunter wrote:
> 
> On 12/05/2012 05:24 PM, Grant Likely wrote:
>> On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter <jon-hunter at ti.com> wrote:
>>> Hi Grant,
>>>
>>> On 12/05/2012 04:22 PM, Grant Likely wrote:
>>>> On Wed,  5 Dec 2012 20:09:31 +0100, Daniel Mack <zonque at gmail.com> 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 at 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.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..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.
> 
>> 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.

Ok, thanks a lot!

However, I don't know whether we should treat different models
differently in the code yet, distiguished by their 'compatible' string.

We should register the driver correctly so we can use the power of that
feature once we get rid of the runtime-hacks (cpu_is_xxx() macros), but
I think until we're there, we can well live with multiple
compatible-entries that all map to the same driver, right?

OTOH, we could also think about tieing num-waitpins and num-cs to a
specific 'compatible' entry (by passing a struct along in .data members
of of_device_id), but I'm not sure whether that's really better here.


Daniel