lkml.org 
[lkml]   [2015]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
    From
    Date
    On Fri, 2015-06-26 at 16:24 +0000, Casey Leedom wrote:
    > Thanks for looking into this Ben. As it stands now, it seems as
    > if Write Combined mappings simply aren't supported and/or all
    > driver writers trying to utilize Write Combined mappings have to
    > "hand roll" their own solutions which really isn't supportable.
    >
    > One thing that might be considered is simply to treat the desire
    > to utilize the Write Combining hardware as a separate issue and
    > develop writel_wc(), writeq_wc(), etc. Those could be defined
    > as legal only for Write Combined Mappings and would "do the
    > right thing" for each architecture.

    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.

    > The initial implementations
    > could simply be writel(), writeq(), etc. till each architecture'si
    > ssues were investigated and understood.
    >
    > Additionally, it would be very useful to have some sort of
    > predicate which could be used to determine if an architecture
    > supported Write Combining. 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 [benh@kernel.crashing.org]
    > Sent: Thursday, June 25, 2015 7:02 PM
    > To: Casey Leedom
    > Cc: Arnd Bergmann; Luis R. Rodriguez; Michael S. Tsirkin; Bjorn Helgaas; Toshi Kani; Andy Lutomirski; Juergen Gross; Tomi Valkeinen; linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; xen-devel@lists.xensource.com; linux-fbdev; Suresh Siddha; Ingo Molnar; Thomas Gleixner; Daniel Vetter; Dave Airlie; Antonino Daplas; Jean-Christophe Plagniol-Villard; Dave Hansen; venkatesh.pallipadi@intel.com; Stefan Bader; ville.syrjala@linux.intel.com; David Vrabel; Jan Beulich; Roger Pau Monné
    > Subject: Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
    >
    > On Thu, 2015-06-25 at 21:40 +0000, 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 don't do relaxed operations yet, at least not with this
    > > semantic
    > > */
    >
    > Yes so I was looking at this but there are some difficulties.
    > Architecturally, even with I=1 G=1 mappings (normal ioremap), we have no
    > guarantee of ordering of load vs. store unless I misunderstood
    > something. I think all current implementations provide some of that but
    > without barriers in the accessors, we aren't architecturally correct.
    >
    > However, having those barriers will cause issues with G=0 (write
    > combine). It's unclear whether eieio() will provide the required
    > ordering for I=1 G=0 mappings and it will probably break write combine.
    >
    > I'm looking into it with our HW guys and will try to come up with a
    > solution for power, but it doesn't help that our memory model conflates
    > write combining with other relaxations and that all our barriers also
    > prevent write combine.
    >
    > Maybe we can bias the relaxed accessors toward write, by having no
    > barriers in it, and putting extra ones in reads.
    >
    > Cheers,
    > Ben.
    >
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html




    \
     
     \ /
      Last update: 2015-06-27 00:41    [W:2.983 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site