From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Chia-I Wu <olvaffe@gmail.com>
Cc: AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Boris Brezillon <boris.brezillon@collabora.com>,
Jassi Brar <jassisinghbrar@gmail.com>,
Chen-Yu Tsai <wenst@chromium.org>,
Steven Price <steven.price@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
kernel@collabora.com, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-hardening@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics
Date: Mon, 06 Oct 2025 13:40:35 +0200 [thread overview]
Message-ID: <2323923.iZASKD2KPV@workhorse> (raw)
In-Reply-To: <8586490.T7Z3S40VBb@workhorse>
On Monday, 6 October 2025 12:58:55 Central European Summer Time Nicolas Frattaroli wrote:
> On Friday, 3 October 2025 23:41:16 Central European Summer Time Chia-I Wu wrote:
> > On Fri, Oct 3, 2025 at 1:16 PM Nicolas Frattaroli
> > <nicolas.frattaroli@collabora.com> wrote:
> > >
> > > Various MediaTek SoCs use GPU integration silicon named "MFlexGraphics"
> > > by MediaTek. On the MT8196 and MT6991 SoCs, interacting with this
> > > integration silicon is required to power on the GPU.
> > >
> > > This glue silicon is in the form of an embedded microcontroller running
> > > special-purpose firmware, which autonomously adjusts clocks and
> > > regulators.
> > >
> > > Implement a driver, modelled as a pmdomain driver with a
> > > set_performance_state operation, to support these SoCs.
> [...]
> > > +static int mtk_mfg_probe(struct platform_device *pdev)
> > > +{
> > > + struct device_node *shmem __free(device_node);
> > > + struct mtk_mfg *mfg;
> > > + struct device *dev = &pdev->dev;
> > > + const struct mtk_mfg_variant *data = of_device_get_match_data(dev);
> > > + struct resource res;
> > > + int ret, i;
> > > +
> > > + mfg = devm_kzalloc(dev, sizeof(*mfg), GFP_KERNEL);
> > > + if (!mfg)
> > > + return -ENOMEM;
> > > +
> > > + mfg->pdev = pdev;
> > > + mfg->variant = data;
> > > +
> > > + dev_set_drvdata(dev, mfg);
> > > +
> > > + mfg->gpr = devm_platform_ioremap_resource(pdev, 0);
> > > + if (IS_ERR(mfg->gpr))
> > > + return dev_err_probe(dev, PTR_ERR(mfg->gpr),
> > > + "Couldn't retrieve GPR MMIO registers\n");
> > > +
> > > + mfg->rpc = devm_platform_ioremap_resource(pdev, 1);
> > > + if (IS_ERR(mfg->rpc))
> > > + return dev_err_probe(dev, PTR_ERR(mfg->rpc),
> > > + "Couldn't retrieve RPC MMIO registers\n");
> > > +
> > > + mfg->clk_eb = devm_clk_get(dev, "eb");
> > > + if (IS_ERR(mfg->clk_eb))
> > > + return dev_err_probe(dev, PTR_ERR(mfg->clk_eb),
> > > + "Couldn't get 'eb' clock\n");
> > > +
> > > + mfg->gpu_clks = devm_kcalloc(dev, data->num_clks, sizeof(*mfg->gpu_clks),
> > > + GFP_KERNEL);
> > > + if (!mfg->gpu_clks)
> > > + return -ENOMEM;
> > > +
> > > + for (i = 0; i < data->num_clks; i++)
> > > + mfg->gpu_clks[i].id = data->clk_names[i];
> > > +
> > > + ret = devm_clk_bulk_get(dev, data->num_clks, mfg->gpu_clks);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Couldn't get GPU clocks\n");
> > > +
> > > + mfg->gpu_regs = devm_kcalloc(dev, data->num_regulators,
> > > + sizeof(*mfg->gpu_regs), GFP_KERNEL);
> > > + if (!mfg->gpu_regs)
> > > + return -ENOMEM;
> > > +
> > > + for (i = 0; i < data->num_regulators; i++)
> > > + mfg->gpu_regs[i].supply = data->regulator_names[i];
> > > +
> > > + ret = devm_regulator_bulk_get(dev, data->num_regulators, mfg->gpu_regs);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Couldn't get GPU regulators\n");
> > > +
> > > + ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Couldn't get GPUEB shared memory\n");
> > > +
> > > + mfg->shared_mem = devm_ioremap(dev, res.start, resource_size(&res));
> > > + if (!mfg->shared_mem)
> > > + return dev_err_probe(dev, -ENOMEM, "Can't ioremap GPUEB shared memory\n");
> > > + mfg->shared_mem_size = resource_size(&res);
> > > + mfg->shared_mem_phys = res.start;
> > > +
> > > + if (data->init) {
> > > + ret = data->init(mfg);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Variant init failed\n");
> > > + }
> > > +
> > > + mfg->pd.name = dev_name(dev);
> > > + mfg->pd.attach_dev = mtk_mfg_attach_dev;
> > > + mfg->pd.detach_dev = mtk_mfg_detach_dev;
> > > + mfg->pd.power_off = mtk_mfg_power_off;
> > > + mfg->pd.power_on = mtk_mfg_power_on;
> > > + mfg->pd.set_performance_state = mtk_mfg_set_performance;
> > > + mfg->pd.flags = GENPD_FLAG_OPP_TABLE_FW;
> > > +
> > > + ret = pm_genpd_init(&mfg->pd, NULL, false);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Failed to initialise power domain\n");
> > We need to clean up mgf->md on errors from this point on. Maybe we can
> > move this to a later point?
> >
> > > +
> > > + ret = mtk_mfg_init_mbox(mfg);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Couldn't initialise mailbox\n");
> > We need to free the mboxes from this point on.
> >
>
> For this and the one above, does .remove not get called on probe failure? If not,
> I'll definitely do this. Otherwise it seems redundant, though with the added
> concern that .remove does not check before calling those functions.
>
Alright nevermind, I'm being confused by devres vs. remove callback.
.remove does not get called if the probe function fails, but devres
handlers still do get called.
Sorry for the confusion, will fix things accordingly.
prev parent reply other threads:[~2025-10-06 11:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 20:15 [PATCH v6 0/7] MT8196 GPU Frequency/Power Control Support Nicolas Frattaroli
2025-10-03 20:15 ` [PATCH v6 1/7] dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant Nicolas Frattaroli
2025-10-06 9:35 ` AngeloGioacchino Del Regno
2025-10-09 19:25 ` Rob Herring (Arm)
2025-10-03 20:15 ` [PATCH v6 2/7] dt-bindings: power: Add MT8196 GPU frequency control binding Nicolas Frattaroli
2025-10-06 9:36 ` AngeloGioacchino Del Regno
2025-10-09 19:27 ` Rob Herring (Arm)
2025-10-03 20:15 ` [PATCH v6 3/7] dt-bindings: mailbox: Add MT8196 GPUEB Mailbox Nicolas Frattaroli
2025-10-03 20:15 ` [PATCH v6 4/7] mailbox: add MediaTek GPUEB IPI mailbox Nicolas Frattaroli
2025-10-03 20:15 ` [PATCH v6 5/7] drm/panthor: call into devfreq for current frequency Nicolas Frattaroli
2025-10-03 20:15 ` [PATCH v6 6/7] drm/panthor: Use existing OPP table if present Nicolas Frattaroli
2025-10-03 20:47 ` Chia-I Wu
2025-10-03 20:15 ` [PATCH v6 7/7] pmdomain: mediatek: Add support for MFlexGraphics Nicolas Frattaroli
2025-10-03 21:41 ` Chia-I Wu
2025-10-03 21:42 ` Chia-I Wu
2025-10-06 10:58 ` Nicolas Frattaroli
2025-10-06 11:37 ` AngeloGioacchino Del Regno
2025-10-06 12:16 ` Nicolas Frattaroli
2025-10-06 14:28 ` AngeloGioacchino Del Regno
2025-10-06 21:04 ` Chia-I Wu
2025-10-06 11:40 ` Nicolas Frattaroli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2323923.iZASKD2KPV@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=boris.brezillon@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavoars@kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=kees@kernel.org \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=olvaffe@gmail.com \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
--cc=ulf.hansson@linaro.org \
--cc=wenst@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).