Re: [PATCH 03/14] iommu: Create a base struct for io_mm

On Fri, Mar 02, 2018 at 12:25:48PM +, Jean-Philippe Brucker wrote: > Hi Jordan, > > Thank you for this, SMMUv3 and virtio-iommu need these SVA patches as well. > > On 21/02/18 22:59, Jordan Crouse wrote: > [...]> diff --git a/include/linux/iommu.h b/include/linux/iommu.h > > index

Re: [PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable

On 02/03/18 14:55, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla Many of the rpmsg clients like audio drivers need to allocate dma memory. Make this bus DMA capable so that the child devices can use dma apis. AFAICS after 15 minutes in the

Re: [PATCH 04/14] iommu: sva: Add support for pasid allocation

On Fri, Mar 02, 2018 at 12:27:58PM +, Jean-Philippe Brucker wrote: > On 21/02/18 22:59, Jordan Crouse wrote: > [...] > > +int iommu_sva_alloc_pasid(struct iommu_domain *domain, struct device *dev) > > +{ > > + int ret, pasid; > > + struct io_pasid *io_pasid; > > + > > + if

Re: [PATCH 02/14] iommu/arm-smmu: Add support for TTBR1

On 21/02/18 22:59, Jordan Crouse wrote: Allow a SMMU device to opt into allocating a TTBR1 pagetable. The size of the TTBR1 region will be the same as the TTBR0 size with the sign extension bit set on the highest bit in the region unless the upstream size is 49 bits and then the sign-extension

Re: [PATCH 02/14] iommu/arm-smmu: Add support for TTBR1

On Fri, Mar 02, 2018 at 05:57:21PM +, Robin Murphy wrote: > On 21/02/18 22:59, Jordan Crouse wrote: > >Allow a SMMU device to opt into allocating a TTBR1 pagetable. > > > >The size of the TTBR1 region will be the same as > >the TTBR0 size with the sign extension bit set on the highest > >bit

Re: [PATCH 03/37] iommu/sva: Manage process address spaces

On 01/03/18 06:52, Lu Baolu wrote: > Can the pasid management code be moved into a common library? > PASID is not stick to SVA. An IOMMU model device could be designed > to use PASID for second level translation (classical DMA translation) > as well. What do you mean by second level translation?

Re: [PATCH 02/37] iommu/sva: Bind process address spaces to devices

On 01/03/18 03:03, Liu, Yi L wrote: > Hi Jean, > >> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] >> Sent: Thursday, February 15, 2018 8:41 PM >> Subject: Re: [PATCH 02/37] iommu/sva: Bind process address spaces to devices >> >> On 13/02/18 23:34, Tian, Kevin wrote:

Re: [PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable

Thanks for your time, On 02/03/18 16:14, Robin Murphy wrote: On 02/03/18 14:55, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla Many of the rpmsg clients like audio drivers need to allocate dma memory. Make this bus DMA capable so that the

Re: RFC on Kdump and PCIe on ARM64

On Fri, Mar 02, 2018 at 09:12:29AM -0500, Sinan Kaya wrote: > On 3/2/2018 5:30 AM, Will Deacon wrote: > >> Do you really have to reset the IOMMU? Can you just give it new page > >> tables that start out with all IOVAs from all devices being invalid, > >> then add valid mappings as drivers need

Re: RFC on Kdump and PCIe on ARM64

On 3/2/2018 1:02 PM, Will Deacon wrote: >> How about the points that Baoquan highlighted in his email regarding the >> solution from AMD and X86? > Which specific points do you think this proposal doesn't address? > No specific concerns at this moment. >> I have not read the entire thread but,

Re: [PATCH v12 3/3] arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07

Hi Shameer, On 2017/12/14 16:09, Shameer Kolothum wrote: > The HiSilicon erratum 161010801 describes the limitation of > HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings > for MSI transactions. > > PCIe controller on these platforms has to differentiate the > MSI payload against

Re: [PATCH 03/37] iommu/sva: Manage process address spaces

On 01/03/18 08:04, Christian König wrote: > Am 01.03.2018 um 07:52 schrieb Lu Baolu: >> Hi Jean, >> >> On 02/13/2018 02:33 AM, Jean-Philippe Brucker wrote: >>> [SNIP] >>> + pasid = idr_alloc_cyclic(_pasid_idr, io_mm, dev_param->min_pasid, >>> +dev_param->max_pasid +

Re: [PATCH 3/3] iommu: armsmmu: set iommu ops for rpmsg bus

On 02/03/18 14:55, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla On Qualcomm SoCs, ADSP exposes many functions like audio and others. These services need iommu access to allocate any memory for the DSP. As these drivers are childeren of rpmsg

WARN_ON(irqs_disabled()) in dma_free_attrs?

Hello DMA mapping helpers maintainers, I'm porting the PS2 OHCI driver to v4.15 and it triggers WARN_ON(irqs_disabled()); in include/linux/dma-mapping.h:dma_free_attrs (trace below). USB maintainer Alan Stern notes in https://www.spinics.net/lists/linux-usb/msg162817.html that

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

Hi Fredrik, On 02/03/18 18:07, Fredrik Noring wrote: Hello DMA mapping helpers maintainers, I'm porting the PS2 OHCI driver to v4.15 and it triggers WARN_ON(irqs_disabled()); in include/linux/dma-mapping.h:dma_free_attrs (trace below). USB maintainer Alan Stern notes in

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

On Fri, Mar 02, 2018 at 07:07:06PM +0100, Fredrik Noring wrote: > What is the best way to proceed? Can dma_free_attrs be reworked to handle > disabled IRQs? Why do you want to free coherent dma allocations from irq context? They generally are a long-term resource that as a rule of thumb should be

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

On Fri, Mar 02, 2018 at 07:55:48PM +, Robin Murphy wrote: > On the other hand, HCD_LOCAL_MEM implies a per-device coherent pool. Since > those bypass the arch-specific code, then depending on how unlikely we > think it is for devices covered by a single driver to exist both with and >

Re: [PATCH 01/14] iommu: Add DOMAIN_ATTR_ENABLE_TTBR1

On 21/02/18 22:59, Jordan Crouse wrote: Add a new domain attribute to enable the TTBR1 pagetable for drivers and devices that support it. This will enabled using a TTBR1 (otherwise known as a "global" or "system" pagetable for devices that support a split pagetable scheme for switching

[PATCH 1/3] rpmsg: core: export rpmsg bus type

From: Srinivas Kandagatla Export rpmsg bus type so that iommu drivers iommu ops to rpmsg bus type. On Qualcomm SoCs ADSP exposes functions like audio and other which need iommu access, as these drivers are part of rpmsg bus, able to allocate memory from iommus is

[PATCH 0/3] drivers: rpmsg: make rpmsg bus DMA capable

From: Srinivas Kandagatla On Qualcomm SoCs, DSP exposes many functionalities like audio, as these drivers are child of rpmsg bus. Any dma allocations or iommu operations on these devices would fail as the rpmsg bus is not marked as dma capable bus. This patchset

[PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable

From: Srinivas Kandagatla Many of the rpmsg clients like audio drivers need to allocate dma memory. Make this bus DMA capable so that the child devices can use dma apis. Signed-off-by: Srinivas Kandagatla ---

[PATCH 3/3] iommu: armsmmu: set iommu ops for rpmsg bus

From: Srinivas Kandagatla On Qualcomm SoCs, ADSP exposes many functions like audio and others. These services need iommu access to allocate any memory for the DSP. As these drivers are childeren of rpmsg bus, able to allocate memory from iommus is basic

[PATCH v8 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu gets runtime enabled/disabled only when the master needs it. This is done from add_device callback which gets called once when the master is added to the smmu.

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

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 Reviewed-by: Rob Herring

[PATCH v8 0/5] iommu/arm-smmu: Add runtime pm/sleep support

This series provides the support for turning on the arm-smmu's clocks/power domains using runtime pm. This is done using the recently introduced device links patches, which lets the smmu's runtime to follow the master's runtime pm, so the smmu remains powered only when the masters use it. It also

[PATCH v8 2/5] iommu/arm-smmu: Add pm_runtime/sleep ops

From: Sricharan R The smmu needs to be functional only when the respective master's using it are active. The device_link feature helps to track such functional dependencies, so that the iommu gets powered when the master device enables itself using pm_runtime. So by

[PATCH v8 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So calling runtime apis in those places separately. Signed-off-by: Sricharan R

[PATCH v8 1/5] iommu/arm-smmu: Destroy domain context in failure path

If we fail after initializing domain_context, we should destroy the context to free up resources. Signed-off-by: Vivek Gautam --- * New patch added in this series. drivers/iommu/arm-smmu.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git

Re: RFC on Kdump and PCIe on ARM64

On Thu, Mar 01, 2018 at 06:03:03PM -0600, Bjorn Helgaas wrote: > On Thu, Mar 01, 2018 at 02:19:09PM -0500, Sinan Kaya wrote: > > On 3/1/2018 2:05 PM, Bjorn Helgaas wrote: > > > On Thu, Mar 01, 2018 at 12:44:26PM -0500, Sinan Kaya wrote: > > >> Hi, > > >> > > >> We are seeing IOMMU faults when

Re: RFC on Kdump and PCIe on ARM64

Hi Will, On 3/2/2018 5:30 AM, Will Deacon wrote: >> Do you really have to reset the IOMMU? Can you just give it new page >> tables that start out with all IOVAs from all devices being invalid, >> then add valid mappings as drivers need them (presumably after the >> driver has done whatever it

Re: RFC on Kdump and PCIe on ARM64

On 3/1/2018 7:03 PM, Bjorn Helgaas wrote: >> 3. The last one is adapter gets into fuzzy state due to not coming >> out of clean state in the second time init and being rejected by >> SMMUv3 multiple times. >> >> [ 16.093441] pci :01:00.0: aer_status: 0x0004, aer_mask: 0x >> [

Re: [PATCH 03/14] iommu: Create a base struct for io_mm

Hi Jordan, Thank you for this, SMMUv3 and virtio-iommu need these SVA patches as well. On 21/02/18 22:59, Jordan Crouse wrote: [...]> diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index e2c49e583d8d..e998389cf195 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h >

Re: [PATCH 04/14] iommu: sva: Add support for pasid allocation

On 21/02/18 22:59, Jordan Crouse wrote: [...] > +int iommu_sva_alloc_pasid(struct iommu_domain *domain, struct device *dev) > +{ > + int ret, pasid; > + struct io_pasid *io_pasid; > + > + if (!domain->ops->pasid_alloc || !domain->ops->pasid_free) > + return -ENODEV; > + > +

Re: [PATCH 02/37] iommu/sva: Bind process address spaces to devices

On 28/02/18 20:34, Sinan Kaya wrote: > On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote: >> +int iommu_sva_unbind_group(struct iommu_group *group, int pasid) >> +{ >> +struct group_device *device; >> + >> +mutex_lock(>mutex); >> +list_for_each_entry(device, >devices, list) >> +

Re: [PATCH 11/14] drm/msm: Add support for iommu-sva PASIDs

On 21/02/18 22:59, Jordan Crouse wrote: [...]> +static int install_pasid_cb(int pasid, u64 ttbr, u32 asid, void *data) > +{ > + struct pasid_entry *entry = kzalloc(sizeof(*entry), GFP_KERNEL); > + > + if (!entry) > + return -ENOMEM; > + > + entry->pasid = pasid; > +

Re: [PATCH 1/3] rpmsg: core: export rpmsg bus type

On 02/03/18 14:55, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla Export rpmsg bus type so that iommu drivers iommu ops to rpmsg bus type. On Qualcomm SoCs ADSP exposes functions like audio and other which need iommu access, as these drivers