From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Matti Vaittinen <mazziesaccount@gmail.com>,
broonie@kernel.org, lee.jones@linaro.org, lgirdwood@gmail.com,
mark.rutland@arm.com, mturquette@baylibre.com,
robh+dt@kernel.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
mikko.mutanen@fi.rohmeurope.com,
heikki.haikola@fi.rohmeurope.com
Subject: Re: [PATCH v5 4/4] clk: bd71837: Add driver for BD71837 PMIC clock
Date: Wed, 27 Jun 2018 11:40:00 +0300 [thread overview]
Message-ID: <20180627084000.GE2118@localhost.localdomain> (raw)
In-Reply-To: <152997038474.143105.3390705878521933864@swboyd.mtv.corp.google.com>
Hello Stephen,
On Mon, Jun 25, 2018 at 04:46:24PM -0700, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-06-13 06:03:38)
> > On Tue, Jun 12, 2018 at 11:23:54AM +0300, Matti Vaittinen wrote:
> > >
> > > I see. This makes sense. I need to verify from HW colleagues whether
> > > this chip has internal oscillator or not. I originally thought we have
> > > on-chip oscillator - but as you say, we do have XIN pin in documentation.
> > > So now I am not sure if the test board I have contains oscillator driving
> > > the clk on PMIC - or if the PMIC has internal oscillator. I'll clarify this.
> >
> > It really turned out that the PMIC just acts as a clock buffer. So I do
> > as you suggested and add lookup for parent clock to the driver. I
> > planned to do it so that if no parent is found from DT - then we assume
> > the 32.768KHz clock (as described in documentation). Eg, something along
> > the lines:
> >
> > init.parent_names = of_clk_get_parent_name(pdev->dev.parent->of_node, 0);
> > if (init.parent_names) {
> > init.num_parents = 1;
> > } else {
> > /* If parent is not given from DT we assume the typical use-case with
> > * 32.768 KHz oscillator for RTC (Maybe we could just error out here?)
> > */
> > c->rate = BD71837_CLK_RATE;
> > bd71837_clk_ops.recalc_rate = &bd71837_clk_recalc_rate;
> > }
>
> You can also add a clk directly in this driver in that case there isn't
> one in DT with the rate and name of your choosing. Then the logic is the
> same and we don't need a c->rate variable.
So you mean that I should use clk_hw_register_fixed_rate and create new
clk if parent is not found? Isn't this a bit of an overkill? Downside is
that then we do need remove/cleanup functionality for deleting this
parent clock - and I didn't find devm support for fixed clock. Furthermore
I guess that since it is parent, it can't be removed before child is removed.
Or did you mean something else but creating a fixed rate clock as parent
here?
Best Regards
Matti Vaittinen
next prev parent reply other threads:[~2018-06-27 8:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-04 13:17 [PATCH v5 0/4] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver Matti Vaittinen
2018-06-04 13:18 ` [PATCH v5 1/4] mfd: bd71837: mfd driver for ROHM BD71837 PMIC Matti Vaittinen
2018-06-05 7:57 ` Matti Vaittinen
2018-06-04 13:18 ` [PATCH v5 2/4] mfd: bd71837: Devicetree bindings " Matti Vaittinen
2018-06-05 15:47 ` Rob Herring
2018-06-06 5:14 ` Matti Vaittinen
2018-06-04 13:18 ` [PATCH v5 3/4] clk: " Matti Vaittinen
2018-06-05 15:49 ` Rob Herring
2018-06-06 5:10 ` Matti Vaittinen
2018-06-04 13:19 ` [PATCH v5 4/4] clk: bd71837: Add driver for BD71837 PMIC clock Matti Vaittinen
2018-06-12 7:44 ` Stephen Boyd
2018-06-12 7:44 ` Stephen Boyd
2018-06-12 8:23 ` Matti Vaittinen
2018-06-13 13:03 ` Matti Vaittinen
2018-06-25 23:46 ` Stephen Boyd
2018-06-25 23:46 ` Stephen Boyd
2018-06-27 8:40 ` Matti Vaittinen [this message]
2018-07-31 9:05 ` Matti Vaittinen
2018-06-25 23:44 ` Stephen Boyd
2018-06-25 23:44 ` Stephen Boyd
2018-06-25 23:44 ` Stephen Boyd
2018-06-26 8:13 ` Matti Vaittinen
2018-06-29 8:34 ` Matti Vaittinen
2018-07-31 8:28 ` Matti Vaittinen
2018-08-03 8:09 ` Matti Vaittinen
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=20180627084000.GE2118@localhost.localdomain \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heikki.haikola@fi.rohmeurope.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mazziesaccount@gmail.com \
--cc=mikko.mutanen@fi.rohmeurope.com \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.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.