linux-kernel - Re: [PATCH v10 3/4] drm/panfrost: devfreq: Disable devfreq when num

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <495a0ad3-ef01-d4b8-eb1f-e70d55fd7ddf@arm.com>
Date:   Thu, 14 Jan 2021 15:10:25 +0000
From:   Steven Price <steven.price@....com>
To:     Nicolas Boichat <drinkcat@...omium.org>,
        Rob Herring <robh@...nel.org>,
        Alyssa Rosenzweig <alyssa.rosenzweig@...labora.com>
Cc:     Tomeu Vizoso <tomeu.vizoso@...labora.com>, fshao@...omium.org,
        boris.brezillon@...labora.com, hsinyi@...omium.org,
        hoegsberg@...omium.org, Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 3/4] drm/panfrost: devfreq: Disable devfreq when
 num_supplies > 1

On 13/01/2021 06:07, Nicolas Boichat wrote:
> GPUs with more than a single regulator (e.g. G72 on MT8183) will
> require platform-specific handling for devfreq, for 2 reasons:
>   1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator)
>      does not support multiple regulators, so we'll need custom
>      handlers.
>   2. Generally, platforms with 2 regulators have platform-specific
>      constraints on how the voltages should be set (e.g.
>      minimum/maximum voltage difference between them), so we
>      should not just create generic handlers that simply
>      change the voltages without taking care of those constraints.
> 
> Disable devfreq for now on those GPUs.
> 
> Signed-off-by: Nicolas Boichat <drinkcat@...omium.org>
> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>

Thanks for the clarification in the commit message.

Reviewed-by: Steven Price <steven.price@....com>

> ---
> 
> (no changes since v9)
> 
> Changes in v9:
>   - Explain why devfreq needs to be disabled for GPUs with >1
>     regulators.
> 
> Changes in v8:
>   - Use DRM_DEV_INFO instead of ERROR
> 
> Changes in v7:
>   - Fix GPU ID in commit message
> 
> Changes in v6:
>   - New change
> 
>   drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index f44d28fad085..812cfecdee3b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -92,6 +92,15 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
>   	struct thermal_cooling_device *cooling;
>   	struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
>   
> +	if (pfdev->comp->num_supplies > 1) {
> +		/*
> +		 * GPUs with more than 1 supply require platform-specific handling:
> +		 * continue without devfreq
> +		 */
> +		DRM_DEV_INFO(dev, "More than 1 supply is not supported yet\n");
> +		return 0;
> +	}
> +
>   	opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
>   					      pfdev->comp->num_supplies);
>   	if (IS_ERR(opp_table)) {
>