Re: [PATCH v4 0/5] memory: Introduce memory controller mini-framework

2020-02-13 Thread Maxime Ripard
On Thu, Feb 13, 2020 at 07:15:55PM +0100, Thierry Reding wrote: > On Thu, Feb 13, 2020 at 05:23:23PM +, Robin Murphy wrote: > > [+ Maxime] > > > > On 13/02/2020 4:39 pm, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > Hi, > > > > > > this set of patches adds a new binding that all

Re: [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation

2020-02-13 Thread Stephen Boyd
Quoting Sai Prakash Ranjan (2020-01-22 03:48:01) > Currently the QCOM specific smmu reset implementation is very > specific to SDM845 SoC and has a wait-for-safe logic which > may not be required for other SoCs. So move the SDM845 specific > logic to its specific reset function. Also add SC7180 SMM

Re: [PATCH v2] iommu/arm-smmu-v3: Add SMMUv3.2 range invalidation support

2020-02-13 Thread Rob Herring
On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy wrote: > > On 30/01/2020 3:06 pm, Auger Eric wrote: > > Hi Rob, > > On 1/17/20 10:16 PM, Rob Herring wrote: > >> Arm SMMUv3.2 adds support for TLB range invalidate operations. > >> Support for range invalidate is determined by the RIL bit in the IDR3 >

[PATCH v2] iommu/arm-smmu-v3: Batch ATC invalidation commands

2020-02-13 Thread Rob Herring
Similar to commit 2af2e72b18b4 ("iommu/arm-smmu-v3: Defer TLB invalidation until ->iotlb_sync()"), build up a list of ATC invalidation commands and submit them all at once to the command queue instead of one-by-one. As there is only one caller of arm_smmu_atc_inv_master() left, we can simplify it

Re: [PATCH v2] iommu/arm-smmu-v3: Add SMMUv3.2 range invalidation support

2020-02-13 Thread Rob Herring
On Thu, Jan 30, 2020 at 9:06 AM Auger Eric wrote: > > Hi Rob, > On 1/17/20 10:16 PM, Rob Herring wrote: > > Arm SMMUv3.2 adds support for TLB range invalidate operations. > > Support for range invalidate is determined by the RIL bit in the IDR3 > > register. > > > > The range invalidate is in unit

Re: arm64 iommu groups issue

2020-02-13 Thread Robin Murphy
On 13/02/2020 3:49 pm, John Garry wrote: The underlying issue is that, for historical reasons, OF/IORT-based IOMMU drivers have ended up with group allocation being tied to endpoint driver probing via the dma_configure() mechanism (long story short, driver probe is the only thing which can be de

Re: [PATCH 03/11] PCI: OF: Check whether the host bridge supports ATS

2020-02-13 Thread Rob Herring
On Thu, Feb 13, 2020 at 10:52 AM Jean-Philippe Brucker wrote: > > Copy the ats-supported flag into the pci_host_bridge structure. > > Signed-off-by: Jean-Philippe Brucker > --- > drivers/pci/controller/pci-host-common.c | 1 + > drivers/pci/of.c | 9 + > include/l

Re: [PATCH v4 0/5] memory: Introduce memory controller mini-framework

2020-02-13 Thread Thierry Reding
On Thu, Feb 13, 2020 at 05:23:23PM +, Robin Murphy wrote: > [+ Maxime] > > On 13/02/2020 4:39 pm, Thierry Reding wrote: > > From: Thierry Reding > > > > Hi, > > > > this set of patches adds a new binding that allows device tree nodes to > > explicitly define the DMA parent for a given devic

Re: [PATCH v4 3/5] memory: Introduce memory controller mini-framework

2020-02-13 Thread Thierry Reding
On Thu, Feb 13, 2020 at 05:03:10PM +, Robin Murphy wrote: > On 13/02/2020 4:39 pm, Thierry Reding wrote: > > From: Thierry Reding > > > > This new framework is currently nothing more than a registry of memory > > controllers, with the goal being to order device probing. One use-case > > where

Re: [PATCH v4 0/5] memory: Introduce memory controller mini-framework

2020-02-13 Thread Robin Murphy
[+ Maxime] On 13/02/2020 4:39 pm, Thierry Reding wrote: From: Thierry Reding Hi, this set of patches adds a new binding that allows device tree nodes to explicitly define the DMA parent for a given device. This supplements the existing interconnect bindings and is useful to disambiguate in th

Re: [PATCH v4 3/5] memory: Introduce memory controller mini-framework

2020-02-13 Thread Robin Murphy
On 13/02/2020 4:39 pm, Thierry Reding wrote: From: Thierry Reding This new framework is currently nothing more than a registry of memory controllers, with the goal being to order device probing. One use-case where this is useful, for example, is a memory controller device which needs to program

[PATCH 02/11] PCI: Add ats_supported host bridge flag

2020-02-13 Thread Jean-Philippe Brucker
Each vendor has their own way of describing whether a host bridge supports ATS. The Intel and AMD ACPI tables selectively enable or disable ATS per device or sub-tree, while Arm has a single bit for each host bridge. For those that need it, add an ats_supported bit to the host bridge structure.

[PATCH 09/11] ACPI/IORT: Drop ATS fwspec flag

2020-02-13 Thread Jean-Philippe Brucker
Now that the ats_supported flag is in the host bridge structure where it belongs, we can remove it from the per-device fwspec structure. Signed-off-by: Jean-Philippe Brucker --- drivers/acpi/arm64/iort.c | 11 --- include/linux/iommu.h | 4 2 files changed, 15 deletions(-) dif

[PATCH 08/11] iommu/vt-d: Use pci_ats_supported()

2020-02-13 Thread Jean-Philippe Brucker
The pci_ats_supported() function checks if a device supports ATS and is allowed to use it. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/intel-iommu.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c i

[PATCH 01/11] dt-bindings: PCI: generic: Add ats-supported property

2020-02-13 Thread Jean-Philippe Brucker
Add a way for firmware to tell the OS that ATS is supported by the PCI root complex. An endpoint with ATS enabled may send Translation Requests and Translated Memory Requests, which look just like Normal Memory Requests with a non-zero AT field. So a root controller that ignores the AT field may si

[PATCH 06/11] iommu/amd: Use pci_ats_supported()

2020-02-13 Thread Jean-Philippe Brucker
The pci_ats_supported() function checks if a device supports ATS and is allowed to use it. In addition to checking that the device has an ATS capability and that the global pci=noats is not set (pci_ats_disabled()), it also checks if a device is untrusted (plugged into an external-facing port such

[PATCH 04/11] ACPI/IORT: Check ATS capability in root complex node

2020-02-13 Thread Jean-Philippe Brucker
When initializing a PCI root bridge, copy its "ATS supported" attribute into the root bridge. Signed-off-by: Jean-Philippe Brucker --- drivers/acpi/arm64/iort.c | 27 +++ drivers/acpi/pci_root.c | 3 +++ include/linux/acpi_iort.h | 8 3 files changed, 38 inse

[PATCH 03/11] PCI: OF: Check whether the host bridge supports ATS

2020-02-13 Thread Jean-Philippe Brucker
Copy the ats-supported flag into the pci_host_bridge structure. Signed-off-by: Jean-Philippe Brucker --- drivers/pci/controller/pci-host-common.c | 1 + drivers/pci/of.c | 9 + include/linux/of_pci.h | 3 +++ 3 files changed, 13 insertions(+) di

[PATCH 05/11] PCI/ATS: Gather checks into pci_ats_supported()

2020-02-13 Thread Jean-Philippe Brucker
IOMMU drivers need to perform several tests when checking if a device supports ATS. Move them all into a new function that returns true when a device and its host bridge support ATS. Since pci_enable_ats() now calls pci_ats_supported(), the following new checks are now common: * whether a device

[PATCH 07/11] iommu/arm-smmu-v3: Use pci_ats_supported()

2020-02-13 Thread Jean-Philippe Brucker
The new pci_ats_supported() function checks if a device supports ATS and is allowed to use it. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/

[PATCH 10/11] arm64: dts: fast models: Enable PCIe ATS for Base RevC FVP

2020-02-13 Thread Jean-Philippe Brucker
Declare that the host controller supports ATS, so the OS can enable it for ATS-capable PCIe endpoints. Signed-off-by: Jean-Philippe Brucker --- All endpoints support ATS provided they have the ats_supported=1 model parameter. "lspci -vv" shows whether ATS is supported and enabled. --- arch/arm64

[PATCH 11/11] Documentation: Generalize the "pci=noats" boot parameter

2020-02-13 Thread Jean-Philippe Brucker
The "pci=noats" kernel parameter disables PCIe ATS globally, and affects any ATS-capable IOMMU driver. So rather than adding Arm SMMUv3, which recently gained ATS support, to the list of relevant build options, simplify the noats description. Signed-off-by: Jean-Philippe Brucker --- Documentatio

[PATCH 00/10] PCI/ATS: Device-tree support and other improvements

2020-02-13 Thread Jean-Philippe Brucker
Enable ATS on device-tree based systems, and factor the common ATS enablement checks into pci_enable_ats(). ATS support in PCIe endpoints is discovered through the ATS capability, but there is no common method for discovering whether the host bridge supports ATS. Each vendor provides their own ACP

[PATCH v4 5/5] iommu: arm-smmu: Get reference to memory controller

2020-02-13 Thread Thierry Reding
From: Thierry Reding Use the memory controller framework to obtain a reference to the memory controller to which the SMMU will make memory requests. This allows the two drivers to properly order their probes so that the memory controller can be programmed first. An example where this is required

[PATCH v4 4/5] memory: tegra186: Register as memory controller

2020-02-13 Thread Thierry Reding
From: Thierry Reding Registering as memory controller allows other drivers to obtain a reference to it. This is mostly useful as a way of ordering probe between devices depending on one another. Signed-off-by: Thierry Reding --- drivers/memory/tegra/tegra186.c | 9 - 1 file changed, 8

[PATCH v4 3/5] memory: Introduce memory controller mini-framework

2020-02-13 Thread Thierry Reding
From: Thierry Reding This new framework is currently nothing more than a registry of memory controllers, with the goal being to order device probing. One use-case where this is useful, for example, is a memory controller device which needs to program some registers before the system MMU can be en

[PATCH v4 2/5] of: Use memory-controllers property for DMA parent

2020-02-13 Thread Thierry Reding
From: Thierry Reding Prefer the memory-controllers property to determine the DMA parent of a device over the interconnects property, which can be ambiguous since it can be used to describe multiple paths to system memory. Signed-off-by: Thierry Reding --- drivers/of/address.c | 25

[PATCH v4 0/5] memory: Introduce memory controller mini-framework

2020-02-13 Thread Thierry Reding
From: Thierry Reding Hi, this set of patches adds a new binding that allows device tree nodes to explicitly define the DMA parent for a given device. This supplements the existing interconnect bindings and is useful to disambiguate in the case where a device has multiple paths to system memory.

[PATCH v4 1/5] dt-bindings: Add memory controller bindings

2020-02-13 Thread Thierry Reding
From: Thierry Reding Add the DT schema for memory controller and consumer bindings. Signed-off-by: Thierry Reding --- .../bindings/memory-controllers/consumer.yaml | 14 .../memory-controllers/memory-controller.yaml | 32 +++ 2 files changed, 46 insertions(+) create m

Re: arm64 iommu groups issue

2020-02-13 Thread John Garry
The underlying issue is that, for historical reasons, OF/IORT-based IOMMU drivers have ended up with group allocation being tied to endpoint driver probing via the dma_configure() mechanism (long story short, driver probe is the only thing which can be delayed in order to wait for a specific IOMM

[PATCH] iommu: Use C99 flexible array in fwspec

2020-02-13 Thread Robin Murphy
Although the 1-element array was a typical pre-C99 way to implement variable-length structures, and indeed is a fundamental construct in the APIs of certain other popular platforms, there's no good reason for it here (and in particular the sizeof() trick is far too "clever" for its own good). We ca

Re: [PATCH v12 2/4] uacce: add uacce driver

2020-02-13 Thread Greg Kroah-Hartman
On Thu, Feb 13, 2020 at 05:15:10PM +0800, Herbert Xu wrote: > On Mon, Feb 10, 2020 at 03:37:11PM -0800, Greg Kroah-Hartman wrote: > > > > Looks much saner now, thanks for all of the work on this: > > > > Reviewed-by: Greg Kroah-Hartman > > > > Or am I supposed to take this in my tree? If so, I

[PATCH 4/4] iommu/arm-smmu-v3: Write level-1 descriptors atomically

2020-02-13 Thread Jean-Philippe Brucker
Use WRITE_ONCE() to make sure that the SMMU doesn't read incomplete stream table descriptors. Refer to the comment about 64-bit accesses, and add the comment to the equivalent context descriptor code. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 4 +++- 1 file changed,

[PATCH 0/4] iommu: Finish off PASID support for Arm SMMUv3

2020-02-13 Thread Jean-Philippe Brucker
Support for context descriptor tables was added to the SMMUv3 driver by commit 87f42391f6a5 ("iommu/arm-smmu-v3: Add support for Substream IDs"). The last patch enabling PASID in PCI devices couldn't be included right away since it would have prevented from building SMMUv3 as a module, another feat

[PATCH 2/4] iommu/arm-smmu-v3: Add support for PCI PASID

2020-02-13 Thread Jean-Philippe Brucker
Enable PASID for PCI devices that support it. Initialize PASID early in add_device() because it must be enabled before ATS. Tested-by: Zhangfei Gao Reviewed-by: Jonathan Cameron Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 62 - 1 f

[PATCH 3/4] iommu/arm-smmu-v3: Batch context descriptor invalidation

2020-02-13 Thread Jean-Philippe Brucker
Rather than publishing one command at a time when invalidating a context descriptor, batch the commands for all SIDs in the domain. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/iommu

[PATCH 1/4] PCI/ATS: Export symbols of PASID functions

2020-02-13 Thread Jean-Philippe Brucker
The Arm SMMUv3 driver uses pci_{enable,disable}_pasid() and related functions. Export them to allow the driver to be built as a module. Signed-off-by: Jean-Philippe Brucker --- drivers/pci/ats.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index

Re: [PATCH v12 2/4] uacce: add uacce driver

2020-02-13 Thread zhangfei
On 2020/2/13 下午5:15, Herbert Xu wrote: On Mon, Feb 10, 2020 at 03:37:11PM -0800, Greg Kroah-Hartman wrote: Looks much saner now, thanks for all of the work on this: Reviewed-by: Greg Kroah-Hartman Or am I supposed to take this in my tree? If so, I can, but I need an ack for the crypto part

Re: [PATCH] iommu/arm-smmu: fix the module name to be consistent with older kernel

2020-02-13 Thread Will Deacon
On Wed, Feb 12, 2020 at 01:59:46PM -0600, Li Yang wrote: > On Wed, Feb 12, 2020 at 4:50 AM Will Deacon wrote: > > > > On Tue, Feb 11, 2020 at 06:37:20PM -0600, Li Yang wrote: > > > Commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module") > > > introduced a side effect that changed the mo

Re: [PATCH v12 2/4] uacce: add uacce driver

2020-02-13 Thread Herbert Xu
On Mon, Feb 10, 2020 at 03:37:11PM -0800, Greg Kroah-Hartman wrote: > > Looks much saner now, thanks for all of the work on this: > > Reviewed-by: Greg Kroah-Hartman > > Or am I supposed to take this in my tree? If so, I can, but I need an > ack for the crypto parts. I can take this series thr