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@xxxxxxxxxxx>
> > > ---
> > > 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
