On 5/28/2024 6:36 PM, Dmitry Baryshkov wrote:
On Tue, May 28, 2024 at 02:59:51PM +0200, Konrad Dybcio wrote:
On 5/15/24 15:59, Bibek Kumar Patro wrote:
On 5/10/2024 6:32 PM, Konrad Dybcio wrote:
On 10.05.2024 2:52 PM, Bibek Kumar Patro wrote:
On 5/1/2024 12:30 AM, Rob Clark wrote:
On Tue, Jan 23, 2024 at 7:00 AM Bibek Kumar Patro
<quic_bibekkum@xxxxxxxxxxx> wrote:
Currently in Qualcomm SoCs the default prefetch is set to 1 which allows
the TLB to fetch just the next page table. MMU-500 features ACTLR
register which is implementation defined and is used for Qualcomm SoCs
to have a custom prefetch setting enabling TLB to prefetch the next set
of page tables accordingly allowing for faster translations.
ACTLR value is unique for each SMR (Stream matching register) and stored
in a pre-populated table. This value is set to the register during
context bank initialisation.
Signed-off-by: Bibek Kumar Patro <quic_bibekkum@xxxxxxxxxxx>
---
[...]
+
+ for_each_cfg_sme(cfg, fwspec, j, idx) {
+ smr = &smmu->smrs[idx];
+ if (smr_is_subset(smr, id, mask)) {
+ arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
+ actlrcfg[i].actlr);
So, this makes ACTLR look like kind of a FIFO. But I'm looking at
downstream kgsl's PRR thing (which we'll need to implement vulkan
sparse residency), and it appears to be wanting to set BIT(5) in ACTLR
to enable PRR.
val = KGSL_IOMMU_GET_CTX_REG(ctx, KGSL_IOMMU_CTX_ACTLR);
val |= FIELD_PREP(KGSL_IOMMU_ACTLR_PRR_ENABLE, 1);
KGSL_IOMMU_SET_CTX_REG(ctx, KGSL_IOMMU_CTX_ACTLR, val);
Any idea how this works? And does it need to be done before or after
the ACTLR programming done in this patch?
BR,
-R
Hi Rob,
Can you please help provide some more clarification on the FIFO part? By FIFO are you referring to the storing of ACTLR data in the table?
Thanks for pointing to the downstream implementation of kgsl driver for
the PRR bit. Since kgsl driver is already handling this PRR bit's
setting, this makes setting the PRR BIT(5) by SMMU driver redundant.
The kgsl driver is not present upstream.
Right kgsl is not present upstream, it would be better to avoid configuring the PRR bit and can be handled by kgsl directly in downstream.
No! Upstream is not a dumping ground to reduce your technical debt.
There is no kgsl driver upstream, so this ought to be handled here, in
the iommu driver (as poking at hardware A from driver B is usually not good
practice).
I'd second the request here. If another driver has to control the
behaviour of another driver, please add corresponding API for that.
Ack, I understood this point now. Will add an interface for gfx to carry
out the PRR bit implementation through smmu driver.
Thanks & regards,
Bibek
Thanks for bringing up this point.
I will send v10 patch series removing this BIT(5) setting from the ACTLR
table.
I think it's generally saner to configure the SMMU from the SMMU driver..
Yes, agree on this. But since PRR bit is not directly related to SMMU
configuration so I think it would be better to remove this PRR bit
setting from SMMU driver based on my understanding.
Why is it not related? We still don't know what it does.
Konrad
