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
s
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 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() wh
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> 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 to use it
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"
> > >
> > > PCI BARs
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 wh
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 wha
On Wed, 2015-06-24 at 17:58 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 24, 2015 at 5:52 PM, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
> >>
> >> OK thanks I'll proceed with these patches the
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 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 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:
>
> /*
>
bining. Our drivers would use this to
> eliminate a wasteful attempt to use write combining on those
> architectures where it didn't work.
>
> Casey
>
>
> From: Benjamin Herrenschmidt [b...@kernel.crashing.org]
> Sent: Thursday, June
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
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.
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
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
> > wrote:
> >> This fixes virtio on Xen guests as well as on any other platform
> >> that uses virtio_pci on which physical addresses don'
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 disa
On Tue, 2015-07-28 at 16:33 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 4:21 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote:
> >> Let me try to summarize a proposal:
> >>
> >> Add a fe
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 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 wor
20 matches
Mail list logo
