From nobody Sat Sep 21 22:41:51 2024 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D79CAC433EF for ; Tue, 28 Jun 2022 11:02:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239520AbiF1LCD (ORCPT ); Tue, 28 Jun 2022 07:02:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345187AbiF1LBf (ORCPT ); Tue, 28 Jun 2022 07:01:35 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABA082F39A for ; Tue, 28 Jun 2022 04:01:34 -0700 (PDT) Received: from IcarusMOD.eternityproject.eu (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 EB9466601854; Tue, 28 Jun 2022 12:01:32 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1656414093; bh=sDqfOcIWii00kAS2BwVN4xr77/6lZhUs1JWOAvF/S5E=; h=From:To:Cc:Subject:Date:From; b=aQxRVg4VxNUJj6ANehygUP4c0YhpEqdYvvPrEt557n3gs/NZSxl5CCHFR8l00W9JL /w6zZxVm4fY2FI1ZXDyoYnjftng++pRlgZx92GvmnEQtvdCC8dKK73HTnWVu2jKoNB SJGap7e+k/t+zl9RT85T3Co5bs+Rsqwz3fUdWE1D9geGWmtyVEC68zdYTCDzugNCA2 3oUEVAC2h0rBYLr3kVI2Z20291BobpmX0OQ1SX1WcI8wkf6My+X80BcnTDlA8SDAKL 9+875TDCxdjBQhBXW5NKxo3lHsDeZTlqAQasg9dZ9Y7hG+6b0ar9p5dFr+tKOeKcGR GoWFzTHkkQeEg== From: AngeloGioacchino Del Regno To: matthias.bgg@gmail.com 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, digetx@gmail.com, AngeloGioacchino Del Regno Subject: [PATCH v2] soc: mediatek: Introduce mediatek-regulator-coupler driver Date: Tue, 28 Jun 2022 13:01:28 +0200 Message-Id: <20220628110128.64137-1-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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 --- Changes in v2: - Added check for n_coupled - Added check for vgpu to enforce attaching to vgpu<->sram coupling only Context: This driver is one 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 | 158 +++++++++++++++++++ 3 files changed, 164 insertions(+) create mode 100644 drivers/soc/mediatek/mtk-regulator-coupler.c diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig index 3c3eedea35f7..cfa24fc6287b 100644 --- a/drivers/soc/mediatek/Kconfig +++ b/drivers/soc/mediatek/Kconfig @@ -43,6 +43,11 @@ config MTK_PMIC_WRAP on different MediaTek SoCs. The PMIC wrapper is a proprietary hardware to connect the PMIC. =20 +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) +=3D mtk-cmdq-helper.o obj-$(CONFIG_MTK_DEVAPC) +=3D mtk-devapc.o obj-$(CONFIG_MTK_INFRACFG) +=3D mtk-infracfg.o obj-$(CONFIG_MTK_PMIC_WRAP) +=3D mtk-pmic-wrap.o +obj-$(CONFIG_MTK_REGULATOR_COUPLER) +=3D mtk-regulator-coupler.o obj-$(CONFIG_MTK_SCPSYS) +=3D mtk-scpsys.o obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) +=3D mtk-pm-domains.o obj-$(CONFIG_MTK_MMSYS) +=3D mtk-mmsys.o diff --git a/drivers/soc/mediatek/mtk-regulator-coupler.c b/drivers/soc/med= iatek/mtk-regulator-coupler.c new file mode 100644 index 000000000000..dfec0d21d439 --- /dev/null +++ b/drivers/soc/mediatek/mtk-regulator-coupler.c @@ -0,0 +1,158 @@ +// 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_c= oupler, 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 *co= upler, + struct regulator_dev *rdev, + suspend_state_t state) +{ + struct mediatek_regulator_coupler *mrc =3D to_mediatek_coupler(coupler); + int max_spread =3D rdev->constraints->max_spread[0]; + int vsram_min_uV =3D mrc->vsram_rdev->constraints->min_uV; + int vsram_max_uV =3D mrc->vsram_rdev->constraints->max_uV; + int vsram_target_min_uV, vsram_target_max_uV; + int min_uV =3D 0; + int max_uV =3D 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 =3D=3D mrc->vsram_rdev) { + if (rdev->use_count =3D=3D 0) + return regulator_do_balance_voltage(rdev, state, true); + + return -EPERM; + } + + ret =3D regulator_check_consumers(rdev, &min_uV, &max_uV, state); + if (ret < 0) + return ret; + + if (min_uV =3D=3D 0) { + ret =3D regulator_get_voltage_rdev(rdev); + if (ret < 0) + return ret; + min_uV =3D ret; + } + + ret =3D 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 =3D max(vsram_min_uV, min_uV + max_spread); + vsram_target_max_uV =3D min(vsram_max_uV, vsram_target_min_uV + max_sprea= d); + + /* Make sure we're not out of range */ + vsram_target_min_uV =3D 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 =3D 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 =3D to_mediatek_coupler(coupler); + const char *rdev_name =3D 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")) { + if (mrc->vsram_rdev) + return -EINVAL; + mrc->vsram_rdev =3D rdev; + } else if (!strstr(rdev_name, "vgpu") && !strstr(rdev_name, "Vgpu")) + return 1; + + return 0; +} + +static int mediatek_regulator_detach(struct regulator_coupler *coupler, + struct regulator_dev *rdev) +{ + struct mediatek_regulator_coupler *mrc =3D to_mediatek_coupler(coupler); + + if (rdev =3D=3D mrc->vsram_rdev) + mrc->vsram_rdev =3D NULL; + + return 0; +} + +static struct mediatek_regulator_coupler mediatek_coupler =3D { + .coupler =3D { + .attach_regulator =3D mediatek_regulator_attach, + .detach_regulator =3D mediatek_regulator_detach, + .balance_voltage =3D mediatek_regulator_balance_voltage, + }, +}; + +static int mediatek_regulator_coupler_init(void) +{ + if (!of_machine_is_compatible("mediatek,mt8183") && + !of_machine_is_compatible("mediatek,mt8186") && + !of_machine_is_compatible("mediatek,mt8192")) + return 0; + + return regulator_coupler_register(&mediatek_coupler.coupler); +} +arch_initcall(mediatek_regulator_coupler_init); + +MODULE_AUTHOR("AngeloGioacchino Del Regno "); +MODULE_DESCRIPTION("MediaTek Regulator Coupler driver"); +MODULE_LICENSE("GPL"); --=20 2.35.1