Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4172638rwb; Mon, 21 Nov 2022 04:45:43 -0800 (PST) X-Google-Smtp-Source: AA0mqf6iKqvCFptMmdiHiAIeoq3zk6GB4MA/P8tuNmS3QSoMhYQkYp4gWMDC6f5YzPbvnsigXiAy X-Received: by 2002:a17:906:86c9:b0:78d:9324:6f18 with SMTP id j9-20020a17090686c900b0078d93246f18mr15564416ejy.664.1669034743166; Mon, 21 Nov 2022 04:45:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669034743; cv=none; d=google.com; s=arc-20160816; b=RcK5BkBb32Yo/lV8u68kM4phCy3J9HaC2lvujdAC/yXYZbqpqVJnlEYvLLNSDBTfG3 JIIlxbBVKqzT2G3MK63pdWgicPz081XLtZd22q1YJKbSMypAHWy2sRr2Gi4gpV9+9LH8 p0WiKxLrzP0iAqkOWFh1kwLL/5yRi/dlVjXtnF5C21H9PNNTffRQ7GaDaJYimQ8Y2/xF iC2xQcni4Lzxc2j8Ol8QCYcmR6LxSLqu5+jJ+XdhGjuycTFaQ/fMkEOiOMJqllQMbVGE Vp9l7QDSmQ4y6weAbuuvPZNXYuUZXBwp/VoEyAuWgxCJ1yKC5pl7lpDIgXPV/XlFoJ82 uZpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=zmBIpBwmGEB6+X5TtFNnIkbSdMUzu9DpYDUSRNirV6w=; b=IiwTubbpJuTM2Bk/CbAFh/TgTGuuJBP9vmTXJiizp4Prfy592tChVzP30FvIAgTU5T /4d23n70fVeVDaq4fPPOfK6l5iqshMW90yYRgP36MxWXX7Zx6zf8qDKU84EjDv7a7H53 r8M4A/JLnSspoM1zHUiNn+rm8OdMJAGwD2MN1Vq7wl5lWH4S4RfVfL3PUz3qsTzDpdt5 eAb3nnqCzAgjjJUDdEGdWElKckd12FW7W5Bt9j0PcHHyckhO7yb2vKnTDIRxfeWm3sFh 5ushddgQlY5nHT/j8CVUIehQme3qaNUKU+4bmScKlhak+T+hazpr5kmBEMnSJExEa4T7 HlNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=LSI7kAIw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l4-20020aa7d944000000b00467e2dc8d13si3280376eds.94.2022.11.21.04.45.18; Mon, 21 Nov 2022 04:45:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=LSI7kAIw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231386AbiKUMBL (ORCPT + 93 others); Mon, 21 Nov 2022 07:01:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231415AbiKUMBJ (ORCPT ); Mon, 21 Nov 2022 07:01:09 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7908217E2C for ; Mon, 21 Nov 2022 04:01:06 -0800 (PST) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 911C56601DEA; Mon, 21 Nov 2022 12:01:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1669032065; bh=NG4/5IZyY1SjaNQIs07uOPi5SzQEZBoAwoUix43JLXs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LSI7kAIwIu50oezePtCjqfxfuIvevXPcNXKDyuI9AY4GQ8FgHigIbZJ1+JVWGceT+ 3goVHzSb8N52oAF7e7DhODUzHfmnP2XppXjR89IBL8Ybcv0t+JYz7qsMqhmNFfABai AUtnJWjme+rJP3J2McXymBiFYY0xsn2cSfcOKA9Q1aETredpw0XVbiXRMkl+0r00wK jKO/YgKA01vBiNS8+Viihnr2hFAeDmuUYjOsQ+k+tKz3/q7Xwg/JB6PbrAZm2ObnDw bIfp3i/vm2PQ9g7E+s1ToJgeS8QUJES+HkL8WsF4hcGEdJX+SfpHFrXF1U9+hN9i/j fenV9NvXxM0Cw== Message-ID: Date: Mon, 21 Nov 2022 13:01:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [RESEND PATCH v3] soc: mediatek: Introduce mediatek-regulator-coupler driver Content-Language: en-US To: Matthias Brugger Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, wenst@chromium.org, alyssa.rosenzweig@collabora.com, nfraprado@collabora.com, dmitry.osipenko@collabora.com References: <20221006115816.66853-1-angelogioacchino.delregno@collabora.com> From: AngeloGioacchino Del Regno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 21/11/22 12:44, Matthias Brugger ha scritto: > > > On 06/10/2022 13:58, AngeloGioacchino Del Regno wrote: >> This driver currently deals with GPU-SRAM regulator coupling, ensuring >> that the SRAM voltage is always between a specific range of distance to >> the GPU voltage, depending on the SoC, necessary in order to achieve >> system stability across the full range of supported GPU frequencies. >> >> Signed-off-by: AngeloGioacchino Del Regno >> Reviewed-by: Dmitry Osipenko >> --- >> >> This driver was successfully tested for more than 3 months. >> GPU DVFS works correctly with no stability issues. >> >> Changes in RESEND,v3: >>   Rebased over next-20221005 >> >> Changes in v3: >>   - Added braces to else-if branch >> >> Changes in v2: >>   - Added check for n_coupled >>   - Added check for vgpu to enforce attaching to vgpu<->sram coupling only >> >> Context: >> This driver is the last of the pieces of a bigger puzzle, aiming to finally >> enable Dynamic Voltage/Frequency Scaling for Mali GPUs found on MediaTek >> SoCs on the fully open source graphics stack (Panfrost driver). >> >> No devicetree bindings are provided because this does not require any >> driver-specific binding at all. >> >> Last but not least: it was chosen to have this driver enabled for >> ( ARCH_MEDIATEK && REGULATOR ) without really giving a free configuration >> choice because, once the DVFS mechanism will be fully working, using one >> of the listed MediaTek SoCs *without* this coupling mechanism *will* lead >> to unstabilities and system crashes. >> For COMPILE_TEST, choice is given for obvious reasons. >> >>   drivers/soc/mediatek/Kconfig                 |   5 + >>   drivers/soc/mediatek/Makefile                |   1 + >>   drivers/soc/mediatek/mtk-regulator-coupler.c | 159 +++++++++++++++++++ >>   3 files changed, 165 insertions(+) >>   create mode 100644 drivers/soc/mediatek/mtk-regulator-coupler.c >> >> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig >> index 40d0cc600cae..30b5afc0e51d 100644 >> --- a/drivers/soc/mediatek/Kconfig >> +++ b/drivers/soc/mediatek/Kconfig >> @@ -44,6 +44,11 @@ config MTK_PMIC_WRAP >>         on different MediaTek SoCs. The PMIC wrapper is a proprietary >>         hardware to connect the PMIC. >> +config MTK_REGULATOR_COUPLER >> +    bool "MediaTek SoC Regulator Coupler" if COMPILE_TEST >> +    default ARCH_MEDIATEK >> +    depends on REGULATOR >> + >>   config MTK_SCPSYS >>       bool "MediaTek SCPSYS Support" >>       default ARCH_MEDIATEK >> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile >> index 0e9e703c931a..8c0ddacbcde8 100644 >> --- a/drivers/soc/mediatek/Makefile >> +++ b/drivers/soc/mediatek/Makefile >> @@ -3,6 +3,7 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o >>   obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o >>   obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o >>   obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o >> +obj-$(CONFIG_MTK_REGULATOR_COUPLER) += mtk-regulator-coupler.o >>   obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o >>   obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o >>   obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o >> diff --git a/drivers/soc/mediatek/mtk-regulator-coupler.c >> b/drivers/soc/mediatek/mtk-regulator-coupler.c >> new file mode 100644 >> index 000000000000..ad2ed42aa697 >> --- /dev/null >> +++ b/drivers/soc/mediatek/mtk-regulator-coupler.c >> @@ -0,0 +1,159 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Voltage regulators coupler for MediaTek SoCs >> + * >> + * Copyright (C) 2022 Collabora, Ltd. >> + * Author: AngeloGioacchino Del Regno >> + */ >> + >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define to_mediatek_coupler(x)    container_of(x, struct >> mediatek_regulator_coupler, coupler) >> + >> +struct mediatek_regulator_coupler { >> +    struct regulator_coupler coupler; >> +    struct regulator_dev *vsram_rdev; >> +}; >> + >> +/* >> + * We currently support only couples of not more than two vregs and >> + * modify the vsram voltage only when changing voltage of vgpu. >> + * >> + * This function is limited to the GPU<->SRAM voltages relationships. >> + */ >> +static int mediatek_regulator_balance_voltage(struct regulator_coupler *coupler, >> +                          struct regulator_dev *rdev, >> +                          suspend_state_t state) >> +{ >> +    struct mediatek_regulator_coupler *mrc = to_mediatek_coupler(coupler); >> +    int max_spread = rdev->constraints->max_spread[0]; >> +    int vsram_min_uV = mrc->vsram_rdev->constraints->min_uV; >> +    int vsram_max_uV = mrc->vsram_rdev->constraints->max_uV; >> +    int vsram_target_min_uV, vsram_target_max_uV; >> +    int min_uV = 0; >> +    int max_uV = INT_MAX; >> +    int ret; >> + >> +    /* >> +     * If the target device is on, setting the SRAM voltage directly >> +     * is not supported as it scales through its coupled supply voltage. >> +     * >> +     * An exception is made in case the use_count is zero: this means >> +     * that this is the first time we power up the SRAM regulator, which >> +     * implies that the target device has yet to perform initialization >> +     * and setting a voltage at that time is harmless. >> +     */ >> +    if (rdev == mrc->vsram_rdev) { >> +        if (rdev->use_count == 0) >> +            return regulator_do_balance_voltage(rdev, state, true); >> + >> +        return -EPERM; >> +    } >> + >> +    ret = regulator_check_consumers(rdev, &min_uV, &max_uV, state); >> +    if (ret < 0) >> +        return ret; >> + >> +    if (min_uV == 0) { >> +        ret = regulator_get_voltage_rdev(rdev); >> +        if (ret < 0) >> +            return ret; >> +        min_uV = ret; >> +    } >> + >> +    ret = regulator_check_voltage(rdev, &min_uV, &max_uV); >> +    if (ret < 0) >> +        return ret; >> + >> +    /* >> +     * If we're asked to set a voltage less than VSRAM min_uV, set >> +     * the minimum allowed voltage on VSRAM, as in this case it is >> +     * safe to ignore the max_spread parameter. >> +     */ >> +    vsram_target_min_uV = max(vsram_min_uV, min_uV + max_spread); >> +    vsram_target_max_uV = min(vsram_max_uV, vsram_target_min_uV + max_spread); >> + >> +    /* Make sure we're not out of range */ >> +    vsram_target_min_uV = min(vsram_target_min_uV, vsram_max_uV); >> + >> +    pr_debug("Setting voltage %d-%duV on %s (minuV %d)\n", >> +         vsram_target_min_uV, vsram_target_max_uV, >> +         rdev_get_name(mrc->vsram_rdev), min_uV); >> + >> +    ret = regulator_set_voltage_rdev(mrc->vsram_rdev, vsram_target_min_uV, >> +                     vsram_target_max_uV, state); >> +    if (ret) >> +        return ret; >> + >> +    /* The sram voltage is now balanced: update the target vreg voltage */ >> +    return regulator_do_balance_voltage(rdev, state, true); >> +} >> + >> +static int mediatek_regulator_attach(struct regulator_coupler *coupler, >> +                     struct regulator_dev *rdev) >> +{ >> +    struct mediatek_regulator_coupler *mrc = to_mediatek_coupler(coupler); >> +    const char *rdev_name = rdev_get_name(rdev); >> + >> +    /* >> +     * If we're getting a coupling of more than two regulators here and >> +     * this means that this is surely not a GPU<->SRAM couple: in that >> +     * case, we may want to use another coupler implementation, if any, >> +     * or the generic one: the regulator core will keep walking through >> +     * the list of couplers when any .attach_regulator() cb returns 1. >> +     */ >> +    if (rdev->coupling_desc.n_coupled > 2) >> +        return 1; >> + >> +    if (strstr(rdev_name, "sram")) { > > My understanding is, that we have to have either a DT node with regulator-name = > "sram" property to pollute rdev->constraints->name or some regulator_desc->name > populated in the drivers/regulator/mt*.c > No, it's not trying to find a regulator named "sram", but any regulator that *contains* the "sram" string in its name, but checks only regulators that are coupled to others. This is the same for the "Vgpu" / "vgpu". Example: Regulator A, coupled to Regulator B. Regulator A name = "Vgpu" or "vgpu", or *vgpu*, or *Vgpu* (name must contain either Vgpu or vgpu) Regulator B name = "vsram" or "sram_gpu" or *sram* (name must contain "sram"). mrc->vsram_rdev = rdev rdev == our Regulator B. We hence return 0 to the coupling API: this will produce the effect of making it use this driver's .balance_voltage() callback instead of the generic one on vgpu<->vsram. > I wasn't able to find either of this, so I wonder how this is supposed to work. > Please provide pointers to a working and complete implementation of this, so that > I'm able to judge what is going on and if the approach is the correct one. > > I tried to figure out using mt8195-tracking-master-rolling That's the right branch. Let's take MT8192 Asurada as an example of how this works.... `mt6359_vsram_others_ldo_reg´ is the SRAM regulator for the GPU: https://gitlab.collabora.com/google/chromeos-kernel/-/blob/mt8195-tracking-master-rolling/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi#L551 `mt6359_vsram_others_ldo_reg` regulator-name = "vsram_others"; ^^^^ Contains "sram", and this regulator is also regulator-coupled-with = <&mt6315_7_vbuck1>; `mt6315_7_vbuck1` regulator-name = "Vgpu"; ^^^^ Contains "Vgpu", and this regulator is also regulator-coupled-with = <&mt6359_vsram_others_ldo_reg>; That's how the coupling works in this case. Now, looking at case exclusions: In MT8192 Asurada (or, actually, mt6359.dtsi) we have other regulators that do actually contain "sram" in their name, like "vsram_proc1" and "vsram_others_sshub". These regulators will be ignored, as they are *not* coupled with Vgpu. What this driver currently does in this regard is: 1. Regulator attach is called only on *coupled* regulators, not on the others 2. If the regulator contains name "vgpu" or "Vgpu" or "sram" we're good, otherwise we don't attach the balance_voltage logic of this driver to the unmatched regulators. Does this explanation clarify your doubts? Regards, Angelo