From: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Yong Wu <yong.wu@mediatek.com>
Cc: joro@8bytes.org, will@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org,
iommu@lists.linux-foundation.org,
linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
konrad.dybcio@somainline.org, marijn.suijten@somainline.org,
martin.botka@somainline.org,
~postmarketos/upstreaming@lists.sr.ht,
phone-devel@vger.kernel.org, paul.bouchara@somainline.org,
yf.wang@mediatek.com, mingyuan.ma@mediatek.com
Subject: Re: [PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us
Date: Tue, 17 May 2022 11:37:34 +0200 [thread overview]
Message-ID: <8a3079d2-1a2f-43ff-9072-91083a025c7b@gmail.com> (raw)
In-Reply-To: <9a67d3e8-8840-03b1-aec8-5a218e810eae@collabora.com>
On 17/05/2022 11:26, AngeloGioacchino Del Regno wrote:
> Il 17/05/22 11:08, Yong Wu ha scritto:
>> On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
>>> Add support for the M4Us found in the MT6795 Helio X10 SoC.
>>>
>>> Signed-off-by: AngeloGioacchino Del Regno <
>>> angelogioacchino.delregno@collabora.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 20 +++++++++++++++++++-
>>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 71b2ace74cd6..3d802dd3f377 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -157,6 +157,7 @@
>>> enum mtk_iommu_plat {
>>> M4U_MT2712,
>>> M4U_MT6779,
>>> + M4U_MT6795,
>>> M4U_MT8167,
>>> M4U_MT8173,
>>> M4U_MT8183,
>>> @@ -953,7 +954,8 @@ static int mtk_iommu_hw_init(const struct
>>> mtk_iommu_data *data, unsigned int ban
>>> * Global control settings are in bank0. May re-init these
>>> global registers
>>> * since no sure if there is bank0 consumers.
>>> */
>>> - if (data->plat_data->m4u_plat == M4U_MT8173) {
>>> + if (data->plat_data->m4u_plat == M4U_MT6795 ||
>>> + data->plat_data->m4u_plat == M4U_MT8173) {
>>> regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
>>> F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
>>> } else {
>>> @@ -1138,6 +1140,9 @@ static int mtk_iommu_probe(struct
>>> platform_device *pdev)
>>> case M4U_MT2712:
>>> p = "mediatek,mt2712-infracfg";
>>> break;
>>> + case M4U_MT6795:
>>> + p = "mediatek,mt6795-infracfg";
>>> + break;
>>> case M4U_MT8173:
>>> p = "mediatek,mt8173-infracfg";
>>> break;
>>> @@ -1404,6 +1409,18 @@ static const struct mtk_iommu_plat_data
>>> mt6779_data = {
>>> .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
>>> };
>>> +static const struct mtk_iommu_plat_data mt6795_data = {
>>> + .m4u_plat = M4U_MT6795,
>>> + .flags = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
>>> + HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
>>> + .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
>>> + .banks_num = 1,
>>> + .banks_enable = {true},
>>> + .iova_region = single_domain,
>>> + .iova_region_nr = ARRAY_SIZE(single_domain),
>>> + .larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping.
>>> */
>>> +};
>>
>> This is nearly same with mt8173_data. mt8173 has one more larb than
>> mt6795, its larbid_remap is also ok for mt6795.
>>
>
> I think that we should be explicit about the larbid_remap property,
> since mt6795 has one less larb, we should explicitly say that like
> I did there... that's only for human readability I admit ... but,
> still, I wouldn't want to see people thinking that MT6795 has 6 LARBs
> because they've read that larbid_remap having 6 entries.
>
>> thus it looks we could use mt8173 as the backward compatible.
>> compatible = "mediatek,mt6795-m4u",
>> "mediatek,mt8173-m4u";
>>
>> After this, the only thing is about "mediatek,mt6795-infracfg". we have
>> to try again with mediatek,mt6795-infracfg after mediatek,mt8173-
>> infracfg fail. I think we should allow the backward case in 4GB mode
>> judgment if we have.
>>
>> What's your opinion? or some other suggestion?
>> Thanks.
>
> I know, I may have a plan for that, but I wanted to have a good reason to
> propose such a thing, as if it's just about two SoCs needing that, there
> would be no good reason to get things done differently.
>
> ...so, in order to provide a good cleanup, we have two possible roads to
> follow here: either we add a generic "mediatek,infracfg" compatible to the
> infra node (but I don't like that), or we can do it like it was previously
> done in mtk-pm-domains.c (I prefer that approach):
>
> iommu: iommu@somewhere {
> ... something ...
> mediatek,infracfg = <&infracfg>;
> };
>
> infracfg = syscon_regmap_lookup_by_compatible(node, "mediatek,infracfg");
> if (IS_ERR(infracfg)) {
> /* try with the older way */
> switch (...) {
> case .... p = "mediatek,mt2712-infracfg";
> ... blah blah ...
> }
> /* legacy also failed, ouch! */
> if (IS_ERR(infracfg))
> return PTR_ERR(infracfg);
> }
>
> ret = regmap_read ... etc etc etc
>
I prefer that approach as well.
Regards,
Matthias
> Cheers,
> Angelo
next prev parent reply other threads:[~2022-05-17 9:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-13 15:14 [PATCH 0/2] MediaTek Helio X10 MT6795 - M4U/IOMMU Support AngeloGioacchino Del Regno
2022-05-13 15:14 ` [PATCH 1/2] dt-bindings: mediatek: Add bindings for MT6795 M4U AngeloGioacchino Del Regno
2022-05-16 16:03 ` Rob Herring
2022-05-17 11:10 ` AngeloGioacchino Del Regno
2022-05-13 15:14 ` [PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us AngeloGioacchino Del Regno
2022-05-17 9:08 ` Yong Wu
2022-05-17 9:26 ` AngeloGioacchino Del Regno
2022-05-17 9:37 ` Matthias Brugger [this message]
2022-05-18 1:13 ` Yong Wu
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=8a3079d2-1a2f-43ff-9072-91083a025c7b@gmail.com \
--to=matthias.bgg@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=konrad.dybcio@somainline.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=marijn.suijten@somainline.org \
--cc=martin.botka@somainline.org \
--cc=mingyuan.ma@mediatek.com \
--cc=paul.bouchara@somainline.org \
--cc=phone-devel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=will@kernel.org \
--cc=yf.wang@mediatek.com \
--cc=yong.wu@mediatek.com \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/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).