From: Chanwoo Choi <cw00.choi@samsung.com>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Enric Balletbo Serra <eballetbo@gmail.com>,
cwchoi00@gmail.com
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
kernel@collabora.com, Kyungmin Park <kyungmin.park@samsung.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [PATCH] devfreq: rk3399_dmc: Fix duplicated opp table on reload.
Date: Wed, 20 Jun 2018 09:50:22 +0900 [thread overview]
Message-ID: <5B29A4CE.9060009@samsung.com> (raw)
In-Reply-To: <65546a48-3291-9836-cb0c-1e65ff7c9d41@collabora.com>
Hi Enric,
On 2018년 06월 19일 17:07, Enric Balletbo i Serra wrote:
> Hi Chanwoo,
>
> On 19/06/18 06:18, Chanwoo Choi wrote:
>> Hi Enric,
>>
>> On 2018년 06월 18일 18:10, Enric Balletbo Serra wrote:
>>> Hi Chanwoo,
>>>
>>> Missatge de Chanwoo Choi <cwchoi00@gmail.com> del dia dg., 17 de juny
>>> 2018 a les 5:23:
>>>>
>>>> Hi Enric,
>>>>
>>>> 2018-06-16 0:12 GMT+09:00 Enric Balletbo i Serra <enric.balletbo@collabora.com>:
>>>>> The opp table is not removed when the driver is unloaded neither when
>>>>> there is an error within probe, so if the driver is reloaded the opp
>>>>> core shows the following warning:
>>>>>
>>>>> rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
>>>>> 200000000, volt: 900000, enabled: 1. New: freq: 200000000,
>>>>> volt: 900000, enabled: 1
>>>>> rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
>>>>> 400000000, volt: 900000, enabled: 1. New: freq: 400000000,
>>>>> volt: 900000, enabled: 1
>>>>> rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
>>>>> 666000000, volt: 900000, enabled: 1. New: freq: 666000000,
>>>>> volt: 900000, enabled: 1
>>>>> rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
>>>>> 800000000, volt: 900000, enabled: 1. New: freq: 800000000,
>>>>> volt: 900000, enabled: 1
>>>>> rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
>>>>> 928000000, volt: 900000, enabled: 1. New: freq: 928000000,
>>>>> volt: 900000, enabled: 1
>>>>>
>>>>> This patch fixes the error path in the probe function and adds a .remove
>>>>> function to properly cleanup the opp table on unloading.
>>>>>
>>>>> Fixes: 5a893e31a636c (PM / devfreq: rockchip: add devfreq driver for rk3399 dmc)
>>>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>>>> ---
>>>>>
>>>>> drivers/devfreq/rk3399_dmc.c | 31 +++++++++++++++++++++++++++----
>>>>> 1 file changed, 27 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
>>>>> index d5c03e5abe13..e795ad2b3f6b 100644
>>>>> --- a/drivers/devfreq/rk3399_dmc.c
>>>>> +++ b/drivers/devfreq/rk3399_dmc.c
>>>>> @@ -375,8 +375,10 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
>>>>> data->rate = clk_get_rate(data->dmc_clk);
>>>>>
>>>>> opp = devfreq_recommended_opp(dev, &data->rate, 0);
>>>>> - if (IS_ERR(opp))
>>>>> - return PTR_ERR(opp);
>>>>> + if (IS_ERR(opp)) {
>>>>> + ret = PTR_ERR(opp);
>>>>> + goto err_free_opp;
>>>>> + }
>>>>>
>>>>> data->rate = dev_pm_opp_get_freq(opp);
>>>>> data->volt = dev_pm_opp_get_voltage(opp);
>>>>> @@ -388,13 +390,33 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
>>>>> &rk3399_devfreq_dmc_profile,
>>>>> DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>>>> &data->ondemand_data);
>>>>> - if (IS_ERR(data->devfreq))
>>>>> - return PTR_ERR(data->devfreq);
>>>>> + if (IS_ERR(data->devfreq)) {
>>>>> + ret = PTR_ERR(data->devfreq);
>>>>> + goto err_free_opp;
>>>>> + }
>>>>> +
>>>>> devm_devfreq_register_opp_notifier(dev, data->devfreq);
>>>>>
>>>>> data->dev = dev;
>>>>> platform_set_drvdata(pdev, data);
>>>>>
>>>>> + return 0;
>>>>
>>>> It looks strange. Because rk3399_dmcfreq_probe() already include
>>>> 'return 0' when success.
>>>> What is the base commit of this patch?
>>>>
>>>
>>> Sorry, I am not sure I understand your question, If I am not answering
>>> below could you rephrase?
>>
>> When I check the rk3399_dmcfreq_probe()[1], as I commented,
>> rk3399_dmcfreq_probe() already 'return 0' after platform_set_drvdata().
>> You can check it on link[1].
>> [1] https://elixir.bootlin.com/linux/v4.18-rc1/source/drivers/devfreq/rk3399_dmc.c#L443
>>
>> But, this patch add new '+ return 0;' line again in rk3399_dmcfreq_probe().
>> So, just I asked what is base commit of this patch.
>>
>
> I think that this is just how git did the diff and if you only look at the diff
> is a bit confusing, if you apply the patch on top of mainline you will see that
> there is only one return 0 in the probe function.
Anyway, when I applied it to git, there is no problem.
Just I have never seen such a case and asked a question.
Don't care about this anymore. Thanks.
>
> + return 0; (this new return ...)
> +
> +err_free_opp:
> + dev_pm_opp_of_remove_table(&pdev->dev);
> + return ret;
> +}
> +
> +static int rk3399_dmcfreq_remove(struct platform_device *pdev)
> +{
> + struct rk3399_dmcfreq *dmcfreq = dev_get_drvdata(&pdev->dev);
> +
> + /*
> + * Before remove the opp table we need to unregister the opp notifier.
> + */
> + devm_devfreq_unregister_opp_notifier(dmcfreq->dev, dmcfreq->devfreq);
> + dev_pm_opp_of_remove_table(dmcfreq->dev);
> +
> return 0; (was this before the patch, but now is in another function)
>
> Cheers,
> Enric
>
>>>
>>> So, once the opp table is added we need an error path to free it if an
>>> error occurs later. When the probe returns 0, we need to free the opp
>>> table when we remove the module.
>>>
>>>> [snip]
>>>>
>>>> Anyway, if probe fail, device driver have to remove registered OPP table.
>>>> Looks good to me.
>>>>
>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>
>>>
>>> Thanks,
>>> Enric
>>>
>>>> --
>>>> Best Regards,
>>>> Chanwoo Choi
>>>> Samsung Electronics
>>>
>>>
>>>
>>
>>
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
next prev parent reply other threads:[~2018-06-20 0:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 15:12 [PATCH] devfreq: rk3399_dmc: Fix duplicated opp table on reload Enric Balletbo i Serra
2018-06-17 3:23 ` Chanwoo Choi
2018-06-18 9:10 ` Enric Balletbo Serra
2018-06-19 4:18 ` Chanwoo Choi
2018-06-19 8:07 ` Enric Balletbo i Serra
2018-06-20 0:50 ` Chanwoo Choi [this message]
2018-07-17 13:17 ` Enric Balletbo Serra
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=5B29A4CE.9060009@samsung.com \
--to=cw00.choi@samsung.com \
--cc=cwchoi00@gmail.com \
--cc=eballetbo@gmail.com \
--cc=enric.balletbo@collabora.com \
--cc=kernel@collabora.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=myungjoo.ham@samsung.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.