[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01292a92-c5f5-490d-a45f-a11547854c68@vivo.com>
Date: Thu, 22 Aug 2024 11:18:43 +0800
From: Rong Qianfeng <11065417@...o.com>
To: Julian Calaby <julian.calaby@...il.com>,
Rong Qianfeng <rongqianfeng@...o.com>
Cc: Stefan Agner <stefan@...er.ch>, Alison Wang <alison.wang@....com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
Chen-Yu Tsai <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-sunxi@...ts.linux.dev, opensource.kernel@...o.com
Subject: Re: [PATCH] gpu: drm: Use devm_clk_get_enabled() helpers
在 2024/8/22 8:35, Julian Calaby 写道:
> [Some people who received this message don't often get email from julian.calaby@...il.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Rong,
>
> On Tue, Aug 20, 2024 at 10:59 PM Rong Qianfeng <rongqianfeng@...o.com> wrote:
>> Replace devm_clk_get() and clk_prepare_enable() with
>> devm_clk_get_enabled() that also disables and unprepares it on
>> driver detach.
>>
>> Signed-off-by: Rong Qianfeng <rongqianfeng@...o.com>
>> ---
>> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 13 +++----------
>> drivers/gpu/drm/sun4i/sun6i_drc.c | 15 ++++-----------
>> drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 +++----------
>> 3 files changed, 10 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
>> index 0d342f43fa93..f263ad282828 100644
>> --- a/drivers/gpu/drm/sun4i/sun6i_drc.c
>> +++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
>> @@ -42,33 +42,28 @@ static int sun6i_drc_bind(struct device *dev, struct device *master,
>> return ret;
>> }
>>
>> - drc->bus_clk = devm_clk_get(dev, "ahb");
>> + drc->bus_clk = devm_clk_get_enabled(dev, "ahb");
>> if (IS_ERR(drc->bus_clk)) {
>> dev_err(dev, "Couldn't get our bus clock\n");
>> ret = PTR_ERR(drc->bus_clk);
>> goto err_assert_reset;
>> }
>> - clk_prepare_enable(drc->bus_clk);
>>
>> - drc->mod_clk = devm_clk_get(dev, "mod");
>> + drc->mod_clk = devm_clk_get_enabled(dev, "mod");
>> if (IS_ERR(drc->mod_clk)) {
>> dev_err(dev, "Couldn't get our mod clock\n");
>> ret = PTR_ERR(drc->mod_clk);
>> - goto err_disable_bus_clk;
>> + goto err_assert_reset;
>> }
>>
>> ret = clk_set_rate_exclusive(drc->mod_clk, 300000000);
>> if (ret) {
>> dev_err(dev, "Couldn't set the module clock frequency\n");
>> - goto err_disable_bus_clk;
>> + goto err_assert_reset;
>> }
>>
>> - clk_prepare_enable(drc->mod_clk);
> Am I reading this right: is this changing the init sequence so that
> the clock is enabled before setting a rate?
>
> This is the sort of thing that might cause glitches and issues in some
> hardware, so it'd be polite to test such a change on the actual
> hardware before posting it.
Hi Julian ,
I have seen this used in other places, but the problem you raised may be
different on different hardware.
I wonder if anyone can clarify this?
Best regards,
Qianfeng
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: julian.calaby@...il.com
> Profile: http://www.google.com/profiles/julian.calaby/
Powered by blists - more mailing lists