dri-devel February 2019

dri-devel@lists.freedesktop.org

256 participants
1976 discussions

[PATCH] drm/msm: dpu: Don't set frame_busy_mask for async updates
by Sean Paul 05 Feb '19

05 Feb '19

From: Sean Paul <seanpaul(a)chromium.org> The frame_busy mask is used in frame_done event handling, which is not invoked for async commits. So an async commit will leave the frame_busy mask populated after it completes and future commits will start with the busy mask incorrect. This showed up on disable after cursor move. I was hitting the "this should not happen" comment in the frame event worker since frame_busy was set, we queued the event, but there were no frames pending (since async also doesn't set that). Signed-off-by: Sean Paul <seanpaul(a)chromium.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 36158b7d99cd..1a81c4daabc9 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -1558,8 +1558,14 @@ static void _dpu_encoder_kickoff_phys(struct dpu_encoder_virt *dpu_enc, if (!ctl) continue; - if (phys->split_role != ENC_ROLE_SLAVE) + /* + * This is cleared in frame_done worker, which isn't invoked + * for async commits. So don't set this for async, since it'll + * roll over to the next commit. + */ + if (!async && phys->split_role != ENC_ROLE_SLAVE) set_bit(i, dpu_enc->frame_busy_mask); + if (!phys->ops.needs_single_flush || !phys->ops.needs_single_flush(phys)) _dpu_encoder_trigger_flush(&dpu_enc->base, phys, 0x0, -- Sean Paul, Software Engineer, Google / Chromium OS

2 1

[PATCH] drm/i915: do not return invalid pointers as a *dentry
by Greg Kroah-Hartman 05 Feb '19

05 Feb '19

When calling debugfs functions, they can now return error values if something went wrong. If that happens, return a NULL as a *dentry to the relay core instead of passing it an illegal pointer. The relay core should be able to handle an illegal pointer, but add this check to be safe. Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: intel-gfx(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_guc_log.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index d3ebdbc0182e..8bf03497dcd8 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -140,6 +140,9 @@ static struct dentry *create_buf_file_callback(const char *filename, buf_file = debugfs_create_file(filename, mode, parent, buf, &relay_file_operations); + if (IS_ERR(buf_file)) + return NULL; + return buf_file; } -- 2.20.1

2 5

[v12 0/4] Add Colorspace connector property interface
by Uma Shankar 05 Feb '19

05 Feb '19

This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Addressed Maarten' review comment, updated the RB from Maarten and Jani Nikula's ack. Also fixed sparse warnings and checkpatch complaints. v11: Addressed Ville's review comments. Modified MACRO names, added infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace macro definitions defined in CTA 861.G. Currently linux/hdmi lacks support for ACE formats, will be added as a separate series. v12: Exported the helper API. Uma Shankar (4): drm: Add HDMI colorspace property drm: Add DP colorspace property drm: Add colorspace info to AVI Infoframe drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c | 104 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_edid.c | 29 +++++++++ drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_connector.c | 8 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 13 +++++ include/drm/drm_connector.h | 50 ++++++++++++++++ include/drm/drm_edid.h | 6 ++ 9 files changed, 216 insertions(+) -- 1.9.1

1 4

[v10 0/3] Add Colorspace connector property interface
by Uma Shankar 05 Feb '19

05 Feb '19

This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Addressed Maarten' review comment, updated the RB from Maarten and Jani Nikula's ack. Also fixed sparse warnings and checkpatch complaints. Uma Shankar (3): drm: Add HDMI colorspace property drm: Add DP colorspace property drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c | 104 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_connector.c | 8 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 25 ++++++++ include/drm/drm_connector.h | 46 +++++++++++++++ 7 files changed, 189 insertions(+) -- 1.9.1

3 13

[Bug 109557] [CI][BAT] random tests - crash / warn - Received signal SIGSEGV.
by bugzilla-daemon＠freedesktop.org 05 Feb '19

05 Feb '19

https://bugs.freedesktop.org/show_bug.cgi?id=109557 Martin Peres <martin.peres(a)free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|dri-devel(a)lists.freedesktop |maxime.ripard@free-electron |.org |s.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 109557] [CI][BAT] random tests - crash / warn - Received signal SIGSEGV.
by bugzilla-daemon＠freedesktop.org 05 Feb '19

05 Feb '19

1 0

[Bug 109550] [regression][amd tahiti xt][vm fault] Rise of the Tomb Raider hangs the system
by bugzilla-daemon＠freedesktop.org 05 Feb '19

05 Feb '19

1 0

[PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
by Joonas Lahtinen 05 Feb '19

05 Feb '19

Hi all, I would like to have some Acked-by's from you, the distro media folks Cc'd here, to document your intent to start using Intel's new media driver[1]. So if you recognize yourself (or are otherwise interested), please read on. TL;DR Distro folks, please give your Acked-by on patch [5/6] I believe most are already aware of the situation that Intel is moving to the new codebase for libva backend to support new Intel integrated graphics devices. The existing intel-libva-driver will be continue to be be supported for pre-Icelake platforms (<Gen11). Icelake and further platforms will only be supported from the new codebase. There's the complication that some Icelake features of the new driver will require new kernel uAPIs to work... But the new driver has not yet been well-established in the community from perspective of fulfilling [2]. This is very much due to the demand being low as Icelake is not widely available yet. So it's bit of a chicken and egg problem as we have a new platform *and* a new codebase for it simultaneously. Ahead of that community adoption, to ensure that Icelake has good kernel support from day one, we'd like to merge kernel support for the parts that have functional effect (this series). This is to avoid the scenario where end users have to update their distro kernels, like happened with Skylake. So if I could get Acked-by's from distro folks on the patch [5/6] that adds the new uAPI. That would document their intent to become an active user of the media-driver[1]. If that happens in the next week or two, it would mean that Icelake hardware features would be supported in kernel version 5.1 fully from kernel driver point of view. The new uAPI is needed to make VME feature functionally work on Icelake. It's pretty much a simple enable/disable switch for hardware configuration that only includes hardware slices compatible with the VME workload. So it's currently limited to the required on/off choice to keep things straightforward. The uAPI can be extended in the future for possible performance gains for more fine-grained control. VME is shared function to handle motion estimation. One intended usercase is in Hierarchical Motion Estimation (HME) media kernel. It provides a bigger search range with reduced cost for the search. HME should improve the encode quality with scenarios where the video has a lot of motion in it. Carl (Cc'd) can provide more details if needed. The respective IGT tests are reviewed and can be found at: https://patchwork.freedesktop.org/series/49190/ The userspace changes are reviewed and rebased here: https://github.com/intel/media-driver/pull/271 https://github.com/intel/media-driver/pull/463 Best Regards, Joonas Lahtinen Cc: dri-devel(a)lists.freedesktop.org Cc: Timo Aaltonen <timo.aaltonen(a)canonical.com> Cc: Takashi Iwai <tiwai(a)suse.de> Cc: Stephane Marchesin <stephane.marchesin(a)gmail.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> PS. This series might result in some CI failures reported as it adds new uAPI and Patchwork / CI synchronization of tests and kernel is currently WIP. [1] https://github.com/intel/media-driver [2] https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-use… Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (4): drm/i915/execlists: Move RPCS setup to context pin drm/i915: Add timeline barrier support drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) drm/i915/selftests: Context SSEU reconfiguration tests drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_gem_context.c | 354 ++++++++++++- drivers/gpu/drm/i915/i915_gem_context.h | 10 + drivers/gpu/drm/i915/i915_perf.c | 13 +- drivers/gpu/drm/i915/i915_request.c | 13 + drivers/gpu/drm/i915/i915_request.h | 10 + drivers/gpu/drm/i915/i915_timeline.c | 3 + drivers/gpu/drm/i915/i915_timeline.h | 27 + drivers/gpu/drm/i915/intel_lrc.c | 100 ++-- drivers/gpu/drm/i915/intel_lrc.h | 2 + .../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++++++++++++++++++ .../gpu/drm/i915/selftests/mock_timeline.c | 2 + include/uapi/drm/i915_drm.h | 64 +++ 13 files changed, 1056 insertions(+), 37 deletions(-) -- 2.17.2

3 4

[PATCH 0/8] fbdev: sm712fb: implement 2D acceleration w/ cleanups.
by Yifeng Li 05 Feb '19

05 Feb '19

Previously, in staging/sm7xxfb (now fbdev/sm712fb), 2D acceleration was implemented, but after its submission, a critical bug that causes total system hang was discovered, as a stopgap measure, 2D ops was completele removed in commit 3af805735a25 ("staging: sm7xx: remove the buggy 2D acceleration support") and never implemented again. It created a massive usability problem - on YeeLoong 8089, a notable MIPS platform which uses SM712 - even scrolling a single line of text on the console required an unaccelerated screen redraw, running "dmesg" typically takes 8-11 seconds, and absurdly, printf(), became a significant performance bottleneck that slows down GCC and "make", make the computer largely unusable. So I decided to take a look. Most of the my actual development was done in 2014 in a personal out-of-tree driver, I did not mainline it because 2D acceleration was not working properly in 24-bit color. I discovered the solution in early 2019 and now it's ready to be mainlined. This commit reimplements the 2D acceleration for sm712fb. Unlike the original implementation, which was messy and unnecessarily complicated by calling a 2D acceleration wrapper file with many unneeded functions, this is a minimum and (relatively) clean implementation. My tests have shown that running "dmesg" only takes 0.9 seconds, a performance boost of 950%. System hangs did not occur in my tests. Currently, 2D acceleration is only supported on SM712 with little-endian CPUs, it's disabled on Big Endian systems and SM720 chips as a safety measure, since I code for myself without any monetary or hardware support from any company or OEMs, I don't have the hardware and it's completely untested. I should be also to purchase a Big Endian test platform and add proper support soon. If you have a Big-Endian platform with SM7xx available for testing, please send an E-mail to me immediately! Thanks! Also, thanks to Miodrag Vallat and other OpenBSD developers, this work would be impossible without their code, that served as a reference implementation for me. Finally, during the development and testing of 2D acceleration, the modesetting code of this driver received a minor cleanup, and many issues about issues about the modesetting code and this driver in general have been documented. Yifeng Li (8): fbdev: sm712fb: update copyright headers. fbdev: sm712fb: use type "u8" for 8-bit I/O. fbdev: sm712fb: add 2D-related I/O headers and functions. fbdev: sm712fb: support 2D acceleration on SM712 w/ Little-Endian CPU. fbdev: sm712fb: add 32-bit color modes, drops some other modes. Documentation: fb: sm712fb: add information mainly about 2D. fbdev: sm712fb: Kconfig: add information about docs. MAINTAINERS: sm712fb: list myself as one maintainer. Documentation/fb/sm712fb.txt | 123 +++++++- MAINTAINERS | 1 + drivers/video/fbdev/Kconfig | 4 + drivers/video/fbdev/sm712.h | 129 +++++++- drivers/video/fbdev/sm712fb.c | 574 ++++++++++++++++++++++++++-------- 5 files changed, 679 insertions(+), 152 deletions(-) -- 2.20.1

3 11

[PATCH] drm/bochs: fix bochs_gem_prime_mmap
by Gerd Hoffmann 05 Feb '19

05 Feb '19

ttm_fbdev_mmap() just doesn't work. It appears to work fine, mmap() returns success, but any attempt to actually access the mapping causes a SIGBUS. We can just use drm_gem_prime_mmap() instead. Almost. We have to copy over the start offset from the ttm_buffer_object vm_node to the drm_gem_object vm_node so the offset math in drm_gem_prime_mmap() works correctly for us even though we use ttm to manage our objects. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- drivers/gpu/drm/bochs/bochs_mm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c index 641a33f134..49463348a0 100644 --- a/drivers/gpu/drm/bochs/bochs_mm.c +++ b/drivers/gpu/drm/bochs/bochs_mm.c @@ -442,5 +442,6 @@ int bochs_gem_prime_mmap(struct drm_gem_object *obj, { struct bochs_bo *bo = gem_to_bochs_bo(obj); - return ttm_fbdev_mmap(vma, &bo->bo); + bo->gem.vma_node.vm_node.start = bo->bo.vma_node.vm_node.start; + return drm_gem_prime_mmap(obj, vma); } -- 2.9.3

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2019