Re: [PATCH v13 4/6] iommu/arm-smmu: add ACTLR data and support for SM8550

[Will Deacon <will@kernel.org>]

On Wed, Jul 03, 2024 at 05:45:23PM +0530, Bibek Kumar Patro wrote:
> 
> 
> On 7/2/2024 12:04 AM, Dmitry Baryshkov wrote:
> > On Fri, Jun 28, 2024 at 07:34:33PM GMT, Bibek Kumar Patro wrote:
> > > Add ACTLR data table for SM8550 along with support for
> > > same including SM8550 specific implementation operations.
> > > 
> > > Signed-off-by: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
> > > ---
> > >   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
> > >   1 file changed, 89 insertions(+)
> > > 
> > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > > index 77c9abffe07d..b4521471ffe9 100644
> > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > > @@ -23,6 +23,85 @@
> > > 
> > >   #define CPRE			(1 << 1)
> > >   #define CMTLB			(1 << 0)
> > > +#define PREFETCH_SHIFT		8
> > > +#define PREFETCH_DEFAULT	0
> > > +#define PREFETCH_SHALLOW	(1 << PREFETCH_SHIFT)
> > > +#define PREFETCH_MODERATE	(2 << PREFETCH_SHIFT)
> > > +#define PREFETCH_DEEP		(3 << PREFETCH_SHIFT)
> > > +
> > > +static const struct actlr_config sm8550_apps_actlr_cfg[] = {
> > > +	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> > 
> > - Please keep the list sorted
> 
> Sure Dmitry, will sort this list in reverse-christmas-tree order
> in next iteration. Thanks for this input.
> 
> > - Please comment, which devices use these settings.
> 
> As discussed in earlier versions of this patch, these table entries
> are kind of just blind values for SMMU device, where SMMU do not have
> idea on which SID belong to which client. During probe time when the
> clients' Stream-ID has corresponding ACTLR entry then the driver would
> set value in register.

I'm still firmly of the opinion that this stuff needs a higher-level
description in the device-tree and should not be hard-coded in the driver
like this. It's not just a list of opaque values; it describes
SoC-specific topological information that should not be this rigid.

Will