From nobody Thu Apr 9 18:46:42 2026 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2E3A37E2E6 for ; Fri, 6 Mar 2026 10:30:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772793007; cv=none; b=HGhE2M+o3N2ICQ7nlXAE1RXQv4Ico96ur3DTKSbqUb/fM1OK+5agQDg/7sFAf6FErFuKSx6crMBVH8jJLuM03zsyGNoM3QJi0jIiQ2KZE6SWGa94t8Kn0SHjkh1pG9mc1v0wJbbWUlV7siQD+HJCarniBHuc8lOH9uWcdIJKeDA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772793007; c=relaxed/simple; bh=0U4HtqSeHlGrJn9AJ7ErQ0CtQcraLAhfSS8YefF1XM0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=hHfucooCpd3j6NmpWD5F7i8X1fHXq50t+A1wnFJ7/rb9Q0KZlfx+RxaNm3qJrM4AD7NrTgzhAay0kEP5+DVo5tyKLeJWTiAVPx56rUvksuEui4lmXDjznXaE0sYIdl2RMGXDvSYsngQYEEol9De3y+q5ntSlORodn+F48dCgKTI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=qZE9N9f1; arc=none smtp.client-ip=209.85.208.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="qZE9N9f1" Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-661568ce781so2482078a12.0 for ; Fri, 06 Mar 2026 02:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1772792999; x=1773397799; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=VJGr1pYRHm/J99djTiuPZ983bNSUstvUPO/CtwCwtA8=; b=qZE9N9f1CMPnzrFnwCxX3bekxlpg45NjSj3kEadC3TDB7UoZbuOQ5tbtjqJ2n0pUR/ UcsvstpwHKs8eYoJ5L1v9CHgETcB5OoVty2Rv/ohavJOxIWoptEJOWEkmIIxTGy1Zd03 mhqHc92bYAN3L2mgVu39a4UMWVcscuBTgruaDwS3Yr7ZtdIX5z/uJISMfgI3Hw4rTi4+ T2Bqrbvn1aBR9m2yTusw6+0B7mteEj3veP9p9vO7P4fpep8oqRmeYZjr6lXNEk7npYN7 sr+BqmGespubQ2deW7ALDmy69mq157qJFn2By4sInNAFdCVxyduBi5p6GLUmVlYX6sct peWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772792999; x=1773397799; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=VJGr1pYRHm/J99djTiuPZ983bNSUstvUPO/CtwCwtA8=; b=Cdi8sZ5w9cy2aYSF/0myEiOUzNM/pxJCxSlJmc0Ed2/VnJTyjK1O9gUKR8betSxp35 TjS3/TVs/M6Q6ZfHXw0Vwe7gyi4gR4e0anEJsgzrc3FY5JcewYoSWXfvVXKSKNdJOb8L S6tAaRNv2p7RGc1NE4iGKaHdX0600wISefnx8sZRP9lQ8HgxFj1tiSWFYHiFdCTlT8Tw /I+L20AMHShMVDkAd5vSUilnL3ZPSdICK8coszok6TqZCnETfa4edzilyrHozHD5qnk/ h2Ql1Bf9ykusBy8+0sjmRbdIJZ0u0u4mCwmhFN0cXlufeyewhDWuIqvq9kg6q1s47X3W zVdg== X-Forwarded-Encrypted: i=1; AJvYcCUbZhezsH/lXw7ZqLPCimL0n8qZdW4bB9/QyddZCWhpETCRaXihZ7bCN+AcYR9JbARmQ+3eUkePgfJLd78=@vger.kernel.org X-Gm-Message-State: AOJu0YwCyuzQfejz8MMfcid1sq9WT586ogDj+yz2V3J0mXzWFGKoe5w2 xjD+Tj5BGfyKky/ca59KJ7uWtJm8AR2rt/PsV0AGApbgBEKQoF5slWbhWW9izUKtnOg= X-Gm-Gg: ATEYQzwMivdpDVGgaUqTVVEs7fLfFvrJBFhn0dmStiIws1kqiv1Xob6dI31Vr9B754M UrxL0s14+9CNQDZEdkDJNG67HhMsY4Camc1f4TRefCXSFM5b68DrVqibbkGMv5fwvD/VLboCIsX hkHZwSbrNimiS1gUz3452As1q1Q+vz9KQRHdnBKtt+8MPqZs07KeOhQw0JSE81+HfOQ1Q3U+70U olMmCr0V0jbHX4mAZV13gd0zsTJKkIH6Ns7qJaTXT0NjLBiSeOIglEW98u4l/G/ShEQNRERtHio 55rTrvlgNm6mExN7SGNry+mETx7BKf134b5De7ve8EZuhbQplODl++ERSEoa04tJmHLIYFNRfxf niKLemgjTbzOsr0zwYbu3BNH9B6oyOQp4aPfmq4fMi0MunFqAB8FlGyps3L3v5peJ3aBNSheK/j uaNfBbBRK1aK9EI1IrKIolSU/mAvKp5QbmZzbfEgjj/zrPVLSfQEmmL+l/dWd9OLuVBVcXN2kB7 mFBXtdtCKO8wXY= X-Received: by 2002:a17:907:6e9e:b0:b94:29e:a94c with SMTP id a640c23a62f3a-b942dbdc1femr96088266b.15.1772792998840; Fri, 06 Mar 2026 02:29:58 -0800 (PST) Received: from puffmais2.c.googlers.com (221.210.91.34.bc.googleusercontent.com. [34.91.210.221]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b942ef8c95csm42907266b.21.2026.03.06.02.29.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 02:29:58 -0800 (PST) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Fri, 06 Mar 2026 10:29:58 +0000 Subject: [PATCH v7 07/10] pmdomain: samsung: add support for google,gs101-pd Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260306-gs101-pd-v7-7-03f7c7965ba5@linaro.org> References: <20260306-gs101-pd-v7-0-03f7c7965ba5@linaro.org> In-Reply-To: <20260306-gs101-pd-v7-0-03f7c7965ba5@linaro.org> To: Krzysztof Kozlowski , Alim Akhtar , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Ulf Hansson , Liam Girdwood , Mark Brown Cc: Peter Griffin , Tudor Ambarus , Juan Yescas , Will McVicker , kernel-team@android.com, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, =?utf-8?q?Andr=C3=A9_Draszik?= , Marek Szyprowski X-Mailer: b4 0.14.3 On Google gs101, direct mmio register access to the PMU registers doesn't work and access must happen via a regmap created by the PMU driver instead. Add a flag to the device match data to denote this case, and obtain the regmap using the parent node in DT if true, while keeping to use the traditional direct mmio regmap otherwise. Additionally, the status is just one bit on gs101. Tested-by: Marek Szyprowski Signed-off-by: Andr=C3=A9 Draszik Reviewed-by: Peter Griffin --- v4: - add 'use_parent_regmap' flag instead of going by 'syscon' compatible in parent, as it's not a given that the parent provides a syscon- compatible regmap (it actually doesn't anymore after recent changes on gs101) I've still kept Marek's Tested-by from v3, as legacy Exynos code doesn't change. --- drivers/pmdomain/samsung/exynos-pm-domains.c | 66 +++++++++++++++++++-----= ---- 1 file changed, 46 insertions(+), 20 deletions(-) diff --git a/drivers/pmdomain/samsung/exynos-pm-domains.c b/drivers/pmdomai= n/samsung/exynos-pm-domains.c index 8df46b41f9bc..2214d9f32d59 100644 --- a/drivers/pmdomain/samsung/exynos-pm-domains.c +++ b/drivers/pmdomain/samsung/exynos-pm-domains.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -21,6 +22,7 @@ struct exynos_pm_domain_config { /* Value for LOCAL_PWR_CFG and STATUS fields for each domain */ u32 local_pwr_cfg; + bool use_parent_regmap; }; =20 /* @@ -93,8 +95,16 @@ static const struct exynos_pm_domain_config exynos5433_c= fg =3D { .local_pwr_cfg =3D 0xf, }; =20 +static const struct exynos_pm_domain_config gs101_cfg =3D { + .local_pwr_cfg =3D BIT(0), + .use_parent_regmap =3D true, +}; + static const struct of_device_id exynos_pm_domain_of_match[] =3D { { + .compatible =3D "google,gs101-pd", + .data =3D &gs101_cfg, + }, { .compatible =3D "samsung,exynos4210-pd", .data =3D &exynos4210_cfg, }, { @@ -122,17 +132,9 @@ static int exynos_pd_probe(struct platform_device *pde= v) struct of_phandle_args child, parent; struct exynos_pm_domain *pd; struct resource *res; - void __iomem *base; unsigned int val; int on, ret; =20 - struct regmap_config reg_config =3D { - .reg_bits =3D 32, - .val_bits =3D 32, - .reg_stride =3D 4, - .use_relaxed_mmio =3D true, - }; - pm_domain_cfg =3D of_device_get_match_data(dev); pd =3D devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL); if (!pd) @@ -143,25 +145,49 @@ static int exynos_pd_probe(struct platform_device *pd= ev) return -ENOMEM; =20 /* - * The resource typically points into the address space of the PMU. + * The resource typically points into the address space of the PMU and + * we have to consider two cases: + * 1) some implementations require a custom regmap (from PMU parent) + * 2) this driver might map the same addresses as the PMU driver * Therefore, avoid using devm_platform_get_and_ioremap_resource() and - * instead use platform_get_resource() and devm_ioremap() to avoid + * instead use platform_get_resource() here, and below for case 1) use + * syscon_node_to_regmap() while for case 2) use devm_ioremap() to avoid * conflicts due to address space overlap. */ res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) return dev_err_probe(dev, -ENXIO, "missing IO resources"); =20 - base =3D devm_ioremap(dev, res->start, resource_size(res)); - if (!base) - return dev_err_probe(dev, -ENOMEM, - "failed to ioremap PMU registers"); - - reg_config.max_register =3D resource_size(res) - reg_config.reg_stride; - pd->regmap =3D devm_regmap_init_mmio(dev, base, ®_config); - if (IS_ERR(pd->regmap)) - return dev_err_probe(dev, PTR_ERR(base), - "failed to init regmap"); + if (pm_domain_cfg->use_parent_regmap) { + pd->regmap =3D syscon_node_to_regmap(dev->parent->of_node); + if (IS_ERR(pd->regmap)) + return dev_err_probe(dev, PTR_ERR(pd->regmap), + "failed to acquire PMU regmap"); + + pd->configuration_reg =3D res->start; + pd->status_reg =3D res->start; + } else { + void __iomem *base; + + const struct regmap_config reg_config =3D { + .reg_bits =3D 32, + .val_bits =3D 32, + .reg_stride =3D 4, + .use_relaxed_mmio =3D true, + .max_register =3D (resource_size(res) + - reg_config.reg_stride), + }; + + base =3D devm_ioremap(dev, res->start, resource_size(res)); + if (!base) + return dev_err_probe(dev, -ENOMEM, + "failed to ioremap PMU registers"); + + pd->regmap =3D devm_regmap_init_mmio(dev, base, ®_config); + if (IS_ERR(pd->regmap)) + return dev_err_probe(dev, PTR_ERR(base), + "failed to init regmap"); + } =20 pd->pd.power_off =3D exynos_pd_power_off; pd->pd.power_on =3D exynos_pd_power_on; --=20 2.53.0.473.g4a7958ca14-goog