From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Steven Price <steven.price@arm.com>, boris.brezillon@collabora.com
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
matthias.bgg@gmail.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
Subject: Re: [PATCH v2 2/2] drm/panfrost: Add support for Mali on the MT8188 SoC
Date: Wed, 5 Jun 2024 13:43:33 +0200 [thread overview]
Message-ID: <6dee4870-3ca2-46d7-a30b-014a7d34135a@collabora.com> (raw)
In-Reply-To: <f44611fd-523a-4b4d-accd-20fdfbac178a@arm.com>
Il 05/06/24 11:18, Steven Price ha scritto:
> On 04/06/2024 13:39, AngeloGioacchino Del Regno wrote:
>> MediaTek MT8188 has a Mali-G57 MC3 (Valhall-JM): add a new
>> compatible and platform data using the same supplies and the
>> same power domain lists as MT8183 (one regulator, three power
>> domains).
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>> drivers/gpu/drm/panfrost/panfrost_drv.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
>> index ef9f6c0716d5..4e2d9f671a0d 100644
>> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
>> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
>> @@ -777,6 +777,14 @@ static const struct panfrost_compatible mediatek_mt8186_data = {
>> .pm_features = BIT(GPU_PM_CLK_DIS) | BIT(GPU_PM_VREG_OFF),
>> };
>>
>> +static const struct panfrost_compatible mediatek_mt8188_data = {
>> + .num_supplies = ARRAY_SIZE(mediatek_mt8183_b_supplies) - 1,
>> + .supply_names = mediatek_mt8183_b_supplies,
>
> I think this is a little confusing. Ideally we'd drop the existing
> mediatek_xxx_supplies which are the same as default_supplies and just
> use that instead.
>
>> + .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
>> + .pm_domain_names = mediatek_mt8183_pm_domains,
>
> We'd want at least a comment explaining that this isn't a typo (i.e. /*
> mt8188 uses the same pm domains as mt8183 */). But I'm also wondering if
> it would be sensible to simply have one domain list, something like:
>
> --->8---
> static const char * const mediatek_pm_domains[] = { "core0", "core1",
> "core2", "core3",
> "core4" };
>
> static const struct panfrost_compatible mediatek_mt8183_data = {
> ...
> .num_pm_domains = 3,
> .pm_domain_names = mediatek_pm_domains,
> };
> ...
> static const struct panfrost_compatible mediatek_mt8186_data = {
> ...
> .num_pm_domains = 2,
> .pm_domain_names = mediatek_pm_domains,
> };
> ...
> static const struct panfrost_compatible mediatek_mt8188_data = {
> ...
> .num_pm_domains = 3,
> .pm_domain_names = mediatek_pm_domains,
> };
> ...
> static const struct panfrost_compatible mediatek_mt8192_data = {
> ...
> .num_pm_domains = 5,
> .pm_domain_names = mediatek_pm_domains,
> };
> --->8---
>
> OTOH what you've got it no worse than what we already had, so it's up to
> you whether you want to tidy this up or just add a comment so it doesn't
> look like there's a typo.
>
I didn't disclose my plan, but you've already shown part of it, so seeing that
you preventively agree with at least part of that is fun :-)
I surely won't be able to do what I want to do for *this* cycle as I'm mostly
sure that I won't have time for this in the next 3 weeks - but anyway....
What I was thinking is that we should either look for a number of power domains
limited by a max power domains definition (that should already be present somewhere
in panfrost if I recall correctly) without even caring about the actual power
domain names, or we should look for a number of PDs having any name matching,
in a for loop, snprintf(*something, sizeof(something), "core%d", i).
This means that, with the snprintf idea, we don't even have to set any
pm_domain_names list anymore, at all, and we can either reuse num_pm_domains
or just get the number of PDs limited by the binding - but that's a problem for
the future me/us I guess...
But since we're there...
Please, I'd like to hear your opinion about the core%d idea :-)
Anyway, I think that for now I'm choosing the "comment shortcut" for this patch.
P.S.: Thanks for the feedback!
Cheers,
Angelo
> Steve
>
>> + .pm_features = BIT(GPU_PM_CLK_DIS) | BIT(GPU_PM_VREG_OFF),
>> +};
>> +
>> static const char * const mediatek_mt8192_supplies[] = { "mali", NULL };
>> static const char * const mediatek_mt8192_pm_domains[] = { "core0", "core1", "core2",
>> "core3", "core4" };
>> @@ -808,6 +816,7 @@ static const struct of_device_id dt_match[] = {
>> { .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
>> { .compatible = "mediatek,mt8183b-mali", .data = &mediatek_mt8183_b_data },
>> { .compatible = "mediatek,mt8186-mali", .data = &mediatek_mt8186_data },
>> + { .compatible = "mediatek,mt8188-mali", .data = &mediatek_mt8188_data },
>> { .compatible = "mediatek,mt8192-mali", .data = &mediatek_mt8192_data },
>> {}
>> };
>
next prev parent reply other threads:[~2024-06-05 11:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 12:39 [PATCH v2 0/2] drm/panfrost: Add MT8188 support AngeloGioacchino Del Regno
2024-06-04 12:39 ` [PATCH v2 1/2] dt-bindings: gpu: mali-bifrost: Add compatible for MT8188 SoC AngeloGioacchino Del Regno
2024-06-04 16:37 ` Conor Dooley
2024-06-05 4:20 ` Chen-Yu Tsai
2024-06-04 12:39 ` [PATCH v2 2/2] drm/panfrost: Add support for Mali on the " AngeloGioacchino Del Regno
2024-06-05 4:25 ` Chen-Yu Tsai
2024-06-05 9:18 ` Steven Price
2024-06-05 11:43 ` AngeloGioacchino Del Regno [this message]
2024-06-05 12:39 ` Steven Price
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=6dee4870-3ca2-46d7-a30b-014a7d34135a@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/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