RE: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

Hi Christian You are right on that part of obj-staged is set to NULL in add_fence, So my following question will be why we kfree(obj->staged) in reserve_shared() if staged is always NULL in that point ? Thanks /Monk -Original Message- From: Christian König

[PATCH] drm/bridge/synopsys: dw-hdmi: Fix memleak in __dw_hdmi_remove

The platform_device_register_full() will allocate dma_mask for hdmi->audio, so we should free before platform_device_unregister(). Reported by kmemleak: unreferenced object 0xffc0ef70ff00 (size 128): comm "kworker/4:1", pid 123, jiffies 4294670080 (age 189.604s) hex dump (first 32 bytes):

Re: [PATCH] drm/sun4i: move rgb mode_valid from connector to encoder

On Sun, Mar 04, 2018 at 11:37:50AM +0100, Giulio Benetti wrote: > mode_valid function must be connected to encoder, not connector. > Otherwise it doesn't get called by drm. That's not true, or rather, that's a big oversimplification. It doesn't get called by DRM if you have a bridge instead of

Re: nouveau 30bpp / deep color status

On 02/05/2018 12:50 AM, Ilia Mirkin wrote: In case anyone's curious about 30bpp framebuffer support, here's the current status: Kernel: Ben and I have switched the code to using a 256-based LUT for Kepler+, and I've also written a patch to cause the addfb ioctl to use the proper format. You

[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]

https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #24 from Ruben Harutyunyan --- Created attachment 137789 --> https://bugs.freedesktop.org/attachment.cgi?id=137789=edit dmesg log (maximum verbosity) RX580 -- You are receiving this mail because: You

[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]

https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #23 from Ruben Harutyunyan --- Hello! I am having a similar (same?) issue on my RX580 (Asus STRIX TOC). Seems to be an issue with MCLK switching. Here is a video of it happening on the desktop:

Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

Hi Laurent, sorry, you're right, this patch should not be needed. the connector should be cleanup by drm_mode_config_cleanup->drm_connector_put. i did that in analogix_dp is to avoid a use-after-free issue not kmemleak, because the connector was allocated/freed in analogix_dp's

[Bug 105339] Deadlock inside glClientWaitSync

https://bugs.freedesktop.org/show_bug.cgi?id=105339 --- Comment #4 from Matias N. Goldberg --- By the way, if I change the waits to the following: while( waitRet != GL_ALREADY_SIGNALED && waitRet != GL_CONDITION_SATISFIED ) { waitDuration = 1 second; waitRet =

[Bug 105339] Deadlock inside glClientWaitSync

https://bugs.freedesktop.org/show_bug.cgi?id=105339 --- Comment #3 from Matias N. Goldberg --- I've uploaded a binary with the repro. Unfortunately it wasn't easy to repro the problem on a simpler one-liner test case. Just download the binary and run

[Bug 105339] Deadlock inside glClientWaitSync

https://bugs.freedesktop.org/show_bug.cgi?id=105339 --- Comment #2 from Matias N. Goldberg --- Created attachment 137784 --> https://bugs.freedesktop.org/attachment.cgi?id=137784=edit Relevant Source Code -- You are receiving this mail because: You are the assignee

[Bug 105339] Deadlock inside glClientWaitSync

https://bugs.freedesktop.org/show_bug.cgi?id=105339 --- Comment #1 from Matias N. Goldberg --- Created attachment 137783 --> https://bugs.freedesktop.org/attachment.cgi?id=137783=edit Binary test built with Debug & full symbols -- You are receiving this mail

[Bug 105339] Deadlock inside glClientWaitSync

https://bugs.freedesktop.org/show_bug.cgi?id=105339 Bug ID: 105339 Summary: Deadlock inside glClientWaitSync Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: blocker

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #31 from Andrew Nelson --- I have been running into the same issue. The problem seems to be that AMDGPU is reporting that it supports 7 speakers instead of 8 in the EID. HBR formats work with 5.1 encoded

[Bug 105262] [R600] [BISECTED] ttf fonts are invisible in many programs

https://bugs.freedesktop.org/show_bug.cgi?id=105262 --- Comment #13 from Pavel Vinogradov --- Confirmed, the patch works. Thank you all for quick solution. (In reply to LoneVVolf from comment #12) > Patch applied to trunk rev 411aa8c322f6703b20d32c7c263fd7ea8639cf3f

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #51 from Alex Deucher --- (In reply to Bong Cosca from comment #48) > Created attachment 137740 [details] [review] > kaveri.patch > > Alex, the patch you suggested overrides the cu_per_sh and backends_per_se >

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #52 from Alex Deucher --- (In reply to Bong Cosca from comment #50) > Will we see this patch/commit on the stable kernel too? Yes, I will CC stable. -- You are receiving this mail because: You are the

Re: [PATCH v2 0/2] Chunk splitting of spi transfers

Den 02.03.2018 12.11, skrev Meghana Madhyastha: On Sun, Feb 25, 2018 at 02:19:10PM +0100, Lukas Wunner wrote: [cc += linux-rpi-ker...@lists.infradead.org] On Sat, Feb 24, 2018 at 06:15:59PM +, Meghana Madhyastha wrote: I've added bcm2835_spi_transfer_one_message in spi-bcm2835. This

[Bug 105262] [R600] [BISECTED] ttf fonts are invisible in many programs

https://bugs.freedesktop.org/show_bug.cgi?id=105262 --- Comment #12 from LoneVVolf --- Patch applied to trunk rev 411aa8c322f6703b20d32c7c263fd7ea8639cf3f cleanly and appears to solve all problems. Pavel, can you or other sourcemage users with r600 cards also test ? -- You

[PATCH v9 3/5] drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind

From: Jeffy Chen In bind the clk_prepare_enable of the HDMI pclk is called before adding the i2c_adapter. So it should be the other way around in unbind, first remove the i2c_adapter and then call the clk_disable_unprepare. Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi:

[PATCH v9 4/5] drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind()

From: Jeffy Chen The HDMI vpll clock should be enabled when bind() is called. So move the clk_prepare_enable of that clock to bind() function and add the missing clk_disable_unprepare() required in error handling path and unbind(). Fixes: 12b9f204e804 ("drm:

[PATCH v9 0/5] rockchip: kevin: Enable edp display

Hi, Actually the name of this patch series is not really true as the edp display is working, but to not confuse I decided to maintain it. Now this patchset is more a group of cleanups, the patchset has been originally posted by Jeffy Chen and the 2 first commits from a previous version (v6) are

[PATCH v9 1/5] drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup.

From: Jeffy Chen In bind()'s error handling path call destroy functions instead of cleanup functions for encoder and connector and reorder to match how is called in bind(). In unbind() call the connector and encoder destroy functions. Signed-off-by: Jeffy Chen

[PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

From: Jeffy Chen We inited connector in attach(), so need a detach() to cleanup. Signed-off-by: Jeffy Chen Signed-off-by: Thierry Escande Signed-off-by: Enric Balletbo i Serra

[PATCH v9 2/5] drm/rockchip: inno_hdmi: Fix error handling path.

From: Jeffy Chen Add missing error handling in bind(). Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support") Signed-off-by: Jeffy Chen Signed-off-by: Thierry Escande [moved

[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"

https://bugs.freedesktop.org/show_bug.cgi?id=105308 --- Comment #11 from Bob Ham --- Created attachment 13 --> https://bugs.freedesktop.org/attachment.cgi?id=13=edit First 1000 lines of /var/log/Xorg.0.log (2018-03-04) Here is an updated version of the Xorg.0.log.

[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"

https://bugs.freedesktop.org/show_bug.cgi?id=105308 Bob Ham changed: What|Removed |Added Attachment #137719|0 |1 is obsolete|

[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"

https://bugs.freedesktop.org/show_bug.cgi?id=105308 Bob Ham changed: What|Removed |Added Attachment #137723|0 |1 is obsolete|

[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"

https://bugs.freedesktop.org/show_bug.cgi?id=105308 --- Comment #9 from Bob Ham --- Created attachment 137775 --> https://bugs.freedesktop.org/attachment.cgi?id=137775=edit Kernel output while setting /sys/module/drm/parameters/debug to 255 with monitor off while playing

[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"

https://bugs.freedesktop.org/show_bug.cgi?id=105308 --- Comment #7 from Bob Ham --- (In reply to Michel Dänzer from comment #6) > Please make sure the problem is actually occurring when you capture the > dmesg debugging output. I've discovered that the problem occurs when the

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #5 from mercuriete --- The width lanes calculation on radeon is a different bug of amdgpu null dereference. But at least that patch silence that warning. -- You are receiving this mail because: You are the

[Bug 105244] NULL dereference during startup of Cape Verde with AMDGPU and GPU passthrough

https://bugs.freedesktop.org/show_bug.cgi?id=105244 --- Comment #5 from mercuriete --- Sorry for the noise: I have a null dereference in a Cape Verde but not in bootup my bug is https://bugs.freedesktop.org/show_bug.cgi?id=102553 Can somebody check that bug It blocks me

Re: [PATCH] drm/sun4i: move rgb mode_valid from connector to encoder

Hello everybody, I wanted to move function sun4i_rgb_encoder_mode_valid from connector section to encoder section. This is why it changes so many things, I don't know if it is the right way to do this. Let me know. Thanks -- Giulio Benetti CTO MICRONOVA SRL Sede: Via A. Niedda 3 - 35010

[PATCH] drm/sun4i: move rgb mode_valid from connector to encoder

mode_valid function must be connected to encoder, not connector. Otherwise it doesn't get called by drm. Move mode_valid function pointer to encoder helper functions, changing its prototype according to encoder helper function pointer. Signed-off-by: Giulio Benetti

Re: [PATCH] drm/dp: only accept valid DP_TRAINING_AUX_RD_INTERVAL values

On Fri, 02 Mar 2018, Rodrigo Vivi wrote: > On Fri, Mar 02, 2018 at 02:25:58PM -0800, matthew.s.atw...@intel.com wrote: >> From: Matt Atwood >> >> For panels that do not follow Display Port specifications mask off invalid >> values for

Re: [PATCH] drm/dp: only accept valid DP_TRAINING_AUX_RD_INTERVAL values

On Fri, 02 Mar 2018, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > For panels that do not follow Display Port specifications mask off invalid > values for DP_TRAINING_AUX_RD_INTERVAL. Specification lists acceptable > values 0-4 all other values are reserved