dri-devel June 2019

dri-devel@lists.freedesktop.org

350 participants
2370 discussions

[Bug 110823] [Intel-GFX-CI][BAT] igt@amdgpu/amd_basic@userptr - fail - Failed assertion: r == 0
by bugzilla-daemon＠freedesktop.org 03 Jun '19

03 Jun '19

1 0

[Bug 110823] [Intel-GFX-CI][BAT] igt@amdgpu/amd_basic@userptr - fail - Failed assertion: r == 0
by bugzilla-daemon＠freedesktop.org 03 Jun '19

03 Jun '19

1 0

[RFC PATCH 0/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
by Janusz Krzysztofik 03 Jun '19

03 Jun '19

Hi, I do realize more work needs to be done to get a clean hotunplug solution, however I need your comments to make sure that I'm going in the right direction. So far I have no good idea how to resolve pm_runtime_get_sync() failures on outstanding device file close after successfull driver unbind. Thanks, Janusz Janusz Krzysztofik (1): drm/i915: Split off pci_driver.remove() tail to drm_driver.release() drivers/gpu/drm/i915/i915_drv.c | 17 +++++++++++++---- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 10 +++++++++- 3 files changed, 23 insertions(+), 5 deletions(-) -- 2.21.0

3 4

[PATCH 1/2] dt-bindings: display: Add King Display KD035G6-54NT panel documentation
by Paul Cercueil 03 Jun '19

03 Jun '19

The KD035G6-54NT is a 3.5" 320x240 24-bit TFT LCD panel. Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- .../panel/kingdisplay,kd035g6-54nt.txt | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt new file mode 100644 index 000000000000..a6e4a9af4925 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt @@ -0,0 +1,27 @@ +King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel + +Required properties: +- compatible: should be "kingdisplay,kd035g6-54nt" +- power-supply: See panel-common.txt +- reset-gpios: See panel-common.txt + +Optional properties: +- backlight: see panel-common.txt + +Example: + +&spi { + display-panel { + compatible = "kingdisplay,kd035g6-54nt"; + reg = <0>; + + spi-max-frequency = <3125000>; + spi-3wire; + spi-cs-high; + + reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>; + + backlight = <&backlight>; + power-supply = <&ldo6>; + }; +}; -- 2.21.0.593.g511ec345e18

3 4

[PATCHv6 0/4] omapdrm: DSI command mode panel support
by Sebastian Reichel 03 Jun '19

03 Jun '19

Hi, Here is another round of the DSI command mode panel patchset integrating the feedback from PATCHv5. The patches are based on v5.2-rc1 tag. It does not contain the patches required for OMAP3 support (it needs a workaround for a hardware bug) and for automatic display rotation. They should get their own series, once after everything has been moved to DRM panel API. I think DRM panel conversion should happen _after_ this series, since otherwise there is a high risk of bricking DSI support completely. I already started a WIP branch for converting DSI to the DRM panel API on top of this patchset. Tested on Droid 4: * Display blanking - automatic backlight blanking is missing (not handled by DSI) * Framebuffer Console, updated at 1Hz due to blinking cursor * Xorg 1.19 with modesetting driver * Weston 5.0 with DRM backend * kmstest (static image) * No updates send when nothing needs to be sent Known issues: * OMAP3 is untested and most likely broken due to missing workaround(s) for hardware bugs. * Weston 5.0 with fbdev backend does not work, since it uses neither page flip nor dirty ioctl. You need to use the drm backend. Changes since PATCHv5: * Rebased to v5.2-rc1 * Simplified omap_framebuffer_dirty() by using drm_for_each_crtc() Changes since PATCHv4: * Apply Acked-/Tested-by received from Tony and Pavel * Fix spelling/optimize commit messages * Use proper multi-line comments * Restructure patch 4: move the whole HDMI block into a static subfunction, that is only called when output type is HDMI. Also drop the incorrect check for DVI. Changes since PATCHv3: * Drop all Tested/Acked-by tags * Drop the rotation patches for now * Rebase to 4.20-rc1 + fixes from Laurent and Tony * Add fixes for DSI regressions introduced in 4.20-rc1 * Store info update manual update mode in omap_crtc_state * Lock modesetting in omap_framebuffer_dirty * Directly loop through CRTCs instead of connectors in dirty function * Properly refresh display during page flips and get Weston working * Add more comments about implementation details Changes since PATCHv2: * Drop omap3 quirk patch (OMAP3 should get its own mini-series) * Rebase to current linux-next * Use existing 'rotation' DT property to set DRM orientation hint * Add Tested-by from Tony Changes since PATCHv1: * Drop patches, that were queued by Tomi * Rebase to current master * Rework the omap3 workaround patch to only affect omap3 * Add orientation DRM property support -- Sebastian Sebastian Reichel (4): drm/omap: use DRM_DEBUG_DRIVER instead of CORE drm/omap: don't check dispc timings for DSI drm/omap: add framedone interrupt support drm/omap: add support for manually updated displays drivers/gpu/drm/omapdrm/omap_crtc.c | 182 ++++++++++++++++++++++++++-- drivers/gpu/drm/omapdrm/omap_crtc.h | 2 + drivers/gpu/drm/omapdrm/omap_drv.h | 4 +- drivers/gpu/drm/omapdrm/omap_fb.c | 19 +++ drivers/gpu/drm/omapdrm/omap_irq.c | 25 ++++ drivers/gpu/drm/omapdrm/omap_irq.h | 1 + 6 files changed, 222 insertions(+), 11 deletions(-) -- 2.20.1

8 22

[Bug 110807] Regression: artifacts in Chromium after mesa 19.0.5 update
by bugzilla-daemon＠freedesktop.org 03 Jun '19

03 Jun '19

https://bugs.freedesktop.org/show_bug.cgi?id=110807 Bug ID: 110807 Summary: Regression: artifacts in Chromium after mesa 19.0.5 update Product: Mesa Version: 19.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: mezin.alexander(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 144403 --> https://bugs.freedesktop.org/attachment.cgi?id=144403&action=edit Artifacts in Chromium mesa 19.0.4: Chromium works fine mesa 19.0.5, 19.1.0-rc4 (haven't tested other 19.1 rcs yet): see attached screenshot Hardware: RX Vega 64 (Sapphire Nitro+) Distro: Arch Linux Kernel: 5.1.6, 4.19.47 - no difference X.org server 1.20.5, no difference between modesetting and amdgpu drivers chromium 74.0.3729.169 Not sure if it's a hardware-specific problem or generic mesa issue -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
by bugzilla-daemon＠freedesktop.org 03 Jun '19

03 Jun '19

https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #25 from Matt Coffin <mcoffin13(a)gmail.com> --- (In reply to Mauro Gaspari from comment #24) > Hi, a bit frustrating eh? :) > I have been asking around and it seems that RadeonVII and RX590 do not > suffer those issues. Probably related to default clock speeds by > manufacturers. FWIW, I'm seeing this exact same issue, and I'm on an RX590. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm/doc: More fine-tuning on userspace review requirements
by Daniel Vetter 03 Jun '19

03 Jun '19

With Eric's patch commit ba6e798ecf320716780bb6a6088a8d17dcba1d49 Author: Eric Anholt <eric(a)anholt.net> Date: Wed Apr 24 11:56:17 2019 -0700 drm/doc: Document expectation that userspace review looks at kernel uAPI. there's been concerns raised that we expect userspace people to do in-depth kernel patch review. That's not reasonable, same way kernel people can't review all the userspace we have. Try to clarify expectations a bit more. Cc: Eric Anholt <eric(a)anholt.net> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> Cc: contact(a)emersion.fr Cc: wayland-devel(a)lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- Documentation/gpu/drm-uapi.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 05874d09820c..f368e58fb727 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -85,9 +85,9 @@ leads to a few additional requirements: - The userspace side must be fully reviewed and tested to the standards of that userspace project. For e.g. mesa this means piglit testcases and review on the mailing list. This is again to ensure that the new interface actually gets the - job done. The userspace-side reviewer should also provide at least an - Acked-by on the kernel uAPI patch indicating that they've looked at how the - kernel side is implementing the new feature being used. + job done. The userspace-side reviewer should also provide an Acked-by on the + kernel uAPI patch indicating that they believe the proposed uAPI is sound and + sufficiently documented and validated for userspace's consumption. - The userspace patches must be against the canonical upstream, not some vendor fork. This is to make sure that no one cheats on the review and testing -- 2.20.1

4 3

[PATCH v2] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
by Janusz Krzysztofik 03 Jun '19

03 Jun '19

In order to support driver hot unbind, some cleanup operations, now performed on PCI driver remove, must be called later, after all device file descriptors are closed. Split out those operations from the tail of pci_driver.remove() callback and put them into drm_driver.release() which is called as soon as all references to the driver are put. As a result, those cleanups will be now run on last drm_dev_put(), either still called from pci_driver.remove() if all device file descriptors are already closed, or on last drm_release() file operation. Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik(a)linux.intel.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> --- Changelog: v1 -> v2: - defer intel_engines_cleanup() as well. (Chris) drivers/gpu/drm/i915/i915_drv.c | 17 +++++++++++++---- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 10 +++++++++- 3 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 83d2eb9e74cb..8be69f84eb6d 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device *dev) cleanup_gem: i915_gem_suspend(dev_priv); + i915_gem_fini_hw(dev_priv); i915_gem_fini(dev_priv); cleanup_modeset: intel_modeset_cleanup(dev); @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct drm_i915_private *dev_priv) pci_disable_msi(pdev); pm_qos_remove_request(&dev_priv->pm_qos); - i915_ggtt_cleanup_hw(dev_priv); } /** @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) out_cleanup_hw: i915_driver_cleanup_hw(dev_priv); + i915_ggtt_cleanup_hw(dev_priv); out_cleanup_mmio: i915_driver_cleanup_mmio(dev_priv); out_runtime_pm_put: @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev) cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work); i915_reset_error_state(dev_priv); - i915_gem_fini(dev_priv); + i915_gem_fini_hw(dev_priv); intel_power_domains_fini_hw(dev_priv); i915_driver_cleanup_hw(dev_priv); - i915_driver_cleanup_mmio(dev_priv); enable_rpm_wakeref_asserts(dev_priv); - intel_runtime_pm_cleanup(dev_priv); } static void i915_driver_release(struct drm_device *dev) { struct drm_i915_private *dev_priv = to_i915(dev); + disable_rpm_wakeref_asserts(dev_priv); + + i915_gem_fini(dev_priv); + + i915_ggtt_cleanup_hw(dev_priv); + i915_driver_cleanup_mmio(dev_priv); + + enable_rpm_wakeref_asserts(dev_priv); + intel_runtime_pm_cleanup(dev_priv); + i915_driver_cleanup_early(dev_priv); i915_driver_destroy(dev_priv); } diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a2664ea1395b..d08e7bd83544 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private *i915); int __must_check i915_gem_init(struct drm_i915_private *dev_priv); int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv); void i915_gem_init_swizzling(struct drm_i915_private *dev_priv); +void i915_gem_fini_hw(struct drm_i915_private *dev_priv); void i915_gem_fini(struct drm_i915_private *dev_priv); int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv, unsigned int flags, long timeout); diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 7cafd5612f71..20d3f7532cef 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv) return ret; } -void i915_gem_fini(struct drm_i915_private *dev_priv) +void i915_gem_fini_hw(struct drm_i915_private *dev_priv) { GEM_BUG_ON(dev_priv->gt.awake); @@ -4680,6 +4680,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv) mutex_lock(&dev_priv->drm.struct_mutex); intel_uc_fini_hw(dev_priv); intel_uc_fini(dev_priv); + mutex_unlock(&dev_priv->drm.struct_mutex); + + i915_gem_drain_freed_objects(dev_priv); +} + +void i915_gem_fini(struct drm_i915_private *dev_priv) +{ + mutex_lock(&dev_priv->drm.struct_mutex); intel_engines_cleanup(dev_priv); i915_gem_contexts_fini(dev_priv); i915_gem_fini_scratch(dev_priv); -- 2.21.0

2 1

[PATCH v1 0/2] Adds slave pipeline support
by Lowry Li (Arm Technology China) 03 Jun '19

03 Jun '19

Hi, This serie aims at adding the support for slave pipeline on Komeda driver. Also adds drop_master to shutdown the device and make sure all the komeda resources shared between crtcs have been released. This patch series depends on: - https://patchwork.freedesktop.org/series/58710/ - https://patchwork.freedesktop.org/series/59000/ - https://patchwork.freedesktop.org/series/59002/ - https://patchwork.freedesktop.org/series/59747/ - https://patchwork.freedesktop.org/series/59915/ - https://patchwork.freedesktop.org/series/60083/ - https://patchwork.freedesktop.org/series/60698/ - https://patchwork.freedesktop.org/series/60856/ - https://patchwork.freedesktop.org/series/60893/ - https://patchwork.freedesktop.org/series/61370/ Regards, Lowry Lowry Li (Arm Technology China) (2): drm/komeda: Add slave pipeline support drm/komeda: Adds komeda_kms_drop_master drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 41 ++++++++++++++++++++-- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 23 ++++++++++++ drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 9 +++++ .../gpu/drm/arm/display/komeda/komeda_pipeline.c | 22 ++++++++++++ .../gpu/drm/arm/display/komeda/komeda_pipeline.h | 2 ++ .../drm/arm/display/komeda/komeda_pipeline_state.c | 15 ++++++++ drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 32 ++++++++++++++++- 7 files changed, 141 insertions(+), 3 deletions(-) -- 1.9.1

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2019