Hi Michael,
On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
>
>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman
>> wrote:
>>> Christoph Hellwig writes:
>>>
We want to use the dma_direct_ namespace for a generic implementation,
so rename powerp
Geert Uytterhoeven writes:
> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman wrote:
>> Christoph Hellwig writes:
>>
>>> We want to use the dma_direct_ namespace for a generic implementation,
>>> so rename powerpc to the second best choice: dma_nommu_.
>>
>> I'm not a fan of "nommu". Some of t
The for_each_matching_node_and_match() would return every matching
nodes including unavailable ones.
It's pointless to init unavailable IOMMUs, so add a sanity check to
avoid that.
Signed-off-by: Jeffy Chen
---
drivers/iommu/of_iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/dri
> -Original Message-
> From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> Sent: Thursday, December 28, 2017 12:52 AM
> To: Mehta, Sohil ; Joerg Roedel ;
> Alex Williamson
> Cc: David Woodhouse ; Raj, Ashok
> ; iommu@lists.linux-foundation.org; linux-
> ker...@vger.kernel.
On Tue, Jan 02, 2018 at 01:00:36PM +, Will Deacon wrote:
> On Tue, Jan 02, 2018 at 12:33:14PM +, Robin Murphy wrote:
> > For PCI devices behind an aliasing PCIe-to-PCI/X bridge, the bridge
> > alias to DevFn 0.0 on the subordinate bus may match the original RID of
> > the device, resulting
On 29/12/17 08:18, Christoph Hellwig wrote:
> So that they don't need to indirect through the operation vector.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/arm/mm/dma-mapping-nommu.c | 9 +++--
> include/linux/dma-direct.h | 5 +
> lib/dma-direct.c| 6 +++---
>
On 29/12/17 08:18, Christoph Hellwig wrote:
> If we got back an allocation that wasn't inside the support coherent mask,
> retry the allocation using GFP_DMA.
>
> Based on the x86 code.
>
> Signed-off-by: Christoph Hellwig
> ---
> lib/dma-direct.c | 25 -
> 1 file change
Hi Robin,
Thank you for fixing this.
Regards,
Tomasz
On 02.01.2018 13:33, Robin Murphy wrote:
For PCI devices behind an aliasing PCIe-to-PCI/X bridge, the bridge
alias to DevFn 0.0 on the subordinate bus may match the original RID of
the device, resulting in the same SID being present in the d
On 29/12/17 08:18, Christoph Hellwig wrote:
> This means it uses whatever linear remapping scheme that the architecture
> provides is used in the generic dma_direct ops.
>
> Signed-off-by: Christoph Hellwig
> ---
> lib/dma-direct.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 d
On 29/12/17 08:18, Christoph Hellwig wrote:
> The trivial direct mapping implementation already does a virtual to
> physical translation which isn't strictly a noop, and will soon learn
> to do non-direct but linear physical to dma translations through the
> device offset and a few small tricks. R
When exposing data access through debugfs, the correct
debugfs_create_*() functions must be used, depending on data type.
Remove all casts from data pointers passed to debugfs_create_*()
functions, as such casts prevent the compiler from flagging bugs.
omap_iommu.nr_tlb_entries is "int", hence ca
On Tue, Jan 02, 2018 at 12:33:14PM +, Robin Murphy wrote:
> For PCI devices behind an aliasing PCIe-to-PCI/X bridge, the bridge
> alias to DevFn 0.0 on the subordinate bus may match the original RID of
> the device, resulting in the same SID being present in the device's
> fwspec twice. This ca
For PCI devices behind an aliasing PCIe-to-PCI/X bridge, the bridge
alias to DevFn 0.0 on the subordinate bus may match the original RID of
the device, resulting in the same SID being present in the device's
fwspec twice. This causes trouble later in arm_smmu_write_strtab_ent()
when we wind up visi
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and ca
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Hi Christoph,
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> CONFIG_ALPHA_JENSEN has failed to compile since commit aca05038
> ("alpha/dma: use common noop dma ops"), so mark it as broken.
unknown revision or path not in the working tree.
Ah, you dropped the leading "6":
6aca0503847
Missing patch description explaining why this change is desirable.
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -39,7 +39,7 @@ static void *dma_direct_alloc(struct device *dev, size_t
> size,
> if (gfpflags_allow_blockin
On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman wrote:
> Christoph Hellwig writes:
>
>> We want to use the dma_direct_ namespace for a generic implementation,
>> so rename powerpc to the second best choice: dma_nommu_.
>
> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
Christoph Hellwig writes:
> We want to use the dma_direct_ namespace for a generic implementation,
> so rename powerpc to the second best choice: dma_nommu_.
I'm not a fan of "nommu". Some of the users of direct ops *are* using an
IOMMU, they're just setting up a 1:1 mapping once at init time, r
19 matches
Mail list logo
