Neither fbmem_peek() nor fbmem_poke() require to disable pagefaults and
preemption as a side effect of io_mapping_map_atomic_wc().
Use io_mapping_map_local_wc() instead.
Signed-off-by: Thomas Gleixner
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: no
None of these mapping requires the side effect of disabling pagefaults and
preemption.
Use io_mapping_map_local_wc() instead, rename the related functions
accordingly and clean up qxl_process_single_command() to use a plain
copy_from_user() as the local maps are not disabling pagefaults.
Signed-o
Instead of storing the map per CPU provide and use per task storage. That
prepares for local kmaps which are preemptible.
The context switch code is preparatory and not yet in use because
kmap_atomic() runs with preemption disabled. Will be made usable in the
next step.
The context switch logic i
Move the gory details of kmap & al into a private header and only document
the interfaces which are usable by drivers.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem-internal.h | 174 +
include/linux/highmem.h | 270 ++---
Now that the scheduler can deal with migrate disable properly, there is no
real compelling reason to make it only available for RT.
There are quite some code pathes which needlessly disable preemption in
order to prevent migration and some constructs like kmap_atomic() enforce
it implicitly.
Maki
All users gone.
Signed-off-by: Thomas Gleixner
---
include/linux/highmem.h | 63 +++-
mm/highmem.c|7 -
2 files changed, 5 insertions(+), 65 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -86,31 +86,1
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
---
V3: Remove the kmap types cruft
---
arch/sparc/Kconfig |1
arch/sparc/include/asm/highmem.h|8 +-
arch/sparc/include/asm/kma
For some obscure reason when CONFIG_DEBUG_HIGHMEM is enabled the stack
depth is increased from 20 to 41. But the only thing DEBUG_HIGHMEM does is
to enable a few BUG_ON()'s in the mapping code.
That's a leftover from the historical mapping code which had fixed entries
for various purposes. DEBUG_H
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
V3: Remove the kmap types cruft
---
arch/mips/Kconfig |1
arch/mips/include/asm/fixmap.h |4 -
arch/mips/include/asm/highm
Adopt the map ordering to match the other architectures and the generic
code. Also make the maximum entries limited and not dependend on the number
of CPUs. With the original implementation did the following calculation:
nr_slots = mapsize >> PAGE_SHIFT;
The results in either 512 or 1024 total
Convert X86 to the generic kmap atomic implementation and make the
iomap_atomic() naming convention consistent while at it.
Signed-off-by: Thomas Gleixner
Cc: x...@kernel.org
---
V3: Remove the kmap_types cruft
---
arch/x86/Kconfig |3 +
arch/x86/include/asm/fixmap.h
Historical leftovers from the time where kmap() had fixed slots.
Signed-off-by: Thomas Gleixner
Cc: Alexander Viro
Cc: Benjamin LaHaise
Cc: linux-fsde...@vger.kernel.org
Cc: linux-...@kvack.org
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-bt...@vger.kernel.org
---
fs/aio.c
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org
---
V3: Remove the kmap types cruft
---
arch/arm/Kconfig |1
arch/arm/include/asm/fixmap.h |4 -
arch/a
kmap_types.h is a misnomer because the old atomic MAP based array does not
exist anymore and the whole indirection of architectures including
kmap_types.h is inconinstent and does not allow to provide guard page
debugging for this misfeature.
Add a common header file which defines the mapping stac
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
---
V3: Remove the kmap types cruft
---
arch/powerpc/Kconfig |1
arch/powerpc/include/
The mapping code is odd and looks broken. See FIXME in the comment.
Also fix the harmless off by one in the FIX_KMAP_END define.
Signed-off-by: Thomas Gleixner
Cc: Nick Hu
Cc: Greentime Hu
Cc: Vincent Chen
---
V3: Remove the kmap types cruft
---
arch/nds32/Kconfig.cpu |1
arch
Nothing uses totalhigh_pages_dec() and totalhigh_pages_set().
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem.h | 10 --
1 file changed, 10 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -104,21 +104,11 @@ static inline void tota
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523...@linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achie
For whatever reasons SH has highmem bits all over the place but does
not enable it via Kconfig. Remove the bitrot.
Signed-off-by: Thomas Gleixner
---
arch/sh/include/asm/fixmap.h |8
arch/sh/include/asm/kmap_types.h | 15 ---
arch/sh/mm/init.c|8
The kmap_atomic* interfaces in all architectures are pretty much the same
except for post map operations (flush) and pre- and post unmap operations.
Provide a generic variant for that.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: linux...@kvack.org
---
V3: Do not reuse the kmap_atomic_i
Nothing in modules can use that.
Signed-off-by: Thomas Gleixner
Reviewed-by: Christoph Hellwig
Cc: Andrew Morton
Cc: linux...@kvack.org
---
mm/highmem.c |2 --
1 file changed, 2 deletions(-)
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -108,8 +108,6 @@ static inline wait_queue_head_t *get_pkm
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: linux-c...@vger.kernel.org
---
V3: Does not compile with gcc 10
---
arch/csky/Kconfig |1
arch/csky/include/asm/fixmap.h |4 +-
arch/csky/include/asm/highmem.h |6 ++-
arch/csky/m
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: Michal Simek
---
V3: Remove the kmap types cruft
---
arch/microblaze/Kconfig |1
arch/microblaze/include/asm/fixmap.h |4 -
arch/microblaze/include/asm/highmem.h |6 ++
arch/micr
Chris Wilson writes:
> Add another lower level to emit_ggtt_write so that the GGTT nature of
> the write is not hardcoded into the emitter.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 55 --
> 1 file changed, 35 insertions(+), 20 dele
Quoting Tvrtko Ursulin (2020-11-03 11:14:32)
>
>
> On 03/11/2020 02:53, Lu Baolu wrote:
> > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
> >>
> >> On 02/11/2020 02:00, Lu Baolu wrote:
> >>> Hi Tvrtko,
> >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
>
> On 29/09/2020 01:11, Lu Baolu wrote:
Hi Stephen,
On Tue, Nov 03, 2020 at 11:31:21AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/gpu/drm/vc4/vc4_drv.c: In function 'vc4_drm_unbind':
> drivers/gpu/drm/vc4/vc4
On 03/11/2020 02:53, Lu Baolu wrote:
On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
On 02/11/2020 02:00, Lu Baolu wrote:
Hi Tvrtko,
On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
On 29/09/2020 01:11, Lu Baolu wrote:
Hi Tvrtko,
On 9/28/20 5:44 PM, Tvrtko Ursulin wrote:
On 27/09/2020 07:34, Lu Ba
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We may create page table objects on the fly, but we may need to
wait with the ww lock held. Instead of waiting on a freed obj
lock, ensure we have the same lock for each object to keep
-EDEADLK working. This ensures that i915_vma_pin_ww can lock
the
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Quick fix, just use the unlocked version.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Because of the long lifetime of the mapping, we cannot wrap this in a
simple limited ww lock. Just use the unlocked version of pin_map,
because we'll likely release the mapping a lot later, in a different
thread.
Signed-off-by: Maarten Lankhorst
-
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
vmap is using pin_pages, but needs to use ww locking,
add pin_pages_unlocked to correctly lock the mapping.
Also add ww locking to begin/end cpu access.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
_
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
In the ucode functions, the calls are done before userspace runs,
when debugging using debugfs, or when creating semi-permanent mappings;
we can safely use the unlocked versions that does the ww dance for us.
Because there is no pin_pages_unlocked
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We need to lock a few more objects, some temporarily,
add ww lock where needed.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesk
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
i915_gem_object_pin_map potentially needs a ww context, so ensure we
have one we can revoke.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 24 ++--
1 file changed, 22 insertions(+), 2 deleti
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
By default, we assume that it's called inside igt_create_request
to keep existing selftests working, but allow for manual pinning
when passing a ww context.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
__
101 - 135 of 135 matches
Mail list logo
