From: linux@prisktech.co.nz (Tony Prisk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
Date: Mon, 22 Oct 2012 20:36:22 +1300 [thread overview]
Message-ID: <1350891382.3592.22.camel@gitbox> (raw)
In-Reply-To: <20121022072448.GB30026@avionic-0098.mockup.avionic-design.de>
On Mon, 2012-10-22 at 09:24 +0200, Thierry Reding wrote:
> On Mon, Oct 22, 2012 at 08:09:07PM +1300, Tony Prisk wrote:
> > On Mon, 2012-10-22 at 19:51 +1300, Tony Prisk wrote:
> > > >
> > > > > chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> > > > > if (chip == NULL) {
> > > > > dev_err(&pdev->dev, "failed to allocate memory\n");
> > > > > @@ -123,26 +144,32 @@ static int __devinit pwm_probe(struct platform_device *pdev)
> > > > > chip->chip.ops = &vt8500_pwm_ops;
> > > > > chip->chip.base = -1;
> > > > > chip->chip.npwm = VT8500_NR_PWMS;
> > > > > + chip->clk = of_clk_get(np, 0);
> > > >
> > > > I thought this was supposed to work transparently across OF and !OF
> > > > configurations by using just clk_get() or devm_clk_get()? I guess that
> > > > if the driver depends on OF, then this would be moot, but we should
> > > > probably stick to the standard usage anyway.
> > > >
> > > > Furthermore, of_clk_get() doesn't seem to be managed, so you'd need to
> > > > add explicit clk_put() in the error cleanup paths. One more argument in
> > > > favour of using devm_clk_get() instead.
> > >
> > > Hmm good point. I stuck with of_ functions because its an OF only driver
> > > and it seemed 'backward' to mix old code with new. It does pose the
> > > question of 'why have of_clk_get() if existing functions work better'.
> >
> > Was about to fix this but noticed why it wasn't like this to start
> > with :)
> >
> > struct clk *devm_clk_get(struct device *dev, const char *id);
> > struct clk *of_clk_get(struct device_node *np, int index);
> >
> > devm_clk_get requires me to 'get' the clock by name. arch-vt8500 (and I
> > believe a lot of other arch's) don't enforce names for clocks defined in
> > devicetree, therefore there is no way for me to know what name the clk
> > has unless I include in the binding that the clock must be named 'xxx'.
>
> I thought clk_get() was supposed to return the first clock specified in
> DT if you pass NULL as the consumer name. I haven't tested this though.
> And I haven't looked at the code.
>
> > of_clk_get retrieves it by the dt-node + index, so it doesn't care as
> > long as its the 1st clock listed.
>
> So the usual way to do this, I believe, is:
>
> clocks = <&clk_foo>;
> clock-names = "foo";
>
> Then use:
>
> clk = devm_clk_get(&pdev->dev, "foo");
>
> And as I said above, I was under the impression that the default would
> be to use the first clock if NULL was specified instead of "foo".
>
> Thierry
clock-names is an optional property (as defined in
bindings/clock/clock-bindings.txt) so relying on it is .. well,
unreliable.
What you say makes sense, but it means the binding document has to make
an optional property into a required property simply to use an 'old'
function when a new function would 'work' (granted not as well, as you
pointed out) without requiring the optional property.
Your subsystem - your rules. Let me know if I've managed to sway you or
not :)
Regards
Tony P
WARNING: multiple messages have this Message-ID (diff)
From: Tony Prisk <linux@prisktech.co.nz>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: devicetree-discuss@lists.ozlabs.org, arm@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
Date: Mon, 22 Oct 2012 20:36:22 +1300 [thread overview]
Message-ID: <1350891382.3592.22.camel@gitbox> (raw)
In-Reply-To: <20121022072448.GB30026@avionic-0098.mockup.avionic-design.de>
On Mon, 2012-10-22 at 09:24 +0200, Thierry Reding wrote:
> On Mon, Oct 22, 2012 at 08:09:07PM +1300, Tony Prisk wrote:
> > On Mon, 2012-10-22 at 19:51 +1300, Tony Prisk wrote:
> > > >
> > > > > chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> > > > > if (chip == NULL) {
> > > > > dev_err(&pdev->dev, "failed to allocate memory\n");
> > > > > @@ -123,26 +144,32 @@ static int __devinit pwm_probe(struct platform_device *pdev)
> > > > > chip->chip.ops = &vt8500_pwm_ops;
> > > > > chip->chip.base = -1;
> > > > > chip->chip.npwm = VT8500_NR_PWMS;
> > > > > + chip->clk = of_clk_get(np, 0);
> > > >
> > > > I thought this was supposed to work transparently across OF and !OF
> > > > configurations by using just clk_get() or devm_clk_get()? I guess that
> > > > if the driver depends on OF, then this would be moot, but we should
> > > > probably stick to the standard usage anyway.
> > > >
> > > > Furthermore, of_clk_get() doesn't seem to be managed, so you'd need to
> > > > add explicit clk_put() in the error cleanup paths. One more argument in
> > > > favour of using devm_clk_get() instead.
> > >
> > > Hmm good point. I stuck with of_ functions because its an OF only driver
> > > and it seemed 'backward' to mix old code with new. It does pose the
> > > question of 'why have of_clk_get() if existing functions work better'.
> >
> > Was about to fix this but noticed why it wasn't like this to start
> > with :)
> >
> > struct clk *devm_clk_get(struct device *dev, const char *id);
> > struct clk *of_clk_get(struct device_node *np, int index);
> >
> > devm_clk_get requires me to 'get' the clock by name. arch-vt8500 (and I
> > believe a lot of other arch's) don't enforce names for clocks defined in
> > devicetree, therefore there is no way for me to know what name the clk
> > has unless I include in the binding that the clock must be named 'xxx'.
>
> I thought clk_get() was supposed to return the first clock specified in
> DT if you pass NULL as the consumer name. I haven't tested this though.
> And I haven't looked at the code.
>
> > of_clk_get retrieves it by the dt-node + index, so it doesn't care as
> > long as its the 1st clock listed.
>
> So the usual way to do this, I believe, is:
>
> clocks = <&clk_foo>;
> clock-names = "foo";
>
> Then use:
>
> clk = devm_clk_get(&pdev->dev, "foo");
>
> And as I said above, I was under the impression that the default would
> be to use the first clock if NULL was specified instead of "foo".
>
> Thierry
clock-names is an optional property (as defined in
bindings/clock/clock-bindings.txt) so relying on it is .. well,
unreliable.
What you say makes sense, but it means the binding document has to make
an optional property into a required property simply to use an 'old'
function when a new function would 'work' (granted not as well, as you
pointed out) without requiring the optional property.
Your subsystem - your rules. Let me know if I've managed to sway you or
not :)
Regards
Tony P
next prev parent reply other threads:[~2012-10-22 7:36 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 10:38 [PATCH 1/3] ARM: dts: Update board files for pwm support Tony Prisk
2012-10-19 10:38 ` Tony Prisk
2012-10-19 10:38 ` [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support Tony Prisk
2012-10-19 10:38 ` Tony Prisk
2012-10-19 10:38 ` Tony Prisk
2012-10-22 6:34 ` Thierry Reding
2012-10-22 6:34 ` Thierry Reding
2012-10-22 6:51 ` Tony Prisk
2012-10-22 6:51 ` Tony Prisk
2012-10-22 7:09 ` Tony Prisk
2012-10-22 7:09 ` Tony Prisk
2012-10-22 7:09 ` Tony Prisk
2012-10-22 7:24 ` Thierry Reding
2012-10-22 7:24 ` Thierry Reding
2012-10-22 7:24 ` Thierry Reding
2012-10-22 7:36 ` Tony Prisk [this message]
2012-10-22 7:36 ` Tony Prisk
2012-10-22 8:04 ` Thierry Reding
2012-10-22 8:04 ` Thierry Reding
2012-10-22 8:13 ` [PATCH v2] pwm: " Tony Prisk
2012-10-22 8:13 ` Tony Prisk
2012-10-22 8:13 ` Tony Prisk
2012-10-22 8:40 ` Thierry Reding
2012-10-22 8:40 ` Thierry Reding
2012-10-22 18:10 ` [PATCH v3] " Tony Prisk
2012-10-22 18:10 ` Tony Prisk
2012-10-23 22:14 ` Thierry Reding
2012-10-23 22:14 ` Thierry Reding
2012-10-24 3:46 ` Tony Prisk
2012-10-24 3:46 ` Tony Prisk
2012-10-24 5:41 ` Thierry Reding
2012-10-24 5:41 ` Thierry Reding
2012-10-24 17:35 ` Tony Prisk
2012-10-24 17:35 ` Tony Prisk
2012-10-24 3:48 ` Tony Prisk
2012-10-24 3:48 ` Tony Prisk
2012-10-23 8:41 ` [PATCH 2/3] PWM: " Tony Prisk
2012-10-23 8:41 ` Tony Prisk
2012-10-23 9:22 ` Thierry Reding
2012-10-23 9:22 ` Thierry Reding
2012-10-23 9:22 ` Thierry Reding
2012-10-23 9:31 ` Russell King - ARM Linux
2012-10-23 9:31 ` Russell King - ARM Linux
2012-10-23 9:31 ` Russell King - ARM Linux
2012-10-23 9:56 ` Thierry Reding
2012-10-23 9:56 ` Thierry Reding
2012-10-22 7:11 ` Thierry Reding
2012-10-22 7:11 ` Thierry Reding
2012-10-22 11:50 ` Arnd Bergmann
2012-10-22 11:50 ` Arnd Bergmann
2012-10-22 12:07 ` Thierry Reding
2012-10-22 12:07 ` Thierry Reding
2012-10-22 13:52 ` Arnd Bergmann
2012-10-22 13:52 ` Arnd Bergmann
2012-10-22 13:52 ` Arnd Bergmann
2012-10-22 15:08 ` Thierry Reding
2012-10-22 15:08 ` Thierry Reding
2012-10-22 15:08 ` Thierry Reding
2012-10-22 17:49 ` Tony Prisk
2012-10-22 17:49 ` Tony Prisk
2012-10-19 10:38 ` [PATCH 3/3] DOC: PWM: Adding binding document for via,vt8500-pwm Tony Prisk
2012-10-19 10:38 ` Tony Prisk
2012-10-19 10:38 ` Tony Prisk
2012-10-22 6:35 ` Thierry Reding
2012-10-22 6:35 ` Thierry Reding
2012-10-22 6:53 ` Tony Prisk
2012-10-22 6:53 ` Tony Prisk
2012-10-19 22:37 ` [PATCH 1/3] ARM: dts: Update board files for pwm support Tony Prisk
2012-10-19 22:37 ` Tony Prisk
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=1350891382.3592.22.camel@gitbox \
--to=linux@prisktech.co.nz \
--cc=linux-arm-kernel@lists.infradead.org \
/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.