linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: scottwood@freescale.com (Scott Wood)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT
Date: Wed, 28 Sep 2011 13:23:14 -0500	[thread overview]
Message-ID: <4E836612.2010709@freescale.com> (raw)
In-Reply-To: <4E82D7B3.6080909@ti.com>

On 09/28/2011 03:15 AM, Cousson, Benoit wrote:
> On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
>> On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
>>> +Required properties:
>>> +- compatible:
>>> +  - "ti,omap2-gpio" for OMAP2 and OMAP3 controllers
>>
>> Would it be more readable to have
>> "ti,omap2-gpio" for OMAP2 controllers and
>> "ti,omap3-gpio" for OMAP3 controllers?

Or have OMAP3 say this if it's fully backwards compatible:

	compatible = "ti,omap3-gpio", "ti,omap2-gpio";

>>> +  - "ti,omap4-gpio" for OMAP4 controller
>>> +- #gpio-cells : Should be two.
>>> +  - first cell is the pin number
>>> +  - second cell is used to specify optional parameters (unused)
>>> +- gpio-controller : Marks the device node as a GPIO controller.
>>> +
>>> +OMAP specific properties:
>>> +- ti,hwmods: Name of the hwmod associated to the GPIO
>>> +- id: 32 bits to identify the id (1 based index)

What does "the id" mean, in relation to the actual hardware?

Some existing bindings have such a thing (often called "cell-index"),
but it should be well-defined what it refers to.  Often aliases would be
a better approach, if it just refers to what the manual calls the device.

>>> +- bank-width: number of pin supported by the controller (16 or 32)
>>> +- debounce: set if the controller support the debouce funtionnality
>>> +- bank-count: number of controller support by the SoC. This is a
>>> temporary
>>> +  hack until the bank_count is removed from the driver.
>>
>> Is there a general rule to be followed as to when to use
>> "ti,<prop-name>" and when to use just"<prop-name>".
>> Since all these are OMAP specific properties, shouldn't all
>> of them be "ti,<prop-name>"?
> 
> To be honest, I was wondering as well about this rule.
> I think that a property that is not purely OMAP specific and that
> represents some standard HW information does not have to be prefixed by
> "ti,XXX".
> So hwmods must be "ti,hwmods", but bank-witdh and bank-count seems to me
> quite generic.

It's about where the property is documented.  Suppose you use an
un-prefixed bank-width but define it in the TI-specific binding to mean
width in bits.  Later, someone wants something similar for another
driver, doesn't look at the TI binding, but says, "This is generic, I'll
define something in the main gpio binding," but defines it as width in
bytes (ignore the (de)merits of defining it that way in this case).  If
you had a namespace prefix, it would be clear which binding a node is
referring to.

As for bank-count, the description "this is a temporary hack until the
bank_count is removed from the driver" suggests it shouldn't be there at
all, much less be part of the generic binding.

-Scott

  reply	other threads:[~2011-09-28 18:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-26 16:50 [PATCH 00/13] OMAP3+: Add DT support for early devices and i2c / twl6030 Benoit Cousson
2011-09-26 16:50 ` [PATCH 01/13] hwspinlock: OMAP4: Add spinlock support in DT Benoit Cousson
2011-10-10 12:49   ` Ohad Ben-Cohen
2011-09-26 16:50 ` [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT Benoit Cousson
2011-09-27  5:40   ` Rajendra Nayak
2011-09-28  8:15     ` Cousson, Benoit
2011-09-28 18:23       ` Scott Wood [this message]
2011-09-28 20:57         ` Cousson, Benoit
2011-09-28 21:32           ` Scott Wood
2011-09-28  8:20     ` Cousson, Benoit
2011-09-30 11:53     ` Cousson, Benoit
2011-09-26 16:50 ` [PATCH 03/13] arm/dts: OMAP4: Add gpio nodes Benoit Cousson
2011-09-26 16:50 ` [PATCH 04/13] irq: Add stub for none DT build in irqdomain.h Benoit Cousson
2011-09-26 16:50 ` [PATCH 05/13] i2c: OMAP: Add DT support for i2c controller Benoit Cousson
2011-09-26 16:50 ` [PATCH 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030 Benoit Cousson
2011-09-27  5:42   ` Rajendra Nayak
2011-09-28  8:52     ` Cousson, Benoit
2011-09-26 16:50 ` [PATCH 07/13] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030 Benoit Cousson
2011-09-26 16:50 ` [PATCH 08/13] arm/dts: OMAP4: Add i2c controller nodes Benoit Cousson
2011-09-27  5:42   ` Rajendra Nayak
2011-09-26 16:50 ` [PATCH 09/13] arm/dts: OMAP3: " Benoit Cousson
2011-09-26 16:50 ` [PATCH 10/13] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM Benoit Cousson
2011-09-26 16:50 ` [PATCH 11/13] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices Benoit Cousson
2011-09-26 16:50 ` [PATCH 12/13] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM Benoit Cousson
2011-09-29 17:25   ` Grant Likely
2011-09-26 16:50 ` [PATCH 13/13] OMAP2+: board-generic: Remove i2c static init Benoit Cousson

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=4E836612.2010709@freescale.com \
    --to=scottwood@freescale.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).