public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	linux-pwm@vger.kernel.org, Rob Herring <rob.herring@calxeda.com>,
	linux-omap@vger.kernel.org, Philip Avinash <avinashphilip@ti.com>,
	Grant Likely <grant.likely@linaro.org>,
	Boris BREZILLON <linux-arm@overkiz.com>,
	Steffen Trumtrar <s.trumtrar@pengutronix.de>,
	devicetree-discuss@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Date: Mon, 15 Jul 2013 21:39:31 -0600	[thread overview]
Message-ID: <51E4C073.4020407@wwwdotorg.org> (raw)
In-Reply-To: <2883016.87pKJk9n0R@avalon>

On 07/15/2013 07:10 PM, Laurent Pinchart wrote:
> On Friday 12 July 2013 08:42:41 Stephen Warren wrote:
...
>> I think the values for any common system-wide flags should be defined
>> once in some system-wide place, and the values for any HW-specific
>> values should be defined only in the documentation for that specific HW.
>> You could try and avoid conflicts by either:
>>
>> a) Allocating system-wide flags from bit 0 up, and HW-specific flags
>> from bit 31 down.
>>
>> or:
>>
>> b) Using 1 cell for standard flags, and a separate cell for any
>> HW-specific flags. Drivers can quite easily adapt to adding extra cells
>> to #pwm-cells, thus making adding a HW-specific cell later
>> backwards-compatible.
> 
> I wasn't referring to HW-specific flags, but rather to system-wide flags that 
> might not be supported by all drivers. If we later add new system-wide flags I 
> think the individual DT bindings should explicitly document which flags they 
> support.

Shouldn't all system-wide flags be supported by all HW, perhaps being
implemented by the core subsystem rather than individual drivers to
ensure that? Consider the case of the GPIO active-low flag which is
actually implemented in SW, hence can work with any GPIO controller.

Perhaps that's not possible in all cases, in which case, yes, it does
make sense to define which of the common flags a particular HW module
supports.

But then there's a problem where people assume that the common flags are
always available, and somewhere they aren't... Care is needed in the
choice of which common flags to define and/or how they're used.

  reply	other threads:[~2013-07-16  3:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-11 14:37 [PATCH 0/2] Add PWM polarity flag macros for DT Laurent Pinchart
2013-07-11 14:37 ` [PATCH 1/2] ARM i.MX53: mba53: Fix PWM backlight DT node Laurent Pinchart
2013-07-12  7:55   ` Shawn Guo
2013-07-11 14:37 ` [PATCH 2/2] pwm: Add PWM polarity flag macros for DT Laurent Pinchart
2013-07-11 15:36   ` Thierry Reding
2013-07-11 17:50     ` Stephen Warren
2013-07-11 19:32       ` Thierry Reding
2013-07-11 20:06         ` Stephen Warren
2013-07-12 11:01           ` Laurent Pinchart
2013-07-12 14:42             ` Stephen Warren
2013-07-16  1:10               ` Laurent Pinchart
2013-07-16  3:39                 ` Stephen Warren [this message]
2013-07-17 11:00                   ` Laurent Pinchart
2013-07-17 17:11                     ` Stephen Warren
2013-07-17 18:20                       ` Thierry Reding
2013-07-12 10:50     ` Laurent Pinchart
2013-07-11 17:40   ` Stephen Warren
2013-07-12 10:41     ` Laurent Pinchart
2013-07-12 14:40       ` Stephen Warren
2013-07-12 17:24         ` Thierry Reding
2013-07-12 17:40           ` Stephen Warren
2013-07-16  1:16             ` Laurent Pinchart

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=51E4C073.4020407@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=avinashphilip@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@linaro.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm@overkiz.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    --cc=s.trumtrar@pengutronix.de \
    --cc=thierry.reding@gmail.com \
    /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