dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
by Sebastian Frias 04 Jan '16

04 Jan '16

Hi, On 12/30/2015 09:06 AM, Tomi Valkeinen wrote: > > Also note that I don't want new fbdev drivers into the mainline kernel. > You should implement a DRM based driver instead. > Thanks, is there a porting guide to go from fbdev to DRM? Does DRM provides a "fbdev" backward compatible API? Would that be feasible? I did not find much about that. Currently our stack is something like: Qt -> eglfs -> Mali -> fbdev -> mem -> output (HW) (HW) We don't control the eglfs/Mali (GPU) part. From what I could see, Mali uses DRM with X11 which we do not need (note: I'm not a Mali expert and just took a quick look at the code so I may be wrong), which could be a problem. If "implement a DRM driver" is a lot of work, it would end up as a business decision and probably would not happen. Would you say there are good solid arguments to shake our current stack (other than for dusting it off)? By the way, does DRM improves 2D acceleration support over fbdev? Thanks, Sebastian

3 2

[PATCH 2/9] drm/gma500: use to_pci_dev()
by Geliang Tang 04 Jan '16

04 Jan '16

Use to_pci_dev() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang(a)163.com> --- drivers/gpu/drm/gma500/power.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c index b6b135f..bea8578 100644 --- a/drivers/gpu/drm/gma500/power.c +++ b/drivers/gpu/drm/gma500/power.c @@ -187,7 +187,7 @@ static bool gma_resume_pci(struct pci_dev *pdev) */ int gma_power_suspend(struct device *_dev) { - struct pci_dev *pdev = container_of(_dev, struct pci_dev, dev); + struct pci_dev *pdev = to_pci_dev(_dev); struct drm_device *dev = pci_get_drvdata(pdev); struct drm_psb_private *dev_priv = dev->dev_private; @@ -214,7 +214,7 @@ int gma_power_suspend(struct device *_dev) */ int gma_power_resume(struct device *_dev) { - struct pci_dev *pdev = container_of(_dev, struct pci_dev, dev); + struct pci_dev *pdev = to_pci_dev(_dev); struct drm_device *dev = pci_get_drvdata(pdev); mutex_lock(&power_mutex); -- 2.5.0

2 1

[RESEND 1/3] drm: fsl-dcu: Fix no fb check bug
by Dongsheng Wang 04 Jan '16

04 Jan '16

From: Jianwei Wang <jianwei.wang.chn(a)gmail.com> For state->fb may be NULL in fsl_dcu_drm_plane_atomic_check function, if so, return -EINVAL. No need check in fsl_dcu_drm_plane_atomic_update anymore. Signed-off-by: Jianwei Wang <jianwei.wang.chn(a)gmail.com> Signed-off-by: Yi Meng <b56799(a)freescale.com> Signed-off-by: Wang Dongsheng <dongsheng.wang(a)freescale.com> Tested-by: Stefan Agner <stefan(a)agner.ch> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c index 51daaea..a8932a8 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c @@ -41,6 +41,9 @@ static int fsl_dcu_drm_plane_atomic_check(struct drm_plane *plane, { struct drm_framebuffer *fb = state->fb; + if (!fb) + return -EINVAL; + switch (fb->pixel_format) { case DRM_FORMAT_RGB565: case DRM_FORMAT_RGB888: @@ -85,9 +88,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct drm_plane *plane, unsigned int alpha, bpp; int index, ret; - if (!fb) - return; - index = fsl_dcu_drm_plane_index(plane); if (index < 0) return; -- 2.1.0.27.g96db324

4 8

[PATCH v4 REPOST 00/14] ASoC: hdac_hdmi: Add DP & notification support
by Subhransu S. Prusty 04 Jan '16

04 Jan '16

This patch series adds DP audio and hotplug notification support. On Skylake two DP ports are available and to enable DP on both ports all pins need to be enabled. There is a special vendor widget which need to be programmed to enable all pins and converters. This series adds hotplug notification, read/set constraint based on ELD, enable all pin/cvts, DP1.2, programs the audio infoframe for DP. There is a one to one mapping between converter and stream, so the dais are created based on the no of streams supported on hdmi codec. Even though cvts can be mapped dynamically to the streams, currently it is statically mapped as simultaneous playback on both DP and HDMI is not supported as of now. Pin muxes and controls are created dynamically to map converter to pin widget. So at run time specific pin is mapped to the dai based on the control selected (based on the display type DP/HDMI connected). Finally the DP audio infoframe programming is added to support the DP feature. Also with hotplug notification support, ELD is read and capabilities are set for rate, formats and channels. drm_eld sound/core framework is updated to limit the formats based on ELD. There are few fixes one fixing the static checker warning and other one not to fail if no connection list is found for a pin widget. Pls note, the 10th patch is adding a small macro for getting connection type in drm header, we have CCed drm folks on that and this one. Pls ack so that we can have this series merged thru sound trees changes in v4: - Added NULL check - Dropped the Jack reporting patch for now. Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter(a)intel.com> Jeeja KP (2): ASoC: hdac_hdmi: Add codec suspend/resume handler ASoC: hdac_hdmi: Fix to enable device configuration in hw_params Ramesh Babu (1): ASoC: hdac_hdmi: Fix to keep display active while enumerating codec Subhransu S. Prusty (11): ASoC: hdac_hdmi: Fix to check num nodes correctly ASoC: hdac_hdmi: Fix to warn instead of err for no connected nids ASoC: hdac_hdmi: Use list to add pins and converters ASoC: hdac_hdmi: Add hotplug notification and read eld ASoC: hdac_hdmi: Apply constraints based on ELD ASoC: hdac_hdmi: Enable DP1.2 and all converters/pins ASoC: hdac_hdmi: create dais based on number of streams ASoC: hdac_hdmi: Create widget/route based on nodes enumerated ASoC: hdac_hdmi: Assign pin for stream based on dapm connection drm/edid: Add API to help find connection type ASoC: hdac_hdmi: Add infoframe support for dp audio include/drm/drm_edid.h | 12 + sound/soc/codecs/Kconfig | 1 + sound/soc/codecs/hdac_hdmi.c | 1116 +++++++++++++++++++++++++++++++++++------- 3 files changed, 951 insertions(+), 178 deletions(-) -- 1.9.1

1 1

[PULL] drm-intel-fixes
by Jani Nikula 04 Jan '16

04 Jan '16

Hi Dave, Linus - Two display fixes still for v4.4. The new year's resolution is to start using signed tags per Linus' request. This one is still unsigned; I want to fix this up in our maintainer scripts instead of doing it one-off. BR, Jani. The following changes since commit a98728e0bb978fbe9246c93ea89198de612c22e6: drm/i915: Correct max delay for HDMI hotplug live status checking (2015-12-22 13:01:24 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-01-02 for you to fetch changes up to 3d8acd1f667b45c531401c8f0c2033072e32a05d: drm/i915: increase the tries for HDMI hotplug live status checking (2015-12-30 13:58:37 +0200) ---------------------------------------------------------------- Gary Wang (1): drm/i915: increase the tries for HDMI hotplug live status checking Ville Syrjälä (1): drm/i915: Unbreak check_digital_port_conflicts() drivers/gpu/drm/i915/intel_display.c | 12 ++++++++---- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 2 files changed, 9 insertions(+), 5 deletions(-) -- Jani Nikula, Intel Open Source Technology Center

3 2

[Bug 66501] Feature request: support multiseat for a single multi-headed graphics card
by bugzilla-daemon＠freedesktop.org 03 Jan '16

03 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=66501 --- Comment #7 from Francesco Frassinelli <fraph24(a)gmail.com> --- (In reply to Laércio de Sousa from comment #0) > As long as more display managers gain support to logind's automatic > multiseat feature, it would be nice if the couple "Wayland + multiseat > capable display manager" also support multiseat for a single multi-headed > graphics card. First of all, thank you for your work on Xephyr. I would really like to see this feature and maybe it could be possible to crowdfund the development like Timothy Arceri did with KHR_debug support for Mesa and GL_ARB_arrays_of_arrays extension. Some interesting references: David Herrmann, for Linux Plumbers Conference (2013) - https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/ Laércio de Sousa on Xephyr limitations: - http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/x-org-drm… - http://lists.x.org/archives/xorg-devel/2015-December/048282.html -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] vga_switcheroo: Prettify documentation
by Lukas Wunner 02 Jan '16

02 Jan '16

Fix indentation of vga_switcheroo sections in gpu.tmpl. Change section type of API documentation from "chapter" to "sect1" so that the individual functions no longer clutter up the ToC. Group together under a new "API" chapter. Fix wording "heretoforth" -> "henceforth". Signed-off-by: Lukas Wunner <lukas(a)wunner.de> --- Documentation/DocBook/gpu.tmpl | 40 ++++++++++++++++++++-------------------- drivers/gpu/vga/vga_switcheroo.c | 2 +- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index f96a5d4..8e15980 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -3631,37 +3631,37 @@ int num_ioctls;</synopsis> <chapter id="modes_of_use"> <title>Modes of Use</title> - <sect1> - <title>Manual switching and manual power control</title> + <sect1> + <title>Manual switching and manual power control</title> !Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control - </sect1> - <sect1> - <title>Driver power control</title> + </sect1> + <sect1> + <title>Driver power control</title> !Pdrivers/gpu/vga/vga_switcheroo.c Driver power control - </sect1> + </sect1> </chapter> - <chapter id="pubfunctions"> - <title>Public functions</title> + <chapter id="api"> + <title>API</title> + <sect1> + <title>Public functions</title> !Edrivers/gpu/vga/vga_switcheroo.c - </chapter> - - <chapter id="pubstructures"> - <title>Public structures</title> + </sect1> + <sect1> + <title>Public structures</title> !Finclude/linux/vga_switcheroo.h vga_switcheroo_handler !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops - </chapter> - - <chapter id="pubconstants"> - <title>Public constants</title> + </sect1> + <sect1> + <title>Public constants</title> !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id !Finclude/linux/vga_switcheroo.h vga_switcheroo_state - </chapter> - - <chapter id="privstructures"> - <title>Private structures</title> + </sect1> + <sect1> + <title>Private structures</title> !Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv !Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client + </sect1> </chapter> !Cdrivers/gpu/vga/vga_switcheroo.c diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c index 41edd5a..d64d905 100644 --- a/drivers/gpu/vga/vga_switcheroo.c +++ b/drivers/gpu/vga/vga_switcheroo.c @@ -63,7 +63,7 @@ * for the inactive GPU.) Also, muxes are often used to cut power to the * discrete GPU while it is not used. * - * DRM drivers register GPUs with vga_switcheroo, these are heretoforth called + * DRM drivers register GPUs with vga_switcheroo, these are henceforth called * clients. The mux is called the handler. Muxless machines also register a * handler to control the power state of the discrete GPU, its ->switchto * callback is a no-op for obvious reasons. The discrete GPU is often equipped -- 1.8.5.2 (Apple Git-48)

1 0

[Bug 93522] Tonga has only black virtual terminals
by bugzilla-daemon＠freedesktop.org 02 Jan '16

02 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=93522 Bug ID: 93522 Summary: Tonga has only black virtual terminals Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: EoD(a)xmw.de When I boot the kernel via grub everything is fine, once the kernel is loading there is only a black screen until X starts. When I switch back to the VT (via Ctrl+Alt+F1) I still see everything from X, except the mouse. When I switch back to X everything works fine again. I am using current mesa-git and kernel 4.4-rc6. glxinfo, dmesg, etc: can be found here: https://gist.github.com/EoD/ecb3e28fc004d740daa1 This might be a duplicate of Bug 91202. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[4.4-rc7 / vmwgfx] debugging bug or driver bug?
by Tetsuo Handa 01 Jan '16

01 Jan '16

I booted a CONFIG_PREEMPT_NONE=y && CONFIG_SMP=n kernel (linux.git as of 9c982e86dbdb), and hit BUG_ON() at __vmw_cmdbuf_header_free(). ---------- static void __vmw_cmdbuf_header_free(struct vmw_cmdbuf_header *header) { struct vmw_cmdbuf_man *man = header->man; BUG_ON(!spin_is_locked(&man->lock)); if (header->inline_space) { vmw_cmdbuf_header_inline_free(header); return; } (...snipped...) ---------- [ 1.883512] ------------[ cut here ]------------ [ 1.885102] kernel BUG at drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:250! [ 1.886836] invalid opcode: 0000 [#1] [ 1.888390] Modules linked in: [ 1.889519] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 4.4.0-rc7+ #22 [ 1.891125] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 1.893404] Workqueue: events vmw_fb_dirty_flush [ 1.894767] task: ffff880036406e00 ti: ffff880079a98000 task.ti: ffff880079a98000 [ 1.896572] RIP: 0010:[<ffffffff8143dad4>] [<ffffffff8143dad4>] __vmw_cmdbuf_header_free.isra.16+0x4/0x10 [ 1.898729] RSP: 0018:ffff880079a9bae8 EFLAGS: 00010246 [ 1.900209] RAX: ffff8800365635c8 RBX: ffff88003654aa80 RCX: ffff8800365635e0 [ 1.901950] RDX: ffff8800365635e0 RSI: 0000000000000003 RDI: 0000000000000246 [ 1.903700] RBP: ffff880079a9bae8 R08: 0000000000000000 R09: 0000000000000000 [ 1.905713] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880079b1c300 [ 1.907498] R13: 0000000000000001 R14: ffff88003654aa98 R15: ffff880036563400 [ 1.909306] FS: 0000000000000000(0000) GS:ffffffff81c23000(0000) knlGS:0000000000000000 [ 1.911147] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.912711] CR2: 00007f8e571d8298 CR3: 0000000079b33000 CR4: 00000000001406f0 [ 1.914541] Stack: [ 1.915430] ffff880079a9bb58 ffffffff8143dc78 ffff880036563430 ffff880036563490 [ 1.917350] ffff880036563478 ffff8800365635e0 ffff880036563590 ffff880036563458 [ 1.919311] ffff880036563468 ffff880036563400 ffff880079b1c300 0000000000000008 [ 1.921239] Call Trace: [ 1.922235] [<ffffffff8143dc78>] vmw_cmdbuf_man_process+0xe8/0x220 [ 1.923841] [<ffffffff8143e20f>] __vmw_cmdbuf_cur_flush+0x8f/0xe0 [ 1.925504] [<ffffffff8143ea96>] vmw_cmdbuf_commit+0x96/0xe0 [ 1.927000] [<ffffffff814330c1>] vmw_fifo_commit_flush+0x21/0x40 [ 1.928559] [<ffffffff81433169>] vmw_fifo_send_fence+0x69/0xd0 [ 1.930145] [<ffffffff81426c90>] vmw_execbuf_fence_commands+0x50/0x100 [ 1.931767] [<ffffffff8142b4ab>] vmw_kms_helper_buffer_finish+0x4b/0xe0 [ 1.933442] [<ffffffff8143308e>] ? vmw_fifo_commit+0x1e/0x30 [ 1.935000] [<ffffffff81438139>] vmw_kms_sou_do_dmabuf_dirty+0xe9/0x110 [ 1.936652] [<ffffffff814374c0>] ? vmw_sou_surface_fifo_commit+0xf0/0xf0 [ 1.938408] [<ffffffff81437330>] ? vmw_sou_surface_clip+0x70/0x70 [ 1.939970] [<ffffffff81428b28>] vmw_framebuffer_dmabuf_dirty+0x148/0x1f0 [ 1.941589] [<ffffffff8107c5e9>] ? update_curr+0x99/0xe0 [ 1.943092] [<ffffffff8142df51>] vmw_fb_dirty_flush+0x231/0x290 [ 1.944586] [<ffffffff8106e1fb>] process_one_work+0x11b/0x310 [ 1.946087] [<ffffffff8106e4fe>] worker_thread+0x10e/0x440 [ 1.947586] [<ffffffff8164be9c>] ? __schedule+0x22c/0x590 [ 1.949067] [<ffffffff8106e3f0>] ? process_one_work+0x310/0x310 [ 1.950573] [<ffffffff810730f2>] kthread+0xd2/0xf0 [ 1.951894] [<ffffffff81073020>] ? kthread_worker_fn+0x150/0x150 [ 1.953472] [<ffffffff8164edff>] ret_from_fork+0x3f/0x70 [ 1.954905] [<ffffffff81073020>] ? kthread_worker_fn+0x150/0x150 [ 1.956432] Code: 48 8b 43 f0 c7 00 00 00 00 00 eb e2 be 5b 01 00 00 48 c7 c7 18 81 9a 81 e8 4a d6 c1 ff c6 05 d8 e1 86 00 01 eb da 90 55 48 89 e5 <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 48 89 [ 1.962434] RIP [<ffffffff8143dad4>] __vmw_cmdbuf_header_free.isra.16+0x4/0x10 [ 1.964217] RSP <ffff880079a9bae8> [ 1.965409] ---[ end trace 6120f678d5112bae ]--- [ 1.966727] Kernel panic - not syncing: Fatal exception in interrupt [ 1.968374] Kernel Offset: disabled [ 1.969467] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

2 2

4.4-rc, intel dri i915, regular hangs and corruptions
by Norbert Preining 01 Jan '16

01 Jan '16

Dear all, since 4.4-rc (at least rc2 it was the first I tested), the Intel DRI is in very broken state. Hardware: Sony VAIO Pro 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation Device 90b6 Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at f5c00000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Symptoms: * font corruption sometime sets of glyphs, or practically all glyphs disappear related probably to bug https://bugs.freedesktop.org/show_bug.cgi?id=55500 I have sent some info there already, without response Currently my font displays some kind of strange symbols instead of an m ... looks a bit like a Kanji. * drm/i915 hang: GPU HANG: ecode 7:0:0x86d2bff9, in cinnamon [9300], reason: Ring hung, action: reset opened a new bug as advised https://bugs.freedesktop.org/show_bug.cgi?id=93279 several other hangs like that, reported only one * intelfb is dead switching to the console often leaves a black console Most of the time this happens after a suspend to ram and wake up, but not always. Let me know if there is anything else one might want to know Thanks Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ------------------------------------------------------------------------

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016