[git pull] drm fixes for rc4 or 5

On 29 August 2016 at 07:35, Linus Torvalds wrote: > On Sun, Aug 28, 2016 at 2:31 PM, Linus Torvalds > wrote: >> >> Anyway, the real problem was that this was in my spam-box. Which I've >> learnt to check religiously, so I noticed almost immediately. > > Btw, on a totally unrelated issue: you

[PATCH] drm/amdgpu: Add amdkfd softdep

On 26/08/16 06:16 PM, Michal Marek wrote: > On 2016-08-26 04:20, Michel Dänzer wrote: >> On 26/08/16 02:10 AM, Michal Marek wrote: >>> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that >>> userspace knows that amdgpu needs amdkfd in the initrd. >>> >>> Reported-and-tested-by:

[PATCH] modetest: Adding amdgpu to module list

On 26/08/16 11:52 PM, Alex Deucher wrote: > From: satsahu > > Signed-off-by: Alex Deucher > --- > tests/util/kms.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/util/kms.c b/tests/util/kms.c > index 650b23b..c20134e 100644 > --- a/tests/util/kms.c > +++ b/tests/util/kms.c >

"Fixes" for page flipping under PRIME on AMD & nouveau

On 27/08/16 05:07 AM, Mario Kleiner wrote: > On 08/18/2016 04:32 AM, Michel Dänzer wrote: >> On 18/08/16 08:51 AM, Mario Kleiner wrote: >>> >>> and the offload gpu imports those and renders into them. That saves >>> one extra copy, so should be somewhat more efficient. >> >> Using two shared

"Fixes" for page flipping under PRIME on AMD & nouveau

On 27/08/16 04:57 AM, Mario Kleiner wrote: > On 08/18/2016 04:23 AM, Michel Dänzer wrote: >> On 18/08/16 01:12 AM, Mario Kleiner wrote: > > One thing that confuses me so far is that visual results and measurment > suggest it works nicely, properly serializing the rendering/detiling > blit and

[PATCH v3 1/3] drm/bridge: introduce bridge detaching mechanism

On 08/25/2016 05:46 PM, Daniel Vetter wrote: > On Thu, Aug 25, 2016 at 11:04:32AM +0200, Andrea Merello wrote: >> Up to now, once a bridge has been attached to a DRM device, it cannot >> be undone. >> >> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge, >> because the

[PATCH v3 2/3] drm: simple_kms_helper: make connector optional at init time

On 08/25/2016 02:34 PM, Andrea Merello wrote: > drm_simple_display_pipe_init() pretends to attach a connector > to the display pipe. > > In case a drm bridge has to be used, then it's the bridge that > takes care of connectors. > > This patch makes the connector parameter optional for >

[PATCH v3 3/3] drm: simple_kms_helper: add support for bridges

On 08/25/2016 02:34 PM, Andrea Merello wrote: > Introduce drm_simple_display_pipe_attach_bridge() and > drm_simple_display_pipe_detach_bridge() in order to make it possible to use > drm encoders with the simple display pipes managed by simple_kms_helpers > > Suggested-by: Daniel Vetter >

[Bug 97524] Invalid sampler settings cause full GPU reset

TML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/123304cd/attachment.html>

imx-drm: Possible regression after update to atomic

Hi Thorsten, On Sun, Aug 28, 2016 at 6:17 PM, Thorsten Leemhuis wrote: > Lo! Dave, below report made it to the list of regression for 4.8, but > afaics nothing happened after the initial report. Was it discussed (and > maybe even fixed?) elsewhere? Or is there some reason why it shouldn't > be

drm: WARNING in drm_irq_by_busid

On Sun, Aug 28, 2016 at 01:30:04PM +0200, Dmitry Vyukov wrote: > Hello, > > I've got the following WARNING while running syzkaller fuzzer: This should be fixed in linux-next, can you pls confirm? Also I'm somewhat suprised that syzkaller can't reproduce this reliably, at least in the latest

dri: WARNING in idr_remove

On Sun, Aug 28, 2016 at 04:32:55PM +0200, Dmitry Vyukov wrote: > Hello, > > The following program causes a WARNING in idr_remove: Again under the assumption that you're running this with the vgem driver: linux-next has it fixed. -Daniel > > [ cut here ] > WARNING: CPU:

drm: WARNING in ioremap_wc

On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote: > Hello, > > The following program triggers WARNING in ioremap_wc: Yup, that should also be fixed in linux-next. Probably better to not report more for 4.8-rc kernels for now ;-) If you have some time to test, you need to cherry

[PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy

[PATCH 02/11] drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu before wait

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy

[PATCH 03/11] drm/msm: Remove call to reservation_object_test_signaled_rcu before wait

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy

[PATCH 04/11] drm/nouveau: Remove call to reservation_object_test_signaled_rcu before wait

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy

[PATCH 05/11] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy

[PATCH 06/11] dma-buf: Introduce fence_get_rcu_safe()

This variant of fence_get_rcu() takes an RCU protected pointer to a fence and carefully returns a reference to the fence ensuring that it is not reallocated as it does. This is required when mixing fences and SLAB_DESTROY_BY_RCU - although it serves a more pedagogical function atm Signed-off-by:

[PATCH 07/11] dma-buf: Restart reservation_object_get_fences_rcu() after writes

In order to be completely generic, we have to double check the read seqlock after acquiring a reference to the fence. If the driver is allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then within an RCU grace period a fence may be freed and reallocated. The RCU read side critical

[PATCH 08/11] dma-buf: Restart reservation_object_wait_timeout_rcu() after writes

In order to be completely generic, we have to double check the read seqlock after acquiring a reference to the fence. If the driver is allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then within an RCU grace period a fence may be freed and reallocated. The RCU read side critical

[PATCH 09/11] dma-buf: Restart reservation_object_test_signaled_rcu() after writes

In order to be completely generic, we have to double check the read seqlock after acquiring a reference to the fence. If the driver is allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then within an RCU grace period a fence may be freed and reallocated. The RCU read side critical

[PATCH 10/11] dma-buf: Use seqlock to close RCU race in test_signaled_single

With the seqlock now extended to cover the lookup of the fence and its testing, we can perform that testing solely under the seqlock guard and avoid the effective locking and serialisation of acquiring a reference to the request. As the fence is RCU protected we know it cannot disappear as we

[PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

Currently we install a callback for performing poll on a dma-buf, irrespective of the timeout. This involves taking a spinlock, as well as unnecessary work, and greatly reduces scaling of poll(.timeout=0) across multiple threads. We can query whether the poll will block prior to installing the

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

On Sun, 28 Aug 2016, Andrea Arcangeli wrote: > Skylake was already singled out, but it doesn't cover the XPS 13 L332X > model which is based on IvyBridge. > > The commit that introduced the regression is > 1d6da87a3241deb13d073c4125d19ed0e5a0c62c That's a merge commit, the real one is commit

[PATCH RFC] drm/tilcdc: Write DMA base and ceiling address with single instruction

Write DMA base and ceiling address with a single instruction, if available. This should make it more unlikely that LCDC would fetch the DMA addresses in the middle of an update. Having bad combination of addresses in dma base and ceiling (e.g base > ceiling) can cause unpredictaple behavior in

[PATCH] drm/hisilicon: Don't set drm_device->platformdev

It's deprecated and only should be used by drivers which still use drm_platform_init, not by anyone else. And indeed it's entirely unused and can be nuked. This required a bit more fudging, but I guess kirin_dc_ops really wants to operate on the platform_device, not something else. Also bonus

[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

>Sent: Saturday, August 27, 2016 8:07 PM >To: Tomi Valkeinen ; Tony Lindgren atomide.com>; >Sean Paul ; Peter Chen ; >Andrey Utkin >Cc: David Airlie ; Peter Ujfalusi ti.com>; Dave >Airlie ; Rob Clark ; Dr. H. >Nikolaus >Schaller ; Andrew Bradford ; >kernel at pyra-handheld.com; Discussions

i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

Tried 4.8-rc4 on my i5-2400 PC, got this warning: [ 14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 15.847321] [ cut here ] [ 15.847346] WARNING: CPU: 0 PID: 208 at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write+0x109/0x1f0 [i915] [

[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote: > Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter > of the helper drm_atomic_helper_commit_planes() if the relevant display > controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes > when the CRTC

[PATCH 1/9] drm: Extract drm_encoder.[hc]

Same treatment as before. Only hiccup is drm_crtc_mask, which unfortunately can't be resolved until drm_crtc.h is less of a monster. Untangle the header loop with a forward declaration for that static inline. Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter ---

[PATCH 2/9] drm/doc: Polish kerneldoc for encoders

- Move missing bits into struct drm_encoder docs. - Explain that encoders are 95% internal and only 5% uapi, and that in general the uapi part is broken. - Remove verbose comments for functions not exposed to drivers. v2: Review from Archit: - Appease checkpatch in the moved code. - Make it

[PATCH 3/9] drm: Extract drm_mode_object.[hc]

Just for the struct drm_mode_object base class. The header file was already partially extracted to help untangle the include loops. v2: - Also move the generic get/set property ioctls. At first this seemed like a bad idea since it requires making drm_mode_crtc_set_obj_prop non-static. But

[PATCH 4/9] drm: Remove drm_mode_object->atomic_count

It's only used in drm_mode_object_get_properties, and we can compute it there directly with a bit of code shuffling. Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mode_object.c | 31 --- include/drm/drm_mode_object.h | 2 +- 2

[PATCH 6/9] drm: move drm_mode_legacy_fb_format to drm_fourcc.c

It's part of the drm fourcc handling code, mapping the old depth/bpp values to new fourcc codes. Cc: Laurent Pinchart Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 43 --- drivers/gpu/drm/drm_fourcc.c | 43

[PATCH 8/9] drm: Unify handling of blob and object properties

They work exactly the same now, after the refcounting unification a bit ago. The only reason they're distinct is backwards compat with existing userspace. Cc: Daniel Stone Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_property.c | 23 +--

[PATCH 9/9] drm/doc: Polish docs for drm_property_property_blob

- remove kerneldoc for drm-internal functions - drm_property_replace_global_blob isn't actually atomic, and doesn't need to be. Update docs to match - document all the types and try to link things a bit better - nits all over v2: Appease checkpatch in the moved code (Archit) Reviewed-by:

[PATCH 5/9] drm/doc: Polish docs for drm_mode_object

I figured an overview section here is overkill, and better to just document the 2 structures themselves well enough. v2: Review from Archit: - Appease checkpatch in moved code. - Spelling fixes in the kerneldoc. Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter ---

[PATCH 7/9] drm: Extract drm_property.[hc]

This just contains the base property classes and all the code to handle blobs. I think for any kind of standardized/shared properties it's better to have separate files - this is fairly big already as-is. v2: resurrect misplaced hunk (Daniel Stone) Cc: Daniel Stone Reviewed-by: Archit Taneja

[PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

Am 29.08.2016 um 09:08 schrieb Chris Wilson: > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not > need to handle such conversion in the caller. The only challenge are > those callers that wish to

[Bug 97530] [HD5650][REDWOOD] kernel commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 causing multiple delays during X server start

hments/20160829/71f5e05a/attachment.html>

[Bug 97530] [HD5650][REDWOOD] kernel commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 causing multiple delays during X server start

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/569aafd9/attachment.html>

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > According to basic tests, it looks there is no issue if we don't wait for > DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that, > either. This patch is needed to avoid the annoying warning caused by a > timeout on

[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

On Mon, Aug 29, 2016 at 4:25 PM, Daniel Vetter wrote: > On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote: >> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter >> of the helper drm_atomic_helper_commit_planes() if the relevant display >> controllers(e.g., IPUv3 for

Skylake underruns on 4.8-rc4

My Dell XPS 13 9350 laptop just got a buffer underrun: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun I'm seeing this very occasionally, and they don't come in groups -- I seem to get one underrun with a black flash and that's it. This is with just the laptop

[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

https://bugzilla.kernel.org/show_bug.cgi?id=153121 Kontantin Ivanov changed: What|Removed |Added Severity|low |normal -- You are receiving this

[PATCH v2] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter of the helper drm_atomic_helper_commit_planes() if the relevant display controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes when the CRTC is disabled. The helper would skip the ->atomic_disable call for

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel wrote: > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: >> According to basic tests, it looks there is no issue if we don't wait for >> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that, >> either. This patch is

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu: > On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel > wrote: > > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > >> According to basic tests, it looks there is no issue if we don't wait for > >> DMFC FIFO to clear when disabling

[PATCH 1/2] drm/imx: imx-ldb: detach bridge on unbind

Don't leave the bridge attached to a stale driver instance when unbinding, to allow reattachment on a rebind. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/imx-ldb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c index

[PATCH 2/2] drm/imx: parallel-display: detach bridge or panel on unbind

Don't leave any bridge or panel attached to a stale driver instance when unbinding, to allow reattachment on a rebind. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/parallel-display.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/imx/parallel-display.c

[Bug 97119] screen flickerin under KDE when compositor was dis- and reenabled

e assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/25d8573f/attachment.html>

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel wrote: > Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu: >> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel >> wrote: >> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: >> >> According to basic tests, it looks there is no issue

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

Am Montag, den 29.08.2016, 17:57 +0800 schrieb Ying Liu: > On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel > wrote: > > Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu: > >> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel > >> wrote: > >> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb

[RFC 1/2] gpu: ipu-v3: export memory reset function

Add defines for the memory reset bits and export the memory reset function to IPU modules. Signed-off-by: Philipp Zabel --- drivers/gpu/ipu-v3/ipu-common.c | 17 + drivers/gpu/ipu-v3/ipu-prv.h| 24 2 files changed, 37 insertions(+), 4 deletions(-)

[RFC 2/2] gpu: ipu-v3: reset DMFC memory when disabling

Reset the write FIFO memories after disabling the DMFC to make sure no stale data is kept around. Signed-off-by: Philipp Zabel --- drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

Am Freitag, den 26.08.2016, 17:10 +0100 schrieb Russell King - ARM Linux: > On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote: > > The devicetree documentation states that those are required properties, > > so the driver should refuse to probe if those are absent to be > > consistent.

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > This patch adds active plane reconfiguration support for imx-drm. > This may fixes some mode setting failure issues which were introduced > by imx-drm atomic conversion patch set. The main idea is to disable the > plane in question in

[PATCH 1/5] drm/imx: don't call disable_plane in plane destroy path

Am Donnerstag, den 11.08.2016, 11:18 +0200 schrieb Lucas Stach: > When the destroy path is called the plane should already be > disabled. If not, this is a core bug and should not be worked > around in the driver. > > Signed-off-by: Lucas Stach > --- > drivers/gpu/drm/imx/ipuv3-plane.c | 1 - >

[PATCH] drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y

When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration in which some DRM drivers are built-in, but the framebuffer core is a loadable module. This results in a link error, such as: drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':

[Bug 97249] R290x combined with Mg279q, Dp link fail in ubuntu-multihead setup.

from Vedran Miletić --- Can you try a newer kernel? 4.7 at least. -- 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/20160

[PATCH] drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y

On Mon, Aug 29, 2016 at 02:34:07PM +0200, Arnd Bergmann wrote: > When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration > in which some DRM drivers are built-in, but the framebuffer core is a > loadable module. This results in a link error, such as: > >

[PATCH v2] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

On Mon, Aug 29, 2016 at 05:12:03PM +0800, Liu Ying wrote: > Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter > of the helper drm_atomic_helper_commit_planes() if the relevant display > controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes > when the CRTC

[PATCH v2] amdgpu, radeon: Add amdkfd softdep

Both amdgpu and radeon load amdkfd via symbol_request(). Add a softdep hint so that userspace knows that each of them needs amdkfd in the initrd. Reported-and-tested-by: Martin Jambor [amdgpu] Reported-by: Michel Dänzer [radeon] Signed-off-by: Michal Marek --- v2: Also patch radeon

[PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling

On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote: > drm_kms_helper_poll_enable_locked() should check if we have delayed event > pending and if we have, schedule the work to run without delay. > > Currently the output_poll_work is only scheduled if any of the connectors > have

[PATCH] drm/amdgpu: Add amdkfd softdep

On 2016-08-29 03:37, Michel Dänzer wrote: > On 26/08/16 06:16 PM, Michal Marek wrote: >> It's a soft dependency, so it will be silently ignored. /sbin/modprobe >> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies. > > Thanks for the clarification. > > The radeon driver

[PATCH 9/9] drm/doc: Polish docs for drm_property_property_blob

On 08/29/2016 01:57 PM, Daniel Vetter wrote: > - remove kerneldoc for drm-internal functions > - drm_property_replace_global_blob isn't actually atomic, and doesn't >need to be. Update docs to match > - document all the types and try to link things a bit better > - nits all over >

"Fixes" for page flipping under PRIME on AMD & nouveau

> -Original Message- > From: Michel Dänzer [mailto:michel at daenzer.net] > Sent: Sunday, August 28, 2016 11:17 PM > To: Mario Kleiner > Cc: dri-devel at lists.freedesktop.org; jglisse at redhat.com; > bskeggs at redhat.com; Deucher, Alexander; airlied at redhat.com > Subject: Re: "Fixes"

[Bug 97504] Enabling SDMA on CIK (0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes corruption on a mobile Bonaire with AMDGPU DDX / video desktop recording

part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/2216ebd8/attachment.html>

[PATCH 9/9] drm/doc: Polish docs for drm_property_property_blob

On Mon, Aug 29, 2016 at 06:44:46PM +0530, Archit Taneja wrote: > > > On 08/29/2016 01:57 PM, Daniel Vetter wrote: > > - remove kerneldoc for drm-internal functions > > - drm_property_replace_global_blob isn't actually atomic, and doesn't > >need to be. Update docs to match > > - document all

[PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

i915 sometimes needs to disable planes in the middle of an atomic commit, and then reenable them later in the same commit. Because of this, we can't make the assumption that the state of the plane actually changed. Since the state of the plane hasn't actually changed, neither have it's watermarks.

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel: > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > > This patch adds active plane reconfiguration support for imx-drm. > > This may fixes some mode setting failure issues which were introduced > > by imx-drm atomic conversion

[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes

chives/dri-devel/attachments/20160829/ff05218c/attachment.html>

[Bug 97340] [radeonsi] POSTAL 2 freezes during shader compilation

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160829/4fec402d/attachment.html>

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

On Mon, 29 Aug 2016, Andrea Arcangeli wrote: > On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: >> If it's an Iybridge, there's no low vswing, and that explanation is >> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 >> on an unpatched kernel. > > What I should

[Bug 95308] [radeonsi] Hangs after some minutes on Team Fortress 2

dri-devel/attachments/20160829/5e8abd78/attachment.html>

[Bug 97340] [radeonsi] POSTAL 2 freezes during shader compilation

dri-devel/attachments/20160829/8138f61a/attachment.html>

[PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

On Mon, 29 Aug 2016, Lyude wrote: > i915 sometimes needs to disable planes in the middle of an atomic > commit, and then reenable them later in the same commit. Because of > this, we can't make the assumption that the state of the plane actually > changed. Since the state of the plane hasn't

[Bug 91969] [radeonsi][bonaire] Stalls with Borderlands 2

dri-devel/attachments/20160829/14bd2532/attachment.html>

[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160829/aab84dbb/attachment.html>

[Bug 97513] clover reports wrong device pointer size

was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/78c15ac6/attachment.html>

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

On Mon, Aug 29, 2016 at 4:59 PM, Philipp Zabel wrote: > Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel: >> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: >> > This patch adds active plane reconfiguration support for imx-drm. >> > This may fixes some mode setting failure

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote: > The change adds support of internal HDMI I2C master controller, this > subdevice is used by default, if "ddc-i2c-bus" DT property is omitted. > > The main purpose of this functionality is to support reading EDID from > an HDMI

[PATCH] drm/imx: fix crtc vblank state regression

The atomic conversion lost the notification to let the DRM core know about the current state of the CRTC vblank interrupts. This regressed the ability of the core to reject page flip attempts on currently disabled CRTCs. Add back the notifications. Signed-off-by: Lucas Stach ---

[PATCH v3] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

i915 sometimes needs to disable planes in the middle of an atomic commit, and then reenable them later in the same commit. Because of this, we can't make the assumption that the state of the plane actually changed. Since the state of the plane hasn't actually changed, neither have it's watermarks.

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

Hi all, On 24 August 2016 at 06:46, Vladimir Zapolskiy wrote: > MODULE_AUTHOR("Sascha Hauer "); > MODULE_AUTHOR("Andy Yan "); > MODULE_AUTHOR("Yakir Yang "); > +MODULE_AUTHOR("Vladimir Zapolskiy "); Don't meant to start a flame-war or alike but to educate myself: Where does one draw the line

[PATCH] drm/ttm: Use RCU for ttm_mem_type_manager.move fence

The ttm_mem_type_manager.move tracks the fence for the last migration on the memory manager. Currently it is accessed under its own spinlock to ensure that the fence doesn't disappear from underneath it. We can translate the reader to acquire a reference to the fence using fence_get_rcu_safe()

[PATCH] drm/ttm: Use RCU for ttm_mem_type_manager.move fence

Am 29.08.2016 um 18:57 schrieb Chris Wilson: > The ttm_mem_type_manager.move tracks the fence for the last migration on > the memory manager. Currently it is accessed under its own spinlock to > ensure that the fence doesn't disappear from underneath it. We can > translate the reader to acquire a

[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes

hments/20160829/11ad4aef/attachment-0001.html>

[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)

If we being polled with a timeout of zero, a nonblocking busy query, we don't need to install any fence callbacks as we will not be waiting. As we only install the callback once, the overhead comes from the atomic bit test that also causes serialisation between threads. Signed-off-by: Chris

[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)

Hi Chris, 2016-08-29 Chris Wilson : > If we being polled with a timeout of zero, a nonblocking busy query, > we don't need to install any fence callbacks as we will not be waiting. > As we only install the callback once, the overhead comes from the atomic > bit test that also causes

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

Hi Emil, On 08/29/2016 07:41 PM, Emil Velikov wrote: > Hi all, > > On 24 August 2016 at 06:46, Vladimir Zapolskiy > wrote: > >> MODULE_AUTHOR("Sascha Hauer "); >> MODULE_AUTHOR("Andy Yan "); >> MODULE_AUTHOR("Yakir Yang "); >> +MODULE_AUTHOR("Vladimir Zapolskiy "); > Don't meant to start a

[Bug 117581] Celsius H265: suspend does not bring up console unless no_console_suspend is given

https://bugzilla.kernel.org/show_bug.cgi?id=117581 --- Comment #7 from Elmar Stellnberger --- I guess it would already be resolved but Bug 155511 inhibits me from testing that out correctly. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 92912] Full GPU lockups in TF2 - R600

nown about it... ;-). The base OS was Fedora 24/x86_64 with LLVM 3.8.0. -- 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/20160829/1e187f11/attachment.html>

[PATCH 0/4] Backported vlv fixes for 4.7.y

drm/i915/vlv: Make intel_crt_reset() per-encoder: 4570d833390b10043d082fe535375d4a0e071d9c drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init(): 4c732e6ee9e71903934d75b12a021eb3520b6197 drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug(): 21842ea84f161ae37ba25f0250c377fd19c5b307

[GIT PULL] drm-vc4-fixes-2016-08-29

Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: https://github.com/anholt/linux drm-vc4-fixes-2016-08-29 for you to fetch changes up to 552416c146fadc67cd9b53ef7adf88d3381c43a6: drm/vc4: Fix oops when userspace hands in a bad BO. (2016-08-19 19:17:39

[GIT PULL] drm-vc4-next-2016-08-29

Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: https://github.com/anholt/linux tags/drm-vc4-next-2016-08-29 for you to fetch changes up to 67f13690f447841fb3d2f952a6e49b2b28ae379b: drm/vc4: Don't force new binner overflow allocation per draw.

[PATCH 0/4 v2] Audio support for adv7511 hdmi bridge

This is another swing at getting the adv7511 hdmi bridge audio support reviewed. I've taken the core audio work done by Lars-Peter Clausen, and adapted by Srinivas Kandagatla and Archit Taneja, and tried to rework it to use the hdmi-codec sound driver. This patchset, along with the i2s driver

[PATCH 1/4 v2] drm/bridge: adv7511: Move the common data structures to header file

From: Archit Taneja This patch moves the adv7511 data structure to header file so that the audio driver file could use it. Cc: David Airlie Cc: Archit Taneja Cc: Laurent Pinchart Cc: Wolfram Sang Cc: Srinivas Kandagatla Cc:

[PATCH 3/4 v2] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

From: Srinivas Kandagatla This patch enables the Audio Data and Clock pads to the adv7533 bridge. Without this patch audio can not be played. Cc: David Airlie Cc: Archit Taneja Cc: Laurent Pinchart Cc: Wolfram Sang Cc:

  1   2   >