* [PATCH 0/6] Support for fsl-mc bus and its devices in SMMU @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon, robin.murphy, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor, Nipun Gupta This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. These patches - Define the new property 'iommu-parent' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3) - Adds the dma-mapping support for fsl-mc bus (patch 4,5) - Updates the fsl-mc device node with iommu/dma related changes This patchset is based on staging-testing tree where fsl-mc bus is out from staging This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/; otherwise DPAA2 Ethernet driver functionality will break. Nipun Gupta (6): Docs: dt: add fsl-mc iommu-parent device-tree binding iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: remove dma ops setup from driver dma-mapping: support fsl-mc bus dts: fsl-ls208x: updated DT with SMMU support for fsl-mc .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 ++++- drivers/base/dma-mapping.c | 7 +++++ drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +--- drivers/iommu/arm-smmu.c | 7 +++++ drivers/iommu/iommu.c | 21 +++++++++++++++ drivers/iommu/of_iommu.c | 23 ++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++ include/linux/iommu.h | 2 ++ 9 files changed, 105 insertions(+), 5 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 0/6] Support for fsl-mc bus and its devices in SMMU @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: linux-arm-kernel This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. These patches - Define the new property 'iommu-parent' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3) - Adds the dma-mapping support for fsl-mc bus (patch 4,5) - Updates the fsl-mc device node with iommu/dma related changes This patchset is based on staging-testing tree where fsl-mc bus is out from staging This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/; otherwise DPAA2 Ethernet driver functionality will break. Nipun Gupta (6): Docs: dt: add fsl-mc iommu-parent device-tree binding iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: remove dma ops setup from driver dma-mapping: support fsl-mc bus dts: fsl-ls208x: updated DT with SMMU support for fsl-mc .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 ++++- drivers/base/dma-mapping.c | 7 +++++ drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +--- drivers/iommu/arm-smmu.c | 7 +++++ drivers/iommu/iommu.c | 21 +++++++++++++++ drivers/iommu/of_iommu.c | 23 ++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++ include/linux/iommu.h | 2 ++ 9 files changed, 105 insertions(+), 5 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 0/6] Support for fsl-mc bus and its devices in SMMU @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon-5wv7dgnIgG8, robin.murphy-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. These patches - Define the new property 'iommu-parent' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3) - Adds the dma-mapping support for fsl-mc bus (patch 4,5) - Updates the fsl-mc device node with iommu/dma related changes This patchset is based on staging-testing tree where fsl-mc bus is out from staging This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/; otherwise DPAA2 Ethernet driver functionality will break. Nipun Gupta (6): Docs: dt: add fsl-mc iommu-parent device-tree binding iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: remove dma ops setup from driver dma-mapping: support fsl-mc bus dts: fsl-ls208x: updated DT with SMMU support for fsl-mc .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 ++++- drivers/base/dma-mapping.c | 7 +++++ drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +--- drivers/iommu/arm-smmu.c | 7 +++++ drivers/iommu/iommu.c | 21 +++++++++++++++ drivers/iommu/of_iommu.c | 23 ++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++ include/linux/iommu.h | 2 ++ 9 files changed, 105 insertions(+), 5 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon, robin.murphy, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor, Nipun Gupta The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a binding for mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 6611a7c..011c7d6 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices such as network interfaces, crypto accelerator instances, L2 switches, etc. +For an overview of the DPAA2 architecture and fsl-mc bus see: +drivers/staging/fsl-mc/README.txt + +As described in the above overview, all DPAA2 objects in a DPRC share the +same hardware "isolation context" and a 10-bit value called an ICID +(isolation context id) is expressed by the hardware to identify +the requester. + +The generic 'iommus' property is cannot be used to describe the relationship +between fsl-mc and IOMMUs, so an iommu-parent property is used to define +the same. + +For generic IOMMU bindings, see +Documentation/devicetree/bindings/iommu/iommu.txt. + +For arm-smmu binding, see: +Documentation/devicetree/bindings/iommu/arm,smmu.txt. + Required properties: - compatible @@ -88,14 +106,27 @@ Sub-nodes: Value type: <phandle> Definition: Specifies the phandle to the PHY device node associated with the this dpmac. +Optional properties: + +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. + The property specifies the IOMMU behind which the devices on + fsl-mc bus are residing. Example: + smmu: iommu@5000000 { + compatible = "arm,mmu-500"; + #iommu-cells = <1>; + stream-match-mask = <0x7C00>; + ... + }; + fsl_mc: fsl-mc@80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-parent = <&smmu>; #address-cells = <3>; #size-cells = <1>; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: linux-arm-kernel The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a binding for mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 6611a7c..011c7d6 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices such as network interfaces, crypto accelerator instances, L2 switches, etc. +For an overview of the DPAA2 architecture and fsl-mc bus see: +drivers/staging/fsl-mc/README.txt + +As described in the above overview, all DPAA2 objects in a DPRC share the +same hardware "isolation context" and a 10-bit value called an ICID +(isolation context id) is expressed by the hardware to identify +the requester. + +The generic 'iommus' property is cannot be used to describe the relationship +between fsl-mc and IOMMUs, so an iommu-parent property is used to define +the same. + +For generic IOMMU bindings, see +Documentation/devicetree/bindings/iommu/iommu.txt. + +For arm-smmu binding, see: +Documentation/devicetree/bindings/iommu/arm,smmu.txt. + Required properties: - compatible @@ -88,14 +106,27 @@ Sub-nodes: Value type: <phandle> Definition: Specifies the phandle to the PHY device node associated with the this dpmac. +Optional properties: + +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. + The property specifies the IOMMU behind which the devices on + fsl-mc bus are residing. Example: + smmu: iommu at 5000000 { + compatible = "arm,mmu-500"; + #iommu-cells = <1>; + stream-match-mask = <0x7C00>; + ... + }; + fsl_mc: fsl-mc at 80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-parent = <&smmu>; #address-cells = <3>; #size-cells = <1>; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon-5wv7dgnIgG8, robin.murphy-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a binding for mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 6611a7c..011c7d6 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices such as network interfaces, crypto accelerator instances, L2 switches, etc. +For an overview of the DPAA2 architecture and fsl-mc bus see: +drivers/staging/fsl-mc/README.txt + +As described in the above overview, all DPAA2 objects in a DPRC share the +same hardware "isolation context" and a 10-bit value called an ICID +(isolation context id) is expressed by the hardware to identify +the requester. + +The generic 'iommus' property is cannot be used to describe the relationship +between fsl-mc and IOMMUs, so an iommu-parent property is used to define +the same. + +For generic IOMMU bindings, see +Documentation/devicetree/bindings/iommu/iommu.txt. + +For arm-smmu binding, see: +Documentation/devicetree/bindings/iommu/arm,smmu.txt. + Required properties: - compatible @@ -88,14 +106,27 @@ Sub-nodes: Value type: <phandle> Definition: Specifies the phandle to the PHY device node associated with the this dpmac. +Optional properties: + +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. + The property specifies the IOMMU behind which the devices on + fsl-mc bus are residing. Example: + smmu: iommu@5000000 { + compatible = "arm,mmu-500"; + #iommu-cells = <1>; + stream-match-mask = <0x7C00>; + ... + }; + fsl_mc: fsl-mc@80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-parent = <&smmu>; #address-cells = <3>; #size-cells = <1>; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding 2018-03-05 14:29 ` Nipun Gupta @ 2018-03-05 14:53 ` Robin Murphy -1 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 14:53 UTC (permalink / raw) To: Nipun Gupta, will.deacon, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor On 05/03/18 14:29, Nipun Gupta wrote: > The existing IOMMU bindings cannot be used to specify the relationship > between fsl-mc devices and IOMMUs. This patch adds a binding for > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. Given that allowing "msi-parent" for #msi-cells > 1 is merely a backward-compatibility bodge full of hard-coded assumptions, why would we want to knowingly introduce a similarly unpleasant equivalent for IOMMUs? What's wrong with "iommu-map"? > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > --- > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > index 6611a7c..011c7d6 100644 > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices > such as network interfaces, crypto accelerator instances, L2 switches, > etc. > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > +drivers/staging/fsl-mc/README.txt > + > +As described in the above overview, all DPAA2 objects in a DPRC share the > +same hardware "isolation context" and a 10-bit value called an ICID > +(isolation context id) is expressed by the hardware to identify > +the requester. IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know they're currently documented under bindings/pci, but they're not really intended to be absolutely PCI-specific. Robin. > +The generic 'iommus' property is cannot be used to describe the relationship > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > +the same. > + > +For generic IOMMU bindings, see > +Documentation/devicetree/bindings/iommu/iommu.txt. > + > +For arm-smmu binding, see: > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > + > Required properties: > > - compatible > @@ -88,14 +106,27 @@ Sub-nodes: > Value type: <phandle> > Definition: Specifies the phandle to the PHY device node associated > with the this dpmac. > +Optional properties: > + > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > + The property specifies the IOMMU behind which the devices on > + fsl-mc bus are residing. > > Example: > > + smmu: iommu@5000000 { > + compatible = "arm,mmu-500"; > + #iommu-cells = <1>; > + stream-match-mask = <0x7C00>; > + ... > + }; > + > fsl_mc: fsl-mc@80c000000 { > compatible = "fsl,qoriq-mc"; > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > msi-parent = <&its>; > + iommu-parent = <&smmu>; > #address-cells = <3>; > #size-cells = <1>; > > ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 14:53 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 14:53 UTC (permalink / raw) To: linux-arm-kernel On 05/03/18 14:29, Nipun Gupta wrote: > The existing IOMMU bindings cannot be used to specify the relationship > between fsl-mc devices and IOMMUs. This patch adds a binding for > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. Given that allowing "msi-parent" for #msi-cells > 1 is merely a backward-compatibility bodge full of hard-coded assumptions, why would we want to knowingly introduce a similarly unpleasant equivalent for IOMMUs? What's wrong with "iommu-map"? > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > --- > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > index 6611a7c..011c7d6 100644 > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices > such as network interfaces, crypto accelerator instances, L2 switches, > etc. > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > +drivers/staging/fsl-mc/README.txt > + > +As described in the above overview, all DPAA2 objects in a DPRC share the > +same hardware "isolation context" and a 10-bit value called an ICID > +(isolation context id) is expressed by the hardware to identify > +the requester. IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know they're currently documented under bindings/pci, but they're not really intended to be absolutely PCI-specific. Robin. > +The generic 'iommus' property is cannot be used to describe the relationship > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > +the same. > + > +For generic IOMMU bindings, see > +Documentation/devicetree/bindings/iommu/iommu.txt. > + > +For arm-smmu binding, see: > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > + > Required properties: > > - compatible > @@ -88,14 +106,27 @@ Sub-nodes: > Value type: <phandle> > Definition: Specifies the phandle to the PHY device node associated > with the this dpmac. > +Optional properties: > + > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > + The property specifies the IOMMU behind which the devices on > + fsl-mc bus are residing. > > Example: > > + smmu: iommu at 5000000 { > + compatible = "arm,mmu-500"; > + #iommu-cells = <1>; > + stream-match-mask = <0x7C00>; > + ... > + }; > + > fsl_mc: fsl-mc at 80c000000 { > compatible = "fsl,qoriq-mc"; > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > msi-parent = <&its>; > + iommu-parent = <&smmu>; > #address-cells = <3>; > #size-cells = <1>; > > ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding 2018-03-05 14:53 ` Robin Murphy (?) @ 2018-03-05 15:00 ` Nipun Gupta -1 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 15:00 UTC (permalink / raw) To: Robin Murphy, will.deacon, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Monday, March 05, 2018 20:23 > To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com; > mark.rutland@arm.com; catalin.marinas@arm.com > Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de; > m.szyprowski@samsung.com; gregkh@linuxfoundation.org; joro@8bytes.org; > Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com> > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On 05/03/18 14:29, Nipun Gupta wrote: > > The existing IOMMU bindings cannot be used to specify the relationship > > between fsl-mc devices and IOMMUs. This patch adds a binding for > > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > Given that allowing "msi-parent" for #msi-cells > 1 is merely a > backward-compatibility bodge full of hard-coded assumptions, why would > we want to knowingly introduce a similarly unpleasant equivalent for > IOMMUs? What's wrong with "iommu-map"? Hi Robin, With 'msi-parent' the property is fixed up to have msi-map. In this case there is no fixup required and simple 'iommu-parent' property can be used, with MC bus itself providing the stream-id's (in the code execution via FW). We can also use the iommu-map property similar to PCI, which will require u-boot fixup. But then it leads to little bit complications of u-boot - kernel compatibility. If you suggest we can re-use the iommu-map property. What is your opinion? Thanks, Nipun > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 > ++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > index 6611a7c..011c7d6 100644 > > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware > objects/devices > > such as network interfaces, crypto accelerator instances, L2 switches, > > etc. > > > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > > +drivers/staging/fsl-mc/README.txt > > + > > +As described in the above overview, all DPAA2 objects in a DPRC share the > > +same hardware "isolation context" and a 10-bit value called an ICID > > +(isolation context id) is expressed by the hardware to identify > > +the requester. > > IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know > they're currently documented under bindings/pci, but they're not really > intended to be absolutely PCI-specific. > > Robin. > > > +The generic 'iommus' property is cannot be used to describe the relationship > > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > > +the same. > > + > > +For generic IOMMU bindings, see > > +Documentation/devicetree/bindings/iommu/iommu.txt. > > + > > +For arm-smmu binding, see: > > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > > + > > Required properties: > > > > - compatible > > @@ -88,14 +106,27 @@ Sub-nodes: > > Value type: <phandle> > > Definition: Specifies the phandle to the PHY device node associated > > with the this dpmac. > > +Optional properties: > > + > > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > > + The property specifies the IOMMU behind which the devices on > > + fsl-mc bus are residing. > > > > Example: > > > > + smmu: iommu@5000000 { > > + compatible = "arm,mmu-500"; > > + #iommu-cells = <1>; > > + stream-match-mask = <0x7C00>; > > + ... > > + }; > > + > > fsl_mc: fsl-mc@80c000000 { > > compatible = "fsl,qoriq-mc"; > > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > > msi-parent = <&its>; > > + iommu-parent = <&smmu>; > > #address-cells = <3>; > > #size-cells = <1>; > > > > ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 15:00 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 15:00 UTC (permalink / raw) To: linux-arm-kernel > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy at arm.com] > Sent: Monday, March 05, 2018 20:23 > To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; > mark.rutland at arm.com; catalin.marinas at arm.com > Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de; > m.szyprowski at samsung.com; gregkh at linuxfoundation.org; joro at 8bytes.org; > Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux- > kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm- > kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com> > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On 05/03/18 14:29, Nipun Gupta wrote: > > The existing IOMMU bindings cannot be used to specify the relationship > > between fsl-mc devices and IOMMUs. This patch adds a binding for > > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > Given that allowing "msi-parent" for #msi-cells > 1 is merely a > backward-compatibility bodge full of hard-coded assumptions, why would > we want to knowingly introduce a similarly unpleasant equivalent for > IOMMUs? What's wrong with "iommu-map"? Hi Robin, With 'msi-parent' the property is fixed up to have msi-map. In this case there is no fixup required and simple 'iommu-parent' property can be used, with MC bus itself providing the stream-id's (in the code execution via FW). We can also use the iommu-map property similar to PCI, which will require u-boot fixup. But then it leads to little bit complications of u-boot - kernel compatibility. If you suggest we can re-use the iommu-map property. What is your opinion? Thanks, Nipun > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 > ++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > index 6611a7c..011c7d6 100644 > > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware > objects/devices > > such as network interfaces, crypto accelerator instances, L2 switches, > > etc. > > > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > > +drivers/staging/fsl-mc/README.txt > > + > > +As described in the above overview, all DPAA2 objects in a DPRC share the > > +same hardware "isolation context" and a 10-bit value called an ICID > > +(isolation context id) is expressed by the hardware to identify > > +the requester. > > IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know > they're currently documented under bindings/pci, but they're not really > intended to be absolutely PCI-specific. > > Robin. > > > +The generic 'iommus' property is cannot be used to describe the relationship > > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > > +the same. > > + > > +For generic IOMMU bindings, see > > +Documentation/devicetree/bindings/iommu/iommu.txt. > > + > > +For arm-smmu binding, see: > > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > > + > > Required properties: > > > > - compatible > > @@ -88,14 +106,27 @@ Sub-nodes: > > Value type: <phandle> > > Definition: Specifies the phandle to the PHY device node associated > > with the this dpmac. > > +Optional properties: > > + > > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > > + The property specifies the IOMMU behind which the devices on > > + fsl-mc bus are residing. > > > > Example: > > > > + smmu: iommu at 5000000 { > > + compatible = "arm,mmu-500"; > > + #iommu-cells = <1>; > > + stream-match-mask = <0x7C00>; > > + ... > > + }; > > + > > fsl_mc: fsl-mc at 80c000000 { > > compatible = "fsl,qoriq-mc"; > > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > > msi-parent = <&its>; > > + iommu-parent = <&smmu>; > > #address-cells = <3>; > > #size-cells = <1>; > > > > ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 15:00 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 15:00 UTC (permalink / raw) To: Robin Murphy, will.deacon, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIw MTggMjA6MjMNCj4gVG86IE5pcHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5k ZWFjb25AYXJtLmNvbTsNCj4gbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bh cm0uY29tDQo+IENjOiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBr ZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdr aEBsaW51eGZvdW5kYXRpb24ub3JnOyBqb3JvQDhieXRlcy5vcmc7DQo+IExlbyBMaSA8bGVveWFu Zy5saUBueHAuY29tPjsgc2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2Vy Lmtlcm5lbC5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtl cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg QmhhcmF0IEJodXNoYW4NCj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFp bC5jb207IExhdXJlbnRpdSBUdWRvcg0KPiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+IFN1 YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg ZGV2aWNlLXRyZWUgYmluZGluZw0KPiANCj4gT24gMDUvMDMvMTggMTQ6MjksIE5pcHVuIEd1cHRh IHdyb3RlOg0KPiA+IFRoZSBleGlzdGluZyBJT01NVSBiaW5kaW5ncyBjYW5ub3QgYmUgdXNlZCB0 byBzcGVjaWZ5IHRoZSByZWxhdGlvbnNoaXANCj4gPiBiZXR3ZWVuIGZzbC1tYyBkZXZpY2VzIGFu ZCBJT01NVXMuIFRoaXMgcGF0Y2ggYWRkcyBhIGJpbmRpbmcgZm9yDQo+ID4gbWFwcGluZyBmc2wt bWMgZGV2aWNlcyB0byBJT01NVXMsIHVzaW5nIGEgbmV3IGlvbW11LXBhcmVudCBwcm9wZXJ0eS4N Cj4gDQo+IEdpdmVuIHRoYXQgYWxsb3dpbmcgIm1zaS1wYXJlbnQiIGZvciAjbXNpLWNlbGxzID4g MSBpcyBtZXJlbHkgYQ0KPiBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IGJvZGdlIGZ1bGwgb2YgaGFy ZC1jb2RlZCBhc3N1bXB0aW9ucywgd2h5IHdvdWxkDQo+IHdlIHdhbnQgdG8ga25vd2luZ2x5IGlu dHJvZHVjZSBhIHNpbWlsYXJseSB1bnBsZWFzYW50IGVxdWl2YWxlbnQgZm9yDQo+IElPTU1Vcz8g V2hhdCdzIHdyb25nIHdpdGggImlvbW11LW1hcCI/DQoNCkhpIFJvYmluLA0KDQpXaXRoICdtc2kt cGFyZW50JyB0aGUgcHJvcGVydHkgaXMgZml4ZWQgdXAgdG8gaGF2ZSBtc2ktbWFwLiBJbiB0aGlz IGNhc2UgdGhlcmUgaXMNCm5vIGZpeHVwIHJlcXVpcmVkIGFuZCBzaW1wbGUgJ2lvbW11LXBhcmVu dCcgcHJvcGVydHkgY2FuIGJlIHVzZWQsIHdpdGggTUMgYnVzDQppdHNlbGYgcHJvdmlkaW5nIHRo ZSBzdHJlYW0taWQncyAoaW4gdGhlIGNvZGUgZXhlY3V0aW9uIHZpYSBGVykuDQoNCldlIGNhbiBh bHNvIHVzZSB0aGUgaW9tbXUtbWFwIHByb3BlcnR5IHNpbWlsYXIgdG8gUENJLCB3aGljaCB3aWxs IHJlcXVpcmUgdS1ib290DQpmaXh1cC4gQnV0IHRoZW4gaXQgbGVhZHMgdG8gbGl0dGxlIGJpdCBj b21wbGljYXRpb25zIG9mIHUtYm9vdCAtIGtlcm5lbCBjb21wYXRpYmlsaXR5Lg0KDQpJZiB5b3Ug c3VnZ2VzdCB3ZSBjYW4gcmUtdXNlIHRoZSBpb21tdS1tYXAgcHJvcGVydHkuIFdoYXQgaXMgeW91 ciBvcGluaW9uPw0KDQpUaGFua3MsDQpOaXB1bg0KDQo+IA0KPiA+IFNpZ25lZC1vZmYtYnk6IE5p cHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPg0KPiA+IC0tLQ0KPiA+ICAgLi4uL2Rldmlj ZXRyZWUvYmluZGluZ3MvbWlzYy9mc2wscW9yaXEtbWMudHh0ICAgICAgfCAzMQ0KPiArKysrKysr KysrKysrKysrKysrKysrDQo+ID4gICAxIGZpbGUgY2hhbmdlZCwgMzEgaW5zZXJ0aW9ucygrKQ0K PiA+DQo+ID4gZGlmZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9t aXNjL2ZzbCxxb3JpcS1tYy50eHQNCj4gYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGlu Z3MvbWlzYy9mc2wscW9yaXEtbWMudHh0DQo+ID4gaW5kZXggNjYxMWE3Yy4uMDExYzdkNiAxMDA2 NDQNCj4gPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvbWlzYy9mc2ws cW9yaXEtbWMudHh0DQo+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdz L21pc2MvZnNsLHFvcmlxLW1jLnR4dA0KPiA+IEBAIC05LDYgKzksMjQgQEAgYmxvY2tzIHRoYXQg Y2FuIGJlIHVzZWQgdG8gY3JlYXRlIGZ1bmN0aW9uYWwgaGFyZHdhcmUNCj4gb2JqZWN0cy9kZXZp Y2VzDQo+ID4gICBzdWNoIGFzIG5ldHdvcmsgaW50ZXJmYWNlcywgY3J5cHRvIGFjY2VsZXJhdG9y IGluc3RhbmNlcywgTDIgc3dpdGNoZXMsDQo+ID4gICBldGMuDQo+ID4NCj4gPiArRm9yIGFuIG92 ZXJ2aWV3IG9mIHRoZSBEUEFBMiBhcmNoaXRlY3R1cmUgYW5kIGZzbC1tYyBidXMgc2VlOg0KPiA+ ICtkcml2ZXJzL3N0YWdpbmcvZnNsLW1jL1JFQURNRS50eHQNCj4gPiArDQo+ID4gK0FzIGRlc2Ny aWJlZCBpbiB0aGUgYWJvdmUgb3ZlcnZpZXcsIGFsbCBEUEFBMiBvYmplY3RzIGluIGEgRFBSQyBz aGFyZSB0aGUNCj4gPiArc2FtZSBoYXJkd2FyZSAiaXNvbGF0aW9uIGNvbnRleHQiIGFuZCBhIDEw LWJpdCB2YWx1ZSBjYWxsZWQgYW4gSUNJRA0KPiA+ICsoaXNvbGF0aW9uIGNvbnRleHQgaWQpIGlz IGV4cHJlc3NlZCBieSB0aGUgaGFyZHdhcmUgdG8gaWRlbnRpZnkNCj4gPiArdGhlIHJlcXVlc3Rl ci4NCj4gDQo+IElPVywgcHJlY2lzZWx5IHRoZSBjYXNlIGZvciB3aGljaCAie21zaSxpb21tdX0t bWFwIiBleGlzdC4gWWVzLCBJIGtub3cNCj4gdGhleSdyZSBjdXJyZW50bHkgZG9jdW1lbnRlZCB1 bmRlciBiaW5kaW5ncy9wY2ksIGJ1dCB0aGV5J3JlIG5vdCByZWFsbHkNCj4gaW50ZW5kZWQgdG8g YmUgYWJzb2x1dGVseSBQQ0ktc3BlY2lmaWMuDQo+IA0KPiBSb2Jpbi4NCj4gDQo+ID4gK1RoZSBn ZW5lcmljICdpb21tdXMnIHByb3BlcnR5IGlzIGNhbm5vdCBiZSB1c2VkIHRvIGRlc2NyaWJlIHRo ZSByZWxhdGlvbnNoaXANCj4gPiArYmV0d2VlbiBmc2wtbWMgYW5kIElPTU1Vcywgc28gYW4gaW9t bXUtcGFyZW50IHByb3BlcnR5IGlzIHVzZWQgdG8gZGVmaW5lDQo+ID4gK3RoZSBzYW1lLg0KPiA+ ICsNCj4gPiArRm9yIGdlbmVyaWMgSU9NTVUgYmluZGluZ3MsIHNlZQ0KPiA+ICtEb2N1bWVudGF0 aW9uL2RldmljZXRyZWUvYmluZGluZ3MvaW9tbXUvaW9tbXUudHh0Lg0KPiA+ICsNCj4gPiArRm9y IGFybS1zbW11IGJpbmRpbmcsIHNlZToNCj4gPiArRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp bmRpbmdzL2lvbW11L2FybSxzbW11LnR4dC4NCj4gPiArDQo+ID4gICBSZXF1aXJlZCBwcm9wZXJ0 aWVzOg0KPiA+DQo+ID4gICAgICAgLSBjb21wYXRpYmxlDQo+ID4gQEAgLTg4LDE0ICsxMDYsMjcg QEAgU3ViLW5vZGVzOg0KPiA+ICAgICAgICAgICAgICAgICBWYWx1ZSB0eXBlOiA8cGhhbmRsZT4N Cj4gPiAgICAgICAgICAgICAgICAgRGVmaW5pdGlvbjogU3BlY2lmaWVzIHRoZSBwaGFuZGxlIHRv IHRoZSBQSFkgZGV2aWNlIG5vZGUgYXNzb2NpYXRlZA0KPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB3aXRoIHRoZSB0aGlzIGRwbWFjLg0KPiA+ICtPcHRpb25hbCBwcm9wZXJ0aWVzOg0K PiA+ICsNCj4gPiArLSBpb21tdS1wYXJlbnQ6IE1hcHMgdGhlIGRldmljZXMgb24gZnNsLW1jIGJ1 cyB0byBhbiBJT01NVS4NCj4gPiArICBUaGUgcHJvcGVydHkgc3BlY2lmaWVzIHRoZSBJT01NVSBi ZWhpbmQgd2hpY2ggdGhlIGRldmljZXMgb24NCj4gPiArICBmc2wtbWMgYnVzIGFyZSByZXNpZGlu Zy4NCj4gPg0KPiA+ICAgRXhhbXBsZToNCj4gPg0KPiA+ICsgICAgICAgIHNtbXU6IGlvbW11QDUw MDAwMDAgew0KPiA+ICsgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxtbXUtNTAwIjsN Cj4gPiArICAgICAgICAgICAgICAgI2lvbW11LWNlbGxzID0gPDE+Ow0KPiA+ICsgICAgICAgICAg ICAgICBzdHJlYW0tbWF0Y2gtbWFzayA9IDwweDdDMDA+Ow0KPiA+ICsgICAgICAgICAgICAgICAu Li4NCj4gPiArICAgICAgICB9Ow0KPiA+ICsNCj4gPiAgICAgICAgICAgZnNsX21jOiBmc2wtbWNA ODBjMDAwMDAwIHsNCj4gPiAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImZzbCxxb3Jp cS1tYyI7DQo+ID4gICAgICAgICAgICAgICAgICAgcmVnID0gPDB4MDAwMDAwMDggMHgwYzAwMDAw MCAwIDB4NDA+LCAgICAvKiBNQyBwb3J0YWwgYmFzZSAqLw0KPiA+ICAgICAgICAgICAgICAgICAg ICAgICAgIDwweDAwMDAwMDAwIDB4MDgzNDAwMDAgMCAweDQwMDAwPjsgLyogTUMgY29udHJvbCBy ZWcgKi8NCj4gPiAgICAgICAgICAgICAgICAgICBtc2ktcGFyZW50ID0gPCZpdHM+Ow0KPiA+ICsg ICAgICAgICAgICAgICAgaW9tbXUtcGFyZW50ID0gPCZzbW11PjsNCj4gPiAgICAgICAgICAgICAg ICAgICAjYWRkcmVzcy1jZWxscyA9IDwzPjsNCj4gPiAgICAgICAgICAgICAgICAgICAjc2l6ZS1j ZWxscyA9IDwxPjsNCj4gPg0KPiA+DQo= ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 15:37 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 15:37 UTC (permalink / raw) To: Nipun Gupta, will.deacon, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor On 05/03/18 15:00, Nipun Gupta wrote: > > >> -----Original Message----- >> From: Robin Murphy [mailto:robin.murphy@arm.com] >> Sent: Monday, March 05, 2018 20:23 >> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com; >> mark.rutland@arm.com; catalin.marinas@arm.com >> Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de; >> m.szyprowski@samsung.com; gregkh@linuxfoundation.org; joro@8bytes.org; >> Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux- >> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm- >> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan >> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor >> <laurentiu.tudor@nxp.com> >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding >> >> On 05/03/18 14:29, Nipun Gupta wrote: >>> The existing IOMMU bindings cannot be used to specify the relationship >>> between fsl-mc devices and IOMMUs. This patch adds a binding for >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. >> >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a >> backward-compatibility bodge full of hard-coded assumptions, why would >> we want to knowingly introduce a similarly unpleasant equivalent for >> IOMMUs? What's wrong with "iommu-map"? > > Hi Robin, > > With 'msi-parent' the property is fixed up to have msi-map. In this case there is > no fixup required and simple 'iommu-parent' property can be used, with MC bus > itself providing the stream-id's (in the code execution via FW). > > We can also use the iommu-map property similar to PCI, which will require u-boot > fixup. But then it leads to little bit complications of u-boot - kernel compatibility. What needs fixing up? With a stream-map-mask in place to ignore the upper Stream ID bits, you just need: iommu-map = <0 &smmu 0 0x80>; to say that the lower bits of the ICID value map directly to the lower bits of the Stream ID value - that's the same fixed property of the hardware that you're wanting to assume in iommu-parent. > If you suggest we can re-use the iommu-map property. What is your opinion? I think it makes a lot more sense to directly use the property which already exists, than to introduce a new one to merely assume one hard-coded value of the existing one. Extending msi-parent to msi-map was a case of "oops, it turns out we need more flexibility here"; for the case of iommu-map I can't imagine any justification for saying "oops, we need less flexibility here" (saving 9 whole bytes in the DT really is irrelevant). Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 15:37 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 15:37 UTC (permalink / raw) To: linux-arm-kernel On 05/03/18 15:00, Nipun Gupta wrote: > > >> -----Original Message----- >> From: Robin Murphy [mailto:robin.murphy at arm.com] >> Sent: Monday, March 05, 2018 20:23 >> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; >> mark.rutland at arm.com; catalin.marinas at arm.com >> Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de; >> m.szyprowski at samsung.com; gregkh at linuxfoundation.org; joro at 8bytes.org; >> Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux- >> kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm- >> kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan >> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor >> <laurentiu.tudor@nxp.com> >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding >> >> On 05/03/18 14:29, Nipun Gupta wrote: >>> The existing IOMMU bindings cannot be used to specify the relationship >>> between fsl-mc devices and IOMMUs. This patch adds a binding for >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. >> >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a >> backward-compatibility bodge full of hard-coded assumptions, why would >> we want to knowingly introduce a similarly unpleasant equivalent for >> IOMMUs? What's wrong with "iommu-map"? > > Hi Robin, > > With 'msi-parent' the property is fixed up to have msi-map. In this case there is > no fixup required and simple 'iommu-parent' property can be used, with MC bus > itself providing the stream-id's (in the code execution via FW). > > We can also use the iommu-map property similar to PCI, which will require u-boot > fixup. But then it leads to little bit complications of u-boot - kernel compatibility. What needs fixing up? With a stream-map-mask in place to ignore the upper Stream ID bits, you just need: iommu-map = <0 &smmu 0 0x80>; to say that the lower bits of the ICID value map directly to the lower bits of the Stream ID value - that's the same fixed property of the hardware that you're wanting to assume in iommu-parent. > If you suggest we can re-use the iommu-map property. What is your opinion? I think it makes a lot more sense to directly use the property which already exists, than to introduce a new one to merely assume one hard-coded value of the existing one. Extending msi-parent to msi-map was a case of "oops, it turns out we need more flexibility here"; for the case of iommu-map I can't imagine any justification for saying "oops, we need less flexibility here" (saving 9 whole bytes in the DT really is irrelevant). Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 15:37 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 15:37 UTC (permalink / raw) To: Nipun Gupta, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On 05/03/18 15:00, Nipun Gupta wrote: > > >> -----Original Message----- >> From: Robin Murphy [mailto:robin.murphy-5wv7dgnIgG8@public.gmane.org] >> Sent: Monday, March 05, 2018 20:23 >> To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; will.deacon-5wv7dgnIgG8@public.gmane.org; >> mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org >> Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; hch-jcswGhMUV9g@public.gmane.org; >> m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; >> Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org>; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; linux- >> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm- >> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Bharat Bhushan >> <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Laurentiu Tudor >> <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org> >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding >> >> On 05/03/18 14:29, Nipun Gupta wrote: >>> The existing IOMMU bindings cannot be used to specify the relationship >>> between fsl-mc devices and IOMMUs. This patch adds a binding for >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. >> >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a >> backward-compatibility bodge full of hard-coded assumptions, why would >> we want to knowingly introduce a similarly unpleasant equivalent for >> IOMMUs? What's wrong with "iommu-map"? > > Hi Robin, > > With 'msi-parent' the property is fixed up to have msi-map. In this case there is > no fixup required and simple 'iommu-parent' property can be used, with MC bus > itself providing the stream-id's (in the code execution via FW). > > We can also use the iommu-map property similar to PCI, which will require u-boot > fixup. But then it leads to little bit complications of u-boot - kernel compatibility. What needs fixing up? With a stream-map-mask in place to ignore the upper Stream ID bits, you just need: iommu-map = <0 &smmu 0 0x80>; to say that the lower bits of the ICID value map directly to the lower bits of the Stream ID value - that's the same fixed property of the hardware that you're wanting to assume in iommu-parent. > If you suggest we can re-use the iommu-map property. What is your opinion? I think it makes a lot more sense to directly use the property which already exists, than to introduce a new one to merely assume one hard-coded value of the existing one. Extending msi-parent to msi-map was a case of "oops, it turns out we need more flexibility here"; for the case of iommu-map I can't imagine any justification for saying "oops, we need less flexibility here" (saving 9 whole bytes in the DT really is irrelevant). Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding 2018-03-05 15:37 ` Robin Murphy (?) @ 2018-03-05 15:54 ` Nipun Gupta -1 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 15:54 UTC (permalink / raw) To: Robin Murphy, will.deacon, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Monday, March 05, 2018 21:07 > To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com; > mark.rutland@arm.com; catalin.marinas@arm.com > Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de; > m.szyprowski@samsung.com; gregkh@linuxfoundation.org; joro@8bytes.org; > Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com> > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On 05/03/18 15:00, Nipun Gupta wrote: > > > > > >> -----Original Message----- > >> From: Robin Murphy [mailto:robin.murphy@arm.com] > >> Sent: Monday, March 05, 2018 20:23 > >> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com; > >> mark.rutland@arm.com; catalin.marinas@arm.com > >> Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de; > >> m.szyprowski@samsung.com; gregkh@linuxfoundation.org; > joro@8bytes.org; > >> Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux- > >> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm- > >> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan > >> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor > >> <laurentiu.tudor@nxp.com> > >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree > binding > >> > >> On 05/03/18 14:29, Nipun Gupta wrote: > >>> The existing IOMMU bindings cannot be used to specify the relationship > >>> between fsl-mc devices and IOMMUs. This patch adds a binding for > >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > >> > >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a > >> backward-compatibility bodge full of hard-coded assumptions, why would > >> we want to knowingly introduce a similarly unpleasant equivalent for > >> IOMMUs? What's wrong with "iommu-map"? > > > > Hi Robin, > > > > With 'msi-parent' the property is fixed up to have msi-map. In this case there is > > no fixup required and simple 'iommu-parent' property can be used, with MC > bus > > itself providing the stream-id's (in the code execution via FW). > > > > We can also use the iommu-map property similar to PCI, which will require u- > boot > > fixup. But then it leads to little bit complications of u-boot - kernel > compatibility. > > What needs fixing up? With a stream-map-mask in place to ignore the > upper Stream ID bits, you just need: > > iommu-map = <0 &smmu 0 0x80>; > > to say that the lower bits of the ICID value map directly to the lower > bits of the Stream ID value - that's the same fixed property of the > hardware that you're wanting to assume in iommu-parent. Makes sense. I was going in a little bit wrong direction. Thanks for correcting. I will send v2 patchset with iommu-map property. Regards, Nipun > > > If you suggest we can re-use the iommu-map property. What is your opinion? > > I think it makes a lot more sense to directly use the property which > already exists, than to introduce a new one to merely assume one > hard-coded value of the existing one. Extending msi-parent to msi-map > was a case of "oops, it turns out we need more flexibility here"; for > the case of iommu-map I can't imagine any justification for saying > "oops, we need less flexibility here" (saving 9 whole bytes in the DT > really is irrelevant). > > Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 15:54 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 15:54 UTC (permalink / raw) To: linux-arm-kernel > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy at arm.com] > Sent: Monday, March 05, 2018 21:07 > To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; > mark.rutland at arm.com; catalin.marinas at arm.com > Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de; > m.szyprowski at samsung.com; gregkh at linuxfoundation.org; joro at 8bytes.org; > Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux- > kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm- > kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com> > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On 05/03/18 15:00, Nipun Gupta wrote: > > > > > >> -----Original Message----- > >> From: Robin Murphy [mailto:robin.murphy at arm.com] > >> Sent: Monday, March 05, 2018 20:23 > >> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; > >> mark.rutland at arm.com; catalin.marinas at arm.com > >> Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de; > >> m.szyprowski at samsung.com; gregkh at linuxfoundation.org; > joro at 8bytes.org; > >> Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux- > >> kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm- > >> kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan > >> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor > >> <laurentiu.tudor@nxp.com> > >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree > binding > >> > >> On 05/03/18 14:29, Nipun Gupta wrote: > >>> The existing IOMMU bindings cannot be used to specify the relationship > >>> between fsl-mc devices and IOMMUs. This patch adds a binding for > >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > >> > >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a > >> backward-compatibility bodge full of hard-coded assumptions, why would > >> we want to knowingly introduce a similarly unpleasant equivalent for > >> IOMMUs? What's wrong with "iommu-map"? > > > > Hi Robin, > > > > With 'msi-parent' the property is fixed up to have msi-map. In this case there is > > no fixup required and simple 'iommu-parent' property can be used, with MC > bus > > itself providing the stream-id's (in the code execution via FW). > > > > We can also use the iommu-map property similar to PCI, which will require u- > boot > > fixup. But then it leads to little bit complications of u-boot - kernel > compatibility. > > What needs fixing up? With a stream-map-mask in place to ignore the > upper Stream ID bits, you just need: > > iommu-map = <0 &smmu 0 0x80>; > > to say that the lower bits of the ICID value map directly to the lower > bits of the Stream ID value - that's the same fixed property of the > hardware that you're wanting to assume in iommu-parent. Makes sense. I was going in a little bit wrong direction. Thanks for correcting. I will send v2 patchset with iommu-map property. Regards, Nipun > > > If you suggest we can re-use the iommu-map property. What is your opinion? > > I think it makes a lot more sense to directly use the property which > already exists, than to introduce a new one to merely assume one > hard-coded value of the existing one. Extending msi-parent to msi-map > was a case of "oops, it turns out we need more flexibility here"; for > the case of iommu-map I can't imagine any justification for saying > "oops, we need less flexibility here" (saving 9 whole bytes in the DT > really is irrelevant). > > Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-05 15:54 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 15:54 UTC (permalink / raw) To: Robin Murphy, will.deacon, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIw MTggMjE6MDcNCj4gVG86IE5pcHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5k ZWFjb25AYXJtLmNvbTsNCj4gbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bh cm0uY29tDQo+IENjOiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBr ZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdr aEBsaW51eGZvdW5kYXRpb24ub3JnOyBqb3JvQDhieXRlcy5vcmc7DQo+IExlbyBMaSA8bGVveWFu Zy5saUBueHAuY29tPjsgc2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2Vy Lmtlcm5lbC5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtl cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg QmhhcmF0IEJodXNoYW4NCj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFp bC5jb207IExhdXJlbnRpdSBUdWRvcg0KPiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+IFN1 YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg ZGV2aWNlLXRyZWUgYmluZGluZw0KPiANCj4gT24gMDUvMDMvMTggMTU6MDAsIE5pcHVuIEd1cHRh IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogUm9iaW4gTXVycGh5IFttYWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+ID4+IFNl bnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIwMTggMjA6MjMNCj4gPj4gVG86IE5pcHVuIEd1cHRhIDxu aXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5kZWFjb25AYXJtLmNvbTsNCj4gPj4gbWFyay5ydXRs YW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tDQo+ID4+IENjOiBpb21tdUBsaXN0 cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBrZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0K PiA+PiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3Jn Ow0KPiBqb3JvQDhieXRlcy5vcmc7DQo+ID4+IExlbyBMaSA8bGVveWFuZy5saUBueHAuY29tPjsg c2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+ID4+IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7 IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+ID4+IGtlcm5lbEBsaXN0 cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgQmhhcmF0IEJo dXNoYW4NCj4gPj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFpbC5jb207 IExhdXJlbnRpdSBUdWRvcg0KPiA+PiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+ID4+IFN1 YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg ZGV2aWNlLXRyZWUNCj4gYmluZGluZw0KPiA+Pg0KPiA+PiBPbiAwNS8wMy8xOCAxNDoyOSwgTmlw dW4gR3VwdGEgd3JvdGU6DQo+ID4+PiBUaGUgZXhpc3RpbmcgSU9NTVUgYmluZGluZ3MgY2Fubm90 IGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgcmVsYXRpb25zaGlwDQo+ID4+PiBiZXR3ZWVuIGZzbC1t YyBkZXZpY2VzIGFuZCBJT01NVXMuIFRoaXMgcGF0Y2ggYWRkcyBhIGJpbmRpbmcgZm9yDQo+ID4+ PiBtYXBwaW5nIGZzbC1tYyBkZXZpY2VzIHRvIElPTU1VcywgdXNpbmcgYSBuZXcgaW9tbXUtcGFy ZW50IHByb3BlcnR5Lg0KPiA+Pg0KPiA+PiBHaXZlbiB0aGF0IGFsbG93aW5nICJtc2ktcGFyZW50 IiBmb3IgI21zaS1jZWxscyA+IDEgaXMgbWVyZWx5IGENCj4gPj4gYmFja3dhcmQtY29tcGF0aWJp bGl0eSBib2RnZSBmdWxsIG9mIGhhcmQtY29kZWQgYXNzdW1wdGlvbnMsIHdoeSB3b3VsZA0KPiA+ PiB3ZSB3YW50IHRvIGtub3dpbmdseSBpbnRyb2R1Y2UgYSBzaW1pbGFybHkgdW5wbGVhc2FudCBl cXVpdmFsZW50IGZvcg0KPiA+PiBJT01NVXM/IFdoYXQncyB3cm9uZyB3aXRoICJpb21tdS1tYXAi Pw0KPiA+DQo+ID4gSGkgUm9iaW4sDQo+ID4NCj4gPiBXaXRoICdtc2ktcGFyZW50JyB0aGUgcHJv cGVydHkgaXMgZml4ZWQgdXAgdG8gaGF2ZSBtc2ktbWFwLiBJbiB0aGlzIGNhc2UgdGhlcmUgaXMN Cj4gPiBubyBmaXh1cCByZXF1aXJlZCBhbmQgc2ltcGxlICdpb21tdS1wYXJlbnQnIHByb3BlcnR5 IGNhbiBiZSB1c2VkLCB3aXRoIE1DDQo+IGJ1cw0KPiA+IGl0c2VsZiBwcm92aWRpbmcgdGhlIHN0 cmVhbS1pZCdzIChpbiB0aGUgY29kZSBleGVjdXRpb24gdmlhIEZXKS4NCj4gPg0KPiA+IFdlIGNh biBhbHNvIHVzZSB0aGUgaW9tbXUtbWFwIHByb3BlcnR5IHNpbWlsYXIgdG8gUENJLCB3aGljaCB3 aWxsIHJlcXVpcmUgdS0NCj4gYm9vdA0KPiA+IGZpeHVwLiBCdXQgdGhlbiBpdCBsZWFkcyB0byBs aXR0bGUgYml0IGNvbXBsaWNhdGlvbnMgb2YgdS1ib290IC0ga2VybmVsDQo+IGNvbXBhdGliaWxp dHkuDQo+IA0KPiBXaGF0IG5lZWRzIGZpeGluZyB1cD8gV2l0aCBhIHN0cmVhbS1tYXAtbWFzayBp biBwbGFjZSB0byBpZ25vcmUgdGhlDQo+IHVwcGVyIFN0cmVhbSBJRCBiaXRzLCB5b3UganVzdCBu ZWVkOg0KPiANCj4gCWlvbW11LW1hcCA9IDwwICZzbW11IDAgMHg4MD47DQo+IA0KPiB0byBzYXkg dGhhdCB0aGUgbG93ZXIgYml0cyBvZiB0aGUgSUNJRCB2YWx1ZSBtYXAgZGlyZWN0bHkgdG8gdGhl IGxvd2VyDQo+IGJpdHMgb2YgdGhlIFN0cmVhbSBJRCB2YWx1ZSAtIHRoYXQncyB0aGUgc2FtZSBm aXhlZCBwcm9wZXJ0eSBvZiB0aGUNCj4gaGFyZHdhcmUgdGhhdCB5b3UncmUgd2FudGluZyB0byBh c3N1bWUgaW4gaW9tbXUtcGFyZW50Lg0KDQpNYWtlcyBzZW5zZS4gSSB3YXMgZ29pbmcgaW4gYSBs aXR0bGUgYml0IHdyb25nIGRpcmVjdGlvbi4gVGhhbmtzIGZvciBjb3JyZWN0aW5nLg0KSSB3aWxs IHNlbmQgdjIgcGF0Y2hzZXQgd2l0aCBpb21tdS1tYXAgcHJvcGVydHkuDQoNClJlZ2FyZHMsDQpO aXB1bg0KDQo+IA0KPiA+IElmIHlvdSBzdWdnZXN0IHdlIGNhbiByZS11c2UgdGhlIGlvbW11LW1h cCBwcm9wZXJ0eS4gV2hhdCBpcyB5b3VyIG9waW5pb24/DQo+IA0KPiBJIHRoaW5rIGl0IG1ha2Vz IGEgbG90IG1vcmUgc2Vuc2UgdG8gZGlyZWN0bHkgdXNlIHRoZSBwcm9wZXJ0eSB3aGljaA0KPiBh bHJlYWR5IGV4aXN0cywgdGhhbiB0byBpbnRyb2R1Y2UgYSBuZXcgb25lIHRvIG1lcmVseSBhc3N1 bWUgb25lDQo+IGhhcmQtY29kZWQgdmFsdWUgb2YgdGhlIGV4aXN0aW5nIG9uZS4gRXh0ZW5kaW5n IG1zaS1wYXJlbnQgdG8gbXNpLW1hcA0KPiB3YXMgYSBjYXNlIG9mICJvb3BzLCBpdCB0dXJucyBv dXQgd2UgbmVlZCBtb3JlIGZsZXhpYmlsaXR5IGhlcmUiOyBmb3INCj4gdGhlIGNhc2Ugb2YgaW9t bXUtbWFwIEkgY2FuJ3QgaW1hZ2luZSBhbnkganVzdGlmaWNhdGlvbiBmb3Igc2F5aW5nDQo+ICJv b3BzLCB3ZSBuZWVkIGxlc3MgZmxleGliaWxpdHkgaGVyZSIgKHNhdmluZyA5IHdob2xlIGJ5dGVz IGluIHRoZSBEVA0KPiByZWFsbHkgaXMgaXJyZWxldmFudCkuDQo+IA0KPiBSb2Jpbi4NCg== ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-07 22:40 ` Rob Herring 0 siblings, 0 replies; 106+ messages in thread From: Rob Herring @ 2018-03-07 22:40 UTC (permalink / raw) To: Nipun Gupta Cc: will.deacon, robin.murphy, mark.rutland, catalin.marinas, devicetree, stuyoder, bharat.bhushan, gregkh, joro, linuxppc-dev, linux-kernel, leoyang.li, iommu, laurentiu.tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote: > The existing IOMMU bindings cannot be used to specify the relationship > between fsl-mc devices and IOMMUs. This patch adds a binding for > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > --- > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > index 6611a7c..011c7d6 100644 > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices > such as network interfaces, crypto accelerator instances, L2 switches, > etc. > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > +drivers/staging/fsl-mc/README.txt > + > +As described in the above overview, all DPAA2 objects in a DPRC share the > +same hardware "isolation context" and a 10-bit value called an ICID > +(isolation context id) is expressed by the hardware to identify > +the requester. > + > +The generic 'iommus' property is cannot be used to describe the relationship > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > +the same. Why not? It is just a link between 2 nodes. > + > +For generic IOMMU bindings, see > +Documentation/devicetree/bindings/iommu/iommu.txt. > + > +For arm-smmu binding, see: > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > + > Required properties: > > - compatible > @@ -88,14 +106,27 @@ Sub-nodes: > Value type: <phandle> > Definition: Specifies the phandle to the PHY device node associated > with the this dpmac. > +Optional properties: > + > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > + The property specifies the IOMMU behind which the devices on > + fsl-mc bus are residing. If you want a generic property, this should be documented in the common binding. Couldn't you have more than 1 IOMMU upstream of a MC? > > Example: > > + smmu: iommu@5000000 { > + compatible = "arm,mmu-500"; > + #iommu-cells = <1>; > + stream-match-mask = <0x7C00>; > + ... > + }; > + > fsl_mc: fsl-mc@80c000000 { > compatible = "fsl,qoriq-mc"; > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > msi-parent = <&its>; > + iommu-parent = <&smmu>; > #address-cells = <3>; > #size-cells = <1>; > > -- > 1.9.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-07 22:40 ` Rob Herring 0 siblings, 0 replies; 106+ messages in thread From: Rob Herring @ 2018-03-07 22:40 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote: > The existing IOMMU bindings cannot be used to specify the relationship > between fsl-mc devices and IOMMUs. This patch adds a binding for > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > --- > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > index 6611a7c..011c7d6 100644 > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices > such as network interfaces, crypto accelerator instances, L2 switches, > etc. > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > +drivers/staging/fsl-mc/README.txt > + > +As described in the above overview, all DPAA2 objects in a DPRC share the > +same hardware "isolation context" and a 10-bit value called an ICID > +(isolation context id) is expressed by the hardware to identify > +the requester. > + > +The generic 'iommus' property is cannot be used to describe the relationship > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > +the same. Why not? It is just a link between 2 nodes. > + > +For generic IOMMU bindings, see > +Documentation/devicetree/bindings/iommu/iommu.txt. > + > +For arm-smmu binding, see: > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > + > Required properties: > > - compatible > @@ -88,14 +106,27 @@ Sub-nodes: > Value type: <phandle> > Definition: Specifies the phandle to the PHY device node associated > with the this dpmac. > +Optional properties: > + > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > + The property specifies the IOMMU behind which the devices on > + fsl-mc bus are residing. If you want a generic property, this should be documented in the common binding. Couldn't you have more than 1 IOMMU upstream of a MC? > > Example: > > + smmu: iommu at 5000000 { > + compatible = "arm,mmu-500"; > + #iommu-cells = <1>; > + stream-match-mask = <0x7C00>; > + ... > + }; > + > fsl_mc: fsl-mc at 80c000000 { > compatible = "fsl,qoriq-mc"; > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > msi-parent = <&its>; > + iommu-parent = <&smmu>; > #address-cells = <3>; > #size-cells = <1>; > > -- > 1.9.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-07 22:40 ` Rob Herring 0 siblings, 0 replies; 106+ messages in thread From: Rob Herring @ 2018-03-07 22:40 UTC (permalink / raw) To: Nipun Gupta Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, leoyang.li-3arQi8VN3Tc, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote: > The existing IOMMU bindings cannot be used to specify the relationship > between fsl-mc devices and IOMMUs. This patch adds a binding for > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> > --- > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > index 6611a7c..011c7d6 100644 > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices > such as network interfaces, crypto accelerator instances, L2 switches, > etc. > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > +drivers/staging/fsl-mc/README.txt > + > +As described in the above overview, all DPAA2 objects in a DPRC share the > +same hardware "isolation context" and a 10-bit value called an ICID > +(isolation context id) is expressed by the hardware to identify > +the requester. > + > +The generic 'iommus' property is cannot be used to describe the relationship > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > +the same. Why not? It is just a link between 2 nodes. > + > +For generic IOMMU bindings, see > +Documentation/devicetree/bindings/iommu/iommu.txt. > + > +For arm-smmu binding, see: > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > + > Required properties: > > - compatible > @@ -88,14 +106,27 @@ Sub-nodes: > Value type: <phandle> > Definition: Specifies the phandle to the PHY device node associated > with the this dpmac. > +Optional properties: > + > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > + The property specifies the IOMMU behind which the devices on > + fsl-mc bus are residing. If you want a generic property, this should be documented in the common binding. Couldn't you have more than 1 IOMMU upstream of a MC? > > Example: > > + smmu: iommu@5000000 { > + compatible = "arm,mmu-500"; > + #iommu-cells = <1>; > + stream-match-mask = <0x7C00>; > + ... > + }; > + > fsl_mc: fsl-mc@80c000000 { > compatible = "fsl,qoriq-mc"; > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > msi-parent = <&its>; > + iommu-parent = <&smmu>; > #address-cells = <3>; > #size-cells = <1>; > > -- > 1.9.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding 2018-03-07 22:40 ` Rob Herring (?) (?) @ 2018-03-08 12:32 ` Nipun Gupta -1 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-08 12:32 UTC (permalink / raw) To: Rob Herring Cc: will.deacon, robin.murphy, mark.rutland, catalin.marinas, devicetree, stuyoder, Bharat Bhushan, gregkh, joro, linuxppc-dev, linux-kernel, Leo Li, iommu, Laurentiu Tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski Hi Rob, > -----Original Message----- > From: Rob Herring [mailto:robh@kernel.org] > Sent: Thursday, March 08, 2018 4:10 > To: Nipun Gupta <nipun.gupta@nxp.com> > Cc: will.deacon@arm.com; robin.murphy@arm.com; mark.rutland@arm.com; > catalin.marinas@arm.com; devicetree@vger.kernel.org; stuyoder@gmail.com; > Bharat Bhushan <bharat.bhushan@nxp.com>; gregkh@linuxfoundation.org; > joro@8bytes.org; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; > Leo Li <leoyang.li@nxp.com>; iommu@lists.linux-foundation.org; Laurentiu > Tudor <laurentiu.tudor@nxp.com>; shawnguo@kernel.org; hch@lst.de; linux- > arm-kernel@lists.infradead.org; m.szyprowski@samsung.com > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote: > > The existing IOMMU bindings cannot be used to specify the relationship > > between fsl-mc devices and IOMMUs. This patch adds a binding for > > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 > ++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > index 6611a7c..011c7d6 100644 > > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware > objects/devices > > such as network interfaces, crypto accelerator instances, L2 switches, > > etc. > > > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > > +drivers/staging/fsl-mc/README.txt > > + > > +As described in the above overview, all DPAA2 objects in a DPRC share the > > +same hardware "isolation context" and a 10-bit value called an ICID > > +(isolation context id) is expressed by the hardware to identify > > +the requester. > > + > > +The generic 'iommus' property is cannot be used to describe the relationship > > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > > +the same. > > Why not? It is just a link between 2 nodes. We have #iommu-cells as '1' i.e. iommu will have one stream ID configured for a device. Once USB and other devices start to use IOMMU we will also need this iommu-cells. When #iommu-cells is defined as '1' and we have 'iommus=<&smmu>' compilation reports warning about the mismatch. In fsl-mc bus case we do not have any stream id associated with the bus. As suggested by Robin, we can simply use the iommu-map property. > > > + > > +For generic IOMMU bindings, see > > +Documentation/devicetree/bindings/iommu/iommu.txt. > > + > > +For arm-smmu binding, see: > > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > > + > > Required properties: > > > > - compatible > > @@ -88,14 +106,27 @@ Sub-nodes: > > Value type: <phandle> > > Definition: Specifies the phandle to the PHY device node associated > > with the this dpmac. > > +Optional properties: > > + > > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > > + The property specifies the IOMMU behind which the devices on > > + fsl-mc bus are residing. > > If you want a generic property, this should be documented in the common > binding. We can use the iommu-map property which is already documented. > > Couldn't you have more than 1 IOMMU upstream of a MC? There is no such device currently with which fsl-mc bus uses more than one iommu. Infact, our current systems have only single IOMMU :). Even in future if such devices are there then we can use iommu-map to specify more than one iommu with separate requester ID's (RID's). Thank you for review... Regards, Nipun > > > > > Example: > > > > + smmu: iommu@5000000 { > > + compatible = "arm,mmu-500"; > > + #iommu-cells = <1>; > > + stream-match-mask = <0x7C00>; > > + ... > > + }; > > + > > fsl_mc: fsl-mc@80c000000 { > > compatible = "fsl,qoriq-mc"; > > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > > msi-parent = <&its>; > > + iommu-parent = <&smmu>; > > #address-cells = <3>; > > #size-cells = <1>; > > > > -- > > 1.9.1 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fmailman%2Flistinfo%2Flinux-arm- > kernel&data=02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a > 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560 > 592302736942&sdata=iOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI > %3D&reserved=0 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-08 12:32 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-08 12:32 UTC (permalink / raw) To: linux-arm-kernel Hi Rob, > -----Original Message----- > From: Rob Herring [mailto:robh at kernel.org] > Sent: Thursday, March 08, 2018 4:10 > To: Nipun Gupta <nipun.gupta@nxp.com> > Cc: will.deacon at arm.com; robin.murphy at arm.com; mark.rutland at arm.com; > catalin.marinas at arm.com; devicetree at vger.kernel.org; stuyoder at gmail.com; > Bharat Bhushan <bharat.bhushan@nxp.com>; gregkh at linuxfoundation.org; > joro at 8bytes.org; linuxppc-dev at lists.ozlabs.org; linux-kernel at vger.kernel.org; > Leo Li <leoyang.li@nxp.com>; iommu at lists.linux-foundation.org; Laurentiu > Tudor <laurentiu.tudor@nxp.com>; shawnguo at kernel.org; hch at lst.de; linux- > arm-kernel at lists.infradead.org; m.szyprowski at samsung.com > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote: > > The existing IOMMU bindings cannot be used to specify the relationship > > between fsl-mc devices and IOMMUs. This patch adds a binding for > > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 > ++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > index 6611a7c..011c7d6 100644 > > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware > objects/devices > > such as network interfaces, crypto accelerator instances, L2 switches, > > etc. > > > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > > +drivers/staging/fsl-mc/README.txt > > + > > +As described in the above overview, all DPAA2 objects in a DPRC share the > > +same hardware "isolation context" and a 10-bit value called an ICID > > +(isolation context id) is expressed by the hardware to identify > > +the requester. > > + > > +The generic 'iommus' property is cannot be used to describe the relationship > > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > > +the same. > > Why not? It is just a link between 2 nodes. We have #iommu-cells as '1' i.e. iommu will have one stream ID configured for a device. Once USB and other devices start to use IOMMU we will also need this iommu-cells. When #iommu-cells is defined as '1' and we have 'iommus=<&smmu>' compilation reports warning about the mismatch. In fsl-mc bus case we do not have any stream id associated with the bus. As suggested by Robin, we can simply use the iommu-map property. > > > + > > +For generic IOMMU bindings, see > > +Documentation/devicetree/bindings/iommu/iommu.txt. > > + > > +For arm-smmu binding, see: > > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > > + > > Required properties: > > > > - compatible > > @@ -88,14 +106,27 @@ Sub-nodes: > > Value type: <phandle> > > Definition: Specifies the phandle to the PHY device node associated > > with the this dpmac. > > +Optional properties: > > + > > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > > + The property specifies the IOMMU behind which the devices on > > + fsl-mc bus are residing. > > If you want a generic property, this should be documented in the common > binding. We can use the iommu-map property which is already documented. > > Couldn't you have more than 1 IOMMU upstream of a MC? There is no such device currently with which fsl-mc bus uses more than one iommu. Infact, our current systems have only single IOMMU :). Even in future if such devices are there then we can use iommu-map to specify more than one iommu with separate requester ID's (RID's). Thank you for review... Regards, Nipun > > > > > Example: > > > > + smmu: iommu at 5000000 { > > + compatible = "arm,mmu-500"; > > + #iommu-cells = <1>; > > + stream-match-mask = <0x7C00>; > > + ... > > + }; > > + > > fsl_mc: fsl-mc at 80c000000 { > > compatible = "fsl,qoriq-mc"; > > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > > msi-parent = <&its>; > > + iommu-parent = <&smmu>; > > #address-cells = <3>; > > #size-cells = <1>; > > > > -- > > 1.9.1 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel at lists.infradead.org > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fmailman%2Flistinfo%2Flinux-arm- > kernel&data=02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a > 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560 > 592302736942&sdata=iOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI > %3D&reserved=0 ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-08 12:32 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-08 12:32 UTC (permalink / raw) To: Rob Herring Cc: will.deacon, robin.murphy, mark.rutland, catalin.marinas, devicetree, stuyoder, Bharat Bhushan, gregkh, joro, linuxppc-dev, linux-kernel, Leo Li, iommu, Laurentiu Tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski Hi Rob, > -----Original Message----- > From: Rob Herring [mailto:robh@kernel.org] > Sent: Thursday, March 08, 2018 4:10 > To: Nipun Gupta <nipun.gupta@nxp.com> > Cc: will.deacon@arm.com; robin.murphy@arm.com; mark.rutland@arm.com; > catalin.marinas@arm.com; devicetree@vger.kernel.org; stuyoder@gmail.com; > Bharat Bhushan <bharat.bhushan@nxp.com>; gregkh@linuxfoundation.org; > joro@8bytes.org; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.= org; > Leo Li <leoyang.li@nxp.com>; iommu@lists.linux-foundation.org; Laurentiu > Tudor <laurentiu.tudor@nxp.com>; shawnguo@kernel.org; hch@lst.de; linux- > arm-kernel@lists.infradead.org; m.szyprowski@samsung.com > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree bi= nding >=20 > On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote: > > The existing IOMMU bindings cannot be used to specify the relationship > > between fsl-mc devices and IOMMUs. This patch adds a binding for > > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 > ++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > index 6611a7c..011c7d6 100644 > > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware > objects/devices > > such as network interfaces, crypto accelerator instances, L2 switches, > > etc. > > > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > > +drivers/staging/fsl-mc/README.txt > > + > > +As described in the above overview, all DPAA2 objects in a DPRC share = the > > +same hardware "isolation context" and a 10-bit value called an ICID > > +(isolation context id) is expressed by the hardware to identify > > +the requester. > > + > > +The generic 'iommus' property is cannot be used to describe the relati= onship > > +between fsl-mc and IOMMUs, so an iommu-parent property is used to defi= ne > > +the same. >=20 > Why not? It is just a link between 2 nodes. We have #iommu-cells as '1' i.e. iommu will have one stream ID configured f= or a device. Once USB and other devices start to use IOMMU we will also need this iommu-= cells. When #iommu-cells is defined as '1' and we have 'iommus=3D<&smmu>' compilat= ion reports warning about the mismatch. In fsl-mc bus case we do not have any stream id associated with the bus. As suggested by Robin, we can simply use the iommu-map property. >=20 > > + > > +For generic IOMMU bindings, see > > +Documentation/devicetree/bindings/iommu/iommu.txt. > > + > > +For arm-smmu binding, see: > > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > > + > > Required properties: > > > > - compatible > > @@ -88,14 +106,27 @@ Sub-nodes: > > Value type: <phandle> > > Definition: Specifies the phandle to the PHY device node= associated > > with the this dpmac. > > +Optional properties: > > + > > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > > + The property specifies the IOMMU behind which the devices on > > + fsl-mc bus are residing. >=20 > If you want a generic property, this should be documented in the common > binding. We can use the iommu-map property which is already documented. >=20 > Couldn't you have more than 1 IOMMU upstream of a MC? There is no such device currently with which fsl-mc bus uses more than one = iommu. Infact, our current systems have only single IOMMU :). Even in future if such devices are there then we can use iommu-map to speci= fy more than one iommu with separate requester ID's (RID's). Thank you for review... Regards, Nipun >=20 > > > > Example: > > > > + smmu: iommu@5000000 { > > + compatible =3D "arm,mmu-500"; > > + #iommu-cells =3D <1>; > > + stream-match-mask =3D <0x7C00>; > > + ... > > + }; > > + > > fsl_mc: fsl-mc@80c000000 { > > compatible =3D "fsl,qoriq-mc"; > > reg =3D <0x00000008 0x0c000000 0 0x40>, /* MC porta= l base */ > > <0x00000000 0x08340000 0 0x40000>; /* MC control= reg */ > > msi-parent =3D <&its>; > > + iommu-parent =3D <&smmu>; > > #address-cells =3D <3>; > > #size-cells =3D <1>; > > > > -- > > 1.9.1 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Flists= .infr > adead.org%2Fmailman%2Flistinfo%2Flinux-arm- > kernel&data=3D02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a > 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560 > 592302736942&sdata=3DiOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI > %3D&reserved=3D0 ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding @ 2018-03-08 12:32 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-08 12:32 UTC (permalink / raw) To: Rob Herring Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, Leo Li, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Hi Rob, > -----Original Message----- > From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org] > Sent: Thursday, March 08, 2018 4:10 > To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> > Cc: will.deacon-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; > catalin.marinas-5wv7dgnIgG8@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; > Bharat Bhushan <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; > joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; > Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Laurentiu > Tudor <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org>; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; hch-jcswGhMUV9g@public.gmane.org; linux- > arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org > Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding > > On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote: > > The existing IOMMU bindings cannot be used to specify the relationship > > between fsl-mc devices and IOMMUs. This patch adds a binding for > > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. > > > > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> > > --- > > .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 > ++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > index 6611a7c..011c7d6 100644 > > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware > objects/devices > > such as network interfaces, crypto accelerator instances, L2 switches, > > etc. > > > > +For an overview of the DPAA2 architecture and fsl-mc bus see: > > +drivers/staging/fsl-mc/README.txt > > + > > +As described in the above overview, all DPAA2 objects in a DPRC share the > > +same hardware "isolation context" and a 10-bit value called an ICID > > +(isolation context id) is expressed by the hardware to identify > > +the requester. > > + > > +The generic 'iommus' property is cannot be used to describe the relationship > > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define > > +the same. > > Why not? It is just a link between 2 nodes. We have #iommu-cells as '1' i.e. iommu will have one stream ID configured for a device. Once USB and other devices start to use IOMMU we will also need this iommu-cells. When #iommu-cells is defined as '1' and we have 'iommus=<&smmu>' compilation reports warning about the mismatch. In fsl-mc bus case we do not have any stream id associated with the bus. As suggested by Robin, we can simply use the iommu-map property. > > > + > > +For generic IOMMU bindings, see > > +Documentation/devicetree/bindings/iommu/iommu.txt. > > + > > +For arm-smmu binding, see: > > +Documentation/devicetree/bindings/iommu/arm,smmu.txt. > > + > > Required properties: > > > > - compatible > > @@ -88,14 +106,27 @@ Sub-nodes: > > Value type: <phandle> > > Definition: Specifies the phandle to the PHY device node associated > > with the this dpmac. > > +Optional properties: > > + > > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU. > > + The property specifies the IOMMU behind which the devices on > > + fsl-mc bus are residing. > > If you want a generic property, this should be documented in the common > binding. We can use the iommu-map property which is already documented. > > Couldn't you have more than 1 IOMMU upstream of a MC? There is no such device currently with which fsl-mc bus uses more than one iommu. Infact, our current systems have only single IOMMU :). Even in future if such devices are there then we can use iommu-map to specify more than one iommu with separate requester ID's (RID's). Thank you for review... Regards, Nipun > > > > > Example: > > > > + smmu: iommu@5000000 { > > + compatible = "arm,mmu-500"; > > + #iommu-cells = <1>; > > + stream-match-mask = <0x7C00>; > > + ... > > + }; > > + > > fsl_mc: fsl-mc@80c000000 { > > compatible = "fsl,qoriq-mc"; > > reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > > <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > > msi-parent = <&its>; > > + iommu-parent = <&smmu>; > > #address-cells = <3>; > > #size-cells = <1>; > > > > -- > > 1.9.1 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fmailman%2Flistinfo%2Flinux-arm- > kernel&data=02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a > 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560 > 592302736942&sdata=iOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI > %3D&reserved=0 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 2/6] iommu: support iommu configuration for fsl-mc devices @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon, robin.murphy, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor, Nipun Gupta Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..cc2fb9c 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -24,6 +24,7 @@ #include <linux/of_iommu.h> #include <linux/of_pci.h> #include <linux/slab.h> +#include <linux/fsl/mc.h> #define NO_IOMMU 1 @@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) return err; } +static int +of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev, + struct device_node *master_np) +{ + struct of_phandle_args iommu_spec; + int err; + + iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0); + if (!iommu_spec.np) + return NO_IOMMU; + + iommu_spec.args[0] = mc_dev->icid; + iommu_spec.args_count = 1; + + err = of_iommu_xlate(&mc_dev->dev, &iommu_spec); + of_node_put(iommu_spec.np); + + return err; +} + const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np) { @@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev, err = pci_for_each_dma_alias(to_pci_dev(dev), of_pci_iommu_init, &info); + } else if (dev_is_fsl_mc(dev)) { + err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np); } else { struct of_phandle_args iommu_spec; int idx = 0; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 2/6] iommu: support iommu configuration for fsl-mc devices @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..cc2fb9c 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -24,6 +24,7 @@ #include <linux/of_iommu.h> #include <linux/of_pci.h> #include <linux/slab.h> +#include <linux/fsl/mc.h> #define NO_IOMMU 1 @@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) return err; } +static int +of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev, + struct device_node *master_np) +{ + struct of_phandle_args iommu_spec; + int err; + + iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0); + if (!iommu_spec.np) + return NO_IOMMU; + + iommu_spec.args[0] = mc_dev->icid; + iommu_spec.args_count = 1; + + err = of_iommu_xlate(&mc_dev->dev, &iommu_spec); + of_node_put(iommu_spec.np); + + return err; +} + const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np) { @@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev, err = pci_for_each_dma_alias(to_pci_dev(dev), of_pci_iommu_init, &info); + } else if (dev_is_fsl_mc(dev)) { + err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np); } else { struct of_phandle_args iommu_spec; int idx = 0; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 2/6] iommu: support iommu configuration for fsl-mc devices @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon-5wv7dgnIgG8, robin.murphy-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..cc2fb9c 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -24,6 +24,7 @@ #include <linux/of_iommu.h> #include <linux/of_pci.h> #include <linux/slab.h> +#include <linux/fsl/mc.h> #define NO_IOMMU 1 @@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) return err; } +static int +of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev, + struct device_node *master_np) +{ + struct of_phandle_args iommu_spec; + int err; + + iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0); + if (!iommu_spec.np) + return NO_IOMMU; + + iommu_spec.args[0] = mc_dev->icid; + iommu_spec.args_count = 1; + + err = of_iommu_xlate(&mc_dev->dev, &iommu_spec); + of_node_put(iommu_spec.np); + + return err; +} + const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np) { @@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev, err = pci_for_each_dma_alias(to_pci_dev(dev), of_pci_iommu_init, &info); + } else if (dev_is_fsl_mc(dev)) { + err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np); } else { struct of_phandle_args iommu_spec; int idx = 0; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon, robin.murphy, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor, Nipun Gupta Implement bus specific support for the fsl-mc bus including registering arm_smmu_ops and bus specific device add operations. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/arm-smmu.c | 7 +++++++ drivers/iommu/iommu.c | 21 +++++++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++++ include/linux/iommu.h | 2 ++ 4 files changed, 38 insertions(+) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 69e7c60..e1d5090 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -52,6 +52,7 @@ #include <linux/spinlock.h> #include <linux/amba/bus.h> +#include <linux/fsl/mc.h> #include "io-pgtable.h" #include "arm-smmu-regs.h" @@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev) if (dev_is_pci(dev)) group = pci_device_group(dev); + else if (dev_is_fsl_mc(dev)) + group = fsl_mc_device_group(dev); else group = generic_device_group(dev); @@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void) bus_set_iommu(&pci_bus_type, &arm_smmu_ops); } #endif +#ifdef CONFIG_FSL_MC_BUS + if (!iommu_present(&fsl_mc_bus_type)) + bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops); +#endif } static int arm_smmu_device_probe(struct platform_device *pdev) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 69fef99..fbeebb2 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -32,6 +32,7 @@ #include <linux/pci.h> #include <linux/bitops.h> #include <linux/property.h> +#include <linux/fsl/mc.h> #include <trace/events/iommu.h> static struct kset *iommu_group_kset; @@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev) return iommu_group_alloc(); } +/* Get the IOMMU group for device on fsl-mc bus */ +struct iommu_group *fsl_mc_device_group(struct device *dev) +{ + struct device *cont_dev = fsl_mc_cont_dev(dev); + struct iommu_group *group; + + /* Container device is responsible for creating the iommu group */ + if (fsl_mc_is_cont_dev(dev)) { + group = iommu_group_alloc(); + if (IS_ERR(group)) + return NULL; + } else { + get_device(cont_dev); + group = iommu_group_get(cont_dev); + put_device(cont_dev); + } + + return group; +} + /** * iommu_group_get_for_dev - Find or create the IOMMU group for a device * @dev: target device diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h index 765ba41..ae9382b 100644 --- a/include/linux/fsl/mc.h +++ b/include/linux/fsl/mc.h @@ -351,6 +351,14 @@ struct fsl_mc_io { #define dev_is_fsl_mc(_dev) (0) #endif +/* Macro to check if a device is a container device */ +#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \ + FSL_MC_IS_DPRC) + +/* Macro to get the container device of a MC device */ +#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \ + (_dev) : (_dev)->parent) + /* * module_fsl_mc_driver() - Helper macro for drivers that don't do * anything special in module init/exit. This eliminates a lot of diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 41b8c57..00a460b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain, extern struct iommu_group *pci_device_group(struct device *dev); /* Generic device grouping function */ extern struct iommu_group *generic_device_group(struct device *dev); +/* FSL-MC device grouping function */ +struct iommu_group *fsl_mc_device_group(struct device *dev); /** * struct iommu_fwspec - per-device IOMMU instance data -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: linux-arm-kernel Implement bus specific support for the fsl-mc bus including registering arm_smmu_ops and bus specific device add operations. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/arm-smmu.c | 7 +++++++ drivers/iommu/iommu.c | 21 +++++++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++++ include/linux/iommu.h | 2 ++ 4 files changed, 38 insertions(+) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 69e7c60..e1d5090 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -52,6 +52,7 @@ #include <linux/spinlock.h> #include <linux/amba/bus.h> +#include <linux/fsl/mc.h> #include "io-pgtable.h" #include "arm-smmu-regs.h" @@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev) if (dev_is_pci(dev)) group = pci_device_group(dev); + else if (dev_is_fsl_mc(dev)) + group = fsl_mc_device_group(dev); else group = generic_device_group(dev); @@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void) bus_set_iommu(&pci_bus_type, &arm_smmu_ops); } #endif +#ifdef CONFIG_FSL_MC_BUS + if (!iommu_present(&fsl_mc_bus_type)) + bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops); +#endif } static int arm_smmu_device_probe(struct platform_device *pdev) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 69fef99..fbeebb2 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -32,6 +32,7 @@ #include <linux/pci.h> #include <linux/bitops.h> #include <linux/property.h> +#include <linux/fsl/mc.h> #include <trace/events/iommu.h> static struct kset *iommu_group_kset; @@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev) return iommu_group_alloc(); } +/* Get the IOMMU group for device on fsl-mc bus */ +struct iommu_group *fsl_mc_device_group(struct device *dev) +{ + struct device *cont_dev = fsl_mc_cont_dev(dev); + struct iommu_group *group; + + /* Container device is responsible for creating the iommu group */ + if (fsl_mc_is_cont_dev(dev)) { + group = iommu_group_alloc(); + if (IS_ERR(group)) + return NULL; + } else { + get_device(cont_dev); + group = iommu_group_get(cont_dev); + put_device(cont_dev); + } + + return group; +} + /** * iommu_group_get_for_dev - Find or create the IOMMU group for a device * @dev: target device diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h index 765ba41..ae9382b 100644 --- a/include/linux/fsl/mc.h +++ b/include/linux/fsl/mc.h @@ -351,6 +351,14 @@ struct fsl_mc_io { #define dev_is_fsl_mc(_dev) (0) #endif +/* Macro to check if a device is a container device */ +#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \ + FSL_MC_IS_DPRC) + +/* Macro to get the container device of a MC device */ +#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \ + (_dev) : (_dev)->parent) + /* * module_fsl_mc_driver() - Helper macro for drivers that don't do * anything special in module init/exit. This eliminates a lot of diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 41b8c57..00a460b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain, extern struct iommu_group *pci_device_group(struct device *dev); /* Generic device grouping function */ extern struct iommu_group *generic_device_group(struct device *dev); +/* FSL-MC device grouping function */ +struct iommu_group *fsl_mc_device_group(struct device *dev); /** * struct iommu_fwspec - per-device IOMMU instance data -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon-5wv7dgnIgG8, robin.murphy-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Implement bus specific support for the fsl-mc bus including registering arm_smmu_ops and bus specific device add operations. Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/iommu/arm-smmu.c | 7 +++++++ drivers/iommu/iommu.c | 21 +++++++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++++ include/linux/iommu.h | 2 ++ 4 files changed, 38 insertions(+) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 69e7c60..e1d5090 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -52,6 +52,7 @@ #include <linux/spinlock.h> #include <linux/amba/bus.h> +#include <linux/fsl/mc.h> #include "io-pgtable.h" #include "arm-smmu-regs.h" @@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev) if (dev_is_pci(dev)) group = pci_device_group(dev); + else if (dev_is_fsl_mc(dev)) + group = fsl_mc_device_group(dev); else group = generic_device_group(dev); @@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void) bus_set_iommu(&pci_bus_type, &arm_smmu_ops); } #endif +#ifdef CONFIG_FSL_MC_BUS + if (!iommu_present(&fsl_mc_bus_type)) + bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops); +#endif } static int arm_smmu_device_probe(struct platform_device *pdev) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 69fef99..fbeebb2 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -32,6 +32,7 @@ #include <linux/pci.h> #include <linux/bitops.h> #include <linux/property.h> +#include <linux/fsl/mc.h> #include <trace/events/iommu.h> static struct kset *iommu_group_kset; @@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev) return iommu_group_alloc(); } +/* Get the IOMMU group for device on fsl-mc bus */ +struct iommu_group *fsl_mc_device_group(struct device *dev) +{ + struct device *cont_dev = fsl_mc_cont_dev(dev); + struct iommu_group *group; + + /* Container device is responsible for creating the iommu group */ + if (fsl_mc_is_cont_dev(dev)) { + group = iommu_group_alloc(); + if (IS_ERR(group)) + return NULL; + } else { + get_device(cont_dev); + group = iommu_group_get(cont_dev); + put_device(cont_dev); + } + + return group; +} + /** * iommu_group_get_for_dev - Find or create the IOMMU group for a device * @dev: target device diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h index 765ba41..ae9382b 100644 --- a/include/linux/fsl/mc.h +++ b/include/linux/fsl/mc.h @@ -351,6 +351,14 @@ struct fsl_mc_io { #define dev_is_fsl_mc(_dev) (0) #endif +/* Macro to check if a device is a container device */ +#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \ + FSL_MC_IS_DPRC) + +/* Macro to get the container device of a MC device */ +#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \ + (_dev) : (_dev)->parent) + /* * module_fsl_mc_driver() - Helper macro for drivers that don't do * anything special in module init/exit. This eliminates a lot of diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 41b8c57..00a460b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain, extern struct iommu_group *pci_device_group(struct device *dev); /* Generic device grouping function */ extern struct iommu_group *generic_device_group(struct device *dev); +/* FSL-MC device grouping function */ +struct iommu_group *fsl_mc_device_group(struct device *dev); /** * struct iommu_fwspec - per-device IOMMU instance data -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon, robin.murphy, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor, Nipun Gupta The dma setup for fsl-mc devices is being done from device_add() function. So, no need to call in mc bus driver. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 1b333c4..c9a239a 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, mc_dev->icid = parent_mc_dev->icid; mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK; mc_dev->dev.dma_mask = &mc_dev->dma_mask; + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask; dev_set_msi_domain(&mc_dev->dev, dev_get_msi_domain(&parent_mc_dev->dev)); } @@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, goto error_cleanup_dev; } - /* Objects are coherent, unless 'no shareability' flag set. */ - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY)) - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); - /* * The device-specific probe callback will get invoked by device_add() */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: linux-arm-kernel The dma setup for fsl-mc devices is being done from device_add() function. So, no need to call in mc bus driver. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 1b333c4..c9a239a 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, mc_dev->icid = parent_mc_dev->icid; mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK; mc_dev->dev.dma_mask = &mc_dev->dma_mask; + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask; dev_set_msi_domain(&mc_dev->dev, dev_get_msi_domain(&parent_mc_dev->dev)); } @@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, goto error_cleanup_dev; } - /* Objects are coherent, unless 'no shareability' flag set. */ - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY)) - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); - /* * The device-specific probe callback will get invoked by device_add() */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon-5wv7dgnIgG8, robin.murphy-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r The dma setup for fsl-mc devices is being done from device_add() function. So, no need to call in mc bus driver. Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 1b333c4..c9a239a 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, mc_dev->icid = parent_mc_dev->icid; mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK; mc_dev->dev.dma_mask = &mc_dev->dma_mask; + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask; dev_set_msi_domain(&mc_dev->dev, dev_get_msi_domain(&parent_mc_dev->dev)); } @@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, goto error_cleanup_dev; } - /* Objects are coherent, unless 'no shareability' flag set. */ - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY)) - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); - /* * The device-specific probe callback will get invoked by device_add() */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon, robin.murphy, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor, Nipun Gupta Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/base/dma-mapping.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index 3b11835..2279c4d 100644 --- a/drivers/base/dma-mapping.c +++ b/drivers/base/dma-mapping.c @@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags) * Common configuration to enable DMA API use for a device */ #include <linux/pci.h> +#include <linux/fsl/mc.h> int dma_configure(struct device *dev) { @@ -349,6 +350,12 @@ int dma_configure(struct device *dev) dma_dev = dma_dev->parent; } + if (dev_is_fsl_mc(dev)) { + dma_dev = dev; + while (dev_is_fsl_mc(dma_dev)) + dma_dev = dma_dev->parent; + } + if (dma_dev->of_node) { ret = of_dma_configure(dev, dma_dev->of_node); } else if (has_acpi_companion(dma_dev)) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/base/dma-mapping.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index 3b11835..2279c4d 100644 --- a/drivers/base/dma-mapping.c +++ b/drivers/base/dma-mapping.c @@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags) * Common configuration to enable DMA API use for a device */ #include <linux/pci.h> +#include <linux/fsl/mc.h> int dma_configure(struct device *dev) { @@ -349,6 +350,12 @@ int dma_configure(struct device *dev) dma_dev = dma_dev->parent; } + if (dev_is_fsl_mc(dev)) { + dma_dev = dev; + while (dev_is_fsl_mc(dma_dev)) + dma_dev = dma_dev->parent; + } + if (dma_dev->of_node) { ret = of_dma_configure(dev, dma_dev->of_node); } else if (has_acpi_companion(dma_dev)) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon-5wv7dgnIgG8, robin.murphy-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/base/dma-mapping.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index 3b11835..2279c4d 100644 --- a/drivers/base/dma-mapping.c +++ b/drivers/base/dma-mapping.c @@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags) * Common configuration to enable DMA API use for a device */ #include <linux/pci.h> +#include <linux/fsl/mc.h> int dma_configure(struct device *dev) { @@ -349,6 +350,12 @@ int dma_configure(struct device *dev) dma_dev = dma_dev->parent; } + if (dev_is_fsl_mc(dev)) { + dma_dev = dev; + while (dev_is_fsl_mc(dma_dev)) + dma_dev = dma_dev->parent; + } + if (dma_dev->of_node) { ret = of_dma_configure(dev, dma_dev->of_node); } else if (has_acpi_companion(dma_dev)) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus 2018-03-05 14:29 ` Nipun Gupta @ 2018-03-05 15:08 ` Christoph Hellwig -1 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-05 15:08 UTC (permalink / raw) To: Nipun Gupta Cc: will.deacon, robin.murphy, mark.rutland, catalin.marinas, iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor We should not add any new hardocded busses here. Please mark them in OF/ACPI. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 15:08 ` Christoph Hellwig 0 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-05 15:08 UTC (permalink / raw) To: linux-arm-kernel We should not add any new hardocded busses here. Please mark them in OF/ACPI. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 15:48 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 15:48 UTC (permalink / raw) To: Christoph Hellwig Cc: Nipun Gupta, will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor On 05/03/18 15:08, Christoph Hellwig wrote: > We should not add any new hardocded busses here. Please mark them in > OF/ACPI. Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's software-discoverable and the only thing described in DT is the bus "host", thus we need the same sort of thing as for PCI to map from the child devices back to the bus root in order to find the appropriate firmware node. Worse than PCI, though, we wouldn't even have the option of describing child devices statically in firmware at all, since it's actually one of these runtime-configurable "build your own network accelerator" hardware pools where userspace gets to create and destroy "devices" as it likes. Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 15:48 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 15:48 UTC (permalink / raw) To: linux-arm-kernel On 05/03/18 15:08, Christoph Hellwig wrote: > We should not add any new hardocded busses here. Please mark them in > OF/ACPI. Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's software-discoverable and the only thing described in DT is the bus "host", thus we need the same sort of thing as for PCI to map from the child devices back to the bus root in order to find the appropriate firmware node. Worse than PCI, though, we wouldn't even have the option of describing child devices statically in firmware at all, since it's actually one of these runtime-configurable "build your own network accelerator" hardware pools where userspace gets to create and destroy "devices" as it likes. Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 15:48 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 15:48 UTC (permalink / raw) To: Christoph Hellwig Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On 05/03/18 15:08, Christoph Hellwig wrote: > We should not add any new hardocded busses here. Please mark them in > OF/ACPI. Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's software-discoverable and the only thing described in DT is the bus "host", thus we need the same sort of thing as for PCI to map from the child devices back to the bus root in order to find the appropriate firmware node. Worse than PCI, though, we wouldn't even have the option of describing child devices statically in firmware at all, since it's actually one of these runtime-configurable "build your own network accelerator" hardware pools where userspace gets to create and destroy "devices" as it likes. Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 18:39 ` Christoph Hellwig 0 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-05 18:39 UTC (permalink / raw) To: Robin Murphy Cc: Christoph Hellwig, Nipun Gupta, will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: > Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > software-discoverable and the only thing described in DT is the bus "host", > thus we need the same sort of thing as for PCI to map from the child > devices back to the bus root in order to find the appropriate firmware > node. Worse than PCI, though, we wouldn't even have the option of > describing child devices statically in firmware at all, since it's actually > one of these runtime-configurable "build your own network accelerator" > hardware pools where userspace gets to create and destroy "devices" as it > likes. I really hate the PCI special case just as much. Maybe we just need a dma_configure method on the bus, and move PCI as well as fsl-mc to it. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 18:39 ` Christoph Hellwig 0 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-05 18:39 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: > Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > software-discoverable and the only thing described in DT is the bus "host", > thus we need the same sort of thing as for PCI to map from the child > devices back to the bus root in order to find the appropriate firmware > node. Worse than PCI, though, we wouldn't even have the option of > describing child devices statically in firmware at all, since it's actually > one of these runtime-configurable "build your own network accelerator" > hardware pools where userspace gets to create and destroy "devices" as it > likes. I really hate the PCI special case just as much. Maybe we just need a dma_configure method on the bus, and move PCI as well as fsl-mc to it. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 18:39 ` Christoph Hellwig 0 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-05 18:39 UTC (permalink / raw) To: Robin Murphy Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, Christoph Hellwig, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: > Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > software-discoverable and the only thing described in DT is the bus "host", > thus we need the same sort of thing as for PCI to map from the child > devices back to the bus root in order to find the appropriate firmware > node. Worse than PCI, though, we wouldn't even have the option of > describing child devices statically in firmware at all, since it's actually > one of these runtime-configurable "build your own network accelerator" > hardware pools where userspace gets to create and destroy "devices" as it > likes. I really hate the PCI special case just as much. Maybe we just need a dma_configure method on the bus, and move PCI as well as fsl-mc to it. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 18:51 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 18:51 UTC (permalink / raw) To: Christoph Hellwig Cc: Nipun Gupta, will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor On 05/03/18 18:39, Christoph Hellwig wrote: > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's >> software-discoverable and the only thing described in DT is the bus "host", >> thus we need the same sort of thing as for PCI to map from the child >> devices back to the bus root in order to find the appropriate firmware >> node. Worse than PCI, though, we wouldn't even have the option of >> describing child devices statically in firmware at all, since it's actually >> one of these runtime-configurable "build your own network accelerator" >> hardware pools where userspace gets to create and destroy "devices" as it >> likes. > > I really hate the PCI special case just as much. Maybe we just > need a dma_configure method on the bus, and move PCI as well as fsl-mc > to it. Hmm, on reflection, 100% ack to that idea. It would neatly supersede bus->force_dma *and* mean that we don't have to effectively pull pci.h into everything, which I've never liked. In hindsight dma_configure() does feel like it's grown into this odd choke point where we munge everything in just for it to awkwardly unpick things again. Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 18:51 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 18:51 UTC (permalink / raw) To: linux-arm-kernel On 05/03/18 18:39, Christoph Hellwig wrote: > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's >> software-discoverable and the only thing described in DT is the bus "host", >> thus we need the same sort of thing as for PCI to map from the child >> devices back to the bus root in order to find the appropriate firmware >> node. Worse than PCI, though, we wouldn't even have the option of >> describing child devices statically in firmware at all, since it's actually >> one of these runtime-configurable "build your own network accelerator" >> hardware pools where userspace gets to create and destroy "devices" as it >> likes. > > I really hate the PCI special case just as much. Maybe we just > need a dma_configure method on the bus, and move PCI as well as fsl-mc > to it. Hmm, on reflection, 100% ack to that idea. It would neatly supersede bus->force_dma *and* mean that we don't have to effectively pull pci.h into everything, which I've never liked. In hindsight dma_configure() does feel like it's grown into this odd choke point where we munge everything in just for it to awkwardly unpick things again. Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-05 18:51 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-05 18:51 UTC (permalink / raw) To: Christoph Hellwig Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On 05/03/18 18:39, Christoph Hellwig wrote: > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's >> software-discoverable and the only thing described in DT is the bus "host", >> thus we need the same sort of thing as for PCI to map from the child >> devices back to the bus root in order to find the appropriate firmware >> node. Worse than PCI, though, we wouldn't even have the option of >> describing child devices statically in firmware at all, since it's actually >> one of these runtime-configurable "build your own network accelerator" >> hardware pools where userspace gets to create and destroy "devices" as it >> likes. > > I really hate the PCI special case just as much. Maybe we just > need a dma_configure method on the bus, and move PCI as well as fsl-mc > to it. Hmm, on reflection, 100% ack to that idea. It would neatly supersede bus->force_dma *and* mean that we don't have to effectively pull pci.h into everything, which I've never liked. In hindsight dma_configure() does feel like it's grown into this odd choke point where we munge everything in just for it to awkwardly unpick things again. Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 5/6] dma-mapping: support fsl-mc bus 2018-03-05 18:51 ` Robin Murphy (?) (?) @ 2018-03-06 4:41 ` Nipun Gupta -1 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-06 4:41 UTC (permalink / raw) To: Robin Murphy, Christoph Hellwig Cc: will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Tuesday, March 06, 2018 0:22 > > On 05/03/18 18:39, Christoph Hellwig wrote: > > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: > >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > >> software-discoverable and the only thing described in DT is the bus "host", > >> thus we need the same sort of thing as for PCI to map from the child > >> devices back to the bus root in order to find the appropriate firmware > >> node. Worse than PCI, though, we wouldn't even have the option of > >> describing child devices statically in firmware at all, since it's actually > >> one of these runtime-configurable "build your own network accelerator" > >> hardware pools where userspace gets to create and destroy "devices" as it > >> likes. > > > > I really hate the PCI special case just as much. Maybe we just > > need a dma_configure method on the bus, and move PCI as well as fsl-mc > > to it. > > Hmm, on reflection, 100% ack to that idea. It would neatly supersede > bus->force_dma *and* mean that we don't have to effectively pull pci.h > into everything, which I've never liked. In hindsight dma_configure() > does feel like it's grown into this odd choke point where we munge > everything in just for it to awkwardly unpick things again. > > Robin. +1 to the idea. Sorry for asking a trivial question - looking into dma_configure() I see that PCI is used in the start and the end of the API. In the end part pci_put_host_bridge_device() is called. So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' will be required where the former one will return "dma_dev"? Regards, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-06 4:41 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-06 4:41 UTC (permalink / raw) To: linux-arm-kernel > From: Robin Murphy [mailto:robin.murphy at arm.com] > Sent: Tuesday, March 06, 2018 0:22 > > On 05/03/18 18:39, Christoph Hellwig wrote: > > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: > >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > >> software-discoverable and the only thing described in DT is the bus "host", > >> thus we need the same sort of thing as for PCI to map from the child > >> devices back to the bus root in order to find the appropriate firmware > >> node. Worse than PCI, though, we wouldn't even have the option of > >> describing child devices statically in firmware at all, since it's actually > >> one of these runtime-configurable "build your own network accelerator" > >> hardware pools where userspace gets to create and destroy "devices" as it > >> likes. > > > > I really hate the PCI special case just as much. Maybe we just > > need a dma_configure method on the bus, and move PCI as well as fsl-mc > > to it. > > Hmm, on reflection, 100% ack to that idea. It would neatly supersede > bus->force_dma *and* mean that we don't have to effectively pull pci.h > into everything, which I've never liked. In hindsight dma_configure() > does feel like it's grown into this odd choke point where we munge > everything in just for it to awkwardly unpick things again. > > Robin. +1 to the idea. Sorry for asking a trivial question - looking into dma_configure() I see that PCI is used in the start and the end of the API. In the end part pci_put_host_bridge_device() is called. So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' will be required where the former one will return "dma_dev"? Regards, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-06 4:41 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-06 4:41 UTC (permalink / raw) To: Robin Murphy, Christoph Hellwig Cc: will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor DQoNCj4gRnJvbTogUm9iaW4gTXVycGh5IFttYWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+ IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA2LCAyMDE4IDA6MjINCj4gDQo+IE9uIDA1LzAzLzE4IDE4 OjM5LCBDaHJpc3RvcGggSGVsbHdpZyB3cm90ZToNCj4gPiBPbiBNb24sIE1hciAwNSwgMjAxOCBh dCAwMzo0ODozMlBNICswMDAwLCBSb2JpbiBNdXJwaHkgd3JvdGU6DQo+ID4+IFVuZm9ydHVuYXRl bHkgZm9yIHVzLCBmc2wtbWMgaXMgY29uY2VwdHVhbGx5IHJhdGhlciBsaWtlIFBDSSBpbiB0aGF0 IGl0J3MNCj4gPj4gc29mdHdhcmUtZGlzY292ZXJhYmxlIGFuZCB0aGUgb25seSB0aGluZyBkZXNj cmliZWQgaW4gRFQgaXMgdGhlIGJ1cyAiaG9zdCIsDQo+ID4+IHRodXMgd2UgbmVlZCB0aGUgc2Ft ZSBzb3J0IG9mIHRoaW5nIGFzIGZvciBQQ0kgdG8gbWFwIGZyb20gdGhlIGNoaWxkDQo+ID4+IGRl dmljZXMgYmFjayB0byB0aGUgYnVzIHJvb3QgaW4gb3JkZXIgdG8gZmluZCB0aGUgYXBwcm9wcmlh dGUgZmlybXdhcmUNCj4gPj4gbm9kZS4gV29yc2UgdGhhbiBQQ0ksIHRob3VnaCwgd2Ugd291bGRu J3QgZXZlbiBoYXZlIHRoZSBvcHRpb24gb2YNCj4gPj4gZGVzY3JpYmluZyBjaGlsZCBkZXZpY2Vz IHN0YXRpY2FsbHkgaW4gZmlybXdhcmUgYXQgYWxsLCBzaW5jZSBpdCdzIGFjdHVhbGx5DQo+ID4+ IG9uZSBvZiB0aGVzZSBydW50aW1lLWNvbmZpZ3VyYWJsZSAiYnVpbGQgeW91ciBvd24gbmV0d29y ayBhY2NlbGVyYXRvciINCj4gPj4gaGFyZHdhcmUgcG9vbHMgd2hlcmUgdXNlcnNwYWNlIGdldHMg dG8gY3JlYXRlIGFuZCBkZXN0cm95ICJkZXZpY2VzIiBhcyBpdA0KPiA+PiBsaWtlcy4NCj4gPg0K PiA+IEkgcmVhbGx5IGhhdGUgdGhlIFBDSSBzcGVjaWFsIGNhc2UganVzdCBhcyBtdWNoLiAgTWF5 YmUgd2UganVzdA0KPiA+IG5lZWQgYSBkbWFfY29uZmlndXJlIG1ldGhvZCBvbiB0aGUgYnVzLCBh bmQgbW92ZSBQQ0kgYXMgd2VsbCBhcyBmc2wtbWMNCj4gPiB0byBpdC4NCj4gDQo+IEhtbSwgb24g cmVmbGVjdGlvbiwgMTAwJSBhY2sgdG8gdGhhdCBpZGVhLiBJdCB3b3VsZCBuZWF0bHkgc3VwZXJz ZWRlDQo+IGJ1cy0+Zm9yY2VfZG1hICphbmQqIG1lYW4gdGhhdCB3ZSBkb24ndCBoYXZlIHRvIGVm ZmVjdGl2ZWx5IHB1bGwgcGNpLmgNCj4gaW50byBldmVyeXRoaW5nLCB3aGljaCBJJ3ZlIG5ldmVy IGxpa2VkLiBJbiBoaW5kc2lnaHQgZG1hX2NvbmZpZ3VyZSgpDQo+IGRvZXMgZmVlbCBsaWtlIGl0 J3MgZ3Jvd24gaW50byB0aGlzIG9kZCBjaG9rZSBwb2ludCB3aGVyZSB3ZSBtdW5nZQ0KPiBldmVy eXRoaW5nIGluIGp1c3QgZm9yIGl0IHRvIGF3a3dhcmRseSB1bnBpY2sgdGhpbmdzIGFnYWluLg0K PiANCj4gUm9iaW4uDQoNCisxIHRvIHRoZSBpZGVhLg0KDQpTb3JyeSBmb3IgYXNraW5nIGEgdHJp dmlhbCBxdWVzdGlvbiAtIGxvb2tpbmcgaW50byBkbWFfY29uZmlndXJlKCkgSSBzZWUgdGhhdA0K UENJIGlzIHVzZWQgaW4gdGhlIHN0YXJ0IGFuZCB0aGUgZW5kIG9mIHRoZSBBUEkuDQpJbiB0aGUg ZW5kIHBhcnQgcGNpX3B1dF9ob3N0X2JyaWRnZV9kZXZpY2UoKSBpcyBjYWxsZWQuDQpTbyBhcmUg dHdvIGJ1cyBjYWxsYmFja3Mgc29tZXRoaW5nIGxpa2UgJ2RtYV9jb25maWdfc3RhcnQnICYgJ2Rt YV9jb25maWdfZW5kJw0Kd2lsbCBiZSByZXF1aXJlZCB3aGVyZSB0aGUgZm9ybWVyIG9uZSB3aWxs IHJldHVybiAiZG1hX2RldiI/DQoNClJlZ2FyZHMsDQpOaXB1bg0K ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-06 4:41 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-06 4:41 UTC (permalink / raw) To: Robin Murphy, Christoph Hellwig Cc: will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Tuesday, March 06, 2018 0:22 > > On 05/03/18 18:39, Christoph Hellwig wrote: > > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote: > >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > >> software-discoverable and the only thing described in DT is the bus "host", > >> thus we need the same sort of thing as for PCI to map from the child > >> devices back to the bus root in order to find the appropriate firmware > >> node. Worse than PCI, though, we wouldn't even have the option of > >> describing child devices statically in firmware at all, since it's actually > >> one of these runtime-configurable "build your own network accelerator" > >> hardware pools where userspace gets to create and destroy "devices" as it > >> likes. > > > > I really hate the PCI special case just as much. Maybe we just > > need a dma_configure method on the bus, and move PCI as well as fsl-mc > > to it. > > Hmm, on reflection, 100% ack to that idea. It would neatly supersede > bus->force_dma *and* mean that we don't have to effectively pull pci.h > into everything, which I've never liked. In hindsight dma_configure() > does feel like it's grown into this odd choke point where we munge > everything in just for it to awkwardly unpick things again. > > Robin. +1 to the idea. Sorry for asking a trivial question - looking into dma_configure() I see that PCI is used in the start and the end of the API. In the end part pci_put_host_bridge_device() is called. So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' will be required where the former one will return "dma_dev"? Regards, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus 2018-03-06 4:41 ` Nipun Gupta (?) @ 2018-03-08 7:41 ` Christoph Hellwig -1 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-08 7:41 UTC (permalink / raw) To: Nipun Gupta Cc: Robin Murphy, Christoph Hellwig, will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: > Sorry for asking a trivial question - looking into dma_configure() I see that > PCI is used in the start and the end of the API. > In the end part pci_put_host_bridge_device() is called. > So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' > will be required where the former one will return "dma_dev"? I'd just use dma_configure as the callback. Currently the of_dma_configure and acpi_dma_configure are only used for PCI anyway, as no one else sets a non-NULL dma dev. For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly. If at some point we get enough busses with either OF or ACPI we could create a helper called from ->dma_configure for that. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-08 7:41 ` Christoph Hellwig 0 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-08 7:41 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: > Sorry for asking a trivial question - looking into dma_configure() I see that > PCI is used in the start and the end of the API. > In the end part pci_put_host_bridge_device() is called. > So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' > will be required where the former one will return "dma_dev"? I'd just use dma_configure as the callback. Currently the of_dma_configure and acpi_dma_configure are only used for PCI anyway, as no one else sets a non-NULL dma dev. For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly. If at some point we get enough busses with either OF or ACPI we could create a helper called from ->dma_configure for that. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-08 7:41 ` Christoph Hellwig 0 siblings, 0 replies; 106+ messages in thread From: Christoph Hellwig @ 2018-03-08 7:41 UTC (permalink / raw) To: Nipun Gupta Cc: mark.rutland, devicetree, stuyoder, Bharat Bhushan, catalin.marinas, joro, linuxppc-dev, will.deacon, linux-kernel, Leo Li, iommu, robh+dt, gregkh, shawnguo, Laurentiu Tudor, Robin Murphy, Christoph Hellwig, linux-arm-kernel@lists.infradead.org On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: > Sorry for asking a trivial question - looking into dma_configure() I see that > PCI is used in the start and the end of the API. > In the end part pci_put_host_bridge_device() is called. > So are two bus callbacks something like 'dma_config_start' & 'dma_config_end' > will be required where the former one will return "dma_dev"? I'd just use dma_configure as the callback. Currently the of_dma_configure and acpi_dma_configure are only used for PCI anyway, as no one else sets a non-NULL dma dev. For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly. If at some point we get enough busses with either OF or ACPI we could create a helper called from ->dma_configure for that. ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-09 18:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-09 18:29 UTC (permalink / raw) To: Christoph Hellwig Cc: Robin Murphy, will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor > -----Original Message----- > From: Christoph Hellwig [mailto:hch@lst.de] > Sent: Thursday, March 08, 2018 13:11 > > On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: > > Sorry for asking a trivial question - looking into dma_configure() I see that > > PCI is used in the start and the end of the API. > > In the end part pci_put_host_bridge_device() is called. > > So are two bus callbacks something like 'dma_config_start' & > 'dma_config_end' > > will be required where the former one will return "dma_dev"? > > I'd just use dma_configure as the callback. This would be a decent stuff. > > Currently the of_dma_configure and acpi_dma_configure are only used > for PCI anyway, as no one else sets a non-NULL dma dev. My understanding is that even the platform bus uses the of_dma_configure and probably acpi_dma_configure too. So platform bus may also need the callback implemented. Please correct me if my understanding is wrong. I will submit the patch with 'dma_configure' callback implemented for the busses shortly. > For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly. > If at some point we get enough busses with either OF or ACPI we could > create a helper called from ->dma_configure for that. Totally agree with this. Thanks, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-09 18:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-09 18:29 UTC (permalink / raw) To: linux-arm-kernel > -----Original Message----- > From: Christoph Hellwig [mailto:hch at lst.de] > Sent: Thursday, March 08, 2018 13:11 > > On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: > > Sorry for asking a trivial question - looking into dma_configure() I see that > > PCI is used in the start and the end of the API. > > In the end part pci_put_host_bridge_device() is called. > > So are two bus callbacks something like 'dma_config_start' & > 'dma_config_end' > > will be required where the former one will return "dma_dev"? > > I'd just use dma_configure as the callback. This would be a decent stuff. > > Currently the of_dma_configure and acpi_dma_configure are only used > for PCI anyway, as no one else sets a non-NULL dma dev. My understanding is that even the platform bus uses the of_dma_configure and probably acpi_dma_configure too. So platform bus may also need the callback implemented. Please correct me if my understanding is wrong. I will submit the patch with 'dma_configure' callback implemented for the busses shortly. > For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly. > If at some point we get enough busses with either OF or ACPI we could > create a helper called from ->dma_configure for that. Totally agree with this. Thanks, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-09 18:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-09 18:29 UTC (permalink / raw) To: Christoph Hellwig Cc: Robin Murphy, will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor > -----Original Message----- > From: Christoph Hellwig [mailto:hch@lst.de] > Sent: Thursday, March 08, 2018 13:11 >=20 > On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: > > Sorry for asking a trivial question - looking into dma_configure() I se= e that > > PCI is used in the start and the end of the API. > > In the end part pci_put_host_bridge_device() is called. > > So are two bus callbacks something like 'dma_config_start' & > 'dma_config_end' > > will be required where the former one will return "dma_dev"? >=20 > I'd just use dma_configure as the callback. This would be a decent stuff. >=20 > Currently the of_dma_configure and acpi_dma_configure are only used > for PCI anyway, as no one else sets a non-NULL dma dev. My understanding is that even the platform bus uses the of_dma_configure and probably acpi_dma_configure too. So platform bus may also need the callback implemented. Please correct me if my understanding is wrong. I will submit the patch with 'dma_configure' callback implemented for the busses shortly. > For fsl-mc I suspect only of_dma_configure is relevanet, so just call tha= t directly. > If at some point we get enough busses with either OF or ACPI we could > create a helper called from ->dma_configure for that. Totally agree with this. Thanks, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-09 18:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-09 18:29 UTC (permalink / raw) To: Christoph Hellwig Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r > -----Original Message----- > From: Christoph Hellwig [mailto:hch-jcswGhMUV9g@public.gmane.org] > Sent: Thursday, March 08, 2018 13:11 > > On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: > > Sorry for asking a trivial question - looking into dma_configure() I see that > > PCI is used in the start and the end of the API. > > In the end part pci_put_host_bridge_device() is called. > > So are two bus callbacks something like 'dma_config_start' & > 'dma_config_end' > > will be required where the former one will return "dma_dev"? > > I'd just use dma_configure as the callback. This would be a decent stuff. > > Currently the of_dma_configure and acpi_dma_configure are only used > for PCI anyway, as no one else sets a non-NULL dma dev. My understanding is that even the platform bus uses the of_dma_configure and probably acpi_dma_configure too. So platform bus may also need the callback implemented. Please correct me if my understanding is wrong. I will submit the patch with 'dma_configure' callback implemented for the busses shortly. > For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly. > If at some point we get enough busses with either OF or ACPI we could > create a helper called from ->dma_configure for that. Totally agree with this. Thanks, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-09 18:50 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-09 18:50 UTC (permalink / raw) To: Nipun Gupta, Christoph Hellwig Cc: will.deacon, mark.rutland, catalin.marinas, iommu, robh+dt, m.szyprowski, gregkh, joro, Leo Li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, Bharat Bhushan, stuyoder, Laurentiu Tudor On 09/03/18 18:29, Nipun Gupta wrote: > > >> -----Original Message----- >> From: Christoph Hellwig [mailto:hch@lst.de] >> Sent: Thursday, March 08, 2018 13:11 >> >> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: >>> Sorry for asking a trivial question - looking into dma_configure() I see that >>> PCI is used in the start and the end of the API. >>> In the end part pci_put_host_bridge_device() is called. >>> So are two bus callbacks something like 'dma_config_start' & >> 'dma_config_end' >>> will be required where the former one will return "dma_dev"? >> >> I'd just use dma_configure as the callback. > > This would be a decent stuff. Yes, the PCI version should end up looking a lot like the old pci_dma_configure() used to, before everything got pulled together. >> Currently the of_dma_configure and acpi_dma_configure are only used >> for PCI anyway, as no one else sets a non-NULL dma dev. > > My understanding is that even the platform bus uses the of_dma_configure > and probably acpi_dma_configure too. So platform bus may also need the > callback implemented. Please correct me if my understanding is wrong. Indeed, platform and AMBA will want an implementation to dispatch between {of,acpi}_dma_configre() per the current logic. Host1x doesn't seem to care about ACPI so probably wants its own just calling of_dma_configure(). > I will submit the patch with 'dma_configure' callback implemented for > the busses shortly. Cheers - I've been trying to find some time to take a look myself, but having something to review instead would certainly be easier :) Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-09 18:50 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-09 18:50 UTC (permalink / raw) To: linux-arm-kernel On 09/03/18 18:29, Nipun Gupta wrote: > > >> -----Original Message----- >> From: Christoph Hellwig [mailto:hch at lst.de] >> Sent: Thursday, March 08, 2018 13:11 >> >> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: >>> Sorry for asking a trivial question - looking into dma_configure() I see that >>> PCI is used in the start and the end of the API. >>> In the end part pci_put_host_bridge_device() is called. >>> So are two bus callbacks something like 'dma_config_start' & >> 'dma_config_end' >>> will be required where the former one will return "dma_dev"? >> >> I'd just use dma_configure as the callback. > > This would be a decent stuff. Yes, the PCI version should end up looking a lot like the old pci_dma_configure() used to, before everything got pulled together. >> Currently the of_dma_configure and acpi_dma_configure are only used >> for PCI anyway, as no one else sets a non-NULL dma dev. > > My understanding is that even the platform bus uses the of_dma_configure > and probably acpi_dma_configure too. So platform bus may also need the > callback implemented. Please correct me if my understanding is wrong. Indeed, platform and AMBA will want an implementation to dispatch between {of,acpi}_dma_configre() per the current logic. Host1x doesn't seem to care about ACPI so probably wants its own just calling of_dma_configure(). > I will submit the patch with 'dma_configure' callback implemented for > the busses shortly. Cheers - I've been trying to find some time to take a look myself, but having something to review instead would certainly be easier :) Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus @ 2018-03-09 18:50 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-03-09 18:50 UTC (permalink / raw) To: Nipun Gupta, Christoph Hellwig Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On 09/03/18 18:29, Nipun Gupta wrote: > > >> -----Original Message----- >> From: Christoph Hellwig [mailto:hch-jcswGhMUV9g@public.gmane.org] >> Sent: Thursday, March 08, 2018 13:11 >> >> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote: >>> Sorry for asking a trivial question - looking into dma_configure() I see that >>> PCI is used in the start and the end of the API. >>> In the end part pci_put_host_bridge_device() is called. >>> So are two bus callbacks something like 'dma_config_start' & >> 'dma_config_end' >>> will be required where the former one will return "dma_dev"? >> >> I'd just use dma_configure as the callback. > > This would be a decent stuff. Yes, the PCI version should end up looking a lot like the old pci_dma_configure() used to, before everything got pulled together. >> Currently the of_dma_configure and acpi_dma_configure are only used >> for PCI anyway, as no one else sets a non-NULL dma dev. > > My understanding is that even the platform bus uses the of_dma_configure > and probably acpi_dma_configure too. So platform bus may also need the > callback implemented. Please correct me if my understanding is wrong. Indeed, platform and AMBA will want an implementation to dispatch between {of,acpi}_dma_configre() per the current logic. Host1x doesn't seem to care about ACPI so probably wants its own just calling of_dma_configure(). > I will submit the patch with 'dma_configure' callback implemented for > the busses shortly. Cheers - I've been trying to find some time to take a look myself, but having something to review instead would certainly be easier :) Robin. ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon, robin.murphy, mark.rutland, catalin.marinas Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor, Nipun Gupta Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..1f15492 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -135,6 +135,7 @@ #address-cells = <2>; #size-cells = <2>; ranges; + dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>; clockgen: clocking@1300000 { compatible = "fsl,ls2080a-clockgen"; @@ -357,6 +358,8 @@ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-parent = <&smmu>; + dma-coherent; #address-cells = <3>; #size-cells = <1>; @@ -460,6 +463,8 @@ compatible = "arm,mmu-500"; reg = <0 0x5000000 0 0x800000>; #global-interrupts = <12>; + stream-match-mask = <0x7C00>; + dma-coherent; interrupts = <0 13 4>, /* global secure fault */ <0 14 4>, /* combined secure interrupt */ <0 15 4>, /* global non-secure fault */ @@ -502,7 +507,6 @@ <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, <0 208 4>, <0 209 4>; - mmu-masters = <&fsl_mc 0x300 0>; }; dspi: dspi@2100000 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..1f15492 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -135,6 +135,7 @@ #address-cells = <2>; #size-cells = <2>; ranges; + dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>; clockgen: clocking at 1300000 { compatible = "fsl,ls2080a-clockgen"; @@ -357,6 +358,8 @@ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-parent = <&smmu>; + dma-coherent; #address-cells = <3>; #size-cells = <1>; @@ -460,6 +463,8 @@ compatible = "arm,mmu-500"; reg = <0 0x5000000 0 0x800000>; #global-interrupts = <12>; + stream-match-mask = <0x7C00>; + dma-coherent; interrupts = <0 13 4>, /* global secure fault */ <0 14 4>, /* combined secure interrupt */ <0 15 4>, /* global non-secure fault */ @@ -502,7 +507,6 @@ <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, <0 208 4>, <0 209 4>; - mmu-masters = <&fsl_mc 0x300 0>; }; dspi: dspi at 2100000 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc @ 2018-03-05 14:29 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw) To: will.deacon-5wv7dgnIgG8, robin.murphy-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..1f15492 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -135,6 +135,7 @@ #address-cells = <2>; #size-cells = <2>; ranges; + dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>; clockgen: clocking@1300000 { compatible = "fsl,ls2080a-clockgen"; @@ -357,6 +358,8 @@ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-parent = <&smmu>; + dma-coherent; #address-cells = <3>; #size-cells = <1>; @@ -460,6 +463,8 @@ compatible = "arm,mmu-500"; reg = <0 0x5000000 0 0x800000>; #global-interrupts = <12>; + stream-match-mask = <0x7C00>; + dma-coherent; interrupts = <0 13 4>, /* global secure fault */ <0 14 4>, /* combined secure interrupt */ <0 15 4>, /* global non-secure fault */ @@ -502,7 +507,6 @@ <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, <0 208 4>, <0 209 4>; - mmu-masters = <&fsl_mc 0x300 0>; }; dspi: dspi@2100000 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. This patch series is dependent on patset: https://patchwork.kernel.org/patch/10317337/ These patches - Define property 'iommu-map' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3,4) - Adds the dma configuration support for fsl-mc bus (patch 5) - Updates the fsl-mc device node with iommu/dma related changes (patch6) Nipun Gupta (6): Docs: dt: add fsl-mc iommu-map device-tree binding iommu: of: make of_pci_map_rid() available for other devices too iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc Changes in v2: - use iommu-map property for fsl-mc bus - rebase over patchset https://patchwork.kernel.org/patch/10317337/ and make corresponding changes for dma configuration of devices on fsl-mc bus .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 +++++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +- drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++- drivers/iommu/arm-smmu.c | 7 ++ drivers/iommu/iommu.c | 21 ++++ drivers/iommu/of_iommu.c | 126 ++++++++++++++++++++- drivers/of/irq.c | 6 +- drivers/pci/of.c | 101 ----------------- include/linux/fsl/mc.h | 8 ++ include/linux/iommu.h | 2 + include/linux/of_iommu.h | 11 ++ include/linux/of_pci.h | 10 -- 12 files changed, 231 insertions(+), 122 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: linux-arm-kernel This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. This patch series is dependent on patset: https://patchwork.kernel.org/patch/10317337/ These patches - Define property 'iommu-map' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3,4) - Adds the dma configuration support for fsl-mc bus (patch 5) - Updates the fsl-mc device node with iommu/dma related changes (patch6) Nipun Gupta (6): Docs: dt: add fsl-mc iommu-map device-tree binding iommu: of: make of_pci_map_rid() available for other devices too iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc Changes in v2: - use iommu-map property for fsl-mc bus - rebase over patchset https://patchwork.kernel.org/patch/10317337/ and make corresponding changes for dma configuration of devices on fsl-mc bus .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 +++++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +- drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++- drivers/iommu/arm-smmu.c | 7 ++ drivers/iommu/iommu.c | 21 ++++ drivers/iommu/of_iommu.c | 126 ++++++++++++++++++++- drivers/of/irq.c | 6 +- drivers/pci/of.c | 101 ----------------- include/linux/fsl/mc.h | 8 ++ include/linux/iommu.h | 2 + include/linux/of_iommu.h | 11 ++ include/linux/of_pci.h | 10 -- 12 files changed, 231 insertions(+), 122 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: devicetree, bharat.bhushan, stuyoder, frowand.list, gregkh, joro, linuxppc-dev, linux-kernel, leoyang.li, iommu, robh+dt, Nipun Gupta, linux-pci, bhelgaas, laurentiu.tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. This patch series is dependent on patset: https://patchwork.kernel.org/patch/10317337/ These patches - Define property 'iommu-map' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3,4) - Adds the dma configuration support for fsl-mc bus (patch 5) - Updates the fsl-mc device node with iommu/dma related changes (patch6) Nipun Gupta (6): Docs: dt: add fsl-mc iommu-map device-tree binding iommu: of: make of_pci_map_rid() available for other devices too iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc Changes in v2: - use iommu-map property for fsl-mc bus - rebase over patchset https://patchwork.kernel.org/patch/10317337/ and make corresponding changes for dma configuration of devices on fsl-mc bus .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 +++++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +- drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++- drivers/iommu/arm-smmu.c | 7 ++ drivers/iommu/iommu.c | 21 ++++ drivers/iommu/of_iommu.c | 126 ++++++++++++++++++++- drivers/of/irq.c | 6 +- drivers/pci/of.c | 101 ----------------- include/linux/fsl/mc.h | 8 ++ include/linux/iommu.h | 2 + include/linux/of_iommu.h | 11 ++ include/linux/of_pci.h | 10 -- 12 files changed, 231 insertions(+), 122 deletions(-) -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. This patch series is dependent on patset: https://patchwork.kernel.org/patch/10317337/ These patches - Define property 'iommu-map' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3,4) - Adds the dma configuration support for fsl-mc bus (patch 5) - Updates the fsl-mc device node with iommu/dma related changes (patch6) Nipun Gupta (6): Docs: dt: add fsl-mc iommu-map device-tree binding iommu: of: make of_pci_map_rid() available for other devices too iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc Changes in v2: - use iommu-map property for fsl-mc bus - rebase over patchset https://patchwork.kernel.org/patch/10317337/ and make corresponding changes for dma configuration of devices on fsl-mc bus .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 +++++++ arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +- drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++- drivers/iommu/arm-smmu.c | 7 ++ drivers/iommu/iommu.c | 21 ++++ drivers/iommu/of_iommu.c | 126 ++++++++++++++++++++- drivers/of/irq.c | 6 +- drivers/pci/of.c | 101 ----------------- include/linux/fsl/mc.h | 8 ++ include/linux/iommu.h | 2 + include/linux/of_iommu.h | 11 ++ include/linux/of_pci.h | 10 -- 12 files changed, 231 insertions(+), 122 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a generic binding for mapping fsl-mc devices to IOMMUs, using iommu-map property. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 6611a7c..8cbed4f 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices such as network interfaces, crypto accelerator instances, L2 switches, etc. +For an overview of the DPAA2 architecture and fsl-mc bus see: +drivers/staging/fsl-mc/README.txt + +As described in the above overview, all DPAA2 objects in a DPRC share the +same hardware "isolation context" and a 10-bit value called an ICID +(isolation context id) is expressed by the hardware to identify +the requester. + +The generic 'iommus' property is insufficient to describe the relationship +between ICIDs and IOMMUs, so an iommu-map property is used to define +the set of possible ICIDs under a root DPRC and how they map to +an IOMMU. + +For generic IOMMU bindings, see +Documentation/devicetree/bindings/iommu/iommu.txt. + +For arm-smmu binding, see: +Documentation/devicetree/bindings/iommu/arm,smmu.txt. + Required properties: - compatible @@ -88,14 +107,34 @@ Sub-nodes: Value type: <phandle> Definition: Specifies the phandle to the PHY device node associated with the this dpmac. +Optional properties: + +- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier + data. + + The property is an arbitrary number of tuples of + (icid-base,iommu,iommu-base,length). + + Any ICID i in the interval [icid-base, icid-base + length) is + associated with the listed IOMMU, with the iommu-specifier + (i - icid-base + iommu-base). Example: + smmu: iommu@5000000 { + compatible = "arm,mmu-500"; + #iommu-cells = <2>; + stream-match-mask = <0x7C00>; + ... + }; + fsl_mc: fsl-mc@80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + /* define map for ICIDs 23-64 */ + iommu-map = <23 &smmu 23 41>; #address-cells = <3>; #size-cells = <1>; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: linux-arm-kernel The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a generic binding for mapping fsl-mc devices to IOMMUs, using iommu-map property. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 6611a7c..8cbed4f 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices such as network interfaces, crypto accelerator instances, L2 switches, etc. +For an overview of the DPAA2 architecture and fsl-mc bus see: +drivers/staging/fsl-mc/README.txt + +As described in the above overview, all DPAA2 objects in a DPRC share the +same hardware "isolation context" and a 10-bit value called an ICID +(isolation context id) is expressed by the hardware to identify +the requester. + +The generic 'iommus' property is insufficient to describe the relationship +between ICIDs and IOMMUs, so an iommu-map property is used to define +the set of possible ICIDs under a root DPRC and how they map to +an IOMMU. + +For generic IOMMU bindings, see +Documentation/devicetree/bindings/iommu/iommu.txt. + +For arm-smmu binding, see: +Documentation/devicetree/bindings/iommu/arm,smmu.txt. + Required properties: - compatible @@ -88,14 +107,34 @@ Sub-nodes: Value type: <phandle> Definition: Specifies the phandle to the PHY device node associated with the this dpmac. +Optional properties: + +- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier + data. + + The property is an arbitrary number of tuples of + (icid-base,iommu,iommu-base,length). + + Any ICID i in the interval [icid-base, icid-base + length) is + associated with the listed IOMMU, with the iommu-specifier + (i - icid-base + iommu-base). Example: + smmu: iommu at 5000000 { + compatible = "arm,mmu-500"; + #iommu-cells = <2>; + stream-match-mask = <0x7C00>; + ... + }; + fsl_mc: fsl-mc at 80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + /* define map for ICIDs 23-64 */ + iommu-map = <23 &smmu 23 41>; #address-cells = <3>; #size-cells = <1>; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: devicetree, bharat.bhushan, stuyoder, frowand.list, gregkh, joro, linuxppc-dev, linux-kernel, leoyang.li, iommu, robh+dt, Nipun Gupta, linux-pci, bhelgaas, laurentiu.tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a generic binding for mapping fsl-mc devices to IOMMUs, using iommu-map property. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 6611a7c..8cbed4f 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices such as network interfaces, crypto accelerator instances, L2 switches, etc. +For an overview of the DPAA2 architecture and fsl-mc bus see: +drivers/staging/fsl-mc/README.txt + +As described in the above overview, all DPAA2 objects in a DPRC share the +same hardware "isolation context" and a 10-bit value called an ICID +(isolation context id) is expressed by the hardware to identify +the requester. + +The generic 'iommus' property is insufficient to describe the relationship +between ICIDs and IOMMUs, so an iommu-map property is used to define +the set of possible ICIDs under a root DPRC and how they map to +an IOMMU. + +For generic IOMMU bindings, see +Documentation/devicetree/bindings/iommu/iommu.txt. + +For arm-smmu binding, see: +Documentation/devicetree/bindings/iommu/arm,smmu.txt. + Required properties: - compatible @@ -88,14 +107,34 @@ Sub-nodes: Value type: <phandle> Definition: Specifies the phandle to the PHY device node associated with the this dpmac. +Optional properties: + +- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier + data. + + The property is an arbitrary number of tuples of + (icid-base,iommu,iommu-base,length). + + Any ICID i in the interval [icid-base, icid-base + length) is + associated with the listed IOMMU, with the iommu-specifier + (i - icid-base + iommu-base). Example: + smmu: iommu@5000000 { + compatible = "arm,mmu-500"; + #iommu-cells = <2>; + stream-match-mask = <0x7C00>; + ... + }; + fsl_mc: fsl-mc@80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + /* define map for ICIDs 23-64 */ + iommu-map = <23 &smmu 23 41>; #address-cells = <3>; #size-cells = <1>; -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a generic binding for mapping fsl-mc devices to IOMMUs, using iommu-map property. Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 6611a7c..8cbed4f 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices such as network interfaces, crypto accelerator instances, L2 switches, etc. +For an overview of the DPAA2 architecture and fsl-mc bus see: +drivers/staging/fsl-mc/README.txt + +As described in the above overview, all DPAA2 objects in a DPRC share the +same hardware "isolation context" and a 10-bit value called an ICID +(isolation context id) is expressed by the hardware to identify +the requester. + +The generic 'iommus' property is insufficient to describe the relationship +between ICIDs and IOMMUs, so an iommu-map property is used to define +the set of possible ICIDs under a root DPRC and how they map to +an IOMMU. + +For generic IOMMU bindings, see +Documentation/devicetree/bindings/iommu/iommu.txt. + +For arm-smmu binding, see: +Documentation/devicetree/bindings/iommu/arm,smmu.txt. + Required properties: - compatible @@ -88,14 +107,34 @@ Sub-nodes: Value type: <phandle> Definition: Specifies the phandle to the PHY device node associated with the this dpmac. +Optional properties: + +- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier + data. + + The property is an arbitrary number of tuples of + (icid-base,iommu,iommu-base,length). + + Any ICID i in the interval [icid-base, icid-base + length) is + associated with the listed IOMMU, with the iommu-specifier + (i - icid-base + iommu-base). Example: + smmu: iommu@5000000 { + compatible = "arm,mmu-500"; + #iommu-cells = <2>; + stream-match-mask = <0x7C00>; + ... + }; + fsl_mc: fsl-mc@80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + /* define map for ICIDs 23-64 */ + iommu-map = <23 &smmu 23 41>; #address-cells = <3>; #size-cells = <1>; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta iommu-map property is also used by devices with fsl-mc. This patch moves the of_pci_map_rid to generic location, so that it can be used by other busses too. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-- drivers/of/irq.c | 6 +-- drivers/pci/of.c | 101 -------------------------------------------- include/linux/of_iommu.h | 11 +++++ include/linux/of_pci.h | 10 ----- 5 files changed, 117 insertions(+), 117 deletions(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..4e7712f 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, return ops->of_xlate(dev, iommu_spec); } +/** + * of_map_rid - Translate a requester ID through a downstream mapping. + * @np: root complex device node. + * @rid: device requester ID to map. + * @map_name: property name of the map to use. + * @map_mask_name: optional property name of the mask to use. + * @target: optional pointer to a target device node. + * @id_out: optional pointer to receive the translated ID. + * + * Given a device requester ID, look up the appropriate implementation-defined + * platform ID and/or the target device which receives transactions on that + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or + * @id_out may be NULL if only the other is required. If @target points to + * a non-NULL device node pointer, only entries targeting that node will be + * matched; if it points to a NULL value, it will receive the device node of + * the first matching target phandle, with a reference held. + * + * Return: 0 on success or a standard error code on failure. + */ +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + u32 map_mask, masked_rid; + int map_len; + const __be32 *map = NULL; + + if (!np || !map_name || (!target && !id_out)) + return -EINVAL; + + map = of_get_property(np, map_name, &map_len); + if (!map) { + if (target) + return -ENODEV; + /* Otherwise, no map implies no translation */ + *id_out = rid; + return 0; + } + + if (!map_len || map_len % (4 * sizeof(*map))) { + pr_err("%pOF: Error: Bad %s length: %d\n", np, + map_name, map_len); + return -EINVAL; + } + + /* The default is to select all bits. */ + map_mask = 0xffffffff; + + /* + * Can be overridden by "{iommu,msi}-map-mask" property. + */ + if (map_mask_name) + of_property_read_u32(np, map_mask_name, &map_mask); + + masked_rid = map_mask & rid; + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { + struct device_node *phandle_node; + u32 rid_base = be32_to_cpup(map + 0); + u32 phandle = be32_to_cpup(map + 1); + u32 out_base = be32_to_cpup(map + 2); + u32 rid_len = be32_to_cpup(map + 3); + + if (rid_base & ~map_mask) { + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", + np, map_name, map_name, + map_mask, rid_base); + return -EFAULT; + } + + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) + continue; + + phandle_node = of_find_node_by_phandle(phandle); + if (!phandle_node) + return -ENODEV; + + if (target) { + if (*target) + of_node_put(phandle_node); + else + *target = phandle_node; + + if (*target != phandle_node) + continue; + } + + if (id_out) + *id_out = masked_rid - rid_base + out_base; + + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", + np, map_name, map_mask, rid_base, out_base, + rid_len, rid, masked_rid - rid_base + out_base); + return 0; + } + + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", + np, map_name, rid, target && *target ? *target : NULL); + return -EFAULT; +} + struct of_pci_iommu_alias_info { struct device *dev; struct device_node *np; @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_pci_map_rid(info->np, alias, "iommu-map", - "iommu-map-mask", &iommu_spec.np, - iommu_spec.args); + err = of_map_rid(info->np, alias, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); if (err) return err == -ENODEV ? NO_IOMMU : err; diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 02ad93a..b72eeec 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -22,7 +22,7 @@ #include <linux/module.h> #include <linux/of.h> #include <linux/of_irq.h> -#include <linux/of_pci.h> +#include <linux/of_iommu.h> #include <linux/string.h> #include <linux/slab.h> @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np, * "msi-map" property. */ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", - "msi-map-mask", np, &rid_out)) + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", + "msi-map-mask", np, &rid_out)) break; return rid_out; } diff --git a/drivers/pci/of.c b/drivers/pci/of.c index a28355c..d2cebbe 100644 --- a/drivers/pci/of.c +++ b/drivers/pci/of.c @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev, EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); #endif /* CONFIG_OF_ADDRESS */ -/** - * of_pci_map_rid - Translate a requester ID through a downstream mapping. - * @np: root complex device node. - * @rid: PCI requester ID to map. - * @map_name: property name of the map to use. - * @map_mask_name: optional property name of the mask to use. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. - * - * Given a PCI requester ID, look up the appropriate implementation-defined - * platform ID and/or the target device which receives transactions on that - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or - * @id_out may be NULL if only the other is required. If @target points to - * a non-NULL device node pointer, only entries targeting that node will be - * matched; if it points to a NULL value, it will receive the device node of - * the first matching target phandle, with a reference held. - * - * Return: 0 on success or a standard error code on failure. - */ -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - u32 map_mask, masked_rid; - int map_len; - const __be32 *map = NULL; - - if (!np || !map_name || (!target && !id_out)) - return -EINVAL; - - map = of_get_property(np, map_name, &map_len); - if (!map) { - if (target) - return -ENODEV; - /* Otherwise, no map implies no translation */ - *id_out = rid; - return 0; - } - - if (!map_len || map_len % (4 * sizeof(*map))) { - pr_err("%pOF: Error: Bad %s length: %d\n", np, - map_name, map_len); - return -EINVAL; - } - - /* The default is to select all bits. */ - map_mask = 0xffffffff; - - /* - * Can be overridden by "{iommu,msi}-map-mask" property. - * If of_property_read_u32() fails, the default is used. - */ - if (map_mask_name) - of_property_read_u32(np, map_mask_name, &map_mask); - - masked_rid = map_mask & rid; - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { - struct device_node *phandle_node; - u32 rid_base = be32_to_cpup(map + 0); - u32 phandle = be32_to_cpup(map + 1); - u32 out_base = be32_to_cpup(map + 2); - u32 rid_len = be32_to_cpup(map + 3); - - if (rid_base & ~map_mask) { - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", - np, map_name, map_name, - map_mask, rid_base); - return -EFAULT; - } - - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) - continue; - - phandle_node = of_find_node_by_phandle(phandle); - if (!phandle_node) - return -ENODEV; - - if (target) { - if (*target) - of_node_put(phandle_node); - else - *target = phandle_node; - - if (*target != phandle_node) - continue; - } - - if (id_out) - *id_out = masked_rid - rid_base + out_base; - - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", - np, map_name, map_mask, rid_base, out_base, - rid_len, rid, masked_rid - rid_base + out_base); - return 0; - } - - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", - np, map_name, rid, target && *target ? *target : NULL); - return -EFAULT; -} - #if IS_ENABLED(CONFIG_OF_IRQ) /** * of_irq_parse_pci - Resolve the interrupt for a PCI device diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index 4fa654e..432b53c 100644 --- a/include/linux/of_iommu.h +++ b/include/linux/of_iommu.h @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix, extern const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np); +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out); + #else static inline int of_get_dma_window(struct device_node *dn, const char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, return NULL; } +static inline int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + return -EINVAL; +} + #endif /* CONFIG_OF_IOMMU */ extern struct of_device_id __iommu_of_table; diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index 091033a..a23b44a 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent, int of_get_pci_domain_nr(struct device_node *node); int of_pci_get_max_link_speed(struct device_node *node); void of_pci_check_probe_only(void); -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out); #else static inline struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn) @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np) return -1; } -static inline int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - return -EINVAL; -} - static inline int of_pci_get_max_link_speed(struct device_node *node) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: linux-arm-kernel iommu-map property is also used by devices with fsl-mc. This patch moves the of_pci_map_rid to generic location, so that it can be used by other busses too. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-- drivers/of/irq.c | 6 +-- drivers/pci/of.c | 101 -------------------------------------------- include/linux/of_iommu.h | 11 +++++ include/linux/of_pci.h | 10 ----- 5 files changed, 117 insertions(+), 117 deletions(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..4e7712f 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, return ops->of_xlate(dev, iommu_spec); } +/** + * of_map_rid - Translate a requester ID through a downstream mapping. + * @np: root complex device node. + * @rid: device requester ID to map. + * @map_name: property name of the map to use. + * @map_mask_name: optional property name of the mask to use. + * @target: optional pointer to a target device node. + * @id_out: optional pointer to receive the translated ID. + * + * Given a device requester ID, look up the appropriate implementation-defined + * platform ID and/or the target device which receives transactions on that + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or + * @id_out may be NULL if only the other is required. If @target points to + * a non-NULL device node pointer, only entries targeting that node will be + * matched; if it points to a NULL value, it will receive the device node of + * the first matching target phandle, with a reference held. + * + * Return: 0 on success or a standard error code on failure. + */ +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + u32 map_mask, masked_rid; + int map_len; + const __be32 *map = NULL; + + if (!np || !map_name || (!target && !id_out)) + return -EINVAL; + + map = of_get_property(np, map_name, &map_len); + if (!map) { + if (target) + return -ENODEV; + /* Otherwise, no map implies no translation */ + *id_out = rid; + return 0; + } + + if (!map_len || map_len % (4 * sizeof(*map))) { + pr_err("%pOF: Error: Bad %s length: %d\n", np, + map_name, map_len); + return -EINVAL; + } + + /* The default is to select all bits. */ + map_mask = 0xffffffff; + + /* + * Can be overridden by "{iommu,msi}-map-mask" property. + */ + if (map_mask_name) + of_property_read_u32(np, map_mask_name, &map_mask); + + masked_rid = map_mask & rid; + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { + struct device_node *phandle_node; + u32 rid_base = be32_to_cpup(map + 0); + u32 phandle = be32_to_cpup(map + 1); + u32 out_base = be32_to_cpup(map + 2); + u32 rid_len = be32_to_cpup(map + 3); + + if (rid_base & ~map_mask) { + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", + np, map_name, map_name, + map_mask, rid_base); + return -EFAULT; + } + + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) + continue; + + phandle_node = of_find_node_by_phandle(phandle); + if (!phandle_node) + return -ENODEV; + + if (target) { + if (*target) + of_node_put(phandle_node); + else + *target = phandle_node; + + if (*target != phandle_node) + continue; + } + + if (id_out) + *id_out = masked_rid - rid_base + out_base; + + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", + np, map_name, map_mask, rid_base, out_base, + rid_len, rid, masked_rid - rid_base + out_base); + return 0; + } + + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", + np, map_name, rid, target && *target ? *target : NULL); + return -EFAULT; +} + struct of_pci_iommu_alias_info { struct device *dev; struct device_node *np; @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_pci_map_rid(info->np, alias, "iommu-map", - "iommu-map-mask", &iommu_spec.np, - iommu_spec.args); + err = of_map_rid(info->np, alias, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); if (err) return err == -ENODEV ? NO_IOMMU : err; diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 02ad93a..b72eeec 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -22,7 +22,7 @@ #include <linux/module.h> #include <linux/of.h> #include <linux/of_irq.h> -#include <linux/of_pci.h> +#include <linux/of_iommu.h> #include <linux/string.h> #include <linux/slab.h> @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np, * "msi-map" property. */ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", - "msi-map-mask", np, &rid_out)) + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", + "msi-map-mask", np, &rid_out)) break; return rid_out; } diff --git a/drivers/pci/of.c b/drivers/pci/of.c index a28355c..d2cebbe 100644 --- a/drivers/pci/of.c +++ b/drivers/pci/of.c @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev, EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); #endif /* CONFIG_OF_ADDRESS */ -/** - * of_pci_map_rid - Translate a requester ID through a downstream mapping. - * @np: root complex device node. - * @rid: PCI requester ID to map. - * @map_name: property name of the map to use. - * @map_mask_name: optional property name of the mask to use. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. - * - * Given a PCI requester ID, look up the appropriate implementation-defined - * platform ID and/or the target device which receives transactions on that - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or - * @id_out may be NULL if only the other is required. If @target points to - * a non-NULL device node pointer, only entries targeting that node will be - * matched; if it points to a NULL value, it will receive the device node of - * the first matching target phandle, with a reference held. - * - * Return: 0 on success or a standard error code on failure. - */ -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - u32 map_mask, masked_rid; - int map_len; - const __be32 *map = NULL; - - if (!np || !map_name || (!target && !id_out)) - return -EINVAL; - - map = of_get_property(np, map_name, &map_len); - if (!map) { - if (target) - return -ENODEV; - /* Otherwise, no map implies no translation */ - *id_out = rid; - return 0; - } - - if (!map_len || map_len % (4 * sizeof(*map))) { - pr_err("%pOF: Error: Bad %s length: %d\n", np, - map_name, map_len); - return -EINVAL; - } - - /* The default is to select all bits. */ - map_mask = 0xffffffff; - - /* - * Can be overridden by "{iommu,msi}-map-mask" property. - * If of_property_read_u32() fails, the default is used. - */ - if (map_mask_name) - of_property_read_u32(np, map_mask_name, &map_mask); - - masked_rid = map_mask & rid; - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { - struct device_node *phandle_node; - u32 rid_base = be32_to_cpup(map + 0); - u32 phandle = be32_to_cpup(map + 1); - u32 out_base = be32_to_cpup(map + 2); - u32 rid_len = be32_to_cpup(map + 3); - - if (rid_base & ~map_mask) { - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", - np, map_name, map_name, - map_mask, rid_base); - return -EFAULT; - } - - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) - continue; - - phandle_node = of_find_node_by_phandle(phandle); - if (!phandle_node) - return -ENODEV; - - if (target) { - if (*target) - of_node_put(phandle_node); - else - *target = phandle_node; - - if (*target != phandle_node) - continue; - } - - if (id_out) - *id_out = masked_rid - rid_base + out_base; - - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", - np, map_name, map_mask, rid_base, out_base, - rid_len, rid, masked_rid - rid_base + out_base); - return 0; - } - - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", - np, map_name, rid, target && *target ? *target : NULL); - return -EFAULT; -} - #if IS_ENABLED(CONFIG_OF_IRQ) /** * of_irq_parse_pci - Resolve the interrupt for a PCI device diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index 4fa654e..432b53c 100644 --- a/include/linux/of_iommu.h +++ b/include/linux/of_iommu.h @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix, extern const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np); +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out); + #else static inline int of_get_dma_window(struct device_node *dn, const char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, return NULL; } +static inline int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + return -EINVAL; +} + #endif /* CONFIG_OF_IOMMU */ extern struct of_device_id __iommu_of_table; diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index 091033a..a23b44a 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent, int of_get_pci_domain_nr(struct device_node *node); int of_pci_get_max_link_speed(struct device_node *node); void of_pci_check_probe_only(void); -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out); #else static inline struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn) @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np) return -1; } -static inline int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - return -EINVAL; -} - static inline int of_pci_get_max_link_speed(struct device_node *node) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: devicetree, bharat.bhushan, stuyoder, frowand.list, gregkh, joro, linuxppc-dev, linux-kernel, leoyang.li, iommu, robh+dt, Nipun Gupta, linux-pci, bhelgaas, laurentiu.tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski iommu-map property is also used by devices with fsl-mc. This patch moves the of_pci_map_rid to generic location, so that it can be used by other busses too. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-- drivers/of/irq.c | 6 +-- drivers/pci/of.c | 101 -------------------------------------------- include/linux/of_iommu.h | 11 +++++ include/linux/of_pci.h | 10 ----- 5 files changed, 117 insertions(+), 117 deletions(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..4e7712f 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, return ops->of_xlate(dev, iommu_spec); } +/** + * of_map_rid - Translate a requester ID through a downstream mapping. + * @np: root complex device node. + * @rid: device requester ID to map. + * @map_name: property name of the map to use. + * @map_mask_name: optional property name of the mask to use. + * @target: optional pointer to a target device node. + * @id_out: optional pointer to receive the translated ID. + * + * Given a device requester ID, look up the appropriate implementation-defined + * platform ID and/or the target device which receives transactions on that + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or + * @id_out may be NULL if only the other is required. If @target points to + * a non-NULL device node pointer, only entries targeting that node will be + * matched; if it points to a NULL value, it will receive the device node of + * the first matching target phandle, with a reference held. + * + * Return: 0 on success or a standard error code on failure. + */ +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + u32 map_mask, masked_rid; + int map_len; + const __be32 *map = NULL; + + if (!np || !map_name || (!target && !id_out)) + return -EINVAL; + + map = of_get_property(np, map_name, &map_len); + if (!map) { + if (target) + return -ENODEV; + /* Otherwise, no map implies no translation */ + *id_out = rid; + return 0; + } + + if (!map_len || map_len % (4 * sizeof(*map))) { + pr_err("%pOF: Error: Bad %s length: %d\n", np, + map_name, map_len); + return -EINVAL; + } + + /* The default is to select all bits. */ + map_mask = 0xffffffff; + + /* + * Can be overridden by "{iommu,msi}-map-mask" property. + */ + if (map_mask_name) + of_property_read_u32(np, map_mask_name, &map_mask); + + masked_rid = map_mask & rid; + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { + struct device_node *phandle_node; + u32 rid_base = be32_to_cpup(map + 0); + u32 phandle = be32_to_cpup(map + 1); + u32 out_base = be32_to_cpup(map + 2); + u32 rid_len = be32_to_cpup(map + 3); + + if (rid_base & ~map_mask) { + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", + np, map_name, map_name, + map_mask, rid_base); + return -EFAULT; + } + + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) + continue; + + phandle_node = of_find_node_by_phandle(phandle); + if (!phandle_node) + return -ENODEV; + + if (target) { + if (*target) + of_node_put(phandle_node); + else + *target = phandle_node; + + if (*target != phandle_node) + continue; + } + + if (id_out) + *id_out = masked_rid - rid_base + out_base; + + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", + np, map_name, map_mask, rid_base, out_base, + rid_len, rid, masked_rid - rid_base + out_base); + return 0; + } + + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", + np, map_name, rid, target && *target ? *target : NULL); + return -EFAULT; +} + struct of_pci_iommu_alias_info { struct device *dev; struct device_node *np; @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_pci_map_rid(info->np, alias, "iommu-map", - "iommu-map-mask", &iommu_spec.np, - iommu_spec.args); + err = of_map_rid(info->np, alias, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); if (err) return err == -ENODEV ? NO_IOMMU : err; diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 02ad93a..b72eeec 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -22,7 +22,7 @@ #include <linux/module.h> #include <linux/of.h> #include <linux/of_irq.h> -#include <linux/of_pci.h> +#include <linux/of_iommu.h> #include <linux/string.h> #include <linux/slab.h> @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np, * "msi-map" property. */ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", - "msi-map-mask", np, &rid_out)) + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", + "msi-map-mask", np, &rid_out)) break; return rid_out; } diff --git a/drivers/pci/of.c b/drivers/pci/of.c index a28355c..d2cebbe 100644 --- a/drivers/pci/of.c +++ b/drivers/pci/of.c @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev, EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); #endif /* CONFIG_OF_ADDRESS */ -/** - * of_pci_map_rid - Translate a requester ID through a downstream mapping. - * @np: root complex device node. - * @rid: PCI requester ID to map. - * @map_name: property name of the map to use. - * @map_mask_name: optional property name of the mask to use. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. - * - * Given a PCI requester ID, look up the appropriate implementation-defined - * platform ID and/or the target device which receives transactions on that - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or - * @id_out may be NULL if only the other is required. If @target points to - * a non-NULL device node pointer, only entries targeting that node will be - * matched; if it points to a NULL value, it will receive the device node of - * the first matching target phandle, with a reference held. - * - * Return: 0 on success or a standard error code on failure. - */ -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - u32 map_mask, masked_rid; - int map_len; - const __be32 *map = NULL; - - if (!np || !map_name || (!target && !id_out)) - return -EINVAL; - - map = of_get_property(np, map_name, &map_len); - if (!map) { - if (target) - return -ENODEV; - /* Otherwise, no map implies no translation */ - *id_out = rid; - return 0; - } - - if (!map_len || map_len % (4 * sizeof(*map))) { - pr_err("%pOF: Error: Bad %s length: %d\n", np, - map_name, map_len); - return -EINVAL; - } - - /* The default is to select all bits. */ - map_mask = 0xffffffff; - - /* - * Can be overridden by "{iommu,msi}-map-mask" property. - * If of_property_read_u32() fails, the default is used. - */ - if (map_mask_name) - of_property_read_u32(np, map_mask_name, &map_mask); - - masked_rid = map_mask & rid; - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { - struct device_node *phandle_node; - u32 rid_base = be32_to_cpup(map + 0); - u32 phandle = be32_to_cpup(map + 1); - u32 out_base = be32_to_cpup(map + 2); - u32 rid_len = be32_to_cpup(map + 3); - - if (rid_base & ~map_mask) { - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", - np, map_name, map_name, - map_mask, rid_base); - return -EFAULT; - } - - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) - continue; - - phandle_node = of_find_node_by_phandle(phandle); - if (!phandle_node) - return -ENODEV; - - if (target) { - if (*target) - of_node_put(phandle_node); - else - *target = phandle_node; - - if (*target != phandle_node) - continue; - } - - if (id_out) - *id_out = masked_rid - rid_base + out_base; - - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", - np, map_name, map_mask, rid_base, out_base, - rid_len, rid, masked_rid - rid_base + out_base); - return 0; - } - - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", - np, map_name, rid, target && *target ? *target : NULL); - return -EFAULT; -} - #if IS_ENABLED(CONFIG_OF_IRQ) /** * of_irq_parse_pci - Resolve the interrupt for a PCI device diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index 4fa654e..432b53c 100644 --- a/include/linux/of_iommu.h +++ b/include/linux/of_iommu.h @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix, extern const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np); +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out); + #else static inline int of_get_dma_window(struct device_node *dn, const char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, return NULL; } +static inline int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + return -EINVAL; +} + #endif /* CONFIG_OF_IOMMU */ extern struct of_device_id __iommu_of_table; diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index 091033a..a23b44a 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent, int of_get_pci_domain_nr(struct device_node *node); int of_pci_get_max_link_speed(struct device_node *node); void of_pci_check_probe_only(void); -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out); #else static inline struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn) @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np) return -1; } -static inline int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - return -EINVAL; -} - static inline int of_pci_get_max_link_speed(struct device_node *node) { -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r iommu-map property is also used by devices with fsl-mc. This patch moves the of_pci_map_rid to generic location, so that it can be used by other busses too. Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-- drivers/of/irq.c | 6 +-- drivers/pci/of.c | 101 -------------------------------------------- include/linux/of_iommu.h | 11 +++++ include/linux/of_pci.h | 10 ----- 5 files changed, 117 insertions(+), 117 deletions(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..4e7712f 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, return ops->of_xlate(dev, iommu_spec); } +/** + * of_map_rid - Translate a requester ID through a downstream mapping. + * @np: root complex device node. + * @rid: device requester ID to map. + * @map_name: property name of the map to use. + * @map_mask_name: optional property name of the mask to use. + * @target: optional pointer to a target device node. + * @id_out: optional pointer to receive the translated ID. + * + * Given a device requester ID, look up the appropriate implementation-defined + * platform ID and/or the target device which receives transactions on that + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or + * @id_out may be NULL if only the other is required. If @target points to + * a non-NULL device node pointer, only entries targeting that node will be + * matched; if it points to a NULL value, it will receive the device node of + * the first matching target phandle, with a reference held. + * + * Return: 0 on success or a standard error code on failure. + */ +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + u32 map_mask, masked_rid; + int map_len; + const __be32 *map = NULL; + + if (!np || !map_name || (!target && !id_out)) + return -EINVAL; + + map = of_get_property(np, map_name, &map_len); + if (!map) { + if (target) + return -ENODEV; + /* Otherwise, no map implies no translation */ + *id_out = rid; + return 0; + } + + if (!map_len || map_len % (4 * sizeof(*map))) { + pr_err("%pOF: Error: Bad %s length: %d\n", np, + map_name, map_len); + return -EINVAL; + } + + /* The default is to select all bits. */ + map_mask = 0xffffffff; + + /* + * Can be overridden by "{iommu,msi}-map-mask" property. + */ + if (map_mask_name) + of_property_read_u32(np, map_mask_name, &map_mask); + + masked_rid = map_mask & rid; + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { + struct device_node *phandle_node; + u32 rid_base = be32_to_cpup(map + 0); + u32 phandle = be32_to_cpup(map + 1); + u32 out_base = be32_to_cpup(map + 2); + u32 rid_len = be32_to_cpup(map + 3); + + if (rid_base & ~map_mask) { + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", + np, map_name, map_name, + map_mask, rid_base); + return -EFAULT; + } + + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) + continue; + + phandle_node = of_find_node_by_phandle(phandle); + if (!phandle_node) + return -ENODEV; + + if (target) { + if (*target) + of_node_put(phandle_node); + else + *target = phandle_node; + + if (*target != phandle_node) + continue; + } + + if (id_out) + *id_out = masked_rid - rid_base + out_base; + + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", + np, map_name, map_mask, rid_base, out_base, + rid_len, rid, masked_rid - rid_base + out_base); + return 0; + } + + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", + np, map_name, rid, target && *target ? *target : NULL); + return -EFAULT; +} + struct of_pci_iommu_alias_info { struct device *dev; struct device_node *np; @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_pci_map_rid(info->np, alias, "iommu-map", - "iommu-map-mask", &iommu_spec.np, - iommu_spec.args); + err = of_map_rid(info->np, alias, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); if (err) return err == -ENODEV ? NO_IOMMU : err; diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 02ad93a..b72eeec 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -22,7 +22,7 @@ #include <linux/module.h> #include <linux/of.h> #include <linux/of_irq.h> -#include <linux/of_pci.h> +#include <linux/of_iommu.h> #include <linux/string.h> #include <linux/slab.h> @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np, * "msi-map" property. */ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", - "msi-map-mask", np, &rid_out)) + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", + "msi-map-mask", np, &rid_out)) break; return rid_out; } diff --git a/drivers/pci/of.c b/drivers/pci/of.c index a28355c..d2cebbe 100644 --- a/drivers/pci/of.c +++ b/drivers/pci/of.c @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev, EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); #endif /* CONFIG_OF_ADDRESS */ -/** - * of_pci_map_rid - Translate a requester ID through a downstream mapping. - * @np: root complex device node. - * @rid: PCI requester ID to map. - * @map_name: property name of the map to use. - * @map_mask_name: optional property name of the mask to use. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. - * - * Given a PCI requester ID, look up the appropriate implementation-defined - * platform ID and/or the target device which receives transactions on that - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or - * @id_out may be NULL if only the other is required. If @target points to - * a non-NULL device node pointer, only entries targeting that node will be - * matched; if it points to a NULL value, it will receive the device node of - * the first matching target phandle, with a reference held. - * - * Return: 0 on success or a standard error code on failure. - */ -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - u32 map_mask, masked_rid; - int map_len; - const __be32 *map = NULL; - - if (!np || !map_name || (!target && !id_out)) - return -EINVAL; - - map = of_get_property(np, map_name, &map_len); - if (!map) { - if (target) - return -ENODEV; - /* Otherwise, no map implies no translation */ - *id_out = rid; - return 0; - } - - if (!map_len || map_len % (4 * sizeof(*map))) { - pr_err("%pOF: Error: Bad %s length: %d\n", np, - map_name, map_len); - return -EINVAL; - } - - /* The default is to select all bits. */ - map_mask = 0xffffffff; - - /* - * Can be overridden by "{iommu,msi}-map-mask" property. - * If of_property_read_u32() fails, the default is used. - */ - if (map_mask_name) - of_property_read_u32(np, map_mask_name, &map_mask); - - masked_rid = map_mask & rid; - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { - struct device_node *phandle_node; - u32 rid_base = be32_to_cpup(map + 0); - u32 phandle = be32_to_cpup(map + 1); - u32 out_base = be32_to_cpup(map + 2); - u32 rid_len = be32_to_cpup(map + 3); - - if (rid_base & ~map_mask) { - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", - np, map_name, map_name, - map_mask, rid_base); - return -EFAULT; - } - - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) - continue; - - phandle_node = of_find_node_by_phandle(phandle); - if (!phandle_node) - return -ENODEV; - - if (target) { - if (*target) - of_node_put(phandle_node); - else - *target = phandle_node; - - if (*target != phandle_node) - continue; - } - - if (id_out) - *id_out = masked_rid - rid_base + out_base; - - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", - np, map_name, map_mask, rid_base, out_base, - rid_len, rid, masked_rid - rid_base + out_base); - return 0; - } - - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", - np, map_name, rid, target && *target ? *target : NULL); - return -EFAULT; -} - #if IS_ENABLED(CONFIG_OF_IRQ) /** * of_irq_parse_pci - Resolve the interrupt for a PCI device diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index 4fa654e..432b53c 100644 --- a/include/linux/of_iommu.h +++ b/include/linux/of_iommu.h @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix, extern const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np); +int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out); + #else static inline int of_get_dma_window(struct device_node *dn, const char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, return NULL; } +static inline int of_map_rid(struct device_node *np, u32 rid, + const char *map_name, const char *map_mask_name, + struct device_node **target, u32 *id_out) +{ + return -EINVAL; +} + #endif /* CONFIG_OF_IOMMU */ extern struct of_device_id __iommu_of_table; diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index 091033a..a23b44a 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent, int of_get_pci_domain_nr(struct device_node *node); int of_pci_get_max_link_speed(struct device_node *node); void of_pci_check_probe_only(void); -int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out); #else static inline struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn) @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np) return -1; } -static inline int of_pci_map_rid(struct device_node *np, u32 rid, - const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) -{ - return -EINVAL; -} - static inline int of_pci_get_max_link_speed(struct device_node *node) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-17 16:52 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-04-17 16:52 UTC (permalink / raw) To: Nipun Gupta, robh+dt, frowand.list Cc: will.deacon, mark.rutland, catalin.marinas, hch, gregkh, joro, m.szyprowski, shawnguo, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li On 17/04/18 11:21, Nipun Gupta wrote: > iommu-map property is also used by devices with fsl-mc. This > patch moves the of_pci_map_rid to generic location, so that it > can be used by other busses too. > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > --- > drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-- Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you don't want fsl-mc to have to depend on PCI, but this looks like a step in the wrong direction. I'm not entirely sure where of_map_rid() fits best, but from a quick look around the least-worst option might be drivers/of/of_address.c, unless Rob and Frank have a better idea of where generic DT-based ID translation routines could live? > drivers/of/irq.c | 6 +-- > drivers/pci/of.c | 101 -------------------------------------------- > include/linux/of_iommu.h | 11 +++++ > include/linux/of_pci.h | 10 ----- > 5 files changed, 117 insertions(+), 117 deletions(-) > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index 5c36a8b..4e7712f 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, > return ops->of_xlate(dev, iommu_spec); > } > > +/** > + * of_map_rid - Translate a requester ID through a downstream mapping. > + * @np: root complex device node. > + * @rid: device requester ID to map. > + * @map_name: property name of the map to use. > + * @map_mask_name: optional property name of the mask to use. > + * @target: optional pointer to a target device node. > + * @id_out: optional pointer to receive the translated ID. > + * > + * Given a device requester ID, look up the appropriate implementation-defined > + * platform ID and/or the target device which receives transactions on that > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or > + * @id_out may be NULL if only the other is required. If @target points to > + * a non-NULL device node pointer, only entries targeting that node will be > + * matched; if it points to a NULL value, it will receive the device node of > + * the first matching target phandle, with a reference held. > + * > + * Return: 0 on success or a standard error code on failure. > + */ > +int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out) > +{ > + u32 map_mask, masked_rid; > + int map_len; > + const __be32 *map = NULL; > + > + if (!np || !map_name || (!target && !id_out)) > + return -EINVAL; > + > + map = of_get_property(np, map_name, &map_len); > + if (!map) { > + if (target) > + return -ENODEV; > + /* Otherwise, no map implies no translation */ > + *id_out = rid; > + return 0; > + } > + > + if (!map_len || map_len % (4 * sizeof(*map))) { > + pr_err("%pOF: Error: Bad %s length: %d\n", np, > + map_name, map_len); > + return -EINVAL; > + } > + > + /* The default is to select all bits. */ > + map_mask = 0xffffffff; > + > + /* > + * Can be overridden by "{iommu,msi}-map-mask" property. > + */ > + if (map_mask_name) > + of_property_read_u32(np, map_mask_name, &map_mask); > + > + masked_rid = map_mask & rid; > + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > + struct device_node *phandle_node; > + u32 rid_base = be32_to_cpup(map + 0); > + u32 phandle = be32_to_cpup(map + 1); > + u32 out_base = be32_to_cpup(map + 2); > + u32 rid_len = be32_to_cpup(map + 3); > + > + if (rid_base & ~map_mask) { > + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", > + np, map_name, map_name, > + map_mask, rid_base); > + return -EFAULT; > + } > + > + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > + continue; > + > + phandle_node = of_find_node_by_phandle(phandle); > + if (!phandle_node) > + return -ENODEV; > + > + if (target) { > + if (*target) > + of_node_put(phandle_node); > + else > + *target = phandle_node; > + > + if (*target != phandle_node) > + continue; > + } > + > + if (id_out) > + *id_out = masked_rid - rid_base + out_base; > + > + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", > + np, map_name, map_mask, rid_base, out_base, > + rid_len, rid, masked_rid - rid_base + out_base); > + return 0; > + } > + > + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > + np, map_name, rid, target && *target ? *target : NULL); > + return -EFAULT; > +} > + > struct of_pci_iommu_alias_info { > struct device *dev; > struct device_node *np; > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) > struct of_phandle_args iommu_spec = { .args_count = 1 }; > int err; > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > - "iommu-map-mask", &iommu_spec.np, > - iommu_spec.args); > + err = of_map_rid(info->np, alias, "iommu-map", > + "iommu-map-mask", &iommu_spec.np, > + iommu_spec.args); Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if it's being touched again, that would be nice ;) Robin. > if (err) > return err == -ENODEV ? NO_IOMMU : err; > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 02ad93a..b72eeec 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -22,7 +22,7 @@ > #include <linux/module.h> > #include <linux/of.h> > #include <linux/of_irq.h> > -#include <linux/of_pci.h> > +#include <linux/of_iommu.h> > #include <linux/string.h> > #include <linux/slab.h> > > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np, > * "msi-map" property. > */ > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) > - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", > - "msi-map-mask", np, &rid_out)) > + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", > + "msi-map-mask", np, &rid_out)) > break; > return rid_out; > } > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index a28355c..d2cebbe 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev, > EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); > #endif /* CONFIG_OF_ADDRESS */ > > -/** > - * of_pci_map_rid - Translate a requester ID through a downstream mapping. > - * @np: root complex device node. > - * @rid: PCI requester ID to map. > - * @map_name: property name of the map to use. > - * @map_mask_name: optional property name of the mask to use. > - * @target: optional pointer to a target device node. > - * @id_out: optional pointer to receive the translated ID. > - * > - * Given a PCI requester ID, look up the appropriate implementation-defined > - * platform ID and/or the target device which receives transactions on that > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or > - * @id_out may be NULL if only the other is required. If @target points to > - * a non-NULL device node pointer, only entries targeting that node will be > - * matched; if it points to a NULL value, it will receive the device node of > - * the first matching target phandle, with a reference held. > - * > - * Return: 0 on success or a standard error code on failure. > - */ > -int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > -{ > - u32 map_mask, masked_rid; > - int map_len; > - const __be32 *map = NULL; > - > - if (!np || !map_name || (!target && !id_out)) > - return -EINVAL; > - > - map = of_get_property(np, map_name, &map_len); > - if (!map) { > - if (target) > - return -ENODEV; > - /* Otherwise, no map implies no translation */ > - *id_out = rid; > - return 0; > - } > - > - if (!map_len || map_len % (4 * sizeof(*map))) { > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > - map_name, map_len); > - return -EINVAL; > - } > - > - /* The default is to select all bits. */ > - map_mask = 0xffffffff; > - > - /* > - * Can be overridden by "{iommu,msi}-map-mask" property. > - * If of_property_read_u32() fails, the default is used. > - */ > - if (map_mask_name) > - of_property_read_u32(np, map_mask_name, &map_mask); > - > - masked_rid = map_mask & rid; > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > - struct device_node *phandle_node; > - u32 rid_base = be32_to_cpup(map + 0); > - u32 phandle = be32_to_cpup(map + 1); > - u32 out_base = be32_to_cpup(map + 2); > - u32 rid_len = be32_to_cpup(map + 3); > - > - if (rid_base & ~map_mask) { > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", > - np, map_name, map_name, > - map_mask, rid_base); > - return -EFAULT; > - } > - > - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > - continue; > - > - phandle_node = of_find_node_by_phandle(phandle); > - if (!phandle_node) > - return -ENODEV; > - > - if (target) { > - if (*target) > - of_node_put(phandle_node); > - else > - *target = phandle_node; > - > - if (*target != phandle_node) > - continue; > - } > - > - if (id_out) > - *id_out = masked_rid - rid_base + out_base; > - > - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", > - np, map_name, map_mask, rid_base, out_base, > - rid_len, rid, masked_rid - rid_base + out_base); > - return 0; > - } > - > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > - np, map_name, rid, target && *target ? *target : NULL); > - return -EFAULT; > -} > - > #if IS_ENABLED(CONFIG_OF_IRQ) > /** > * of_irq_parse_pci - Resolve the interrupt for a PCI device > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h > index 4fa654e..432b53c 100644 > --- a/include/linux/of_iommu.h > +++ b/include/linux/of_iommu.h > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix, > extern const struct iommu_ops *of_iommu_configure(struct device *dev, > struct device_node *master_np); > > +int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out); > + > #else > > static inline int of_get_dma_window(struct device_node *dn, const char *prefix, > @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, > return NULL; > } > > +static inline int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out) > +{ > + return -EINVAL; > +} > + > #endif /* CONFIG_OF_IOMMU */ > > extern struct of_device_id __iommu_of_table; > diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h > index 091033a..a23b44a 100644 > --- a/include/linux/of_pci.h > +++ b/include/linux/of_pci.h > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent, > int of_get_pci_domain_nr(struct device_node *node); > int of_pci_get_max_link_speed(struct device_node *node); > void of_pci_check_probe_only(void); > -int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out); > #else > static inline struct device_node *of_pci_find_child_device(struct device_node *parent, > unsigned int devfn) > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np) > return -1; > } > > -static inline int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > -{ > - return -EINVAL; > -} > - > static inline int > of_pci_get_max_link_speed(struct device_node *node) > { > ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-17 16:52 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-04-17 16:52 UTC (permalink / raw) To: linux-arm-kernel On 17/04/18 11:21, Nipun Gupta wrote: > iommu-map property is also used by devices with fsl-mc. This > patch moves the of_pci_map_rid to generic location, so that it > can be used by other busses too. > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > --- > drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-- Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you don't want fsl-mc to have to depend on PCI, but this looks like a step in the wrong direction. I'm not entirely sure where of_map_rid() fits best, but from a quick look around the least-worst option might be drivers/of/of_address.c, unless Rob and Frank have a better idea of where generic DT-based ID translation routines could live? > drivers/of/irq.c | 6 +-- > drivers/pci/of.c | 101 -------------------------------------------- > include/linux/of_iommu.h | 11 +++++ > include/linux/of_pci.h | 10 ----- > 5 files changed, 117 insertions(+), 117 deletions(-) > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index 5c36a8b..4e7712f 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, > return ops->of_xlate(dev, iommu_spec); > } > > +/** > + * of_map_rid - Translate a requester ID through a downstream mapping. > + * @np: root complex device node. > + * @rid: device requester ID to map. > + * @map_name: property name of the map to use. > + * @map_mask_name: optional property name of the mask to use. > + * @target: optional pointer to a target device node. > + * @id_out: optional pointer to receive the translated ID. > + * > + * Given a device requester ID, look up the appropriate implementation-defined > + * platform ID and/or the target device which receives transactions on that > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or > + * @id_out may be NULL if only the other is required. If @target points to > + * a non-NULL device node pointer, only entries targeting that node will be > + * matched; if it points to a NULL value, it will receive the device node of > + * the first matching target phandle, with a reference held. > + * > + * Return: 0 on success or a standard error code on failure. > + */ > +int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out) > +{ > + u32 map_mask, masked_rid; > + int map_len; > + const __be32 *map = NULL; > + > + if (!np || !map_name || (!target && !id_out)) > + return -EINVAL; > + > + map = of_get_property(np, map_name, &map_len); > + if (!map) { > + if (target) > + return -ENODEV; > + /* Otherwise, no map implies no translation */ > + *id_out = rid; > + return 0; > + } > + > + if (!map_len || map_len % (4 * sizeof(*map))) { > + pr_err("%pOF: Error: Bad %s length: %d\n", np, > + map_name, map_len); > + return -EINVAL; > + } > + > + /* The default is to select all bits. */ > + map_mask = 0xffffffff; > + > + /* > + * Can be overridden by "{iommu,msi}-map-mask" property. > + */ > + if (map_mask_name) > + of_property_read_u32(np, map_mask_name, &map_mask); > + > + masked_rid = map_mask & rid; > + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > + struct device_node *phandle_node; > + u32 rid_base = be32_to_cpup(map + 0); > + u32 phandle = be32_to_cpup(map + 1); > + u32 out_base = be32_to_cpup(map + 2); > + u32 rid_len = be32_to_cpup(map + 3); > + > + if (rid_base & ~map_mask) { > + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", > + np, map_name, map_name, > + map_mask, rid_base); > + return -EFAULT; > + } > + > + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > + continue; > + > + phandle_node = of_find_node_by_phandle(phandle); > + if (!phandle_node) > + return -ENODEV; > + > + if (target) { > + if (*target) > + of_node_put(phandle_node); > + else > + *target = phandle_node; > + > + if (*target != phandle_node) > + continue; > + } > + > + if (id_out) > + *id_out = masked_rid - rid_base + out_base; > + > + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", > + np, map_name, map_mask, rid_base, out_base, > + rid_len, rid, masked_rid - rid_base + out_base); > + return 0; > + } > + > + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > + np, map_name, rid, target && *target ? *target : NULL); > + return -EFAULT; > +} > + > struct of_pci_iommu_alias_info { > struct device *dev; > struct device_node *np; > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) > struct of_phandle_args iommu_spec = { .args_count = 1 }; > int err; > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > - "iommu-map-mask", &iommu_spec.np, > - iommu_spec.args); > + err = of_map_rid(info->np, alias, "iommu-map", > + "iommu-map-mask", &iommu_spec.np, > + iommu_spec.args); Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if it's being touched again, that would be nice ;) Robin. > if (err) > return err == -ENODEV ? NO_IOMMU : err; > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 02ad93a..b72eeec 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -22,7 +22,7 @@ > #include <linux/module.h> > #include <linux/of.h> > #include <linux/of_irq.h> > -#include <linux/of_pci.h> > +#include <linux/of_iommu.h> > #include <linux/string.h> > #include <linux/slab.h> > > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np, > * "msi-map" property. > */ > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) > - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", > - "msi-map-mask", np, &rid_out)) > + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", > + "msi-map-mask", np, &rid_out)) > break; > return rid_out; > } > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index a28355c..d2cebbe 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev, > EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); > #endif /* CONFIG_OF_ADDRESS */ > > -/** > - * of_pci_map_rid - Translate a requester ID through a downstream mapping. > - * @np: root complex device node. > - * @rid: PCI requester ID to map. > - * @map_name: property name of the map to use. > - * @map_mask_name: optional property name of the mask to use. > - * @target: optional pointer to a target device node. > - * @id_out: optional pointer to receive the translated ID. > - * > - * Given a PCI requester ID, look up the appropriate implementation-defined > - * platform ID and/or the target device which receives transactions on that > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or > - * @id_out may be NULL if only the other is required. If @target points to > - * a non-NULL device node pointer, only entries targeting that node will be > - * matched; if it points to a NULL value, it will receive the device node of > - * the first matching target phandle, with a reference held. > - * > - * Return: 0 on success or a standard error code on failure. > - */ > -int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > -{ > - u32 map_mask, masked_rid; > - int map_len; > - const __be32 *map = NULL; > - > - if (!np || !map_name || (!target && !id_out)) > - return -EINVAL; > - > - map = of_get_property(np, map_name, &map_len); > - if (!map) { > - if (target) > - return -ENODEV; > - /* Otherwise, no map implies no translation */ > - *id_out = rid; > - return 0; > - } > - > - if (!map_len || map_len % (4 * sizeof(*map))) { > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > - map_name, map_len); > - return -EINVAL; > - } > - > - /* The default is to select all bits. */ > - map_mask = 0xffffffff; > - > - /* > - * Can be overridden by "{iommu,msi}-map-mask" property. > - * If of_property_read_u32() fails, the default is used. > - */ > - if (map_mask_name) > - of_property_read_u32(np, map_mask_name, &map_mask); > - > - masked_rid = map_mask & rid; > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > - struct device_node *phandle_node; > - u32 rid_base = be32_to_cpup(map + 0); > - u32 phandle = be32_to_cpup(map + 1); > - u32 out_base = be32_to_cpup(map + 2); > - u32 rid_len = be32_to_cpup(map + 3); > - > - if (rid_base & ~map_mask) { > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", > - np, map_name, map_name, > - map_mask, rid_base); > - return -EFAULT; > - } > - > - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > - continue; > - > - phandle_node = of_find_node_by_phandle(phandle); > - if (!phandle_node) > - return -ENODEV; > - > - if (target) { > - if (*target) > - of_node_put(phandle_node); > - else > - *target = phandle_node; > - > - if (*target != phandle_node) > - continue; > - } > - > - if (id_out) > - *id_out = masked_rid - rid_base + out_base; > - > - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", > - np, map_name, map_mask, rid_base, out_base, > - rid_len, rid, masked_rid - rid_base + out_base); > - return 0; > - } > - > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > - np, map_name, rid, target && *target ? *target : NULL); > - return -EFAULT; > -} > - > #if IS_ENABLED(CONFIG_OF_IRQ) > /** > * of_irq_parse_pci - Resolve the interrupt for a PCI device > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h > index 4fa654e..432b53c 100644 > --- a/include/linux/of_iommu.h > +++ b/include/linux/of_iommu.h > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix, > extern const struct iommu_ops *of_iommu_configure(struct device *dev, > struct device_node *master_np); > > +int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out); > + > #else > > static inline int of_get_dma_window(struct device_node *dn, const char *prefix, > @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, > return NULL; > } > > +static inline int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out) > +{ > + return -EINVAL; > +} > + > #endif /* CONFIG_OF_IOMMU */ > > extern struct of_device_id __iommu_of_table; > diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h > index 091033a..a23b44a 100644 > --- a/include/linux/of_pci.h > +++ b/include/linux/of_pci.h > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent, > int of_get_pci_domain_nr(struct device_node *node); > int of_pci_get_max_link_speed(struct device_node *node); > void of_pci_check_probe_only(void); > -int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out); > #else > static inline struct device_node *of_pci_find_child_device(struct device_node *parent, > unsigned int devfn) > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np) > return -1; > } > > -static inline int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > -{ > - return -EINVAL; > -} > - > static inline int > of_pci_get_max_link_speed(struct device_node *node) > { > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-17 16:52 ` Robin Murphy 0 siblings, 0 replies; 106+ messages in thread From: Robin Murphy @ 2018-04-17 16:52 UTC (permalink / raw) To: Nipun Gupta, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, linux-pci-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On 17/04/18 11:21, Nipun Gupta wrote: > iommu-map property is also used by devices with fsl-mc. This > patch moves the of_pci_map_rid to generic location, so that it > can be used by other busses too. > > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> > --- > drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-- Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you don't want fsl-mc to have to depend on PCI, but this looks like a step in the wrong direction. I'm not entirely sure where of_map_rid() fits best, but from a quick look around the least-worst option might be drivers/of/of_address.c, unless Rob and Frank have a better idea of where generic DT-based ID translation routines could live? > drivers/of/irq.c | 6 +-- > drivers/pci/of.c | 101 -------------------------------------------- > include/linux/of_iommu.h | 11 +++++ > include/linux/of_pci.h | 10 ----- > 5 files changed, 117 insertions(+), 117 deletions(-) > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index 5c36a8b..4e7712f 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, > return ops->of_xlate(dev, iommu_spec); > } > > +/** > + * of_map_rid - Translate a requester ID through a downstream mapping. > + * @np: root complex device node. > + * @rid: device requester ID to map. > + * @map_name: property name of the map to use. > + * @map_mask_name: optional property name of the mask to use. > + * @target: optional pointer to a target device node. > + * @id_out: optional pointer to receive the translated ID. > + * > + * Given a device requester ID, look up the appropriate implementation-defined > + * platform ID and/or the target device which receives transactions on that > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or > + * @id_out may be NULL if only the other is required. If @target points to > + * a non-NULL device node pointer, only entries targeting that node will be > + * matched; if it points to a NULL value, it will receive the device node of > + * the first matching target phandle, with a reference held. > + * > + * Return: 0 on success or a standard error code on failure. > + */ > +int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out) > +{ > + u32 map_mask, masked_rid; > + int map_len; > + const __be32 *map = NULL; > + > + if (!np || !map_name || (!target && !id_out)) > + return -EINVAL; > + > + map = of_get_property(np, map_name, &map_len); > + if (!map) { > + if (target) > + return -ENODEV; > + /* Otherwise, no map implies no translation */ > + *id_out = rid; > + return 0; > + } > + > + if (!map_len || map_len % (4 * sizeof(*map))) { > + pr_err("%pOF: Error: Bad %s length: %d\n", np, > + map_name, map_len); > + return -EINVAL; > + } > + > + /* The default is to select all bits. */ > + map_mask = 0xffffffff; > + > + /* > + * Can be overridden by "{iommu,msi}-map-mask" property. > + */ > + if (map_mask_name) > + of_property_read_u32(np, map_mask_name, &map_mask); > + > + masked_rid = map_mask & rid; > + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > + struct device_node *phandle_node; > + u32 rid_base = be32_to_cpup(map + 0); > + u32 phandle = be32_to_cpup(map + 1); > + u32 out_base = be32_to_cpup(map + 2); > + u32 rid_len = be32_to_cpup(map + 3); > + > + if (rid_base & ~map_mask) { > + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", > + np, map_name, map_name, > + map_mask, rid_base); > + return -EFAULT; > + } > + > + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > + continue; > + > + phandle_node = of_find_node_by_phandle(phandle); > + if (!phandle_node) > + return -ENODEV; > + > + if (target) { > + if (*target) > + of_node_put(phandle_node); > + else > + *target = phandle_node; > + > + if (*target != phandle_node) > + continue; > + } > + > + if (id_out) > + *id_out = masked_rid - rid_base + out_base; > + > + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", > + np, map_name, map_mask, rid_base, out_base, > + rid_len, rid, masked_rid - rid_base + out_base); > + return 0; > + } > + > + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > + np, map_name, rid, target && *target ? *target : NULL); > + return -EFAULT; > +} > + > struct of_pci_iommu_alias_info { > struct device *dev; > struct device_node *np; > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) > struct of_phandle_args iommu_spec = { .args_count = 1 }; > int err; > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > - "iommu-map-mask", &iommu_spec.np, > - iommu_spec.args); > + err = of_map_rid(info->np, alias, "iommu-map", > + "iommu-map-mask", &iommu_spec.np, > + iommu_spec.args); Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if it's being touched again, that would be nice ;) Robin. > if (err) > return err == -ENODEV ? NO_IOMMU : err; > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 02ad93a..b72eeec 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -22,7 +22,7 @@ > #include <linux/module.h> > #include <linux/of.h> > #include <linux/of_irq.h> > -#include <linux/of_pci.h> > +#include <linux/of_iommu.h> > #include <linux/string.h> > #include <linux/slab.h> > > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np, > * "msi-map" property. > */ > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) > - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", > - "msi-map-mask", np, &rid_out)) > + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", > + "msi-map-mask", np, &rid_out)) > break; > return rid_out; > } > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index a28355c..d2cebbe 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev, > EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); > #endif /* CONFIG_OF_ADDRESS */ > > -/** > - * of_pci_map_rid - Translate a requester ID through a downstream mapping. > - * @np: root complex device node. > - * @rid: PCI requester ID to map. > - * @map_name: property name of the map to use. > - * @map_mask_name: optional property name of the mask to use. > - * @target: optional pointer to a target device node. > - * @id_out: optional pointer to receive the translated ID. > - * > - * Given a PCI requester ID, look up the appropriate implementation-defined > - * platform ID and/or the target device which receives transactions on that > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or > - * @id_out may be NULL if only the other is required. If @target points to > - * a non-NULL device node pointer, only entries targeting that node will be > - * matched; if it points to a NULL value, it will receive the device node of > - * the first matching target phandle, with a reference held. > - * > - * Return: 0 on success or a standard error code on failure. > - */ > -int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > -{ > - u32 map_mask, masked_rid; > - int map_len; > - const __be32 *map = NULL; > - > - if (!np || !map_name || (!target && !id_out)) > - return -EINVAL; > - > - map = of_get_property(np, map_name, &map_len); > - if (!map) { > - if (target) > - return -ENODEV; > - /* Otherwise, no map implies no translation */ > - *id_out = rid; > - return 0; > - } > - > - if (!map_len || map_len % (4 * sizeof(*map))) { > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > - map_name, map_len); > - return -EINVAL; > - } > - > - /* The default is to select all bits. */ > - map_mask = 0xffffffff; > - > - /* > - * Can be overridden by "{iommu,msi}-map-mask" property. > - * If of_property_read_u32() fails, the default is used. > - */ > - if (map_mask_name) > - of_property_read_u32(np, map_mask_name, &map_mask); > - > - masked_rid = map_mask & rid; > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > - struct device_node *phandle_node; > - u32 rid_base = be32_to_cpup(map + 0); > - u32 phandle = be32_to_cpup(map + 1); > - u32 out_base = be32_to_cpup(map + 2); > - u32 rid_len = be32_to_cpup(map + 3); > - > - if (rid_base & ~map_mask) { > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n", > - np, map_name, map_name, > - map_mask, rid_base); > - return -EFAULT; > - } > - > - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > - continue; > - > - phandle_node = of_find_node_by_phandle(phandle); > - if (!phandle_node) > - return -ENODEV; > - > - if (target) { > - if (*target) > - of_node_put(phandle_node); > - else > - *target = phandle_node; > - > - if (*target != phandle_node) > - continue; > - } > - > - if (id_out) > - *id_out = masked_rid - rid_base + out_base; > - > - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n", > - np, map_name, map_mask, rid_base, out_base, > - rid_len, rid, masked_rid - rid_base + out_base); > - return 0; > - } > - > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > - np, map_name, rid, target && *target ? *target : NULL); > - return -EFAULT; > -} > - > #if IS_ENABLED(CONFIG_OF_IRQ) > /** > * of_irq_parse_pci - Resolve the interrupt for a PCI device > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h > index 4fa654e..432b53c 100644 > --- a/include/linux/of_iommu.h > +++ b/include/linux/of_iommu.h > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix, > extern const struct iommu_ops *of_iommu_configure(struct device *dev, > struct device_node *master_np); > > +int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out); > + > #else > > static inline int of_get_dma_window(struct device_node *dn, const char *prefix, > @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev, > return NULL; > } > > +static inline int of_map_rid(struct device_node *np, u32 rid, > + const char *map_name, const char *map_mask_name, > + struct device_node **target, u32 *id_out) > +{ > + return -EINVAL; > +} > + > #endif /* CONFIG_OF_IOMMU */ > > extern struct of_device_id __iommu_of_table; > diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h > index 091033a..a23b44a 100644 > --- a/include/linux/of_pci.h > +++ b/include/linux/of_pci.h > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent, > int of_get_pci_domain_nr(struct device_node *node); > int of_pci_get_max_link_speed(struct device_node *node); > void of_pci_check_probe_only(void); > -int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out); > #else > static inline struct device_node *of_pci_find_child_device(struct device_node *parent, > unsigned int devfn) > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np) > return -1; > } > > -static inline int of_pci_map_rid(struct device_node *np, u32 rid, > - const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > -{ > - return -EINVAL; > -} > - > static inline int > of_pci_get_max_link_speed(struct device_node *node) > { > ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 5:09 ` Bharat Bhushan 0 siblings, 0 replies; 106+ messages in thread From: Bharat Bhushan @ 2018-04-18 5:09 UTC (permalink / raw) To: Robin Murphy, Nipun Gupta, robh+dt, frowand.list Cc: will.deacon, mark.rutland, catalin.marinas, hch, gregkh, joro, m.szyprowski, shawnguo, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, stuyoder, Laurentiu Tudor, Leo Li > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org; > frowand.list@gmail.com > Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com; > hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org; > m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com; > iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc- > dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. Nipun, please clarify that only function name is changed and rest of body is same. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? Yes, this will be a problem with MSI > I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? drivers/of/address.c may be proper place to move until someone have better idea. Thanks -Bharat > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index > > 5c36a8b..4e7712f 100644 > > --- a/drivers/iommu/of_iommu.c > > +++ b/drivers/iommu/of_iommu.c > > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, > > return ops->of_xlate(dev, iommu_spec); > > } > > > > +/** > > + * of_map_rid - Translate a requester ID through a downstream mapping. > > + * @np: root complex device node. > > + * @rid: device requester ID to map. > > + * @map_name: property name of the map to use. > > + * @map_mask_name: optional property name of the mask to use. > > + * @target: optional pointer to a target device node. > > + * @id_out: optional pointer to receive the translated ID. > > + * > > + * Given a device requester ID, look up the appropriate > > +implementation-defined > > + * platform ID and/or the target device which receives transactions > > +on that > > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > +@target or > > + * @id_out may be NULL if only the other is required. If @target > > +points to > > + * a non-NULL device node pointer, only entries targeting that node > > +will be > > + * matched; if it points to a NULL value, it will receive the device > > +node of > > + * the first matching target phandle, with a reference held. > > + * > > + * Return: 0 on success or a standard error code on failure. > > + */ > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + u32 map_mask, masked_rid; > > + int map_len; > > + const __be32 *map = NULL; > > + > > + if (!np || !map_name || (!target && !id_out)) > > + return -EINVAL; > > + > > + map = of_get_property(np, map_name, &map_len); > > + if (!map) { > > + if (target) > > + return -ENODEV; > > + /* Otherwise, no map implies no translation */ > > + *id_out = rid; > > + return 0; > > + } > > + > > + if (!map_len || map_len % (4 * sizeof(*map))) { > > + pr_err("%pOF: Error: Bad %s length: %d\n", np, > > + map_name, map_len); > > + return -EINVAL; > > + } > > + > > + /* The default is to select all bits. */ > > + map_mask = 0xffffffff; > > + > > + /* > > + * Can be overridden by "{iommu,msi}-map-mask" property. > > + */ > > + if (map_mask_name) > > + of_property_read_u32(np, map_mask_name, &map_mask); > > + > > + masked_rid = map_mask & rid; > > + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > + struct device_node *phandle_node; > > + u32 rid_base = be32_to_cpup(map + 0); > > + u32 phandle = be32_to_cpup(map + 1); > > + u32 out_base = be32_to_cpup(map + 2); > > + u32 rid_len = be32_to_cpup(map + 3); > > + > > + if (rid_base & ~map_mask) { > > + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > + np, map_name, map_name, > > + map_mask, rid_base); > > + return -EFAULT; > > + } > > + > > + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > + continue; > > + > > + phandle_node = of_find_node_by_phandle(phandle); > > + if (!phandle_node) > > + return -ENODEV; > > + > > + if (target) { > > + if (*target) > > + of_node_put(phandle_node); > > + else > > + *target = phandle_node; > > + > > + if (*target != phandle_node) > > + continue; > > + } > > + > > + if (id_out) > > + *id_out = masked_rid - rid_base + out_base; > > + > > + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > + np, map_name, map_mask, rid_base, out_base, > > + rid_len, rid, masked_rid - rid_base + out_base); > > + return 0; > > + } > > + > > + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > + np, map_name, rid, target && *target ? *target : NULL); > > + return -EFAULT; > > +} > > + > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) > > Robin. > > > if (err) > > return err == -ENODEV ? NO_IOMMU : err; > > > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index > > 02ad93a..b72eeec 100644 > > --- a/drivers/of/irq.c > > +++ b/drivers/of/irq.c > > @@ -22,7 +22,7 @@ > > #include <linux/module.h> > > #include <linux/of.h> > > #include <linux/of_irq.h> > > -#include <linux/of_pci.h> > > +#include <linux/of_iommu.h> > > #include <linux/string.h> > > #include <linux/slab.h> > > > > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, > struct device_node **np, > > * "msi-map" property. > > */ > > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) > > - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", > > - "msi-map-mask", np, &rid_out)) > > + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", > > + "msi-map-mask", np, &rid_out)) > > break; > > return rid_out; > > } > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index > > a28355c..d2cebbe 100644 > > --- a/drivers/pci/of.c > > +++ b/drivers/pci/of.c > > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct > device_node *dev, > > EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); > > #endif /* CONFIG_OF_ADDRESS */ > > > > -/** > > - * of_pci_map_rid - Translate a requester ID through a downstream mapping. > > - * @np: root complex device node. > > - * @rid: PCI requester ID to map. > > - * @map_name: property name of the map to use. > > - * @map_mask_name: optional property name of the mask to use. > > - * @target: optional pointer to a target device node. > > - * @id_out: optional pointer to receive the translated ID. > > - * > > - * Given a PCI requester ID, look up the appropriate > > implementation-defined > > - * platform ID and/or the target device which receives transactions > > on that > > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > @target or > > - * @id_out may be NULL if only the other is required. If @target > > points to > > - * a non-NULL device node pointer, only entries targeting that node > > will be > > - * matched; if it points to a NULL value, it will receive the device > > node of > > - * the first matching target phandle, with a reference held. > > - * > > - * Return: 0 on success or a standard error code on failure. > > - */ > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - u32 map_mask, masked_rid; > > - int map_len; > > - const __be32 *map = NULL; > > - > > - if (!np || !map_name || (!target && !id_out)) > > - return -EINVAL; > > - > > - map = of_get_property(np, map_name, &map_len); > > - if (!map) { > > - if (target) > > - return -ENODEV; > > - /* Otherwise, no map implies no translation */ > > - *id_out = rid; > > - return 0; > > - } > > - > > - if (!map_len || map_len % (4 * sizeof(*map))) { > > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > > - map_name, map_len); > > - return -EINVAL; > > - } > > - > > - /* The default is to select all bits. */ > > - map_mask = 0xffffffff; > > - > > - /* > > - * Can be overridden by "{iommu,msi}-map-mask" property. > > - * If of_property_read_u32() fails, the default is used. > > - */ > > - if (map_mask_name) > > - of_property_read_u32(np, map_mask_name, &map_mask); > > - > > - masked_rid = map_mask & rid; > > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > - struct device_node *phandle_node; > > - u32 rid_base = be32_to_cpup(map + 0); > > - u32 phandle = be32_to_cpup(map + 1); > > - u32 out_base = be32_to_cpup(map + 2); > > - u32 rid_len = be32_to_cpup(map + 3); > > - > > - if (rid_base & ~map_mask) { > > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > - np, map_name, map_name, > > - map_mask, rid_base); > > - return -EFAULT; > > - } > > - > > - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > - continue; > > - > > - phandle_node = of_find_node_by_phandle(phandle); > > - if (!phandle_node) > > - return -ENODEV; > > - > > - if (target) { > > - if (*target) > > - of_node_put(phandle_node); > > - else > > - *target = phandle_node; > > - > > - if (*target != phandle_node) > > - continue; > > - } > > - > > - if (id_out) > > - *id_out = masked_rid - rid_base + out_base; > > - > > - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > - np, map_name, map_mask, rid_base, out_base, > > - rid_len, rid, masked_rid - rid_base + out_base); > > - return 0; > > - } > > - > > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > - np, map_name, rid, target && *target ? *target : NULL); > > - return -EFAULT; > > -} > > - > > #if IS_ENABLED(CONFIG_OF_IRQ) > > /** > > * of_irq_parse_pci - Resolve the interrupt for a PCI device diff > > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index > > 4fa654e..432b53c 100644 > > --- a/include/linux/of_iommu.h > > +++ b/include/linux/of_iommu.h > > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node > *dn, const char *prefix, > > extern const struct iommu_ops *of_iommu_configure(struct device *dev, > > struct device_node *master_np); > > > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out); > > + > > #else > > > > static inline int of_get_dma_window(struct device_node *dn, const > > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops > *of_iommu_configure(struct device *dev, > > return NULL; > > } > > > > +static inline int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char > *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + return -EINVAL; > > +} > > + > > #endif /* CONFIG_OF_IOMMU */ > > > > extern struct of_device_id __iommu_of_table; diff --git > > a/include/linux/of_pci.h b/include/linux/of_pci.h index > > 091033a..a23b44a 100644 > > --- a/include/linux/of_pci.h > > +++ b/include/linux/of_pci.h > > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct > device_node *parent, > > int of_get_pci_domain_nr(struct device_node *node); > > int of_pci_get_max_link_speed(struct device_node *node); > > void of_pci_check_probe_only(void); > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out); > > #else > > static inline struct device_node *of_pci_find_child_device(struct device_node > *parent, > > unsigned int devfn) > > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node > *np) > > return -1; > > } > > > > -static inline int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - return -EINVAL; > > -} > > - > > static inline int > > of_pci_get_max_link_speed(struct device_node *node) > > { > > ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 5:09 ` Bharat Bhushan 0 siblings, 0 replies; 106+ messages in thread From: Bharat Bhushan @ 2018-04-18 5:09 UTC (permalink / raw) To: linux-arm-kernel > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy at arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt at kernel.org; > frowand.list at gmail.com > Cc: will.deacon at arm.com; mark.rutland at arm.com; catalin.marinas at arm.com; > hch at lst.de; gregkh at linuxfoundation.org; joro at 8bytes.org; > m.szyprowski at samsung.com; shawnguo at kernel.org; bhelgaas at google.com; > iommu at lists.linux-foundation.org; linux-kernel at vger.kernel.org; > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linuxppc- > dev at lists.ozlabs.org; linux-pci at vger.kernel.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. Nipun, please clarify that only function name is changed and rest of body is same. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? Yes, this will be a problem with MSI > I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? drivers/of/address.c may be proper place to move until someone have better idea. Thanks -Bharat > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index > > 5c36a8b..4e7712f 100644 > > --- a/drivers/iommu/of_iommu.c > > +++ b/drivers/iommu/of_iommu.c > > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, > > return ops->of_xlate(dev, iommu_spec); > > } > > > > +/** > > + * of_map_rid - Translate a requester ID through a downstream mapping. > > + * @np: root complex device node. > > + * @rid: device requester ID to map. > > + * @map_name: property name of the map to use. > > + * @map_mask_name: optional property name of the mask to use. > > + * @target: optional pointer to a target device node. > > + * @id_out: optional pointer to receive the translated ID. > > + * > > + * Given a device requester ID, look up the appropriate > > +implementation-defined > > + * platform ID and/or the target device which receives transactions > > +on that > > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > + at target or > > + * @id_out may be NULL if only the other is required. If @target > > +points to > > + * a non-NULL device node pointer, only entries targeting that node > > +will be > > + * matched; if it points to a NULL value, it will receive the device > > +node of > > + * the first matching target phandle, with a reference held. > > + * > > + * Return: 0 on success or a standard error code on failure. > > + */ > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + u32 map_mask, masked_rid; > > + int map_len; > > + const __be32 *map = NULL; > > + > > + if (!np || !map_name || (!target && !id_out)) > > + return -EINVAL; > > + > > + map = of_get_property(np, map_name, &map_len); > > + if (!map) { > > + if (target) > > + return -ENODEV; > > + /* Otherwise, no map implies no translation */ > > + *id_out = rid; > > + return 0; > > + } > > + > > + if (!map_len || map_len % (4 * sizeof(*map))) { > > + pr_err("%pOF: Error: Bad %s length: %d\n", np, > > + map_name, map_len); > > + return -EINVAL; > > + } > > + > > + /* The default is to select all bits. */ > > + map_mask = 0xffffffff; > > + > > + /* > > + * Can be overridden by "{iommu,msi}-map-mask" property. > > + */ > > + if (map_mask_name) > > + of_property_read_u32(np, map_mask_name, &map_mask); > > + > > + masked_rid = map_mask & rid; > > + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > + struct device_node *phandle_node; > > + u32 rid_base = be32_to_cpup(map + 0); > > + u32 phandle = be32_to_cpup(map + 1); > > + u32 out_base = be32_to_cpup(map + 2); > > + u32 rid_len = be32_to_cpup(map + 3); > > + > > + if (rid_base & ~map_mask) { > > + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > + np, map_name, map_name, > > + map_mask, rid_base); > > + return -EFAULT; > > + } > > + > > + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > + continue; > > + > > + phandle_node = of_find_node_by_phandle(phandle); > > + if (!phandle_node) > > + return -ENODEV; > > + > > + if (target) { > > + if (*target) > > + of_node_put(phandle_node); > > + else > > + *target = phandle_node; > > + > > + if (*target != phandle_node) > > + continue; > > + } > > + > > + if (id_out) > > + *id_out = masked_rid - rid_base + out_base; > > + > > + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > + np, map_name, map_mask, rid_base, out_base, > > + rid_len, rid, masked_rid - rid_base + out_base); > > + return 0; > > + } > > + > > + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > + np, map_name, rid, target && *target ? *target : NULL); > > + return -EFAULT; > > +} > > + > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) > > Robin. > > > if (err) > > return err == -ENODEV ? NO_IOMMU : err; > > > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index > > 02ad93a..b72eeec 100644 > > --- a/drivers/of/irq.c > > +++ b/drivers/of/irq.c > > @@ -22,7 +22,7 @@ > > #include <linux/module.h> > > #include <linux/of.h> > > #include <linux/of_irq.h> > > -#include <linux/of_pci.h> > > +#include <linux/of_iommu.h> > > #include <linux/string.h> > > #include <linux/slab.h> > > > > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, > struct device_node **np, > > * "msi-map" property. > > */ > > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) > > - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", > > - "msi-map-mask", np, &rid_out)) > > + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", > > + "msi-map-mask", np, &rid_out)) > > break; > > return rid_out; > > } > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index > > a28355c..d2cebbe 100644 > > --- a/drivers/pci/of.c > > +++ b/drivers/pci/of.c > > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct > device_node *dev, > > EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); > > #endif /* CONFIG_OF_ADDRESS */ > > > > -/** > > - * of_pci_map_rid - Translate a requester ID through a downstream mapping. > > - * @np: root complex device node. > > - * @rid: PCI requester ID to map. > > - * @map_name: property name of the map to use. > > - * @map_mask_name: optional property name of the mask to use. > > - * @target: optional pointer to a target device node. > > - * @id_out: optional pointer to receive the translated ID. > > - * > > - * Given a PCI requester ID, look up the appropriate > > implementation-defined > > - * platform ID and/or the target device which receives transactions > > on that > > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > @target or > > - * @id_out may be NULL if only the other is required. If @target > > points to > > - * a non-NULL device node pointer, only entries targeting that node > > will be > > - * matched; if it points to a NULL value, it will receive the device > > node of > > - * the first matching target phandle, with a reference held. > > - * > > - * Return: 0 on success or a standard error code on failure. > > - */ > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - u32 map_mask, masked_rid; > > - int map_len; > > - const __be32 *map = NULL; > > - > > - if (!np || !map_name || (!target && !id_out)) > > - return -EINVAL; > > - > > - map = of_get_property(np, map_name, &map_len); > > - if (!map) { > > - if (target) > > - return -ENODEV; > > - /* Otherwise, no map implies no translation */ > > - *id_out = rid; > > - return 0; > > - } > > - > > - if (!map_len || map_len % (4 * sizeof(*map))) { > > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > > - map_name, map_len); > > - return -EINVAL; > > - } > > - > > - /* The default is to select all bits. */ > > - map_mask = 0xffffffff; > > - > > - /* > > - * Can be overridden by "{iommu,msi}-map-mask" property. > > - * If of_property_read_u32() fails, the default is used. > > - */ > > - if (map_mask_name) > > - of_property_read_u32(np, map_mask_name, &map_mask); > > - > > - masked_rid = map_mask & rid; > > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > - struct device_node *phandle_node; > > - u32 rid_base = be32_to_cpup(map + 0); > > - u32 phandle = be32_to_cpup(map + 1); > > - u32 out_base = be32_to_cpup(map + 2); > > - u32 rid_len = be32_to_cpup(map + 3); > > - > > - if (rid_base & ~map_mask) { > > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > - np, map_name, map_name, > > - map_mask, rid_base); > > - return -EFAULT; > > - } > > - > > - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > - continue; > > - > > - phandle_node = of_find_node_by_phandle(phandle); > > - if (!phandle_node) > > - return -ENODEV; > > - > > - if (target) { > > - if (*target) > > - of_node_put(phandle_node); > > - else > > - *target = phandle_node; > > - > > - if (*target != phandle_node) > > - continue; > > - } > > - > > - if (id_out) > > - *id_out = masked_rid - rid_base + out_base; > > - > > - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > - np, map_name, map_mask, rid_base, out_base, > > - rid_len, rid, masked_rid - rid_base + out_base); > > - return 0; > > - } > > - > > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > - np, map_name, rid, target && *target ? *target : NULL); > > - return -EFAULT; > > -} > > - > > #if IS_ENABLED(CONFIG_OF_IRQ) > > /** > > * of_irq_parse_pci - Resolve the interrupt for a PCI device diff > > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index > > 4fa654e..432b53c 100644 > > --- a/include/linux/of_iommu.h > > +++ b/include/linux/of_iommu.h > > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node > *dn, const char *prefix, > > extern const struct iommu_ops *of_iommu_configure(struct device *dev, > > struct device_node *master_np); > > > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out); > > + > > #else > > > > static inline int of_get_dma_window(struct device_node *dn, const > > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops > *of_iommu_configure(struct device *dev, > > return NULL; > > } > > > > +static inline int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char > *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + return -EINVAL; > > +} > > + > > #endif /* CONFIG_OF_IOMMU */ > > > > extern struct of_device_id __iommu_of_table; diff --git > > a/include/linux/of_pci.h b/include/linux/of_pci.h index > > 091033a..a23b44a 100644 > > --- a/include/linux/of_pci.h > > +++ b/include/linux/of_pci.h > > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct > device_node *parent, > > int of_get_pci_domain_nr(struct device_node *node); > > int of_pci_get_max_link_speed(struct device_node *node); > > void of_pci_check_probe_only(void); > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out); > > #else > > static inline struct device_node *of_pci_find_child_device(struct device_node > *parent, > > unsigned int devfn) > > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node > *np) > > return -1; > > } > > > > -static inline int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - return -EINVAL; > > -} > > - > > static inline int > > of_pci_get_max_link_speed(struct device_node *node) > > { > > ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 5:09 ` Bharat Bhushan 0 siblings, 0 replies; 106+ messages in thread From: Bharat Bhushan @ 2018-04-18 5:09 UTC (permalink / raw) To: Robin Murphy, Nipun Gupta, robh+dt, frowand.list Cc: will.deacon, mark.rutland, catalin.marinas, hch, gregkh, joro, m.szyprowski, shawnguo, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, stuyoder, Laurentiu Tudor, Leo Li DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAy MDE4IDEwOjIzIFBNDQo+IFRvOiBOaXB1biBHdXB0YSA8bmlwdW4uZ3VwdGFAbnhwLmNvbT47IHJv YmgrZHRAa2VybmVsLm9yZzsNCj4gZnJvd2FuZC5saXN0QGdtYWlsLmNvbQ0KPiBDYzogd2lsbC5k ZWFjb25AYXJtLmNvbTsgbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bhcm0u Y29tOw0KPiBoY2hAbHN0LmRlOyBncmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsgam9yb0A4Ynl0 ZXMub3JnOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IHNoYXduZ3VvQGtlcm5lbC5vcmc7 IGJoZWxnYWFzQGdvb2dsZS5jb207DQo+IGlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3Jn OyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVs Lm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy0NCj4g ZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmc7IEJoYXJhdCBC aHVzaGFuDQo+IDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPjsgc3R1eW9kZXJAZ21haWwuY29tOyBM YXVyZW50aXUgVHVkb3INCj4gPGxhdXJlbnRpdS50dWRvckBueHAuY29tPjsgTGVvIExpIDxsZW95 YW5nLmxpQG54cC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi82IHYyXSBpb21tdTogb2Y6 IG1ha2Ugb2ZfcGNpX21hcF9yaWQoKSBhdmFpbGFibGUgZm9yDQo+IG90aGVyIGRldmljZXMgdG9v DQo+IA0KPiBPbiAxNy8wNC8xOCAxMToyMSwgTmlwdW4gR3VwdGEgd3JvdGU6DQo+ID4gaW9tbXUt bWFwIHByb3BlcnR5IGlzIGFsc28gdXNlZCBieSBkZXZpY2VzIHdpdGggZnNsLW1jLiBUaGlzIHBh dGNoDQo+ID4gbW92ZXMgdGhlIG9mX3BjaV9tYXBfcmlkIHRvIGdlbmVyaWMgbG9jYXRpb24sIHNv IHRoYXQgaXQgY2FuIGJlIHVzZWQNCj4gPiBieSBvdGhlciBidXNzZXMgdG9vLg0KDQpOaXB1biwg cGxlYXNlIGNsYXJpZnkgdGhhdCBvbmx5IGZ1bmN0aW9uIG5hbWUgaXMgY2hhbmdlZCBhbmQgcmVz dCBvZiBib2R5IGlzIHNhbWUuDQoNCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IE5pcHVuIEd1cHRh IDxuaXB1bi5ndXB0YUBueHAuY29tPg0KPiA+IC0tLQ0KPiA+ICAgZHJpdmVycy9pb21tdS9vZl9p b21tdS5jIHwgMTA2DQo+ID4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrLS0NCj4gDQo+IERvZXNuJ3QgdGhpcyBicmVhayAibXNpLXBhcmVudCIgcGFyc2luZyBm b3IgIUNPTkZJR19PRl9JT01NVT8NCg0KWWVzLCB0aGlzIHdpbGwgYmUgYSBwcm9ibGVtIHdpdGgg TVNJIA0KDQo+IEkgZ3Vlc3MgeW91DQo+IGRvbid0IHdhbnQgZnNsLW1jIHRvIGhhdmUgdG8gZGVw ZW5kIG9uIFBDSSwgYnV0IHRoaXMgbG9va3MgbGlrZSBhIHN0ZXAgaW4gdGhlDQo+IHdyb25nIGRp cmVjdGlvbi4NCj4gDQo+IEknbSBub3QgZW50aXJlbHkgc3VyZSB3aGVyZSBvZl9tYXBfcmlkKCkg Zml0cyBiZXN0LCBidXQgZnJvbSBhIHF1aWNrIGxvb2sgYXJvdW5kDQo+IHRoZSBsZWFzdC13b3Jz dCBvcHRpb24gbWlnaHQgYmUgZHJpdmVycy9vZi9vZl9hZGRyZXNzLmMsIHVubGVzcyBSb2IgYW5k IEZyYW5rDQo+IGhhdmUgYSBiZXR0ZXIgaWRlYSBvZiB3aGVyZSBnZW5lcmljIERULWJhc2VkIElE IHRyYW5zbGF0aW9uIHJvdXRpbmVzIGNvdWxkIGxpdmU/DQoNCmRyaXZlcnMvb2YvYWRkcmVzcy5j IG1heSBiZSBwcm9wZXIgcGxhY2UgdG8gbW92ZSB1bnRpbCBzb21lb25lIGhhdmUgYmV0dGVyIGlk ZWEuDQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+IA0KPiA+ICAgZHJpdmVycy9vZi9pcnEuYyAgICAg ICAgIHwgICA2ICstLQ0KPiA+ICAgZHJpdmVycy9wY2kvb2YuYyAgICAgICAgIHwgMTAxIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gICBpbmNsdWRlL2xp bnV4L29mX2lvbW11LmggfCAgMTEgKysrKysNCj4gPiAgIGluY2x1ZGUvbGludXgvb2ZfcGNpLmgg ICB8ICAxMCAtLS0tLQ0KPiA+ICAgNSBmaWxlcyBjaGFuZ2VkLCAxMTcgaW5zZXJ0aW9ucygrKSwg MTE3IGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaW9tbXUvb2Zf aW9tbXUuYyBiL2RyaXZlcnMvaW9tbXUvb2ZfaW9tbXUuYyBpbmRleA0KPiA+IDVjMzZhOGIuLjRl NzcxMmYgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9pb21tdS9vZl9pb21tdS5jDQo+ID4gKysr IGIvZHJpdmVycy9pb21tdS9vZl9pb21tdS5jDQo+ID4gQEAgLTEzOCw2ICsxMzgsMTA2IEBAIHN0 YXRpYyBpbnQgb2ZfaW9tbXVfeGxhdGUoc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ICAgCXJldHVy biBvcHMtPm9mX3hsYXRlKGRldiwgaW9tbXVfc3BlYyk7DQo+ID4gICB9DQo+ID4NCj4gPiArLyoq DQo+ID4gKyAqIG9mX21hcF9yaWQgLSBUcmFuc2xhdGUgYSByZXF1ZXN0ZXIgSUQgdGhyb3VnaCBh IGRvd25zdHJlYW0gbWFwcGluZy4NCj4gPiArICogQG5wOiByb290IGNvbXBsZXggZGV2aWNlIG5v ZGUuDQo+ID4gKyAqIEByaWQ6IGRldmljZSByZXF1ZXN0ZXIgSUQgdG8gbWFwLg0KPiA+ICsgKiBA bWFwX25hbWU6IHByb3BlcnR5IG5hbWUgb2YgdGhlIG1hcCB0byB1c2UuDQo+ID4gKyAqIEBtYXBf bWFza19uYW1lOiBvcHRpb25hbCBwcm9wZXJ0eSBuYW1lIG9mIHRoZSBtYXNrIHRvIHVzZS4NCj4g PiArICogQHRhcmdldDogb3B0aW9uYWwgcG9pbnRlciB0byBhIHRhcmdldCBkZXZpY2Ugbm9kZS4N Cj4gPiArICogQGlkX291dDogb3B0aW9uYWwgcG9pbnRlciB0byByZWNlaXZlIHRoZSB0cmFuc2xh dGVkIElELg0KPiA+ICsgKg0KPiA+ICsgKiBHaXZlbiBhIGRldmljZSByZXF1ZXN0ZXIgSUQsIGxv b2sgdXAgdGhlIGFwcHJvcHJpYXRlDQo+ID4gK2ltcGxlbWVudGF0aW9uLWRlZmluZWQNCj4gPiAr ICogcGxhdGZvcm0gSUQgYW5kL29yIHRoZSB0YXJnZXQgZGV2aWNlIHdoaWNoIHJlY2VpdmVzIHRy YW5zYWN0aW9ucw0KPiA+ICtvbiB0aGF0DQo+ID4gKyAqIElELCBhcyBwZXIgdGhlICJpb21tdS1t YXAiIGFuZCAibXNpLW1hcCIgYmluZGluZ3MuIEVpdGhlciBvZg0KPiA+ICtAdGFyZ2V0IG9yDQo+ ID4gKyAqIEBpZF9vdXQgbWF5IGJlIE5VTEwgaWYgb25seSB0aGUgb3RoZXIgaXMgcmVxdWlyZWQu IElmIEB0YXJnZXQNCj4gPiArcG9pbnRzIHRvDQo+ID4gKyAqIGEgbm9uLU5VTEwgZGV2aWNlIG5v ZGUgcG9pbnRlciwgb25seSBlbnRyaWVzIHRhcmdldGluZyB0aGF0IG5vZGUNCj4gPiArd2lsbCBi ZQ0KPiA+ICsgKiBtYXRjaGVkOyBpZiBpdCBwb2ludHMgdG8gYSBOVUxMIHZhbHVlLCBpdCB3aWxs IHJlY2VpdmUgdGhlIGRldmljZQ0KPiA+ICtub2RlIG9mDQo+ID4gKyAqIHRoZSBmaXJzdCBtYXRj aGluZyB0YXJnZXQgcGhhbmRsZSwgd2l0aCBhIHJlZmVyZW5jZSBoZWxkLg0KPiA+ICsgKg0KPiA+ ICsgKiBSZXR1cm46IDAgb24gc3VjY2VzcyBvciBhIHN0YW5kYXJkIGVycm9yIGNvZGUgb24gZmFp bHVyZS4NCj4gPiArICovDQo+ID4gK2ludCBvZl9tYXBfcmlkKHN0cnVjdCBkZXZpY2Vfbm9kZSAq bnAsIHUzMiByaWQsDQo+ID4gKwkJICAgY29uc3QgY2hhciAqbWFwX25hbWUsIGNvbnN0IGNoYXIg Km1hcF9tYXNrX25hbWUsDQo+ID4gKwkJICAgc3RydWN0IGRldmljZV9ub2RlICoqdGFyZ2V0LCB1 MzIgKmlkX291dCkgew0KPiA+ICsJdTMyIG1hcF9tYXNrLCBtYXNrZWRfcmlkOw0KPiA+ICsJaW50 IG1hcF9sZW47DQo+ID4gKwljb25zdCBfX2JlMzIgKm1hcCA9IE5VTEw7DQo+ID4gKw0KPiA+ICsJ aWYgKCFucCB8fCAhbWFwX25hbWUgfHwgKCF0YXJnZXQgJiYgIWlkX291dCkpDQo+ID4gKwkJcmV0 dXJuIC1FSU5WQUw7DQo+ID4gKw0KPiA+ICsJbWFwID0gb2ZfZ2V0X3Byb3BlcnR5KG5wLCBtYXBf bmFtZSwgJm1hcF9sZW4pOw0KPiA+ICsJaWYgKCFtYXApIHsNCj4gPiArCQlpZiAodGFyZ2V0KQ0K PiA+ICsJCQlyZXR1cm4gLUVOT0RFVjsNCj4gPiArCQkvKiBPdGhlcndpc2UsIG5vIG1hcCBpbXBs aWVzIG5vIHRyYW5zbGF0aW9uICovDQo+ID4gKwkJKmlkX291dCA9IHJpZDsNCj4gPiArCQlyZXR1 cm4gMDsNCj4gPiArCX0NCj4gPiArDQo+ID4gKwlpZiAoIW1hcF9sZW4gfHwgbWFwX2xlbiAlICg0 ICogc2l6ZW9mKCptYXApKSkgew0KPiA+ICsJCXByX2VycigiJXBPRjogRXJyb3I6IEJhZCAlcyBs ZW5ndGg6ICVkXG4iLCBucCwNCj4gPiArCQkJbWFwX25hbWUsIG1hcF9sZW4pOw0KPiA+ICsJCXJl dHVybiAtRUlOVkFMOw0KPiA+ICsJfQ0KPiA+ICsNCj4gPiArCS8qIFRoZSBkZWZhdWx0IGlzIHRv IHNlbGVjdCBhbGwgYml0cy4gKi8NCj4gPiArCW1hcF9tYXNrID0gMHhmZmZmZmZmZjsNCj4gPiAr DQo+ID4gKwkvKg0KPiA+ICsJICogQ2FuIGJlIG92ZXJyaWRkZW4gYnkgIntpb21tdSxtc2l9LW1h cC1tYXNrIiBwcm9wZXJ0eS4NCj4gPiArCSAqLw0KPiA+ICsJaWYgKG1hcF9tYXNrX25hbWUpDQo+ ID4gKwkJb2ZfcHJvcGVydHlfcmVhZF91MzIobnAsIG1hcF9tYXNrX25hbWUsICZtYXBfbWFzayk7 DQo+ID4gKw0KPiA+ICsJbWFza2VkX3JpZCA9IG1hcF9tYXNrICYgcmlkOw0KPiA+ICsJZm9yICgg OyBtYXBfbGVuID4gMDsgbWFwX2xlbiAtPSA0ICogc2l6ZW9mKCptYXApLCBtYXAgKz0gNCkgew0K PiA+ICsJCXN0cnVjdCBkZXZpY2Vfbm9kZSAqcGhhbmRsZV9ub2RlOw0KPiA+ICsJCXUzMiByaWRf YmFzZSA9IGJlMzJfdG9fY3B1cChtYXAgKyAwKTsNCj4gPiArCQl1MzIgcGhhbmRsZSA9IGJlMzJf dG9fY3B1cChtYXAgKyAxKTsNCj4gPiArCQl1MzIgb3V0X2Jhc2UgPSBiZTMyX3RvX2NwdXAobWFw ICsgMik7DQo+ID4gKwkJdTMyIHJpZF9sZW4gPSBiZTMyX3RvX2NwdXAobWFwICsgMyk7DQo+ID4g Kw0KPiA+ICsJCWlmIChyaWRfYmFzZSAmIH5tYXBfbWFzaykgew0KPiA+ICsJCQlwcl9lcnIoIiVw T0Y6IEludmFsaWQgJXMgdHJhbnNsYXRpb24gLSAlcy1tYXNrICgweCV4KQ0KPiBpZ25vcmVzIHJp ZC1iYXNlICgweCV4KVxuIiwNCj4gPiArCQkJCW5wLCBtYXBfbmFtZSwgbWFwX25hbWUsDQo+ID4g KwkJCQltYXBfbWFzaywgcmlkX2Jhc2UpOw0KPiA+ICsJCQlyZXR1cm4gLUVGQVVMVDsNCj4gPiAr CQl9DQo+ID4gKw0KPiA+ICsJCWlmIChtYXNrZWRfcmlkIDwgcmlkX2Jhc2UgfHwgbWFza2VkX3Jp ZCA+PSByaWRfYmFzZSArIHJpZF9sZW4pDQo+ID4gKwkJCWNvbnRpbnVlOw0KPiA+ICsNCj4gPiAr CQlwaGFuZGxlX25vZGUgPSBvZl9maW5kX25vZGVfYnlfcGhhbmRsZShwaGFuZGxlKTsNCj4gPiAr CQlpZiAoIXBoYW5kbGVfbm9kZSkNCj4gPiArCQkJcmV0dXJuIC1FTk9ERVY7DQo+ID4gKw0KPiA+ ICsJCWlmICh0YXJnZXQpIHsNCj4gPiArCQkJaWYgKCp0YXJnZXQpDQo+ID4gKwkJCQlvZl9ub2Rl X3B1dChwaGFuZGxlX25vZGUpOw0KPiA+ICsJCQllbHNlDQo+ID4gKwkJCQkqdGFyZ2V0ID0gcGhh bmRsZV9ub2RlOw0KPiA+ICsNCj4gPiArCQkJaWYgKCp0YXJnZXQgIT0gcGhhbmRsZV9ub2RlKQ0K PiA+ICsJCQkJY29udGludWU7DQo+ID4gKwkJfQ0KPiA+ICsNCj4gPiArCQlpZiAoaWRfb3V0KQ0K PiA+ICsJCQkqaWRfb3V0ID0gbWFza2VkX3JpZCAtIHJpZF9iYXNlICsgb3V0X2Jhc2U7DQo+ID4g Kw0KPiA+ICsJCXByX2RlYnVnKCIlcE9GOiAlcywgdXNpbmcgbWFzayAlMDh4LCByaWQtYmFzZTog JTA4eCwgb3V0LQ0KPiBiYXNlOiAlMDh4LCBsZW5ndGg6ICUwOHgsIHJpZDogJTA4eCAtPiAlMDh4 XG4iLA0KPiA+ICsJCQlucCwgbWFwX25hbWUsIG1hcF9tYXNrLCByaWRfYmFzZSwgb3V0X2Jhc2Us DQo+ID4gKwkJCXJpZF9sZW4sIHJpZCwgbWFza2VkX3JpZCAtIHJpZF9iYXNlICsgb3V0X2Jhc2Up Ow0KPiA+ICsJCXJldHVybiAwOw0KPiA+ICsJfQ0KPiA+ICsNCj4gPiArCXByX2VycigiJXBPRjog SW52YWxpZCAlcyB0cmFuc2xhdGlvbiAtIG5vIG1hdGNoIGZvciByaWQgMHgleCBvbg0KPiAlcE9G XG4iLA0KPiA+ICsJCW5wLCBtYXBfbmFtZSwgcmlkLCB0YXJnZXQgJiYgKnRhcmdldCA/ICp0YXJn ZXQgOiBOVUxMKTsNCj4gPiArCXJldHVybiAtRUZBVUxUOw0KPiA+ICt9DQo+ID4gKw0KPiA+ICAg c3RydWN0IG9mX3BjaV9pb21tdV9hbGlhc19pbmZvIHsNCj4gPiAgIAlzdHJ1Y3QgZGV2aWNlICpk ZXY7DQo+ID4gICAJc3RydWN0IGRldmljZV9ub2RlICpucDsNCj4gPiBAQCAtMTQ5LDkgKzI0OSw5 IEBAIHN0YXRpYyBpbnQgb2ZfcGNpX2lvbW11X2luaXQoc3RydWN0IHBjaV9kZXYgKnBkZXYsIHUx Ng0KPiBhbGlhcywgdm9pZCAqZGF0YSkNCj4gPiAgIAlzdHJ1Y3Qgb2ZfcGhhbmRsZV9hcmdzIGlv bW11X3NwZWMgPSB7IC5hcmdzX2NvdW50ID0gMSB9Ow0KPiA+ICAgCWludCBlcnI7DQo+ID4NCj4g PiAtCWVyciA9IG9mX3BjaV9tYXBfcmlkKGluZm8tPm5wLCBhbGlhcywgImlvbW11LW1hcCIsDQo+ ID4gLQkJCSAgICAgImlvbW11LW1hcC1tYXNrIiwgJmlvbW11X3NwZWMubnAsDQo+ID4gLQkJCSAg ICAgaW9tbXVfc3BlYy5hcmdzKTsNCj4gPiArCWVyciA9IG9mX21hcF9yaWQoaW5mby0+bnAsIGFs aWFzLCAiaW9tbXUtbWFwIiwNCj4gPiArCQkJICJpb21tdS1tYXAtbWFzayIsICZpb21tdV9zcGVj Lm5wLA0KPiA+ICsJCQkgaW9tbXVfc3BlYy5hcmdzKTsNCj4gDQo+IFN1cGVyLW5pdDogQXBwYXJl bnRseSBJIG1pc3NlZCByZXdyYXBwaW5nIHRoaXMgdG8gMiBsaW5lcyBpbiBkODdiZWI3NDkyODEs IGJ1dCBpZg0KPiBpdCdzIGJlaW5nIHRvdWNoZWQgYWdhaW4sIHRoYXQgd291bGQgYmUgbmljZSA7 KQ0KPiANCj4gUm9iaW4uDQo+IA0KPiA+ICAgCWlmIChlcnIpDQo+ID4gICAJCXJldHVybiBlcnIg PT0gLUVOT0RFViA/IE5PX0lPTU1VIDogZXJyOw0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZl cnMvb2YvaXJxLmMgYi9kcml2ZXJzL29mL2lycS5jIGluZGV4DQo+ID4gMDJhZDkzYS4uYjcyZWVl YyAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL29mL2lycS5jDQo+ID4gKysrIGIvZHJpdmVycy9v Zi9pcnEuYw0KPiA+IEBAIC0yMiw3ICsyMiw3IEBADQo+ID4gICAjaW5jbHVkZSA8bGludXgvbW9k dWxlLmg+DQo+ID4gICAjaW5jbHVkZSA8bGludXgvb2YuaD4NCj4gPiAgICNpbmNsdWRlIDxsaW51 eC9vZl9pcnEuaD4NCj4gPiAtI2luY2x1ZGUgPGxpbnV4L29mX3BjaS5oPg0KPiA+ICsjaW5jbHVk ZSA8bGludXgvb2ZfaW9tbXUuaD4NCj4gPiAgICNpbmNsdWRlIDxsaW51eC9zdHJpbmcuaD4NCj4g PiAgICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQo+ID4NCj4gPiBAQCAtNTg4LDggKzU4OCw4IEBA IHN0YXRpYyB1MzIgX19vZl9tc2lfbWFwX3JpZChzdHJ1Y3QgZGV2aWNlICpkZXYsDQo+IHN0cnVj dCBkZXZpY2Vfbm9kZSAqKm5wLA0KPiA+ICAgCSAqICJtc2ktbWFwIiBwcm9wZXJ0eS4NCj4gPiAg IAkgKi8NCj4gPiAgIAlmb3IgKHBhcmVudF9kZXYgPSBkZXY7IHBhcmVudF9kZXY7IHBhcmVudF9k ZXYgPSBwYXJlbnRfZGV2LT5wYXJlbnQpDQo+ID4gLQkJaWYgKCFvZl9wY2lfbWFwX3JpZChwYXJl bnRfZGV2LT5vZl9ub2RlLCByaWRfaW4sICJtc2ktbWFwIiwNCj4gPiAtCQkJCSAgICAibXNpLW1h cC1tYXNrIiwgbnAsICZyaWRfb3V0KSkNCj4gPiArCQlpZiAoIW9mX21hcF9yaWQocGFyZW50X2Rl di0+b2Zfbm9kZSwgcmlkX2luLCAibXNpLW1hcCIsDQo+ID4gKwkJCQkibXNpLW1hcC1tYXNrIiwg bnAsICZyaWRfb3V0KSkNCj4gPiAgIAkJCWJyZWFrOw0KPiA+ICAgCXJldHVybiByaWRfb3V0Ow0K PiA+ICAgfQ0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3BjaS9vZi5jIGIvZHJpdmVycy9wY2kv b2YuYyBpbmRleA0KPiA+IGEyODM1NWMuLmQyY2ViYmUgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVy cy9wY2kvb2YuYw0KPiA+ICsrKyBiL2RyaXZlcnMvcGNpL29mLmMNCj4gPiBAQCAtMzYyLDEwNyAr MzYyLDYgQEAgaW50IG9mX3BjaV9nZXRfaG9zdF9icmlkZ2VfcmVzb3VyY2VzKHN0cnVjdA0KPiBk ZXZpY2Vfbm9kZSAqZGV2LA0KPiA+ICAgRVhQT1JUX1NZTUJPTF9HUEwob2ZfcGNpX2dldF9ob3N0 X2JyaWRnZV9yZXNvdXJjZXMpOw0KPiA+ICAgI2VuZGlmIC8qIENPTkZJR19PRl9BRERSRVNTICov DQo+ID4NCj4gPiAtLyoqDQo+ID4gLSAqIG9mX3BjaV9tYXBfcmlkIC0gVHJhbnNsYXRlIGEgcmVx dWVzdGVyIElEIHRocm91Z2ggYSBkb3duc3RyZWFtIG1hcHBpbmcuDQo+ID4gLSAqIEBucDogcm9v dCBjb21wbGV4IGRldmljZSBub2RlLg0KPiA+IC0gKiBAcmlkOiBQQ0kgcmVxdWVzdGVyIElEIHRv IG1hcC4NCj4gPiAtICogQG1hcF9uYW1lOiBwcm9wZXJ0eSBuYW1lIG9mIHRoZSBtYXAgdG8gdXNl Lg0KPiA+IC0gKiBAbWFwX21hc2tfbmFtZTogb3B0aW9uYWwgcHJvcGVydHkgbmFtZSBvZiB0aGUg bWFzayB0byB1c2UuDQo+ID4gLSAqIEB0YXJnZXQ6IG9wdGlvbmFsIHBvaW50ZXIgdG8gYSB0YXJn ZXQgZGV2aWNlIG5vZGUuDQo+ID4gLSAqIEBpZF9vdXQ6IG9wdGlvbmFsIHBvaW50ZXIgdG8gcmVj ZWl2ZSB0aGUgdHJhbnNsYXRlZCBJRC4NCj4gPiAtICoNCj4gPiAtICogR2l2ZW4gYSBQQ0kgcmVx dWVzdGVyIElELCBsb29rIHVwIHRoZSBhcHByb3ByaWF0ZQ0KPiA+IGltcGxlbWVudGF0aW9uLWRl ZmluZWQNCj4gPiAtICogcGxhdGZvcm0gSUQgYW5kL29yIHRoZSB0YXJnZXQgZGV2aWNlIHdoaWNo IHJlY2VpdmVzIHRyYW5zYWN0aW9ucw0KPiA+IG9uIHRoYXQNCj4gPiAtICogSUQsIGFzIHBlciB0 aGUgImlvbW11LW1hcCIgYW5kICJtc2ktbWFwIiBiaW5kaW5ncy4gRWl0aGVyIG9mDQo+ID4gQHRh cmdldCBvcg0KPiA+IC0gKiBAaWRfb3V0IG1heSBiZSBOVUxMIGlmIG9ubHkgdGhlIG90aGVyIGlz IHJlcXVpcmVkLiBJZiBAdGFyZ2V0DQo+ID4gcG9pbnRzIHRvDQo+ID4gLSAqIGEgbm9uLU5VTEwg ZGV2aWNlIG5vZGUgcG9pbnRlciwgb25seSBlbnRyaWVzIHRhcmdldGluZyB0aGF0IG5vZGUNCj4g PiB3aWxsIGJlDQo+ID4gLSAqIG1hdGNoZWQ7IGlmIGl0IHBvaW50cyB0byBhIE5VTEwgdmFsdWUs IGl0IHdpbGwgcmVjZWl2ZSB0aGUgZGV2aWNlDQo+ID4gbm9kZSBvZg0KPiA+IC0gKiB0aGUgZmly c3QgbWF0Y2hpbmcgdGFyZ2V0IHBoYW5kbGUsIHdpdGggYSByZWZlcmVuY2UgaGVsZC4NCj4gPiAt ICoNCj4gPiAtICogUmV0dXJuOiAwIG9uIHN1Y2Nlc3Mgb3IgYSBzdGFuZGFyZCBlcnJvciBjb2Rl IG9uIGZhaWx1cmUuDQo+ID4gLSAqLw0KPiA+IC1pbnQgb2ZfcGNpX21hcF9yaWQoc3RydWN0IGRl dmljZV9ub2RlICpucCwgdTMyIHJpZCwNCj4gPiAtCQkgICBjb25zdCBjaGFyICptYXBfbmFtZSwg Y29uc3QgY2hhciAqbWFwX21hc2tfbmFtZSwNCj4gPiAtCQkgICBzdHJ1Y3QgZGV2aWNlX25vZGUg Kip0YXJnZXQsIHUzMiAqaWRfb3V0KQ0KPiA+IC17DQo+ID4gLQl1MzIgbWFwX21hc2ssIG1hc2tl ZF9yaWQ7DQo+ID4gLQlpbnQgbWFwX2xlbjsNCj4gPiAtCWNvbnN0IF9fYmUzMiAqbWFwID0gTlVM TDsNCj4gPiAtDQo+ID4gLQlpZiAoIW5wIHx8ICFtYXBfbmFtZSB8fCAoIXRhcmdldCAmJiAhaWRf b3V0KSkNCj4gPiAtCQlyZXR1cm4gLUVJTlZBTDsNCj4gPiAtDQo+ID4gLQltYXAgPSBvZl9nZXRf cHJvcGVydHkobnAsIG1hcF9uYW1lLCAmbWFwX2xlbik7DQo+ID4gLQlpZiAoIW1hcCkgew0KPiA+ IC0JCWlmICh0YXJnZXQpDQo+ID4gLQkJCXJldHVybiAtRU5PREVWOw0KPiA+IC0JCS8qIE90aGVy d2lzZSwgbm8gbWFwIGltcGxpZXMgbm8gdHJhbnNsYXRpb24gKi8NCj4gPiAtCQkqaWRfb3V0ID0g cmlkOw0KPiA+IC0JCXJldHVybiAwOw0KPiA+IC0JfQ0KPiA+IC0NCj4gPiAtCWlmICghbWFwX2xl biB8fCBtYXBfbGVuICUgKDQgKiBzaXplb2YoKm1hcCkpKSB7DQo+ID4gLQkJcHJfZXJyKCIlcE9G OiBFcnJvcjogQmFkICVzIGxlbmd0aDogJWRcbiIsIG5wLA0KPiA+IC0JCQltYXBfbmFtZSwgbWFw X2xlbik7DQo+ID4gLQkJcmV0dXJuIC1FSU5WQUw7DQo+ID4gLQl9DQo+ID4gLQ0KPiA+IC0JLyog VGhlIGRlZmF1bHQgaXMgdG8gc2VsZWN0IGFsbCBiaXRzLiAqLw0KPiA+IC0JbWFwX21hc2sgPSAw eGZmZmZmZmZmOw0KPiA+IC0NCj4gPiAtCS8qDQo+ID4gLQkgKiBDYW4gYmUgb3ZlcnJpZGRlbiBi eSAie2lvbW11LG1zaX0tbWFwLW1hc2siIHByb3BlcnR5Lg0KPiA+IC0JICogSWYgb2ZfcHJvcGVy dHlfcmVhZF91MzIoKSBmYWlscywgdGhlIGRlZmF1bHQgaXMgdXNlZC4NCj4gPiAtCSAqLw0KPiA+ IC0JaWYgKG1hcF9tYXNrX25hbWUpDQo+ID4gLQkJb2ZfcHJvcGVydHlfcmVhZF91MzIobnAsIG1h cF9tYXNrX25hbWUsICZtYXBfbWFzayk7DQo+ID4gLQ0KPiA+IC0JbWFza2VkX3JpZCA9IG1hcF9t YXNrICYgcmlkOw0KPiA+IC0JZm9yICggOyBtYXBfbGVuID4gMDsgbWFwX2xlbiAtPSA0ICogc2l6 ZW9mKCptYXApLCBtYXAgKz0gNCkgew0KPiA+IC0JCXN0cnVjdCBkZXZpY2Vfbm9kZSAqcGhhbmRs ZV9ub2RlOw0KPiA+IC0JCXUzMiByaWRfYmFzZSA9IGJlMzJfdG9fY3B1cChtYXAgKyAwKTsNCj4g PiAtCQl1MzIgcGhhbmRsZSA9IGJlMzJfdG9fY3B1cChtYXAgKyAxKTsNCj4gPiAtCQl1MzIgb3V0 X2Jhc2UgPSBiZTMyX3RvX2NwdXAobWFwICsgMik7DQo+ID4gLQkJdTMyIHJpZF9sZW4gPSBiZTMy X3RvX2NwdXAobWFwICsgMyk7DQo+ID4gLQ0KPiA+IC0JCWlmIChyaWRfYmFzZSAmIH5tYXBfbWFz aykgew0KPiA+IC0JCQlwcl9lcnIoIiVwT0Y6IEludmFsaWQgJXMgdHJhbnNsYXRpb24gLSAlcy1t YXNrICgweCV4KQ0KPiBpZ25vcmVzIHJpZC1iYXNlICgweCV4KVxuIiwNCj4gPiAtCQkJCW5wLCBt YXBfbmFtZSwgbWFwX25hbWUsDQo+ID4gLQkJCQltYXBfbWFzaywgcmlkX2Jhc2UpOw0KPiA+IC0J CQlyZXR1cm4gLUVGQVVMVDsNCj4gPiAtCQl9DQo+ID4gLQ0KPiA+IC0JCWlmIChtYXNrZWRfcmlk IDwgcmlkX2Jhc2UgfHwgbWFza2VkX3JpZCA+PSByaWRfYmFzZSArIHJpZF9sZW4pDQo+ID4gLQkJ CWNvbnRpbnVlOw0KPiA+IC0NCj4gPiAtCQlwaGFuZGxlX25vZGUgPSBvZl9maW5kX25vZGVfYnlf cGhhbmRsZShwaGFuZGxlKTsNCj4gPiAtCQlpZiAoIXBoYW5kbGVfbm9kZSkNCj4gPiAtCQkJcmV0 dXJuIC1FTk9ERVY7DQo+ID4gLQ0KPiA+IC0JCWlmICh0YXJnZXQpIHsNCj4gPiAtCQkJaWYgKCp0 YXJnZXQpDQo+ID4gLQkJCQlvZl9ub2RlX3B1dChwaGFuZGxlX25vZGUpOw0KPiA+IC0JCQllbHNl DQo+ID4gLQkJCQkqdGFyZ2V0ID0gcGhhbmRsZV9ub2RlOw0KPiA+IC0NCj4gPiAtCQkJaWYgKCp0 YXJnZXQgIT0gcGhhbmRsZV9ub2RlKQ0KPiA+IC0JCQkJY29udGludWU7DQo+ID4gLQkJfQ0KPiA+ IC0NCj4gPiAtCQlpZiAoaWRfb3V0KQ0KPiA+IC0JCQkqaWRfb3V0ID0gbWFza2VkX3JpZCAtIHJp ZF9iYXNlICsgb3V0X2Jhc2U7DQo+ID4gLQ0KPiA+IC0JCXByX2RlYnVnKCIlcE9GOiAlcywgdXNp bmcgbWFzayAlMDh4LCByaWQtYmFzZTogJTA4eCwgb3V0LQ0KPiBiYXNlOiAlMDh4LCBsZW5ndGg6 ICUwOHgsIHJpZDogJTA4eCAtPiAlMDh4XG4iLA0KPiA+IC0JCQlucCwgbWFwX25hbWUsIG1hcF9t YXNrLCByaWRfYmFzZSwgb3V0X2Jhc2UsDQo+ID4gLQkJCXJpZF9sZW4sIHJpZCwgbWFza2VkX3Jp ZCAtIHJpZF9iYXNlICsgb3V0X2Jhc2UpOw0KPiA+IC0JCXJldHVybiAwOw0KPiA+IC0JfQ0KPiA+ IC0NCj4gPiAtCXByX2VycigiJXBPRjogSW52YWxpZCAlcyB0cmFuc2xhdGlvbiAtIG5vIG1hdGNo IGZvciByaWQgMHgleCBvbg0KPiAlcE9GXG4iLA0KPiA+IC0JCW5wLCBtYXBfbmFtZSwgcmlkLCB0 YXJnZXQgJiYgKnRhcmdldCA/ICp0YXJnZXQgOiBOVUxMKTsNCj4gPiAtCXJldHVybiAtRUZBVUxU Ow0KPiA+IC19DQo+ID4gLQ0KPiA+ICAgI2lmIElTX0VOQUJMRUQoQ09ORklHX09GX0lSUSkNCj4g PiAgIC8qKg0KPiA+ICAgICogb2ZfaXJxX3BhcnNlX3BjaSAtIFJlc29sdmUgdGhlIGludGVycnVw dCBmb3IgYSBQQ0kgZGV2aWNlIGRpZmYNCj4gPiAtLWdpdCBhL2luY2x1ZGUvbGludXgvb2ZfaW9t bXUuaCBiL2luY2x1ZGUvbGludXgvb2ZfaW9tbXUuaCBpbmRleA0KPiA+IDRmYTY1NGUuLjQzMmI1 M2MgMTAwNjQ0DQo+ID4gLS0tIGEvaW5jbHVkZS9saW51eC9vZl9pb21tdS5oDQo+ID4gKysrIGIv aW5jbHVkZS9saW51eC9vZl9pb21tdS5oDQo+ID4gQEAgLTE1LDYgKzE1LDEwIEBAIGV4dGVybiBp bnQgb2ZfZ2V0X2RtYV93aW5kb3coc3RydWN0IGRldmljZV9ub2RlDQo+ICpkbiwgY29uc3QgY2hh ciAqcHJlZml4LA0KPiA+ICAgZXh0ZXJuIGNvbnN0IHN0cnVjdCBpb21tdV9vcHMgKm9mX2lvbW11 X2NvbmZpZ3VyZShzdHJ1Y3QgZGV2aWNlICpkZXYsDQo+ID4gICAJCQkJCXN0cnVjdCBkZXZpY2Vf bm9kZSAqbWFzdGVyX25wKTsNCj4gPg0KPiA+ICtpbnQgb2ZfbWFwX3JpZChzdHJ1Y3QgZGV2aWNl X25vZGUgKm5wLCB1MzIgcmlkLA0KPiA+ICsJICAgICAgIGNvbnN0IGNoYXIgKm1hcF9uYW1lLCBj b25zdCBjaGFyICptYXBfbWFza19uYW1lLA0KPiA+ICsJICAgICAgIHN0cnVjdCBkZXZpY2Vfbm9k ZSAqKnRhcmdldCwgdTMyICppZF9vdXQpOw0KPiA+ICsNCj4gPiAgICNlbHNlDQo+ID4NCj4gPiAg IHN0YXRpYyBpbmxpbmUgaW50IG9mX2dldF9kbWFfd2luZG93KHN0cnVjdCBkZXZpY2Vfbm9kZSAq ZG4sIGNvbnN0DQo+ID4gY2hhciAqcHJlZml4LCBAQCAtMzAsNiArMzQsMTMgQEAgc3RhdGljIGlu bGluZSBjb25zdCBzdHJ1Y3QgaW9tbXVfb3BzDQo+ICpvZl9pb21tdV9jb25maWd1cmUoc3RydWN0 IGRldmljZSAqZGV2LA0KPiA+ICAgCXJldHVybiBOVUxMOw0KPiA+ICAgfQ0KPiA+DQo+ID4gK3N0 YXRpYyBpbmxpbmUgaW50IG9mX21hcF9yaWQoc3RydWN0IGRldmljZV9ub2RlICpucCwgdTMyIHJp ZCwNCj4gPiArCQkJICAgICBjb25zdCBjaGFyICptYXBfbmFtZSwgY29uc3QgY2hhcg0KPiAqbWFw X21hc2tfbmFtZSwNCj4gPiArCQkJICAgICBzdHJ1Y3QgZGV2aWNlX25vZGUgKip0YXJnZXQsIHUz MiAqaWRfb3V0KSB7DQo+ID4gKwlyZXR1cm4gLUVJTlZBTDsNCj4gPiArfQ0KPiA+ICsNCj4gPiAg ICNlbmRpZgkvKiBDT05GSUdfT0ZfSU9NTVUgKi8NCj4gPg0KPiA+ICAgZXh0ZXJuIHN0cnVjdCBv Zl9kZXZpY2VfaWQgX19pb21tdV9vZl90YWJsZTsgZGlmZiAtLWdpdA0KPiA+IGEvaW5jbHVkZS9s aW51eC9vZl9wY2kuaCBiL2luY2x1ZGUvbGludXgvb2ZfcGNpLmggaW5kZXgNCj4gPiAwOTEwMzNh Li5hMjNiNDRhIDEwMDY0NA0KPiA+IC0tLSBhL2luY2x1ZGUvbGludXgvb2ZfcGNpLmgNCj4gPiAr KysgYi9pbmNsdWRlL2xpbnV4L29mX3BjaS5oDQo+ID4gQEAgLTE3LDkgKzE3LDYgQEAgc3RydWN0 IGRldmljZV9ub2RlICpvZl9wY2lfZmluZF9jaGlsZF9kZXZpY2Uoc3RydWN0DQo+IGRldmljZV9u b2RlICpwYXJlbnQsDQo+ID4gICBpbnQgb2ZfZ2V0X3BjaV9kb21haW5fbnIoc3RydWN0IGRldmlj ZV9ub2RlICpub2RlKTsNCj4gPiAgIGludCBvZl9wY2lfZ2V0X21heF9saW5rX3NwZWVkKHN0cnVj dCBkZXZpY2Vfbm9kZSAqbm9kZSk7DQo+ID4gICB2b2lkIG9mX3BjaV9jaGVja19wcm9iZV9vbmx5 KHZvaWQpOw0KPiA+IC1pbnQgb2ZfcGNpX21hcF9yaWQoc3RydWN0IGRldmljZV9ub2RlICpucCwg dTMyIHJpZCwNCj4gPiAtCQkgICBjb25zdCBjaGFyICptYXBfbmFtZSwgY29uc3QgY2hhciAqbWFw X21hc2tfbmFtZSwNCj4gPiAtCQkgICBzdHJ1Y3QgZGV2aWNlX25vZGUgKip0YXJnZXQsIHUzMiAq aWRfb3V0KTsNCj4gPiAgICNlbHNlDQo+ID4gICBzdGF0aWMgaW5saW5lIHN0cnVjdCBkZXZpY2Vf bm9kZSAqb2ZfcGNpX2ZpbmRfY2hpbGRfZGV2aWNlKHN0cnVjdCBkZXZpY2Vfbm9kZQ0KPiAqcGFy ZW50LA0KPiA+ICAgCQkJCQkgICAgIHVuc2lnbmVkIGludCBkZXZmbikNCj4gPiBAQCAtNDQsMTMg KzQxLDYgQEAgc3RhdGljIGlubGluZSBpbnQgb2ZfcGNpX2dldF9kZXZmbihzdHJ1Y3QgZGV2aWNl X25vZGUNCj4gKm5wKQ0KPiA+ICAgCXJldHVybiAtMTsNCj4gPiAgIH0NCj4gPg0KPiA+IC1zdGF0 aWMgaW5saW5lIGludCBvZl9wY2lfbWFwX3JpZChzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wLCB1MzIg cmlkLA0KPiA+IC0JCQljb25zdCBjaGFyICptYXBfbmFtZSwgY29uc3QgY2hhciAqbWFwX21hc2tf bmFtZSwNCj4gPiAtCQkJc3RydWN0IGRldmljZV9ub2RlICoqdGFyZ2V0LCB1MzIgKmlkX291dCkN Cj4gPiAtew0KPiA+IC0JcmV0dXJuIC1FSU5WQUw7DQo+ID4gLX0NCj4gPiAtDQo+ID4gICBzdGF0 aWMgaW5saW5lIGludA0KPiA+ICAgb2ZfcGNpX2dldF9tYXhfbGlua19zcGVlZChzdHJ1Y3QgZGV2 aWNlX25vZGUgKm5vZGUpDQo+ID4gICB7DQo+ID4NCg== ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 5:09 ` Bharat Bhushan 0 siblings, 0 replies; 106+ messages in thread From: Bharat Bhushan @ 2018-04-18 5:09 UTC (permalink / raw) To: Robin Murphy, Nipun Gupta, robh+dt, frowand.list Cc: mark.rutland, devicetree, stuyoder, linux-pci, catalin.marinas, joro, linuxppc-dev, will.deacon, linux-kernel, Leo Li, iommu, gregkh, bhelgaas, Laurentiu Tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org; > frowand.list@gmail.com > Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com; > hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org; > m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com; > iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc- > dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. Nipun, please clarify that only function name is changed and rest of body is same. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? Yes, this will be a problem with MSI > I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? drivers/of/address.c may be proper place to move until someone have better idea. Thanks -Bharat > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index > > 5c36a8b..4e7712f 100644 > > --- a/drivers/iommu/of_iommu.c > > +++ b/drivers/iommu/of_iommu.c > > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, > > return ops->of_xlate(dev, iommu_spec); > > } > > > > +/** > > + * of_map_rid - Translate a requester ID through a downstream mapping. > > + * @np: root complex device node. > > + * @rid: device requester ID to map. > > + * @map_name: property name of the map to use. > > + * @map_mask_name: optional property name of the mask to use. > > + * @target: optional pointer to a target device node. > > + * @id_out: optional pointer to receive the translated ID. > > + * > > + * Given a device requester ID, look up the appropriate > > +implementation-defined > > + * platform ID and/or the target device which receives transactions > > +on that > > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > +@target or > > + * @id_out may be NULL if only the other is required. If @target > > +points to > > + * a non-NULL device node pointer, only entries targeting that node > > +will be > > + * matched; if it points to a NULL value, it will receive the device > > +node of > > + * the first matching target phandle, with a reference held. > > + * > > + * Return: 0 on success or a standard error code on failure. > > + */ > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + u32 map_mask, masked_rid; > > + int map_len; > > + const __be32 *map = NULL; > > + > > + if (!np || !map_name || (!target && !id_out)) > > + return -EINVAL; > > + > > + map = of_get_property(np, map_name, &map_len); > > + if (!map) { > > + if (target) > > + return -ENODEV; > > + /* Otherwise, no map implies no translation */ > > + *id_out = rid; > > + return 0; > > + } > > + > > + if (!map_len || map_len % (4 * sizeof(*map))) { > > + pr_err("%pOF: Error: Bad %s length: %d\n", np, > > + map_name, map_len); > > + return -EINVAL; > > + } > > + > > + /* The default is to select all bits. */ > > + map_mask = 0xffffffff; > > + > > + /* > > + * Can be overridden by "{iommu,msi}-map-mask" property. > > + */ > > + if (map_mask_name) > > + of_property_read_u32(np, map_mask_name, &map_mask); > > + > > + masked_rid = map_mask & rid; > > + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > + struct device_node *phandle_node; > > + u32 rid_base = be32_to_cpup(map + 0); > > + u32 phandle = be32_to_cpup(map + 1); > > + u32 out_base = be32_to_cpup(map + 2); > > + u32 rid_len = be32_to_cpup(map + 3); > > + > > + if (rid_base & ~map_mask) { > > + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > + np, map_name, map_name, > > + map_mask, rid_base); > > + return -EFAULT; > > + } > > + > > + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > + continue; > > + > > + phandle_node = of_find_node_by_phandle(phandle); > > + if (!phandle_node) > > + return -ENODEV; > > + > > + if (target) { > > + if (*target) > > + of_node_put(phandle_node); > > + else > > + *target = phandle_node; > > + > > + if (*target != phandle_node) > > + continue; > > + } > > + > > + if (id_out) > > + *id_out = masked_rid - rid_base + out_base; > > + > > + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > + np, map_name, map_mask, rid_base, out_base, > > + rid_len, rid, masked_rid - rid_base + out_base); > > + return 0; > > + } > > + > > + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > + np, map_name, rid, target && *target ? *target : NULL); > > + return -EFAULT; > > +} > > + > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) > > Robin. > > > if (err) > > return err == -ENODEV ? NO_IOMMU : err; > > > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index > > 02ad93a..b72eeec 100644 > > --- a/drivers/of/irq.c > > +++ b/drivers/of/irq.c > > @@ -22,7 +22,7 @@ > > #include <linux/module.h> > > #include <linux/of.h> > > #include <linux/of_irq.h> > > -#include <linux/of_pci.h> > > +#include <linux/of_iommu.h> > > #include <linux/string.h> > > #include <linux/slab.h> > > > > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, > struct device_node **np, > > * "msi-map" property. > > */ > > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) > > - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", > > - "msi-map-mask", np, &rid_out)) > > + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", > > + "msi-map-mask", np, &rid_out)) > > break; > > return rid_out; > > } > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index > > a28355c..d2cebbe 100644 > > --- a/drivers/pci/of.c > > +++ b/drivers/pci/of.c > > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct > device_node *dev, > > EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); > > #endif /* CONFIG_OF_ADDRESS */ > > > > -/** > > - * of_pci_map_rid - Translate a requester ID through a downstream mapping. > > - * @np: root complex device node. > > - * @rid: PCI requester ID to map. > > - * @map_name: property name of the map to use. > > - * @map_mask_name: optional property name of the mask to use. > > - * @target: optional pointer to a target device node. > > - * @id_out: optional pointer to receive the translated ID. > > - * > > - * Given a PCI requester ID, look up the appropriate > > implementation-defined > > - * platform ID and/or the target device which receives transactions > > on that > > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > @target or > > - * @id_out may be NULL if only the other is required. If @target > > points to > > - * a non-NULL device node pointer, only entries targeting that node > > will be > > - * matched; if it points to a NULL value, it will receive the device > > node of > > - * the first matching target phandle, with a reference held. > > - * > > - * Return: 0 on success or a standard error code on failure. > > - */ > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - u32 map_mask, masked_rid; > > - int map_len; > > - const __be32 *map = NULL; > > - > > - if (!np || !map_name || (!target && !id_out)) > > - return -EINVAL; > > - > > - map = of_get_property(np, map_name, &map_len); > > - if (!map) { > > - if (target) > > - return -ENODEV; > > - /* Otherwise, no map implies no translation */ > > - *id_out = rid; > > - return 0; > > - } > > - > > - if (!map_len || map_len % (4 * sizeof(*map))) { > > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > > - map_name, map_len); > > - return -EINVAL; > > - } > > - > > - /* The default is to select all bits. */ > > - map_mask = 0xffffffff; > > - > > - /* > > - * Can be overridden by "{iommu,msi}-map-mask" property. > > - * If of_property_read_u32() fails, the default is used. > > - */ > > - if (map_mask_name) > > - of_property_read_u32(np, map_mask_name, &map_mask); > > - > > - masked_rid = map_mask & rid; > > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > - struct device_node *phandle_node; > > - u32 rid_base = be32_to_cpup(map + 0); > > - u32 phandle = be32_to_cpup(map + 1); > > - u32 out_base = be32_to_cpup(map + 2); > > - u32 rid_len = be32_to_cpup(map + 3); > > - > > - if (rid_base & ~map_mask) { > > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > - np, map_name, map_name, > > - map_mask, rid_base); > > - return -EFAULT; > > - } > > - > > - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > - continue; > > - > > - phandle_node = of_find_node_by_phandle(phandle); > > - if (!phandle_node) > > - return -ENODEV; > > - > > - if (target) { > > - if (*target) > > - of_node_put(phandle_node); > > - else > > - *target = phandle_node; > > - > > - if (*target != phandle_node) > > - continue; > > - } > > - > > - if (id_out) > > - *id_out = masked_rid - rid_base + out_base; > > - > > - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > - np, map_name, map_mask, rid_base, out_base, > > - rid_len, rid, masked_rid - rid_base + out_base); > > - return 0; > > - } > > - > > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > - np, map_name, rid, target && *target ? *target : NULL); > > - return -EFAULT; > > -} > > - > > #if IS_ENABLED(CONFIG_OF_IRQ) > > /** > > * of_irq_parse_pci - Resolve the interrupt for a PCI device diff > > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index > > 4fa654e..432b53c 100644 > > --- a/include/linux/of_iommu.h > > +++ b/include/linux/of_iommu.h > > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node > *dn, const char *prefix, > > extern const struct iommu_ops *of_iommu_configure(struct device *dev, > > struct device_node *master_np); > > > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out); > > + > > #else > > > > static inline int of_get_dma_window(struct device_node *dn, const > > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops > *of_iommu_configure(struct device *dev, > > return NULL; > > } > > > > +static inline int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char > *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + return -EINVAL; > > +} > > + > > #endif /* CONFIG_OF_IOMMU */ > > > > extern struct of_device_id __iommu_of_table; diff --git > > a/include/linux/of_pci.h b/include/linux/of_pci.h index > > 091033a..a23b44a 100644 > > --- a/include/linux/of_pci.h > > +++ b/include/linux/of_pci.h > > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct > device_node *parent, > > int of_get_pci_domain_nr(struct device_node *node); > > int of_pci_get_max_link_speed(struct device_node *node); > > void of_pci_check_probe_only(void); > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out); > > #else > > static inline struct device_node *of_pci_find_child_device(struct device_node > *parent, > > unsigned int devfn) > > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node > *np) > > return -1; > > } > > > > -static inline int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - return -EINVAL; > > -} > > - > > static inline int > > of_pci_get_max_link_speed(struct device_node *node) > > { > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 5:09 ` Bharat Bhushan 0 siblings, 0 replies; 106+ messages in thread From: Bharat Bhushan @ 2018-04-18 5:09 UTC (permalink / raw) To: Robin Murphy, Nipun Gupta, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, linux-pci-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy-5wv7dgnIgG8@public.gmane.org] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; > frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > Cc: will.deacon-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org; > hch-jcswGhMUV9g@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; > m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; > iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linuxppc- > dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Bharat Bhushan > <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Laurentiu Tudor > <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org>; Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. Nipun, please clarify that only function name is changed and rest of body is same. > > > > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? Yes, this will be a problem with MSI > I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? drivers/of/address.c may be proper place to move until someone have better idea. Thanks -Bharat > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index > > 5c36a8b..4e7712f 100644 > > --- a/drivers/iommu/of_iommu.c > > +++ b/drivers/iommu/of_iommu.c > > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev, > > return ops->of_xlate(dev, iommu_spec); > > } > > > > +/** > > + * of_map_rid - Translate a requester ID through a downstream mapping. > > + * @np: root complex device node. > > + * @rid: device requester ID to map. > > + * @map_name: property name of the map to use. > > + * @map_mask_name: optional property name of the mask to use. > > + * @target: optional pointer to a target device node. > > + * @id_out: optional pointer to receive the translated ID. > > + * > > + * Given a device requester ID, look up the appropriate > > +implementation-defined > > + * platform ID and/or the target device which receives transactions > > +on that > > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > +@target or > > + * @id_out may be NULL if only the other is required. If @target > > +points to > > + * a non-NULL device node pointer, only entries targeting that node > > +will be > > + * matched; if it points to a NULL value, it will receive the device > > +node of > > + * the first matching target phandle, with a reference held. > > + * > > + * Return: 0 on success or a standard error code on failure. > > + */ > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + u32 map_mask, masked_rid; > > + int map_len; > > + const __be32 *map = NULL; > > + > > + if (!np || !map_name || (!target && !id_out)) > > + return -EINVAL; > > + > > + map = of_get_property(np, map_name, &map_len); > > + if (!map) { > > + if (target) > > + return -ENODEV; > > + /* Otherwise, no map implies no translation */ > > + *id_out = rid; > > + return 0; > > + } > > + > > + if (!map_len || map_len % (4 * sizeof(*map))) { > > + pr_err("%pOF: Error: Bad %s length: %d\n", np, > > + map_name, map_len); > > + return -EINVAL; > > + } > > + > > + /* The default is to select all bits. */ > > + map_mask = 0xffffffff; > > + > > + /* > > + * Can be overridden by "{iommu,msi}-map-mask" property. > > + */ > > + if (map_mask_name) > > + of_property_read_u32(np, map_mask_name, &map_mask); > > + > > + masked_rid = map_mask & rid; > > + for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > + struct device_node *phandle_node; > > + u32 rid_base = be32_to_cpup(map + 0); > > + u32 phandle = be32_to_cpup(map + 1); > > + u32 out_base = be32_to_cpup(map + 2); > > + u32 rid_len = be32_to_cpup(map + 3); > > + > > + if (rid_base & ~map_mask) { > > + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > + np, map_name, map_name, > > + map_mask, rid_base); > > + return -EFAULT; > > + } > > + > > + if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > + continue; > > + > > + phandle_node = of_find_node_by_phandle(phandle); > > + if (!phandle_node) > > + return -ENODEV; > > + > > + if (target) { > > + if (*target) > > + of_node_put(phandle_node); > > + else > > + *target = phandle_node; > > + > > + if (*target != phandle_node) > > + continue; > > + } > > + > > + if (id_out) > > + *id_out = masked_rid - rid_base + out_base; > > + > > + pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > + np, map_name, map_mask, rid_base, out_base, > > + rid_len, rid, masked_rid - rid_base + out_base); > > + return 0; > > + } > > + > > + pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > + np, map_name, rid, target && *target ? *target : NULL); > > + return -EFAULT; > > +} > > + > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) > > Robin. > > > if (err) > > return err == -ENODEV ? NO_IOMMU : err; > > > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index > > 02ad93a..b72eeec 100644 > > --- a/drivers/of/irq.c > > +++ b/drivers/of/irq.c > > @@ -22,7 +22,7 @@ > > #include <linux/module.h> > > #include <linux/of.h> > > #include <linux/of_irq.h> > > -#include <linux/of_pci.h> > > +#include <linux/of_iommu.h> > > #include <linux/string.h> > > #include <linux/slab.h> > > > > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, > struct device_node **np, > > * "msi-map" property. > > */ > > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) > > - if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map", > > - "msi-map-mask", np, &rid_out)) > > + if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map", > > + "msi-map-mask", np, &rid_out)) > > break; > > return rid_out; > > } > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index > > a28355c..d2cebbe 100644 > > --- a/drivers/pci/of.c > > +++ b/drivers/pci/of.c > > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct > device_node *dev, > > EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); > > #endif /* CONFIG_OF_ADDRESS */ > > > > -/** > > - * of_pci_map_rid - Translate a requester ID through a downstream mapping. > > - * @np: root complex device node. > > - * @rid: PCI requester ID to map. > > - * @map_name: property name of the map to use. > > - * @map_mask_name: optional property name of the mask to use. > > - * @target: optional pointer to a target device node. > > - * @id_out: optional pointer to receive the translated ID. > > - * > > - * Given a PCI requester ID, look up the appropriate > > implementation-defined > > - * platform ID and/or the target device which receives transactions > > on that > > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of > > @target or > > - * @id_out may be NULL if only the other is required. If @target > > points to > > - * a non-NULL device node pointer, only entries targeting that node > > will be > > - * matched; if it points to a NULL value, it will receive the device > > node of > > - * the first matching target phandle, with a reference held. > > - * > > - * Return: 0 on success or a standard error code on failure. > > - */ > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - u32 map_mask, masked_rid; > > - int map_len; > > - const __be32 *map = NULL; > > - > > - if (!np || !map_name || (!target && !id_out)) > > - return -EINVAL; > > - > > - map = of_get_property(np, map_name, &map_len); > > - if (!map) { > > - if (target) > > - return -ENODEV; > > - /* Otherwise, no map implies no translation */ > > - *id_out = rid; > > - return 0; > > - } > > - > > - if (!map_len || map_len % (4 * sizeof(*map))) { > > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > > - map_name, map_len); > > - return -EINVAL; > > - } > > - > > - /* The default is to select all bits. */ > > - map_mask = 0xffffffff; > > - > > - /* > > - * Can be overridden by "{iommu,msi}-map-mask" property. > > - * If of_property_read_u32() fails, the default is used. > > - */ > > - if (map_mask_name) > > - of_property_read_u32(np, map_mask_name, &map_mask); > > - > > - masked_rid = map_mask & rid; > > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > > - struct device_node *phandle_node; > > - u32 rid_base = be32_to_cpup(map + 0); > > - u32 phandle = be32_to_cpup(map + 1); > > - u32 out_base = be32_to_cpup(map + 2); > > - u32 rid_len = be32_to_cpup(map + 3); > > - > > - if (rid_base & ~map_mask) { > > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) > ignores rid-base (0x%x)\n", > > - np, map_name, map_name, > > - map_mask, rid_base); > > - return -EFAULT; > > - } > > - > > - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len) > > - continue; > > - > > - phandle_node = of_find_node_by_phandle(phandle); > > - if (!phandle_node) > > - return -ENODEV; > > - > > - if (target) { > > - if (*target) > > - of_node_put(phandle_node); > > - else > > - *target = phandle_node; > > - > > - if (*target != phandle_node) > > - continue; > > - } > > - > > - if (id_out) > > - *id_out = masked_rid - rid_base + out_base; > > - > > - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out- > base: %08x, length: %08x, rid: %08x -> %08x\n", > > - np, map_name, map_mask, rid_base, out_base, > > - rid_len, rid, masked_rid - rid_base + out_base); > > - return 0; > > - } > > - > > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on > %pOF\n", > > - np, map_name, rid, target && *target ? *target : NULL); > > - return -EFAULT; > > -} > > - > > #if IS_ENABLED(CONFIG_OF_IRQ) > > /** > > * of_irq_parse_pci - Resolve the interrupt for a PCI device diff > > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index > > 4fa654e..432b53c 100644 > > --- a/include/linux/of_iommu.h > > +++ b/include/linux/of_iommu.h > > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node > *dn, const char *prefix, > > extern const struct iommu_ops *of_iommu_configure(struct device *dev, > > struct device_node *master_np); > > > > +int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char *map_mask_name, > > + struct device_node **target, u32 *id_out); > > + > > #else > > > > static inline int of_get_dma_window(struct device_node *dn, const > > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops > *of_iommu_configure(struct device *dev, > > return NULL; > > } > > > > +static inline int of_map_rid(struct device_node *np, u32 rid, > > + const char *map_name, const char > *map_mask_name, > > + struct device_node **target, u32 *id_out) { > > + return -EINVAL; > > +} > > + > > #endif /* CONFIG_OF_IOMMU */ > > > > extern struct of_device_id __iommu_of_table; diff --git > > a/include/linux/of_pci.h b/include/linux/of_pci.h index > > 091033a..a23b44a 100644 > > --- a/include/linux/of_pci.h > > +++ b/include/linux/of_pci.h > > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct > device_node *parent, > > int of_get_pci_domain_nr(struct device_node *node); > > int of_pci_get_max_link_speed(struct device_node *node); > > void of_pci_check_probe_only(void); > > -int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out); > > #else > > static inline struct device_node *of_pci_find_child_device(struct device_node > *parent, > > unsigned int devfn) > > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node > *np) > > return -1; > > } > > > > -static inline int of_pci_map_rid(struct device_node *np, u32 rid, > > - const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > -{ > > - return -EINVAL; > > -} > > - > > static inline int > > of_pci_get_max_link_speed(struct device_node *node) > > { > > ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 6:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-18 6:21 UTC (permalink / raw) To: Robin Murphy, robh+dt, frowand.list Cc: will.deacon, mark.rutland, catalin.marinas, hch, gregkh, joro, m.szyprowski, shawnguo, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, Bharat Bhushan, stuyoder, Laurentiu Tudor, Leo Li > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org; > frowand.list@gmail.com > Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com; > hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org; > m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com; > iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc- > dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. Thanks for pointing out. Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > [...] > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) Sure.. I'll take care of this in the next version :) Regards, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 6:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-18 6:21 UTC (permalink / raw) To: linux-arm-kernel > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy at arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt at kernel.org; > frowand.list at gmail.com > Cc: will.deacon at arm.com; mark.rutland at arm.com; catalin.marinas at arm.com; > hch at lst.de; gregkh at linuxfoundation.org; joro at 8bytes.org; > m.szyprowski at samsung.com; shawnguo at kernel.org; bhelgaas at google.com; > iommu at lists.linux-foundation.org; linux-kernel at vger.kernel.org; > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linuxppc- > dev at lists.ozlabs.org; linux-pci at vger.kernel.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. Thanks for pointing out. Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > [...] > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) Sure.. I'll take care of this in the next version :) Regards, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 6:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-18 6:21 UTC (permalink / raw) To: Robin Murphy, robh+dt, frowand.list Cc: will.deacon, mark.rutland, catalin.marinas, hch, gregkh, joro, m.szyprowski, shawnguo, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, Bharat Bhushan, stuyoder, Laurentiu Tudor, Leo Li DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAy MDE4IDEwOjIzIFBNDQo+IFRvOiBOaXB1biBHdXB0YSA8bmlwdW4uZ3VwdGFAbnhwLmNvbT47IHJv YmgrZHRAa2VybmVsLm9yZzsNCj4gZnJvd2FuZC5saXN0QGdtYWlsLmNvbQ0KPiBDYzogd2lsbC5k ZWFjb25AYXJtLmNvbTsgbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bhcm0u Y29tOw0KPiBoY2hAbHN0LmRlOyBncmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsgam9yb0A4Ynl0 ZXMub3JnOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IHNoYXduZ3VvQGtlcm5lbC5vcmc7 IGJoZWxnYWFzQGdvb2dsZS5jb207DQo+IGlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3Jn OyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVs Lm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy0NCj4g ZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmc7IEJoYXJhdCBC aHVzaGFuDQo+IDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPjsgc3R1eW9kZXJAZ21haWwuY29tOyBM YXVyZW50aXUgVHVkb3INCj4gPGxhdXJlbnRpdS50dWRvckBueHAuY29tPjsgTGVvIExpIDxsZW95 YW5nLmxpQG54cC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi82IHYyXSBpb21tdTogb2Y6 IG1ha2Ugb2ZfcGNpX21hcF9yaWQoKSBhdmFpbGFibGUgZm9yDQo+IG90aGVyIGRldmljZXMgdG9v DQo+IA0KPiBPbiAxNy8wNC8xOCAxMToyMSwgTmlwdW4gR3VwdGEgd3JvdGU6DQo+ID4gaW9tbXUt bWFwIHByb3BlcnR5IGlzIGFsc28gdXNlZCBieSBkZXZpY2VzIHdpdGggZnNsLW1jLiBUaGlzIHBh dGNoDQo+ID4gbW92ZXMgdGhlIG9mX3BjaV9tYXBfcmlkIHRvIGdlbmVyaWMgbG9jYXRpb24sIHNv IHRoYXQgaXQgY2FuIGJlIHVzZWQNCj4gPiBieSBvdGhlciBidXNzZXMgdG9vLg0KPiA+DQo+ID4g U2lnbmVkLW9mZi1ieTogTmlwdW4gR3VwdGEgPG5pcHVuLmd1cHRhQG54cC5jb20+DQo+ID4gLS0t DQo+ID4gICBkcml2ZXJzL2lvbW11L29mX2lvbW11LmMgfCAxMDYNCj4gPiArKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQ0KPiANCj4gRG9lc24ndCB0aGlzIGJy ZWFrICJtc2ktcGFyZW50IiBwYXJzaW5nIGZvciAhQ09ORklHX09GX0lPTU1VPyBJIGd1ZXNzIHlv dQ0KPiBkb24ndCB3YW50IGZzbC1tYyB0byBoYXZlIHRvIGRlcGVuZCBvbiBQQ0ksIGJ1dCB0aGlz IGxvb2tzIGxpa2UgYSBzdGVwIGluIHRoZQ0KPiB3cm9uZyBkaXJlY3Rpb24uDQoNClRoYW5rcyBm b3IgcG9pbnRpbmcgb3V0Lg0KQWdyZWUsIHRoaXMgd2lsbCBicmVhayAibXNpLXBhcmVudCIgcGFy c2luZyBmb3IgIUNPTkZJR19PRl9JT01NVSBjYXNlLg0KDQo+IA0KPiBJJ20gbm90IGVudGlyZWx5 IHN1cmUgd2hlcmUgb2ZfbWFwX3JpZCgpIGZpdHMgYmVzdCwgYnV0IGZyb20gYSBxdWljayBsb29r IGFyb3VuZA0KPiB0aGUgbGVhc3Qtd29yc3Qgb3B0aW9uIG1pZ2h0IGJlIGRyaXZlcnMvb2Yvb2Zf YWRkcmVzcy5jLCB1bmxlc3MgUm9iIGFuZCBGcmFuaw0KPiBoYXZlIGEgYmV0dGVyIGlkZWEgb2Yg d2hlcmUgZ2VuZXJpYyBEVC1iYXNlZCBJRCB0cmFuc2xhdGlvbiByb3V0aW5lcyBjb3VsZCBsaXZl Pw0KPiANCj4gPiAgIGRyaXZlcnMvb2YvaXJxLmMgICAgICAgICB8ICAgNiArLS0NCj4gPiAgIGRy aXZlcnMvcGNpL29mLmMgICAgICAgICB8IDEwMSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICAgaW5jbHVkZS9saW51eC9vZl9pb21tdS5oIHwgIDExICsr KysrDQo+ID4gICBpbmNsdWRlL2xpbnV4L29mX3BjaS5oICAgfCAgMTAgLS0tLS0NCj4gPiAgIDUg ZmlsZXMgY2hhbmdlZCwgMTE3IGluc2VydGlvbnMoKyksIDExNyBkZWxldGlvbnMoLSkNCj4gPg0K DQpbLi4uXQ0KDQo+ID4gICBzdHJ1Y3Qgb2ZfcGNpX2lvbW11X2FsaWFzX2luZm8gew0KPiA+ICAg CXN0cnVjdCBkZXZpY2UgKmRldjsNCj4gPiAgIAlzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wOw0KPiA+ IEBAIC0xNDksOSArMjQ5LDkgQEAgc3RhdGljIGludCBvZl9wY2lfaW9tbXVfaW5pdChzdHJ1Y3Qg cGNpX2RldiAqcGRldiwgdTE2DQo+IGFsaWFzLCB2b2lkICpkYXRhKQ0KPiA+ICAgCXN0cnVjdCBv Zl9waGFuZGxlX2FyZ3MgaW9tbXVfc3BlYyA9IHsgLmFyZ3NfY291bnQgPSAxIH07DQo+ID4gICAJ aW50IGVycjsNCj4gPg0KPiA+IC0JZXJyID0gb2ZfcGNpX21hcF9yaWQoaW5mby0+bnAsIGFsaWFz LCAiaW9tbXUtbWFwIiwNCj4gPiAtCQkJICAgICAiaW9tbXUtbWFwLW1hc2siLCAmaW9tbXVfc3Bl Yy5ucCwNCj4gPiAtCQkJICAgICBpb21tdV9zcGVjLmFyZ3MpOw0KPiA+ICsJZXJyID0gb2ZfbWFw X3JpZChpbmZvLT5ucCwgYWxpYXMsICJpb21tdS1tYXAiLA0KPiA+ICsJCQkgImlvbW11LW1hcC1t YXNrIiwgJmlvbW11X3NwZWMubnAsDQo+ID4gKwkJCSBpb21tdV9zcGVjLmFyZ3MpOw0KPiANCj4g U3VwZXItbml0OiBBcHBhcmVudGx5IEkgbWlzc2VkIHJld3JhcHBpbmcgdGhpcyB0byAyIGxpbmVz IGluIGQ4N2JlYjc0OTI4MSwgYnV0IGlmDQo+IGl0J3MgYmVpbmcgdG91Y2hlZCBhZ2FpbiwgdGhh dCB3b3VsZCBiZSBuaWNlIDspDQoNClN1cmUuLiBJJ2xsIHRha2UgY2FyZSBvZiB0aGlzIGluIHRo ZSBuZXh0IHZlcnNpb24gOikNCg0KUmVnYXJkcywNCk5pcHVuDQo= ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 6:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-18 6:21 UTC (permalink / raw) To: Robin Murphy, robh+dt, frowand.list Cc: mark.rutland, devicetree, stuyoder, Bharat Bhushan, linux-pci, catalin.marinas, joro, linuxppc-dev, will.deacon, linux-kernel, Leo Li, iommu, gregkh, bhelgaas, Laurentiu Tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org; > frowand.list@gmail.com > Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com; > hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org; > m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com; > iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc- > dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan > <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor > <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. > > > > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. Thanks for pointing out. Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > [...] > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) Sure.. I'll take care of this in the next version :) Regards, Nipun _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too @ 2018-04-18 6:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-18 6:21 UTC (permalink / raw) To: Robin Murphy, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, linux-pci-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy-5wv7dgnIgG8@public.gmane.org] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; > frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > Cc: will.deacon-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org; > hch-jcswGhMUV9g@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; > m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; > iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linuxppc- > dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Bharat Bhushan > <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Laurentiu Tudor > <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org>; Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org> > Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for > other devices too > > On 17/04/18 11:21, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This patch > > moves the of_pci_map_rid to generic location, so that it can be used > > by other busses too. > > > > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> > > --- > > drivers/iommu/of_iommu.c | 106 > > +++++++++++++++++++++++++++++++++++++++++++++-- > > Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you > don't want fsl-mc to have to depend on PCI, but this looks like a step in the > wrong direction. Thanks for pointing out. Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case. > > I'm not entirely sure where of_map_rid() fits best, but from a quick look around > the least-worst option might be drivers/of/of_address.c, unless Rob and Frank > have a better idea of where generic DT-based ID translation routines could live? > > > drivers/of/irq.c | 6 +-- > > drivers/pci/of.c | 101 -------------------------------------------- > > include/linux/of_iommu.h | 11 +++++ > > include/linux/of_pci.h | 10 ----- > > 5 files changed, 117 insertions(+), 117 deletions(-) > > [...] > > struct of_pci_iommu_alias_info { > > struct device *dev; > > struct device_node *np; > > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 > alias, void *data) > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_pci_map_rid(info->np, alias, "iommu-map", > > - "iommu-map-mask", &iommu_spec.np, > > - iommu_spec.args); > > + err = of_map_rid(info->np, alias, "iommu-map", > > + "iommu-map-mask", &iommu_spec.np, > > + iommu_spec.args); > > Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if > it's being touched again, that would be nice ;) Sure.. I'll take care of this in the next version :) Regards, Nipun ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 4e7712f..af4fc3b 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -24,6 +24,7 @@ #include <linux/of_iommu.h> #include <linux/of_pci.h> #include <linux/slab.h> +#include <linux/fsl/mc.h> #define NO_IOMMU 1 @@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) return err; } +static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev, + struct device_node *master_np) +{ + struct of_phandle_args iommu_spec = { .args_count = 1 }; + int err; + + err = of_map_rid(master_np, mc_dev->icid, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); + if (err) + return err == -ENODEV ? NO_IOMMU : err; + + err = of_iommu_xlate(&mc_dev->dev, &iommu_spec); + of_node_put(iommu_spec.np); + return err; +} + const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np) { @@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev, err = pci_for_each_dma_alias(to_pci_dev(dev), of_pci_iommu_init, &info); + } else if (dev_is_fsl_mc(dev)) { + err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np); } else { struct of_phandle_args iommu_spec; int idx = 0; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 4e7712f..af4fc3b 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -24,6 +24,7 @@ #include <linux/of_iommu.h> #include <linux/of_pci.h> #include <linux/slab.h> +#include <linux/fsl/mc.h> #define NO_IOMMU 1 @@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) return err; } +static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev, + struct device_node *master_np) +{ + struct of_phandle_args iommu_spec = { .args_count = 1 }; + int err; + + err = of_map_rid(master_np, mc_dev->icid, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); + if (err) + return err == -ENODEV ? NO_IOMMU : err; + + err = of_iommu_xlate(&mc_dev->dev, &iommu_spec); + of_node_put(iommu_spec.np); + return err; +} + const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np) { @@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev, err = pci_for_each_dma_alias(to_pci_dev(dev), of_pci_iommu_init, &info); + } else if (dev_is_fsl_mc(dev)) { + err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np); } else { struct of_phandle_args iommu_spec; int idx = 0; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: devicetree, bharat.bhushan, stuyoder, frowand.list, gregkh, joro, linuxppc-dev, linux-kernel, leoyang.li, iommu, robh+dt, Nipun Gupta, linux-pci, bhelgaas, laurentiu.tudor, shawnguo, hch, linux-arm-kernel, m.szyprowski Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 4e7712f..af4fc3b 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -24,6 +24,7 @@ #include <linux/of_iommu.h> #include <linux/of_pci.h> #include <linux/slab.h> +#include <linux/fsl/mc.h> #define NO_IOMMU 1 @@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) return err; } +static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev, + struct device_node *master_np) +{ + struct of_phandle_args iommu_spec = { .args_count = 1 }; + int err; + + err = of_map_rid(master_np, mc_dev->icid, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); + if (err) + return err == -ENODEV ? NO_IOMMU : err; + + err = of_iommu_xlate(&mc_dev->dev, &iommu_spec); + of_node_put(iommu_spec.np); + return err; +} + const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np) { @@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev, err = pci_for_each_dma_alias(to_pci_dev(dev), of_pci_iommu_init, &info); + } else if (dev_is_fsl_mc(dev)) { + err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np); } else { struct of_phandle_args iommu_spec; int idx = 0; -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 4e7712f..af4fc3b 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -24,6 +24,7 @@ #include <linux/of_iommu.h> #include <linux/of_pci.h> #include <linux/slab.h> +#include <linux/fsl/mc.h> #define NO_IOMMU 1 @@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data) return err; } +static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev, + struct device_node *master_np) +{ + struct of_phandle_args iommu_spec = { .args_count = 1 }; + int err; + + err = of_map_rid(master_np, mc_dev->icid, "iommu-map", + "iommu-map-mask", &iommu_spec.np, + iommu_spec.args); + if (err) + return err == -ENODEV ? NO_IOMMU : err; + + err = of_iommu_xlate(&mc_dev->dev, &iommu_spec); + of_node_put(iommu_spec.np); + return err; +} + const struct iommu_ops *of_iommu_configure(struct device *dev, struct device_node *master_np) { @@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev, err = pci_for_each_dma_alias(to_pci_dev(dev), of_pci_iommu_init, &info); + } else if (dev_is_fsl_mc(dev)) { + err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np); } else { struct of_phandle_args iommu_spec; int idx = 0; -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta Implement bus specific support for the fsl-mc bus including registering arm_smmu_ops and bus specific device add operations. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/arm-smmu.c | 7 +++++++ drivers/iommu/iommu.c | 21 +++++++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++++ include/linux/iommu.h | 2 ++ 4 files changed, 38 insertions(+) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 69e7c60..e1d5090 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -52,6 +52,7 @@ #include <linux/spinlock.h> #include <linux/amba/bus.h> +#include <linux/fsl/mc.h> #include "io-pgtable.h" #include "arm-smmu-regs.h" @@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev) if (dev_is_pci(dev)) group = pci_device_group(dev); + else if (dev_is_fsl_mc(dev)) + group = fsl_mc_device_group(dev); else group = generic_device_group(dev); @@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void) bus_set_iommu(&pci_bus_type, &arm_smmu_ops); } #endif +#ifdef CONFIG_FSL_MC_BUS + if (!iommu_present(&fsl_mc_bus_type)) + bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops); +#endif } static int arm_smmu_device_probe(struct platform_device *pdev) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 69fef99..fbeebb2 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -32,6 +32,7 @@ #include <linux/pci.h> #include <linux/bitops.h> #include <linux/property.h> +#include <linux/fsl/mc.h> #include <trace/events/iommu.h> static struct kset *iommu_group_kset; @@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev) return iommu_group_alloc(); } +/* Get the IOMMU group for device on fsl-mc bus */ +struct iommu_group *fsl_mc_device_group(struct device *dev) +{ + struct device *cont_dev = fsl_mc_cont_dev(dev); + struct iommu_group *group; + + /* Container device is responsible for creating the iommu group */ + if (fsl_mc_is_cont_dev(dev)) { + group = iommu_group_alloc(); + if (IS_ERR(group)) + return NULL; + } else { + get_device(cont_dev); + group = iommu_group_get(cont_dev); + put_device(cont_dev); + } + + return group; +} + /** * iommu_group_get_for_dev - Find or create the IOMMU group for a device * @dev: target device diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h index f27cb14..dddaca1 100644 --- a/include/linux/fsl/mc.h +++ b/include/linux/fsl/mc.h @@ -351,6 +351,14 @@ struct fsl_mc_io { #define dev_is_fsl_mc(_dev) (0) #endif +/* Macro to check if a device is a container device */ +#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \ + FSL_MC_IS_DPRC) + +/* Macro to get the container device of a MC device */ +#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \ + (_dev) : (_dev)->parent) + /* * module_fsl_mc_driver() - Helper macro for drivers that don't do * anything special in module init/exit. This eliminates a lot of diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 41b8c57..00a460b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain, extern struct iommu_group *pci_device_group(struct device *dev); /* Generic device grouping function */ extern struct iommu_group *generic_device_group(struct device *dev); +/* FSL-MC device grouping function */ +struct iommu_group *fsl_mc_device_group(struct device *dev); /** * struct iommu_fwspec - per-device IOMMU instance data -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: linux-arm-kernel Implement bus specific support for the fsl-mc bus including registering arm_smmu_ops and bus specific device add operations. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/iommu/arm-smmu.c | 7 +++++++ drivers/iommu/iommu.c | 21 +++++++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++++ include/linux/iommu.h | 2 ++ 4 files changed, 38 insertions(+) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 69e7c60..e1d5090 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -52,6 +52,7 @@ #include <linux/spinlock.h> #include <linux/amba/bus.h> +#include <linux/fsl/mc.h> #include "io-pgtable.h" #include "arm-smmu-regs.h" @@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev) if (dev_is_pci(dev)) group = pci_device_group(dev); + else if (dev_is_fsl_mc(dev)) + group = fsl_mc_device_group(dev); else group = generic_device_group(dev); @@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void) bus_set_iommu(&pci_bus_type, &arm_smmu_ops); } #endif +#ifdef CONFIG_FSL_MC_BUS + if (!iommu_present(&fsl_mc_bus_type)) + bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops); +#endif } static int arm_smmu_device_probe(struct platform_device *pdev) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 69fef99..fbeebb2 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -32,6 +32,7 @@ #include <linux/pci.h> #include <linux/bitops.h> #include <linux/property.h> +#include <linux/fsl/mc.h> #include <trace/events/iommu.h> static struct kset *iommu_group_kset; @@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev) return iommu_group_alloc(); } +/* Get the IOMMU group for device on fsl-mc bus */ +struct iommu_group *fsl_mc_device_group(struct device *dev) +{ + struct device *cont_dev = fsl_mc_cont_dev(dev); + struct iommu_group *group; + + /* Container device is responsible for creating the iommu group */ + if (fsl_mc_is_cont_dev(dev)) { + group = iommu_group_alloc(); + if (IS_ERR(group)) + return NULL; + } else { + get_device(cont_dev); + group = iommu_group_get(cont_dev); + put_device(cont_dev); + } + + return group; +} + /** * iommu_group_get_for_dev - Find or create the IOMMU group for a device * @dev: target device diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h index f27cb14..dddaca1 100644 --- a/include/linux/fsl/mc.h +++ b/include/linux/fsl/mc.h @@ -351,6 +351,14 @@ struct fsl_mc_io { #define dev_is_fsl_mc(_dev) (0) #endif +/* Macro to check if a device is a container device */ +#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \ + FSL_MC_IS_DPRC) + +/* Macro to get the container device of a MC device */ +#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \ + (_dev) : (_dev)->parent) + /* * module_fsl_mc_driver() - Helper macro for drivers that don't do * anything special in module init/exit. This eliminates a lot of diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 41b8c57..00a460b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain, extern struct iommu_group *pci_device_group(struct device *dev); /* Generic device grouping function */ extern struct iommu_group *generic_device_group(struct device *dev); +/* FSL-MC device grouping function */ +struct iommu_group *fsl_mc_device_group(struct device *dev); /** * struct iommu_fwspec - per-device IOMMU instance data -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Implement bus specific support for the fsl-mc bus including registering arm_smmu_ops and bus specific device add operations. Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/iommu/arm-smmu.c | 7 +++++++ drivers/iommu/iommu.c | 21 +++++++++++++++++++++ include/linux/fsl/mc.h | 8 ++++++++ include/linux/iommu.h | 2 ++ 4 files changed, 38 insertions(+) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 69e7c60..e1d5090 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -52,6 +52,7 @@ #include <linux/spinlock.h> #include <linux/amba/bus.h> +#include <linux/fsl/mc.h> #include "io-pgtable.h" #include "arm-smmu-regs.h" @@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev) if (dev_is_pci(dev)) group = pci_device_group(dev); + else if (dev_is_fsl_mc(dev)) + group = fsl_mc_device_group(dev); else group = generic_device_group(dev); @@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void) bus_set_iommu(&pci_bus_type, &arm_smmu_ops); } #endif +#ifdef CONFIG_FSL_MC_BUS + if (!iommu_present(&fsl_mc_bus_type)) + bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops); +#endif } static int arm_smmu_device_probe(struct platform_device *pdev) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 69fef99..fbeebb2 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -32,6 +32,7 @@ #include <linux/pci.h> #include <linux/bitops.h> #include <linux/property.h> +#include <linux/fsl/mc.h> #include <trace/events/iommu.h> static struct kset *iommu_group_kset; @@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev) return iommu_group_alloc(); } +/* Get the IOMMU group for device on fsl-mc bus */ +struct iommu_group *fsl_mc_device_group(struct device *dev) +{ + struct device *cont_dev = fsl_mc_cont_dev(dev); + struct iommu_group *group; + + /* Container device is responsible for creating the iommu group */ + if (fsl_mc_is_cont_dev(dev)) { + group = iommu_group_alloc(); + if (IS_ERR(group)) + return NULL; + } else { + get_device(cont_dev); + group = iommu_group_get(cont_dev); + put_device(cont_dev); + } + + return group; +} + /** * iommu_group_get_for_dev - Find or create the IOMMU group for a device * @dev: target device diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h index f27cb14..dddaca1 100644 --- a/include/linux/fsl/mc.h +++ b/include/linux/fsl/mc.h @@ -351,6 +351,14 @@ struct fsl_mc_io { #define dev_is_fsl_mc(_dev) (0) #endif +/* Macro to check if a device is a container device */ +#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \ + FSL_MC_IS_DPRC) + +/* Macro to get the container device of a MC device */ +#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \ + (_dev) : (_dev)->parent) + /* * module_fsl_mc_driver() - Helper macro for drivers that don't do * anything special in module init/exit. This eliminates a lot of diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 41b8c57..00a460b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain, extern struct iommu_group *pci_device_group(struct device *dev); /* Generic device grouping function */ extern struct iommu_group *generic_device_group(struct device *dev); +/* FSL-MC device grouping function */ +struct iommu_group *fsl_mc_device_group(struct device *dev); /** * struct iommu_fwspec - per-device IOMMU instance data -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 5d8266c..624828b 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env) return 0; } +static int fsl_mc_dma_configure(struct device *dev) +{ + struct device *dma_dev = dev; + + while (dev_is_fsl_mc(dma_dev)) + dma_dev = dma_dev->parent; + + return of_dma_configure(dev, dma_dev->of_node, 0); +} + static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, char *buf) { @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = { .name = "fsl-mc", .match = fsl_mc_bus_match, .uevent = fsl_mc_bus_uevent, + .dma_configure = fsl_mc_dma_configure, .dev_groups = fsl_mc_dev_groups, }; EXPORT_SYMBOL_GPL(fsl_mc_bus_type); @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, mc_dev->icid = parent_mc_dev->icid; mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK; mc_dev->dev.dma_mask = &mc_dev->dma_mask; + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask; dev_set_msi_domain(&mc_dev->dev, dev_get_msi_domain(&parent_mc_dev->dev)); } @@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, goto error_cleanup_dev; } - /* Objects are coherent, unless 'no shareability' flag set. */ - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY)) - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); - /* * The device-specific probe callback will get invoked by device_add() */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 5d8266c..624828b 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env) return 0; } +static int fsl_mc_dma_configure(struct device *dev) +{ + struct device *dma_dev = dev; + + while (dev_is_fsl_mc(dma_dev)) + dma_dev = dma_dev->parent; + + return of_dma_configure(dev, dma_dev->of_node, 0); +} + static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, char *buf) { @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = { .name = "fsl-mc", .match = fsl_mc_bus_match, .uevent = fsl_mc_bus_uevent, + .dma_configure = fsl_mc_dma_configure, .dev_groups = fsl_mc_dev_groups, }; EXPORT_SYMBOL_GPL(fsl_mc_bus_type); @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, mc_dev->icid = parent_mc_dev->icid; mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK; mc_dev->dev.dma_mask = &mc_dev->dma_mask; + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask; dev_set_msi_domain(&mc_dev->dev, dev_get_msi_domain(&parent_mc_dev->dev)); } @@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, goto error_cleanup_dev; } - /* Objects are coherent, unless 'no shareability' flag set. */ - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY)) - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); - /* * The device-specific probe callback will get invoked by device_add() */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index 5d8266c..624828b 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env) return 0; } +static int fsl_mc_dma_configure(struct device *dev) +{ + struct device *dma_dev = dev; + + while (dev_is_fsl_mc(dma_dev)) + dma_dev = dma_dev->parent; + + return of_dma_configure(dev, dma_dev->of_node, 0); +} + static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, char *buf) { @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = { .name = "fsl-mc", .match = fsl_mc_bus_match, .uevent = fsl_mc_bus_uevent, + .dma_configure = fsl_mc_dma_configure, .dev_groups = fsl_mc_dev_groups, }; EXPORT_SYMBOL_GPL(fsl_mc_bus_type); @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, mc_dev->icid = parent_mc_dev->icid; mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK; mc_dev->dev.dma_mask = &mc_dev->dma_mask; + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask; dev_set_msi_domain(&mc_dev->dev, dev_get_msi_domain(&parent_mc_dev->dev)); } @@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, goto error_cleanup_dev; } - /* Objects are coherent, unless 'no shareability' flag set. */ - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY)) - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); - /* * The device-specific probe callback will get invoked by device_add() */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus @ 2018-04-26 0:00 ` kbuild test robot 0 siblings, 0 replies; 106+ messages in thread From: kbuild test robot @ 2018-04-26 0:00 UTC (permalink / raw) To: Nipun Gupta Cc: kbuild-all, robin.murphy, will.deacon, mark.rutland, catalin.marinas, hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta [-- Attachment #1: Type: text/plain, Size: 2834 bytes --] Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180424] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931 config: powerpc64-allmodconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=powerpc64 All errors (new ones prefixed by >>): drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure': >> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure' return of_dma_configure(dev, dma_dev->of_node, 0); ^~~~~~~~~~~~~~~~ In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0: include/linux/of_device.h:58:5: note: declared here int of_dma_configure(struct device *dev, struct device_node *np); ^~~~~~~~~~~~~~~~ drivers/bus/fsl-mc/fsl-mc-bus.c: At top level: >> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure' .dma_configure = fsl_mc_dma_configure, ^~~~~~~~~~~~~ vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c 129 130 static int fsl_mc_dma_configure(struct device *dev) 131 { 132 struct device *dma_dev = dev; 133 134 while (dev_is_fsl_mc(dma_dev)) 135 dma_dev = dma_dev->parent; 136 > 137 return of_dma_configure(dev, dma_dev->of_node, 0); 138 } 139 140 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, 141 char *buf) 142 { 143 struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); 144 145 return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor, 146 mc_dev->obj_desc.type); 147 } 148 static DEVICE_ATTR_RO(modalias); 149 150 static struct attribute *fsl_mc_dev_attrs[] = { 151 &dev_attr_modalias.attr, 152 NULL, 153 }; 154 155 ATTRIBUTE_GROUPS(fsl_mc_dev); 156 157 struct bus_type fsl_mc_bus_type = { 158 .name = "fsl-mc", 159 .match = fsl_mc_bus_match, 160 .uevent = fsl_mc_bus_uevent, > 161 .dma_configure = fsl_mc_dma_configure, 162 .dev_groups = fsl_mc_dev_groups, 163 }; 164 EXPORT_SYMBOL_GPL(fsl_mc_bus_type); 165 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 56229 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus @ 2018-04-26 0:00 ` kbuild test robot 0 siblings, 0 replies; 106+ messages in thread From: kbuild test robot @ 2018-04-26 0:00 UTC (permalink / raw) To: linux-arm-kernel Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180424] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931 config: powerpc64-allmodconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=powerpc64 All errors (new ones prefixed by >>): drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure': >> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure' return of_dma_configure(dev, dma_dev->of_node, 0); ^~~~~~~~~~~~~~~~ In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0: include/linux/of_device.h:58:5: note: declared here int of_dma_configure(struct device *dev, struct device_node *np); ^~~~~~~~~~~~~~~~ drivers/bus/fsl-mc/fsl-mc-bus.c: At top level: >> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure' .dma_configure = fsl_mc_dma_configure, ^~~~~~~~~~~~~ vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c 129 130 static int fsl_mc_dma_configure(struct device *dev) 131 { 132 struct device *dma_dev = dev; 133 134 while (dev_is_fsl_mc(dma_dev)) 135 dma_dev = dma_dev->parent; 136 > 137 return of_dma_configure(dev, dma_dev->of_node, 0); 138 } 139 140 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, 141 char *buf) 142 { 143 struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); 144 145 return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor, 146 mc_dev->obj_desc.type); 147 } 148 static DEVICE_ATTR_RO(modalias); 149 150 static struct attribute *fsl_mc_dev_attrs[] = { 151 &dev_attr_modalias.attr, 152 NULL, 153 }; 154 155 ATTRIBUTE_GROUPS(fsl_mc_dev); 156 157 struct bus_type fsl_mc_bus_type = { 158 .name = "fsl-mc", 159 .match = fsl_mc_bus_match, 160 .uevent = fsl_mc_bus_uevent, > 161 .dma_configure = fsl_mc_dma_configure, 162 .dev_groups = fsl_mc_dev_groups, 163 }; 164 EXPORT_SYMBOL_GPL(fsl_mc_bus_type); 165 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 56229 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180426/3bed7b4d/attachment-0001.gz> ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus @ 2018-04-26 0:00 ` kbuild test robot 0 siblings, 0 replies; 106+ messages in thread From: kbuild test robot @ 2018-04-26 0:00 UTC (permalink / raw) To: Nipun Gupta Cc: mark.rutland, stuyoder, linux-pci, will.deacon, shawnguo, bharat.bhushan, hch, m.szyprowski, frowand.list, joro, catalin.marinas, devicetree, robin.murphy, robh+dt, Nipun Gupta, bhelgaas, linux-arm-kernel, laurentiu.tudor, gregkh, linux-kernel, leoyang.li, iommu, kbuild-all, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 2834 bytes --] Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180424] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931 config: powerpc64-allmodconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=powerpc64 All errors (new ones prefixed by >>): drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure': >> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure' return of_dma_configure(dev, dma_dev->of_node, 0); ^~~~~~~~~~~~~~~~ In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0: include/linux/of_device.h:58:5: note: declared here int of_dma_configure(struct device *dev, struct device_node *np); ^~~~~~~~~~~~~~~~ drivers/bus/fsl-mc/fsl-mc-bus.c: At top level: >> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure' .dma_configure = fsl_mc_dma_configure, ^~~~~~~~~~~~~ vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c 129 130 static int fsl_mc_dma_configure(struct device *dev) 131 { 132 struct device *dma_dev = dev; 133 134 while (dev_is_fsl_mc(dma_dev)) 135 dma_dev = dma_dev->parent; 136 > 137 return of_dma_configure(dev, dma_dev->of_node, 0); 138 } 139 140 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, 141 char *buf) 142 { 143 struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); 144 145 return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor, 146 mc_dev->obj_desc.type); 147 } 148 static DEVICE_ATTR_RO(modalias); 149 150 static struct attribute *fsl_mc_dev_attrs[] = { 151 &dev_attr_modalias.attr, 152 NULL, 153 }; 154 155 ATTRIBUTE_GROUPS(fsl_mc_dev); 156 157 struct bus_type fsl_mc_bus_type = { 158 .name = "fsl-mc", 159 .match = fsl_mc_bus_match, 160 .uevent = fsl_mc_bus_uevent, > 161 .dma_configure = fsl_mc_dma_configure, 162 .dev_groups = fsl_mc_dev_groups, 163 }; 164 EXPORT_SYMBOL_GPL(fsl_mc_bus_type); 165 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 56229 bytes --] [-- Attachment #3: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus @ 2018-04-26 0:00 ` kbuild test robot 0 siblings, 0 replies; 106+ messages in thread From: kbuild test robot @ 2018-04-26 0:00 UTC (permalink / raw) To: Nipun Gupta Cc: mark.rutland-5wv7dgnIgG8, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, linux-pci-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, catalin.marinas-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, kbuild-all-JC7UmRfGjtg, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ [-- Attachment #1: Type: text/plain, Size: 2834 bytes --] Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180424] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931 config: powerpc64-allmodconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=powerpc64 All errors (new ones prefixed by >>): drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure': >> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure' return of_dma_configure(dev, dma_dev->of_node, 0); ^~~~~~~~~~~~~~~~ In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0: include/linux/of_device.h:58:5: note: declared here int of_dma_configure(struct device *dev, struct device_node *np); ^~~~~~~~~~~~~~~~ drivers/bus/fsl-mc/fsl-mc-bus.c: At top level: >> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure' .dma_configure = fsl_mc_dma_configure, ^~~~~~~~~~~~~ vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c 129 130 static int fsl_mc_dma_configure(struct device *dev) 131 { 132 struct device *dma_dev = dev; 133 134 while (dev_is_fsl_mc(dma_dev)) 135 dma_dev = dma_dev->parent; 136 > 137 return of_dma_configure(dev, dma_dev->of_node, 0); 138 } 139 140 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr, 141 char *buf) 142 { 143 struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev); 144 145 return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor, 146 mc_dev->obj_desc.type); 147 } 148 static DEVICE_ATTR_RO(modalias); 149 150 static struct attribute *fsl_mc_dev_attrs[] = { 151 &dev_attr_modalias.attr, 152 NULL, 153 }; 154 155 ATTRIBUTE_GROUPS(fsl_mc_dev); 156 157 struct bus_type fsl_mc_bus_type = { 158 .name = "fsl-mc", 159 .match = fsl_mc_bus_match, 160 .uevent = fsl_mc_bus_uevent, > 161 .dma_configure = fsl_mc_dma_configure, 162 .dev_groups = fsl_mc_dev_groups, 163 }; 164 EXPORT_SYMBOL_GPL(fsl_mc_bus_type); 165 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 56229 bytes --] [-- Attachment #3: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy, will.deacon, mark.rutland, catalin.marinas Cc: hch, gregkh, joro, robh+dt, m.szyprowski, shawnguo, frowand.list, bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan, stuyoder, laurentiu.tudor, leoyang.li, Nipun Gupta Fsl-mc bus now support the iommu-map property. Comply to this binding for fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..1b1c5eb 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -135,6 +135,7 @@ #address-cells = <2>; #size-cells = <2>; ranges; + dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>; clockgen: clocking@1300000 { compatible = "fsl,ls2080a-clockgen"; @@ -357,6 +358,8 @@ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-map = <0 &smmu 0 0>; /* This is fixed-up by u-boot */ + dma-coherent; #address-cells = <3>; #size-cells = <1>; @@ -460,6 +463,8 @@ compatible = "arm,mmu-500"; reg = <0 0x5000000 0 0x800000>; #global-interrupts = <12>; + #iommu-cells = <1>; + stream-match-mask = <0x7C00>; interrupts = <0 13 4>, /* global secure fault */ <0 14 4>, /* combined secure interrupt */ <0 15 4>, /* global non-secure fault */ @@ -502,7 +507,6 @@ <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, <0 208 4>, <0 209 4>; - mmu-masters = <&fsl_mc 0x300 0>; }; dspi: dspi@2100000 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: linux-arm-kernel Fsl-mc bus now support the iommu-map property. Comply to this binding for fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..1b1c5eb 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -135,6 +135,7 @@ #address-cells = <2>; #size-cells = <2>; ranges; + dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>; clockgen: clocking at 1300000 { compatible = "fsl,ls2080a-clockgen"; @@ -357,6 +358,8 @@ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-map = <0 &smmu 0 0>; /* This is fixed-up by u-boot */ + dma-coherent; #address-cells = <3>; #size-cells = <1>; @@ -460,6 +463,8 @@ compatible = "arm,mmu-500"; reg = <0 0x5000000 0 0x800000>; #global-interrupts = <12>; + #iommu-cells = <1>; + stream-match-mask = <0x7C00>; interrupts = <0 13 4>, /* global secure fault */ <0 14 4>, /* combined secure interrupt */ <0 15 4>, /* global non-secure fault */ @@ -502,7 +507,6 @@ <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, <0 208 4>, <0 209 4>; - mmu-masters = <&fsl_mc 0x300 0>; }; dspi: dspi at 2100000 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc @ 2018-04-17 10:21 ` Nipun Gupta 0 siblings, 0 replies; 106+ messages in thread From: Nipun Gupta @ 2018-04-17 10:21 UTC (permalink / raw) To: robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8 Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, stuyoder-Re5JQEeQqe8AvxtiuMwx3w, frowand.list-Re5JQEeQqe8AvxtiuMwx3w, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, shawnguo-DgEjT+Ai2ygdnm+yROfE0A, hch-jcswGhMUV9g, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Fsl-mc bus now support the iommu-map property. Comply to this binding for fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration. Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org> --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..1b1c5eb 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -135,6 +135,7 @@ #address-cells = <2>; #size-cells = <2>; ranges; + dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>; clockgen: clocking@1300000 { compatible = "fsl,ls2080a-clockgen"; @@ -357,6 +358,8 @@ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ msi-parent = <&its>; + iommu-map = <0 &smmu 0 0>; /* This is fixed-up by u-boot */ + dma-coherent; #address-cells = <3>; #size-cells = <1>; @@ -460,6 +463,8 @@ compatible = "arm,mmu-500"; reg = <0 0x5000000 0 0x800000>; #global-interrupts = <12>; + #iommu-cells = <1>; + stream-match-mask = <0x7C00>; interrupts = <0 13 4>, /* global secure fault */ <0 14 4>, /* combined secure interrupt */ <0 15 4>, /* global non-secure fault */ @@ -502,7 +507,6 @@ <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, <0 208 4>, <0 209 4>; - mmu-masters = <&fsl_mc 0x300 0>; }; dspi: dspi@2100000 { -- 1.9.1 ^ permalink raw reply related [flat|nested] 106+ messages in thread
end of thread, other threads:[~2018-04-26 0:01 UTC | newest] Thread overview: 106+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-05 14:29 [PATCH 0/6] Support for fsl-mc bus and its devices in SMMU Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:53 ` Robin Murphy 2018-03-05 14:53 ` Robin Murphy 2018-03-05 15:00 ` Nipun Gupta 2018-03-05 15:00 ` Nipun Gupta 2018-03-05 15:00 ` Nipun Gupta 2018-03-05 15:37 ` Robin Murphy 2018-03-05 15:37 ` Robin Murphy 2018-03-05 15:37 ` Robin Murphy 2018-03-05 15:54 ` Nipun Gupta 2018-03-05 15:54 ` Nipun Gupta 2018-03-05 15:54 ` Nipun Gupta 2018-03-07 22:40 ` Rob Herring 2018-03-07 22:40 ` Rob Herring 2018-03-07 22:40 ` Rob Herring 2018-03-08 12:32 ` Nipun Gupta 2018-03-08 12:32 ` Nipun Gupta 2018-03-08 12:32 ` Nipun Gupta 2018-03-08 12:32 ` Nipun Gupta 2018-03-05 14:29 ` [PATCH 2/6] iommu: support iommu configuration for fsl-mc devices Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` [PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` [PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` [PATCH 5/6] dma-mapping: support fsl-mc bus Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 15:08 ` Christoph Hellwig 2018-03-05 15:08 ` Christoph Hellwig 2018-03-05 15:48 ` Robin Murphy 2018-03-05 15:48 ` Robin Murphy 2018-03-05 15:48 ` Robin Murphy 2018-03-05 18:39 ` Christoph Hellwig 2018-03-05 18:39 ` Christoph Hellwig 2018-03-05 18:39 ` Christoph Hellwig 2018-03-05 18:51 ` Robin Murphy 2018-03-05 18:51 ` Robin Murphy 2018-03-05 18:51 ` Robin Murphy 2018-03-06 4:41 ` Nipun Gupta 2018-03-06 4:41 ` Nipun Gupta 2018-03-06 4:41 ` Nipun Gupta 2018-03-06 4:41 ` Nipun Gupta 2018-03-08 7:41 ` Christoph Hellwig 2018-03-08 7:41 ` Christoph Hellwig 2018-03-08 7:41 ` Christoph Hellwig 2018-03-09 18:29 ` Nipun Gupta 2018-03-09 18:29 ` Nipun Gupta 2018-03-09 18:29 ` Nipun Gupta 2018-03-09 18:29 ` Nipun Gupta 2018-03-09 18:50 ` Robin Murphy 2018-03-09 18:50 ` Robin Murphy 2018-03-09 18:50 ` Robin Murphy 2018-03-05 14:29 ` [PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-03-05 14:29 ` Nipun Gupta 2018-04-17 10:21 ` [PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` [PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 16:52 ` Robin Murphy 2018-04-17 16:52 ` Robin Murphy 2018-04-17 16:52 ` Robin Murphy 2018-04-18 5:09 ` Bharat Bhushan 2018-04-18 5:09 ` Bharat Bhushan 2018-04-18 5:09 ` Bharat Bhushan 2018-04-18 5:09 ` Bharat Bhushan 2018-04-18 5:09 ` Bharat Bhushan 2018-04-18 6:21 ` Nipun Gupta 2018-04-18 6:21 ` Nipun Gupta 2018-04-18 6:21 ` Nipun Gupta 2018-04-18 6:21 ` Nipun Gupta 2018-04-18 6:21 ` Nipun Gupta 2018-04-17 10:21 ` [PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` [PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on " Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-26 0:00 ` kbuild test robot 2018-04-26 0:00 ` kbuild test robot 2018-04-26 0:00 ` kbuild test robot 2018-04-26 0:00 ` kbuild test robot 2018-04-17 10:21 ` [PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta 2018-04-17 10:21 ` Nipun Gupta
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.