Re: [PATCH] i915: Increase *_latency array size

On Tue, 04 May 2021, Andi Kleen wrote: > From: Andi Kleen > > Newer gcc prints the following warning: > > drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’ > reading 16 bytes from a region of size 10 [-Wstringop-overread] > and some other related warnings in similar funct

Enabling sample_c optimization for Broadwell GPUs

Hi there, While browsing an old downstream kernel, I found a patch[0] that enables sample_c optimizations at Broadwell GPUs. The message from the upstream commit that enables it for Haswell[1] (and presumably where the code at[0] was copied from) states that "[..] later platforms remove this

[PATCH] i915: Increase *_latency array size

From: Andi Kleen Newer gcc prints the following warning: drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] and some other related warnings in similar functions. gcc has a point here. Some of the latency arr

Re: [PATCH v2] drm: log errors in drm_gem_fb_init_with_funcs

On Wednesday, May 5th, 2021 at 2:14 AM, Rodrigo Siqueira wrote: > > As Ville said, if things got this far and the format is unsupported, > > something > > must be going wrong. I'm not confident enough to switch this to a WARN_ON, > > though. > > Hi Simon, thanks for your explanation. > > Is it

[PATCH 3/6] drm/vmwgfx: Fix cpu updates of coherent multisample surfaces

From: Thomas Hellstrom In cases where the dirty linear memory range spans multiple sample sheets in a surface, the dirty surface region is incorrectly computed. To do this correctly and in an optimized fashion we would have to compute the dirty region of each sample sheet and compute the union o

[PATCH 6/6] drm/vmwgfx: Port vmwgfx to arm64

This change fixes all of the arm64 issues we've had in the driver. ARM support is provided in svga version 3, for which support we've added in previous changes. svga version 3 currently lacks many of the advanced features (in particular 3D support is lacking) but that will change in time. Signed-o

[PATCH 0/6] drm/vmwgfx: SVGA v3 and arm64 support

This set includes some lost fixes and adds SVGA v3 and arm64 support to the driver. SVGA v3 is the next version of our virtual device, it's largely about making the device a little easier and cleaner to use (e.g. MMIO for register accesses instead of ioports, adding MSI-X support, deprecating the F

[PATCH 5/6] drm/vmwgfx: Add basic support for SVGA3

SVGA3 is the next version of our PCI device. Some of the changes include using MMIO for register accesses instead of ioports, deprecating the FIFO MMIO and removing a lot of the old and legacy functionality. SVGA3 doesn't support guest backed objects right now so everything except 3D is working. S

[PATCH 1/6] drm/vmwgfx: Fix incorrect enum usage

SVGA_REG_ENABLE is a register name, and SVGA_REG_ENABLE_(ENABLE| DISABLE|HIDE) are its valid values. We were incorrectly setting the register value to itself. This happened to work because the SVGA_REG_ENABLE is happens to to be the same value as SVGA_REG_ENABLE_ENABLE, but is still semantically in

[PATCH 4/6] drm/vmwgfx: Remove the reservation semaphore

Now since Christian reworked TTM to always keep objects on the LRU list unless they are pinned we shouldn't need the reservation semaphore. It makes the driver code a lot cleaner, especially because it was a little hard to reason when and where the reservation semaphore needed to be held. Signed-o

[PATCH 2/6] drm/vmwgfx: Mark a surface gpu-dirty after the SVGA3dCmdDXGenMips command

From: Thomas Hellstrom The SVGA3dCmdDXGenMips command uses a shader-resource view to access the underlying surface. Normally accesses using that view-type are not dirtying the underlying surface, but that particular command is an exception. Mark the surface gpu-dirty after a SVGA3dCmdDXGenMips co

[PATCH] drm: Declare drm_send_event_helper static

0-day reports: drivers/gpu/drm/drm_file.c:789:6: error: no previous prototype for 'drm_send_event_helper' Since drm_send_event_helper() is only used locally, declare it static to fix the problem. Reported-by: kernel test robot Signed-off-by: Guenter Roeck --- drivers/gpu/drm/drm_file.

Re: [Intel-gfx] [PATCH] drm/i915: drop the __i915_active_call pointer packing

On Tue, May 04, 2021 at 05:41:36PM +0100, Matthew Auld wrote: > 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 in

Re: [PATCH v2] drm: log errors in drm_gem_fb_init_with_funcs

On 05/03, Simon Ser wrote: > On Monday, May 3rd, 2021 at 4:20 PM, Rodrigo Siqueira > wrote: > > > > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c > > > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c > > > index 109d11fb4cd4..aeb808a0ba54 100644 > > > --- a/drivers/gpu/drm/drm_gem_fr

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

Fixed proposed at: https://lore.kernel.org/dri-devel/20210504220207.4004511-1-adrien.grass...@gmail.com/T/#u Thanks, Le mar. 4 mai 2021 à 21:19, Adrien Grassein a écrit : > > Ok thanks, > > I will investigate this. > > Le mar. 4 mai 2021 à 21:04, Michal Suchánek a écrit : > > > > Hello, > > > >

[PATCH] drm/bridge: fix LONTIUM_LT8912B dependencies

LONTIUM_LT8912B uses "drm_display_mode_to_videomode" from DRM framework that needs VIDEOMODE_HELPERS to be enabled. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Reported-by: Michal Suchánek Signed-off-by: Adrien Grassein --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 fi

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

On Mon, May 03, 2021 at 10:57:44AM -0500, Jason Ekstrand wrote: > Signed-off-by: Jason Ekstrand First, a bit of commit message please here. Second I accidentally went down the rabbit hole and ended up at try_qad_pin(). Your patch looks good, unfortunately my brain is complete mushroom soup now.

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

On Tue, May 4, 2021 at 12:16 PM Marek Olšák wrote: > > 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 s

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.

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 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: [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: 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 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: 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] 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: [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: [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: 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? >

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: [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

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: [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: 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: 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 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: [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

[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: 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

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: [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 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: [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: 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 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: [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 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 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: 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] 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: [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: [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 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: [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 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 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 > >> + * >

[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

[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,

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

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 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: [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: [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: 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, > > > > > >

[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

[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 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 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 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 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 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 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 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 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 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/

[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

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

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, 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: [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: [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] 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: [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: [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)

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: [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: [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

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: [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,

[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: [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

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: [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 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: [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: [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 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: [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 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

  1   2   >