All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Dunn <mikedunn@newsguy.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	linux-pwm@vger.kernel.org, Grant Likely <grant.likely@linaro.org>,
	Rob Herring <rob.herring@calxeda.com>,
	Haojian Zhuang <haojian.zhuang@linaro.org>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Marek Vasut <marex@denx.de>,
	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>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v2] pwm: pxa: add device tree support to pwm driver
Date: Tue, 10 Sep 2013 07:53:15 -0700	[thread overview]
Message-ID: <522F325B.4090602@newsguy.com> (raw)
In-Reply-To: <522E14F5.1020909@wwwdotorg.org>

On 09/09/2013 11:35 AM, Stephen Warren wrote:
> On 09/09/2013 12:03 PM, Mike Dunn wrote:
>> On 09/09/2013 05:08 AM, Thierry Reding wrote:
>>> On Sun, Sep 08, 2013 at 12:40:18PM -0700, Mike Dunn wrote:
>>>> This patch adds device tree support to the pxa's pwm driver.  Only an OF match
> 
>>>> diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> 
>>>> +Marvell pwm controller
>>>> +
>>>> +Required properties:
>>>> +- compatible:
>>>> +  for pxa25x, pxa27x, pxa168, pxa910: must be compatible = "marvell,pxa250-pwm";
>>>> +- reg: physical base address and length of the registers used by the pwm channel
>>>
>>> "pwm" -> "PWM". There are a few more occurrences that I haven't
>>> explicitly pointed out.
>>>
>>>> +  NB: One device instance must be created for each pwm that is used, so the
>>>> +  length covers only the register window for one pwm output, not that of the
>>>> +  entire pwm controller.  Currently length is 0x10 for all supported devices.
>>>
>>> I'm not sure I like that very much. It seems a wrong representation of
>>> the hardware for the sake of modifying a smaller number of lines in the
>>> driver.
>>
>> I don't like it either, but this is an existing driver defect that will need to
>> be corrected.  To do so, I will need to to survey all the supported processors
>> to determine how many pwm outputs is posessed by each.  And there may be some
>> confusion in that regard; the driver says "pxa25x" has one, but my pxa255
>> developer's manual makes no mention of a pwm.  The pxa270 I am testing on has
>> four, but the driver says "pxa27x" has two, so currently (using platform_data
>> with existing driver) two devices are instantiated, each with two pwms.  It
>> seems that there are many variations within a single generation of the processor
>> family, so to correctly identify the number of pwms, processor identification
>> will have to be made on a finer granularity than the current "pxa25x", for
>> example.  I'm guessing that the hardware designers had this
>> one-device-instance-per-pwm approach in mind when they made the decision to
>> segregate the register sets of each pwm.  I really hope that this sin can be
>> forgiven :)
> 
> The DT binding is an ABI, so it needs to correctly represent the HW. As
> such, I'd say that if the binding is wrong, we need to fix it even if it
> means a lot of work.
> 
> That said, if each PWM truly is a *completely* independent block, with
> non-overlapping register spaces, there's certainly an argument that it's
> perfectly acceptable to represent each PWM as a separate DT node...


Thanks Stephen.  Yes, each pwm output has its own registers with no common
control registers.  The only commonality is that they all share a clock in the
clock unit.  But this is handled in the clock manager.

Thanks,
Mike

WARNING: multiple messages have this Message-ID (diff)
From: mikedunn@newsguy.com (Mike Dunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] pwm: pxa: add device tree support to pwm driver
Date: Tue, 10 Sep 2013 07:53:15 -0700	[thread overview]
Message-ID: <522F325B.4090602@newsguy.com> (raw)
In-Reply-To: <522E14F5.1020909@wwwdotorg.org>

On 09/09/2013 11:35 AM, Stephen Warren wrote:
> On 09/09/2013 12:03 PM, Mike Dunn wrote:
>> On 09/09/2013 05:08 AM, Thierry Reding wrote:
>>> On Sun, Sep 08, 2013 at 12:40:18PM -0700, Mike Dunn wrote:
>>>> This patch adds device tree support to the pxa's pwm driver.  Only an OF match
> 
>>>> diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> 
>>>> +Marvell pwm controller
>>>> +
>>>> +Required properties:
>>>> +- compatible:
>>>> +  for pxa25x, pxa27x, pxa168, pxa910: must be compatible = "marvell,pxa250-pwm";
>>>> +- reg: physical base address and length of the registers used by the pwm channel
>>>
>>> "pwm" -> "PWM". There are a few more occurrences that I haven't
>>> explicitly pointed out.
>>>
>>>> +  NB: One device instance must be created for each pwm that is used, so the
>>>> +  length covers only the register window for one pwm output, not that of the
>>>> +  entire pwm controller.  Currently length is 0x10 for all supported devices.
>>>
>>> I'm not sure I like that very much. It seems a wrong representation of
>>> the hardware for the sake of modifying a smaller number of lines in the
>>> driver.
>>
>> I don't like it either, but this is an existing driver defect that will need to
>> be corrected.  To do so, I will need to to survey all the supported processors
>> to determine how many pwm outputs is posessed by each.  And there may be some
>> confusion in that regard; the driver says "pxa25x" has one, but my pxa255
>> developer's manual makes no mention of a pwm.  The pxa270 I am testing on has
>> four, but the driver says "pxa27x" has two, so currently (using platform_data
>> with existing driver) two devices are instantiated, each with two pwms.  It
>> seems that there are many variations within a single generation of the processor
>> family, so to correctly identify the number of pwms, processor identification
>> will have to be made on a finer granularity than the current "pxa25x", for
>> example.  I'm guessing that the hardware designers had this
>> one-device-instance-per-pwm approach in mind when they made the decision to
>> segregate the register sets of each pwm.  I really hope that this sin can be
>> forgiven :)
> 
> The DT binding is an ABI, so it needs to correctly represent the HW. As
> such, I'd say that if the binding is wrong, we need to fix it even if it
> means a lot of work.
> 
> That said, if each PWM truly is a *completely* independent block, with
> non-overlapping register spaces, there's certainly an argument that it's
> perfectly acceptable to represent each PWM as a separate DT node...


Thanks Stephen.  Yes, each pwm output has its own registers with no common
control registers.  The only commonality is that they all share a clock in the
clock unit.  But this is handled in the clock manager.

Thanks,
Mike

WARNING: multiple messages have this Message-ID (diff)
From: Mike Dunn <mikedunn@newsguy.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Marek Vasut <marex@denx.de>,
	linux-pwm@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	devicetree@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Rob Herring <rob.herring@calxeda.com>,
	Chao Xie <chao.xie@marvell.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Haojian Zhuang <haojian.zhuang@linaro.org>,
	Grant Likely <grant.likely@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	linux-arm-kernel@lists.infradead.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v2] pwm: pxa: add device tree support to pwm driver
Date: Tue, 10 Sep 2013 07:53:15 -0700	[thread overview]
Message-ID: <522F325B.4090602@newsguy.com> (raw)
In-Reply-To: <522E14F5.1020909@wwwdotorg.org>

On 09/09/2013 11:35 AM, Stephen Warren wrote:
> On 09/09/2013 12:03 PM, Mike Dunn wrote:
>> On 09/09/2013 05:08 AM, Thierry Reding wrote:
>>> On Sun, Sep 08, 2013 at 12:40:18PM -0700, Mike Dunn wrote:
>>>> This patch adds device tree support to the pxa's pwm driver.  Only an OF match
> 
>>>> diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
> 
>>>> +Marvell pwm controller
>>>> +
>>>> +Required properties:
>>>> +- compatible:
>>>> +  for pxa25x, pxa27x, pxa168, pxa910: must be compatible = "marvell,pxa250-pwm";
>>>> +- reg: physical base address and length of the registers used by the pwm channel
>>>
>>> "pwm" -> "PWM". There are a few more occurrences that I haven't
>>> explicitly pointed out.
>>>
>>>> +  NB: One device instance must be created for each pwm that is used, so the
>>>> +  length covers only the register window for one pwm output, not that of the
>>>> +  entire pwm controller.  Currently length is 0x10 for all supported devices.
>>>
>>> I'm not sure I like that very much. It seems a wrong representation of
>>> the hardware for the sake of modifying a smaller number of lines in the
>>> driver.
>>
>> I don't like it either, but this is an existing driver defect that will need to
>> be corrected.  To do so, I will need to to survey all the supported processors
>> to determine how many pwm outputs is posessed by each.  And there may be some
>> confusion in that regard; the driver says "pxa25x" has one, but my pxa255
>> developer's manual makes no mention of a pwm.  The pxa270 I am testing on has
>> four, but the driver says "pxa27x" has two, so currently (using platform_data
>> with existing driver) two devices are instantiated, each with two pwms.  It
>> seems that there are many variations within a single generation of the processor
>> family, so to correctly identify the number of pwms, processor identification
>> will have to be made on a finer granularity than the current "pxa25x", for
>> example.  I'm guessing that the hardware designers had this
>> one-device-instance-per-pwm approach in mind when they made the decision to
>> segregate the register sets of each pwm.  I really hope that this sin can be
>> forgiven :)
> 
> The DT binding is an ABI, so it needs to correctly represent the HW. As
> such, I'd say that if the binding is wrong, we need to fix it even if it
> means a lot of work.
> 
> That said, if each PWM truly is a *completely* independent block, with
> non-overlapping register spaces, there's certainly an argument that it's
> perfectly acceptable to represent each PWM as a separate DT node...


Thanks Stephen.  Yes, each pwm output has its own registers with no common
control registers.  The only commonality is that they all share a clock in the
clock unit.  But this is handled in the clock manager.

Thanks,
Mike

  reply	other threads:[~2013-09-10 14:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-08 19:40 [PATCH v2] pwm: pxa: add device tree support to pwm driver Mike Dunn
2013-09-08 19:40 ` Mike Dunn
2013-09-08 19:40 ` Mike Dunn
2013-09-09  0:49 ` Marek Vasut
2013-09-09  0:49   ` Marek Vasut
2013-09-09  0:49   ` Marek Vasut
2013-09-09 15:37   ` Mike Dunn
2013-09-09 15:37     ` Mike Dunn
2013-09-09 15:37     ` Mike Dunn
2013-09-09 15:56     ` Marek Vasut
2013-09-09 15:56       ` Marek Vasut
2013-09-09 15:56       ` Marek Vasut
2013-09-09 18:26       ` Mike Dunn
2013-09-09 18:26         ` Mike Dunn
2013-09-09 18:26         ` Mike Dunn
2013-09-09 12:08 ` Thierry Reding
2013-09-09 12:08   ` Thierry Reding
2013-09-09 12:08   ` Thierry Reding
2013-09-09 18:03   ` Mike Dunn
2013-09-09 18:03     ` Mike Dunn
2013-09-09 18:03     ` Mike Dunn
2013-09-09 18:35     ` Stephen Warren
2013-09-09 18:35       ` Stephen Warren
2013-09-09 18:35       ` Stephen Warren
2013-09-10 14:53       ` Mike Dunn [this message]
2013-09-10 14:53         ` Mike Dunn
2013-09-10 14:53         ` Mike Dunn

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=522F325B.4090602@newsguy.com \
    --to=mikedunn@newsguy.com \
    --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=marex@denx.de \
    --cc=mark.rutland@arm.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.