From: Stephen Boyd <sboyd@codeaurora.org>
To: Rick Altherr <raltherr@google.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-iio@vger.kernel.org,
Quentin Schulz <quentin.schulz@free-electrons.com>,
David Lechner <david@lechnology.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
William Breathitt Gray <vilhelm.gray@gmail.com>,
linux-clk@vger.kernel.org, Andreas Klinger <ak@it-klinger.de>,
Marek Vasut <marek.vasut+renesas@gmail.com>,
Jonathan Cameron <jic23@kernel.org>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Michael Turquette <mturquette@baylibre.com>,
Rob Herring <robh@kernel.org>,
Alison Schofield <amsfield22@gmail.com>,
Fabrice Gasnier <fabrice.gasnier@st.com>,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Crestez Dan Leonard <leonard.crestez@intel.com>,
Akinobu Mita <akinobu.mita@gmail.com>,
Matt Ranostay <mranostay@gmail.com>
Subject: Re: [PATCH v4 2/2] iio: Aspeed ADC
Date: Wed, 5 Apr 2017 18:10:03 -0700 [thread overview]
Message-ID: <20170406011003.GP7065@codeaurora.org> (raw)
In-Reply-To: <CAPLgG=nYnVuwRZOdXuFCaFy9P0cx_zqfk0f9orBv+8+HxcnqKQ@mail.gmail.com>
On 04/05, Rick Altherr wrote:
> On Wed, Apr 5, 2017 at 1:27 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 03/23, Rick Altherr wrote:
> >> +
> >> +static int aspeed_adc_probe(struct platform_device *pdev)
> >> +{
> >> + struct iio_dev *indio_dev;
> >> + struct aspeed_adc_data *data;
> >> + const struct aspeed_adc_model_data *model_data;
> >> + struct resource *res;
> >> + const char *clk_parent_name;
> >> + int ret;
> >> + u32 adc_engine_control_reg_val;
> >> +
> >> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*data));
> >> + if (!indio_dev)
> >> + return -ENOMEM;
> >> +
> >> + data = iio_priv(indio_dev);
> >> + data->dev = &pdev->dev;
> >> +
> >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> + data->base = devm_ioremap_resource(&pdev->dev, res);
> >> + if (IS_ERR(data->base))
> >> + return PTR_ERR(data->base);
> >> +
> >> + /* Register ADC clock prescaler with source specified by device tree. */
> >> + spin_lock_init(&data->clk_lock);
> >> + clk_parent_name = of_clk_get_parent_name(pdev->dev.of_node, 0);
> >
> > What if the parent clk is not registered yet? Or if we're not
> > always using DT in this driver? Put another way, this code is
> > fragile. But I guess it probably works well enough for now so no
> > big deal, just pointing out my fear.
>
> I'm not terribly worried about not using DT for this driver as it is
> for an ARM SoC's built-in ADC which is only supported via DT. I take
> your point though. What's the right way to do this? Use clk_get() to
> request by name and clock-names in the DT?
Yes that will work. When we add probe defer to clk_get() things
will work better. Presumably the clocks property already exists
for this device so that of_clk_get_parent_name() works so it's
not a binding change?
>
> >
> >> +
> >> + data->clk_prescaler = clk_hw_register_divider(
> >> + &pdev->dev, "prescaler", clk_parent_name, 0,
> >> + data->base + ASPEED_REG_CLOCK_CONTROL,
> >> + 17, 15, 0, &data->clk_lock);
> >> + if (IS_ERR(data->clk_prescaler))
> >> + return PTR_ERR(data->clk_prescaler);
> >> +
> >> + /*
> >> + * Register ADC clock scaler downstream from the prescaler. Allow rate
> >> + * setting to adjust the prescaler as well.
> >> + */
> >> + data->clk_scaler = clk_hw_register_divider(
> >> + &pdev->dev, "scaler", "prescaler",
> >> + CLK_SET_RATE_PARENT,
> >> + data->base + ASPEED_REG_CLOCK_CONTROL,
> >> + 0, 10, 0, &data->clk_lock);
> >> + if (IS_ERR(data->clk_scaler)) {
> >> + ret = PTR_ERR(data->clk_scaler);
> >> + goto scaler_error;
> >> + }
> >> +
> >> + /* Start all channels in normal mode. */
> >> + clk_prepare_enable(data->clk_scaler->clk);
> >
> > Eventually we'd like to get rid of hw->clk pointer so that users
> > have to call some sort of clk_get() API and then we get warm
> > fuzzies from knowing who is consuming a clk structure. Can you
> > change this to register a clk provider and call clk_get()? I
> > think a device that references itself should be OK in DT still,
> > and would properly reflect what's going on.
>
> Do you mean call of_clk_add_hw_provider with of_clk_hw_simple_get or
> something else? I'm still wrapping my head around the distinction
> between clk, clk_hw, and a clk provider.
>
Yes. Unless you don't want to expose these details in DT because
it's all internal to the device?
In that case we need to go merge that patch on the clk list to
have clk_hw_create_clk() or something like that, so we can turn a
clk_hw structure into a clk pointer without directly referencing
the clk member of clk_hw.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2017-04-06 1:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-23 18:41 [PATCH v4 1/2] Documentation: dt-bindings: Document bindings for Aspeed ADC Rick Altherr
2017-03-23 18:41 ` Rick Altherr
2017-03-23 18:41 ` [PATCH v4 2/2] iio: " Rick Altherr
2017-03-24 4:03 ` Joel Stanley
2017-03-25 17:32 ` Jonathan Cameron
2017-03-27 23:05 ` Rick Altherr
2017-04-05 20:27 ` Stephen Boyd
2017-04-05 23:49 ` Rick Altherr
2017-04-06 1:10 ` Stephen Boyd [this message]
2017-04-06 18:57 ` Rick Altherr
2017-04-06 23:03 ` Stephen Boyd
2017-03-24 4:05 ` [PATCH v4 1/2] Documentation: dt-bindings: Document bindings for " Joel Stanley
2017-03-24 4:05 ` Joel Stanley
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=20170406011003.GP7065@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=ak@it-klinger.de \
--cc=akinobu.mita@gmail.com \
--cc=amsfield22@gmail.com \
--cc=david@lechnology.com \
--cc=fabrice.gasnier@st.com \
--cc=geert@linux-m68k.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=leonard.crestez@intel.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marek.vasut+renesas@gmail.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=mranostay@gmail.com \
--cc=mturquette@baylibre.com \
--cc=openbmc@lists.ozlabs.org \
--cc=pmeerw@pmeerw.net \
--cc=quentin.schulz@free-electrons.com \
--cc=raltherr@google.com \
--cc=robh@kernel.org \
--cc=vilhelm.gray@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.