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

Unfortunately as I pointed out to Daniel as well this won't work 100% reliable either. See the signal on the ring buffer needs to be protected by manipulation from userspace so that we can guarantee that the hardware really has finished executing when it fires. Protecting memory by immediate

Re: [PATCH v5 06/27] drm/amdgpu: Handle IOMMU enabled case.

Am 03.05.21 um 22:43 schrieb Andrey Grodzovsky: On 2021-04-29 3:08 a.m., Christian König wrote: Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky: Handle all DMA IOMMU gropup related dependencies before the group is removed. v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopul

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

On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: > Unfortunately as I pointed out to Daniel as well this won't work 100% > reliable either. You're claiming this, but there's no clear reason why really, and you did't reply to my last mail on that sub-thread, so I really don't get wh

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

On Sat, May 01, 2021 at 10:17:46AM -0700, Matthew Brost wrote: > On Fri, Apr 30, 2021 at 12:11:07PM +0200, Daniel Vetter wrote: > > On Thu, Apr 29, 2021 at 09:03:48PM -0700, Matthew Brost wrote: > > > On Thu, Apr 29, 2021 at 02:14:19PM +0200, Daniel Vetter wrote: > > > > On Wed, Apr 28, 2021 at 01:

Re: [PATCH v3 10/11] drm: Use state helper instead of the plane state pointer

On Fri, Apr 30, 2021 at 09:44:42AM -0700, Rob Clark wrote: > On Thu, Apr 8, 2021 at 6:20 AM Maxime Ripard wrote: > > > > Hi Stephen, > > > > On Tue, Mar 30, 2021 at 11:56:15AM -0700, Stephen Boyd wrote: > > > Quoting Maxime Ripard (2021-03-30 08:35:27) > > > > Hi Stephen, > > > > > > > > On Mon, M

Re: [Heads up to maintainers] Re: [PATCH v8 1/1] drm/drm_mst: Use Extended Base Receiver Capability DPCD space

On Mon, May 03, 2021 at 11:33:33AM +0300, Jani Nikula wrote: > On Fri, 30 Apr 2021, Jani Nikula wrote: > > On Thu, 29 Apr 2021, Lyude Paul wrote: > >> JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime > >> today if there's no objections > > > > Thanks for the heads-up, I t

Re: [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

On Monday, May 3, 2021, Hans de Goede wrote: > From: Heikki Krogerus > > On Intel platforms we know that the ACPI connector device > node order will follow the order the driver (i915) decides. > The decision is made using the custom Intel ACPI OpRegion > (intel_opregion.c), though the driver doe

Re: [PATCH 2/9] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI

On Monday, May 3, 2021, Hans de Goede wrote: > Add a fwnode pointer to struct drm_connector and register an acpi_bus_type > for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled). > > The adding of the fwnode pointer allows drivers to associate a fwnode > that represents a conne

Re: [PATCH 3/9] drm/connector: Add drm_connector_find_by_fwnode() function (v2)

On Monday, May 3, 2021, Hans de Goede wrote: > Add a function to find a connector based on a fwnode. > > This will be used by the new drm_connector_oob_hotplug_event() > function which is added by the next patch in this patch-set. > > Changes in v2: > - Complete rewrite to use a global connector

NVIDIA GPU fallen off the bus after exiting s2idle

Hi, We have some Intel laptops (11th generation CPU) with NVIDIA GPU suffering the same GPU falling off the bus problem while exiting s2idle with external display connected. These laptops connect the external display via the HDMI/DisplayPort on a USB Type-C interfaced dock. If we enter and exit

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

Am 04.05.21 um 09:32 schrieb Daniel Vetter: On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: Unfortunately as I pointed out to Daniel as well this won't work 100% reliable either. You're claiming this, but there's no clear reason why really, and you did't reply to my last mail o

[PATCH][next] drm/nouveau/nvkm: Fix spelling mistake "endianess" -> "endianness"

From: Colin Ian King There is a spelling mistake in a nvdev_error message. Fix it. Signed-off-by: Colin Ian King --- drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c b/driver

Re: [PATCH 3/6] drm/i915: Add a separate low-level helper for masked workarounds

On 01/05/2021 07:55, Lucas De Marchi wrote: On Thu, Apr 29, 2021 at 10:12:51AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin We distinguish masked registers from other workarounds by the mask (clr) being zero for the former. the difference is more on the fact that those calls used _MASK

Re: [PATCHv3 1/6] drm: drm_bridge: add connector_attach/detach bridge ops

On 28/04/2021 16:25, Hans Verkuil wrote: Add bridge connector_attach/detach ops. These ops are called when a bridge is attached or detached to a drm_connector. These ops can be used to register and unregister an HDMI CEC adapter for a bridge that supports CEC. Signed-off-by: Hans Verkuil ---

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

On Tue, May 4, 2021 at 10:09 AM Christian König wrote: > > Am 04.05.21 um 09:32 schrieb Daniel Vetter: > > On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: > >> Unfortunately as I pointed out to Daniel as well this won't work 100% > >> reliable either. > > You're claiming this, but

Re: [PATCH 02/27] drm/i915: Stop storing the ring size in the ring pointer

On Mon, May 03, 2021 at 10:57:23AM -0500, Jason Ekstrand wrote: > Previously, we were storing the ring size in the ring pointer before it > was actually allocated. We would then guard setting the ring size on > checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really > only saves us

Re: [Intel-gfx] [PATCH 03/27] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP

On Mon, May 03, 2021 at 10:57:24AM -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: [Intel-gfx] [PATCH 06/27] drm/i915: Drop the CONTEXT_CLONE API

On Mon, May 03, 2021 at 10:57:27AM -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: [PATCH 11/27] drm/i915/request: Remove the hook from await_execution

On Mon, May 03, 2021 at 10:57:32AM -0500, Jason Ekstrand wrote: > This was only ever used for FENCE_SUBMIT automatic engine selection > which was removed in the previous commit. > > Signed-off-by: Jason Ekstrand I really how this is now split up and much more decipherable what's going on. For th

Re: [PATCH 10/27] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT

On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote: > Even though FENCE_SUBMIT is only documented to wait until the request in > the in-fence starts instead of waiting until it completes, it has a bit > more magic than that. If FENCE_SUBMIT is used to submit something to a > balanced e

Re: [PATCH 15/27] drm/i915: Add gem/i915_gem_context.h to the docs

On Mon, May 03, 2021 at 10:57:36AM -0500, Jason Ekstrand wrote: > In order to prevent kernel doc warnings, also fill out docs for any > missing fields and fix those that forgot the "@". > > Signed-off-by: Jason Ekstrand > --- > Documentation/gpu/i915.rst| 2 + > .../gpu/drm/

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

Am 04.05.21 um 10:27 schrieb Daniel Vetter: On Tue, May 4, 2021 at 10:09 AM Christian König wrote: Am 04.05.21 um 09:32 schrieb Daniel Vetter: On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: Unfortunately as I pointed out to Daniel as well this won't work 100% reliable either

Re: [PATCH] drm/ttm: fix warning in new sys man

On 03/05/2021 15:27, Christian König wrote: Include the header for the prototype. Signed-off-by: Christian König Reported-by: kernel test robot Reviewed-by: Matthew Auld ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freed

Re: [PATCH 2/4] Add missing check

On Mon, May 03, 2021 at 08:21:46PM +0200, Werner Sembach wrote: > Add a missing check that could potentially lead to an unarchivable mode being > validated. > > Signed-off-by: Werner Sembach > --- > > >From 54fa706f0a5f260a32af5d18b9622ceebb94c12e Mon Sep 17 00:00:00 2001 > From: Werner Sembach

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

On Tue, May 04, 2021 at 11:14:06AM +0200, Christian König wrote: > Am 04.05.21 um 10:27 schrieb Daniel Vetter: > > On Tue, May 4, 2021 at 10:09 AM Christian König > > wrote: > > > Am 04.05.21 um 09:32 schrieb Daniel Vetter: > > > > On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: >

Re: [PATCH 3/4] Restructure output format computation for better expandability

On Mon, May 03, 2021 at 08:21:47PM +0200, Werner Sembach wrote: > Couples the decission between RGB and YCbCr420 mode and the check if the port > clock can archive the required frequency. Other checks and configuration steps > that where previously done in between can also be done before or after.

Re: [PATCH 4/4] Use YCbCr420 as fallback when RGB fails

On Mon, May 03, 2021 at 08:21:48PM +0200, Werner Sembach wrote: > When encoder validation of a display mode fails, retry with less bandwidth > heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups > to support 4k60Hz output, which previously failed silently. > > AMDGPU had nea

[PATCH] drm: Use drm_mode_is_420_only() instead of open coding it

From: Ville Syrjälä Replace the open coded drm_mode_is_420_only() with the real thing. No functional changes. Cc: Werner Sembach Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_

Re: [Intel-gfx] [PATCH resend 2/2] drm/i915/display: Make vlv_find_free_pps() skip pipes which are in use for non DP purposes

On Wed, Mar 24, 2021 at 04:37:14PM +0200, Ville Syrjälä wrote: > On Wed, Mar 24, 2021 at 03:10:59PM +0100, Hans de Goede wrote: > > Hi, > > > > On 3/24/21 3:02 PM, Ville Syrjälä wrote: > > > On Tue, Mar 23, 2021 at 11:39:09AM +0100, Hans de Goede wrote: > > >> Hi, > > >> > > >> On 3/2/21 3:51 PM,

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

Am 04.05.21 um 11:47 schrieb Daniel Vetter: [SNIP] Yeah, it just takes to long for the preemption to complete to be really useful for the feature we are discussing here. As I said when the kernel requests to preempt a queue we can easily expect a timeout of ~100ms until that comes back. For com

Re: [led-backlight] default-brightness-level issue

‐‐‐ Original Message ‐‐‐ On Thursday, April 29, 2021 2:07 PM, Daniel Thompson wrote: > On Thu, Apr 29, 2021 at 11:31:20AM +, pgeiem wrote: > > > On Thursday, April 29, 2021 1:00 PM, Daniel Thompson > > daniel.thomp...@linaro.org wrote: > > > > > On Fri, Apr 23, 2021 at 01:04:23PM +0

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

On Tue, May 4, 2021 at 12:53 PM Christian König wrote: > > Am 04.05.21 um 11:47 schrieb Daniel Vetter: > > [SNIP] > >> Yeah, it just takes to long for the preemption to complete to be really > >> useful for the feature we are discussing here. > >> > >> As I said when the kernel requests to preempt

Re: [PATCH 3/9] drm/connector: Add drm_connector_find_by_fwnode() function (v2)

Hi, On 5/4/21 10:00 AM, Andy Shevchenko wrote: > > > On Monday, May 3, 2021, Hans de Goede > wrote: > > Add a function to find a connector based on a fwnode. > > This will be used by the new drm_connector_oob_hotplug_event() > function which is added by

Re: [RFC] CRIU support for ROCm

On Mon, May 03, 2021 at 02:21:53PM -0400, Felix Kuehling wrote: > Am 2021-05-01 um 1:03 p.m. schrieb Adrian Reber: > > On Fri, Apr 30, 2021 at 09:57:45PM -0400, Felix Kuehling wrote: > >> We have been working on a prototype supporting CRIU (Checkpoint/Restore > >> In Userspace) for accelerated comp

Re: [PATCH 3/9] drm/connector: Add drm_connector_find_by_fwnode() function (v2)

On Tue, May 4, 2021 at 2:53 PM Hans de Goede wrote: > On 5/4/21 10:00 AM, Andy Shevchenko wrote: > > On Monday, May 3, 2021, Hans de Goede > > wrote: ... > > +struct drm_connector *drm_connector_find_by_fwnode(struct > > fwnode_handle *fwnode) > > +{ > >

Re: [PATCH] drm: Use drm_mode_is_420_only() instead of open coding it

On Tue, 04 May 2021, Ville Syrjala wrote: > From: Ville Syrjälä > > Replace the open coded drm_mode_is_420_only() with the real thing. > > No functional changes. > > Cc: Werner Sembach > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/drm_modes.c | 13 -

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

Am 04.05.21 um 13:13 schrieb Daniel Vetter: On Tue, May 4, 2021 at 12:53 PM Christian König wrote: Am 04.05.21 um 11:47 schrieb Daniel Vetter: [SNIP] Yeah, it just takes to long for the preemption to complete to be really useful for the feature we are discussing here. As I said when the kern

Re: [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification

On Mon, May 03, 2021 at 11:00:20AM +0300, Heikki Krogerus wrote: > Hi Hans, > > On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote: > > +/** > > + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data > > + * > > + * Contains data about out-of-band hotplug events, signal

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote: > On Fri, 26 Mar 2021 07:13:09 +0100 > Christoph Hellwig wrote: > > > Hi all, > > > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware > > feature without any open source component - what would normally be > > the nor

Re: [RFC] CRIU support for ROCm

On Fri, Apr 30, 2021 at 09:57:45PM -0400, Felix Kuehling wrote: > We have been working on a prototype supporting CRIU (Checkpoint/Restore > In Userspace) for accelerated compute applications running on AMD GPUs > using ROCm (Radeon Open Compute Platform). We're happy to finally share > this work pu

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, 4 May 2021 15:00:39 +0200 Christoph Hellwig wrote: > On Tue, May 04, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote: > > > Hi Christoph, > > > > > > FYI, these uapi changes break build of QEMU. > > > > What uapi changes? > > > > What exactly breaks? > > > > Why does QEMU require

[RFC] Implicit vs explicit user fence sync

Hi guys, with this patch set I want to look into how much more additional work it would be to support implicit sync compared to only explicit sync. Turned out that this is much simpler than expected since the only addition is that before a command submission or flip the kernel and classic drive

[PATCH 02/12] RDMA/mlx5: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/infiniband/hw/mlx5/odp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c index b103555b1f5d..6b4d980c02e8 100644 --- a/drivers/infiniband/

[PATCH 01/12] dma-buf: add interface for user fence synchronization

This is a RFC/WIP patch which just adds the interface and lockdep annotation without any actual implementation. Signed-off-by: Christian König --- drivers/dma-buf/dma-resv.c | 18 ++ include/linux/dma-resv.h | 1 + 2 files changed, 19 insertions(+) diff --git a/drivers/dma-bu

[PATCH 03/12] drm/amdgpu: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++ 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd

[PATCH 04/12] drm/gem: dd DMA-buf user fence support for the atomic helper

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/drm_gem_atomic_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c b/drivers/gpu/drm/drm_gem_atomic_helper.c index a005c5a0ba46..fe0d18486643 100644 ---

[PATCH 06/12] drm/i915: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 5964e67c7d36..

[PATCH 05/12] drm/etnaviv: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 23 ++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_sub

[PATCH 09/12] drm/nouveau: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/nouveau/nouveau_gem.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index a70e82413fa7..e349a8b32549 100644

[PATCH 11/12] drm/radeon: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_cs.c | 6 ++ drivers/gpu/drm/radeon/radeon_display.c | 4 2 files changed, 10 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c

[PATCH 07/12] drm/lima: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/lima/lima_gem.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c index de62966243cd..d3d68218568d 100644 --- a/drivers/gpu/drm/lima

[PATCH 08/12] drm/msm: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/msm/msm_gem_submit.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index 5480852bdeda..a77389ce23d0 100

[PATCH 12/12] drm/v3d: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/v3d/v3d_gem.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c index 4eb354226972..7c45292c641c 100644 --- a/drivers/gpu/drm/v3d/v3d_ge

[PATCH 10/12] drm/panfrost: add DMA-buf user fence support

Just add the call before taking locks. Signed-off-by: Christian König --- drivers/gpu/drm/panfrost/panfrost_job.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index 6003cfeb1322..9174ceb1d

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote: > On Tue, 4 May 2021 14:59:07 +0200 > Greg Kroah-Hartman wrote: > > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote: > > > On Fri, 26 Mar 2021 07:13:09 +0100 > > > Christoph Hellwig wrote: > > > > > > > Hi all, > > > > > >

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

On Tue, 27 Apr 2021 11:20:18 +0200 Daniel Vetter wrote: > 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

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

Hi Daniel, Thanks for the extra clarification. On Tue, 27 Apr 2021 at 13:22, Daniel Vetter wrote: > > 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_

Re: [RFC] Implicit vs explicit user fence sync

Hi Christian, On Tue, May 04, 2021 at 03:27:17PM +0200, Christian König wrote: > Hi guys, > > with this patch set I want to look into how much more additional work it > would be to support implicit sync compared to only explicit sync. > > Turned out that this is much simpler than expected since

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote: > On Tue, 4 May 2021 14:59:07 +0200 > Greg Kroah-Hartman wrote: > > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote: > > > On Fri, 26 Mar 2021 07:13:09 +0100 > > > Christoph Hellwig wrote: > > > > > > > Hi all, > > > > > >

Re: [RFC] Implicit vs explicit user fence sync

Hi Daniel, Am 04.05.21 um 16:15 schrieb Daniel Vetter: Hi Christian, On Tue, May 04, 2021 at 03:27:17PM +0200, Christian König wrote: Hi guys, with this patch set I want to look into how much more additional work it would be to support implicit sync compared to only explicit sync. Turned out

[PATCH] fbmem: Mark proc_fb_seq_ops as __maybe_unused

With CONFIG_PROC_FS=n and -Werror, 0-day reports: drivers/video/fbdev/core/fbmem.c:736:36: error: 'proc_fb_seq_ops' defined but not used Mark it as __maybe_unused. Reported-by: kernel test robot Signed-off-by: Guenter Roeck --- drivers/video/fbdev/core/fbmem.c | 2 +- 1 file changed,

[PATCH] drm/bridge: ti-sn65dsi86: Remove __exit from GPIO sub-driver remove helper

The ti_sn_gpio_unregister() is not just called from the remove path but also from the error handling of the init path. That means it can't have the __exit annotation. Fixes: bf73537f411b ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers") Reported-by: kernel test robo

Re: [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification

On Mon, May 03, 2021 at 04:35:29PM +0200, Hans de Goede wrote: > Hi, > > On 5/3/21 10:00 AM, Heikki Krogerus wrote: > > Hi Hans, > > > > On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote: > >> +/** > >> + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data > >> + * >

Re: [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

Hi Andy, > > +/* NOTE: The connector order must be final before this is called. */ > > +void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) > > +{ > > + struct drm_connector_list_iter conn_iter; > > + struct drm_device *drm_dev = &i915->drm; > > + struct devic

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

Continuing on that idea to push for enabling the cap in more cases: do we have a policy to require new drivers to always support modifiers? That would be nice, even if it's just about enabling LINEAR. ___ dri-devel mailing list dri-devel@lists.freedeskto

Re: [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2)

> +/** > + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to > connector > + * @connector: connector to report the event on > + * @data: data related to the event > + * > + * On some hardware a hotplug event notification may come from outside the > display > + * driver / dev

Re: [RFC] Implicit vs explicit user fence sync

On Tue, May 04, 2021 at 04:26:42PM +0200, Christian König wrote: > Hi Daniel, > > Am 04.05.21 um 16:15 schrieb Daniel Vetter: > > Hi Christian, > > > > On Tue, May 04, 2021 at 03:27:17PM +0200, Christian König wrote: > > > Hi guys, > > > > > > with this patch set I want to look into how much mor

Re: [PATCH 0/9] drm + usb-type-c: Add support for out-of-band hotplug notification (v2)

On Mon, May 03, 2021 at 05:46:38PM +0200, Hans de Goede wrote: > Hi All, > > Here is v2 of my work on making DP over Type-C work on devices where the > Type-C controller does not drive the HPD pin on the GPU, but instead > we need to forward HPD events from the Type-C controller to the DRM driver.

Re: [PATCH] drm/bridge: ti-sn65dsi86: Remove __exit from GPIO sub-driver remove helper

Hey Douglas, On Tue, 4 May 2021 at 16:39, Douglas Anderson wrote: > The ti_sn_gpio_unregister() is not just called from the remove path > but also from the error handling of the init path. That means it can't > have the __exit annotation. > > Fixes: bf73537f411b ("drm/bridge: ti-sn65dsi86: Break

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, 4 May 2021 16:11:31 +0200 Greg Kurz wrote: > On Tue, 4 May 2021 15:30:15 +0200 > Greg Kroah-Hartman wrote: > > > On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote: > > > On Tue, 4 May 2021 14:59:07 +0200 > > > Greg Kroah-Hartman wrote: > > > > > > > On Tue, May 04, 2021 at

Re: [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification

Hi, On 5/4/21 4:52 PM, Heikki Krogerus wrote: > On Mon, May 03, 2021 at 04:35:29PM +0200, Hans de Goede wrote: >> Hi, >> >> On 5/3/21 10:00 AM, Heikki Krogerus wrote: >>> Hi Hans, >>> >>> On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote: +/** + * struct drm_connector_oob_hot

Re: [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2)

Hi, On 5/4/21 5:10 PM, Heikki Krogerus wrote: >> +/** >> + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to >> connector >> + * @connector: connector to report the event on >> + * @data: data related to the event >> + * >> + * On some hardware a hotplug event notification m

Re: [PATCH v5 06/27] drm/amdgpu: Handle IOMMU enabled case.

On 2021-05-04 3:03 a.m., Christian König wrote: Am 03.05.21 um 22:43 schrieb Andrey Grodzovsky: On 2021-04-29 3:08 a.m., Christian König wrote: Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky: Handle all DMA IOMMU gropup related dependencies before the group is removed. v5: Drop IOMMU noti

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

On Tue, 4 May 2021 at 15:58, Simon Ser wrote: > > Continuing on that idea to push for enabling the cap in more cases: do > we have a policy to require new drivers to always support modifiers? > > That would be nice, even if it's just about enabling LINEAR. Sounds perfectly reasonable IMHO. I thin

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote: > Just my 2cents from drm (where we deprecate old gunk uapi quite often): > Imo it's best to keep the uapi headers as-is, but exchange the > documentation with a big "this is removed, never use again" warning: We in RDMA have been doi

Re: [PATCH] drm/bridge: ti-sn65dsi86: Remove __exit from GPIO sub-driver remove helper

Merged to drm-misc-next. On Tue, 4 May 2021 at 17:22, Robert Foss wrote: > Hey Douglas, > > On Tue, 4 May 2021 at 16:39, Douglas Anderson > wrote: > >> The ti_sn_gpio_unregister() is not just called from the remove path >> but also from the error handling of the init path. That means it can't >

Re: [PATCH 16/27] drm/i915/gem: Add an intermediate proto_context struct

On Mon, May 03, 2021 at 10:57:37AM -0500, Jason Ekstrand wrote: > The current context uAPI allows for two methods of setting context > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The > former is allowed to be called at any time while the later happens as > part of GEM_CONTEXT_CR

Re: [Intel-gfx] [PATCH 17/27] drm/i915/gem: Rework error handling in default_engines

On Mon, May 03, 2021 at 10:57:38AM -0500, Jason Ekstrand wrote: > Since free_engines works for partially constructed engine sets, we can > use the usual goto pattern. > > Signed-off-by: Jason Ekstrand I guess subsequent patches apply the same for the set_engines command and __free_engines disapp

Re: [PATCH] fbmem: Mark proc_fb_seq_ops as __maybe_unused

On Tue, May 4, 2021 at 4:29 PM Guenter Roeck wrote: > > With CONFIG_PROC_FS=n and -Werror, 0-day reports: > > drivers/video/fbdev/core/fbmem.c:736:36: error: > 'proc_fb_seq_ops' defined but not used > > Mark it as __maybe_unused. > > Reported-by: kernel test robot > Signed-off-by: Guenter

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, May 04, 2021 at 12:53:27PM -0300, Jason Gunthorpe wrote: > On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote: > > > Just my 2cents from drm (where we deprecate old gunk uapi quite often): > > Imo it's best to keep the uapi headers as-is, but exchange the > > documentation with

[PATCH] drm/i915: drop the __i915_active_call pointer packing

We use some of the lower bits of the retire function pointer for potential flags, which is quite thorny, since the caller needs to remember to give the function the correct alignment with __i915_active_call, otherwise we might incorrectly unpack the pointer and jump to some garbage address later. I

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

On Tue, May 04, 2021 at 02:48:35PM +0200, Christian König wrote: > Am 04.05.21 um 13:13 schrieb Daniel Vetter: > > On Tue, May 4, 2021 at 12:53 PM Christian König > > wrote: > > > Am 04.05.21 um 11:47 schrieb Daniel Vetter: > > > > [SNIP] > > > > > Yeah, it just takes to long for the preemption to

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, 4 May 2021 14:59:07 +0200 Greg Kroah-Hartman wrote: > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote: > > On Fri, 26 Mar 2021 07:13:09 +0100 > > Christoph Hellwig wrote: > > > > > Hi all, > > > > > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware > > >

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, 4 May 2021 15:30:15 +0200 Greg Kroah-Hartman wrote: > On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote: > > On Tue, 4 May 2021 14:59:07 +0200 > > Greg Kroah-Hartman wrote: > > > > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote: > > > > On Fri, 26 Mar 2021 07:13:09

Re: remove the nvlink2 pci_vfio subdriver v2

On Fri, 26 Mar 2021 07:13:09 +0100 Christoph Hellwig wrote: > Hi all, > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware > feature without any open source component - what would normally be > the normal open source userspace that we require for kernel drivers, > although in

Re: [PATCH v5 06/27] drm/amdgpu: Handle IOMMU enabled case.

Am 2021-04-28 um 11:11 a.m. schrieb Andrey Grodzovsky: > Handle all DMA IOMMU gropup related dependencies before the > group is removed. > > v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate > > Signed-off-by: Andrey Grodzovsky > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h

Re: i.MX53 error during GPU use

Hello Rob, Em sex., 23 de abr. de 2021 às 11:35, Rob Clark escreveu: > On Fri, Apr 23, 2021 at 4:58 AM Otavio Salvador > wrote: > > We found this error when using Freedreno driver on an i.MX53 device > > with Wayland. Any idea how to fix this? > > > > [ 32.414110] [drm:msm_ioctl_gem_submit] *E

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

I see some mentions of XNACK and recoverable page faults. Note that all gaming AMD hw that has userspace queues doesn't have XNACK, so there is no overhead in compute units. My understanding is that recoverable page faults are still supported without XNACK, but instead of the compute unit replaying

ERROR: modpost: "drm_display_mode_to_videomode" [drivers/gpu/drm/bridge/lontium-lt8912b.ko] undefined!

Hello, I get errors about missing symbol in the lontium-lt8912b module. Is the problem self-evident or do you need the config as well? I don't need the driver for anything, it was just auto-enabled because it's new and the change has not been reviewed. Thanks Michal > > Last output: > WRAP

Re: ERROR: modpost: "drm_display_mode_to_videomode" [drivers/gpu/drm/bridge/lontium-lt8912b.ko] undefined!

Hello, I think this is self-evident but could you please send the config to confirm? Thanks, Le mar. 4 mai 2021 à 20:30, Michal Suchánek a écrit : > > Hello, > > I get errors about missing symbol in the lontium-lt8912b module. > > Is the problem self-evident or do you need the config as well? >

Re: [Intel-gfx] [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

On Mon, May 03, 2021 at 10:57:39AM -0500, Jason Ekstrand wrote: > For now this is a no-op because everyone passes in a null SSEU but it > lets us get some of the error handling and selftest refactoring plumbed > through. > > Signed-off-by: Jason Ekstrand it is a bit icky that intel_context_set_g

Re: [PATCH 0/2] drm/radeon: Fix off-by-one power_state index heap overwrite

On Mon, May 3, 2021 at 1:06 AM Kees Cook wrote: > > Hi, > > This is an attempt at fixing a bug[1] uncovered by the relocation of > the slab freelist pointer offset, as well as some related clean-ups. > > I don't have hardware to do runtime testing, but it builds. ;) > > -Kees > > [1] https://bugzi

Re: [PATCH] drm/amd/pm: initialize variable

On Fri, Apr 30, 2021 at 2:05 PM wrote: > > From: Tom Rix > > Static analysis reports this problem > > amdgpu_pm.c:478:16: warning: The right operand of '<' is a garbage value > for (i = 0; i < data.nums; i++) { > ^ ~ > > In some cases data is not set. Initialize to 0 an

Re: ERROR: modpost: "drm_display_mode_to_videomode" [drivers/gpu/drm/bridge/lontium-lt8912b.ko] undefined!

Ok thanks, I will investigate this. Le mar. 4 mai 2021 à 21:04, Michal Suchánek a écrit : > > Hello, > > I have only one from ppc64, the other architectures don't have the > problem or fail earlier. > > Thanks > > Michal > > On Tue, May 04, 2021 at 08:45:01PM +0200, Adrien Grassein wrote: > > He

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

On Tue, Apr 27, 2021 at 5:45 AM Fabio M. De Francesco wrote: > > 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-b

Re: 16 bpc fixed point (RGBA16) framebuffer support for core and AMD.

On Wed, Apr 28, 2021 at 5:21 PM Alex Deucher wrote: > > On Tue, Apr 20, 2021 at 5:25 PM Alex Deucher wrote: > > > > On Fri, Apr 16, 2021 at 12:29 PM Mario Kleiner > > wrote: > > > > > > Friendly ping to the AMD people. Nicholas, Harry, Alex, any feedback? > > > Would be great to get this in soon

Re: [PATCH 19/27] drm/i915/gem: Use the proto-context to handle create parameters

On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote: > This means that the proto-context needs to grow support for engine > configuration information as well as setparam logic. Fortunately, we'll > be deleting a lot of setparam logic on the primary context shortly so it > will hopefully

Re: [Intel-gfx] [PATCH 22/27] drm/i915/gem: Delay context creation

On Mon, May 03, 2021 at 10:57:43AM -0500, Jason Ekstrand wrote: > The current context uAPI allows for two methods of setting context > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The > former is allowed to be called at any time while the later happens as > part of GEM_CONTEXT_CR

Re: [Intel-gfx] [PATCH 22/27] drm/i915/gem: Delay context creation

> https://github.com/0day-ci/linux/commits/Jason-Ekstrand/drm-i915-gem-ioctl-clean-ups-v5/20210504-000132 > base: git://anongit.freedesktop.org/drm-intel for-linux-next > config: i386-randconfig-r013-20210503 (attached as .config) > compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 > reproduce

Re: [Intel-gfx] [PATCH 23/27] drm/i915/gem: Don't allow changing the VM on running contexts

> url: > https://github.com/0day-ci/linux/commits/Jason-Ekstrand/drm-i915-gem-ioctl-clean-ups-v5/20210504-000132 > base: git://anongit.freedesktop.org/drm-intel for-linux-next > config: i386-randconfig-s002-20210503 (attached as .config) > compiler: gcc-9 (Debian 9.

  1   2   >