From nobody Mon Feb 9 17:58:34 2026 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (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 4FA1E3358C4 for ; Thu, 5 Feb 2026 21:42:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770327758; cv=none; b=YAEtHBCsOfsxtoF0JVUF9aO57b9jENQUg3YgtoEX39nbR7iumxL5MEk7RMdbw+rEVQFRTH75P5PzKX0yn1dsyOHtqfhhsguA+FdE7tq300khD0WMjsA8vXB/YqA8/Qk7PDmu43DjVdWQK1OG91Ce7rPnewwhxuIWq6DFipGQHt4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770327758; c=relaxed/simple; bh=Gh7wNCcyhCNv3CePFSJgIk8GG1EwmMyjPmTewvDCbUk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=fELPA0ueFSv0awaM3QRl3zB5HupnIhCcP3K7hBr7jb3mLtOwepSOS8qOmHK3+Jwr5cL9e40cbdVZ8dFask5ElDwaJm7/YLXDwGpidPSqzlsEmNT7z99Bz11+V5K28D+nWowjSIScYNAAICBuFM6BhVffcfr0PSkPQKeSIs7Rfw4= 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=T/dh08di; arc=none smtp.client-ip=209.85.218.42 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="T/dh08di" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-b885a18f620so225969166b.3 for ; Thu, 05 Feb 2026 13:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1770327757; x=1770932557; 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=9l8kLhxgu+f7eSuFAPa71vI1PB55KyeTUUj2gGy7pqY=; b=T/dh08di8Ui7niVytZhGBi6n4He4wmaXUVd4MGBHZQqIAvhjLRwYY0puQiCYbdIGYJ Kz1YHCq4DBSq6XbM6BOG+hZBOsN72F2uxlE5xK0vJBcwij+msZYCgtOPy2NxKktrbX38 Fz6q7SLWWy3ulBer/FGgAT73bScj+fgV0coZx9NFe4DQlXihpQW6YLHg49qQIdhX8LU2 VAxXN+mwr0Ruot+Wa4stlf9yCD13dgZ3V2q/BH2y9LxjC4J9ufmemKahVxtbpt3N6uwp UXlC3OkkLFVpr5pOPYv/DOSJSk+2UJHQiD8ARnUitmllpXEPMVmxwpvab8ZJ7Q4lTUBP X5AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770327757; x=1770932557; 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=9l8kLhxgu+f7eSuFAPa71vI1PB55KyeTUUj2gGy7pqY=; b=JARnp4eDeTQvfJQxgXnPpLTXtzSzWDd04fulJCVrEvWcMY6yWf/8n5PWgemjw+hG10 pKj6JeUP0Mju7REAZrfvgAEDirjMKckHlwORFhasZWJkbCj5fpHl+8qF6Y/uNlIRh51Q U4/XomE5QlJnHIHyzIgL5IFwQuLf2sCcPk+iwj51HbWrvcwnKQA9sZQ5rGCXkfWC7PdB cK4Xz8rR4GV2IiHGtBaIQ+2SndGBapFF7MdBhbXyvPwtQ5Z4KvmgVv/VlPnX+qqXXMGt zcFuv9o0rXR9FBXntNFFLFUC+PI8fqjDlZ9FgUJBPNULMZx5sNzkeCRLkvzJTR/kpxJs zZPA== X-Forwarded-Encrypted: i=1; AJvYcCVBVLuVOM3vLCsalZffYx8eYh+nDlk/tuaazRXoZVmcVqJMkASIxvDqhFYYP++vKMWve+e4NFN5qwT5xMI=@vger.kernel.org X-Gm-Message-State: AOJu0YxmeAimai47TotuaMPYDOCujixC0zfcSKdofZgUB5rOzg4UJx1a DXrOR7x18cOpUxrLlJf1lP3cR93jBw/XSoSf0b5+oZcvK2Yi1dQACX7Kg7Yd5WOiUGQ= X-Gm-Gg: AZuq6aILNmZFg22w6VqJ/ros+B35JnfUqSJohk58F1VrfXs8Wy3ZckSmONb5INEbtOM JYO2eGfN4M6ZRKdF1YoVIeYew0ck+OZdG6YvO6HFxMdltAzQ02L7VdJJqc1YEQBmNUMf757PUb1 dWO053TGJ3vhijl75nFXwv8UEqTWUPeaUhLqfdocIp5z2WNF8OusLEkWWJXrSmPRdbij7i61kp6 ji6dWslEdLKd9mAx3891K8Eiaqs7DjuyT35gEwTVjKk6ahmPhXwdJ2/JKWpL+j82ye4UJKADhUo PInDqRrE/DmeFojbXAfbIjukbZt+Ms9fPhYYi43Xk/OGOxZBQwIvAj3mPY6jqpkSTB97SqPdWJA 1s3YN2aej0mupil94455zKAXnZcMZkHe5fARkDZlZ46hGVLdUOWYHgAGvH98WodT95cc5GoHjrH qctKeRSdpLgTToyQu1s+T5YFGU/fHpRsmb5M9rW7PLVA6e9HvhFVRjHnlb4NloWUXEQxhKLI+7h RMhCQ== X-Received: by 2002:a17:907:868f:b0:b88:6542:868e with SMTP id a640c23a62f3a-b8edf11f3ecmr24389666b.8.1770327756743; Thu, 05 Feb 2026 13:42:36 -0800 (PST) Received: from puffmais2.c.googlers.com (244.175.141.34.bc.googleusercontent.com. [34.141.175.244]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8eda7a0074sm21859966b.18.2026.02.05.13.42.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 13:42:36 -0800 (PST) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Thu, 05 Feb 2026 21:42:35 +0000 Subject: [PATCH v5 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: <20260205-gs101-pd-v5-7-ede49cdb57a6@linaro.org> References: <20260205-gs101-pd-v5-0-ede49cdb57a6@linaro.org> In-Reply-To: <20260205-gs101-pd-v5-0-ede49cdb57a6@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.2 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 --- 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 8df46b41f9bc8f0b2a03300169a4b52457faaf4d..2214d9f32d5967b60e84f68f4e9= 9a725d66a39eb 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.rc2.204.g2597b5adb4-goog