[PATCH 1/2] drm: exynos: Perform initialization/cleanup at probe/remove time

[Laurent Pinchart]

Hi Daniel,

On Friday 16 Dec 2016 18:02:20 Daniel Stone wrote:
> On 13 December 2016 at 19:34, Laurent Pinchart wrote:
> > From: Laurent Pinchart 
> > 
> > The drm driver .load() operation is prone to race conditions as it
> > initializes the driver after registering the device nodes. Its usage is
> > deprecated, inline it in the probe function and call drm_dev_alloc() and
> > drm_dev_register() explicitly.
> > 
> > For consistency inline the .unload() handler in the remove function as
> > well.
> 
> Almost there: you need to add 'drm->platformdev =
> to_platform_device(dev)' next to the drm->dev_private assignment.

I don't think that's needed. The field was indeed initialized by 
drm_get_platform_dev() (called from drm_platform_init()), but only used in two 
locations in the driver where the struct device is available through different 
ways.

As struct drm_device contains a separate struct device *dev, I'll write a 
patch to remove the platformdev field.

> I thought about cleaning this up, but my XU3's eMMC is dead, so testing
> on Exynos for me has a 5+ minute RTT through LAVA ... so this is:
> 
> Reviewed-by: Daniel Stone 

Thanks.

-- 
Regards,

Laurent Pinchart

Radeon X200M device suspend problem

[Dmitriy Kryuk]

On 12/16/2016 04:01 PM, Michel Dänzer wrote:
> On 16/12/16 01:29 AM, Dmitriy Kryuk wrote:
>> I have a laptop with a Radeon X200M card in it. I use Radeon DRM driver
>> for graphics, and it makes the system hang with display off when trying
>> to suspend (either to disk or to RAM). Using /sys/power/pm_test
>> interface revealed that it freezes when suspending devices.
>>
>> I have tried both Debian repository kernel
>> (https://packages.debian.org/stable/linux-image-3.16.0-4-686-pae) and a
>> custom-built vanilla 3.18.45 kernel with this driver both built-in and
>> included as a module. The problem reproduces the same way. It stops to
>> reproduce if I delete the module radeon.ko or otherwise prevent it from
>> loading. The problem didn't appear before I started using DRM.
...
>> What additional information can I collect and how? What other kernel and
>> driver versions can I try to see if the problem is already solved?
> Please try a current kernel version; ideally 4.9, but definitely much
> newer than 3.18.
>
>
I have built a 4.9 kernel with the configuration based on my 3.18.45 
one, and the behaviour is still the same. How could I get more 
information to debug the problem, at least to make the driver not switch 
off LCD panel power and backlight?

[Bug 98812] video and switching windows causing flickering

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98812

--- Comment #12 from Sanjeev Kumar Sharma  ---
>This looks like similar issue: 
https://bugs.freedesktop.org/show_bug.cgi?id=73116

that fix is working for me too - I applied it and reverted the xrandr command
to the old rate and no issues for a couple of hours now

-- 
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/20161217/8b7c76e2/attachment.html>

[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99130

--- Comment #3 from Chris Wilson  ---
Looks like the timeout value isn't being computed properly (possibly just that
too much time is unaccounted?). Can you apply:

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1b2f18d0ca2b..dfe751b350ad 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3019,6 +3019,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
 {
struct drm_i915_gem_wait *args = data;
struct drm_i915_gem_object *obj;
+   u64 prev_timeout = args->timeout_ns;
ktime_t start;
long ret;

@@ -3042,6 +3043,12 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
args->timeout_ns = 0;
}

+   pr_info("%s: timeout %d.%09d -> %d.%09d\n", __func__,
+   prev_timeout < 0 ? -1 : ns_to_timespec(prev_timeout).tv_sec,
+   prev_timeout < 0 ? 0 : ns_to_timespec(prev_timeout).tv_nsec,
+   args->timeout_ns < 0 ? -1 :
ns_to_timespec(args->timeout_ns).tv_sec,
+   args->timeout_ns < 0 ? 0 :
ns_to_timespec(args->timeout_ns).tv_nsec);
+
i915_gem_object_put(obj);
return ret;
 }

and get the output for a failure?

-- 
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/20161217/1bf1392d/attachment.html>

[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99130

--- Comment #2 from Dorota Czaplejewicz  ---
Software:
Fedora 24
kernel revision: 5415795 (drm-tip: 2016y-12m-16d-21h-26m-45s UTC integration
manifest)
kernel config: https://intel-gfx-ci.01.org/CI/CI_DRM_1968/kernel.config.bz2

Hardware:
Intel i7-3770

-- 
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/20161217/8edb4eac/attachment.html>

[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99130

--- Comment #1 from Dorota Czaplejewicz  ---
Created attachment 128525
  --> https://bugs.freedesktop.org/attachment.cgi?id=128525=edit
basic-wait-all dmesg log

-- 
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/20161217/d938ab3d/attachment.html>

[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99130

Bug ID: 99130
   Summary: [IVB] CONFIG_PROVE_LOCKING=y causes
igt/gem_exec/basic-wait-all (and possibly others) to
fail
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: dorota.czaplejewicz at collabora.co.uk

Created attachment 128524
  --> https://bugs.freedesktop.org/attachment.cgi?id=128524=edit
basic-wait-all log

Kernels built with the default CI config (e.g.
https://intel-gfx-ci.01.org/CI/CI_DRM_1968/kernel.config.bz2 ) will trigger
failures in the test
igt/gem_exec/basic-wait-all
The failures will rarely appear immediately; for faithful reproduction, running
the test several times consecutively is needed (at least 4 times). Afterwards,
the failures will be constant.

Changing CONFIG_PROVE_LOCKING from "=y" to "=n" will stop the failures.

-- 
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/20161217/f268308b/attachment-0001.html>

[PATCH] drm/amdgpu: Don't save new cursor size before updating CUR_SIZE register.

['Liviu Dudau']

On Fri, Dec 16, 2016 at 07:16:25PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Liviu Dudau [mailto:liviu at dudau.co.uk]
> > Sent: Friday, December 16, 2016 2:11 PM
> > To: Daenzer, Michel; Deucher, Alexander
> > Cc: Koenig, Christian; David Airlie; dri-devel at lists.freedesktop.org; 
> > amd-
> > gfx at lists.freedesktop.org; Liviu Dudau
> > Subject: [PATCH] drm/amdgpu: Don't save new cursor size before updating
> > CUR_SIZE register.
> > 
> > Commit 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register
> > when
> > necessary") did not cleanup correctly the old code for DCE v6 and v8.
> > As a consequence, cursor updates stopped working for my Radeon R9
> > 1002:67b0
> > dual-monitor setup.
> > 
> > Fixes: 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register
> > when necessary")
> > Signed-off-by: Liviu Dudau 
> 
> Already fixed:
> https://lists.freedesktop.org/archives/amd-gfx/2016-December/003985.html

Sorry, I've only checked the dri-devel list, I've only noticed there is an
amd-gfx one while preparing the patch for sending.

> and queued for fixes:
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.10-wip=837b2d51a5847584fe64aebbc94ef8b7ae59fd87

Cool, thanks!

Best regards,
Liviu

> 
> Alex
> 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +-
> >  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 --
> >  2 files changed, 1 insertion(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > index e564442..b4e4ec6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > @@ -1944,9 +1944,7 @@ static int dce_v6_0_crtc_cursor_set2(struct
> > drm_crtc *crtc,
> > 
> > dce_v6_0_lock_cursor(crtc, true);
> > 
> > -   if (width != amdgpu_crtc->cursor_width ||
> > -   height != amdgpu_crtc->cursor_height ||
> > -   hot_x != amdgpu_crtc->cursor_hot_x ||
> > +   if (hot_x != amdgpu_crtc->cursor_hot_x ||
> > hot_y != amdgpu_crtc->cursor_hot_y) {
> > int x, y;
> > 
> > @@ -1955,8 +1953,6 @@ static int dce_v6_0_crtc_cursor_set2(struct
> > drm_crtc *crtc,
> > 
> > dce_v6_0_cursor_move_locked(crtc, x, y);
> > 
> > -   amdgpu_crtc->cursor_width = width;
> > -   amdgpu_crtc->cursor_height = height;
> > amdgpu_crtc->cursor_hot_x = hot_x;
> > amdgpu_crtc->cursor_hot_y = hot_y;
> > }
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > index 6ce7fb4..584abe8 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > @@ -2438,8 +2438,6 @@ static int dce_v8_0_crtc_cursor_set2(struct
> > drm_crtc *crtc,
> > 
> > dce_v8_0_cursor_move_locked(crtc, x, y);
> > 
> > -   amdgpu_crtc->cursor_width = width;
> > -   amdgpu_crtc->cursor_height = height;
> > amdgpu_crtc->cursor_hot_x = hot_x;
> > amdgpu_crtc->cursor_hot_y = hot_y;
> > }
> > --
> > 2.10.2
> 

-- 
---
   .oooO
   (   )
\ (  Oooo.
 \_) (   )
  ) /
 (_/

 One small step
   for me ...

[PATCH libdrm v2 3/3] xf86drm: don't fatal on per device error in drmGetDevice[s]2

[Jonathan Gray]

When iterating over all the device nodes if drmProcessPciDevice()
returned an error for any node the function would return an error,
ignoring any valid nodes.

The result of this on OpenBSD where drmProcessPciDevice() results in
device nodes being opened to issue ioctls to get pci data
was that data obtained from /dev/drm0 would be ignored if /dev/drm1
could not be opened.

Signed-off-by: Jonathan Gray 
---
 xf86drm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index f684c017..7d7df184 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3383,7 +3383,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr 
*device)
 case DRM_BUS_PCI:
 ret = drmProcessPciDevice(, node, node_type, maj, min, true, 
flags);
 if (ret)
-goto free_devices;
+continue;

 break;
 default:
@@ -3514,7 +3514,7 @@ int drmGetDevices2(uint32_t flags, drmDevicePtr 
devices[], int max_devices)
 ret = drmProcessPciDevice(, node, node_type,
   maj, min, devices != NULL, flags);
 if (ret)
-goto free_devices;
+continue;

 break;
 default:
-- 
2.11.0

[PATCH libdrm v2 2/3] xf86drm: add a non-sysfs version of drmGetDeviceNameFromFd2

[Jonathan Gray]

Implement a generic drmGetDeviceNameFromFd2() to use on non-linux
systems without sysfs.

v2: remove min < base test as requested by Emil

Signed-off-by: Jonathan Gray 
---
 xf86drm.c | 44 ++--
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index f6850aa2..f684c017 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3627,7 +3627,47 @@ char *drmGetDeviceNameFromFd2(int fd)
 fclose(f);
 return device_name;
 #else
-#warning "Missing implementation of drmGetDeviceNameFromFd2"
-return NULL;
+struct stat  sbuf;
+char node[PATH_MAX + 1];
+const char  *dev_name;
+int  node_type;
+int  maj, min, n, base;
+
+if (fstat(fd, ))
+return NULL;
+
+maj = major(sbuf.st_rdev);
+min = minor(sbuf.st_rdev);
+
+if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+return NULL;
+
+node_type = drmGetMinorType(min);
+if (node_type == -1)
+return NULL;
+
+switch (node_type) {
+case DRM_NODE_PRIMARY:
+dev_name = DRM_DEV_NAME;
+break;
+case DRM_NODE_CONTROL:
+dev_name = DRM_CONTROL_DEV_NAME;
+break;
+case DRM_NODE_RENDER:
+dev_name = DRM_RENDER_DEV_NAME;
+break;
+default:
+return NULL;
+};
+
+base = drmGetMinorBase(node_type);
+if (base < 0)
+return NULL;
+
+n = snprintf(node, PATH_MAX, dev_name, DRM_DIR_NAME, min - base);
+if (n == -1 || n >= PATH_MAX)
+  return NULL;
+
+return strdup(node);
 #endif
 }
-- 
2.11.0

[PATCH libdrm v2 1/3] xf86drm: adjust device node path for minor base

[Jonathan Gray]

When constructing a path to a device node the minor number retrieved
from fstat needs to have the offset of the node type subtracted from it.
Control and render node types have the same major as the primary node
but each has their own block of minor types at fixed offsets.

v2: remove min < base test as requested by Emil

Signed-off-by: Jonathan Gray 
---
 xf86drm.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index b5eeeb09..f6850aa2 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2838,7 +2838,7 @@ out_close_dir:
 char buf[PATH_MAX + 1];
 const char *dev_name;
 unsigned int maj, min;
-int n;
+int n, base;

 if (fstat(fd, ))
 return NULL;
@@ -2863,7 +2863,11 @@ out_close_dir:
 return NULL;
 };

-n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min);
+base = drmGetMinorBase(type);
+if (base < 0)
+return NULL;
+
+n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min - base);
 if (n == -1 || n >= sizeof(buf))
 return NULL;

@@ -3262,7 +3266,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr 
*device)
 char node[PATH_MAX + 1];
 const char  *dev_name;
 int  node_type, subsystem_type;
-int  maj, min, n, ret;
+int  maj, min, n, ret, base;

 if (fd == -1 || device == NULL)
 return -EINVAL;
@@ -3294,7 +3298,11 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr 
*device)
 return -EINVAL;
 };

-n = snprintf(node, PATH_MAX, dev_name, DRM_DIR_NAME, min);
+base = drmGetMinorBase(node_type);
+if (base < 0)
+return -EINVAL;
+
+n = snprintf(node, PATH_MAX, dev_name, DRM_DIR_NAME, min - base);
 if (n == -1 || n >= PATH_MAX)
   return -errno;
 if (stat(node, ))
-- 
2.11.0

Issue with DRM and "reimplement IDR and IDA using the radix tree"

[Alexandre Courbot]

On 12/17/2016 01:16 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Dec 14, 2016 at 11:08:20PM +0900, Alexandre Courbot wrote:
>> Forgot to add the most relevant list for this issue (linux-next).
>>
>> Stephen, maybe you will want to temporarily revert this patch until this
>> is cleared? This probably affects other users than DRM.
>>
>> On 12/13/2016 04:14 PM, Alexandre Courbot wrote:
>>> Hi Matthew,
>>>
>>> Trying the latest -next on the Jetson TK1 board (with two different DRM
>>> devices and display and render), I noticed that the GPU device probe
>>> always failed with error -ENOSPC. After investigating I figured out that
>>> this was due to the minor device allocation failing when a second DRM
>>> device is added.
>>>
>>> More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY
>>> (0) as argument for a second time, the call to idr_alloc() (which has a
>>> requested range of 0..64) fails instead of returning 1 as expected. Note
>>> that the first call is successful.
>>>
>>> Reverting "reimplement IDR and IDA using the radix tree" on 20161213's
>>> next fixes the issue for me, suggesting a bug may have slipped in there.
>>>
>>> Not sure how this could be fixed, so reporting the issue for now in case
>>> it is not known yet.
> 
> I can confirm Alex' findings, though the symptoms seem to be slightly
> different, which may be related to me testing on next-20161216 rather
> than next-20161213.
> 
> What I'm seeing is that all drivers get probed correctly, but when an
> application tries to open the DRM device files (/dev/dri/card0 in this
> case), then all devices of a given minor type disappear. So in my case
> upon boot I get this:
> 
>   # ls -l /dev/dri/
>   total 0
>   crw-rw 1 root video 226,   0 Dec 16 15:59 card0
>   crw-rw 1 root video 226,   1 Dec 16 15:59 card1
>   crw-rw 1 root video 226, 128 Dec 16 15:59 renderD128
> 
> The modetest program from libdrm is then unable to open any devices:
> 
>   # modetest
>   trying to open device 'i915'...failed
>   trying to open device 'amdgpu'...failed
>   trying to open device 'radeon'...failed
>   trying to open device 'nouveau'...failed
>   trying to open device 'vmwgfx'...failed
>   trying to open device 'omapdrm'...failed
>   trying to open device 'exynos'...failed
>   trying to open device 'tilcdc'...failed
>   trying to open device 'msm'...failed
>   trying to open device 'sti'...failed
>   trying to open device 'tegra'...failed
>   trying to open device 'imx-drm'...failed
>   trying to open device 'rockchip'...failed
>   trying to open device 'atmel-hlcdc'...failed
>   trying to open device 'fsl-dcu-drm'...failed
>   trying to open device 'vc4'...failed
>   trying to open device 'virtio_gpu'...failed
>   trying to open device 'mediatek'...failed
>   no device found
> 
> And after that all of the primary minors are gone:
> 
>   # ls -l /dev/dri/
>   total 0
>   crw-rw 1 root video 226, 128 Dec 16 15:59 renderD128

That's exactly what I am also getting with 20161216. As it turns out the
patch has changed slightly (my revert did not apply after a rebase), and
the symptoms changed against 20161215, but the fix is the same:
reverting gives me back a working system.

This patch really should be reverted for now. Like Thierry I am
available to test further iterations.

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

[Peter Zijlstra]

On Fri, Dec 16, 2016 at 02:17:25PM +0100, Nicolai Hähnle wrote:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
> >On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
> >
> >>@@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, 
> >>unsigned int subclass,
> >>struct mutex_waiter waiter;
> >>unsigned long flags;
> >>bool first = false;
> >>-   struct ww_mutex *ww;
> >>int ret;
> >>
> >>-   if (use_ww_ctx) {
> >>+   if (use_ww_ctx && ww_ctx) {
> >>+   struct ww_mutex *ww;
> >>+
> >>ww = container_of(lock, struct ww_mutex, base);
> >>if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
> >>return -EALREADY;
> >
> >So I don't see the point of removing *ww from the function scope, we can
> >still compute that container_of() even if !ww_ctx, right? That would
> >safe a ton of churn below, adding all those struct ww_mutex declarations
> >and container_of() casts.
> >
> >(and note that the container_of() is a fancy NO-OP because base is the
> >first member).
> 
> Sorry for taking so long to get back to you.
> 
> In my experience, the undefined behavior sanitizer in GCC for userspace
> programs complains about merely casting a pointer to the wrong type. I never
> went into the standards rabbit hole to figure out the details. It might be a
> C++ only thing (ubsan cannot tell the difference otherwise anyway), but that
> was the reason for doing the change in this more complicated way.

Note that C only has what C++ calls reinterpret_cast<>(). It cannot
complain about a 'wrong' cast, there is no such thing.

Also, container_of() works, irrespective of what C language says about
it -- note that the kernel in general hard relies on a lot of things C
calls undefined behaviour.

> Are you sure that this is defined behavior in C? If so, I'd be happy to go
> with the version that has less churn.

It should very much work with kernel C.

[RFC 00/10] implement alternative and much simpler id allocator

[Matthew Wilcox]

From: Matthew Wilcox
> From: Rasmus Villemoes [mailto:linux at rasmusvillemoes.dk]
> > This sounds good. I think there may still be a lot of users that never
> > allocate more than a handful of IDAs, making a 128 byte allocation still
> > somewhat excessive. One thing I considered was (exactly as it's done for
> > file descriptor tables) to embed a single word in the struct ida and
> > use that initially; I haven't looked closely at newIDA, so I don't know
> > how easy that would be or if its worth the complexity.
> 
> Heh, I was thinking about that too.  The radix tree supports "exceptional
> entries" which have the bottom bit set.  On a 64-bit machine, we could use 62
> of the bits in the radix tree root to store the ID bitmap.  I'm a little wary 
> of the
> potential complexity, but we should try it out.

Test patch here: 
http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/idr-2016-12-16
It passes the test suite ... which I actually had to adjust because it now 
succeeds in cases where it hadn't (allocating ID 0 without preallocating), and 
it will now fail in cases where it hadn't previously (assuming a single 
preallocation would be enough).  There shouldn't be any examples of that in the 
kernel proper; it was simply me being lazy when I wrote the test suite.

[PATCH] lib: Add a simple prime number generator

[Chris Wilson]

Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.

v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
v5: Fix RCU unwind on module exit, add to kselftests

Signed-off-by: Chris Wilson 
Cc: Lukas Wunner 
---
 include/linux/prime_numbers.h|  13 ++
 lib/Kconfig  |   7 +
 lib/Makefile |   2 +
 lib/prime_numbers.c  | 238 +++
 tools/testing/selftests/lib/prime_numbers.sh |  15 ++
 5 files changed, 275 insertions(+)
 create mode 100644 include/linux/prime_numbers.h
 create mode 100644 lib/prime_numbers.c
 create mode 100755 tools/testing/selftests/lib/prime_numbers.sh

diff --git a/include/linux/prime_numbers.h b/include/linux/prime_numbers.h
new file mode 100644
index ..877f6acbd0b6
--- /dev/null
+++ b/include/linux/prime_numbers.h
@@ -0,0 +1,13 @@
+#ifndef __LINUX_PRIME_NUMBERS_H
+#define __LINUX_PRIME_NUMBERS_H
+
+#include 
+
+bool is_prime_number(unsigned long x);
+unsigned long next_prime_number(unsigned long x);
+
+/* A useful white-lie here is that 1 is prime. */
+#define for_each_prime_number(prime, max) \
+   for (prime = 1; prime < (max); prime = next_prime_number(prime))
+
+#endif /* !__LINUX_PRIME_NUMBERS_H */
diff --git a/lib/Kconfig b/lib/Kconfig
index 260a80e313b9..1788a1f50d28 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -550,4 +550,11 @@ config STACKDEPOT
 config SBITMAP
bool

+config PRIME_NUMBERS
+   tristate "Prime number generator"
+   default n
+   help
+ Provides a helper module to generate prime numbers. Useful for writing
+ test code, especially when checking multiplication and divison.
+
 endmenu
diff --git a/lib/Makefile b/lib/Makefile
index 50144a3aeebd..c664143fd917 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -197,6 +197,8 @@ obj-$(CONFIG_ASN1) += asn1_decoder.o

 obj-$(CONFIG_FONT_SUPPORT) += fonts/

+obj-$(CONFIG_PRIME_NUMBERS) += prime_numbers.o
+
 hostprogs-y:= gen_crc32table
 clean-files:= crc32table.h

diff --git a/lib/prime_numbers.c b/lib/prime_numbers.c
new file mode 100644
index ..f5a704033a3c
--- /dev/null
+++ b/lib/prime_numbers.c
@@ -0,0 +1,238 @@
+#define pr_fmt(fmt) "prime numbers: " fmt "\n"
+
+#include 
+#include 
+#include 
+#include 
+
+struct primes {
+   struct rcu_head rcu;
+   unsigned long last, sz;
+   unsigned long primes[];
+};
+
+#if BITS_PER_LONG == 64
+static const struct primes small_primes = {
+   .last = 61,
+   .sz = 64,
+   .primes = { 0x28208a20a08a28acUL }
+};
+#elif BITS_PER_LONG == 32
+static const struct primes small_primes = {
+   .last = 31,
+   .sz = 32,
+   .primes = { 0xa08a28acUL }
+};
+#else
+#error "unhandled BITS_PER_LONG"
+#endif
+
+static DEFINE_MUTEX(lock);
+static const struct primes __rcu *primes = RCU_INITIALIZER(_primes);
+
+static unsigned long selftest_max;
+
+static bool slow_is_prime_number(unsigned long x)
+{
+   unsigned long y = int_sqrt(x);
+
+   while (y > 1) {
+   if ((x % y) == 0)
+   break;
+   y--;
+   }
+
+   return y == 1;
+}
+
+static unsigned long slow_next_prime_number(unsigned long x)
+{
+   for (;;) {
+   if (slow_is_prime_number(++x))
+   return x;
+   }
+}
+
+static unsigned long mark_multiples(unsigned long x,
+   unsigned long *p,
+   unsigned long start,
+   unsigned long end)
+{
+   unsigned long m;
+
+   m = 2 * x;
+   if (m < start)
+   m = roundup(start, x);
+
+   while (m < end) {
+   __clear_bit(m, p);
+   m += x;
+   }
+
+   return x;
+}
+
+static const struct primes *expand_to_next(unsigned long x)
+{
+   const struct primes *p;
+   struct primes *new;
+   unsigned long sz, y;
+
+   rcu_read_unlock();
+
+   /* Betrand's Theorem states:
+*  For all n > 1, there exists a prime p: n < p <= 2*n.
+*/
+   sz = 2 * x + 1;
+   if (sz < x)
+   return NULL;
+
+   sz = round_up(sz, BITS_PER_LONG);
+   new = kmalloc(sizeof(*new) + sz / sizeof(long), GFP_KERNEL);
+   if (!new)
+   return NULL;
+
+   mutex_lock();
+   p = rcu_dereference_protected(primes, lockdep_is_held());
+   if (x < p->last) {
+   kfree(new);
+   goto relock;
+   }
+
+   /* Where memory permits, track the primes using the
+* Sieve of Eratosthenes.
+*/
+   memcpy(new->primes, p->primes, p->sz / BITS_PER_LONG * sizeof(long));
+   memset(new->primes + p->sz / BITS_PER_LONG,
+  0xff, (sz - p->sz) / BITS_PER_LONG * 

[Bug 98812] video and switching windows causing flickering

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98812

--- Comment #11 from Sanjeev Kumar Sharma  ---
The xrandr solution above works but from 3 to 5 days apart the flickering
returns and I need to re-run the command

-- 
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/20161217/920979f7/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #10 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
> Does not enabling Option "ShadowPrimary" in xorg.conf help for any of the 
> issues under X?

I disabled "ShadowPrimary" and verified the change in xorg.0.log. This does not
resolve either issue, not the blurring nor the display garbage. If anything, it
introduces some new misbehaviors when in blender.

-- 
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/20161217/46fa9b2f/attachment.html>

[PATCH] drm: kselftest for drm_mm and top-down allocation

[Chris Wilson]

Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.

v2: Flip sign on conditional assert.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/selftests/drm_mm_selftests.h |   1 +
 drivers/gpu/drm/selftests/test-drm_mm.c  | 119 +++
 2 files changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h 
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index 965aca65c160..cd508e3d6538 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -17,3 +17,4 @@ selftest(align32, igt_align32)
 selftest(align64, igt_align64)
 selftest(evict, igt_evict)
 selftest(evict_range, igt_evict_range)
+selftest(topdown, igt_topdown)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 403543c67e52..4530c514016e 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1552,6 +1552,125 @@ static int igt_evict_range(void *ignored)
return ret;
 }

+static unsigned int node_index(const struct drm_mm_node *node)
+{
+   return div64_u64(node->start, node->size);
+}
+
+static int igt_topdown(void *ignored)
+{
+   const struct insert_mode *topdown = _modes[TOPDOWN];
+   DRM_RND_STATE(prng, random_seed);
+   const unsigned int count = 8192;
+   unsigned int size;
+   unsigned long *bitmap = NULL;
+   struct drm_mm mm;
+   struct drm_mm_node *nodes, *node, *next;
+   unsigned int *order, n, m, o = 0;
+   int ret;
+
+   /* When allocating top-down, we expect to be returned a node
+* from a suitable hole at the top of the drm_mm. We check that
+* the returned node does match the highest available slot.
+*/
+
+   ret = -ENOMEM;
+   nodes = vzalloc(count * sizeof(*nodes));
+   if (!nodes)
+   goto err;
+
+   bitmap = kzalloc(count / BITS_PER_LONG * sizeof(unsigned long),
+GFP_TEMPORARY);
+   if (!bitmap)
+   goto err_nodes;
+
+   order = drm_random_order(count, );
+   if (!order)
+   goto err_bitmap;
+
+   ret = -EINVAL;
+   for (size = 1; size <= 64; size <<= 1) {
+   drm_mm_init(, 0, size*count);
+   for (n = 0; n < count; n++) {
+   if (!expect_insert(, [n],
+  size, 0, n,
+  topdown)) {
+   pr_err("insert failed, size %u step %d\n", 
size, n);
+   goto out;
+   }
+
+   if (nodes[n].hole_follows) {
+   pr_err("hole after topdown insert %d, 
start=%llx\n, size=%u",
+  n, nodes[n].start, size);
+   goto out;
+   }
+
+   if (!assert_one_hole(, 0, size*(count - n - 1)))
+   goto out;
+   }
+
+   if (!assert_continuous(, size))
+   goto out;
+
+   drm_random_reorder(order, count, );
+   for_each_prime_number(n, min(count, max_prime)) {
+   for (m = 0; m < n; m++) {
+   node = [order[(o + m) % count]];
+   drm_mm_remove_node(node);
+   __set_bit(node_index(node), bitmap);
+   }
+
+   for (m = 0; m < n; m++) {
+   unsigned int last;
+
+   node = [order[(o + m) % count]];
+   if (!expect_insert(, node,
+  size, 0, 0,
+  topdown)) {
+   pr_err("insert failed, step %d/%d\n", 
m, n);
+   goto out;
+   }
+
+   if (node->hole_follows) {
+   pr_err("hole after topdown insert 
%d/%d, start=%llx\n",
+  m, n, node->start);
+   goto out;
+   }
+
+   last = find_last_bit(bitmap, count);
+   if (node_index(node) != last) {
+   pr_err("node %d/%d, size %d, not 
inserted into upmost hole, expected %d, found %d\n",
+  m, n, size, last, 
node_index(node));
+   goto out;
+   }
+
+   __clear_bit(last, bitmap);
+   }
+
+  

[PATCH] drm: kselftest for drm_mm_insert_node_in_range()

[Chris Wilson]

Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.

v2: Use all allocation flags
v3: Don't pass in invalid ranges - these will be asserted later.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/selftests/drm_mm_selftests.h |   1 +
 drivers/gpu/drm/selftests/test-drm_mm.c  | 269 +++
 2 files changed, 270 insertions(+)

diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h 
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index dca726baa65d..92b2c1cb10fa 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -11,3 +11,4 @@ selftest(debug, igt_debug)
 selftest(reserve, igt_reserve)
 selftest(insert, igt_insert)
 selftest(replace, igt_replace)
+selftest(insert_range, igt_insert_range)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c
index fa5b12c57161..cfbc3f53798e 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -738,6 +738,275 @@ static int igt_replace(void *ignored)
return 0;
 }

+static bool expect_insert_in_range(struct drm_mm *mm, struct drm_mm_node *node,
+  u64 size, u64 alignment, unsigned long color,
+  u64 range_start, u64 range_end,
+  const struct insert_mode *mode)
+{
+   int err;
+
+   err = drm_mm_insert_node_in_range_generic(mm, node,
+ size, alignment, color,
+ range_start, range_end,
+ mode->search_flags,
+ mode->create_flags);
+   if (err) {
+   pr_err("insert (size=%llu, alignment=%llu, color=%lu, mode=%s) 
nto range [%llx, %llx] failed with err=%d\n",
+  size, alignment, color, mode->name,
+  range_start, range_end, err);
+   return false;
+   }
+
+   if (!assert_node(node, mm, size, alignment, color)) {
+   drm_mm_remove_node(node);
+   return false;
+   }
+
+   return true;
+}
+
+static bool expect_insert_in_range_fail(struct drm_mm *mm,
+   u64 size,
+   u64 range_start,
+   u64 range_end)
+{
+   struct drm_mm_node tmp = {};
+   int err;
+
+   err = drm_mm_insert_node_in_range_generic(mm, ,
+ size, 0, 0,
+ range_start, range_end,
+ DRM_MM_SEARCH_DEFAULT,
+ DRM_MM_CREATE_DEFAULT);
+   if (likely(err == -ENOSPC))
+   return true;
+
+   if (!err) {
+   pr_err("impossible insert succeeded, node %llx + %llu, range 
[%llx, %llx]\n",
+  tmp.start, tmp.size, range_start, range_end);
+   drm_mm_remove_node();
+   } else {
+   pr_err("impossible insert failed with wrong error %d [expected 
%d], size %llu, range [%llx, %llx]\n",
+  err, -ENOSPC, size, range_start, range_end);
+   }
+
+   return false;
+}
+
+static bool assert_contiguous_in_range(struct drm_mm *mm,
+  u64 size,
+  u64 start,
+  u64 end)
+{
+   struct drm_mm_node *node;
+   unsigned int n;
+
+   if (!expect_insert_in_range_fail(mm, size, start, end))
+   return false;
+
+   n = div64_u64(start + size - 1, size);
+   drm_mm_for_each_node(node, mm) {
+   if (node->start < start || node->start + node->size > end) {
+   pr_err("node %d out of range, address [%llx + %llu], 
range [%llx, %llx]\n",
+  n, node->start, node->start + node->size, start, 
end);
+   return false;
+   }
+
+   if (node->start != n * size) {
+   pr_err("node %d out of order, expected start %llx, 
found %llx\n",
+  n, n * size, node->start);
+   return false;
+   }
+
+   if (node->size != size) {
+   pr_err("node %d has wrong size, expected size %llx, 
found %llx\n",
+  n, size, node->size);
+   return false;
+   }
+
+   if (node->hole_follows && drm_mm_hole_node_end(node) < end) {
+   pr_err("node %d is followed by a hole!\n", n);
+   return false;
+   }
+
+   n++;
+   }
+
+   

[PATCH 1/2] drm: exynos: Perform initialization/cleanup at probe/remove time

[Inki Dae]

HI,

Thanks for patch. Reasonable to me and go to misc excepting below one thing.
Please check my comment.

2016-12-14 4:34 GMT+09:00 Laurent Pinchart
:
> From: Laurent Pinchart 
>
> The drm driver .load() operation is prone to race conditions as it
> initializes the driver after registering the device nodes. Its usage is
> deprecated, inline it in the probe function and call drm_dev_alloc() and
> drm_dev_register() explicitly.
>
> For consistency inline the .unload() handler in the remove function as
> well.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/exynos/exynos_dp.c   |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c  |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 245 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c |   1 -
>  drivers/gpu/drm/exynos/exynos_hdmi.c |   1 -
>  6 files changed, 127 insertions(+), 123 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 528229faffe4..b839f065f4b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -102,7 +102,6 @@ static int exynos_dp_bridge_attach(struct 
> analogix_dp_plat_data *plat_data,
> struct drm_encoder *encoder = >encoder;
> int ret;
>
> -   drm_connector_register(connector);

You removed above function from encoder and connector drivers.Is
removing this required?
And is this related to this patch? If not so, it seems this change
should go to another patch with the reason to remove this function
call.

Thanks,
Inki Dae

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #9 from Michel Dänzer  ---
Does not enabling Option "ShadowPrimary" in xorg.conf help for any of the
issues under X?

-- 
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/20161217/ef4f0277/attachment-0001.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #8 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
fc25 currently uses mesa-dri-drivers-13.0.2-2.fc25.x86_64

And I should also point out that glxgears runs fine, both initially when
launched and even after resizing.

-- 
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/20161217/a418ce69/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #7 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
Created attachment 128517
  --> https://bugs.freedesktop.org/attachment.cgi?id=128517=edit
shot of vlc playing video using openGL backend

-- 
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/20161217/0116ddb3/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #6 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
Created attachment 128516
  --> https://bugs.freedesktop.org/attachment.cgi?id=128516=edit
dmesg | grep -i radeon

-- 
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/20161217/e37901f0/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #5 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
Created attachment 128515
  --> https://bugs.freedesktop.org/attachment.cgi?id=128515=edit
shot of weston window under X

-- 
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/20161217/d3d8163c/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #4 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
Created attachment 128514
  --> https://bugs.freedesktop.org/attachment.cgi?id=128514=edit
terminal output from launching weston under X

-- 
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/20161217/664dbbc3/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #3 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
Created attachment 128513
  --> https://bugs.freedesktop.org/attachment.cgi?id=128513=edit
xorg log

-- 
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/20161217/27801a15/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #2 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
Created attachment 128512
  --> https://bugs.freedesktop.org/attachment.cgi?id=128512=edit
glxdemo shot after resize

-- 
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/20161217/cc359cc0/attachment-0001.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

--- Comment #1 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---
Created attachment 128511
  --> https://bugs.freedesktop.org/attachment.cgi?id=128511=edit
blender shot, blurred fonts

-- 
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/20161217/314e2740/attachment.html>

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99120

Bug ID: 99120
   Summary: VERDE 7770 - glxdemo, vlc/glx, weston fail with
garbled screen. Elsewhere blurry text rendering when
focus lost
   Product: Mesa
   Version: 13.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: 5lokuf+c77xmvwa3y1jk at sharklasers.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 128510
  --> https://bugs.freedesktop.org/attachment.cgi?id=128510=edit
glxinfo dump

OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE (DRM 2.46.0 /
4.8.13-300.fc25.x86_64, LLVM 3.8.0)

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X] [1002:683d]

Launching weston from vconsole freezes the display, switching to another
vconsole and killing the process returns to command line.

Launching weston under X opens a window with garbled contents. (attached shot)

Launching glxdemo under X opens a window with yellow square, but background
contains garbled noise. resizing the window causes the yellow square to resize
and render, but with more and more garbage appearing in the background
(attached shots)

Using vlc to play a video after selecting the OpenGL backend produces a fixed
garbled screen while the audio plays fine. (Shot attached)

I've experienced similar issues with other X programs which rely on GL(X?),
where the main screen appears but is completely corrupted.

another issue (related or not) is blurry text rendering in various programs.
I've experienced this with blender (see #38070) and with gnome-shell. 
Unlike (as I understand it) in #38070, the text is initially rendered properly
but when focus is lost it is blurred and as the cursor hovers over other
elements in the UI it gets worse and worse. Occasionally the whole UI s redrawn
and all the text snaps back, but it's largely unusable. Using software gl
instead has no such issues.  Shot attached, note properly rendered text on left
pane (which has focus) vs. blurred right hand pane (which doesn't have focus).

I've experienced the exact same issues on fc23 which uses mesa 11.x and had
(painfully) switched to catalyst which didn't have these issues. A recent
upgrade to fc25 means I can't use catalyst anymore, and despite several years
passing all these issues have not been resolved in the open source drivers.

Attaching everything I can think of, and glad to provide additional info as
needed.

-- 
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/20161217/ba2ff03a/attachment.html>

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

[Maarten Lankhorst]

Op 16-12-16 om 14:17 schreef Nicolai Hähnle:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
>> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>>
>>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, 
>>> unsigned int subclass,
>>>  struct mutex_waiter waiter;
>>>  unsigned long flags;
>>>  bool first = false;
>>> -struct ww_mutex *ww;
>>>  int ret;
>>>
>>> -if (use_ww_ctx) {
>>> +if (use_ww_ctx && ww_ctx) {
>>> +struct ww_mutex *ww;
>>> +
>>>  ww = container_of(lock, struct ww_mutex, base);
>>>  if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
>>>  return -EALREADY;
>>
>> So I don't see the point of removing *ww from the function scope, we can
>> still compute that container_of() even if !ww_ctx, right? That would
>> safe a ton of churn below, adding all those struct ww_mutex declarations
>> and container_of() casts.
>>
>> (and note that the container_of() is a fancy NO-OP because base is the
>> first member).
>
> Sorry for taking so long to get back to you.
>
> In my experience, the undefined behavior sanitizer in GCC for userspace 
> programs complains about merely casting a pointer to the wrong type. I never 
> went into the standards rabbit hole to figure out the details. It might be a 
> C++ only thing (ubsan cannot tell the difference otherwise anyway), but that 
> was the reason for doing the change in this more complicated way.
>
> Are you sure that this is defined behavior in C? If so, I'd be happy to go 
> with the version that has less churn.
>
> I'll also get rid of those ww_mutex_lock* wrapper functions. 

ww_ctx = use_ww_ctx ? container_of : NULL ?

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92258

--- Comment #47 from russianneuromancer at ya.ru ---
> FWIW, there's no need to set DRI_PRIME for steam itself, it can be set in 
> Properties -> Launch Options of individual games.
Then I have to don't forget to set it for every game. Set it for Steam once is
easier.

> Does the problem still occur with a current kernel?
Due to few issues with Linux 4.9 (not related to graphics) I tested this with
Linux 4.8 and Mesa 13.0.2. Yes, issue is still reproducible.

-- 
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/20161217/1f34ebfd/attachment.html>

[Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling

[Pandiyan, Dhinakaran]

On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> On Fri, 16 Dec 2016, Daniel Vetter  wrote:
> > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> >> The two remaining patches from [1], rebased.
> >> 
> >> BR,
> >> Jani.
> >> 
> >> 
> >> [1] 
> >> http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare
> >>  at intel.com
> >
> > Just for the record, I think the only thing missing here is the Xorg
> > review on the -modesetting patch. As soon as we have that I can vacuum
> > this up (probably best through drm-misc, but not sure).
> 
> Yeah I rebased this (and provided a debug hack privately) so Martin can
> test the modesetting changes.
> 
> BR,
> Jani.
> 
> 

I tested the -modesetting patch, which Martin had provided to Manasi,
with a compliance testing device (DPR-120) that can simulate link
training failure. The link rate correctly lowered after the link_status
property was set to BAD by the kernel and the userspace responded with a
modeset. 

One thing that was not straight forward to figure out was I had to boot
with i915.nuclear_pageflip=1. Is it documented somewhere that the
property needs DRIVER_ATOMIC to be set, or is it implicit?

The other thing I had trouble with -modesetting was, there was no
modeset following a long pulse from the sink at the begging of the test.
I had to force a modeset by changing the resolution so that the link
training path is executed. However, the link training failure induced a
modeset without any intervention.

-DK


> > -Daniel
> >
> >> 
> >> 
> >> Manasi Navare (2):
> >>   drm: Add a new connector atomic property for link status
> >>   drm/i915: Implement Link Rate fallback on Link training failure
> >> 
> >>  drivers/gpu/drm/drm_atomic.c  | 16 +
> >>  drivers/gpu/drm/drm_atomic_helper.c   | 15 
> >>  drivers/gpu/drm/drm_connector.c   | 52 
> >> +++
> >>  drivers/gpu/drm/i915/intel_dp.c   | 27 ++
> >>  drivers/gpu/drm/i915/intel_dp_link_training.c | 22 ++--
> >>  drivers/gpu/drm/i915/intel_drv.h  |  3 ++
> >>  include/drm/drm_connector.h   | 19 ++
> >>  include/drm/drm_mode_config.h |  5 +++
> >>  include/uapi/drm/drm_mode.h   |  4 +++
> >>  9 files changed, 161 insertions(+), 2 deletions(-)
> >> 
> >> -- 
> >> 2.1.4
> >> 
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[Intel-gfx] [PATCH v3] lib: Add a simple prime number generator

[kbuild test robot]

Hi Chris,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.9 next-20161216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/lib-Add-a-simple-prime-number-generator/20161217-013805
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> lib/prime_numbers.c:220:20: sparse: incompatible types in comparison 
>> expression (different address spaces)

vim +220 lib/prime_numbers.c

   204  return -EINVAL;
   205  }
   206  last = x;
   207  }
   208  
   209  pr_info("selftest(%lu) passed, last prime was %lu", x, last);
   210  return 0;
   211  }
   212  
   213  static int __init primes_init(void)
   214  {
   215  return selftest(selftest_max);
   216  }
   217  
   218  static void __exit primes_exit(void)
   219  {
 > 220  if (primes != _primes)
   221  kfree_rcu((struct primes *)primes, rcu);
   222  }
   223  
   224  module_init(primes_init);
   225  module_exit(primes_exit);
   226  
   227  module_param_named(selftest, selftest_max, ulong, 0400);
   228  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation