24 Aug, 2016

2 commits

  • Somehow architectures can't agree on this. And for good measure make
    sure we have a fallback which should work everywhere (fingers
    crossed).

    v2: Make it compile properly, needs a defined() for the #elif.

    Fixes: ac96b5566926 ("io-mapping.h: s/PAGE_KERNEL_IO/PAGE_KERNEL/")
    Cc: Chris Wilson
    Cc: Daniel Vetter
    Cc: Joonas Lahtinen
    Cc: linux-mm@kvack.org
    Reviewed-by: Chris Wilson
    Reviewed-by: Joonas Lahtinen
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/20160823202233.4681-1-daniel.vetter@ffwll.ch
    (cherry picked from commit 80c33624e4723c4e22d9917cd676067ebf652dc2)

    Daniel Vetter
     
  • PAGE_KERNEL_IO is an x86-ism. Though it is used to define the pgprot_t
    used for the iomapped region, it itself is just PAGE_KERNEL. On all
    other arches, PAGE_KERNEL_IO is undefined so in a general header we must
    refrain from using it.

    v2: include pgtable for pgprot_combine()

    Reported-by: Stephen Rothwell
    Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the io-mapping")
    Signed-off-by: Chris Wilson
    Cc: Daniel Vetter
    Cc: Joonas Lahtinen
    Cc: linux-mm@kvack.org
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/20160823155024.22379-1-chris@chris-wilson.co.uk
    (cherry picked from commit ac96b5566926af83463ddcf4655856033c092f26)

    Chris Wilson
     

20 Aug, 2016

1 commit

  • Currently, we only allocate a structure to hold metadata if we need to
    allocate an ioremap for every access, such as on x86-32. However, it
    would be useful to store basic information about the io-mapping, such as
    its page protection, on all platforms.

    Signed-off-by: Chris Wilson
    Cc: linux-mm@kvack.org
    Reviewed-by: Joonas Lahtinen
    Link: http://patchwork.freedesktop.org/patch/msgid/20160819155428.1670-4-chris@chris-wilson.co.uk

    Chris Wilson
     

28 Apr, 2016

1 commit

  • The ioremap() hidden behind the io_mapping_map_wc() convenience helper
    can be used for remapping multiple pages. Extend the helper so that
    future callers can use it for larger ranges.

    Signed-off-by: Chris Wilson
    Cc: Tvrtko Ursulin
    Cc: Daniel Vetter
    Cc: Jani Nikula
    Cc: David Airlie
    Cc: Yishai Hadas
    Cc: Dan Williams
    Cc: Ingo Molnar
    Cc: "Peter Zijlstra (Intel)"
    Cc: David Hildenbrand
    Cc: Luis R. Rodriguez
    Cc: intel-gfx@lists.freedesktop.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: netdev@vger.kernel.org
    Cc: linux-rdma@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Reviewed-by: Luis R. Rodriguez
    Link: http://patchwork.freedesktop.org/patch/msgid/1461833819-3991-3-git-send-email-chris@chris-wilson.co.uk

    Chris Wilson
     

11 Aug, 2015

1 commit


19 May, 2015

1 commit

  • The existing code relies on pagefault_disable() implicitly disabling
    preemption, so that no schedule will happen between kmap_atomic() and
    kunmap_atomic().

    Let's make this explicit, to prepare for pagefault_disable() not
    touching preemption anymore.

    Reviewed-and-tested-by: Thomas Gleixner
    Signed-off-by: David Hildenbrand
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: David.Laight@ACULAB.COM
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: airlied@linux.ie
    Cc: akpm@linux-foundation.org
    Cc: benh@kernel.crashing.org
    Cc: bigeasy@linutronix.de
    Cc: borntraeger@de.ibm.com
    Cc: daniel.vetter@intel.com
    Cc: heiko.carstens@de.ibm.com
    Cc: herbert@gondor.apana.org.au
    Cc: hocko@suse.cz
    Cc: hughd@google.com
    Cc: mst@redhat.com
    Cc: paulus@samba.org
    Cc: ralf@linux-mips.org
    Cc: schwidefsky@de.ibm.com
    Cc: yang.shi@windriver.com
    Link: http://lkml.kernel.org/r/1431359540-32227-5-git-send-email-dahi@linux.vnet.ibm.com
    Signed-off-by: Ingo Molnar

    David Hildenbrand
     

05 Mar, 2012

1 commit

  • If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
    other BUG variant in a static inline (i.e. not in a #define) then
    that header really should be including and not just
    expecting it to be implicitly present.

    We can make this change risk-free, since if the files using these
    headers didn't have exposure to linux/bug.h already, they would have
    been causing compile failures/warnings.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

28 Oct, 2011

1 commit

  • * 'drm-core-next' of git://people.freedesktop.org/~airlied/linux: (290 commits)
    Revert "drm/ttm: add a way to bo_wait for either the last read or last write"
    Revert "drm/radeon/kms: add a new gem_wait ioctl with read/write flags"
    vmwgfx: Don't pass unused arguments to do_dirty functions
    vmwgfx: Emulate depth 32 framebuffers
    drm/radeon: Lower the severity of the radeon lockup messages.
    drm/i915/dp: Fix eDP on PCH DP on CPT/PPT
    drm/i915/dp: Introduce is_cpu_edp()
    drm/i915: use correct SPD type value
    drm/i915: fix ILK+ infoframe support
    drm/i915: add DP test request handling
    drm/i915: read full receiver capability field during DP hot plug
    drm/i915/dp: Remove eDP special cases from bandwidth checks
    drm/i915/dp: Fix the math in intel_dp_link_required
    drm/i915/panel: Always record the backlight level again (but cleverly)
    i915: Move i915_read/write out of line
    drm/i915: remove transcoder PLL mashing from mode_set per specs
    drm/i915: if transcoder disable fails, say which
    drm/i915: set watermarks for third pipe on IVB
    drm/i915: export a CPT mode set verification function
    drm/i915: fix transcoder PLL select masking
    ...

    Linus Torvalds
     

21 Oct, 2011

1 commit

  • For the !HAVE_ATOMIC_IOMAP case the stub functions did not call
    pagefault_disable/_enable. The i915 driver relies on the map
    actually being atomic, otherwise it can deadlock with it's own
    pagefault handler in the gtt pwrite fastpath.

    This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem
    testsuite.

    v2: Chris Wilson noted the lack of an include.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115
    Cc: stable@kernel.org
    Signed-off-by: Daniel Vetter
    Reviewed-by: Chris Wilson
    Signed-off-by: Keith Packard

    Daniel Vetter
     

28 Sep, 2011

1 commit

  • There are numerous broken references to Documentation files (in other
    Documentation files, in comments, etc.). These broken references are
    caused by typo's in the references, and by renames or removals of the
    Documentation files. Some broken references are simply odd.

    Fix these broken references, sometimes by dropping the irrelevant text
    they were part of.

    Signed-off-by: Paul Bolle
    Signed-off-by: Jiri Kosina

    Paul Bolle
     

27 Oct, 2010

1 commit

  • Keep the current interface but ignore the KM_type and use a stack based
    approach.

    The advantage is that we get rid of crappy code like:

    #define __KM_PTE \
    (in_nmi() ? KM_NMI_PTE : \
    in_irq() ? KM_IRQ_PTE : \
    KM_PTE0)

    and in general can stop worrying about what context we're in and what kmap
    slots might be appropriate for that.

    The downside is that FRV kmap_atomic() gets more expensive.

    For now we use a CPP trick suggested by Andrew:

    #define kmap_atomic(page, args...) __kmap_atomic(page)

    to avoid having to touch all kmap_atomic() users in a single patch.

    [ not compiled on:
    - mn10300: the arch doesn't actually build with highmem to begin with ]

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
    Acked-by: Rik van Riel
    Signed-off-by: Peter Zijlstra
    Acked-by: Chris Metcalf
    Cc: David Howells
    Cc: Hugh Dickins
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc: Steven Rostedt
    Cc: Russell King
    Cc: Ralf Baechle
    Cc: David Miller
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Dave Airlie
    Cc: Li Zefan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Zijlstra
     

05 Sep, 2010

1 commit


12 Aug, 2010

1 commit


05 Aug, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

27 Aug, 2009

1 commit

  • io_mapping_* interfaces were added, mainly for graphics drivers.
    Make this interface go through the PAT reserve/free, instead of
    hardcoding WC mapping. This makes sure that there are no
    aliases due to unconditional WC setting.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Suresh Siddha
    Signed-off-by: H. Peter Anvin

    Venkatesh Pallipadi
     

02 Mar, 2009

1 commit


25 Feb, 2009

1 commit

  • io_mapping_create_wc should take a resource_size_t parameter in place of
    unsigned long. With unsigned long, there will be no way to map greater than 4GB
    address in i386/32 bit.

    On x86, greater than 4GB addresses cannot be mapped on i386 without PAE. Return
    error for such a case.

    Patch also adds a structure for io_mapping, that saves the base, size and
    type on HAVE_ATOMIC_IOMAP archs, that can be used to verify the offset on
    io_mapping_map calls.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Suresh Siddha
    Cc: Dave Airlie
    Cc: Jesse Barnes
    Cc: Eric Anholt
    Cc: Keith Packard
    Signed-off-by: Ingo Molnar

    Venkatesh Pallipadi
     

04 Nov, 2008

1 commit

  • Impact: cleanup

    clean up ifdefs: change #ifdef CONFIG_X86_32/64 to
    CONFIG_HAVE_ATOMIC_IOMAP.

    flip around the #ifdef sections to clean up the structure.

    Signed-off-by: Keith Packard
    Signed-off-by: Ingo Molnar

    Keith Packard
     

31 Oct, 2008

1 commit

  • Impact: add new generic io_map_*() APIs

    Graphics devices have large PCI apertures which would consume a significant
    fraction of a 32-bit address space if mapped during driver initialization.
    Using ioremap at runtime is impractical as it is too slow.

    This new set of interfaces uses atomic mappings on 32-bit processors and a
    large static mapping on 64-bit processors to provide reasonable 32-bit
    performance and optimal 64-bit performance.

    The current implementation sits atop the io_map_atomic fixmap-based
    mechanism for 32-bit processors.

    This includes some editorial suggestions from Randy Dunlap for
    Documentation/io-mapping.txt

    Signed-off-by: Keith Packard
    Signed-off-by: Eric Anholt
    Signed-off-by: Ingo Molnar

    Keith Packard