[PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition
Tomasz Figa
tfiga at chromium.org
Wed Jan 13 00:22:50 EST 2021
On Thu, Dec 24, 2020 at 8:27 PM Yong Wu <yong.wu at mediatek.com> wrote:
>
> On Wed, 2020-12-23 at 17:15 +0900, Tomasz Figa wrote:
> > Hi Yong,
> >
> > On Wed, Dec 09, 2020 at 04:00:39PM +0800, Yong Wu wrote:
> > > In the latest SoC, there are several HW IP require a sepecial iova
> > > range, mainly CCU and VPU has this requirement. Take CCU as a example,
> > > CCU require its iova locate in the range(0x4000_0000 ~ 0x43ff_ffff).
> >
> > Is this really a domain? Does the address range come from the design of
> > the IOMMU?
>
> It is not a really a domain. The address range comes from CCU HW
> requirement. That HW can only access this iova range. thus I create a
> special iommu domain for it.
>
I guess it's the IOMMU/DT maintainers who have the last word here, but
shouldn't DT just specify the hardware characteristics and then the
kernel configure the hardware appropriately, possibly based on some
other configuration interface (e.g. command line parameters or sysfs)?
How I'd do this is rather than enforcing those arbitrary decisions
onto the DT bindings, I'd add properties to the master devices (e.g.
CCU) that specify which IOVA range they can operate on. Then, the
exact split of the complete address space would be done at runtime,
based on kernel configuration, command line parameters and possibly
sysfs attributes if things could be reconfigured dynamically.
Best regards,
Tomasz
> >
> > Best regards,
> > Tomasz
> >
> > >
> > > In this patch we add a domain definition for the special port. In the
> > > example of CCU, If we preassign CCU port in domain1, then iommu driver
> > > will prepare a independent iommu domain of the special iova range for it,
> > > then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special
> > > range.
> > >
> > > This is a preparing patch for multi-domain support.
> > >
> > > Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> > > Acked-by: Krzysztof Kozlowski <krzk at kernel.org>
> > > Acked-by: Rob Herring <robh at kernel.org>
> > > ---
> > > include/dt-bindings/memory/mtk-smi-larb-port.h | 9 ++++++++-
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h
> > > index 7d64103209af..2d4c973c174f 100644
> > > --- a/include/dt-bindings/memory/mtk-smi-larb-port.h
> > > +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h
> > > @@ -7,9 +7,16 @@
> > > #define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
> > >
> > > #define MTK_LARB_NR_MAX 32
> > > +#define MTK_M4U_DOM_NR_MAX 8
> > > +
> > > +#define MTK_M4U_DOM_ID(domid, larb, port) \
> > > + (((domid) & 0x7) << 16 | (((larb) & 0x1f) << 5) | ((port) & 0x1f))
> > > +
> > > +/* The default dom id is 0. */
> > > +#define MTK_M4U_ID(larb, port) MTK_M4U_DOM_ID(0, larb, port)
> > >
> > > -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
> > > #define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0x1f)
> > > #define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
> > > +#define MTK_M4U_TO_DOM(id) (((id) >> 16) & 0x7)
> > >
> > > #endif
> > > --
> > > 2.18.0
> > >
> > > _______________________________________________
> > > iommu mailing list
> > > iommu at lists.linux-foundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
More information about the linux-arm-kernel
mailing list