linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Rob Herring <robh@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kernel@stlinux.com,
	maxime.coquelin@st.com, patrice.chotard@st.com,
	linux-pwm@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes
Date: Fri, 10 Jun 2016 15:06:35 +0100	[thread overview]
Message-ID: <20160610140635.GC1537@dell> (raw)
In-Reply-To: <20160610131855.GG27142@ulmo.ba.sec>

On Fri, 10 Jun 2016, Thierry Reding wrote:

> On Thu, Jun 09, 2016 at 12:41:07PM +0100, Lee Jones wrote:
> > On Wed, 08 Jun 2016, Rob Herring wrote:
> > 
> > > On Wed, Jun 08, 2016 at 10:21:35AM +0100, Lee Jones wrote:
> > > > We're renaming the 'st,pwm-num-chan' binding to 'st,pwm-num-devs' to
> > > > be more inline with the naming conventions of the subsystem.  Where
> > > > we used to treat each line as a channel, the PWM convention is to
> > > > describe them as devices.
> > > 
> > > That's all linux implementation details and you are breaking 
> > > compatibility.
> > 
> > Normally I'd agree with you, but I happen to know that a) this IP is
> > currently unused and b) up until this point (and probably beyond), ST
> > always ship the DTB with the kernel, so there will be no breakage.
> 
> Heh... I've long given up on trying to make that argument go anywhere.
> The general rule is that once we support a binding in a kernel release
> we have to support it indefinitely. If you really want to go ahead with
> this change (I don't think you should), you'd at least have to document
> both properties and support st,pwm-num-chan in the driver for backwards
> compatibility.

I understand what the *general* rule is, but we have to remember why
this rule was put into place and apply some common sense.  In some
Enterprise user-cases where DTBs are written into ROM or where they
are difficult /impossible to update, I can completely understand the
requirement to support previous incarnations.  However in this, the
real world, DTBs are shipped with their corresponding kernels.  We
would lack a great deal of functionality if they weren't.  It is
therefor, foolhardy and inappropriate to stick to this rule just
'cos.

> > > > The second documentation adaption entails adding support for PWM
> > > > capture devices.  A new clock is required as well as an IRQ line.
> > > > We're also adding a new property similar to the one described
> > > > above, but for capture channels.  Typically, there will be less
> > > > capture channels than PWM-out, since all channels have the latter
> > > > capability, but only some have capture support.
> > > 
> > > Humm, sounds like all of this should be implied from compatible strings.
> > 
> > You mean have a bunch of of_machine_is_compatibles() scattered around?
> 
> I don't understand why you need this at all. Quite frankly I don't even
> know why st,pwm-num-devs exists. I probably missed it back at the time.
> Usually, like Rob suggests, this should be inferred from the compatible
> string. One commonly used way to avoid scattering explicit checks for
> the compatible string is to add this information to the of_device_id
> table. See a bunch of existing drivers for reference.

Yes, I am aware of the strategy, and happy to oblige if this is your
suggestion.  I'll move all platform data into the driver and eradicate
the DT properties.

> Also, why make a separation of output vs. capture channels at this
> point? Could you not simply obtain the total number of PWM channels,
> preferably from SoC data associated with the compatible string, and
> check at ->capture() time whether or not the particular PWM supports
> this?
> 
> As-is, you imply that you have n (output) + m (capture) channels, and
> that 0..n-1 are output and n..n+m-1 are capture channels. What if that
> no longer holds true, but 0 and 2 are the only ones that support
> capture?

We do?  What makes you think that?

> If you check for this at runtime you can avoid complicated DT parsing
> code, but still get the safety check which should be enough to encourage
> people to use the right channels in DT.

I'm pretty sure I can move all the data into the driver.  I did want
to avoid having lots of different compatible strings, but if that's
what you're suggesting, I can introduce one per supported platform.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2016-06-10 14:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08  9:21 [PATCH v3 00/20] pwm: Add support for PWM Capture Lee Jones
2016-06-08  9:21 ` [PATCH v3 01/20] ARM: dts: STi: Rename properites in line with PWM naming conventions Lee Jones
2016-06-08  9:21 ` [PATCH v3 02/20] ARM: dts: STiH407: Supply PWM Capture IRQ Lee Jones
2016-06-08  9:21 ` [PATCH v3 03/20] ARM: dts: STiH407: Declare PWM Capture data lines via Pinctrl Lee Jones
2016-06-08  9:21 ` [PATCH v3 04/20] ARM: dts: STiH416: Supply PWM Capture IRQs Lee Jones
2016-06-08  9:21 ` [PATCH v3 05/20] ARM: dts: STiH416: Declare PWM Capture data lines via Pinctrl Lee Jones
2016-06-08  9:21 ` [PATCH v3 06/20] ARM: dts: STiH416: Define PWM Capture clock Lee Jones
2016-06-08  9:21 ` [PATCH v3 07/20] ARM: dts: STiH416: Define the number of PWM Capture channels Lee Jones
2016-06-08  9:21 ` [PATCH v3 08/20] pwm: Add PWM Capture support Lee Jones
2016-06-10 13:53   ` Thierry Reding
2016-06-10 14:38     ` Lee Jones
2016-06-10 16:39       ` Thierry Reding
2016-06-20 11:14         ` Lee Jones
2016-06-08  9:21 ` [PATCH v3 09/20] pwm: sti: Rename channel => device Lee Jones
2016-06-08  9:21 ` [PATCH v3 10/20] pwm: sysfs: Add PWM Capture support Lee Jones
2016-06-10 14:04   ` Thierry Reding
2016-06-10 14:36     ` Lee Jones
2016-06-08  9:21 ` [PATCH v3 11/20] pwm: sti: Reorganise register names in preparation for new functionality Lee Jones
2016-06-08  9:21 ` [PATCH v3 12/20] pwm: sti: Only request clock rate when you need to Lee Jones
2016-06-08  9:21 ` [PATCH v3 13/20] pwm: sti: Supply PWM Capture register addresses and bit locations Lee Jones
2016-06-08  9:21 ` [PATCH v3 14/20] pwm: sti: Supply PWM Capture clock handling Lee Jones
2016-06-08  9:21 ` [PATCH v3 15/20] pwm: sti: Initialise PWM Capture device data Lee Jones
2016-06-08  9:21 ` [PATCH v3 16/20] pwm: sti: Add support for PWM Capture IRQs Lee Jones
2016-06-08  9:21 ` [PATCH v3 17/20] pwm: sti: Add PWM Capture call-back Lee Jones
2016-06-08  9:21 ` [PATCH v3 18/20] pwm: sti: It's now valid for number of PWM channels to be zero Lee Jones
2016-06-08  9:21 ` [PATCH v3 19/20] pwm: sti: Take the opportunity to conduct a little house keeping Lee Jones
2016-06-08  9:21 ` [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes Lee Jones
2016-06-08 20:51   ` Rob Herring
2016-06-09 11:41     ` Lee Jones
2016-06-10 13:18       ` Thierry Reding
2016-06-10 14:06         ` Lee Jones [this message]
2016-06-10 14:53           ` Thierry Reding
2016-06-10 15:19             ` Lee Jones
2016-07-13  9:02             ` Lee Jones
2016-06-10 13:10     ` Thierry Reding

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=20160610140635.GC1537@dell \
    --to=lee.jones@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@stlinux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=maxime.coquelin@st.com \
    --cc=patrice.chotard@st.com \
    --cc=robh@kernel.org \
    --cc=thierry.reding@gmail.com \
    --subject='Re: [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes' \
    /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

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).