From: Marek Vasut <marex@denx.de>
To: Mike Dunn <mikedunn@newsguy.com>
Cc: linux-pwm@vger.kernel.org, Grant Likely <grant.likely@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Rob Herring <rob.herring@calxeda.com>,
Haojian Zhuang <haojian.zhuang@linaro.org>,
Robert Jarzmik <robert.jarzmik@free.fr>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Chao Xie <chao.xie@marvell.com>,
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v3] PWM: PXA: add device tree support to PWM driver
Date: Mon, 16 Sep 2013 17:10:15 +0200 [thread overview]
Message-ID: <201309161710.15800.marex@denx.de> (raw)
In-Reply-To: <523718D3.4050003@newsguy.com>
Dear Mike Dunn,
> On 09/15/2013 07:07 AM, Marek Vasut wrote:
> > Dear Mike Dunn,
> >
> >> This patch adds device tree support to the PXA's PWM driver. Only an OF
> >> match table is added; nothing needs to be extracted from the device tree
> >> node. The existing ID table is reused for the match table data.
> >>
> >> Tested on a Palm Treo 680 (both platform data and DT cases).
> >>
> >> Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
> >> ---
> >> Changle log:
> >> v3:
> >> - remove support for the polarity flag
> >> - remove per-chip pwm index cell; define custom of_xlate()
> >>
> >> (now #pwm-cells = <1>)
> >>
> >> - "compatible" strings for all devices added to OF match table
> >> - various stylistic changes recommended by reviewers
> >>
> >> v2:
> >> - of_match_table contains only the "pxa250-pwm" compatible string;
> >> require one device instance per pwm
> >> - add Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> - add support for polarity flag in DT and implement set_polarity()
> >> method
> >>
> >> (the treo 680 inverts the signal between pwm out and backlight)
> >>
> >> - return -EINVAL instead of -ENODEV if platform data or DT node not
> >> found - output dev_info string if platform data missing
> >> - expanded CC list of patch
> >>
> >> Documentation/devicetree/bindings/pwm/pxa-pwm.txt | 31 ++++++++++++
> >> arch/arm/boot/dts/pxa27x.dtsi | 24 +++++++++
> >> drivers/pwm/pwm-pxa.c | 62
> >>
> >> +++++++++++++++++++++++ 3 files changed, 117 insertions(+)
> >>
> >> create mode 100644 Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt new file mode 100644
> >> index 0000000..6fcf90c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> @@ -0,0 +1,31 @@
> >> +Marvell PWM controller
> >> +
> >> +Required properties:
> >> +- compatible: should be one of:
> >> + - "marvell,pxa250-pwm"
> >> + - "marvell,pxa270-pwm"
> >> + - "marvell,pxa168-pwm"
> >> + - "marvell,pxa910-pwm"
> >
> > This really is something I dont quite understand. Why should the driver
> > list _every_ _single_ existing CPU that contains such PWM block? Is
> > there any agreement about that? For me, it'd make much more sense to
> > list only the CPUs where the IP block actually changed in some way, so
> > that the differences can be discerned that way.
>
> I believe that this was Stephen's suggestion.
>
> I actually don't object myself. For the price of a few strings, it
> - clearly shows which SoCs the driver supports
> - ensures that any future differences are handled cleanly (e.g., if a hw
> bug in one is discovered and a work-around is implemented)
> - keeps thngs clean if support for another processor which does have pwm hw
> differences is added
>
> Especially the third point... otherwise, you have the case of a somewhat
> confusing many-to-one mapping of processors to compatible strings.
OK, to push it ad-absurdum, shall we not start listing every single revision of
the CPU as well ? Like pxa250a0 250a1 etc ? Yes , this many-to-one mapping is
something I don't quite understand, that's why I'd love to see a good reasoning
from Stephen.
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] PWM: PXA: add device tree support to PWM driver
Date: Mon, 16 Sep 2013 17:10:15 +0200 [thread overview]
Message-ID: <201309161710.15800.marex@denx.de> (raw)
In-Reply-To: <523718D3.4050003@newsguy.com>
Dear Mike Dunn,
> On 09/15/2013 07:07 AM, Marek Vasut wrote:
> > Dear Mike Dunn,
> >
> >> This patch adds device tree support to the PXA's PWM driver. Only an OF
> >> match table is added; nothing needs to be extracted from the device tree
> >> node. The existing ID table is reused for the match table data.
> >>
> >> Tested on a Palm Treo 680 (both platform data and DT cases).
> >>
> >> Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
> >> ---
> >> Changle log:
> >> v3:
> >> - remove support for the polarity flag
> >> - remove per-chip pwm index cell; define custom of_xlate()
> >>
> >> (now #pwm-cells = <1>)
> >>
> >> - "compatible" strings for all devices added to OF match table
> >> - various stylistic changes recommended by reviewers
> >>
> >> v2:
> >> - of_match_table contains only the "pxa250-pwm" compatible string;
> >> require one device instance per pwm
> >> - add Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> - add support for polarity flag in DT and implement set_polarity()
> >> method
> >>
> >> (the treo 680 inverts the signal between pwm out and backlight)
> >>
> >> - return -EINVAL instead of -ENODEV if platform data or DT node not
> >> found - output dev_info string if platform data missing
> >> - expanded CC list of patch
> >>
> >> Documentation/devicetree/bindings/pwm/pxa-pwm.txt | 31 ++++++++++++
> >> arch/arm/boot/dts/pxa27x.dtsi | 24 +++++++++
> >> drivers/pwm/pwm-pxa.c | 62
> >>
> >> +++++++++++++++++++++++ 3 files changed, 117 insertions(+)
> >>
> >> create mode 100644 Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt new file mode 100644
> >> index 0000000..6fcf90c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> @@ -0,0 +1,31 @@
> >> +Marvell PWM controller
> >> +
> >> +Required properties:
> >> +- compatible: should be one of:
> >> + - "marvell,pxa250-pwm"
> >> + - "marvell,pxa270-pwm"
> >> + - "marvell,pxa168-pwm"
> >> + - "marvell,pxa910-pwm"
> >
> > This really is something I dont quite understand. Why should the driver
> > list _every_ _single_ existing CPU that contains such PWM block? Is
> > there any agreement about that? For me, it'd make much more sense to
> > list only the CPUs where the IP block actually changed in some way, so
> > that the differences can be discerned that way.
>
> I believe that this was Stephen's suggestion.
>
> I actually don't object myself. For the price of a few strings, it
> - clearly shows which SoCs the driver supports
> - ensures that any future differences are handled cleanly (e.g., if a hw
> bug in one is discovered and a work-around is implemented)
> - keeps thngs clean if support for another processor which does have pwm hw
> differences is added
>
> Especially the third point... otherwise, you have the case of a somewhat
> confusing many-to-one mapping of processors to compatible strings.
OK, to push it ad-absurdum, shall we not start listing every single revision of
the CPU as well ? Like pxa250a0 250a1 etc ? Yes , this many-to-one mapping is
something I don't quite understand, that's why I'd love to see a good reasoning
from Stephen.
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Mike Dunn <mikedunn-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Haojian Zhuang
<haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Chao Xie <chao.xie-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Ian Campbell
<ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v3] PWM: PXA: add device tree support to PWM driver
Date: Mon, 16 Sep 2013 17:10:15 +0200 [thread overview]
Message-ID: <201309161710.15800.marex@denx.de> (raw)
In-Reply-To: <523718D3.4050003-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
Dear Mike Dunn,
> On 09/15/2013 07:07 AM, Marek Vasut wrote:
> > Dear Mike Dunn,
> >
> >> This patch adds device tree support to the PXA's PWM driver. Only an OF
> >> match table is added; nothing needs to be extracted from the device tree
> >> node. The existing ID table is reused for the match table data.
> >>
> >> Tested on a Palm Treo 680 (both platform data and DT cases).
> >>
> >> Signed-off-by: Mike Dunn <mikedunn-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
> >> ---
> >> Changle log:
> >> v3:
> >> - remove support for the polarity flag
> >> - remove per-chip pwm index cell; define custom of_xlate()
> >>
> >> (now #pwm-cells = <1>)
> >>
> >> - "compatible" strings for all devices added to OF match table
> >> - various stylistic changes recommended by reviewers
> >>
> >> v2:
> >> - of_match_table contains only the "pxa250-pwm" compatible string;
> >> require one device instance per pwm
> >> - add Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> - add support for polarity flag in DT and implement set_polarity()
> >> method
> >>
> >> (the treo 680 inverts the signal between pwm out and backlight)
> >>
> >> - return -EINVAL instead of -ENODEV if platform data or DT node not
> >> found - output dev_info string if platform data missing
> >> - expanded CC list of patch
> >>
> >> Documentation/devicetree/bindings/pwm/pxa-pwm.txt | 31 ++++++++++++
> >> arch/arm/boot/dts/pxa27x.dtsi | 24 +++++++++
> >> drivers/pwm/pwm-pxa.c | 62
> >>
> >> +++++++++++++++++++++++ 3 files changed, 117 insertions(+)
> >>
> >> create mode 100644 Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt new file mode 100644
> >> index 0000000..6fcf90c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> >> @@ -0,0 +1,31 @@
> >> +Marvell PWM controller
> >> +
> >> +Required properties:
> >> +- compatible: should be one of:
> >> + - "marvell,pxa250-pwm"
> >> + - "marvell,pxa270-pwm"
> >> + - "marvell,pxa168-pwm"
> >> + - "marvell,pxa910-pwm"
> >
> > This really is something I dont quite understand. Why should the driver
> > list _every_ _single_ existing CPU that contains such PWM block? Is
> > there any agreement about that? For me, it'd make much more sense to
> > list only the CPUs where the IP block actually changed in some way, so
> > that the differences can be discerned that way.
>
> I believe that this was Stephen's suggestion.
>
> I actually don't object myself. For the price of a few strings, it
> - clearly shows which SoCs the driver supports
> - ensures that any future differences are handled cleanly (e.g., if a hw
> bug in one is discovered and a work-around is implemented)
> - keeps thngs clean if support for another processor which does have pwm hw
> differences is added
>
> Especially the third point... otherwise, you have the case of a somewhat
> confusing many-to-one mapping of processors to compatible strings.
OK, to push it ad-absurdum, shall we not start listing every single revision of
the CPU as well ? Like pxa250a0 250a1 etc ? Yes , this many-to-one mapping is
something I don't quite understand, that's why I'd love to see a good reasoning
from Stephen.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-09-16 15:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 16:54 [PATCH v3] PWM: PXA: add device tree support to PWM driver Mike Dunn
2013-09-13 16:54 ` Mike Dunn
2013-09-13 16:54 ` Mike Dunn
2013-09-15 14:07 ` Marek Vasut
2013-09-15 14:07 ` Marek Vasut
2013-09-15 14:07 ` Marek Vasut
2013-09-16 14:42 ` Mike Dunn
2013-09-16 14:42 ` Mike Dunn
2013-09-16 14:42 ` Mike Dunn
2013-09-16 15:10 ` Marek Vasut [this message]
2013-09-16 15:10 ` Marek Vasut
2013-09-16 15:10 ` Marek Vasut
2013-09-16 19:45 ` Stephen Warren
2013-09-16 19:45 ` Stephen Warren
2013-09-16 19:45 ` Stephen Warren
2013-09-16 23:00 ` Marek Vasut
2013-09-16 23:00 ` Marek Vasut
2013-09-16 23:00 ` Marek Vasut
2013-09-16 19:44 ` Stephen Warren
2013-09-16 19:44 ` Stephen Warren
2013-09-16 19:44 ` Stephen Warren
2013-09-16 23:01 ` Marek Vasut
2013-09-16 23:01 ` Marek Vasut
2013-09-16 23:01 ` Marek Vasut
2013-09-16 23:03 ` Stephen Warren
2013-09-16 23:03 ` Stephen Warren
2013-09-16 23:03 ` Stephen Warren
2013-09-17 14:07 ` Mike Dunn
2013-09-17 14:07 ` Mike Dunn
2013-09-17 14:07 ` Mike Dunn
2013-09-17 16:17 ` Stephen Warren
2013-09-17 16:17 ` Stephen Warren
2013-09-17 16:17 ` Stephen Warren
2013-09-17 18:56 ` Mike Dunn
2013-09-17 18:56 ` Mike Dunn
2013-09-17 18:56 ` Mike Dunn
2013-09-17 19:26 ` Stephen Warren
2013-09-17 19:26 ` Stephen Warren
2013-09-17 19:26 ` Stephen Warren
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=201309161710.15800.marex@denx.de \
--to=marex@denx.de \
--cc=chao.xie@marvell.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=grant.likely@linaro.org \
--cc=haojian.zhuang@linaro.org \
--cc=ian.campbell@citrix.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mikedunn@newsguy.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=robert.jarzmik@free.fr \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=swarren@wwwdotorg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.