[Bug 76490] Hang during boot when DPM is on (R9 270X)

e bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/343a02bf/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

tages change at once (or maybe it's just the memory reclocking?). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/4c5100b7/attachment.html>

__i915_spin_request() sucks

On Thu, Nov 12, 2015 at 01:40:33PM -0700, Jens Axboe wrote: > On 11/12/2015 01:36 PM, Jens Axboe wrote: > >Hi, > > > >So a few months ago I got an XPS13 laptop, the one with the high res > >screen. GUI performance was never really that great, I attributed it to > >coming from a more powerful laptop

[Bug 92907] ARB_copy_image breaks recording with obs-studio

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/d1c65cca/attachment.html>

[PATCH v2 8/8] drm/i915: Give meaningful names to all the planes

From: Ville Syrjälä Let's name our planes in a way that makes sense wrt. the spec: - skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc. - g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc. - pre-g4x -> "plane A", "cursor B" etc. v2: Rebase on top of the fixed/cleaned error

[PATCH 7/8] drm/i915: Don't leak primary/cursor planes on crtc init failure

From: Ville Syrjälä Call intel_plane_destroy() instead of drm_plane_cleanup() so that we also free the plane struct itself when bailing out of the crtc init. And make intel_plane_destroy() NULL tolerant to avoid having to check for it in the caller. Signed-off-by: Ville Syrjälä --- driver

[PATCH 6/8] drm/i915: Fix plane init failure paths

From: Ville Syrjälä Deal with errors from drm_universal_plane_init() in primary and cursor plane init paths (sprites were already covered). Also make the code neater by using goto for error handling. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 64 +++

[PATCH v2 5/8] drm/i915: Set crtc->name to "pipe A", "pipe B", etc.

From: Ville Syrjälä v2: Fix intel_crtc leak on failure to allocate the name Use a local 'name' variable to make things easier Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a

[PATCH 4/8] drm/i915: Use plane->name in debug prints

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 38 +--- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9845687..b6

[PATCH 3/8] drm/i915: Use crtc->name in debug messages

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 55 drivers/gpu/drm/i915/intel_fbdev.c | 5 ++-- 2 files changed, 33 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drive

[PATCH 2/8] drm: Add plane->name and use it in debug prints

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 12 ++-- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- drivers/gpu/drm/drm_crtc.c | 3 +++ include/drm/drm_crtc.h | 2 ++ 4 files changed, 13 insertions(+), 8 deletion

[PATCH 1/8] drm: Add crtc->name and use it in debug messages

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 41 ++- drivers/gpu/drm/drm_atomic_helper.c | 56 +++-- drivers/gpu/drm/drm_crtc.c | 8 -- drivers/gpu/drm/drm_crtc_helper.c | 2

[PATCH v2 0/8] drm: Give crtcs and planes actual names (v2)

From: Ville Syrjälä OK, so another attempt. This time the error handling and cleanup should be more solid. Previus attempt was at http://lists.freedesktop.org/archives/dri-devel/2015-November/094331.html I pushed v2 to: git://github.com/vsyrjala/linux.git crtc_plane_name_2 Ville Syrjälä (8

[PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.

On Thu, Nov 12, 2015 at 4:42 AM, Liviu Dudau wrote: > On Wed, Nov 11, 2015 at 12:48:50PM -0600, Rob Herring wrote: >> On Wed, Nov 11, 2015 at 04:06:47PM +, Liviu Dudau wrote: >> > Cc: Rob Herring >> > Cc: Pawel Moll >> > Cc: Mark Rutland >> > Cc: Ian Campbell >> > Cc: Kumar Gala >> > >> >

[Intel-gfx] [PATCH 6/6] drm/i915: Give meaningful names to all the planes

On Thu, Nov 12, 2015 at 07:49:19PM +0200, Ville Syrjälä wrote: > On Thu, Nov 12, 2015 at 05:38:48PM +, Emil Velikov wrote: > > Hi Ville, > > > > On 12 November 2015 at 16:52, wrote: > > > From: Ville Syrjälä > > > > > > Let's name our planes in a way that makes sense wrt. the spec: > >

[Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4

On 12.11.2015 14:48, Thierry Reding wrote: > On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote: >> On 10.11.2015 17:25, Mario Kleiner wrote: >>> On 11/10/2015 05:00 PM, Thierry Reding wrote: On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote: > From: Daniel Vetter >

[PATCH 6/6] drm/i915: Give meaningful names to all the planes

On Thu, Nov 12, 2015 at 05:38:48PM +, Emil Velikov wrote: > Hi Ville, > > On 12 November 2015 at 16:52, wrote: > > From: Ville Syrjälä > > > > Let's name our planes in a way that makes sense wrt. the spec: > > - skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc. > > - g4x+ -> "pr

[PATCH 0/9] uapi: drm: fixes for userspace compilation

Hi Gabriel, Interestingly enough we had a person (gaby) asking about this over at #dri-devel, and I forwarded him to the work of Mikko Rapeli. You don't happen to be that person do you ? On 12 November 2015 at 18:14, Gabriel Laskar wrote: > Public headers should use types from include/uapi/linux

[PATCH 9/9] include/uapi/drm/omap_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/omap_drm.h | 39 --- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h index 1d0b117..926e42a 100

[PATCH 8/9] include/uapi/drm/vmwgfx_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/vmwgfx_drm.h | 264 +- 1 file changed, 132 insertions(+), 132 deletions(-) diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h index 05b2049.

[PATCH 7/9] include/uapi/drm/drm_mode.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/drm_mode.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 6c11ca4..44ad794 100644 --- a/include/uapi/dr

[PATCH 6/9] include/uapi/drm/armada_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/radeon_drm.h | 130 +- 1 file changed, 66 insertions(+), 64 deletions(-) diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h index 01aa2a8..8

[PATCH 5/9] include/uapi/drm/amdgpu_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/amdgpu_drm.h | 292 +- 1 file changed, 147 insertions(+), 145 deletions(-) diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h index e52933a.

[PATCH 4/9] include/uapi/drm/nouveau_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/nouveau_drm.h | 84 +- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h index fd594cc.

[PATCH 3/9] include/uapi/drm/qxl_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/qxl_drm.h | 74 +++--- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/include/uapi/drm/qxl_drm.h b/include/uapi/drm/qxl_drm.h index ebebd36..2aa6376

[PATCH 2/9] include/uapi/drm/virtgpu_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/virtgpu_drm.h | 99 +- 1 file changed, 50 insertions(+), 49 deletions(-) diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h index fc9e2d6.

[PATCH 1/9] include/uapi/drm/armada_drm.h: use __u{32, 64} types instead of uint{32, 64}_t

Kernel headers should use linux/types.h Signed-off-by: Gabriel Laskar --- include/uapi/drm/armada_drm.h | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/include/uapi/drm/armada_drm.h b/include/uapi/drm/armada_drm.h index 8dec3fd..77184b7 100644 --- a

[PATCH 0/9] uapi: drm: fixes for userspace compilation

Public headers should use types from include/uapi/linux/types.h. This series fixes that, and allow out-of-the-box compilation of thoses headers from userspace. Some programs need to parse and use these headers, in order to gather informations about the public kernel API, for example strace genera

[Bug 92900] [regression bisected] About 700 piglit regressions is what could go wrong

t; > > on it. Thanks for testing! Patches sent. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/dd8cc708/attachment.html>

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

On 2015年11月12日 18:34, Liviu Dudau wrote: > Can you switch your email client to text mode and make it do proper reply > quoting? It is > rather difficult to follow where your reply comes when you don't use HTML > MUAs. > > Best regards, > Liviu Hi Liviu I'm sorry about that, now I switc

[PATCH 6/6] drm/i915: Give meaningful names to all the planes

From: Ville Syrjälä Let's name our planes in a way that makes sense wrt. the spec: - skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc. - g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc. - pre-g4x -> "plane A", "cursor B" etc. Signed-off-by: Ville Syrjälä --- drivers/

[PATCH 5/6] drm/i915: Set crtc->name to "pipe A", "pipe B", etc.

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b628dab..2b5e81a 100644 --- a/drive

[PATCH 4/6] drm/i915: Use plane->name in debug prints

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 38 +--- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9845687..b6

[PATCH 3/6] drm/i915: Use crtc->name in debug messages

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 55 drivers/gpu/drm/i915/intel_fbdev.c | 5 ++-- 2 files changed, 33 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drive

[PATCH 2/6] drm: Add plane->name and use it in debug prints

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 12 ++-- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- drivers/gpu/drm/drm_crtc.c | 3 +++ include/drm/drm_crtc.h | 2 ++ 4 files changed, 13 insertions(+), 8 deletion

[PATCH 1/6] drm: Add crtc->name and use it in debug messages

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 41 ++- drivers/gpu/drm/drm_atomic_helper.c | 56 +++-- drivers/gpu/drm/drm_crtc.c | 8 -- drivers/gpu/drm/drm_crtc_helper.c | 2

[PATCH 0/6] drm: Give crtcs and planes actual names

From: Ville Syrjälä I got sick and tired of staring at the line noise produced by drm.debug=0x1e, so I decided to give the crtcs and planes human readable names. Each driver can give whatever names it wants, and for i915 I gave something that makes some sense w.r.t. to the spec. The only magic

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

On 2015年11月12日 18:36, Liviu Dudau wrote: > On Thu, Nov 12, 2015 at 04:32:33PM +0800, Mark yao wrote: >> On 2015年11月10日 23:01, Liviu Dudau wrote: >> >> Hello, >> >> When booting my Juno board with the HDLCD driver that I have converted to >> atomic operations I'm getting the fo

[Bug 92923] SGPR spilling

the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/719bd96a/attachment.html>

[Bug 92923] SGPR spilling

re the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/226d5448/attachment-0001.html>

[PATCH i915 v3 2/2] i915: wait for fence in prepare_plane_fb

In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for fence. Signed-off-by: Alex Goins --- drivers/gpu/drm/i915/intel_display.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index acec108a..36c558

[PATCH i915 v3 1/2] i915: wait for fences in mmio_flip()

If a buffer is backed by dmabuf, wait on its reservation object's fences before flipping. Signed-off-by: Alex Goins --- drivers/gpu/drm/i915/intel_display.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display

[PATCH i915 v3 0/2] PRIME Synchronization

Hello all, For a while now, I've been working to fix tearing with PRIME. This is my third version of the solution, revised according to Chris Wilson and Maarten Lankhorst's suggestions to remove the unnecessary lock on object_name_lock and to move fence waiting from intel_atomic_commit() to intel_

[PATCH 6/6] drm/i915: Give meaningful names to all the planes

Hi Ville, On 12 November 2015 at 16:52, wrote: > From: Ville Syrjälä > > Let's name our planes in a way that makes sense wrt. the spec: > - skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc. > - g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc. > - pre-g4x -> "plane A", "

[PATCH v9 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

On Thu, Nov 12, 2015 at 09:27:21AM +0800, Yakir Yang wrote: > Hi Rob, > > On 11/12/2015 07:10 AM, Rob Herring wrote: > >On Fri, Oct 30, 2015 at 09:09:15AM +0800, Yakir Yang wrote: > >>Some edp screen do not have hpd signal, so we can't just return > >>failed when hpd plug in detect failed. > >> >

[RESEND] drm/rockchip: Fix module autoload for OF platform driver

From: Luis de Bethencourt This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt --- Hi, This is a Resend of a patch from 20 Oct [0] I am adding Andrew Morton to the CC list as was

[RESEND] drm: imx: imx-tve: Fix module autoload for OF platform driver

From: Luis de Bethencourt This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt --- Hi, This is a Resend of a patch from 20 Oct [0] I am adding Andrew Morton to the CC list as was

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

because at that point the core will have reset connector->encoder to NULL as part of tearing down the pipeline. To corroborate that, the Tegra driver doesn't trigger this WARN_ON() and also never sets up the connector->encoder manually. The same is probably true for many other drivers that have already been converted. That said, from a brief look it seems like many more drivers get this wrong and may run into this WARN when they get converted to atomic. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/0ed8a97c/attachment.sig>

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

gt; > >> > > > >> -- > > > >> ï¼­ark Yao > > > Hi Liviu > > > drivers/gpu/drm/i2c/tda998x_drv.c do the same things: > > > priv->connector.encoder = &priv->encoder; > > > drm_mode_connector_attach_encoder(&priv->connector, &priv->encoder); > > > > > > I believe must be same problem. > > > > Oh, I hadn't noticed this subthread, but you came to the same conclusion > > as I did. I have the below local change, which I think might be good to > > have given that there are at least two drivers that got this wrong. > > > > Thierry > > > > --- >8 --- > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index 24c5434abd1c..56d53106b32d 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > @@ -4983,6 +4983,20 @@ int drm_mode_connector_attach_encoder(struct > > drm_connector *connector, > > { > > int i; > > > > + /* > > +* In the past, drivers have attempted to model the static association > > +* of connector to encoder in simple connector/encoder devices using a > > +* direct assignment of connector->encoder = encoder. This connection > > +* is a logical one and the responsibility of the core, so drivers are > > +* expected not to mess with this. > > +* > > +* Note that the error return should've been enough here, but a large > > +* majority of drivers ignores the return value, so add in a big WARN > > +* to get people's attention. > > +*/ > > + if (WARN_ON(connector->encoder)) > > + return -EINVAL; > > + > > for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { > > if (connector->encoder_ids[i] == 0) { > > connector->encoder_ids[i] = encoder->base.id; > > Hi Thierry, > > This patch together with your tda998x proposed patch should solve > nicely the problem we are detecting, as long as no one calls > drm_connector_get_encoder() before drm_crtc_helper_set_config(). The only caller of drm_connector_get_encoder() is drm_mode_getconnector() and that handles the NULL case gracefully, so I don't think there are any issues. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/0f5fd474/attachment.sig>

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

On Thu, Nov 12, 2015 at 05:12:33PM +0100, Thierry Reding wrote: > On Thu, Nov 12, 2015 at 02:03:35PM +, Liviu Dudau wrote: > > On Thu, Nov 12, 2015 at 02:34:11PM +0100, Thierry Reding wrote: > > > On Thu, Nov 12, 2015 at 06:49:38PM +0800, Mark yao wrote: > > > > On 2015年11月12日 18:36, Livi

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

- hdmi->connector.encoder = encoder; +// hdmi->connector.encoder = encoder; drm_mode_connector_attach_encoder(&hdmi->connector, encoder); I found some other drivers set connector.encoder before drm_mode_connector_attach_encoder, some are not. drm_mode_connector_attach_encoder already describe the link of connector and encoder, so I think "connector.encoder = encoder" is not needed, is that right? Thanks. -- ï¼­ark Yao -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/5ddae3e6/attachment.html>

[PATCH 10/25] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

Hi Marek, 2015-11-10 Marek Szyprowski : > DMA address is a framebuffer attribute and the right place for it is > exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces > helper function for getting dma address of the given framebuffer. > > Signed-off-by: Marek Szyprowski > ---

[PATCH 06/25] drm/exynos: fix to calculate offset of each plane for ipp fimc

Hello, Marek Szyprowski wrote: > From: Seung-Woo Kim > > NV12 and YUV420 formats are need to calculate offset of each plane > for ipp fimc in a gem buffer. Without proper offset, only Y plane > can be processed, so result shows green frame. > This patch fixes to calculate offset for cbcr plane

[PATCH 18/25] drm/exynos: fimd: fix dma burst size setting for small plane size

This one looks a bit strange. It only changes the argument list of fimd_win_set_pixfmt() but the commit message that it actually fixes something. The corresponding upstream commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66367461e573321f0fbb0be0391165b5a54d5fe4

[PATCH 09/25] drm/exynos: exynos7-decon: remove excessive check

Hi Marek, 2015-11-10 Marek Szyprowski : > Display area is already checked by exynos plane core, so there is no > need for such check in driver code. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 10 -- > 1 file changed, 10 deletions(-) Review

[PATCH 08/25] drm/exynos: rotator: convert to common clock framework

Hi Marek, 2015-11-10 Marek Szyprowski : > This driver was not used after introduction of common clock framework. > This patch adds missing prepare/unprepare calls and allows to use it > again with current kernel code. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_dr

[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem

Hey Daniel, Daniel Stone wrote: > Hi, > > On 12 November 2015 at 12:44, Tobias Jakobi > wrote: >> Daniel Stone wrote: >>> On 10 November 2015 at 13:23, Marek Szyprowski >> samsung.com> wrote: This patch series introduces a new life into Exynos IPP (Image Post Processing) subsystem by

[PATCH] drm/tegra: fix locking of SET_TILING ioctl

drm_gem_object_unreference() now expects obj->dev->struct_mutex to be held. Use the newly-introduced drm_gem_object_unreference_unlocked() which handles locking for us. If we don't do this drm_gem_object_unreference() will get noisy about struct_mutex not being held every time we call the SET_TILI

__i915_spin_request() sucks

On 11/12/2015 03:52 PM, Jens Axboe wrote: > On 11/12/2015 03:19 PM, Chris Wilson wrote: So today, I figured I'd try just killing that spin. If it fails, we'll punt to normal completions, so easy change. And wow, MASSIVE difference. I can now scroll in chrome and not rage! It's l

__i915_spin_request() sucks

On 11/12/2015 03:19 PM, Chris Wilson wrote: >>> So today, I figured I'd try just killing that spin. If it fails, we'll >>> punt to normal completions, so easy change. And wow, MASSIVE difference. >>> I can now scroll in chrome and not rage! It's like the laptop is 10x >>> faster now. >>> >>> Ran gi

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #12 from Alex Deucher --- (In reply to Aneroid from comment #11) > May be the root of that problem is that Radeon HD 8970M is not a Pitcairn > card ? > > It is a Neptune XT, some kind of mobile version: > http://www.techpowerup.com/g

[PATCH 18/25] drm/exynos: fimd: fix dma burst size setting for small plane size

Hey Tobias, On 12 November 2015 at 15:17, Tobias Jakobi wrote: > This one looks a bit strange. It only changes the argument list of > fimd_win_set_pixfmt() but the commit message that it actually fixes > something. > > The corresponding upstream commit: > https://git.kernel.org/cgit/linux/kernel/

[PATCH] drm/exynos: only run atomic_check() if crtc is active

ing. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/06f9101b/attachment.sig>

[Bug 92850] Segfault loading War Thunder

HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/4a77a23c/attachment.html>

[Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4

buildID=695636 > https://patchwork.kernel.org/patch/7591531/mbox This doesn't look at all related and has probably been an issue for quite some time. I /think/ this happens because memory is allocated from the non-DMA pool (i.e. using alloc_page()) and then ends up getting run through the dma_sync_*() API for cache maintenance. But the assumption is that you can only do cache maintenance by the dma_sync_*() API on memory allocated by dma_alloc_*(), hence the warning. There was some discussion about this a while ago, and there was some conclusion that an API was needed to do cache maintenance on non-DMA- allocated pages of memory, but I don't think any work happened towards that API. Adding Alex and Arnd who had been part of that discussion, though possibly in different threads. Guys, I've been doing too many unrelated things lately it seems, because I can't remember where exactly we left off. I vaguely remember that at some point somebody (maybe Russell) had objected to adding such a non-DMA cache-maintenance API, but I can't find a link to the relevant threads. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/b2802904/attachment.sig>

[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem

Hi, On 12 November 2015 at 12:44, Tobias Jakobi wrote: > Daniel Stone wrote: >> On 10 November 2015 at 13:23, Marek Szyprowski >> wrote: >>> This patch series introduces a new life into Exynos IPP (Image Post >>> Processing) subsystem by integrating it (transparently for userspace >>> applicati

[Bug 92850] Segfault loading War Thunder

the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/1228ed61/attachment.html>

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #11 from Aneroid --- May be the root of that problem is that Radeon HD 8970M is not a Pitcairn card ? It is a Neptune XT, some kind of mobile version: http://www.techpowerup.com/gpudb/1966/radeon-hd-8970m.html -- You are receiving

[Bug 92850] Segfault loading War Thunder

the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/cb25d5ee/attachment.html>

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

l current connectors for [CRTC:20] to ee38ebc0 [1.300117] [drm:drm_atomic_connectors_for_crtc] State ee38ebc0 has 1 connectors for [CRTC:20] [1.300130] [drm:drm_atomic_commit] commiting ee38ebc0 [1.300156] WARNING: CPU: 0 PID: 26 at drivers/gpu/drm/drm_atomic_helper.c:674 drm_atomic_helper_update_legacy_modeset_state+0x3c/0x1f8() -- ï¼­ark Yao -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/3b3de8a1/attachment-0001.html>

[PATCH] drm: Don't oops in drm_calc_timestamping_constants() if drm_vblank_init() wasn't called

From: Ville Syrjälä Seems the crtc helpers call drm_calc_timestamping_constants() unconditionally even if the driver didn't initialize vblank support by calling drm_vblank_init(). That used to be OK since the constants were stored under drm_crtc. However I broke this with commit eba1f35dfe14 (

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

he below local change, which I think might be good to have given that there are at least two drivers that got this wrong. Thierry --- >8 --- diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 24c5434abd1c..56d53106b32d 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -4983,6 +4983,20 @@ int drm_mode_connector_attach_encoder(struct drm_connector *connector, { int i; + /* +* In the past, drivers have attempted to model the static association +* of connector to encoder in simple connector/encoder devices using a +* direct assignment of connector->encoder = encoder. This connection +* is a logical one and the responsibility of the core, so drivers are +* expected not to mess with this. +* +* Note that the error return should've been enough here, but a large +* majority of drivers ignores the return value, so add in a big WARN +* to get people's attention. +*/ + if (WARN_ON(connector->encoder)) + return -EINVAL; + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { if (connector->encoder_ids[i] == 0) { connector->encoder_ids[i] = encoder->base.id; -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/ec66b2b8/attachment-0001.sig>

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

(ret_from_fork+0x14/0x3c) I can't found who can set encoder->crtc value before atomic_commit, what's going wrong? -- ï¼­ark Yao -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/ee9c93d3/attachment.html>

DRM i2c module or bridge ?

e start. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/fa58afd1/attachment.sig>

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

On Thu, Nov 12, 2015 at 02:34:11PM +0100, Thierry Reding wrote: > On Thu, Nov 12, 2015 at 06:49:38PM +0800, Mark yao wrote: > > On 2015年11月12日 18:36, Liviu Dudau wrote: > > >On Thu, Nov 12, 2015 at 04:32:33PM +0800, Mark yao wrote: > > >>On 2015年11月10日 23:01, Liviu Dudau wrote: > >

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

On Thu, Nov 12, 2015 at 01:16:55PM +0100, Thierry Reding wrote: > On Wed, Nov 11, 2015 at 04:09:42PM +, Liviu Dudau wrote: > > On Tue, Nov 10, 2015 at 05:56:15PM +0100, Thierry Reding wrote: > > > On Tue, Nov 10, 2015 at 03:01:03PM +, Liviu Dudau wrote: > > > > Hello, > > > > > > > > When

DRM i2c module or bridge ?

On 12 November 2015 at 13:18, Thierry Reding wrote: > On Thu, Nov 12, 2015 at 12:48:51PM +, Emil Velikov wrote: >> Hello Thierry, all, >> >> Inspired by a recent discussion I was started wondering - where is the >> cut between DRM i2c modules (most of which encoders/transmitters) and >> bridg

[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem

Hello, Daniel Stone wrote: > Hi Marek, > > On 10 November 2015 at 13:23, Marek Szyprowski > wrote: >> This patch series introduces a new life into Exynos IPP (Image Post >> Processing) subsystem by integrating it (transparently for userspace >> applications) with Exynos DRM core plane manageme

__i915_spin_request() sucks

On 11/12/2015 01:36 PM, Jens Axboe wrote: > Hi, > > So a few months ago I got an XPS13 laptop, the one with the high res > screen. GUI performance was never really that great, I attributed it to > coming from a more powerful laptop, and the i915 driving a lot of > pixels. But yesterday I browsed fr

__i915_spin_request() sucks

Hi, So a few months ago I got an XPS13 laptop, the one with the high res screen. GUI performance was never really that great, I attributed it to coming from a more powerful laptop, and the i915 driving a lot of pixels. But yesterday I browsed from my wife's macbook, and was blown away. Wow, sc

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

drm_connector_init(drm, &hdmi->connector, &dw_hdmi_connector_funcs, DRM_MODE_CONNECTOR_HDMIA); - hdmi->connector.encoder = encoder; - drm_mode_connector_attach_encoder(&hdmi->connector, encoder); return 0; -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/799ea424/attachment.sig>

[PATCHv10 16/16] cobalt: add cec support

From: Hans Verkuil Add CEC support to the cobalt driver. Signed-off-by: Hans Verkuil --- drivers/media/pci/cobalt/Kconfig | 1 + drivers/media/pci/cobalt/cobalt-driver.c | 108 +- drivers/media/pci/cobalt/cobalt-driver.h | 2 + drivers/media/pci/cobalt/cobal

[PATCHv10 15/16] cec: s5p-cec: Add s5p-cec driver

From: Kamil Debski Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- .../devicetree/bindings/media/s5p-cec.txt

[PATCHv10 14/16] cec: adv7511: add cec support.

From: Hans Verkuil Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- drivers/media/i2c/adv7511.c | 364 +

[PATCHv10 13/16] cec: adv7842: add cec support

From: Hans Verkuil Add CEC support to the adv7842 driver. Signed-off-by: Hans Verkuil --- drivers/media/i2c/adv7842.c | 255 +--- 1 file changed, 238 insertions(+), 17 deletions(-) diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c i

[PATCHv10 12/16] cec: adv7604: add cec support.

From: Hans Verkuil Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: add missing methods cec/io_write_and_or] [k.debski at samsung.com: change adv7604 to adv76xx in adde

[PATCHv10 11/16] v4l2-subdev: add HDMI CEC ops

From: Hans Verkuil Add CEC callbacks to the new v4l2_subdev_cec_ops struct. These are the low-level CEC ops that subdevs that support CEC have to implement. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski

[PATCHv10 10/16] DocBook/media: add CEC documentation

From: Hans Verkuil Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add documentation for passthrough mode] [k.debski at samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Do

[PATCHv10 09/16] cec.txt: add CEC framework documentation

Document the new HDMI CEC framework. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/cec.txt | 326 ++ 1 file changed,

[PATCHv10 08/16] cec: add compat32 ioctl support

From: Hans Verkuil The CEC ioctls didn't have compat32 support, so they returned -ENOTTY when used in a 32 bit application on a 64 bit kernel. Since all the CEC ioctls are 32-bit compatible adding support for this API is trivial. Signed-off-by: Hans Verkuil --- fs/compat_ioctl.c | 19

[PATCHv10 07/16] cec: add HDMI CEC framework

The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: Merged Update author commit by Hans Verkuil] [k.debski at samsung.com: change kthread h

[PATCHv10 06/16] rc: Add HDMI CEC protocol handling

From: Kamil Debski Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski Signed-off-by: Hans V

[PATCHv10 05/16] HID: add HDMI CEC specific keycodes

From: Kamil Debski Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- include/uapi/linux/input.h | 28 1 file changed, 28 insertions(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linu

[PATCHv10 04/16] input.h: add BUS_CEC type

From: Hans Verkuil Inputs can come in over the HDMI CEC bus, so add a new type for this. Signed-off-by: Hans Verkuil Acked-by: Dmitry Torokhov --- include/uapi/linux/input.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 73141

[PATCHv10 03/16] dts: exynos4412-odroid*: enable the HDMI CEC device

From: Kamil Debski Add a dts node entry and enable the HDMI CEC device present in the Exynos4 family of SoCs. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 1 file changed, 4 insertions(+) d

[PATCHv10 02/16] dts: exynos4: add node for the HDMI CEC device

From: Kamil Debski This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boo

[PATCHv10 01/16] dts: exynos4*: add HDMI CEC pin definition to pinctrl

From: Kamil Debski Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and Exynos4x12 SoCs. These are required by the HDMI CEC device. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++ arch

[PATCHv10 00/16] HDMI CEC framework

Hi all, The tenth version of this patchset addresses comments I received from Russell King and various bug fixes and enhancements as the result of more testing. The cec.txt has been updated, but before I can make the final version there are three areas that I want to look at more closely: 1) Wha

drm: Bogus WARN() in drm_atomic_helper_update_legacy_modeset_state() ?

attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151112/c49e1dac/attachment.sig>

[PATCH 04/25] drm/exynos: gsc: fix wrong pm_runtime state

Hi Marek, 2015-11-10 Marek Szyprowski : > From: Seung-Woo Kim > > At probe time, gsc clock is not enabled, so pm_runtime state should > be deactive. So this patch removes pm_runtime_set_active() from > gsc_probe(). > > Signed-off-by: Seung-Woo Kim > Signed-off-by: Marek Szyprowski > --- > d

  1   2   >