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
next prev parent 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 \
/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).