Re: [PATCH v1 03/16] dt-bindings: power: mediatek: Refine multiple level power domain nodes
On Mon, Jul 04, 2022 at 06:00:15PM +0800, Tinghan Shen wrote: > Extract duplicated properties and support more levels of power > domain nodes. > > This change fix following error when do dtbs_check, > arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: power-controller: > power-domain@15:power-domain@16:power-domain@18: 'power-domain@19', > 'power-domain@20', 'power-domain@21' do not match any of the regexes: > 'pinctrl-[0-9]+' >From schema: > Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > > Signed-off-by: Tinghan Shen > --- > .../power/mediatek,power-controller.yaml | 132 ++ > 1 file changed, 12 insertions(+), 120 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > index 135c6f722091..09a537a802b8 100644 > --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml > @@ -39,8 +39,17 @@ properties: >'#size-cells': > const: 0 > > +required: > + - compatible > + > +additionalProperties: false > + > patternProperties: >"^power-domain@[0-9a-f]+$": > +$ref: "#/$defs/power-domain-node" > + > +$defs: > + power-domain-node: > type: object > description: | >Represents the power domains within the power controller node as > documented > @@ -98,127 +107,10 @@ patternProperties: > $ref: /schemas/types.yaml#/definitions/phandle > description: phandle to the device containing the SMI register range. > > -patternProperties: > - "^power-domain@[0-9a-f]+$": > -type: object > -description: | > - Represents a power domain child within a power domain parent node. > - > -properties: > - > - '#power-domain-cells': > -description: > - Must be 0 for nodes representing a single PM domain and 1 for > nodes > - providing multiple PM domains. > - > - '#address-cells': > -const: 1 > - > - '#size-cells': > -const: 0 > - > - reg: > -maxItems: 1 > - > - clocks: > -description: | > - A number of phandles to clocks that need to be enabled during > domain > - power-up sequencing. > - > - clock-names: > -description: | > - List of names of clocks, in order to match the power-up > sequencing > - for each power domain we need to group the clocks by name. > BASIC > - clocks need to be enabled before enabling the corresponding > power > - domain, and should not have a '-' in their name (i.e mm, mfg, > venc). > - SUSBYS clocks need to be enabled before releasing the bus > protection, > - and should contain a '-' in their name (i.e mm-0, isp-0, > cam-0). > - > - In order to follow properly the power-up sequencing, the > clocks must > - be specified by order, adding first the BASIC clocks followed > by the > - SUSBSYS clocks. > - > - domain-supply: > -description: domain regulator supply. > - > - mediatek,infracfg: > -$ref: /schemas/types.yaml#/definitions/phandle > -description: phandle to the device containing the INFRACFG > register range. > - > - mediatek,smi: > -$ref: /schemas/types.yaml#/definitions/phandle > -description: phandle to the device containing the SMI register > range. > - > -patternProperties: > - "^power-domain@[0-9a-f]+$": > -type: object > -description: | > - Represents a power domain child within a power domain parent > node. > - > -properties: > + required: > +- reg > > - '#power-domain-cells': > -description: > - Must be 0 for nodes representing a single PM domain and 1 > for nodes > - providing multiple PM domains. > - > - '#address-cells': > -const: 1 > - > - '#size-cells': > -const: 0 > - > - reg: > -maxItems: 1 > - > - clocks: > -description: | > - A number of phandles to clocks that need to be enabled > during domain > - power-up sequencing. > - > - clock-names: > -description: | > - List of names of clocks, in order to match the power-up > sequencing > - for each power domain we need to group the clocks by name. > BASIC > - clocks need to be enabled before enabling the > corresponding power > - domain, and should not have a '-' in their name (i.e mm, > mfg,
Re: [PATCH v1 01/16] dt-bindings: iommu: mediatek: Increase max interrupt number
On Mon, Jul 04, 2022 at 06:00:13PM +0800, Tinghan Shen wrote: > mt8195 infra iommu has max 5 interrupts. > > Signed-off-by: Tinghan Shen > --- > .../devicetree/bindings/iommu/mediatek,iommu.yaml| 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > index 2ae3bbad7f1a..27eb9f6aa3ce 100644 > --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > @@ -91,7 +91,8 @@ properties: > maxItems: 1 > >interrupts: > -maxItems: 1 > +minItems: 1 > +maxItems: 5 > >clocks: > items: > @@ -175,9 +176,18 @@ allOf: >const: mediatek,mt8195-iommu-infra > > then: > + properties: > +interrupts: > + maxItems: 1 > + >required: > - mediatek,larbs > > +else: > + properties: > +interrupts: > + maxItems: 5 5 is already the max. minItems: 5 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7] dt-bindings: reserved-memory: Document iommu-addresses
On Tue, 05 Jul 2022 15:06:52 +0200, Thierry Reding wrote: > From: Thierry Reding > > This adds the "iommu-addresses" property to reserved-memory nodes, which > allow describing the interaction of memory regions with IOMMUs. Two use- > cases are supported: > > 1. Static mappings can be described by pairing the "iommu-addresses" > property with a "reg" property. This is mostly useful for adopting > firmware-allocated buffers via identity mappings. One common use- > case where this is required is if early firmware or bootloaders > have set up a bootsplash framebuffer that a display controller is > actively scanning out from during the operating system boot > process. > > 2. If an "iommu-addresses" property exists without a "reg" property, > the reserved-memory node describes an IOVA reservation. Such memory > regions are excluded from the IOVA space available to operating > system drivers and can be used for regions that must not be used to > map arbitrary buffers. > > Each mapping or reservation is tied to a specific device via a phandle > to the device's device tree node. This allows a reserved-memory region > to be reused across multiple devices. > > Signed-off-by: Thierry Reding > --- > Changes in v7: > - keep reserved-memory.txt to avoid broken references > > Changes in v6: > - add device phandle to iommu-addresses property in examples > - remove now unused dt-bindings/reserved-memory.h header > --- > .../reserved-memory/reserved-memory.yaml | 62 +++ > 1 file changed, 62 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: Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:22.7-45: Warning (reg_format): /reserved-memory/framebuffer@9000:reg: property has invalid length (16 bytes) (#address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:29.7-40: Warning (reg_format): /bus@0/adsp@299:reg: property has invalid length (16 bytes) (#address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:34.7-42: Warning (reg_format): /bus@0/display@1520:reg: property has invalid length (16 bytes) (#address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:9.5-12: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (1) differs from / (2) Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:27.9-37.5: Warning (unit_address_vs_reg): /bus@0: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:21.30-24.7: Warning (avoid_default_addr_size): /reserved-memory/framebuffer@9000: Relying on default #address-cells value Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:21.30-24.7: Warning (avoid_default_addr_size): /reserved-memory/framebuffer@9000: Relying on default #size-cells value Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:28.24-31.7: Warning (avoid_default_addr_size): /bus@0/adsp@299: Relying on default #address-cells value Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:28.24-31.7: Warning (avoid_default_addr_size): /bus@0/adsp@299: Relying on default #size-cells value Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:33.27-36.7: Warning (avoid_default_addr_size): /bus@0/display@1520: Relying on default #address-cells value Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:33.27-36.7: Warning (avoid_default_addr_size): /bus@0/display@1520: Relying on default #size-cells value Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size' /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dtb: /: bus@0: 'anyOf'
Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()
On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan wrote:
>
> On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
> >
> > * Saravana Kannan [220623 08:17]:
> > > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote:
> > > >
> > > > * Saravana Kannan [220622 19:05]:
> > > > > On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren
> > > > > wrote:
> > > > > > This issue is no directly related fw_devlink. It is a side effect of
> > > > > > removing driver_deferred_probe_check_state(). We no longer return
> > > > > > -EPROBE_DEFER at the end of driver_deferred_probe_check_state().
> > > > >
> > > > > Yes, I understand the issue. But driver_deferred_probe_check_state()
> > > > > was deleted because fw_devlink=on should have short circuited the
> > > > > probe attempt with an -EPROBE_DEFER before reaching the bus/driver
> > > > > probe function and hitting this -ENOENT failure. That's why I was
> > > > > asking the other questions.
> > > >
> > > > OK. So where is the -EPROBE_DEFER supposed to happen without
> > > > driver_deferred_probe_check_state() then?
> > >
> > > device_links_check_suppliers() call inside really_probe() would short
> > > circuit and return an -EPROBE_DEFER if the device links are created as
> > > expected.
> >
> > OK
> >
> > > > Hmm so I'm not seeing any supplier for the top level ocp device in
> > > > the booting case without your patches. I see the suppliers for the
> > > > ocp child device instances only.
> > >
> > > Hmmm... this is strange (that the device link isn't there), but this
> > > is what I suspected.
> >
> > Yup, maybe it's because of the supplier being a device in the child
> > interconnect for the ocp.
>
> Ugh... yeah, this is why the normal (not SYNC_STATE_ONLY) device link
> isn't being created.
>
> So the aggregated view is something like (I had to set tabs = 4 space
> to fit it within 80 cols):
>
> ocp: ocp { <= Consumer
> compatible = "simple-pm-bus";
> power-domains = <_per>; <=== Supplier ref
>
> l4_wkup: interconnect@44c0 {
> compatible = "ti,am33xx-l4-wkup", "simple-pm-bus";
>
> segment@20 { /* 0x44e0 */
> compatible = "simple-pm-bus";
>
> target-module@0 { /* 0x44e0, ap 8 58.0 */
> compatible = "ti,sysc-omap4", "ti,sysc";
>
> prcm: prcm@0 {
> compatible = "ti,am3-prcm", "simple-bus";
>
> prm_per: prm@c00 { <= Actual Supplier
> compatible = "ti,am3-prm-inst",
> "ti,omap-prm-inst";
> };
> };
> };
> };
> };
> };
>
> The power-domain supplier is the great-great-great-grand-child of the
> consumer. It's not clear to me how this is valid. What does it even
> mean?
>
> Rob, is this considered a valid DT?
Valid DT for broken h/w.
So the domain must be default on and then simple-pm-bus is going to
hold a reference to the domain preventing it from ever getting powered
off and things seem to work. Except what happens during suspend?
Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1
On Thu, Jun 23, 2022 at 12:04:21PM +0200, sascha hauer wrote:
> On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> > Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> > enabled iommus and dmas dependency enforcement by default. On some
> > systems, this caused the console device's probe to get delayed until the
> > deferred_probe_timeout expires.
> >
> > We need consoles to work as soon as possible, so mark the console device
> > node with FWNODE_FLAG_BEST_EFFORT so that fw_delink knows not to delay
> > the probe of the console device for suppliers without drivers. The
> > driver can then make the decision on where it can probe without those
> > suppliers or defer its probe.
> >
> > Fixes: 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> > Reported-by: Sascha Hauer
> > Reported-by: Peng Fan
> > Signed-off-by: Saravana Kannan
> > Tested-by: Peng Fan
> > ---
> > drivers/of/base.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index d4f98c8469ed..a19cd0c73644 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -1919,6 +1919,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64
> > align))
> > of_property_read_string(of_aliases, "stdout", );
> > if (name)
> > of_stdout = of_find_node_opts_by_path(name,
> > _stdout_options);
> > + if (of_stdout)
> > + of_stdout->fwnode.flags |= FWNODE_FLAG_BEST_EFFORT;
>
> The device given in the stdout-path property doesn't necessarily have to
> be consistent with the console= parameter. The former is usually
> statically set in the device trees contained in the kernel while the
> latter is dynamically set by the bootloader. So if you change the
> console uart in the bootloader then you'll still run into this trap.
>
> It's problematic to consult only the device tree for dependencies. I
> found several examples of drivers in the tree for which dma support
> is optional. They use it if they can, but continue without it when
> not available. "hwlock" is another property which consider several
> drivers as optional. Also consider SoCs in early upstreaming phases
> when the device tree is merged with "dmas" or "hwlock" properties,
> but the corresponding drivers are not yet upstreamed. It's not nice
> to defer probing of all these devices for a long time.
>
> I wonder if it wouldn't be a better approach to just probe all devices
> and record the device(node) they are waiting on. Then you know that you
> don't need to probe them again until the device they are waiting for
> is available.
Can't we have a driver flag 'I have optional dependencies' that will
trigger probe without all dependencies and then the driver can defer
probe if required dependencies are not yet met.
Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 02/10] dt-bindings: display: tegra: Convert to json-schema
On Fri, Jun 24, 2022 at 11:26 AM Rob Herring wrote:
>
> On Tue, 21 Jun 2022 18:10:14 +0300, Mikko Perttunen wrote:
> > From: Thierry Reding
> >
> > Convert the Tegra host1x controller bindings from the free-form text
> > format to json-schema.
> >
> > This also adds the missing display-hub DT bindings that were not
> > previously documented.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Thierry Reding
> > ---
> > .../display/tegra/nvidia,tegra114-mipi.txt| 41 --
> > .../display/tegra/nvidia,tegra114-mipi.yaml | 74 ++
> > .../display/tegra/nvidia,tegra124-dpaux.yaml | 149
> > .../display/tegra/nvidia,tegra124-sor.yaml| 206 ++
> > .../display/tegra/nvidia,tegra124-vic.yaml| 71 ++
> > .../display/tegra/nvidia,tegra186-dc.yaml | 85 +++
> > .../tegra/nvidia,tegra186-display.yaml| 310
> > .../tegra/nvidia,tegra186-dsi-padctl.yaml | 45 ++
> > .../display/tegra/nvidia,tegra20-dc.yaml | 181 +
> > .../display/tegra/nvidia,tegra20-dsi.yaml | 159 +
> > .../display/tegra/nvidia,tegra20-epp.yaml | 70 ++
> > .../display/tegra/nvidia,tegra20-gr2d.yaml| 73 ++
> > .../display/tegra/nvidia,tegra20-gr3d.yaml| 214 ++
> > .../display/tegra/nvidia,tegra20-hdmi.yaml| 126
> > .../display/tegra/nvidia,tegra20-host1x.txt | 675 --
> > .../display/tegra/nvidia,tegra20-host1x.yaml | 347 +
> > .../display/tegra/nvidia,tegra20-isp.yaml | 67 ++
> > .../display/tegra/nvidia,tegra20-mpe.yaml | 73 ++
> > .../display/tegra/nvidia,tegra20-tvo.yaml | 58 ++
> > .../display/tegra/nvidia,tegra20-vi.yaml | 163 +
> > .../display/tegra/nvidia,tegra210-csi.yaml| 52 ++
> > .../pinctrl/nvidia,tegra124-dpaux-padctl.txt | 59 --
> > 22 files changed, 2523 insertions(+), 775 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
> > delete mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml
> > delete mode 100644
> > Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-dpaux-padctl.txt
> >
>
> 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/display/tegra/nvidia,tegra124-sor.yaml:
> allOf:1:if:not:properties: {'contains': {'const': 'nvidia,panel'}} sho
Re: [PATCH v6 02/10] dt-bindings: display: tegra: Convert to json-schema
On Tue, 21 Jun 2022 18:10:14 +0300, Mikko Perttunen wrote:
> From: Thierry Reding
>
> Convert the Tegra host1x controller bindings from the free-form text
> format to json-schema.
>
> This also adds the missing display-hub DT bindings that were not
> previously documented.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Thierry Reding
> ---
> .../display/tegra/nvidia,tegra114-mipi.txt| 41 --
> .../display/tegra/nvidia,tegra114-mipi.yaml | 74 ++
> .../display/tegra/nvidia,tegra124-dpaux.yaml | 149
> .../display/tegra/nvidia,tegra124-sor.yaml| 206 ++
> .../display/tegra/nvidia,tegra124-vic.yaml| 71 ++
> .../display/tegra/nvidia,tegra186-dc.yaml | 85 +++
> .../tegra/nvidia,tegra186-display.yaml| 310
> .../tegra/nvidia,tegra186-dsi-padctl.yaml | 45 ++
> .../display/tegra/nvidia,tegra20-dc.yaml | 181 +
> .../display/tegra/nvidia,tegra20-dsi.yaml | 159 +
> .../display/tegra/nvidia,tegra20-epp.yaml | 70 ++
> .../display/tegra/nvidia,tegra20-gr2d.yaml| 73 ++
> .../display/tegra/nvidia,tegra20-gr3d.yaml| 214 ++
> .../display/tegra/nvidia,tegra20-hdmi.yaml| 126
> .../display/tegra/nvidia,tegra20-host1x.txt | 675 --
> .../display/tegra/nvidia,tegra20-host1x.yaml | 347 +
> .../display/tegra/nvidia,tegra20-isp.yaml | 67 ++
> .../display/tegra/nvidia,tegra20-mpe.yaml | 73 ++
> .../display/tegra/nvidia,tegra20-tvo.yaml | 58 ++
> .../display/tegra/nvidia,tegra20-vi.yaml | 163 +
> .../display/tegra/nvidia,tegra210-csi.yaml| 52 ++
> .../pinctrl/nvidia,tegra124-dpaux-padctl.txt | 59 --
> 22 files changed, 2523 insertions(+), 775 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml
> delete mode 100644
> Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-dpaux-padctl.txt
>
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/display/tegra/nvidia,tegra124-sor.yaml:
allOf:1:if:not:properties: {'contains': {'const': 'nvidia,panel'}} should not
be valid under {'$ref': '#/definitions/sub-schemas'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml:
ignoring, error in schema: allOf: 1: if: not: properties
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.example.dt
Re: [PATCH v2 1/4] dt-bindings: qcom-iommu: Add Qualcomm MSM8953 compatible
On Sun, 12 Jun 2022 11:22:13 +0200, Luca Weiss wrote: > Document the compatible used for IOMMU on the msm8953 SoC. > > Signed-off-by: Luca Weiss > --- > Changes from v1: > - new patch > > Documentation/devicetree/bindings/iommu/qcom,iommu.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 V4 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops
On Thu, 02 Jun 2022 22:23:50 +0300, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The main purpose of this binding is to communicate Xen specific > information using generic IOMMU device tree bindings (which is > a good fit here) rather than introducing a custom property. > > Introduce Xen specific IOMMU for the virtualized device (e.g. virtio) > to be used by Xen grant DMA-mapping layer in the subsequent commit. > > The reference to Xen specific IOMMU node using "iommus" property > indicates that Xen grant mappings need to be enabled for the device, > and it specifies the ID of the domain where the corresponding backend > resides. The domid (domain ID) is used as an argument to the Xen grant > mapping APIs. > > This is needed for the option to restrict memory access using Xen grant > mappings to work which primary goal is to enable using virtio devices > in Xen guests. > > Signed-off-by: Oleksandr Tyshchenko > Reviewed-by: Stefano Stabellini > --- > Changes RFC -> V1: >- update commit subject/description and text in description >- move to devicetree/bindings/arm/ > > Changes V1 -> V2: >- update text in description >- change the maintainer of the binding >- fix validation issue >- reference xen,dev-domid.yaml schema from virtio/mmio.yaml > > Change V2 -> V3: >- Stefano already gave his Reviewed-by, I dropped it due to the changes > (significant) >- use generic IOMMU device tree bindings instead of custom property > "xen,dev-domid" >- change commit subject and description, was > "dt-bindings: Add xen,dev-domid property description for xen-grant DMA > ops" > > Changes V3 -> V4: >- add Stefano's R-b >- remove underscore in iommu node name >- remove consumer example virtio@3000 >- update text for two descriptions > --- > .../devicetree/bindings/iommu/xen,grant-dma.yaml | 39 > ++ > 1 file changed, 39 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml > Reviewed-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] dt-bindings: iommu: mediatek: add binding documentation for MT8365 SoC
On Mon, May 30, 2022 at 08:03:26PM +0200, Fabien Parent wrote: > Add IOMMU binding documentation for the MT8365 SoC. > > Signed-off-by: Fabien Parent > --- > .../bindings/iommu/mediatek,iommu.yaml| 2 + > include/dt-bindings/memory/mt8365-larb-port.h | 96 +++ > 2 files changed, 98 insertions(+) > create mode 100644 include/dt-bindings/memory/mt8365-larb-port.h > > diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > index 97e8c471a5e8..5ba688365da5 100644 > --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > @@ -77,6 +77,7 @@ properties: >- mediatek,mt8173-m4u # generation two >- mediatek,mt8183-m4u # generation two >- mediatek,mt8192-m4u # generation two > + - mediatek,mt8365-m4u # generation two > >- description: mt7623 generation one > items: > @@ -120,6 +121,7 @@ properties: >dt-binding/memory/mt8173-larb-port.h for mt8173, >dt-binding/memory/mt8183-larb-port.h for mt8183, >dt-binding/memory/mt8192-larb-port.h for mt8192. > + dt-binding/memory/mt8365-larb-port.h for mt8365. > >power-domains: > maxItems: 1 > diff --git a/include/dt-bindings/memory/mt8365-larb-port.h > b/include/dt-bindings/memory/mt8365-larb-port.h > new file mode 100644 > index ..e7d5637aa38e > --- /dev/null > +++ b/include/dt-bindings/memory/mt8365-larb-port.h > @@ -0,0 +1,96 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ Dual license please. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 4/6] iommu/qcom: Add support for AArch64 IOMMU pagetables
On Fri, May 27, 2022 at 11:28:59PM +0200, Konrad Dybcio wrote: > From: AngeloGioacchino Del Regno > > Some IOMMUs associated with some TZ firmwares may support switching > to the AArch64 pagetable format by sending a "set pagetable format" > scm command indicating the IOMMU secure ID and the context number > to switch. > > Add a DT property "qcom,use-aarch64-pagetables" for this driver to > send this command to the secure world and to switch the pagetable > format to benefit of the ARM64 IOMMU pagetables, where possible. > > Note that, even though the command should be valid to switch each > context, the property is made global because: > 1. It doesn't make too much sense to switch only one or two >context(s) to AA64 instead of just the entire thing > 2. Some IOMMUs will go crazy and produce spectacular results when >trying to mix up the pagetables on a per-context basis. > > Signed-off-by: AngeloGioacchino Del Regno > > Signed-off-by: Marijn Suijten > Signed-off-by: Konrad Dybcio > --- > .../devicetree/bindings/iommu/qcom,iommu.txt | 2 + Bindings should be separate patch. As you are making multiple changes, please convert this to DT schema first. > drivers/iommu/arm/arm-smmu/qcom_iommu.c | 54 +++ > 2 files changed, 47 insertions(+), 9 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] iommu: bindings: Add binding documentation for Toshiba Visconti5 IOMMU device
On Wed, May 25, 2022 at 10:31:46AM +0900, Nobuhiro Iwamatsu wrote:
> Add documentation for the binding of Toshiba Visconti5 SoC's IOMMU.
>
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> .../bindings/iommu/toshiba,visconti-atu.yaml | 62 +++
> 1 file changed, 62 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iommu/toshiba,visconti-atu.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/iommu/toshiba,visconti-atu.yaml
> b/Documentation/devicetree/bindings/iommu/toshiba,visconti-atu.yaml
> new file mode 100644
> index ..af8d6688fa70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/toshiba,visconti-atu.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: GPL-2.0-only
Dual license: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/toshiba,visconti-atu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba ARM SoC Visconti5 IOMMU (ATU)
> +
> +maintainers:
> + - Nobuhiro Iwamatsu
> +
> +description: |+
> + IOMMU (ATU) driver can bse used for Visconti5's multimedia IPs, such as
Bindings are for hardware, not drivers.
> + DCNN (Deep Convolutional Neural Network), VIIF(Video Input), VOIF(Video
> + output), and others.
> +
> +properties:
> + compatible:
> +const: toshiba,visconti-atu
> +
> + reg:
> +maxItems: 1
> +
> + "#iommu-cells":
> +const: 0
> +
> + toshiba,max-entry:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: The size of entry for address
> +enum:
> + - 16
> + - 32
> +
> + toshiba,reserved-entry:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: The reserve number of entry address.
> +default: 0
> +minimum: 0
> +maximum: 32
These 2 need a better description of what they are for.
> +
> +required:
> + - compatible
> + - reg
> + - "#iommu-cells"
> + - toshiba,max-entry
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +soc {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +atu_affine0: iommu@1400f000 {
Drop unused labels.
> +compatible = "toshiba,visconti-atu";
> +reg = <0 0x1400F000 0 0x1000>;
> +toshiba,max-entry = <16>;
> +toshiba,reserved-entry = <1>;
> +#iommu-cells = <0>;
> +};
> +};
> --
> 2.36.0
>
>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/7] dt-bindings: iommu: mediatek: Add phandles for mediatek infra/pericfg
On Wed, May 18, 2022 at 01:42:20PM +0200, AngeloGioacchino Del Regno wrote: > Il 18/05/22 13:29, Matthias Brugger ha scritto: > > > > > > On 18/05/2022 12:04, AngeloGioacchino Del Regno wrote: > > > Add properties "mediatek,infracfg" and "mediatek,pericfg" to let the > > > mtk_iommu driver retrieve phandles to the infracfg and pericfg syscon(s) > > > instead of performing a per-soc compatible lookup. > > > > > > Signed-off-by: AngeloGioacchino Del Regno > > > > > > --- > > > .../devicetree/bindings/iommu/mediatek,iommu.yaml | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > > b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > > index 2ae3bbad7f1a..c4af41947593 100644 > > > --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > > +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > > @@ -101,6 +101,10 @@ properties: > > > items: > > > - const: bclk > > > + mediatek,infracfg: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + description: The phandle to the mediatek infracfg syscon > > > + > > > mediatek,larbs: > > > $ref: /schemas/types.yaml#/definitions/phandle-array > > > minItems: 1 > > > @@ -112,6 +116,10 @@ properties: > > > Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It > > > must sort > > > according to the local arbiter index, like larb0, larb1, larb2... > > > + mediatek,pericfg: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + description: The phandle to the mediatek pericfg syscon > > > + > > > > I didn't explain myself. What I was suguesting was to squash the patch > > that add requiered mediatek,infracfg with the patch that adds > > mediatk,infracfg to the binding description. And then squash the both > > patches adding pericfg as well. > > Sorry Matthias, I'm not sure ... I think I'm misunderstanding you again... > ...but if I'm not, I don't think that squashing actual code and bindings > together > is something acceptable? > > I've made that kind of mistake in the past and I was told multiple times that > dt-bindings changes shall be sent separately from the actual driver changes. Combine patches 1 and 6 is the suggestion, not driver changes. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] dt-bindings: mediatek: Add bindings for MT6795 M4U
On Wed, 18 May 2022 12:18:48 +0200, AngeloGioacchino Del Regno wrote: > Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/iommu/mediatek,iommu.yaml| 4 + > include/dt-bindings/memory/mt6795-larb-port.h | 96 +++ > 2 files changed, 100 insertions(+) > create mode 100644 include/dt-bindings/memory/mt6795-larb-port.h > Acked-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/8] iommu: mtk_iommu: Lookup phandle to retrieve syscon to infracfg
On Wed, May 18, 2022 at 12:07:58PM +0100, Robin Murphy wrote:
> On 2022-05-18 09:29, AngeloGioacchino Del Regno wrote:
> > Il 17/05/22 16:12, Robin Murphy ha scritto:
> > > On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote:
> > > > This driver will get support for more SoCs and the list of infracfg
> > > > compatibles is expected to grow: in order to prevent getting this
> > > > situation out of control and see a long list of compatible strings,
> > > > add support to retrieve a handle to infracfg's regmap through a
> > > > new "mediatek,infracfg" phandle.
> > > >
> > > > In order to keep retrocompatibility with older devicetrees, the old
> > > > way is kept in place, but also a dev_warn() was added to advertise
> > > > this change in hope that the user will see it and eventually update
> > > > the devicetree if this is possible.
> > > >
> > > > Signed-off-by: AngeloGioacchino Del Regno
> > > >
> > > > ---
> > > > drivers/iommu/mtk_iommu.c | 40 +--
> > > > 1 file changed, 26 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > > > index 71b2ace74cd6..cfaaa98d2b50 100644
> > > > --- a/drivers/iommu/mtk_iommu.c
> > > > +++ b/drivers/iommu/mtk_iommu.c
> > > > @@ -1134,22 +1134,34 @@ static int mtk_iommu_probe(struct
> > > > platform_device *pdev)
> > > > data->protect_base = ALIGN(virt_to_phys(protect),
> > > > MTK_PROTECT_PA_ALIGN);
> > > > if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
> > > > - switch (data->plat_data->m4u_plat) {
> > > > - case M4U_MT2712:
> > > > - p = "mediatek,mt2712-infracfg";
> > > > - break;
> > > > - case M4U_MT8173:
> > > > - p = "mediatek,mt8173-infracfg";
> > > > - break;
> > > > - default:
> > > > - p = NULL;
> > > > + infracfg =
> > > > syscon_regmap_lookup_by_phandle(dev->of_node,
> > > > "mediatek,infracfg");
> > > > + if (IS_ERR(infracfg)) {
> > > > + dev_warn(dev, "Cannot find phandle to mediatek,infracfg:"
> > > > + " Please update your devicetree.\n");
> > >
> > > Is this really a dev_warn-level problem? There's no functional
> > > impact, given that we can't stop supporting the original binding any
> > > time soon, if ever, so I suspect this is more likely to just annoy
> > > users and CI systems than effect any significant change.
> > >
> >
> > The upstream devicetrees were updated to use the new handle and this is
> > a way to
> > warn about having outdated DTs... besides, I believe that CIs will
> > always get the
> > devicetree from the same tree that the kernel was compiled from (hence
> > no message
> > will be thrown).
> >
> > In any case, if you think that a dev_info would be more appropriate, I
> > can change
> > that no problem.
>
> If there's some functional impact from using the old binding vs. the new one
> then it's reasonable to inform the user of that (as we do in arm-smmu, for
> example).
>
> However if you change an established binding for non-functional reasons,
> then you get to support both bindings, and it's not the end user's problem
> at all. There seems to be zero reason to update an existing DTB for this
> difference alone, so TBH I don't think it deserves a message at all.
It's also not the kernel's job to validate the DT. It's horrible at it
and we have something else now.
Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 7/8] dt-bindings: iommu: mediatek: Require mediatek,infracfg for mt2712/8173
On Wed, May 18, 2022 at 10:14:43AM +0200, AngeloGioacchino Del Regno wrote: > Il 18/05/22 03:41, Rob Herring ha scritto: > > On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote: > > > Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to > > > the required properties for these SoCs to deprecate the old way of > > > looking for SoC-specific infracfg compatible in the entire devicetree. > > > > Wait, what? If there's only one possible node that can match, I prefer > > the 'old way'. Until we implemented a phandle cache, searching the > > entire tree was how phandle lookups worked too, so not any better. > > > > But if this makes things more consistent, > > > > Acked-by: Rob Herring > > > Hello Rob, > > This makes things definitely more consistent, as it's done like that on > mtk-pm-domains and other mtk drivers as well. > > The main reason why this phandle is useful, here and in other drivers, is > that we're seeing a list of compatibles that is growing more and more, so > you see stuff like (mockup names warning): > > switch (some_model) > case MT1000: > p = "mediatek,mt1000-infracfg"; > break; > case MT1001: > p = "mediatek,mt1001-infracfg"; > break; > case MT1002: > p = "mediatek,mt1002-infracfg"; > break; > .add another 20 SoCs, replicate this switch for 4/5 drivers This type of property is used for poking random bits in another block (that's usually a collection of random bits). These interfaces don't tend to be that stable across many SoC generations. As there's no abstraction beyond perhaps what the offset is, the client side ends up needing to know the specifics of that block anyways. If the block is that stable, then perhaps it needs a common fallback compatible. Sometimes these instances are also just places we haven't created a common subsystem for. > and this is why I want the mtk_iommu driver to also get that phandle like > some other drivers are already doing. As I said, fine. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 8/8] dt-bindings: iommu: mediatek: Require mediatek,pericfg for mt8195-infra
On Tue, 17 May 2022 15:21:07 +0200, AngeloGioacchino Del Regno wrote: > The MT8195 SoC has IOMMU related registers in the pericfg_ao iospace: > require a phandle to that. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > > Note for Rob: as of now, there's no iommu node in upstream mt8195 devicetrees > yet. > > .../devicetree/bindings/iommu/mediatek,iommu.yaml | 10 ++ > 1 file changed, 10 insertions(+) > Acked-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 7/8] dt-bindings: iommu: mediatek: Require mediatek,infracfg for mt2712/8173
On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote: > Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to > the required properties for these SoCs to deprecate the old way of > looking for SoC-specific infracfg compatible in the entire devicetree. Wait, what? If there's only one possible node that can match, I prefer the 'old way'. Until we implemented a phandle cache, searching the entire tree was how phandle lookups worked too, so not any better. But if this makes things more consistent, Acked-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 1/9] dt-bindings: host1x: Add iommu-map property
On Mon, 16 May 2022 11:52:50 +0300, cyn...@kapsi.fi wrote: > From: Mikko Perttunen > > Add schema information for specifying context stream IDs. This uses > the standard iommu-map property. > > Signed-off-by: Mikko Perttunen > Reviewed-by: Robin Murphy > --- > v3: > * New patch > v4: > * Remove memory-contexts subnode. > --- > .../bindings/display/tegra/nvidia,tegra20-host1x.yaml| 5 + > 1 file changed, 5 insertions(+) > Acked-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] dt-bindings: mediatek: Add bindings for MT6795 M4U
On Fri, 13 May 2022 17:14:10 +0200, AngeloGioacchino Del Regno wrote: > Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/iommu/mediatek,iommu.yaml| 3 + > include/dt-bindings/memory/mt6795-larb-port.h | 96 +++ > 2 files changed, 99 insertions(+) > create mode 100644 include/dt-bindings/memory/mt6795-larb-port.h > Acked-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration
On Fri, May 13, 2022 at 12:26 PM Saravana Kannan wrote: > > On Fri, May 13, 2022 at 6:58 AM Rob Herring wrote: > > > > On Fri, Apr 29, 2022 at 5:09 PM Saravana Kannan > > wrote: > > > > > > The deferred probe timer that's used for this currently starts at > > > late_initcall and runs for driver_deferred_probe_timeout seconds. The > > > assumption being that all available drivers would be loaded and > > > registered before the timer expires. This means, the > > > driver_deferred_probe_timeout has to be pretty large for it to cover the > > > worst case. But if we set the default value for it to cover the worst > > > case, it would significantly slow down the average case. For this > > > reason, the default value is set to 0. > > > > > > Also, with CONFIG_MODULES=y and the current default values of > > > driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing > > > drivers will cause their consumer devices to always defer their probes. > > > This is because device links created by fw_devlink defer the probe even > > > before the consumer driver's probe() is called. > > > > > > Instead of a fixed timeout, if we extend an unexpired deferred probe > > > timer on every successful driver registration, with the expectation more > > > modules would be loaded in the near future, then the default value of > > > driver_deferred_probe_timeout only needs to be as long as the worst case > > > time difference between two consecutive module loads. > > > > > > So let's implement that and set the default value to 10 seconds when > > > CONFIG_MODULES=y. > > > > We had to revert a non-zero timeout before (issue with NFS root IIRC). > > Does fw_devlink=on somehow fix that? > > If it's the one where ip autoconfig was timing out, then John Stultz > fixed it by fixing wait_for_device_probe(). > https://lore.kernel.org/all/20200422203245.83244-4-john.stu...@linaro.org/ Yeah, that was it. Acked-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration
On Fri, Apr 29, 2022 at 5:09 PM Saravana Kannan wrote: > > The deferred probe timer that's used for this currently starts at > late_initcall and runs for driver_deferred_probe_timeout seconds. The > assumption being that all available drivers would be loaded and > registered before the timer expires. This means, the > driver_deferred_probe_timeout has to be pretty large for it to cover the > worst case. But if we set the default value for it to cover the worst > case, it would significantly slow down the average case. For this > reason, the default value is set to 0. > > Also, with CONFIG_MODULES=y and the current default values of > driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing > drivers will cause their consumer devices to always defer their probes. > This is because device links created by fw_devlink defer the probe even > before the consumer driver's probe() is called. > > Instead of a fixed timeout, if we extend an unexpired deferred probe > timer on every successful driver registration, with the expectation more > modules would be loaded in the near future, then the default value of > driver_deferred_probe_timeout only needs to be as long as the worst case > time difference between two consecutive module loads. > > So let's implement that and set the default value to 10 seconds when > CONFIG_MODULES=y. We had to revert a non-zero timeout before (issue with NFS root IIRC). Does fw_devlink=on somehow fix that? Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 1/5] dt-bindings: reserved-memory: Document iommu-addresses
On Thu, 12 May 2022 21:00:48 +0200, Thierry Reding wrote: > From: Thierry Reding > > This adds the "iommu-addresses" property to reserved-memory nodes, which > allow describing the interaction of memory regions with IOMMUs. Two use- > cases are supported: > > 1. Static mappings can be described by pairing the "iommu-addresses" > property with a "reg" property. This is mostly useful for adopting > firmware-allocated buffers via identity mappings. One common use- > case where this is required is if early firmware or bootloaders > have set up a bootsplash framebuffer that a display controller is > actively scanning out from during the operating system boot > process. > > 2. If an "iommu-addresses" property exists without a "reg" property, > the reserved-memory node describes an IOVA reservation. Such memory > regions are excluded from the IOVA space available to operating > system drivers and can be used for regions that must not be used to > map arbitrary buffers. > > Each mapping or reservation is tied to a specific device via a phandle > to the device's device tree node. This allows a reserved-memory region > to be reused across multiple devices. > > Signed-off-by: Thierry Reding > --- > .../reserved-memory/reserved-memory.txt | 1 - > .../reserved-memory/reserved-memory.yaml | 62 +++ > include/dt-bindings/reserved-memory.h | 8 +++ > 3 files changed, 70 insertions(+), 1 deletion(-) > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > create mode 100644 include/dt-bindings/reserved-memory.h > 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: Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:21.11-18: Warning (ranges_format): /example-0/reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from /example-0 (1) Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:21.11-18: Warning (ranges_format): /example-0/reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from /example-0 (1) Documentation/devicetree/bindings/reserved-memory/reserved-memory.example.dts:39.15-52.11: Warning (unit_address_vs_reg): /example-0/bus@0: node has a unit name, but no reg or ranges property doc reference errors (make refcheckdocs): Documentation/devicetree/bindings/display/arm,hdlcd.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/display/arm,komeda.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/display/arm,malidp.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/display/arm,pl11x.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/gpu/aspeed-gfx.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/media/amphion,vpu.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/media/aspeed-video.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/media/mediatek-vpu.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt kernel/dma/Kconfig: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt See https://patchwork.ozlabs.org/patch/ 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
Re: [PATCH v2] iommu/dma: Explicitly sort PCI DMA windows
On Mon, May 9, 2022 at 5:16 AM Robin Murphy wrote: > > Originally, creating the dma_ranges resource list in pre-sorted fashion > was the simplest and most efficient way to enforce the order required by > iova_reserve_pci_windows(). However since then at least one PCI host > driver is now re-sorting the list for its own probe-time processing, > which doesn't seem entirely unreasonable, so that basic assumption no > longer holds. Make iommu-dma robust and get the sort order it needs by > explicitly sorting, which means we can also save the effort at creation > time and just build the list in whatever natural order the DT had. > > Signed-off-by: Robin Murphy > --- > > v2: Clean up now-unused local variable > > drivers/iommu/dma-iommu.c | 13 - > drivers/pci/of.c | 8 +--- > 2 files changed, 13 insertions(+), 8 deletions(-) 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: mmc: sdhci-msm: Document the SDX65 compatible
On Mon, 02 May 2022 14:07:42 +0530, Rohit Agarwal wrote: > The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence, > document the compatible with "qcom,sdhci-msm-v5" as the fallback. > > Signed-off-by: Rohit Agarwal > --- > Documentation/devicetree/bindings/mmc/sdhci-msm.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
[PATCH] dt-bindings: iommu: Drop client node in examples
There's no need to show consumer side in provider examples. The ones
used here are undocumented or undocumented in schemas which results in
warnings.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/iommu/mediatek,iommu.yaml | 10 --
.../devicetree/bindings/iommu/samsung,sysmmu.yaml | 10 --
2 files changed, 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index 97e8c471a5e8..e0389539194f 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -173,13 +173,3 @@ examples:
<>, <>, <>;
#iommu-cells = <1>;
};
-
- - |
-#include
-
-/* Example for a client device */
-display {
- compatible = "mediatek,mt8173-disp";
- iommus = < M4U_PORT_DISP_OVL0>,
-< M4U_PORT_DISP_RDMA0>;
- };
diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml
b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml
index 783c6b37c9f0..672a0beea600 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml
@@ -86,16 +86,6 @@ examples:
- |
#include
-gsc_0: scaler@13e0 {
- compatible = "samsung,exynos5-gsc";
- reg = <0x13e0 0x1000>;
- interrupts = <0 85 0>;
- power-domains = <_gsc>;
- clocks = < CLK_GSCL0>;
- clock-names = "gscl";
- iommus = <_gsc0>;
-};
-
sysmmu_gsc0: iommu@13e8 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13E8 0x1000>;
--
2.32.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: Explicitly sort PCI DMA windows
On Tue, Mar 22, 2022 at 12:27 PM Robin Murphy wrote:
>
> Originally, creating the dma_ranges resource list in pre-sorted fashion
> was the simplest and most efficient way to enforce the order required by
> iova_reserve_pci_windows(). However since then at least one PCI host
> driver is now re-sorting the list for its own probe-time processing,
> which doesn't seem entirely unreasonable, so that basic assumption no
> longer holds. Make iommu-dma robust and get the sort order it needs by
> explicitly sorting, which means we can also save the effort at creation
> time and just build the list in whatever natural order the DT had.
>
> Signed-off-by: Robin Murphy
> ---
>
> Looking at this area off the back of the XGene thread[1] made me realise
> that we need to do it anyway, regardless of whether it might also happen
> to restore the previous XGene behaviour or not. Presumably nobody's
> tried to use pcie-cadence-host behind an IOMMU yet...
>
> Boot-tested on Juno to make sure I hadn't got the sort comparison
> backwards.
>
> Robin.
>
> [1] https://lore.kernel.org/linux-pci/20220321104843.949645-1-...@kernel.org/
>
> drivers/iommu/dma-iommu.c | 13 -
> drivers/pci/of.c | 7 +--
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index b22034975301..91d134c0c9b1 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -414,6 +415,15 @@ static int cookie_init_hw_msi_region(struct
> iommu_dma_cookie *cookie,
> return 0;
> }
>
> +static int iommu_dma_ranges_sort(void *priv, const struct list_head *a,
> + const struct list_head *b)
> +{
> + struct resource_entry *res_a = list_entry(a, typeof(*res_a), node);
> + struct resource_entry *res_b = list_entry(b, typeof(*res_b), node);
> +
> + return res_a->res->start > res_b->res->start;
> +}
> +
> static int iova_reserve_pci_windows(struct pci_dev *dev,
> struct iova_domain *iovad)
> {
> @@ -432,6 +442,7 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
> }
>
> /* Get reserved DMA windows from host bridge */
> + list_sort(NULL, >dma_ranges, iommu_dma_ranges_sort);
> resource_list_for_each_entry(window, >dma_ranges) {
> end = window->res->start - window->offset;
> resv_iova:
> @@ -440,7 +451,7 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
> hi = iova_pfn(iovad, end);
> reserve_iova(iovad, lo, hi);
> } else if (end < start) {
> - /* dma_ranges list should be sorted */
> + /* DMA ranges should be non-overlapping */
> dev_err(>dev,
> "Failed to reserve IOVA [%pa-%pa]\n",
> , );
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index cb2e8351c2cc..d176b4bc6193 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -393,12 +393,7 @@ static int devm_of_pci_get_host_bridge_resources(struct
> device *dev,
> goto failed;
> }
>
> - /* Keep the resource list sorted */
> - resource_list_for_each_entry(entry, ib_resources)
> - if (entry->res->start > res->start)
> - break;
> -
> - pci_add_resource_offset(>node, res,
entry is now unused and causes a warning.
> + pci_add_resource_offset(ib_resources, res,
> res->start - range.pci_addr);
> }
>
> --
> 2.28.0.dirty
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: Explicitly sort PCI DMA windows
On Wed, Mar 23, 2022 at 5:15 PM dann frazier wrote: > > On Wed, Mar 23, 2022 at 09:49:04AM +, Marc Zyngier wrote: > > On Tue, 22 Mar 2022 17:27:36 +, > > Robin Murphy wrote: > > > > > > Originally, creating the dma_ranges resource list in pre-sorted fashion > > > was the simplest and most efficient way to enforce the order required by > > > iova_reserve_pci_windows(). However since then at least one PCI host > > > driver is now re-sorting the list for its own probe-time processing, > > > which doesn't seem entirely unreasonable, so that basic assumption no > > > longer holds. Make iommu-dma robust and get the sort order it needs by > > > explicitly sorting, which means we can also save the effort at creation > > > time and just build the list in whatever natural order the DT had. > > > > > > Signed-off-by: Robin Murphy > > > --- > > > > > > Looking at this area off the back of the XGene thread[1] made me realise > > > that we need to do it anyway, regardless of whether it might also happen > > > to restore the previous XGene behaviour or not. Presumably nobody's > > > tried to use pcie-cadence-host behind an IOMMU yet... > > > > This definitely restores PCIe functionality on my Mustang (XGene-1). > > Hopefully dann can comment on whether this addresses his own issue, as > > his firmware is significantly different. > > Robin, Marc, > > Adding just this patch on top of v5.17 (w/ vendor dtb) isn't enough to > fix m400 networking: I wouldn't expect it to given both the IB register selection changed and the 2nd dma-ranges entry is ignored. Can you (and others) try out this branch: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git xgene-pci-fix It should maintain the same IB register usage for both cases and handle the error in 'dma-ranges'. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 1/2] cma: factor out minimum alignment requirement
On Mon, Feb 14, 2022 at 11:42 AM David Hildenbrand wrote: > > Let's factor out determining the minimum alignment requirement for CMA > and add a helpful comment. > > No functional change intended. > > Signed-off-by: David Hildenbrand > --- > arch/powerpc/include/asm/fadump-internal.h | 5 - > arch/powerpc/kernel/fadump.c | 2 +- > drivers/of/of_reserved_mem.c | 9 +++-- Acked-by: Rob Herring > include/linux/cma.h| 9 + > kernel/dma/contiguous.c| 4 +--- > mm/cma.c | 20 +--- > 6 files changed, 19 insertions(+), 30 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 1/2] dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support
On Tue, 08 Feb 2022 09:20:29 +0900, Yoshihiro Shimoda wrote: > Document the compatible values for the IPMMU-VMSA blocks in > the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4. > > Signed-off-by: Yoshihiro Shimoda > Reviewed-by: Geert Uytterhoeven > --- > .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 4 > 1 file changed, 4 insertions(+) > Acked-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: iommu: renesas,ipmmu-vmsa: Reformat renesas,ipmmu-main description
On Wed, Jan 26, 2022 at 01:24:32PM +0100, Geert Uytterhoeven wrote: > Remove trailing whitespace and break overly long lines. > > Signed-off-by: Geert Uytterhoeven > --- > .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) I fixed this and other whitespace in my tree from commit 'dt-bindings: Improve phandle-array schemas'. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] dt-bindings: mediatek: mt8186: Add binding for MM iommu
On Tue, 25 Jan 2022 17:32:43 +0800, Yong Wu wrote: > Add mt8186 iommu binding. "-mm" means the iommu is for Multimedia. > > Signed-off-by: Yong Wu > --- > .../bindings/iommu/mediatek,iommu.yaml| 4 + > .../dt-bindings/memory/mt8186-memory-port.h | 217 ++ > 2 files changed, 221 insertions(+) > create mode 100644 include/dt-bindings/memory/mt8186-memory-port.h > Reviewed-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Wed, Jan 19, 2022 at 9:22 AM Arnaud POULIQUEN wrote: > > Hello Rob, > > On 1/19/22 2:50 AM, Rob Herring wrote: > > The 'phandle-array' type is a bit ambiguous. It can be either just an > > array of phandles or an array of phandles plus args. Many schemas for > > phandle-array properties aren't clear in the schema which case applies > > though the description usually describes it. > > > > The array of phandles case boils down to needing: > > > > items: > > maxItems: 1 > > > > The phandle plus args cases should typically take this form: > > > > items: > > - items: > > - description: A phandle > > - description: 1st arg cell > > - description: 2nd arg cell > > > > With this change, some examples need updating so that the bracketing of > > property values matches the schema. > > > > Cc: Damien Le Moal > > Cc: Herbert Xu > > Cc: "David S. Miller" > > Cc: Chun-Kuang Hu > > Cc: Philipp Zabel > > Cc: Laurent Pinchart > > Cc: Kieran Bingham > > Cc: Vinod Koul > > Cc: Georgi Djakov > > Cc: Thomas Gleixner > > Cc: Marc Zyngier > > Cc: Joerg Roedel > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Cc: Pavel Machek > > Cc: Mauro Carvalho Chehab > > Cc: Krzysztof Kozlowski > > Cc: Jakub Kicinski > > Cc: Wolfgang Grandegger > > Cc: Marc Kleine-Budde > > Cc: Andrew Lunn > > Cc: Vivien Didelot > > Cc: Florian Fainelli > > Cc: Vladimir Oltean > > Cc: Kalle Valo > > Cc: Viresh Kumar > > Cc: Stephen Boyd > > Cc: Kishon Vijay Abraham I > > Cc: Linus Walleij > > Cc: "Rafael J. Wysocki" > > Cc: Kevin Hilman > > Cc: Ulf Hansson > > Cc: Sebastian Reichel > > Cc: Mark Brown > > Cc: Mathieu Poirier > > Cc: Daniel Lezcano > > Cc: Zhang Rui > > Cc: Greg Kroah-Hartman > > Cc: Thierry Reding > > Cc: Jonathan Hunter > > Cc: Sudeep Holla > > Cc: Geert Uytterhoeven > > Cc: linux-...@vger.kernel.org > > Cc: linux-cry...@vger.kernel.org > > Cc: dri-de...@lists.freedesktop.org > > Cc: dmaeng...@vger.kernel.org > > Cc: linux...@vger.kernel.org > > Cc: iommu@lists.linux-foundation.org > > Cc: linux-l...@vger.kernel.org > > Cc: linux-me...@vger.kernel.org > > Cc: net...@vger.kernel.org > > Cc: linux-...@vger.kernel.org > > Cc: linux-wirel...@vger.kernel.org > > Cc: linux-...@lists.infradead.org > > Cc: linux-g...@vger.kernel.org > > Cc: linux-ri...@lists.infradead.org > > Cc: linux-remotep...@vger.kernel.org > > Cc: alsa-de...@alsa-project.org > > Cc: linux-...@vger.kernel.org > > Signed-off-by: Rob Herring > > --- > > [...] > > > .../bindings/remoteproc/st,stm32-rproc.yaml | 33 ++-- > > [...] > > > diff --git > > a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > index b587c97c282b..be3d9b0e876b 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > @@ -29,17 +29,22 @@ properties: > > > >st,syscfg-holdboot: > > description: remote processor reset hold boot > > - - Phandle of syscon block. > > - - The offset of the hold boot setting register. > > - - The field mask of the hold boot. > > $ref: "/schemas/types.yaml#/definitions/phandle-array" > > -maxItems: 1 > > +items: > > + - items: > > + - description: Phandle of syscon block > > + - description: The offset of the hold boot setting register > > + - description: The field mask of the hold boot > > > >st,syscfg-tz: > > description: > >Reference to the system configuration which holds the RCC trust zone > > mode > > $ref: "/schemas/types.yaml#/definitions/phandle-array" > > -maxItems: 1 > > +items: > > + - items: > > + - description: Phandle of syscon block > > + - description: FIXME > > + - description: FIXME > > - description: The offset of the trust zone setting register > - description: The field mask of the trust zone state > > > > >interrupts: > > description: Should contain the WWDG1 watchdog reset interrupt > > @@ -93,20 +98,32 @@ properties: >
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Wed, Jan 19, 2022 at 4:35 AM Vladimir Oltean wrote: > > On Tue, Jan 18, 2022 at 07:50:38PM -0600, Rob Herring wrote: > > The 'phandle-array' type is a bit ambiguous. It can be either just an > > array of phandles or an array of phandles plus args. Many schemas for > > phandle-array properties aren't clear in the schema which case applies > > though the description usually describes it. > > > > The array of phandles case boils down to needing: > > > > items: > > maxItems: 1 > > > > The phandle plus args cases should typically take this form: > > > > items: > > - items: > > - description: A phandle > > - description: 1st arg cell > > - description: 2nd arg cell > > > > With this change, some examples need updating so that the bracketing of > > property values matches the schema. > > --- > (...) > > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > index 702df848a71d..c504feeec6db 100644 > > --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > @@ -34,6 +34,8 @@ properties: > >full routing information must be given, not just the one hop > >routes to neighbouring switches > > $ref: /schemas/types.yaml#/definitions/phandle-array > > +items: > > + maxItems: 1 > > > >ethernet: > > description: > > For better or worse, the mainline cases of this property all take the > form of: > > arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts > link = < >; > link = < >; > arch/arm/boot/dts/vf610-zii-dev-rev-b.dts > link = < > >; > link = < > >; > arch/arm/boot/dts/vf610-zii-scu4-aib.dts > link = < > > >; > link = < > >; > link = < > >; > > So not really an array of phandles. Either form is an array. The DT yaml encoding maintains the bracketing, so how the schema is defined matters. To some extent the tools will process the schema to support both forms of bracketing, but this has turned out to be fragile and just doesn't work for phandle arrays. I'm working on further changes that will get rid of the yaml encoded DT format and validate DTB files directly. These obviously have no bracketing and needing the DTS source files to change goes away. However, to be able to construct the internal format for validation, I do need the schemas to have more information on what exactly the phandle-array contains. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] dt-bindings: Improve phandle-array schemas
The 'phandle-array' type is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. Many schemas for phandle-array properties aren't clear in the schema which case applies though the description usually describes it. The array of phandles case boils down to needing: items: maxItems: 1 The phandle plus args cases should typically take this form: items: - items: - description: A phandle - description: 1st arg cell - description: 2nd arg cell With this change, some examples need updating so that the bracketing of property values matches the schema. Cc: Damien Le Moal Cc: Herbert Xu Cc: "David S. Miller" Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Laurent Pinchart Cc: Kieran Bingham Cc: Vinod Koul Cc: Georgi Djakov Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Joerg Roedel Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Pavel Machek Cc: Mauro Carvalho Chehab Cc: Krzysztof Kozlowski Cc: Jakub Kicinski Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: Andrew Lunn Cc: Vivien Didelot Cc: Florian Fainelli Cc: Vladimir Oltean Cc: Kalle Valo Cc: Viresh Kumar Cc: Stephen Boyd Cc: Kishon Vijay Abraham I Cc: Linus Walleij Cc: "Rafael J. Wysocki" Cc: Kevin Hilman Cc: Ulf Hansson Cc: Sebastian Reichel Cc: Mark Brown Cc: Mathieu Poirier Cc: Daniel Lezcano Cc: Zhang Rui Cc: Greg Kroah-Hartman Cc: Thierry Reding Cc: Jonathan Hunter Cc: Sudeep Holla Cc: Geert Uytterhoeven Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: dmaeng...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: iommu@lists.linux-foundation.org Cc: linux-l...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Cc: linux-...@lists.infradead.org Cc: linux-g...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: linux-remotep...@vger.kernel.org Cc: alsa-de...@alsa-project.org Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/cpus.yaml | 2 + .../devicetree/bindings/arm/idle-states.yaml | 80 +-- .../devicetree/bindings/arm/pmu.yaml | 2 + .../bindings/ata/sata_highbank.yaml | 3 + .../bus/allwinner,sun50i-a64-de2.yaml | 5 +- .../bindings/crypto/intel,ixp4xx-crypto.yaml | 15 +++- .../allwinner,sun4i-a10-display-engine.yaml | 2 + .../display/mediatek/mediatek,hdmi.yaml | 5 +- .../devicetree/bindings/display/msm/gpu.yaml | 2 + .../bindings/display/renesas,du.yaml | 10 ++- .../display/rockchip/rockchip-drm.yaml| 2 + .../display/sprd/sprd,display-subsystem.yaml | 2 + .../bindings/display/ti/ti,am65x-dss.yaml | 3 +- .../devicetree/bindings/dma/dma-router.yaml | 2 + .../bindings/dma/st,stm32-dmamux.yaml | 2 +- .../bindings/dvfs/performance-domain.yaml | 1 - .../bindings/interconnect/qcom,rpmh.yaml | 2 + .../interrupt-controller/arm,gic-v3.yaml | 6 +- .../interrupt-controller/ti,sci-inta.yaml | 2 + .../bindings/iommu/mediatek,iommu.yaml| 6 +- .../bindings/iommu/renesas,ipmmu-vmsa.yaml| 6 ++ .../leds/backlight/led-backlight.yaml | 2 + .../allwinner,sun4i-a10-video-engine.yaml | 4 + .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 10 +-- .../devicetree/bindings/media/ti,cal.yaml | 4 + .../memory-controllers/mediatek,smi-larb.yaml | 2 +- .../samsung,exynos5422-dmc.yaml | 2 + .../net/allwinner,sun4i-a10-emac.yaml | 4 + .../bindings/net/can/bosch,c_can.yaml | 8 +- .../bindings/net/can/fsl,flexcan.yaml | 12 +-- .../devicetree/bindings/net/dsa/dsa-port.yaml | 2 + .../devicetree/bindings/net/fsl,fec.yaml | 8 +- .../bindings/net/intel,ixp4xx-ethernet.yaml | 15 +++- .../bindings/net/intel,ixp4xx-hss.yaml| 33 ++-- .../bindings/net/nxp,dwmac-imx.yaml | 4 + .../bindings/net/socionext,uniphier-ave4.yaml | 4 + .../devicetree/bindings/net/stm32-dwmac.yaml | 4 + .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 5 ++ .../bindings/net/wireless/mediatek,mt76.yaml | 4 + .../devicetree/bindings/opp/opp-v2-base.yaml | 2 + .../devicetree/bindings/perf/arm,dsu-pmu.yaml | 2 + .../bindings/phy/intel,combo-phy.yaml | 8 ++ .../devicetree/bindings/phy/ti,omap-usb2.yaml | 4 + .../pinctrl/aspeed,ast2500-pinctrl.yaml | 2 + .../bindings/pinctrl/canaan,k210-fpioa.yaml | 4 + .../pinctrl/mediatek,mt65xx-pinctrl.yaml | 2 + .../bindings/pinctrl/st,stm32-pinctrl.yaml| 10 ++- .../bindings/power/power-domain.yaml | 4 + .../bindings/power/renesas,apmu.yaml | 2 + .../power/rockchip,power-controller.yaml | 2 + .../bindings/power/supply/cw2015_battery.yaml | 6 +- .../bindings/power/supply/power-supply.yaml | 2 + .../bindings/regulator/regulator.yaml
Re: [PATCH v3] dt-bindings: iommu: Convert msm,iommu-v0 to yaml
On Sat, Jan 08, 2022 at 07:41:42PM +0100, David Heidelberg wrote:
> Convert Qualcomm IOMMU v0 implementation to yaml format.
>
> Signed-off-by: David Heidelberg
> ---
> v2:
> - fix wrong path in binding $id
> - comment qcom,mdp4 node example (we don't want to validate it yet)
>
> v3:
> - I kept the name as -v0, since we have other binding -v1 and it look
>good, I can change thou in v4 if requested.
The preference is to use compatible strings for filenames. There's
little reason not to do that here.
> - dropped non-existent smmu_clk part (and adjusted example, which was
>using it)
> - dropped iommu description
> - moved iommu-cells description to the property #iommu-cells
> Signed-off-by: David Heidelberg
> ---
> .../bindings/iommu/msm,iommu-v0.txt | 64 -
> .../bindings/iommu/qcom,iommu-v0.yaml | 91 +++
> 2 files changed, 91 insertions(+), 64 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> b/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> deleted file mode 100644
> index 20236385f26e..
> --- a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> +++ /dev/null
> @@ -1,64 +0,0 @@
> -* QCOM IOMMU
> -
> -The MSM IOMMU is an implementation compatible with the ARM VMSA short
> -descriptor page tables. It provides address translation for bus masters
> outside
> -of the CPU, each connected to the IOMMU through a port called micro-TLB.
> -
> -Required Properties:
> -
> - - compatible: Must contain "qcom,apq8064-iommu".
> - - reg: Base address and size of the IOMMU registers.
> - - interrupts: Specifiers for the MMU fault interrupts. For instances that
> -support secure mode two interrupts must be specified, for non-secure and
> -secure mode, in that order. For instances that don't support secure mode
> a
> -single interrupt must be specified.
> - - #iommu-cells: The number of cells needed to specify the stream id. This
> - is always 1.
> - - qcom,ncb: The total number of context banks in the IOMMU.
> - - clocks : List of clocks to be used during SMMU register access. See
> - Documentation/devicetree/bindings/clock/clock-bindings.txt
> - for information about the format. For each clock specified
> - here, there must be a corresponding entry in clock-names
> - (see below).
> -
> - - clock-names : List of clock names corresponding to the clocks
> specified in
> - the "clocks" property (above).
> - Should be "smmu_pclk" for specifying the interface clock
> - required for iommu's register accesses.
> - Should be "smmu_clk" for specifying the functional clock
> - required by iommu for bus accesses.
> -
> -Each bus master connected to an IOMMU must reference the IOMMU in its device
> -node with the following property:
> -
> - - iommus: A reference to the IOMMU in multiple cells. The first cell is a
> - phandle to the IOMMU and the second cell is the stream id.
> - A single master device can be connected to more than one iommu
> - and multiple contexts in each of the iommu. So multiple entries
> - are required to list all the iommus and the stream ids that the
> - master is connected to.
> -
> -Example: mdp iommu and its bus master
> -
> -mdp_port0: iommu@750 {
> - compatible = "qcom,apq8064-iommu";
> - #iommu-cells = <1>;
> - clock-names =
> - "smmu_pclk",
> - "smmu_clk";
> - clocks =
> - < SMMU_AHB_CLK>,
> - < MDP_AXI_CLK>;
> - reg = <0x0750 0x10>;
> - interrupts =
> - ,
> - ;
> - qcom,ncb = <2>;
> - };
> -
> - mdp: qcom,mdp@510 {
> - compatible = "qcom,mdp";
> - ...
> - iommus = <_port0 0
> - _port0 2>;
> - };
> diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
> b/Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
> new file mode 100644
> index ..a506e8ad8902
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: "http://devicetree.org/schemas/iommu/qcom,iommu-v0.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Qualcomm IOMMU for APQ8064
> +
> +maintainers:
> + -
Re: [PATCH v2] dt-bindings: iommu: Convert msm,iommu-v0 to yaml
On Sat, Dec 25, 2021 at 08:35:55PM +0100, David Heidelberg wrote:
> Convert Qualcomm IOMMU v0 implementation to yaml format.
>
> Signed-off-by: David Heidelberg
> ---
> v2:
> - fix wrong path in binding $id
> - comment qcom,mdp4 node example (we don't want to validate it yet)
>
> .../bindings/iommu/msm,iommu-v0.txt | 64 -
> .../bindings/iommu/qcom,iommu-v0.yaml | 96 +++
qcom,apq8064-iommu.yaml
At this point, I don't think we'll get a 2nd user.
> 2 files changed, 96 insertions(+), 64 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> b/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> deleted file mode 100644
> index 20236385f26e..
> --- a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> +++ /dev/null
> @@ -1,64 +0,0 @@
> -* QCOM IOMMU
> -
> -The MSM IOMMU is an implementation compatible with the ARM VMSA short
> -descriptor page tables. It provides address translation for bus masters
> outside
> -of the CPU, each connected to the IOMMU through a port called micro-TLB.
> -
> -Required Properties:
> -
> - - compatible: Must contain "qcom,apq8064-iommu".
> - - reg: Base address and size of the IOMMU registers.
> - - interrupts: Specifiers for the MMU fault interrupts. For instances that
> -support secure mode two interrupts must be specified, for non-secure and
> -secure mode, in that order. For instances that don't support secure mode
> a
> -single interrupt must be specified.
> - - #iommu-cells: The number of cells needed to specify the stream id. This
> - is always 1.
> - - qcom,ncb: The total number of context banks in the IOMMU.
> - - clocks : List of clocks to be used during SMMU register access. See
> - Documentation/devicetree/bindings/clock/clock-bindings.txt
> - for information about the format. For each clock specified
> - here, there must be a corresponding entry in clock-names
> - (see below).
> -
> - - clock-names : List of clock names corresponding to the clocks
> specified in
> - the "clocks" property (above).
> - Should be "smmu_pclk" for specifying the interface clock
> - required for iommu's register accesses.
> - Should be "smmu_clk" for specifying the functional clock
> - required by iommu for bus accesses.
> -
> -Each bus master connected to an IOMMU must reference the IOMMU in its device
> -node with the following property:
> -
> - - iommus: A reference to the IOMMU in multiple cells. The first cell is a
> - phandle to the IOMMU and the second cell is the stream id.
> - A single master device can be connected to more than one iommu
> - and multiple contexts in each of the iommu. So multiple entries
> - are required to list all the iommus and the stream ids that the
> - master is connected to.
> -
> -Example: mdp iommu and its bus master
> -
> -mdp_port0: iommu@750 {
> - compatible = "qcom,apq8064-iommu";
> - #iommu-cells = <1>;
> - clock-names =
> - "smmu_pclk",
> - "smmu_clk";
> - clocks =
> - < SMMU_AHB_CLK>,
> - < MDP_AXI_CLK>;
> - reg = <0x0750 0x10>;
> - interrupts =
> - ,
> - ;
> - qcom,ncb = <2>;
> - };
> -
> - mdp: qcom,mdp@510 {
> - compatible = "qcom,mdp";
> - ...
> - iommus = <_port0 0
> - _port0 2>;
> - };
> diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
> b/Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
> new file mode 100644
> index ..6f166c30b9ec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: "http://devicetree.org/schemas/iommu/qcom,iommu-v0.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Qualcomm IOMMU for APQ8064
> +
> +maintainers:
> + - Will Deacon
> +
> +description: >
> + The MSM IOMMU is an implementation compatible with the ARM VMSA short
> + descriptor page tables. It provides address translation for bus masters
> + outside of the CPU, each connected to the IOMMU through a port called
> micro-TLB.
> +
> +properties:
> + compatible:
> +const: qcom,apq8064-iommu
> +
> + clocks:
> +items:
>
Re: [PATCH] dt-bindings: iommu: Convert msm,iommu-v0 to yaml
On Fri, 24 Dec 2021 17:50:14 +0100, David Heidelberg wrote: > Convert Qualcomm IOMMU v0 implementation to yaml format. > > Signed-off-by: David Heidelberg > --- > .../bindings/iommu/msm,iommu-v0.txt | 64 - > .../bindings/iommu/qcom,iommu-v0.yaml | 96 +++ > 2 files changed, 96 insertions(+), 64 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt > create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu-v0.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: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/iommu/qcom,iommu-v0.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/iommu/qcom,iommu-v0.yaml# Documentation/devicetree/bindings/iommu/qcom,iommu-v0.example.dts:37.26-43.11: Warning (unit_address_vs_reg): /example-0/mdp@510: node has a unit name, but no reg or ranges property Documentation/devicetree/bindings/iommu/qcom,iommu-v0.example.dt.yaml:0:0: /example-0/mdp@510: failed to match any schema with compatible: ['qcom,mdp4'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1573077 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 v2 1/4] dt-bindings: arm-smmu: Document nvidia,memory-controller property
On Thu, 09 Dec 2021 17:35:57 +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. > > Note that this is a backwards-incompatible change that is, however, > necessary to ensure correctness. Without the new property, most of the > devices would still work but it is not guaranteed that all will. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - clarify why the new nvidia,memory-controller property is required > > .../devicetree/bindings/iommu/arm,smmu.yaml | 17 + > 1 file changed, 17 insertions(+) > Reviewed-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/4] dt-bindings: memory: mediatek: Add mt8186 support
On Fri, 03 Dec 2021 14:40:25 +0800, Yong Wu wrote: > Add mt8186 smi support in the bindings. > > Signed-off-by: Yong Wu > --- > .../bindings/memory-controllers/mediatek,smi-common.yaml | 4 +++- > .../bindings/memory-controllers/mediatek,smi-larb.yaml| 3 +++ > 2 files changed, 6 insertions(+), 1 deletion(-) > Acked-by: Rob Herring ___ 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
On Mon, Dec 13, 2021 at 02:48:52PM +0800, Yong Wu wrote:
> On Fri, 2021-12-03 at 17:34 -0600, Rob Herring wrote:
> > 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
>
> I will fix this in next version. This property is not needed in mt8167.
>
> >
> > 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
>
> Some larbs only have two clocks(apb/smi) in mt8183. thus it is
> reasonable for me. I won't fix this in next version.
You also need to adjust 'clock-names' to allow for 2 items.
Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] dt-bindings: arm-smmu: Add compatible for SM8450 SoC
On Wed, 01 Dec 2021 13:09:42 +0530, Vinod Koul wrote: > Add the SoC specific compatible for SM8450 implementing > arm,mmu-500. > > Signed-off-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: [PATCH 1/2] dt-bindings: arm-smmu: Fix json-schema for Tegra
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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] dt-bindings: Drop redundant minItems/maxItems
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
