Re: [PATCH 1/2] drm: remove usage of drm_pci_alloc/free

On Thu, Apr 22, 2021 at 07:02:43PM -0700, Joseph Kogut wrote: > Remove usage of legacy dma-api abstraction in preparation for removal > > Signed-off-by: Joseph Kogut > --- > Checkpatch warns here that r128 is marked obsolete, and asks for no > unnecessary modifications. > > This series aims to a

Re: [PATCH v2 1/1] drm/doc: document drm_mode_get_plane

On Mon, 26 Apr 2021 14:30:53 -0300 Leandro Ribeiro wrote: > On 4/26/21 7:58 AM, Simon Ser wrote: > > On Monday, April 26th, 2021 at 9:36 AM, Pekka Paalanen > > wrote: > > > This should probably explain what the bits in the mask correspond to. > As in, which CRTC does bit 0 refer to

Re: [PATCH 00/12] Remove vfio_mdev.c, mdev_parent_ops and more

On 26.04.21 19:42, Jason Gunthorpe wrote: On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote: On 24.04.21 01:02, Jason Gunthorpe wrote: Prologue This is series #3 in part of a larger work that arose from the minor remark that the mdev_parent_ops indirection shim

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Mon, Apr 26, 2021 at 04:59:28PM -0400, Marek Olšák wrote: > Thanks everybody. The initial proposal is dead. Here are some thoughts on > how to do it differently. > > I think we can have direct command submission from userspace via > memory-mapped queues ("user queues") without changing window s

Re: [PATCH] drm: i915: fix build when ACPI is disabled and BACKLIGHT=m

On Mon, 26 Apr 2021, Randy Dunlap wrote: > When CONFIG_DRM_I915=y, CONFIG_ACPI is not set, and > CONFIG_BACKLIGHT_CLASS_DEVICE=m, not due to I915 config, > there are build errors trying to reference backlight_device_{un}register(). > > Changing the use of IS_ENABLED() to IS_REACHABLE() in intel_pa

Re: [PATCH v4 3/4] drm/vkms: add XRGB planes composition

On Mon, 26 Apr 2021 14:31:28 -0300 Melissa Wen wrote: > On 04/26, Daniel Vetter wrote: > > On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote: > > > On Sat, 24 Apr 2021 05:25:31 -0300 > > > Melissa Wen wrote: > > > > > > > Add support for composing XRGB888 planes in addition to

Re: [PATCH 3/7] drm/i915/gtt: map the PD up front

On 26/04/2021 17:18, Matthew Auld wrote: On 26/04/2021 16:20, Tvrtko Ursulin wrote: On 26/04/2021 11:18, Matthew Auld wrote: We need to general our accessor for the page directories and tables from Generalise? using the simple kmap_atomic to support local memory, and this setup must be do

Re: [PATCH v4 3/4] drm/vkms: add XRGB planes composition

On 04/27, Pekka Paalanen wrote: > On Mon, 26 Apr 2021 14:31:28 -0300 > Melissa Wen wrote: > > > On 04/26, Daniel Vetter wrote: > > > On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote: > > > > On Sat, 24 Apr 2021 05:25:31 -0300 > > > > Melissa Wen wrote: > > > > > > > > > Add su

[PULL] drm-intel-next-fixes for the merge window

Hi Dave & Daniel - Some fixes to the drm-next feature pull. drm-intel-next-fixes-2021-04-27: drm/i915 fixes for v5.13-rc1: - Several fixes to GLK handling in recent display refactoring (Ville) - Rare watchdog timer race fix (Tvrtko) - Cppcheck redundant condition fix (José) - Overlay error code

Re: [PATCH] drm/omap: Fix issue with clocks left on after resume

Hi Tony, On 26/04/2021 17:12, Tony Lindgren wrote: On resume, dispc pm_runtime_force_resume() is not enabling the hardware as we pass the pm_runtime_need_not_resume() test as the device is suspended with no child devices. As the resume continues, omap_atomic_comit_tail() calls dispc_runtime_get

[PATCH v2 1/7] drm/i915/dg1: Fix mapping type for default state object

From: Venkata Ramana Nayana Use I915_MAP_WC when default state object is allocated in LMEM. Signed-off-by: Venkata Ramana Nayana Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gt/shmem_utils.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --gi

[PATCH v2 3/7] drm/i915/gtt: map the PD up front

We need to generalise 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 replace the kmap with the object mapping code that

[PATCH v2 7/7] drm/i915: Return error value when bo not in LMEM for discrete

From: Mohammed Khajapasha Return EREMOTE value when frame buffer object is not backed by LMEM for discrete. If Local memory is supported by hardware the framebuffer backing gem objects should be from local memory. Signed-off-by: Mohammed Khajapasha Signed-off-by: Matthew Auld Reviewed-by: Tvrt

[PATCH v2 6/7] drm/i915/lmem: Bypass aperture when lmem is available

From: Anusha Srivatsa In the scenario where local memory is available, we have rely on CPU access via lmem directly instead of aperture. v2: gmch is only relevant for much older hw, therefore we can drop the has_aperture check since it should always be present on such platforms. (Chris) Cc: Vil

[PATCH v2 2/7] drm/i915: Update the helper to set correct mapping

From: Venkata Sandeep Dhanalakota Determine the possible coherent map type based on object location, and if target has llc or if user requires an always coherent mapping. Cc: Matthew Auld Cc: CQ Tang Suggested-by: Michal Wajdeczko Signed-off-by: Venkata Sandeep Dhanalakota Signed-off-by: Mat

[PATCH v2 5/7] drm/i915/fbdev: Use lmem physical addresses for fb_mmap() on discrete

From: Mohammed Khajapasha Use local memory io BAR address for fbdev's fb_mmap() operation on discrete, fbdev uses the physical address of our framebuffer for its fb_mmap() fn. Signed-off-by: Mohammed Khajapasha Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/di

[PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

It's a requirement that for dgfx we place all the paging structures in device local-memory. v2: use i915_coherent_map_type() v3: improve the shared dma-resv object comment Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 - drivers/gpu/drm/i915/g

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Rewrite CL/CTG L-shaped memory detection

On Mon, Apr 26, 2021 at 08:18:39PM +0300, Ville Syrjälä wrote: > On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote: > > On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote: > > > On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote: > > > > On Wed, Apr 21, 2021 at 06:

Re: [PATCH v2 1/1] drm/doc: document drm_mode_get_plane

On Tue, Apr 27, 2021 at 10:40:24AM +0300, Pekka Paalanen wrote: > On Mon, 26 Apr 2021 14:30:53 -0300 > Leandro Ribeiro wrote: > > > On 4/26/21 7:58 AM, Simon Ser wrote: > > > On Monday, April 26th, 2021 at 9:36 AM, Pekka Paalanen > > > wrote: > > > > > This should probably explain what

Re: [PATCH v4 3/4] drm/vkms: add XRGB planes composition

On Tue, Apr 27, 2021 at 11:10:59AM +0300, Pekka Paalanen wrote: > On Mon, 26 Apr 2021 14:31:28 -0300 > Melissa Wen wrote: > > > On 04/26, Daniel Vetter wrote: > > > On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote: > > > > On Sat, 24 Apr 2021 05:25:31 -0300 > > > > Melissa Wen wr

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Mon, Apr 26, 2021 at 01:38:49PM -0400, Harry Wentland wrote: > > ## Introduction > > We are looking to enable HDR support for a couple of single-plane and > multi-plane scenarios. To do this effectively we recommend new > interfaces to drm_plane. Below I'll give a bit of background on HDR and

Re: [PATCH v2] drm/drm_file.c: Define drm_send_event_helper() as 'static'

On Mon, Apr 26, 2021 at 10:00:51PM +0200, Fabio M. De Francesco wrote: > drm_send_event_helper() has not prototype, it has internal linkage and > therefore it should be defined with storage class 'static'. > > Signed-off-by: Fabio M. De Francesco > --- > > Changes from v1: As suggested by Daniel

[PATCH 1/8] drm/arm: Don't set allow_fb_modifiers explicitly

Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is th

[PATCH 2/8] drm/arm/malidp: Always list modifiers

Even when all we support is linear, make that explicit. Otherwise the uapi is rather confusing. Cc: sta...@vger.kernel.org Cc: Pekka Paalanen Cc: Liviu Dudau Cc: Brian Starkey Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/malidp_planes.c | 9 +++-- 1 file changed, 7 insertions(+),

[PATCH 3/8] drm/i915: Don't set allow_fb_modifiers explicitly

Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is th

[PATCH 5/8] drm/msm/mdp4: Fix modifier support enabling

Setting the cap without the modifier list is very confusing to userspace. Fix that by listing the ones we support explicitly. Stable backport so that userspace can rely on this working in a reasonable way, i.e. that the cap set implies IN_FORMATS is available. Cc: sta...@vger.kernel.org Cc: Pekka

[PATCH 4/8] drm/msm/dpu1: Don't set allow_fb_modifiers explicitly

Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is th

[PATCH 6/8] drm/nouveau: Don't set allow_fb_modifiers explicitly

Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is th

[PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

It's very confusing for userspace to have to deal with inconsistencies here, and some drivers screwed this up a bit. Most just ommitted the format list when they meant to say that only linear modifier is allowed, but some also meant that only implied modifiers are acceptable (because actually none

[PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly

Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is th

Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

Reviewed-by: Simon Ser ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/57] Rid W=1 warnings from Staging

On Wed, Apr 14, 2021 at 07:10:32PM +0100, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > Lee Jones (57): 44 of these applied to my tree, I'll keep them in my "testing"

Re: [PATCH 01/21] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

On Fri, Apr 23, 2021 at 05:31:11PM -0500, Jason Ekstrand wrote: > This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify > ringsize on construction"). This API was originally added for OpenCL > but the compute-runtime PR has sat open for a year without action so we > can still pul

Re: [Intel-gfx] [PATCH 02/21] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP

On Fri, Apr 23, 2021 at 05:31:12PM -0500, Jason Ekstrand wrote: > The idea behind this param is to support OpenCL drivers with relocations > because OpenCL reserves 0x0 for NULL and, if we placed memory there, it > would confuse CL kernels. It was originally sent out as part of a patch > series in

Re: [PATCH 03/21] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem

On Fri, Apr 23, 2021 at 05:31:13PM -0500, Jason Ekstrand wrote: > Instead of handling it like a context param, unconditionally set it when > intel_contexts are created. This doesn't fix anything but does simplify > the code a bit. > > Signed-off-by: Jason Ekstrand So the idea here is that since

Re: [PATCH] drm/i9i5/gt: Fix a double free in gen8_preallocate_top_level_pdp

On Mon, 26 Apr 2021 at 13:44, Lv Yunlong wrote: > > Our code analyzer reported a double free bug. > > In gen8_preallocate_top_level_pdp, pde and pde->pt.base are allocated > via alloc_pd(vm) with one reference. If pin_pt_dma() failed, pde->pt.base > is freed by i915_gem_object_put() with a referen

Re: [PATCH 04/21] drm/i915/gem: Return void from context_apply_all

On Fri, Apr 23, 2021 at 05:31:14PM -0500, Jason Ekstrand wrote: > None of the callbacks we use with it return an error code anymore; they > all return 0 unconditionally. > > Signed-off-by: Jason Ekstrand Nice. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/gem/i915_gem_context.c | 2

[PATCH v4] drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_lock_all with drm_modeset_lock

drm_modeset_lock_all() is not needed here, so it is replaced with drm_modeset_lock(). The crtc list around which we are looping never changes, therefore the only lock we need is to protect access to crtc->state. Suggested-by: Daniel Vetter Suggested-by: Matthew Wilcox Signed-off-by: Fabio M. De

Re: [Intel-gfx] [PATCH 05/21] drm/i915: Drop the CONTEXT_CLONE API

On Fri, Apr 23, 2021 at 05:31:15PM -0500, Jason Ekstrand wrote: > This API allows one context to grab bits out of another context upon > creation. It can be used as a short-cut for setparam(getparam()) for > things like I915_CONTEXT_PARAM_VM. However, it's never been used by any > real userspace.

Re: [Intel-gfx] [PATCH 06/21] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v3)

On Fri, Apr 23, 2021 at 05:31:16PM -0500, Jason Ekstrand wrote: > This API is entirely unnecessary and I'd love to get rid of it. If > userspace wants a single timeline across multiple contexts, they can > either use implicit synchronization or a syncobj, both of which existed > at the time this f

Re: [PATCH v2] drm/bochs: Add screen blanking support

> > I'm fine to change in any better way, of course, so feel free to > > modify the patch. > > If no one objects, I'll merge it as-is. It's somewhat wrong wrt to VGA, but > apparently what qemu wants. No objections. Acked-by: Gerd Hoffmann FYI: cirrus is in the same situation, the modesetting

Re: [PATCH 07/21] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES

On Fri, Apr 23, 2021 at 05:31:17PM -0500, Jason Ekstrand wrote: > This has never been used by any userspace except IGT and provides no > real functionality beyond parroting back parameters userspace passed in > as part of context creation or via setparam. If the context is in > legacy mode (where

Re: [PATCH] drm/omap: Fix issue with clocks left on after resume

Hi, * Tomi Valkeinen [210427 08:47]: > Hi Tony, > > On 26/04/2021 17:12, Tony Lindgren wrote: > > On resume, dispc pm_runtime_force_resume() is not enabling the hardware > > as we pass the pm_runtime_need_not_resume() test as the device is suspended > > with no child devices. > > > > As the res

[PATCH] drm/i915: Simplify userptr locking

Use an rwlock instead of spinlock for the global notifier lock to reduce risk of contention in execbuf. Protect object state with the object lock whenever possible rather than with the global notifier lock Don't take an explicit page_ref in userptr_submit_init() but rather call get_pages() after

Re: [PATCH] drm/omap: Fix issue with clocks left on after resume

* Tony Lindgren [210427 10:12]: > * Tomi Valkeinen [210427 08:47]: > > If I understand right, this is only an issue when the dss was not enabled > > before the system suspend? And as the dispc is not enabled at suspend, > > pm_runtime_force_suspend and pm_runtime_force_resume don't really do > >

[PATCH v3] drm/drm_file.c: Define drm_send_event_helper() as 'static'

drm_send_event_helper() has not prototype, it has internal linkage and therefore it should be defined with storage class 'static'. Signed-off-by: Fabio M. De Francesco --- Changes from v2: Removed all the other lines in function comment. Changes from v1: As suggested by Daniel Vetter, removed un

Re: [PATCH v5] drm/ast: Fixed CVE for DP501

Hi Am 21.04.21 um 10:58 schrieb KuoHsiang Chou: [Bug][DP501] If ASPEED P2A (PCI to AHB) bridge is disabled and disallowed for CVE_2019_6260 item3, and then the monitor's EDID is unable read through Parade DP501. The reason is the DP501's FW is mapped to BMC addressing space rather than Host addr

Re: [PATCH v2 01/13] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

On Mon, 26 Apr 2021 17:00:03 -0300 Jason Gunthorpe wrote: > For some reason the vfio_mdev shim mdev_driver has its own module and > kconfig. As the next patch requires access to it from mdev.ko merge the > two modules together and remove VFIO_MDEV_DEVICE. > > A later patch deletes this driver en

Re: [PATCH v2 1/4] fbtft: Replace custom ->reset() with generic one

On Fri, Apr 16, 2021 at 05:20:41PM +0300, Andy Shevchenko wrote: > The custom ->reset() repeats the generic one, replace it. > > Note, in newer kernels the context of the function is a sleeping one, > it's fine to switch over to the sleeping functions. Keeping the reset > line asserted longer than

[PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

References to struct drm_device.pdev should be used any longer as the field will be moved into the struct's legacy section. Add a fix for the rsp commit. Signed-off-by: Thomas Zimmermann Fixes: d57d4a1daf5e ("drm/i915: Create stolen memory region from local memory") Cc: CQ Tang Cc: Matthew Auld

[PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

V7 of the patchset fixes some bitrot in the intel driver. The pdev field in struct drm_device points to a PCI device structure and goes back to UMS-only days when all DRM drivers were for PCI devices. Meanwhile we also support USB, SPI and platform devices. Each of those uses the generic device st

[PATCH v7 3/4] drm/i915: Don't assign to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Don't assign it. Users should upcast from struct drm_device.dev. v6: * also fix the assignment in selftests in this patch (Chris) Signed-off-by: Thomas Zimmermann Reviewed-by: Chris Wilson Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi

[PATCH v7 1/4] drm/i915/gt: Remove reference to struct drm_device.pdev

References to struct drm_device.pdev should be used any longer as the field will be moved into the struct's legacy section. Add a fix for the rsp commit. Signed-off-by: Thomas Zimmermann Fixes: a50ca39fbd01 ("drm/i915: setup the LMEM region") Cc: Lucas De Marchi Cc: Joonas Lahtinen Cc: Rodrigo

[PATCH v7 2/4] drm/i915: Remove reference to struct drm_device.pdev

References to struct drm_device.pdev should be used any longer as the field will be moved into the struct's legacy section. Fix a rsp comment. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/

[PATCH v7 4/4] drm: Move struct drm_device.pdev to legacy section

Struct drm_device.pdev is being moved to legacy status as only legacy DRM drivers use it. A possible follow-up patchset could remove pdev entirely. v4: * rebased Signed-off-by: Thomas Zimmermann Reviewed-by: Chris Wilson Acked-by: Sam Ravnborg --- include/drm/drm_device.h | 6 +++---

Re: [PATCH] drm/gud: cleanup coding style a bit

Den 02.04.2021 10.55, skrev Bernard Zhao: > Fix coccicheck warning: > drivers/gpu/drm/gud/gud_internal.h:89:2-3: Unneeded semicolon > drivers/gpu/drm/gud/gud_internal.h:107:2-3: Unneeded semicolon > > Signed-off-by: Bernard Zhao > --- Applied to drm-misc-next. Thanks, Noralf. ___

Re: [PATCH v1 1/7] drm/st7735r: Avoid spamming logs if probe is deferred

Den 21.04.2021 18.31, skrev Andy Shevchenko: > The GPIO request can fail and probe may be deferred. Thus, > the error message may be printed again and again. Avoid > this by replacing DRM_DEV_ERROR() by dev_err_probe(). > > Signed-off-by: Andy Shevchenko > --- Series is applied to drm-misc-ne

[PATCH v2] drm/amd/amdgpu: Fix errors in documentation of function parameters

In the documentation of functions, removed excess parameters, described undocumented ones, and fixed syntax errors. Signed-off-by: Fabio M. De Francesco --- Changes from v1: Cc'ed all the maintainers. drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 12 ++-- drivers/gpu/drm/amd/amdg

Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

Hi Daniel, On Tue, 27 Apr 2021 at 10:20, Daniel Vetter wrote: > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device > *dev, > * drm_universal_plane_init() to let the DRM managed resource infrastructure > * take care of cleanup and deallocation. > * > + * Drivers su

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

If we don't use future fences for DMA fences at all, e.g. we don't use them for memory management, it can work, right? Memory management can suspend user queues anytime. It doesn't need to use DMA fences. There might be something that I'm missing here. What would we lose without DMA fences? Just i

Re: [PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

On Tue, 27 Apr 2021, Thomas Zimmermann wrote: > V7 of the patchset fixes some bitrot in the intel driver. > > The pdev field in struct drm_device points to a PCI device structure and > goes back to UMS-only days when all DRM drivers were for PCI devices. > Meanwhile we also support USB, SPI and pl

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Correct, we wouldn't have synchronization between device with and without user queues any more. That could only be a problem for A+I Laptops. Memory management will just work with preemption fences which pause the user queues of a process before evicting something. That will be a dma_fence, b

Re: [PATCH v2 1/4] fbtft: Replace custom ->reset() with generic one

On Tue, Apr 27, 2021 at 2:09 PM Greg Kroah-Hartman wrote: > On Fri, Apr 16, 2021 at 05:20:41PM +0300, Andy Shevchenko wrote: > > The custom ->reset() repeats the generic one, replace it. > > > > Note, in newer kernels the context of the function is a sleeping one, > > it's fine to switch over to t

Re: [PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

Hi Jani Am 27.04.21 um 14:04 schrieb Jani Nikula: On Tue, 27 Apr 2021, Thomas Zimmermann wrote: V7 of the patchset fixes some bitrot in the intel driver. The pdev field in struct drm_device points to a PCI device structure and goes back to UMS-only days when all DRM drivers were for PCI devic

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Ok. I'll interpret this as "yes, it will work, let's do it". Marek On Tue., Apr. 27, 2021, 08:06 Christian König, < ckoenig.leichtzumer...@gmail.com> wrote: > Correct, we wouldn't have synchronization between device with and without > user queues any more. > > That could only be a problem for A+

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 27, 2021 at 1:49 PM Marek Olšák wrote: > > If we don't use future fences for DMA fences at all, e.g. we don't use them > for memory management, it can work, right? Memory management can suspend user > queues anytime. It doesn't need to use DMA fences. There might be something > that

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote: > Ok. I'll interpret this as "yes, it will work, let's do it". It works if all you care about is drm/amdgpu. I'm not sure that's a reasonable approach for upstream, but it definitely is an approach :-) We've already gone somewhat through the pai

Re: [PATCH v2] drm/bochs: Add screen blanking support

Am 27.04.21 um 11:56 schrieb Gerd Hoffmann: I'm fine to change in any better way, of course, so feel free to modify the patch. If no one objects, I'll merge it as-is. It's somewhat wrong wrt to VGA, but apparently what qemu wants. No objections. Acked-by: Gerd Hoffmann Great. Merged now

Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote: > Hi Daniel, > > On Tue, 27 Apr 2021 at 10:20, Daniel Vetter wrote: > > > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device > > *dev, > > * drm_universal_plane_init() to let the DRM managed resource > > i

Re: [PATCH v3] drm/drm_file.c: Define drm_send_event_helper() as 'static'

On Tue, Apr 27, 2021 at 12:55:03PM +0200, Fabio M. De Francesco wrote: > drm_send_event_helper() has not prototype, it has internal linkage and > therefore it should be defined with storage class 'static'. > > Signed-off-by: Fabio M. De Francesco Applied to drm-misc-next for 5.14, thanks for you

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 27.04.21 um 14:15 schrieb Daniel Vetter: On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote: Ok. I'll interpret this as "yes, it will work, let's do it". It works if all you care about is drm/amdgpu. I'm not sure that's a reasonable approach for upstream, but it definitely is an approach :-)

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

I'll defer to Christian and Alex to decide whether dropping sync with non-amd devices (GPUs, cameras etc.) is acceptable. Rewriting those drivers to this new sync model could be done on a case by case basis. For now, would we only lose the "amd -> external" dependency? Or the "external -> amd" de

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Only amd -> external. We can easily install something in an user queue which waits for a dma_fence in the kernel. But we can't easily wait for an user queue as dependency of a dma_fence. The good thing is we have this wait before signal case on Vulkan timeline semaphores which have the same

Re: [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

On Tue, 27 Apr 2021, Thomas Zimmermann wrote: > References to struct drm_device.pdev should be used any longer as > the field will be moved into the struct's legacy section. Add a fix > for the rsp commit. > > Signed-off-by: Thomas Zimmermann > Fixes: d57d4a1daf5e ("drm/i915: Create stolen memory

Re: [PATCH v7 0/4] drm: Move struct drm_device.pdev to legacy

On Tue, 27 Apr 2021, Thomas Zimmermann wrote: > Hi Jani > > Am 27.04.21 um 14:04 schrieb Jani Nikula: >> On Tue, 27 Apr 2021, Thomas Zimmermann wrote: >>> V7 of the patchset fixes some bitrot in the intel driver. >>> >>> The pdev field in struct drm_device points to a PCI device structure and >>>

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Ok. So that would only make the following use cases broken for now: - amd render -> external gpu - amd video encode -> network device What about the case when we get a buffer from an external device and we're supposed to make it "busy" when we are using it, and the external device wants to wait un

RE: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

> -Original Message- > From: Intel-gfx On Behalf Of > Matthew Auld > Sent: Tuesday, April 27, 2021 1:54 AM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM > > It's a requirement th

Re: [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines

On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote: > > This adds a bunch of complexity which the media driver has never > actually used. The media driver does technically bond a balanced engine > to another engine but the balanced engine only has one engine in the > sibling set. This doesn't

Re: [Intel-gfx] [PATCH 08/20] drm/i915/gem: Disallow bonding of virtual engines (v2)

On Mon, Apr 26, 2021 at 06:43:30PM -0500, Jason Ekstrand wrote: > This adds a bunch of complexity which the media driver has never > actually used. The media driver does technically bond a balanced engine > to another engine but the balanced engine only has one engine in the > sibling set. This d

Re: [PATCH] drm: bridge: add missing word in Analogix help text

On 26/04/2021 10:59, Neil Armstrong wrote: > On 26/04/2021 09:42, Robert Foss wrote: >> >> >> On Mon, Apr 26, 2021, 09:15 Neil Armstrong > > wrote: >> >> >> >> Le 24/04/2021 à 08:18, Randy Dunlap a écrit : >> > Insert a missing word "power" in Kconfig help te

Re: [PATCH] drm/bridge: anx7625: Fix power on delay

On 27/04/2021 07:53, Hsin-Yi Wang wrote: > From anx7625 spec, the delay between powering on power supplies and gpio > should be larger than 10ms. > > Fixes: 6c744983004e ("drm/bridge: anx7625: disable regulators when power off") > Signed-off-by: Hsin-Yi Wang > --- > drivers/gpu/drm/bridge/analog

Re: [PATCH v2 08/10] drm/amdgpu: Add DMA mapping of GTT BOs

Regards, Oak On 2021-04-26, 11:56 PM, "Kuehling, Felix" wrote: Am 2021-04-26 um 8:35 p.m. schrieb Zeng, Oak: > Regards, > Oak > > > > On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling" wrote: > > Use DMABufs with dynamic attachment

RE: [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

>-Original Message- >From: dri-devel On Behalf Of >Thomas Zimmermann >Sent: Tuesday, April 27, 2021 7:08 AM >To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo >; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew > >Cc: Tvrtko Ursulin ; Ursulin, Tvrtko >; Mika

Re: [PATCH v2 3/7] drm/i915/gtt: map the PD up front

On 27/04/2021 09:54, Matthew Auld wrote: We need to generalise 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 replac

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

On 27/04/2021 14:34, Tang, CQ wrote: -Original Message- From: Intel-gfx On Behalf Of Matthew Auld Sent: Tuesday, April 27, 2021 1:54 AM To: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

Re: [PATCH v2 4/7] drm/i915/gtt/dgfx: place the PD in LMEM

On 27/04/2021 09:54, Matthew Auld wrote: It's a requirement that for dgfx we place all the paging structures in device local-memory. v2: use i915_coherent_map_type() v3: improve the shared dma-resv object comment Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/g

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Mon, 26 Apr 2021 13:38:49 -0400 Harry Wentland wrote: > ## Introduction > > We are looking to enable HDR support for a couple of single-plane and > multi-plane scenarios. To do this effectively we recommend new > interfaces to drm_plane. Below I'll give a bit of background on HDR > and why we

Re: [PATCH v2 08/10] drm/amdgpu: Add DMA mapping of GTT BOs

Am 2021-04-27 um 10:29 a.m. schrieb Zeng, Oak: > Regards, > Oak > > > > On 2021-04-26, 11:56 PM, "Kuehling, Felix" wrote: > > Am 2021-04-26 um 8:35 p.m. schrieb Zeng, Oak: > > Regards, > > Oak > > > > > > > > On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Ku

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Uff good question. DMA-buf certainly supports that use case, but I have no idea if that is actually used somewhere. Daniel do you know any case? Christian. Am 27.04.21 um 15:26 schrieb Marek Olšák: Ok. So that would only make the following use cases broken for now: - amd render -> external gp

Re: [PATCH v2 00/10] Implement multi-GPU DMA mappings for KFD

This series is Acked-by: Oak Zeng Regards, Oak On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling" wrote: This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is needed

Re: [PATCH 1/8] drm/arm: Don't set allow_fb_modifiers explicitly

On Tue, Apr 27, 2021 at 11:20:11AM +0200, Daniel Vetter wrote: > Since > > commit 890880ddfdbe256083170866e49c87618b706ac7 > Author: Paul Kocialkowski > Date: Fri Jan 4 09:56:10 2019 +0100 > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > this is done automatical

Re: [PATCH] drm: i915: fix build when ACPI is disabled and BACKLIGHT=m

On 4/27/21 1:03 AM, Jani Nikula wrote: > On Mon, 26 Apr 2021, Randy Dunlap wrote: >> When CONFIG_DRM_I915=y, CONFIG_ACPI is not set, and >> CONFIG_BACKLIGHT_CLASS_DEVICE=m, not due to I915 config, >> there are build errors trying to reference backlight_device_{un}register(). >> >> Changing the use

Re: [PATCH v3 2/3] drm/mediatek: init panel orientation property

Hi, Hsin-Yi: Hsin-Yi Wang 於 2021年4月27日 週二 下午12:49寫道： > > Init panel orientation property after connector is initialized. Let the > panel driver decides the orientation value later. > > Signed-off-by: Hsin-Yi Wang > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 1 + > 1 file changed, 1 insertion(+)

Re: [PATCH 2/8] drm/arm/malidp: Always list modifiers

On Tue, Apr 27, 2021 at 11:20:12AM +0200, Daniel Vetter wrote: > Even when all we support is linear, make that explicit. Otherwise the > uapi is rather confusing. :) > > Cc: sta...@vger.kernel.org > Cc: Pekka Paalanen > Cc: Liviu Dudau > Cc: Brian Starkey > Signed-off-by: Daniel Vetter Acke

Re: [PATCH V2 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver

 Hi Marek, SN65DSI84 also supports single-link LVDS. We have quite a few customers using SN65DSI84 on Variscite SOMs with low resolution single-channel LVDS panels. I think having a DTS binding to indicate the number of links used by SN65DSI84 is more flexible than forcing dual-link mode on all

Re: [PATCH 000/190] Revertion of all of the umn.edu commits

On Wed, Apr 21, 2021 at 07:35:44PM +0200, Daniel Vetter wrote: > On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman > wrote: > > > > I have been meaning to do this for a while, but recent events have > > finally forced me to do so. > > > > Commits from @umn.edu addresses have been found to be subm

Re: [PATCH v2 0/9] drm: Add privacy-screen class and connector properties

Hi, >>> There now is GNOME userspace code using the new properties: >>> https://hackmd.io/@3v1n0/rkyIy3BOw >> >> Thanks for working on this. >> >> Can these patches be submitted as merge requests against the upstream >> projects? It would be nice to get some feedback from the maintainers, >> and

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák: > Ok. So that would only make the following use cases broken for now: > - amd render -> external gpu > - amd video encode -> network device FWIW, "only" breaking amd render -> external gpu will make us pretty unhappy, as we have

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach wrote: > > Ok. So that would only make the following use cases broken for now: > > > > - amd render -> external gpu > > - amd video encode -> network device > > FWIW, "only" breaking amd render -> external gpu will make us pretty > unhappy I

Re: [PATCH] drm/i915/gem: Remove reference to struct drm_device.pdev

Am 27.04.21 um 16:39 schrieb Ruhl, Michael J: -Original Message- From: dri-devel On Behalf Of Thomas Zimmermann Sent: Tuesday, April 27, 2021 7:08 AM To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo ; airl...@linux.ie; dan...@ffwll.ch; Auld, Matthew Cc

  1   2   >