linux-kernel - Re: [PATCH v2 3/4] soc: qcom: llcc-qcom: Add support for SM8750

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <26f5e187-9718-4df2-a81c-b33463632cf9@quicinc.com>
Date: Wed, 12 Mar 2025 11:07:37 -0700
From: Melody Olvera <quic_molvera@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Bjorn Andersson
	<andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Conor Dooley
	<conor@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "Satya Durga
 Srinivasu Prabhala" <quic_satyap@...cinc.com>,
        Trilok Soni
	<quic_tsoni@...cinc.com>
CC: <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] soc: qcom: llcc-qcom: Add support for SM8750



On 3/11/2025 3:17 AM, Konrad Dybcio wrote:
> On 3/4/25 11:23 PM, Melody Olvera wrote:
>> Add system cache table and configs for SM8750 SoCs.
>>
>> Signed-off-by: Melody Olvera <quic_molvera@...cinc.com>
>> ---
> [...]
>
>> +		.usecase_id = LLCC_MODPE,
>> +		.slice_id = 29,
>> +		.max_cap = 256,
>> +		.priority = 1,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xf0000000,
>> +		.ovcap_prio = true,
> ovcap_prio = false, alloc_oneway_en = true
>
>> +	}, {
>> +		.usecase_id = LLCC_WRCACHE,
>> +		.slice_id = 31,
>> +		.max_cap = 512,
>> +		.priority = 1,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
> .activate_on_init = true,
>
> [...]
>
>> +		.usecase_id = LLCC_LCPDARE,
>> +		.slice_id = 30,
>> +		.max_cap = 128,
>> +		.priority = 5,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +		.activate_on_init = true,
>> +		.ovcap_prio = true,
> ovcap_prio = false, alloc_oneway_en = true
>
> [...]
>
>> +		.usecase_id = LLCC_VIDVSP,
>> +		.slice_id = 4,
>> +		.max_cap = 256,
>> +		.priority = 4,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +	}, {
>> +		.usecase_id = LLCC_VIDDEC,
>> +		.slice_id = 5,
>> +		.max_cap = 6144,
>> +		.priority = 4,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +		.cache_mode = 2,
>> +		.vict_prio = true,
> .vict_prio = false, .overcap_prio = true
>
>> +	}, {
>> +		.usecase_id = LLCC_CAMOFE,
>> +		.slice_id = 33,
>> +		.max_cap = 6144,
>> +		.priority = 4,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +		.mru_uncap_en = true,
>> +		.vict_prio = true,
> .mru_uncap_en = false, stale_en = true
> .vict_prio = false, .overcap_prio = true
>
>> +	}, {
>> +		.usecase_id = LLCC_CAMRTIP,
>> +		.slice_id = 13,
>> +		.max_cap = 1024,
>> +		.priority = 4,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +		.mru_uncap_en = true,
>> +		.vict_prio = true,
> same
>
>> +	}, {
>> +		.usecase_id = LLCC_CAMSRTIP,
>> +		.slice_id = 14,
>> +		.max_cap = 6144,
>> +		.priority = 4,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +		.mru_uncap_en = true,
>> +		.vict_prio = true,
> same
>
>> +	}, {
>> +		.usecase_id = LLCC_CAMRTRF,
>> +		.slice_id = 7,
>> +		.max_cap = 3584,
>> +		.priority = 1,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +		.mru_uncap_en = true,
>> +		.vict_prio = true,
> same
>
>> +	}, {
>> +		.usecase_id = LLCC_CAMSRTRF,
>> +		.slice_id = 21,
>> +		.max_cap = 6144,
>> +		.priority = 1,
>> +		.fixed_size = true,
>> +		.bonus_ways = 0xffffffff,
>> +		.mru_uncap_en = true,
>> +		.vict_prio = true,
> same

Ack for all the above. Looks like I was looking at an outdated data 
table unfortunately.

> Apart from that, it looks like there's some sort of grouping / parent-child
> relationships involved in this thing - do we need more sw changes for that?
>

Yes; I originally thought that wasn't relevant for this version but upon 
further review it seems
it is. I believe the functionality changes belong in the previous patch 
so I'll add them there
and add the relevant data to this patch.

Thanks,
Melody