09 Sep, 2015

1 commit

  • Pull libnvdimm updates from Dan Williams:
    "This update has successfully completed a 0day-kbuild run and has
    appeared in a linux-next release. The changes outside of the typical
    drivers/nvdimm/ and drivers/acpi/nfit.[ch] paths are related to the
    removal of IORESOURCE_CACHEABLE, the introduction of memremap(), and
    the introduction of ZONE_DEVICE + devm_memremap_pages().

    Summary:

    - Introduce ZONE_DEVICE and devm_memremap_pages() as a generic
    mechanism for adding device-driver-discovered memory regions to the
    kernel's direct map.

    This facility is used by the pmem driver to enable pfn_to_page()
    operations on the page frames returned by DAX ('direct_access' in
    'struct block_device_operations').

    For now, the 'memmap' allocation for these "device" pages comes
    from "System RAM". Support for allocating the memmap from device
    memory will arrive in a later kernel.

    - Introduce memremap() to replace usages of ioremap_cache() and
    ioremap_wt(). memremap() drops the __iomem annotation for these
    mappings to memory that do not have i/o side effects. The
    replacement of ioremap_cache() with memremap() is limited to the
    pmem driver to ease merging the api change in v4.3.

    Completion of the conversion is targeted for v4.4.

    - Similar to the usage of memcpy_to_pmem() + wmb_pmem() in the pmem
    driver, update the VFS DAX implementation and PMEM api to provide
    persistence guarantees for kernel operations on a DAX mapping.

    - Convert the ACPI NFIT 'BLK' driver to map the block apertures as
    cacheable to improve performance.

    - Miscellaneous updates and fixes to libnvdimm including support for
    issuing "address range scrub" commands, clarifying the optimal
    'sector size' of pmem devices, a clarification of the usage of the
    ACPI '_STA' (status) property for DIMM devices, and other minor
    fixes"

    * tag 'libnvdimm-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (34 commits)
    libnvdimm, pmem: direct map legacy pmem by default
    libnvdimm, pmem: 'struct page' for pmem
    libnvdimm, pfn: 'struct page' provider infrastructure
    x86, pmem: clarify that ARCH_HAS_PMEM_API implies PMEM mapped WB
    add devm_memremap_pages
    mm: ZONE_DEVICE for "device memory"
    mm: move __phys_to_pfn and __pfn_to_phys to asm/generic/memory_model.h
    dax: drop size parameter to ->direct_access()
    nd_blk: change aperture mapping from WC to WB
    nvdimm: change to use generic kvfree()
    pmem, dax: have direct_access use __pmem annotation
    dax: update I/O path to do proper PMEM flushing
    pmem: add copy_from_iter_pmem() and clear_pmem()
    pmem, x86: clean up conditional pmem includes
    pmem: remove layer when calling arch_has_wmb_pmem()
    pmem, x86: move x86 PMEM API to new pmem.h header
    libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option
    pmem: switch to devm_ allocations
    devres: add devm_memremap
    libnvdimm, btt: write and validate parent_uuid
    ...

    Linus Torvalds
     

25 Aug, 2015

1 commit

  • 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 a prefetchable region.

    Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take
    advantage of write combining when they know it's safe.

    On architectures that don't fully support WC, e.g., x86 without
    PAT, drivers for legacy framebuffers may get some of the benefit
    by using arch_phys_wc_add() in addition to pci_iomap_wc(). But
    arch_phys_wc_add() is unreliable and should be avoided in
    general. On x86, it uses MTRRs, which are limited in number and
    size, so the results will vary based on driver loading order.

    The goals of adding pci_iomap_wc() are to:

    - Give drivers an architecture-independent way to use WC so they can stop
    using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
    PAT when available).

    - Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
    on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
    performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
    and pci_mmap_page_range()").

    Signed-off-by: Luis R. Rodriguez
    [ Move IORESOURCE_IO check up, space out statements for better readability. ]
    Signed-off-by: Borislav Petkov
    Acked-by: Arnd Bergmann
    Cc:
    Cc:
    Cc: Andrew Morton
    Cc: Andy Lutomirski
    Cc: Antonino Daplas
    Cc: Bjorn Helgaas
    Cc: Daniel Vetter
    Cc: Dave Airlie
    Cc: Dave Hansen
    Cc: Davidlohr Bueso
    Cc: H. Peter Anvin
    Cc: Jean-Christophe Plagniol-Villard
    Cc: Juergen Gross
    Cc: Linus Torvalds
    Cc: Mel Gorman
    Cc: Michael S. Tsirkin
    Cc: Peter Zijlstra
    Cc: Roger Pau Monné
    Cc: Rusty Russell
    Cc: Stefan Bader
    Cc: Suresh Siddha
    Cc: Thomas Gleixner
    Cc: Tomi Valkeinen
    Cc: Toshi Kani
    Cc: Ville Syrjälä
    Cc: Vlastimil Babka
    Cc: airlied@linux.ie
    Cc: benh@kernel.crashing.org
    Cc: dan.j.williams@intel.com
    Cc: david.vrabel@citrix.com
    Cc: jbeulich@suse.com
    Cc: konrad.wilk@oracle.com
    Cc: linux-arch@vger.kernel.org
    Cc: linux-fbdev@vger.kernel.org
    Cc: linux-pci@vger.kernel.org
    Cc: venkatesh.pallipadi@intel.com
    Cc: vinod.koul@intel.com
    Cc: xen-devel@lists.xensource.com
    Link: http://lkml.kernel.org/r/1440443613-13696-6-git-send-email-mcgrof@do-not-panic.com
    Signed-off-by: Ingo Molnar

    Luis R. Rodriguez
     

11 Aug, 2015

1 commit

  • Quoting Arnd:
    I was thinking the opposite approach and basically removing all uses
    of IORESOURCE_CACHEABLE from the kernel. There are only a handful of
    them.and we can probably replace them all with hardcoded
    ioremap_cached() calls in the cases they are actually useful.

    All existing usages of IORESOURCE_CACHEABLE call ioremap() instead of
    ioremap_nocache() if the resource is cacheable, however ioremap() is
    uncached by default. Clearly none of the existing usages care about the
    cacheability. Particularly devm_ioremap_resource() never worked as
    advertised since it always fell back to plain ioremap().

    Clean this up as the new direction we want is to convert
    ioremap_() usages to memremap(..., flags).

    Suggested-by: Arnd Bergmann
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Dan Williams

    Dan Williams
     

21 Jan, 2015

1 commit

  • Virtio drivers should map the part of the BAR they need, not necessarily
    all of it.

    Cc: Bjorn Helgaas
    Cc: linux-pci@vger.kernel.org
    Acked-by: Arnd Bergmann
    Signed-off-by: Michael S. Tsirkin
    Signed-off-by: Rusty Russell

    Michael S. Tsirkin
     

01 Feb, 2012

1 commit


29 Nov, 2011

1 commit