[PATCH v3 0/4] drm/vkms: add overlay plane support

Adding support to overlay type in addition to primary and cursor plane. The planes composition relies on the z order of the active planes and only occurs if there is a primary plane (as in the current behavior). The first patch switches the function of initializing planes from drm_universal_plane_

[RFC] Cross-driver ww transaction lock lists

Hi! During the dma_resv conversion of the i915 driver, we've been using ww transaction lock lists to keep track of ww_mutexes that are locked during the transaction so that they can be batch unlocked at suitable locations. Including also the LMEM/VRAM eviction we've ended up with two static lists

[PATCH v3 1/4] drm/vkms: init plane using drmm_universal_plane_alloc

By using drmm_universal_plane_alloc instead of drm_universal_plane_init, we let the DRM infrastructure handles resource allocation and cleanup. We can also get rid of some code repetitions for plane cleanup, improving code maintainability in vkms. Signed-off-by: Melissa Wen --- drivers/gpu/drm/v

[PATCH v3 2/4] drm/vkms: rename cursor to plane on ops of planes composition

Generalize variables and function names used for planes composition (from cursor to plane), since we will reuse the operations for both cursor and overlay types. No functional change. Signed-off-by: Melissa Wen --- drivers/gpu/drm/vkms/vkms_composer.c | 28 ++-- 1 file c

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

Add support for composing XRGB888 planes in addition to the ARGB format. In the case of an XRGB plane at the top, the composition consists of just copying the RGB values of a pixel from src to dst, without the need for alpha blending operations for each pixel. Signed-off-by: Melissa Wen ---

[PATCH v3 4/4] drm/vkms: add overlay support

Add support to overlay plane, in addition to primary and cursor planes. In this approach, the plane composition still requires an active primary plane and planes are composed associatively in the order: (primary <- overlay) <- cursor It enables to run the following IGT tests successfully: - kms_pl

Re: [RFC] Cross-driver ww transaction lock lists

Am 13.04.21 um 09:50 schrieb Thomas Hellström: Hi! During the dma_resv conversion of the i915 driver, we've been using ww transaction lock lists to keep track of ww_mutexes that are locked during the transaction so that they can be batch unlocked at suitable locations. Including also the LMEM/

[PATCH] drm/amdgpu: remove set but not used variables

The value of ret set but will rewriten, so just delete. Signed-off-by: Tian Tao --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 1fb2a91

Re: [PATCH v6 0/2] enable HDCP in Cadence MHDP bridge driver

Merged series. https://cgit.freedesktop.org/drm/drm-misc/commit/?id=6a3608eae6d33a478a29348eb5e9ca330a528ae6 On Sat, 10 Apr 2021 at 20:14, Parshuram Thombare wrote: > > This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver. > > Changes since v1: > - Move sapb reg block right after

[PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin

I met below error during boot with i915 builtin if pass "i915.mitigations=off": [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations' The reason is slab subsystem isn't ready at that time, so kstrdup() returns NULL. Fix this issue by using stack var instead of kstrdup(). F

Re: [Intel-gfx] [PATCH 18/19] drm/i915/gtt: map the PD up front

On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote: > > On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld > wrote: > > > > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote: > > > > > > On Mon, Apr 12, 2021 at 10:05:25AM +0100, Matthew Auld wrote: > > > > We need to general our accessor for the page d

[PATCH 01/12] 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 02/12] 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 05/12] drm/imx: 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 09/12] 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

[PATCH 11/12] drm/vc4: 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 3/3] drm/shmem-helper: Align to page size in dumb_create

shmem helpers seem a bit sloppy here by automatically rounding up when actually creating the buffer, which results in under-reporting of what we actually have. Caught by igt/vgem_basic tests. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++-- 1 file changed, 2 inse

[PATCH 04/12] 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 03/12] drm/exynos: 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 06/12] 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 07/12] 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 08/12] 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 10/12] drm/tegra: 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 12/12] 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 1/3] dma-buf: Require VM_PFNMAP vma for mmap

tldr; DMA buffers aren't normal memory, expecting that you can use them like that (like calling get_user_pages works, or that they're accounting like any other normal memory) cannot be guaranteed. Since some userspace only runs on integrated devices, where all buffers are actually all resident sys

[PATCH 2/3] drm/vgem: use shmem helpers

Aside from deleting lots of code the real motivation here is to switch the mmap over to VM_PFNMAP, to be more consistent with what real gpu drivers do. They're all VM_PFNMP, which means get_user_pages doesn't work, and even if you try and there's a struct page behind that, touching it and mucking a

Re: [PATCH v2] drm/vmwgfx: Make sure unpinning handles reservations

Hi, Zack, On 4/10/21 8:59 PM, Zack Rusin wrote: Quite often it's a little hard to tell if reservations are already held in code paths that unpin bo's. While our pinning/unpinning code should be more explicit that requires a substential amount of work so instead we can avoid the issues by making

[PATCH 2/2] drm/vc4: hdmi: Convert to the new clock request API

The new clock request API allows us to increase the rate of the HSM clock to match our pixel rate requirements while decreasing it when we're done, resulting in a better power-efficiency. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 19 --- drivers/gpu/drm/vc

[PATCH 1/2] clk: Introduce a clock request API

It's not unusual to find clocks being shared across multiple devices that need to change the rate depending on what the device is doing at a given time. The SoC found on the RaspberryPi4 (BCM2711) is in such a situation between its two HDMI controllers that share a clock that needs to be raised de

[PATCH 0/2] clk: Implement a clock request API

Hi, This is a follow-up of the discussion here: https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ This implements a mechanism to raise and lower clock rates based on consumer workloads, with an example of such an implementation for the RaspberryPi4 HDMI controller. There

Re: [Intel-gfx] [PATCH 18/19] drm/i915/gtt: map the PD up front

On Tue, Apr 13, 2021 at 11:29 AM Matthew Auld wrote: > > On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote: > > > > On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld > > wrote: > > > > > > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote: > > > > > > > > On Mon, Apr 12, 2021 at 10:05:25AM +0100, Ma

Re: [PATCH 3/3] drm/shmem-helper: Align to page size in dumb_create

Hi Am 13.04.21 um 11:49 schrieb Daniel Vetter: shmem helpers seem a bit sloppy here by automatically rounding up when actually creating the buffer, which results in under-reporting of what we actually have. Caught by igt/vgem_basic tests. Signed-off-by: Daniel Vetter Drivers get it more wron

Re: [PATCH 10/12] drm/tegra: Don't set allow_fb_modifiers explicitly

On Tue, Apr 13, 2021 at 11:49:01AM +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

[RFC PATCH v2] drm/doc/rfc: i915 DG1 uAPI

Add an entry for the new uAPI needed for DG1. v2(Daniel): - include the overall upstreaming plan - add a note for mmap, there are differences here for TTM vs i915 - bunch of other suggestions from Daniel Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Daniel Vetter Cc: Dave Airlie -

Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly

Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > 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 automati

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

Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter: > 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 als

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

On Tue, 13 Apr 2021 11:49:03 +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

[PATCH v2 2/5] drm/connector: Add helper to compare HDR metadata

All the drivers that support the HDR metadata property have a similar function to compare the metadata from one connector state to the next, and force a mode change if they differ. All these functions run pretty much the same code, so let's turn it into an helper that can be shared across those dr

[PATCH v2 4/5] drm/connector: Add a helper to attach the colorspace property

The intel driver uses the same logic to attach the Colorspace property in multiple places and we'll need it in vc4 too. Let's move that common code in a helper. Signed-off-by: Maxime Ripard --- Changes from v1: - New patch --- drivers/gpu/drm/drm_connector.c | 20 ++

[PATCH v2 1/5] drm/connector: Create a helper to attach the hdr_output_metadata property

All the drivers that implement HDR output call pretty much the same function to initialise the hdr_output_metadata property, and while the creation of that property is in a helper, every driver uses the same code to attach it. Provide a helper for it as well Reviewed-by: Harry Wentland Reviewed-

[PATCH v2 5/5] drm/vc4: hdmi: Signal the proper colorimetry info in the infoframe

Our driver while supporting HDR didn't send the proper colorimetry info in the AVI infoframe. Let's add the property needed so that the userspace can let us know what the colorspace is supposed to be. Signed-off-by: Maxime Ripard --- Changes from v1: - New patch --- drivers/gpu/drm/vc4/vc4_

[PATCH v2 3/5] drm/vc4: Add HDR metadata property to the VC5 HDMI connectors

From: Dave Stevenson Now that we can export deeper colour depths, add in the signalling for HDR metadata. Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard --- Changes from v1: - Rebased on latest drm-misc-next tag --- drivers/gpu/drm/vc4/vc4_hdmi.c | 53 +

Re: [PATCH v1, 3/3] drm/mediatek: gamma set with cmdq

Hi Yongqiang, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on pza/reset/next linus/master v5.12-rc7] [cannot apply to next-20210413] [If your patch is applied to the wrong git tree, kindly drop us a note. And when

[PATCH 4/7] drm/ttm: move the page_alignment into the BO

The alignment is a constant property and shouldn't change. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_m

[PATCH 6/7] drm/ttm: always initialize the full ttm_resource

Init all fields in ttm_resource_alloc() when we create a new resource. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 -- drivers/gpu/drm/ttm/ttm_bo.c| 26 - drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++-- drivers/gpu/drm/tt

[PATCH 5/7] drm/ttm: add ttm_sys_manager

Add a separate manager for the system domain and make function tables mandatory. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/Makefile | 2 +- drivers/gpu/drm/ttm/ttm_device.c | 17 +- drivers/gpu/drm/ttm/ttm_module.h | 3 ++ drivers/gpu/drm/ttm/ttm_resourc

[PATCH 1/7] drm/nouveau: use bo->base.size instead of mem->num_pages

Change a couple of cases where it makes more sense to use the base size instead of the number of pages in the resource. Signed-off-by: Christian König --- drivers/gpu/drm/nouveau/nouveau_bo.c| 9 - drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_gem.

[PATCH 2/7] drm/amdgpu: check base size instead of mem.num_pages

Drop some ussage of mem in the code. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 984dcf5a475

[PATCH 7/7] drm/ttm: rename bo->mem and make it a pointer

When we want to decouble resource management from buffer management we need to be able to handle resources separately. Add a resource pointer and rename bo->mem so that all code needs to change to access the pointer instead. No functional change. Signed-off-by: Christian König --- .../gpu/drm/

[PATCH 3/7] drm/ttm: minor range manager coding style clean ups

No functional changes, just removing the leftovers from the redesign. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_range_manager.c | 35 - 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c b/drivers/gpu/

Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly

On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > Since > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > Author: Paul Kocialkowski > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > drm: Auto-set all

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

On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote: > On Tue, 13 Apr 2021 11:49:03 +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 th

Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly

Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter: > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > > Since > > > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > > Author: Paul Kocialko

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

On Tue, Apr 13, 2021 at 01:54:00PM +0200, Lucas Stach wrote: > Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter: > > 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 t

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

On Tue, Apr 13, 2021 at 04:11:29PM +0200, Daniel Vetter wrote: > On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote: > > On Tue, 13 Apr 2021 11:49:03 +0200 > > Daniel Vetter wrote: > > > > > It's very confusing for userspace to have to deal with inconsistencies > > > here, and some dr

[PATCH v3 0/9] drm/vc4: hdmi: Support the 4k @ 60Hz modes

Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. The firmware also has a glitch at the moment and will not properly release

[PATCH v3 1/9] drm/vc4: txp: Properly set the possible_crtcs mask

The current code does a binary OR on the possible_crtcs variable of the TXP encoder, while we want to set it to that value instead. Cc: # v5.9+ Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by: Thomas Zimmermann Signed-off-by: Maxime Ripard --- drivers/gpu/drm

[PATCH v3 4/9] drm/vc4: hdmi: Prevent clock unbalance

Since we fixed the hooks to disable the encoder at boot, we now have an unbalanced clk_disable call at boot since we never enabled them in the first place. Let's mimic the state of the hardware and enable the clocks at boot if the controller is enabled to get the use-count right. Cc: # v5.10+ Fi

[PATCH v3 5/9] drm/vc4: hvs: Make the HVS bind first

We'll need to have the HVS binding before the HDMI controllers so that we can check whether the firmware allows to run in 4kp60. Reorder a bit the component list, and document the current constraints we're aware of. Acked-by: Dave Stevenson Acked-by: Thomas Zimmermann Signed-off-by: Maxime Ripar

[PATCH v3 3/9] drm/vc4: Rework the encoder retrieval code

Due to a FIFO that cannot be flushed between the pixelvalve and the HDMI controllers on BCM2711, we need to carefully disable both at boot time if they were left enabled by the firmware. However, at the time we're running that code, the struct drm_connector encoder pointer isn't set yet, and thus

[PATCH v3 9/9] drm/vc4: hdmi: Raise the maximum clock rate

Now that we have the infrastructure in place, we can raise the maximum pixel rate we can reach for HDMI0 on the BCM2711. HDMI1 is left untouched since its pixelvalve has a smaller FIFO and would need a clock faster than what we can provide to support the same modes. Acked-by: Thomas Zimmermann R

[PATCH v3 6/9] drm/vc4: hdmi: Properly compute the BVB clock rate

The BVB clock rate computation doesn't take into account a mode clock of 594MHz that we're going to need to support 4k60. Acked-by: Thomas Zimmermann Reviewed-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 17 + 1 file changed, 9 insertions

[PATCH v3 7/9] drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies

In order to reach the frequencies needed to output at 594MHz, the firmware needs to be configured with the appropriate parameters in the config.txt file (enable_hdmi_4kp60 and force_turbo). Let's detect it at bind time, warn the user if we can't, and filter out the relevant modes. Acked-by: Thoma

[PATCH v3 8/9] drm/vc4: hdmi: Enable the scrambler

The HDMI controller on the BCM2711 includes a scrambler in order to reach the HDMI 2.0 modes that require it. Let's add the support for it. Acked-by: Thomas Zimmermann Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 64 + drivers/gpu/drm/vc4/vc

[PATCH v3 2/9] drm/vc4: crtc: Skip the TXP

The vc4_set_crtc_possible_masks is meant to run over all the encoders and then set their possible_crtcs mask to their associated pixelvalve. However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own"), the TXP has been turned to a CRTC and encoder of its own, and w

Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings

On Mon, 12 Apr 2021 17:46:46 +0200, Neil Armstrong wrote: > From: Phong LE > > Add the ITE bridge HDMI it66121 bindings. > > Signed-off-by: Phong LE > Signed-off-by: Neil Armstrong > --- > .../bindings/display/bridge/ite,it66121.yaml | 123 ++ > 1 file changed, 123 insertions

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

On Tuesday, April 13th, 2021 at 11:49 AM, Daniel Vetter wrote: > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver Prepend an ampersand like so and a hyperlink will be rendered: Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver _

Re: [PATCH 1/7] drm/nouveau: use bo->base.size instead of mem->num_pages

On Tue, 13 Apr 2021 at 14:52, Christian König wrote: > > Change a couple of cases where it makes more sense to use the base size > instead of the number of pages in the resource. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/nouveau/nouveau_bo.c| 9 - > drivers/gpu/drm/n

Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings

Hi Neil, Thank you for the patch. On Mon, Apr 12, 2021 at 05:46:46PM +0200, Neil Armstrong wrote: > From: Phong LE > > Add the ITE bridge HDMI it66121 bindings. > > Signed-off-by: Phong LE > Signed-off-by: Neil Armstrong > --- > .../bindings/display/bridge/ite,it66121.yaml | 123 ++

Re: [PATCH 2/7] drm/amdgpu: check base size instead of mem.num_pages

On Tue, 13 Apr 2021 at 14:52, Christian König wrote: > > Drop some ussage of mem in the code. usage > > Signed-off-by: Christian König Reviewed-by: Matthew Auld ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/

Re: [PATCH 3/7] drm/ttm: minor range manager coding style clean ups

On Tue, 13 Apr 2021 at 14:53, Christian König wrote: > > No functional changes, just removing the leftovers from the redesign. > > Signed-off-by: Christian König Reviewed-by: Matthew Auld ___ dri-devel mailing list dri-devel@lists.freedesktop.org https

Re: [PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin

On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote: > I met below error during boot with i915 builtin if pass > "i915.mitigations=off": > [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations' > > The reason is slab subsystem isn't ready at that time, so kstrdup()

Re: [PATCH v2] drm/bridge/sii8620: fix dependency on extcon

Hey Randy, Thanks for looking at this! On Fri, 9 Apr 2021 at 18:38, Randy Dunlap wrote: > > On 4/8/21 6:07 AM, Robert Foss wrote: > > The DRM_SIL_SII8620 kconfig has a weak `imply` dependency > > on EXTCON, which causes issues when sii8620 is built > > as a builtin and EXTCON is built as a modul

[PATCH] efifb: Check efifb_pci_dev before using it

On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not a PCI device. So make sure efifb_pci_dev is found before using it. Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0") BugLink: https://bugs.launchpad.net/bugs/1922403 Signed-off-by: Kai-Heng Feng

Re: [PATCH v3 3/3] MAINTAINERS: add it66121 HDMI bridge driver entry

On Mon, 12 Apr 2021 at 17:47, Neil Armstrong wrote: > > On 12/04/2021 17:46, Neil Armstrong wrote: > > From: Phong LE > > > > Add Neil Armstrong and myself as maintainers > > > > Signed-off-by: Phong LE > > Obviously: > Signed-off-by: Neil Armstrong > > > --- > > MAINTAINERS | 8 > >

Re: [PATCH] efifb: Check efifb_pci_dev before using it

On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng wrote: > > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not > a PCI device. > > So make sure efifb_pci_dev is found before using it. > > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI > D0") > BugLin

Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings

Hi Neil, Le lun. 12 avril 2021 à 17:46, Neil Armstrong a écrit : From: Phong LE Add the ITE bridge HDMI it66121 bindings. Signed-off-by: Phong LE Signed-off-by: Neil Armstrong --- .../bindings/display/bridge/ite,it66121.yaml | 123 ++ 1 file changed, 123 insertions(+)

Re: [PATCH] efifb: Check efifb_pci_dev before using it

On Tue, Apr 13, 2021 at 8:02 PM Alex Deucher wrote: > > On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng > wrote: > > > > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not > > a PCI device. > > > > So make sure efifb_pci_dev is found before using it. > > > > Fixes: a6c0fd3d5a8

Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings

Hi Paul, On Tue, Apr 13, 2021 at 07:09:17PM +0100, Paul Cercueil wrote: > Le lun. 12 avril 2021 à 17:46, Neil Armstrong a écrit : > > From: Phong LE > > > > Add the ITE bridge HDMI it66121 bindings. > > > > Signed-off-by: Phong LE > > Signed-off-by: Neil Armstrong > > --- > > .../bindings/di

Re: [PATCH v3 2/3] drm: bridge: add it66121 driver

Hey Neil & Phong, Thanks for submitting this series! > + > +static const struct drm_bridge_funcs it66121_bridge_funcs = { > + .attach = it66121_bridge_attach, > + .enable = it66121_bridge_enable, > + .disable = it66121_bridge_disable, > + .mode_set = it66121_bridge_mode_se

Re: [PATCH v3 2/3] drm: bridge: add it66121 driver

Hi Neil, I get build failures locally: drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_hw_reset’: drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration of function ‘gpiod_set_value’ [-Werror=implicit-function-declaration] 242 | gpiod_set_value(ctx->gpio_reset, 1

[PATCH v3] drm/vmwgfx: Make sure bo's are unpinned before putting them back

During cotable resize we pin the backup buffer to make sure the trylock doesn't fail. We were never unpinning the backup buffer resulting in every subsequent cotable resize trying to release a pinned bo. After we copy the old backup to the new we can release the pin. Mob's are always pinned so we j

Re: [pull] amdgpu, radeon drm-next-5.13

On Mon, Apr 12, 2021 at 06:07:32PM -0400, Alex Deucher wrote: > Hi Dave, Daniel, > > Same PR as last week plus a few accumulated fixes, rebased on drm-next > to resolve the dependencies between ttm and scheduler with changes in amdgpu. > > The following changes since commit c103b850721e4a79ff9578

Re: [pull] drm/msm: drm-msm-next for 5.13

On Sun, Apr 11, 2021 at 05:53:32PM -0700, Rob Clark wrote: > Hi Dave&Daniel, > > This time around a bit larger than usual, but a large part of that is > Dmitry's dsi phy/pll refactor (which is itself a pretty large negative > diffstat). The dsi phy/pll refactor includes a couple clk patches a-b >

Re: [PATCH] efifb: Check efifb_pci_dev before using it

On Tue, Apr 13, 2021 at 2:37 PM Daniel Vetter wrote: > > On Tue, Apr 13, 2021 at 8:02 PM Alex Deucher wrote: > > > > On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng > > wrote: > > > > > > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not > > > a PCI device. > > > > > > So ma

[PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status

Link status is different from display connected status in the case of something like an Apple dongle where the type-c plug can be connected, and therefore the link is connected, but no sink is connected until an HDMI cable is plugged into the dongle. The sink_count of DPCD of dongle will increase t

[PATCH v2 2/3] drm/msm/dp: do not re initialize of audio_comp at display_disable()

At dongle unplug, dp initializes audio_comp followed by sending disconnect event notification to audio and to make sure audio had shutdown completely by wait for audio completion notification at display_disable(). This patch will not re initialize audio_comp at display_disable() if audio shutdown i

[PATCH v2 3/3] drm/msm/dp: check main link status before start aux read

Make sure main link is in connection state before start aux read/write operation to avoid unnecessary long delay due to main link had been unplugged. Signed-off-by: Kuogee Hsieh --- drivers/gpu/drm/msm/dp/dp_aux.c | 5 + drivers/gpu/drm/msm/dp/dp_link.c | 20 +++- 2 files c

Re: [PATCH v2, 3/5] Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"

Hi, Yongqiang: Yongqiang Niu 於 2021年4月12日 週一 下午7:19寫道： > > This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f. > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Docume

Re: [PATCH v2, 3/5] Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"

On Wed, 2021-04-14 at 07:38 +0800, Chun-Kuang Hu wrote: > Hi, Yongqiang: > > Yongqiang Niu 於 2021年4月12日 週一 下午7:19寫道： > > > > This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f. > > > > Signed-off-by: Yongqiang Niu > > --- > > Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +

Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly

Hi Daniel, On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote: > Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter: > > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > > > Since > > > > > > >

Re: [PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status

Quoting Kuogee Hsieh (2021-04-13 16:11:10) > Link status is different from display connected status in the case > of something like an Apple dongle where the type-c plug can be > connected, and therefore the link is connected, but no sink is > connected until an HDMI cable is plugged into the dongl

Re: [PATCH v2 2/3] drm/msm/dp: do not re initialize of audio_comp at display_disable()

Quoting Kuogee Hsieh (2021-04-13 16:11:30) > At dongle unplug, dp initializes audio_comp followed by sending disconnect > event notification to audio and to make sure audio had shutdown completely > by wait for audio completion notification at display_disable(). This patch Is this dp_display_disab

Re: [PATCH v3] drm/vmwgfx: Make sure bo's are unpinned before putting them back

Hi, Zack, On 4/13/21 10:59 PM, Zack Rusin wrote: During cotable resize we pin the backup buffer to make sure the trylock doesn't fail. We were never unpinning the backup buffer resulting in every subsequent cotable resize trying to release a pinned bo. After we copy the old backup to the new we

[PATCH] drm/nouveau: fix an error code in nouveau_backlight_init()

If nouveau_get_backlight_name() fails then this should return -ENOMEM but currently it returns success. Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces") Signed-off-by: Dan Carpenter --- This is from static analysis. In the original commit db1a0ae21461 ("drm/nouveau/bl

[PATCH v2] drm/amdgpu: fix an error code in init_pmu_entry_by_type_and_add()

If the kmemdup() fails then this should return a negative error code but it currently returns success Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events for vega20") Signed-off-by: Dan Carpenter --- v2: I sent this patch in Feb but I accidentally added an unrelated hunk f

[PATCH] drm/i915/gvt: Fix error code in intel_gvt_init_device()

The intel_gvt_init_vgpu_type_groups() function is only called from intel_gvt_init_device(). If it fails then the intel_gvt_init_device() prints the error code and propagates it back again. That's a bug because false is zero/success. The fix is to modify it to return zero or negative error codes

[PATCH] drm/i915: fix an error code in intel_overlay_do_put_image()

This code should propagate the error from intel_overlay_pin_fb() but currently it returns success. Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane") Signed-off-by: Dan Carpenter --- drivers/gpu/drm/i915/display/intel_overlay.c | 4 +++- 1 file changed, 3 insertions(+),

[PATCH v2] drm/i915: Fix "mitigations" parsing if i915 is builtin

I met below error during boot with i915 builtin if pass "i915.mitigations=off": [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations' The reason is slab subsystem isn't ready at that time, so kstrdup() returns NULL. Fix this issue by using stack var instead of kstrdup(). F

[PATCH] drm/vmwgfx: remove unused variable

Fix the following gcc warning: drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:456:31: warning: variable ‘vcs’ set but not used [-Wunused-but-set-variable]. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

  1   2   >