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 [mailto:ckoenig.leichtzumer.
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):
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 a
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 can
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&action=edit
dmesg log (maximum verbosity) RX580
--
You are receiving this mail because:
You are the assignee for t
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:
https://www.youtube.com/edit?o=U&vid
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
bind/unbind.
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 = glClientWaitSync( fenceName
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 Sample_PlanarReflections-2.2.0
Let me know if
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&action=edit
Relevant Source Code
--
You are receiving this mail because:
You are the assignee for the bug.
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&action=edit
Binary test built with Debug & full symbols
--
You are receiving this mail because:
You are the assign
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
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 audio, but not 7.1. For some
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 cleanly
> and appears to solv
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
> for ALL Kaveri cards/AP
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 assignee for the bug._
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 calls
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 are receiving this m
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: add Innosilicon HDMI support")
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: bridge/dw_hdmi: add rockchip rk3288 s
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 al
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
Signed-off-by: Thierry Escande
S
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
---
Changes in v9: None
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8
1 file changed, 8 insertions(+)
d
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 clk_disable_unprepare reordering in unbind to separate patch]
Signed-off-by: Enric Balletbo i Serra
-
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&action=edit
First 1000 lines of /var/log/Xorg.0.log (2018-03-04)
Here is an updated version of the Xorg.0.log. The "flip que
https://bugs.freedesktop.org/show_bug.cgi?id=105308
Bob Ham changed:
What|Removed |Added
Attachment #137719|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=105308
Bob Ham changed:
What|Removed |Added
Attachment #137723|0 |1
is obsolete|
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&action=edit
Kernel output while setting /sys/module/drm/parameters/debug to 255 with
monitor off while playing video
--
You a
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 monitor is switched
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 assignee for the bug.___
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 to switch from radeon
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 Vig
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
---
drivers/gpu/drm/sun4i/sun
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 DP_TRAINING_AUX_RD_INTERVAL. Specification lists acceptable
>
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 and bit 7 of DPCD 0xe
>
35 matches
Mail list logo