Hi Chun-Kuang,
On 20/11/2020 00:46, Chun-Kuang Hu wrote:
Hi, Matthias:
I've provided the example for why of this patch. How do you think
about this patch?
Patch looks good to me. If you want to take it through your tree you can add my
Acked-by: Matthias Brugger
Beware that you might need a
On 25/11/2020 11:07, Daniel Vetter wrote:
>> Laurent, does this ring any bells? The WARN comes in
>> drm_atomic_bridge_chain_enable() when
>> drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge.
>>
>> I'm not sure why the bridge state would not be there.
>
> Lack of state
Extend speed-bin support to a618 gpu.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e0ff16c..21db7ae 100644
--- a/d
So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.
Signed-off-by: Akhil P Oommen
---
Changes from v1:
1. Added t
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6678
On 11/16/2020 10:44 PM, Jordan Crouse wrote:
On Mon, Nov 16, 2020 at 07:40:03PM +0530, Akhil P Oommen wrote:
On 11/12/2020 10:05 PM, Jordan Crouse wrote:
On Thu, Nov 12, 2020 at 09:19:04PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a fu
When the SDI output was converted to DRM bridge, the atomic versions of
enable and disable funcs were used. This was not intended, as that would
require implementing other atomic funcs too. This leads to:
WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708
drm_atomic_helper_commit_modeset
Hey Daniel, just a ping on a bunch of questions i posted bellow.
Andtey
From: Grodzovsky, Andrey
Sent: 25 November 2020 14:34
To: Daniel Vetter ; Koenig, Christian
Cc: r...@kernel.org ; daniel.vet...@ffwll.ch
; dri-devel@lists.freedesktop.org
; e...@anholt.net
Hey, just a ping on my comments/question bellow.
Andrey
From: Grodzovsky, Andrey
Sent: 25 November 2020 12:39
To: Daniel Vetter
Cc: amd-gfx list ; dri-devel
; Christian König
; Rob Herring ; Lucas Stach
; Qiang Yu ; Anholt, Eric
; Pekka Paalanen ; Deucher, Al
Quoting Thomas Zimmermann (2020-11-24 13:38:16)
> Using struct drm_device.pdev is deprecated. Convert i915 to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
Any chance of sharing used a cocci scri
Quoting Matthew Auld (2020-11-27 12:06:08)
> Same old gem_create but with now with extensions support. This is needed
> to support various upcoming usecases. For now we use the extensions
> mechanism to support setting an immutable-priority-list of potential
> placements, at creation time.
>
> If
Hi Dave & Daniel -
Last feature pull for v5.11.
drm-intel-next-queued-2020-11-27:
drm/i915 features for v5.11:
Highlights:
- Enable big joiner to join two pipes to one port to overcome pipe restrictions
(Manasi, Ville, Maarten)
Display:
- More DG1 enabling (Lucas, Aditya)
- Fixes to cases wi
Quoting Matthew Auld (2020-11-27 12:06:09)
> From: Michel Thierry
>
> Signed-off-by: Michel Thierry
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/gt/intel_ring.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
Quoting Matthew Auld (2020-11-27 12:06:13)
> From: Zbigniew Kempczyński
>
> IGTs should be able to choose testing strategy depending on memory
> regions and its sizes. Add region instance number to make this
> easier and descriptive.
>
> Cc: Matthew Auld
> Cc: Ramalingam C
> Cc: Tvrtko Ursulin
Quoting Matthew Auld (2020-11-27 12:06:14)
> We need to general our accessor for the page directories and tables from
> using the simple kmap_atomic to support local memory, and this setup
> must be done on acquisition of the backing storage prior to entering
> fence execution contexts. Here we rep
Quoting Matthew Auld (2020-11-27 12:06:17)
> For the PTEs we get an LM bit, to signal whether the page resides in
> SMEM or LMEM.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Abdiel Janulgue
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Niranjana Vishwanathapura
> Si
Quoting Matthew Auld (2020-11-27 12:06:19)
> Based on a patch from Michel Thierry.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Abdiel Janulgue
> ---
> .../drm/i915/gt/intel_execlists_submission.c | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
>
Hi
Am 27.11.20 um 14:20 schrieb Joonas Lahtinen:
Quoting Thomas Zimmermann (2020-11-24 13:38:16)
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Quoting Matthew Auld (2020-11-27 12:06:34)
> From: Imre Deak
>
> On DG1 A0/B0 steppings the first 1MB of local memory must be reserved.
> One reason for this is that the 0xA-0xB range is not accessible
> by the display, probably since this region is redirected to another
> memory location
Quoting Matthew Auld (2020-11-27 12:06:40)
> From: Michel Thierry
Rationale goes here.
Is this wise? HWSP is very frequently read by the CPU, and expected to
be cached on the CPU.
What do the performance profiles indicate?
-Chris
___
dri-devel mailing
Quoting Matthew Auld (2020-11-27 12:06:41)
> From: Venkata Sandeep Dhanalakota
>
> when allocating pages to lmem object of size 4G or greater
> we allocate memory blocks from buddy system.
Any lmem object is from the buddy system.
> In this scenario
> buddy sytem can allocate blocks that can ha
Quoting Matthew Auld (2020-11-27 12:06:42)
> From: Bommu Krishnaiah
>
> Update shmem available memory in “intel_memory_region”
Was avail ever set?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
Quoting Matthew Auld (2020-11-27 12:06:44)
> From: CQ Tang
>
> Function i915_gem_shrink_memory_region() is changed to
> intel_memory_region_evict() and moved from i915_gem_shrinker.c
> to intel_memory_region.c, this function is used to handle local
> memory swapping, in addition to evict purgeabl
Quoting Matthew Auld (2020-11-27 12:06:49)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1366b53ac8c9..7b1e95d494e6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1214,6 +1214,9 @@ struct drm_i915_private {
>
Am 27.11.20 um 09:31 schrieb Dave Airlie:
Oops sorry for delay LGTM
Reviewed-by: Dave Airlie
Thanks.
On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 3:34 PM Christian König
wrote:
Reorder the code to fix checking if blitting is available.
Might be good to ex
Quoting Matthew Auld (2020-11-27 12:06:50)
> From: Sudeep Dutt
>
> Signed-off-by: Sudeep Dutt
> ---
> drivers/gpu/drm/i915/gem/i915_gem_region.c | 16 ++--
> drivers/gpu/drm/i915/i915_debugfs.c| 3 +++
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> 3 files changed,
Ping? Daniel any more ideas on this or should we push it?
Thanks,
Christian.
Am 25.11.20 um 13:59 schrieb Christian König:
This is deprecated.
v2: also use ttm_sg_tt_init to avoid allocating the page array.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 11 ++-
Check the pin_count instead of the lru list is empty here.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9a03c7834b1e..a0bddcc64504 100644
---
We only completely delete the BO from the LRU on destruction.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +-
drivers/gpu/drm/qxl/qxl_release.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 60 +++---
drivers/gpu/drm/ttm/ttm_execbuf
Quoting Matthew Auld (2020-11-27 12:06:53)
> +int i915_window_blt_copy(struct drm_i915_gem_object *dst,
> +struct drm_i915_gem_object *src)
> +{
> + struct drm_i915_private *i915 = to_i915(src->base.dev);
> + struct intel_context *ce = i915->gt.engine[BCS0]->blit
Quoting Matthew Auld (2020-11-27 12:06:56)
> From: Ramalingam C
>
> window_blt_copy feature is used for swapin and swapout based on the i915
> module parameter called enable_eviction.
A module parameter?
-Chris
___
dri-devel mailing list
dri-devel@list
Quoting Matthew Auld (2020-11-27 12:06:57)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 82f431cc38cd..6f0ab363bdee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1225,6 +1225,11 @@ struct drm_i915_private {
>
Quoting Matthew Auld (2020-11-27 12:06:59)
> +static int intel_dmem_evict_buffers(struct drm_device *dev, bool in_suspend)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct drm_i915_gem_object *obj;
> + struct intel_memory_region *mem;
> + int id, ret = 0;
>
Quoting Matthew Auld (2020-11-27 12:07:00)
> From: Venkata Ramana Nayana
>
> We are only doing it now for kernel_context. We also need to do for the
> copy engine blitter context.
>
> Signed-off-by: Venkata Ramana Nayana
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +
> 1 file ch
Quoting Matthew Auld (2020-11-27 12:07:02)
> From: Prathap Kumar Valsan
>
> During suspend we will lose all page tables as they are allocated in
> LMEM. In-order to make sure that the contexts do not access the
> corrupted page table after we restore, we are evicting all vma's that
> are bound t
Quoting Matthew Auld (2020-11-27 12:07:03)
> From: Venkata Ramana Nayana
>
> If record default objects are created in LMEM and in suspend
> pin the pages of obj (src) and use blitter for eviction. But
> during request creation using blitter context and try to pin the same
> default object, to res
Hi Daniel, Jani,
is it ok to merge this patch along with 2/2 via the i915 tree?
--Imre
On Mon, Nov 23, 2020 at 08:26:30PM +0200, Imre Deak wrote:
> From: Radhakrishna Sripada
>
> Gen12 display can decompress surfaces compressed by render engine with
> Clear Color, add a new modifier as the dri
Quoting Matthew Auld (2020-11-27 12:07:04)
> From: Venkata Ramana Nayana
>
> In suspend mode use blitter eviction before disable the runtime
> interrupts and in resume use blitter after the gem resume happens.
Consider add it to the suspend prepare function.
-Chris
__
Quoting Matthew Auld (2020-11-27 12:07:06)
> From: CQ Tang
>
> When cache_level is NONE, we check HAS_LLC(i915).
> But additionally for DGFX, we also need to check
> HAS_SNOOP(i915) on system memory object to use
> I915_BO_CACHE_COHERENT_FOR_READ. on dg1, has_llc=0, and
> has_snoop=1. Otherwise,
Quoting Matthew Auld (2020-11-27 12:07:13)
> From: Tvrtko Ursulin
>
> Current code uses jiffie time to do the accounting and then does:
>
> diff = jiffies - start;
> msec = diff * 1000 / HZ;
> ...
> atomic_long_add(msec, &i915->time_swap_out_ms);
>
> If we assume jiffie can be as non-gr
Hi, Matthias:
Matthias Brugger 於 2020年11月27日 週五 下午8:40寫道：
>
> Hi Chun-Kuang,
>
> On 20/11/2020 00:46, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > I've provided the example for why of this patch. How do you think
> > about this patch?
> >
>
> Patch looks good to me. If you want to take it throu
Quoting Matthew Auld (2020-11-27 12:07:16)
> From: Venkata Ramana Nayana
>
> This is to fix a bug in upstream
> commit a6326a4f8ffb ("drm/i915/gt: Keep a no-frills swappable copy of the
> default context state")
>
> We allocate context state obj ce->state from lmem, so in
> __engines_record_de
On Fri, Nov 27, 2020 at 3:10 PM Christian König
wrote:
>
> Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > Oops sorry for delay LGTM
> >
> > Reviewed-by: Dave Airlie
>
> Thanks.
>
> >
> > On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
> >> On Wed, Nov 25, 2020 at 3:34 PM Christian König
> >>
Am 27.11.20 um 15:46 schrieb Daniel Vetter:
On Fri, Nov 27, 2020 at 3:10 PM Christian König
wrote:
Am 27.11.20 um 09:31 schrieb Dave Airlie:
Oops sorry for delay LGTM
Reviewed-by: Dave Airlie
Thanks.
On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 3:34 PM Chri
On Thu, Nov 26, 2020 at 09:44:02AM +, Jonas Mark (BT-FIR/ENG1-Grb) wrote:
> Hi Daniel,
>
> > > Thank you very much for your feedback. We appreciate it.
> > >
> > > > >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> > > > >>> b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > >>> index 9bf5ad6d1
Hi Dave,
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.10-rc7
for you to fetch changes up to bf3a3cdcad40e592
On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote:
>
> On 11/25/20 11:36 AM, Daniel Vetter wrote:
> > On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote:
> > > Am 25.11.20 um 11:40 schrieb Daniel Vetter:
> > > > On Tue, Nov 24, 2020 at 05:44:07PM +0100, Christian König
On Wed, Nov 25, 2020 at 12:39:47PM -0500, Andrey Grodzovsky wrote:
>
> On 11/25/20 4:04 AM, Daniel Vetter wrote:
> > On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky
> > wrote:
> > >
> > > On 11/24/20 9:49 AM, Daniel Vetter wrote:
> > > > On Sat, Nov 21, 2020 at 12:21:20AM -0500, Andrey Grodzo
On Fri, Nov 27, 2020 at 03:11:05PM +0100, Christian König wrote:
> Ping? Daniel any more ideas on this or should we push it?
Occasionally I bit more prose would be nice about why things changed or
so. Iirc the reason I asked about using ttm_sg_tt_init is that it makes it
easier to convince ourselv
On Fri, Nov 27, 2020 at 03:49:31PM +0100, Christian König wrote:
> Am 27.11.20 um 15:46 schrieb Daniel Vetter:
> > On Fri, Nov 27, 2020 at 3:10 PM Christian König
> > wrote:
> > > Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > > > Oops sorry for delay LGTM
> > > >
> > > > Reviewed-by: Dave Airlie
On Fri, Nov 27, 2020 at 11:14:42AM +0800, Tian Tao wrote:
> if the driver uses drmm_vram_helper_init, there is no need to
> call drm_vram_helper_release_mm when the drm module get unloaded,
> as this will done automagically.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/vboxvideo/vbox_ttm.
On Fri, Nov 27, 2020 at 10:15:49AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 27, 2020 at 4:18 AM Randy Dunlap wrote:
> > It looks like SPARC64 requires FB_ATY_CT to build without errors,
> > so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
> > instead of using "default y if
On Fri, Nov 27, 2020 at 04:31:00PM +0200, Imre Deak wrote:
> Hi Daniel, Jani,
>
> is it ok to merge this patch along with 2/2 via the i915 tree?
Ack from mesa (userspace in general, but mesa is kinda mandatory) is
missing I think. With that
Acked-by: Daniel Vetter
>
> --Imre
>
> On Mon, Nov
On 11/27/20 10:04 AM, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 12:39:47PM -0500, Andrey Grodzovsky wrote:
On 11/25/20 4:04 AM, Daniel Vetter wrote:
On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky
wrote:
On 11/24/20 9:49 AM, Daniel Vetter wrote:
On Sat, Nov 21, 2020 at 12:21:20AM -050
On Fri, Nov 27, 2020 at 09:12:25AM -0400, Jason Gunthorpe wrote:
> On Thu, Nov 19, 2020 at 03:41:29PM +0100, Daniel Vetter wrote:
> > I feel like this is ready for some wider soaking. Since the remaining bits
> > are all kinda connnected probably simplest if it all goes through -mm.
>
> Did you fi
On Wed, Oct 28, 2020 at 01:11:51PM +0100, Christian König wrote:
> Am 28.10.20 um 12:31 schrieb Daniel Vetter:
> > Not technically a problem for ttm, but very likely a driver bug and
> > pretty big time confusing for reviewing code.
> >
> > So warn about it, both at cleanup time (so we catch these
On 27/11/2020 01:17, Ivaylo Dimitrov wrote:
> Hi Tomi,
>
> On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:
>> Hi Aaro, Ivaylo,
>>
>> On 24/11/2020 23:03, Ivaylo Dimitrov wrote:
>>
>>> Is there any progress on the issue? I tried 5.9.1 and still nothing
>>> displayed.
>>
>> Can you test the attached
On 27/11/2020 11:00, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
ret is not actually read after this (only written in one case then
returned), so this assign line is useless. This removes that assignment.
Signed-off-by: Carsten Haitzler
Reviewed-by: Steven Price
---
dri
On 27/11/2020 11:00, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
komeda_component_get_old_state() technically can return a NULL
pointer. komeda_compiz_set_input() even warns when this happens, but
then proceeeds to use that NULL pointer tocompare memory content there
agains the
On 11/27/20 9:59 AM, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote:
On 11/25/20 11:36 AM, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote:
Am 25.11.20 um 11:40 schrieb Daniel Vetter:
On Tue, Nov 24, 2020 at 05:44:0
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f9c81bc21ba4..301e93c9e
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index e67cec8f
Purely conjecture, but I think the original locking inversion with the
legacy page flip code between flipping and ttm's bo move function
shoudn't exist anymore with atomic: With atomic the bo pinning and
actual modeset commit is completely separated in the code patsh.
This annotation was originall
Hi all
Another update of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
https://lore.kernel.org/dri-devel/20201009075934.35090
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pt
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: And
These are persistent, not just for the duration of a dma operation.
Reviewed-by: Oded Gabbay
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
C
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical se
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Hans Verkuil
Acked-by: Mauro Carvalho Chehab
Acked-by: T
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from ded
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings,
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is lo
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.
But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer, sinc
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedic
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pt
The only safe way for non core/arch code to use follow_pfn() is
together with an mmu_notifier subscription. follow_pfn() is already
marked as _GPL and the kerneldoc explains this restriction.
This patch here enforces all this by adding a mmu_notifier argument
and verifying that it is registered fo
Both Christoph Hellwig and Jason Gunthorpe suggested that usage of
follow_pfn by modules should be locked down more. To do so callers
need to be able to pass the mmu_notifier subscription corresponding
to the mm_struct to follow_pfn().
This patch does the rote work of doing that in the kvm subsyst
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire u
On Fri, Nov 27, 2020 at 04:19:20PM +0100, Daniel Vetter wrote:
> On Fri, Nov 27, 2020 at 04:31:00PM +0200, Imre Deak wrote:
> > Hi Daniel, Jani,
> >
> > is it ok to merge this patch along with 2/2 via the i915 tree?
>
> Ack from mesa (userspace in general, but mesa is kinda mandatory) is
> missin
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends up with two eDP displays.
Information is taken from the official DCB documentati
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
---
drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on char-misc/char-misc-testing v5.10-rc5]
[cannot apply to hnaz-linux-mm/master next-20201127]
[If your patch is applied to the wrong git tree, kindly drop us a note
Quoting Matthew Auld (2020-11-27 12:06:08)
> +int
> +i915_gem_create_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct create_ext ext_data = { .i915 = i915 };
> + struct drm_i9
Quoting t...@redhat.com (2020-11-27 16:28:28)
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device
Quoting Matthew Auld (2020-11-27 12:04:37)
> In igt_ppgtt_sanity_check we should also exercise the non-contiguous
> option for LMEM, since this will give us slightly different sg layouts
> and alignment.
>
> Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
-Chris
___
Quoting Matthew Auld (2020-11-27 12:04:40)
> From: Chris Wilson
>
> Cleanup intel_lrc.h by moving some of the residual common register
> definitions into intel_lrc_reg.h, prior to rebranding and splitting off
> the submission backends.
>
> v2: keep the SCHEDULE enum in the old file, since it is
Quoting Matthew Auld (2020-11-27 12:04:41)
> From: Chris Wilson
>
> We want to separate the utility functions for controlling the logical
> ring context from the execlists submission mechanism (which is an
> overgrown scheduler).
>
> This is similar to Daniele's work to split up the files, but b
Following the great work of Lee Jones in other subsystems
here is a set of patches that address all remaining W=1
warnings in drivers/video/.
Lee Jones already fixed all warnings in video/backlight/ so
this is mostly fbdev related fixes.
The general approach used were:
- Fix kernel-doc, this is of
Fix trivial W=1 warnings.
Update kernel-doc to avoid the warnings.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: linux-fb...@vger.kernel.org
---
drivers/video/of_display_timing.c | 1 +
drivers/video/of_videomode.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --g
Replacing DPRINTK() statements with pr_debug fixes
W=1 warnings.
And moves to a more standard logging setup at the same time.
Signed-off-by: Sam Ravnborg
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Jiri Slaby
Cc: Peilin Ye
Cc: Tetsuo Handa
Cc
Fix W=1 warnings by updating kernel-doc to follow the correct syntax.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Randy Dunlap
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Alexander A. Klimov"
---
drivers/video/fbdev/core/fb_notify.c | 3 ++-
drivers/video/fbdev/core/fbmon.c
Fix W=1 about variable that is asssigned a value but never used.
The variable was indeed never used so delete it.
Keep the call to radeon_probe_i2c_connector() as it may have
side-effects. It is unlikely but I could not verify that is was safe to
drop the call.
Signed-off-by: Sam Ravnborg
Cc: Be
Fix W=1 warnings about variables assigned but never used.
- Drop variables that was never used
- Avoid using a local variable by moving the expression to an if
condition
Signed-off-by: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Joe Perches
Cc: Vaibhav
Quoting Matthew Auld (2020-11-27 12:04:42)
> From: Daniele Ceraolo Spurio
>
> These functions are independent from the backend used and can therefore
> be split out of the exelists submission file, so they can be re-used by
> the upcoming GuC submission backend.
>
> Based on a patch by Chris Wil
Fix W=1 about variables assigned but never used.
- One variable is only used when CONFIG_FB_ATY_GENERIC_LCD is defined
Fix so variable is only defined with CONFIG_FB_ATY_GENERIC_LCD
- Several variables was only assigned by a call to aty_ld_le32().
Drop the variables but keep the call to aty_ld_
Fix W=1 warning by dropping unused variable
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/sis_main.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev/sis/sis_main.c
index 03c7
Fix several W=1 warnings.
This removes a lot of unused code - which is always a good thing to do.
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/init.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/driver
201 - 300 of 337 matches
Mail list logo
