On Sat, 2017-06-24 at 09:18 +0200, Christoph Hellwig wrote:
> On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote:
> > Thanks for doing this.
> > So archs can still have their own definition for dma_set_mask() if
> > HAVE_ARCH_DMA_SET_MASK is y?
> > (and similarly for dma_set_coherent_mask()
On Sun, 2017-06-18 at 00:13 -0700, Christoph Hellwig wrote:
> On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote:
> > What is your rationale here ? (I have missed patch 0 it seems).
>
> Less code duplication, more modular dma_map_ops insteance.
>
On Fri, 2017-06-16 at 20:10 +0200, Christoph Hellwig wrote:
> Besides removing the last instance of the set_dma_mask method this also
> reduced the code duplication.
What is your rationale here ? (I have missed patch 0 it seems).
dma_supported() was supposed to be pretty much a "const" function
On Wed, 2015-07-29 at 10:17 +0200, Paolo Bonzini wrote:
On 29/07/2015 02:47, Andy Lutomirski wrote:
If new kernels ignore the IOMMU for devices that don't set the flag
and there are physical devices that already exist and don't set the
flag, then those devices won't work reliably on
On Tue, 2015-07-28 at 17:47 -0700, Andy Lutomirski wrote:
Yes, virtio flag. I dislike having a virtio flag at all, but so far
no one has come up with any better ideas. If there was a reliable,
cross-platform mechanism for per-device PCI bus properties, I'd be all
for using that instead.
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support.
New kernels acknowledge that flag on any device that advertises it.
New kernels always respect the IOMMU (except on PowerPC).
Why ? I disagree,
On Tue, 2015-07-28 at 16:33 -0700, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 4:21 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
Let me try to summarize a proposal:
Add a feature flag that indicates IOMMU support
On Tue, 2015-07-28 at 10:16 +0200, Paolo Bonzini wrote:
On 28/07/2015 03:08, Andy Lutomirski wrote:
On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net
wrote:
This fixes virtio on Xen guests as well as on any other platform
that uses virtio_pci on which physical
On Thu, 2015-07-02 at 20:49 +0200, Luis R. Rodriguez wrote:
The question then is what is the right thing. In the powerpc case,
we'll have a non-garded mapping, which means we also get no ordering
between load and stores.
I don't follow, you *ordering* between load and stores for WC? We
On Fri, 2015-06-26 at 15:41 -0700, Luis R. Rodriguez wrote:
It wasn't nullified for the main user at the time, the fb. And I
mentioned an IB adapter or two for which the code had been hand
tuned.
This still means there could be some affected drivers when used on
powerpc, no?
Yes. In
On Fri, 2015-06-26 at 21:31 +0200, Luis R. Rodriguez wrote:
Yeah either, we need to fix our relaxed implementation (patch
welcome :-)
Yikes, so although powerpc has useful heuristics to automatically
enable WC the default write ops have been nullifying its effects?
The heuristic is for
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote:
Hhmmm, so what do PowerPC Drivers do when they want to take
advantage of Write Combining? Do their own Endian Swizzling
with the __raw_*() APIs?
Yeah either, we need to fix our relaxed implementation (patch
welcome :-)
Cheers,
Ben.
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote:
Ah, thanks. I see now that the __raw_*() APIs don't do any of the
Endian Swizzling. Unfortunately the *_relaxed() APIs on PowerPC
are just defined as the normal *() routines. From
arch/powerpc/include/asm/io.h:
/*
* We
On Wed, 2015-06-24 at 18:22 -0700, Luis R. Rodriguez wrote:
Although I had test compiled this before just to be safe I went ahead and
successfully test-compiled this set with allmodconfig, specially since I've
now
removed the exports for the devres routines. Please let me know if these
On Wed, 2015-06-24 at 18:38 +0200, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe
On Wed, 2015-06-24 at 17:58 -0700, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 5:52 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
OK thanks I'll proceed with these patches then.
As for user mappings
On Wed, 2015-06-24 at 15:29 -0700, Luis R. Rodriguez wrote:
Nope but at least what made me squint at this being a possible
feature was that in practice when reviewing all of the kernels
pending device drivers using MTRR (potential write-combine candidates)
I encountered a slew of them which
On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
OK thanks I'll proceed with these patches then.
As for user mappings,
Which APIs were you considering in this regard BTW?
mmap of the generic /sys/bus/pci/.../resource*
maybe the right thing to do is to let us do what we do
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general
19 matches
Mail list logo
