[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s3iqqnqiqnlujncbb6vnip7hvofgbom54on7fx4hxmyfsk2v2w@gbvpkptsa5g3>
Date: Sun, 10 Mar 2024 23:23:57 +0100
From: Ondřej Jirman <x@...x.eu>
To: Frank Oltmanns <frank@...manns.dev>
Cc: Maxime Ripard <mripard@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>,
Icenowy Zheng <uwu@...nowy.me>, dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/sun4i: tcon: Support keeping dclk rate upon ancestor
clock changes
Hello Frank,
On Sun, Mar 10, 2024 at 02:32:29PM +0100, Frank Oltmanns wrote:
> +static int sun4i_rate_reset_notifier_cb(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + struct sun4i_rate_reset_nb *rate_reset = to_sun4i_rate_reset_nb(nb);
> +
> + if (event == POST_RATE_CHANGE)
> + schedule_delayed_work(&rate_reset->reset_rate_work, msecs_to_jiffies(100));
If you get multiple reset notifier calls within 100ms of the first one,
the delay from the last one will not be 100ms, so this may violate expectations
you're describing in the commit message.
schedule_delayed_work doesn't re-schedule the work if it's already pending.
Kind regards,
o.
Powered by blists - more mailing lists