All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Maxime Ripard <maxime@cerno.tech>, Emma Anholt <emma@anholt.net>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] drm/vc4: hdmi: Enable power domain before setting minimum
Date: Mon, 13 Feb 2023 13:59:06 +0100	[thread overview]
Message-ID: <d6b158ff-382c-c659-04c8-930b2681e8d6@redhat.com> (raw)
In-Reply-To: <20230126-rpi-display-fw-clk-cleanup-v1-2-d646ff6fb842@cerno.tech>

On 1/26/23 18:05, Maxime Ripard wrote:
> On the RaspberryPi0-3, the HSM clock was provided by the clk-bcm2835
> driver, but on the Pi4 it was provided by the firmware through the
> clk-raspberrypi driver.
> 
> The clk-bcm2835 driver registers the HSM clock using the
> CLK_SET_RATE_GATE flag that prevents any modification to the rate while
> the clock is active.
> 
> This meant that we needed to call clk_set_min_rate() before our call to
> pm_runtime_resume_and_get() since our runtime_resume implementation
> needs to enable the HSM clock for the HDMI controller registers to be
> functional.
> 
> However, the HSM clock is part of the HDMI power domain which might not
> be powered prior to the pm_runtime_resume_and_get() call, so we could
> end up changing the rate of the HSM clock while its power domain was
> disabled.
> 
> We recently changed the backing driver for the RaspberryPi0-3 to
> clk-raspberrypi though, which doesn't have such restrictions. We can
> thus move the clk_set_min_rate() after our call to runtime_resume and
> avoid the access while the power domain is disabled.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

I'm not familiar with the RPi clock hierarchy but the commit message explains
why a clk_set_min_rate() was needed before the pm_runtime_resume_and_get(),
and why that isn't needed anymore after the switch to clk-raspberrypi driver.

And certainly, the correct thing to do is to enable the power domain that a
controller is part of, before attempting to change the rate for one of its
clocks. So the patch looks good to me.

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javierm@redhat.com>
To: Maxime Ripard <maxime@cerno.tech>, Emma Anholt <emma@anholt.net>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] drm/vc4: hdmi: Enable power domain before setting minimum
Date: Mon, 13 Feb 2023 13:59:06 +0100	[thread overview]
Message-ID: <d6b158ff-382c-c659-04c8-930b2681e8d6@redhat.com> (raw)
In-Reply-To: <20230126-rpi-display-fw-clk-cleanup-v1-2-d646ff6fb842@cerno.tech>

On 1/26/23 18:05, Maxime Ripard wrote:
> On the RaspberryPi0-3, the HSM clock was provided by the clk-bcm2835
> driver, but on the Pi4 it was provided by the firmware through the
> clk-raspberrypi driver.
> 
> The clk-bcm2835 driver registers the HSM clock using the
> CLK_SET_RATE_GATE flag that prevents any modification to the rate while
> the clock is active.
> 
> This meant that we needed to call clk_set_min_rate() before our call to
> pm_runtime_resume_and_get() since our runtime_resume implementation
> needs to enable the HSM clock for the HDMI controller registers to be
> functional.
> 
> However, the HSM clock is part of the HDMI power domain which might not
> be powered prior to the pm_runtime_resume_and_get() call, so we could
> end up changing the rate of the HSM clock while its power domain was
> disabled.
> 
> We recently changed the backing driver for the RaspberryPi0-3 to
> clk-raspberrypi though, which doesn't have such restrictions. We can
> thus move the clk_set_min_rate() after our call to runtime_resume and
> avoid the access while the power domain is disabled.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

I'm not familiar with the RPi clock hierarchy but the commit message explains
why a clk_set_min_rate() was needed before the pm_runtime_resume_and_get(),
and why that isn't needed anymore after the switch to clk-raspberrypi driver.

And certainly, the correct thing to do is to enable the power domain that a
controller is part of, before attempting to change the rate for one of its
clocks. So the patch looks good to me.

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


  reply	other threads:[~2023-02-13 12:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 17:05 [PATCH 0/4] drm/vc4: hdmi: Firmware clocks cleanup Maxime Ripard
2023-01-26 17:05 ` Maxime Ripard
2023-01-26 17:05 ` [PATCH 1/4] drm/vc4: hdmi: Replace hardcoded value by define Maxime Ripard
2023-01-26 17:05   ` Maxime Ripard
2023-02-13 12:43   ` Javier Martinez Canillas
2023-02-13 12:43     ` Javier Martinez Canillas
2023-01-26 17:05 ` [PATCH 2/4] drm/vc4: hdmi: Enable power domain before setting minimum Maxime Ripard
2023-01-26 17:05   ` Maxime Ripard
2023-02-13 12:59   ` Javier Martinez Canillas [this message]
2023-02-13 12:59     ` Javier Martinez Canillas
2023-01-26 17:05 ` [PATCH 3/4] Revert "drm/vc4: hdmi: Fix HSM clock too low on Pi4" Maxime Ripard
2023-01-26 17:05   ` Maxime Ripard
2023-02-13 13:04   ` Javier Martinez Canillas
2023-02-13 13:04     ` Javier Martinez Canillas
2023-01-26 17:05 ` [PATCH 4/4] Revert "drm/vc4: hdmi: Enforce the minimum rate at runtime_resume" Maxime Ripard
2023-01-26 17:05   ` Maxime Ripard
2023-02-13 13:05   ` Javier Martinez Canillas
2023-02-13 13:05     ` Javier Martinez Canillas
2023-02-16  9:27 ` [PATCH 0/4] drm/vc4: hdmi: Firmware clocks cleanup Maxime Ripard
2023-02-16  9:27   ` Maxime Ripard

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=d6b158ff-382c-c659-04c8-930b2681e8d6@redhat.com \
    --to=javierm@redhat.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime@cerno.tech \
    --cc=mripard@kernel.org \
    --cc=tzimmermann@suse.de \
    /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.