From: York Sun <yorksun@freescale.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: <linux-clk@vger.kernel.org>, <pmarrecas@outlook.com>,
Mike Turquette <mturquette@baylibre.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
"Andrey Filippov" <andrey@elphel.com>,
Paul Bolle <pebolle@tiscali.nl>
Subject: Re: [Resend Patch v6] driver/clk/clk-si5338: Add common clock framework driver for si5338
Date: Mon, 19 Oct 2015 13:34:44 -0700 [thread overview]
Message-ID: <562553E4.30906@freescale.com> (raw)
In-Reply-To: <20151016230555.GE10182@codeaurora.org>
On 10/16/2015 04:05 PM, Stephen Boyd wrote:
> On 10/16, York Sun wrote:
>>
>>
>> On 10/16/2015 02:31 PM, Stephen Boyd wrote:
>>> On 10/16, York Sun wrote:
>>>>
>>>>
>>>> On 10/09/2015 05:09 PM, Stephen Boyd wrote:
>>>>> On 10/09, York Sun wrote:
>>>>>> +/*
>>>>>> + * To support multiple si5338 chips, we cannot use devm_clk_get because
>>>>>> + * each chip has its own clock sources. If device tree is not used,
>>>>>> + * platform driver should provide these clocks. Let the clocks be freed
>>>>>> + * automatically when device is unbound. We implement our own devm_of_clk_get.
>>>>>> + */
>>>>>> +static void devm_of_clk_release(struct device *dev, void *res)
>>>>>> +{
>>>>>> + clk_put(*(struct clk **)res);
>>>>>> +}
>>>>>> +
>>>>>> +static struct clk *devm_of_clk_get(struct device *dev, struct device_node *np,
>>>>>
>>>>> What is this? I don't get it at all.
>>>>
>>>> Maybe you can help me on this.
>>>> We have two ways to get parent clock. One is from device tree, the other is from
>>>> platform data. When the clock is from platform data, the consumer gets the clock
>>>> and passes it. The clock will be put by the consumer as well. When the parent
>>>> clock comes from device tree, what I am trying to do is to call of_clk_get(),
>>>> without worrying about to call clk_put() later when the driver is removed, so I
>>>> don't have to know where the parent clock data came from.
>>>>
>>>
>>> This driver should always use clk_get() then. If the mode is
>>> device tree, clk_get() will lookup the clock in DT and get it
>>> from there. If the mode is platform data, then we'll fallback to
>>> the clkdev method of clk_get(), which will look for a clk_lookup
>>> created for the device calling clk_get() + the connection id that
>>> was provided by the lookup creator. This driver should always
>>> call clk_put() on the clock when it's done with it, regardless of
>>> DT vs. platform data.
>>>
>>
>> For the platform data mode, I think it is up to the consumer to get and put the
>> parent clocks. The current code is to pass (struct clk *) pointers as parent
>> clocks. Are you suggesting to pass the name of parent clocks?
>>
>
> I'm suggesting to register clocks with clkdev using a device name
> that matches the consumer. The consumer (this driver?) will
> simply call clk_get() and clk_put() then, nothing else is needed.
> I'm not suggesting to pass the names of the parent clocks. It
> sounds like those are inputs to this device, so we should be
> calling clk_get() with a device and a connection id to get the
> clock.
>
Stephen,
I am still having difficulty to implement this. The platform device doesn't know
the clock device id when probing the clock chip. For my case, the platform
device is a PCIe device, with I2C controller on it. The clock chip is on the I2C
bus. When the PCIe device is probed, it registers the parent clocks for si5338
before calling i2c_new_probed_device(). At this moment, the si5338 doesn't have
an instance yet. So the parent clock pointer(s) in platform data structure
is/are passed.
I have another solution, let the platform data has clk pointer(s). The clock
driver for si5338 will use device tree of_clk_get() if device tree is used, or
take the pointer(s) from platform data. Upon driver removal, this driver call
clk_put() regardless where the pointer(s) came from. The change will be in my
platform device driver. It doesn't need to call clk_put again.
Would it be acceptable?
York
next prev parent reply other threads:[~2015-10-19 20:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 17:09 [Resend Patch v6] driver/clk/clk-si5338: Add common clock framework driver for si5338 York Sun
2015-10-10 0:09 ` Stephen Boyd
2015-10-16 21:01 ` York Sun
2015-10-16 21:31 ` Stephen Boyd
2015-10-16 21:37 ` York Sun
2015-10-16 23:05 ` Stephen Boyd
2015-10-17 0:09 ` York Sun
2015-10-19 20:34 ` York Sun [this message]
2015-10-20 0:03 ` Stephen Boyd
2015-10-20 0:17 ` York Sun
2015-10-20 0:36 ` Stephen Boyd
2015-10-20 1:28 ` York Sun
2015-10-20 17:20 ` York Sun
2015-10-20 17:49 ` Stephen Boyd
2015-10-21 0:25 ` York Sun
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=562553E4.30906@freescale.com \
--to=yorksun@freescale.com \
--cc=andrey@elphel.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mturquette@baylibre.com \
--cc=pebolle@tiscali.nl \
--cc=pmarrecas@outlook.com \
--cc=sboyd@codeaurora.org \
--cc=sebastian.hesselbarth@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).