linux-kernel - Re: [PATCH v2 2/2] memory: mtk-smi: Add support for MT6795 Helio X10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f222e1c5-4ce1-a42d-ceef-a292136d8b61@collabora.com>
Date:   Tue, 17 May 2022 10:27:16 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Yong Wu <yong.wu@...iatek.com>,
        Krzysztof Kozlowski <krzk@...nel.org>
Cc:     krzysztof.kozlowski@...aro.org, robh+dt@...nel.org,
        matthias.bgg@...il.com, linux-mediatek@...ts.infradead.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, konrad.dybcio@...ainline.org,
        marijn.suijten@...ainline.org, martin.botka@...ainline.org,
        ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        paul.bouchara@...ainline.org, kernel@...labora.com,
        yi.kuo@...iatek.com, anthony.huang@...iatek.com,
        wendy-st.lin@...iatek.com
Subject: Re: [PATCH v2 2/2] memory: mtk-smi: Add support for MT6795 Helio X10

Il 17/05/22 08:37, Yong Wu ha scritto:
> On Fri, 2022-05-13 at 17:06 +0200, AngeloGioacchino Del Regno wrote:
>> The MediaTek Helio X10 (MT6795) SoC has 5 LARBs and one common SMI
>> instance without any sub-common and without GALS.
>>
>> While the smi-common configuration is specific to this SoC, on the
>> LARB side, this is similar to MT8173, in the sense that it doesn't
>> need the port in LARB, and the register layout is also compatible
>> with that one, which makes us able to fully reuse the smi-larb
>> platform data struct that was introduced for MT8173.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <
>> angelogioacchino.delregno@...labora.com>
>> ---
>>   drivers/memory/mtk-smi.c | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>> index 86a3d34f418e..7e7c3ede19e4 100644
>> --- a/drivers/memory/mtk-smi.c
>> +++ b/drivers/memory/mtk-smi.c
>> @@ -21,11 +21,13 @@
>>   /* SMI COMMON */
>>   #define SMI_L1LEN			0x100
>>   
>> +#define SMI_L1_ARB			0x200
>>   #define SMI_BUS_SEL			0x220
>>   #define SMI_BUS_LARB_SHIFT(larbid)	((larbid) << 1)
>>   /* All are MMU0 defaultly. Only specialize mmu1 here. */
>>   #define F_MMU1_LARB(larbid)		(0x1 <<
>> SMI_BUS_LARB_SHIFT(larbid))
>>   
>> +#define SMI_FIFO_TH0			0x230
> 
> Does the name come from the coda you got?
> It is called SMI_READ_FIFO_TH in my coda.
> 

Documentation for this SoC is not public and I have no access to it, so
everything that you see here comes from reading downstream kernel code :-(

I'll change the name to SMI_READ_FIFO_TH as suggested, thanks!

>>   #define SMI_M4U_TH			0x234
>>   #define SMI_FIFO_TH1			0x238
>>   #define SMI_FIFO_TH2			0x23c
>> @@ -360,6 +362,7 @@ static const struct of_device_id
>> mtk_smi_larb_of_ids[] = {
>>   	{.compatible = "mediatek,mt2701-smi-larb", .data =
>> &mtk_smi_larb_mt2701},
>>   	{.compatible = "mediatek,mt2712-smi-larb", .data =
>> &mtk_smi_larb_mt2712},
>>   	{.compatible = "mediatek,mt6779-smi-larb", .data =
>> &mtk_smi_larb_mt6779},
>> +	{.compatible = "mediatek,mt6795-smi-larb", .data =
>> &mtk_smi_larb_mt8173},
>>   	{.compatible = "mediatek,mt8167-smi-larb", .data =
>> &mtk_smi_larb_mt8167},
>>   	{.compatible = "mediatek,mt8173-smi-larb", .data =
>> &mtk_smi_larb_mt8173},
>>   	{.compatible = "mediatek,mt8183-smi-larb", .data =
>> &mtk_smi_larb_mt8183},
>> @@ -541,6 +544,13 @@ static struct platform_driver
>> mtk_smi_larb_driver = {
>>   	}
>>   };
>>   
>> +static const struct mtk_smi_reg_pair
>> mtk_smi_common_mt6795_init[SMI_COMMON_INIT_REGS_NR] = {
>> +	{SMI_L1_ARB, 0x1b},
>> +	{SMI_M4U_TH, 0xce810c85},
>> +	{SMI_FIFO_TH1, 0x43214c8},
>> +	{SMI_FIFO_TH0, 0x191f},
>> +};
>> +
>>   static const struct mtk_smi_reg_pair
>> mtk_smi_common_mt8195_init[SMI_COMMON_INIT_REGS_NR] = {
>>   	{SMI_L1LEN, 0xb},
>>   	{SMI_M4U_TH, 0xe100e10},
>> @@ -565,6 +575,12 @@ static const struct mtk_smi_common_plat
>> mtk_smi_common_mt6779 = {
>>   		    F_MMU1_LARB(5) | F_MMU1_LARB(6) | F_MMU1_LARB(7),
>>   };
>>   
>> +static const struct mtk_smi_common_plat mtk_smi_common_mt6795 = {
>> +	.type	  = MTK_SMI_GEN2,
>> +	.bus_sel  = BIT(0),
> 
> Like the other larbs, use F_MMU1_LARB(0) here?
> 

I agree that F_MMU1_LARB(0) == (1 << (0 << 1)) == BIT(0), but that would
not be correct and induce other people to mistake, I think?
Downstream doesn't do MMU1 bits, but MMU0 in this case... but if you can
check on internal documentation and confirm that the downstream kernel's
logic is wrong on that - and that you've verified that this should indeed
be F_MMU1_LARB(x), you'll get a big(bigger) thank you from me :-)

Meanwhile...

Thanks!
Angelo

> 
> After the two changes,
> 
> Reviewed-by: Yong Wu <yong.wu@...iatek.com>
> 
> Thanks.