dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH] drm/i915: return DRIVER_NAME for the fence driver name
by Matthew Auld 23 Jun '21

23 Jun '21

The first tracepoint for a request is trace_dma_fence_init which is called in the ctor before we have properly setup the request->engine. So if it's a non-recycled request the rq->engine might be NULL, or some garbage value, which leads to a crash. Since we are not permitted to use kmem_cache_zalloc() here with SLAB_TYPESAFE_BY_RCU, one approach is simply to return DRIVER_NAME. We can then revisit this later if we decide to get rid of SLAB_TYPESAFE_BY_RCU. Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Michael Mason <michael.w.mason(a)intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 1014c71cf7f5..55fa94bde22e 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -61,7 +61,7 @@ static struct i915_global_request { static const char *i915_fence_get_driver_name(struct dma_fence *fence) { - return dev_name(to_request(fence)->engine->i915->drm.dev); + return DRIVER_NAME; } static const char *i915_fence_get_timeline_name(struct dma_fence *fence) -- 2.26.3

4 3

[drm-intel:drm-intel-gt-next 7/8] drivers/gpu/drm/i915/intel_region_ttm.c:181:6: error: no previous prototype for 'intel_region_ttm_node_free'
by kernel test robot 23 Jun '21

23 Jun '21

tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next head: 13c2ceb6addb6b14468e09b75832c98909eed8e7 commit: d53ec322dc7de32a59bf1c2a56b93e90fc2f1c28 [7/8] drm/i915/ttm: switch over to ttm_buddy_man config: i386-defconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): git remote add drm-intel git://anongit.freedesktop.org/drm-intel git fetch --no-tags drm-intel drm-intel-gt-next git checkout d53ec322dc7de32a59bf1c2a56b93e90fc2f1c28 # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> Note: the drm-intel/drm-intel-gt-next HEAD ca319ee9ca6a6ef95143df8d0a57b2941c2a9566 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): >> drivers/gpu/drm/i915/intel_region_ttm.c:181:6: error: no previous prototype for 'intel_region_ttm_node_free' [-Werror=missing-prototypes] 181 | void intel_region_ttm_node_free(struct intel_memory_region *mem, | ^~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors vim +/intel_region_ttm_node_free +181 drivers/gpu/drm/i915/intel_region_ttm.c 180 > 181 void intel_region_ttm_node_free(struct intel_memory_region *mem, 182 struct ttm_resource *res) 183 { 184 struct ttm_resource_manager *man = mem->region_private; 185 186 man->func->free(man, res); 187 } 188 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

1 0

[PATCH v5, 0/3] support gce on mt8192 platform
by Yongqiang Niu 23 Jun '21

23 Jun '21

Change since v3: -rebase on linux 5.13-rc1 Change since v3: -fix review comment in v2 Change since v2: - add controy_by_sw for mt8192 Change since v1: - move out shift jump patch - remove useless patch Yongqiang Niu (3): dt-binding: gce: add gce header file for mt8192 arm64: dts: mt8192: add gce node mailbox: cmdq: add mt8192 support .../devicetree/bindings/mailbox/mtk-gce.txt | 7 +- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 + drivers/mailbox/mtk-cmdq-mailbox.c | 10 + include/dt-bindings/gce/mt8192-gce.h | 335 +++++++++++++++++++++ 4 files changed, 359 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8192-gce.h -- 1.8.1.1.dirty

1 3

[PATCH] drm: rcar-du: lvds: use dev_err_probe()
by Laurent Pinchart 23 Jun '21

23 Jun '21

Simplify error handling by using the dev_err_probe() function. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 5909173b26eb..165be31c4c45 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -839,9 +839,8 @@ static struct clk *rcar_lvds_get_clock(struct rcar_lvds *lvds, const char *name, if (PTR_ERR(clk) == -ENOENT && optional) return NULL; - if (PTR_ERR(clk) != -EPROBE_DEFER) - dev_err(lvds->dev, "failed to get %s clock\n", - name ? name : "module"); + dev_err_probe(lvds->dev, PTR_ERR(clk), "failed to get %s clock\n", + name ? name : "module"); return clk; } -- Regards, Laurent Pinchart

2 1

[PATCH] drm: rcar-du: lvds: Don't set bridge driver_private field
by Laurent Pinchart 23 Jun '21

23 Jun '21

The drm_bridge.driver_private field is set but never used. Don't set it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 70dbbe44bb23..5909173b26eb 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -919,7 +919,6 @@ static int rcar_lvds_probe(struct platform_device *pdev) if (ret < 0) return ret; - lvds->bridge.driver_private = lvds; lvds->bridge.funcs = &rcar_lvds_bridge_ops; lvds->bridge.of_node = pdev->dev.of_node; -- Regards, Laurent Pinchart

2 1

Re: [PATCH 0/3] drm: rcar-du: V3U support
by Laurent Pinchart 23 Jun '21

23 Jun '21

Hi Kieran, It seems that the cover letter didn't include the mailing lists on CC, fixing this. On Wed, Jun 23, 2021 at 12:20:21AM +0100, Kieran Bingham wrote: > Extend support for the V3U Display Unit, making use of the {recently, > soon to be} posted DSI encoder from Laurent. > > Patch 1 just cleans up in preparation for patch 3, and patch 2 is > required for operation on the V3U, however it is functional and should > be correct for the D3 and E3 as well, as they also lack external sync. > > Patch 3 enables the V3U and connects it to the MIPI DSI encoder, of > which I'm in a race between me and laurent for posting these patches ;-) You won the race :-) > Tests have been run and produce images - but there are artifacts visible > and some modes are unavailable, which will need further investigations, > but can be done on top of this integration. > > Kieran Bingham (3): > drm: rcar-du: Sort the DU outputs > drm: rcar-du: Only initialise TVM_TVSYNC mode when supported > drm: rcar-du: Add r8a779a0 device support > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 25 ++++++++++++++++++++++- > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 6 ++++-- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +++++++++++++++++++ > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 6 ++++++ > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 ++++ > drivers/gpu/drm/rcar-du/rcar_du_group.c | 2 ++ > 6 files changed, 61 insertions(+), 3 deletions(-) > -- Regards, Laurent Pinchart

2 1

Re: [PATH 0/4] [RFC] Support virtual DRM
by Esaki Tomohito 23 Jun '21

23 Jun '21

Hi, Thomas Thank you for reply. On 2021/06/21 16:10, Thomas Zimmermann wrote: > Hi > > Am 21.06.21 um 08:27 schrieb Tomohito Esaki: >> Virtual DRM splits the overlay planes of a display controller into >> multiple >> virtual devices to allow each plane to be accessed by each process. >> >> This makes it possible to overlay images output from multiple >> processes on a >> display. For example, one process displays the camera image without >> compositor >> while another process overlays the UI. > > I briefly looked over your patches. I didn't understand how this is > different to the functionality of a compositor? Shouldn't this be solved > in userspace? I think when latency is important (e.g., AR, VR, for displaying camera images in IVI systems), there may be use cases where the compositor cannot be used. Normally, when the image is passed through the compositor, it is displayed after 2 VSYNC at most, because the compositor combines the image with VSYNC synchronization. On the other hand, if we use vDRM, the image will be displayed at the next VSYNC, so it will be displayed after 1 VSYNC at most. Also, since the compositor is a single point of failure, we may not want to make it dependent on it. Best regards Tomohito Esaki

4 4

[PATCH v3 0/2] drm: address potential UAF bugs with drm_master ptrs
by Desmond Cheong Zhi Xi 23 Jun '21

23 Jun '21

This patch series addresses potential use-after-free errors when dereferencing pointers to struct drm_master. These were identified after one such bug was caught by Syzbot in drm_getunique(): https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f8… The series is broken up into two patches: 1. Implement a locked version of drm_is_current_master() function that's used within drm_auth.c. 2. Identify areas in drm_lease.c where pointers to struct drm_master are dereferenced, and ensure that the master pointers are not freed during use. Changes in v2 -> v3: - Patch 1: Move the definition of drm_is_current_master and the _locked version higher up in drm_auth.c to avoid needing a forward declaration of drm_is_current_master_locked. As suggested by Daniel Vetter. - Patch 2: Instead of leaking drm_device.master_mutex into drm_lease.c to protect drm_master pointers, add a new drm_file_get_master() function that returns drm_file->master while increasing its reference count, to prevent drm_file->master from being freed. As suggested by Daniel Vetter. Changes in v1 -> v2: - Patch 2: Move the lock and assignment before the DRM_DEBUG_LEASE in drm_mode_get_lease_ioctl, as suggested by Emil Velikov. Desmond Cheong Zhi Xi (2): drm: add a locked version of drm_is_current_master drm: protect drm_master pointers in drm_lease.c drivers/gpu/drm/drm_auth.c | 73 +++++++++++++++++++++++++++---------- drivers/gpu/drm/drm_lease.c | 57 ++++++++++++++++++++--------- include/drm/drm_auth.h | 1 + include/drm/drm_file.h | 15 ++++++-- 4 files changed, 107 insertions(+), 39 deletions(-) -- 2.25.1

3 7

New uAPI for color management proposal and feedback request
by Werner Sembach 23 Jun '21

23 Jun '21

Hello, In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm properties I propose 4 new properties: "preferred pixel encoding", "active color depth", "active color range", and "active pixel encoding" Motivation: Current monitors have a variety pixel encodings available: RGB, YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. In addition they might be full or limited RGB range and the monitors accept different bit depths. Currently the kernel driver for AMD and Intel GPUs automatically configure the color settings automatically with little to no influence of the user. However there are several real world scenarios where the user might disagree with the default chosen by the drivers and wants to set his or her own preference. Some examples: 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color information, some screens might look better on one than the other because of bad internal conversion. The driver currently however has a fixed default that is chosen if available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change this currently is by editing and overloading the edid reported by the monitor to the kernel. 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some hardware might report that it supports the higher port clock, but because of bad shielding on the PC, the cable, or the monitor the screen cuts out every few seconds when RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine without changing hardware. The drivers currently however always default to the "best available" option even if it might be broken. 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color by rapidly switching between 2 adjacent colors. They advertise themselves to the kernel as 10-bit monitors but the user might not like the "fake" 10-bit effect and prefer running at the native 8-bit per color. 4. Some screens are falsely classified as full RGB range wile they actually use limited RGB range. This results in washed out colors in dark and bright scenes. A user override can be helpful to manually fix this issue when it occurs. There already exist several requests, discussion, and patches regarding the thematic: - https://gitlab.freedesktop.org/drm/amd/-/issues/476 - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 - https://lkml.org/lkml/2021/5/7/695 - https://lkml.org/lkml/2021/5/11/416 Current State: I only know bits about the Intel i915 and AMD amdgpu driver. I don't know how other driver handle color management - "max bpc", global setting applied by both i915 (only on dp i think?) and amdgpu. Default value is "8". For every resolution + frequency combination the highest possible even number between 6 and max_bpc is chosen. If the range doesn't contain a valid mode the resolution + frequency combination is discarded (but I guess that would be a very special edge case, if existent at all, when 6 doesn't work but 10 would work). Intel HDMI code always checks 8, 12, and 10 and does not check the max_bpc setting. - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not amdgpu), overwrites the kernel chosen color range setting (full or limited). If I recall correctly Intel HDMI code defaults to full unless this property is set, Intel dp code tries to probe the monitor to find out what to use. amdgpu has no corresponding setting (I don't know how it's decided there). - RGB pixel encoding can be forced by overloading a Monitors edid with one that tells the kernel that only RGB is possible. That doesn't work for YCbCr 4:4:4 however because of the edid specification. Forcing YCbCr 4:2:0 would theoretically also be possible this way. amdgpu has a debugfs switch "force_ycbcr_420" which makes the driver default to YCbCr 4:2:0 on all monitors if possible. Proposed Solution: 1. Add a new uAPI property "preferred pixel encoding", as a per port setting. - An amdgpu specific implementation was already shared here: https://gitlab.freedesktop.org/drm/amd/-/issues/476 - It also writes back the actually used encoding if the one requested was not possible, overwriting the requested value in the process. I think it would be better to have this feedback channel as a different, read-only property. - Make this solution vendor agnostic by putting it in the drm_connector_state struct next do max_bpc https://elixir.bootlin.com/linux/v5.13-rc1/source/include/drm/drm_connector… and add patches to amdgpu and i915 to respect this setting 2. Convert "Broadcast RGB" to a vendor agnostic setting/replace with a vendor agnostic setting. - Imho the name is not very fitting, but it pops up in many tutorials throughout the web (some other opinions? how could a rename be handled?". - Also move it from Intel specific structs to the drm_connector_state struct (please let me know if there is a better place) 3. Strive for full implementation of "max bpc" - I need to double check the Intel HDMI code. 4. Add 3 feedback channels "active color depth", "active color range", and "active pixel encoding" as vendor agnostic settings in the drm_connector_state struct - Possible values are: - unknown, undefined, 6-bit, 8-bit, 9-bit, 10-bit, 11-bit, 12-bit, 14-bit, 16-bit (alternatively: an integer from -1 (unknown), 0 (undefined) to 16, let me know what would be more suitable) - unknown, undefined, full, limited - unknown, undefined, rgb, ycbcr444, ycbcr422, ycbcr420 - it's the responsibility of the driver to update the values once the port configuration changes - if the driver does not support the feedback channels they are set to unknown - if the driver uses a non listed setting it should set the property to undefined - A more detailed description why I think these feedback channel are important and should be their own read-only property can be found here: https://lkml.org/lkml/2021/5/11/339 Adoption: A KDE dev wants to implement the settings in the KDE settings GUI: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370 Tuxedo Computers (my employer) wants to implement the settings desktop environment agnostic in Tuxedo Control Center. I will start work on this in parallel to implementing the new kernel code. Questions: I'm very curious about feedback from the dri-devel community. Would the concept outlaid above be accepted as new uAPI once it's fully implemented? Where would be the best way to store the new vendor agnostic settings? Following the implementation of max_bpc i would put it in the drm_connector_state struct. My way forward would be to implement the feedback channels first, because they can be very useful for debugging the setting properties afterwards. I will split each of it up it in 3 or 5 patch sets: 1 for the vendor agnostic part, 1 for Intel (or 2 split up between HDMI and DP), and 1 for AMD (or 2 split up between HDMI and DP) Kind regards, Werner Sembach

6 15

[PATCH v8 0/3] drm/i915: Move system memory to TTM for discrete
by Thomas Hellström 23 Jun '21

23 Jun '21

Early implementation of moving system memory for discrete cards over to TTM. We first add the notion of objects being migratable under the object lock to i915 gem, and add some asserts to verify that objects are either locked or pinned when the placement is checked by the gem code. Patch 2 deals with updating the i915 gem bookkeeping after a TTM move, Patch 3 moves system over from shmem to TTM for discrete Note that the mock device doesn't consider itself discrete so the TTM system path is not checked by the mock selftests. v2: - Style fixes (reported by Matthew Auld) - Drop the last patch (migration) It needs selftests and some additional work. - Unconditionally add VM_IO at mmap time. v3: - More style fixes (reported by Matthew Auld) - Don't overfill the busy placement vector (reported by Matthew Auld) v4: - Remove confusion around shrinkable objects (reported by Matthew Auld) v5: - Remove confusion around shrinkable objects again, but this time in the correct patch. (reported by Matthew Auld) v6: - One patch already committed. - Introduce a __i915_gem_object_is_lmem() to be used in situations where we know that a fence that can't currently signal keeps the object from being migrated or evicted. - Rebase on accelerated TTM moves - Fix TODO:s for supporting system memory with TTM. - Update the object GEM region after a TTM move if compatible. - Move a couple of warnings for shmem on DGFX. v7: - Just updated a commit message with version history under dashes. v8: - Reinstate alignment at ttm_bo_init_reserved() time. (Reported by Matthew Auld). - When changing regions, also move the object to the new region list and break early. (Reported by Matthew Auld). - Don't flag the object as contiguous based on the current region min pages size. Thomas Hellström (3): drm/i915: Update object placement flags to be mutable drm/i915/ttm: Adjust gem flags and caching settings after a move drm/i915/ttm: Use TTM for system memory drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 22 ++ drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 2 + drivers/gpu/drm/i915/gem/i915_gem_mman.c | 12 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 38 ++++ drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 20 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_region.c | 4 - drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 10 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 196 ++++++++++++++---- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +- .../drm/i915/gem/selftests/huge_gem_object.c | 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 5 +- .../drm/i915/gem/selftests/i915_gem_mman.c | 4 +- .../drm/i915/gem/selftests/i915_gem_phys.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 3 - drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/intel_memory_region.c | 7 +- drivers/gpu/drm/i915/intel_memory_region.h | 8 + 21 files changed, 267 insertions(+), 99 deletions(-) -- 2.31.1

1 3

← Newer
1
...
30
31
32
33
34
35
36
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021