Re: [PATCH 1/6 v3] Docs: dt: add fsl-mc iommu-map device-tree binding

[Rob Herring]

On Fri, Apr 27, 2018 at 03:57:01PM +0530, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a generic binding for
> mapping fsl-mc devices to IOMMUs, using iommu-map property.
> 
> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 
> ++
>  1 file changed, 39 insertions(+)

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

Re: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for other devices too

[Rob Herring]

On Fri, Apr 27, 2018 at 03:57:02PM +0530, Nipun Gupta wrote:
> iommu-map property is also used by devices with fsl-mc. This
> patch moves the of_pci_map_rid to generic location, so that it
> can be used by other busses too.
> 
> 'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
> functional change done in the API.
> 
> Signed-off-by: Nipun Gupta 
> ---
>  drivers/iommu/of_iommu.c   |   6 +--
>  drivers/of/address.c   | 102 
> +
>  drivers/of/irq.c   |   7 ++--
>  drivers/pci/of.c   | 101 
>  include/linux/of_address.h |  11 +
>  include/linux/of_pci.h |  10 -
>  6 files changed, 120 insertions(+), 117 deletions(-)

of/address.c isn't really the best fit either, though I don't have a 
better suggestion. 

I'm guessing this breaks on Sparc which doesn't build of/address.c. 
I guess move it to base.c and of.h if that is the case.

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

Re: [PATCH 1/2] dt-bindings: iommu/rockchip: Make clock properties optional

[Rob Herring]

On Tue, Apr 10, 2018 at 01:26:41PM +0200, Heiko Stuebner wrote:
> Hi Robin,
> 
> Am Dienstag, 10. April 2018, 13:18:48 CEST schrieb Robin Murphy:
> > On 10/04/18 10:26, Heiko Stuebner wrote:
> > > Rockchip IOMMUs are used without explicit clock handling for 4 years
> > > now, so we should keep compatibility with old devicetrees if possible.
> > > Therefore make iommu clocks optional.
> > 
> > Do we need to touch the binding itself? Obviously the driver has to 
> > treat clocks as optional in existing DTs (and I feel a bit dumb now for 
> > managing to overlook that in review), but the binding effectively only 
> > covers future DTs, and I'd assume we want to encourage the clocks to be 
> > correctly specified there.

I'd prefer the DT docs reflect what is correct for new/current dts 
files. That's the only way the docs can validate the dts files.

> I guess that depends on your definition of the timespan for backwards
> compatibility. I'm always starting out at indefinite till convinced
> otherwise ;-). Hence the clocks would need to stay optional for (nearly)
> forever.
> 
> Also, having the binding claim them as required but the code handling
> them as optional just calls for someone to remove the optional handling :-D

A comment in the code saying why missing clocks are allowed should 
suffice.

> Not sure if there is a established way of saying
> "we want this for all future devices, but allow it to be missing for old dts".

We don't really...

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

Re: [PATCH v3 2/2] drivers: remove force dma flag from buses

[Rob Herring]

On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if implicit DMA
> configuration is required even when it is not described by the
> firmware.
> 
> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> ---
> Changes in v2:
>   - This is a new change suggested by Robin and Christoph
> and is added to the series.
> 
> Changes in v3:
>   - Rebase and changes corresponding to the changes in patch 1/2
> 
>  drivers/amba/bus.c| 1 -
>  drivers/base/platform.c   | 3 +--
>  drivers/bcma/main.c   | 2 +-
>  drivers/dma/qcom/hidma_mgmt.c | 2 +-
>  drivers/gpu/host1x/bus.c  | 5 ++---
>  drivers/of/device.c   | 6 --
>  drivers/of/of_reserved_mem.c  | 2 +-
>  drivers/pci/pci-driver.c  | 3 +--
>  include/linux/device.h| 4 
>  include/linux/of_device.h     | 8 ++--
>  10 files changed, 17 insertions(+), 19 deletions(-)

Reviewed-by: Rob Herring <r...@kernel.org>

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

Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

[Rob Herring]

On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
 wrote:
> Hi all,
>
> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>
> The intention of this is twofold:
>   1. To catch users of the DMA API on systems that do no support the DMA
>  mapping API,
>   2. To avoid building drivers that cannot work on such systems anyway.
>
> However, the disadvantage is that we have to keep on adding dependencies
> on HAS_DMA all over the place.
>
> Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
> more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
> already covering intention #2.  Having to add an explicit dependency on
> HAS_DMA here is cumbersome, and hinders compile-testing.

The same can be said for CONFIG_IOMEM and CONFIG_OF. Any plans to
remove those too? CONFIG_IOMEM is mostly just a !CONFIG_UM option.

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

Re: [PATCH] iommu/ipmmu-vmsa: Document R-Car M3-N IPMMU DT bindings

[Rob Herring]

On Tue, Mar 20, 2018 at 03:48:11PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Update the IPMMU DT binding documentation to include the r8a77965 compat
> string for the IPMMU devices included in the R-Car M3-N SoC.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> ---
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
>  1 file changed, 1 insertion(+)

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

Re: [PATCH v8 09/14] dt-bindings: iommu/rockchip: Add clock property

[Rob Herring]

On Fri, Mar 23, 2018 at 03:38:09PM +0800, Jeffy Chen wrote:
> Add clock property, since we are going to control clocks in rockchip
> iommu driver.
> 
> Signed-off-by: Jeffy Chen <jeffy.c...@rock-chips.com>
> Reviewed-by: Robin Murphy <robin.mur...@arm.com>
> ---

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

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Rob Herring]

On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Signed-off-by: Nipun Gupta 
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31 
> ++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware 
> objects/devices
>  such as network interfaces, crypto accelerator instances, L2 switches,
>  etc.
>  
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.
> +
> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.

Why not? It is just a link between 2 nodes.

> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
>  Required properties:
>  
>  - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
>Value type: 
>Definition: Specifies the phandle to the PHY device node 
> associated
>with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> +  The property specifies the IOMMU behind which the devices on
> +  fsl-mc bus are residing.

If you want a generic property, this should be documented in the common 
binding.

Couldn't you have more than 1 IOMMU upstream of a MC?

>  
>  Example:
>  
> +smmu: iommu@500 {
> +   compatible = "arm,mmu-500";
> +   #iommu-cells = <1>;
> +   stream-match-mask = <0x7C00>;
> +   ...
> +};
> +
>  fsl_mc: fsl-mc@80c00 {
>  compatible = "fsl,qoriq-mc";
>  reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
><0x 0x0834 0 0x4>; /* MC control reg */
>  msi-parent = <>;
> +iommu-parent = <>;
>  #address-cells = <3>;
>  #size-cells = <1>;
>  
> -- 
> 1.9.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/1] iommu/arm-smmu: Add support for qcom, smmu-500 variant

[Rob Herring]

On Wed, Mar 7, 2018 at 12:32 AM, Vivek Gautam
 wrote:
> Qualcomm's arm-smmu 500 implementation supports runtime pm
> so enable the same.

That's a driver detail unrelated to the binding.

>
> Signed-off-by: Vivek Gautam 
> ---
>
>  Based on iommu/arm-smmu pm runtime support series [1]:
>  [PATCH v8 0/5] iommu/arm-smmu: Add runtime pm/sleep support
>
>  Tested on sdm845 with necessary support to enable the smmu
>  and with necessary user.
>
>  [1] https://lkml.org/lkml/2018/3/2/325
>
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 14 ++

Please split bindings to separate patches.

>  drivers/iommu/arm-smmu.c |  8 
>  2 files changed, 22 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 6ea27bd4f785..0b5c6d2a9865 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -18,6 +18,7 @@ conditions.
>  "arm,mmu-500"
>  "cavium,smmu-v2"
>  "qcom,-smmu-v2", "qcom,smmu-v2"

I don't even see this one in the tree yet...

> +"qcom,-smmu-500", "qcom,smmu-500"

IIRC, the mmu-500 is SMMU v2 implementation, right? Having
qcom,smmu-500 seems kind of pointless.

Given that we're there's only 1 SoC for "qcom,-smmu-v2" and
you're already on to a new genericish compatible, just do SoC specific
compatible strings.

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

Re: [RESEND PATCH v6 09/14] dt-bindings: iommu/rockchip: Add clock property

[Rob Herring]

On Thu, Mar 01, 2018 at 06:18:32PM +0800, Jeffy Chen wrote:
> Add clock property, since we are going to control clocks in rockchip
> iommu driver.
> 
> Signed-off-by: Jeffy Chen <jeffy.c...@rock-chips.com>
> ---
> 
> Changes in v6: None

Really? There was a different number of clocks before.

> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/iommu/rockchip,iommu.txt | 7 +++
>  1 file changed, 7 insertions(+)

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

Re: [PATCH 5/8] dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)

[Rob Herring]

On Mon, Feb 26, 2018 at 06:57:13PM +0100, Jacopo Mondi wrote:
> Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings
> documentation.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [PATCH 11/37] dt-bindings: document stall and PASID properties for IOMMU masters

[Rob Herring]

On Mon, Feb 12, 2018 at 06:33:26PM +, Jean-Philippe Brucker wrote:
> On ARM systems, some platform devices behind an IOMMU may support stall
> and PASID features. Stall is the ability to recover from page faults and
> PASID offers multiple process address spaces to the device. Together they
> allow to do paging with a device. Let the firmware tell us when a device
> supports stall and PASID.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>
> ---
>  Documentation/devicetree/bindings/iommu/iommu.txt | 24 
> +++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt 
> b/Documentation/devicetree/bindings/iommu/iommu.txt
> index 5a8b4624defc..8066b3852110 100644
> --- a/Documentation/devicetree/bindings/iommu/iommu.txt
> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
> @@ -86,6 +86,30 @@ have a means to turn off translation. But it is invalid in 
> such cases to
>  disable the IOMMU's device tree node in the first place because it would
>  prevent any driver from properly setting up the translations.
>  
> +Optional properties:
> +
> +- dma-can-stall: When present, the master can wait for a transaction to
> +  complete for an indefinite amount of time. Upon translation fault some
> +  IOMMUs, instead of aborting the translation immediately, may first
> +  notify the driver and keep the transaction in flight. This allows the OS
> +  to inspect the fault and, for example, make physical pages resident
> +  before updating the mappings and completing the transaction. Such IOMMU
> +  accepts a limited number of simultaneous stalled transactions before
> +  having to either put back-pressure on the master, or abort new faulting
> +  transactions.
> +
> +  Firmware has to opt-in stalling, because most buses and masters don't
> +  support it. In particular it isn't compatible with PCI, where
> +  transactions have to complete before a time limit. More generally it
> +  won't work in systems and masters that haven't been designed for
> +  stalling. For example the OS, in order to handle a stalled transaction,
> +  may attempt to retrieve pages from secondary storage in a stalled
> +  domain, leading to a deadlock.
> +
> +- pasid-bits: Some masters support multiple address spaces for DMA, by
> +  tagging DMA transactions with an address space identifier. By default,
> +  this is 0, which means that the device only has one address space.

So 3 would mean 8 address spaces?

Maybe pasid-num-bits would be a bit clearer. Either way,

Reviewed-by: Rob Herring <r...@kernel.org>

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

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Rob Herring]

On Wed, Jan 31, 2018 at 1:52 AM, Tomasz Figa <tf...@chromium.org> wrote:
> Hi Rob,
>
> On Wed, Jan 31, 2018 at 2:05 AM, Rob Herring <r...@kernel.org> wrote:
>> On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote:
>>> From: Tomasz Figa <tf...@chromium.org>
>>>
>>> Current code relies on master driver enabling necessary clocks before
>>> IOMMU is accessed, however there are cases when the IOMMU should be
>>> accessed while the master is not running yet, for example allocating
>>> V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
>>> mapping API and doesn't engage the master driver at all.
>>>
>>> This patch fixes the problem by letting clocks needed for IOMMU
>>> operation to be listed in Device Tree and making the driver enable them
>>> for the time of accessing the hardware.
>>>
>>> Signed-off-by: Jeffy Chen <jeffy.c...@rock-chips.com>
>>> Signed-off-by: Tomasz Figa <tf...@chromium.org>
>>> ---
>>>
>>> Changes in v5:
>>> Use clk_bulk APIs.
>>>
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>>  .../devicetree/bindings/iommu/rockchip,iommu.txt   |  8 +++
>>
>> Please split binding patches to a separate patch.
>>
>>>  drivers/iommu/rockchip-iommu.c | 74 
>>> --
>>>  2 files changed, 76 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
>>> b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>>> index 2098f7732264..33dd853359fa 100644
>>> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>>> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>>> @@ -14,6 +14,13 @@ Required properties:
>>>  "single-master" device, and needs no additional 
>>> information
>>>  to associate with its master device.  See:
>>>  Documentation/devicetree/bindings/iommu/iommu.txt
>>> +Optional properties:
>>> +- clocks : A list of master clocks requires for the IOMMU to be accessible
>>> +   by the host CPU. The number of clocks depends on the master
>>> +   block and might as well be zero. See [1] for generic clock
>>> +   bindings description.
>>
>> Hardware blocks don't have a variable number of clock connections.
>
> I think you underestimate the imagination of hardware designers. :)

Learned long ago to never do that. If there are 2 ways to do
something, they will find a 3rd way.

> For Rockchip IOMMU, there is a set of clocks, which all need to be
> enabled for IOMMU register access to succeed. The clocks are not
> directly fed to the IOMMU, but they are needed for the various buses
> and intermediate blocks on the way to the IOMMU to work.

The binding should describe the clock connections, not what clocks a
driver needs (currently). It sounds like a lack of managing bus clocks
to me.

In any case, the binding must be written so it can be verified. If you
can have any number of clocks with any names, there's no point in
documenting.

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

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Rob Herring]

On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote:
> From: Tomasz Figa 
> 
> Current code relies on master driver enabling necessary clocks before
> IOMMU is accessed, however there are cases when the IOMMU should be
> accessed while the master is not running yet, for example allocating
> V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
> mapping API and doesn't engage the master driver at all.
> 
> This patch fixes the problem by letting clocks needed for IOMMU
> operation to be listed in Device Tree and making the driver enable them
> for the time of accessing the hardware.
> 
> Signed-off-by: Jeffy Chen 
> Signed-off-by: Tomasz Figa 
> ---
> 
> Changes in v5:
> Use clk_bulk APIs.
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  .../devicetree/bindings/iommu/rockchip,iommu.txt   |  8 +++

Please split binding patches to a separate patch.

>  drivers/iommu/rockchip-iommu.c | 74 
> --
>  2 files changed, 76 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> index 2098f7732264..33dd853359fa 100644
> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> @@ -14,6 +14,13 @@ Required properties:
>  "single-master" device, and needs no additional 
> information
>  to associate with its master device.  See:
>  Documentation/devicetree/bindings/iommu/iommu.txt
> +Optional properties:
> +- clocks : A list of master clocks requires for the IOMMU to be accessible
> +   by the host CPU. The number of clocks depends on the master
> +   block and might as well be zero. See [1] for generic clock
> +   bindings description.

Hardware blocks don't have a variable number of clock connections. This 
needs to be a defined number of clocks (per compatible string if there 
are different implementations with different # of clocks).

> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>  
>  Optional properties:
>  - rockchip,disable-mmu-reset : Don't use the mmu reset operation.
> @@ -27,5 +34,6 @@ Example:
>   reg = <0xff940300 0x100>;
>   interrupts = ;
>   interrupt-names = "vopl_mmu";
> + clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
>   #iommu-cells = <0>;
>   };
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v6 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Rob Herring]

On Fri, Jan 19, 2018 at 05:13:42PM +0530, Vivek Gautam wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
> 
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 43 
> ++
>  drivers/iommu/arm-smmu.c   | 13 +++
>  2 files changed, 56 insertions(+)

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

Re: [PATCH v5 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Rob Herring]

On Tue, Jan 09, 2018 at 03:31:48PM +0530, Vivek Gautam wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
> 
> Signed-off-by: Vivek Gautam 
> ---
> 
>  * Major change in this patch -
>Changed compatible string from 'qcom,msm8996-smmu-v2' to
>'qcom,smmu-v2' to reflect the IP version rather than the
>platform on which it is used.

The bugs and how things are connected are all the same? I'd suggest you 
keep both strings.

>The same IP is used across multiple platforms including msm8996,
>and sdm845 etc.

But for only 2 or so platforms a fallback is not really worth it. You'll 
probably be on SMMUv3 before too long...

> 
>  .../devicetree/bindings/iommu/arm,smmu.txt | 35 
> ++
>  drivers/iommu/arm-smmu.c   | 13 
>  2 files changed, 48 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 8a6ffce12af5..e4951288c87c 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -17,6 +17,7 @@ conditions.
>  "arm,mmu-401"
>  "arm,mmu-500"
>  "cavium,smmu-v2"
> +"qcom,smmu-v2"
>  
>depending on the particular implementation and/or the
>version of the architecture implemented.
> @@ -71,6 +72,23 @@ conditions.
>or using stream matching with #iommu-cells = <2>, and
>may be ignored if present in such cases.
>  
> +- clock-names:Should be "bus", and "iface" for "qcom,smmu-v2"
> +  implementation.
> +
> +  "bus" clock for "qcom,smmu-v2" is required for downstream
> +  bus access and for the smmu ptw.
> +
> +  "iface" clock is required to access smmu's registers 
> through
> +  the TCU's programming interface.
> +
> +- clocks: Phandles for respective clocks described by clock-names.
> +
> +- power-domains:  Phandles to SMMU's power domain specifier. This is
> +  required even if SMMU belongs to the master's power
> +  domain, as the SMMU will have to be enabled and
> +  accessed before master gets enabled and linked to its
> +  SMMU.
> +
>  ** Deprecated properties:
>  
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> @@ -137,3 +155,20 @@ conditions.
>  iommu-map = <0  0 0x400>;
>  ...
>  };
> +
> + /* Qcom's arm,smmu-v2 implementation */
> + smmu4: iommu {
> + compatible = "qcom,smmu-v2";
> + reg = <0xd0 0x1>;
> +
> + #global-interrupts = <1>;
> + interrupts = ,
> +  ,
> +  ;
> + #iommu-cells = <1>;
> + power-domains = < MDSS_GDSC>;
> +
> + clocks = < SMMU_MDP_AXI_CLK>,
> +  < SMMU_MDP_AHB_CLK>;
> + clock-names = "bus", "iface";
> + };
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 33bbcfedb896..2ade214c41bc 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -119,6 +119,7 @@ enum arm_smmu_implementation {
>   GENERIC_SMMU,
>   ARM_MMU500,
>   CAVIUM_SMMUV2,
> + QCOM_SMMUV2,
>  };
>  
>  struct arm_smmu_s2cr {
> @@ -1971,6 +1972,17 @@ struct arm_smmu_match_data {
>  ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
>  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
>  
> +static const char * const qcom_smmuv2_clks[] = {
> + "bus", "iface",
> +};
> +
> +static const struct arm_smmu_match_data qcom_smmuv2 = {
> + .version = ARM_SMMU_V2,
> + .model = QCOM_SMMUV2,
> + .clks = qcom_smmuv2_clks,
> + .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
> +};
> +
>  static const struct of_device_id arm_smmu_of_match[] = {
>   { .compatible = "arm,smmu-v1", .data = _generic_v1 },
>   { .compatible = "arm,smmu-v2", .data = _generic_v2 },
> @@ -1978,6 +1990,7 @@ struct arm_smmu_match_data {
>   { .compatible = "arm,mmu-401", .data = _mmu401 },
>   { .compatible = "arm,mmu-500", .data = _mmu500 },
>   { .compatible = "cavium,smmu-v2", .data = _smmuv2 },
> + { .compatible = "qcom,smmu-v2", .data = _smmuv2 },
>   { },
>  };
>  MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 
___
iommu mailing list

Re: [RFCv2 PATCH 12/36] dt-bindings: document stall and PASID properties for IOMMU masters

[Rob Herring]

On Mon, Oct 16, 2017 at 5:23 AM, Jean-Philippe Brucker
<jean-philippe.bruc...@arm.com> wrote:
> On 13/10/17 20:10, Rob Herring wrote:
>> On Fri, Oct 06, 2017 at 02:31:39PM +0100, Jean-Philippe Brucker wrote:
>>> On ARM systems, some platform devices behind an IOMMU may support stall
>>> and PASID features. Stall is the ability to recover from page faults and
>>> PASID offers multiple process address spaces to the device. Together they
>>> allow to do paging with a device. Let the firmware tell us when a device
>>> supports stall and PASID.
>>
>> Can't these be implied by the compatible string of the devices?
>
> I think that PASID capacity can be deduced from the compatible string but
> don't know how these devices will be implemented (the only known example
> being a software model for testing). In any case implementing PASID based
> on the compatible string is tricky, because the IOMMU driver needs to know
> PASID capacity before the device driver has had time to probe the device.
> Maybe we could get away with a static table associating compatible string
> to PASID capacity, but it's not very nice.
>
> For stall it's a property of the integration between device and IOMMU,
> much like the "iommus" property, so it can't be deduced only from the
> compatible string. It's crucial that the firmware validates that stalling
> is safe, because we don't have any other way to discover it.

Okay, fair enough. I'll let others comment.

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

Re: [RFCv2 PATCH 12/36] dt-bindings: document stall and PASID properties for IOMMU masters

[Rob Herring]

On Fri, Oct 06, 2017 at 02:31:39PM +0100, Jean-Philippe Brucker wrote:
> On ARM systems, some platform devices behind an IOMMU may support stall
> and PASID features. Stall is the ability to recover from page faults and
> PASID offers multiple process address spaces to the device. Together they
> allow to do paging with a device. Let the firmware tell us when a device
> supports stall and PASID.

Can't these be implied by the compatible string of the devices?

> 
> Signed-off-by: Jean-Philippe Brucker 
> ---
>  Documentation/devicetree/bindings/iommu/iommu.txt | 24 
> +++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt 
> b/Documentation/devicetree/bindings/iommu/iommu.txt
> index 5a8b4624defc..c589b75f7277 100644
> --- a/Documentation/devicetree/bindings/iommu/iommu.txt
> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
> @@ -86,6 +86,30 @@ have a means to turn off translation. But it is invalid in 
> such cases to
>  disable the IOMMU's device tree node in the first place because it would
>  prevent any driver from properly setting up the translations.
>  
> +Optional properties:
> +
> +- dma-can-stall: When present, the master can wait for a transaction to
> +  complete for an indefinite amount of time. Upon translation fault some
> +  IOMMUs, instead of aborting the translation immediately, may first
> +  notify the driver and keep the transaction in flight. This allows the OS
> +  to inspect the fault and, for example, make physical pages resident
> +  before updating the mappings and completing the transaction. Such IOMMU
> +  accepts a limited number of simultaneous stalled transactions before
> +  having to either put back-pressure on the master, or abort new faulting
> +  transactions.
> +
> +  Firmware has to opt-in stalling, because most buses and masters don't
> +  support it. In particular it isn't compatible with PCI, where
> +  transactions have to complete before a time limit. More generally it
> +  won't work in systems and masters that haven't been designed for
> +  stalling. For example the OS, in order to handle a stalled transaction,
> +  may attempt to retrieve pages from secondary storage in a stalled
> +  domain, leading to a deadlock.
> +
> +- pasid-bits: Some masters support multiple address spaces for DMA. By
> +  tagging DMA transactions with an address space identifier. By default,
> +  this is 0, which means that the device only has one address space.
> +
>  
>  Notes:
>  ==
> -- 
> 2.13.3
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dt-bindings: iommu: ipmmu-vmsa: Use generic node name

[Rob Herring]

On Wed, Oct 04, 2017 at 02:33:08PM +0200, Geert Uytterhoeven wrote:
> Use the preferred generic node name in the example.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied.

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

Re: [PATCH v8 1/5] Doc: iommu/arm-smmu-v3: Add workaround for HiSilicon erratum 161010801

[Rob Herring]

On Wed, Sep 27, 2017 at 02:32:37PM +0100, Shameer Kolothum wrote:
> From: John Garry <john.ga...@huawei.com>
> 
> The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> platforms hip06/hip07 to support the SMMU mappings for MSI transactions.
> 
> On these platforms, GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch adds a compatible string to implement this errata for
> HiSilicon Hi161x SMMUv3 model on hip06/hip07 platforms.
> 
> Also, the arm64 silicon errata is updated with this same erratum.
> 
> Signed-off-by: John Garry <john.ga...@huawei.com>
> [Shameer: Modified to use compatible string for errata]
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.th...@huawei.com>
> ---
>  Documentation/arm64/silicon-errata.txt  | 1 +
>  Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 9 -
>  2 files changed, 9 insertions(+), 1 deletion(-)

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

Re: [PATCH 3/3] iommu/ipmmu-vmsa: Document R-Car D3 IPMMU DT bindings

[Rob Herring]

On Fri, Sep 22, 2017 at 06:45:26AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Update the IPMMU DT binding documentation to include the r8a77995 compat
> string for the IPMMU devices included in the R-Car D3 SoC.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> ---
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <r...@kernel.org>

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

Re: [PATCH 2/3] iommu/ipmmu-vmsa: Document R-Car V3M IPMMU DT bindings

[Rob Herring]

On Fri, Sep 22, 2017 at 06:45:16AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Update the IPMMU DT binding documentation to include the r8a77970 compat
> string for the IPMMU devices included in the R-Car V3M SoC.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> ---
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
>  1 file changed, 1 insertion(+)

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

Re: [PATCH v7 1/5] Doc: iommu/arm-smmu-v3: Add workaround for HiSilicon erratum 161010801

[Rob Herring]

On Thu, Sep 14, 2017 at 01:57:52PM +0100, Shameer Kolothum wrote:
> From: John Garry 
> 
> The HiSilicon erratum 161010801 describes the limitation of HiSilicon 
> platforms
> hip06/hip07 to support the SMMU mappings for MSI transactions.
> 
> On these platforms, GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch adds a SMMUv3 binding to flag that the SMMU breaks msi
> translation at ITS.
> 
> Also, the arm64 silicon errata is updated with this same erratum.
> 
> Signed-off-by: John Garry 
> Signed-off-by: Shameer Kolothum 
> ---
>  Documentation/arm64/silicon-errata.txt  | 1 +
>  Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Documentation/arm64/silicon-errata.txt 
> b/Documentation/arm64/silicon-errata.txt
> index 66e8ce1..02816b1 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -70,6 +70,7 @@ stable kernels.
>  || | |   
>   |
>  | Hisilicon  | Hip0{5,6,7} | #161010101  | 
> HISILICON_ERRATUM_161010101 |
>  | Hisilicon  | Hip0{6,7}   | #161010701  | N/A   
>   |
> +| Hisilicon  | Hip0{6,7}   | #161010801  | N/A   
>   |
>  || | |   
>   |
>  | Qualcomm Tech. | Falkor v1   | E1003   | 
> QCOM_FALKOR_ERRATUM_1003|
>  | Qualcomm Tech. | Falkor v1   | E1009   | 
> QCOM_FALKOR_ERRATUM_1009|
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> index c9abbf3..1f5f7f9 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> @@ -55,6 +55,9 @@ the PCIe specification.
>  - hisilicon,broken-prefetch-cmd
>  : Avoid sending CMD_PREFETCH_* commands to the SMMU.
>  
> +- hisilicon,broken-untranslated-msi
> +: Reserve ITS HW region to avoid translating msi.
> +

This should be determined from the compatible string. Continuing to add 
properties for each errata doesn't scale.

>  - cavium,cn9900-broken-page1-regspace
>  : Replaces all page 1 offsets used for EVTQ_PROD/CONS,
> PRIQ_PROD/CONS register access with page 0 offsets.
> -- 
> 1.9.1
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 1/1] iommu/arm-smmu: Add support for multiple TBU child devices

[Rob Herring]

On Tue, Sep 12, 2017 at 05:31:07PM +0530, Vivek Gautam wrote:
> ARM MMU-500 implements a TBU (uTLB) for each connected master
> besides a single TCU which controls and manages the address
> translations. Each of these TBUs can either be in the same
> power domain as the master, or they can have a independent
> power switch.
> This design addresses the challenges to control TBU power.
> Adding child devices for each TBUs present in the configuration
> lets us control the power and clocks to TLBs having individual
> power domains. The device link between master devices (such as,
> display, and GPU) and TBU devices ensures that the master takes
> care of powering the smmu as long as it's available.
> When the master is not available, the TBUs are identified with
> sid and powered on.
> 
> Signed-off-by: Vivek Gautam 
> ---
> 
>  - The idea behind this patch is to handle the distributed smmu
>architectures, similar to MMU-500.
>  - Untested yet.
>  - There are still few instances where the correct tbu device has
>to be referenced and thus powered on to handle TLB maintenance
>operations.
> 
>  .../devicetree/bindings/iommu/arm,smmu.txt |  27 +++
>  drivers/iommu/arm-smmu.c   | 191 
> +++--
>  2 files changed, 205 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index d97a6bc8e608..7cf67e75022e 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -98,6 +98,18 @@ conditions.
>accessed before master gets enabled and linked to its
>SMMU.
>  
> +- child nodes:ARM MMU-500 implements a TBU (page table cache or TLB) for
> +  each connected master besides a single TCU that controls
> +  and manages the address translations.
> +  Each of the child nodes represents a TBU that is attached 
> to
> +  the master. This child node will have following property:
> +
> +  - compatibe:   must be "arm,mmu-500-tbu" for TBU child nodes of 
> arm,mmu-500
> + smmu.
> +  - stream-id-range: array representing the starting stream id and the number
> + of supported stream-ids. This gives information about
> + the range of stream-ids that are supported by this TBU.

Needs a vendor prefix.

Also need to document reg property. What does reg represent? If just an 
index with no correlation to h/w numbering, then perhaps stream ids 
could be put into reg instead.

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

Re: [PATCH v2 1/8] dt-bindings: mediatek: Add binding for mt2712 IOMMU and SMI

[Rob Herring]

On Mon, Aug 21, 2017 at 07:00:14PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt2712 IOMMU and SMI.
> 
> In order to balance the bandwidth, mt2712 has two M4Us, two
> smi-commons, 10 smi-larbs. and mt2712 is also MTK IOMMU gen2 which
> uses ARM Short-Descriptor translation table format.
> 
> The mt2712 M4U-SMI HW diagram is as below:
> 
> EMI
>  |
>   
>   |  |
>  M4U0  M4U1
>   |  |
>  smi-common0smi-common1
>   |  |
>   -   
>   | | | | |   | || | |
>   | | | | |   | || | |
> larb0 larb1 larb2 larb3 larb6larb4larb5larb7 larb8 larb9
> disp0 vdec  cam   venc   jpg  mdp1/disp1 mdp2/disp2 mdp3 vdo/nr tvd
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> Signed-off-by: Yong Wu <yong...@mediatek.com>
> ---
> Hi Rob,
> Comparing with the v1, I add larb8 and larb9 in this version.
> So I don't add your ACK here.

Thanks for the explanation. That's minor enough you could have kept it.

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   |   6 +-
>  .../memory-controllers/mediatek,smi-common.txt |   6 +-
>  .../memory-controllers/mediatek,smi-larb.txt   |   5 +-
>  include/dt-bindings/memory/mt2712-larb-port.h  | 102 
> +
>  4 files changed, 113 insertions(+), 6 deletions(-)
>  create mode 100644 include/dt-bindings/memory/mt2712-larb-port.h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/8] dt-bindings: mediatek: Add binding for mt2712 IOMMU and SMI

[Rob Herring]

On Fri, Aug 11, 2017 at 05:56:10PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt2712 IOMMU and SMI.
> 
> In order to balance the bandwidth, mt2712 has two M4Us, two
> smi-commons, 8 smi-larbs. and mt2712 is also MTK IOMMU gen2 which
> use Short-Descriptor translation table format.

s/use/uses/

> 
> The mt2712 M4U-SMI HW diagram is as below:
> 
> EMI
>  |
>   ---
>   | |
>  M4U0  M4U1
>   | |
>  smi-common0   smi-common1
>   | |
>   -   
>   | | | | |   | ||
>   | | | | |   | ||
> larb0 larb1 larb2 larb3 larb6larb4larb5 larb7
> disp0 vdec  cam   venc   jpg  mdp1/disp1 mdp2/disp2  mdp3->larb names
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> Signed-off-by: Yong Wu <yong...@mediatek.com>
> ---
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   |  6 +-
>  .../memory-controllers/mediatek,smi-common.txt |  6 +-
>  .../memory-controllers/mediatek,smi-larb.txt   |  5 +-
>  include/dt-bindings/memory/mt2712-larb-port.h  | 91 
> ++
>  4 files changed, 102 insertions(+), 6 deletions(-)
>  create mode 100644 include/dt-bindings/memory/mt2712-larb-port.h

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

[PATCH] iommu: Convert to using %pOF instead of full_name

[Rob Herring]

Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.

Signed-off-by: Rob Herring <r...@kernel.org>
Cc: Joerg Roedel <j...@8bytes.org>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: iommu@lists.linux-foundation.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
---
 drivers/iommu/fsl_pamu.c| 20 
 drivers/iommu/fsl_pamu_domain.c | 10 --
 drivers/iommu/of_iommu.c|  3 +--
 drivers/iommu/rockchip-iommu.c  | 10 +-
 4 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355fca37a..919ad9045ac4 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -530,8 +530,8 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
if (node) {
prop = of_get_property(node, "cache-stash-id", NULL);
if (!prop) {
-   pr_debug("missing cache-stash-id at %s\n",
-node->full_name);
+   pr_debug("missing cache-stash-id at %pOF\n",
+node);
of_node_put(node);
return ~(u32)0;
}
@@ -557,8 +557,8 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
if (stash_dest_hint == cache_level) {
prop = of_get_property(node, "cache-stash-id", NULL);
if (!prop) {
-   pr_debug("missing cache-stash-id at %s\n",
-node->full_name);
+   pr_debug("missing cache-stash-id at %pOF\n",
+node);
of_node_put(node);
return ~(u32)0;
}
@@ -568,8 +568,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)

prop = of_get_property(node, "next-level-cache", NULL);
if (!prop) {
-   pr_debug("can't find next-level-cache at %s\n",
-node->full_name);
+   pr_debug("can't find next-level-cache at %pOF\n", node);
of_node_put(node);
return ~(u32)0;  /* can't traverse any further */
}
@@ -1063,8 +1062,7 @@ static int fsl_pamu_probe(struct platform_device *pdev)

guts_node = of_find_matching_node(NULL, guts_device_ids);
if (!guts_node) {
-   dev_err(dev, "could not find GUTS node %s\n",
-   dev->of_node->full_name);
+   dev_err(dev, "could not find GUTS node %pOF\n", dev->of_node);
ret = -ENODEV;
goto error;
}
@@ -1246,8 +1244,7 @@ static __init int fsl_pamu_init(void)

pdev = platform_device_alloc("fsl-of-pamu", 0);
if (!pdev) {
-   pr_err("could not allocate device %s\n",
-  np->full_name);
+   pr_err("could not allocate device %pOF\n", np);
ret = -ENOMEM;
goto error_device_alloc;
}
@@ -1259,8 +1256,7 @@ static __init int fsl_pamu_init(void)

ret = platform_device_add(pdev);
if (ret) {
-   pr_err("could not add device %s (err=%i)\n",
-  np->full_name, ret);
+   pr_err("could not add device %pOF (err=%i)\n", np, ret);
goto error_device_add;
}

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index da0e1e30ef37..01c73479345d 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -619,8 +619,8 @@ static int handle_attach_device(struct fsl_dma_domain 
*dma_domain,
for (i = 0; i < num; i++) {
/* Ensure that LIODN value is valid */
if (liodn[i] >= PAACE_NUMBER_ENTRIES) {
-   pr_debug("Invalid liodn %d, attach device failed for 
%s\n",
-liodn[i], dev->of_node->full_name);
+   pr_debug("Invalid liodn %d, attach device failed for 
%pOF\n",
+liodn[i], dev->of_node);
ret = -EINVAL;
break;
}
@@ -684,8 +684,7 @@ static int fsl_pamu_attach_device(struct iommu_domain 
*domain,
liodn_cnt = len / sizeof(u32);
ret = handle_attach_device(dma_domain, dev, liodn, liodn_cnt);
   

Re: [PATCH V4 6/6] iommu/arm-smmu: Add support for qcom,msm8996-smmu-v2 clocks

[Rob Herring]

On Thu, Jul 06, 2017 at 03:07:05PM +0530, Vivek Gautam wrote:
> qcom,msm8996-smmu-v2 is an arm,smmu-v2 implementation with
> specific clock and power requirements. This smmu core is used
> with multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
> 
> Signed-off-by: Vivek Gautam 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 18 ++
>  drivers/iommu/arm-smmu.c | 13 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 00331752d355..5d8e79775fae 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -17,6 +17,7 @@ conditions.
>  "arm,mmu-401"
>  "arm,mmu-500"
>  "cavium,smmu-v2"
> +"qcom,msm8996-smmu-v2"
>  
>depending on the particular implementation and/or the
>version of the architecture implemented.
> @@ -74,11 +75,16 @@ conditions.
>  - clock-names:Should be "tcu" and "iface" for "arm,mmu-400",
>"arm,mmu-401" and "arm,mmu-500"
>  
> +  Should be "bus", and "iface" for "qcom,msm8996-smmu-v2"
> +  implementation.
> +
>"tcu" clock is required for smmu's register access using 
> the
>programming interface and ptw for downstream bus access. 
> This
>clock is also used for access to the TBU connected to the
>master locally. Sometimes however, TBU is clocked along 
> with
>the master.
> +  "bus" clock for "qcom,msm8996-smmu-v2" is requierd for 
> downstream

s/requierd/required/

> +  bus access and for the smmu ptw.
>  
>"iface" clock is required to access the TCU's programming
>interface, apart from the "tcu" clock.
> @@ -161,3 +167,15 @@ conditions.
>  iommu-map = <0  0 0x400>;
>  ...
>  };
> +
> + /* Qcom's arm,smmu-v2 implementation for msm8996 */
> + smmu4: iommu {
> + compatible = "qcom,msm8996-smmu-v2";

No registers?

> + ...
> + #iommu-cells = <1>;
> + power-domains = < MDSS_GDSC>;
> +
> + clocks = < SMMU_MDP_AXI_CLK>,
> +  < SMMU_MDP_AHB_CLK>;
> + clock-names = "bus", "iface";
> + };
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH V4 5/6] iommu/arm-smmu: Add support for MMU40x/500 clocks

[Rob Herring]

On Thu, Jul 06, 2017 at 03:07:04PM +0530, Vivek Gautam wrote:
> From: Sricharan R 
> 
> The MMU400x/500 is the implementation of the SMMUv2
> arch specification. It is split in to two blocks
> TBU, TCU. TBU caches the page table, instantiated
> for each master locally, clocked by the TBUn_clk.
> TCU manages the address translation with PTW and has
> the programming interface as well, clocked using the
> TCU_CLK. The TBU can also be sharing the same clock
> domain as TCU, in which case both are clocked using
> the TCU_CLK.

No TBU clock below. When is it shared or not? If that's an integration 
option then the binding should always have a TBU clock with the same 
parent as the TCU_CLK.

> This defines the clock bindings for the same and adds
> the clock names to compatible data.
> 
> Signed-off-by: Sricharan R 
> [vivek: clock rework and cleanup]
> Signed-off-by: Vivek Gautam 
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 24 
> ++
>  drivers/iommu/arm-smmu.c   | 12 ++-
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 8a6ffce12af5..00331752d355 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -71,6 +71,26 @@ conditions.
>or using stream matching with #iommu-cells = <2>, and
>may be ignored if present in such cases.
>  
> +- clock-names:Should be "tcu" and "iface" for "arm,mmu-400",
> +  "arm,mmu-401" and "arm,mmu-500"
> +
> +  "tcu" clock is required for smmu's register access using 
> the
> +  programming interface and ptw for downstream bus access. 
> This
> +  clock is also used for access to the TBU connected to the
> +  master locally. Sometimes however, TBU is clocked along 
> with
> +  the master.
> +
> +  "iface" clock is required to access the TCU's programming
> +  interface, apart from the "tcu" clock.
> +
> +- clocks: Phandles for respective clocks described by clock-names.
> +
> +- power-domains:  Phandles to SMMU's power domain specifier. This is
> +  required even if SMMU belongs to the master's power
> +  domain, as the SMMU will have to be enabled and
> +  accessed before master gets enabled and linked to its
> +  SMMU.
> +
>  ** Deprecated properties:
>  
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> @@ -95,6 +115,10 @@ conditions.
>   <0 36 4>,
>   <0 37 4>;
>  #iommu-cells = <1>;
> +clocks = < GCC_SMMU_CFG_CLK>,
> + < GCC_APSS_TCU_CLK>;
> +
> + clock-names = "iface", "tcu";
>  };
>  
>  /* device with two stream IDs, 0 and 7 */
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 75567d9698ab..7bb09280fa11 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1947,9 +1947,19 @@ struct arm_smmu_match_data {
>  ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
>  ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
>  ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU);
> -ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
>  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
>  
> +static const char * const arm_mmu500_clks[] = {
> + "tcu", "iface",
> +};
> +
> +static const struct arm_smmu_match_data arm_mmu500 = {
> + .version = ARM_SMMU_V2,
> + .model = ARM_MMU500,
> + .clks = arm_mmu500_clks,
> + .num_clks = ARRAY_SIZE(arm_mmu500_clks),
> +};
> +
>  static const struct of_device_id arm_smmu_of_match[] = {
>   { .compatible = "arm,smmu-v1", .data = _generic_v1 },
>   { .compatible = "arm,smmu-v2", .data = _generic_v2 },
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes

[Rob Herring]

On Thu, Jun 01, 2017 at 01:28:01PM +0100, Jean-Philippe Brucker wrote:
> On 31/05/17 18:23, Rob Herring wrote:
> > On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote:
> >> Address Translation Service (ATS) is an extension to PCIe allowing
> >> endpoints to manage their own IOTLB, called Address Translation Cache
> >> (ATC). Instead of having every memory transaction processed by the IOMMU,
> >> the endpoint can first send an Address Translation Requests for an IOVA,
> >> obtain the corresponding Physical Address from the IOMMU and store it in
> >> its ATC. Subsequent transactions to this memory region can be performed on
> >> the PA, in which case they are marked 'translated' and (partially) bypass
> >> the IOMMU.
> >>
> >> Since the extension uses fields that were previously reserved in the
> >> PCIe Translation Layer Packet, it seems ill-advised to enabled it on a
> >> system that doesn't fully support ATS.
> >>
> >> To "old" root complexes that simply ignored the new AT field, an Address
> >> Translation Request will look exactly like a Memory Read Request, so the
> >> root bridge will forward a memory read to the IOMMU instead of a
> >> translation request. If the access succeeds, the RC will send a Read
> >> Completion, which looks like a Translation Completion, back to the
> >> endpoint. As a result the endpoint might end up storing the content of
> >> memory instead of a physical address in its ATC. In reality, it's more
> >> likely that the size fields will be invalid and either end will detect the
> >> error, but in any case, it is undesirable.
> >>
> >> Add a way for firmware to tell the OS that ATS is supported by the PCI
> >> root complex.
> > 
> > Can't firmware have already enabled ATS? Often for things like this, not 
> > present means "use firmware setting".
> 
> I don't think it's up to firmware to enable ATS in endpoints, because it
> depends on IOMMU properties (e.g. configured page size). It must also be
> enabled after the PASID capability, which the OS may or may not want to
> enable.
> 
> While endpoints have ATS capability and config register, there is no
> architected mechanism in root complexes as far as I know. So firmware may
> have a mechanism outside the OS scope to toggle ATS in the root complex.
> If there is a bug and firmware cannot enable ATS, then the OS must be made
> aware of it, so that it doesn't enable ATS in endpoints, or else we might
> end up with silent memory corruption as described above. (Lack of ATS may
> slow the system down but shouldn't be fatal.)
> 
> If the SMMU supports ATS, then the root complex attached to it will most
> likely supports ATS. The switch in this patch simply allows firmware to
> confirm that.
> 
> >> Signed-off-by: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>
> >> ---
> >>  Documentation/devicetree/bindings/pci/pci-iommu.txt | 8 
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt 
> >> b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> >> index 0def586fdcdf..f21a68ec471a 100644
> >> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> >> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> >> @@ -44,6 +44,14 @@ Optional properties
> >>  - iommu-map-mask: A mask to be applied to each Requester ID prior to being
> >>mapped to an IOMMU specifier per the iommu-map property.
> >>  
> >> +- ats-supported: if present, the root complex supports the Address
> >> +  Translation Service (ATS). It is able to interpret the AT field in PCIe
> >> +  Transaction Layer Packets, and forward Translation Completions or
> >> +  Invalidation Requests to endpoints.
> > 
> > Why can't this be based on the compatible strings?
> 
> Host controllers like the generic ECAM one should be able to advertise
> ATS, if for instance the virtual IOMMU in Qemu offers a channel for ATS
> invalidation. In that case we would have pci-host-{e,}cam-generic{-ats,}
> compatible strings and double the number of compatible strings each time
> we add a similar capability.

It would not double the compatibles. A given SoC will either support ATS 
or not, right? A given compatible will imply whether ATS is supported or 
not.

pci-host-{e,}cam-generic is a special case. I'm okay with having a 
property for that I suppose. We should not require this property though 
and allow for it to be implied by the SoC specific compatible as well.

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

Re: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes

[Rob Herring]

On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote:
> Address Translation Service (ATS) is an extension to PCIe allowing
> endpoints to manage their own IOTLB, called Address Translation Cache
> (ATC). Instead of having every memory transaction processed by the IOMMU,
> the endpoint can first send an Address Translation Requests for an IOVA,
> obtain the corresponding Physical Address from the IOMMU and store it in
> its ATC. Subsequent transactions to this memory region can be performed on
> the PA, in which case they are marked 'translated' and (partially) bypass
> the IOMMU.
> 
> Since the extension uses fields that were previously reserved in the
> PCIe Translation Layer Packet, it seems ill-advised to enabled it on a
> system that doesn't fully support ATS.
> 
> To "old" root complexes that simply ignored the new AT field, an Address
> Translation Request will look exactly like a Memory Read Request, so the
> root bridge will forward a memory read to the IOMMU instead of a
> translation request. If the access succeeds, the RC will send a Read
> Completion, which looks like a Translation Completion, back to the
> endpoint. As a result the endpoint might end up storing the content of
> memory instead of a physical address in its ATC. In reality, it's more
> likely that the size fields will be invalid and either end will detect the
> error, but in any case, it is undesirable.
> 
> Add a way for firmware to tell the OS that ATS is supported by the PCI
> root complex.

Can't firmware have already enabled ATS? Often for things like this, not 
present means "use firmware setting".

> 
> Signed-off-by: Jean-Philippe Brucker 
> ---
>  Documentation/devicetree/bindings/pci/pci-iommu.txt | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt 
> b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 0def586fdcdf..f21a68ec471a 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -44,6 +44,14 @@ Optional properties
>  - iommu-map-mask: A mask to be applied to each Requester ID prior to being
>mapped to an IOMMU specifier per the iommu-map property.
>  
> +- ats-supported: if present, the root complex supports the Address
> +  Translation Service (ATS). It is able to interpret the AT field in PCIe
> +  Transaction Layer Packets, and forward Translation Completions or
> +  Invalidation Requests to endpoints.

Why can't this be based on the compatible strings?

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

Re: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes

[Rob Herring]

On Tue, May 30, 2017 at 11:58:50AM +0100, Jean-Philippe Brucker wrote:
> On 30/05/17 11:01, Joerg Roedel wrote:
> > On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote:
> >> +- ats-supported: if present, the root complex supports the Address
> >> +  Translation Service (ATS). It is able to interpret the AT field in PCIe
> >> +  Transaction Layer Packets, and forward Translation Completions or
> >> +  Invalidation Requests to endpoints.
> >> +
> >> +  Device drivers should not enable ATS in endpoints unless this property
> >> +  is present.
> > 
> > Device drivers should never enable ATS, this is the job of the IOMMU
> > driver. This should be clarified in the text.
> 
> Right, I will change this.

Driver details should not be in DT to begin with.

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

Re: [v6 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

[Rob Herring]

DT changes should go to DT list.

On Fri, May 12, 2017 at 7:41 AM, Geetha sowjanya
 wrote:
> From: Linu Cherian 
>
> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
> and PAGE0_REGS_ONLY option is enabled as an errata workaround.
> This option when turned on, replaces all page 1 offsets used for
> EVTQ_PROD/CONS, PRIQ_PROD/CONS register access with page 0 offsets.
>
> SMMU resource size checks are now based on SMMU option PAGE0_REGS_ONLY,
> since resource size can be either 64k/128k.
> For this, arm_smmu_device_dt_probe/acpi_probe has been moved before
> platform_get_resource call, so that SMMU options are set beforehand.
>
> Signed-off-by: Linu Cherian 
> Signed-off-by: Geetha Sowjanya 
> ---
>  Documentation/arm64/silicon-errata.txt |  1 +
>  .../devicetree/bindings/iommu/arm,smmu-v3.txt  |  6 ++
>  drivers/iommu/arm-smmu-v3.c| 64 
> +-
>  3 files changed, 56 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt 
> b/Documentation/arm64/silicon-errata.txt
> index 10f2ddd..4693a32 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -62,6 +62,7 @@ stable kernels.
>  | Cavium | ThunderX GICv3  | #23154  | CAVIUM_ERRATUM_23154  
>   |
>  | Cavium | ThunderX Core   | #27456  | CAVIUM_ERRATUM_27456  
>   |
>  | Cavium | ThunderX SMMUv2 | #27704  | N/A   
>   |
> +| Cavium | ThunderX2 SMMUv3| #74 | N/A   
>   |
>  || | |   
>   |
>  | Freescale/NXP  | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585   
>   |
>  || | |   
>   |
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> index be57550..e6da62b 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> @@ -49,6 +49,12 @@ the PCIe specification.
>  - hisilicon,broken-prefetch-cmd
>  : Avoid sending CMD_PREFETCH_* commands to the SMMU.
>
> +- cavium-cn99xx,broken-page1-regspace

"cavium-cn99xx" is not a vendor.

I'm sure you have an SoC specific compatible string, so use that to
enable any errata work-arounds.

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

Re: [RFC v1 3/7] iommu/arm-smmu-v3: Replace the device tree binding for hisilicon broken prefetch cmd with erratum id

[Rob Herring]

On Sat, May 13, 2017 at 4:47 AM, shameer
 wrote:
> Signed-off-by: shameer 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> index be57550..bf48e92 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> @@ -46,7 +46,7 @@ the PCIe specification.
>  devicetree/bindings/interrupt-controller/msi.txt
>for a description of the msi-parent property.
>
> -- hisilicon,broken-prefetch-cmd
> +- hisilicon,erratum-161010701

Why? Your missing commit msg should answer that. This breaks
compatibility, so you are stuck with the old string.

I'd prefer that you start using the compatible string rather than
every vendor adding a property for every errata.

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

Re: [PATCH 3/4] iommu: add qcom_iommu

[Rob Herring]

On Thu, May 4, 2017 at 8:34 AM, Rob Clark  wrote:
> An iommu driver for Qualcomm "B" family devices which do not completely
> implement the ARM SMMU spec.  These devices have context-bank register
> layout that is similar to ARM SMMU, but no global register space (or at
> least not one that is accessible).
>
> Signed-off-by: Rob Clark 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/iommu/Kconfig  |  10 +
>  drivers/iommu/Makefile |   1 +
>  drivers/iommu/qcom_iommu.c | 825 
> +
>  3 files changed, 836 insertions(+)
>  create mode 100644 drivers/iommu/qcom_iommu.c
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 37e204f..400a404 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -359,4 +359,14 @@ config MTK_IOMMU_V1
>
>   if unsure, say N here.
>
> +config QCOM_IOMMU
> +   bool "Qualcomm IOMMU Support"
> +   depends on ARM || ARM64

This is redundant as you have ARCH_QCOM

> +   depends on ARCH_QCOM || COMPILE_TEST
> +   select IOMMU_API
> +   select IOMMU_IO_PGTABLE_LPAE
> +   select ARM_DMA_USE_IOMMU
> +   help
> + Support for IOMMU on certain Qualcomm SoCs.
> +
>  endif # IOMMU_SUPPORT
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 195f7b9..b910aea 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -27,3 +27,4 @@ obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
>  obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
>  obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
>  obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
> +obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> new file mode 100644
> index 000..1cf7c8e
> --- /dev/null
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -0,0 +1,825 @@
> +/*
> + * IOMMU API for QCOM secure IOMMUs.  Somewhat based on arm-smmu.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Don't put FSF address in.

> + *
> + * Copyright (C) 2013 ARM Limited
> + * Copyright (C) 2017 Red Hat
> + */
> +
> +#define pr_fmt(fmt) "qcom-iommu: " fmt

Unused as dev_* prints are used?

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

This driver is boolean and not a module.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "io-pgtable.h"
> +#include "arm-smmu-regs.h"
> +
> +#define SMMU_INTR_SEL_NS 0x2000
> +
> +struct qcom_iommu_dev {
> +   /* IOMMU core code handle */
> +   struct iommu_device  iommu;
> +   struct device   *dev;
> +   struct clk  *iface_clk;
> +   struct clk  *bus_clk;
> +   void __iomem*local_base;
> +   u32  sec_id;
> +   struct list_head context_list;   /* list of 
> qcom_iommu_context */
> +};
> +
> +struct qcom_iommu_ctx {
> +   struct device   *dev;
> +   void __iomem*base;
> +   unsigned int irq;
> +   bool secure_init;
> +   u32  asid;  /* asid and ctx bank # are 1:1 */
> +   struct iommu_group  *group;
> +   struct list_head node;  /* head in 
> qcom_iommu_device::context_list */
> +};
> +
> +struct qcom_iommu_domain {
> +   struct io_pgtable_ops   *pgtbl_ops;
> +   spinlock_t   pgtbl_lock;
> +   struct mutex init_mutex; /* Protects iommu pointer */
> +   struct iommu_domain  domain;
> +   struct qcom_iommu_dev   *iommu;
> +};
> +
> +static struct qcom_iommu_domain *to_qcom_iommu_domain(struct iommu_domain 
> *dom)
> +{
> +   return container_of(dom, struct qcom_iommu_domain, domain);
> +}
> +
> +static const struct iommu_ops qcom_iommu_ops;
> +
> +static struct qcom_iommu_dev * __to_iommu(struct iommu_fwspec *fwspec)
> +{
> +   if (!fwspec || fwspec->ops != _iommu_ops)
> +   return NULL;
> +   return fwspec->iommu_priv;
> +}
> +
> +static struct qcom_iommu_dev * to_iommu(struct iommu_fwspec *fwspec)
> +{
> +   struct 

Re: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

[Rob Herring]

On Tue, May 2, 2017 at 11:46 PM, Oza Pawandeep  wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take care of memory
> mapped devices. but no implementation exists for pci to take
> care of pcie based memory ranges.
>
> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
> world dma-ranges.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>
> this patch fixes this patch fixes the bug in of_dma_get_range,
> which with as is, parses the PCI memory ranges and return wrong
> size as 0.
>
> in order to get largest possible dma_mask. this patch also
> retuns the largest possible size based on dma-ranges,
>
> for e.g.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
> we should get dev->coherent_dma_mask=0x7f.
>
> based on which iova allocation space will honour PCI host
> bridge limitations.
>
> Bug: SOC-5216
> Change-Id: I4c534bdd17e70c6b27327d39d1656e8ed0cf56d6
> Signed-off-by: Oza Pawandeep 
> Reviewed-on: http://gerrit-ccxsw.broadcom.net/40762
> Reviewed-by: vpx_checkpatch status 
> Reviewed-by: CCXSW 
> Reviewed-by: Scott Branden 
> Tested-by: vpx_autobuild status 
> Tested-by: vpx_smoketest status 
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..f7734fc 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -830,6 +831,54 @@ int of_dma_get_range(struct device_node *np, u64 
> *dma_addr, u64 *paddr, u64 *siz
> int ret = 0;
> u64 dmaaddr;
>
> +#ifdef CONFIG_PCI
> +   struct resource_entry *window;
> +   LIST_HEAD(res);
> +
> +   if (!node)
> +   return -EINVAL;
> +
> +   if (of_bus_pci_match(np)) {

You are not following what I'm saying. Let me spell it out:

- Add a get_dma_ranges() function to of_bus struct. Or maybe should
cover ranges too (e.g. get_ranges). I'm not sure.
- Convert existing contents of this function to
of_bus_default_dma_get_ranges and add that to the default of_bus
struct.
- Make of_dma_get_range call of_bus_match() and then bus->get_dma_ranges.

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

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Rob Herring]

On Tue, May 2, 2017 at 11:46 PM, Oza Pawandeep  wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take care of memory
> mapped devices. but no implementation exists for pci to take
> care of pcie based memory ranges.
>
> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
> world dma-ranges.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>
> this patch serves following:
>
> 1) exposes interface to the pci host driver for their
> inbound memory ranges
>
> 2) provide an interface to callers such as of_dma_get_ranges.
> so then the returned size get best possible (largest) dma_mask.
> because PCI RC drivers do not call APIs such as
> dma_set_coherent_mask() and hence rather it shows its addressing
> capabilities based on dma-ranges.
> for e.g.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
> we should get dev->coherent_dma_mask=0x7f.
>
> 3) this patch handles multiple inbound windows and dma-ranges.
> it is left to the caller, how it wants to use them.
> the new function returns the resources in a standard and unform way
>
> 4) this way the callers of for e.g. of_dma_get_ranges
> does not need to change.
>
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.
>
> Bug: SOC-5216
> Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
> Signed-off-by: Oza Pawandeep 
> Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
> Reviewed-by: vpx_checkpatch status 
> Reviewed-by: CCXSW 
> Reviewed-by: Ray Jui 
> Tested-by: vpx_autobuild status 
> Tested-by: vpx_smoketest status 
> Tested-by: CCXSW 

All these non-person, probably internal Broadcom Tested-by and
Reviewed-by's should be removed too.

> Reviewed-by: Scott Branden 
>

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

Re: [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters

[Rob Herring]

On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep  wrote:
> current device frmework and of framework integration assumes dma-ranges
> in a way where memory-mapped devices define their dma-ranges.
> dma-ranges: (child-bus-address, parent-bus-address, length).
>
> but iproc based SOCs and other SOCs(suc as rcar) have PCI world dma-ranges.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>
> of_dma_configure is specifically witten to take care of memory mapped devices.
> but no implementation exists for pci to take care of pcie based memory ranges.
> in fact pci world doesnt seem to define standard dma-ranges
>
> this patch served following purposes
>
> 1) exposes intrface to the pci host driver for thir inbound memory ranges
>
> 2) provide an interface to callers such as of_dma_get_ranges.
> so then the returned size get best possible (largest) dma_mask.
> for e.g.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
> we should get dev->coherent_dma_mask=0x7f.
>
> 3) this patch handles multiple inbound windows and dma-ranges.
> it is left to the caller, how it wants to use them.
> the new function returns the resources in a standard and unform way
>
> 4) this way the callers of of_dma_get_ranges does not need to change.
> and
>
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.
>
> Signed-off-by: Oza Pawandeep 
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..ec21191 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -829,10 +830,30 @@ int of_dma_get_range(struct device_node *np, u64 
> *dma_addr, u64 *paddr, u64 *siz
> int len, naddr, nsize, pna;
> int ret = 0;
> u64 dmaaddr;
> +   struct resource_entry *window;
> +   LIST_HEAD(res);
>
> if (!node)
> return -EINVAL;
>
> +   if (strcmp(np->name, "pci")) {

Using the name is not reliable though I did recently add a dtc check
for this. Of course, 'pcie' is valid too (and probably should be used
for what you are testing). type is what you want to use here. We
already have bus matching function and bus specific handlers in
address.c. Whatever solution you come up with should be integrated
with the existing bus specific handlers.

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

Re: [PATCH V10 00/12] IOMMU probe deferral support

[Rob Herring]

On Tue, Apr 4, 2017 at 5:18 AM, Sricharan R <sricha...@codeaurora.org> wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.

For patches 3, 4, 6, 7, 8:

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

Re: [V9, 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Rob Herring]

On Fri, Mar 10, 2017 at 12:30:57AM +0530, Sricharan R wrote:
> From: Laurent Pinchart 
> 
> Failures to look up an IOMMU when parsing the DT iommus property need to
> be handled separately from the .of_xlate() failures to support deferred
> probing.
> 
> The lack of a registered IOMMU can be caused by the lack of a driver for
> the IOMMU, the IOMMU device probe not having been performed yet, having
> been deferred, or having failed.
> 
> The first case occurs when the device tree describes the bus master and
> IOMMU topology correctly but no device driver exists for the IOMMU yet
> or the device driver has not been compiled in. Return NULL, the caller
> will configure the device without an IOMMU.
> 
> The second and third cases are handled by deferring the probe of the bus
> master device which will eventually get reprobed after the IOMMU.
> 
> The last case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
> 
> Tested-by: Marek Szyprowski 
> Signed-off-by: Laurent Pichart 
> Signed-off-by: Sricharan R 
> ---
>  drivers/base/dma-mapping.c | 5 +++--
>  drivers/iommu/of_iommu.c   | 4 ++--
>  drivers/of/device.c| 7 ++-
>  include/linux/of_device.h  | 9 ++---
>  4 files changed, 17 insertions(+), 8 deletions(-)

Maybe it is the same issue reported for VFIO, but virtio-pci is broken 
with v8 of this series. Bisecting blames this commit which looks like it 
hasn't changeed. 

Rob

P.S. Doesn't look like you have copied the DT maintainers nor list for 
the DT changes.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask

[Rob Herring]

On Tue, Mar 28, 2017 at 12:27 AM, Oza Oza <oza@broadcom.com> wrote:
> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring <r...@kernel.org> wrote:
>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep <oza@broadcom.com> wrote:
>>> it is possible that PCI device supports 64-bit DMA addressing,
>>> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
>>> however PCI host bridge may have limitations on the inbound
>>> transaction addressing. As an example, consider NVME SSD device
>>> connected to iproc-PCIe controller.
>>>
>>> Currently, the IOMMU DMA ops only considers PCI device dma_mask
>>> when allocating an IOVA. This is particularly problematic on
>>> ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to
>>> PA for in-bound transactions only after PCI Host has forwarded
>>> these transactions on SOC IO bus. This means on such ARM/ARM64
>>> SOCs the IOVA of in-bound transactions has to honor the addressing
>>> restrictions of the PCI Host.
>>>
>>> current pcie frmework and of framework integration assumes dma-ranges
>>> in a way where memory-mapped devices define their dma-ranges.
>>> dma-ranges: (child-bus-address, parent-bus-address, length).
>>>
>>> but iproc based SOCs and even Rcar based SOCs has PCI world dma-ranges.
>>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>>
>> If you implement a common function, then I expect to see other users
>> converted to use it. There's also PCI hosts in arch/powerpc that parse
>> dma-ranges.
>
> the common function should be similar to what
> of_pci_get_host_bridge_resources is doing right now.
> it parses ranges property right now.
>
> the new function would look look following.
>
> of_pci_get_dma_ranges(struct device_node *dev, struct list_head *resources)
> where resources would return the dma-ranges.
>
> but right now if you see the patch, of_dma_configure calls the new
> function, which actually returns the largest possible size.
> so this new function has to be generic in a way where other PCI hosts
> can use it. but certainly iproc(Broadcom SOC) , rcar based SOCs can
> use it for sure.
>
> although having powerpc using it;  is a separate exercise, since I do
> not have any access to other PCI hosts such as powerpc. but we can
> workout with them on thsi forum if required.

You don't need h/w. You can analyze what parts are common, write
patches to convert to common implementation, and build test. The PPC
and rcar folks can test on h/w.

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

Re: [PATCH 3/9] Docs: dt: document qcom iommu bindings

[Rob Herring]

On Thu, Mar 23, 2017 at 9:45 PM, Rob Clark <robdcl...@gmail.com> wrote:
> On Thu, Mar 23, 2017 at 6:21 PM, Rob Herring <r...@kernel.org> wrote:
>> On Tue, Mar 14, 2017 at 11:18:05AM -0400, Rob Clark wrote:
>>> Cc: devicet...@vger.kernel.org
>>> Signed-off-by: Rob Clark <robdcl...@gmail.com>
>>> ---
>>>  .../devicetree/bindings/iommu/qcom,iommu.txt   | 113 
>>> +
>>>  1 file changed, 113 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt 
>>> b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>> new file mode 100644
>>> index 000..fd5b7fa
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>> @@ -0,0 +1,113 @@
>>> +* QCOM IOMMU v1 Implementation
>>> +
>>> +Qualcomm "B" family devices which are not compatible with arm-smmu have
>>> +a similar looking IOMMU but without access to the global register space,
>>> +and optionally requiring additional configuration to route context irqs
>>> +to non-secure vs secure interrupt line.
>>> +
>>> +** Required properties:
>>> +
>>> +- compatible   : Should be one of:
>>> +
>>> +"qcom,msm8916-iommu"
>>> +
>>> +- clock-names  : Should be a pair of "iface" (required for IOMMUs
>>> + register group access) and "bus" (required for
>>> + the IOMMUs underlying bus access).
>>> +- clocks   : Phandles for respective clocks described by
>>> + clock-names.
>>> +- #address-cells   : must be 1.
>>> +- #size-cells  : must be 1.
>>> +- #iommu-cells : Must be 1.
>>> +- ranges   : Base address and size of the iommu context banks.
>>> +- qcom,iommu-secure-id  : secure-id.
>>> +
>>> +- List of sub-nodes, one per translation context bank.  Each sub-node
>>> +  has the following required properties:
>>> +
>>> +  - compatible : Should be one of:
>>> +- "qcom,msm-iommu-v1-ns"  : non-secure context bank
>>> +- "qcom,msm-iommu-v1-sec" : secure context bank
>>> +  - reg: Base address and size of context bank within the iommu
>>> +  - interrupts : The context fault irq.
>>> +
>>> +** Optional properties:
>>> +
>>> +- reg  : Base address and size of the SMMU local base, should
>>> + be only specified if the iommu requires configuration
>>> + for routing of context bank irq's to secure vs non-
>>> + secure lines.  (Ie. if the iommu contains secure
>>> + context banks)
>>> +
>>> +
>>> +** Examples:
>>> +
>>> + apps_iommu: iommu@1e2 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + #iommu-cells = <1>;
>>> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
>>
>> You didn't document the fallback above. Maybe just drop it if only a few
>> chips have this iommu.
>
> not completely sure I understand what you want..
>
> I think more than a few chips.. I suspect it is more like everything
> after the last "a" family devices (snapdragon 600?) and before 820..
> (well, more or less at least a few years worth of devices, stuff that
> seems likely to be able to run an upstream kernel would be 800, 805,
> 808, 810.. and I guess there are some cut down 6xx and 4xx variants of
> those)

Okay, then you just need to list qcom,msm-iommu-v1 above. Something
like 'followed by "qcom,msm-iommu-v1"' at the end of the list of
compatibles.

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

Re: [RFC PATCH 3/3] of: fix node traversing in of_dma_get_range

[Rob Herring]

On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep  wrote:
> it jumps to the parent node without examining the child node.
> also with that, it throws "no dma-ranges found for node"
> for pci dma-ranges.
>
> this patch fixes device node traversing for dma-ranges.

What's the DT look like that doesn't work?

dma-ranges is supposed to be a bus property, not a device's property.
So looking at the parent is correct behavior generally.

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

Re: [PATCH 3/9] Docs: dt: document qcom iommu bindings

[Rob Herring]

On Tue, Mar 14, 2017 at 11:18:05AM -0400, Rob Clark wrote:
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Clark 
> ---
>  .../devicetree/bindings/iommu/qcom,iommu.txt   | 113 
> +
>  1 file changed, 113 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
> new file mode 100644
> index 000..fd5b7fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
> @@ -0,0 +1,113 @@
> +* QCOM IOMMU v1 Implementation
> +
> +Qualcomm "B" family devices which are not compatible with arm-smmu have
> +a similar looking IOMMU but without access to the global register space,
> +and optionally requiring additional configuration to route context irqs
> +to non-secure vs secure interrupt line.
> +
> +** Required properties:
> +
> +- compatible   : Should be one of:
> +
> +"qcom,msm8916-iommu"
> +
> +- clock-names  : Should be a pair of "iface" (required for IOMMUs
> + register group access) and "bus" (required for
> + the IOMMUs underlying bus access).
> +- clocks   : Phandles for respective clocks described by
> + clock-names.
> +- #address-cells   : must be 1.
> +- #size-cells  : must be 1.
> +- #iommu-cells : Must be 1.
> +- ranges   : Base address and size of the iommu context banks.
> +- qcom,iommu-secure-id  : secure-id.
> +
> +- List of sub-nodes, one per translation context bank.  Each sub-node
> +  has the following required properties:
> +
> +  - compatible : Should be one of:
> +- "qcom,msm-iommu-v1-ns"  : non-secure context bank
> +- "qcom,msm-iommu-v1-sec" : secure context bank
> +  - reg: Base address and size of context bank within the iommu
> +  - interrupts : The context fault irq.
> +
> +** Optional properties:
> +
> +- reg  : Base address and size of the SMMU local base, should
> + be only specified if the iommu requires configuration
> + for routing of context bank irq's to secure vs non-
> + secure lines.  (Ie. if the iommu contains secure
> + context banks)
> +
> +
> +** Examples:
> +
> + apps_iommu: iommu@1e2 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #iommu-cells = <1>;
> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";

You didn't document the fallback above. Maybe just drop it if only a few 
chips have this iommu.

> + ranges = <0 0x1e2 0x4>;
> + reg = <0x1ef 0x3000>;

When you have both reg and ranges, use reg value for the unit-address.

> + clocks = < GCC_SMMU_CFG_CLK>,
> +  < GCC_APSS_TCU_CLK>;
> + clock-names = "iface", "bus";
> + qcom,iommu-secure-id = <17>;
> +
> + // mdp_0:
> + iommu-ctx@4000 {
> + compatible = "qcom,msm-iommu-v1-ns";
> + reg = <0x4000 0x1000>;
> + interrupts = ;
> + };
> +
> + // venus_ns:
> + iommu-ctx@5000 {
> + compatible = "qcom,msm-iommu-v1-sec";
> + reg = <0x5000 0x1000>;
> + interrupts = ;
> + };
> + };
> +
> + gpu_iommu: iommu@1f08000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #iommu-cells = <1>;
> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
> + ranges = <0 0x1f08000 0x1>;
> + clocks = < GCC_SMMU_CFG_CLK>,
> +  < GCC_GFX_TCU_CLK>;
> + clock-names = "iface", "bus";
> + qcom,iommu-secure-id = <18>;
> +
> + // gfx3d_user:
> + iommu-ctx@1f09000 {

iommu-ctx@1000

> + compatible = "qcom,msm-iommu-v1-ns";
> + reg = <0x1000 0x1000>;
> + interrupts = ;
> + };
> +
> + // gfx3d_priv:
> + iommu-ctx@1f0a000 {

iommu-ctx@2000

> + compatible = "qcom,msm-iommu-v1-ns";
> + reg = <0x2000 0x1000>;
> + interrupts = ;
> + };
> + };
> +
> + ...
> +
> + venus: video-codec@1d0 {
> + ...
> + iommus = <_iommu 5>;
> + };
> +
> + mdp: mdp@1a01000 {
> + ...
> + iommus = <_iommu 4>;
> + };
> +
> + gpu@01c0 {
> + ...
> + iommus = <_iommu 1>, <_iommu 2>;
> + };
> -- 
> 2.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org

Re: [PATCH V3 3/5] drivers: arm-smmu: Add clock support for QCOM_SMMUV2

[Rob Herring]

On Thu, Mar 09, 2017 at 09:05:46PM +0530, Sricharan R wrote:
> The QCOM_SMMUV2 is an implementation of the arm,smmu-v2 architecture.
> The qcom,smmu is instantiated for each of the multimedia cores (for eg)
> Venus (video encoder/decoder), mdp (display) etc, and they are connected
> to the Multimedia Aggregator Interconnect (MMAGIC). So the access to
> any of the MMU's registers, as well as MMU's downstream bus access,
> requires the specified MMAGIC clocks to be enabled. So adding a new
> binding for the qcom,smmu-v2 and the required mmagic clock bindings for
> the same. Also adding the support for enabling the qcom,smmu-v2 clocks in
> the driver.
> 
>-  -
>|   VENUS   |  | MDP   |
>  |   |  |   |
>  -  
>|   |
>|   |
>   --  -
>   |SMMU | | SMMU  |
>   |   | |   |
>   --  
>   ||
>   ||
>-
>|  MMAGIC INTERCONNECT (MMSS NOC) |
>|   |
>-
>| |
>  |   --
>  - |  SYSTEM NOC  |
>  |DDR|   ||
>  - -
>  ||
>|   --
>  |<-| CPU|
> --
> 
> Signed-off-by: Sricharan R 
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt |   8 ++
>  drivers/iommu/arm-smmu.c   | 124 
> +
>  2 files changed, 132 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index b369c13..88e02d6 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -17,6 +17,7 @@ conditions.
>  "arm,mmu-401"
>  "arm,mmu-500"
>  "cavium,smmu-v2"
> + "qcom,smmu-v2"

I know Cavium did it, but I'd prefer to see SoC specific compatibles 
here.

>  
>depending on the particular implementation and/or the
>version of the architecture implemented.
> @@ -74,6 +75,13 @@ conditions.
>"cfg_clk" is optional if required to access the TCU's 
> programming
>interface, apart from the "tcu_clk".
>  
> +   Should have "mmagic_ahb_clk", "mmagic_cfg_ahb_clk",
> +  "smmu_core_ahb_clk", "smmu_core_axi_clk",
> +  "mmagic_core_axi_clk" for "qcom,smmu-v2"

This is instead of the above clocks?

Are these clocks all really part of the SMMU or are the mmagic clocks 
working around no proper driver for the mmagic?

> +
> +   "mmagic_core_axi_clk" is required for smmu's access to the
> +   downstream bus and rest for the smmu's register group 
> access.
> +
>  - clocks: Phandles for respective clocks described by clock-names.
>  
>  - power-domains:  Phandles to SMMU's power domain specifier. This is
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH V3 2/5] iommu/arm-smmu: Add support for MMU40x/500 clocks

[Rob Herring]

On Thu, Mar 09, 2017 at 09:05:45PM +0530, Sricharan R wrote:
> The MMU400x/500 is the implementation of the SMMUv2
> arch specification. It is split in to two blocks
> TBU, TCU. TBU caches the page table, instantiated
> for each master locally, clocked by the TBUn_clk.
> TCU manages the address translation with PTW and has
> the programming interface as well, clocked using the
> TCU_CLK. The TBU can also be sharing the same clock
> domain as TCU, in which case both are clocked using
> the TCU_CLK.
> 
> This defines the clock bindings for the same and adds the
> init, enable and disable functions for handling the
> clocks.
> 
> Signed-off-by: Sricharan R 
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 27 ++
>  drivers/iommu/arm-smmu.c   | 95 
> +-
>  2 files changed, 121 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 6cdf32d..b369c13 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -60,6 +60,28 @@ conditions.
>aliases of secure registers have to be used during
>SMMU configuration.
>  
> +- clock-names:Should be "tbu_clk" and "tcu_clk" and "cfg_clk" for

_clk is redundant

> +  "arm,mmu-400", "arm,mmu-401" and "arm,mmu-500"
> +
> +  "tcu_clk" is required for smmu's register access using the
> +  programming interface and ptw for downstream bus access.
> +
> +  "tbu_clk" is required for access to the TBU connected to 
> the
> +  master locally. This clock is optional and not required 
> when
> +  TBU is in the same clock domain as the TCU or when the TBU 
> is
> +  clocked along with the master.
> +
> +  "cfg_clk" is optional if required to access the TCU's 
> programming
> +  interface, apart from the "tcu_clk".

Clocks generally shouldn't be optional. Either the h/w has a clock or it 
doesn't.

> +
> +- clocks: Phandles for respective clocks described by clock-names.
> +
> +- power-domains:  Phandles to SMMU's power domain specifier. This is
> +  required even if SMMU belongs to the master's power
> +  domain, as the SMMU will have to be enabled and
> +  accessed before master gets enabled and linked to its
> +  SMMU.
> +
>  ** Deprecated properties:
>  
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> @@ -84,6 +106,11 @@ conditions.
>   <0 36 4>,
>   <0 37 4>;
>  #iommu-cells = <1>;
> +clocks = < GCC_SMMU_CFG_CLK>,
> + < GCC_APSS_TCU_CLK>,
> +  < GCC_MDP_TBU_CLK>;
> +
> + clock-names = "cfg_clk", "tcu_clk", "tbu_clk";
>  };
>  
>  /* device with two stream IDs, 0 and 7 */
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index f7e11d3..720a1ef 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -341,6 +341,12 @@ struct arm_smmu_master_cfg {
>  #define for_each_cfg_sme(fw, i, idx) \
>   for (i = 0; idx = fwspec_smendx(fw, i), i < fw->num_ids; ++i)
>  
> +struct mmu500_clk {
> + struct clk *cfg_clk;
> + struct clk *tcu_clk;
> + struct clk *tbu_clk;
> +};
> +
>  struct arm_smmu_clks {
>   void *clks;
>   int (*init_clocks)(struct arm_smmu_device *smmu);
> @@ -455,6 +461,92 @@ static struct arm_smmu_domain *to_smmu_domain(struct 
> iommu_domain *dom)
>   return container_of(dom, struct arm_smmu_domain, domain);
>  }
>  
> +static int mmu500_enable_clocks(struct arm_smmu_device *smmu)
> +{
> + int ret = 0;
> + struct mmu500_clk *sclks = smmu->smmu_clks.clks;
> +
> + if (!sclks)
> + return 0;
> +
> + ret = clk_prepare_enable(sclks->cfg_clk);
> + if (ret) {
> + dev_err(smmu->dev, "Couldn't enable cfg_clk");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(sclks->tcu_clk);
> + if (ret) {
> + dev_err(smmu->dev, "Couldn't enable tcu_clk");
> + clk_disable_unprepare(sclks->cfg_clk);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(sclks->tbu_clk);
> + if (ret) {
> + dev_err(smmu->dev, "Couln't enable tbu_clk");
> + clk_disable_unprepare(sclks->tcu_clk);
> + clk_disable_unprepare(sclks->cfg_clk);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void mmu500_disable_clocks(struct arm_smmu_device *smmu)
> +{
> + struct mmu500_clk *sclks = smmu->smmu_clks.clks;
> +
> + if (!sclks) {
> + 

Re: [PATCH 3/9] Docs: dt: document qcom iommu bindings

[Rob Herring]

On Wed, Mar 01, 2017 at 12:42:52PM -0500, Rob Clark wrote:

Nit: use "dt-bindings: iommu: ..." for subject. And a commit message 
would be nice.

> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Clark 
> ---
>  .../devicetree/bindings/iommu/qcom,iommu.txt   | 106 
> +
>  1 file changed, 106 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
> new file mode 100644
> index 000..2e69b78
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
> @@ -0,0 +1,106 @@
> +* QCOM IOMMU v1 Implementation
> +
> +Qualcomm "B" family devices which are not compatible with arm-smmu have
> +a similar looking IOMMU but without access to the global register space,
> +and optionally requiring additional configuration to route context irqs
> +to non-secure vs secure interrupt line.
> +
> +** Required properties:
> +
> +- compatible   : Should be "qcom,msm-iommu-v1".

Fine as a fallback, but this needs chip specific compatibles.

> +- clocks   : The interface clock (iface_clk) and bus clock (bus_clk).

The names need to be documented under clock-names prop.

'_clk' is redundant.

> +- #address-cells   : must be 1.
> +- #size-cells  : must be 1.
> +- #iommu-cells : Must be 1.
> +- ranges   : Base address and size of the iommu context banks.
> +- qcom,iommu-secure-id  : secure-id.
> +
> +- List of sub-nodes, one per translation context bank.  Each sub-node
> +  has the following required properties:
> +
> +  - compatible : Should be one of:
> +- "qcom,msm-iommu-v1-ns"  : non-secure context bank
> +- "qcom,msm-iommu-v1-sec" : secure context bank

These are okay without chip specific strings.

> +  - reg: Base address and size of context bank within the iommu
> +  - interrupts : The context fault irq.
> +
> +** Optional properties:
> +
> +- reg  : Base address and size of the SMMU local base, should
> + be only specified if the iommu requires configuration
> + for routing of context bank irq's to secure vs non-
> + secure lines.  (Ie. if the iommu contains secure
> + context banks)
> +
> +
> +** Examples:
> +
> + apps_iommu: msm-iommu-v1@1e2 {

iommu@...

And this should be the reg address, not the ranges address.

> + #address-cells = <1>;
> + #size-cells = <1>;
> + #iommu-cells = <1>;
> + compatible = "qcom,msm-iommu-v1";
> + ranges = <0 0x1e2 0x4>;
> + reg = <0x1ef 0x3000>;
> + clocks = < GCC_SMMU_CFG_CLK>,
> +  < GCC_APSS_TCU_CLK>;
> + clock-names = "iface_clk", "bus_clk";
> + qcom,iommu-secure-id = <17>;
> +
> + // mdp_0:
> + msm-iommu-v1-ctx@4000 {

iommu@...

> + compatible = "qcom,msm-iommu-v1-ns";
> + reg = <0x4000 0x1000>;
> + interrupts = ;
> + };
> +
> + // venus_ns:
> + msm-iommu-v1-ctx@5000 {
> + compatible = "qcom,msm-iommu-v1-sec";
> + reg = <0x5000 0x1000>;
> + interrupts = ;
> + };
> + };
> +
> + gpu_iommu: msm-iommu-v1@1f08000 {

ditto.

> + #address-cells = <1>;
> + #size-cells = <1>;
> + #iommu-cells = <1>;
> + compatible = "qcom,msm-iommu-v1";
> + ranges = <0 0x1f08000 0x1>;
> + clocks = < GCC_SMMU_CFG_CLK>,
> +  < GCC_GFX_TCU_CLK>;
> + clock-names = "iface_clk", "bus_clk";
> + qcom,iommu-secure-id = <18>;
> +
> + // gfx3d_user:
> + msm-iommu-v1-ctx@1f09000 {
> + compatible = "qcom,msm-iommu-v1-ns";
> + reg = <0x1000 0x1000>;
> + interrupts = ;
> + };
> +
> + // gfx3d_priv:
> + msm-iommu-v1-ctx@1f0a000 {
> + compatible = "qcom,msm-iommu-v1-ns";
> + reg = <0x2000 0x1000>;
> + interrupts = ;
> + };
> + };
> +
> + ...
> +
> + venus: video-codec@1d0 {
> + ...
> + iommus = <_iommu 5>;
> + };
> +
> + mdp: mdp@1a01000 {
> + ...
> + iommus = <_iommu 4>;
> + };
> +
> + gpu@01c0 {
> + ...
> + iommus = <_iommu 1>, <_iommu 2>;
> + };
> -- 
> 2.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding

[Rob Herring]

On Fri, Feb 03, 2017 at 04:10:30PM +0200, Laurent Pinchart wrote:
> Hi Rob,
> 
> On Monday 29 Feb 2016 23:33:09 Magnus Damm wrote:
> > From: Magnus Damm 
> > 
> > Update the IPMMU DT binding documentation to include the r8a7795 compat
> > string as well as the "renesas,ipmmu-main" property that on r8a7795 will
> > be used to describe the topology and the relationship between the various
> > cache IPMMU instances and the main IPMMU.
> > 
> > Signed-off-by: Magnus Damm 
> 
> This DT binding has been merged already, but isn't used upstream (nor in the 
> dts nor in the drivers). We plan to start using it, and I'd like to seize 
> this 
> last opportunity to change it if needed and ask you for a review.

Looks pretty standard.

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

Re: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property

[Rob Herring]

On Fri, Dec 16, 2016 at 01:19:29PM +, Robin Murphy wrote:
> The current SMR masking support using a 2-cell iommu-specifier is
> primarily intended to handle individual masters with large and/or
> complex Stream ID assignments; it quickly gets a bit clunky in other SMR
> use-cases where we just want to consistently mask out the same part of
> every Stream ID (e.g. for MMU-500 configurations where the appended TBU
> number gets in the way unnecessarily). Let's add a new property to allow
> a single global mask value to better fit the latter situation.
> 
> CC: Stuart Yoder 
> Signed-off-by: Robin Murphy 
> ---
> 
> Compile-tested only...
> 
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 
>  drivers/iommu/arm-smmu.c | 4 +++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index e862d1485205..98f5cbe5fdb4 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -60,6 +60,14 @@ conditions.
>aliases of secure registers have to be used during
>SMMU configuration.
>  
> +- stream-match-mask : Specifies a fixed SMR mask value to combine with

Needs a vendor prefix.

Otherwise looks fine.

> +  the Stream ID value from every iommu-specifier. This
> +  may be used instead of an "#iommu-cells" value of 2
> +  when there is no need for per-master SMR masks, but
> +  it is still desired to mask some portion of every
> +  Stream ID (e.g. for certain MMU-500 configurations
> +  given globally unique external IDs).
> +
>  ** Deprecated properties:
>  
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] Docs: dt: Be explicit and consistent in reference to IOMMU specifiers

[Rob Herring]

On Thu, Dec 15, 2016 at 06:16:13PM -0600, Stuart Yoder wrote:
> The generic IOMMU binding says that the meaning of an 'IOMMU specifier'
> is defined by the binding of a specific SMMU.  The ARM SMMU binding
> never explicitly uses the term 'specifier' at all.  Update implicit
> references to use the explicit term.
> 
> In the iommu-map binding change references to iommu-specifier to
> "IOMMU specifier" so we are 100% consistent everywhere with terminology
> and capitalization.
> 
> Signed-off-by: Stuart Yoder 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 10 +-
>  Documentation/devicetree/bindings/pci/pci-iommu.txt  |  6 +++---
>  2 files changed, 8 insertions(+), 8 deletions(-)

Applied, thanks.

Rob

> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index e862d148..6cdf32d 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -36,15 +36,15 @@ conditions.
>combined interrupt, it must be listed multiple times.
>  
>  - #iommu-cells  : See Documentation/devicetree/bindings/iommu/iommu.txt
> -  for details. With a value of 1, each "iommus" entry
> +  for details. With a value of 1, each IOMMU specifier
>represents a distinct stream ID emitted by that device
>into the relevant SMMU.
>  
>SMMUs with stream matching support and complex masters
> -  may use a value of 2, where the second cell represents
> -  an SMR mask to combine with the ID in the first cell.
> -  Care must be taken to ensure the set of matched IDs
> -  does not result in conflicts.
> +  may use a value of 2, where the second cell of the
> +  IOMMU specifier represents an SMR mask to combine with
> +  the ID in the first cell.  Care must be taken to ensure
> +  the set of matched IDs does not result in conflicts.
>  
>  ** System MMU optional properties:
>  
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt 
> b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 56c8296..0def586 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -32,17 +32,17 @@ PCI root complex
>  Optional properties
>  ---
>  
> -- iommu-map: Maps a Requester ID to an IOMMU and associated iommu-specifier
> +- iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier
>data.
>  
>The property is an arbitrary number of tuples of
>(rid-base,iommu,iommu-base,length).
>  
>Any RID r in the interval [rid-base, rid-base + length) is associated with
> -  the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> +  the listed IOMMU, with the IOMMU specifier (r - rid-base + iommu-base).
>  
>  - iommu-map-mask: A mask to be applied to each Requester ID prior to being
> -  mapped to an iommu-specifier per the iommu-map property.
> +  mapped to an IOMMU specifier per the iommu-map property.
>  
>  
>  Example (1)
> -- 
> 1.9.0
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2] iommu/ipmmu-vmsa: Add r8a7796 DT binding

[Rob Herring]

On Thu, Oct 27, 2016 at 07:45:10PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Update the IPMMU DT binding documentation to include the r8a7796 compat
> string for R-Car M3-W.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> ---
> 
>  Changes since V1:
>  - Added Acked-by from Laurent - thanks!
> 
>  Now broken out, however earlier V1 posted as part of:
>  [PATCH 0/3] iommu/ipmmu-vmsa: Initial r8a7796 support
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
>  1 file changed, 1 insertion(+)

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

Re: [PATCH v7 05/22] Docs: dt: document ARM SMMUv3 generic binding usage

[Rob Herring]

On Mon, Sep 12, 2016 at 05:13:43PM +0100, Robin Murphy wrote:
> We're about to ratify our use of the generic binding, so document it.
> 
> CC: Rob Herring <robh...@kernel.org>
> CC: Mark Rutland <mark.rutl...@arm.com>
> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> 
> ---
> 
> - Reference PCI "iommu-map" binding instead, as that's our main concern
> - Fix "IDs" typo
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

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

Re: [PATCH v5 16/19] Docs: dt: document ARM SMMU generic binding usage

[Rob Herring]

On Tue, Aug 23, 2016 at 08:05:27PM +0100, Robin Murphy wrote:
> Document how the generic "iommus" binding should be used to describe ARM
> SMMU stream IDs instead of the old "mmu-masters" binding.
> 
> CC: Rob Herring <robh...@kernel.org>
> CC: Mark Rutland <mark.rutl...@arm.com>
> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 63 
> --
>  1 file changed, 48 insertions(+), 15 deletions(-)

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

Re: [PATCH v2 3/7] of/irq: Break out msi-map lookup (again)

[Rob Herring]

On Fri, Jun 3, 2016 at 12:15 PM, Robin Murphy <robin.mur...@arm.com> wrote:
> The PCI msi-map code is already doing double-duty translating IDs and
> retrieving MSI parents, which unsurprisingly is the same functionality
> we need for the identically-formatted PCI iommu-map property. Drag the
> core parsing routine up yet another layer into the general OF-PCI code,
> and further generalise it for either kind of lookup in either flavour
> of map property.
>
> CC: Rob Herring <robh...@kernel.org>
> CC: Frank Rowand <frowand.l...@gmail.com>
> CC: Marc Zyngier <marc.zyng...@arm.com>
> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> ---
>
> v2: No change.
>
>  drivers/of/irq.c   |  70 ++---
>  drivers/of/of_pci.c| 102 
> +
>  include/linux/of_pci.h |   8 
>  3 files changed, 114 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index e7bfc175b8e1..0c9118d849ee 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -586,13 +587,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct 
> device_node **np,
> u32 rid_in)
>  {
> struct device *parent_dev;
> -   struct device_node *msi_controller_node;
> -   struct device_node *msi_np = *np;
> -   u32 map_mask, masked_rid, rid_base, msi_base, rid_len, phandle;
> -   int msi_map_len;
> -   bool matched;
> u32 rid_out = rid_in;
> -   const __be32 *msi_map = NULL;
>
> /*
>  * Walk up the device parent links looking for one with a
> @@ -602,71 +597,14 @@ static u32 __of_msi_map_rid(struct device *dev, struct 
> device_node **np,
> if (!parent_dev->of_node)
> continue;
>
> -   msi_map = of_get_property(parent_dev->of_node,
> - "msi-map", _map_len);
> -   if (!msi_map)
> +   if (!of_property_read_bool(parent_dev->of_node, "msi-map"))

But msi-map is not bool, right? I think we allow bools to have values
for historical reasons, but really bool with a value should be an
error. So don't rely on current behavior.

> continue;
>
> -   if (msi_map_len % (4 * sizeof(__be32))) {
> -   dev_err(parent_dev, "Error: Bad msi-map length: %d\n",
> -   msi_map_len);
> -   return rid_out;
> -   }
> /* We have a good parent_dev and msi_map, let's use them. */
> +   of_pci_map_rid(parent_dev->of_node, "msi-map", rid_in, np,
> +  _out);

Seems like this could return an error code and then you could continue
based on the return code. Then you wouldn't be looking up msi-map
twice. Probably could get rid of the !parent_dev->of_node check too.

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

Re: [PATCH V5 2/7] documentation: iommu: Add bindings for msm,iommu-v0 ip

[Rob Herring]

On Fri, May 20, 2016 at 04:24:49PM +0530, Sricharan R wrote:
> 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.
> Adding the DT bindings for the same.
> 
> Signed-off-by: Sricharan R <sricha...@codeaurora.org>
> ---
>  .../devicetree/bindings/iommu/msm,iommu-v0.txt | 64 
> ++
>  1 file changed, 64 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt

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

Re: [PATCH v2 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi

[Rob Herring]

On Thu, May 19, 2016 at 07:49:14PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang <honghui.zh...@mediatek.com>
> 
> This patch defines the local arbitor port IDs for mediatek SoC MT2701 and
> add descriptions of binding for mediatek generation one iommu and smi.
> 
> Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> ---
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   | 13 +++-
>  .../memory-controllers/mediatek,smi-common.txt | 21 +-
>  .../memory-controllers/mediatek,smi-larb.txt   |  4 +-
>  include/dt-bindings/memory/mt2701-larb-port.h  | 85 
> ++
>  4 files changed, 115 insertions(+), 8 deletions(-)
>  create mode 100644 include/dt-bindings/memory/mt2701-larb-port.h

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

Re: [PATCH 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi

[Rob Herring]

On Mon, May 09, 2016 at 04:00:12PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> This patch defines the local arbitor port IDs for mediatek SoC MT2701 and
> add descriptions of binding for mediatek generation one iommu and smi.
> 
> Signed-off-by: Honghui Zhang 
> ---
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   | 13 +++-
>  .../memory-controllers/mediatek,smi-common.txt | 21 +-
>  .../memory-controllers/mediatek,smi-larb.txt   |  4 +-
>  include/dt-bindings/memory/mt2701-larb-port.h  | 85 
> ++
>  4 files changed, 115 insertions(+), 8 deletions(-)
>  create mode 100644 include/dt-bindings/memory/mt2701-larb-port.h
> 
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> index cd1b1cd..9a4a5b5 100644
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> @@ -1,7 +1,9 @@
>  * Mediatek IOMMU Architecture Implementation
>  
> -  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
> -uses the ARM Short-Descriptor translation table format for address 
> translation.
> +  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
> +this M4U have two generations of HW architecture. Generation one use flat

s/use/uses/

> +pagetable, and only support 4K size page mapping. Generation two uses the

s/support/supports/

> +ARM Short-Descriptor translation table format for address translation.
>  
>About the M4U Hardware Block Diagram, please check below:
>  
> @@ -36,7 +38,9 @@ in each larb. Take a example, There are many ports like MC, 
> PP, VLD in the
>  video decode local arbiter, all these ports are according to the video HW.
>  
>  Required properties:
> -- compatible : must be "mediatek,mt8173-m4u".
> +- compatible : must be one of the following string:
> + "mediatek,mt2701-m4u" for mt2701 which use generation one m4u HW.
> + "mediatek,mt8173-m4u" for mt8173 which use generation two m4u HW.
>  - reg : m4u register base and size.
>  - interrupts : the interrupt of m4u.
>  - clocks : must contain one entry for each clock-names.
> @@ -46,7 +50,8 @@ Required properties:
>   according to the local arbiter index, like larb0, larb1, larb2...
>  - iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
>   Specifies the mtk_m4u_id as defined in
> - dt-binding/memory/mt8173-larb-port.h.
> + dt-binding/memory/mt2701-larb-port.h for mt2701 and
> + dt-binding/memory/mt8173-larb-port.h for mt8173
>  
>  Example:
>   iommu: iommu@10205000 {
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> index 06a83ce..80c0e22 100644
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> @@ -2,16 +2,31 @@ SMI (Smart Multimedia Interface) Common
>  
>  The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
>  
> +Mediatek SMI have two generation HW architecture, mt8173 use the secondary

s/generation/generations of/
s/use/uses/
s/secondary/second/

> +generation of SMI HW while mt2701 use the first generation HW of SMI.

s/use/uses/

> +
> +There's slight differences between the two SMI, for generation 2, the
> +register which control the iommu port is at each larb's register base. But
> +for generation 1, the register is at smi ao base(smi always on register
> +base). Besides that, the smi async clock should be prepare and enabled for

s/prepare/prepared/

> +SMI generation 1 to transform the smi clock into emi clock domain, but no

s/no/that is not/

> +needed for SMI generation 2.
> +
>  Required properties:
> -- compatible : must be "mediatek,mt8173-smi-common"
> +- compatible : must be one of :
> + "mediatek,mt2701-smi-common"
> + "mediatek,mt8173-smi-common"
>  - reg : the register and size of the SMI block.
>  - power-domains : a phandle to the power domain of this local arbiter.
>  - clocks : Must contain an entry for each entry in clock-names.
> -- clock-names : must contain 2 entries, as follows:
> +- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
> +  for generation 2 smi HW as follows:
>- "apb" : Advanced Peripheral Bus clock, It's the clock for setting
>   the register.
>- "smi" : It's the clock for transfer data and command.
> -  They may be the same if both source clocks are the same.
> + They may be the same if both source clocks are the same.
> +  - "async" : asynchronous clock, it help transform the smi clock into the 
> emi
> +   clock domain, this clock is only needed by generation 1 smi HW.
>  
>  Example:
>

Re: [PATCH 0/6 v2] of: Implement iterator for phandles

[Rob Herring]

On Mon, Apr 4, 2016 at 10:49 AM, Joerg Roedel <j...@8bytes.org> wrote:
> Hi,
>
> here is a new version of the implementation of the iterator
> over phandles concept which Rob Herring suggested to me some
> time ago. My approach is a little bit different from what
> the diff showed back then, but it gets rid of the allocation
> and 'struct of_phandle_args' misuse.
>
> I also converted the arm-smmu driver to make use of the
> iterator. The resulting kernel boots on my AMD Seattle
> system and fixes the warning triggered there. The patches
> now also pass all dt-unittests in my kvm environment.
>
> Patches are based on v4.6-rc2

Series now applied.

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

Re: [PATCH V2 1/5] iommu/msm: Add DT adaptation

[Rob Herring]

On Wed, Apr 06, 2016 at 07:59:31PM +0530, Sricharan R wrote:
> The driver currently works based on platform data. Remove this
> and add support for DT. A single master can have multiple ports
> connected to more than one iommu.
> 
> master
>   |
>   |
>   |
>  
>||
>   IOMMU0  IOMMU1

You've got mixtures of tabs and spaces here. Either fully use leading 
tabs or use spaces everywhere.

>||
>   ctx0   ctx1  ctx0   ctx1
> 
> This association of master and iommus/contexts were previously
> represented by platform data parent/child device details. The client
> drivers were responsible for programming all of the iommus/contexts
> for the device. Now while adapting to generic DT bindings we maintain the
> list of iommus, contexts that each master domain is connected to and
> program all of them on attach/detach.
> 
> Signed-off-by: Sricharan R 
> ---
>  .../devicetree/bindings/iommu/msm,iommu-v0.txt |  59 

It is preferred to split bindings to separate patch.

>  drivers/iommu/msm_iommu.c  | 252 +
>  drivers/iommu/msm_iommu.h  |  73 ++---
>  drivers/iommu/msm_iommu_dev.c  | 315 
> +
>  4 files changed, 296 insertions(+), 403 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt 
> b/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> new file mode 100644
> index 000..21bfbfc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> @@ -0,0 +1,59 @@
> +* QCOM IOMMU
> +
> +The QCOM 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,iommu-v0".

You need SoC specific compatible strings in addition.

> +  - 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: This is the total number of stream ids that a master would
> +   use during transactions which will be specified as a list
> +   as a part of iommus property below.
> +  - 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). See
> +   Documentation/devicetree/bindings/clock/clock-bindings.txt
> +   for more info.
> +
> +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 list of the
> + stream ids used by the device.
> +
> +Example: mdp iommu and its bus master
> +
> +mdp_port0: qcom,iommu@750 {
> + compatible = "msm,iommu-v0";
> + #iommu-cells = <2>;
> + clock-names =
> + "smmu_pclk",
> + "iommu_clk";
> + clocks =
> + < SMMU_AHB_CLK>,
> + < MDP_AXI_CLK>;
> + reg = <0x0750 0x10>;
> + interrupts =
> + ,
> + ;
> + ncb = <2>;
> + };
> +
> + mdp: qcom,mdp@510 {
> + compatible = "qcom,mdp";
> + ...
> + iommus = <_port0 0 2>;
> + };
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v7, 3/5] dt: move guts devicetree doc out of powerpc directory

[Rob Herring]

On Fri, Apr 01, 2016 at 11:07:29AM +0800, Yangbo Lu wrote:
> Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
> since it's used by not only PowerPC but also ARM. And add a specification
> for 'little-endian' property.
> 
> Signed-off-by: Yangbo Lu <yangbo...@nxp.com>
> ---
> Changes for v2:
>   - None
> Changes for v3:
>   - None
> Changes for v4:
>   - Added this patch
> Changes for v5:
>   - Modified the description for little-endian property
> Changes for v6:
>   - None
> Changes for v7:
>   - None
> ---
>  Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
>  1 file changed, 3 insertions(+)
>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)

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

Re: [PATCH 0/6] of: Implement iterator for phandles

[Rob Herring]

On Wed, Mar 23, 2016 at 6:54 AM, Joerg Roedel <j...@8bytes.org> wrote:
> Hi Rob,
>
> On Tue, Mar 22, 2016 at 01:45:41PM -0500, Rob Herring wrote:
>> On Tue, Mar 22, 2016 at 12:58 PM, Joerg Roedel <j...@8bytes.org> wrote:
>> > Please review. Patches are based on v4.5.
>>
>> Other than my one comment, this looks good to me. For the series:
>>
>> Acked-by: Rob Herring <r...@kernel.org>
>
> Thanks a lot for your fast reply! I guess these patches will go through
> the DT tree, or should I carry them in the IOMMU tree? The DT tree
> probably makes more sense.

Sure, I can take them.

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

Re: [PATCH 6/6] iommu/arm-smmu: Make use of phandle iterators in device-tree parsing

[Rob Herring]

On Tue, Mar 22, 2016 at 12:58 PM, Joerg Roedel  wrote:
> From: Joerg Roedel 
>
> Remove the usage of of_parse_phandle_with_args() and replace
> it by the phandle-iterator implementation so that we can
> parse out all of the potentially present 128 stream-ids.
>
> Signed-off-by: Joerg Roedel 
> ---
>  drivers/iommu/arm-smmu.c | 28 ++--
>  1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 59ee4b8..413bd64 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -48,7 +48,7 @@
>  #include "io-pgtable.h"
>
>  /* Maximum number of stream IDs assigned to a single device */
> -#define MAX_MASTER_STREAMIDS   MAX_PHANDLE_ARGS
> +#define MAX_MASTER_STREAMIDS   128
>
>  /* Maximum number of context banks per SMMU */
>  #define ARM_SMMU_MAX_CBS   128
> @@ -349,6 +349,12 @@ struct arm_smmu_domain {
> struct iommu_domain domain;
>  };
>
> +struct arm_smmu_phandle_args {
> +   struct device_node *np;
> +   int args_count;
> +   uint32_t args[MAX_MASTER_STREAMIDS];
> +};
> +
>  static struct iommu_ops arm_smmu_ops;
>
>  static DEFINE_SPINLOCK(arm_smmu_devices_lock);
> @@ -458,7 +464,7 @@ static int insert_smmu_master(struct arm_smmu_device 
> *smmu,
>
>  static int register_smmu_master(struct arm_smmu_device *smmu,
> struct device *dev,
> -   struct of_phandle_args *masterspec)
> +   struct arm_smmu_phandle_args *masterspec)
>  {
> int i;
> struct arm_smmu_master *master;
> @@ -1716,7 +1722,8 @@ static int arm_smmu_device_dt_probe(struct 
> platform_device *pdev)
> struct arm_smmu_device *smmu;
> struct device *dev = >dev;
> struct rb_node *node;
> -   struct of_phandle_args masterspec;
> +   struct of_phandle_iterator it;
> +   struct arm_smmu_phandle_args masterspec;

Isn't this a bit big to put on the stack being ~512 bytes?

> int num_irqs, i, err;
>
> smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory

[Rob Herring]

On Wed, Mar 09, 2016 at 06:08:49PM +0800, Yangbo Lu wrote:
> Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
> since it's used by not only PowerPC but also ARM. And add a specification
> for 'little-endian' property.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None
> Changes for v3:
>   - None
> Changes for v4:
>   - Added this patch
> Changes for v5:
>   - Modified the description for little-endian property
> Changes for v6:
>   - None
> ---
>  Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
>  1 file changed, 3 insertions(+)
>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt 
> b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
> index b71b203..07adca9 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> @@ -25,6 +25,9 @@ Recommended properties:
>   - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
> registers, for those SOCs that have a PAMU device.
>  
> + - little-endian : Indicates that the global utilities block is little
> +   endian. The default is big endian.

The default is "the native endianness of the system". So absence on an 
ARM system would be LE. This property is valid for any simple-bus 
device, so it isn't really required to document per device. You can, but 
your description had better match the documented behaviour.

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

Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory

[Rob Herring]

On Thu, Mar 17, 2016 at 12:11 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thursday 17 March 2016 12:06:40 Rob Herring wrote:
>> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt 
>> > b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>> > similarity index 91%
>> > rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>> > rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
>> > index b71b203..07adca9 100644
>> > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>> > +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>> > @@ -25,6 +25,9 @@ Recommended properties:
>> >   - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
>> > registers, for those SOCs that have a PAMU device.
>> >
>> > + - little-endian : Indicates that the global utilities block is little
>> > +   endian. The default is big endian.
>>
>> The default is "the native endianness of the system".
>
> This may be what is currently documented, but not what we are doing
> in practice, as there is no "native endianess" for either PowerPC or
> ARM -- both allow running big-endian or little-endian kernels and the
> device registers are fixed.

Notice I said system, not architecture. The way the device registers
are fixed is what I mean by native endianness.

If the purpose of adding this property now is to support GUTS on the
ARM SoCs, then I'd argue using this property is probably wrong. If the
PPC systems are designed with BE device registers and ARM systems with
LE, then this property is not needed.

> I think the property here is fine.

Unless you have studied the FSL ARM based SoCs, then there is not
enough information here to tell.

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

Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

[Rob Herring]

On Mon, Mar 14, 2016 at 05:45:43PM +, Scott Wood wrote:
> On 03/14/2016 02:29 AM, Yangbo Lu wrote:
> >> -Original Message-
> >> From: Arnd Bergmann [mailto:a...@arndb.de]
> >> Sent: Monday, March 14, 2016 6:26 AM
> >> To: linuxppc-...@lists.ozlabs.org
> >> Cc: Yangbo Lu; devicet...@vger.kernel.org; linux-arm-
> >> ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
> >> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> >> foundation.org; net...@vger.kernel.org; linux-...@vger.kernel.org;
> >> ulf.hans...@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma; Joerg
> >> Roedel; Santosh Shilimkar; Scott Wood; Rob Herring; Claudiu Manoil; Kumar
> >> Gala; Yang-Leo Li; Xiaobo Xie
> >> Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-
> >> R1.0-R2.0
> >>
> >> On Wednesday 09 March 2016 18:08:51 Yangbo Lu wrote:
> >>> @@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device
> >> *pdev, struct sdhci_host *host)
> >>> struct sdhci_pltfm_host *pltfm_host;
> >>> struct sdhci_esdhc *esdhc;
> >>> u16 host_ver;
> >>> +   u32 svr;
> >>>
> >>> pltfm_host = sdhci_priv(host);
> >>> esdhc = sdhci_pltfm_priv(pltfm_host);
> >>>
> >>> +   fsl_guts_init();
> >>> +   svr = fsl_guts_get_svr();
> >>> +   if (svr) {
> >>> +   esdhc->soc_ver = SVR_SOC_VER(svr);
> >>> +   esdhc->soc_rev = SVR_REV(svr);
> >>> +   } else {
> >>> +   dev_err(>dev, "Failed to get SVR value!\n");
> >>> +   }
> >>> +
> >>
> >> This makes the driver non-portable. Better identify the specific
> >> workarounds based on the compatible string for this device, or add a
> >> boolean DT property for the quirk.
> >>
> >>Arnd
> > 
> > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 
> > before.
> > https://patchwork.kernel.org/patch/6834221/
> > 
> > We don’t have a separate DTS file for each revision of an SOC and if we 
> > did, we'd constantly have people using the wrong one.
> > In addition, the device tree is stable ABI and errata are often discovered 
> > after device tree are deployed.
> > See the link for details.
> > 
> > So we decide to read SVR from the device-config/guts MMIO block other than 
> > using DTS.
> > Thanks.
> 
> Also note that this driver is already only for fsl-specific hardware,
> and it will still work even if fsl_guts doesn't find anything to bind to
> -- it just wouldn't be able to detect errata based on SVR in that case.

IIRC, it is the same IP block as i.MX and Arnd's point is this won't 
even compile on !PPC. It is things like this that prevent sharing the 
driver. Dealing with Si revs is a common problem. We should have a 
common solution. There is soc_device for this purpose.

OTOH, the integration differences may be enough that trying to have a 
common driver with i.MX would not be worth it.

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

Re: [PATCH 1/2] of: Implement iterator for phandles

[Rob Herring]

On Wed, Mar 16, 2016 at 11:42 AM, Joerg Roedel  wrote:
> From: Joerg Roedel 
>
> Getting the arguments of phandles is somewhat limited at the
> moement, because the number of arguments supported by core
> code is limited to MAX_PHANDLE_ARGS, which is set to 16
> currently.
>
> In case of the arm smmu this is not enough, as the 128
> supported stream-ids are encoded in device-tree with
> arguments to phandles. On some systems with more than 16
> stream-ids this causes a WARN_ON being triggered at boot and
> an incomplete initialization of the smmu.
>
> This patch-set implements an iterator interface over
> phandles which allows to parse out arbitrary numbers of
> arguments per phandle. The existing function for parsing
> them, __of_parse_phandle_with_args(), is converted to make
> use of the iterator.

This mostly looks fine to me, but it is kind of a lot of functions
just for this one thing. For example, I think the caller can track the
index themselves if they care about it. I'd also like to see a more
standard style for_each type iterator define rather than open coded
while loops.

Some minor style comments below.

> Signed-off-by: Joerg Roedel 
> ---
>  drivers/of/base.c  | 219 
> ++---
>  include/linux/of.h |  95 +++
>  2 files changed, 220 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 017dd94..9a5f199 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1439,119 +1439,150 @@ void of_print_phandle_args(const char *msg, const 
> struct of_phandle_args *args)
> printk("\n");
>  }
>
> -static int __of_parse_phandle_with_args(const struct device_node *np,
> -   const char *list_name,
> -   const char *cells_name,
> -   int cell_count, int index,
> -   struct of_phandle_args *out_args)
> +int of_phandle_iterator_init(struct of_phandle_iterator *it,
> +const struct device_node *np,
> +const char *list_name,
> +const char *cells_name,
> +int cell_count)
>  {
> -   const __be32 *list, *list_end;
> -   int rc = 0, size, cur_index = 0;
> -   uint32_t count = 0;
> -   struct device_node *node = NULL;
> -   phandle phandle;
> +   const __be32 *list;
> +   int size;
>
> /* Retrieve the phandle list property */
> list = of_get_property(np, list_name, );
> if (!list)
> return -ENOENT;
> -   list_end = list + size / sizeof(*list);
>
> -   /* Loop over the phandles until all the requested entry is found */
> -   while (list < list_end) {
> -   rc = -EINVAL;
> -   count = 0;
> +   it->np  = np;
> +   it->node= NULL;
> +   it->list= list;
> +   it->phandle_end = list;
> +   it->list_end= list + size / sizeof(*list);
> +   it->cells_name  = cells_name;
> +   it->cell_count  = cell_count;
> +   it->cur_index   = -1;
>
> -   /*
> -* If phandle is 0, then it is an empty entry with no
> -* arguments.  Skip forward to the next entry.
> -*/
> -   phandle = be32_to_cpup(list++);
> -   if (phandle) {
> -   /*
> -* Find the provider node and parse the #*-cells
> -* property to determine the argument length.
> -*
> -* This is not needed if the cell count is hard-coded
> -* (i.e. cells_name not set, but cell_count is set),
> -* except when we're going to return the found node
> -* below.
> -*/
> -   if (cells_name || cur_index == index) {
> -   node = of_find_node_by_phandle(phandle);
> -   if (!node) {
> -   pr_err("%s: could not find phandle\n",
> -   np->full_name);
> -   goto err;
> -   }
> -   }
> +   return 0;
> +}
>
> -   if (cells_name) {
> -   if (of_property_read_u32(node, cells_name,
> -)) {
> -   pr_err("%s: could not get %s for 
> %s\n",
> -   np->full_name, cells_name,
> -   node->full_name);
> -   goto err;
> -

Re: [PATCH 10/12] Docs: dt: document ARM SMMU generic binding usage

[Rob Herring]

On Mon, Feb 29, 2016 at 01:46:19PM +, Robin Murphy wrote:
> Document how the generic "iommus" binding should be used to describe ARM
> SMMU stream IDs instead of the old "mmu-masters" binding.
> 
> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 40 
> ++
>  1 file changed, 25 insertions(+), 15 deletions(-)

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

Re: [PATCH 01/12] Docs: dt: add PCI IOMMU map bindings

[Rob Herring]

On Mon, Feb 29, 2016 at 01:46:10PM +, Robin Murphy wrote:
> From: Mark Rutland <mark.rutl...@arm.com>
> 
> The existing IOMMU bindings are able to specify the relationship between
> masters and IOMMUs, but they are insufficient for describing the general
> case of hotpluggable busses such as PCI where the set of masters is not
> known until runtime, and the relationship between masters and IOMMUs is
> a property of the integration of the system.
> 
> This patch adds a generic binding for mapping PCI devices to IOMMUs,
> using a new iommu-map property (specific to PCI*) which may be used to
> map devices (identified by their Requester ID) to sideband data for the
> IOMMU which they master through.
> 
> Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
> ---
>  .../devicetree/bindings/pci/pci-iommu.txt  | 171 
> +
>  1 file changed, 171 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt

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

Re: [PATCH v8 2/5] dt-bindings: mediatek: Add smi dts binding

[Rob Herring]

On Tue, Jan 26, 2016 at 12:12:39PM +0800, Yong Wu wrote:
> This patch add smi binding document and smi local arbiter header file.
> 
> Signed-off-by: Yong Wu <yong...@mediatek.com>
> ---
>  .../memory-controllers/mediatek,smi-common.txt |  24 +
>  .../memory-controllers/mediatek,smi-larb.txt   |  25 +
>  include/dt-bindings/memory/mt8173-larb-port.h  | 111 
> +
>  3 files changed, 160 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h

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

Re: [PATCH v7 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU

[Rob Herring]

On Fri, Dec 18, 2015 at 04:09:39PM +0800, Yong Wu wrote:
> This patch add mediatek iommu dts binding document.
> 
> Signed-off-by: Yong Wu <yong...@mediatek.com>

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

Re: [PATCH v6 2/5] dt-bindings: mediatek: Add smi dts binding

[Rob Herring]

On Tue, Dec 08, 2015 at 05:49:10PM +0800, Yong Wu wrote:
> This patch add smi binding document.
> 
> Signed-off-by: Yong Wu <yong...@mediatek.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../memory-controllers/mediatek,smi-common.txt | 24 +
>  .../memory-controllers/mediatek,smi-larb.txt   | 25 
> ++
>  2 files changed, 49 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> new file mode 100644
> index 000..06a83ce
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> @@ -0,0 +1,24 @@
> +SMI (Smart Multimedia Interface) Common
> +
> +The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> +
> +Required properties:
> +- compatible : must be "mediatek,mt8173-smi-common"
> +- reg : the register and size of the SMI block.
> +- power-domains : a phandle to the power domain of this local arbiter.
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names : must contain 2 entries, as follows:
> +  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> + the register.
> +  - "smi" : It's the clock for transfer data and command.
> +  They may be the same if both source clocks are the same.
> +
> +Example:
> + smi_common: smi@14022000 {
> + compatible = "mediatek,mt8173-smi-common";
> + reg = <0 0x14022000 0 0x1000>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + clocks = < CLK_MM_SMI_COMMON>,
> +  < CLK_MM_SMI_COMMON>;
> + clock-names = "apb", "smi";
> + };
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> new file mode 100644
> index 000..55ff3b7
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> @@ -0,0 +1,25 @@
> +SMI (Smart Multimedia Interface) Local Arbiter
> +
> +The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> +
> +Required properties:
> +- compatible : must be "mediatek,mt8173-smi-larb"
> +- reg : the register and size of this local arbiter.
> +- mediatek,smi : a phandle to the smi_common node.
> +- power-domains : a phandle to the power domain of this local arbiter.
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names: must contain 2 entries, as follows:
> +  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> + the register.
> +  - "smi" : It's the clock for transfer data and command.
> +
> +Example:
> + larb1: larb@1601 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x1601 0 0x1000>;
> + mediatek,smi = <_common>;
> + power-domains = < MT8173_POWER_DOMAIN_VDEC>;
> + clocks = < CLK_VDEC_CKEN>,
> +  < CLK_VDEC_LARB_CKEN>;
> + clock-names = "apb", "smi";
> + };
> -- 
> 1.8.1.1.dirty
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v6 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU

[Rob Herring]

On Tue, Dec 08, 2015 at 05:49:09PM +0800, Yong Wu wrote:
> This patch add mediatek iommu dts binding document.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   |  68 +
>  include/dt-bindings/memory/mt8173-larb-port.h  | 111 
> +

This should be iommu rather than memory.

Otherwise, it looks okay to me.

>  2 files changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>  create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h
> 
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> new file mode 100644
> index 000..c2fb06e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> @@ -0,0 +1,68 @@
> +* Mediatek IOMMU Architecture Implementation
> +
> +  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
> +uses the ARM Short-Descriptor translation table format for address 
> translation.
> +
> +  About the M4U Hardware Block Diagram, please check below:
> +
> +  EMI (External Memory Interface)
> +   |
> +  m4u (Multimedia Memory Management Unit)
> +   |
> +   SMI Common(Smart Multimedia Interface Common)
> +   |
> +   ++---
> +   ||
> +   ||
> +   SMI larb0SMI larb1   ... SoCs have several SMI local 
> arbiter(larb).
> +   (display) (vdec)
> +   ||
> +   ||
> + +-+-+ +++
> + | | | |||
> + | | |...  |||  ... There are different ports in each larb.
> + | | | |||
> +OVL0 RDMA0 WDMA0  MC   PP   VLD
> +
> +  As above, The Multimedia HW will go through SMI and M4U while it
> +access EMI. SMI is a brige between m4u and the Multimedia HW. It contain
> +smi local arbiter and smi common. It will control whether the Multimedia
> +HW should go though the m4u for translation or bypass it and talk
> +directly with EMI. And also SMI help control the power domain and clocks for
> +each local arbiter.
> +  Normally we specify a local arbiter(larb) for each multimedia HW
> +like display, video decode, and camera. And there are different ports
> +in each larb. Take a example, There are many ports like MC, PP, VLD in the
> +video decode local arbiter, all these ports are according to the video HW.
> +
> +Required properties:
> +- compatible : must be "mediatek,mt8173-m4u".
> +- reg : m4u register base and size.
> +- interrupts : the interrupt of m4u.
> +- clocks : must contain one entry for each clock-names.
> +- clock-names : must be "bclk", It is the block clock of m4u.
> +- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
> + Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
> + according to the local arbiter index, like larb0, larb1, larb2...
> +- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
> + Specifies the mtk_m4u_id as defined in
> + dt-binding/memory/mt8173-larb-port.h.
> +
> +Example:
> + iommu: iommu@10205000 {
> + compatible = "mediatek,mt8173-m4u";
> + reg = <0 0x10205000 0 0x1000>;
> + interrupts = ;
> + clocks = < CLK_INFRA_M4U>;
> + clock-names = "bclk";
> + mediatek,larbs = < >;
> + #iommu-cells = <1>;
> + };
> +
> +Example for a client device:
> + display {
> + compatible = "mediatek,mt8173-disp";
> + iommus = < M4U_PORT_DISP_OVL0>,
> +  < M4U_PORT_DISP_RDMA0>;
> + ...
> + };
> diff --git a/include/dt-bindings/memory/mt8173-larb-port.h 
> b/include/dt-bindings/memory/mt8173-larb-port.h
> new file mode 100644
> index 000..50ccb93
> --- /dev/null
> +++ b/include/dt-bindings/memory/mt8173-larb-port.h
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2014-2015 MediaTek Inc.
> + * Author: Yong Wu 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#ifndef __DTS_IOMMU_PORT_MT8173_H
> +#define __DTS_IOMMU_PORT_MT8173_H
> +
> +#define MTK_M4U_ID(larb, port)   (((larb) << 5) | (port))
> +/* Local arbiter ID */
> +#define MTK_M4U_TO_LARB(id)  (((id) >> 5) & 0x7)
> +/* PortID within the local arbiter */
> +#define MTK_M4U_TO_PORT(id)  ((id) & 0x1f)
> +
> 

Re: [PATCH V5 RESEND 1/3] docs: iommu: Documentation for iommu in hi6220 SoC

[Rob Herring]

On Fri, Nov 20, 2015 at 10:25:07AM +0800, Chen Feng wrote:
> Documentation for hi6220 iommu driver.
> 
> Signed-off-by: Chen Feng <puck.c...@hisilicon.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../bindings/iommu/hisi,hi6220-iommu.txt   | 32 
> ++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt 
> b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
> new file mode 100644
> index 000..44f9101
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
> @@ -0,0 +1,32 @@
> +Hi6220 SoC SMMU Device Driver devicetree document
> +The media system shared the same smmu IP to access DDR memory. And all
> +media IP used the same page table.
> +
> +Below binding describes the system mmu for media system in hi6220 platform
> +
> +Required properties:
> +- compatible: should contain "hisilicon,hi6220-smmu".
> +- reg: A tuple of base address and size of System MMU registers.
> +- clocks: a list of phandle + clock-specifier pairs, one for each entry
> +  in clock-names.
> +- clock-names: should contain:
> +  * "smmu"
> +  * "media-sc"
> +  * "smmu-peri"
> +- interrupts: An interrupt specifier for interrupt signal of System MMU.
> +- #iommu-cells: The iommu-cells should be 0. Because no additional 
> information
> +  needs to be encoded in the specifier.
> +
> +Examples:
> + iommu@f421 {
> + compatible = "hisilicon,hi6220-smmu";
> + reg = <0x0 0xf421 0x0 0x1000>;
> + interrupts = ;
> + clocks = <_ctrl HI6220_MMU_CLK>,
> +  <_ctrl HI6220_MED_MMU>,
> +  <_ctrl HI6220_MEDIA_PLL_SRC>;
> + clock-names = "smmu",
> +   "media-sc",
> +   "smmu-peri";
> + #iommu-cells = <0>;
> + };
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/3] docs: iommu: Documentation for iommu in hi6220 SoC

[Rob Herring]

On Tue, Nov 17, 2015 at 5:57 AM, Chen Feng  wrote:
> Documentation for hi6220 iommu driver.

Please use get_maintainers.pl and re-send to correct lists
(devicet...@vger.kernel.org).

>
> Signed-off-by: Chen Feng 
> ---
>  .../bindings/iommu/hisi,hi6220-iommu.txt   | 32 
> ++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
>
> diff --git a/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt 
> b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
> new file mode 100644
> index 000..44f9101
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
> @@ -0,0 +1,32 @@
> +Hi6220 SoC SMMU Device Driver devicetree document
> +The media system shared the same smmu IP to access DDR memory. And all
> +media IP used the same page table.
> +
> +Below binding describes the system mmu for media system in hi6220 platform
> +
> +Required properties:
> +- compatible: should contain "hisilicon,hi6220-smmu".
> +- reg: A tuple of base address and size of System MMU registers.
> +- clocks: a list of phandle + clock-specifier pairs, one for each entry
> +  in clock-names.
> +- clock-names: should contain:
> +  * "smmu"
> +  * "media-sc"
> +  * "smmu-peri"
> +- interrupts: An interrupt specifier for interrupt signal of System MMU.
> +- #iommu-cells: The iommu-cells should be 0. Because no additional 
> information
> +  needs to be encoded in the specifier.
> +
> +Examples:
> +   iommu@f421 {
> +   compatible = "hisilicon,hi6220-smmu";
> +   reg = <0x0 0xf421 0x0 0x1000>;
> +   interrupts = ;
> +   clocks = <_ctrl HI6220_MMU_CLK>,
> +<_ctrl HI6220_MED_MMU>,
> +<_ctrl HI6220_MEDIA_PLL_SRC>;
> +   clock-names = "smmu",
> + "media-sc",
> + "smmu-peri";
> +   #iommu-cells = <0>;
> +   };
> --
> 1.9.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs

[Rob Herring]

On Tue, Nov 17, 2015 at 12:53:20PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the
> IPMMU DT binding documentation. The example is also updated to show
> how the generic compatible string may be used as fallback.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> 
>  Changes since V1:
>  - Updated compat string section to the following:
>"Must contain SoC-specific and generic entries from below."
> 
>  Thanks to Laurent for feedback!
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |   12 
> --
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> --- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> +++ work/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt   
> 2015-11-17 12:45:26.080513000 +0900
> @@ -7,7 +7,15 @@ connected to the IPMMU through a port ca
>  
>  Required Properties:
>  
> -  - compatible: Must contain "renesas,ipmmu-vmsa".
> +  - compatible: Must contain SoC-specific and generic entries from below.
> +
> +- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
> +- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
> +- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
> +- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
> +- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
> +- "renesas,ipmmu-vmsa" for generic R-Car Gen2 VMSA-compatible IPMMU.
> +
>- reg: Base address and size of the IPMMU registers.
>- interrupts: Specifiers for the MMU fault interrupts. For instances that
>  support secure mode two interrupts must be specified, for non-secure and
> @@ -27,7 +35,7 @@ node with the following property:
>  Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
>  
>   ipmmu_mx: mmu@fe951000 {
> - compatible = "renasas,ipmmu-vmsa";
> + compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
>   reg = <0 0xfe951000 0 0x1000>;
>   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
><0 221 IRQ_TYPE_LEVEL_HIGH>;
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/7] doc:bindings:Document for mtcmos regulator on hi6220 SoC

[Rob Herring]

On Thu, Nov 05, 2015 at 09:34:43PM +0800, Chen Feng wrote:
> Add Document for mtcmos driver on hi6220 SoC
> 
> Signed-off-by: Chen Feng 
> Signed-off-by: Fei Wang 
> ---
>  .../bindings/regulator/hisilicon,hi6220-mtcmos.txt | 32 
> ++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt 
> b/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
> new file mode 100644
> index 000..bb06e1b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
> @@ -0,0 +1,32 @@
> +Hi6220 mtcmos Voltage regulators
> +
> +Required parent device properties:
> +- compatible: Must be "hisilicon,hi6220-mtcmos-driver"

What does "driver" refer to?

> +- hisilicon,mtcmos-steady-us: The time to wait for power steady

Wouldn't regulator-enable-ramp-delay be equivalent?


> +- hisilicon,mtcmos-sc-on-base: address of mtcmos on hi6220 SoC
> +
> +Required child device properties:
> +- regulator-name: The name of mtcmos
> +- hisilicon,ctrl-regs: Offset of ctrl-regs
> +- hisilicon,ctrl-data: The bit to ctrl the regulator
> +
> +Example:
> +mtcmos {
> +compatible = "hisilicon,hi6220-mtcmos-driver";
> +hisilicon,mtcmos-steady-us = <10>;
> +hisilicon,mtcmos-sc-on-base  = <0xf780>;
> +hisilicon,mtcmos-acpu-on-base = <0xf65a>;
> +
> +mtcmos1: regulator@a1{
> +regulator-name = "G3D_PD_VDD";
> +regulator-compatible = "mtcmos1";

regulator-compatible is deprecated. Please drop.

> +hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
> +hisilicon,ctrl-data = <1 0x1>;
> +};
> +mtcmos2: regulator@a2{
> +regulator-name = "SOC_MED";
> +regulator-compatible = "mtcmos2";
> +hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
> +hisilicon,ctrl-data = <2 0x1>;
> +};
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

[Rob Herring]

On Mon, Aug 24, 2015 at 5:17 AM, Mark Rutland mark.rutl...@arm.com wrote:
 On Wed, Aug 05, 2015 at 05:51:20PM +0100, Mark Rutland wrote:
 Rob,

 Do you have any objections to this, or are you happy to take this patch?

 There's a user of this binding (the GICv3 ITS) queued for v4.3 already in
 the tip tree, so either we either need to be ok with this binding or we
 need to rework that before v4.3.

 Sorry to ping, but are you happy to take this? Marc's replied and
 provided his ack.

Sorry. Looks fine to me, so I'll apply.

 I'm happy to resend if you prefer?

What about patch 2 and 3? I can't find patch 3 in my mail.

Rob


 Thanks,
 Mark.

 Marc, can I take it from your use of the binding that you are happy to
 provide your ack?

 Thanks,
 Mark.

 On Thu, Jul 23, 2015 at 05:52:43PM +0100, Mark Rutland wrote:
  Currently msi-parent is used in a couple of drivers despite being fairly
  underspecified. This patch adds a generic binding for MSIs (including
  the existing msi-parent property) enabling the description of platform
  devices capable of using MSIs.
 
  While MSIs are primarily distinguished by doorbell and payload, some MSI
  controllers (e.g. the GICv3 ITS) also use side-band information
  accompanying the write to identify the master which originated the MSI,
  to allow for sandboxing. This sideband information is non-probeable and
  needs to be described in the DT. Other MSI controllers may have
  additional configuration details which need to be described per-master.
 
  This patch adds a generic msi-parent binding document, extending the
  de-facto standard with a new (optional) #msi-cells which can be used to
  express any per-master configuration and/or sideband data. This is
  sufficient to describe non-hotpluggable devices.
 
  For busses where sideband data may be derived from some bus-specific
  master ID scheme, other properties will be required to describe the
  mapping.
 
  Signed-off-by: Mark Rutland mark.rutl...@arm.com
  ---
   .../bindings/interrupt-controller/msi.txt  | 135 
  +
   1 file changed, 135 insertions(+)
   create mode 100644 
  Documentation/devicetree/bindings/interrupt-controller/msi.txt
 
  diff --git 
  a/Documentation/devicetree/bindings/interrupt-controller/msi.txt 
  b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
  new file mode 100644
  index 000..c60c034
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
  @@ -0,0 +1,135 @@
  +This document describes the generic device tree binding for MSI 
  controllers and
  +their master(s).
  +
  +Message Signaled Interrupts (MSIs) are a class of interrupts generated by 
  a
  +write to an MMIO address.
  +
  +MSIs were originally specified by PCI (and are used with PCIe), but may 
  also be
  +used with other busses, and hence a mechanism is required to relate 
  devices on
  +those busses to the MSI controllers which they are capable of using,
  +potentially including additional information.
  +
  +MSIs are distinguished by some combination of:
  +
  +- The doorbell (the MMIO address written to).
  +
  +  Devices may be configured by software to write to arbitrary doorbells 
  which
  +  they can address. An MSI controller may feature a number of doorbells.
  +
  +- The payload (the value written to the doorbell).
  +
  +  Devices may be configured to write an arbitrary payload chosen by 
  software.
  +  MSI controllers may have restrictions on permitted payloads.
  +
  +- Sideband information accompanying the write.
  +
  +  Typically this is neither configurable nor probeable, and depends on 
  the path
  +  taken through the memory system (i.e. it is a property of the 
  combination of
  +  MSI controller and device rather than a property of either in 
  isolation).
  +
  +
  +MSI controllers:
  +
  +
  +An MSI controller signals interrupts to a CPU when a write is made to an 
  MMIO
  +address by some master. An MSI controller may feature a number of 
  doorbells.
  +
  +Required properties:
  +
  +
  +- msi-controller: Identifies the node as an MSI controller.
  +
  +Optional properties:
  +
  +
  +- #msi-cells: The number of cells in an msi-specifier, required if not 
  zero.
  +
  +  Typically this will encode information related to sideband data, and 
  will
  +  not encode doorbells or payloads as these can be configured dynamically.
  +
  +  The meaning of the msi-specifier is defined by the device tree binding 
  of
  +  the specific MSI controller.
  +
  +
  +MSI clients
  +===
  +
  +MSI clients are devices which generate MSIs. For each MSI they wish to
  +generate, the doorbell and payload may be configured, though sideband
  +information may not be configurable.
  +
  +Required properties:
  +
  +
  +- msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
  +  controller which the device is capable of using.
  +
  +  

Re: [PATCH 1/2] of: base: Allow more args than MAX_PHANDLE_ARGS if required

[Rob Herring]

On Thu, Jul 16, 2015 at 6:09 AM, Joerg Roedel jroe...@suse.de wrote:
 Hi Will,

 On Thu, Jul 16, 2015 at 11:23:26AM +0100, Will Deacon wrote:
 On Thu, Jul 16, 2015 at 09:30:43AM +0100, Joerg Roedel wrote:
  +struct of_phandle_args *of_alloc_phandle_args(int size)
  +{
  +   struct of_phandle_args *args;
  +   int e = max(0, size - MAX_PHANDLE_ARGS);
  +
  +   args =  kzalloc(sizeof(struct of_phandle_args) + e * sizeof(uint32_t),
  +   GFP_KERNEL);

 Should you also update args-args_count to reflect the extended array?

 The args_count member just tells us how many of the array elements are
 used and not how many there are. So it doesn't need to be updated here.

 That said, extending the fixed-size array member like this feels a bit
 fragile. Does GCC not complain about out-of-bounds accesses if you
 statically address args-args[MAX_PHANDLE_ARGS]? Admittedly, I can't
 think *why* this would be break (things like additional padding will be
 harmless), but I'm not intimate with the C standard.

 Yeah, I agree, it is not the best possible solution. But this way I
 don't need to update all callers, and thus it works better with our
 development model.

Our development model is not to work-around kernel APIs last time I checked.

 But I am open for suggestions on how to solve this problem better. In
 fact, my main motivation in sending this was to get the discussion about
 an upstreamable solution started :)

 Lets see what the device-tree maintainers have to say.

A good number of callers and all iommu callers loop thru the list of 
phandles which are just open coded ATM. So we should do loop iterators 
here. With iterators, we can do the allocation within the iterators. 
This can be much more efficient as we don't iterate thru the list from 
the start every time. Normally, the list is not big enough to matter, 
but in your case it may be.

I'm thinking something like this untested and not yet compiling patch. It 
still has the abuse of adding onto the end of the of_phandle_args 
struct which I don't really like. We could do a new struct, but I'd like 
to keep this code common.

I also need to refactor the existing code to use 
__of_parse_one_phandle_with_args.

Rob

8
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8b5a187..c1c5a43 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1442,6 +1442,96 @@ void of_print_phandle_args(const char *msg, const struct 
of_phandle_args *args)
printk(\n);
 }
 
+
+static int __of_parse_one_phandle_with_args(const __be32 **list,
+   const char *cells_name,
+   int cell_count,
+   struct of_phandle_args **out_args)
+{
+   struct device_node *node;
+   phandle phandle;
+   struct of_phandle_args *args = *out_args;
+   const __be32 *start_list = *list;
+   u32 i, count = 0;
+   int ret;
+
+   /*
+* If phandle is 0, then it is an empty entry with no
+* arguments.  Skip forward to the next entry.
+*/
+   phandle = be32_to_cpup(*list++);
+   if (phandle) {
+   /*
+* Find the provider node and parse the #*-cells
+* property to determine the argument length.
+*
+* This is not needed if the cell count is hard-coded
+* (i.e. cells_name not set, but cell_count is set),
+* except when we're going to return the found node
+* below.
+*/
+   node = of_find_node_by_phandle(phandle);
+   if (!node)
+   return -ENOENT;
+
+   if (cells_name) {
+   ret = of_property_read_u32(node, cells_name, count);
+   if (ret) {
+   pr_err(could not get %s for %s\n,
+  cells_name, node-full_name);
+   return ret;
+   }
+   } else {
+   count = cell_count;
+   }
+   }
+
+   if (args  WARN_ON(count  MAX_PHANDLE_ARGS))
+   count = MAX_PHANDLE_ARGS;
+
+   if (!args) {
+   args = kzalloc(sizeof(*args) + (count * sizeof(uint32_t))), 
GFP_KERNEL);
+   *out_args = args;
+   }
+   if (!args)
+   return -ENOMEM;
+
+   if (!phandle) {
+   memset(args, 0, sizeof(*args));
+   return -ENOENT;
+   }
+
+   args-np = node;
+   args-val = start_list;
+   args-args_count = count;
+   for (i = 0; i  count; i++)
+   args-args[i] = be32_to_cpup(*list++);
+
+   return 0;
+}
+
+of_phandle_args *of_prop_next_phandle_args(struct property *prop,
+   const char *cells_name,
+

Re: [RFC/PATCH 4/9] of: dma: Make of_dma_deconfigure() public

[Rob Herring]

On Thu, May 14, 2015 at 6:00 PM, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
 As part of moving DMA initializing to probe time the
 of_dma_deconfigure() function will need to be called from different
 source files. Make it public and move it to drivers/of/device.c where
 the of_dma_configure() function is.

 Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com

One minor fix below, but otherwise:

Acked-by: Rob Herring r...@kernel.org

 ---
  drivers/of/device.c   | 12 
  drivers/of/platform.c |  5 -
  include/linux/of_device.h |  3 +++
  3 files changed, 15 insertions(+), 5 deletions(-)

 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index 530aa1ed3e1b..f1b84f464fe1 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -135,6 +135,18 @@ void of_dma_configure(struct device *dev, struct 
 device_node *np)
  }
  EXPORT_SYMBOL_GPL(of_dma_configure);

 +/**
 + * of_dma_deconfigure - Clean up DMA configuration
 + * @dev:   Device for which to clean up DMA configuration
 + *
 + * Clean up all configuration performed by of_dma_configure_ops() and free 
 all
 + * resources that have been allocated.
 + */
 +void of_dma_deconfigure(struct device *dev)
 +{
 +   arch_teardown_dma_ops(dev);
 +}

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

Re: [RFC/PATCH 5/9] of: dma: Split of_configure_dma() into mask and ops configuration

[Rob Herring]

On Thu, May 14, 2015 at 6:00 PM, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
 The of_configure_dma() function configures both the DMA masks and ops.
 Moving DMA ops configuration to probe time would thus also delay
 configuration of the DMA masks, which might not be safe. To avoid issues
 split the configuration in two to allow keeping masks configuration at
 device add time and move ops configuration to device probe time.

Why is it not safe? The probe is deferred before drivers' probe happens.

Rob

 Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
 ---
  drivers/of/device.c   | 48 
 ++-
  drivers/of/of_pci.c   |  3 ++-
  drivers/of/platform.c |  6 --
  include/linux/of_device.h | 11 +--
  4 files changed, 50 insertions(+), 18 deletions(-)

 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index f1b84f464fe1..3cb3f78a6d13 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -70,7 +70,7 @@ int of_device_add(struct platform_device *ofdev)
  }

  /**
 - * of_dma_configure - Setup DMA configuration
 + * of_dma_configure - Setup DMA masks and offset
   * @dev:   Device to apply DMA configuration
   * @np:Pointer to OF node having DMA configuration
   *
 @@ -81,13 +81,11 @@ int of_device_add(struct platform_device *ofdev)
   * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
   * to fix up DMA configuration.
   */
 -void of_dma_configure(struct device *dev, struct device_node *np)
 +void of_dma_configure_masks(struct device *dev, struct device_node *np)
  {
 -   u64 dma_addr, paddr, size;
 -   int ret;
 -   bool coherent;
 +   u64 dma_addr, paddr, size, range_mask;
 unsigned long offset;
 -   struct iommu_ops *iommu;
 +   int ret;

 /*
  * Set default coherent_dma_mask to 32 bit.  Drivers are expected to
 @@ -105,9 +103,10 @@ void of_dma_configure(struct device *dev, struct 
 device_node *np)

 ret = of_dma_get_range(np, dma_addr, paddr, size);
 if (ret  0) {
 -   dma_addr = offset = 0;
 -   size = dev-coherent_dma_mask + 1;
 +   range_mask = dev-coherent_dma_mask + 1;
 +   offset = 0;
 } else {
 +   range_mask = DMA_BIT_MASK(ilog2(dma_addr + size));
 offset = PFN_DOWN(paddr - dma_addr);
 dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
 }
 @@ -118,10 +117,31 @@ void of_dma_configure(struct device *dev, struct 
 device_node *np)
  * Limit coherent and dma mask based on size and default mask
  * set by the driver.
  */
 -   dev-coherent_dma_mask = min(dev-coherent_dma_mask,
 -DMA_BIT_MASK(ilog2(dma_addr + size)));
 -   *dev-dma_mask = min((*dev-dma_mask),
 -DMA_BIT_MASK(ilog2(dma_addr + size)));
 +   dev-coherent_dma_mask = min(dev-coherent_dma_mask, range_mask);
 +   *dev-dma_mask = min((*dev-dma_mask), range_mask);
 +}
 +EXPORT_SYMBOL_GPL(of_dma_configure_masks);
 +
 +/**
 + * of_dma_configure_ops - Setup DMA operations
 + * @dev:   Device to apply DMA configuration
 + * @np:Pointer to OF node having DMA configuration
 + *
 + * Try to get devices's DMA configuration from DT and update it
 + * accordingly.
 + */
 +int of_dma_configure_ops(struct device *dev, struct device_node *np)
 +{
 +   u64 dma_addr, paddr, size;
 +   struct iommu_ops *iommu;
 +   bool coherent;
 +   int ret;
 +
 +   ret = of_dma_get_range(np, dma_addr, paddr, size);
 +   if (ret  0) {
 +   dma_addr = 0;
 +   size = dev-coherent_dma_mask + 1;
 +   }

 coherent = of_dma_is_coherent(np);
 dev_dbg(dev, device is%sdma coherent\n,
 @@ -132,8 +152,10 @@ void of_dma_configure(struct device *dev, struct 
 device_node *np)
 iommu ?   :  not );

 arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
 +
 +   return 0;
  }
 -EXPORT_SYMBOL_GPL(of_dma_configure);
 +EXPORT_SYMBOL_GPL(of_dma_configure_ops);

  /**
   * of_dma_deconfigure - Clean up DMA configuration
 diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
 index 5751dc5b6494..c65803da2067 100644
 --- a/drivers/of/of_pci.c
 +++ b/drivers/of/of_pci.c
 @@ -132,7 +132,8 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
 if (!bridge-parent)
 return;

 -   of_dma_configure(dev, bridge-parent-of_node);
 +   of_dma_configure_masks(dev, bridge-parent-of_node);
 +   of_dma_configure_ops(dev, bridge-parent-of_node);
 pci_put_host_bridge_device(bridge);
  }
  EXPORT_SYMBOL_GPL(of_pci_dma_configure);
 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index 7a660c79ff84..9a29f09b7723 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -177,7 +177,8 @@ static struct 

Re: [RFC/PATCH 3/9] of: dma: Move range size workaround to of_dma_get_range()

[Rob Herring]

On Thu, May 14, 2015 at 6:00 PM, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
 Invalid dma-ranges values should be worked around when retrieving the
 DMA range in of_dma_get_range(), not by all callers of the function.
 This isn't much of a problem now that we have a single caller, but that
 situation will change when moving DMA configuration to device probe
 time.

 Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
 ---
  drivers/of/address.c | 20 ++--
  drivers/of/device.c  | 15 ---

Please use get_maintainers.pl. Anyway, looks fine to me:

Acked-by: Rob Herring r...@kernel.org

Rob

  2 files changed, 18 insertions(+), 17 deletions(-)

 diff --git a/drivers/of/address.c b/drivers/of/address.c
 index 78a7dcbec7d8..75eebd19ebfa 100644
 --- a/drivers/of/address.c
 +++ b/drivers/of/address.c
 @@ -924,8 +924,8 @@ EXPORT_SYMBOL(of_io_request_and_map);
   * CPU addr (phys_addr_t)  : pna cells
   * size: nsize cells
   *
 - * It returns -ENODEV if dma-ranges property was not found
 - * for this device in DT.
 + * Return 0 on success, -ENODEV if the dma-ranges property was not found 
 for
 + * this device in DT, or -EINVAL if the CPU address or size is invalid.
   */
  int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 
 *size)
  {
 @@ -986,6 +986,22 @@ int of_dma_get_range(struct device_node *np, u64 
 *dma_addr, u64 *paddr, u64 *siz
 *dma_addr = dmaaddr;

 *size = of_read_number(ranges + naddr + pna, nsize);
 +   /*
 +* DT nodes sometimes incorrectly set the size as a mask. Work around
 +* those incorrect DT by computing the size as mask + 1.
 +*/
 +   if (*size  1) {
 +   pr_warn(%s: size 0x%llx for dma-range in node(%s) set as 
 mask\n,
 +   __func__, *size, np-full_name);
 +   *size = *size + 1;
 +   }
 +
 +   if (!*size) {
 +   pr_err(%s: invalid size zero for dma-range in node(%s)\n,
 +  __func__, np-full_name);
 +   ret = -EINVAL;
 +   goto out;
 +   }

 pr_debug(dma_addr(%llx) cpu_addr(%llx) size(%llx)\n,
  *dma_addr, *paddr, *size);
 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index 20c1332a0018..530aa1ed3e1b 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -109,21 +109,6 @@ void of_dma_configure(struct device *dev, struct 
 device_node *np)
 size = dev-coherent_dma_mask + 1;
 } else {
 offset = PFN_DOWN(paddr - dma_addr);
 -
 -   /*
 -* Add a work around to treat the size as mask + 1 in case
 -* it is defined in DT as a mask.
 -*/
 -   if (size  1) {
 -   dev_warn(dev, Invalid size 0x%llx for dma-range\n,
 -size);
 -   size = size + 1;
 -   }
 -
 -   if (!size) {
 -   dev_err(dev, Adjusted size 0x%llx invalid\n, size);
 -   return;
 -   }
 dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
 }

 --
 2.3.6


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

[Rob Herring]

On Wed, Jan 28, 2015 at 5:05 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
 On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote:
 On 01/27/2015 06:27 AM, Robin Murphy wrote:
  On 23/01/15 22:32, Murali Karicheri wrote:
  Fix the dma-range size when the DT attribute is missing. i.e set size to
  dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. To detect
  overflow when mask is set to max of u64, add a check, log error and
  return.
  Some platform use mask format for size in DTS. So add a work around to
  catch this and fix.
 
  Cc: Joerg Roedel j...@8bytes.org
  Cc: Grant Likely grant.lik...@linaro.org
  Cc: Rob Herring robh...@kernel.org
  Cc: Bjorn Helgaas bhelg...@google.com
  Cc: Will Deacon will.dea...@arm.com
  Cc: Russell King li...@arm.linux.org.uk
  Cc: Arnd Bergmann a...@arndb.de
  Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
 
  Signed-off-by: Murali Karicheri m-kariche...@ti.com
  ---
  drivers/of/device.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/of/device.c b/drivers/of/device.c
  index 2de320d..0a5ff54 100644
  --- a/drivers/of/device.c
  +++ b/drivers/of/device.c
  @@ -105,12 +105,24 @@ void of_dma_configure(struct device *dev, struct
  device_node *np)
  ret = of_dma_get_range(np, dma_addr, paddr, size);
  if (ret  0) {
  dma_addr = offset = 0;
  - size = dev-coherent_dma_mask;
  + size = dev-coherent_dma_mask + 1;
  } else {
  offset = PFN_DOWN(paddr - dma_addr);
  + /*
  + * Add a work around to treat the size as mask + 1 in case
  + * it is defined in DT as a mask.
  + */
  + if (size  1)
  + size = size + 1;
  dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
  }
 
  + /* if size is 0, we have an overflow of u64 */
  + if (!size) {
  + dev_err(dev, invalid size\n);
  + return;
  + }
  +
 
  This seems potentially fragile to dodgy DTs given that we might also be
  using size to make a mask later. Would it make sense to double-up a
  sanity check as mask-format detection? Something like:
 
  if is_power_of_2(size)
  // use size
  else if is_power_of_2(size + 1)
  // use size + 1
  else
  // cry

 How about having the logic like this?

   ret = of_dma_get_range(np, dma_addr, paddr, size);
   if (ret  0) {
   dma_addr = offset = 0;
   size = dev-coherent_dma_mask + 1;
   } else {
   offset = PFN_DOWN(paddr - dma_addr);
   dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
   }

   if (is_power_of_2(size + 1))
   size = size + 1;
   else if (!is_power_of_2(size))
   {
   dev_err(dev, invalid size\n);
   return;
   }

 In of_dma_configure(), we currently assume that the default coherent
 mask is 32-bit. In this thread:

 http://article.gmane.org/gmane.linux.kernel/1835096

 we talked about setting the coherent mask based on size automatically.
 I'm not sure about the size but I think we can assume is 32-bit mask + 1
 if it is not specified in the DT. Instead of just assuming a default
 mask, let's assume a default size and create the mask based on this
 (untested):

 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index 5b33c6a21807..9ff8d1286b44 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -170,10 +170,10 @@ static void of_dma_configure(struct device *dev)
 struct iommu_ops *iommu;

 /*
 -* Set default dma-mask to 32 bit. Drivers are expected to setup
 -* the correct supported dma_mask.
 +* Set default size to cover the 32-bit. Drivers are expected to setup
 +* the correct size and dma_mask.
  */
 -   dev-coherent_dma_mask = DMA_BIT_MASK(32);
 +   size = 1ULL  32;

 /*
  * Set it to coherent_dma_mask by default if the architecture
 @@ -185,13 +185,24 @@ static void of_dma_configure(struct device *dev)
 ret = of_dma_get_range(dev-of_node, dma_addr, paddr, size);
 if (ret  0) {
 dma_addr = offset = 0;
 -   size = dev-coherent_dma_mask;

Are we assuming dma_addr, paddr and size are not touched on error? If
so, we can get rid of this clause entirely.

 } else {
 offset = PFN_DOWN(paddr - dma_addr);
 dev_dbg(dev, dma_pfn_offset(%#08lx)\n, dev-dma_pfn_offset);
 }
 dev-dma_pfn_offset = offset;

 +   /*
 +* Workaround for DTs setting the size to a mask or 0.
 +*/
 +   if (is_power_of_2(size + 1))
 +   size += 1;

As I mentioned, I think power of 2 is too restrictive (from a DT
perspective even though the kernel may require a power of 2 here for
the mask). Just checking bit0 set should be enough.

Also, we need a WARN here so DTs get fixed.

 +
 +   /*
 +* Coherent DMA masks larger than 32-bit must be explicitly set by the
 +* driver.
 +*/
 +   dev-coherent_dma_mask = min(DMA_BIT_MASK(32), 
 DMA_BIT_MASK(ilog2(size

Re: [PATCH v5 3/8] of: fix size when dma-range is not used

[Rob Herring]

On Tue, Jan 27, 2015 at 3:00 PM, Murali Karicheri m-kariche...@ti.com wrote:
 Fix the dma-range size when the DT attribute is missing. i.e  set size to
 dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add
 code to check invalid values of size configured in DT and log error.

 Cc: Joerg Roedel j...@8bytes.org
 Cc: Grant Likely grant.lik...@linaro.org
 Cc: Rob Herring robh...@kernel.org
 Cc: Bjorn Helgaas bhelg...@google.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com

 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/of/device.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index 2de320d..17504f4 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -105,12 +105,19 @@ void of_dma_configure(struct device *dev, struct 
 device_node *np)
 ret = of_dma_get_range(np, dma_addr, paddr, size);
 if (ret  0) {
 dma_addr = offset = 0;
 -   size = dev-coherent_dma_mask;
 +   size = dev-coherent_dma_mask + 1;

This is fine since coherent_dma_mask will always be 4G - 1 in this case.

 } else {
 offset = PFN_DOWN(paddr - dma_addr);
 dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
 }

 +   if (is_power_of_2(size + 1))
 +   size = size + 1;
 +   else if (!is_power_of_2(size)) {
 +   dev_err(dev, invalid size\n);
 +   return;

I think this is too restrictive. I think checking bit 0 is 1 is enough
to tell the size is a mask.

I would like it to be a WARN if detected and just add 1.

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

Re: [PATCH v5 1/8] of: iommu: add ptr to OF node arg to of_iommu_configure()

[Rob Herring]

On Tue, Jan 27, 2015 at 2:59 PM, Murali Karicheri m-kariche...@ti.com wrote:
 Function of_iommu_configure() is called from of_dma_configure() to
 setup iommu ops using DT property. This API is currently used for
 platform devices for which DMA configuration (including iommu ops)
 may come from device's parent. To extend this functionality for PCI
 devices, this API need to take a parent node ptr as an argument
 instead of assuming device's parent. This is needed since for PCI, the
 dma configuration may be defined in the DT node of the root bus bridge's
 parent device. Currently only dma-range is used for PCI and iommu is not
 supported. So return error if the device is PCI.

 Cc: Joerg Roedel j...@8bytes.org
 Cc: Grant Likely grant.lik...@linaro.org
 Cc: Rob Herring robh...@kernel.org

Acked-by: Rob Herring r...@kernel.org

 Cc: Will Deacon will.dea...@arm.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com

 Acked-by: Bjorn Helgaas bhelg...@google.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/iommu/of_iommu.c |   10 --
  drivers/of/platform.c|2 +-
  include/linux/of_iommu.h |6 --
  3 files changed, 13 insertions(+), 5 deletions(-)

 diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
 index af1dc6a..439235b 100644
 --- a/drivers/iommu/of_iommu.c
 +++ b/drivers/iommu/of_iommu.c
 @@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct device_node 
 *np)
 return ops;
  }

 -struct iommu_ops *of_iommu_configure(struct device *dev)
 +struct iommu_ops *of_iommu_configure(struct device *dev,
 +struct device_node *iommu_np)
  {
 struct of_phandle_args iommu_spec;
 struct device_node *np;
 struct iommu_ops *ops = NULL;
 int idx = 0;

 +   if (dev_is_pci(dev)) {
 +   dev_err(dev, iommu is currently not supported for PCI\n);
 +   return NULL;
 +   }
 +
 /*
  * We don't currently walk up the tree looking for a parent IOMMU.
  * See the `Notes:' section of
  * Documentation/devicetree/bindings/iommu/iommu.txt
  */
 -   while (!of_parse_phandle_with_args(dev-of_node, iommus,
 +   while (!of_parse_phandle_with_args(iommu_np, iommus,
#iommu-cells, idx,
iommu_spec)) {
 np = iommu_spec.np;
 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index b0d50d7..d3f3988 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -196,7 +196,7 @@ static void of_dma_configure(struct device *dev)
 dev_dbg(dev, device is%sdma coherent\n,
 coherent ?   :  not );

 -   iommu = of_iommu_configure(dev);
 +   iommu = of_iommu_configure(dev, dev-of_node);
 dev_dbg(dev, device is%sbehind an iommu\n,
 iommu ?   :  not );

 diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
 index 16c7554..a97e5bd 100644
 --- a/include/linux/of_iommu.h
 +++ b/include/linux/of_iommu.h
 @@ -12,7 +12,8 @@ extern int of_get_dma_window(struct device_node *dn, const 
 char *prefix,
  size_t *size);

  extern void of_iommu_init(void);
 -extern struct iommu_ops *of_iommu_configure(struct device *dev);
 +extern struct iommu_ops *of_iommu_configure(struct device *dev,
 +   struct device_node *iommu_np);

  #else

 @@ -24,7 +25,8 @@ static inline int of_get_dma_window(struct device_node *dn, 
 const char *prefix,
  }

  static inline void of_iommu_init(void) { }
 -static inline struct iommu_ops *of_iommu_configure(struct device *dev)
 +static inline struct iommu_ops *of_iommu_configure(struct device *dev,
 +struct device_node *iommu_np)
  {
 return NULL;
  }
 --
 1.7.9.5

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

Re: [PATCH v5 5/8] of/pci: add of_pci_dma_configure() update dma configuration

[Rob Herring]

On Tue, Jan 27, 2015 at 3:00 PM, Murali Karicheri m-kariche...@ti.com wrote:
 Add of_pci_dma_configure() to allow updating the dma configuration
 of the pci device using the configuration from DT of the parent of
 the root bridge device. Use the newly added APIs
 pci_get/put_host_bridge_device() for implementing this.

 Cc: Joerg Roedel j...@8bytes.org
 Cc: Grant Likely grant.lik...@linaro.org
 Cc: Rob Herring robh...@kernel.org

Acked-by: Rob Herring r...@kernel.org

 Cc: Will Deacon will.dea...@arm.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com

 Acked-by: Bjorn Helgaas bhelg...@google.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/of/of_pci.c|   19 +++
  include/linux/of_pci.h |5 +
  2 files changed, 24 insertions(+)

 diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
 index 88471d3..0f1dd0b 100644
 --- a/drivers/of/of_pci.c
 +++ b/drivers/of/of_pci.c
 @@ -2,6 +2,7 @@
  #include linux/export.h
  #include linux/of.h
  #include linux/of_address.h
 +#include linux/of_device.h
  #include linux/of_pci.h
  #include linux/slab.h

 @@ -229,6 +230,24 @@ parse_failed:
 return err;
  }
  EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
 +
 +/**
 + * of_pci_dma_configure - Setup DMA configuration
 + * @dev: ptr to pci_dev struct of the pci device
 + *
 + * Function to update PCI devices's DMA configuration using the same
 + * info from the OF node of root host bridge's parent.
 + */
 +void of_pci_dma_configure(struct pci_dev *pci_dev)
 +{
 +   struct device *dev = pci_dev-dev;
 +   struct device *bridge = pci_get_host_bridge_device(pci_dev);
 +
 +   of_dma_configure(dev, bridge-parent-of_node);
 +   pci_put_host_bridge_device(bridge);
 +}
 +EXPORT_SYMBOL_GPL(of_pci_dma_configure);
 +
  #endif /* CONFIG_OF_ADDRESS */

  #ifdef CONFIG_PCI_MSI
 diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
 index ce0e5ab..8f1741f 100644
 --- a/include/linux/of_pci.h
 +++ b/include/linux/of_pci.h
 @@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
  int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
  int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
  int of_get_pci_domain_nr(struct device_node *node);
 +void of_pci_dma_configure(struct pci_dev *pci_dev);
  #else
  static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct 
 of_phandle_args *out_irq)
  {
 @@ -50,6 +51,10 @@ of_get_pci_domain_nr(struct device_node *node)
  {
 return -1;
  }
 +
 +static inline void of_pci_dma_configure(struct pci_dev *pci_dev)
 +{
 +}
  #endif

  #if defined(CONFIG_OF_ADDRESS)
 --
 1.7.9.5

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

Re: [PATCH v3 2/4] of: move of_dma_configure() to device, c to help re-use

[Rob Herring]

On Fri, Jan 23, 2015 at 12:19 PM, Murali Karicheri m-kariche...@ti.com wrote:
 On 01/09/2015 10:34 AM, Rob Herring wrote:

 On Thu, Jan 8, 2015 at 4:24 PM, Arnd Bergmanna...@arndb.de  wrote:

 On Thursday 08 January 2015 14:26:36 Murali Karicheri wrote:

 On 01/08/2015 03:40 AM, Arnd Bergmann wrote:

 On Wednesday 07 January 2015 17:37:56 Rob Herring wrote:

 On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicherim-kariche...@ti.com
 wrote:

 +   ret = of_dma_get_range(np,dma_addr,paddr,size);
 +   if (ret   0) {
 +   dma_addr = offset = 0;
 +   size = dev-coherent_dma_mask + 1;


 If coherent_dma_mask is DMA_BIT_MASK(64), then you will overflow and
 have a size of 0. There may also be a problem when the mask is only
 32-bit type.


 The mask is always a 64-bit type, it's not optional. But you are right,
 the 64-bit mask case is broken, so I guess we have to fix it
 differently
 by always passing the smaller value into arch_setup_dma_ops and
 adapting that function instead.

 Arnd,

 What is the smaller value you are referring to in the below code?
 between *dev-dma_mask and size from DT? But overflow can still happen
 when size is to be calculated in arch_setup_dma_ops() for Non DT case or
 when DT size is configured to be equivalent of DMA_BIT_MASK(64) + 1. Can
 we discuss the code change you have in mind when you get a chance?


 I meant changing every function that the size values gets passed into
 to take a mask like 0x instead of a size like 0x1, so
 we can represent a 64-bit capable bus correctly.


 Or you could special case a size of 0 to mean all/max? I'm not sure if
 we need to handle size=0 for other reasons beyond just wrong DT data.

 This means we also need to adapt the value returned from
 of_dma_get_range.
 A minor complication here is that the DT properties sometimes already
 contain the mask value, in particular when we want to represent a
 full mapping like

  bus {
  #address-cells =1;
  #size-cells =1;
  dma-ranges =0 0 0x; /* all 4 GB,
 DMA_BIT_MASK(32) */


 This is wrong though, right? The DT should be size. Certainly, this
 could be a valid size, but that would not make the mask 0xfffe. We
 would still want it to be 0x.

 We could do a fixup for these cases adding 1 if bit 0 is set (or not
 subtracting 1 if we want the mask).

 Rob

 Arnd, Rob, et all,

 Do we have preference one way or other for the size format? If we need to
 follow the mask format, all of the calling functions below and the
 arm_iommu_create_mapping() has to change as well to use this changed format.

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c:mapping =
 arm_iommu_create_mapping(platform_bus_type, 0x,
 drivers/gpu/drm/exynos/exynos_drm_iommu.c:  mapping =
 arm_iommu_create_mapping(platform_bus_type, priv-da_start,
 drivers/media/platform/omap3isp/isp.c:  mapping =
 arm_iommu_create_mapping(platform_bus_type, SZ_1G, SZ_2G);
 drivers/iommu/shmobile-iommu.c: mapping =
 arm_iommu_create_mapping(platform_bus_type, 0,
 drivers/iommu/ipmmu-vmsa.c: mapping =
 arm_iommu_create_mapping(platform_bus_type,

 So IMO, keeping current convention of size and taking care of exception in
 DT handling is the right thing to do instead of changing all of the above
 functions. i.e in of_dma_configure(), if DT provide a mask for size (lsb
 set), we  will check that and add 1 to it. Only case in DTS that I can see
 this usage is

 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi:   dma-ranges = 0x80
 0x0 0x80 0x0 0x7f 0x;
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi:   dma-ranges =
 0x4300 0x80 0x0 0x80 0x0 0x7f 0x;

This should be fixed regardless. I doubt anyone is worried about 512GB
quite yet.

 This logic should take care of setting the size to ox80_ for these
 cases. if dma_coherent_mask is set to max of u64, then this will result in a
 zero size (both DT case and non DT case). So treat a size of zero as error
 being overflow.

I think this would work, but I really need to see patches.

 Also arm_iommu_create_mapping() currently accept a size of type size_t which
 means, this function expect the size to be max of 0x. So in
 arm_setup_iommu_dma_ops(), we need to check if size if 0x and
 return an error. If in future this function support u64 for size, this check
 can be removed.

The aim is to get rid of this function I believe.

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

Re: [PATCH v3 2/4] of: move of_dma_configure() to device, c to help re-use

[Rob Herring]

On Thu, Jan 8, 2015 at 4:24 PM, Arnd Bergmann a...@arndb.de wrote:
 On Thursday 08 January 2015 14:26:36 Murali Karicheri wrote:
 On 01/08/2015 03:40 AM, Arnd Bergmann wrote:
  On Wednesday 07 January 2015 17:37:56 Rob Herring wrote:
  On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicherim-kariche...@ti.com  
  wrote:
 
  +   ret = of_dma_get_range(np,dma_addr,paddr,size);
  +   if (ret  0) {
  +   dma_addr = offset = 0;
  +   size = dev-coherent_dma_mask + 1;
 
  If coherent_dma_mask is DMA_BIT_MASK(64), then you will overflow and
  have a size of 0. There may also be a problem when the mask is only
  32-bit type.
 
  The mask is always a 64-bit type, it's not optional. But you are right,
  the 64-bit mask case is broken, so I guess we have to fix it differently
  by always passing the smaller value into arch_setup_dma_ops and
  adapting that function instead.
 Arnd,

 What is the smaller value you are referring to in the below code?
 between *dev-dma_mask and size from DT? But overflow can still happen
 when size is to be calculated in arch_setup_dma_ops() for Non DT case or
 when DT size is configured to be equivalent of DMA_BIT_MASK(64) + 1. Can
 we discuss the code change you have in mind when you get a chance?

 I meant changing every function that the size values gets passed into
 to take a mask like 0x instead of a size like 0x1, so
 we can represent a 64-bit capable bus correctly.

Or you could special case a size of 0 to mean all/max? I'm not sure if
we need to handle size=0 for other reasons beyond just wrong DT data.

 This means we also need to adapt the value returned from of_dma_get_range.
 A minor complication here is that the DT properties sometimes already
 contain the mask value, in particular when we want to represent a
 full mapping like

 bus {
 #address-cells = 1;
 #size-cells = 1;
 dma-ranges = 0 0 0x; /* all 4 GB, DMA_BIT_MASK(32) 
 */

This is wrong though, right? The DT should be size. Certainly, this
could be a valid size, but that would not make the mask 0xfffe. We
would still want it to be 0x.

We could do a fixup for these cases adding 1 if bit 0 is set (or not
subtracting 1 if we want the mask).

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

Re: [PATCH] iommu/arm-smmu: don't touch the secure STLBIALL register

[Rob Herring]

+Andreas

On Wed, Jan 7, 2015 at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
 On Wed, Jan 07, 2015 at 06:35:41PM +, Mitchel Humpherys wrote:
 On Wed, Jan 07 2015 at 10:04:20 AM, Will Deacon will.dea...@arm.com wrote:
  On Wed, Jan 07, 2015 at 05:52:46PM +, Mitchel Humpherys wrote:
  On Wed, Jan 07 2015 at 02:13:00 AM, Will Deacon will.dea...@arm.com 
  wrote:
   If would be better to check for the ARM_SMMU_OPT_SECURE_CFG_ACCESS 
   feature
   and, if it's set then zero ARM_SMMU_GR0_STLBIALL at the correct address
   otherwise do the ARM_SMMU_GR0_TLBIALLH and ARM_SMMU_GR0_TLBIALLNSNH.
 
  I'm confused.  The problem I'm addressing here is that we're touching a
  register that's marked as secure only, which causes our system to
  crash.  Why would we ever want to touch a secure only register, calxeda
  workaround or not?
 
  Because I think the way the SMMU is wired for Calxeda is that the CPU can
  only see the secure side of the register interface, so the only way to nuke
  the whole TLB would be to use ARM_SMMU_GR0_STLBIALL.

 Still not sure I understand what the correct address is for STLBIALL
 on Calxeda (i.e. whether or not we need to use ARM_SMMU_GR0_NS), but
 something like:

 Hehe, I wasn't actually expecting a patch, but thanks!

 -- 8 --
 Subject: [PATCH v2] iommu/arm-smmu: don't touch the secure STLBIALL register

 Currently we do a STLBIALL when we initialize the SMMU.  However, on
 systems with sane secure
 configurations (i.e. !ARM_SMMU_OPT_SECURE_CFG_ACCESS) that register is
 not supposed to be touched and is marked as Secure only in the spec.
 Touching it results in a crash on those platforms.  However, on
 platforms with ARM_SMMU_OPT_SECURE_CFG_ACCESS it's the only way to nuke
 the whole TLB, so leave it in for them but rip it out for everyone else.

 Signed-off-by: Mitchel Humpherys mitch...@codeaurora.org
 ---
  drivers/iommu/arm-smmu.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

 diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
 index 60558f794922..d4c149d83f3d 100644
 --- a/drivers/iommu/arm-smmu.c
 +++ b/drivers/iommu/arm-smmu.c
 @@ -1686,9 +1686,12 @@ static void arm_smmu_device_reset(struct 
 arm_smmu_device *smmu)
   }

   /* Invalidate the TLB, just in case */
 - writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
 - writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH);
 - writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLNSNH);
 + if (smmu-options  ARM_SMMU_OPT_SECURE_CFG_ACCESS) {
 + writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);

 Right, so this is the bit where we'd need some Calxeda information about
 whether or not to subtract 0x400 from gr0_base or not.

Beats me. I don't recall any configuration option here. The binding
only has a single address. Maybe Andreas remembers.

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

Re: [PATCH v3 1/4] of: iommu: add ptr to OF node arg to of_iommu_configure()

[Rob Herring]

On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri m-kariche...@ti.com wrote:
 Function of_iommu_configure() is called from of_dma_configure() to
 setup iommu ops using DT property. This API is currently used for
 platform devices for which DMA configuration (including iommu ops)
 may come from device's parent. To extend this functionality for PCI
 devices, this API need to take a parent node ptr as an argument
 instead of assuming device's parent. This is needed since for PCI, the
 dma configuration may be defined in the DT node of the root bus bridge's
 parent device. Currently only dma-range is used for PCI and iommu is not
 supported. So return error if the device is PCI.

 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
  drivers/iommu/of_iommu.c |   10 --
  drivers/of/platform.c|2 +-
  include/linux/of_iommu.h |6 --
  3 files changed, 13 insertions(+), 5 deletions(-)

 diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
 index af1dc6a..396bc77 100644
 --- a/drivers/iommu/of_iommu.c
 +++ b/drivers/iommu/of_iommu.c
 @@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct device_node 
 *np)
 return ops;
  }

 -struct iommu_ops *of_iommu_configure(struct device *dev)
 +struct iommu_ops *of_iommu_configure(struct device *dev,
 +struct device_node *node)

You use node here, but np in the declaration. However...

  {
 struct of_phandle_args iommu_spec;
 struct device_node *np;

We also have np here. I would suggest we rename this to iommu_node or
iommu_np to be clear which one this is for.

 struct iommu_ops *ops = NULL;
 int idx = 0;

 +   if (dev_is_pci(dev)) {
 +   dev_err(dev, iommu is currently not supported for PCI\n);
 +   return NULL;
 +   }
 +
 /*
  * We don't currently walk up the tree looking for a parent IOMMU.
  * See the `Notes:' section of
  * Documentation/devicetree/bindings/iommu/iommu.txt
  */
 -   while (!of_parse_phandle_with_args(dev-of_node, iommus,
 +   while (!of_parse_phandle_with_args(node, iommus,
#iommu-cells, idx,
iommu_spec)) {
 np = iommu_spec.np;
 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index a54ec10..7675b79 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -196,7 +196,7 @@ static void of_dma_configure(struct device *dev)
 dev_dbg(dev, device is%sdma coherent\n,
 coherent ?   :  not );

 -   iommu = of_iommu_configure(dev);
 +   iommu = of_iommu_configure(dev, dev-of_node);
 dev_dbg(dev, device is%sbehind an iommu\n,
 iommu ?   :  not );

 diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
 index 16c7554..3258cbb 100644
 --- a/include/linux/of_iommu.h
 +++ b/include/linux/of_iommu.h
 @@ -12,7 +12,8 @@ extern int of_get_dma_window(struct device_node *dn, const 
 char *prefix,
  size_t *size);

  extern void of_iommu_init(void);
 -extern struct iommu_ops *of_iommu_configure(struct device *dev);
 +extern struct iommu_ops *of_iommu_configure(struct device *dev,
 +   struct device_node *np);

  #else

 @@ -24,7 +25,8 @@ static inline int of_get_dma_window(struct device_node *dn, 
 const char *prefix,
  }

  static inline void of_iommu_init(void) { }
 -static inline struct iommu_ops *of_iommu_configure(struct device *dev)
 +static inline struct iommu_ops *of_iommu_configure(struct device *dev,
 +struct device_node *np)
  {
 return NULL;
  }
 --
 1.7.9.5

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

Re: [PATCH v3 2/4] of: move of_dma_configure() to device, c to help re-use

[Rob Herring]

On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri m-kariche...@ti.com wrote:
 Move of_dma_configure() to device.c so that same function can be re-used
 for PCI devices to obtain DMA configuration from DT. Also add a second
 argument so that for PCI, DT node of root bus host bridge can be used to
 obtain the DMA configuration for the slave PCI device. Additionally fix
 the dma-range size when the DT attribute is missing. i.e  set size to
 dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask.

Additionally is a red flag for put in another patch. There is an issue
I think as well.

 +   ret = of_dma_get_range(np, dma_addr, paddr, size);
 +   if (ret  0) {
 +   dma_addr = offset = 0;
 +   size = dev-coherent_dma_mask + 1;

If coherent_dma_mask is DMA_BIT_MASK(64), then you will overflow and
have a size of 0. There may also be a problem when the mask is only
32-bit type.

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

Re: [PATCH] iommu/arm-smmu: don't touch the secure STLBIALL register

[Rob Herring]

On Tue, Jan 6, 2015 at 2:16 PM, Mitchel Humpherys
mitch...@codeaurora.org wrote:
 On Tue, Jan 06 2015 at 06:15:07 AM, Will Deacon will.dea...@arm.com wrote:
  /* Invalidate the TLB, just in case */
 -writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
  writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH);
  writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLNSNH);

 I was slightly worried that this would break the Calxeda implementation
 with ARM_SMMU_OPT_SECURE_CFG_ACCESS, but actually these registers aren't
 even aliased there so I think there's a bigger bug for them.

 Anyway, given that their hardware has gone the way of the dodo, I'll take
 the patch as-is unless you have any further comments?

 Will

 Yeah I agree that this shouldn't affect the (now defunct) Calxeda
 implementation.  I've tested this on some hardware here and we crash
 when we touch that register since it's secure-only (not banked, as you
 mentioned).

It's not quite dead:

http://www.eweek.com/servers/calxedas-arm-based-server-chips-re-emerge-with-new-company.html

But AFAIK, production systems don't enable the SMMU, but someone could
still want to at some point. A note in the commit log here would be
nice so it gets recorded.

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

Re: [PATCH v6 2/8] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops

[Rob Herring]

On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
 set_arch_dma_coherent_ops is called from of_dma_configure in order to
 swizzle the architectural dma-mapping functions over to a cache-coherent
 implementation. This is currently implemented only for ARM.

 In anticipation of re-using this mechanism for IOMMU-backed dma-mapping
 ops too, this patch replaces the function with a broader
 arch_setup_dma_ops callback which will be extended in future.

 Acked-by: Arnd Bergmann a...@arndb.de
 Acked-by: Marek Szyprowski m.szyprow...@samsung.com
 Tested-by: Robin Murphy robin.mur...@arm.com
 Signed-off-by: Will Deacon will.dea...@arm.com

One comment below, but for the DT parts:

Acked-by: Rob Herring r...@kernel.org

 ---
  arch/arm/include/asm/dma-mapping.h |  8 
  drivers/of/platform.c  | 31 +--
  include/linux/dma-mapping.h|  7 ++-
  3 files changed, 19 insertions(+), 27 deletions(-)

 diff --git a/arch/arm/include/asm/dma-mapping.h 
 b/arch/arm/include/asm/dma-mapping.h
 index 85738b200023..dc3420e77758 100644
 --- a/arch/arm/include/asm/dma-mapping.h
 +++ b/arch/arm/include/asm/dma-mapping.h
 @@ -121,12 +121,12 @@ static inline unsigned long dma_max_pfn(struct device 
 *dev)
  }
  #define dma_max_pfn(dev) dma_max_pfn(dev)

 -static inline int set_arch_dma_coherent_ops(struct device *dev)
 +static inline void arch_setup_dma_ops(struct device *dev, bool coherent)
  {
 -   set_dma_ops(dev, arm_coherent_dma_ops);
 -   return 0;
 +   if (coherent)
 +   set_dma_ops(dev, arm_coherent_dma_ops);
  }
 -#define set_arch_dma_coherent_ops(dev) set_arch_dma_coherent_ops(dev)
 +#define arch_setup_dma_ops arch_setup_dma_ops

  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
  {
 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index 3b64d0bf5bba..ff1f4e9afccb 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -164,6 +164,8 @@ static void of_dma_configure(struct device *dev)
  {
 u64 dma_addr, paddr, size;
 int ret;
 +   bool coherent;
 +   unsigned long offset;

 /*
  * Set default dma-mask to 32 bit. Drivers are expected to setup
 @@ -178,28 +180,21 @@ static void of_dma_configure(struct device *dev)
 if (!dev-dma_mask)
 dev-dma_mask = dev-coherent_dma_mask;

 -   /*
 -* if dma-coherent property exist, call arch hook to setup
 -* dma coherent operations.
 -*/
 -   if (of_dma_is_coherent(dev-of_node)) {
 -   set_arch_dma_coherent_ops(dev);
 -   dev_dbg(dev, device is dma coherent\n);
 -   }
 -
 -   /*
 -* if dma-ranges property doesn't exist - just return else
 -* setup the dma offset
 -*/
 ret = of_dma_get_range(dev-of_node, dma_addr, paddr, size);
 if (ret  0) {
 -   dev_dbg(dev, no dma range information to setup\n);
 -   return;
 +   dma_addr = offset = 0;
 +   size = dev-coherent_dma_mask;

It looks like size is not used.

 +   } else {
 +   offset = PFN_DOWN(paddr - dma_addr);
 +   dev_dbg(dev, dma_pfn_offset(%#08lx)\n, dev-dma_pfn_offset);
 }
 +   dev-dma_pfn_offset = offset;
 +
 +   coherent = of_dma_is_coherent(dev-of_node);
 +   dev_dbg(dev, device is%sdma coherent\n,
 +   coherent ?   :  not );

 -   /* DMA ranges found. Calculate and set dma_pfn_offset */
 -   dev-dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
 -   dev_dbg(dev, dma_pfn_offset(%#08lx)\n, dev-dma_pfn_offset);
 +   arch_setup_dma_ops(dev, coherent);
  }

  /**
 diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
 index d5d388160f42..8a1560f95d4a 100644
 --- a/include/linux/dma-mapping.h
 +++ b/include/linux/dma-mapping.h
 @@ -129,11 +129,8 @@ static inline int dma_coerce_mask_and_coherent(struct 
 device *dev, u64 mask)

  extern u64 dma_get_required_mask(struct device *dev);

 -#ifndef set_arch_dma_coherent_ops
 -static inline int set_arch_dma_coherent_ops(struct device *dev)
 -{
 -   return 0;
 -}
 +#ifndef arch_setup_dma_ops
 +static inline void arch_setup_dma_ops(struct device *dev, bool coherent) { }
  #endif

  static inline unsigned int dma_get_max_seg_size(struct device *dev)
 --
 2.1.1


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure

[Rob Herring]

On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
 This patch extends of_dma_configure so that it sets up the IOMMU for a
 device, as well as the coherent/non-coherent DMA mapping ops.

 Acked-by: Arnd Bergmann a...@arndb.de
 Acked-by: Marek Szyprowski m.szyprow...@samsung.com
 Tested-by: Robin Murphy robin.mur...@arm.com
 Signed-off-by: Will Deacon will.dea...@arm.com

Acked-by: Rob Herring r...@kernel.org

 ---
  arch/arm/include/asm/dma-mapping.h |  4 +++-
  drivers/of/platform.c  | 21 ++---
  include/linux/dma-mapping.h|  8 +++-
  3 files changed, 24 insertions(+), 9 deletions(-)

 diff --git a/arch/arm/include/asm/dma-mapping.h 
 b/arch/arm/include/asm/dma-mapping.h
 index dc3420e77758..f3c0d953f6a2 100644
 --- a/arch/arm/include/asm/dma-mapping.h
 +++ b/arch/arm/include/asm/dma-mapping.h
 @@ -121,7 +121,9 @@ static inline unsigned long dma_max_pfn(struct device 
 *dev)
  }
  #define dma_max_pfn(dev) dma_max_pfn(dev)

 -static inline void arch_setup_dma_ops(struct device *dev, bool coherent)
 +static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base,
 + u64 size, struct iommu_ops *iommu,
 + bool coherent)
  {
 if (coherent)
 set_dma_ops(dev, arm_coherent_dma_ops);
 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index ff1f4e9afccb..b89caf8c7586 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -19,6 +19,7 @@
  #include linux/slab.h
  #include linux/of_address.h
  #include linux/of_device.h
 +#include linux/of_iommu.h
  #include linux/of_irq.h
  #include linux/of_platform.h
  #include linux/platform_device.h
 @@ -166,6 +167,7 @@ static void of_dma_configure(struct device *dev)
 int ret;
 bool coherent;
 unsigned long offset;
 +   struct iommu_ops *iommu;

 /*
  * Set default dma-mask to 32 bit. Drivers are expected to setup
 @@ -194,7 +196,16 @@ static void of_dma_configure(struct device *dev)
 dev_dbg(dev, device is%sdma coherent\n,
 coherent ?   :  not );

 -   arch_setup_dma_ops(dev, coherent);
 +   iommu = of_iommu_configure(dev);
 +   dev_dbg(dev, device is%sbehind an iommu\n,
 +   iommu ?   :  not );
 +
 +   arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
 +}
 +
 +static void of_dma_deconfigure(struct device *dev)
 +{
 +   arch_teardown_dma_ops(dev);
  }

  /**
 @@ -223,16 +234,12 @@ static struct platform_device 
 *of_platform_device_create_pdata(
 if (!dev)
 goto err_clear_flag;

 -   of_dma_configure(dev-dev);
 dev-dev.bus = platform_bus_type;
 dev-dev.platform_data = platform_data;
 -
 -   /* We do not fill the DMA ops for platform devices by default.
 -* This is currently the responsibility of the platform code
 -* to do such, possibly using a device notifier
 -*/
 +   of_dma_configure(dev-dev);

 if (of_device_add(dev) != 0) {
 +   of_dma_deconfigure(dev-dev);
 platform_device_put(dev);
 goto err_clear_flag;
 }
 diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
 index 8a1560f95d4a..c3007cb4bfa6 100644
 --- a/include/linux/dma-mapping.h
 +++ b/include/linux/dma-mapping.h
 @@ -130,7 +130,13 @@ static inline int dma_coerce_mask_and_coherent(struct 
 device *dev, u64 mask)
  extern u64 dma_get_required_mask(struct device *dev);

  #ifndef arch_setup_dma_ops
 -static inline void arch_setup_dma_ops(struct device *dev, bool coherent) { }
 +static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base,
 + u64 size, struct iommu_ops *iommu,
 + bool coherent) { }
 +#endif
 +
 +#ifndef arch_teardown_dma_ops
 +static inline void arch_teardown_dma_ops(struct device *dev) { }
  #endif

  static inline unsigned int dma_get_max_seg_size(struct device *dev)
 --
 2.1.1


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers

[Rob Herring]

Adding Grant and Pantelis...

On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
 IOMMU drivers must be initialised before any of their upstream devices,
 otherwise the relevant iommu_ops won't be configured for the bus in
 question. To solve this, a number of IOMMU drivers use initcalls to
 initialise the driver before anything has a chance to be probed.

 Whilst this solves the immediate problem, it leaves the job of probing
 the IOMMU completely separate from the iommu_ops to configure the IOMMU,
 which are called on a per-bus basis and require the driver to figure out
 exactly which instance of the IOMMU is being requested. In particular,
 the add_device callback simply passes a struct device to the driver,
 which then has to parse firmware tables or probe buses to identify the
 relevant IOMMU instance.

 This patch takes the first step in addressing this problem by adding an
 early initialisation pass for IOMMU drivers, giving them the ability to
 store some per-instance data in their iommu_ops structure and store that
 in their of_node. This can later be used when parsing OF masters to
 identify the IOMMU instance in question.

 Acked-by: Arnd Bergmann a...@arndb.de
 Acked-by: Joerg Roedel jroe...@suse.de
 Acked-by: Marek Szyprowski m.szyprow...@samsung.com
 Tested-by: Robin Murphy robin.mur...@arm.com
 Signed-off-by: Will Deacon will.dea...@arm.com
 ---
  drivers/iommu/of_iommu.c  | 17 +
  include/asm-generic/vmlinux.lds.h |  2 ++
  include/linux/iommu.h |  2 ++
  include/linux/of_iommu.h  | 25 +
  4 files changed, 46 insertions(+)

 diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
 index e550ccb7634e..89b903406968 100644
 --- a/drivers/iommu/of_iommu.c
 +++ b/drivers/iommu/of_iommu.c
 @@ -22,6 +22,9 @@
  #include linux/of.h
  #include linux/of_iommu.h

 +static const struct of_device_id __iommu_of_table_sentinel
 +   __used __section(__iommu_of_table_end);
 +
  /**
   * of_get_dma_window - Parse *dma-window property and returns 0 if found.
   *
 @@ -89,3 +92,17 @@ int of_get_dma_window(struct device_node *dn, const char 
 *prefix, int index,
 return 0;
  }
  EXPORT_SYMBOL_GPL(of_get_dma_window);
 +
 +void __init of_iommu_init(void)
 +{
 +   struct device_node *np;
 +   const struct of_device_id *match, *matches = __iommu_of_table;
 +
 +   for_each_matching_node_and_match(np, matches, match) {
 +   const of_iommu_init_fn init_fn = match-data;
 +
 +   if (init_fn(np))
 +   pr_err(Failed to initialise IOMMU %s\n,
 +   of_node_full_name(np));
 +   }
 +}
 diff --git a/include/asm-generic/vmlinux.lds.h 
 b/include/asm-generic/vmlinux.lds.h
 index aa70cbda327c..bee5d683074d 100644
 --- a/include/asm-generic/vmlinux.lds.h
 +++ b/include/asm-generic/vmlinux.lds.h
 @@ -164,6 +164,7 @@
  #define CLKSRC_OF_TABLES() OF_TABLE(CONFIG_CLKSRC_OF, clksrc)
  #define IRQCHIP_OF_MATCH_TABLE() OF_TABLE(CONFIG_IRQCHIP, irqchip)
  #define CLK_OF_TABLES()OF_TABLE(CONFIG_COMMON_CLK, clk)
 +#define IOMMU_OF_TABLES()  OF_TABLE(CONFIG_OF_IOMMU, iommu)
  #define RESERVEDMEM_OF_TABLES()OF_TABLE(CONFIG_OF_RESERVED_MEM, 
 reservedmem)
  #define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_method)
  #define EARLYCON_OF_TABLES()   OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
 @@ -497,6 +498,7 @@
 CLK_OF_TABLES() \
 RESERVEDMEM_OF_TABLES() \
 CLKSRC_OF_TABLES()  \
 +   IOMMU_OF_TABLES()   \
 CPU_METHOD_OF_TABLES()  \
 KERNEL_DTB()\
 IRQCHIP_OF_MATCH_TABLE()\
 diff --git a/include/linux/iommu.h b/include/linux/iommu.h
 index e6a7c9ff72f2..7b83f9f8e11d 100644
 --- a/include/linux/iommu.h
 +++ b/include/linux/iommu.h
 @@ -103,6 +103,7 @@ enum iommu_attr {
   * @domain_get_attr: Query domain attributes
   * @domain_set_attr: Change domain attributes
   * @pgsize_bitmap: bitmap of supported page sizes
 + * @priv: per-instance data private to the iommu driver
   */
  struct iommu_ops {
 bool (*capable)(enum iommu_cap);
 @@ -133,6 +134,7 @@ struct iommu_ops {
 u32 (*domain_get_windows)(struct iommu_domain *domain);

 unsigned long pgsize_bitmap;
 +   void *priv;
  };

  #define IOMMU_GROUP_NOTIFY_ADD_DEVICE  1 /* Device added */
 diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
 index 51a560f34bca..5762cdc8effe 100644
 --- a/include/linux/of_iommu.h
 +++ b/include/linux/of_iommu.h
 @@ -1,12 +1,17 @@
  #ifndef __OF_IOMMU_H
  #define __OF_IOMMU_H

 +#include linux/iommu.h
 +#include linux/of.h
 +
  

Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

[Rob Herring]

On Wed, Jul 30, 2014 at 9:30 AM, Will Deacon will.dea...@arm.com wrote:
 On Wed, Jul 30, 2014 at 02:23:50PM +0100, Thierry Reding wrote:
 On Wed, Jul 30, 2014 at 12:04:25PM +0100, Will Deacon wrote:
  On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
   From: Thierry Reding tred...@nvidia.com
  
   This commit introduces a generic device tree binding for IOMMU devices.
   Only a very minimal subset is described here, but it is enough to cover
   the requirements of both the Exynos System MMU and Tegra SMMU as
   discussed here:
  
   https://lkml.org/lkml/2014/4/27/346
  
   Signed-off-by: Thierry Reding tred...@nvidia.com
   ---
   Changes in v4:
   - clarify that disabling an IOMMU DT node may not disable translation
   - be more explicit that examples are only examples
   - add multi-ID master example
  
   Changes in v3:
   - use #iommu-cells instead of #address-cells/#size-cells
   - drop optional iommu-names property
  
   Changes in v2:
   - add notes about dma-ranges property (drop note from commit message)
   - document priorities of iommus property vs. dma-ranges property
   - drop #iommu-cells in favour of #address-cells and #size-cells
   - remove multiple-master device example
  
Documentation/devicetree/bindings/iommu/iommu.txt | 172 
   ++
1 file changed, 172 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt
 
  I'm concerned that this patch hasn't been picked up for 3.17 (I can't see 
  it
  in -next). If we want to move the ARM SMMU driver over to this new binding,
  we can't keep dragging our feet for much longer as I *really* don't plan to
  support two bindings in parallel (one is complicated enough already).
 
  Any chance we can see this merged, please?

 I think there weren't any comments left for me to address and I've
 mostly been waiting for Joerg to pick it up.

 Joerg, can you take this through the iommu tree for 3.17? Will acked
 this, but perhaps you were waiting for an ACK from the device tree
 bindings maintainers?

 Rob, Mark: can one or both of you take a look at this please?

I've been quiet on this round, but I think prior input I've had has
been addressed. If we believe this will work for ARM SMMU and MSM
IOMMU and some of the crazy chaining scenarios, then I'm fine with the
binding.

Acked-by: Rob Herring r...@kernel.org

Rob

P.S. Thankfully, there are no Calxeda systems with the SMMU enabled,
so a binding change should not cause much pain.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Rob Herring]

On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
thierry.red...@gmail.com wrote:
 From: Thierry Reding tred...@nvidia.com

 This commit introduces a generic device tree binding for IOMMU devices.
 Only a very minimal subset is described here, but it is enough to cover
 the requirements of both the Exynos System MMU and Tegra SMMU as
 discussed here:

 https://lkml.org/lkml/2014/4/27/346

 Signed-off-by: Thierry Reding tred...@nvidia.com
 ---
 Changes in v2:
 - add notes about dma-ranges property (drop note from commit message)
 - document priorities of iommus property vs. dma-ranges property
 - drop #iommu-cells in favour of #address-cells and #size-cells
 - remove multiple-master device example

  Documentation/devicetree/bindings/iommu/iommu.txt | 167 
 ++
  1 file changed, 167 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt

 diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt 
 b/Documentation/devicetree/bindings/iommu/iommu.txt
 new file mode 100644
 index ..6ce759afcc94
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
 @@ -0,0 +1,167 @@
 +This document describes the generic device tree binding for IOMMUs and their
 +master(s).
 +
 +
 +IOMMU device node:
 +==
 +
 +An IOMMU can provide the following services:
 +
 +* Remap address space to allow devices to access physical memory ranges that
 +  they otherwise wouldn't be capable of accessing.
 +
 +  Example: 32-bit DMA to 64-bit physical addresses
 +
 +* Implement scatter-gather at page level granularity so that the device does
 +  not have to.
 +
 +* Provide system protection against rogue DMA by forcing all accesses to go
 +  through the IOMMU and faulting when encountering accesses to unmapped
 +  address regions.
 +
 +* Provide address space isolation between multiple contexts.
 +
 +  Example: Virtualization
 +
 +Device nodes compatible with this binding represent hardware with some of the
 +above capabilities.
 +
 +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
 +typically have a fixed association to the master device, whereas multiple-
 +master IOMMU devices can translate accesses from more than one master.
 +
 +The device tree node of the IOMMU device's parent bus must contain a valid
 +dma-ranges property that describes how the physical address space of the
 +IOMMU maps to memory. An empty dma-ranges property means that there is a
 +1:1 mapping from IOMMU to memory.
 +
 +Required properties:
 +
 +- #address-cells: The number of cells in an IOMMU specifier needed to encode
 +  an address.
 +- #size-cells: The number of cells in an IOMMU specifier needed to represent
 +  the length of an address range.
 +
 +Typical values for the above include:
 +- #address-cells = 0, size-cells = 0: Single master IOMMU devices are not
 +  configurable and therefore no additional information needs to be encoded in
 +  the specifier. This may also apply to multiple master IOMMU devices that do
 +  not allow the association of masters to be configured.
 +- #address-cells = 1, size-cells = 0: Multiple master IOMMU devices may
 +  need to be configured in order to enable translation for a given master. In
 +  such cases the single address cell corresponds to the master device's ID.
 +- #address-cells = 2, size-cells = 2: Some IOMMU devices allow the DMA
 +  window for masters to be configured. The first cell of the address in this
 +  may contain the master device's ID for example, while the second cell could
 +  contain the start of the DMA window for the given device. The length of the
 +  DMA window is specified by two additional cells.
 +
 +
 +IOMMU master node:
 +==
 +
 +Devices that access memory through an IOMMU are called masters. A device can
 +have multiple master interfaces (to one or more IOMMU devices).
 +
 +Required properties:
 +
 +- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
 +  master interfaces of the device. One entry in the list describes one master
 +  interface of the device.
 +
 +When an iommus property is specified in a device tree node, the IOMMU will
 +be used for address translation. If a dma-ranges property exists in the
 +device's parent node it will be ignored. An exception to this rule is if the
 +referenced IOMMU is disabled, in which case the dma-ranges property of the
 +parent shall take effect.

Just thinking out loud, could you have dma-ranges in the iommu node
for the case when the iommu is enabled rather than putting the DMA
window information into the iommus property?

This would probably mean that you need both #iommu-cells and #address-cells.

 +
 +Optional properties:
 +
 +- iommu-names: A list of names identifying each entry in the iommus
 +  property.

Do we really need a name here? I would not expect that you have
clearly documented names here from the datasheet like 

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Rob Herring]

On Fri, May 30, 2014 at 2:06 PM, Arnd Bergmann a...@arndb.de wrote:
 On Friday 30 May 2014 08:16:05 Rob Herring wrote:
 On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
 thierry.red...@gmail.com wrote:
  From: Thierry Reding tred...@nvidia.com
  +IOMMU master node:
  +==
  +
  +Devices that access memory through an IOMMU are called masters. A device 
  can
  +have multiple master interfaces (to one or more IOMMU devices).
  +
  +Required properties:
  +
  +- iommus: A list of phandle and IOMMU specifier pairs that describe the 
  IOMMU
  +  master interfaces of the device. One entry in the list describes one 
  master
  +  interface of the device.
  +
  +When an iommus property is specified in a device tree node, the IOMMU 
  will
  +be used for address translation. If a dma-ranges property exists in the
  +device's parent node it will be ignored. An exception to this rule is if 
  the
  +referenced IOMMU is disabled, in which case the dma-ranges property of 
  the
  +parent shall take effect.

 Just thinking out loud, could you have dma-ranges in the iommu node
 for the case when the iommu is enabled rather than putting the DMA
 window information into the iommus property?

 This would probably mean that you need both #iommu-cells and #address-cells.

 The reason for doing like this was that you may need a different window
 for each device, while there can only be one dma-ranges property in
 an iommu node.

My suggestion was that you also put the IDs in the dma-ranges as the
first cell much as ranges for PCI encodes other information in the
first cell. Then you can have an entry for each ID. The downside is
another special case like PCI.

The argument for using #address-cells and #size-cells seems to be to
align with how ranges work. If that's the route we want to go, then I
say we should not stop there and actually use dma-ranges as well.
Otherwise, I don't see the advantage over #iommu-cells.

  +
  +Optional properties:
  +
  +- iommu-names: A list of names identifying each entry in the iommus
  +  property.

 Do we really need a name here? I would not expect that you have
 clearly documented names here from the datasheet like you would for
 interrupts or clocks, so you'd just be making up names. Sorry, but I'm
 not a fan of names properties in general.

 Good point, this was really overdesign by modeling it after other
 subsystems that can have a use for names.

  +Multiple-master IOMMU:
  +--
  +
  +   iommu {
  +   /* the specifier represents the ID of the master */
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   };
  +
  +   master {
  +   /* device has master ID 42 in the IOMMU */
  +   iommus = /iommu 42;
  +   };

 Presumably the ID would be the streamID on ARM's SMMU. How would a
 master with 8 streamIDs be described? This is what Calxeda midway has
 for SATA and I would expect that to be somewhat common. Either you
 need some ID masking or you'll have lots of duplication when you have
 windows.

 I don't understand the problem. If you have stream IDs 0 through 7,
 you would have

 master@a {
 ...
 iommus = smmu 0;
 };

 master@b {
 ...
 iommus = smmu 1;
 };

 ...

 master@12 {
 ...
 iommus = smmu 7;
 };

 and you don't need a window at all. Why would you need a mask of
 some sort?

1 master with 7 IDs like this:

 master@a {
 ...
 iommus = smmu 0 smmu 1 smmu 2 smmu 3
smmu 4 smmu 5 smmu 6 smmu 7;
 };

If there was any sort of window, then it is almost certainly the same
window for each ID.

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

Re: [PATCH 09/11] ARM: dts: Add nodes for SMMUs on Calxeda ECX-2000

[Rob Herring]

On Thu, Jan 16, 2014 at 6:44 AM, Andreas Herrmann
andreas.herrm...@calxeda.com wrote:
 Cc: Rob Herring robh...@kernel.org
 Cc: Andreas Herrmann herrmann.der.u...@googlemail.com
 Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com

One minor comment, but otherwise:

Acked-by: Rob Herring r...@kernel.org

 ---
  arch/arm/boot/dts/ecx-2000.dts|   44 
 +++--
  arch/arm/boot/dts/ecx-common.dtsi |9 +---
  2 files changed, 48 insertions(+), 5 deletions(-)

 diff --git a/arch/arm/boot/dts/ecx-2000.dts b/arch/arm/boot/dts/ecx-2000.dts
 index 2ccbb57f..722de49 100644
 --- a/arch/arm/boot/dts/ecx-2000.dts
 +++ b/arch/arm/boot/dts/ecx-2000.dts
 @@ -76,10 +76,11 @@
 };

 soc {
 -   ranges = 0x 0x 0x 0x;
 +   ranges = 0x0 0x0 0x0 0x;

 timer {
 -   compatible = arm,cortex-a15-timer, 
 arm,armv7-timer; interrupts = 1 13 0xf08,
 +   compatible = arm,cortex-a15-timer, 
 arm,armv7-timer;
 +   interrupts = 1 13 0xf08,
 1 14 0xf08,
 1 11 0xf08,
 1 10 0xf08;
 @@ -109,6 +110,45 @@
 interrupts = 0 76 4  0 75 4  0 74 4  0 73 4;
 };
 };
 +
 +   soc@92000 {

I believe this and the other  32-bit addresses below should be
soc@9,2000.

 +   ranges = 0x9 0x2000 0x9 0x2000 0x29;
 +   #address-cells = 2;
 +   #size-cells = 1;
 +   compatible = simple-bus;
 +   interrupt-parent = intc;
 +
 +   smmu_mac0: smmu@92000 {
 +   compatible = arm,mmu-400;
 +   reg = 0x9 0x2000 0x1;
 +   #global-interrupts = 1;
 +   interrupts = 0 106 4 0 106 4;
 +   mmu-masters = mac0 0 1;
 +   calxeda,smmu-secure-config-access;
 +   arm,smmu-isolate-devices;
 +   };
 +
 +   smmu_mac1: smmu@92008 {
 +   compatible = arm,mmu-400;
 +   reg = 0x9 0x2008 0x1;
 +   #global-interrupts = 1;
 +   interrupts = 0 108 4 0 108 4;
 +   mmu-masters = mac1 0 1;
 +   calxeda,smmu-secure-config-access;
 +   arm,smmu-isolate-devices;
 +   };
 +
 +   smmu_sata: smmu@92018 {
 +   compatible = arm,mmu-400;
 +   reg = 0x0009 0x2018 0x1;
 +   mmu-masters = sata 0 1 2 3 4 5 6 7 8 9;
 +   #global-interrupts = 1;
 +   interrupts = 0 114 4 0 114 4;
 +   calxeda,smmu-secure-config-access;
 +   arm,smmu-isolate-devices;
 +   };
 +   };
 +
  };

  /include/ ecx-common.dtsi
 diff --git a/arch/arm/boot/dts/ecx-common.dtsi 
 b/arch/arm/boot/dts/ecx-common.dtsi
 index b90045a..ad9b2fd 100644
 --- a/arch/arm/boot/dts/ecx-common.dtsi
 +++ b/arch/arm/boot/dts/ecx-common.dtsi
 @@ -33,7 +33,7 @@
 compatible = simple-bus;
 interrupt-parent = intc;

 -   sata@ffe08000 {
 +   sata: sata@ffe08000 {
 compatible = calxeda,hb-ahci;
 reg = 0xffe08000 0x1;
 interrupts = 0 83 4;
 @@ -43,6 +43,7 @@
  combophy0 3;
 calxeda,sgpio-gpio =gpioh 5 1 gpioh 6 1 gpioh 7 
 1;
 calxeda,led-order = 4 0 1 2 3;
 +   #stream-id-cells = 10;
 };

 sdhci@ffe0e000 {
 @@ -210,18 +211,20 @@
 clock-names = apb_pclk;
 };

 -   ethernet@fff5 {
 +   mac0: ethernet@fff5 {
 compatible = calxeda,hb-xgmac;
 reg = 0xfff5 0x1000;
 interrupts = 0 77 4  0 78 4  0 79 4;
 dma-coherent;
 +   #stream-id-cells = 2;
 };

 -   ethernet@fff51000 {
 +   mac1: ethernet@fff51000 {
 compatible = calxeda,hb-xgmac;
 reg = 0xfff51000 0x1000;
 interrupts = 0 80 4  0 81 4  0 82 4;
 dma-coherent;
 +   #stream-id-cells = 2;
 };

 combophy0: combo-phy@fff58000 {
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux

Re: [PATCH 08/11] of: Increase MAX_PHANDLE_ARGS

[Rob Herring]

On Thu, Jan 16, 2014 at 6:44 AM, Andreas Herrmann
andreas.herrm...@calxeda.com wrote:
 arm-smmu driver uses of_parse_phandle_with_args when parsing DT
 information to determine stream IDs for a master device.
 Thus the number of stream IDs per master device is bound by
 MAX_PHANDLE_ARGS.

 To support Calxeda ECX-2000 hardware arm-smmu driver requires a
 slightly higher value for MAX_PHANDLE_ARGS as this hardware has 10
 stream IDs for one master device.

 Cc: Grant Likely grant.lik...@linaro.org
 Cc: Rob Herring robh...@kernel.org
 Cc: devicet...@vger.kernel.org
 Cc: Andreas Herrmann herrmann.der.u...@googlemail.com
 Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com

Acked-by: Rob Herring r...@kernel.org

One comment below...

 ---
  include/linux/of.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/include/linux/of.h b/include/linux/of.h
 index 276c546..0807af8 100644
 --- a/include/linux/of.h
 +++ b/include/linux/of.h
 @@ -67,7 +67,7 @@ struct device_node {
  #endif
  };

 -#define MAX_PHANDLE_ARGS 8
 +#define MAX_PHANDLE_ARGS 10

Just bump this to 16. This is normally just a temporary on the stack
and 8 more words on the stack is not going to cost much.

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

Re: [PATCH 06/11] documentation/iommu: Update description of ARM System MMU binding

[Rob Herring]

On Thu, Jan 16, 2014 at 6:44 AM, Andreas Herrmann
andreas.herrm...@calxeda.com wrote:
 This patch adds descriptions fore new properties of device tree
 binding for the ARM SMMU architecture. These properties control
 arm-smmu driver options.

 Cc: Rob Herring robherri...@gmail.com
 Cc: Grant Likely grant.lik...@linaro.org
 Cc: Will Deacon will.dea...@arm.com
 Cc: Andreas Herrmann herrmann.der.u...@googlemail.com
 Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com

Acked-by: Rob Herring r...@kernel.org

 ---
  .../devicetree/bindings/iommu/arm,smmu.txt |   11 +++
  1 file changed, 11 insertions(+)

 diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
 b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
 index e34c6cd..7ad8ff0 100644
 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
 +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
 @@ -48,6 +48,16 @@ conditions.
from the mmu-masters towards memory) node for this
SMMU.

 +- arm,smmu-isolate-devices : Enable device isolation for all masters
 +   of this SMMU. Ie. each master will be attached to
 +   its own iommu domain.
 +
 +- calxeda,smmu-secure-config-access : Enable proper handling of buggy
 +   implementations that always use secure access to
 +   SMMU configuration registers. In this case
 +   non-secure aliases of secure registers have to be
 +   used during SMMU configuration.
 +
  Example:

  smmu {
 @@ -67,4 +77,5 @@ Example:
   */
  mmu-masters = dma0 0xd01d 0xd01e,
dma1 0xd11c;
 +arm,smmu-isolate-devices;
  };
 --
 1.7.9.5

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