Re: [PATCH 1/2] dt-bindings: arm-smmu: Fix json-schema for Tegra

2021-12-06 Thread Rob Herring
On Wed, Dec 1, 2021 at 9:57 AM Jon Hunter  wrote:
>
> The dt_binding_check currently issues the following warnings for the

dtbs_check

> Tegra186 and Tegra194 SMMUs ...
>
>  arch/arm64/boot/dts/nvidia/tegra186-p2771-.dt.yaml: iommu@1200:
>   'nvidia,memory-controller' does not match any of the regexes: 
> 'pinctrl-[0-9]+'
> From schema: Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>   DTC arch/arm64/boot/dts/nvidia/tegra186-p3509-+p3636-0001.dt.yaml
>   CHECK   arch/arm64/boot/dts/nvidia/tegra186-p3509-+p3636-0001.dt.yaml
>
> Add the missing 'nvidia,memory-controller' property to fix the above
> warning.

Thierry sent the same change, but made it required. That's not a
compatible change, but could be justified. Please sort out which one
you need applied.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/4] dt-bindings: memory: mediatek: Correct the minItems of clk for larbs

2021-12-03 Thread Rob Herring
On Fri, 03 Dec 2021 14:40:24 +0800, Yong Wu wrote:
> If a platform's larb support gals, there will be some larbs have a one
> more "gals" clock while the others still only need "apb"/"smi" clocks.
> then the minItems is 2 and the maxItems is 3.
> 
> Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT 
> schema")
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/memory-controllers/mediatek,smi-larb.yaml  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consider if they are expected or the schema is
incorrect. These may not be new warnings.

Note that it is not yet a requirement to have 0 warnings for dtbs_check.
This will change in the future.

Full log is available here: https://patchwork.ozlabs.org/patch/1563127


larb@14016000: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml

larb@14017000: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dt.yaml

larb@15001000: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml

larb@1601: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dt.yaml

larb@1601: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml

larb@1701: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dt.yaml

Re: [PATCH 1/4] dt-bindings: iommu: dart: add t6000 compatible

2021-11-29 Thread Rob Herring
On Wed, 17 Nov 2021 22:15:06 +0100, Sven Peter wrote:
> The M1 Max/Pro SoCs come with a new DART variant that is incompatible with
> the previous one. Add a new compatible for those.
> 
> Signed-off-by: Sven Peter 
> ---
>  Documentation/devicetree/bindings/iommu/apple,dart.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/4] dt-bindings: arm-smmu: Add compatible for Tegra234 SOC

2021-11-29 Thread Rob Herring
On Fri, 12 Nov 2021 14:12:29 +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The NVIDIA Tegra234 SoC comes with one single-instance ARM SMMU used by
> isochronous memory clients and two dual-instance ARM SMMUs used by non-
> isochronous memory clients.
> 
> Signed-off-by: Thierry Reding 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/4] dt-bindings: arm-smmu: Document nvidia,memory-controller property

2021-11-29 Thread Rob Herring
On Fri, Nov 12, 2021 at 02:12:28PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> On NVIDIA SoC's the ARM SMMU needs to interact with the memory
> controller in order to map memory clients to the corresponding stream
> IDs. Document how the nvidia,memory-controller property can be used to
> achieve this.
> 
> Signed-off-by: Thierry Reding 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index f66a3effba73..cf32a7955475 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -155,6 +155,12 @@ properties:
>power-domains:
>  maxItems: 1
>  
> +  nvidia,memory-controller:
> +description: A phandle to the memory controller on NVIDIA Tegra186
> +  and later SoCs. The memory controller needs to be programmed with
> +  a mapping of memory client IDs to ARM SMMU stream IDs.
> +$ref: /schemas/types.yaml#/definitions/phandle
> +
>  required:
>- compatible
>- reg
> @@ -177,6 +183,9 @@ allOf:
>  reg:
>minItems: 1
>maxItems: 2
> +
> +  required:
> +- nvidia,memory-controller

That's not a compatible change. Document why it is necessary if that's 
intended.

>  else:
>properties:
>  reg:
> -- 
> 2.33.1
> 
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/3] dt-bindings: Add io-tlb-segsize property for restricted-dma-pool

2021-11-23 Thread Rob Herring
On Tue, 23 Nov 2021 19:21:03 +0800, Hsin-Yi Wang wrote:
> Add a io-tlb-segsize property that each restricted-dma-pool can set its
> own io_tlb_segsize since some use cases require slabs larger than default
> value (128).
> 
> Signed-off-by: Hsin-Yi Wang 
> ---
>  .../bindings/reserved-memory/shared-dma-pool.yaml | 8 
>  1 file changed, 8 insertions(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml:
 properties:io-tlb-segsize:type: 'anyOf' conditional failed, one must be fixed:
'u32' is not one of ['array', 'boolean', 'integer', 'null', 'number', 
'object', 'string']
'u32' is not of type 'array'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml:
 properties:io-tlb-segsize:type: 'u32' is not one of ['boolean', 'object']
from schema $id: http://devicetree.org/meta-schemas/core.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml:
 ignoring, error in schema: properties: io-tlb-segsize: type
warning: no schema found in file: 
./Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
Documentation/devicetree/bindings/display/msm/gpu.example.dt.yaml:0:0: 
/example-1/reserved-memory/gpu@8f20: failed to match any schema with 
compatible: ['shared-dma-pool']
Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.example.dt.yaml:0:0:
 /example-0/reserved-memory/linux,cma: failed to match any schema with 
compatible: ['shared-dma-pool']
Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.example.dt.yaml:0:0:
 /example-0/reserved-memory/restricted-dma-pool@5000: failed to match any 
schema with compatible: ['restricted-dma-pool']
Documentation/devicetree/bindings/dsp/fsl,dsp.example.dt.yaml:0:0: 
/example-1/vdev0buffer@9430: failed to match any schema with compatible: 
['shared-dma-pool']
Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.example.dt.yaml:0:0:
 /example-0/reserved-memory/dsp-memory@9800: failed to match any schema 
with compatible: ['shared-dma-pool']
Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.example.dt.yaml:0:0:
 /example-1/reserved-memory/ipu-memory@9580: failed to match any schema 
with compatible: ['shared-dma-pool']
Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.example.dt.yaml:0:0:
 /example-2/reserved-memory/dsp1-memory@9900: failed to match any schema 
with compatible: ['shared-dma-pool']
Documentation/devicetree/bindings/sound/google,cros-ec-codec.example.dt.yaml:0:0:
 /example-0/reserved-mem@5280: failed to match any schema with compatible: 
['shared-dma-pool']

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1558503

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/2] dt-bindings: Add Arm SMMUv3 PMCG binding

2021-11-17 Thread Rob Herring
On Tue, Nov 16, 2021 at 5:52 AM Jean-Philippe Brucker
 wrote:
>
> Add binding for the Arm SMMUv3 PMU. Each node represents a PMCG, and is
> placed as a sibling node of the SMMU. Although the PMCGs registers may
> be within the SMMU MMIO region, they are separate devices, and there can
> be multiple PMCG devices for each SMMU (for example one for the TCU and
> one for each TBU).
>
> Signed-off-by: Jean-Philippe Brucker 
> ---
>  .../bindings/iommu/arm,smmu-v3-pmcg.yaml  | 67 +++
>  1 file changed, 67 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml 
> b/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
> new file mode 100644
> index ..a893e071fdb4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/arm,smmu-v3-pmcg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Arm SMMUv3 Performance Monitor Counter Group
> +
> +maintainers:
> +  - Will Deacon 
> +  - Robin Murphy 
> +
> +description: |+

Don't need '|+' if no formatting to preserve.

> +  An SMMUv3 may have several Performance Monitor Counter Group (PMCG).
> +  They are standalone performance monitoring units that support both
> +  architected and IMPLEMENTATION DEFINED event counters.

Humm, I don't know that I agree they are standalone. They could be I
guess, but looking at the MMU-600 spec the PMCG looks like it's just a
subset of registers in a larger block. This seems similar to MPAM
(which I'm working on a binding for) where it's just a register map
and interrupts, but every other possible resource is unspecified by
the architecture.

The simplest change from this would be just specifying that the PMCG
is child node(s) of whatever it is part of. The extreme would be this
is all part of the SMMU binding (i.e. reg entry X is PMCG registers,
interrupts entry Y is pmu irq).

> +
> +properties:
> +  $nodename:
> +pattern: "^pmu@[0-9a-f]*"

s/*/+/

Need at least 1 digit.

> +  compatible:
> +oneOf:
> +  - items:
> +- enum:
> +  - hisilicon,smmu-v3-pmcg-hip08
> +- const: arm,smmu-v3-pmcg
> +  - const: arm,smmu-v3-pmcg
> +
> +  reg:
> +description: |
> +  Base addresses of the PMCG registers. Either a single address for Page > 0
> +  or an additional address for Page 1, where some registers can be
> +  relocated with SMMU_PMCG_CFGR.RELOC_CTRS.
> +minItems: 1
> +maxItems: 2
> +
> +  interrupts:
> +maxItems: 1
> +
> +  msi-parent: true
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |+
> +#include 
> +#include 
> +
> +pmu@2b42 {
> +compatible = "arm,smmu-v3-pmcg";
> +reg = <0 0x2b42 0 0x1000>,
> +  <0 0x2b43 0 0x1000>;
> +interrupts = ;
> +msi-parent = < 0xff>;
> +};
> +
> +pmu@2b44 {
> +compatible = "arm,smmu-v3-pmcg";
> +reg = <0 0x2b44 0 0x1000>,
> +  <0 0x2b45 0 0x1000>;
> +interrupts = ;
> +msi-parent = < 0xff>;
> +};
> --
> 2.33.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/2] dt-bindings: Add Arm SMMUv3 PMCG binding

2021-11-16 Thread Rob Herring
On Tue, 16 Nov 2021 11:35:36 +, Jean-Philippe Brucker wrote:
> Add binding for the Arm SMMUv3 PMU. Each node represents a PMCG, and is
> placed as a sibling node of the SMMU. Although the PMCGs registers may
> be within the SMMU MMIO region, they are separate devices, and there can
> be multiple PMCG devices for each SMMU (for example one for the TCU and
> one for each TBU).
> 
> Signed-off-by: Jean-Philippe Brucker 
> ---
>  .../bindings/iommu/arm,smmu-v3-pmcg.yaml  | 67 +++
>  1 file changed, 67 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml:24:9: [warning] 
wrong indentation: expected 10 but found 8 (indentation)
./Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml:25:11: 
[warning] wrong indentation: expected 12 but found 10 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml:
 example-0: pmu@2b42:reg:0: [0, 725745664, 0, 4096] is too long
From schema: 
/usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml:
 example-0: pmu@2b42:reg:1: [0, 725811200, 0, 4096] is too long
From schema: 
/usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml:
 example-0: pmu@2b44:reg:0: [0, 725876736, 0, 4096] is too long
From schema: 
/usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml:
 example-0: pmu@2b44:reg:1: [0, 725942272, 0, 4096] is too long
From schema: 
/usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1555758

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: arm-smmu: Add compatible for the SDX55 SoC

2021-10-29 Thread Rob Herring
On Thu, Oct 28, 2021 at 04:39:40PM -0500, Rob Herring wrote:
> On Thu, 21 Oct 2021 01:17:00 +0200, David Heidelberg wrote:
> > Add missing compatible for the SDX55 SoC.
> > 
> > Signed-off-by: David Heidelberg 
> > ---
> >  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> 
> Applied, thanks!

Now dropped. This conflicts with Will's tree, so he should take it. 

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: arm-smmu: Add compatible for the SDX55 SoC

2021-10-28 Thread Rob Herring
On Thu, 21 Oct 2021 01:17:00 +0200, David Heidelberg wrote:
> Add missing compatible for the SDX55 SoC.
> 
> Signed-off-by: David Heidelberg 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Applied, thanks!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 02/13] dt-bindings: memory: mediatek: Add mt8195 smi sub common

2021-09-21 Thread Rob Herring
On Tue, 14 Sep 2021 19:36:52 +0800, Yong Wu wrote:
> Add the binding for smi-sub-common. The SMI block diagram like this:
> 
> IOMMU
>  |  |
>   smi-common
>   --
>   |    |
>  larb0   larb7   <-max is 8
> 
> The smi-common connects with smi-larb and IOMMU. The maximum larbs number
> that connects with a smi-common is 8. If the engines number is over 8,
> sometimes we use a smi-sub-common which is nearly same with smi-common.
> It supports up to 8 input and 1 output(smi-common has 2 output)
> 
> Something like:
> 
> IOMMU
>  |  |
>   smi-common
>   -
>   |  |  ...
> larb0  sub-common   ...   <-max is 8
>   ---
>||...   <-max is 8 too.
>  larb2 larb5
> 
> We don't need extra SW setting for smi-sub-common, only the sub-common has
> special clocks need to enable when the engines access dram.
> 
> If it is sub-common, it should have a "mediatek,smi" phandle to point to
> its smi-common. meanwhile the sub-common only has one gals clock.
> 
> Signed-off-by: Yong Wu 
> ---
> change note: add "else mediatek,smi: false".
> ---
>  .../mediatek,smi-common.yaml  | 28 +++
>  1 file changed, 28 insertions(+)
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier

2021-09-07 Thread Rob Herring
On Fri, Sep 3, 2021 at 10:36 AM Thierry Reding  wrote:
>
> On Fri, Sep 03, 2021 at 09:36:33AM -0500, Rob Herring wrote:
> > On Fri, Sep 3, 2021 at 8:52 AM Thierry Reding  
> > wrote:
> > >
> > > On Fri, Sep 03, 2021 at 08:20:55AM -0500, Rob Herring wrote:
> > > > On Wed, Sep 1, 2021 at 9:13 AM Thierry Reding 
> > > >  wrote:
> > > > >
> > > > > On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote:
> > > > > > 01.07.2021 21:14, Thierry Reding пишет:
> > > > > > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote:
> > > > > > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote:
> > > > > > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote:
> > > > > > >>>> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote:
> > > > > > >>>>> From: Thierry Reding 
> > > > > > >>>>>
> > > > > > >>>>> Reserved memory region phandle references can be accompanied 
> > > > > > >>>>> by a
> > > > > > >>>>> specifier that provides additional information about how that 
> > > > > > >>>>> specific
> > > > > > >>>>> reference should be treated.
> > > > > > >>>>>
> > > > > > >>>>> One use-case is to mark a memory region as needing an 
> > > > > > >>>>> identity mapping
> > > > > > >>>>> in the system's IOMMU for the device that references the 
> > > > > > >>>>> region. This is
> > > > > > >>>>> needed for example when the bootloader has set up hardware 
> > > > > > >>>>> (such as a
> > > > > > >>>>> display controller) to actively access a memory region (e.g. 
> > > > > > >>>>> a boot
> > > > > > >>>>> splash screen framebuffer) during boot. The operating system 
> > > > > > >>>>> can use the
> > > > > > >>>>> identity mapping flag from the specifier to make sure an 
> > > > > > >>>>> IOMMU identity
> > > > > > >>>>> mapping is set up for the framebuffer before IOMMU 
> > > > > > >>>>> translations are
> > > > > > >>>>> enabled for the display controller.
> > > > > > >>>>>
> > > > > > >>>>> Signed-off-by: Thierry Reding 
> > > > > > >>>>> ---
> > > > > > >>>>>  .../reserved-memory/reserved-memory.txt   | 21 
> > > > > > >>>>> +++
> > > > > > >>>>>  include/dt-bindings/reserved-memory.h |  8 +++
> > > > > > >>>>>  2 files changed, 29 insertions(+)
> > > > > > >>>>>  create mode 100644 include/dt-bindings/reserved-memory.h
> > > > > > >>>>
> > > > > > >>>> Sorry for being slow on this. I have 2 concerns.
> > > > > > >>>>
> > > > > > >>>> First, this creates an ABI issue. A DT with cells in 
> > > > > > >>>> 'memory-region'
> > > > > > >>>> will not be understood by an existing OS. I'm less concerned 
> > > > > > >>>> about this
> > > > > > >>>> if we address that with a stable fix. (Though I'm pretty sure 
> > > > > > >>>> we've
> > > > > > >>>> naively added #?-cells in the past ignoring this issue.)
> > > > > > >>>
> > > > > > >>> A while ago I had proposed adding memory-region*s* as an 
> > > > > > >>> alternative
> > > > > > >>> name for memory-region to make the naming more consistent with 
> > > > > > >>> other
> > > > > > >>> types of properties (think clocks, resets, gpios, ...). If we 
> > > > > > >>> added
> > > > > > >>> that, we could easily differentiate between the "legacy" cases 
> > > > &

Re: [PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779a0 support

2021-09-03 Thread Rob Herring
On Wed, 01 Sep 2021 19:27:04 +0900, Yoshihiro Shimoda wrote:
> Add support for r8a779a0 (R-Car V3U).
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier

2021-09-03 Thread Rob Herring
On Fri, Sep 3, 2021 at 8:52 AM Thierry Reding  wrote:
>
> On Fri, Sep 03, 2021 at 08:20:55AM -0500, Rob Herring wrote:
> > On Wed, Sep 1, 2021 at 9:13 AM Thierry Reding  
> > wrote:
> > >
> > > On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote:
> > > > 01.07.2021 21:14, Thierry Reding пишет:
> > > > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote:
> > > > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote:
> > > > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote:
> > > > >>>> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote:
> > > > >>>>> From: Thierry Reding 
> > > > >>>>>
> > > > >>>>> Reserved memory region phandle references can be accompanied by a
> > > > >>>>> specifier that provides additional information about how that 
> > > > >>>>> specific
> > > > >>>>> reference should be treated.
> > > > >>>>>
> > > > >>>>> One use-case is to mark a memory region as needing an identity 
> > > > >>>>> mapping
> > > > >>>>> in the system's IOMMU for the device that references the region. 
> > > > >>>>> This is
> > > > >>>>> needed for example when the bootloader has set up hardware (such 
> > > > >>>>> as a
> > > > >>>>> display controller) to actively access a memory region (e.g. a 
> > > > >>>>> boot
> > > > >>>>> splash screen framebuffer) during boot. The operating system can 
> > > > >>>>> use the
> > > > >>>>> identity mapping flag from the specifier to make sure an IOMMU 
> > > > >>>>> identity
> > > > >>>>> mapping is set up for the framebuffer before IOMMU translations 
> > > > >>>>> are
> > > > >>>>> enabled for the display controller.
> > > > >>>>>
> > > > >>>>> Signed-off-by: Thierry Reding 
> > > > >>>>> ---
> > > > >>>>>  .../reserved-memory/reserved-memory.txt   | 21 
> > > > >>>>> +++
> > > > >>>>>  include/dt-bindings/reserved-memory.h |  8 +++
> > > > >>>>>  2 files changed, 29 insertions(+)
> > > > >>>>>  create mode 100644 include/dt-bindings/reserved-memory.h
> > > > >>>>
> > > > >>>> Sorry for being slow on this. I have 2 concerns.
> > > > >>>>
> > > > >>>> First, this creates an ABI issue. A DT with cells in 
> > > > >>>> 'memory-region'
> > > > >>>> will not be understood by an existing OS. I'm less concerned about 
> > > > >>>> this
> > > > >>>> if we address that with a stable fix. (Though I'm pretty sure we've
> > > > >>>> naively added #?-cells in the past ignoring this issue.)
> > > > >>>
> > > > >>> A while ago I had proposed adding memory-region*s* as an alternative
> > > > >>> name for memory-region to make the naming more consistent with other
> > > > >>> types of properties (think clocks, resets, gpios, ...). If we added
> > > > >>> that, we could easily differentiate between the "legacy" cases where
> > > > >>> no #memory-region-cells was allowed and the new cases where it was.
> > > > >>>
> > > > >>>> Second, it could be the bootloader setting up the reserved region. 
> > > > >>>> If a
> > > > >>>> node already has 'memory-region', then adding more regions is more
> > > > >>>> complicated compared to adding new properties. And defining what 
> > > > >>>> each
> > > > >>>> memory-region entry is or how many in schemas is impossible.
> > > > >>>
> > > > >>> It's true that updating the property gets a bit complicated, but 
> > > > >>> it's
> > > > >>> not exactly rocket science. We really just need to splice the 
> > > > >>> array. I
> &g

Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier

2021-09-03 Thread Rob Herring
On Wed, Sep 1, 2021 at 9:13 AM Thierry Reding  wrote:
>
> On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote:
> > 01.07.2021 21:14, Thierry Reding пишет:
> > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote:
> > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote:
> > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote:
> > >>>> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote:
> > >>>>> From: Thierry Reding 
> > >>>>>
> > >>>>> Reserved memory region phandle references can be accompanied by a
> > >>>>> specifier that provides additional information about how that specific
> > >>>>> reference should be treated.
> > >>>>>
> > >>>>> One use-case is to mark a memory region as needing an identity mapping
> > >>>>> in the system's IOMMU for the device that references the region. This 
> > >>>>> is
> > >>>>> needed for example when the bootloader has set up hardware (such as a
> > >>>>> display controller) to actively access a memory region (e.g. a boot
> > >>>>> splash screen framebuffer) during boot. The operating system can use 
> > >>>>> the
> > >>>>> identity mapping flag from the specifier to make sure an IOMMU 
> > >>>>> identity
> > >>>>> mapping is set up for the framebuffer before IOMMU translations are
> > >>>>> enabled for the display controller.
> > >>>>>
> > >>>>> Signed-off-by: Thierry Reding 
> > >>>>> ---
> > >>>>>  .../reserved-memory/reserved-memory.txt   | 21 
> > >>>>> +++
> > >>>>>  include/dt-bindings/reserved-memory.h |  8 +++
> > >>>>>  2 files changed, 29 insertions(+)
> > >>>>>  create mode 100644 include/dt-bindings/reserved-memory.h
> > >>>>
> > >>>> Sorry for being slow on this. I have 2 concerns.
> > >>>>
> > >>>> First, this creates an ABI issue. A DT with cells in 'memory-region'
> > >>>> will not be understood by an existing OS. I'm less concerned about this
> > >>>> if we address that with a stable fix. (Though I'm pretty sure we've
> > >>>> naively added #?-cells in the past ignoring this issue.)
> > >>>
> > >>> A while ago I had proposed adding memory-region*s* as an alternative
> > >>> name for memory-region to make the naming more consistent with other
> > >>> types of properties (think clocks, resets, gpios, ...). If we added
> > >>> that, we could easily differentiate between the "legacy" cases where
> > >>> no #memory-region-cells was allowed and the new cases where it was.
> > >>>
> > >>>> Second, it could be the bootloader setting up the reserved region. If a
> > >>>> node already has 'memory-region', then adding more regions is more
> > >>>> complicated compared to adding new properties. And defining what each
> > >>>> memory-region entry is or how many in schemas is impossible.
> > >>>
> > >>> It's true that updating the property gets a bit complicated, but it's
> > >>> not exactly rocket science. We really just need to splice the array. I
> > >>> have a working implemention for this in U-Boot.
> > >>>
> > >>> For what it's worth, we could run into the same issue with any new
> > >>> property that we add. Even if we renamed this to iommu-memory-region,
> > >>> it's still possible that a bootloader may have to update this property
> > >>> if it already exists (it could be hard-coded in DT, or it could have
> > >>> been added by some earlier bootloader or firmware).
> > >>>
> > >>>> Both could be addressed with a new property. Perhaps something like
> > >>>> 'iommu-memory-region = <>;'. I think the 'iommu' prefix is
> > >>>> appropriate given this is entirely because of the IOMMU being in the
> > >>>> mix. I might feel differently if we had other uses for cells, but I
> > >>>> don't really see it in this case.
> > >>>
> > >>> I'm afraid that down the road we'll end up with other cases and then w

Re: [PATCH 1/2] dt-bindings: arm-smmu: Add compatible for SM6350 SoC

2021-08-24 Thread Rob Herring
On Fri, 20 Aug 2021 22:29:04 +0200, Konrad Dybcio wrote:
> Add the SoC specific compatible for SM6350 implementing
> arm,mmu-500.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 02/29] dt-bindings: mediatek: mt8195: Add binding for infra IOMMU

2021-08-17 Thread Rob Herring
On Fri, 13 Aug 2021 14:52:57 +0800, Yong Wu wrote:
> In mt8195, we have a new IOMMU that is for INFRA IOMMU. its masters
> mainly are PCIe and USB. Different with MM IOMMU, all these masters
> connect with IOMMU directly, there is no mediatek,larbs property for
> infra IOMMU.
> 
> Another thing is about PCIe ports. currently the function
> "of_iommu_configure_dev_id" only support the id number is 1, But our
> PCIe have two ports, one is for reading and the other is for writing.
> see more about the PCIe patch in this patchset. Thus, I only list
> the reading id here and add the other id in our driver.
> 
> Signed-off-by: Yong Wu 
> Acked-by: Krzysztof Kozlowski 
> ---
> Change note: use "contains" commented from Rob.
> ---
>  .../bindings/iommu/mediatek,iommu.yaml | 13 -
>  .../dt-bindings/memory/mt8195-memory-port.h| 18 ++
>  include/dt-bindings/memory/mtk-memory-port.h   |  2 ++
>  3 files changed, 32 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 02/13] dt-bindings: memory: mediatek: Add mt8195 smi sub common

2021-08-17 Thread Rob Herring
On Tue, Aug 10, 2021 at 04:08:48PM +0800, Yong Wu wrote:
> Add the binding for smi-sub-common. The SMI block diagram like this:
> 
> IOMMU
>  |  |
>   smi-common
>   --
>   |    |
>  larb0   larb7   <-max is 8
> 
> The smi-common connects with smi-larb and IOMMU. The maximum larbs number
> that connects with a smi-common is 8. If the engines number is over 8,
> sometimes we use a smi-sub-common which is nearly same with smi-common.
> It supports up to 8 input and 1 output(smi-common has 2 output)
> 
> Something like:
> 
> IOMMU
>  |  |
>   smi-common
>   -
>   |  |  ...
> larb0  sub-common   ...   <-max is 8
>   ---
>||...   <-max is 8 too.
>  larb2 larb5
> 
> We don't need extra SW setting for smi-sub-common, only the sub-common has
> special clocks need to enable when the engines access dram.
> 
> If it is sub-common, it should have a "mediatek,smi" phandle to point to
> its smi-common. meanwhile the sub-common only has one gals clock.
> 
> Additionally, add a new property "mediatek,smi_sub_common" for this
> sub-common, this is needed in the IOMMU driver in which we create a device
> link between smi-common and the IOMMU device. If we add the smi-sub-common
> here, the IOMMU driver still need to find the smi-common device. thus,
> add this bool property to indicate if it is sub-common.
> 
> Signed-off-by: Yong Wu 
> ---
> change note:
> a. change mediatek, smi type from phandle-array to phandle from Rob.
> b. Add a new bool property (mediatek,smi_sub_common) to indicate this is
>smi-sub-common. the reason is as above.
> ---
>  .../mediatek,smi-common.yaml  | 30 +++
>  1 file changed, 30 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> index 602592b6c3f5..26bb9903864b 100644
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> @@ -38,6 +38,7 @@ properties:
>- mediatek,mt8192-smi-common
>- mediatek,mt8195-smi-common-vdo
>- mediatek,mt8195-smi-common-vpp
> +  - mediatek,mt8195-smi-sub-common
>  
>- description: for mt7623
>  items:
> @@ -67,6 +68,14 @@ properties:
>  minItems: 2
>  maxItems: 4
>  
> +  mediatek,smi:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: a phandle to the smi-common node above. Only for sub-common.
> +
> +  mediatek,smi_sub_common:

s/_/-/

> +type: boolean
> +description: Indicate if this is smi-sub-common.
> +
>  required:
>- compatible
>- reg
> @@ -93,6 +102,27 @@ allOf:
>  - const: smi
>  - const: async
>  
> +  - if:  # only for sub common
> +  properties:
> +compatible:
> +  contains:
> +enum:
> +  - mediatek,mt8195-smi-sub-common
> +then:
> +  required:
> +- mediatek,smi
> +- mediatek,smi_sub_common
> +  properties:
> +clock:
> +  items:
> +minItems: 3
> +maxItems: 3
> +clock-names:
> +  items:
> +- const: apb
> +- const: smi
> +- const: gals0

If not allowed for other compatibles, you need:

else:
  properties:
mediatek,sni: false
mediatek,smi_sub_common: false


> +
>- if:  # for gen2 HW that have gals
>properties:
>  compatible:
> -- 
> 2.18.0
> 
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 0/2] Don't fail device probing due to of_dma_set_restricted_buffer()

2021-08-16 Thread Rob Herring
On Mon, Aug 16, 2021 at 8:26 AM Will Deacon  wrote:
>
> Hi all,
>
> This is v2 of the patch I previously posted here:
>
>   https://lore.kernel.org/r/20210805094736.902-1-w...@kernel.org
>
> Changes since v1 are:
>
>   * Move of_dma_set_restricted_buffer() into of/device.c (Rob)
>   * Use IS_ENABLED() instead of 'static inline' stub (Rob)
>
> This applies on Konrad's devel/for-linus-5.15 branch in swiotlb.git
>
> Cheers,
>
> Will
>
> Cc: Claire Chang 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Christoph Hellwig 
> Cc: Rob Herring 
> Cc: Robin Murphy 
>
> --->8
>
> Will Deacon (2):
>   of: Move of_dma_set_restricted_buffer() into device.c
>   of: restricted dma: Don't fail device probe on rmem init failure
>
>  drivers/of/address.c| 33 -
>  drivers/of/device.c | 39 ++-
>  drivers/of/of_private.h |  7 ---
>  3 files changed, 38 insertions(+), 41 deletions(-)

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] of: restricted dma: Don't fail device probe on rmem init failure

2021-08-06 Thread Rob Herring
On Thu, Aug 5, 2021 at 3:47 AM Will Deacon  wrote:
>
> If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference
> to a "restricted-dma-pool" will fail with a reasonably cryptic error:

I'm left wondering why of_dma_set_restricted_buffer() is even enabled
with CONFIG_DMA_RESTRICTED_POOL=n.

of_dma_set_restricted_buffer() should use IS_ENABLED and it should
also be moved to of/device.c. There's no reason for it to be in
of/address.c. It has nothing to do with address parsing.

>   | pci-host-generic: probe of 1.pci failed with error -22
>
> Print a more helpful message in this case and try to continue probing
> the device as we do if the kernel doesn't have the restricted DMA patches
> applied or either CONFIG_OF_ADDRESS or CONFIG_HAS_DMA =n.

I think you'd have to work pretty hard to hit this code path with
either of the above config options off.

> Cc: Claire Chang 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Robin Murphy 
> Cc: Christoph Hellwig 
> Cc: Rob Herring 
> Signed-off-by: Will Deacon 
> ---
>  drivers/of/address.c| 8 
>  drivers/of/device.c | 2 +-
>  drivers/of/of_private.h | 8 +++-
>  3 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 973257434398..f6bf4b423c2a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -997,7 +997,7 @@ int of_dma_get_range(struct device_node *np, const struct 
> bus_dma_region **map)
> return ret;
>  }
>
> -int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
> +void of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
>  {
> struct device_node *node, *of_node = dev->of_node;
> int count, i;
> @@ -1022,11 +1022,11 @@ int of_dma_set_restricted_buffer(struct device *dev, 
> struct device_node *np)
>  */
> if (of_device_is_compatible(node, "restricted-dma-pool") &&
> of_device_is_available(node))
> -   return of_reserved_mem_device_init_by_idx(dev, 
> of_node,
> - i);
> +   break;
> }
>
> -   return 0;
> +   if (i != count && of_reserved_mem_device_init_by_idx(dev, of_node, i))
> +   dev_warn(dev, "failed to initialise \"restricted-dma-pool\" 
> memory node\n");
>  }
>  #endif /* CONFIG_HAS_DMA */
>
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 2defdca418ec..258a2b099410 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -166,7 +166,7 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
> arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>
> if (!iommu)
> -   return of_dma_set_restricted_buffer(dev, np);
> +   of_dma_set_restricted_buffer(dev, np);
>
> return 0;
>  }
> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
> index f557bd22b0cf..bc883f69496b 100644
> --- a/drivers/of/of_private.h
> +++ b/drivers/of/of_private.h
> @@ -163,18 +163,16 @@ struct bus_dma_region;
>  #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
>  int of_dma_get_range(struct device_node *np,
> const struct bus_dma_region **map);
> -int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np);
> +void of_dma_set_restricted_buffer(struct device *dev, struct device_node 
> *np);
>  #else
>  static inline int of_dma_get_range(struct device_node *np,
> const struct bus_dma_region **map)
>  {
> return -ENODEV;
>  }
> -static inline int of_dma_set_restricted_buffer(struct device *dev,
> -  struct device_node *np)
> +static inline void of_dma_set_restricted_buffer(struct device *dev,
> +   struct device_node *np)
>  {
> -   /* Do nothing, successfully. */
> -   return 0;
>  }
>  #endif
>
> --
> 2.32.0.605.g8dce9f2422-goog
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC 3/5] dma-mapping: Enable global non-coherent pool support for RISC-V

2021-07-25 Thread Rob Herring
On Fri, Jul 23, 2021 at 3:40 PM Atish Patra  wrote:
>
> Currently, linux,dma-default is used to reserve a global non-coherent pool
> to allocate memory for dma operations. This can be useful for RISC-V as
> well as the ISA specification doesn't specify a method to modify PMA
> attributes or page table entries to define non-cacheable area yet.
> A non-cacheable memory window is an alternate options for vendors to
> support non-coherent devices. "dma-ranges" must be used in conjunction with
> "linux,dma-default" property to define one or more mappings between device
> and cpu accesible memory regions.

'dma-ranges' applies to buses. And, well, maybe devices when the bus
is not well defined. It is not a reserved-memory property.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 02/11] dt-bindings: memory: mediatek: Add mt8195 smi sub common

2021-07-21 Thread Rob Herring
On Thu, Jul 15, 2021 at 08:12:00PM +0800, Yong Wu wrote:
> Add the binding for smi-sub-common. The SMI block diagram like this:
> 
> IOMMU
>  |  |
>   smi-common
>   --
>   |    |
>  larb0   larb7   <-max is 8
> 
> The smi-common connects with smi-larb and IOMMU. The maximum larbs number
> that connects with a smi-common is 8. If the engines number is over 8,
> sometimes we use a smi-sub-common which is nearly same with smi-common.
> It supports up to 8 input and 1 output(smi-common has 2 output)
> 
> Something like:
> 
> IOMMU
>  |  |
>   smi-common
>   -
>   |  |  ...
> larb0  sub-common   ...   <-max is 8
>   ---
>||...   <-max is 8 too.
>  larb2 larb5
> 
> We don't need extra SW setting for smi-sub-common, only the sub-common has
> special clocks need to enable when the engines access dram.
> 
> If it is sub-common, it should have a "mediatek,smi" phandle to point to
> its smi-common. meanwhile, the sub-common only has one gals clock.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.yaml  | 25 +++
>  1 file changed, 25 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> index 602592b6c3f5..f79d99ebc440 100644
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> @@ -38,6 +38,7 @@ properties:
>- mediatek,mt8192-smi-common
>- mediatek,mt8195-smi-common-vdo
>- mediatek,mt8195-smi-common-vpp
> +  - mediatek,mt8195-smi-sub-common
>  
>- description: for mt7623
>  items:
> @@ -67,6 +68,10 @@ properties:
>  minItems: 2
>  maxItems: 4
>  
> +  mediatek,smi:
> +$ref: /schemas/types.yaml#/definitions/phandle-array

If only a phandle, then s/phandle-array/phandle/

> +description: a phandle to the smi-common node above. Only for sub-common.
> +
>  required:
>- compatible
>- reg
> @@ -93,6 +98,26 @@ allOf:
>  - const: smi
>  - const: async
>  
> +  - if:  # only for sub common
> +  properties:
> +compatible:
> +  contains:
> +enum:
> +  - mediatek,mt8195-smi-sub-common
> +then:
> +  required:
> +- mediatek,smi
> +  properties:
> +clock:
> +  items:
> +minItems: 3
> +maxItems: 3
> +clock-names:
> +  items:
> +- const: apb
> +- const: smi
> +- const: gals0
> +
>- if:  # for gen2 HW that have gals
>properties:
>  compatible:
> -- 
> 2.18.0
> 
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 01/11] dt-bindings: memory: mediatek: Add mt8195 smi binding

2021-07-21 Thread Rob Herring
On Thu, 15 Jul 2021 20:11:59 +0800, Yong Wu wrote:
> Add mt8195 smi supporting in the bindings.
> 
> In mt8195, there are two smi-common HW, one is for vdo(video output),
> the other is for vpp(video processing pipe). They connect with different
> smi-larbs, then some setting(bus_sel) is different. Differentiate them
> with the compatible string.
> 
> Something like this:
> 
> IOMMU(VDO)  IOMMU(VPP)
>|   |
>  SMI_COMMON_VDO  SMI_COMMON_VPP
>   
>   |  |   ...  |  | ...
> larb0 larb2  ...larb1 larb3...
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/memory-controllers/mediatek,smi-common.yaml| 6 +-
>  .../bindings/memory-controllers/mediatek,smi-larb.yaml  | 3 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 2/5] iommu: Implement of_iommu_get_resv_regions()

2021-07-16 Thread Rob Herring
On Fri, Jul 2, 2021 at 8:05 AM Dmitry Osipenko  wrote:
>
> 23.04.2021 19:32, Thierry Reding пишет:
> > +void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
> > +{
> > + struct of_phandle_iterator it;
> > + int err;
> > +
> > + of_for_each_phandle(, err, dev->of_node, "memory-region", 
> > "#memory-region-cells", 0) {
> > + struct iommu_resv_region *region;
> > + struct of_phandle_args args;
> > + struct resource res;
> > +
> > + args.args_count = of_phandle_iterator_args(, args.args, 
> > MAX_PHANDLE_ARGS);
> > +
> > + err = of_address_to_resource(it.node, 0, );
> > + if (err < 0) {
> > + dev_err(dev, "failed to parse memory region %pOF: 
> > %d\n",
> > + it.node, err);
> > + continue;
> > + }
> > +
> > + if (args.args_count > 0) {
> > + /*
> > +  * Active memory regions are expected to be accessed 
> > by hardware during
> > +  * boot and must therefore have an identity mapping 
> > created prior to the
> > +  * driver taking control of the hardware. This 
> > ensures that non-quiescent
> > +  * hardware doesn't cause IOMMU faults during boot.
> > +  */
> > + if (args.args[0] & MEMORY_REGION_IDENTITY_MAPPING) {
> > + region = iommu_alloc_resv_region(res.start, 
> > resource_size(),
> > +  IOMMU_READ | 
> > IOMMU_WRITE,
> > +  
> > IOMMU_RESV_DIRECT_RELAXABLE);
> > + if (!region)
> > + continue;
> > +
> > + list_add_tail(>list, list);
> > + }
> > + }
> > + }
> > +}
> > +EXPORT_SYMBOL(of_iommu_get_resv_regions);
>
> Any reason why this is not EXPORT_SYMBOL_GPL? I'm curious what is the
> logic behind the OF symbols in general since it looks like half of them
> are GPL.

Generally, new ones are _GPL. Old ones probably predate _GPL.

This one is up to the IOMMU maintainers.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 02/24] dt-bindings: mediatek: mt8195: Add binding for infra IOMMU

2021-07-14 Thread Rob Herring
On Wed, Jun 30, 2021 at 10:34:42AM +0800, Yong Wu wrote:
> In mt8195, we have a new IOMMU that is for INFRA IOMMU. its masters
> mainly are PCIe and USB. Different with MM IOMMU, all these masters
> connect with IOMMU directly, there is no mediatek,larbs property for
> infra IOMMU.
> 
> Another thing is about PCIe ports. currently the function
> "of_iommu_configure_dev_id" only support the id number is 1, But our
> PCIe have two ports, one is for reading and the other is for writing.
> see more about the PCIe patch in this patchset. Thus, I only list
> the reading id here and add the other id in our driver.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml | 14 +-
>  .../dt-bindings/memory/mt8195-memory-port.h| 18 ++
>  include/dt-bindings/memory/mtk-memory-port.h   |  2 ++
>  3 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml 
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> index 9b04630158c8..6f3ff631c06b 100644
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> @@ -79,6 +79,7 @@ properties:
>- mediatek,mt8192-m4u  # generation two
>- mediatek,mt8195-iommu-vdo# generation two
>- mediatek,mt8195-iommu-vpp# generation two
> +  - mediatek,mt8195-iommu-infra  # generation two
>  
>- description: mt7623 generation one
>  items:
> @@ -129,7 +130,6 @@ required:
>- compatible
>- reg
>- interrupts
> -  - mediatek,larbs
>- '#iommu-cells'
>  
>  allOf:
> @@ -161,6 +161,18 @@ allOf:
>required:
>  - power-domains
>  
> +  - if:
> +  not:
> +properties:
> +  compatible:
> +items:
> +  enum:
> +- mediatek,mt8195-iommu-infra

This is saying all items are 'mediatek,mt8195-iommu-infra'. Other 
schemas prevent that, but really this should be:

compatible:
  contains:
const: mediatek,mt8195-iommu-infra

> +
> +then:
> +  required:
> +- mediatek,larbs
> +
>  additionalProperties: false
>  
>  examples:
> diff --git a/include/dt-bindings/memory/mt8195-memory-port.h 
> b/include/dt-bindings/memory/mt8195-memory-port.h
> index 783bcae8cdea..67afad848725 100644
> --- a/include/dt-bindings/memory/mt8195-memory-port.h
> +++ b/include/dt-bindings/memory/mt8195-memory-port.h
> @@ -387,4 +387,22 @@
>  #define M4U_PORT_L28_CAM_DRZS4NO_R1  MTK_M4U_ID(28, 5)
>  #define M4U_PORT_L28_CAM_TNCSO_R1MTK_M4U_ID(28, 6)
>  
> +/* infra iommu ports */
> +/* PCIe1: read: BIT16; write BIT17. */
> +#define M4U_PORT_INFRA_PCIE1 MTK_IFAIOMMU_PERI_ID(16)
> +/* PCIe0: read: BIT18; write BIT19. */
> +#define M4U_PORT_INFRA_PCIE0 MTK_IFAIOMMU_PERI_ID(18)
> +#define M4U_PORT_INFRA_SSUSB_P3_RMTK_IFAIOMMU_PERI_ID(20)
> +#define M4U_PORT_INFRA_SSUSB_P3_WMTK_IFAIOMMU_PERI_ID(21)
> +#define M4U_PORT_INFRA_SSUSB_P2_RMTK_IFAIOMMU_PERI_ID(22)
> +#define M4U_PORT_INFRA_SSUSB_P2_WMTK_IFAIOMMU_PERI_ID(23)
> +#define M4U_PORT_INFRA_SSUSB_P1_1_R  MTK_IFAIOMMU_PERI_ID(24)
> +#define M4U_PORT_INFRA_SSUSB_P1_1_W  MTK_IFAIOMMU_PERI_ID(25)
> +#define M4U_PORT_INFRA_SSUSB_P1_0_R  MTK_IFAIOMMU_PERI_ID(26)
> +#define M4U_PORT_INFRA_SSUSB_P1_0_W  MTK_IFAIOMMU_PERI_ID(27)
> +#define M4U_PORT_INFRA_SSUSB2_R  MTK_IFAIOMMU_PERI_ID(28)
> +#define M4U_PORT_INFRA_SSUSB2_W  MTK_IFAIOMMU_PERI_ID(29)
> +#define M4U_PORT_INFRA_SSUSB_R   MTK_IFAIOMMU_PERI_ID(30)
> +#define M4U_PORT_INFRA_SSUSB_W   MTK_IFAIOMMU_PERI_ID(31)
> +
>  #endif
> diff --git a/include/dt-bindings/memory/mtk-memory-port.h 
> b/include/dt-bindings/memory/mtk-memory-port.h
> index 7d64103209af..2f68a0511a25 100644
> --- a/include/dt-bindings/memory/mtk-memory-port.h
> +++ b/include/dt-bindings/memory/mtk-memory-port.h
> @@ -12,4 +12,6 @@
>  #define MTK_M4U_TO_LARB(id)  (((id) >> 5) & 0x1f)
>  #define MTK_M4U_TO_PORT(id)  ((id) & 0x1f)
>  
> +#define MTK_IFAIOMMU_PERI_ID(port)   MTK_M4U_ID(0, port)
> +
>  #endif
> -- 
> 2.18.0
> 
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 01/24] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU

2021-07-14 Thread Rob Herring
On Wed, 30 Jun 2021 10:34:41 +0800, Yong Wu wrote:
> This patch adds descriptions for mt8195 IOMMU which also use ARM
> Short-Descriptor translation table format.
> 
> In mt8195, there are two smi-common HW and IOMMU, one is for vdo(video
> output), the other is for vpp(video processing pipe). They connects
> with different smi-larbs, then some setting(larbid_remap) is different.
> Differentiate them with the compatible string.
> 
> Something like this:
> 
> IOMMU(VDO)  IOMMU(VPP)
>|   |
>   SMI_COMMON_VDO  SMI_COMMON_VPP
>   --- 
>   |  |   ...  |  | ...
> larb0 larb2  ...larb1 larb3...
> 
> Another change is that we have a new IOMMU that is for infra master like
> PCIe and USB. The infra master don't have the larb and ports, thus we
> rename the port header file to mt8195-memory-port.h rather than
> mt8195-larb-port.h.
> 
> Also, the IOMMU is not only for MM, thus, we don't call it "m4u" which
> means "MultiMedia Memory Management UNIT". thus, use the "iommu" as the
> compatiable string.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml|   7 +
>  .../dt-bindings/memory/mt8195-memory-port.h   | 390 ++
>  2 files changed, 397 insertions(+)
>  create mode 100644 include/dt-bindings/memory/mt8195-memory-port.h
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] dt-bindings: More dropping redundant minItems/maxItems

2021-07-13 Thread Rob Herring
Another round of removing redundant minItems/maxItems from new schema in
the recent merge window.

If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
same size as the list is redundant and can be dropped. Note that is DT
schema specific behavior and not standard json-schema behavior. The tooling
will fixup the final schema adding any unspecified minItems/maxItems.

This condition is partially checked with the meta-schema already, but
only if both 'minItems' and 'maxItems' are equal to the 'items' length.
An improved meta-schema is pending.

Cc: Stephen Boyd 
Cc: Joerg Roedel 
Cc: Will Deacon 
Cc: Krzysztof Kozlowski 
Cc: Miquel Raynal 
Cc: Richard Weinberger 
Cc: Vignesh Raghavendra 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Greg Kroah-Hartman 
Cc: Sureshkumar Relli 
Cc: Brian Norris 
Cc: Kamal Dasu 
Cc: Linus Walleij 
Cc: Sebastian Siewior 
Cc: Laurent Pinchart 
Cc: linux-...@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: linux-...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 .../devicetree/bindings/clock/brcm,iproc-clocks.yaml  | 1 -
 .../devicetree/bindings/iommu/rockchip,iommu.yaml | 2 --
 .../bindings/memory-controllers/arm,pl353-smc.yaml| 1 -
 Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml  | 8 
 .../devicetree/bindings/rtc/faraday,ftrtc010.yaml | 1 -
 Documentation/devicetree/bindings/usb/nxp,isp1760.yaml| 2 --
 6 files changed, 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml 
b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml
index 8dc7b404ee12..1174c9aa9934 100644
--- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml
@@ -50,7 +50,6 @@ properties:
 
   reg:
 minItems: 1
-maxItems: 3
 items:
   - description: base register
   - description: power register
diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml 
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
index d2e28a9e3545..ba9124f721f1 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -28,14 +28,12 @@ properties:
   - description: configuration registers for MMU instance 0
   - description: configuration registers for MMU instance 1
 minItems: 1
-maxItems: 2
 
   interrupts:
 items:
   - description: interruption for MMU instance 0
   - description: interruption for MMU instance 1
 minItems: 1
-maxItems: 2
 
   clocks:
 items:
diff --git 
a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
index 7a63c85ef8c5..01c9acf9275d 100644
--- a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
@@ -57,7 +57,6 @@ properties:
 
   ranges:
 minItems: 1
-maxItems: 3
 description: |
   Memory bus areas for interacting with the devices. Reflects
   the memory layout with four integer values following:
diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml 
b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
index e5f1a2a5..dd5a64969e37 100644
--- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
+++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
@@ -84,7 +84,6 @@ properties:
 
   interrupts:
 minItems: 1
-maxItems: 3
 items:
   - description: NAND CTLRDY interrupt
   - description: FLASH_DMA_DONE if flash DMA is available
@@ -92,7 +91,6 @@ properties:
 
   interrupt-names:
 minItems: 1
-maxItems: 3
 items:
   - const: nand_ctlrdy
   - const: flash_dma_done
@@ -148,8 +146,6 @@ allOf:
 then:
   properties:
 reg-names:
-  minItems: 2
-  maxItems: 2
   items:
 - const: nand
 - const: nand-int-base
@@ -161,8 +157,6 @@ allOf:
 then:
   properties:
 reg-names:
-  minItems: 3
-  maxItems: 3
   items:
 - const: nand
 - const: nand-int-base
@@ -175,8 +169,6 @@ allOf:
 then:
   properties:
 reg-names:
-  minItems: 3
-  maxItems: 3
   items:
 - const: nand
 - const: iproc-idm
diff --git a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml 
b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml
index 657c13b62b67..056d42daae06 100644
--- a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml
+++ b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml
@@ -30,7 +30,6 @@ properties:
 maxItems: 1
 
   clocks:
-minItems: 2
 items:
   - description: PCLK clocks

Re: [PATCH] dt-bindings: arm-smmu: Fix json-schema syntax

2021-07-12 Thread Rob Herring
On Tue, Jun 22, 2021 at 11:56 PM Krzysztof Kozlowski
 wrote:
>
> On Mon, 21 Jun 2021 16:00:36 +0200, Thierry Reding wrote:
> > Commit 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible
> > string") introduced a jsonschema syntax error as a result of a rebase
> > gone wrong. Fix it.
>
> Applied, thanks!
>
> [1/1] dt-bindings: arm-smmu: Fix json-schema syntax
>   commit: bf3ec9deaa33889630722c47f7bb86ba58872ea7

Applied where? Now Linus's master is broken.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH V3 1/2] dt-bindings: iommu: arm-smmu: Add binding for sm6125

2021-06-24 Thread Rob Herring
On Sat, 12 Jun 2021 11:46:04 +0200, Martin Botka wrote:
> This patch adds binding for sm6125 SoC
> 
> Signed-off-by: Martin Botka 
> ---
> Changes in V2:
> Add commit description
> Changes in V3:
> None
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

2021-06-23 Thread Rob Herring
On Tue, Jun 22, 2021 at 2:10 PM Doug Anderson  wrote:
>
> Hi,
>
> On Tue, Jun 22, 2021 at 1:06 PM Saravana Kannan  wrote:
> >
> > On Tue, Jun 22, 2021 at 1:02 PM Rob Herring  wrote:
> > >
> > > On Tue, Jun 22, 2021 at 09:06:02AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Tue, Jun 22, 2021 at 4:35 AM Robin Murphy  
> > > > wrote:
> > > > >
> > > > > Hi Doug,
> > > > >
> > > > > On 2021-06-22 00:52, Douglas Anderson wrote:
> > > > > >
> > > > > > This patch attempts to put forward a proposal for enabling 
> > > > > > non-strict
> > > > > > DMA on a device-by-device basis. The patch series requests 
> > > > > > non-strict
> > > > > > DMA for the Qualcomm SDHCI controller as a first device to enable,
> > > > > > getting a nice bump in performance with what's believed to be a very
> > > > > > small drop in security / safety (see the patch for the full 
> > > > > > argument).
> > > > > >
> > > > > > As part of this patch series I am end up slightly cleaning up some 
> > > > > > of
> > > > > > the interactions between the PCI subsystem and the IOMMU subsystem 
> > > > > > but
> > > > > > I don't go all the way to fully remove all the tentacles. 
> > > > > > Specifically
> > > > > > this patch series only concerns itself with a single aspect: strict
> > > > > > vs. non-strict mode for the IOMMU. I'm hoping that this will be 
> > > > > > easier
> > > > > > to talk about / reason about for more subsystems compared to overall
> > > > > > deciding what it means for a device to be "external" or "untrusted".
> > > > > >
> > > > > > If something like this patch series ends up being landable, it will
> > > > > > undoubtedly need coordination between many maintainers to land. I
> > > > > > believe it's fully bisectable but later patches in the series
> > > > > > definitely depend on earlier ones. Sorry for the long CC list. :(
> > > > >
> > > > > Unfortunately, this doesn't work. In normal operation, the default
> > > > > domains should be established long before individual drivers are even
> > > > > loaded (if they are modules), let alone anywhere near probing. The 
> > > > > fact
> > > > > that iommu_probe_device() sometimes gets called far too late off the
> > > > > back of driver probe is an unfortunate artefact of the original
> > > > > probe-deferral scheme, and causes other problems like potentially
> > > > > malformed groups - I've been forming a plan to fix that for a while 
> > > > > now,
> > > > > so I for one really can't condone anything trying to rely on it.
> > > > > Non-deterministic behaviour based on driver probe order for 
> > > > > multi-device
> > > > > groups is part of the existing problem, and your proposal seems 
> > > > > equally
> > > > > vulnerable to that too.
> > > >
> > > > Doh! :( I definitely can't say I understand the iommu subsystem
> > > > amazingly well. It was working for me, but I could believe that I was
> > > > somehow violating a rule somewhere.
> > > >
> > > > I'm having a bit of a hard time understanding where the problem is
> > > > though. Is there any chance that you missed the part of my series
> > > > where I introduced a "pre_probe" step? Specifically, I see this:
> > > >
> > > > * really_probe() is called w/ a driver and a device.
> > > > * -> calls dev->bus->dma_configure() w/ a "struct device *"
> > > > * -> eventually calls iommu_probe_device() w/ the device.
> > > > * -> calls iommu_alloc_default_domain() w/ the device
> > > > * -> calls iommu_group_alloc_default_domain()
> > > > * -> always allocates a new domain
> > > >
> > > > ...so we always have a "struct device" when a domain is allocated if
> > > > that domain is going to be associated with a device.
> > > >
> > > > I will agree that iommu_probe_device() is called before the driver
> > > > probe, but unless I missed something it's after t

Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

2021-06-22 Thread Rob Herring
On Tue, Jun 22, 2021 at 09:06:02AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Tue, Jun 22, 2021 at 4:35 AM Robin Murphy  wrote:
> >
> > Hi Doug,
> >
> > On 2021-06-22 00:52, Douglas Anderson wrote:
> > >
> > > This patch attempts to put forward a proposal for enabling non-strict
> > > DMA on a device-by-device basis. The patch series requests non-strict
> > > DMA for the Qualcomm SDHCI controller as a first device to enable,
> > > getting a nice bump in performance with what's believed to be a very
> > > small drop in security / safety (see the patch for the full argument).
> > >
> > > As part of this patch series I am end up slightly cleaning up some of
> > > the interactions between the PCI subsystem and the IOMMU subsystem but
> > > I don't go all the way to fully remove all the tentacles. Specifically
> > > this patch series only concerns itself with a single aspect: strict
> > > vs. non-strict mode for the IOMMU. I'm hoping that this will be easier
> > > to talk about / reason about for more subsystems compared to overall
> > > deciding what it means for a device to be "external" or "untrusted".
> > >
> > > If something like this patch series ends up being landable, it will
> > > undoubtedly need coordination between many maintainers to land. I
> > > believe it's fully bisectable but later patches in the series
> > > definitely depend on earlier ones. Sorry for the long CC list. :(
> >
> > Unfortunately, this doesn't work. In normal operation, the default
> > domains should be established long before individual drivers are even
> > loaded (if they are modules), let alone anywhere near probing. The fact
> > that iommu_probe_device() sometimes gets called far too late off the
> > back of driver probe is an unfortunate artefact of the original
> > probe-deferral scheme, and causes other problems like potentially
> > malformed groups - I've been forming a plan to fix that for a while now,
> > so I for one really can't condone anything trying to rely on it.
> > Non-deterministic behaviour based on driver probe order for multi-device
> > groups is part of the existing problem, and your proposal seems equally
> > vulnerable to that too.
> 
> Doh! :( I definitely can't say I understand the iommu subsystem
> amazingly well. It was working for me, but I could believe that I was
> somehow violating a rule somewhere.
> 
> I'm having a bit of a hard time understanding where the problem is
> though. Is there any chance that you missed the part of my series
> where I introduced a "pre_probe" step? Specifically, I see this:
> 
> * really_probe() is called w/ a driver and a device.
> * -> calls dev->bus->dma_configure() w/ a "struct device *"
> * -> eventually calls iommu_probe_device() w/ the device.
> * -> calls iommu_alloc_default_domain() w/ the device
> * -> calls iommu_group_alloc_default_domain()
> * -> always allocates a new domain
> 
> ...so we always have a "struct device" when a domain is allocated if
> that domain is going to be associated with a device.
> 
> I will agree that iommu_probe_device() is called before the driver
> probe, but unless I missed something it's after the device driver is
> loaded.  ...and assuming something like patch #1 in this series looks
> OK then iommu_probe_device() will be called after "pre_probe".
> 
> So assuming I'm not missing something, I'm not actually relying the
> IOMMU getting init off the back of driver probe.
> 
> 
> > FWIW we already have a go-faster knob for people who want to tweak the
> > security/performance compromise for specific devices, namely the sysfs
> > interface for changing a group's domain type before binding the relevant
> > driver(s). Is that something you could use in your application, say from
> > an initramfs script?
> 
> We've never had an initramfs script in Chrome OS. I don't know all the
> history of why (I'm trying to check), but I'm nearly certain it was a
> conscious decision. Probably it has to do with the fact that we're not
> trying to build a generic distribution where a single boot source can
> boot a huge variety of hardware. We generally have one kernel for a
> class of devices. I believe avoiding the initramfs just keeps things
> simpler.
> 
> I think trying to revamp Chrome OS to switch to an initramfs type
> system would be a pretty big undertaking since (as I understand it)
> you can't just run a little command and then return to the normal boot
> flow. Once you switch to initramfs you're committing to finding /
> setting up the rootfs yourself and on Chrome OS I believe that means a
> whole bunch of dm-verity work.
> 
> 
> ...so probably the initramfs is a no-go for me, but I'm still crossing
> my fingers that the pre_probe() might be legit if you take a second
> look at it?

Couldn't you have a driver flag that has the same effect as twiddling 
sysfs? At the being of probe, check the flag and go set the underlying 
sysfs setting in the device.

Though you may want this to be per device, not per driver. To do that 
early, I 

Re: [PATCH] dt-bindings: arm-smmu: Fix json-schema syntax

2021-06-22 Thread Rob Herring
On Mon, Jun 21, 2021 at 7:58 AM Thierry Reding  wrote:
>
> From: Thierry Reding 
>
> Commit 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible
> string") introduced a jsonschema syntax error as a result of a rebase
> gone wrong. Fix it.
>
> Fixes: 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible string")
> Reported-by: Rob Herring 
> Signed-off-by: Thierry Reding 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

2021-06-22 Thread Rob Herring
On Tue, Jun 22, 2021 at 2:17 AM Geert Uytterhoeven  wrote:
>
> Hi Rob,
>
> On Tue, Jun 15, 2021 at 9:16 PM Rob Herring  wrote:
> > If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> > same size as the list is redundant and can be dropped. Note that is DT
> > schema specific behavior and not standard json-schema behavior. The tooling
> > will fixup the final schema adding any unspecified minItems/maxItems.
> >
> > This condition is partially checked with the meta-schema already, but
> > only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> > An improved meta-schema is pending.
>
> > Signed-off-by: Rob Herring 
>
> > --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> > @@ -46,7 +46,6 @@ properties:
> >
> >clocks:
> >  minItems: 3
> > -maxItems: 5
> >  items:
> >- description: GMAC main clock
> >- description: MAC TX clock
>
> While resolving the conflict with commit fea99822914039c6
> ("dt-bindings: net: document ptp_ref clk in dwmac") in soc/for-next,
> I noticed the following construct for clock-names:
>
>   clock-names:
> minItems: 3
> maxItems: 6
> contains:
>   enum:
> - stmmaceth
> - mac-clk-tx
> - mac-clk-rx
> - ethstp
> - eth-ck
> - ptp_ref
>
> Should this use items instead of enum, and drop maxItems, or is this
> a valid construct to support specifying the clocks in random order?
> If the latter, it does mean that the order of clock-names may not
> match the order of the clock descriptions.

'contains' is true if one or more entries match the strings. So it is
really saying one of these is required. That's not really much of a
constraint. There's 'minContains' and 'maxContains' in newer
json-schema versions (not yet supported) that could add some
constraints if there has to be at least N entries from contains. An
'items' schema (as opposed to a list) would say all items have to
match one of the strings. I'm sure that's too strict.

TLDR: clocks for this binding are a mess and the above is probably all
we can do here.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 2/9] dt-bindings: arm-smmu: Add Tegra186 compatible string

2021-06-18 Thread Rob Herring
On Thu, Jun 3, 2021 at 10:49 AM Thierry Reding  wrote:
>
> From: Thierry Reding 
>
> The ARM SMMU instantiations found on Tegra186 and later need inter-
> operation with the memory controller in order to correctly program
> stream ID overrides.
>
> Furthermore, on Tegra194 multiple instances of the SMMU can gang up
> to achieve higher throughput. In order to do this, they have to be
> programmed identically so that the memory controller can interleave
> memory accesses between them.
>
> Add the Tegra186 compatible string to make sure the interoperation
> with the memory controller can be enabled on that SoC generation.
>
> Signed-off-by: Thierry Reding 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 9d27aa5111d4..1181b590db71 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -54,8 +54,14 @@ properties:
>- const: arm,mmu-500
>- description: NVIDIA SoCs that program two ARM MMU-500s identically
>  items:
> +  - description: NVIDIA SoCs that require memory controller interaction

This is not valid jsonschema:

/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
must be fixed:
None is not of type 'object', 'boolean'
None is not of type 'array'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
must be fixed:
[{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
type 'object'
{'const': 'nvidia,tegra194-smmu'} is not of type 'string'
{'const': 'nvidia,tegra186-smmu'} is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#


This was not reviewed nor tested since the DT list was not Cc'ed.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

2021-06-17 Thread Rob Herring
On Thu, Jun 17, 2021 at 10:06 AM Suman Anna  wrote:
>
> Hi Rob,
>
> On 6/15/21 2:15 PM, Rob Herring wrote:
> > If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> > same size as the list is redundant and can be dropped. Note that is DT
> > schema specific behavior and not standard json-schema behavior. The tooling
> > will fixup the final schema adding any unspecified minItems/maxItems.
> >
> > This condition is partially checked with the meta-schema already, but
> > only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> > An improved meta-schema is pending.
> >
> > Cc: Jens Axboe 
> > Cc: Stephen Boyd 
> > Cc: Herbert Xu 
> > Cc: "David S. Miller" 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Vinod Koul 
> > Cc: Bartosz Golaszewski 
> > Cc: Kamal Dasu 
> > Cc: Jonathan Cameron 
> > Cc: Lars-Peter Clausen 
> > Cc: Thomas Gleixner 
> > Cc: Marc Zyngier 
> > Cc: Joerg Roedel 
> > Cc: Jassi Brar 
> > Cc: Mauro Carvalho Chehab 
> > Cc: Krzysztof Kozlowski 
> > Cc: Ulf Hansson 
> > Cc: Jakub Kicinski 
> > Cc: Wolfgang Grandegger 
> > Cc: Marc Kleine-Budde 
> > Cc: Andrew Lunn 
> > Cc: Vivien Didelot 
> > Cc: Vladimir Oltean 
> > Cc: Bjorn Helgaas 
> > Cc: Kishon Vijay Abraham I 
> > Cc: Linus Walleij 
> > Cc: "Uwe Kleine-König" 
> > Cc: Lee Jones 
> > Cc: Ohad Ben-Cohen 
> > Cc: Mathieu Poirier 
> > Cc: Philipp Zabel 
> > Cc: Paul Walmsley 
> > Cc: Palmer Dabbelt 
> > Cc: Albert Ou 
> > Cc: Alessandro Zummo 
> > Cc: Alexandre Belloni 
> > Cc: Greg Kroah-Hartman 
> > Cc: Mark Brown 
> > Cc: Zhang Rui 
> > Cc: Daniel Lezcano 
> > Cc: Wim Van Sebroeck 
> > Cc: Guenter Roeck 
> > Signed-off-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/ata/nvidia,tegra-ahci.yaml  | 1 -
> >  .../devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml  | 2 --
> >  .../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 1 -
> >  Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml | 2 --
> >  .../devicetree/bindings/clock/qcom,gcc-sm8350.yaml  | 2 --
> >  .../devicetree/bindings/clock/sprd,sc9863a-clk.yaml | 1 -
> >  .../devicetree/bindings/crypto/allwinner,sun8i-ce.yaml  | 2 --
> >  Documentation/devicetree/bindings/crypto/fsl-dcp.yaml   | 1 -
> >  .../display/allwinner,sun4i-a10-display-backend.yaml| 6 --
> >  .../bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml  | 1 -
> >  .../bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml  | 4 
> >  .../bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml | 2 --
> >  .../bindings/display/allwinner,sun8i-r40-tcon-top.yaml  | 2 --
> >  .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml   | 2 --
> >  .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 2 --
> >  Documentation/devicetree/bindings/display/st,stm32-dsi.yaml | 2 --
> >  .../devicetree/bindings/display/st,stm32-ltdc.yaml  | 1 -
> >  .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml | 4 
> >  .../devicetree/bindings/dma/renesas,rcar-dmac.yaml  | 1 -
> >  .../devicetree/bindings/edac/amazon,al-mc-edac.yaml | 2 --
> >  Documentation/devicetree/bindings/eeprom/at24.yaml  | 1 -
> >  Documentation/devicetree/bindings/example-schema.yaml   | 2 --
> >  Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 -
> >  Documentation/devicetree/bindings/gpu/vivante,gc.yaml   | 1 -
> >  Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml | 1 -
> >  .../devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml| 2 --
> >  .../devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml | 1 -
> >  .../devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml   | 1 -
> >  .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 2 --
> >  .../bindings/interrupt-controller/fsl,irqsteer.yaml | 1 -
> >  .../bindings/interrupt-controller/loongson,liointc.yaml | 1 -
> >  Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml| 1 -
> >  .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml   | 1 -
> >  .../devicetree/bindings/mailbox/st,stm32-ipcc.yaml  | 2 --
> >  .../devicetree/bindings/media/amlogic,gx-vdec.yaml  | 1 -
> >  Documentation/devicetree/bindings/media/i2c/adv7604.yaml| 1 -
> >  .../devicetree/bindings/media/marvell,mmp2-ccic.yaml| 1 -
> >  .../devicetree/bindings/media/qcom,sc7180-venus.yaml 

[PATCH] dt-bindings: Drop redundant minItems/maxItems

2021-06-15 Thread Rob Herring
If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
same size as the list is redundant and can be dropped. Note that is DT
schema specific behavior and not standard json-schema behavior. The tooling
will fixup the final schema adding any unspecified minItems/maxItems.

This condition is partially checked with the meta-schema already, but
only if both 'minItems' and 'maxItems' are equal to the 'items' length.
An improved meta-schema is pending.

Cc: Jens Axboe 
Cc: Stephen Boyd 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Vinod Koul 
Cc: Bartosz Golaszewski 
Cc: Kamal Dasu 
Cc: Jonathan Cameron 
Cc: Lars-Peter Clausen 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Joerg Roedel 
Cc: Jassi Brar 
Cc: Mauro Carvalho Chehab 
Cc: Krzysztof Kozlowski 
Cc: Ulf Hansson 
Cc: Jakub Kicinski 
Cc: Wolfgang Grandegger 
Cc: Marc Kleine-Budde 
Cc: Andrew Lunn 
Cc: Vivien Didelot 
Cc: Vladimir Oltean 
Cc: Bjorn Helgaas 
Cc: Kishon Vijay Abraham I 
Cc: Linus Walleij 
Cc: "Uwe Kleine-König" 
Cc: Lee Jones 
Cc: Ohad Ben-Cohen 
Cc: Mathieu Poirier 
Cc: Philipp Zabel 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Greg Kroah-Hartman 
Cc: Mark Brown 
Cc: Zhang Rui 
Cc: Daniel Lezcano 
Cc: Wim Van Sebroeck 
Cc: Guenter Roeck 
Signed-off-by: Rob Herring 
---
 .../devicetree/bindings/ata/nvidia,tegra-ahci.yaml  | 1 -
 .../devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml  | 2 --
 .../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 1 -
 Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml | 2 --
 .../devicetree/bindings/clock/qcom,gcc-sm8350.yaml  | 2 --
 .../devicetree/bindings/clock/sprd,sc9863a-clk.yaml | 1 -
 .../devicetree/bindings/crypto/allwinner,sun8i-ce.yaml  | 2 --
 Documentation/devicetree/bindings/crypto/fsl-dcp.yaml   | 1 -
 .../display/allwinner,sun4i-a10-display-backend.yaml| 6 --
 .../bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml  | 1 -
 .../bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml  | 4 
 .../bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml | 2 --
 .../bindings/display/allwinner,sun8i-r40-tcon-top.yaml  | 2 --
 .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml   | 2 --
 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 2 --
 Documentation/devicetree/bindings/display/st,stm32-dsi.yaml | 2 --
 .../devicetree/bindings/display/st,stm32-ltdc.yaml  | 1 -
 .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml | 4 
 .../devicetree/bindings/dma/renesas,rcar-dmac.yaml  | 1 -
 .../devicetree/bindings/edac/amazon,al-mc-edac.yaml | 2 --
 Documentation/devicetree/bindings/eeprom/at24.yaml  | 1 -
 Documentation/devicetree/bindings/example-schema.yaml   | 2 --
 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 -
 Documentation/devicetree/bindings/gpu/vivante,gc.yaml   | 1 -
 Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml | 1 -
 .../devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml| 2 --
 .../devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml | 1 -
 .../devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml   | 1 -
 .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 2 --
 .../bindings/interrupt-controller/fsl,irqsteer.yaml | 1 -
 .../bindings/interrupt-controller/loongson,liointc.yaml | 1 -
 Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml| 1 -
 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml   | 1 -
 .../devicetree/bindings/mailbox/st,stm32-ipcc.yaml  | 2 --
 .../devicetree/bindings/media/amlogic,gx-vdec.yaml  | 1 -
 Documentation/devicetree/bindings/media/i2c/adv7604.yaml| 1 -
 .../devicetree/bindings/media/marvell,mmp2-ccic.yaml| 1 -
 .../devicetree/bindings/media/qcom,sc7180-venus.yaml| 1 -
 .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 1 -
 .../devicetree/bindings/media/qcom,sm8250-venus.yaml| 1 -
 Documentation/devicetree/bindings/media/renesas,drif.yaml   | 1 -
 .../bindings/memory-controllers/mediatek,smi-common.yaml| 6 ++
 .../bindings/memory-controllers/mediatek,smi-larb.yaml  | 1 -
 .../devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml| 2 --
 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml| 1 -
 Documentation/devicetree/bindings/mmc/mtk-sd.yaml   | 2 --
 Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 2 --
 Documentation/devicetree/bindings/mmc/sdhci-am654.yaml  | 1 -
 Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml| 1 -
 .../devicetree/bindings/net/amlogic,meson-dwmac.yaml| 2 --
 .../devicetree/bindings/net/brcm,bcm4908-enet.yaml  | 2 --
 Documentation/devicetree/bindings/net/can/bosch,m_can.yaml  | 2 --
 Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml | 2 --
 Documentation/devicetr

Re: [PATCH v3 2/3] dt-bindings: iommu: add DART iommu bindings

2021-06-10 Thread Rob Herring
On Thu, Jun 03, 2021 at 10:50:02AM +0200, Sven Peter wrote:
> DART (Device Address Resolution Table) is the iommu found on Apple
> ARM SoCs such as the M1.
> 
> Signed-off-by: Sven Peter 
> ---
>  .../devicetree/bindings/iommu/apple,dart.yaml | 81 +++
>  MAINTAINERS   |  6 ++
>  2 files changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/apple,dart.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml 
> b/Documentation/devicetree/bindings/iommu/apple,dart.yaml
> new file mode 100644
> index ..db21ca07d121
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/apple,dart.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple DART IOMMU
> +
> +maintainers:
> +  - Sven Peter 
> +
> +description: |+
> +  Apple SoCs may contain an implementation of their Device Address
> +  Resolution Table which provides a mandatory layer of address
> +  translations for various masters.
> +
> +  Each DART instance is capable of handling up to 16 different streams
> +  with individual pagetables and page-level read/write protection flags.
> +
> +  This DART IOMMU also raises interrupts in response to various
> +  fault conditions.
> +
> +properties:
> +  compatible:
> +const: apple,t8103-dart
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  clocks:
> +description:
> +  Reference to the gate clock phandle if required for this IOMMU.
> +  Optional since not all IOMMUs are attached to a clock gate.
> +
> +  '#iommu-cells':
> +const: 1
> +description:
> +  Has to be one. The single cell describes the stream id emitted by
> +  a master to the IOMMU.
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#iommu-cells'
> +  - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> +  - |+
> +dart1: iommu@82f8 {
> +  compatible = "apple,t8103-dart";
> +  reg = <0x82f8 0x4000>;
> +  interrupts = <1 781 4>;
> +  #iommu-cells = <1>;
> +};
> +
> +master1 {
> +  iommus = <&{/dart1} 0>;

/dart1 is a path, but 'dart1' is a label. You need '' (or 
'&{/iommu@82f8}' but that doesn't really work here because the 
examples get prefixed with /example-n/...)

With that fixed,

Reviewed-by: Rob Herring 


> +};
> +
> +  - |+
> +dart2a: iommu@82f0 {
> +  compatible = "apple,t8103-dart";
> +  reg = <0x82f0 0x4000>;
> +  interrupts = <1 781 4>;
> +  #iommu-cells = <1>;
> +};
> +dart2b: iommu@82f8 {
> +  compatible = "apple,t8103-dart";
> +  reg = <0x82f8 0x4000>;
> +  interrupts = <1 781 4>;
> +  #iommu-cells = <1>;
> +};
> +
> +master2 {
> +  iommus = <&{/dart2a} 0>, <&{/dart2b} 1>;
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 673cadd5107a..4373d63f9ccf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1240,6 +1240,12 @@ L: linux-in...@vger.kernel.org
>  S:   Odd fixes
>  F:   drivers/input/mouse/bcm5974.c
>  
> +APPLE DART IOMMU DRIVER
> +M:   Sven Peter 
> +L:   iommu@lists.linux-foundation.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/iommu/apple,dart.yaml
> +
>  APPLE SMC DRIVER
>  M:   Henrik Rydberg 
>  L:   linux-hw...@vger.kernel.org
> -- 
> 2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 2/2] iommu: Drop unnecessary of_iommu.h includes

2021-05-27 Thread Rob Herring
The only place of_iommu.h is needed is in drivers/of/device.c. Remove it
from everywhere else.

Cc: Will Deacon 
Cc: Robin Murphy 
Cc: Joerg Roedel 
Cc: Rob Clark 
Cc: Marek Szyprowski 
Cc: Krzysztof Kozlowski 
Cc: Bjorn Andersson 
Cc: Yong Wu 
Cc: Matthias Brugger 
Cc: Heiko Stuebner 
Cc: Jean-Philippe Brucker 
Cc: Frank Rowand 
Cc: linux-arm-ker...@lists.infradead.org
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring 
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
 drivers/iommu/arm/arm-smmu/arm-smmu.c   | 1 -
 drivers/iommu/arm/arm-smmu/qcom_iommu.c | 1 -
 drivers/iommu/exynos-iommu.c| 1 -
 drivers/iommu/ipmmu-vmsa.c  | 1 -
 drivers/iommu/msm_iommu.c   | 1 -
 drivers/iommu/mtk_iommu.c   | 1 -
 drivers/iommu/mtk_iommu_v1.c| 1 -
 drivers/iommu/omap-iommu.c  | 1 -
 drivers/iommu/rockchip-iommu.c  | 1 -
 drivers/iommu/virtio-iommu.c| 1 -
 drivers/of/platform.c   | 1 -
 12 files changed, 12 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 54b2f27b81d4..2ddc3cd5a7d1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 6f72c4d208ca..dba15f312cbd 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c 
b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index 4294abe389b2..021cf8f65ffc 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 7623d8c371f5..d0fbf1d10e18 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index aaa6a4d59057..51ea6f00db2f 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 7880f307cb2d..3a38352b603f 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index e06b8a0e2b56..6f7c69688ce2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 5915d7b38211..778e66f5f1aa 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 26e517eb0dd3..91749654fd49 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 7a2932772fdf..bb50e015b1d5 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 7c02481a81b4..d9f46f2c3058 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 25d448f5af91..74afbb7a4f5e 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.27.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 1/2] iommu: Remove unused of_get_dma_window()

2021-05-27 Thread Rob Herring
of_get_dma_window() was added in 2012 and removed in 2014 in commit
891846516317 ("memory: Add NVIDIA Tegra memory controller support").
Remove it and simplify the header to use forward declarations for
structs rather than includes.

Cc: Joerg Roedel 
Cc: Will Deacon 
Cc: Frank Rowand 
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring 
---
 drivers/iommu/of_iommu.c | 68 
 include/linux/of_iommu.h | 17 ++
 2 files changed, 3 insertions(+), 82 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index a9d2df001149..5696314ae69e 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -19,74 +19,6 @@
 
 #define NO_IOMMU   1
 
-/**
- * of_get_dma_window - Parse *dma-window property and returns 0 if found.
- *
- * @dn: device node
- * @prefix: prefix for property name if any
- * @index: index to start to parse
- * @busno: Returns busno if supported. Otherwise pass NULL
- * @addr: Returns address that DMA starts
- * @size: Returns the range that DMA can handle
- *
- * This supports different formats flexibly. "prefix" can be
- * configured if any. "busno" and "index" are optionally
- * specified. Set 0(or NULL) if not used.
- */
-int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
- unsigned long *busno, dma_addr_t *addr, size_t *size)
-{
-   const __be32 *dma_window, *end;
-   int bytes, cur_index = 0;
-   char propname[NAME_MAX], addrname[NAME_MAX], sizename[NAME_MAX];
-
-   if (!dn || !addr || !size)
-   return -EINVAL;
-
-   if (!prefix)
-   prefix = "";
-
-   snprintf(propname, sizeof(propname), "%sdma-window", prefix);
-   snprintf(addrname, sizeof(addrname), "%s#dma-address-cells", prefix);
-   snprintf(sizename, sizeof(sizename), "%s#dma-size-cells", prefix);
-
-   dma_window = of_get_property(dn, propname, );
-   if (!dma_window)
-   return -ENODEV;
-   end = dma_window + bytes / sizeof(*dma_window);
-
-   while (dma_window < end) {
-   u32 cells;
-   const void *prop;
-
-   /* busno is one cell if supported */
-   if (busno)
-   *busno = be32_to_cpup(dma_window++);
-
-   prop = of_get_property(dn, addrname, NULL);
-   if (!prop)
-   prop = of_get_property(dn, "#address-cells", NULL);
-
-   cells = prop ? be32_to_cpup(prop) : of_n_addr_cells(dn);
-   if (!cells)
-   return -EINVAL;
-   *addr = of_read_number(dma_window, cells);
-   dma_window += cells;
-
-   prop = of_get_property(dn, sizename, NULL);
-   cells = prop ? be32_to_cpup(prop) : of_n_size_cells(dn);
-   if (!cells)
-   return -EINVAL;
-   *size = of_read_number(dma_window, cells);
-   dma_window += cells;
-
-   if (cur_index++ == index)
-   break;
-   }
-   return 0;
-}
-EXPORT_SYMBOL_GPL(of_get_dma_window);
-
 static int of_iommu_xlate(struct device *dev,
  struct of_phandle_args *iommu_spec)
 {
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 16f4b3e87f20..55c1eb300a86 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -2,29 +2,18 @@
 #ifndef __OF_IOMMU_H
 #define __OF_IOMMU_H
 
-#include 
-#include 
-#include 
+struct device;
+struct device_node;
+struct iommu_ops;
 
 #ifdef CONFIG_OF_IOMMU
 
-extern int of_get_dma_window(struct device_node *dn, const char *prefix,
-int index, unsigned long *busno, dma_addr_t *addr,
-size_t *size);
-
 extern const struct iommu_ops *of_iommu_configure(struct device *dev,
struct device_node *master_np,
const u32 *id);
 
 #else
 
-static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
-   int index, unsigned long *busno, dma_addr_t *addr,
-   size_t *size)
-{
-   return -EINVAL;
-}
-
 static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
 struct device_node *master_np,
 const u32 *id)
-- 
2.27.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4] iommu/of: Fix pci_request_acs() before enumerating PCI devices

2021-05-21 Thread Rob Herring
On Thu, May 20, 2021 at 10:03 PM Wang Xingang  wrote:
>
> From: Xingang Wang 
>
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. And ACS should be enabled when IOMMU is detected for the
> PCI host bridge, so add check for IOMMU before probe of PCI host and call
> pci_request_acs() to make sure ACS will be enabled when enumerating PCI
> devices.
>
> Fixes: 6bf6c24720d33 ("iommu/of: Request ACS from the PCI core when
> configuring IOMMU linkage")
> Signed-off-by: Xingang Wang 
> ---
>  drivers/iommu/of_iommu.c | 1 -
>  drivers/pci/of.c | 8 +++-
>  2 files changed, 7 insertions(+), 2 deletions(-)

Reviewed-by: Rob Herring 

> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index a9d2df001149..54a14da242cc 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -205,7 +205,6 @@ const struct iommu_ops *of_iommu_configure(struct device 
> *dev,
> .np = master_np,
> };
>
> -   pci_request_acs();
> err = pci_for_each_dma_alias(to_pci_dev(dev),
>  of_pci_iommu_init, );
> } else {
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index da5b414d585a..2313c3f848b0 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -581,9 +581,15 @@ static int pci_parse_request_of_pci_ranges(struct device 
> *dev,
>
>  int devm_of_pci_bridge_init(struct device *dev, struct pci_host_bridge 
> *bridge)
>  {
> -   if (!dev->of_node)
> +   struct device_node *node = dev->of_node;
> +
> +   if (!node)
> return 0;
>
> +   /* Detect IOMMU and make sure ACS will be enabled */
> +   if (of_property_read_bool(node, "iommu-map"))
> +   pci_request_acs();
> +
> bridge->swizzle_irq = pci_common_swizzle;
> bridge->map_irq = of_irq_parse_and_map_pci;
>
> --
> 2.19.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier

2021-05-20 Thread Rob Herring
On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Reserved memory region phandle references can be accompanied by a
> specifier that provides additional information about how that specific
> reference should be treated.
> 
> One use-case is to mark a memory region as needing an identity mapping
> in the system's IOMMU for the device that references the region. This is
> needed for example when the bootloader has set up hardware (such as a
> display controller) to actively access a memory region (e.g. a boot
> splash screen framebuffer) during boot. The operating system can use the
> identity mapping flag from the specifier to make sure an IOMMU identity
> mapping is set up for the framebuffer before IOMMU translations are
> enabled for the display controller.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../reserved-memory/reserved-memory.txt   | 21 +++
>  include/dt-bindings/reserved-memory.h |  8 +++
>  2 files changed, 29 insertions(+)
>  create mode 100644 include/dt-bindings/reserved-memory.h

Sorry for being slow on this. I have 2 concerns.

First, this creates an ABI issue. A DT with cells in 'memory-region' 
will not be understood by an existing OS. I'm less concerned about this 
if we address that with a stable fix. (Though I'm pretty sure we've 
naively added #?-cells in the past ignoring this issue.)

Second, it could be the bootloader setting up the reserved region. If a 
node already has 'memory-region', then adding more regions is more 
complicated compared to adding new properties. And defining what each 
memory-region entry is or how many in schemas is impossible.

Both could be addressed with a new property. Perhaps something like 
'iommu-memory-region = <>;'. I think the 'iommu' prefix is 
appropriate given this is entirely because of the IOMMU being in the 
mix. I might feel differently if we had other uses for cells, but I 
don't really see it in this case. 

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3] iommu/of: Fix pci_request_acs() before enumerating PCI devices

2021-05-20 Thread Rob Herring
On Thu, May 20, 2021 at 2:28 AM Wang Xingang  wrote:
>
> From: Xingang Wang 
>
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. And ACS should be enabled when IOMMU is detected for the
> PCI host bridge, so add check for IOMMU before probe of PCI host and call
> pci_request_acs() to make sure ACS will be enabled when enumerating PCI
> devices.
>
> Fixes: 6bf6c24720d33 ("iommu/of: Request ACS from the PCI core when
> configuring IOMMU linkage")
> Signed-off-by: Xingang Wang 
> ---
>  drivers/iommu/of_iommu.c |  1 -
>  drivers/pci/controller/pci-host-common.c | 17 +
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index a9d2df001149..54a14da242cc 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -205,7 +205,6 @@ const struct iommu_ops *of_iommu_configure(struct device 
> *dev,
> .np = master_np,
> };
>
> -   pci_request_acs();
> err = pci_for_each_dma_alias(to_pci_dev(dev),
>  of_pci_iommu_init, );
> } else {
> diff --git a/drivers/pci/controller/pci-host-common.c 
> b/drivers/pci/controller/pci-host-common.c
> index d3924a44db02..5904ad0bd9ae 100644
> --- a/drivers/pci/controller/pci-host-common.c
> +++ b/drivers/pci/controller/pci-host-common.c

This file is generally only for ECAM compliant hosts. Are those the
only hosts we need to support this? From the looks of dts files with
iommu-map, that would be dropping support in lots of cases.

Perhaps in devm_of_pci_bridge_init() or one of the functions it calls
is the better place.

> @@ -49,6 +49,21 @@ static struct pci_config_window *gen_pci_init(struct 
> device *dev,
> return cfg;
>  }
>
> +static void pci_host_enable_acs(struct pci_host_bridge *bridge)
> +{
> +   struct device_node *np = bridge->dev.parent->of_node;
> +   static bool acs_enabled;
> +
> +   if (!np || acs_enabled)
> +   return;
> +
> +   /* Detect IOMMU and make sure ACS will be enabled */
> +   if (of_property_read_bool(np, "iommu-map")) {
> +   acs_enabled = true;
> +   pci_request_acs();

Given this function just sets a variable, I don't think you need the
static acs_enabled here.

> +   }
> +}
> +
>  int pci_host_common_probe(struct platform_device *pdev)
>  {
> struct device *dev = >dev;
> @@ -81,6 +96,8 @@ int pci_host_common_probe(struct platform_device *pdev)
> bridge->ops = (struct pci_ops *)>pci_ops;
> bridge->msi_domain = true;
>
> +   pci_host_enable_acs(bridge);
> +
> return pci_host_probe(bridge);
>  }
>  EXPORT_SYMBOL_GPL(pci_host_common_probe);
> --
> 2.19.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] iommu/of: Fix pci_request_acs() before enumerating PCI devices

2021-05-19 Thread Rob Herring
On Mon, May 17, 2021 at 01:17:05PM +, Wang Xingang wrote:
> From: Xingang Wang 
> 
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. This patch add check for IOMMU in of_core_init(), and call
> pci_request_acs() when iommu is detected, making sure that the ACS will
> be enabled.
> 
> Fixes: 6bf6c24720d33 ("iommu/of: Request ACS from the PCI core when
> configuring IOMMU linkage")
> Signed-off-by: Xingang Wang 
> ---
>  drivers/iommu/of_iommu.c | 1 -
>  drivers/of/base.c| 9 -
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> Change log:
> v1->v2:
>  - remove pci_request_acs() in of_iommu_configure
>  - check and call pci_request_acs() in of_core_init()
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index a9d2df001149..54a14da242cc 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -205,7 +205,6 @@ const struct iommu_ops *of_iommu_configure(struct device 
> *dev,
>   .np = master_np,
>   };
>  
> - pci_request_acs();
>   err = pci_for_each_dma_alias(to_pci_dev(dev),
>of_pci_iommu_init, );
>   } else {
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 48e941f99558..95cd8f0e5435 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -166,7 +167,7 @@ void __of_phandle_cache_inv_entry(phandle handle)
>  void __init of_core_init(void)
>  {
>   struct device_node *np;
> -
> + bool of_iommu_detect = false;
>  
>   /* Create the kset, and register existing nodes */
>   mutex_lock(_mutex);
> @@ -180,6 +181,12 @@ void __init of_core_init(void)
>   __of_attach_node_sysfs(np);
>   if (np->phandle && 
> !phandle_cache[of_phandle_cache_hash(np->phandle)])
>   phandle_cache[of_phandle_cache_hash(np->phandle)] = np;
> +
> + /* Detect IOMMU and make sure ACS will be enabled */
> + if (!of_iommu_detect && of_get_property(np, "iommu-map", NULL)) 
> {
> + of_iommu_detect = true;
> + pci_request_acs();
> + }

Private DT internal init code doesn't seem like the right place for 
this. If this needs to be ordered WRT PCI device enumeration, then 
somewhere in the PCI host bridge or bus init code seems like the right 
place to me.

Also, shouldn't this be conditional on 'iommu-map' being in the host 
bridge or a parent or ??? rather than just any iommu-map anywhere in the 
DT.

>   }
>   mutex_unlock(_mutex);
>  
> -- 
> 2.19.1
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 1/6] dt-bindings: iommu: rockchip: Convert IOMMU to DT schema

2021-05-07 Thread Rob Herring
On Fri, 07 May 2021 11:02:27 +0200, Benjamin Gaignard wrote:
> Convert Rockchip IOMMU to DT schema
> 
> Signed-off-by: Benjamin Gaignard 
> ---
> version 4:
>  - Add descriptions for reg items
>  - Add description for interrupts items
>  - Remove useless interrupt-names proporties
> 
> version 2:
>  - Change maintainer
>  - Change reg maxItems
>  - Change interrupt maxItems
>  .../bindings/iommu/rockchip,iommu.txt | 38 -
>  .../bindings/iommu/rockchip,iommu.yaml| 80 +++
>  2 files changed, 80 insertions(+), 38 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 2/4] dt-bindings: iommu: rockchip: Add compatible for v2

2021-05-06 Thread Rob Herring
On Tue, 04 May 2021 10:41:22 +0200, Benjamin Gaignard wrote:
> Add compatible for the second version of IOMMU hardware block.
> RK356x IOMMU can also be link to a power domain.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
> version 3:
>  - Rename compatible with SoC name
> 
> version 2:
>  - Add power-domains property
> 
>  .../devicetree/bindings/iommu/rockchip,iommu.yaml  | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 1/4] dt-bindings: iommu: rockchip: Convert IOMMU to DT schema

2021-05-06 Thread Rob Herring
On Tue, May 04, 2021 at 10:41:21AM +0200, Benjamin Gaignard wrote:
> Convert Rockchip IOMMU to DT schema
> 
> Signed-off-by: Benjamin Gaignard 
> ---
> version 2:
>  - Change maintainer
>  - Change reg maxItems
>  - Change interrupt maxItems
> 
>  .../bindings/iommu/rockchip,iommu.txt | 38 -
>  .../bindings/iommu/rockchip,iommu.yaml| 79 +++
>  2 files changed, 79 insertions(+), 38 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> deleted file mode 100644
> index 6ecefea1c6f9..
> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -Rockchip IOMMU
> -==
> -
> -A Rockchip DRM iommu translates io virtual addresses to physical addresses 
> for
> -its master device.  Each slave device is bound to a single master device, and
> -shares its clocks, power domain and irq.
> -
> -Required properties:
> -- compatible  : Should be "rockchip,iommu"
> -- reg : Address space for the configuration registers
> -- interrupts  : Interrupt specifier for the IOMMU instance
> -- interrupt-names : Interrupt name for the IOMMU instance
> -- #iommu-cells: Should be <0>.  This indicates the iommu is a
> -"single-master" device, and needs no additional 
> information
> -to associate with its master device.  See:
> -Documentation/devicetree/bindings/iommu/iommu.txt
> -- clocks  : A list of clocks required for the IOMMU to be accessible 
> by
> -the host CPU.
> -- clock-names : Should contain the following:
> - "iface" - Main peripheral bus clock (PCLK/HCL) (required)
> - "aclk"  - AXI bus clock (required)
> -
> -Optional properties:
> -- rockchip,disable-mmu-reset : Don't use the mmu reset operation.
> -Some mmu instances may produce unexpected results
> -when the reset operation is used.
> -
> -Example:
> -
> - vopl_mmu: iommu@ff940300 {
> - compatible = "rockchip,iommu";
> - reg = <0xff940300 0x100>;
> - interrupts = ;
> - interrupt-names = "vopl_mmu";
> - clocks = < ACLK_VOP1>, < HCLK_VOP1>;
> - clock-names = "aclk", "iface";
> - #iommu-cells = <0>;
> - };
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml 
> b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> new file mode 100644
> index ..0db208cf724a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip IOMMU
> +
> +maintainers:
> +  - Heiko Stuebner 
> +
> +description: |+
> +  A Rockchip DRM iommu translates io virtual addresses to physical addresses 
> for
> +  its master device. Each slave device is bound to a single master device and
> +  shares its clocks, power domain and irq.
> +
> +  For information on assigning IOMMU controller to its peripheral devices,
> +  see generic IOMMU bindings.
> +
> +properties:
> +  compatible:
> +const: rockchip,iommu
> +
> +  reg:
> +minItems: 1
> +maxItems: 2

What's the 2nd entry? If there's only 1 entry, then you don't have to 
describe what it is. If more than 1, then each entry has to be defined.

> +
> +  interrupts:
> +minItems: 1
> +maxItems: 2

Same here, though if interrupt-names defines them, that's good enough.

> +
> +  interrupt-names:
> +minItems: 1
> +maxItems: 2

Here we need the values.

> +
> +  clocks:
> +items:
> +  - description: Core clock
> +  - description: Interface clock
> +
> +  clock-names:
> +items:
> +  - const: aclk
> +  - const: iface
> +
> +  "#iommu-cells":
> +const: 0
> +
> +  rockchip,disable-mmu-reset:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Do not use the mmu reset operation.
> +  Some mmu instances may produce unexpected results
> +  when the reset operation is used.
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - "#iommu-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +vopl_mmu: iommu@ff940300 {
> +  compatible = "rockchip,iommu";
> +  reg = <0xff940300 0x100>;
> +  interrupts = ;
> +  interrupt-names = "vopl_mmu";
> +  clocks = < ACLK_VOP1>, < HCLK_VOP1>;
> +  clock-names = "aclk", "iface";
> +  

Re: [PATCH v2 2/4] dt-bindings: iommu: rockchip: Add compatible for v2

2021-04-30 Thread Rob Herring
On Thu, Apr 22, 2021 at 04:16:00PM +0200, Benjamin Gaignard wrote:
> Add compatible for the second version of IOMMU hardware block.
> RK356x IOMMU can also be link to a power domain.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
> version 2:
>  - Add power-domains property
> 
>  .../devicetree/bindings/iommu/rockchip,iommu.yaml  | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml 
> b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> index 0db208cf724a..e54353ccd1ec 100644
> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> @@ -19,7 +19,9 @@ description: |+
>  
>  properties:
>compatible:
> -const: rockchip,iommu
> +enum:
> +  - rockchip,iommu
> +  - rockchip,iommu-v2

This should be SoC specific.

>  
>reg:
>  minItems: 1
> @@ -46,6 +48,9 @@ properties:
>"#iommu-cells":
>  const: 0
>  
> +  power-domains:
> +maxItems: 1
> +
>rockchip,disable-mmu-reset:
>  $ref: /schemas/types.yaml#/definitions/flag
>  description: |
> -- 
> 2.25.1
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/4] dt-bindings: iommu: rockchip: Convert IOMMU to DT schema

2021-04-30 Thread Rob Herring
On Thu, Apr 22, 2021 at 02:16:53PM -0300, Ezequiel Garcia wrote:
> (Adding Kever)
> 
> Hi Benjamin,
> 
> Thanks a lot for working on this, it looks amazing. Together with the great 
> work
> that Rockchip is doing, it seems RK3566/RK3568 will have decent support very 
> soon.
> 
> One comment here:
> 
> On Thu, 2021-04-22 at 16:15 +0200, Benjamin Gaignard wrote:
> > Convert Rockchip IOMMU to DT schema
> > 
> > Signed-off-by: Benjamin Gaignard 
> > ---
> > version 2:
> >  - Change maintainer
> >  - Change reg maxItems
> >  - Change interrupt maxItems
> > 
> >  .../bindings/iommu/rockchip,iommu.txt | 38 -
> >  .../bindings/iommu/rockchip,iommu.yaml    | 79 +++
> >  2 files changed, 79 insertions(+), 38 deletions(-)
> >  delete mode 100644 
> > Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
> > b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> > deleted file mode 100644
> > index 6ecefea1c6f9..
> > --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> > +++ /dev/null
> > @@ -1,38 +0,0 @@
> > -Rockchip IOMMU
> > -==
> > -
> > -A Rockchip DRM iommu translates io virtual addresses to physical addresses 
> > for
> > -its master device.  Each slave device is bound to a single master device, 
> > and
> > -shares its clocks, power domain and irq.
> > -
> > -Required properties:
> > -- compatible  : Should be "rockchip,iommu"
> > -- reg : Address space for the configuration registers
> > -- interrupts  : Interrupt specifier for the IOMMU instance
> > -- interrupt-names : Interrupt name for the IOMMU instance
> > -- #iommu-cells    : Should be <0>.  This indicates the iommu is a
> > -    "single-master" device, and needs no additional 
> > information
> > -    to associate with its master device.  See:
> > -    Documentation/devicetree/bindings/iommu/iommu.txt
> > -- clocks  : A list of clocks required for the IOMMU to be 
> > accessible by
> > -    the host CPU.
> > -- clock-names : Should contain the following:
> > -   "iface" - Main peripheral bus clock (PCLK/HCL) (required)
> > -   "aclk"  - AXI bus clock (required)
> > -
> > -Optional properties:
> > -- rockchip,disable-mmu-reset : Don't use the mmu reset operation.
> > -  Some mmu instances may produce unexpected 
> > results
> > -  when the reset operation is used.
> > -
> > -Example:
> > -
> > -   vopl_mmu: iommu@ff940300 {
> > -   compatible = "rockchip,iommu";
> > -   reg = <0xff940300 0x100>;
> > -   interrupts = ;
> > -   interrupt-names = "vopl_mmu";
> > -   clocks = < ACLK_VOP1>, < HCLK_VOP1>;
> > -   clock-names = "aclk", "iface";
> > -   #iommu-cells = <0>;
> > -   };
> > diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml 
> > b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> > new file mode 100644
> > index ..0db208cf724a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> > @@ -0,0 +1,79 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip IOMMU
> > +
> > +maintainers:
> > +  - Heiko Stuebner 
> > +
> > +description: |+
> > +  A Rockchip DRM iommu translates io virtual addresses to physical 
> > addresses for
> > +  its master device. Each slave device is bound to a single master device 
> > and
> > +  shares its clocks, power domain and irq.
> > +
> > +  For information on assigning IOMMU controller to its peripheral devices,
> > +  see generic IOMMU bindings.
> > +
> > +properties:
> > +  compatible:
> > +    const: rockchip,iommu
> > +
> > +  reg:
> > +    minItems: 1
> > +    maxItems: 2
> > +
> > +  interrupts:
> > +    minItems: 1
> > +    maxItems: 2
> > +
> > +  interrupt-names:
> > +    minItems: 1
> > +    maxItems: 2
> > +
> 
> AFAICS, the driver supports handling multiple MMUs, and there's one reg and
> interrupt cell for each MMU. IOW, there's no requirement that maxItems is 2.
> 
> Is there any way we can describe that? Or maybe just allow a bigger maximum?

With #iommu-cells == 0, how would one distinguish which IOMMU is 
associated with a device? IOW, is more that 1 really usable?

If you need more just pick a maxItems value that's either the most seen 
or 'should be enough'TM. If the entries are just multiple instances of 
the same thing, please note that here.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org

Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-23 Thread Rob Herring
On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
> > Date: Sat, 20 Mar 2021 15:19:33 +
> > From: Sven Peter 
> > 
> > Hi,
> > 
> > After Hector's initial work [1] to bring up Linux on Apple's M1 it's time to
> > bring up more devices. Most peripherals connected to the SoC are behind a 
> > iommu
> > which Apple calls "Device Address Resolution Table", or DART for short [2].
> > Unfortunately, it only shares the name with PowerPC's DART.
> > Configuring this iommu is mandatory if these peripherals require DMA access.
> > 
> > This patchset implements initial support for this iommu. The hardware itself
> > uses a pagetable format that's very similar to the one already implement in
> > io-pgtable.c. There are some minor modifications, namely some details of the
> > PTE format and that there are always three pagetable levels, which I've
> > implement as a new format variant.
> > 
> > I have mainly tested this with the USB controller in device mode which is
> > compatible with Linux's dwc3 driver. Some custom PHY initialization (which 
> > is
> > not yet ready or fully understood) is required though to bring up the ports,
> > see e.g. my patches to our m1n1 bootloader [3,4]. If you want to test the 
> > same
> > setup you will probably need that branch for now and add the nodes from
> > the DT binding specification example to your device tree.
> > 
> > Even though each DART instances could support up to 16 devices usually only
> > a single device is actually connected. Different devices generally just use
> > an entirely separate DART instance with a seperate MMIO range, IRQ, etc.
> > 
> > I have just noticed today though that at least the USB DWC3 controller in 
> > host
> > mode uses *two* darts at the same time. I'm not sure yet which parts seem to
> > require which DART instance.
> > 
> > This means that we might need to support devices attached to two iommus
> > simultaneously and just create the same iova mappings. Currently this only
> > seems to be required for USB according to Apple's Device Tree.
> > 
> > I see two options for this and would like to get feedback before
> > I implement either one:
> > 
> > 1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first 
> > cell
> >to identify the DART and the second one to identify the master.
> >The DART DT node would then also take two register ranges that would
> >correspond to the two DARTs. Both instances use the same IRQ and the
> >same clocks according to Apple's device tree and my experiments.
> >This would keep a single device node and the DART driver would then
> >simply map iovas in both DARTs if required.
> > 
> > 2) Keep #iommu-cells as-is but support
> > iommus = <_dart1a 1>, <_dart1b 0>;
> >instead.
> >This would then require two devices nodes for the two DART instances 
> > and
> >some housekeeping in the DART driver to support mapping iovas in both
> >DARTs.
> >I believe omap-iommu.c supports this setup but I will have to read
> >more code to understand the details there and figure out how to 
> > implement
> >this in a sane way.
> > 
> > I currently prefer the first option but I don't understand enough details of
> > the iommu system to actually make an informed decision.

Please don't mix what does the h/w look like and what's easy to 
implement in Linux's IOMMU subsytem. It's pretty clear (at least 
from the description here) that option 2 reflects the h/w. 

> > I'm obviously also open to more options :-)
> 
> Hi Sven,
> 
> I don't think the first option is going to work for PCIe.  PCIe
> devices will have to use "iommu-map" properties to map PCI devices to
> the right iommu, and the currently implementation seems to assume that
> #iommu-cells = <1>.  The devictree binding[1] doesn't explicitly state
> that it relies on #iommu-cells = <1>, but it isn't clear how the
> rid-base to iommu-base mapping mechanism would work when that isn't
> the case.
> 
> Now the PCIe DARTs are simpler and seem to have only one "instance"
> per DART.  So if we keep #iommu-cells = <1> for those, you'd still be
> fine using the first approach.
> 
> As I mentioned before, not all DARTs support the full 32-bit aperture.
> In particular the PCIe DARTs support a smaller address-space.  It is
> not clear whether this is a restriction of the PCIe host controller or
> the DART, but the Apple Device Tree has "vm-base" and "vm-size"
> properties that encode the base address and size of the aperture.
> These single-cell properties which is probably why for the USB DARTs
> only "vm-base" is given; since "vm-base" is 0, a 32-bit number
> wouldn't be able to encode the full aperture size.  We could make them
> 64-bit numbers in the Linux device tree though and always be explicit
> about the size.  Older Sun SPARC machines used a single "virtual-dma"
> property to encode the aperture.  We could do someting similar.  You

Re: [PATCH 2/3] dt-bindings: iommu: add DART iommu bindings

2021-03-21 Thread Rob Herring
On Sat, 20 Mar 2021 15:20:08 +, Sven Peter wrote:
> DART (Device Address Resolution Table) is the iommu found on Apple
> ARM SoCs such as the M1.
> 
> Signed-off-by: Sven Peter 
> ---
>  .../bindings/iommu/apple,t8103-dart.yaml  | 82 +++
>  MAINTAINERS   |  6 ++
>  2 files changed, 88 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/apple,t8103-dart.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: 
Documentation/devicetree/bindings/iommu/apple,t8103-dart.example.dts:23.25-26 
syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:349: 
Documentation/devicetree/bindings/iommu/apple,t8103-dart.example.dt.yaml] Error 
1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1380: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1456122

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 13/14] dt-bindings: of: Add restricted DMA pool

2021-03-10 Thread Rob Herring
On Wed, Mar 10, 2021 at 9:08 AM Will Deacon  wrote:
>
> Hi Claire,
>
> On Tue, Feb 09, 2021 at 02:21:30PM +0800, Claire Chang wrote:
> > Introduce the new compatible string, restricted-dma-pool, for restricted
> > DMA. One can specify the address and length of the restricted DMA memory
> > region by restricted-dma-pool in the reserved-memory node.
> >
> > Signed-off-by: Claire Chang 
> > ---
> >  .../reserved-memory/reserved-memory.txt   | 24 +++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > index e8d3096d922c..fc9a12c2f679 100644
> > --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > @@ -51,6 +51,20 @@ compatible (optional) - standard definition
> >used as a shared pool of DMA buffers for a set of devices. It can
> >be used by an operating system to instantiate the necessary pool
> >management subsystem if necessary.
> > +- restricted-dma-pool: This indicates a region of memory meant to 
> > be
> > +  used as a pool of restricted DMA buffers for a set of devices. 
> > The
> > +  memory region would be the only region accessible to those 
> > devices.
> > +  When using this, the no-map and reusable properties must not be 
> > set,
> > +  so the operating system can create a virtual mapping that will 
> > be used
> > +  for synchronization. The main purpose for restricted DMA is to
> > +  mitigate the lack of DMA access control on systems without an 
> > IOMMU,
> > +  which could result in the DMA accessing the system memory at
> > +  unexpected times and/or unexpected addresses, possibly leading 
> > to data
> > +  leakage or corruption. The feature on its own provides a basic 
> > level
> > +  of protection against the DMA overwriting buffer contents at
> > +  unexpected times. However, to protect against general data 
> > leakage and
> > +  system memory corruption, the system needs to provide way to 
> > lock down
> > +  the memory access, e.g., MPU.
>
> As far as I can tell, these pools work with both static allocations (which
> seem to match your use-case where firmware has preconfigured the DMA ranges)
> but also with dynamic allocations where a 'size' property is present instead
> of the 'reg' property and the kernel is responsible for allocating the
> reservation during boot. Am I right and, if so, is that deliberate?

I believe so. I'm not keen on having size only reservations in DT.
Yes, we allowed that already, but that's back from the days of needing
large CMA carveouts to be reserved early in boot. I've read that the
kernel is much better now at contiguous allocations, so do we really
need this in DT anymore?

> I ask because I think that would potentially be useful to us for the
> Protected KVM work, where we need to bounce virtio memory accesses via
> guest-determined windows because the guest memory is generally inaccessible
> to the host. We've been hacking this using a combination of "swiotlb=force"
> and set_memory_{decrypted,encrypted}() but it would be much better to
> leverage the stuff you have here.
>
> Also:
>
> > +
> > + restricted_dma_mem_reserved: restricted_dma_mem_reserved {
> > + compatible = "restricted-dma-pool";
> > + reg = <0x5000 0x40>;
> > + };
> >   };
> >
> >   /* ... */
> > @@ -138,4 +157,9 @@ one for multimedia processing (named 
> > multimedia-memory@7700, 64MiB).
> >   memory-region = <_reserved>;
> >   /* ... */
> >   };
> > +
> > + pcie_device: pcie_device@0,0 {
> > + memory-region = <_dma_mem_reserved>;
> > + /* ... */
> > + };
>
> I find this example a bit weird, as I didn't think we usually had DT nodes
> for PCI devices; rather they are discovered as a result of probing config
> space. Is the idea that you have one reserved memory region attached to the
> RC and all the PCI devices below that share the region, or is there a need
> for a mapping mechanism?

We can have DT nodes for PCI. AIUI, IBM power systems always do. For
FDT, it's only if there are extra non-discoverable resources. It's
particularly fun when it's resources which need to be enabled for the
PCI device to be discovered. That seems to be a growing problem as PCI
becomes more common on embedded systems.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu

2021-02-10 Thread Rob Herring
On Fri, Feb 5, 2021 at 1:21 AM Chunyan Zhang  wrote:
>
> Hi Rob,
>
> On Fri, 5 Feb 2021 at 07:25, Rob Herring  wrote:
> >
> > On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> > > From: Chunyan Zhang 
> > >
> > > This iommu module can be used by Unisoc's multimedia devices, such as
> > > display, Image codec(jpeg) and a few signal processors, including
> > > VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), 
> > > etc.
> > >
> > > Signed-off-by: Chunyan Zhang 
> > > ---
> > >  .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
> > >  1 file changed, 72 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml 
> > > b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > new file mode 100644
> > > index ..4fc99e81fa66
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > @@ -0,0 +1,72 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +# Copyright 2020 Unisoc Inc.
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Unisoc IOMMU and Multi-media MMU
> > > +
> > > +maintainers:
> > > +  - Chunyan Zhang 
> > > +
> > > +properties:
> > > +  compatible:
> > > +enum:
> > > +  - sprd,iommu-v1
> > > +
> > > +  "#iommu-cells":
> > > +const: 0
> > > +description:
> > > +  Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> > > +  additional information needs to associate with its master device.
> > > +  Please refer to the generic bindings document for more details,
> > > +  Documentation/devicetree/bindings/iommu/iommu.txt
> > > +
> > > +  reg:
> > > +maxItems: 1
> > > +description:
> > > +  Not required if 'sprd,iommu-regs' is defined.
> > > +
> > > +  clocks:
> > > +description:
> > > +  Reference to a gate clock phandle, since access to some of IOMMUs 
> > > are
> > > +  controlled by gate clock, but this is not required.
> > > +
> > > +  sprd,iommu-regs:
> > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > > +description:
> > > +  Reference to a syscon phandle plus 1 cell, the syscon defines the
> > > +  register range used by the iommu and the media device, the cell
> > > +  defines the offset for iommu registers. Since iommu module shares
> > > +  the same register range with the media device which uses it.
> > > +
> > > +required:
> > > +  - compatible
> > > +  - "#iommu-cells"
> > > +
> > > +oneOf:
> > > +  - required:
> > > +  - reg
> > > +  - required:
> > > +  - sprd,iommu-regs
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +iommu_disp: iommu-disp {
> > > +  compatible = "sprd,iommu-v1";
> > > +  sprd,iommu-regs = <_regs 0x800>;
> >
> > If the IOMMU is contained within another device, then it should just be
> > a child node of that device.
>
> Yes, actually IOMMU can be seen as a child of multimedia devices, I
> considered moving IOMMU under into multimedia device node, but
> multimedia devices need IOMMU when probe[1], so I dropped that idea.

Don't design your binding around working-around linux issues.

> And they share the same register base, e.g.
>
> +   mm {
> +   compatible = "simple-bus";
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   ranges;
> +
> +   dpu_regs: syscon@6300 {

Drop this node.

> +   compatible = "sprd,sc9863a-dpuregs", "syscon";
> +   reg = <0 0x6300 0 0x1000>;
> +   };
> +
> +   dpu: dpu@6300 {
> +   compatible = "sprd,sharkl3-dpu";
> +   sprd,disp-regs = <_regs>;

reg = <0 0x6300 0 0x800>;

> +   iommus = <_dispc>;
> +   };
> +
> +   iommu_dispc: iommu@6300 {
> +   compatible = "sprd,iommu-v1";
> +   sprd,iommu-regs = <_regs 0x800>;

reg = <0 0x63000800 0 0x800>;

> +   #iommu-cells = <0>;

Though given it seems there is only 1 client and this might really be
just 1 h/w block, you don't really need to use the iommu binding at
all. The DPU should be able to instantiate it's own IOMMU device.
There's other examples of this such as mali GPU though that is all one
driver, but that's a Linux implementation detail.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu

2021-02-04 Thread Rob Herring
On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang 
> 
> This iommu module can be used by Unisoc's multimedia devices, such as
> display, Image codec(jpeg) and a few signal processors, including
> VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
> 
> Signed-off-by: Chunyan Zhang 
> ---
>  .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
>  1 file changed, 72 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml 
> b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> new file mode 100644
> index ..4fc99e81fa66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2020 Unisoc Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc IOMMU and Multi-media MMU
> +
> +maintainers:
> +  - Chunyan Zhang 
> +
> +properties:
> +  compatible:
> +enum:
> +  - sprd,iommu-v1
> +
> +  "#iommu-cells":
> +const: 0
> +description:
> +  Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> +  additional information needs to associate with its master device.
> +  Please refer to the generic bindings document for more details,
> +  Documentation/devicetree/bindings/iommu/iommu.txt
> +
> +  reg:
> +maxItems: 1
> +description:
> +  Not required if 'sprd,iommu-regs' is defined.
> +
> +  clocks:
> +description:
> +  Reference to a gate clock phandle, since access to some of IOMMUs are
> +  controlled by gate clock, but this is not required.
> +
> +  sprd,iommu-regs:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> +  Reference to a syscon phandle plus 1 cell, the syscon defines the
> +  register range used by the iommu and the media device, the cell
> +  defines the offset for iommu registers. Since iommu module shares
> +  the same register range with the media device which uses it.
> +
> +required:
> +  - compatible
> +  - "#iommu-cells"
> +
> +oneOf:
> +  - required:
> +  - reg
> +  - required:
> +  - sprd,iommu-regs
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +iommu_disp: iommu-disp {
> +  compatible = "sprd,iommu-v1";
> +  sprd,iommu-regs = <_regs 0x800>;

If the IOMMU is contained within another device, then it should just be 
a child node of that device. Or just make 'dpu_regs' an IOMMU provider 
(i.e. just add #iommu-cells to it).

> +  #iommu-cells = <0>;
> +};
> +
> +  - |
> +iommu_jpg: iommu-jpg {
> +  compatible = "sprd,iommu-v1";
> +  sprd,iommu-regs = <_regs 0x300>;
> +  #iommu-cells = <0>;
> +  clocks = <_gate 1>;
> +};
> +
> +...
> -- 
> 2.25.1
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples

2021-02-03 Thread Rob Herring
On Tue, Feb 02, 2021 at 04:33:56PM -0800, Stephen Boyd wrote:
> Quoting Rob Herring (2021-02-02 12:55:42)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> >  
> > b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> > index fa0ee03a527f..53cc6df0df96 100644
> > --- 
> > a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> > +++ 
> > b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> > @@ -18,7 +18,7 @@ properties:
> >  const: 1
> >  
> >compatible:
> > -const: allwinner,sun9i-a80-usb-clocks
> > +const: allwinner,sun9i-a80-usb-clks
> 
> Should the file name change too?

Yes, I'll fix that while applying.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas

2021-02-03 Thread Rob Herring
On Wed, Feb 03, 2021 at 09:01:23AM +0100, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Tue, Feb 2, 2021 at 9:55 PM Rob Herring  wrote:
> > Properties in if/then schemas weren't getting checked by the meta-schemas.
> > Enabling meta-schema checks finds several errors.
> >
> > The use of an 'items' schema (as opposed to the list form) is wrong in
> > some cases as it applies to all entries. 'contains' is the correct schema
> > to use in the case of multiple entries.
> 
> > Signed-off-by: Rob Herring 
> 
> Thanks for your patch!
> 
> > --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> > @@ -81,9 +81,8 @@ properties:
> >  if:
> >properties:
> >  compatible:
> > -  items:
> > -enum:
> > -  - renesas,usb2-phy-r7s9210
> > +  contains:
> > +const: renesas,usb2-phy-r7s9210
> 
> Single entry, so "contains" not needed?

No, you are misunderstanding how these work. 'contains' means at least 
one entry in an array passes with the subschema. In this case, 
'renesas,usb2-phy-r7s9210' must appear somewhere in the 'compatible' 
values. (Before, it said *every* entry must be 
'renesas,usb2-phy-r7s9210'.) As there is a fallback compatible, we need 
'contains'.

> > --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> > @@ -76,11 +76,10 @@ required:
> >  if:
> >properties:
> >  compatible:
> > -  items:
> > -enum:
> > -  - renesas,pfc-r8a73a4
> > -  - renesas,pfc-r8a7740
> > -  - renesas,pfc-sh73a0
> > +  enum:
> > +- renesas,pfc-r8a73a4
> > +- renesas,pfc-r8a7740
> > +- renesas,pfc-sh73a0
> 
> Missing "contains"?

No. In this case, 'compatible' is always a single entry, so no 
'contains' needed (but would work). If compatible is one of these 3 
strings, then the 'if' is true.

The original way would actually work in this case (i.e. is valid 
json-schema), but we require 'items' to have a size (maxItems/minItems) 
in our meta-schema.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 3/3] dt-bindings: Fix errors in 'if' schemas

2021-02-02 Thread Rob Herring
Properties in if/then schemas weren't getting checked by the meta-schemas.
Enabling meta-schema checks finds several errors.

The use of an 'items' schema (as opposed to the list form) is wrong in
some cases as it applies to all entries. 'contains' is the correct schema
to use in the case of multiple entries.

Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Eric Anholt 
Cc: Nicolas Saenz Julienne 
Cc: Florian Fainelli 
Cc: Ray Jui 
Cc: Scott Branden 
Cc: Pavel Machek 
Cc: Ulf Hansson 
Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: Geert Uytterhoeven 
Cc: Linus Walleij 
Cc: Daniel Lezcano 
Cc: linux-cry...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-l...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 .../devicetree/bindings/crypto/allwinner,sun8i-ce.yaml   | 3 +--
 .../devicetree/bindings/display/brcm,bcm2835-hvs.yaml| 2 +-
 Documentation/devicetree/bindings/leds/ti,tca6507.yaml   | 1 +
 Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml  | 2 +-
 Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml | 3 +--
 .../devicetree/bindings/phy/renesas,usb2-phy.yaml| 5 ++---
 .../devicetree/bindings/pinctrl/renesas,pfc.yaml | 9 -
 .../bindings/timer/allwinner,sun5i-a13-hstimer.yaml  | 3 +--
 8 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml 
b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
index 7a60d84289cc..6ab07eba7778 100644
--- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
+++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
@@ -46,8 +46,7 @@ properties:
 if:
   properties:
 compatible:
-  items:
-const: allwinner,sun50i-h6-crypto
+  const: allwinner,sun50i-h6-crypto
 then:
   properties:
 clocks:
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml 
b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
index e826ab0adb75..2e8566f47e63 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
@@ -36,7 +36,7 @@ if:
   properties:
 compatible:
   contains:
-const: brcm,bcm2711-hvs"
+const: brcm,bcm2711-hvs
 
 then:
   required:
diff --git a/Documentation/devicetree/bindings/leds/ti,tca6507.yaml 
b/Documentation/devicetree/bindings/leds/ti,tca6507.yaml
index 94c307c98762..32c600387895 100644
--- a/Documentation/devicetree/bindings/leds/ti,tca6507.yaml
+++ b/Documentation/devicetree/bindings/leds/ti,tca6507.yaml
@@ -69,6 +69,7 @@ patternProperties:
 if:
   patternProperties:
 "^gpio@[0-6]$":
+  type: object
   properties:
 compatible:
   contains:
diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml 
b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
index 6bbf29b5c239..6c13703b31db 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
+++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
@@ -123,7 +123,7 @@ required:
 if:
   properties:
 compatible:
-  items:
+  contains:
 enum:
   - renesas,sdhi-r7s72100
   - renesas,sdhi-r7s9210
diff --git a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml 
b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
index 58c3ef8004ad..04edda504ab6 100644
--- a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
@@ -99,8 +99,7 @@ patternProperties:
 if:
   properties:
 compatible:
-  items:
-const: brcm,iproc-ns2-sata-phy
+  const: brcm,iproc-ns2-sata-phy
 then:
   properties:
 reg:
diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml 
b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
index 829e8c7e467a..0f358d5b84ef 100644
--- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -81,9 +81,8 @@ properties:
 if:
   properties:
 compatible:
-  items:
-enum:
-  - renesas,usb2-phy-r7s9210
+  contains:
+const: renesas,usb2-phy-r7s9210
 then:
   required:
 - clock-names
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml 
b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
index 5b5b1b9d2ec7..5d3947902f2d 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
@@ -76,11 +76,10 @@ required:
 if:
   properties:
 compatible:
-  items:
-enum:
-  - renesas,pfc-r8a73a4
-  - renesas,pfc-r8a7740
-  - renesas,pfc-sh73a0
+  enum:
+- renesas,pfc-r8a73a4
+- renesas,pfc-r8a7740
+   

[PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples

2021-02-02 Thread Rob Herring
Running 'dt-validate -m' will flag any compatible strings missing a schema.
Fix all the errors found in DT binding examples. Most of these are just
typos.

Cc: Stephen Boyd 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Linus Walleij 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Daniel Palmer 
Cc: Bartosz Golaszewski 
Cc: Avi Fishman 
Cc: Tomer Maimon 
Cc: Tali Perry 
Cc: Joerg Roedel 
Cc: Will Deacon 
Cc: Andrew Jeffery 
Cc: Joel Stanley 
Cc: Wim Van Sebroeck 
Cc: Guenter Roeck 
Cc: Yoshihiro Shimoda 
Cc: Vincent Cheng 
Cc: linux-...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: linux-watch...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 .../bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml| 2 +-
 Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml  | 4 ++--
 Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml| 2 +-
 Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml | 2 +-
 .../devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml  | 2 +-
 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 2 +-
 .../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml   | 2 +-
 .../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml   | 2 +-
 .../devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml   | 2 +-
 Documentation/devicetree/bindings/ptp/ptp-idtcm.yaml  | 4 +---
 Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml| 4 ++--
 11 files changed, 13 insertions(+), 15 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml 
b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
index fa0ee03a527f..53cc6df0df96 100644
--- 
a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
+++ 
b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
@@ -18,7 +18,7 @@ properties:
 const: 1
 
   compatible:
-const: allwinner,sun9i-a80-usb-clocks
+const: allwinner,sun9i-a80-usb-clks
 
   reg:
 maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml 
b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
index eb241587efd1..118c5543e037 100644
--- a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
+++ b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
@@ -66,8 +66,8 @@ properties:
   - arm,syscon-icst525-integratorcp-cm-mem
   - arm,integrator-cm-auxosc
   - arm,versatile-cm-auxosc
-  - arm,impd-vco1
-  - arm,impd-vco2
+  - arm,impd1-vco1
+  - arm,impd1-vco2
 
   clocks:
 description: Parent clock for the ICST VCO
diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml 
b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
index 1465c9ebaf93..1d48ac712b23 100644
--- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
+++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
@@ -66,7 +66,7 @@ examples:
 #include 
 
 main_crypto: crypto@4e0 {
-compatible = "ti,j721-sa2ul";
+compatible = "ti,j721e-sa2ul";
 reg = <0x4e0 0x1200>;
 power-domains = <_pds 264 TI_SCI_PD_EXCLUSIVE>;
 dmas = <_udmap 0xc000>, <_udmap 0x4000>,
diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml 
b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
index 1f2ef408bb43..fe1e1c63ffe3 100644
--- a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
@@ -46,7 +46,7 @@ examples:
 #include 
 
 gpio: gpio@207800 {
-  compatible = "mstar,msc313e-gpio";
+  compatible = "mstar,msc313-gpio";
   #gpio-cells = <2>;
   reg = <0x207800 0x200>;
   gpio-controller;
diff --git a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml 
b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
index e3ef2d36f372..128444942aec 100644
--- a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
@@ -17,7 +17,7 @@ maintainers:
 
 properties:
   compatible:
-const: nuvoton,npcm7xx-i2c
+const: nuvoton,npcm750-i2c
 
   reg:
 maxItems: 1
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index cde1afa8dfd6..349633108bbd 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -93,7 +93,7 @@ examples:
 #include 
 
 ipmmu_mx: iommu@fe951000 {
-compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
+compatible = "renesas,ipmmu-r8a7791", "renesas,ipm

[PATCH 2/3] dt-bindings: iommu: renesas, ipmmu-vmsa: Make 'power-domains' conditionally required

2021-02-02 Thread Rob Herring
Fixing the compatible string typos results in an error in the example:

Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.example.dt.yaml:
  iommu@fe951000: 'power-domains' is a required property

Based on the dts files, a 'power-domains' property only exists on Gen 3
which can be conditioned on !renesas,ipmmu-vmsa.

Cc: Joerg Roedel 
Cc: Will Deacon 
Cc: Yoshihiro Shimoda 
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring 
---
 .../bindings/iommu/renesas,ipmmu-vmsa.yaml   | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 349633108bbd..dda44976acc1 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -76,7 +76,6 @@ required:
   - compatible
   - reg
   - '#iommu-cells'
-  - power-domains
 
 oneOf:
   - required:
@@ -86,6 +85,17 @@ oneOf:
 
 additionalProperties: false
 
+allOf:
+  - if:
+  properties:
+compatible:
+  not:
+contains:
+  const: renesas,ipmmu-vmsa
+then:
+  required:
+- power-domains
+
 examples:
   - |
 #include 
-- 
2.27.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] of/device: Update dma_range_map only when dev has valid dma-ranges

2021-01-27 Thread Rob Herring
On Tue, 19 Jan 2021 18:52:03 +0800, Yong Wu wrote:
> The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
> supplanting dma_pfn_offset") always update dma_range_map even though it was
> already set, like in the sunxi_mbus driver. the issue is reported at [1].
> This patch avoid this(Updating it only when dev has valid dma-ranges).
> 
> Meanwhile, dma_range_map contains the devices' dma_ranges information,
> This patch moves dma_range_map before of_iommu_configure. The iommu
> driver may need to know the dma_address requirements of its iommu
> consumer devices.
> 
> [1] 
> https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ce...@arm.com/
> 
> CC: Rob Herring 
> CC: Frank Rowand 
> Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting 
> dma_pfn_offset"),
> Suggested-by: Robin Murphy 
> Signed-off-by: Yong Wu 
> Signed-off-by: Paul Kocialkowski 
> Reviewed-by: Rob Herring 
> ---
>  drivers/of/device.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 

Applied, thanks!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] of/device: Update dma_range_map only when dev has valid dma-ranges

2021-01-27 Thread Rob Herring
On Wed, Jan 27, 2021 at 7:13 AM Robin Murphy  wrote:
>
> [ + Christoph, Marek ]
>
> On 2021-01-27 13:00, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Tue 19 Jan 21, 18:52, Yong Wu wrote:
> >> The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
> >> supplanting dma_pfn_offset") always update dma_range_map even though it was
> >> already set, like in the sunxi_mbus driver. the issue is reported at [1].
> >> This patch avoid this(Updating it only when dev has valid dma-ranges).
> >>
> >> Meanwhile, dma_range_map contains the devices' dma_ranges information,
> >> This patch moves dma_range_map before of_iommu_configure. The iommu
> >> driver may need to know the dma_address requirements of its iommu
> >> consumer devices.
> >
> > Just a gentle ping on this issue, it would be nice to have this fix merged
> > ASAP, in the next RC :)
>
> Ack to that - Rob, Frank, do you want to take this through the OF tree,
> or shall we take it through the DMA-mapping tree like the original culprit?

I've already got some fixes queued up and can take it.

Suggested-by doesn't mean you are happy with the implementation. So
Acked-by or Reviewed-by?

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] of/device: Update dma_range_map only when dev has valid dma-ranges

2021-01-27 Thread Rob Herring
On Tue, Jan 19, 2021 at 4:52 AM Yong Wu  wrote:
>
> The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
> supplanting dma_pfn_offset") always update dma_range_map even though it was
> already set, like in the sunxi_mbus driver. the issue is reported at [1].
> This patch avoid this(Updating it only when dev has valid dma-ranges).

only when dev *doesn't* have valid dma-ranges?

> Meanwhile, dma_range_map contains the devices' dma_ranges information,
> This patch moves dma_range_map before of_iommu_configure. The iommu
> driver may need to know the dma_address requirements of its iommu
> consumer devices.
>
> [1] 
> https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ce...@arm.com/
>
> CC: Rob Herring 
> CC: Frank Rowand 
> Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting 
> dma_pfn_offset"),
> Suggested-by: Robin Murphy 
> Signed-off-by: Yong Wu 
> Signed-off-by: Paul Kocialkowski 
> Reviewed-by: Rob Herring 
> ---
>  drivers/of/device.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index aedfaaafd3e7..1122daa8e273 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -162,9 +162,11 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
> mask = DMA_BIT_MASK(ilog2(end) + 1);
> dev->coherent_dma_mask &= mask;
> *dev->dma_mask &= mask;
> -   /* ...but only set bus limit if we found valid dma-ranges earlier */
> -   if (!ret)
> +   /* ...but only set bus limit and range map if we found valid 
> dma-ranges earlier */
> +   if (!ret) {
> dev->bus_dma_limit = end;
> +   dev->dma_range_map = map;
> +   }
>
> coherent = of_dma_is_coherent(np);
> dev_dbg(dev, "device is%sdma coherent\n",
> @@ -172,6 +174,9 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>
> iommu = of_iommu_configure(dev, np, id);
> if (PTR_ERR(iommu) == -EPROBE_DEFER) {
> +   /* Don't touch range map if it wasn't set from a valid 
> dma-ranges */
> +   if (!ret)
> +   dev->dma_range_map = NULL;
> kfree(map);
> return -EPROBE_DEFER;
> }
> @@ -181,7 +186,6 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>
> arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>
> -   dev->dma_range_map = map;
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_configure_id);
> --
> 2.18.0
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool

2021-01-21 Thread Rob Herring
On Wed, Jan 20, 2021 at 7:10 PM Robin Murphy  wrote:
>
> On 2021-01-20 21:31, Rob Herring wrote:
> > On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy  wrote:
> >>
> >> On 2021-01-20 16:53, Rob Herring wrote:
> >>> On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> >>>> Introduce the new compatible string, restricted-dma-pool, for restricted
> >>>> DMA. One can specify the address and length of the restricted DMA memory
> >>>> region by restricted-dma-pool in the device tree.
> >>>
> >>> If this goes into DT, I think we should be able to use dma-ranges for
> >>> this purpose instead. Normally, 'dma-ranges' is for physical bus
> >>> restrictions, but there's no reason it can't be used for policy or to
> >>> express restrictions the firmware has enabled.
> >>
> >> There would still need to be some way to tell SWIOTLB to pick up the
> >> corresponding chunk of memory and to prevent the kernel from using it
> >> for anything else, though.
> >
> > Don't we already have that problem if dma-ranges had a very small
> > range? We just get lucky because the restriction is generally much
> > more RAM than needed.
>
> Not really - if a device has a naturally tiny addressing capability that
> doesn't even cover ZONE_DMA32 where the regular SWIOTLB buffer will be
> allocated then it's unlikely to work well, but that's just crap system
> design. Yes, memory pressure in ZONE_DMA{32} is particularly problematic
> for such limited devices, but it's irrelevant to the issue at hand here.

Yesterday's crap system design is today's security feature. Couldn't
this feature make crap system design work better?

> What we have here is a device that's not allowed to see *kernel* memory
> at all. It's been artificially constrained to a particular region by a
> TZASC or similar, and the only data which should ever be placed in that

May have been constrained, but that's entirely optional.

In the optional case where the setup is entirely up to the OS, I don't
think this belongs in the DT at all. Perhaps that should be solved
first.

> region is data intended for that device to see. That way if it tries to
> go rogue it physically can't start slurping data intended for other
> devices or not mapped for DMA at all. The bouncing is an important part
> of this - I forget the title off-hand but there was an interesting paper
> a few years ago which demonstrated that even with an IOMMU, streaming
> DMA of in-place buffers could reveal enough adjacent data from the same
> page to mount an attack on the system. Memory pressure should be
> immaterial since the size of each bounce pool carveout will presumably
> be tuned for the needs of the given device.
>
> > In any case, wouldn't finding all the dma-ranges do this? We're
> > already walking the tree to find the max DMA address now.
>
> If all you can see are two "dma-ranges" properties, how do you propose
> to tell that one means "this is the extent of what I can address, please
> set my masks and dma-range-map accordingly and try to allocate things
> where I can reach them" while the other means "take this output range
> away from the page allocator and hook it up as my dedicated bounce pool,
> because it is Serious Security Time"? Especially since getting that
> choice wrong either way would be a Bad Thing.

Either we have some heuristic based on the size or we add some hint.
The point is let's build on what we already have for defining DMA
accessible memory in DT rather than some parallel mechanism.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool

2021-01-20 Thread Rob Herring
On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy  wrote:
>
> On 2021-01-20 16:53, Rob Herring wrote:
> > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> >> Introduce the new compatible string, restricted-dma-pool, for restricted
> >> DMA. One can specify the address and length of the restricted DMA memory
> >> region by restricted-dma-pool in the device tree.
> >
> > If this goes into DT, I think we should be able to use dma-ranges for
> > this purpose instead. Normally, 'dma-ranges' is for physical bus
> > restrictions, but there's no reason it can't be used for policy or to
> > express restrictions the firmware has enabled.
>
> There would still need to be some way to tell SWIOTLB to pick up the
> corresponding chunk of memory and to prevent the kernel from using it
> for anything else, though.

Don't we already have that problem if dma-ranges had a very small
range? We just get lucky because the restriction is generally much
more RAM than needed.

In any case, wouldn't finding all the dma-ranges do this? We're
already walking the tree to find the max DMA address now.

> >> Signed-off-by: Claire Chang 
> >> ---
> >>   .../reserved-memory/reserved-memory.txt   | 24 +++
> >>   1 file changed, 24 insertions(+)
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> >> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> >> index e8d3096d922c..44975e2a1fd2 100644
> >> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> >> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> >> @@ -51,6 +51,20 @@ compatible (optional) - standard definition
> >> used as a shared pool of DMA buffers for a set of devices. It 
> >> can
> >> be used by an operating system to instantiate the necessary 
> >> pool
> >> management subsystem if necessary.
> >> +- restricted-dma-pool: This indicates a region of memory meant to 
> >> be
> >> +  used as a pool of restricted DMA buffers for a set of devices. 
> >> The
> >> +  memory region would be the only region accessible to those 
> >> devices.
> >> +  When using this, the no-map and reusable properties must not be 
> >> set,
> >> +  so the operating system can create a virtual mapping that will 
> >> be used
> >> +  for synchronization. The main purpose for restricted DMA is to
> >> +  mitigate the lack of DMA access control on systems without an 
> >> IOMMU,
> >> +  which could result in the DMA accessing the system memory at
> >> +  unexpected times and/or unexpected addresses, possibly leading 
> >> to data
> >> +  leakage or corruption. The feature on its own provides a basic 
> >> level
> >> +  of protection against the DMA overwriting buffer contents at
> >> +  unexpected times. However, to protect against general data 
> >> leakage and
> >> +  system memory corruption, the system needs to provide way to 
> >> restrict
> >> +  the DMA to a predefined memory region.
> >>   - vendor specific string in the form ,[-]
> >>   no-map (optional) - empty property
> >>   - Indicates the operating system must not create a virtual mapping
> >> @@ -120,6 +134,11 @@ one for multimedia processing (named 
> >> multimedia-memory@7700, 64MiB).
> >>  compatible = "acme,multimedia-memory";
> >>  reg = <0x7700 0x400>;
> >>  };
> >> +
> >> +restricted_dma_mem_reserved: restricted_dma_mem_reserved {
> >> +compatible = "restricted-dma-pool";
> >> +reg = <0x5000 0x40>;
> >> +};
> >>  };
> >>
> >>  /* ... */
> >> @@ -138,4 +157,9 @@ one for multimedia processing (named 
> >> multimedia-memory@7700, 64MiB).
> >>  memory-region = <_reserved>;
> >>  /* ... */
> >>  };
> >> +
> >> +pcie_device: pcie_device@0,0 {
> >> +memory-region = <_dma_mem_reserved>;
> >
> > PCI hosts often have inbound window configurations that limit the
> > address range and translate PCI to bus addresses. Those wind

Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool

2021-01-20 Thread Rob Herring
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the device tree.

If this goes into DT, I think we should be able to use dma-ranges for 
this purpose instead. Normally, 'dma-ranges' is for physical bus 
restrictions, but there's no reason it can't be used for policy or to 
express restrictions the firmware has enabled.

> Signed-off-by: Claire Chang 
> ---
>  .../reserved-memory/reserved-memory.txt   | 24 +++
>  1 file changed, 24 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index e8d3096d922c..44975e2a1fd2 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -51,6 +51,20 @@ compatible (optional) - standard definition
>used as a shared pool of DMA buffers for a set of devices. It can
>be used by an operating system to instantiate the necessary pool
>management subsystem if necessary.
> +- restricted-dma-pool: This indicates a region of memory meant to be
> +  used as a pool of restricted DMA buffers for a set of devices. The
> +  memory region would be the only region accessible to those devices.
> +  When using this, the no-map and reusable properties must not be 
> set,
> +  so the operating system can create a virtual mapping that will be 
> used
> +  for synchronization. The main purpose for restricted DMA is to
> +  mitigate the lack of DMA access control on systems without an 
> IOMMU,
> +  which could result in the DMA accessing the system memory at
> +  unexpected times and/or unexpected addresses, possibly leading to 
> data
> +  leakage or corruption. The feature on its own provides a basic 
> level
> +  of protection against the DMA overwriting buffer contents at
> +  unexpected times. However, to protect against general data leakage 
> and
> +  system memory corruption, the system needs to provide way to 
> restrict
> +  the DMA to a predefined memory region.
>  - vendor specific string in the form ,[-]
>  no-map (optional) - empty property
>  - Indicates the operating system must not create a virtual mapping
> @@ -120,6 +134,11 @@ one for multimedia processing (named 
> multimedia-memory@7700, 64MiB).
>   compatible = "acme,multimedia-memory";
>   reg = <0x7700 0x400>;
>   };
> +
> + restricted_dma_mem_reserved: restricted_dma_mem_reserved {
> + compatible = "restricted-dma-pool";
> + reg = <0x5000 0x40>;
> + };
>   };
>  
>   /* ... */
> @@ -138,4 +157,9 @@ one for multimedia processing (named 
> multimedia-memory@7700, 64MiB).
>   memory-region = <_reserved>;
>   /* ... */
>   };
> +
> + pcie_device: pcie_device@0,0 {
> + memory-region = <_dma_mem_reserved>;

PCI hosts often have inbound window configurations that limit the 
address range and translate PCI to bus addresses. Those windows happen 
to be configured by dma-ranges. In any case, wouldn't you want to put 
the configuration in the PCI host node? Is there a usecase of 
restricting one PCIe device and not another? 

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v6 06/33] of/device: Move dma_range_map before of_iommu_configure

2021-01-14 Thread Rob Herring
On Mon, Jan 11, 2021 at 07:18:47PM +0800, Yong Wu wrote:
> "dev->dma_range_map" contains the devices' dma_ranges information,
> This patch moves dma_range_map before of_iommu_configure. The iommu
> driver may need to know the dma_address requirements of its iommu
> consumer devices.
> 
> CC: Rob Herring 
> CC: Frank Rowand 
> Signed-off-by: Yong Wu 
> ---
>  drivers/of/device.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index aedfaaafd3e7..1d84636149df 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -170,9 +170,11 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>   dev_dbg(dev, "device is%sdma coherent\n",
>   coherent ? " " : " not ");
>  
> + dev->dma_range_map = map;
>   iommu = of_iommu_configure(dev, np, id);
>   if (PTR_ERR(iommu) == -EPROBE_DEFER) {
>   kfree(map);
> + dev->dma_range_map = NULL;

Not really going to matter, but you should probably clear dma_range_map 
before what it points to is freed.

With that,

Reviewed-by: Rob Herring 

>   return -EPROBE_DEFER;
>   }
>  
> @@ -181,7 +183,6 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>  
>   arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>  
> - dev->dma_range_map = map;
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_configure_id);
> -- 
> 2.18.0
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH 1/2] dt-bindings: iommu: add bindings for sprd iommu

2021-01-13 Thread Rob Herring
On Fri, Jan 8, 2021 at 5:34 AM Chunyan Zhang  wrote:
>
> On Fri, 8 Jan 2021 at 10:25, Rob Herring  wrote:
> >
> > On Wed, Dec 23, 2020 at 07:16:32PM +0800, Chunyan Zhang wrote:
> > > From: Chunyan Zhang 
> > >
> > > This patch only adds bindings to support display iommu, support for others
> > > would be added once finished tests with those devices, such as Image
> > > codec(jpeg) processor, a few signal processors, including VSP(video),
> > > GSP(graphic), ISP(image), and camera CPP, etc.
> > >
> > > Signed-off-by: Chunyan Zhang 
> > > ---
> > >  .../devicetree/bindings/iommu/sprd,iommu.yaml | 44 +++
> > >  1 file changed, 44 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml 
> > > b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > new file mode 100644
> > > index ..4d9a578a7cc9
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > @@ -0,0 +1,44 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +# Copyright 2020 Unisoc Inc.
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Unisoc IOMMU and Multi-media MMU
> > > +
> > > +maintainers:
> > > +  - Chunyan Zhang 
> > > +
> > > +properties:
> > > +  compatible:
> > > +enum:
> > > +  - sprd,iommu-disp
> >
> > Needs to be Soc specific.
>
> All SoCs so far use the same iommu IP, there's a little different
> among different iommu users.

That's what everyone says. Be warned that you cannot add properties
for any differences that come up whether features or errata.

> > Is this block specific to display subsys or
> > that just happens to be where the instance is?
>
> This iommu driver can serve many subsystem devices, such as Video,
> Camera, Image, etc., but they have their own iommu module which looks
> like a subdevice embedded in the master devices.
> I will add more compatible strings for those devices when needed.
> For now, only this one was listed here because I just tested this
> iommu driver with DPU only.

The iommu binding takes care of what each one is connected to. Is each
instance different in terms of features or programming model? If not,
then you shouldn't have different compatible strings for each
instance.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/2] dt-bindings: arm-smmu: Add binding for Qcom SDX55 SMMU

2021-01-12 Thread Rob Herring
On Thu, 07 Jan 2021 20:01:18 +0530, Manivannan Sadhasivam wrote:
> Add devicetree binding for Qualcomm SDX55 SMMU.
> 
> Cc: Will Deacon 
> Cc: Robin Murphy 
> Cc: Joerg Roedel 
> Cc: iommu@lists.linux-foundation.org
> Signed-off-by: Manivannan Sadhasivam 
> Reviewed-by: Vinod Koul 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH 1/2] dt-bindings: iommu: add bindings for sprd iommu

2021-01-07 Thread Rob Herring
On Wed, Dec 23, 2020 at 07:16:32PM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang 
> 
> This patch only adds bindings to support display iommu, support for others
> would be added once finished tests with those devices, such as Image
> codec(jpeg) processor, a few signal processors, including VSP(video),
> GSP(graphic), ISP(image), and camera CPP, etc.
> 
> Signed-off-by: Chunyan Zhang 
> ---
>  .../devicetree/bindings/iommu/sprd,iommu.yaml | 44 +++
>  1 file changed, 44 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml 
> b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> new file mode 100644
> index ..4d9a578a7cc9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2020 Unisoc Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc IOMMU and Multi-media MMU
> +
> +maintainers:
> +  - Chunyan Zhang 
> +
> +properties:
> +  compatible:
> +enum:
> +  - sprd,iommu-disp

Needs to be Soc specific. Is this block specific to display subsys or 
that just happens to be where the instance is?

> +
> +  reg:
> +maxItems: 1
> +
> +  "#iommu-cells":
> +const: 0
> +description:
> +  Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> +  additional information needs to associate with its master device.
> +  Please refer to the generic bindings document for more details,
> +  Documentation/devicetree/bindings/iommu/iommu.txt
> +
> +required:
> +  - compatible
> +  - reg
> +  - "#iommu-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +iommu_disp: iommu@6300 {
> +  compatible = "sprd,iommu-disp";
> +  reg = <0x6300 0x880>;
> +  #iommu-cells = <0>;
> +};
> +
> +...
> -- 
> 2.25.1
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-12-18 Thread Rob Herring
On Thu, Dec 17, 2020 at 9:00 AM Thierry Reding  wrote:
>
> On Tue, Nov 10, 2020 at 08:33:09PM +0100, Thierry Reding wrote:
> > On Fri, Nov 06, 2020 at 04:25:48PM +0100, Thierry Reding wrote:
> > > On Thu, Nov 05, 2020 at 05:47:21PM +, Robin Murphy wrote:
> > > > On 2020-11-05 16:43, Thierry Reding wrote:
> > > > > On Thu, Sep 24, 2020 at 01:27:25PM +0200, Thierry Reding wrote:
> > > > > > On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote:
> > > > > > > On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote:
> > > > > > > > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote:
> > > > > > > > > From: Thierry Reding 
> > > > > > > > >
> > > > > > > > > Reserved memory regions can be marked as "active" if hardware 
> > > > > > > > > is
> > > > > > > > > expected to access the regions during boot and before the 
> > > > > > > > > operating
> > > > > > > > > system can take control. One example where this is useful is 
> > > > > > > > > for the
> > > > > > > > > operating system to infer whether the region needs to be 
> > > > > > > > > identity-
> > > > > > > > > mapped through an IOMMU.
> > > > > > > >
> > > > > > > > I like simple solutions, but this hardly seems adequate to 
> > > > > > > > solve the
> > > > > > > > problem of passing IOMMU setup from bootloader/firmware to the 
> > > > > > > > OS. Like
> > > > > > > > what is the IOVA that's supposed to be used if identity mapping 
> > > > > > > > is not
> > > > > > > > used?
> > > > > > >
> > > > > > > The assumption here is that if the region is not active there is 
> > > > > > > no need
> > > > > > > for the IOVA to be specified because the kernel will allocate 
> > > > > > > memory and
> > > > > > > assign any IOVA of its choosing.
> > > > > > >
> > > > > > > Also, note that this is not meant as a way of passing IOMMU setup 
> > > > > > > from
> > > > > > > the bootloader or firmware to the OS. The purpose of this is to 
> > > > > > > specify
> > > > > > > that some region of memory is actively being accessed during 
> > > > > > > boot. The
> > > > > > > particular case that I'm looking at is where the bootloader set 
> > > > > > > up a
> > > > > > > splash screen and keeps it on during boot. The bootloader has not 
> > > > > > > set up
> > > > > > > an IOMMU mapping and the identity mapping serves as a way of 
> > > > > > > keeping the
> > > > > > > accesses by the display hardware working during the transitional 
> > > > > > > period
> > > > > > > after the IOMMU translations have been enabled by the kernel but 
> > > > > > > before
> > > > > > > the kernel display driver has had a chance to set up its own IOMMU
> > > > > > > mappings.
> > > > > > >
> > > > > > > > If you know enough about the regions to assume identity 
> > > > > > > > mapping, then
> > > > > > > > can't you know if active or not?
> > > > > > >
> > > > > > > We could alternatively add some property that describes the 
> > > > > > > region as
> > > > > > > requiring an identity mapping. But note that we can't make any
> > > > > > > assumptions here about the usage of these regions because the 
> > > > > > > IOMMU
> > > > > > > driver simply has no way of knowing what they are being used for.
> > > > > > >
> > > > > > > Some additional information is required in device tree for the 
> > > > > > > IOMMU
> > > > > > > driver to be able to make that decision.
> > > > > >
> > > > > > Rob, can you provide any hints on exactly how you want to move this
> > > > > > forward? 

Re: [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file

2020-12-10 Thread Rob Herring
On Wed, 09 Dec 2020 16:00:40 +0800, Yong Wu wrote:
> Only rename the header guard for all the SoC larb port header file.
> No funtional change.
> 
> Suggested-by: Krzysztof Kozlowski 
> Signed-off-by: Yong Wu 
> ---
>  include/dt-bindings/memory/mt2701-larb-port.h | 4 ++--
>  include/dt-bindings/memory/mt2712-larb-port.h | 4 ++--
>  include/dt-bindings/memory/mt6779-larb-port.h | 4 ++--
>  include/dt-bindings/memory/mt8167-larb-port.h | 4 ++--
>  include/dt-bindings/memory/mt8173-larb-port.h | 4 ++--
>  include/dt-bindings/memory/mt8183-larb-port.h | 4 ++--
>  6 files changed, 12 insertions(+), 12 deletions(-)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 04/24] dt-bindings: memory: mediatek: Add domain definition

2020-11-16 Thread Rob Herring
On Wed, 11 Nov 2020 20:38:18 +0800, Yong Wu wrote:
> In the latest SoC, there are several HW IP require a sepecial iova
> range, mainly CCU and VPU has this requirement. Take CCU as a example,
> CCU require its iova locate in the range(0x4000_ ~ 0x43ff_).
> 
> In this patch we add a domain definition for the special port. In the
> example of CCU, If we preassign CCU port in domain1, then iommu driver
> will prepare a independent iommu domain of the special iova range for it,
> then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special
> range.
> 
> This is a preparing patch for multi-domain support.
> 
> Signed-off-by: Yong Wu 
> ---
>  include/dt-bindings/memory/mtk-smi-larb-port.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 01/24] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema

2020-11-16 Thread Rob Herring
On Wed, 11 Nov 2020 20:38:15 +0800, Yong Wu wrote:
> Convert MediaTek IOMMU to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.txt | 105 ---
>  .../bindings/iommu/mediatek,iommu.yaml| 167 ++
>  2 files changed, 167 insertions(+), 105 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 1/3] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-11-05 Thread Rob Herring
On Tue, 03 Nov 2020 13:41:58 +0800, Yong Wu wrote:
> Convert MediaTek SMI to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.txt   |  50 ---
>  .../mediatek,smi-common.yaml  | 140 ++
>  .../memory-controllers/mediatek,smi-larb.txt  |  50 ---
>  .../memory-controllers/mediatek,smi-larb.yaml | 130 
>  4 files changed, 270 insertions(+), 100 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 3/7] of/address: Introduce of_dma_get_max_cpu_address()

2020-11-02 Thread Rob Herring
On Thu, Oct 29, 2020 at 12:26 PM Nicolas Saenz Julienne
 wrote:
>
> Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> physical address addressable by all DMA masters in the system. It's
> specially useful for setting memory zones sizes at early boot time.
>
> Signed-off-by: Nicolas Saenz Julienne 
>
> ---
>
> Changes since v4:
>  - Return max address, not address limit (one-off difference)
>
> Changes since v3:
>  - use u64 with cpu_end
>
> Changes since v2:
>  - Use PHYS_ADDR_MAX
>  - return phys_dma_t
>  - Rename function
>  - Correct subject
>  - Add support to start parsing from an arbitrary device node in order
>for the function to work with unit tests
>
>  drivers/of/address.c | 42 ++
>  include/linux/of.h   |  7 +++
>  2 files changed, 49 insertions(+)

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 1/3] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-30 Thread Rob Herring
On Fri, 30 Oct 2020 17:12:52 +0800, Yong Wu wrote:
> Convert MediaTek SMI to DT schema.
> 
> CC: Fabien Parent 
> CC: Ming-Fan Chen 
> CC: Matthias Brugger 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.txt   |  50 ---
>  .../mediatek,smi-common.yaml  | 140 ++
>  .../memory-controllers/mediatek,smi-larb.txt  |  50 ---
>  .../memory-controllers/mediatek,smi-larb.yaml | 129 
>  4 files changed, 269 insertions(+), 100 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml:84:8:
 [warning] wrong indentation: expected 6 but found 7 (indentation)
./Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml:98:13:
 [warning] wrong indentation: expected 10 but found 12 (indentation)
./Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml:41:8:
 [warning] wrong indentation: expected 6 but found 7 (indentation)

dtschema/dtc warnings/errors:


See https://patchwork.ozlabs.org/patch/1390887

The base for the patch is generally the last rc1. Any dependencies
should be noted.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 4/7] of: unittest: Add test for of_dma_get_max_cpu_address()

2020-10-26 Thread Rob Herring
On Wed, 21 Oct 2020 14:34:34 +0200, Nicolas Saenz Julienne wrote:
> Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
> data as the rest of dma-ranges unit tests.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> 
> ---
> Changes since v3:
>  - Remove HAS_DMA guards
> 
>  drivers/of/unittest.c | 18 ++
>  1 file changed, 18 insertions(+)
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-16 Thread Rob Herring
On Thu, Oct 15, 2020 at 12:42 AM Christoph Hellwig  wrote:
>
> > +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
> > +{
> > + phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
> > + struct of_range_parser parser;
> > + phys_addr_t subtree_max_addr;
> > + struct device_node *child;
> > + phys_addr_t cpu_end = 0;
> > + struct of_range range;
> > + const __be32 *ranges;
> > + int len;
> > +
> > + if (!np)
> > + np = of_root;
>
> Requiring of_root to be passed explicitly would seem more natural
> to me than the magic NULL argument.  There doesn't seem to be any
> precedent for that kind of calling convention either.

I prefer that of_root is not more widely exposed and NULL regularly
means 'the whole tree'.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 4/8] of: unittest: Add test for of_dma_get_max_cpu_address()

2020-10-14 Thread Rob Herring
On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
 wrote:
>
> Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
> data as the rest of dma-ranges unit tests.
>
> Signed-off-by: Nicolas Saenz Julienne 
> ---
>  drivers/of/unittest.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 06cc988faf78..2cbf2a585c9f 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -869,6 +869,25 @@ static void __init of_unittest_changeset(void)
>  #endif
>  }
>
> +static void __init of_unittest_dma_get_max_cpu_address(void)
> +{
> +#ifdef CONFIG_HAS_DMA

Can't the unittest run without this? I run the unittests under UML.

> +   struct device_node *np;
> +   phys_addr_t cpu_addr;
> +
> +   np = of_find_node_by_path("/testcase-data/address-tests");
> +   if (!np) {
> +   pr_err("missing testcase data\n");
> +   return;
> +   }
> +
> +   cpu_addr = of_dma_get_max_cpu_address(np);
> +   unittest(cpu_addr == 0x5000ULL,
> +"of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting 
> %llx)\n",
> +_addr, 0x5000ULL);
> +#endif
> +}
> +
>  static void __init of_unittest_dma_ranges_one(const char *path,
> u64 expect_dma_addr, u64 expect_paddr)
>  {
> @@ -3266,6 +3285,7 @@ static int __init of_unittest(void)
> of_unittest_changeset();
> of_unittest_parse_interrupts();
> of_unittest_parse_interrupts_extended();
> +   of_unittest_dma_get_max_cpu_address();
> of_unittest_parse_dma_ranges();
> of_unittest_pci_dma_ranges();
> of_unittest_match_node();
> --
> 2.28.0
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-14 Thread Rob Herring
On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
 wrote:
>
> Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> physical address addressable by all DMA masters in the system. It's
> specially useful for setting memory zones sizes at early boot time.
>
> Signed-off-by: Nicolas Saenz Julienne 
>
> ---
>
> Changes since v2:
>  - Use PHYS_ADDR_MAX
>  - return phys_dma_t
>  - Rename function
>  - Correct subject
>  - Add support to start parsing from an arbitrary device node in order
>for the function to work with unit tests
>
>  drivers/of/address.c | 42 ++
>  include/linux/of.h   |  7 +++
>  2 files changed, 49 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index eb9ab4f1e80b..b5a9695aaf82 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -1024,6 +1024,48 @@ int of_dma_get_range(struct device_node *np, const 
> struct bus_dma_region **map)
>  }
>  #endif /* CONFIG_HAS_DMA */
>
> +/**
> + * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
> + * @np: The node to start searching from or NULL to start from the root
> + *
> + * Gets the highest CPU physical address that is addressable by all DMA 
> masters
> + * in the system (or subtree when np is non-NULL). If no DMA constrained 
> device
> + * is found, it returns PHYS_ADDR_MAX.
> + */
> +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
> +{
> +   phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;

One issue with using phys_addr_t is it may be 32-bit even though the
DT is 64-bit addresses. LPAE capable system with LPAE disabled. Maybe
the truncation is fine here? Maybe not.

> +   struct of_range_parser parser;
> +   phys_addr_t subtree_max_addr;
> +   struct device_node *child;
> +   phys_addr_t cpu_end = 0;
> +   struct of_range range;
> +   const __be32 *ranges;
> +   int len;
> +
> +   if (!np)
> +   np = of_root;
> +
> +   ranges = of_get_property(np, "dma-ranges", );

I'm not really following why you changed the algorithm here. You're
skipping disabled nodes which is good. Was there some other reason?

> +   if (ranges && len) {
> +   of_dma_range_parser_init(, np);
> +   for_each_of_range(, )
> +   if (range.cpu_addr + range.size > cpu_end)
> +   cpu_end = range.cpu_addr + range.size;
> +
> +   if (max_cpu_addr > cpu_end)
> +   max_cpu_addr = cpu_end;
> +   }
> +
> +   for_each_available_child_of_node(np, child) {
> +   subtree_max_addr = of_dma_get_max_cpu_address(child);
> +   if (max_cpu_addr > subtree_max_addr)
> +   max_cpu_addr = subtree_max_addr;
> +   }
> +
> +   return max_cpu_addr;
> +}
> +
>  /**
>   * of_dma_is_coherent - Check if device is coherent
>   * @np:device node
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 481ec0467285..db8db8f2c967 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -558,6 +558,8 @@ int of_map_id(struct device_node *np, u32 id,
>const char *map_name, const char *map_mask_name,
>struct device_node **target, u32 *id_out);
>
> +phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
> +
>  #else /* CONFIG_OF */
>
>  static inline void of_core_init(void)
> @@ -995,6 +997,11 @@ static inline int of_map_id(struct device_node *np, u32 
> id,
> return -EINVAL;
>  }
>
> +static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
> +{
> +   return PHYS_ADDR_MAX;
> +}
> +
>  #define of_match_ptr(_ptr) NULL
>  #define of_match_node(_matches, _node) NULL
>  #endif /* CONFIG_OF */
> --
> 2.28.0
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 2/5] of/address: Introduce of_dma_lower_bus_limit()

2020-10-14 Thread Rob Herring
On Wed, Oct 14, 2020 at 6:52 AM Nicolas Saenz Julienne
 wrote:
>
> Hi Rob,
>
> On Mon, 2020-10-12 at 10:25 -0500, Rob Herring wrote:
> > On Sat, Oct 10, 2020 at 10:12 AM Nicolas Saenz Julienne
> >  wrote:
> > > The function provides the CPU physical address addressable by the most
> > > constrained bus in the system. It might be useful in order to
> > > dynamically set up memory zones during boot.
> > >
> > > Signed-off-by: Nicolas Saenz Julienne 
> > > ---
> > >  drivers/of/address.c | 34 ++
> > >  include/linux/of.h   |  7 +++
> > >  2 files changed, 41 insertions(+)
> > >
> > > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > > index eb9ab4f1e80b..755e97b65096 100644
> > > --- a/drivers/of/address.c
> > > +++ b/drivers/of/address.c
> > > @@ -1024,6 +1024,40 @@ int of_dma_get_range(struct device_node *np, const 
> > > struct bus_dma_region **map)
> > >  }
> > >  #endif /* CONFIG_HAS_DMA */
> > >
> > > +/**
> > > + * of_dma_safe_phys_limit - Get system wide DMA safe address space
> > > + *
> > > + * Gets the CPU physical address limit for safe DMA addressing system 
> > > wide by
> > > + * searching for the most constraining dma-range. Otherwise it returns 
> > > ~0ULL.
> > > + */
> > > +u64 __init of_dma_safe_phys_limit(void)
> > > +{
> > > +   struct device_node *np = NULL;
> > > +   struct of_range_parser parser;
> > > +   const __be32 *ranges = NULL;
> > > +   u64 phys_dma_limit = ~0ULL;
> > > +   struct of_range range;
> > > +   int len;
> > > +
> > > +   for_each_of_allnodes(np) {
> > > +   dma_addr_t cpu_end = 0;
> > > +
> > > +   ranges = of_get_property(np, "dma-ranges", );
> > > +   if (!ranges || !len)
> > > +   continue;
> > > +
> > > +   of_dma_range_parser_init(, np);
> > > +   for_each_of_range(, )
> > > +   if (range.cpu_addr + range.size > cpu_end)
> > > +   cpu_end = range.cpu_addr + range.size;
> >
> > This doesn't work if you have more than one level of dma-ranges. The
> > address has to be translated first. It should be okay to do that on
> > the start or end address (if not, your DT is broken).
>
> for_each_of_range() calls of_pci_range_parser_one() which utimately populates
> range.cpu_addr with of_translate_dma_address() results. Isn't that good 
> enough?

Indeed. I guess I was remembering the cases not using
for_each_of_range which forgot to do that...

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 2/5] of/address: Introduce of_dma_lower_bus_limit()

2020-10-12 Thread Rob Herring
On Sat, Oct 10, 2020 at 10:12 AM Nicolas Saenz Julienne
 wrote:
>
> The function provides the CPU physical address addressable by the most
> constrained bus in the system. It might be useful in order to
> dynamically set up memory zones during boot.
>
> Signed-off-by: Nicolas Saenz Julienne 
> ---
>  drivers/of/address.c | 34 ++
>  include/linux/of.h   |  7 +++
>  2 files changed, 41 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index eb9ab4f1e80b..755e97b65096 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -1024,6 +1024,40 @@ int of_dma_get_range(struct device_node *np, const 
> struct bus_dma_region **map)
>  }
>  #endif /* CONFIG_HAS_DMA */
>
> +/**
> + * of_dma_safe_phys_limit - Get system wide DMA safe address space
> + *
> + * Gets the CPU physical address limit for safe DMA addressing system wide by
> + * searching for the most constraining dma-range. Otherwise it returns ~0ULL.
> + */
> +u64 __init of_dma_safe_phys_limit(void)
> +{
> +   struct device_node *np = NULL;
> +   struct of_range_parser parser;
> +   const __be32 *ranges = NULL;
> +   u64 phys_dma_limit = ~0ULL;
> +   struct of_range range;
> +   int len;
> +
> +   for_each_of_allnodes(np) {
> +   dma_addr_t cpu_end = 0;
> +
> +   ranges = of_get_property(np, "dma-ranges", );
> +   if (!ranges || !len)
> +   continue;
> +
> +   of_dma_range_parser_init(, np);
> +   for_each_of_range(, )
> +   if (range.cpu_addr + range.size > cpu_end)
> +   cpu_end = range.cpu_addr + range.size;

This doesn't work if you have more than one level of dma-ranges. The
address has to be translated first. It should be okay to do that on
the start or end address (if not, your DT is broken).

Please add/extend a unittest for this.

> +
> +   if (phys_dma_limit > cpu_end)
> +   phys_dma_limit = cpu_end;
> +   }
> +
> +   return phys_dma_limit;
> +}
> +
>  /**
>   * of_dma_is_coherent - Check if device is coherent
>   * @np:device node
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 481ec0467285..958c64cffa92 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -558,6 +558,8 @@ int of_map_id(struct device_node *np, u32 id,
>const char *map_name, const char *map_mask_name,
>struct device_node **target, u32 *id_out);
>
> +u64 of_dma_safe_phys_limit(void);
> +
>  #else /* CONFIG_OF */
>
>  static inline void of_core_init(void)
> @@ -995,6 +997,11 @@ static inline int of_map_id(struct device_node *np, u32 
> id,
> return -EINVAL;
>  }
>
> +static inline u64 of_dma_safe_phys_limit(void)
> +{
> +   return ~0ULL;
> +}
> +
>  #define of_match_ptr(_ptr) NULL
>  #define of_match_node(_matches, _node) NULL
>  #endif /* CONFIG_OF */
> --
> 2.28.0
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

2020-10-01 Thread Rob Herring
On Thu, Oct 1, 2020 at 12:31 PM Nicolas Saenz Julienne
 wrote:
>
> On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> > On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> > > Hi Nicolas,
> > >
> > > Thanks for putting this together.
> > >
> > > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> > > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > > > index 4602e467ca8b..cd0d115ef329 100644
> > > > --- a/drivers/of/fdt.c
> > > > +++ b/drivers/of/fdt.c
> > > > @@ -25,6 +25,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include /* for zone_dma_bits */
> > > >
> > > >  #include   /* for COMMAND_LINE_SIZE */
> > > >  #include 
> > > > @@ -1198,6 +1199,14 @@ void __init early_init_dt_scan_nodes(void)
> > > >   of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> > > >  }
> > > >
> > > > +void __init early_init_dt_update_zone_dma_bits(void)
> > > > +{
> > > > + unsigned long dt_root = of_get_flat_dt_root();
> > > > +
> > > > + if (of_flat_dt_is_compatible(dt_root, "brcm,bcm2711"))
> > > > + zone_dma_bits = 30;
> > > > +}
> > >
> > > I think we could keep this entirely in the arm64 setup_machine_fdt() and
> > > not pollute the core code with RPi4-specific code.
> >
> > Actually, even better, could we not move the check to
> > arm64_memblock_init() when we initialise zone_dma_bits?
>
> I did it this way as I vaguely remembered Rob saying he wanted to centralise
> all early boot fdt code in one place. But I'll be happy to move it there.

Right, unless zone_dma_bits is only an arm64 thing, then this doesn't
really have anything arch specific.

Reviewed-by: Rob Herring 

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 01/23] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema

2020-09-18 Thread Rob Herring
On Mon, Sep 14, 2020 at 11:51 PM Yong Wu  wrote:
>
> On Mon, 2020-09-14 at 17:22 -0600, Rob Herring wrote:
> > On Sat, Sep 05, 2020 at 04:08:58PM +0800, Yong Wu wrote:
> > > Convert MediaTek IOMMU to DT schema.
> > >
> > > Signed-off-by: Yong Wu 
> > > ---
>
> [...]
>
> > > +properties:
> > > +  compatible:
> > > +enum:
> > > +  - mediatek,mt2701-m4u #mt2701 generation one HW
> > > +  - mediatek,mt2712-m4u #mt2712 generation two HW
> > > +  - mediatek,mt6779-m4u #mt6779 generation two HW
> > > +  - mediatek,mt7623-m4u, mediatek,mt2701-m4u #mt7623 generation one 
> > > HW
> >
> > This is not right.
> >
> > items:
> >   - const: mediatek,mt7623-m4u
> >   - const: mediatek,mt2701-m4u
> >
> > And that has to be under a 'oneOf' with the rest of this.
>
> Thanks for the review. Is this OK?
>
>   compatible:
> oneOf:
>   - const: mediatek,mt2701-m4u # mt2701 generation one HW
>   - const: mediatek,mt2712-m4u # mt2712 generation two HW
>   - const: mediatek,mt6779-m4u # mt6779 generation two HW
>   - const: mediatek,mt8173-m4u # mt8173 generation two HW
>   - const: mediatek,mt8183-m4u # mt8183 generation two HW
>   - const: mediatek,mt8192-m4u # mt8192 generation two HW

It is correct, but I prefer all these to be a single enum. So 'oneOf'
would have 2 entries.

>   - description: mt7623 generation one HW
> items:
>   - const: mediatek,mt7623-m4u
>   - const: mediatek,mt2701-m4u
>
> >
> > > +  - mediatek,mt8173-m4u #mt8173 generation two HW
> > > +  - mediatek,mt8183-m4u #mt8183 generation two HW
> > > +
> > > +  reg:
> > > +maxItems: 1
>
> [snip]
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] drm: panfrost: Coherency support

2020-09-16 Thread Rob Herring
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
 wrote:
>
> > So I get a performance regression with the dma-coherent approach, even if 
> > it's
> > clearly the cleaner.
>
> That's bizarre -- this should really be the faster of the two.

Coherency may not be free. CortexA9 had something like 4x slower
memcpy if SMP was enabled as an example. I don't know if there's
anything going on like that specifically here. If there's never any
CPU accesses mixed in with kmscube, then there would be no benefit to
coherency.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 06/23] dt-bindings: mediatek: Add binding for mt8192 IOMMU and SMI

2020-09-14 Thread Rob Herring
On Sat, 05 Sep 2020 16:09:03 +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
> 
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
> 
>   EMI
>|
>   M4U
>|
>   
>SMI Common
>   
>|
>   +---+--+--+--+---+
>   |   |  |  |   .. |   |
>   |   |  |  |  |   |
> larb0   larb1  larb2  larb4 ..  larb19   larb20
> disp0   disp1   mdpvdec   IPE  IPE
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> mt8192 M4U support 0~16GB iova range. we preassign different engines
> into different iova ranges:
> 
> domain-id  module iova-range  larbs
>0   disp0 ~ 4G  larb0/1
>1   vcodec  4G ~ 8G larb4/5/7
>2   cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>3   CCU00x4000_ ~ 0x43ff_ larb13: port 9/10
>4   CCU10x4400_ ~ 0x47ff_ larb14: port 4/5
> 
> The iova range for CCU0/1(camera control unit) is HW requirement.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml|   9 +-
>  .../mediatek,smi-common.yaml  |   5 +-
>  .../memory-controllers/mediatek,smi-larb.yaml |   3 +-
>  include/dt-bindings/memory/mt8192-larb-port.h | 239 ++
>  4 files changed, 251 insertions(+), 5 deletions(-)
>  create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> 

Reviewed-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 02/23] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-09-14 Thread Rob Herring
On Sat, Sep 05, 2020 at 04:08:59PM +0800, Yong Wu wrote:
> Convert MediaTek SMI to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.txt   | 49 --
>  .../mediatek,smi-common.yaml  | 96 +++
>  .../memory-controllers/mediatek,smi-larb.txt  | 49 --
>  .../memory-controllers/mediatek,smi-larb.yaml | 85 
>  4 files changed, 181 insertions(+), 98 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> deleted file mode 100644
> index b64573680b42..
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -SMI (Smart Multimedia Interface) Common
> -
> -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> -
> -Mediatek SMI have two generations of HW architecture, here is the list
> -which generation the SoCs use:
> -generation 1: mt2701 and mt7623.
> -generation 2: mt2712, mt6779, mt8173 and mt8183.
> -
> -There's slight differences between the two SMI, for generation 2, the
> -register which control the iommu port is at each larb's register base. But
> -for generation 1, the register is at smi ao base(smi always on register
> -base). Besides that, the smi async clock should be prepared and enabled for
> -SMI generation 1 to transform the smi clock into emi clock domain, but that 
> is
> -not needed for SMI generation 2.
> -
> -Required properties:
> -- compatible : must be one of :
> - "mediatek,mt2701-smi-common"
> - "mediatek,mt2712-smi-common"
> - "mediatek,mt6779-smi-common"
> - "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
> - "mediatek,mt8173-smi-common"
> - "mediatek,mt8183-smi-common"
> -- reg : the register and size of the SMI block.
> -- power-domains : a phandle to the power domain of this local arbiter.
> -- clocks : Must contain an entry for each entry in clock-names.
> -- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
> -  for generation 2 smi HW as follows:
> -  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> - the register.
> -  - "smi" : It's the clock for transfer data and command.
> - They may be the same if both source clocks are the same.
> -  - "async" : asynchronous clock, it help transform the smi clock into the 
> emi
> -   clock domain, this clock is only needed by generation 1 smi HW.
> -  and these 2 option clocks for generation 2 smi HW:
> -  - "gals0": the path0 clock of GALS(Global Async Local Sync).
> -  - "gals1": the path1 clock of GALS(Global Async Local Sync).
> -  Here is the list which has this GALS: mt6779 and mt8183.
> -
> -Example:
> - smi_common: smi@14022000 {
> - compatible = "mediatek,mt8173-smi-common";
> - reg = <0 0x14022000 0 0x1000>;
> - power-domains = < MT8173_POWER_DOMAIN_MM>;
> - clocks = < CLK_MM_SMI_COMMON>,
> -  < CLK_MM_SMI_COMMON>;
> - clock-names = "apb", "smi";
> - };
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> new file mode 100644
> index ..781d7b7617d9
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SMI (Smart Multimedia Interface) Common
> +
> +maintainers:
> +  - Yong Wu 
> +
> +description: |+
> +  The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml
> +
> +  MediaTek SMI have two generations of HW architecture, here is the list
> +  which generation the SoCs use:
> +  generation 1: mt2701 and mt7623.
> +  generation 2: mt2712, mt6779, mt8173 and mt8183.
> +
> +  There's slight differences between the two SMI, for generation 2, the
> +  register which control the iommu port is at each larb's register base. But
> +  for generation 1, the register is at smi ao base(smi always on register
> +  base). Besides that, the smi async clock should be prepared and enabled for
> +  SMI generation 1 to transform the smi clock into emi clock 

Re: [PATCH v2 01/23] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema

2020-09-14 Thread Rob Herring
On Sat, Sep 05, 2020 at 04:08:58PM +0800, Yong Wu wrote:
> Convert MediaTek IOMMU to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.txt | 103 
>  .../bindings/iommu/mediatek,iommu.yaml| 150 ++
>  2 files changed, 150 insertions(+), 103 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> deleted file mode 100644
> index c1ccd8582eb2..
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -* Mediatek IOMMU Architecture Implementation
> -
> -  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
> -this M4U have two generations of HW architecture. Generation one uses flat
> -pagetable, and only supports 4K size page mapping. Generation two uses the
> -ARM Short-Descriptor translation table format for address translation.
> -
> -  About the M4U Hardware Block Diagram, please check below:
> -
> -  EMI (External Memory Interface)
> -   |
> -  m4u (Multimedia Memory Management Unit)
> -   |
> -  ++
> -  ||
> -  gals0-rx   gals1-rx(Global Async Local Sync rx)
> -  ||
> -  ||
> -  gals0-tx   gals1-tx(Global Async Local Sync tx)
> -  ||  Some SoCs may have GALS.
> -  ++
> -   |
> -   SMI Common(Smart Multimedia Interface Common)
> -   |
> -   ++---
> -   ||
> -   | gals-rxThere may be GALS in some larbs.
> -   ||
> -   ||
> -   | gals-tx
> -   ||
> -   SMI larb0SMI larb1   ... SoCs have several SMI local 
> arbiter(larb).
> -   (display) (vdec)
> -   ||
> -   ||
> - +-+-+ +++
> - | | | |||
> - | | |...  |||  ... There are different ports in each larb.
> - | | | |||
> -OVL0 RDMA0 WDMA0  MC   PP   VLD
> -
> -  As above, The Multimedia HW will go through SMI and M4U while it
> -access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
> -smi local arbiter and smi common. It will control whether the Multimedia
> -HW should go though the m4u for translation or bypass it and talk
> -directly with EMI. And also SMI help control the power domain and clocks for
> -each local arbiter.
> -  Normally we specify a local arbiter(larb) for each multimedia HW
> -like display, video decode, and camera. And there are different ports
> -in each larb. Take a example, There are many ports like MC, PP, VLD in the
> -video decode local arbiter, all these ports are according to the video HW.
> -  In some SoCs, there may be a GALS(Global Async Local Sync) module between
> -smi-common and m4u, and additional GALS module between smi-larb and
> -smi-common. GALS can been seen as a "asynchronous fifo" which could help
> -synchronize for the modules in different clock frequency.
> -
> -Required properties:
> -- compatible : must be one of the following string:
> - "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
> - "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW.
> - "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW.
> - "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
> -  generation one m4u HW.
> - "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
> - "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
> -- reg : m4u register base and size.
> -- interrupts : the interrupt of m4u.
> -- clocks : must contain one entry for each clock-names.
> -- clock-names : Only 1 optional clock:
> -  - "bclk": the block clock of m4u.
> -  Here is the list which require this "bclk":
> -  - mt2701, mt2712, mt7623 and mt8173.
> -  Note that m4u use the EMI clock which always has been enabled before kernel
> -  if there is no this "bclk".
> -- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
> - Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
> - according to the local arbiter index, like larb0, larb1, larb2...
> -- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
> - Specifies the mtk_m4u_id as defined in
> - dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
> - dt-binding/memory/mt2712-larb-port.h for mt2712,
> - dt-binding/memory/mt6779-larb-port.h for mt6779,
> - 

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-09-14 Thread Rob Herring
On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Reserved memory regions can be marked as "active" if hardware is
> expected to access the regions during boot and before the operating
> system can take control. One example where this is useful is for the
> operating system to infer whether the region needs to be identity-
> mapped through an IOMMU.

I like simple solutions, but this hardly seems adequate to solve the 
problem of passing IOMMU setup from bootloader/firmware to the OS. Like 
what is the IOVA that's supposed to be used if identity mapping is not 
used?

If you know enough about the regions to assume identity mapping, then 
can't you know if active or not?

> Signed-off-by: Thierry Reding 
> ---
>  .../bindings/reserved-memory/reserved-memory.txt   | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index 4dd20de6977f..163d2927e4fc 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -63,6 +63,13 @@ reusable (optional) - empty property
>able to reclaim it back. Typically that means that the operating
>system can use that region to store volatile or cached data that
>can be otherwise regenerated or migrated elsewhere.
> +active (optional) - empty property
> +- If this property is set for a reserved memory region, it indicates
> +  that some piece of hardware may be actively accessing this region.
> +  Should the operating system want to enable IOMMU protection for a
> +  device, all active memory regions must have been identity-mapped
> +  in order to ensure that non-quiescent hardware during boot can
> +  continue to access the memory.
>  
>  Linux implementation note:
>  - If a "linux,cma-default" property is present, then Linux will use the
> -- 
> 2.28.0
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: iommu: renesas,ipmmu-vmsa: Sort compatible string in increasing number of the SoC

2020-08-24 Thread Rob Herring
On Sun, 09 Aug 2020 20:35:27 +0100, Lad Prabhakar wrote:
> Sort the items in the compatible string list in increasing number of SoC.
> 
> Signed-off-by: Lad Prabhakar 
> ---
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v2 4/5] dt-bindings: of: Add plumbing for restricted DMA pool

2020-07-31 Thread Rob Herring
On Tue, Jul 28, 2020 at 01:01:39PM +0800, Claire Chang wrote:
> Introduce the new compatible string, device-swiotlb-pool, for restricted
> DMA. One can specify the address and length of the device swiotlb memory
> region by device-swiotlb-pool in the device tree.
> 
> Signed-off-by: Claire Chang 
> ---
>  .../reserved-memory/reserved-memory.txt   | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index 4dd20de6977f..78850896e1d0 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -51,6 +51,24 @@ compatible (optional) - standard definition
>used as a shared pool of DMA buffers for a set of devices. It can
>be used by an operating system to instantiate the necessary pool
>management subsystem if necessary.
> +- device-swiotlb-pool: This indicates a region of memory meant to be

swiotlb is a Linux thing. The binding should be independent.

> +  used as a pool of device swiotlb buffers for a given device. When
> +  using this, the no-map and reusable properties must not be set, so 
> the
> +  operating system can create a virtual mapping that will be used for
> +  synchronization. Also, there must be a restricted-dma property in 
> the
> +  device node to specify the indexes of reserved-memory nodes. One 
> can
> +  specify two reserved-memory nodes in the device tree. One with
> +  shared-dma-pool to handle the coherent DMA buffer allocation, and
> +  another one with device-swiotlb-pool for regular DMA to/from system
> +  memory, which would be subject to bouncing. The main purpose for
> +  restricted DMA is to mitigate the lack of DMA access control on
> +  systems without an IOMMU, which could result in the DMA accessing 
> the
> +  system memory at unexpected times and/or unexpected addresses,
> +  possibly leading to data leakage or corruption. The feature on its 
> own
> +  provides a basic level of protection against the DMA overwriting 
> buffer
> +  contents at unexpected times. However, to protect against general 
> data
> +  leakage and system memory corruption, the system needs to provide a
> +  way to restrict the DMA to a predefined memory region.

I'm pretty sure we already support per device carveouts and I don't 
understand how this is different.

What is the last sentence supposed to imply? You need an IOMMU?

>  - vendor specific string in the form ,[-]
>  no-map (optional) - empty property
>  - Indicates the operating system must not create a virtual mapping
> @@ -117,6 +135,16 @@ one for multimedia processing (named 
> multimedia-memory@7700, 64MiB).
>   compatible = "acme,multimedia-memory";
>   reg = <0x7700 0x400>;
>   };
> +
> + wifi_coherent_mem_region: wifi_coherent_mem_region {
> + compatible = "shared-dma-pool";
> + reg = <0x5000 0x40>;
> + };
> +
> + wifi_device_swiotlb_region: wifi_device_swiotlb_region {
> + compatible = "device-swiotlb-pool";
> + reg = <0x5040 0x400>;
> + };
>   };
>  
>   /* ... */
> @@ -135,4 +163,11 @@ one for multimedia processing (named 
> multimedia-memory@7700, 64MiB).
>   memory-region = <_reserved>;
>   /* ... */
>   };
> +
> + pcie_wifi: pcie_wifi@0,0 {
> + memory-region = <_coherent_mem_region>,
> +  <_device_swiotlb_region>;
> + restricted-dma = <0>, <1>;
> + /* ... */
> + };
>  };
> -- 
> 2.28.0.rc0.142.g3c755180ce-goog
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-31 Thread Rob Herring
On Thu, Jul 30, 2020 at 10:44 AM Jim Quinlan  wrote:
>
> On Wed, Jul 29, 2020 at 10:28 AM Rob Herring  wrote:
> >
> > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig  wrote:
> > >
> > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > > > I started using devm_kcalloc() but at least two reviewers convinced me
> > > > to just use kcalloc().  In addition, when I was using devm_kcalloc()
> > > > it was awkward because 'dev' is not available to this function.
> > > >
> > > > It comes down to whether unbind/binding the device N times is actually
> > > > a reasonable usage.  As for my experience I've seen two cases: (1) my
> > > > overnight "bind/unbind the PCIe RC driver" script, and we have a
> > > > customer who does an unbind/bind as a hail mary to bring back life to
> > > > their dead EP device.  If the latter case happens repeatedly, there
> > > > are bigger problems.
> > >
> > > We can't just leak the allocations.  Do you have a pointer to the
> > > arguments against managed resources?  I'm generally not a huge fan
> > > of the managed resources, but for a case like this they actually seem
> > > useful.  If we don't use the managed resources we'll at leat need
> > > to explicitly free the resources when freeing the device.
> >
> > The lifetime for devm_kcalloc may not be what we want here. devm
> > allocs are freed on probe fail or remove, not on freeing the device
> > (there is a just in case free there too though).
>
> What do you suggest doing as an alternative?

I believe I gave it already. Put a kfree in the struct device release
function. But you can't be passing the pointer from device to device
if you go that route. You'd have to either copy the struct or check if
it's the same as the parent's and skip the kfree in that case.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-29 Thread Rob Herring
On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig  wrote:
>
> On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > I started using devm_kcalloc() but at least two reviewers convinced me
> > to just use kcalloc().  In addition, when I was using devm_kcalloc()
> > it was awkward because 'dev' is not available to this function.
> >
> > It comes down to whether unbind/binding the device N times is actually
> > a reasonable usage.  As for my experience I've seen two cases: (1) my
> > overnight "bind/unbind the PCIe RC driver" script, and we have a
> > customer who does an unbind/bind as a hail mary to bring back life to
> > their dead EP device.  If the latter case happens repeatedly, there
> > are bigger problems.
>
> We can't just leak the allocations.  Do you have a pointer to the
> arguments against managed resources?  I'm generally not a huge fan
> of the managed resources, but for a case like this they actually seem
> useful.  If we don't use the managed resources we'll at leat need
> to explicitly free the resources when freeing the device.

The lifetime for devm_kcalloc may not be what we want here. devm
allocs are freed on probe fail or remove, not on freeing the device
(there is a just in case free there too though).

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-28 Thread Rob Herring
On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan  wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
>
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
>
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code.  These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> Signed-off-by: Jim Quinlan 
> ---

[...]

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8eea3f6e29a4..4b718d199efe 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct device_node 
> *np, int index,
>  }
>  EXPORT_SYMBOL(of_io_request_and_map);
>
> +#ifdef CONFIG_HAS_DMA
>  /**
> - * of_dma_get_range - Get DMA range info
> + * of_dma_get_range - Get DMA range info and put it into a map array
>   * @np:device node to get DMA range info
> - * @dma_addr:  pointer to store initial DMA address of DMA range
> - * @paddr: pointer to store initial CPU address of DMA range
> - * @size:  pointer to store size of DMA range
> + * @map:   dma range structure to return
>   *
>   * Look in bottom up direction for the first "dma-ranges" property
> - * and parse it.
> - *  dma-ranges format:
> + * and parse it.  Put the information into a DMA offset map array.
> + *
> + * dma-ranges format:
>   * DMA addr (dma_addr) : naddr cells
>   * CPU addr (phys_addr_t)  : pna cells
>   * size: nsize cells
>   *
> - * It returns -ENODEV if "dma-ranges" property was not found
> - * for this device in DT.
> + * It returns -ENODEV if "dma-ranges" property was not found for this
> + * device in the DT.
>   */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 
> *size)
> +int of_dma_get_range(struct device_node *np, const struct bus_dma_region 
> **map)
>  {
> struct device_node *node = of_node_get(np);
> const __be32 *ranges = NULL;
> -   int len;
> -   int ret = 0;
> bool found_dma_ranges = false;
> struct of_range_parser parser;
> struct of_range range;
> -   u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> +   struct bus_dma_region *r;
> +   int len, num_ranges = 0;
> +   int ret;
>
> while (node) {
> ranges = of_get_property(node, "dma-ranges", );
> @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64 
> *dma_addr, u64 *paddr, u64 *siz
> }
>
> of_dma_range_parser_init(, node);
> +   for_each_of_range(, )
> +   num_ranges++;
> +
> +   of_dma_range_parser_init(, node);
> +
> +   ret = -ENOMEM;
> +   r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> +   if (!r)
> +   goto out;

AFAICT, you have the error cases covered, but you are leaking memory
if the device is removed.

[...]

> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..49242dd6176e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
> /* Initialise vdev subdevice */
> snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> rvdev->dev.parent = >dev;
> -   rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> +   rvdev->dev.dma_range_map = rproc->dev.parent->dma_range_map;

But doing this means you can't just free the dma_range_map. You need
to do a copy here or you'd have to refcount it. Or I suppose you could
check if it the child has a different dma_range_map ptr than the
parent.

Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 18/21] iommu/mediatek: Add support for multi domain

2020-07-23 Thread Rob Herring
On Sat, Jul 11, 2020 at 02:48:43PM +0800, Yong Wu wrote:
> Some HW IP(ex: CCU) require the special iova range. That means the
> iova got from dma_alloc_attrs for that devices must locate in his
> special range. In this patch, we allocate a special iova_range for
> each a special requirement and create each a iommu domain for each
> a iova_range.
> 
> meanwhile we still use one pagetable which support 16GB iova.
> 
> After this patch, If the iova range of a master is over 4G, the master
> should:
> a) Declare its special dma_ranges in its dtsi node. For example, If we
> preassign the iova 4G-8G for vcodec, then the vcodec dtsi node should:
>   dma-ranges = <0x1 0x0 0x1 0x0 0x1 0x0>;  /* 4G ~ 8G */

BTW, dma-ranges should be in the parent node of the vcodec.

> b) Update the dma_mask:
>  dma_set_mask_and_coherent(dev, DMA_BIT_MASK(33));

This should happen for you automatically. The DMA PFN offset 
should also be 4GB here.

> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/iommu/mtk_iommu.c | 49 ---
>  drivers/iommu/mtk_iommu.h |  3 ++-
>  2 files changed, 42 insertions(+), 10 deletions(-)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 6/9] dt-bindings: gpio: renesas,rcar-gpio: Add r8a774e1 support

2020-07-20 Thread Rob Herring
On Mon, 13 Jul 2020 22:35:17 +0100, Lad Prabhakar wrote:
> Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the
> relevant dt-bindings.
> 
> Signed-off-by: Lad Prabhakar 
> ---
>  Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 8/9] dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC

2020-07-20 Thread Rob Herring
On Mon, 13 Jul 2020 22:35:19 +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu 
> 
> Document RZ/G2H (R8A774E1) SoC bindings.
> 
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 
> ---
>  Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/9] dt-bindings: iommu: renesas, ipmmu-vmsa: Add r8a774e1 support

2020-07-20 Thread Rob Herring
On Mon, Jul 13, 2020 at 10:35:12PM +0100, Lad Prabhakar wrote:
> Document RZ/G2H (R8A774E1) SoC bindings.
> 
> Signed-off-by: Lad Prabhakar 
> ---
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/9] arm64: dts: renesas: r8a774e1: Add IPMMU device nodes

2020-07-20 Thread Rob Herring
On Mon, Jul 13, 2020 at 10:35:14PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu 
> 
> Add RZ/G2H (R8A774E1) IPMMU nodes.
> 
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 
> ---
>  arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 121 ++
>  1 file changed, 121 insertions(+)

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 04/21] dt-binding: mediatek: Add binding for mt8192 IOMMU and SMI

2020-07-20 Thread Rob Herring
On Sat, Jul 11, 2020 at 02:48:29PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
> 
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
> 
>   EMI
>|
>   M4U
>|
>   
>SMI Common
>   
>|
>   +---+--+--+--+---+
>   |   |  |  |   .. |   |
>   |   |  |  |  |   |
> larb0   larb1  larb2  larb4 ..  larb19   larb20
> disp0   disp1   mdpvdec   IPE  IPE
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> mt8192 M4U support 0~16GB iova range. we preassign different engines
> into different iova ranges:
> 
> domain-id  module iova-range  larbs
>0   disp0 ~ 4G  larb0/1
>1   vcodec  4G ~ 8G larb4/5/7
>2   cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>3   CCU00x4000_ ~ 0x43ff_ larb13: port 9/10
>4   CCU10x4400_ ~ 0x47ff_ larb14: port 4/5

You probably want to use dma-ranges for defining these 
address restrictions. 

How is the domain-id used or needed?

Rob 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 02/21] dt-binding: memory: mediatek: Extend LARB_NR_MAX to 32

2020-07-20 Thread Rob Herring
On Sat, 11 Jul 2020 14:48:27 +0800, Yong Wu wrote:
> Extend the max larb number definition as mt8192 has larb_nr over 16.
> 
> Signed-off-by: Yong Wu 
> ---
>  include/dt-bindings/memory/mtk-smi-larb-port.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


  1   2   3   4   >