On Fri, Sep 22, 2017 at 6:02 AM, Jean-Philippe Brucker
wrote:
> On 22/09/17 10:02, Joerg Roedel wrote:
>> On Tue, Sep 19, 2017 at 10:23:43AM -0400, Rob Clark wrote:
>>> I would like to decide in the IRQ whether or not to queue work or not,
>>> because when we get a gpu fault, we tend to get 1000's
Hi Björn,
On Fri, Sep 22, 2017 at 5:56 PM, Bjorn Helgaas wrote:
> On Mon, Sep 11, 2017 at 02:29:15PM +0200, Geert Uytterhoeven wrote:
>> If CONFIG_PCI=n, and gcc (e.g. 4.1.2) decides not to inline
>> get_pci_function_alias_group(), the build fails with:
>>
>> drivers/iommu/iommu.o: In functio
Hey Bjorn,
On Fri, Sep 22, 2017 at 10:56:05AM -0500, Bjorn Helgaas wrote:
> Joerg, if you pick this up, would you mind capitalizing the subject
> line to match the PCI convention, e.g.,
>
> PCI: Add dummy pci_acs_enabled() for CONFIG_PCI=n build
>
> If it's too late for you to pick this up thi
On 22/09/17 17:21, Tomasz Nowicki wrote:
> Hi Robin,
>
> On 21.09.2017 17:52, Robin Murphy wrote:
>> The cached node mechanism provides a significant performance benefit for
>> allocations using a 32-bit DMA mask, but in the case of non-PCI devices
>> or where the 32-bit space is full, the loss of
On 22.09.2017 18:50, tn wrote:
On 22.09.2017 18:21, Tomasz Nowicki wrote:
Hi Robin,
On 21.09.2017 17:52, Robin Murphy wrote:
The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit spac
On 22.09.2017 18:21, Tomasz Nowicki wrote:
Hi Robin,
On 21.09.2017 17:52, Robin Murphy wrote:
The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this bene
Hi Robin,
On 21.09.2017 17:52, Robin Murphy wrote:
The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this benefit can be
significant - on large systems th
On Mon, Sep 11, 2017 at 02:29:15PM +0200, Geert Uytterhoeven wrote:
> If CONFIG_PCI=n, and gcc (e.g. 4.1.2) decides not to inline
> get_pci_function_alias_group(), the build fails with:
>
> drivers/iommu/iommu.o: In function `get_pci_function_alias_group':
> iommu.c:(.text+0xfdc): undefine
Hi Robin,
On Thu, Sep 21, 2017 at 5:11 PM, Robin Murphy wrote:
> On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
>> Change function __iommu_dma_alloc_pages to allocate memory/pages
>> for dma from respective device numa node.
>>
>> Signed-off-by: Ganapatrao Kulkarni
>> ---
>> drivers/iommu/dma-i
On Mon, Sep 18, 2017 at 04:21:53PM +0100, Robin Murphy wrote:
> Now that the core API issues its own post-unmap TLB sync call, push that
> operation out from the io-pgtable-arm internals into the users. For now,
> we leave the invalidation implicit in the unmap operation, since none of
> the curren
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: Friday, September 22, 2017 3:28 PM
> To: Shameerali Kolothum Thodi
> Cc: marc.zyng...@arm.com; sudeep.ho...@arm.com; will.dea...@arm.com;
> robin.mur...@arm.com; j...@8bytes.org; mark.rutl...@arm.co
On Thu, Sep 21, 2017 at 4:41 PM, Robin Murphy wrote:
> On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
>> function __arm_lpae_alloc_pages is used to allcoated memory for smmu
>> translation tables. updating function to allocate memory/pages
>> from the proximity domain of SMMU device.
>
> AFAICS, da
John, Shameer,
On Thu, Sep 14, 2017 at 01:57:54PM +0100, Shameer Kolothum wrote:
> From: John Garry
>
> On some platforms msi-controller address regions have to be excluded
> from normal IOVA allocation in that they are detected and decoded in
> a HW specific way by system components and so they
Now that the kernel headers have synced with the relevant upstream
ACPICA updates, it's time to clean up the temporary local definitions.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c | 11 +--
drivers/iommu/arm-smmu.c| 8
2 files changed, 1 insertion(+), 18 d
Hi Linus,
The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v4.14-rc1
for you to fetch changes up to
On Fri, Sep 22, 2017 at 10:51:30AM +0100, Robin Murphy wrote:
>
> Fixes: d87beb749281 ("iommu/of: Handle PCI aliases properly")
>
> The check itself originally dates back to b996444cf35e ("iommu/of:
> Handle iommu-map property for PCI") but it's really not worth
> backporting past the above refac
On Thu, Sep 21, 2017 at 11:45 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> 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
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
On Thu, Sep 21, 2017 at 11:45 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> 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
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
On 22/09/17 10:02, Joerg Roedel wrote:
> On Tue, Sep 19, 2017 at 10:23:43AM -0400, Rob Clark wrote:
>> I would like to decide in the IRQ whether or not to queue work or not,
>> because when we get a gpu fault, we tend to get 1000's of gpu faults
>> all at once (and I really only need to handle the
On 22/09/17 09:56, Joerg Roedel wrote:
> Hey Robin,
>
> On Thu, Sep 21, 2017 at 11:20:58AM +0100, Robin Murphy wrote:
>> of_pci_iommu_init() tries to be clever and stop its alias walk at the
>> device represented by master_np, in case of weird PCI topologies where
>> the bridge to the IOMMU and th
On Tue, Sep 19, 2017 at 10:23:43AM -0400, Rob Clark wrote:
> I would like to decide in the IRQ whether or not to queue work or not,
> because when we get a gpu fault, we tend to get 1000's of gpu faults
> all at once (and I really only need to handle the first one). I
> suppose that could also be
Hey Robin,
On Thu, Sep 21, 2017 at 11:20:58AM +0100, Robin Murphy wrote:
> of_pci_iommu_init() tries to be clever and stop its alias walk at the
> device represented by master_np, in case of weird PCI topologies where
> the bridge to the IOMMU and the rest of the system is not at the root.
> It tu
22 matches
Mail list logo
