[Bug 66963] Rv6xx dpm problems

but without dpm. -- 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/20141105/67bfc131/attachment.html>

[PATCH] drm/atomic-helper: implementatations for legacy interfaces

On Wed, Nov 05, 2014 at 02:48:48PM -0500, Sean Paul wrote: > > + if (!crtc && crtc != set->crtc) > > I think this should be an || Hm. My idea idea was actually something along the lines of diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index

[PATCH 10/17] drm: Atomic crtc/connector updates using crtc/plane helper interfaces

I've applied all the other nits, replies to the more interesting bits below. On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote: > On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote: > > + if (new_encoder != connector_state->best_encoder) { > > nit: If you just returned early

Bug#768157: machine hangs when loading cirrus with modeset=1 while booted with vga=791

A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 811 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/50d0a3a2/attachment.sig>

[PATCH V2 1/2] imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly difference, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width), 4K support(imx6 doesn't support 4k, but

[PATCH V2 2/2] move imx-hdmi to bridge/dw-hdmi

the original imx hdmi driver is under staging/imx-drm, which depends on imx-drm, so move the imx hdmi drvier out to drm/bridge and rename imx-hdmi to dw-hdmi Signed-off-by: Andy Yan --- drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile

[PATCH 1/2] imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly difference, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width), 4K support(imx6 doesn't support 4k, but

[PATCH V2 0/2] make imx hdmi publicly used by dw hdmi compatible platform

We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly difference, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only access by

exynos-drm registration: infinite loop

2014-11-05 17:38 GMT+03:00 Thierry Reding : > On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote: >> Hi, >> >> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM >> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is >> set to 'y'. >> The issue

[PATCH 6/7] drm/rcar: gem: dumb: pitch is an output

Hi Thierry, Thank you for the patch. On Wednesday 05 November 2014 14:25:18 Thierry Reding wrote: > From: Thierry Reding > > When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB > IOCTL, only the width, height, bpp and flags fields are inputs. The > caller is not guaranteed

[PATCH] drm/exynos: add has_vtsel flag

The exynos fimd provides video type selection bits from system register but exynos3 series don't has it, so needs has_vtsel flag and we can distinguish whether set video type selection bits. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +- 1 file changed, 5

[PATCH] drm/exynos: add has_vtsel flag

The exynos fimd provides video type selection bits from system register but exynos3 series don't has it, so needs has_vtsel flag and we can distinguish whether set video type selection bits. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +- 1 file changed, 5

[Bug 87791] radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 --- Comment #3 from aCaB --- (In reply to Alex Deucher from comment #2) > This sounds like a mesa regression rather than a kernel driver bug. Can you > bisect mesa? I understand mesa may be sending crap to the kernel space but that doesn't

[PATCH] drm/exynos: add has_vtsel flag

The exynos fimd provides video type selection bits from system register but exynos3 series don't has it, so needs has_vtsel flag and we can distinguish whether set video type selection bits. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +- 1 file changed, 5

[Bug 87791] radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2

[Bug 87791] radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 aCaB changed: What|Removed |Added Attachment #156761|application/octet-stream|text/plain mime type|

[Bug 87791] radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 aCaB changed: What|Removed |Added Attachment #156771|application/octet-stream|text/plain mime type|

[Bug 87791] radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 --- Comment #1 from aCaB --- Created attachment 156771 --> https://bugzilla.kernel.org/attachment.cgi?id=156771=edit lockup example (with oops) -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 87791] New: radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 Bug ID: 87791 Summary: radeonsi lockup and oops Product: Drivers Version: 2.5 Kernel Version: 3.17 Hardware: x86-64 OS: Linux Tree: Mainline

[lm-sensors] Kaveri [and Radeon] temps

> "GR" == Guenter Roeck writes: ... GR> AMD CPUs are known report wildly off temperatures especially at GR> low temperatures. Thanks. After some further digging, I wonder whether Aravind's recent patch might help? The apu does have both PCI_DEVICE_ID_AMD_16H_M30H_NB_F3 and

[RFC 1/2] core: Add generic object registry implementation

On Wed, Nov 05, 2014 at 10:13:53AM +0100, Thierry Reding wrote: > On Tue, Nov 04, 2014 at 08:38:45AM -0800, Greg Kroah-Hartman wrote: > > On Tue, Nov 04, 2014 at 05:29:27PM +0100, Thierry Reding wrote: > [...] > > > diff --git a/drivers/base/registry.c b/drivers/base/registry.c > [...] > > > +/**

[PATCH] drm: Global atomic state handling

Some differences compared to Rob's patches again: - Dropped the committed and checked booleans. Checking will be internally enforced by always calling ->atomic_check before ->atomic_commit. And async handling needs to be solved differently because the current scheme completely side-steps ww

[PATCH 05/17] drm: Add atomic driver interface definitions for objects

On Wed, Nov 5, 2014 at 5:26 PM, Thierry Reding wrote: >> +struct drm_plane_state { >> + struct drm_crtc *crtc; >> + struct drm_framebuffer *fb; >> + >> + /* Signed dest location allows it to be partially off screen */ >> + int32_t crtc_x, crtc_y; >> + uint32_t crtc_w, crtc_h;

[PATCH] drm/plane-helper: transitional atomic plane helpers

Converting a driver to the atomic interface can be a daunting undertaking. One of the prerequisites is to have full universal planes support. To make that transition a bit easier this patch provides plane helpers which use the new atomic helper callbacks just only for the plane changes. This way

[PATCH 08/17] drm/plane-helper: transitional atomic plane helpers

On Wed, Nov 5, 2014 at 5:45 PM, Sean Paul wrote: >> + /* There's no other way to figure out whether the crtc is running. */ >> + ret = drm_crtc_vblank_get(crtc[i]); >> + if (ret == 0) { >> + drm_crtc_wait_one_vblank(crtc[i]); >> + drm_crtc_vblank_put(crtc[i]); >> + } > > This will be good

[PATCH 05/17] drm: Add atomic driver interface definitions for objects

src_x, src_y; > + uint32_t src_h, src_w; Do we really use the 16.16 fixed point format for these? Maybe now would be a good time to get rid of that if we don't need it. If they're not a 16.16 fixed point format they could also be unsized. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/dd908b27/attachment-0001.sig>

[PATCH 04/17] drm/modeset_lock: document trylock_only in kerneldoc

e/drm/drm_modeset_lock.h | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/f63342a9/attachment.sig>

[Intel-gfx] [PATCH 05/17] drm: Add atomic driver interface definitions for objects

On Wed, Nov 05, 2014 at 06:04:59PM +0100, Daniel Vetter wrote: > On Wed, Nov 5, 2014 at 5:26 PM, Thierry Reding > wrote: > >> +struct drm_plane_state { > >> + struct drm_crtc *crtc; > >> + struct drm_framebuffer *fb; > >> + > >> + /* Signed dest location allows it to be partially off

[RFC 1/2] core: Add generic object registry implementation

On 11/05/2014 03:04 PM, Thierry Reding wrote: > On Wed, Nov 05, 2014 at 01:36:24PM +0100, Andrzej Hajda wrote: >> On 11/04/2014 05:29 PM, Thierry Reding wrote: >>> From: Thierry Reding >>> >>> Add a generic implementation of an object registry. This targets drivers >>> and subsystems that provide

[Bug 76130] Radeon HD 4570 set dpm state fails after suspend

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

[PATCH 3/7] drm/doc: Add GEM/CMA helpers to kerneldoc

-) Alright, I'll go with the variant that you proposed for the sake of consistency. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/fd7d4352/attachment.sig>

[PATCH 3/7] drm/doc: Add GEM/CMA helpers to kerneldoc

On Wed, Nov 05, 2014 at 04:01:26PM +0100, Thierry Reding wrote: > On Wed, Nov 05, 2014 at 03:34:40PM +0100, Daniel Vetter wrote: > > On Wed, Nov 05, 2014 at 02:25:15PM +0100, Thierry Reding wrote: > > > + * Return: A struct drm_gem_cma_object * on success or an > > > ERR_PTR()-encoded > > > >

[PATCH 0/7] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

On Wed, Nov 05, 2014 at 02:24:42PM +, Russell King - ARM Linux wrote: > On Wed, Nov 05, 2014 at 02:25:12PM +0100, Thierry Reding wrote: > > Discussion on IRC lead to the conclusion that new IOCTLs should have > > input validation and require userspace to zero out output parameters to > > avoid

[PATCH 3/7] drm/doc: Add GEM/CMA helpers to kerneldoc

t;This function implements an augmented version of the gem DRM file mmap > operation for cma objects: In addition to the usual gem vma setup it > immediately faults in the entire object instead of using on-demand > faulting. Drivers which employ the cma helpers should use this function as > their ->mmap handler for the DRM device file's file_operation structure." I've taken the easy route and simply copied your example. > So requires grepping each function and hunting for the usual pattern (and > noticing tons of crazy stuff, usually). > > Same for all the functions below. Okay, I'll see what I can come up with. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/13ffdda2/attachment.sig>

[lm-sensors] Kaveri [and Radeon] temps

On Wed, Nov 05, 2014 at 06:34:20PM -0500, James Cloos wrote: > > "GR" == Guenter Roeck writes: > > ... > GR> AMD CPUs are known report wildly off temperatures especially at > GR> low temperatures. > > Thanks. After some further digging, I wonder whether Aravind's recent > patch might help?

[PATCH 0/7] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

If that works for you it'd at least give you a means to check that the kerneldoc comments you've added are consistent. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL

[PATCH 7/7] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

On Wed, Nov 05, 2014 at 02:25:19PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Some drivers treat the pitch and size fields as inputs and will use them > as minima provided by userspace so that they are only overwritten if the > minimal requirements of the driver exceed them. > >

[PATCH 6/7] drm/rcar: gem: dumb: pitch is an output

On Wed, Nov 05, 2014 at 02:25:18PM +0100, Thierry Reding wrote: > From: Thierry Reding > > When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB > IOCTL, only the width, height, bpp and flags fields are inputs. The > caller is not guaranteed to zero out or set handle, pitch and

[PATCH v4 16/16] drm/panel: Add Sharp LQ101R1SX01 support

On 11/04/2014 02:29 PM, Thierry Reding wrote: > On Tue, Nov 04, 2014 at 11:41:15AM +0100, Andrzej Hajda wrote: >> On 11/03/2014 10:13 AM, Thierry Reding wrote: > [...] >>> diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt >>>

[PATCH 5/7] drm/omap: gem: dumb: pitch is an output

On Wed, Nov 05, 2014 at 02:25:17PM +0100, Thierry Reding wrote: > From: Thierry Reding > > When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB > IOCTL, only the width, height, bpp and flags fields are inputs. The > caller is not guaranteed to zero out or set handle, pitch and

exynos-drm registration: infinite loop

lable URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/dfa3a341/attachment.sig>

[PATCH 4/7] drm/cma: Introduce drm_gem_cma_dumb_create_internal()

On Wed, Nov 05, 2014 at 02:25:16PM +0100, Thierry Reding wrote: > From: Thierry Reding > > This function is similar to drm_gem_cma_dumb_create() but targetted at > kernel internal users so that they can override the pitch and size > requirements of the dumb buffer. > > It is important to make

[PATCH 3/7] drm/doc: Add GEM/CMA helpers to kerneldoc

On Wed, Nov 05, 2014 at 02:25:15PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Most of the functions already have the beginnings of kerneldoc comments > but are using the wrong opening marker. Use the correct opening marker > and flesh out the comments so that they can be integrated

[PATCH] drm: Global atomic state handling

Some differences compared to Rob's patches again: - Dropped the committed and checked booleans. Checking will be internally enforced by always calling ->atomic_check before ->atomic_commit. And async handling needs to be solved differently because the current scheme completely side-steps ww

[lm-sensors] Kaveri [and Radeon] temps

On Wed, Nov 05, 2014 at 04:15:54PM -0500, James Cloos wrote: > I'm getting odd temp readings on an A8-7600 with 3.3.4 and Linus' > current kernel. > > Eg, the gpu temp shows up when (mostly) idle as: > > radeon-pci-0008 > Adapter: PCI adapter > temp1: -1.0°C (crit = +120.0°C, hyst

[PATCH 2/7] drm/doc: mm: Fix indentation

On Wed, Nov 05, 2014 at 02:25:14PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Use spaces consistently for indentation in the memory-management > section. > > Signed-off-by: Thierry Reding Acked-by: Daniel Vetter > --- > Documentation/DocBook/drm.tmpl | 268 >

[PATCH 1/7] drm/gem: Fix a few kerneldoc typos

On Wed, Nov 05, 2014 at 02:25:13PM +0100, Thierry Reding wrote: > From: Thierry Reding > > While at it, adjust the drm_gem_handle_create() function declaration to > be more consistent with other functions in the file. > > Signed-off-by: Thierry Reding Reviewed-by: Daniel Vetter > --- >

[Bug 81644] Random crashes on RadeonSI with Chromium.

that started with mesa 10.3. -- 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/20141105/5819663d/attachment-0001.html>

[PATCH] drm: Global atomic state handling

On 11/05/2014 12:07 AM, Daniel Vetter wrote: > /** > + * struct struct drm_atomic_state - the global state object for atomic > updates > + * @dev: parent DRM device > + * @flags: state flags like async update > + * @planes: pointer to array of plane pointers > + * @plane_states: pointer to

[RFC 1/2] core: Add generic object registry implementation

e counted life- times of these record objects. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/4e6c84bb/attachment-0001.sig>

[PATCH] drm/atomic-helper: implementatations for legacy interfaces

On Wed, Nov 05, 2014 at 02:46:10PM +0100, Daniel Vetter wrote: > Well, except page_flip since that requires async commit, which isn't > there yet. > > For the functions which changes planes there's a bit of trickery > involved to keep the fb refcounting working. But otherwise fairly >

[PATCH] drm/atomic-helper: implement ->page_flip

Currently there is no way to implement async flips using atomic, that essentially requires us to be able to cancel pending requests mid-flight. To be able to do that (and I guess we want this since vblank synced updates whic opportunistically cancel still pending updates seem to be wanted) we'd

[PATCH] drm/atomic-helper: implementatations for legacy interfaces

Well, except page_flip since that requires async commit, which isn't there yet. For the functions which changes planes there's a bit of trickery involved to keep the fb refcounting working. But otherwise fairly straight-forward atomic updates. The property setting functions are still a bit

[PATCH] drm: Global atomic state handling

Some differences compared to Rob's patches again: - Dropped the committed and checked booleans. Checking will be internally enforced by always calling ->atomic_check before ->atomic_commit. And async handling needs to be solved differently because the current scheme completely side-steps ww

[PATCH 1/2] imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

Hi Andy, I think separating the core from the SoC specific part is a good step into the right direction. Am Mittwoch, den 05.11.2014, 20:55 +0800 schrieb Andy Yan: > imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS) > use the interface compatible Designware HDMI IP, but they > also have

[PATCH v4 01/16] drm/dsi: Add message to packet translator

On 11/04/2014 03:39 PM, Thierry Reding wrote: > On Tue, Nov 04, 2014 at 03:21:14PM +0100, Andrzej Hajda wrote: >> On 11/04/2014 02:58 PM, Thierry Reding wrote: >>> On Tue, Nov 04, 2014 at 12:43:21PM +0100, Andrzej Hajda wrote: On 11/03/2014 10:13 AM, Thierry Reding wrote: > [...] > diff

[PATCH 7/7] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

From: Thierry Reding Some drivers treat the pitch and size fields as inputs and will use them as minima provided by userspace so that they are only overwritten if the minimal requirements of the driver exceed them. This can cause strange behaviour when applications don't

[PATCH 6/7] drm/rcar: gem: dumb: pitch is an output

From: Thierry Reding When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB IOCTL, only the width, height, bpp and flags fields are inputs. The caller is not guaranteed to zero out or set handle, pitch and size. Drivers must not treat these values as possible

[PATCH 5/7] drm/omap: gem: dumb: pitch is an output

From: Thierry Reding When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB IOCTL, only the width, height, bpp and flags fields are inputs. The caller is not guaranteed to zero out or set handle, pitch and size. Drivers must not treat these values as possible

[PATCH 4/7] drm/cma: Introduce drm_gem_cma_dumb_create_internal()

From: Thierry Reding This function is similar to drm_gem_cma_dumb_create() but targetted at kernel internal users so that they can override the pitch and size requirements of the dumb buffer. It is important to make this difference because the IOCTL says that the pitch and

[PATCH 3/7] drm/doc: Add GEM/CMA helpers to kerneldoc

From: Thierry Reding Most of the functions already have the beginnings of kerneldoc comments but are using the wrong opening marker. Use the correct opening marker and flesh out the comments so that they can be integrated with the DRM DocBook document. Signed-off-by: Thierry

[PATCH 2/7] drm/doc: mm: Fix indentation

From: Thierry Reding Use spaces consistently for indentation in the memory-management section. Signed-off-by: Thierry Reding --- Documentation/DocBook/drm.tmpl | 268 - 1 file changed, 134 insertions(+), 134 deletions(-) diff --git

[PATCH 1/7] drm/gem: Fix a few kerneldoc typos

From: Thierry Reding While at it, adjust the drm_gem_handle_create() function declaration to be more consistent with other functions in the file. Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_gem.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-)

[PATCH 0/7] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

From: Thierry Reding Drivers currently treat the IOCTL data for DRM_IOCTL_MODE_CREATE_DUMB inconsistently. While the documentation clearly states that the handle, pitch and size fields are outputs, some drivers use their values as a minimum hint from userspace, presumably to

[PATCH 0/7] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

On Wed, Nov 05, 2014 at 02:25:12PM +0100, Thierry Reding wrote: > Discussion on IRC lead to the conclusion that new IOCTLs should have > input validation and require userspace to zero out output parameters to > avoid this kind of mess in the future. In order to help avoid this kind > of ambiguity

[PULL] topic/core-stuff

Hi Dave, Just various stuff all over from a bunch of people. Shortlog gives a beter overview, it's really all misc drm patches. Cheers, Daniel The following changes since commit 1bcecfacde6269dc6cee9a098bc454222d441ff9: drm/core: use helper to check driver features (2014-10-03 10:38:56

[PATCH] drm/panel: Flesh out kerneldoc

On Tue, Nov 04, 2014 at 05:26:13PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Write more complete kerneldoc comments for the DRM panel API and > integrate the helpers in the DRM DocBook reference. > > Signed-off-by: Thierry Reding A few comments below. With thos addressed this is

[PATCH 10/17] drm: Atomic crtc/connector updates using crtc/plane helper interfaces

On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote: > So this is finally the integration of the crtc and plane helper > interfaces into the atomic helper functions. > > In the check function we now have a few steps: > > - First we update the output routing and figure out which crtcs

[RFC 1/2] core: Add generic object registry implementation

On 11/04/2014 05:29 PM, Thierry Reding wrote: > From: Thierry Reding > > Add a generic implementation of an object registry. This targets drivers > and subsystems that provide auxiliary objects that other drivers need to > look up. The goal is to put the difficult parts (keep object references,

[PATCH V2 1/2] imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

This one patch does too much to be reviewed easily. One patch is supposed to modify/add one thing at a time in the kernel. Separating platform specific code from imx-drm/imx-hdmi is one thing. Adding support for multi-byte register access is something different. i.e. Something like. 1/3 split

i915/dri hang

I filed this with bugzilla @ kernel.org (87741) Not sure if I need to send here. Long running stable systems exhibit the following with all mods removed, as distributed. (I use my own scheduler and file system - the kernels below use the stock ext4 file system): Kernel Command line:

[PATCH 09/17] drm/crtc-helper: Transitional functions using atomic plane helpers

On Sun, Nov 02, 2014 at 02:19:22PM +0100, Daniel Vetter wrote: > These two functions allow drivers to reuse their atomic plane helpers > functions for the primary plane to implement the interfaces required > by the crtc helpers for the legacy ->set_config callback. > > This is purely transitional

[PATCH 2/2] move imx-hdmi to bridge/dw-hdmi

On Tue, Nov 04, 2014 at 09:39:58PM +0800, Andy Yan wrote: > From: Andy yan Leave this out. It's for when you are forwarding a patch from someone else. Also it has a typo and your email From: header is correct. > > the original imx hdmi driver is under staging/imx-drm, > which depends on

[PATCH 08/17] drm/plane-helper: transitional atomic plane helpers

On Sun, Nov 02, 2014 at 02:19:21PM +0100, Daniel Vetter wrote: > Converting a driver to the atomic interface can be a daunting > undertaking. One of the prerequisites is to have full universal planes > support. > > To make that transition a bit easier this pathc provides plane helpers

[PATCH] drm/atomic-helper: implement ->page_flip

On 04/11/14 22:09, Daniel Vetter wrote: > Currently there is no way to implement async flips using atomic, that > essentially requires us to be able to cancel pending requests > mid-flight. > > To be able to do that (and I guess we want this since vblank synced > updates whic opportunistically

[PATCH] drm: drop README.drm, ancient scrolls

From: Dave Airlie This stuff is ancient, we have docs now in the kernel, lets just drop it. Pointed out by Glenn Signed-off-by: Dave Airlie --- drivers/gpu/drm/README.drm | 43 --- 1 file changed, 43 deletions(-) delete mode 100644

[RFC 1/2] core: Add generic object registry implementation

er. Can you elaborate what you think is confusing? Perhaps I can add more kerneldoc to clarify. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/00a5f89f/attachment.sig>

[PATCH 0/2] make imx hdmi publicly used by dw hdmi compatible platform

On 2014年11月04日 22:29, Russell King - ARM Linux wrote: > On Tue, Nov 04, 2014 at 09:33:10PM +0800, Andy Yan wrote: >> From: Andy yan >> >> We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) >> use the interface compatible Designware HDMI IP, but they also have some

i915/dri hang

On Wed, 05 Nov 2014, Jim McDevitt wrote: > I filed this with bugzilla @ kernel.org (87741) Not sure if I need to > send here. Thanks for the report; for drm/i915 we do track the bugs at kernel.org and freedesktop.org bugzillas, so let's have the follow-ups in

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

use: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141105/da24c2b8/attachment.html>

[PATCH 2/2] move imx-hdmi to bridge/dw-hdmi

Hi ZubairLK: On 2014年11月04日 21:50, Zubair Lutfullah Kakakhel wrote: > Hi, > > On 04/11/14 13:39, Andy Yan wrote: >> From: Andy yan >> >> the original imx hdmi driver is under staging/imx-drm, >> which depends on imx-drm, so move the imx hdmi drvier out >> to drm/bridge and rename imx-hdmi

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

chives/dri-devel/attachments/20141105/a80ce9b8/attachment.html>

[PATCH 2/2] drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()

Reviewed-by: Rodrigo Vivi On Tue, Oct 28, 2014 at 7:20 AM, Jani Nikula wrote: > The Baseline_ELD_Len field does not include ELD Header Block size. > > From High Definition Audio Specification, Revision 1.0a: > > The header block is a fixed size of 4 bytes. The baseline block >

[Bug 85866] Desktop environment becomes unresponsive, but mouse can move after distro update

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141105/afc83609/attachment.html>

[PATCH] drm: drop README.drm, ancient scrolls

On November 5, 2014 2:03:16 AM Dave Airlie wrote: > From: Dave Airlie > > This stuff is ancient, we have docs now in the kernel, > lets just drop it. > > Pointed out by Glenn > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/README.drm | 43 --- > 1

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #72 from prettyvanilla at posteo.at --- Created attachment 156581 --> https://bugzilla.kernel.org/attachment.cgi?id=156581=edit vbios of the sapphire radeon hd 6870 dirt3 edition -- You are receiving this mail because: You are

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #71 from prettyvanilla at posteo.at --- Created attachment 156571 --> https://bugzilla.kernel.org/attachment.cgi?id=156571=edit dmesg after (uvd related) gpu lockup and successful reset -- You are receiving this mail because: You

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #70 from prettyvanilla at posteo.at --- I just had my Sapphire HD 6870 (Dirt3 Edition) successfully reset itself after a lockup for the first time (as opposed to the usual black or funnily patterned screen), so I can post my dmesg.

[PATCH 07/17] drm: Add atomic/plane helpers

On Tue, Nov 4, 2014 at 11:30 PM, Sean Paul wrote: >> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl >> index 89829ae58e97..ea0ef43b19e1 100644 >> --- a/Documentation/DocBook/drm.tmpl >> +++ b/Documentation/DocBook/drm.tmpl >> @@ -996,6 +996,10 @@ int max_width,