[git pull] drm intel hibernation fix

Hi Linus, I tracked down the misc memory corruption after i915 hibernate to the blinking fbcon cursor, and realised the i915 driver wasn't doing the fbdev suspend/resume calls at all. nouveau and radeon have done these calls for a long time. This has been fairly well tested and is definitely

Re: [git pull] drm intel hibernation fix

<#part sign=pgpmime> On Thu, 29 Mar 2012 08:14:08 +0100 (IST), Dave Airlie wrote: > Dave Airlie (1): > drm/i915: suspend fbdev device around suspend/hibernate This has my Reviewed-by on it; Dave suggested just sending it directly to you instead of running it through my tree and then back t

Re: [PATCH] drm/radeon/kms: add register definitions for audio

Oh YES! Finally! Just as a side note before it went unnoticed: That is the official HDMI register documentation from R6xx - NI hardware, not just something reverse engineered! @Rafał and the rest of the community: We hoped that you could stick with it and cleanup the current implementation wit

Re: [PATCH] drm/radeon/kms: add register definitions for audio

2012/3/28 : > +/* digital blocks */ > +#define TMDSA_CNTL                       0x7880 > +#       define TMDSA_HDMI_EN             (1 << 2) > +#define LVTMA_CNTL                       0x7a80 > +#       define LVTMA_HDMI_EN             (1 << 2) > +#define DDIA_CNTL                        0x7200 > +

Re: [PATCH 2/7 v6] drm/i915/intel_i2c: use double-buffered writes

On Thu, Mar 29, 2012 at 04:46:39PM +0800, Daniel Kurtz wrote: > On Thu, Mar 29, 2012 at 2:41 AM, Chris Wilson > wrote: > > On Thu, 29 Mar 2012 02:26:34 +0800, Daniel Kurtz > > wrote: > >> The GMBUS controller GMBUS3 register is double-buffered.  Take advantage > >> of this  by writing two 4-byt

Re: [PATCH 5/7 v6] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

On Thu, Mar 29, 2012 at 04:37:18PM +0800, Daniel Kurtz wrote: > On Thu, Mar 29, 2012 at 2:52 AM, Chris Wilson > wrote: > > On Thu, 29 Mar 2012 02:26:37 +0800, Daniel Kurtz > > wrote: > >> It is very common for an i2c device to require a small 1 or 2 byte write > >> followed by a read.  For exam

[Bug 26891] Radeon KMS on Macs with EFI boot

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #16 from James Tyrrell 2012-03-29 03:03:58 PDT --- This works for my MacBook Pro 8,3. It allows me to use my thunderbolt monitor whilst booting via EFI, something that is not possible when using the Intel IGD. -- Configure bugmail:

RE: [PATCH] drm/radeon/kms: add register definitions for audio

> -Original Message- > From: Rafał Miłecki [mailto:zaj...@gmail.com] > Sent: Thursday, March 29, 2012 4:17 AM > To: alexdeuc...@gmail.com > Cc: airl...@gmail.com; dri-devel@lists.freedesktop.org; Deucher, Alexander > Subject: Re: [PATCH] drm/radeon/kms: add register definitions for audio >

Re: [git pull] drm main pull for 3.4-rc1

On Wed, Mar 28, 2012 at 09:55:09AM +0100, Tony Vroon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 27/03/12 21:39, Daniel Vetter wrote: > > Yet another thing to try: Can you append intel_iommu=igfx_off to > > your kernel cmdline? If you can, try this both on mainline kernels > >

drm/i915:fix for some -Wuninitialized compiler warnings

>From 2424354579d86a9c40eaea58b75c7d1c2e52577b Mon Sep 17 00:00:00 2001 From: majianpeng Date: Thu, 29 Mar 2012 15:20:40 +0800 Subject: [PATCH] drm/i915:fix for some -Wuninitialized compiler warnings. Signed-off-by: majianpeng --- drivers/gpu/drm/i915/i915_gem.c |4 ++-- 1 files changed, 2

drm/i915:Fix array bounds warnings

>From 9f714f4192fcfccfc312466531a77f0e73162417 Mon Sep 17 00:00:00 2001 From: majianpeng Date: Thu, 29 Mar 2012 15:48:02 +0800 Subject: [PATCH] drm/i915:Fix array bounds warnings. Signed-off-by: majianpeng --- drivers/gpu/drm/i915/i915_debugfs.c |1 + 1 files changed, 1 insertions(+), 0 de

Re: [PATCH 5/7 v6] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

On Thu, Mar 29, 2012 at 2:52 AM, Chris Wilson wrote: > On Thu, 29 Mar 2012 02:26:37 +0800, Daniel Kurtz wrote: >> It is very common for an i2c device to require a small 1 or 2 byte write >> followed by a read.  For example, when reading from an i2c EEPROM it is >> common to write and address, off

Re: [PATCH 4/7 v6] drm/i915/intel_i2c: use WAIT cycle, not STOP

On Thu, Mar 29, 2012 at 2:48 AM, Chris Wilson wrote: > On Thu, 29 Mar 2012 02:26:36 +0800, Daniel Kurtz wrote: >> The i915 is only able to generate a STOP cycle (i.e. finalize an i2c >> transaction) during a DATA or WAIT phase.  In other words, the >> controller rejects a STOP requested as part o

Re: [PATCH 2/7 v6] drm/i915/intel_i2c: use double-buffered writes

On Thu, Mar 29, 2012 at 2:41 AM, Chris Wilson wrote: > On Thu, 29 Mar 2012 02:26:34 +0800, Daniel Kurtz wrote: >> The GMBUS controller GMBUS3 register is double-buffered.  Take advantage >> of this  by writing two 4-byte words before the first wait for HW_RDY. >> This helps keep the GMBUS control

re: drm/radeon: Only warn if the intra-domain offset actually exceeds the limit.

Hello Michel Dänzer, This is a semi-automatic email about new static checker warnings. The patch d936622c3627: "drm/radeon: Only warn if the intra-domain offset actually exceeds the limit." from Mar 28, 2012, leads to the following Smatch complaint: drivers/gpu/drm/radeon/radeon_object.c:244 r

[PATCH] drm/radeon: Don't dereference possibly-NULL pointer.

From: Michel Dänzer Reported-by: Dan Carpenter Signed-off-by: Michel Dänzer --- Third time's the charm, I hope... drivers/gpu/drm/radeon/radeon_object.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon

[RFC] Revive the work on render-nodes branch

The following set of patches will revive the drm-render-nodes [1] branch that has been dormant in Dave Airlie's repository for some time. I rebased this branch to the latest drm-core-next and did some (hopefully useful) follow-up work. I fixed a few bugs, did a substantial cleanup, separated the e

[PATCH 01/16] drm: do not push inode down into drm_open_helper

Push minor number instead. This is a preparatory patch for introducing render nodes. It has been derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc originally created by Dave Airlie. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_fops.c | 19 ++- 1 files changed, 10 ins

[PATCH 03/16] drm: add support for render nodes

Add support for creating multiple render nodes on the same physical GPU. Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc originally authored by Dave Airlie. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_crtc.c |1 + drivers/gpu/drm/drm_stub.c | 32 +++

[PATCH 02/16] drm: move dev_mapping to the minor node

Make dev_mapping per-minor instead of per device. This is a preparatory patch for introducing render nodes. This will allow per-node instead of per-device mapping range, once we introduce render nodes. Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc originally authored by Dave Airlie.

[PATCH 04/16] drm: initial multiple nodes ioctl work.

From: Dave Airlie just adds some unchecked ioctls to setup the nodes. Signed-off-by: Dave Airlie v2: - original ioctl numbers are now taken, use next available - resolve some trivial conflicts due to bit-rot that occurred since the original patch was created Signed-off-by: Ilija Had

[PATCH 05/16] drm: separate render node descriptor from minor

drm_minor structure had a list_head pointer that was used only for render nodes. control and primary nodes do not live in the list and had this list pointer unused. Create a separate drm_render_node structure that is used to build the render node list and that points to the coresponding minor. Thi

[PATCH 07/16] drm: only allow render node ioctls through control node

The render-node manipulation ioctls are supposed to be issued through control node only. Add a check and return -EPERM to user space if access is attempted through a node other than a control node. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_stub.c |8 1 files changed, 8 ins

[PATCH 06/16] drm: cleanup render node ioctls

Fix a few bugs in render node create and destroy ioctl (mostly handling of error cases). Also separate some common code into a new function for destroying the render node. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_stub.c | 80 +++ 1 files chang

[PATCH 09/16] drm: allocate correct id_list size for a render node

When a new render node is created, the number of elements of id_list allocated in drm_mode_group_init function should not be the sum of all CRTCs, encoders, and connectors that the device has, but the one specified by the ioctl that created the node. Signed-off-by: Ilija Hadzic --- drivers/gpu/d

[PATCH 08/16] drm: do not remove a render node in use

Keep track of per-node open count and do not allow removal of a render node in use. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_fops.c |2 ++ drivers/gpu/drm/drm_stub.c |2 ++ include/drm/drmP.h |1 + 3 files changed, 5 insertions(+), 0 deletions(-) diff --git a/driv

[PATCH 10/16] drm: add drm_mode_group_fini function

This is the opposite function of drm_mode_group_init. It will be needed to properly cleanup the render node after removing it. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_crtc.c | 10 ++ include/drm/drm_crtc.h |1 + 2 files changed, 11 insertions(+), 0 deletions(-) dif

[PATCH 12/16] drm: call drm_mode_group_fini on primary node

In drm_put_dev, the whole device is being destroyed, so id_list of the primary (legacy) node should also be cleaned up. This plugs a memory leak that has probably existed even without the render-node work. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_stub.c |1 + 1 files changed, 1 in

[PATCH 15/16] drm: keep track of which node holds which resource

Add fields to drm_crtc, drm_encoder and drm_connector that keep track of which render node owns it. Assign ownership when resource is added and revoke it when resource is destroyed. Do not allow creation of a node that tries to claim resources that are already in use by another node. Signed-off-by

[PATCH 16/16] drm: hold mutex in critical sections of render-node code

Critical sections are parts of the code where we claim or release resources (we don't want two render-node create or remove ioctl called in the context of different processes to claim part of requested resources because of the race). Another critical section is manipulating the render node list. We

[PATCH 13/16] drm: more elaborate check for num_crtc/encoder/connector

User space can send us all kinds of nonsense for num_crtc, num_encoder and num_connector. So far, we have been checking only for presence of at least one CRTC/encoder/connector (barring the trivial case of a render node with no display resources, i.e., GPGPU node). This patch makes the ioctl fail

[PATCH 14/16] drm: validate id list when creating a render node

Render node ioctl requires a list of DRM mode objects in specific order: first all CRTCs, then all encoders, followed by all connectors. Check that the IDs passed from userland are in conformance with this requirement and that they are consistent with specified num_crtc, num_encoder and num_connect

[PATCH 11/16] drm: properly free id_list when a render node is removed

id_list is dynamically allocated when a render node is created. Consequently, if must be freed when the render node is removed, otherwise we have a memory leak. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_stub.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git

libdrm part of the render-node patch series

The following two patches add libdrm support for render node manipulation. The first patch adds the functions for render node creation and removal that an application can call. The second patch add two small test utilities that allow render node creation and removal from shell. For example, this w

[PATCH 1/2] libdrm: add functions for render node manipulation

Implement the user-space side of drm_render_node_create and drm_render_node_remove ioctls. The new functions are drmCreateRenderNode and drmRemoveRenderNode. Signed-off-by: Ilija Hadzic --- include/drm/drm.h |2 + include/drm/drm_mode.h | 16 + xf86drm.c | 5

[PATCH 2/2] tests: add render_node tests

Add two simple programs (render_node_add and render_node_rm) that can be used to add and remove render nodes from a shell command or a script. Signed-off-by: Ilija Hadzic --- .gitignore |2 + configure.ac |1 + tests/Makefile.am

Re: [PATCH 04/16] drm: initial multiple nodes ioctl work.

On Thu, Mar 29, 2012 at 12:41:26PM -0400, Ilija Hadzic wrote: > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h > index 2a2acda..2a403bb 100644 > --- a/include/drm/drm_mode.h > +++ b/include/drm/drm_mode.h > @@ -441,4 +441,18 @@ struct drm_mode_destroy_dumb { > uint32_t handle; >

Re: [RFC] Revive the work on render-nodes branch

On Thu, Mar 29, 2012 at 12:41:22PM -0400, Ilija Hadzic wrote: > The following set of patches will revive the drm-render-nodes [1] > branch that has been dormant in Dave Airlie's repository for some > time. I rebased this branch to the latest drm-core-next and did some > (hopefully useful) follow-up

Re: [PATCH 04/16] drm: initial multiple nodes ioctl work.

On Thu, 29 Mar 2012, Ville [iso-8859-1] Syrjälä wrote: +/* render node create and remove functions + if crtc/encoders/connectors all == 0 then gpgpu node */ +struct drm_render_node_create { + __u32 node_minor_id; + __u32 num_crtc; + __u32 num_encoder; + __u32 num_conn

Re: [PATCH 04/16] drm: initial multiple nodes ioctl work.

On Thu, Mar 29, 2012 at 12:22:20PM -0500, Ilija Hadzic wrote: > > > On Thu, 29 Mar 2012, Ville [iso-8859-1] Syrjälä wrote: > > >> +/* render node create and remove functions > >> + if crtc/encoders/connectors all == 0 then gpgpu node */ > >> +struct drm_render_node_create { > >> + __u32 node_

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #14 from Jon Dowland 2012-03-29 18:08:59 --- That second patch sorts it! Thanks! I booted to single-user; modprobe radeon; pm-suspend; resumed: fine. Moved to multi-user; logged into GNOME; suspended via GNOME menu; resumed: fine

Re: CRTC properties patches

Hi Here is a new version of the patches. Summary: almost all patches changed at least one line, Kernel patches 7 and 8 are RFCs. The main difference is that now the ioctls are not for CRTC properties, but for generic "object" properties. I decided to write it like this after Rob Clark's review.

[PATCH 1/8] drm: add drm_property_change_is_valid

From: Paulo Zanoni Move code from drm_mode_connector_property_set_ioctl to a new function, so we can reuse this code when we add crtc properties. v2: use bool instead of int Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/drm_crtc.c | 41 + 1 files ch

[PATCH 2/8] drm: WARN() when drm_connector_attach_property fails

From: Paulo Zanoni Also return void instead of int. We have more than 100 callers and no one checks for the return value. If this function fails the property won't be exposed by the get/set ioctls, but we should probably survive. If this starts happening, the solution will be to increase DRM_CON

[PATCH 3/8] drm: create struct drm_object_properties and use it

From: Paulo Zanoni For now, only connectors have it. In the future, all objects that need properties should use it. Since the strucutre is referenced inside struct drm_mode_object, we will be able to deal with object properties without knowing the real type of the object. Signed-off-by: Paulo Za

[PATCH 4/8] drm: add generic ioctls to get/set properties on any object

From: Paulo Zanoni Useless for connector properties (since they already have their own ioctls), but useful when we add properties to CRTCs, planes and other objects. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/drm_crtc.c | 180 drivers/gpu/drm/

[PATCH 5/8] drm: make the connector properties code use the object properties code

From: Paulo Zanoni Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/drm_crtc.c | 96 +-- 1 files changed, 12 insertions(+), 84 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 12f93e4..b21bfcd 100644 --- a/drivers/

[PATCH 6/8] drm: add CRTC properties

From: Paulo Zanoni The i915 driver needs this for the rotation and overscan compensation properties. Other drivers might need this too. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/drm_crtc.c | 20 include/drm/drm_crtc.h |9 - 2 files changed, 28 inser

[PATCH RFC 7/8] drm/i915: add 'rotation' CRTC property

From: Paulo Zanoni This property is needed so we can inform the KVMr feature about our current rotation: whenever we change the rotation, we should change that property so that the KVMr knows that the screen is rotated. How to reproduce the problem: - on an AMT machine, enable KVM - boot the mac

[PATCH 8/8] drm/i915: add overscan compensation CRTC properties

From: Paulo Zanoni They're named "underscan hborder" and "underscan vborder". The properties accept values from 0 to 100, where 0 is "don't compensate" and 100 is "shrink the screen as much as possible" (not necessarily 100 pixels). V2: Rename to "underscan hborder" and "underscan vborder" to ma

[PATCH libdrm 1/5] modetest: fix some compiler warnings

From: Paulo Zanoni Use unsigned int instead of int: - modetest.c:89:1: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] - modetest.c:97:1: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] - modetest.c:117:1: warning: compar

[PATCH libdrm 2/5] modetest: fix memory leak

From: Paulo Zanoni Don't "continue" without freeing the connector. 192 bytes in 6 blocks are indirectly lost in loss record 6 of 12 at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x4E30DD8: drmMalloc (xf86drm.c:147) by 0x4E35024: drmAllocCpy (xf86drmMod

[PATCH libdrm 3/5] modetest: print more about our properties

From: Paulo Zanoni In the future we'll have more than just connector properties, so create a dump_prop function that can handle any property (instead of the current dump_props function that only handles connector properties). Also, make this function print a lot more information about the existi

[PATCH libdrm 4/5] Add support for generic object properties IOCTLs

From: Paulo Zanoni New library calls: - drmModeObjectGetProperties - drmModeFreeObjectProperties - drmModeObjectSetProperties Signed-off-by: Paulo Zanoni --- include/drm/drm.h |2 + include/drm/drm_mode.h | 24 ++ xf86drmMode.c | 83 +++

[PATCH libdrm 5/5] modetest: print CRTC properties

From: Paulo Zanoni Signed-off-by: Paulo Zanoni --- tests/modetest/modetest.c | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index 02ea579..a6a2a8c 100644 --- a/tests/modetest/modetest.c +++ b/tests/mo

[PATCH RFC xf86-video-intel 1/2] Update the rotation property whenever we change the rotation.

From: Paulo Zanoni Don't worry if that fails: only the KVMr feature will be affected. We still need to change the sna/ code. We also need to add the dependency on libdrm. Signed-off-by: Paulo Zanoni --- src/intel.h |3 ++ src/intel_display.c | 80

[PATCH RFC xf86-video-intel 2/2] Add underscan properties

From: Paulo Zanoni In the Kernel side, these are crtc properties (since in the hardware, underscan use the panel fitters, which are attached to the pipes). Ideally we should make these as crtc properties too, but since xrandr doesn't have support for them, we expose the atoms as output properties

Re: [PATCH 2/8] drm: WARN() when drm_connector_attach_property fails

On Thu, 29 Mar 2012 18:27:20 -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > Also return void instead of int. We have more than 100 callers and > no one checks for the return value. > > If this function fails the property won't be exposed by the get/set > ioctls, but we should probably surv

[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup

https://bugzilla.kernel.org/show_bug.cgi?id=42678 Adrien Nader changed: What|Removed |Added CC||camarade...@gmail.com --- Comment #9 f

Re: [PATCH RFC xf86-video-intel 1/2] Update the rotation property whenever we change the rotation.

On Thu, 29 Mar 2012 18:30:19 -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > Don't worry if that fails: only the KVMr feature will be affected. > > We still need to change the sna/ code. > We also need to add the dependency on libdrm. > > Signed-off-by: Paulo Zanoni > --- > src/intel.h

Re: [PATCH RFC xf86-video-intel 2/2] Add underscan properties

On Thu, 29 Mar 2012 18:30:20 -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > In the Kernel side, these are crtc properties (since in the hardware, > underscan use the panel fitters, which are attached to the pipes). > Ideally we should make these as crtc properties too, but since xrandr > do

[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup

https://bugzilla.kernel.org/show_bug.cgi?id=42678 --- Comment #10 from Jérôme Glisse 2012-03-29 22:57:06 --- Adrien question is: Is Xorg stuck inside the kernel ? Fixing root cause of GPU lockup is a different matter (basicly you have to go though several G of datas and there is no tools to

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #15 from Alex Deucher 2012-03-29 23:01:52 --- Perfect. No need for the vbios. I'll send the patch to Dave. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because:

[PATCH] drm/radeon/kms: fix fans after resume

From: Alex Deucher On pre-R600 asics, the SpeedFanControl table is not executed as part of ASIC_Init as it is on newer asics. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=29412 Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/atom.c | 15 ++

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #8 from ArTourter 2012-03-29 23:36:40 --- (In reply to comment #7) > (In reply to comment #6) > > I have tried booting with both nouveau and nvidia blacklisted in console > > mode > > and still get the same behaviour. > > > > As

[PATCH RFC 1/2] drm: add bitmask property type

From: Rob Clark A bitmask property is similar to an enum. The enum value is a bit position (0-63), and valid property values consist of a mask of zero or more of (1 << enum_val[n]). TODO: word commit msg better TODO: maybe "flags" would be a better name for the property type? --- See https://g

[PATCH RFC 2/2] drm: add plane properties

From: Rob Clark The omapdrm driver uses this for setting per-overlay rotation. It is likely also useful for setting YUV->RGB colorspace conversion matrix, etc. --- drivers/gpu/drm/drm_crtc.c | 19 +++ include/drm/drm_crtc.h |5 + 2 files changed, 24 insertions(+),

Re: [PATCH RFC 1/2] drm: add bitmask property type

On Thu, Mar 29, 2012 at 8:02 PM, Rob Clark wrote: > From: Rob Clark > > A bitmask property is similar to an enum.  The enum value is a bit > position (0-63), and valid property values consist of a mask of > zero or more of (1 << enum_val[n]). > > TODO: word commit msg better > TODO: maybe "flags"

Re: regression(?) 3.3-rc4 -> 3.3-rc5: drm intel hangs

Hi everyone, is there anything else I can provide? On Fr, 09 Mär 2012, Norbert Preining wrote: > Hi everyone, > > currently 3.3.0-rc6+ I just was hit by that after wake up from ram: > > On Di, 28 Feb 2012, Daniel Vetter wrote: > > > Feb 28 11:42:47 mithrandir kernel: [15627.756071] > > > [drm:

Re: [PATCH libdrm 1/5] modetest: fix some compiler warnings

On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote: > From: Paulo Zanoni > > Use unsigned int instead of int: > - modetest.c:89:1: warning: comparison between signed and unsigned integer > expressions [-Wsign-compare] > - modetest.c:97:1: warning: comparison between signed and unsigned integer >

Re: [PATCH libdrm 2/5] modetest: fix memory leak

On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote: > From: Paulo Zanoni > > Don't "continue" without freeing the connector. > > 192 bytes in 6 blocks are indirectly lost in loss record 6 of 12 > at 0x4C2779D: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > by 0x4E30DD8: d

Re: [PATCH libdrm 3/5] modetest: print more about our properties

On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote: > From: Paulo Zanoni > > In the future we'll have more than just connector properties, so create > a dump_prop function that can handle any property (instead of the > current dump_props function that only handles connector properties). > > Also,

Re: [PATCH libdrm 4/5] Add support for generic object properties IOCTLs

On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote: > From: Paulo Zanoni > > New library calls: > - drmModeObjectGetProperties > - drmModeFreeObjectProperties > - drmModeObjectSetProperties > > Signed-off-by: Paulo Zanoni > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov

Re: [PATCH libdrm 5/5] modetest: print CRTC properties

On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote: > From: Paulo Zanoni > > Signed-off-by: Paulo Zanoni > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://

[PATCH libdrm] omap: fix license header

From: Rob Clark In syncing with the corresponding kernel header, the wrong license header was inadvertantly copied over. The intention was for the userspace headers to have a MIT license following the convention of the rest of libdrm, xorg, etc. Signed-off-by: Rob Clark --- omap/omap_drm.h |

Re: [PATCH 1/8] drm: add drm_property_change_is_valid

On Thu, Mar 29, 2012 at 18:27, Paulo Zanoni wrote: > + if (property->flags & DRM_MODE_PROP_RANGE) { > + if (value < property->values[0]) > + return false; > + if (value > property->values[1]) > + return false; > Those

Re: [PATCH 3/8] drm: create struct drm_object_properties and use it

On Thu, Mar 29, 2012 at 18:27, Paulo Zanoni wrote: > From: Paulo Zanoni > > For now, only connectors have it. In the future, all objects that need > properties should use it. Since the strucutre is referenced inside > *structure > struct drm_mode_object, we will be able to deal with object pr

Re: [PATCH 4/8] drm: add generic ioctls to get/set properties on any object

On Thu, Mar 29, 2012 at 18:27, Paulo Zanoni wrote: > + switch (arg_obj->type) { > + case DRM_MODE_OBJECT_CONNECTOR: > + ret = drm_mode_connector_set_obj_prop(arg_obj, property, > + arg->value); > + break;

Re: [PATCH 5/8] drm: make the connector properties code use the object properties code

On Thu, Mar 29, 2012 at 18:27, Paulo Zanoni wrote: > From: Paulo Zanoni > > Signed-off-by: Paulo Zanoni > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://

[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

Multi buffer plane pixel formats are added as like kernel header. Signed-off-by: Seung-Woo Kim --- include/drm/drm_fourcc.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h index 85facb0..7cfd95a 100644 --- a/inclu

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #15 from Andrew Randrianasulu 2012-03-29 20:54:13 PDT --- .. and spriteblast mesa demo surely don't work correctly here. (I see something remotely like _giant_ sprites flashing on screen) -- Configure bugmail: https://bugs.freedesk

Re: [git pull] drm main pull for 3.4-rc1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/03/12 13:39, Daniel Vetter wrote: > Is the for-chainsaw branch plus intel_iommu=igfx_off now stable for > you? It appears to crash when I shut my machine down, but has otherwise behaved quite well. Regards, - -- Tony Vroon UNIX systems adminis

Re: [git pull] drm intel hibernation fix

On Thu, Mar 29, 2012 at 9:34 AM, Keith Packard wrote: > <#part sign=pgpmime> > On Thu, 29 Mar 2012 08:14:08 +0100 (IST), Dave Airlie > wrote: > >> Dave Airlie (1): >>       drm/i915: suspend fbdev device around suspend/hibernate > I've reported the issue one year ago and kept the discussion ali

[PATCH] drm: add valid pixel formats for fb

This patch adds multi buffer plane pixel formats into valid pixel format list for fb since they are missed from the list. Signed-off-by: Seung-Woo Kim Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/drm_crtc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-

Re: [PATCH] drm/radeon/kms: fix fans after resume

On Don, 2012-03-29 at 19:04 -0400, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > On pre-R600 asics, the SpeedFanControl table is not > executed as part of ASIC_Init as it is on newer asics. > > Fixes: > https://bugzilla.kernel.org/show_bug.cgi?id=29412 > > Signed-off-by: Alex Deucher

[PATCH 3/7 v6] drm/i915/intel_i2c: always wait for IDLE before clearing NAK

The GMBUS controller can report a NAK condition while a transaction is still active. If the driver is fast enough, and the bus is slow enough, the driver may clear the NAK condition while the controller is still busy, resulting in a confused GMBUS controller. This will leave the controller in a ba

[PATCH 1/7 v6] drm/i915/intel_i2c: handle zero-length writes

A common method of probing an i2c bus is trying to do a zero-length write. Handle this case by checking the length first before decrementing it. This is actually important, since attempting a zero-length write is one of the ways that i2cdetect and i2c_new_probed_device detect whether there is devi

[PATCH 5/7 v6] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

It is very common for an i2c device to require a small 1 or 2 byte write followed by a read. For example, when reading from an i2c EEPROM it is common to write and address, offset or index followed by a reading some values. The i915 gmbus controller provides a special "INDEX" cycle for performing

[PATCH 0/7 v6] fix gmbus writes and related issues

This patchset addresses a couple of issues with the i915 gmbus implementation. v6 is a rebased and trimmed version of the patchset, since the first few patches have already been merged onto drm-intel-next-queued. * Cleans up INDEX cycle implementation * Only remove POSTING_READ() when it immedia

[PATCH 6/7 v6] drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop

Save the GMBUS2 value read while polling for state changes, and then reuse this value when determining for which reason the loops were exited. This is a small optimization which saves a couple of bus accesses for memory mapped IO registers. To avoid "assigning in if clause" checkpatch errors", use

[PATCH 2/7 v6] drm/i915/intel_i2c: use double-buffered writes

The GMBUS controller GMBUS3 register is double-buffered. Take advantage of this by writing two 4-byte words before the first wait for HW_RDY. This helps keep the GMBUS controller from becoming idle during long writes. Signed-off-by: Daniel Kurtz --- drivers/gpu/drm/i915/intel_i2c.c | 14

[PATCH 7/7 v6] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

The POSTING_READ() calls were originally added to make sure the writes were flushed before any timing delays and across loops. Now that the code has settled a bit, let's remove them. Signed-off-by: Daniel Kurtz --- drivers/gpu/drm/i915/intel_i2c.c |3 --- 1 files changed, 0 insertions(+), 3

[PATCH 4/7 v6] drm/i915/intel_i2c: use WAIT cycle, not STOP

The i915 is only able to generate a STOP cycle (i.e. finalize an i2c transaction) during a DATA or WAIT phase. In other words, the controller rejects a STOP requested as part of the first transaction in a sequence. Thus, for the first transaction we must always use a WAIT cycle, detect when the d

[PATCH] drm/i915: suspend fbdev device around suspend/hibernate

From: Dave Airlie Looking at hibernate overwriting I though it looked like a cursor, so I tracked down this missing piece to stop the cursor blink timer. I've no idea if this is sufficient to fix the hibernate problems people are seeing, but please test it. Both radeon and nouveau have done this

[git pull] drm intel hibernation fix

Hi Linus, I tracked down the misc memory corruption after i915 hibernate to the blinking fbcon cursor, and realised the i915 driver wasn't doing the fbdev suspend/resume calls at all. nouveau and radeon have done these calls for a long time. This has been fairly well tested and is definitely

[git pull] drm intel hibernation fix

<#part sign=pgpmime> On Thu, 29 Mar 2012 08:14:08 +0100 (IST), Dave Airlie wrote: > Dave Airlie (1): > drm/i915: suspend fbdev device around suspend/hibernate This has my Reviewed-by on it; Dave suggested just sending it directly to you instead of running it through my tree and then back

[PATCH] drm/radeon/kms: add register definitions for audio

Oh YES! Finally! Just as a side note before it went unnoticed: That is the official HDMI register documentation from R6xx - NI hardware, not just something reverse engineered! @Rafa? and the rest of the community: We hoped that you could stick with it and cleanup the current implementation with

[PATCH] drm/radeon/kms: add register definitions for audio

2012/3/28 : > +/* digital blocks */ > +#define TMDSA_CNTL ? ? ? ? ? ? ? ? ? ? ? 0x7880 > +# ? ? ? define TMDSA_HDMI_EN ? ? ? ? ? ? (1 << 2) > +#define LVTMA_CNTL ? ? ? ? ? ? ? ? ? ? ? 0x7a80 > +# ? ? ? define LVTMA_HDMI_EN ? ? ? ? ? ? (1 << 2) > +#define DDIA_CNTL ? ? ? ? ? ? ? ? ? ? ? ?0x7200 > +

[PATCH 2/7 v6] drm/i915/intel_i2c: use double-buffered writes

On Thu, Mar 29, 2012 at 04:46:39PM +0800, Daniel Kurtz wrote: > On Thu, Mar 29, 2012 at 2:41 AM, Chris Wilson > wrote: > > On Thu, 29 Mar 2012 02:26:34 +0800, Daniel Kurtz > > wrote: > >> The GMBUS controller GMBUS3 register is double-buffered. ?Take advantage > >> of this ?by writing two 4-byt

[PATCH 5/7 v6] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

On Thu, Mar 29, 2012 at 04:37:18PM +0800, Daniel Kurtz wrote: > On Thu, Mar 29, 2012 at 2:52 AM, Chris Wilson > wrote: > > On Thu, 29 Mar 2012 02:26:37 +0800, Daniel Kurtz > > wrote: > >> It is very common for an i2c device to require a small 1 or 2 byte write > >> followed by a read. ?For exam

  1   2   >