From: jinkun.hong@rock-chips.com (Hong jinkun)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/3] power-domain: add power domain drivers for Rockchip platform
Date: Wed, 29 Oct 2014 22:09:56 +0800 [thread overview]
Message-ID: <5450F534.8030501@rock-chips.com> (raw)
In-Reply-To: <CAPDyKFp+aNJd_FEY6=-ubK0zvVDWh+x5ZsVG+AVpuBzpSqynOQ@mail.gmail.com>
On 2014/10/22 15:58, Ulf Hansson wrote:
> [...]
>
>>>> +
>>>> + list_for_each_entry(de, &pd->dev_list, node) {
>>>> + i += 1;
>>>> + pm_clk_resume(pd->dev);
>>> Do you really need to call pm_clk_resume() number of times that there
>>> are devices in power domain? Did you want it to be
>>>
>>> pm_clk_resume(de->dev);
>>>
>>> by any chance?
> I was just about to ask the similar question as Dmitry did. :-)
>
>> You are right.I will modify in the next version.
> Now, does that also mean you would like to assign the ->start|stop()
> callbacks in the struct gpd_dev_ops to pm_clk_suspend|resume()? Or do
> you intend to handle that from each driver instead?
If it can call dev_ops.start before calling power_on and power_off is
the best.But I found dev_ops.start not called.Is not I did add some patch?
>>>> + }
>>>> +
>>>> + /* no clk, set power domain will fail */
>>>> + if (i == 0) {
>>>> + pr_err("%s: failed to on/off power domain!", __func__);
>>>> + spin_unlock_irq(&pd->dev_lock);
>>>> + return ret;
>>>> + }
>>> Instead of counting I'd do
>>>
>>> if (list_empty(&pd->dev_list)) {
>>> pr_waen("%s: no devices in power domain\n", __func__);
>>> goto out;
>>> }
>>>
>>> in the beginning of the function.
>> This is a good idea.
>>
>>>> +
>>>> + ret = rockchip_pmu_set_power_domain(pd, power_on);
>>>> +
>>>> + list_for_each_entry(de, &pd->dev_list, node) {
>>>> + pm_clk_suspend(pd->dev);
>>> Same here?
>>>
>>>> + }
>>>> +
>>>> + spin_unlock_irq(&pd->dev_lock);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int rockchip_pd_power_on(struct generic_pm_domain *domain)
>>>> +{
>>>> + struct rockchip_domain *pd = to_rockchip_pd(domain);
>>>> +
>>>> + return rockchip_pd_power(pd, true);
>>>> +}
>>>> +
>>>> +static int rockchip_pd_power_off(struct generic_pm_domain *domain)
>>>> +{
>>>> + struct rockchip_domain *pd = to_rockchip_pd(domain);
>>>> +
>>>> + return rockchip_pd_power(pd, false);
>>>> +}
>>>> +
>>>> +void rockchip_pm_domain_attach_dev(struct device *dev)
>>>> +{
>>>> + int ret;
>>>> + int i = 0;
>>>> + struct clk *clk;
>>>> + struct rockchip_domain *pd;
>>>> + struct rockchip_dev_entry *de;
>>>> +
>>>> + pd = (struct rockchip_domain *)dev->pm_domain;
>>>> + ret = pm_clk_create(dev);
>>>> + if (ret) {
>>>> + dev_err(dev, "pm_clk_create failed %d\n", ret);
>>>> + return;
>>>> + };
>>> Stray semicolon.
>>>> +
>>>> + while ((clk = of_clk_get(dev->of_node, i++)) && !IS_ERR(clk)) {
>>>> + ret = pm_clk_add_clk(dev, clk);
>>>> + if (ret) {
>>>> + dev_err(dev, "pm_clk_add_clk failed %d\n", ret);
>>>> + goto clk_err;
>>>> + };
>>>> + }
>>>> +
>>>> + de = devm_kcalloc(pd->dev, 1,
>>>> + sizeof(struct rockchip_dev_entry *), GFP_KERNEL);
>>> Why devm_calloc for a single element and not devm_kzalloc? Also, I am a
>>> bit concerned about using devm_* API here. They are better reserved fir
>>> driver's ->probe() paths whereas we are called from
>>> dev_pm_domain_attach() which is more general API (yes, currently it is
>>> used by buses probing code, but that might change in the future).
> Using the devm_*API is supposed to work from here. I have kept this in
> mind, while we added the new dev_pm_domain_attach|detach() API. The
> buses also handles -EPROBE_DEFER.
>
> Now, I just realized that while Geert added attach|detach_dev()
> callbacks for the generic PM domain, those are both "void" callbacks.
> It means the deferred probe error handling is broken for these
> callbacks. We should convert the attach_dev() callback into an int, I
> will cook a patch immediately.
>
>>> Also, where is OOM error handling?
>> Ok,I will change the use devm_kzalloc.
>> Register to pm domain devices, the number is not a lot.
> [...]
>
> Kind regards
> Uffe
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Hong jinkun <jinkun.hong@rock-chips.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Russell King <linux@arm.linux.org.uk>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Grant Likely <grant.likely@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Doug Anderson <dianders@chromium.org>,
Heiko Stuebner <heiko@sntech.de>,
linux-rockchip@lists.infradead.org,
Jack Dai <jack.dai@rock-chips.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH v5 1/3] power-domain: add power domain drivers for Rockchip platform
Date: Wed, 29 Oct 2014 22:09:56 +0800 [thread overview]
Message-ID: <5450F534.8030501@rock-chips.com> (raw)
In-Reply-To: <CAPDyKFp+aNJd_FEY6=-ubK0zvVDWh+x5ZsVG+AVpuBzpSqynOQ@mail.gmail.com>
On 2014/10/22 15:58, Ulf Hansson wrote:
> [...]
>
>>>> +
>>>> + list_for_each_entry(de, &pd->dev_list, node) {
>>>> + i += 1;
>>>> + pm_clk_resume(pd->dev);
>>> Do you really need to call pm_clk_resume() number of times that there
>>> are devices in power domain? Did you want it to be
>>>
>>> pm_clk_resume(de->dev);
>>>
>>> by any chance?
> I was just about to ask the similar question as Dmitry did. :-)
>
>> You are right.I will modify in the next version.
> Now, does that also mean you would like to assign the ->start|stop()
> callbacks in the struct gpd_dev_ops to pm_clk_suspend|resume()? Or do
> you intend to handle that from each driver instead?
If it can call dev_ops.start before calling power_on and power_off is
the best.But I found dev_ops.start not called.Is not I did add some patch?
>>>> + }
>>>> +
>>>> + /* no clk, set power domain will fail */
>>>> + if (i == 0) {
>>>> + pr_err("%s: failed to on/off power domain!", __func__);
>>>> + spin_unlock_irq(&pd->dev_lock);
>>>> + return ret;
>>>> + }
>>> Instead of counting I'd do
>>>
>>> if (list_empty(&pd->dev_list)) {
>>> pr_waen("%s: no devices in power domain\n", __func__);
>>> goto out;
>>> }
>>>
>>> in the beginning of the function.
>> This is a good idea.
>>
>>>> +
>>>> + ret = rockchip_pmu_set_power_domain(pd, power_on);
>>>> +
>>>> + list_for_each_entry(de, &pd->dev_list, node) {
>>>> + pm_clk_suspend(pd->dev);
>>> Same here?
>>>
>>>> + }
>>>> +
>>>> + spin_unlock_irq(&pd->dev_lock);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int rockchip_pd_power_on(struct generic_pm_domain *domain)
>>>> +{
>>>> + struct rockchip_domain *pd = to_rockchip_pd(domain);
>>>> +
>>>> + return rockchip_pd_power(pd, true);
>>>> +}
>>>> +
>>>> +static int rockchip_pd_power_off(struct generic_pm_domain *domain)
>>>> +{
>>>> + struct rockchip_domain *pd = to_rockchip_pd(domain);
>>>> +
>>>> + return rockchip_pd_power(pd, false);
>>>> +}
>>>> +
>>>> +void rockchip_pm_domain_attach_dev(struct device *dev)
>>>> +{
>>>> + int ret;
>>>> + int i = 0;
>>>> + struct clk *clk;
>>>> + struct rockchip_domain *pd;
>>>> + struct rockchip_dev_entry *de;
>>>> +
>>>> + pd = (struct rockchip_domain *)dev->pm_domain;
>>>> + ret = pm_clk_create(dev);
>>>> + if (ret) {
>>>> + dev_err(dev, "pm_clk_create failed %d\n", ret);
>>>> + return;
>>>> + };
>>> Stray semicolon.
>>>> +
>>>> + while ((clk = of_clk_get(dev->of_node, i++)) && !IS_ERR(clk)) {
>>>> + ret = pm_clk_add_clk(dev, clk);
>>>> + if (ret) {
>>>> + dev_err(dev, "pm_clk_add_clk failed %d\n", ret);
>>>> + goto clk_err;
>>>> + };
>>>> + }
>>>> +
>>>> + de = devm_kcalloc(pd->dev, 1,
>>>> + sizeof(struct rockchip_dev_entry *), GFP_KERNEL);
>>> Why devm_calloc for a single element and not devm_kzalloc? Also, I am a
>>> bit concerned about using devm_* API here. They are better reserved fir
>>> driver's ->probe() paths whereas we are called from
>>> dev_pm_domain_attach() which is more general API (yes, currently it is
>>> used by buses probing code, but that might change in the future).
> Using the devm_*API is supposed to work from here. I have kept this in
> mind, while we added the new dev_pm_domain_attach|detach() API. The
> buses also handles -EPROBE_DEFER.
>
> Now, I just realized that while Geert added attach|detach_dev()
> callbacks for the generic PM domain, those are both "void" callbacks.
> It means the deferred probe error handling is broken for these
> callbacks. We should convert the attach_dev() callback into an int, I
> will cook a patch immediately.
>
>>> Also, where is OOM error handling?
>> Ok,I will change the use devm_kzalloc.
>> Register to pm domain devices, the number is not a lot.
> [...]
>
> Kind regards
> Uffe
>
>
>
next prev parent reply other threads:[~2014-10-29 14:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 9:13 [PATCH v5 0/3] ARM: rk3288 : Add PM Domain support jinkun.hong
2014-10-21 9:13 ` jinkun.hong
2014-10-21 9:13 ` [PATCH v5 1/3] power-domain: add power domain drivers for Rockchip platform jinkun.hong
2014-10-21 9:13 ` jinkun.hong
2014-10-21 19:58 ` Dmitry Torokhov
2014-10-21 19:58 ` Dmitry Torokhov
2014-10-22 3:34 ` Hong jinkun
2014-10-22 3:34 ` Hong jinkun
2014-10-22 7:58 ` Ulf Hansson
2014-10-22 7:58 ` Ulf Hansson
2014-10-22 8:07 ` Geert Uytterhoeven
2014-10-22 8:07 ` Geert Uytterhoeven
2014-10-22 8:07 ` Geert Uytterhoeven
2014-10-22 8:29 ` Ulf Hansson
2014-10-22 8:29 ` Ulf Hansson
2014-10-22 8:29 ` Ulf Hansson
2014-10-22 17:45 ` Dmitry Torokhov
2014-10-22 17:45 ` Dmitry Torokhov
2014-10-23 12:25 ` Ulf Hansson
2014-10-23 12:25 ` Ulf Hansson
2014-10-29 14:09 ` Hong jinkun [this message]
2014-10-29 14:09 ` Hong jinkun
2014-10-21 9:13 ` [PATCH v5 2/3] dt-bindings: add document of Rockchip power domain jinkun.hong
2014-10-21 9:13 ` jinkun.hong
2014-10-21 9:13 ` [PATCH v5 3/3] ARM: dts: add rk3288 power-domain node jinkun.hong
2014-10-21 9:13 ` jinkun.hong
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=5450F534.8030501@rock-chips.com \
--to=jinkun.hong@rock-chips.com \
--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.