Calling drm_atomic_helper_check_modeset() after drm_atomic_helper_check_planes()
Hi, The documentation of drm_atomic_helper_check_modeset() says: "Drivers which update ->mode_changed (e.g. in their ->atomic_check hooks if a plane update can't be done without a full modeset) _must_ call this function afterwards after that change. It is permitted to call this function multiple times for the same update, e.g. when the ->atomic_check functions depend upon the adjusted dotclock for fifo space allocation and watermark computation." Then drm_crtc_helper_funcs mode_fixup() callback documentations says: "Atomic drivers which need to inspect and adjust more state should instead use the @atomic_check callback." Now an atomic driver that needs to do the both in the check phase: update ->mode_changed and inspect and adjust the mode, is in trouble. This is because any adjusted_mode modifications are reset by the afterwards call of drm_atomic_helper_check_modeset(). I can get the atomic tilcdc driver working either: by using the crtc_helper mode_fixup() calback, tuning the mode once more in mode_set_nofb(), or calling drm_atomic_helper_check_modeset() last in drm_mode_config_funcs atomic_check() callback. What is the right thing to do? Any of these three approaches (and possibly updating the documentation), or some other option that I did not think of? Best regards, Jyri
[PATCH 10/16] drm: Don't call drm_dev_set_unique from platform drivers
On Fri, Jun 17, 2016 at 02:12:09PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Friday 17 Jun 2016 09:33:28 Daniel Vetter wrote: > > Since > > > > commit e112e593b215c394c0303dbf0534db0928e87967 > > Author: Nicolas Iooss > > Date: Fri Dec 11 11:20:28 2015 +0100 > > > > drm: use dev_name as default unique name in drm_dev_alloc() > > > > we're using a reasonable default which should work for everyone. Only > > mtk, rcar-du and sun4i are affected, and as kms-only drivers without > > any rendering support no one should ever care about the unique name > > > > v2: Rebase on top of mediatek. > > > > Cc: Philipp Zabel > > Cc: Maxime Ripard > > Cc: Laurent Pinchart > > Cc: Emil Velikov > > Signed-off-by: Daniel Vetter > > Reviewed-by: Laurent Pinchart Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/eb36b098/attachment.sig>
[Bug 96588] [regression] [amdgpu] Errors scheduling IBs
https://bugs.freedesktop.org/show_bug.cgi?id=96588 Mike Lothian changed: What|Removed |Added Attachment #124602|0 |1 is obsolete|| --- Comment #4 from Mike Lothian --- Created attachment 124607 --> https://bugs.freedesktop.org/attachment.cgi?id=124607=edit demsg output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/b3866c14/attachment.html>
[Bug 96588] [regression] [amdgpu] Errors scheduling IBs
https://bugs.freedesktop.org/show_bug.cgi?id=96588 --- Comment #3 from Christian König --- Could be some kind of race condition, please provide the output of "journalctl --dmesg -o short-monotonic". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/89e2326b/attachment.html>
[Bug 95427] gem_userptr_blits@mlocked-* should skip due to memory pre-condition not met
https://bugs.freedesktop.org/show_bug.cgi?id=95427 --- Comment #3 from Emil Velikov --- Guys have you actually looked at the following line ? Aperture size is 268435456 MiB -- That is 256 TiB !!! That's rather impossible amount if you ask me. So there's either a bug in IGT's gem_aperture_size() or one of the two ioctls (I915_GEM_CONTEXT_GETPARAM I915_GEM_GET_APERTURE) that it uses. With a couple of print statements you should be able to quickly track the exact offender. Good luck ! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/e99385bd/attachment.html>
[Bug 96580] GPU lockup on AMD 7970M when playing games
https://bugs.freedesktop.org/show_bug.cgi?id=96580 --- Comment #5 from Saad Naji --- Created attachment 124604 --> https://bugs.freedesktop.org/attachment.cgi?id=124604=edit dmesg-ouput-DRI2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/bee582f3/attachment.html>
[Bug 96580] GPU lockup on AMD 7970M when playing games
https://bugs.freedesktop.org/show_bug.cgi?id=96580 --- Comment #4 from Saad Naji --- (In reply to Hleb Valoshka from comment #3) > Looks like DRI3 is the issue, I have lockups in L4D2 & Portal2 (but not in > old HL2) with DRI3, but haven't them with DRI2. My card is radeon 7750. I followed his comments and I switched both modessting(Intel) and Radeon to DRI 2 instead of DRI 3. The result was the same for CS:GO. In fact I could not get past the main menu screen this time. I am attaching dmesg output with DRI 2 option -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/d3075b4e/attachment-0001.html>
[Bug 119861] Kernel BUG() when Xorg server is started using nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=119861 Dmitrii Tcvetkov changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Dmitrii Tcvetkov --- commit fffc5f59f2c68ca859c3f92b224393ed3adbe1ca Author: Philipp Zabel Date: Thu Jun 2 19:27:51 2016 +0200 drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 120591] BUG() in dmesg after loading nouveau module
https://bugzilla.kernel.org/show_bug.cgi?id=120591 Dmitrii Tcvetkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 95427] gem_userptr_blits@mlocked-* should skip due to memory pre-condition not met
https://bugs.freedesktop.org/show_bug.cgi?id=95427 --- Comment #2 from Humberto Israel Perez Rodriguez --- even with 16GB of ram in APL the following tests keeps failing : Tests cases = igt at gem_userptr_blits@mlocked-unsync-normal igt at gem_userptr_blits@mlocked-normal-sync output : IGT-Version: 1.15-g3ce58b6 (x86_64) (Linux: 4.7.0-rc2-drm-intel-nightly-ww24-commit-55d1291+ x86_64) (gem_userptr_blits:1332) drmtest-DEBUG: Test requirement passed: fd >= 0 (gem_userptr_blits:1332) ioctl-wrappers-DEBUG: Test requirement passed: !(ret == ENODEV && (flags & LOCAL_I915_USERPTR_UNSYNCHRONIZED) == 0 && !read_only) (gem_userptr_blits:1332) DEBUG: Test requirement passed: !(ret == 0) Aperture size is 268435456 MiB Total RAM is 15,884 MiB Not enough RAM to run test, reducing buffer count. Testing unsynchronized mappings... (gem_userptr_blits:1332) igt-core-DEBUG: Starting subtest: mlocked-unsync-normal (gem_userptr_blits:1332) intel-os-DEBUG: Checking 256 surfaces of size 1,048,576 bytes (total 268,566,528) against RAM (gem_userptr_blits:1332) intel-os-DEBUG: Test requirement passed: __intel_check_memory(count, size, mode, , ) (gem_userptr_blits:1332) igt-core-DEBUG: Test requirement passed: !igt_run_in_simulation() (gem_userptr_blits:1332) DEBUG: Test requirement passed: pin > sz (gem_userptr_blits:1332) DEBUG: Pinning [15,428, 15,684] MiB Killed relevant kernel messages: = kern :err : [Sat Jun 18 16:18:55 2016] 32 and 0 pages still available in the bound and unbound GPU page lists. kern :err : [Sat Jun 18 16:18:55 2016] Out of memory: Kill process 1348 (gem_userptr_bli) score 1762 or sacrifice child kern :err : [Sat Jun 18 16:18:55 2016] Killed process 1348 (gem_userptr_bli) total-vm:16169932kB, anon-rss:15988692kB, file-rss:4kB, shmem-rss:0kB looks like that is something wrong in the test itself of the test needs much more memory ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/cbab276f/attachment.html>
[Bug 93826] 144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #25 from Dennis Martin Herbers --- I've got the same problem with a Sapphire R9 390 Nitro ASUS MG279Q With Windows/Linux+fglrx, 2560x1440 at 144Hz work fine With Linux+open source stack, it defaults to 2568x1440 at 139Hz with graphical artifacts due to the 2568 width With AMDGPU PRO 16.10 only 60Hz was possible, haven't tried AMDGPU PRO 16.20 yet Using the open source stack and switching to 120Hz with xrandr -r 120 does the trick and it runs at 2560x1440 at 119Hz without glitches, but it isn't optimal. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/e49b7ab4/attachment.html>
[GIT PULL] exynos-drm-fixes
Hi Dave, Just regression fixups and cleanups. Since HW trigger mode was suppoted we have faced with a issue that Display panel didn't work correctly when trigger mode was changed in booting time. For this, we keep trigger mode with SW trigger mode in default mode like we did before. However, we will need to consider PSR(Panel Self Reflash) mode to resolve this issue fundamentally later. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 0ab15bdeb2943bd6491a35ec4eeb53a9a4436525: Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2016-06-16 10:24:13 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-fixes for you to fetch changes up to 41abbf5afa51136bcb2aeefc80bf5c3a005d0aa3: drm/exynos: use logical AND in exynos_drm_plane_check_size() (2016-06-19 14:37:28 +0900) Javier Martinez Canillas (2): drm/exynos: fimd: don't set .has_hw_trigger in s3c6400 driver data drm/exynos: don't use HW trigger for Exynos5420/5422/5800 Tobias Jakobi (3): drm/exynos: g2d: drop the _REG postfix from the stride defines drm/exynos: remove superfluous inclusions of fbdev header drm/exynos: use logical AND in exynos_drm_plane_check_size() Yakir Yang (1): drm/exynos: dp: Fix NULL pointer dereference due uninitialized connector drivers/gpu/drm/exynos/exynos7_drm_decon.c |1 - drivers/gpu/drm/exynos/exynos_dp.c |5 +++-- drivers/gpu/drm/exynos/exynos_drm_core.c |1 - drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 - drivers/gpu/drm/exynos/exynos_drm_g2d.c| 12 ++-- drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- 6 files changed, 10 insertions(+), 16 deletions(-)
[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window
On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > > On Fri, 17 Jun 2016, Daniel Vetter wrote: > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: > > > > > > I guess we'll need the bisect on this one to make progress. > > > > > > > > > > Sigh, I was afraid that might be the next step. > > > > > > > > OK, I have a curious data point. I assumed the problem would > > > > be > > > > somewhere in the drm update, so I started bisecting that at the > > > > top. > > > > However, the top most commit: > > > > > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c > > > > Merge: 1f40c49 a39ed68 > > > > Author: Linus Torvalds > > > > Date: Mon May 23 11:48:48 2016 -0700 > > > > > > > > Merge branch 'drm-next' of > > > > git://people.freedesktop.org/~airlied/linux > > > > > > > > Isn't actually bad. There's no flicker here, so whatever > > > > caused > > > > the > > > > problem came from some update after this. > > > > > > There was a fixes pull after this. Might be worth it to restrict > > > to > > > just > > > the i915 changes, which are just > > > 5b4fd5bb1230cd037..157d2c7fad0863222 > > > > > > Looking at those nothing seems to stick out which might explain > > > what's > > > happening for you. > > OK, so just on the firmware, the system seems less flickery with the > new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata > issue. The flicker isn't gone for good, but seems to be reboot > dependent (it's there in some boots, but gone on a reboot). > > > This should be easy enough to try before bisecting: > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git > > -s > > end-email-mika.kahola at intel.com > > Applying this didn't seem to make a difference: still there on some > and gone on other reboots. OK, my candidate bad commit is this one: commit a05628195a0d9f3173dd9aa76f482aef692e46ee Author: Ville Syrjälä Date: Mon Apr 11 10:23:51 2016 +0300 drm/i915: Get panel_type from OpRegion panel details After being more careful about waiting to identify flicker, this one seems to be the one the bisect finds. I'm now running v4.7-rc3 with this one reverted and am currently seeing no flicker problems. It is, however, early days because the flicker can hide for long periods, so I 'll wait until Monday evening and a few reboots before declaring victory. James
[PATCH 3/3] dma-buf: remove dma_buf_debugfs_create_file()
There is only a single user of dma_buf_debugfs_create_file() and that
one got the function pointer cast wrong. With that one fixed, there is
no need to have a wrapper for debugfs_create_file(), just call it
directly.
With no users left, we can remove dma_buf_debugfs_create_file().
While at it, simplify the error handling in dma_buf_init_debugfs()
slightly.
Signed-off-by: Mathias Krause
Cc: Sumit Semwal
Cc: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 29 +
include/linux/dma-buf.h |2 --
2 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f03e51561199..20ce0687b111 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -895,22 +895,22 @@ static struct dentry *dma_buf_debugfs_dir;
static int dma_buf_init_debugfs(void)
{
+ struct dentry *d;
int err = 0;
- dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL);
+ d = debugfs_create_dir("dma_buf", NULL);
+ if (IS_ERR(d))
+ return PTR_ERR(d);
- if (IS_ERR(dma_buf_debugfs_dir)) {
- err = PTR_ERR(dma_buf_debugfs_dir);
- dma_buf_debugfs_dir = NULL;
- return err;
- }
+ dma_buf_debugfs_dir = d;
- err = dma_buf_debugfs_create_file("bufinfo", NULL);
-
- if (err) {
+ d = debugfs_create_file("bufinfo", S_IRUGO, dma_buf_debugfs_dir,
+ NULL, _buf_debug_fops);
+ if (IS_ERR(d)) {
pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
debugfs_remove_recursive(dma_buf_debugfs_dir);
dma_buf_debugfs_dir = NULL;
+ err = PTR_ERR(d);
}
return err;
@@ -921,17 +921,6 @@ static void dma_buf_uninit_debugfs(void)
if (dma_buf_debugfs_dir)
debugfs_remove_recursive(dma_buf_debugfs_dir);
}
-
-int dma_buf_debugfs_create_file(const char *name,
- int (*write)(struct seq_file *))
-{
- struct dentry *d;
-
- d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir,
- write, _buf_debug_fops);
-
- return PTR_ERR_OR_ZERO(d);
-}
#else
static inline int dma_buf_init_debugfs(void)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 4551c6f2a6c4..e0b0741ae671 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -242,6 +242,4 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-int dma_buf_debugfs_create_file(const char *name,
- int (*write)(struct seq_file *));
#endif /* __DMA_BUF_H__ */
--
1.7.10.4
[PATCH 2/3] dma-buf: remove dma_buf directory on bufinfo file creation errors
Change the error handling in dma_buf_init_debugfs() to remove the
"dma_buf" directory if creating the "bufinfo" file fails. No need to
have an empty debugfs directory around.
Signed-off-by: Mathias Krause
Cc: Sumit Semwal
Cc: Daniel Vetter
---
drivers/dma-buf/dma-buf.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7094b19bb495..f03e51561199 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -907,8 +907,11 @@ static int dma_buf_init_debugfs(void)
err = dma_buf_debugfs_create_file("bufinfo", NULL);
- if (err)
+ if (err) {
pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
+ debugfs_remove_recursive(dma_buf_debugfs_dir);
+ dma_buf_debugfs_dir = NULL;
+ }
return err;
}
--
1.7.10.4
[PATCH 1/3] dma-buf: propagate errors from dma_buf_describe() on debugfs read
The callback function dma_buf_describe() returns an int not void so the
function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can
also fail when acquiring the mutex gets interrupted so always returning
0 in dma_buf_show() is wrong, too.
Fix both issues by avoiding the indirection via dma_buf_show() and call
dma_buf_describe() directly. Rename it to dma_buf_debug_show() to get it
in line with the other functions.
This type mismatch was caught by the PaX RAP plugin.
Signed-off-by: Mathias Krause
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Brad Spengler
Cc: PaX Team
---
drivers/dma-buf/dma-buf.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6355ab38d630..7094b19bb495 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -824,7 +824,7 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
#ifdef CONFIG_DEBUG_FS
-static int dma_buf_describe(struct seq_file *s)
+static int dma_buf_debug_show(struct seq_file *s, void *unused)
{
int ret;
struct dma_buf *buf_obj;
@@ -879,17 +879,9 @@ static int dma_buf_describe(struct seq_file *s)
return 0;
}
-static int dma_buf_show(struct seq_file *s, void *unused)
-{
- void (*func)(struct seq_file *) = s->private;
-
- func(s);
- return 0;
-}
-
static int dma_buf_debug_open(struct inode *inode, struct file *file)
{
- return single_open(file, dma_buf_show, inode->i_private);
+ return single_open(file, dma_buf_debug_show, NULL);
}
static const struct file_operations dma_buf_debug_fops = {
@@ -913,7 +905,7 @@ static int dma_buf_init_debugfs(void)
return err;
}
- err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe);
+ err = dma_buf_debugfs_create_file("bufinfo", NULL);
if (err)
pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
--
1.7.10.4
[PATCH 0/3] dma-buf: debugfs fixes
This small series is the v2 of the patch posted initially here: http://www.spinics.net/lists/linux-media/msg101347.html It not only fixes the type mix-up and addresses Daniel's remark (patch 1), it also smoothes out the error handling in dma_buf_init_debugfs() (patch 2) and removes the then unneeded function dma_buf_debugfs_create_file() (patch 3). Please apply! Mathias Krause (3): dma-buf: propagate errors from dma_buf_describe() on debugfs read dma-buf: remove dma_buf directory on bufinfo file creation errors dma-buf: remove dma_buf_debugfs_create_file() drivers/dma-buf/dma-buf.c | 44 ++-- include/linux/dma-buf.h |2 -- 2 files changed, 14 insertions(+), 32 deletions(-) -- 1.7.10.4
[Bug 96588] [regression] [amdgpu] Errors scheduling IBs
https://bugs.freedesktop.org/show_bug.cgi?id=96588 --- Comment #2 from Mike Lothian --- Reverting that commit makes the errors go away -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/56df04df/attachment.html>
[PATCH] dma-buf: propagate errors from dma_buf_describe() on debugfs read
On 19 June 2016 at 10:45, Daniel Vetter wrote:
> On Fri, Jun 17, 2016 at 08:57:03PM +0200, Mathias Krause wrote:
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 6355ab38d630..0f2a4592fdd2 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -881,10 +881,9 @@ static int dma_buf_describe(struct seq_file *s)
>>
>> static int dma_buf_show(struct seq_file *s, void *unused)
>> {
>> - void (*func)(struct seq_file *) = s->private;
>> + int (*func)(struct seq_file *) = s->private;
>>
>> - func(s);
>> - return 0;
>> + return func(s);
>
> Probably even better to just nuke that indirection. Set this pointer to
> NULL and inline dma_buf_describe into dma_buf_show.
Even further, we can get rid of dma_buf_debugfs_create_file() too as
it's only used to create this indirection.
I'll send a v2 just doing that.
Thanks,
Mathias
[Bug 78987] black screen when trying to enable external VGA screen on Trinity APU laptop
https://bugs.freedesktop.org/show_bug.cgi?id=78987 Lucas Stach changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/c0dced61/attachment.html>
[PATCH] dma-buf: propagate errors from dma_buf_describe() on debugfs read
On Fri, Jun 17, 2016 at 08:57:03PM +0200, Mathias Krause wrote:
> The callback function dma_buf_describe() returns an int not void so the
> function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can
> also fail when acquiring the mutex gets interrupted so always returning
> 0 in dma_buf_show() is wrong, too.
>
> Fix both issues by casting the function pointer to the correct type and
> propagate its return value.
>
> This type mismatch was caught by the PaX RAP plugin.
>
> Signed-off-by: Mathias Krause
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> Cc: PaX Team
> ---
> drivers/dma-buf/dma-buf.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6355ab38d630..0f2a4592fdd2 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -881,10 +881,9 @@ static int dma_buf_describe(struct seq_file *s)
>
> static int dma_buf_show(struct seq_file *s, void *unused)
> {
> - void (*func)(struct seq_file *) = s->private;
> + int (*func)(struct seq_file *) = s->private;
>
> - func(s);
> - return 0;
> + return func(s);
Probably even better to just nuke that indirection. Set this pointer to
NULL and inline dma_buf_describe into dma_buf_show.
-Daniel
> }
>
> static int dma_buf_debug_open(struct inode *inode, struct file *file)
> --
> 1.7.10.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 96588] [regression] [amdgpu] Errors scheduling IBs
https://bugs.freedesktop.org/show_bug.cgi?id=96588 Mike Lothian changed: What|Removed |Added CC||mike at fireburn.co.uk --- Comment #1 from Mike Lothian --- Created attachment 124602 --> https://bugs.freedesktop.org/attachment.cgi?id=124602=edit journalctl output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/3756abe3/attachment.html>
[Bug 120591] BUG() in dmesg after loading nouveau module
https://bugzilla.kernel.org/show_bug.cgi?id=120591 --- Comment #5 from Dmitrii Tcvetkov --- Created attachment 220621 --> https://bugzilla.kernel.org/attachment.cgi?id=220621=edit dmesg with patched kernel -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 96588] [regression] [amdgpu] Errors scheduling IBs
https://bugs.freedesktop.org/show_bug.cgi?id=96588 Bug ID: 96588 Summary: [regression] [amdgpu] Errors scheduling IBs Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: mike at fireburn.co.uk Hi I've been seeing these errors in my kernel logs: amdgpu :01:00.0: couldn't schedule ib [drm:amdgpu_job_run] *ERROR* Error scheduling IBs (-22) [drm:amd_sched_main] *ERROR* Failed to run job! I've bisected it down to: a7c77c7fe5f659428e73d77aa4a8ac80b638daf3 is the first bad commit commit a7c77c7fe5f659428e73d77aa4a8ac80b638daf3 Author: Christian König Date: Wed Jun 15 13:44:05 2016 +0200 drm/amdgpu: pipeline evictions as well This boosts Xonotic from 38fps to 47fps when artificially limiting VRAM to 256MB for testing. It should improve all CPU bound rendering situations where we have a lot of swapping to/from VRAM. Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher :04 04 2fdfd546d7175759ed5f09bdec209f71d084ab1e 6b0cdbc8f42f4e3873e3bbdcc440336856073883 M drivers -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/5efee250/attachment.html>
[Bug 120591] BUG() in dmesg after loading nouveau module
https://bugzilla.kernel.org/show_bug.cgi?id=120591 --- Comment #4 from Dmitrii Tcvetkov --- Thanks, that change helped, nouveau loaded successfully, Xorg started normally. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 120591] BUG() in dmesg after loading nouveau module
https://bugzilla.kernel.org/show_bug.cgi?id=120591 --- Comment #3 from Dmitrii Tcvetkov --- Created attachment 220611 --> https://bugzilla.kernel.org/attachment.cgi?id=220611=edit fix Suggested by Ilia Mirkin -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/nouveau/gr/gk20a: delete unneeded second newline
Signed-off-by: Julia Lawall --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c index 4ca8ed1..de8b806 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c @@ -361,6 +361,5 @@ gk20a_gr_new(struct nvkm_device *device, int index, struct nvkm_gr **pgr) if (ret) return ret; - return 0; }
[PATCH v2] drm/vgem: Enable dmabuf interface for export
Enable the standard GEM dma-buf interface provided by the DRM core, but
only for exporting the VGEM object. This allows passing around the VGEM
objects created from the dumb interface and using them as sources
elsewhere. Creating a VGEM object for a foriegn handle is not supported.
Testcase: igt/vgem_basic/dmabuf-mmap
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 101 +++-
1 file changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 4747b7f98e7a..32e2f51ed55f 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -193,14 +193,113 @@ static const struct file_operations vgem_driver_fops = {
.release= drm_release,
};
+static struct sg_table *vgem_prime_get_sg_table(struct drm_gem_object *obj)
+{
+ struct address_space *mapping = file_inode(obj->filp)->i_mapping;
+ long n_pages = obj->size >> PAGE_SHIFT, i;
+ struct sg_table *st;
+ struct scatterlist *sg;
+
+ st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+ if (st == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ if (sg_alloc_table(st, n_pages, GFP_KERNEL)) {
+ kfree(st);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ sg = st->sgl;
+ for (i = 0; i < n_pages; i++) {
+ struct page *page = shmem_read_mapping_page(mapping, i);
+ if (IS_ERR(page)) {
+ sg_mark_end(sg);
+ goto err_unwind;
+ }
+
+ sg_set_page(sg, page, PAGE_SIZE, 0);
+ sg = sg_next(sg);
+ }
+
+ return st;
+
+err_unwind:
+ for (sg = st->sgl; sg; sg = sg_next(sg))
+ put_page(sg_page(sg));
+ sg_free_table(st);
+ kfree(st);
+ return ERR_PTR(-ENOMEM);
+}
+
+static void *vgem_prime_vmap(struct drm_gem_object *obj)
+{
+ struct address_space *mapping = file_inode(obj->filp)->i_mapping;
+ long n_pages = obj->size >> PAGE_SHIFT, i;
+ struct page **pages;
+ void *addr = NULL;
+
+ pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
+ if (!pages)
+ return NULL;
+
+ for (i = 0; i < n_pages; i++) {
+ struct page *page = shmem_read_mapping_page(mapping, i);
+ if (IS_ERR(page))
+ goto out;
+ }
+
+ addr = vmap(pages, n_pages, 0, pgprot_writecombine(PAGE_KERNEL_IO));
+out:
+ while (i--)
+ put_page(pages[i]);
+ drm_free_large(pages);
+
+ return addr;
+}
+
+static void vgem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+{
+ vunmap(vaddr);
+}
+
+static int vgem_prime_mmap(struct drm_gem_object *obj,
+ struct vm_area_struct *vma)
+{
+ int ret;
+
+ if (obj->size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ if (!obj->filp)
+ return -ENODEV;
+
+ ret = obj->filp->f_op->mmap(obj->filp, vma);
+ if (ret)
+ return ret;
+
+ fput(vma->vm_file);
+ vma->vm_file = get_file(obj->filp);
+
+ return 0;
+}
+
static struct drm_driver vgem_driver = {
- .driver_features= DRIVER_GEM,
+ .driver_features= DRIVER_GEM | DRIVER_PRIME,
.gem_free_object_unlocked = vgem_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
.fops = _driver_fops,
+
.dumb_create= vgem_gem_dumb_create,
.dumb_map_offset= vgem_gem_dumb_map,
+
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .gem_prime_export = drm_gem_prime_export,
+ .gem_prime_get_sg_table = vgem_prime_get_sg_table,
+ .gem_prime_vmap = vgem_prime_vmap,
+ .gem_prime_vunmap = vgem_prime_vunmap,
+ .gem_prime_mmap = vgem_prime_mmap,
+
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
--
2.8.1
[Bug 96580] GPU lockup on AMD 7970M when playing games
https://bugs.freedesktop.org/show_bug.cgi?id=96580 --- Comment #3 from Hleb Valoshka <375gnu at gmail.com> --- Looks like DRI3 is the issue, I have lockups in L4D2 & Portal2 (but not in old HL2) with DRI3, but haven't them with DRI2. My card is radeon 7750. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/1192c9a5/attachment-0001.html>
[Bug 96585] R7 260X multiple soft lockups while playing TF2
https://bugs.freedesktop.org/show_bug.cgi?id=96585 Bug ID: 96585 Summary: R7 260X multiple soft lockups while playing TF2 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: toni.spets at iki.fi Created attachment 124600 --> https://bugs.freedesktop.org/attachment.cgi?id=124600=edit Full dmesg On my Radeon R260X, I get random soft locks that last for around 10 seconds each while playing Team Fortress 2. This happens around once or twice per hour and usually they are close to each other. The system becomes completely unresponsive until the outputs reset and everything continues normally. This system has suspended and resumed multiple times so it's not a "clean boot" and all the cycles are in the attached dmesg, including the lockups. It's a Fedora 24 system with their 4.5.5 kernel, Mesa version 11.2.1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/c08a8fb2/attachment.html>
[Bug 96532] [BISECTED: 0955c1250e] 4.7-rc1 oops at drm_connector_cleanup+0x5c/0x1d0
https://bugs.freedesktop.org/show_bug.cgi?id=96532 George Spelvin changed: What|Removed |Added Keywords||bisected, have-backtrace, ||regression -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160619/d381654e/attachment-0001.html>
[PATCH v6 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel
On 18 June 2016 at 07:59, Vinay Simha wrote:
> On Sat, Jun 18, 2016 at 5:58 AM, Emil Velikov
> wrote:
>> Hi Vinay,
>>
>> On 17 June 2016 at 19:23, Vinay Simha BN wrote:
>>
>>> v6:
>>> * emil review comments incorporated
>>>PANEL_NUM_REGULATORS dropped, return ret added at necessary
>>>places, if checks dropped for backlight and gpios
>>
>> Looks like some of my suggestions went below the radar. Did you miss
>> them or I've I lost the plot somewhere ? In case of the latter don't
>> be shy to point out :-)
>>
>>
>>> +struct jdi_panel {
>>> + struct drm_panel base;
>>> + struct mipi_dsi_device *dsi;
>>> +
>>> + struct regulator_bulk_data supplies[3];
>>> +
>> struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
>>
>>
>>> +static int jdi_panel_off(struct jdi_panel *jdi)
>>> +{
>>> + struct mipi_dsi_device *dsi = jdi->dsi;
>>> + int ret;
>>> +
>>> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
>>> +
>>> + ret = mipi_dsi_dcs_set_display_off(dsi);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>> IMHO neither this function nor its caller jdi_panel_unprepare() should
>> stop in the middle/return prematurely.
>>
>> Or in other words - one should change the function return type to void
>> and drop the returns.
>>
>>
>>> +static int jdi_panel_unprepare(struct drm_panel *panel)
>>> +{
>>> + struct jdi_panel *jdi = to_jdi_panel(panel);
>>> + struct device *dev = >dsi->dev;
>>> + int ret;
>>> +
>>> + if (!jdi->prepared)
>>> + return 0;
>>> +
>>> + ret = jdi_panel_off(jdi);
>>> + if (ret) {
>>> + dev_err(panel->dev, "failed to set panel off: %d\n", ret);
>>> + return ret;
>> As suggested above, drop this return.
>>
> i can make the function void for jdi_panel_off and drop the return,
> but i cannot make void for jdi_panel_unprepare,
> since drm_panel_prepare requires 0 or negative value.
>
Seems like I wasn't clear enough - all you want here is to drop the
spurious return.
Regards,
Emil
[PATCH 1/3] drm: Wait on the reservation object when sync'ing dmabufs
On Sat, Jun 18, 2016 at 04:20:47PM +0100, Chris Wilson wrote:
> Rendering operations to the dma-buf are tracked implicitly via the
> reservation_object (dmabuf->resv). The dmabuf sync ioctl allows
> userspace to wait upon outstanding rendering and prepare the object for
> CPU access (provided by the prime dma_buf_ops.begin_cpu_access). Fill
> this out for the generic drm_gem_prime by waiting on outstanding
> rendering via dmabuf->resv. (This offers an alternative to using poll
> that is consistent with other drivers that may need to more work to
> prepare the object for access by the CPU.)
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_prime.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 780589b420a4..479ff7cc3634 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -28,6 +28,7 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> @@ -288,6 +289,22 @@ static int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf,
> return dev->driver->gem_prime_mmap(obj, vma);
> }
>
> +static int drm_gem_begin_cpu_access(struct dma_buf *dma_buf,
> + enum dma_data_direction direction)
> +{
> + bool write = (direction == DMA_BIDIRECTIONAL ||
> + direction == DMA_TO_DEVICE);
> + struct reservation_object *resv = dma_buf->resv;
> + long ret;
> +
> + ret = reservation_object_wait_timeout_rcu(resv, write, true,
> + MAX_SCHEDULE_TIMEOUT);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
Maybe we even want this in the dma-buf layer as default function if
nothing else is provided? After all this one here is entirely generic, and
uses neither gem nor even drm_prime knowledge. Either way:
Reviewed-by: Daniel Vetter
> +
> static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = {
> .attach = drm_gem_map_attach,
> .detach = drm_gem_map_detach,
> @@ -301,6 +318,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops
> = {
> .mmap = drm_gem_dmabuf_mmap,
> .vmap = drm_gem_dmabuf_vmap,
> .vunmap = drm_gem_dmabuf_vunmap,
> + .begin_cpu_access = drm_gem_begin_cpu_access,
> };
>
> /**
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2] drm: Protect drm_connector_register_all() under DRIVER_MODESET
On Sat, Jun 18, 2016 at 04:41:26PM +0100, Chris Wilson wrote:
> On Sat, Jun 18, 2016 at 04:25:46PM +0100, Emil Velikov wrote:
> > On 18 June 2016 at 14:46, Chris Wilson wrote:
> > > 0-day kbuilder found
> > >
> > > [1.360244] BUG: unable to handle kernel NULL pointer dereference at
> > > (null)
> > > [1.360972] IP: [] mutex_lock_nested+0x11f/0x2c3
> > > [1.361512] *pde =
> > > [1.361827] Oops: 0002 [#1]
> > > [1.362123] Modules linked in:
> > > [1.362451] CPU: 0 PID: 1 Comm: swapper Not tainted
> > > 4.7.0-rc2-00564-ge28cd4d #1
> > > [1.363202] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> > > BIOS Debian-1.8.2-1 04/01/2014
> > > [1.364105] task: c03d ti: d28da000 task.ti: d28da000
> > > [1.364636] EIP: 0060:[] EFLAGS: 00210096 CPU: 0
> > > [1.365215] EIP is at mutex_lock_nested+0x11f/0x2c3
> > > [1.365703] EAX: EBX: d39e8ae8 ECX: d39e8b14 EDX: c1361cf9
> > > [1.366351] ESI: c03d EDI: d28dbed0 EBP: d28dbeec ESP: d28dbec0
> > > [1.367010] DS: 007b ES: 007b FS: GS: SS: 0068
> > > [1.367534] CR0: 80050033 CR2: CR3: 019a9000 CR4: 0690
> > > [1.368152] Stack:
> > > [1.368356] d39e8b14 d39e8b24 c1361cf9 00200246 d39e8b14
> > > d28dbed0
> > > [1.369235] d39e8800 d39e8ae8 d28dbf08 c1361cf9 d28dbf0c
> > > c10b25be d39e8800
> > > [1.370087] d28dbf1c c135e37d fff4
> > > d28dbf28
> > > [1.371012] Call Trace:
> > > [1.371272] [] ? drm_connector_register_all+0x1a/0x92
> > > [1.371847] [] drm_connector_register_all+0x1a/0x92
> > > [1.372421] [] ? kstrdup+0x25/0x3a
> > > [1.372863] [] drm_dev_register+0x59/0x99
> > > [1.373358] [] vgem_init+0x34/0x49
> > > [1.373770] [] ? mipi_dsi_bus_init+0xf/0xf
> > > [1.374257] [] do_one_initcall+0x7c/0xfd
> > > [1.374754] [] ? parse_args+0x1fd/0x314
> > > [1.375259] [] ? kernel_init_freeable+0xd0/0x179
> > > [1.375837] [] kernel_init_freeable+0xec/0x179
> > > [1.376371] [] kernel_init+0x8/0xcb
> > > [1.376806] [] ret_from_kernel_thread+0xe/0x30
> > > [1.377322] [] ? rest_init+0x10e/0x10e
> > > [1.377754] Code: 89 fa e8 71 c5 b7 ff 8b 4e 04 89 fa 89 d8 e8 8e c6
> > > b7 ff 8d 43 2c 89 45 d4 8b 43 30 8d 4b 2c 89 45 e8 89 7b 30 89 4d e4 8b
> > > 55 dc <89> 38 8d 43 3c 89 75 ec e8 c9 dd b7 ff eb 0c 31 c0 87 03 48
> > > +75
> > > [1.380442] EIP: [] mutex_lock_nested+0x11f/0x2c3 SS:ESP
> > > 0068:d28dbec0
> > > [1.381174] CR2:
> > >
> > > when loading the non-modesetting vGEM module. To prevent use of the
> > > uninitialised dev->mode_config from drm_dev_register() we move the
> > > drm_connector_register_all() under a DRIVER_MODESET guard. Longer term,
> > > we probably want to initialise the embedded dev->mode_config automatically
> > > from drm_dev_init() for all DRIVER_MODESET drivers.
> > >
> > > v2: Also protect drm_dev_unregister.
> > >
> > > Fixes: e28cd4d0a223 ("drm: Automatically register/unregister all
> > > connectors")
> > > Signed-off-by: Chris Wilson
> > > Cc: Daniel Vetter
> > > Cc: Emil Velikov
> >
> > Reviewed-by: Emil Velikov
>
> Can also add
> Testcase: igt/vgem_reload_basic
Thanks for patch, applied to drm-misc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
