[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #2 from Emil Velikov --- Wild guess, but can it be bug 67887 ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/bb90d0e9/attachment-0001.html>
[Bug 67800] Computer freezes after idle for several hours (trinity)
https://bugs.freedesktop.org/show_bug.cgi?id=67800 --- Comment #9 from Kertesz Laszlo --- I may have found a crude workaround for the freezing issue. It seems that if i completely disable screensaver (it was turning the monitor off with dpms after 4 minutes) and leave the monitor on permanently works. I now have 1 day uptime. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/rcar-du: fix return value check in rcar_du_lvdsenc_get_resources()
From: Wei Yongjun
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index a0f6a17..f59cbc4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -151,11 +151,8 @@ static int rcar_du_lvdsenc_get_resources(struct
rcar_du_lvdsenc *lvds,
}
lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
- if (lvds->mmio == NULL) {
- dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
- name);
- return -ENOMEM;
- }
+ if (IS_ERR(lvds->mmio))
+ return PTR_ERR(lvds->mmio);
lvds->clock = devm_clk_get(&pdev->dev, name);
if (IS_ERR(lvds->clock)) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #3 from Laurent carlier --- Created attachment 84475 --> https://bugs.freedesktop.org/attachment.cgi?id=84475&action=edit Shader dump with patch applied -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/544a8fab/attachment.html>
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #1 from Alex Deucher --- Can you bisect to track down what commit caused the problem? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/07c60892/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #2 from Laurent carlier --- (In reply to comment #1) > Created attachment 84473 [details] [review] > Possible Fix > > Can you try this mesa patch. If it doesn't fix the crash, can you re-post > the shader dump with the patch applied. With the patch applied it still fail -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/6b872ffe/attachment.html>
[Bug 68451] New: Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 Priority: medium Bug ID: 68451 Assignee: dri-devel at lists.freedesktop.org Summary: Texture flicker in native Dota2 in mesa 9.2.0rc1 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: peter.kraus at geeksonbikes.net Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/DRI/R600 Product: Mesa Hello, hopefully this is the right place to report this stuff. I've got a mildly annoying texture corruption/flicker happening in native Dota2 since recent update in mesa. Downgrading mesa fixes this. Offending versions: 9.2.0rc1-1 of lib32-mesa, lib32-mesa-libgl and lib32-ati-dri as packaged by Archlinux. Reverting to 9.1.6-1 of the above packages resolves this issue (the 64bit packages remain 9.2.0rc1). This is on AMD Radeon Juniper (6750), Arch Linux 64-bit, with the following non-default options in xorg.conf.d: Section "Device" Identifier"ATI" Driver"radeon" Option"ColorTiling""on" Option"ColorTiling2D""on" Option"SwapBuffersWait""false" EndSection Regardless of this corruption, the framerate goes up by about 10 fps. Good job on the release! If I can help in any way, let me know. Peter -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/ae705021/attachment.html>
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #59 from Chu Viet Huong --- Created attachment 84489 --> https://bugs.freedesktop.org/attachment.cgi?id=84489&action=edit create success dmesg attachment After remove generic driver xf86-video-vesa, it work fine :) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #58 from Chu Viet Huong --- Created attachment 84488 --> https://bugs.freedesktop.org/attachment.cgi?id=84488&action=edit create full dmesg attachment. My same issue with RV730 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68389] [radeonsi]Black screen in unigine-tropics
https://bugs.freedesktop.org/show_bug.cgi?id=68389 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tom Stellard --- I've committed the fix. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/71cc0594/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #1 from Tom Stellard --- Created attachment 84473 --> https://bugs.freedesktop.org/attachment.cgi?id=84473&action=edit Possible Fix Can you try this mesa patch. If it doesn't fix the crash, can you re-post the shader dump with the patch applied. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/09094a0a/attachment.html>
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #3 from Alexandre Demers --- kernel 3.11.0-rc1 was experiencing a bug, but not the one seen in rc2 and beyond. I'll dig on the "fix" that brought us to the state seen since rc2. If nothing can be found, I'll go up the drm-next branch that was included in rc1. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module
https://bugzilla.kernel.org/show_bug.cgi?id=60741 Eastern Heart changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Eastern Heart --- *** This bug has been marked as a duplicate of bug 60674 *** -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 Eastern Heart changed: What|Removed |Added CC||zxd123...@hotmail.com --- Comment #16 from Eastern Heart --- *** Bug 60741 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Remove the dithering_mode_property field
Unfortunately, I haven't been thorough enough in:
commit ddecb10cf402a8325579f298fd4986a90f33496b
Author: Lespiau, Damien
Date: Tue Aug 20 00:53:04 2013 +0100
drm: Remove drm_mode_create_dithering_property()
And forgot to remove the dithering_mode_property member of struct
drm_mode_config.
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0a9f73e..960a27c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -837,7 +837,6 @@ struct drm_mode_config {
/* Optional properties */
struct drm_property *scaling_mode_property;
- struct drm_property *dithering_mode_property;
struct drm_property *dirty_info_property;
/* dumb ioctl parameters */
--
1.8.3.1
[PATCH V3] i2c: move of helpers into the core
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Acked-by: Rob Herring Reviewed-by: Felipe Balbi Acked-by: Rafael J. Wysocki Tested-by: Sylwester Nawrocki Signed-off-by: Wolfram Sang --- V2->V3: Was trying to be too smart by only fixing includes needed. Took a more general approach this time, converting of_i2c.h to i2c.h in case i2c.h was not already there. Otherwise remove it. Improved my build scripts and no build failures, no complaints from buildbot as well. Documentation/acpi/enumeration.txt |1 - arch/powerpc/platforms/44x/warp.c |1 - drivers/gpu/drm/tilcdc/tilcdc_slave.c |1 - drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |1 - drivers/gpu/host1x/drm/output.c |2 +- drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 109 +- drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +- drivers/media/platform/exynos4-is/fimc-is.c |2 +- drivers/media/platform/exynos4-is/media-dev.c |1 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- drivers/staging/imx-drm/imx-tve.c |2 +- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - sound/soc/fsl/imx-sgtl5000.c|2 +- sound/soc/fsl/imx-wm8962.c |2 +- 47 files changed, 138 insertions(+), 262 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c index 4cfa499..534574a 100644 --- a/arch/powerpc/platforms/44x/warp.c +++ b/arch/powerpc/platforms/44x/warp.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c index dfffaf0..a19f657 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c @@ -16,7 +16,6 @@ */ #include -#include #include #include #include diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c index 925c7cd..c38b56b 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c @@ -16,7 +16,6 @@ */ #
[PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync support
Thanks for your comments, Inki Dae > -Original Message- > From: David Herrmann [mailto:dh.herrmann at gmail.com] > Sent: Wednesday, August 21, 2013 10:17 PM > To: Inki Dae > Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org; linux- > arm-kernel at lists.infradead.org; linux-media at vger.kernel.org; linaro- > kernel at lists.linaro.org; Maarten Lankhorst; Sumit Semwal; > kyungmin.park at samsung.com; myungjoo.ham at samsung.com > Subject: Re: [PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync > support > > Hi > > On Wed, Aug 21, 2013 at 12:33 PM, Inki Dae wrote: > > This patch adds lock and poll callbacks to dma buf file operations, > > and these callbacks will be called by fcntl and select system calls. > > > > fcntl and select system calls can be used to wait for the completion > > of DMA or CPU access to a shared dmabuf. The difference of them is > > fcntl system call takes a lock after the completion but select system > > call doesn't. So in case of fcntl system call, it's useful when a task > > wants to access a shared dmabuf without any broken. On the other hand, > > it's useful when a task wants to just wait for the completion. > > 1) > So how is that supposed to work in user-space? I don't want to block > on a buffer, but get notified once I can lock it. So I do: > select(..dmabuf..) > Once it is finished, I want to use it: > flock(..dmabuf..) > However, how can I guarantee the flock will not block? Some other > process might have locked it in between. So I do a non-blocking > flock() and if it fails I wait again? s/flock/fcntl Yes, it does if you wanted to do a non-blocking fcntl. The fcntl() call will return -EAGAIN if some other process have locked first. So user process could retry to lock or do other work. This user process called fcntl() with non-blocking mode so in this case, I think the user should consider two things. One is that the fcntl() call couldn't be failed, and other is that the call could take a lock successfully. Isn't fcntl() with a other fd also, not dmabuf, take a same action? >Looks ugly and un-predictable. > So I think this is reasonable. However, for select system call, I'm not sure that this system call is needed yet. So I can remove it if unnecessary. > 2) > What do I do if some user-space program holds a lock and dead-locks? > I think fcntl call with a other fd also could lead same situation, and the lock will be unlocked once the user-space program is killed because when the process is killed, all file descriptors of the process are closed. > 3) > How do we do modesetting in atomic-context in the kernel? There is no > way to lock the object. But this is required for panic-handlers and > more importantly the kdb debugging hooks. > Ok, I can live with that being racy, but would still be nice to be > considered. Yes, The lock shouldn't be called in the atomic-context. For this, will add comments enough. > > 4) > Why do we need locks? Aren't fences enough? That is, in which > situation is a lock really needed? > If we assume we have two writers A and B (DMA, CPU, GPU, whatever) and > they have no synchronization on their own. What do we win by > synchronizing their writes? Ok, yeah, we end up with either A or B and > not a mixture of both. But if we cannot predict whether we get A or B, > I don't know why we care at all? It's random, so a mixture would be > fine, too, wouldn't it? I think not so. There are some cases that the mixture wouldn't be fine. For this, will describe it at below. > > So if user-space doesn't have any synchronization on its own, I don't > see why we need an implicit sync on a dma-buf. Could you describe a > more elaborate use-case? Ok, first, I think I described that enough though [PATCH 0/2]. For this, you can refer to the below link, http://lwn.net/Articles/564208/ Anyway, there are some cases that user-space process needs the synchronization on its own. In case of Tizen platform[1], one is between X Client and X Server; actually, Composite Manager. Other is between Web app based on HTML5 and Web Browser. Please, assume that X Client draws something in a window buffer using CPU, and then the X Client requests SWAP to X Server. And then X Server notifies a damage event to Composite Manager. And then Composite Manager composes the window buffer with its own back buffer using GPU. In this case, Composite Manager calls eglSwapBuffers; internally, flushing GL commands instead of finishing them for more performance. As you may know, the flushing doesn't wait for the complete event from GPU driver. And at the same time, the X Client could do other work, and also draw something in the same buffer again. At this time, The buffer could be broken. Because the X Client can't aware of when GPU access to the buffer is completed without out-of-band hand shaking; the out-of-band hand shaking is quite big overhead. That is why we need user-space locking interface, fcntl system call. And also ther
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929
--- Comment #14 from Torsten Kaiser ---
Created attachment 84467
--> https://bugs.freedesktop.org/attachment.cgi?id=84467&action=edit
apitrace from hanging startup of OpenRA
I'm seeing the same problem with the mono game OpenRA from http://open-ra.org/
on an RV730 PRO [Radeon HD 4650] with mesa-9.2-rc1 (but early mesa versions
showed the same behaviour).
With Gentoo I'm able to switch the R600_LLVM via useflag, but as soon as I'm
using a mesa version with this enabled OpenRA will no longer start. It will
just display a black window, the loading symbols never apear.
Running apitrace gives (full apitrace as attachment):
10 glXChooseVisual(dpy = 0x15fbef0, [snip]) = &{visual = 0x1661f58, [snip]}
11 glXCreateContext(dpy = 0x15fbef0, vis = &{visual = 0x1661f58, [snip]) =
0x16734e0
12 glXMakeCurrent(dpy = 0x15fbef0, drawable = 20971535, ctx = 0x16734e0) = True
43 glXMakeCurrent(dpy = 0x15fbef0, drawable = 20971535, ctx = 0x16734e0) = True
Trying gdb it seems one of the mono threads get stuck in
radeon_drm_cs_emit_ioctl(), the other 7 threads look like mono internal things
relating to its garbage collector.
strace gives:
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 7
connect(7, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
[snip]
open("/dev/dri/card0", O_RDWR|O_CLOEXEC) = 9
[snip]
ioctl(9, 0xc010640b, 0x7fffeb471ea0)= 0
ioctl(9, 0xc00c6469, 0x7fffeb471ec0)= 0
ioctl(9, 0xc020645d, 0x7fffeb471d10)= 0
ioctl(9, 0xc020645d, 0x7fffeb471b10)= 0
ioctl(9, 0xc020645e, 0x7fffeb471b20)= 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x112992000) =
0x7f921dfe9000
ioctl(9, 0xc020645d, 0x7fffeb471b20)= 0
ioctl(9, 0xc020645e, 0x7fffeb471b30)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x1129a2000) =
0x7f921dfe8000
ioctl(9, VIDIOC_INT_RESET, 0x24460b0) = 0
ioctl(9, 0xc020645d, 0x7fffeb471db0)= 0
Then some more interactions with fd=7 until it gets stuck with:
futex(0x984280, FUTEX_WAIT_PRIVATE, 0, NULL
At that point only kill -9 helps.
Do you have anything I should try or any info I should provide?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/79c299f5/attachment.html>
[radeon-alex:drm-next-3.12-wip 31/90] WARNING: kfree(NULL) is safe this check is probably not required
Hi Alex, FYI, there are new warnings show up in tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-3.12-wip head: 21419df38d4ba010b1ea80e2f91b853c8c3de7e5 commit: 38306848032ac045ac5a5f3145271bc01176883e [31/90] drm/radeon/dpm: add support for parsing the atom powertune table scripts/checkpatch.pl 0001-drm-radeon-dpm-add-support-for-parsing-the-atom-powe.patch WARNING: kfree(NULL) is safe this check is probably not required #73: drivers/gpu/drm/radeon/r600_dpm.c:1079: + if (rdev->pm.dpm.dyn_state.cac_tdp_table) + kfree(rdev->pm.dpm.dyn_state.cac_tdp_table); The warning also shows up in many of the follow up patches. [radeon-alex:drm-next-3.12-wip 32/90] WARNING: kfree(NULL) is safe [radeon-alex:drm-next-3.12-wip 35/90] WARNING: kfree(NULL) is safe [radeon-alex:drm-next-3.12-wip 36/90] WARNING: kfree(NULL) is safe [radeon-alex:drm-next-3.12-wip 38/90] WARNING: kfree(NULL) is safe [radeon-alex:drm-next-3.12-wip 39/90] WARNING: kfree(NULL) is safe --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin wrote: > The code expects non-VRAM mem nodes to have a pages list. If that's not > set, it will do a null deref down the line. Warn on that condition and > return an error. > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > > Reported-by: Pasi K?rkk?inen > Tested-by: Pasi K?rkk?inen > Signed-off-by: Ilia Mirkin > Cc: # 3.8+ > --- > > I don't exactly understand what's going on, but this is just a > straightforward way to avoid a null deref that you see happens in the > bug. I haven't figured out the root cause of this, but it's getting > well into the "I have no idea how TTM works" space. However this seems > like a bit of defensive programming -- nouveau_vm_map_sg will pass > node->pages as a list down, which will be dereferenced by > nvc0_vm_map_sg. Perhaps the other arguments should make that > dereferencing not happen, but it definitely was happening here, as you > can see in the bug. > > Ben/Maarten, I'll let you judge whether this check is appropriate, > since like I hope I was able to convey above, I'm just not really sure :) > > drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c > b/drivers/gpu/drm/nouveau/nouveau_bo.c > index cdc3282..191145d 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > @@ -963,6 +963,12 @@ nouveau_vma_getmap(struct nouveau_channel *chan, struct > nouveau_bo *nvbo, > struct nouveau_mem *node = mem->mm_node; > int ret; > > + /* If we ever get here for a non-vram mem node that doesn't > +* have pages, we will end up doing a null deref in > +* nouveau_vm_map_sg. */ > + if (WARN_ON(mem->mem_type != TTM_PL_VRAM && !node->pages)) > + return -EINVAL; My guess here is that this is a mapping that requires the use of map_sg_table() (see nouveau_bo_move_ntfy() for the condition). I'm not entirely sure this should even be happening to be honest. I guess TTM is trying to move a shared buffer from GART to VRAM for some reason (userspace probably asked for it?).. And well, this really shouldn't be allowed.. The other device won't be able to touch it then. If you can confirm this is indeed what's happening, we should find out why and fix it (and have the kernel completely reject such attempts). Ben. > + > ret = nouveau_vm_get(nv_client(chan->cli)->vm, mem->num_pages << > PAGE_SHIFT, node->page_shift, > NV_MEM_ACCESS_RW, vma); > -- > 1.8.1.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #2 from Emil Velikov --- Wild guess, but can it be bug 67887 ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/omap: tiler: clear buffer properly
We're taking the sizeof() the wrong thing so it doesn't clear the whole
buffer.
Signed-off-by: Dan Carpenter
---
I can't compile this.
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 9b794c9..acf6678 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -871,7 +871,7 @@ int tiler_map_show(struct seq_file *s, void *arg)
goto error;
for (lut_idx = 0; lut_idx < omap_dmm->num_lut; lut_idx++) {
- memset(map, 0, sizeof(h_adj * sizeof(*map)));
+ memset(map, 0, h_adj * sizeof(*map));
memset(global_map, ' ', (w_adj + 1) * h_adj);
for (i = 0; i < omap_dmm->container_height; i++) {
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 --- Comment #8 from Johannes Obermayr --- (In reply to comment #3) > I think the problem is that egl_gallium.so links both radeonsi and r600g, > which have some conflicting symbols. Maybe this patch helps: https://github.com/jobermayr/mesa/commit/27db605 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/7d290ebc/attachment.html>
[Bug 68389] [radeonsi]Black screen in unigine-tropics
https://bugs.freedesktop.org/show_bug.cgi?id=68389 --- Comment #7 from Vladimir Ysikov --- >Nothing has changed with this patch. Sorry guys, i forget rebuild mesa after rebuild patched llvm. With Tom's patch unigine-tropics show normal picture. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/c72cf491/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #3 from Laurent carlier --- Created attachment 84475 --> https://bugs.freedesktop.org/attachment.cgi?id=84475&action=edit Shader dump with patch applied -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #1 from Alex Deucher --- Can you bisect to track down what commit caused the problem? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #2 from Laurent carlier --- (In reply to comment #1) > Created attachment 84473 [details] [review] > Possible Fix > > Can you try this mesa patch. If it doesn't fix the crash, can you re-post > the shader dump with the patch applied. With the patch applied it still fail -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] New: Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 Priority: medium Bug ID: 68451 Assignee: dri-devel@lists.freedesktop.org Summary: Texture flicker in native Dota2 in mesa 9.2.0rc1 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: peter.kr...@geeksonbikes.net Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/DRI/R600 Product: Mesa Hello, hopefully this is the right place to report this stuff. I've got a mildly annoying texture corruption/flicker happening in native Dota2 since recent update in mesa. Downgrading mesa fixes this. Offending versions: 9.2.0rc1-1 of lib32-mesa, lib32-mesa-libgl and lib32-ati-dri as packaged by Archlinux. Reverting to 9.1.6-1 of the above packages resolves this issue (the 64bit packages remain 9.2.0rc1). This is on AMD Radeon Juniper (6750), Arch Linux 64-bit, with the following non-default options in xorg.conf.d: Section "Device" Identifier"ATI" Driver"radeon" Option"ColorTiling""on" Option"ColorTiling2D""on" Option"SwapBuffersWait""false" EndSection Regardless of this corruption, the framerate goes up by about 10 fps. Good job on the release! If I can help in any way, let me know. Peter -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/exynos: Make Exynos DRM drivers depend on OF
Hi Tomasz, On 22 August 2013 13:57, Tomasz Figa wrote: > Hi Sachin, > > On Thursday 22 of August 2013 11:15:23 Sachin Kamat wrote: >> Exynos is a DT-only platform. Add this info to Kconfig. >> >> Signed-off-by: Sachin Kamat >> --- >> drivers/gpu/drm/exynos/Kconfig |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/Kconfig >> b/drivers/gpu/drm/exynos/Kconfig index 772c62a..80a251a 100644 >> --- a/drivers/gpu/drm/exynos/Kconfig >> +++ b/drivers/gpu/drm/exynos/Kconfig >> @@ -1,6 +1,6 @@ >> config DRM_EXYNOS >> tristate "DRM Support for Samsung SoC EXYNOS Series" >> - depends on DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) >> + depends on OF && DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) >> select DRM_KMS_HELPER >> select FB_CFB_FILLRECT >> select FB_CFB_COPYAREA >> @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF >> >> config DRM_EXYNOS_FIMD >> bool "Exynos DRM FIMD" >> - depends on OF && DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM >> + depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM >> select FB_MODE_HELPERS >> select VIDEOMODE_HELPERS >> help > > Shouldn't this patch be first in the series? I do not recollect my reasoning for having this at the last :) Thanks for pointing out. -- With warm regards, Sachin
[Bug 68389] [radeonsi]Black screen in unigine-tropics
https://bugs.freedesktop.org/show_bug.cgi?id=68389 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tom Stellard --- I've committed the fix. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #1 from Tom Stellard --- Created attachment 84473 --> https://bugs.freedesktop.org/attachment.cgi?id=84473&action=edit Possible Fix Can you try this mesa patch. If it doesn't fix the crash, can you re-post the shader dump with the patch applied. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration
On Thu, Aug 22, 2013 at 07:33:43AM -0400, Rob Clark wrote: > On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine > wrote: > > On Wed, 21 Aug 2013 23:36:05 +0100 > > Russell King - ARM Linux wrote: > > > >> > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is > >> > no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 > >> > of the Dove lcd for RGB or YUV formats). > >> > > >> > Which board needs a special VIP configuration? > >> > >> If you run the NXP driver, and then run this driver, things get messed > >> up - which has already been covered months ago when this patch was first > >> brought up. > >> > >> It's there to ensure that the TDA998x is correctly configured no matter > >> what it's previous state is, and prevent the thing being fragile as hell. > > > > The NXP driver will never go to the mainline, so, I don't see the > > problem. If you want to use it to test some other drivers, you should > > better patch it instead of adding useless code in the TDA998x driver. > > I don't think it really matters for the end user if NXP isn't > mainline. If they are jumping between vendor kernel and mainline, and > inheriting some state left over from the NXP driver in vendor kernel, > it makes debugging very confusing. It would be less of an issue if a > warm reset actually reset the tda998x part, but that is not the case, > it is better to rely less on the hw state when the driver is loaded, > IMHO. Absolutely right, thanks for backing up what I've said. I've done exactly that - switching between the NXP driver and the mainline driver to debug other problems, and not having the TDA998x setup correctly just makes the job much harder and time consuming. I keep both drivers available in my internal git tree so that I can switch between them when necessary.
[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC
On Wed, Aug 21, 2013 at 01:31:42PM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Wednesday 21 August 2013 17:36:12 Simon Horman wrote: > > On Sat, Aug 10, 2013 at 07:28:30AM +1000, Dave Airlie wrote: > > > On Sat, Aug 10, 2013 at 7:25 AM, Laurent Pinchart wrote: > > > > On Saturday 10 August 2013 06:45:05 Dave Airlie wrote: > > > >> On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman wrote: > > > >> > On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote: > > > >> >> Hi Dave, > > > >> >> > > > >> >> (CC'ing Simon Horman, the shmobile tree maintainer) > > > >> >> > > > >> >> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote: > > > >> >> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote: > > > >> >> > > Hi Dave, > > > >> >> > > > > > >> >> > > I've got a couple of arch/arm/ patches that depend on this > > > >> >> > > series and that I would like to get merged in v3.12. They should > > > >> >> > > go upstream through the arm-soc tree. Would you be able to > > > >> >> > > provide a stable branch with this patch set based on one of the > > > >> >> > > 3.11-rcX tags ? > > > >> >> > > Ideally that branch should have as little patches as possible > > > >> >> > > other than this set. > > > >> >> > > > > >> >> > Yeah that shouldn't be a problem, though is there any interface > > > >> >> > changes or things with this wrt drm-next? > > > >> >> > > > > >> >> > i.e. will this tree build on v3.11-rcX and drm-next? > > > >> >> > > > >> >> They depend on a fix that went in between -rc1 and -rc2. You can > > > >> >> base the branch on any -rc >= 2. > > > >> > > > > >> > An rc2 or rc3 base would be ideal for me, but any rc would be fine. > > > >> > > > >> So the problem with making a stable branch is we have conflicts in > > > >> other places that have already been solved in drm-next, > > > >> > > > >> is there any problem with using Laurent's tree directly as the stable > > > >> point? > > > > > > > > As agreed on IRC, I've rebased the patches on top of v3.11-rc3 and > > > > pushed the result to > > > > > > > > git://linuxtv.org/pinchartl/fbdev.git drm/next/du > > > > > > > > b/drivers/gpu/drm/rcar-du/Kconfig |7 > > > > b/drivers/gpu/drm/rcar-du/Makefile | 10 - > > > > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 255 ++-- > > > > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 13 - > > > > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c | 173 +++--- > > > > b/drivers/gpu/drm/rcar-du/rcar_du_drv.h | 63 +- > > > > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 202 > > > > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 49 + > > > > b/drivers/gpu/drm/rcar-du/rcar_du_group.c | 187 > > > > b/drivers/gpu/drm/rcar-du/rcar_du_group.h | 50 + > > > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c | 165 ++ > > > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.h | 29 --- > > > > b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 131 ++ > > > > b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 25 ++ > > > > b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 196 > > > > b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 46 + > > > > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c | 170 +- > > > > b/drivers/gpu/drm/rcar-du/rcar_du_plane.h | 26 ++ > > > > b/drivers/gpu/drm/rcar-du/rcar_du_regs.h| 94 -- > > > > b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 96 ++ > > > > b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.h | 23 ++ > > > > b/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 69 +++ > > > > b/include/linux/platform_data/rcar-du.h | 34 ++- > > > > drivers/gpu/drm/rcar-du/rcar_du_lvds.c | 216 > > > > drivers/gpu/drm/rcar-du/rcar_du_lvds.h | 24 -- > > > > drivers/gpu/drm/rcar-du/rcar_du_vga.c | 149 > > > > drivers/gpu/drm/rcar-du/rcar_du_vga.h | 24 -- > > > > 27 files changed, 1665 insertions(+), 861 deletions(-) > > > > > > > > Can you merge that into drm-next ? Simon, you can base the r8a7790 arch/ > > > > patches on top of this drm/next/du branch. > > > > > > Actually small change > > > > > > Simon can you use > > > > > > git://git.freedesktop.org/~airlied/linux drm-rcar-for-v3.12 > > > > > > as I've merged this tree with an S-o-b on the merge commit, so other > > > people will know it has gone via me. > > > > Sorry for the delayed response. > > > > I had assumed that the reason I was having trouble fetching > > the remote above was related to the internet connection at the > > end of the world that I was in turn at the end while on holidays. > > > > However, it seems that I am unable to fetch the remote from my office > > either. This may well be a fault at my end, but its not something > > I can readily think of a work around for other than trying from home a > > little later. > > > > # git r
[PATCH 6/6] drm/exynos: Make Exynos DRM drivers depend on OF
Exynos is a DT-only platform. Add this info to Kconfig. Signed-off-by: Sachin Kamat --- drivers/gpu/drm/exynos/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 772c62a..80a251a 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -1,6 +1,6 @@ config DRM_EXYNOS tristate "DRM Support for Samsung SoC EXYNOS Series" - depends on DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) + depends on OF && DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) select DRM_KMS_HELPER select FB_CFB_FILLRECT select FB_CFB_COPYAREA @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF config DRM_EXYNOS_FIMD bool "Exynos DRM FIMD" - depends on OF && DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM + depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM select FB_MODE_HELPERS select VIDEOMODE_HELPERS help -- 1.7.9.5
[PATCH 5/6] drm/exynos: Remove non-DT support in exynos_hdmi
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 70 ++
1 file changed, 12 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8ea07a1..a0e10ae 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1858,7 +1858,6 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
}
-#ifdef CONFIG_OF
static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
{
@@ -1882,33 +1881,7 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
err_data:
return NULL;
}
-#else
-static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
- (struct device *dev)
-{
- return NULL;
-}
-#endif
-
-static struct platform_device_id hdmi_driver_types[] = {
- {
- .name = "s5pv210-hdmi",
- .driver_data= HDMI_TYPE13,
- }, {
- .name = "exynos4-hdmi",
- .driver_data= HDMI_TYPE13,
- }, {
- .name = "exynos4-hdmi14",
- .driver_data= HDMI_TYPE14,
- }, {
- .name = "exynos5-hdmi",
- .driver_data= HDMI_TYPE14,
- }, {
- /* end node */
- }
-};
-#ifdef CONFIG_OF
static struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos5-hdmi",
@@ -1920,7 +1893,6 @@ static struct of_device_id hdmi_match_types[] = {
/* end node */
}
};
-#endif
static int hdmi_probe(struct platform_device *pdev)
{
@@ -1929,30 +1901,21 @@ static int hdmi_probe(struct platform_device *pdev)
struct hdmi_context *hdata;
struct s5p_hdmi_platform_data *pdata;
struct resource *res;
+ const struct of_device_id *match;
int ret;
- if (dev->of_node) {
- pdata = drm_hdmi_dt_parse_pdata(dev);
- if (IS_ERR(pdata)) {
- DRM_ERROR("failed to parse dt\n");
- return PTR_ERR(pdata);
- }
- } else {
- pdata = dev->platform_data;
- }
+if (!dev->of_node)
+ return -ENODEV;
- if (!pdata) {
- DRM_ERROR("no platform data specified\n");
+ pdata = drm_hdmi_dt_parse_pdata(dev);
+ if (!pdata)
return -EINVAL;
- }
- drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx),
- GFP_KERNEL);
+ drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx), GFP_KERNEL);
if (!drm_hdmi_ctx)
return -ENOMEM;
- hdata = devm_kzalloc(dev, sizeof(struct hdmi_context),
- GFP_KERNEL);
+ hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -1963,23 +1926,15 @@ static int hdmi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, drm_hdmi_ctx);
- if (dev->of_node) {
- const struct of_device_id *match;
- match = of_match_node(of_match_ptr(hdmi_match_types),
- dev->of_node);
- if (match == NULL)
- return -ENODEV;
- hdata->type = (enum hdmi_type)match->data;
- } else {
- hdata->type = (enum hdmi_type)platform_get_device_id
- (pdev)->driver_data;
- }
+ match = of_match_node(hdmi_match_types, dev->of_node);
+ if (!match)
+ return -ENODEV;
+ hdata->type = (enum hdmi_type)match->data;
hdata->hpd_gpio = pdata->hpd_gpio;
hdata->dev = dev;
ret = hdmi_resources_init(hdata);
-
if (ret) {
DRM_ERROR("hdmi_resources_init failed\n");
return -EINVAL;
@@ -2134,11 +2089,10 @@ static const struct dev_pm_ops hdmi_pm_ops = {
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
.remove = hdmi_remove,
- .id_table = hdmi_driver_types,
.driver = {
.name = "exynos-hdmi",
.owner = THIS_MODULE,
.pm = &hdmi_pm_ops,
- .of_match_table = of_match_ptr(hdmi_match_types),
+ .of_match_table = hdmi_match_types,
},
};
--
1.7.9.5
[PATCH 4/6] drm/exynos: Remove non-DT support in exynos_drm_g2d
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 0b8b6e4..3271fd4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1534,12 +1534,10 @@ static const struct dev_pm_ops g2d_pm_ops = {
SET_RUNTIME_PM_OPS(g2d_runtime_suspend, g2d_runtime_resume, NULL)
};
-#ifdef CONFIG_OF
static const struct of_device_id exynos_g2d_match[] = {
{ .compatible = "samsung,exynos5250-g2d" },
{},
};
-#endif
struct platform_driver g2d_driver = {
.probe = g2d_probe,
@@ -1548,6 +1546,6 @@ struct platform_driver g2d_driver = {
.name = "s5p-g2d",
.owner = THIS_MODULE,
.pm = &g2d_pm_ops,
- .of_match_table = of_match_ptr(exynos_g2d_match),
+ .of_match_table = exynos_g2d_match,
},
};
--
1.7.9.5
[PATCH 3/6] drm/exynos: Remove non-DT support in exynos_hdmiphy
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index 6021996..59abb14 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -40,13 +40,6 @@ static int hdmiphy_remove(struct i2c_client *client)
return 0;
}
-static const struct i2c_device_id hdmiphy_id[] = {
- { "s5p_hdmiphy", 0 },
- { "exynos5-hdmiphy", 0 },
- { },
-};
-
-#ifdef CONFIG_OF
static struct of_device_id hdmiphy_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiphy",
@@ -58,15 +51,13 @@ static struct of_device_id hdmiphy_match_types[] = {
/* end node */
}
};
-#endif
struct i2c_driver hdmiphy_driver = {
.driver = {
.name = "exynos-hdmiphy",
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(hdmiphy_match_types),
+ .of_match_table = hdmiphy_match_types,
},
- .id_table = hdmiphy_id,
.probe = hdmiphy_probe,
.remove = hdmiphy_remove,
.command= NULL,
--
1.7.9.5
[PATCH 2/6] drm/exynos: Remove non-DT support in exynos_ddc
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_ddc.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
index d1e539b..6a8c84e 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -41,13 +41,6 @@ static int s5p_ddc_remove(struct i2c_client *client)
return 0;
}
-static struct i2c_device_id ddc_idtable[] = {
- {"s5p_ddc", 0},
- {"exynos5-hdmiddc", 0},
- { },
-};
-
-#ifdef CONFIG_OF
static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiddc",
@@ -57,15 +50,13 @@ static struct of_device_id hdmiddc_match_types[] = {
/* end node */
}
};
-#endif
struct i2c_driver ddc_driver = {
.driver = {
.name = "exynos-hdmiddc",
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(hdmiddc_match_types),
+ .of_match_table = hdmiddc_match_types,
},
- .id_table = ddc_idtable,
.probe = s5p_ddc_probe,
.remove = s5p_ddc_remove,
.command= NULL,
--
1.7.9.5
[PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 +++---
1 file changed, 13 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f8889d2..90da9ef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -123,7 +123,6 @@ struct fimd_context {
struct fimd_driver_data *driver_data;
};
-#ifdef CONFIG_OF
static const struct of_device_id fimd_driver_dt_match[] = {
{ .compatible = "samsung,s3c6400-fimd",
.data = &s3c64xx_fimd_driver_data },
@@ -133,21 +132,14 @@ static const struct of_device_id fimd_driver_dt_match[] =
{
.data = &exynos5_fimd_driver_data },
{},
};
-#endif
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
{
-#ifdef CONFIG_OF
const struct of_device_id *of_id =
of_match_device(fimd_driver_dt_match, &pdev->dev);
- if (of_id)
- return (struct fimd_driver_data *)of_id->data;
-#endif
-
- return (struct fimd_driver_data *)
- platform_get_device_id(pdev)->driver_data;
+ return (struct fimd_driver_data *)of_id->data;
}
static bool fimd_display_is_connected(struct device *dev)
@@ -891,23 +883,18 @@ static int fimd_probe(struct platform_device *pdev)
int win;
int ret = -EINVAL;
- if (dev->of_node) {
- pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata)
- return -ENOMEM;
+ if (!dev->of_node)
+ return -ENODEV;
- ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
- OF_USE_NATIVE_MODE);
- if (ret) {
- DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
- return ret;
- }
- } else {
- pdata = dev->platform_data;
- if (!pdata) {
- DRM_ERROR("no platform data specified\n");
- return -EINVAL;
- }
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
+ return ret;
}
panel = &pdata->panel;
@@ -1069,20 +1056,6 @@ static int fimd_runtime_resume(struct device *dev)
}
#endif
-static struct platform_device_id fimd_driver_ids[] = {
- {
- .name = "s3c64xx-fb",
- .driver_data= (unsigned long)&s3c64xx_fimd_driver_data,
- }, {
- .name = "exynos4-fb",
- .driver_data= (unsigned long)&exynos4_fimd_driver_data,
- }, {
- .name = "exynos5-fb",
- .driver_data= (unsigned long)&exynos5_fimd_driver_data,
- },
- {},
-};
-
static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -1091,11 +1064,10 @@ static const struct dev_pm_ops fimd_pm_ops = {
struct platform_driver fimd_driver = {
.probe = fimd_probe,
.remove = fimd_remove,
- .id_table = fimd_driver_ids,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
.pm = &fimd_pm_ops,
- .of_match_table = of_match_ptr(fimd_driver_dt_match),
+ .of_match_table = fimd_driver_dt_match,
},
};
--
1.7.9.5
[PATCH] drm: Remove the dithering_mode_property field
Unfortunately, I haven't been thorough enough in:
commit ddecb10cf402a8325579f298fd4986a90f33496b
Author: Lespiau, Damien
Date: Tue Aug 20 00:53:04 2013 +0100
drm: Remove drm_mode_create_dithering_property()
And forgot to remove the dithering_mode_property member of struct
drm_mode_config.
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0a9f73e..960a27c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -837,7 +837,6 @@ struct drm_mode_config {
/* Optional properties */
struct drm_property *scaling_mode_property;
- struct drm_property *dithering_mode_property;
struct drm_property *dirty_info_property;
/* dumb ioctl parameters */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi K?rkk?inen
> > Tested-by: Pasi K?rkk?inen
> > Signed-off-by: Ilia Mirkin
> > Cc: # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> Not it really isn't appropriate..
>
> You'd have to call call nouveau_vm_map_sg_table instead, the only place that
> doesn't handle that correctly
> is where it's not expected to be called.
>
> Here, have a completely untested patch to fix things...
>
Thanks! I'll give it a try later today..
-- Pasi
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
> {
> struct nouveau_framebuffer *nouveau_fb;
> struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
> int ret = -ENOMEM;
>
> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> if (!gem)
> return ERR_PTR(-ENOENT);
>
> + nvbo = nouveau_gem_object(gem);
> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
> + " valid_domains=%08x\n", nvbo->valid_domains);
> + ret = -EINVAL;
> + goto err_unref;
> + }
> +
> nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> if (!nouveau_fb)
> goto err_unref;
>
> - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
> nouveau_gem_object(gem));
> + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
> if (ret)
> goto err;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/exynos: Make Exynos DRM drivers depend on OF
Hi Sachin, On Thursday 22 of August 2013 11:15:23 Sachin Kamat wrote: > Exynos is a DT-only platform. Add this info to Kconfig. > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/exynos/Kconfig |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig > b/drivers/gpu/drm/exynos/Kconfig index 772c62a..80a251a 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -1,6 +1,6 @@ > config DRM_EXYNOS > tristate "DRM Support for Samsung SoC EXYNOS Series" > - depends on DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) > + depends on OF && DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) > select DRM_KMS_HELPER > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF > > config DRM_EXYNOS_FIMD > bool "Exynos DRM FIMD" > - depends on OF && DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM > + depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM > select FB_MODE_HELPERS > select VIDEOMODE_HELPERS > help Shouldn't this patch be first in the series? Best regards, Tomasz
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929
--- Comment #14 from Torsten Kaiser ---
Created attachment 84467
--> https://bugs.freedesktop.org/attachment.cgi?id=84467&action=edit
apitrace from hanging startup of OpenRA
I'm seeing the same problem with the mono game OpenRA from http://open-ra.org/
on an RV730 PRO [Radeon HD 4650] with mesa-9.2-rc1 (but early mesa versions
showed the same behaviour).
With Gentoo I'm able to switch the R600_LLVM via useflag, but as soon as I'm
using a mesa version with this enabled OpenRA will no longer start. It will
just display a black window, the loading symbols never apear.
Running apitrace gives (full apitrace as attachment):
10 glXChooseVisual(dpy = 0x15fbef0, [snip]) = &{visual = 0x1661f58, [snip]}
11 glXCreateContext(dpy = 0x15fbef0, vis = &{visual = 0x1661f58, [snip]) =
0x16734e0
12 glXMakeCurrent(dpy = 0x15fbef0, drawable = 20971535, ctx = 0x16734e0) = True
43 glXMakeCurrent(dpy = 0x15fbef0, drawable = 20971535, ctx = 0x16734e0) = True
Trying gdb it seems one of the mono threads get stuck in
radeon_drm_cs_emit_ioctl(), the other 7 threads look like mono internal things
relating to its garbage collector.
strace gives:
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 7
connect(7, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
[snip]
open("/dev/dri/card0", O_RDWR|O_CLOEXEC) = 9
[snip]
ioctl(9, 0xc010640b, 0x7fffeb471ea0)= 0
ioctl(9, 0xc00c6469, 0x7fffeb471ec0)= 0
ioctl(9, 0xc020645d, 0x7fffeb471d10)= 0
ioctl(9, 0xc020645d, 0x7fffeb471b10)= 0
ioctl(9, 0xc020645e, 0x7fffeb471b20)= 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x112992000) =
0x7f921dfe9000
ioctl(9, 0xc020645d, 0x7fffeb471b20)= 0
ioctl(9, 0xc020645e, 0x7fffeb471b30)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x1129a2000) =
0x7f921dfe8000
ioctl(9, VIDIOC_INT_RESET, 0x24460b0) = 0
ioctl(9, 0xc020645d, 0x7fffeb471db0)= 0
Then some more interactions with fd=7 until it gets stuck with:
futex(0x984280, FUTEX_WAIT_PRIVATE, 0, NULL
At that point only kill -9 helps.
Do you have anything I should try or any info I should provide?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3] i2c: move of helpers into the core
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Acked-by: Rob Herring Reviewed-by: Felipe Balbi Acked-by: Rafael J. Wysocki Tested-by: Sylwester Nawrocki Signed-off-by: Wolfram Sang --- V2->V3: Was trying to be too smart by only fixing includes needed. Took a more general approach this time, converting of_i2c.h to i2c.h in case i2c.h was not already there. Otherwise remove it. Improved my build scripts and no build failures, no complaints from buildbot as well. Documentation/acpi/enumeration.txt |1 - arch/powerpc/platforms/44x/warp.c |1 - drivers/gpu/drm/tilcdc/tilcdc_slave.c |1 - drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |1 - drivers/gpu/host1x/drm/output.c |2 +- drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 109 +- drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +- drivers/media/platform/exynos4-is/fimc-is.c |2 +- drivers/media/platform/exynos4-is/media-dev.c |1 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- drivers/staging/imx-drm/imx-tve.c |2 +- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - sound/soc/fsl/imx-sgtl5000.c|2 +- sound/soc/fsl/imx-wm8962.c |2 +- 47 files changed, 138 insertions(+), 262 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c index 4cfa499..534574a 100644 --- a/arch/powerpc/platforms/44x/warp.c +++ b/arch/powerpc/platforms/44x/warp.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c index dfffaf0..a19f657 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c @@ -16,7 +16,6 @@ */ #include -#include #include #include #include diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c index 925c7cd..c38b56b 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c @@ -16,7 +16,6 @@ */
Re: [PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration
On Thu, Aug 22, 2013 at 07:33:43AM -0400, Rob Clark wrote: > On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine wrote: > > On Wed, 21 Aug 2013 23:36:05 +0100 > > Russell King - ARM Linux wrote: > > > >> > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is > >> > no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 > >> > of the Dove lcd for RGB or YUV formats). > >> > > >> > Which board needs a special VIP configuration? > >> > >> If you run the NXP driver, and then run this driver, things get messed > >> up - which has already been covered months ago when this patch was first > >> brought up. > >> > >> It's there to ensure that the TDA998x is correctly configured no matter > >> what it's previous state is, and prevent the thing being fragile as hell. > > > > The NXP driver will never go to the mainline, so, I don't see the > > problem. If you want to use it to test some other drivers, you should > > better patch it instead of adding useless code in the TDA998x driver. > > I don't think it really matters for the end user if NXP isn't > mainline. If they are jumping between vendor kernel and mainline, and > inheriting some state left over from the NXP driver in vendor kernel, > it makes debugging very confusing. It would be less of an issue if a > warm reset actually reset the tda998x part, but that is not the case, > it is better to rely less on the hw state when the driver is loaded, > IMHO. Absolutely right, thanks for backing up what I've said. I've done exactly that - switching between the NXP driver and the mainline driver to debug other problems, and not having the TDA998x setup correctly just makes the job much harder and time consuming. I keep both drivers available in my internal git tree so that I can switch between them when necessary. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration
On Thu, Aug 22, 2013 at 08:53:13AM +0200, Jean-Francois Moine wrote: > On Wed, 21 Aug 2013 23:36:05 +0100 > Russell King - ARM Linux wrote: > > > > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is > > > no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 > > > of the Dove lcd for RGB or YUV formats). > > > > > > Which board needs a special VIP configuration? > > > > If you run the NXP driver, and then run this driver, things get messed > > up - which has already been covered months ago when this patch was first > > brought up. > > > > It's there to ensure that the TDA998x is correctly configured no matter > > what it's previous state is, and prevent the thing being fragile as hell. > > The NXP driver will never go to the mainline, so, I don't see the > problem. If you want to use it to test some other drivers, you should > better patch it instead of adding useless code in the TDA998x driver. Sorry, you're wrong. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/exynos: Make Exynos DRM drivers depend on OF
Hi Tomasz, On 22 August 2013 13:57, Tomasz Figa wrote: > Hi Sachin, > > On Thursday 22 of August 2013 11:15:23 Sachin Kamat wrote: >> Exynos is a DT-only platform. Add this info to Kconfig. >> >> Signed-off-by: Sachin Kamat >> --- >> drivers/gpu/drm/exynos/Kconfig |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/Kconfig >> b/drivers/gpu/drm/exynos/Kconfig index 772c62a..80a251a 100644 >> --- a/drivers/gpu/drm/exynos/Kconfig >> +++ b/drivers/gpu/drm/exynos/Kconfig >> @@ -1,6 +1,6 @@ >> config DRM_EXYNOS >> tristate "DRM Support for Samsung SoC EXYNOS Series" >> - depends on DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) >> + depends on OF && DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) >> select DRM_KMS_HELPER >> select FB_CFB_FILLRECT >> select FB_CFB_COPYAREA >> @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF >> >> config DRM_EXYNOS_FIMD >> bool "Exynos DRM FIMD" >> - depends on OF && DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM >> + depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM >> select FB_MODE_HELPERS >> select VIDEOMODE_HELPERS >> help > > Shouldn't this patch be first in the series? I do not recollect my reasoning for having this at the last :) Thanks for pointing out. -- With warm regards, Sachin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68389] [radeonsi]Black screen in unigine-tropics
https://bugs.freedesktop.org/show_bug.cgi?id=68389 --- Comment #6 from Michel D?nzer --- > 0:0(0): error: no matching function for call to > `texelFetch2DOffset(sampler2D, ivec2, int, ivec2)' I was seeing these errors before, but I no longer am. Does it help if you launch Tropics something like: force_glsl_extensions_warn=true disable_blend_func_extended=true ./1024x768_windowed.sh (In reply to comment #3) > Tropics: SIInstrInfo.cpp:94: virtual void > llvm::SIInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, > llvm::MachineBasicBlock::iterator, llvm::DebugLoc, unsigned int, unsigned > int, bool) const: Assertion `AMDGPU::SReg_32RegClass.contains(SrcReg)' > failed. Tom's LLVM patch fixes this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/40b02c5e/attachment.html>
[patch] drm/omap: tiler: clear buffer properly
On Thu, Aug 22, 2013 at 8:42 AM, Dan Carpenter
wrote:
> We're taking the sizeof() the wrong thing so it doesn't clear the whole
> buffer.
>
> Signed-off-by: Dan Carpenter
Oh, that was very certainly wrong before!
Acked-by: Rob Clark
> ---
> I can't compile this.
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 9b794c9..acf6678 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -871,7 +871,7 @@ int tiler_map_show(struct seq_file *s, void *arg)
> goto error;
>
> for (lut_idx = 0; lut_idx < omap_dmm->num_lut; lut_idx++) {
> - memset(map, 0, sizeof(h_adj * sizeof(*map)));
> + memset(map, 0, h_adj * sizeof(*map));
> memset(global_map, ' ', (w_adj + 1) * h_adj);
>
> for (i = 0; i < omap_dmm->container_height; i++) {
[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Aug 22, 2013 at 04:41:06PM +1000, Ben Skeggs wrote: > On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin wrote: > > The code expects non-VRAM mem nodes to have a pages list. If that's not > > set, it will do a null deref down the line. Warn on that condition and > > return an error. > > > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774 > > > > Reported-by: Pasi K?rkk?inen > > Tested-by: Pasi K?rkk?inen > > Signed-off-by: Ilia Mirkin > > Cc: # 3.8+ > > --- > > > > I don't exactly understand what's going on, but this is just a > > straightforward way to avoid a null deref that you see happens in the > > bug. I haven't figured out the root cause of this, but it's getting > > well into the "I have no idea how TTM works" space. However this seems > > like a bit of defensive programming -- nouveau_vm_map_sg will pass > > node->pages as a list down, which will be dereferenced by > > nvc0_vm_map_sg. Perhaps the other arguments should make that > > dereferencing not happen, but it definitely was happening here, as you > > can see in the bug. > > > > Ben/Maarten, I'll let you judge whether this check is appropriate, > > since like I hope I was able to convey above, I'm just not really sure :) > > > > drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c > > b/drivers/gpu/drm/nouveau/nouveau_bo.c > > index cdc3282..191145d 100644 > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > > @@ -963,6 +963,12 @@ nouveau_vma_getmap(struct nouveau_channel *chan, > > struct nouveau_bo *nvbo, > > struct nouveau_mem *node = mem->mm_node; > > int ret; > > > > + /* If we ever get here for a non-vram mem node that doesn't > > +* have pages, we will end up doing a null deref in > > +* nouveau_vm_map_sg. */ > > + if (WARN_ON(mem->mem_type != TTM_PL_VRAM && !node->pages)) > > + return -EINVAL; > My guess here is that this is a mapping that requires the use of > map_sg_table() (see nouveau_bo_move_ntfy() for the condition). > > I'm not entirely sure this should even be happening to be honest. I > guess TTM is trying to move a shared buffer from GART to VRAM for some > reason (userspace probably asked for it?).. And well, this really > shouldn't be allowed.. The other device won't be able to touch it > then. > > If you can confirm this is indeed what's happening, we should find out > why and fix it (and have the kernel completely reject such attempts). > Yes it does happen. I've been experiencing the kernel crash with Linux 3.8.x, 3.9.x and 3.10.x. I'm able to reproduce the crash when having Optimus enabled in BIOS on my Lenovo T430 laptop with Intel IGD + Nvidia GF108 GPU, booting to Xorg desktop, and when I try to enable external DVI monitor connected to nouveau card, the kernel crashes hard.. crash traceback and WARN_ON() tracebacks with this patch applied available in the bugzilla entry: https://bugs.freedesktop.org/show_bug.cgi?id=64774 -- Pasi > Ben. > > > + > > ret = nouveau_vm_get(nv_client(chan->cli)->vm, mem->num_pages << > > PAGE_SHIFT, node->page_shift, > > NV_MEM_ACCESS_RW, vma); > > -- > > 1.8.1.5 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration
On Thu, Aug 22, 2013 at 08:53:13AM +0200, Jean-Francois Moine wrote: > On Wed, 21 Aug 2013 23:36:05 +0100 > Russell King - ARM Linux wrote: > > > > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is > > > no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 > > > of the Dove lcd for RGB or YUV formats). > > > > > > Which board needs a special VIP configuration? > > > > If you run the NXP driver, and then run this driver, things get messed > > up - which has already been covered months ago when this patch was first > > brought up. > > > > It's there to ensure that the TDA998x is correctly configured no matter > > what it's previous state is, and prevent the thing being fragile as hell. > > The NXP driver will never go to the mainline, so, I don't see the > problem. If you want to use it to test some other drivers, you should > better patch it instead of adding useless code in the TDA998x driver. Sorry, you're wrong.
[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 22-08-13 02:10, Ilia Mirkin schreef:
> The code expects non-VRAM mem nodes to have a pages list. If that's not
> set, it will do a null deref down the line. Warn on that condition and
> return an error.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>
> Reported-by: Pasi K?rkk?inen
> Tested-by: Pasi K?rkk?inen
> Signed-off-by: Ilia Mirkin
> Cc: # 3.8+
> ---
>
> I don't exactly understand what's going on, but this is just a
> straightforward way to avoid a null deref that you see happens in the
> bug. I haven't figured out the root cause of this, but it's getting
> well into the "I have no idea how TTM works" space. However this seems
> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> node->pages as a list down, which will be dereferenced by
> nvc0_vm_map_sg. Perhaps the other arguments should make that
> dereferencing not happen, but it definitely was happening here, as you
> can see in the bug.
>
> Ben/Maarten, I'll let you judge whether this check is appropriate,
> since like I hope I was able to convey above, I'm just not really sure :)
Not it really isn't appropriate..
You'd have to call call nouveau_vm_map_sg_table instead, the only place that
doesn't handle that correctly
is where it's not expected to be called.
Here, have a completely untested patch to fix things...
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
int ret = -ENOMEM;
gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
if (!gem)
return ERR_PTR(-ENOENT);
+ nvbo = nouveau_gem_object(gem);
+ if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
+ nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
+ " valid_domains=%08x\n", nvbo->valid_domains);
+ ret = -EINVAL;
+ goto err_unref;
+ }
+
nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
if (!nouveau_fb)
goto err_unref;
- ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
nouveau_gem_object(gem));
+ ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
if (ret)
goto err;
[PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration
On Wed, 21 Aug 2013 23:36:05 +0100 Russell King - ARM Linux wrote: > > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is > > no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 > > of the Dove lcd for RGB or YUV formats). > > > > Which board needs a special VIP configuration? > > If you run the NXP driver, and then run this driver, things get messed > up - which has already been covered months ago when this patch was first > brought up. > > It's there to ensure that the TDA998x is correctly configured no matter > what it's previous state is, and prevent the thing being fragile as hell. The NXP driver will never go to the mainline, so, I don't see the problem. If you want to use it to test some other drivers, you should better patch it instead of adding useless code in the TDA998x driver. > No, reset doesn't restore its settings, only a power cycle does. Sorry, all VIP control registers may be changed at any time and the change appears immediately (thank you for the /sys i2c_read/write). -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 --- Comment #8 from Johannes Obermayr --- (In reply to comment #3) > I think the problem is that egl_gallium.so links both radeonsi and r600g, > which have some conflicting symbols. Maybe this patch helps: https://github.com/jobermayr/mesa/commit/27db605 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration
On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine wrote: > On Wed, 21 Aug 2013 23:36:05 +0100 > Russell King - ARM Linux wrote: > >> > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is >> > no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 >> > of the Dove lcd for RGB or YUV formats). >> > >> > Which board needs a special VIP configuration? >> >> If you run the NXP driver, and then run this driver, things get messed >> up - which has already been covered months ago when this patch was first >> brought up. >> >> It's there to ensure that the TDA998x is correctly configured no matter >> what it's previous state is, and prevent the thing being fragile as hell. > > The NXP driver will never go to the mainline, so, I don't see the > problem. If you want to use it to test some other drivers, you should > better patch it instead of adding useless code in the TDA998x driver. I don't think it really matters for the end user if NXP isn't mainline. If they are jumping between vendor kernel and mainline, and inheriting some state left over from the NXP driver in vendor kernel, it makes debugging very confusing. It would be less of an issue if a warm reset actually reset the tda998x part, but that is not the case, it is better to rely less on the hw state when the driver is loaded, IMHO. BR, -R >> No, reset doesn't restore its settings, only a power cycle does. > > Sorry, all VIP control registers may be changed at any time and the > change appears immediately (thank you for the /sys i2c_read/write). > > -- > Ken ar c'henta? | ** Breizh ha Linux atav! ** > Jef | http://moinejf.free.fr/
[Bug 68389] [radeonsi]Black screen in unigine-tropics
https://bugs.freedesktop.org/show_bug.cgi?id=68389 --- Comment #7 from Vladimir Ysikov --- >Nothing has changed with this patch. Sorry guys, i forget rebuild mesa after rebuild patched llvm. With Tom's patch unigine-tropics show normal picture. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch] drm/omap: tiler: clear buffer properly
On Thu, Aug 22, 2013 at 8:42 AM, Dan Carpenter wrote:
> We're taking the sizeof() the wrong thing so it doesn't clear the whole
> buffer.
>
> Signed-off-by: Dan Carpenter
Oh, that was very certainly wrong before!
Acked-by: Rob Clark
> ---
> I can't compile this.
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 9b794c9..acf6678 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -871,7 +871,7 @@ int tiler_map_show(struct seq_file *s, void *arg)
> goto error;
>
> for (lut_idx = 0; lut_idx < omap_dmm->num_lut; lut_idx++) {
> - memset(map, 0, sizeof(h_adj * sizeof(*map)));
> + memset(map, 0, h_adj * sizeof(*map));
> memset(global_map, ' ', (w_adj + 1) * h_adj);
>
> for (i = 0; i < omap_dmm->container_height; i++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67888] R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace
https://bugs.freedesktop.org/show_bug.cgi?id=67888 --- Comment #5 from fossphreak at gmail.com --- Created attachment 84429 --> https://bugs.freedesktop.org/attachment.cgi?id=84429&action=edit dmesg contents after GPU hangup occurred - Linux kernel 3.11-rc5 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/b03ac07d/attachment.html>
[Bug 67888] R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace
https://bugs.freedesktop.org/show_bug.cgi?id=67888 --- Comment #4 from fossphreak at gmail.com --- Tested with Linux kernel 3.11-rc5 as well. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/9c01f6ff/attachment-0001.html>
[patch] drm/omap: tiler: clear buffer properly
We're taking the sizeof() the wrong thing so it doesn't clear the whole
buffer.
Signed-off-by: Dan Carpenter
---
I can't compile this.
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 9b794c9..acf6678 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -871,7 +871,7 @@ int tiler_map_show(struct seq_file *s, void *arg)
goto error;
for (lut_idx = 0; lut_idx < omap_dmm->num_lut; lut_idx++) {
- memset(map, 0, sizeof(h_adj * sizeof(*map)));
+ memset(map, 0, h_adj * sizeof(*map));
memset(global_map, ' ', (w_adj + 1) * h_adj);
for (i = 0; i < omap_dmm->container_height; i++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #2 from Alexandre Demers --- I began bisecting tonight. Rc2 was already having this bug. More news to come before the weekend. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/a6de8a31/attachment.html>
Re: [PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration
On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine wrote: > On Wed, 21 Aug 2013 23:36:05 +0100 > Russell King - ARM Linux wrote: > >> > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is >> > no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 >> > of the Dove lcd for RGB or YUV formats). >> > >> > Which board needs a special VIP configuration? >> >> If you run the NXP driver, and then run this driver, things get messed >> up - which has already been covered months ago when this patch was first >> brought up. >> >> It's there to ensure that the TDA998x is correctly configured no matter >> what it's previous state is, and prevent the thing being fragile as hell. > > The NXP driver will never go to the mainline, so, I don't see the > problem. If you want to use it to test some other drivers, you should > better patch it instead of adding useless code in the TDA998x driver. I don't think it really matters for the end user if NXP isn't mainline. If they are jumping between vendor kernel and mainline, and inheriting some state left over from the NXP driver in vendor kernel, it makes debugging very confusing. It would be less of an issue if a warm reset actually reset the tda998x part, but that is not the case, it is better to rely less on the hw state when the driver is loaded, IMHO. BR, -R >> No, reset doesn't restore its settings, only a power cycle does. > > Sorry, all VIP control registers may be changed at any time and the > change appears immediately (thank you for the /sys i2c_read/write). > > -- > Ken ar c'hentañ | ** Breizh ha Linux atav! ** > Jef | http://moinejf.free.fr/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68389] [radeonsi]Black screen in unigine-tropics
https://bugs.freedesktop.org/show_bug.cgi?id=68389 --- Comment #5 from Vladimir Ysikov --- Nothing has changed with this patch. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/ed2df0c9/attachment.html>
[Bug 68391] [radeonsi] Crash unigine-sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=68391 --- Comment #3 from Vladimir Ysikov --- I tray get backtrace after crash, but gdb said "No stack". Maybe it does not crash, it's normal exit from the program? My course of action: 1)$gdb --args Sanctuary -video_app opengl -sound_app openal -engine_config ../data/unigine.cfg -data_path ../ -extern_define RELEASE -video_fullscreen 0 -video_mode -1 -video_width 1024 -video_height 768 2)(gdb) run 3)Wait until the closure of the program window 4)(gdb) bt -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130822/762c2989/attachment-0001.html>
[Bug 68389] [radeonsi]Black screen in unigine-tropics
https://bugs.freedesktop.org/show_bug.cgi?id=68389 --- Comment #6 from Michel Dänzer --- > 0:0(0): error: no matching function for call to > `texelFetch2DOffset(sampler2D, ivec2, int, ivec2)' I was seeing these errors before, but I no longer am. Does it help if you launch Tropics something like: force_glsl_extensions_warn=true disable_blend_func_extended=true ./1024x768_windowed.sh (In reply to comment #3) > Tropics: SIInstrInfo.cpp:94: virtual void > llvm::SIInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, > llvm::MachineBasicBlock::iterator, llvm::DebugLoc, unsigned int, unsigned > int, bool) const: Assertion `AMDGPU::SReg_32RegClass.contains(SrcReg)' > failed. Tom's LLVM patch fixes this. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC v3 06/19] video: display: OF support
Hi Philipp,
On Wednesday 21 August 2013 11:10:12 Philipp Zabel wrote:
> Am Mittwoch, den 21.08.2013, 03:02 +0200 schrieb Laurent Pinchart:
> > On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
> > > Hi Laurent,
> > >
> > > thanks for this update. I'm very happy about the move to the display
> > > entity model, given that the i.MX6 IPU has both drm/display and
> > > v4l2/capture ports> in a single device - this will allow to use a
> > > unified device tree binding scheme.
> >
> > Thanks for the support :-)
> >
> > > I'm still trying to see how this all fits together, so far I have only
> > > one comment, below.
> > >
> > > Am Freitag, den 09.08.2013, 19:14 +0200 schrieb Laurent Pinchart:
> > > [...]
> > >
> > > > +static int display_of_parse_dt(struct display_entity_notifier
> > > > *notifier,
> > > > + struct list_head *entities,
> > > > + struct device_node *node)
> > > > +{
> > > > + struct display_entity_of *entity;
> > > > + struct device_node *remote;
> > > > + struct device_node *ep = NULL;
> > > > + struct device_node *next;
> > > > + unsigned int num_entities = 0;
> > > > + int ret = 0;
> > > > +
> > > > + /* Walk the device tree and build a list of nodes. */
> > > > + dev_dbg(notifier->dev, "parsing node %s\n", node->full_name);
> > > > +
> > > > + while (1) {
> > > > + next = display_of_get_next_endpoint(node, ep);
> > > > + if (next == NULL)
> > > > + break;
> > > > +
> > > > + of_node_put(ep);
> > > > + ep = next;
> > > > +
> > > > + dev_dbg(notifier->dev, "handling endpoint %s\n",
> > > > ep->full_name);
> > > > +
> > > > + remote = display_of_get_remote_port_parent(ep);
> > > > + if (remote == NULL)
> > > > + continue;
> > > > +
> > > > + /* Skip entities that we have already processed. */
> > > > + if (display_of_find_entity(entities, remote) || remote
> > > > == node) {
> > > > + dev_dbg(notifier->dev,
> > > > + "entity %s already in list, skipping\n",
> > > > + remote->full_name);
> > > > + continue;
> > > > + }
> > >
> > > device tree nodes with status = "disabled" should be skipped here:
> > > if (!of_device_is_available(remote)) {
> > > dev_dbg(notifier->dev,
> > > "entity %s is disabled, skipping\n",
> > > remote->full_name);
> > > continue;
> > > }
> > >
> > > Otherwise the completion notification will never be delivered if there
> > > are any disabled entities in the graph.
> >
> > That's a good point, but if a device is disabled, why would it be in the
> > DT graph in the first place ? Do you have a use case for this ?
>
> This is mostly about separate encoders inside the SoC, which are always
> present but not useful unless the board designer connected something to
> the external pads. Those might be contained in the SoC .dtsi but have
> status = "disabled" set for board device tree writers' convenience.
> My use case would be the LVDS encoder bridge or the Synopsys Designware
> HDMI TX on i.MX6.
My point was that, if a DT node is disabled, it should not be linked in a CDF
graph in DT. However, I agree that it's easier to express the in-SoC links in
the .dtsi files, so you've got a point. I'll integrate the change in v4.
--
Regards,
Laurent Pinchart
RE: [PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync support
Thanks for your comments, Inki Dae > -Original Message- > From: David Herrmann [mailto:dh.herrm...@gmail.com] > Sent: Wednesday, August 21, 2013 10:17 PM > To: Inki Dae > Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux- > arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org; linaro- > ker...@lists.linaro.org; Maarten Lankhorst; Sumit Semwal; > kyungmin.p...@samsung.com; myungjoo@samsung.com > Subject: Re: [PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync > support > > Hi > > On Wed, Aug 21, 2013 at 12:33 PM, Inki Dae wrote: > > This patch adds lock and poll callbacks to dma buf file operations, > > and these callbacks will be called by fcntl and select system calls. > > > > fcntl and select system calls can be used to wait for the completion > > of DMA or CPU access to a shared dmabuf. The difference of them is > > fcntl system call takes a lock after the completion but select system > > call doesn't. So in case of fcntl system call, it's useful when a task > > wants to access a shared dmabuf without any broken. On the other hand, > > it's useful when a task wants to just wait for the completion. > > 1) > So how is that supposed to work in user-space? I don't want to block > on a buffer, but get notified once I can lock it. So I do: > select(..dmabuf..) > Once it is finished, I want to use it: > flock(..dmabuf..) > However, how can I guarantee the flock will not block? Some other > process might have locked it in between. So I do a non-blocking > flock() and if it fails I wait again? s/flock/fcntl Yes, it does if you wanted to do a non-blocking fcntl. The fcntl() call will return -EAGAIN if some other process have locked first. So user process could retry to lock or do other work. This user process called fcntl() with non-blocking mode so in this case, I think the user should consider two things. One is that the fcntl() call couldn't be failed, and other is that the call could take a lock successfully. Isn't fcntl() with a other fd also, not dmabuf, take a same action? >Looks ugly and un-predictable. > So I think this is reasonable. However, for select system call, I'm not sure that this system call is needed yet. So I can remove it if unnecessary. > 2) > What do I do if some user-space program holds a lock and dead-locks? > I think fcntl call with a other fd also could lead same situation, and the lock will be unlocked once the user-space program is killed because when the process is killed, all file descriptors of the process are closed. > 3) > How do we do modesetting in atomic-context in the kernel? There is no > way to lock the object. But this is required for panic-handlers and > more importantly the kdb debugging hooks. > Ok, I can live with that being racy, but would still be nice to be > considered. Yes, The lock shouldn't be called in the atomic-context. For this, will add comments enough. > > 4) > Why do we need locks? Aren't fences enough? That is, in which > situation is a lock really needed? > If we assume we have two writers A and B (DMA, CPU, GPU, whatever) and > they have no synchronization on their own. What do we win by > synchronizing their writes? Ok, yeah, we end up with either A or B and > not a mixture of both. But if we cannot predict whether we get A or B, > I don't know why we care at all? It's random, so a mixture would be > fine, too, wouldn't it? I think not so. There are some cases that the mixture wouldn't be fine. For this, will describe it at below. > > So if user-space doesn't have any synchronization on its own, I don't > see why we need an implicit sync on a dma-buf. Could you describe a > more elaborate use-case? Ok, first, I think I described that enough though [PATCH 0/2]. For this, you can refer to the below link, http://lwn.net/Articles/564208/ Anyway, there are some cases that user-space process needs the synchronization on its own. In case of Tizen platform[1], one is between X Client and X Server; actually, Composite Manager. Other is between Web app based on HTML5 and Web Browser. Please, assume that X Client draws something in a window buffer using CPU, and then the X Client requests SWAP to X Server. And then X Server notifies a damage event to Composite Manager. And then Composite Manager composes the window buffer with its own back buffer using GPU. In this case, Composite Manager calls eglSwapBuffers; internally, flushing GL commands instead of finishing them for more performance. As you may know, the flushing doesn't wait for the complete event from GPU driver. And at the same time, the X Client could do other work, and also draw something in the same buffer again. At this time, The buffer could be broken. Because the X Client can't aware of when GPU access to the buffer is completed without out-of-band hand shaking; the out-of-band hand shaking is quite big overhead. That is why we need user-space locking interface, fcntl system call. And also there is same issue in case
Re: [PATCH 6/6] drm/exynos: Make Exynos DRM drivers depend on OF
Hi Sachin, On Thursday 22 of August 2013 11:15:23 Sachin Kamat wrote: > Exynos is a DT-only platform. Add this info to Kconfig. > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/exynos/Kconfig |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig > b/drivers/gpu/drm/exynos/Kconfig index 772c62a..80a251a 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -1,6 +1,6 @@ > config DRM_EXYNOS > tristate "DRM Support for Samsung SoC EXYNOS Series" > - depends on DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) > + depends on OF && DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) > select DRM_KMS_HELPER > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF > > config DRM_EXYNOS_FIMD > bool "Exynos DRM FIMD" > - depends on OF && DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM > + depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM > select FB_MODE_HELPERS > select VIDEOMODE_HELPERS > help Shouldn't this patch be first in the series? Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi Kärkkäinen
> > Tested-by: Pasi Kärkkäinen
> > Signed-off-by: Ilia Mirkin
> > Cc: # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> Not it really isn't appropriate..
>
> You'd have to call call nouveau_vm_map_sg_table instead, the only place that
> doesn't handle that correctly
> is where it's not expected to be called.
>
> Here, have a completely untested patch to fix things...
>
Thanks! I'll give it a try later today..
-- Pasi
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
> {
> struct nouveau_framebuffer *nouveau_fb;
> struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
> int ret = -ENOMEM;
>
> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> if (!gem)
> return ERR_PTR(-ENOENT);
>
> + nvbo = nouveau_gem_object(gem);
> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
> + " valid_domains=%08x\n", nvbo->valid_domains);
> + ret = -EINVAL;
> + goto err_unref;
> + }
> +
> nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> if (!nouveau_fb)
> goto err_unref;
>
> - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
> nouveau_gem_object(gem));
> + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
> if (ret)
> goto err;
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/exynos: Make Exynos DRM drivers depend on OF
Exynos is a DT-only platform. Add this info to Kconfig. Signed-off-by: Sachin Kamat --- drivers/gpu/drm/exynos/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 772c62a..80a251a 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -1,6 +1,6 @@ config DRM_EXYNOS tristate "DRM Support for Samsung SoC EXYNOS Series" - depends on DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) + depends on OF && DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM) select DRM_KMS_HELPER select FB_CFB_FILLRECT select FB_CFB_COPYAREA @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF config DRM_EXYNOS_FIMD bool "Exynos DRM FIMD" - depends on OF && DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM + depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM select FB_MODE_HELPERS select VIDEOMODE_HELPERS help -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/exynos: Remove non-DT support in exynos_hdmi
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 70 ++
1 file changed, 12 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8ea07a1..a0e10ae 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1858,7 +1858,6 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
}
-#ifdef CONFIG_OF
static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
{
@@ -1882,33 +1881,7 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
err_data:
return NULL;
}
-#else
-static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
- (struct device *dev)
-{
- return NULL;
-}
-#endif
-
-static struct platform_device_id hdmi_driver_types[] = {
- {
- .name = "s5pv210-hdmi",
- .driver_data= HDMI_TYPE13,
- }, {
- .name = "exynos4-hdmi",
- .driver_data= HDMI_TYPE13,
- }, {
- .name = "exynos4-hdmi14",
- .driver_data= HDMI_TYPE14,
- }, {
- .name = "exynos5-hdmi",
- .driver_data= HDMI_TYPE14,
- }, {
- /* end node */
- }
-};
-#ifdef CONFIG_OF
static struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos5-hdmi",
@@ -1920,7 +1893,6 @@ static struct of_device_id hdmi_match_types[] = {
/* end node */
}
};
-#endif
static int hdmi_probe(struct platform_device *pdev)
{
@@ -1929,30 +1901,21 @@ static int hdmi_probe(struct platform_device *pdev)
struct hdmi_context *hdata;
struct s5p_hdmi_platform_data *pdata;
struct resource *res;
+ const struct of_device_id *match;
int ret;
- if (dev->of_node) {
- pdata = drm_hdmi_dt_parse_pdata(dev);
- if (IS_ERR(pdata)) {
- DRM_ERROR("failed to parse dt\n");
- return PTR_ERR(pdata);
- }
- } else {
- pdata = dev->platform_data;
- }
+if (!dev->of_node)
+ return -ENODEV;
- if (!pdata) {
- DRM_ERROR("no platform data specified\n");
+ pdata = drm_hdmi_dt_parse_pdata(dev);
+ if (!pdata)
return -EINVAL;
- }
- drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx),
- GFP_KERNEL);
+ drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx), GFP_KERNEL);
if (!drm_hdmi_ctx)
return -ENOMEM;
- hdata = devm_kzalloc(dev, sizeof(struct hdmi_context),
- GFP_KERNEL);
+ hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -1963,23 +1926,15 @@ static int hdmi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, drm_hdmi_ctx);
- if (dev->of_node) {
- const struct of_device_id *match;
- match = of_match_node(of_match_ptr(hdmi_match_types),
- dev->of_node);
- if (match == NULL)
- return -ENODEV;
- hdata->type = (enum hdmi_type)match->data;
- } else {
- hdata->type = (enum hdmi_type)platform_get_device_id
- (pdev)->driver_data;
- }
+ match = of_match_node(hdmi_match_types, dev->of_node);
+ if (!match)
+ return -ENODEV;
+ hdata->type = (enum hdmi_type)match->data;
hdata->hpd_gpio = pdata->hpd_gpio;
hdata->dev = dev;
ret = hdmi_resources_init(hdata);
-
if (ret) {
DRM_ERROR("hdmi_resources_init failed\n");
return -EINVAL;
@@ -2134,11 +2089,10 @@ static const struct dev_pm_ops hdmi_pm_ops = {
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
.remove = hdmi_remove,
- .id_table = hdmi_driver_types,
.driver = {
.name = "exynos-hdmi",
.owner = THIS_MODULE,
.pm = &hdmi_pm_ops,
- .of_match_table = of_match_ptr(hdmi_match_types),
+ .of_match_table = hdmi_match_types,
},
};
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://l
[PATCH 4/6] drm/exynos: Remove non-DT support in exynos_drm_g2d
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 0b8b6e4..3271fd4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1534,12 +1534,10 @@ static const struct dev_pm_ops g2d_pm_ops = {
SET_RUNTIME_PM_OPS(g2d_runtime_suspend, g2d_runtime_resume, NULL)
};
-#ifdef CONFIG_OF
static const struct of_device_id exynos_g2d_match[] = {
{ .compatible = "samsung,exynos5250-g2d" },
{},
};
-#endif
struct platform_driver g2d_driver = {
.probe = g2d_probe,
@@ -1548,6 +1546,6 @@ struct platform_driver g2d_driver = {
.name = "s5p-g2d",
.owner = THIS_MODULE,
.pm = &g2d_pm_ops,
- .of_match_table = of_match_ptr(exynos_g2d_match),
+ .of_match_table = exynos_g2d_match,
},
};
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/exynos: Remove non-DT support in exynos_hdmiphy
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index 6021996..59abb14 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -40,13 +40,6 @@ static int hdmiphy_remove(struct i2c_client *client)
return 0;
}
-static const struct i2c_device_id hdmiphy_id[] = {
- { "s5p_hdmiphy", 0 },
- { "exynos5-hdmiphy", 0 },
- { },
-};
-
-#ifdef CONFIG_OF
static struct of_device_id hdmiphy_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiphy",
@@ -58,15 +51,13 @@ static struct of_device_id hdmiphy_match_types[] = {
/* end node */
}
};
-#endif
struct i2c_driver hdmiphy_driver = {
.driver = {
.name = "exynos-hdmiphy",
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(hdmiphy_match_types),
+ .of_match_table = hdmiphy_match_types,
},
- .id_table = hdmiphy_id,
.probe = hdmiphy_probe,
.remove = hdmiphy_remove,
.command= NULL,
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/exynos: Remove non-DT support in exynos_ddc
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_ddc.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
index d1e539b..6a8c84e 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -41,13 +41,6 @@ static int s5p_ddc_remove(struct i2c_client *client)
return 0;
}
-static struct i2c_device_id ddc_idtable[] = {
- {"s5p_ddc", 0},
- {"exynos5-hdmiddc", 0},
- { },
-};
-
-#ifdef CONFIG_OF
static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiddc",
@@ -57,15 +50,13 @@ static struct of_device_id hdmiddc_match_types[] = {
/* end node */
}
};
-#endif
struct i2c_driver ddc_driver = {
.driver = {
.name = "exynos-hdmiddc",
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(hdmiddc_match_types),
+ .of_match_table = hdmiddc_match_types,
},
- .id_table = ddc_idtable,
.probe = s5p_ddc_probe,
.remove = s5p_ddc_remove,
.command= NULL,
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 +++---
1 file changed, 13 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f8889d2..90da9ef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -123,7 +123,6 @@ struct fimd_context {
struct fimd_driver_data *driver_data;
};
-#ifdef CONFIG_OF
static const struct of_device_id fimd_driver_dt_match[] = {
{ .compatible = "samsung,s3c6400-fimd",
.data = &s3c64xx_fimd_driver_data },
@@ -133,21 +132,14 @@ static const struct of_device_id fimd_driver_dt_match[] =
{
.data = &exynos5_fimd_driver_data },
{},
};
-#endif
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
{
-#ifdef CONFIG_OF
const struct of_device_id *of_id =
of_match_device(fimd_driver_dt_match, &pdev->dev);
- if (of_id)
- return (struct fimd_driver_data *)of_id->data;
-#endif
-
- return (struct fimd_driver_data *)
- platform_get_device_id(pdev)->driver_data;
+ return (struct fimd_driver_data *)of_id->data;
}
static bool fimd_display_is_connected(struct device *dev)
@@ -891,23 +883,18 @@ static int fimd_probe(struct platform_device *pdev)
int win;
int ret = -EINVAL;
- if (dev->of_node) {
- pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata)
- return -ENOMEM;
+ if (!dev->of_node)
+ return -ENODEV;
- ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
- OF_USE_NATIVE_MODE);
- if (ret) {
- DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
- return ret;
- }
- } else {
- pdata = dev->platform_data;
- if (!pdata) {
- DRM_ERROR("no platform data specified\n");
- return -EINVAL;
- }
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
+ return ret;
}
panel = &pdata->panel;
@@ -1069,20 +1056,6 @@ static int fimd_runtime_resume(struct device *dev)
}
#endif
-static struct platform_device_id fimd_driver_ids[] = {
- {
- .name = "s3c64xx-fb",
- .driver_data= (unsigned long)&s3c64xx_fimd_driver_data,
- }, {
- .name = "exynos4-fb",
- .driver_data= (unsigned long)&exynos4_fimd_driver_data,
- }, {
- .name = "exynos5-fb",
- .driver_data= (unsigned long)&exynos5_fimd_driver_data,
- },
- {},
-};
-
static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -1091,11 +1064,10 @@ static const struct dev_pm_ops fimd_pm_ops = {
struct platform_driver fimd_driver = {
.probe = fimd_probe,
.remove = fimd_remove,
- .id_table = fimd_driver_ids,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
.pm = &fimd_pm_ops,
- .of_match_table = of_match_ptr(fimd_driver_dt_match),
+ .of_match_table = fimd_driver_dt_match,
},
};
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 22-08-13 02:10, Ilia Mirkin schreef:
> The code expects non-VRAM mem nodes to have a pages list. If that's not
> set, it will do a null deref down the line. Warn on that condition and
> return an error.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>
> Reported-by: Pasi Kärkkäinen
> Tested-by: Pasi Kärkkäinen
> Signed-off-by: Ilia Mirkin
> Cc: # 3.8+
> ---
>
> I don't exactly understand what's going on, but this is just a
> straightforward way to avoid a null deref that you see happens in the
> bug. I haven't figured out the root cause of this, but it's getting
> well into the "I have no idea how TTM works" space. However this seems
> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> node->pages as a list down, which will be dereferenced by
> nvc0_vm_map_sg. Perhaps the other arguments should make that
> dereferencing not happen, but it definitely was happening here, as you
> can see in the bug.
>
> Ben/Maarten, I'll let you judge whether this check is appropriate,
> since like I hope I was able to convey above, I'm just not really sure :)
Not it really isn't appropriate..
You'd have to call call nouveau_vm_map_sg_table instead, the only place that
doesn't handle that correctly
is where it's not expected to be called.
Here, have a completely untested patch to fix things...
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
int ret = -ENOMEM;
gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
if (!gem)
return ERR_PTR(-ENOENT);
+ nvbo = nouveau_gem_object(gem);
+ if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
+ nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
+ " valid_domains=%08x\n", nvbo->valid_domains);
+ ret = -EINVAL;
+ goto err_unref;
+ }
+
nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
if (!nouveau_fb)
goto err_unref;
- ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
nouveau_gem_object(gem));
+ ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
if (ret)
goto err;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
