dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[PATCH] drm/radeon: only init fbdev if we have connectors
by Rob Clark 26 Jan '16

26 Jan '16

This fixes an issue that was noticed on an optimus/prime laptop with a kernel that was old enough to not support the integrated intel gfx (which was driving all the outputs), but did have support for the discrete radeon gpu. The end result was not falling back to VESA and leaving the user with a black screen. (Plus it is kind of silly to create an framebuffer device if there are no outputs hooked up to the gpu.) Signed-off-by: Rob Clark <robdclark(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_display.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 1eca0ac..f8e776c 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1670,8 +1670,10 @@ int radeon_modeset_init(struct radeon_device *rdev) /* setup afmt */ radeon_afmt_init(rdev); - radeon_fbdev_init(rdev); - drm_kms_helper_poll_init(rdev->ddev); + if (!list_empty(&rdev->ddev->mode_config.connector_list)) { + radeon_fbdev_init(rdev); + drm_kms_helper_poll_init(rdev->ddev); + } /* do pm late init */ ret = radeon_pm_late_init(rdev); -- 2.5.0

3 4

[PATCH v6 0/1] Introduce Innosilicon HDMI driver on Rockchip platforms
by Yakir Yang 26 Jan '16

26 Jan '16

Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec - Digital video interface supports a pixel size of 24, 30, 36, 48bits color depth in RGB - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission (32-192kHz Fs) using IEC60958 and IEC 61937 - The EDID and CEC function are also supported by Innosilicon HDMI Transmitter Controlle Changes in v6: - Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver (Caeser) Changes in v5: - Use hdmi_infoframe helper functions to packed the infoframe (Russell) - Remove the unused double wait_for_completion_timeout for ddc transfer (Russell) - Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell) Changes in v4: - Modify the commit title "drm/rockchip: hdmi: ..." (Mark) - Correct the "DKMS" to "DPMS" (Mark) - Fix over 80 characters problems (Mark) - Remove encoder .prepare/.commit helper functions, and move the vop mode configure function into encoder .enable helper functions. (Mark) Changes in v3: - Use encoder enable/disable function, and remove the encoder DPMS function - Keep HDMI PLL power on in standby mode Changes in v2: - Using DRM atomic helper functions for connector init (Mark) - Remove "hdmi->connector.encoder = encoder;" (Mark) Yakir Yang (1): drm/rockchip: hdmi: add Innosilicon HDMI support drivers/gpu/drm/rockchip/Kconfig | 8 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/inno_hdmi.c | 941 +++++++++++++++++++++++++++++++++++ drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++++++++++++++ 4 files changed, 1312 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h -- 1.9.1

3 5

Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon
by Ville Syrjälä 25 Jan '16

25 Jan '16

On Fri, Jan 15, 2016 at 11:34:08AM +0100, Vlastimil Babka wrote: > Hi, > > since kernel 4.4 I'm unable to login to kde5 desktop (on openSUSE > Tumbleweed). There's a screen with progressbar showing the startup, > which normally fades away after reaching 100%. But with kernel 4.4, the > progress gets stuck somewhere between 1/2 and 3/4 (not always the same). > Top shows that kwin is using few % of CPU's but mostly sleeps in poll(). > When I kill it from another console, I see that everything has actually > started up, just the progressbar screen was obscuring it. The windows > obviously don't have decorations etc. Starting kwin manually again shows > me again the progressbar screen at the same position. Hmm. Sounds like it could then be waiting for a vblank in the distant future. There's that 1<<23 limit in the code though, but even with that we end up with a max wait of ~38 hours assuming a 60Hz refresh rate. Stuff to try might include enabling drm.debug=0x2f, though that'll generate a lot of stuff. Another option would be to use the drm vblank tracepoints to try and catch what seq number it's waiting for and where we're at currently. Or I suppose you could just hack up drm_wait_vblank() to print an error message or something if the requested seq number is in the future by, say, more than a few seconds, and if that's the case then we could try to figure out why that happens. > > I have suspected that kwin is waiting for some event, but nevertheless > tried bisecting the kernel between 4.3 and 4.4, which lead to: > > # first bad commit: [4dfd64862ff852df7b1198d667dda778715ee88f] drm: Use > vblank timestamps to guesstimate how many vblanks were missed > > I can confirm that 4.4 works if I revert the following commits: > 63154ff230fc9255cc507af6277cd181943c50a1 "drm/amdgpu: Fixup hw vblank > counter/ts for new drm_update_vblank_count() (v3)" > > d1145ad1e41b6c33758a856163198cb53bb96a50 "drm/radeon: Fixup hw vblank > counter/ts for new drm_update_vblank_count() (v2)" The sha1s don't seem to match what I have, so not sure which kernel tree you have, but looking at the radeon commit at least one thing immediately caught my attention; + /* Bump counter if we are at >= leading edge of vblank, + * but before vsync where vpos would turn negative and + * the hw counter really increments. + */ + if (vpos >= 0) + count++; It's rather hard to see what it's really doing since the custom flags to the get_scanout_position now cause it return non-standard things. But if I'm reading things correctly it should really say something like: if (vpos >= 0 && vpos < (vsync_start - vblank_start)) count++; Hmm. Actually even that might not be correct since it could be using the "fake" vblank start here, so might be it'd need to be something like: if (vpos >= 0 && vpos < (vsync_start - vblank_start + lb_vblank_lead_lines) count++; Also might be worth a shot to just ignore the hw frame counter. Eg.: index e266ffc520d2..db728580549a 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -492,7 +492,6 @@ static struct drm_driver kms_driver = { .lastclose = radeon_driver_lastclose_kms, .set_busid = drm_pci_set_busid, .unload = radeon_driver_unload_kms, - .get_vblank_counter = radeon_get_vblank_counter_kms, .enable_vblank = radeon_enable_vblank_kms, .disable_vblank = radeon_disable_vblank_kms, .get_vblank_timestamp = radeon_get_vblank_timestamp_kms, diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c index 979f3bf65f2c..3c5fcab74152 100644 --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c @@ -152,11 +152,6 @@ int radeon_driver_irq_postinstall_kms(struct drm_device *dev) { struct radeon_device *rdev = dev->dev_private; - if (ASIC_IS_AVIVO(rdev)) - dev->max_vblank_count = 0x00ffffff; - else - dev->max_vblank_count = 0x001fffff; - return 0; } assuming I'm reading the code correctly. > > 31ace027c9f1f8e0a2b09bbf961e4db7b1f6cf19 "drm: Don't zero vblank > timestamps from the irq handler" > > ac0567a4b132fa66e3edf3f913938af9daf7f916 "drm: Add DRM_DEBUG_VBL()" > > 4dfd64862ff852df7b1198d667dda778715ee88f "drm: Use vblank timestamps to > guesstimate how many vblanks were missed" > > All clean reverts, just needs some fixup on top to use abs() instead of > abs64() due to 79211c8ed19c055ca105502c8733800d442a0ae6. > > Unfortunately I don't know if this is a kernel problem or kwin problem. > I tried to CC maintainers of both, advices what to try or what info to > provide welcome. The card is "CAICOS" with 1GB memory. > > Thanks, > Vlastimil -- Ville Syrjälä Intel OTC

5 18

[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm
by bugzilla-daemon＠freedesktop.org 25 Jan '16

25 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=92944 Bug ID: 92944 Summary: [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: ernstp(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 119654 --> https://bugs.freedesktop.org/attachment.cgi?id=119654&action=edit backtrace Every time CS:GO has finished loading a level and is about to draw 3D graphics it crashes with this error before any 3D graphics is displayed. Attaching the backtrace. Hardware: Radeon Fury Intel 2500k Software: 64-bit Ubuntu 15.10 LLVM 3.8~svn252698-0~padoka0 Mesa 11.1~git151113012700.2de2e17~padoka0 Linux both 4.3.0 and agd5f/powerplay tested Other games work fine, Borderlands, Civ 5, Shadow of Mordor, Metro: Last Light (old version). -- You are receiving this mail because: You are the assignee for the bug.

1 16

[PATCH] drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctl
by Matthew Dawson 25 Jan '16

25 Jan '16

Found with lockdep while testing gpu reset. Signed-off-by: Matthew Dawson <matthew(a)mjdsystems.ca> --- drivers/gpu/drm/radeon/radeon_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 3dcc573..e26c963 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -663,6 +663,7 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data, bo_va = radeon_vm_bo_find(&fpriv->vm, rbo); if (!bo_va) { args->operation = RADEON_VA_RESULT_ERROR; + radeon_bo_unreserve(rbo); drm_gem_object_unreference_unlocked(gobj); return -ENOENT; } -- 2.7.0

3 2

[PATCH] drm/crtc-helper: Add caveat to disable_unused_functions doc
by Daniel Vetter 25 Jan '16

25 Jan '16

This shouldn't be used by atomic drivers any more, it confuses the state tracking. Cc: Maxime Ripard <maxime.ripard(a)free-electrons.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_crtc_helper.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index a02a7f9a6a9d..a278fbbe23e0 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -220,6 +220,15 @@ static void __drm_helper_disable_unused_functions(struct drm_device *dev) * disconnected connectors. Then it will disable all unused encoders and CRTCs * either by calling their disable callback if available or by calling their * dpms callback with DRM_MODE_DPMS_OFF. + * + * NOTE: + * + * This function is part of the legacy modeset helper library and will cause + * major confusion with atomic drivers. This is because atomic helpers guarantee + * to never call ->disable() hooks on a disabled function, or ->enable() hooks + * on an enabled functions. drm_helper_disable_unused_functions() on the other + * hand throws such guarantees into the wind and calls disable hooks + * unconditionally on unused functions. */ void drm_helper_disable_unused_functions(struct drm_device *dev) { -- 2.7.0.rc3

2 1

[PATCH] drm/i915: Remove select to deleted STOP_MACHINE from Kconfig
by Andreas Ziegler 25 Jan '16

25 Jan '16

Commit 86fffe4a61dd ("kernel: remove stop_machine() Kconfig dependency") removed the option STOP_MACHINE from init/Kconfig, but missed a select to this option from the DRM_I915 option. Remove this now obsolete select statement. Signed-off-by: Andreas Ziegler <andreas.ziegler(a)fau.de> --- drivers/gpu/drm/i915/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index fcd77b2..051eab3 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -10,7 +10,6 @@ config DRM_I915 # the shmem_readpage() which depends upon tmpfs select SHMEM select TMPFS - select STOP_MACHINE select DRM_KMS_HELPER select DRM_PANEL select DRM_MIPI_DSI -- 1.9.1

3 3

[PATCH] drm: armada: use dma_addr_t properly
by Arnd Bergmann 25 Jan '16

25 Jan '16

The armada_gem driver stores a DMA address token in a resource_size_t. This is safe because both are always at least 32 bits wide and can store any address that is accessible by this driver. However, it is a slight type mismatch when we assign it from/to an sg_dma_address() value, and we get a warning in any configuration in which resource_size_t is shorter than dma_addr_t: drivers/gpu/drm/armada/armada_gem.c: In function 'armada_gem_alloc_private_object': arch/arm/include/asm/dma-mapping.h:16:24: warning: large integer implicitly truncated to unsigned type [-Woverflow] #define DMA_ERROR_CODE (~(dma_addr_t)0x0) ^ drivers/gpu/drm/armada/armada_gem.c:204:18: note: in expansion of macro 'DMA_ERROR_CODE' obj->dev_addr = DMA_ERROR_CODE; ^ Changing the type to dma_addr_t solves both issues. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/gpu/drm/armada/armada_gem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/armada/armada_gem.h b/drivers/gpu/drm/armada/armada_gem.h index b000ea3a829a..270cff02c1cd 100644 --- a/drivers/gpu/drm/armada/armada_gem.h +++ b/drivers/gpu/drm/armada/armada_gem.h @@ -15,7 +15,7 @@ struct armada_gem_object { struct drm_gem_object obj; void *addr; phys_addr_t phys_addr; - resource_size_t dev_addr; + dma_addr_t dev_addr; struct drm_mm_node *linear; /* for linear backed */ struct page *page; /* for page backed */ struct sg_table *sgt; /* for imported */ -- 2.7.0

1 0

[Bug 93648] Random lines being rendered when playing Dolphin on radeonsi (w/ apitrace)
by bugzilla-daemon＠freedesktop.org 25 Jan '16

25 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=93648 Bug ID: 93648 Summary: Random lines being rendered when playing Dolphin on radeonsi (w/ apitrace) Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: delroth(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org We recently setup Dolphin's automated rendering tests on Fiji XT with Mesa/amdgpu. It started detected a random rendering issue which I think we can attribute to a driver bug. See https://fifoci.dolphin-emu.org/compare/1086020-1085934/ . Left side has the "bad" rendering, right side the "good" rendering. The issue is properly captured in this apitrace: http://delroth.net/radeon-unpredictable.trace -- rendering it on my Fiji XT system shows the lines but rendering it on i965 doesn't. We have also had reports of users seeing this in action on Pitcairn GPUs: https://bugs.dolphin-emu.org/issues/9239 -- You are receiving this mail because: You are the assignee for the bug.

1 7

[PATCH 00/22] drm_event cleanup, round 2
by Daniel Vetter 25 Jan '16

25 Jan '16

Hi all, Mostly just small changes from review feedback (plus a few misplaced hunks, silly me). Plus an attempt at better kerneldoc to explain how this works. Since that caused questions both from Thomas and Laurent let me explain things also here: Currently anyone using drm_events (vblank code, atomic/legacy flips, drivers like exynos) need to handle event setup, sending to the drm file and handling when the drm file disappears themselves. This patch series provides functions to encapsulate all these steps. Furthermore the file closing is handled differently: Events are no longer completely destroyed in preclose hooks like all current users do, but instead they're just unlinked from the file. The new drm_send_event can still be called, but instead of transmitting the event to the file it'll destroy it right away. This means that when the drm file disappears it's entirely transparent to drivers, and we can remove all the special tracking and cleanup code around preclose functions. The other consequence is that it's opt-in - drivers are still free to remove events explicitly when the file disappears, it's just needless code. Which means the patch series can be split up really nicely into core parts + driver patches. The only patch I didn't split up in this fashion is the one that creates drm_send_event - it's imo easier to review this way, and the driver changes are really simple. Cheers, Daniel Daniel Vetter (22): drm: kerneldoc for drm_fops.c drm: Add functions to setup/tear down drm_events. drm/exynos: Use the new event init/free functions drm/vmwgfx: Use the new event init/free functions drm: Create drm_send_event helpers drm/fsl: Remove preclose hook drm/armada: Remove NULL open/pre/postclose hooks drm/gma500: Remove empty preclose hook drm: Clean up pending events in the core drm: Nuke vblank event file cleanup code drm/i915: Nuke intel_modeset_preclose drm/atmel: Nuke preclose drm/exynos: Remove event cancelling from postclose drm/imx: Unconfuse preclose logic drm/msm: Nuke preclose hooks drm/omap: Nuke close hooks drm/rcar: Nuke preclose hook drm/shmob: Nuke preclose hook drm/tegra: Stop cancelling page flip events drm/tilcdc: Nuke preclose hook drm/vc4: Nuke preclose hook drm/vmwgfx: Nuke preclose hook Documentation/DocBook/gpu.tmpl | 48 +---- drivers/gpu/drm/armada/armada_drv.c | 3 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 -- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 10 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 3 - drivers/gpu/drm/drm_atomic.c | 44 +--- drivers/gpu/drm/drm_crtc.c | 36 +--- drivers/gpu/drm/drm_fops.c | 271 ++++++++++++++++++++++--- drivers/gpu/drm/drm_irq.c | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 -- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 36 +--- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 28 +-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 5 - drivers/gpu/drm/gma500/psb_drv.c | 9 - drivers/gpu/drm/i915/i915_dma.c | 2 - drivers/gpu/drm/i915/intel_display.c | 21 -- drivers/gpu/drm/i915/intel_drv.h | 1 - drivers/gpu/drm/imx/imx-drm-core.c | 13 -- drivers/gpu/drm/imx/ipuv3-crtc.c | 4 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 7 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 11 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 11 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 - drivers/gpu/drm/omapdrm/omap_crtc.c | 13 +- drivers/gpu/drm/omapdrm/omap_drv.c | 41 ---- drivers/gpu/drm/omapdrm/omap_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 20 -- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_drv.c | 10 - drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 20 -- drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 2 - drivers/gpu/drm/shmobile/shmob_drm_drv.c | 8 - drivers/gpu/drm/tegra/dc.c | 17 -- drivers/gpu/drm/tegra/drm.c | 3 - drivers/gpu/drm/tegra/drm.h | 1 - drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 20 -- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 8 - drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 - drivers/gpu/drm/vc4/vc4_crtc.c | 20 -- drivers/gpu/drm/vc4/vc4_drv.c | 10 - drivers/gpu/drm/vc4/vc4_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 87 +------- drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 2 - include/drm/drmP.h | 26 ++- 48 files changed, 312 insertions(+), 623 deletions(-) -- 2.6.4

12 44

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016