[ANNOUNCE] libdrm 2.4.29

2011-12-13 Thread Chris Wilson 
This publishes some new API for Intel to be able to cap the number of
VMA that libdrm_intel caches amongst its bo. This is intended to be used
by clients to prevent applications (such as the xserver) from exhausting
their per-process limits on inactive GTT mmaps whilst also mitigating
against the costs of recreating those mmaps.
-Chris

Chris Wilson (6):
  intel: Clean up mmaps on freeing the buffer
  intel: Add an interface to limit vma caching
  intel: Evict cached VMA in order to make room for new mappings
  intel: Update map-count for an early error return during mapping
  intel: Remove the fresh assertions used to debug the vma cacheing
  configure: Bump version for 2.4.29

Dave Airlie (1):
  test/radeon: add missing files for dist

git tag: 2.4.29

http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.bz2
MD5:  96d5e3e9edd55f4b016fe3b5dd0a1953  libdrm-2.4.29.tar.bz2
SHA1: 054ca4f6b9145b1bb5192f3cba4dd1835fcc5977  libdrm-2.4.29.tar.bz2
SHA256: e2432dc93e933479132123a1dca382294c30f55bc895bb737b6bdd6f2b8c452e  
libdrm-2.4.29.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.gz
MD5:  2596e48b4d2663ed075f0a86e977cf99  libdrm-2.4.29.tar.gz
SHA1: 68d46937f5e725b439a8ed748211f0a27168caf3  libdrm-2.4.29.tar.gz
SHA256: d60ecf6fc52f92663ee80cc94560ead56b493e4b91d1ee99f2292f7ecdab40b2  
libdrm-2.4.29.tar.gz

-- 
Chris Wilson, Intel Open Source Technology Centre


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Black screen with AMD A4-3300 support

2011-12-13 Thread Boszormenyi Zoltan 
Hi,

I have a new ASUS K53TA notebook with AMD A4-3300 CPU
and an extra Radeon HD6550M. I installed Fedora 16 on it but
I get only black screen even during installation unless booted
with nomodeset. But it's only VESA so there's no acceleration
and there's no native LCD 1366x768 resolution, only 1024x768,
so it's a bit blurry.

The machine boots up and I can login via ssh so I can debug it.
dmesg and Xorg.0.log says the integrated video is recognized
and handled. Only the screen is black. dmesg says something
about not being able to determine initial brightness setting.

Can anyone help me to get it to display X with KMS?

Thanks in advance,
Zoltán Böszörményi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

EDID Override

2011-12-13 Thread Thorsten Schoel 

Dear all,

please find below a patch that will allow overriding a monitor's EDID 
with something provided by the user. This can be helpful in a number of 
situations as a quick google for "edid override" or similar suggests; I 
wrote it because my monitor is broken and doesn't provide any EDID at 
all. This is done through a module parameter named edid_override which 
is made up of three parts, each separated by a colon from the next. 
First is the name of a connector, second is the type of source for the 
information, third is the source of the information itself. If the 
second part is an 'f', the third will be the name of a file containing 
the EDID, if it is a 'w', the third will be the name of a firmware blob 
(i.e. the kernel firmware loading mechanism will be used to get the 
data), and if it is an 'r' th third part is raw EDID encoded as a stream 
of hexadecimal characters. 'd' as the second part will simply remove any 
previous edid override for the connector.


Since this is my first attempt at getting a patch into the kernel the 
patch might well be in need of some additional work which I will be 
pleased to provide if someone provides me with a description and 
explanation of what needs to be done.


The following points are on my mind. These are not things that I think 
have to be fixed but rather that I am unsure of:


- Is drm_edid.c, the file where all the logic and currently everything 
else is placed, really the right place for the definition of the module 
parameter or should this go elsewhere?


- Is it really desirable to have three different ways of fetching the 
EDID-data? Yet, having the raw EDID in hex (256 characters) on the 
kernel command line might not always be desirable. Loading the EDID as 
firmware may sometimes be more convenient than reading it from an 
arbitrary file. But if you look at it closely EDID data is not exactly 
what you think of when you think of firmware.


- Adding an override through sysfs doesn't work yet and I can't figure 
out why.


The patch was written and tested on Fedora 16, Linux 3.1. I have adopted 
it to 3.2-rc5 though. If anyone desires the 3.1 patch I can provide that 
as well. It is only marginally different though.


Best,
Thorsten

diff -uNpr orig/drivers/gpu/drm/drm_edid.c new/drivers/gpu/drm/drm_edid.c
--- orig/drivers/gpu/drm/drm_edid.c 2011-12-12 12:36:10.409354108 +0100
+++ new/drivers/gpu/drm/drm_edid.c  2011-12-12 12:38:02.717817296 +0100
@@ -31,6 +31,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "drmP.h"
 #include "drm_edid.h"
 #include "drm_edid_modes.h"
@@ -226,6 +231,267 @@ bool drm_edid_is_valid(struct edid *edid
 }
 EXPORT_SYMBOL(drm_edid_is_valid);
 
+enum drm_edid_override_entry_type {
+   DRM_EDID_OVERRIDE_ENTRY_TYPE_DEL,
+   DRM_EDID_OVERRIDE_ENTRY_TYPE_FILE,
+   DRM_EDID_OVERRIDE_ENTRY_TYPE_FIRMWARE,
+   DRM_EDID_OVERRIDE_ENTRY_TYPE_RAW
+};
+
+struct drm_edid_override_entry {
+   struct list_head list;
+   
+   char *connector;
+   enum drm_edid_override_entry_type type;
+   char *param;
+   char edid[EDID_LENGTH];
+};
+LIST_HEAD(__drm_edid_override_list );
+
+
+static int __drm_edid_override_ops__get(char *buffer, const struct 
kernel_param *kp);
+static int __drm_edid_override_ops__set(const char *val, const struct 
kernel_param *kp);
+static void __drm_edid_override_ops__free(void *arg);
+
+
+struct kernel_param_ops drm_edid_override_ops = {
+   .get = __drm_edid_override_ops__get,
+   .set = __drm_edid_override_ops__set,
+   .free = __drm_edid_override_ops__free
+};
+
+MODULE_PARM_DESC(edid_override, "Override the EDID data of a monitor. "
+   "This should be a comma separated list of entries of the following 
format:\n"
+   "\"[connector name]:[type]:[data]\", where type is 'f' if data is a 
file "
+   "name, 'w' if it is a name of a firmware image, 'r' if it is raw edid 
data "
+   "encoded as a hexadecimal string or 'd' (or anything else actually, but 
"
+   "stick to 'd' since other options might be added in future versions) if 
a "
+   "previous edid override for the connector is to be deleted.\n"
+   "The parameter can appear more than once. An appearance of a connector 
will "
+   "override the previous override for that connector. ");
+module_param_cb(edid_override, &drm_edid_override_ops, 
&__drm_edid_override_list, 0600);
+
+
+/*
+ * Delete an entry from the edid overrides list.
+ */
+static void
+drm_delete_edid_override_entry(struct drm_edid_override_entry *entry)
+{
+   /* everything else is generated from the same piece of memory through 
strsep */
+   kfree(entry->connector);
+   kfree(entry);
+}
+
+/*
+ * Convert a string representation of hexadecimal data to binary. Returns 
buffer
+ * if length bytes could indeed be extracted from stream, NULL otherwise.
+ */
+static char *
+convert_hex_stream(const char *stream, char *buffer, size_t length)

Re: Black screen with AMD A4-3300 support

2011-12-13 Thread Joshua Roys 

On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:

I have a new ASUS K53TA notebook with AMD A4-3300 CPU
and an extra Radeon HD6550M. I installed Fedora 16 on it but
I get only black screen even during installation unless booted
with nomodeset. But it's only VESA so there's no acceleration
and there's no native LCD 1366x768 resolution, only 1024x768,
so it's a bit blurry.



Hello,

Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 .  (The HP 
G4-1215DX also has a AMD A4-3300.)  After making the f16 kernel work, I 
ended up installing a f17/rawhide kernel from 
http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to fix other 
bugs, which will probably be the easiest solution for you.  I would be 
interested to hear if, after installing a newer kernel, suspend/resume 
worked for you.


Good luck,

Josh

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

2011-12-13 Thread Hans Verkuil 
(I've been away for the past two weeks, so I'm only now catching up)


On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote:
> On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann  wrote:
> > On Wednesday 07 December 2011, Semwal, Sumit wrote:
> >> Thanks for the excellent discussion - it indeed is very good learning
> >> for the relatively-inexperienced me :)
> >> 
> >> So, for the purpose of dma-buf framework, could I summarize the
> >> following and rework accordingly?:
> >> 1. remove mmap() dma_buf_op [and mmap fop], and introduce cpu_start(),
> >> cpu_finish() ops to bracket cpu accesses to the buffer. Also add
> >> DMABUF_CPU_START / DMABUF_CPU_FINI IOCTLs?
> > 
> > I think we'd be better off for now without the extra ioctls and
> > just document that a shared buffer must not be exported to user
> > space using mmap at all, to avoid those problems. Serialization
> > between GPU and CPU is on a higher level than the dma_buf framework
> > IMHO.
> 
> Agreed.
> 
> >> 2. remove sg_sync* ops for now (and we'll see if we need to add them
> >> later if needed)
> > 
> > Just removing the sg_sync_* operations is not enough. We have to make
> > the decision whether we want to allow
> > a) only coherent mappings of the buffer into kernel memory (requiring
> > an extension to the dma_map_ops on ARM to not flush caches at map/unmap
> > time)
> > b) not allowing any in-kernel mappings (same requirement on ARM, also
> > limits the usefulness of the dma_buf if we cannot access it from the
> > kernel or from user space)
> > c) only allowing streaming mappings, even if those are non-coherent
> > (requiring strict serialization between CPU (in-kernel) and dma users of
> > the buffer)
> 
> I think only allowing streaming access makes the most sense:
> - I don't see much (if any need) for the kernel to access a dma_buf -
> in all current usecases it just contains pixel data and no hw-specific
> things (like sg tables, command buffers, ..). At most I see the need
> for the kernel to access the buffer for dma bounce buffers, but that
> is internal to the dma subsystem (and hence does not need to be
> exposed).

There are a few situations where the kernel might actually access a dma_buf:

First of all there are some sensors that add meta data before the actual
pixel data, and a kernel driver might well want to read out that data and
process it. Secondly (and really very similar), video frames sent to/from
an FPGA can also contain meta data (Cisco does that on some of our products)
that the kernel may need to inspect.

I admit that these use-cases aren't very common, but they do exist.

> - Userspace can still access the contents through the exporting
> subsystem (e.g. use some gem mmap support). For efficiency reason gpu
> drivers are already messing around with cache coherency in a platform
> specific way (and hence violated the dma api a bit), so we could stuff
> the mmap coherency in there, too. When we later on extend dma_buf
> support so that other drivers than the gpu can export dma_bufs, we can
> then extend the official dma api with already a few drivers with
> use-patterns around.
> 
> But I still think that the kernel must not be required to enforce
> correct access ordering for the reasons outlined in my other mail.

I agree with Daniel on this.

BTW, the V4L2 subsystem has a clear concept of passing bufffer ownership: the
VIDIOC_QBUF and VIDIOC_DQBUF ioctls deal with that. Pretty much all V4L2 apps 
request the buffers, then mmap them, then call QBUF to give the ownership of 
those buffers to the kernel. While the kernel owns those buffers any access to 
the mmap'ped memory leads to undefined results. Only after calling DQBUF can 
userspace actually safely access that memory.

Allowing mmap() on the dma_buf's fd would actually make things easier for 
V4L2. It's an elegant way of mapping the memory.

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeon stable patches

2011-12-13 Thread Alex Deucher 
Hi Greg,

Can you cherry-pick the following patches back to the stable branches:
b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11
1d33e1fc8dcce667a70387b666a8b6f60153d90f
cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd
They fix the internal panel setup on certain fusion laptops.  I've
attached patches I cherry-picked myself against 3.1.x stable if you'd
prefer that.

Thanks!

Alex
From 3b7c938b4ed246999446a52a5d4c96ff6e652856 Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Tue, 25 Oct 2011 11:34:51 -0400
Subject: [PATCH 1/3] drm/radeon/kms: cleanup atombios_adjust_pll()

The logic was messy and hard to follow.

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |   41 ++-
 1 files changed, 13 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index a515b2a..4901179 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -638,38 +638,23 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
 if (ss_enabled && ss->percentage)
 	args.v3.sInput.ucDispPllConfig |=
 		DISPPLL_CONFIG_SS_ENABLE;
-if (radeon_encoder->devices & (ATOM_DEVICE_DFP_SUPPORT) ||
-radeon_encoder_is_dp_bridge(encoder)) {
+if (encoder_mode == ATOM_ENCODER_MODE_DP) {
+	args.v3.sInput.ucDispPllConfig |=
+		DISPPLL_CONFIG_COHERENT_MODE;
+	/* 16200 or 27000 */
+	args.v3.sInput.usPixelClock = cpu_to_le16(dp_clock / 10);
+} else if (radeon_encoder->devices & (ATOM_DEVICE_DFP_SUPPORT)) {
 	struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
-	if (encoder_mode == ATOM_ENCODER_MODE_DP) {
+	if (encoder_mode == ATOM_ENCODER_MODE_HDMI)
+		/* deep color support */
+		args.v3.sInput.usPixelClock =
+			cpu_to_le16((mode->clock * bpc / 8) / 10);
+	if (dig->coherent_mode)
 		args.v3.sInput.ucDispPllConfig |=
 			DISPPLL_CONFIG_COHERENT_MODE;
-		/* 16200 or 27000 */
-		args.v3.sInput.usPixelClock = cpu_to_le16(dp_clock / 10);
-	} else {
-		if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
-			/* deep color support */
-			args.v3.sInput.usPixelClock =
-cpu_to_le16((mode->clock * bpc / 8) / 10);
-		}
-		if (dig->coherent_mode)
-			args.v3.sInput.ucDispPllConfig |=
-DISPPLL_CONFIG_COHERENT_MODE;
-		if (mode->clock > 165000)
-			args.v3.sInput.ucDispPllConfig |=
-DISPPLL_CONFIG_DUAL_LINK;
-	}
-} else if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
-	if (encoder_mode == ATOM_ENCODER_MODE_DP) {
+	if (mode->clock > 165000)
 		args.v3.sInput.ucDispPllConfig |=
-			DISPPLL_CONFIG_COHERENT_MODE;
-		/* 16200 or 27000 */
-		args.v3.sInput.usPixelClock = cpu_to_le16(dp_clock / 10);
-	} else if (encoder_mode != ATOM_ENCODER_MODE_LVDS) {
-		if (mode->clock > 165000)
-			args.v3.sInput.ucDispPllConfig |=
-DISPPLL_CONFIG_DUAL_LINK;
-	}
+			DISPPLL_CONFIG_DUAL_LINK;
 }
 if (radeon_encoder_is_dp_bridge(encoder)) {
 	struct drm_encoder *ext_encoder = radeon_atom_get_external_encoder(encoder);
-- 
1.7.3.4

From 2afee838ac228bfca544951b6059032a50ef7f1d Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Mon, 31 Oct 2011 08:58:47 -0400
Subject: [PATCH 2/3] drm/radeon/kms: rework DP bridge checks

Return the encoder id rather than a boolean.  This is needed
for differentiate between multiple DP bridge chips.

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |   12 ++--
 drivers/gpu/drm/radeon/atombios_dp.c   |6 --
 drivers/gpu/drm/radeon/radeon_connectors.c |   16 +++-
 drivers/gpu/drm/radeon/radeon_display.c|3 ++-
 drivers/gpu/drm/radeon/radeon_encoders.c   |   11 ++-
 drivers/gpu/drm/radeon/radeon_mode.h   |4 ++--
 6 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 4901179..9bb3d6f 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -558,7 +558,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
 bpc = connector->display_info.bpc;
 			encoder_mode = atombios_get_encoder_mode(encoder);
 			if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
-			radeon_encoder_is_dp_bridge(encoder)) {
+			(radeon_encoder_get_dp_bridge_encoder_id(encoder) != ENCODER_OBJECT_ID_NONE)) {
 if (connector) {
 	struct radeon_connector *radeon_connector = to_radeon_connector(connector);
 	struct radeon_connector_atom_dig *dig_connector =
@@ -656,11 +656,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
 		args.v3.sInput.ucDispPllConfig |=
 			DISPPLL_CONFIG_DUAL_LINK;
 }
-if (radeon_encoder_is_dp_bridge(encoder)) {
-	struct drm_encoder *ex

[PATCH] radeon: Set macrotile shape on Evergreen hardware

2011-12-13 Thread Simon Farnsworth 
Evergreen and later Radeons let the driver choose a macro tile layout,
within certain constraints. If we don't set the appropriate fields
correctly, the card will use a layout that doesn't normally meet the
constraints on Evergreen tiling.

For now, select 8x8 aspect 1 macrotiles, as this makes it possible to
guarantee that we meet the hardware constraints. Once macrotiling is
reliable, we can consider a better API to let us exploit the hardware
capabilities.

Signed-off-by: Simon Farnsworth 
---

This doesn't fix my problems with enabling macro tiling, but it does help
somewhat. I also need to fix alignment in the DDX and Mesa to avoid
misrendering, at which point I see CP lockups instead.

I'm therefore sending this, the DDX patch, and the Mesa patch out in order
to avoid getting stuck in a world where I have an 80% fix, someone else has
an 80% fix, and if only we talked, we'd have a 100% fix.

 drivers/gpu/drm/radeon/atombios_crtc.c |4 
 drivers/gpu/drm/radeon/evergreen_cs.c  |9 +
 drivers/gpu/drm/radeon/evergreend.h|7 +++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 2b97262..f982975 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1113,6 +1113,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
else
tmp = rdev->config.evergreen.tile_config;
 
+   fb_format |= 
(EVERGREEN_GRPH_BANK_HEIGHT(EVERGREEN_ADDR_SURF_BANK_HEIGHT_8) |
+ 
EVERGREEN_GRPH_BANK_WIDTH(EVERGREEN_ADDR_SURF_BANK_WIDTH_8) |
+ 
EVERGREEN_GRPH_MACRO_TILE_ASPECT(EVERGREEN_ADDR_SURF_MACRO_TILE_ASPECT_1));
+
switch ((tmp & 0xf0) >> 4) {
case 0: /* 4 banks */
fb_format |= 
EVERGREEN_GRPH_NUM_BANKS(EVERGREEN_ADDR_SURF_4_BANK);
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index b53d1c6..a14a04e 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -532,6 +532,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
ib[idx] |= 
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
track->db_z_info |= 
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
+   ib[idx] |= 
(DB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
+   
DB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
+   
DB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
ib[idx] |= 
DB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
ib[idx] |= 
DB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
}
@@ -736,6 +739,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
return -EINVAL;
}
if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
+   ib[idx] |= (CB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
+   CB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
+   
CB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
ib[idx] |= 
CB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
ib[idx] |= 
CB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
}
@@ -1360,6 +1366,9 @@ static int evergreen_packet3_check(struct 
radeon_cs_parser *p,
if (reloc->lobj.tiling_flags & 
RADEON_TILING_MACRO) {
ib[idx+1+(i*8)+6] |= 
TEX_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
ib[idx+1+(i*8)+7] |= 
TEX_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
+   ib[idx+1+(i*8)+8] |= 
(TEX_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
+ 
TEX_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
+ 
TEX_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
}
}
texture = reloc->robj;
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index e00039e..3731e8f 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -903,6 +903,7 @@
 #   define DB_NUM_BANKS(x)  (((x) & 0x3) << 12)
 #

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

2011-12-13 Thread Arnd Bergmann 
On Monday 12 December 2011, Robert Morell wrote:
> > 
> > Doing a buffer sharing with something that is not GPL is not fun, as, if any
> > issue rises there, it would be impossible to discover if the problem is 
> > either
> > at the closed-source driver or at the open source one. At the time I was 
> > using
> > the Nvidia proprietary driver, it was very common to have unexplained issues
> > caused likely by bad code there at the buffer management code, causing X
> > applications and extensions (like xv) to break.
> >
> > We should really make this EXPORT_SYMBOL_GPL(), in order to be able to 
> > latter
> > debug future share buffer issues, when needed.
> 
> Sorry, I don't buy this argument.  Making these exports GPL-only is not
> likely to cause anybody to open-source their driver, but will rather
> just cause them to use yet more closed-source code that is even less
> debuggable than this would be, to those without access to the source.

But at least the broken module then won't be interacting with other modules
because it cannot share any buffers.

Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] radeon: Set macrotile shape on Evergreen hardware

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 03:08:53PM +, Simon Farnsworth wrote:
> Evergreen and later Radeons let the driver choose a macro tile layout,
> within certain constraints. If we don't set the appropriate fields
> correctly, the card will use a layout that doesn't normally meet the
> constraints on Evergreen tiling.
> 
> For now, select 8x8 aspect 1 macrotiles, as this makes it possible to
> guarantee that we meet the hardware constraints. Once macrotiling is
> reliable, we can consider a better API to let us exploit the hardware
> capabilities.
> 
> Signed-off-by: Simon Farnsworth 

NAK

We don't want to enforce those value in kernel. I am working on fixing
tiling accross the stack and such patch would only hurt us in the
future.

Cheers,
Jerome

> ---
> 
> This doesn't fix my problems with enabling macro tiling, but it does help
> somewhat. I also need to fix alignment in the DDX and Mesa to avoid
> misrendering, at which point I see CP lockups instead.
> 
> I'm therefore sending this, the DDX patch, and the Mesa patch out in order
> to avoid getting stuck in a world where I have an 80% fix, someone else has
> an 80% fix, and if only we talked, we'd have a 100% fix.
> 
>  drivers/gpu/drm/radeon/atombios_crtc.c |4 
>  drivers/gpu/drm/radeon/evergreen_cs.c  |9 +
>  drivers/gpu/drm/radeon/evergreend.h|7 +++
>  3 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index 2b97262..f982975 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -1113,6 +1113,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
>   else
>   tmp = rdev->config.evergreen.tile_config;
>  
> + fb_format |= 
> (EVERGREEN_GRPH_BANK_HEIGHT(EVERGREEN_ADDR_SURF_BANK_HEIGHT_8) |
> +   
> EVERGREEN_GRPH_BANK_WIDTH(EVERGREEN_ADDR_SURF_BANK_WIDTH_8) |
> +   
> EVERGREEN_GRPH_MACRO_TILE_ASPECT(EVERGREEN_ADDR_SURF_MACRO_TILE_ASPECT_1));
> +
>   switch ((tmp & 0xf0) >> 4) {
>   case 0: /* 4 banks */
>   fb_format |= 
> EVERGREEN_GRPH_NUM_BANKS(EVERGREEN_ADDR_SURF_4_BANK);
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index b53d1c6..a14a04e 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -532,6 +532,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
> *p, u32 reg, u32 idx)
>   ib[idx] |= 
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
>   track->db_z_info |= 
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
>   if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
> + ib[idx] |= 
> (DB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
> + 
> DB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
> + 
> DB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
>   ib[idx] |= 
> DB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
>   ib[idx] |= 
> DB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
>   }
> @@ -736,6 +739,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
> *p, u32 reg, u32 idx)
>   return -EINVAL;
>   }
>   if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
> + ib[idx] |= (CB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
> + CB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
> + 
> CB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
>   ib[idx] |= 
> CB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
>   ib[idx] |= 
> CB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
>   }
> @@ -1360,6 +1366,9 @@ static int evergreen_packet3_check(struct 
> radeon_cs_parser *p,
>   if (reloc->lobj.tiling_flags & 
> RADEON_TILING_MACRO) {
>   ib[idx+1+(i*8)+6] |= 
> TEX_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
>   ib[idx+1+(i*8)+7] |= 
> TEX_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
> + ib[idx+1+(i*8)+8] |= 
> (TEX_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
> +   
> TEX_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
> +   
> TEX_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
>   }
>

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread Jerome Glisse 
On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> Jerome pointed me to some accounting error in the DMA API debugging code and
> while I can't figure it out yet, I did notice some extreme slowness - which
> is due to the nouveau driver calling the unpopulate (now that unbind +
> unpopulate are squashed) quite a lot (this is using Gnome Shell - I think 
> GNOME2
> did not have those issues but I can't recall).
> 
> Anyhow these patches fix the 50% perf regression I saw and also some minor 
> bugs
> that I noticed.
> 

Gonna review those today and test them.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Enable reading 3D capabilities of 3D monitor

2011-12-13 Thread Adam Jackson 
On Fri, 2011-12-09 at 11:46 +, Kavuri, Sateesh wrote:

> + if ((multi_val == STRUCTURE_PRESENT) || 
> + (multi_val == STRUCTURE_MASK_PRESENT) ) {
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x01) == 
> 0x01)
> + caps->format |= 0x0; /* FRAME_PACKING */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x02) == 
> 0x02)
> + caps->format |= 0x1; 
> /*FIELD_ALTERNATIVE */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x04) == 
> 0x04)
> + caps->format |= 0x2; /* 
> LINE_ALTERNATIVE */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x08) == 
> 0x08)
> + caps->format |= 0x3; 
> /*SIDE_BY_SIDE_FULL */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x10) == 
> 0x10)
> + caps->format |= 0x4; /* L_DEPTH */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x20) == 
> 0x20)
> + caps->format |= 0x5; /* 
> L_DEPTH_GFX_GFX_DEPTH */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x40) == 
> 0x40)
> + caps->format |= 0x6; /* TOP_BOTTOM */
> + if ((edid_ext[i+14+hdmi_vic_len] & 0x01) == 
> 0x01)
> + caps->format |= 0x7; /* S_BY_S_HALF */
> + if ((edid_ext[i+14+hdmi_vic_len] & 0x80) == 
> 0x80)
> + caps->format |= 0x8; /* 
> S_BY_S_HALF_QUINCUNX */
> + }

This reads poorly, which makes me think it's wrong.  Is format supposed
to be a bitfield or an enum?

> +EXPORT_SYMBOL(drm_detect_3D_monitor);

I suspect this is poorly named.  There exist 3D displays which are not
HDMI.

> +#define VSIF_RESET_INDEX 0xFFF8
> +#define VSIF_RESET_BIT_22 0xFFBF
> +#define VSIF_SET_BIT_19 0x8
> +#define VSIF_RESET_BIT_20 0xFFEF
> +#define VSIF_RESET_BIT_17 0x1
> +#define VSIF_SET_BIT_16 0xFFFD
> +#define VSIF_SET_MASTER_BIT 0x40

i915 style is usually to write these as (1 << 22) I think.

More importantly, use semantic names for register contents.  "Bit 17"
doesn't mean anything.

> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8020798..5b4d09c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -798,6 +798,8 @@ extern int drm_mode_gamma_set_ioctl(struct drm_device 
> *dev,
>  extern u8 *drm_find_cea_extension(struct edid *edid);
>  extern bool drm_detect_hdmi_monitor(struct edid *edid);
>  extern bool drm_detect_monitor_audio(struct edid *edid);
> +extern bool drm_detect_3D_monitor(struct edid *edid);
> +//extern struct panel_3d_caps* drm_detect_3D_monitor(struct edid *edid);

Well, which is it?

> +enum s3d_formats {
> + FRAME_PACKING   = 0x0,
> + FIELD_ALTERNATIVE   = 0x1,
> + LINE_ALTERNATIVE= 0x2,
> + SIDE_BY_SIDE_FULL   = 0x3,
> + L_DEPTH = 0x4,
> + L_DEPTH_GFX_GFX_DEPTH   = 0x5,
> + TOP_BOTTOM  = 0x6, /* 0x7 is reserved for future */
> + SIDE_BY_SIDE_HALF   = 0x8  /* 0x9 onwards is reserved for future */
> +};

If format is supposed to be an enum, why aren't you using these symbolic
values?

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread Thomas Hellstrom 

On 12/13/2011 05:07 PM, Jerome Glisse wrote:

On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
   

Jerome pointed me to some accounting error in the DMA API debugging code and
while I can't figure it out yet, I did notice some extreme slowness - which
is due to the nouveau driver calling the unpopulate (now that unbind +
unpopulate are squashed) quite a lot (this is using Gnome Shell - I think GNOME2
did not have those issues but I can't recall).

Anyhow these patches fix the 50% perf regression I saw and also some minor bugs
that I noticed.

 

Gonna review those today and test them.

Cheers,
Jerome
   

Hi!

I'm not whether any drivers are still using the AGP backend?
Calling unpopulate / (previous clear) each time unbind is done should be 
quite
inefficient with that one, as AGP sets up its own data structures and 
copies page tables
on each populate. That should really be avoided unless there is a good 
reason to have it.


/Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread Konrad Rzeszutek Wilk 
On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> >>Jerome pointed me to some accounting error in the DMA API debugging code and
> >>while I can't figure it out yet, I did notice some extreme slowness - which
> >>is due to the nouveau driver calling the unpopulate (now that unbind +
> >>unpopulate are squashed) quite a lot (this is using Gnome Shell - I think 
> >>GNOME2
> >>did not have those issues but I can't recall).
> >>
> >>Anyhow these patches fix the 50% perf regression I saw and also some minor 
> >>bugs
> >>that I noticed.
> >>
> >Gonna review those today and test them.
> >
> >Cheers,
> >Jerome
> Hi!
> 
> I'm not whether any drivers are still using the AGP backend?

Uh, probably they do if the cards are AGP?
The problem I encountered was with an PCIe Nvidia card:

01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce 8600 GT] 
(rev a1

> Calling unpopulate / (previous clear) each time unbind is done
> should be quite
> inefficient with that one, as AGP sets up its own data structures
> and copies page tables
> on each populate. That should really be avoided unless there is a
> good reason to have it.

nouveau_bo_rd32 and nv50_crtc_cursor_set showed up as the callers that
were causing the unpopulate calls. It did happen _a lot_ when I moved the
cursor madly.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Keith Packard 
On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villací­s Lasso 
 wrote:

> By using a bootable USB stick, I could check the logs, which
> showed many segfaults at /lib64/ld-2.14.90.so .

Ouch!

Please let me know if you find anything further; I'd like to get a
revert sent upstream in the next day or so.

-- 
keith.pack...@intel.com


pgp0AfIuEPsW3.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Daniel Vetter 
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villací­s Lasso 
>  wrote:
> 
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
> 
> Ouch!
> 
> Please let me know if you find anything further; I'd like to get a
> revert sent upstream in the next day or so.

I think the revert is trtd. But if you revert it, please also
revert/disable the ilk vt-d workaound or apply one of Ben's patches,
because that one _does_ blow up, too.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/23] kill drm cruft with fire

2011-12-13 Thread Daniel Vetter 
On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote:
> 
> > > >> Testing this on via would be awesome! Iirc I haven't changed anything 
> > > >> in
> > > >> the via specific patches, but if it's more convenient you can also
> > > >> directly test my branch:
> > > >>
> > > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire
> > > >
> > > > Okay I tried the patches and it locked up the openchrome X server. I'm
> > > > going to try your branch tonight to see if it makes any difference. If 
> > > > it
> > > > still fails I will have to track down what the problem is.
> > >
> > > If you can bisect the issue, that would be awesome. Meanwhile my sis
> > > card arrived, so I'm hopefully get around to test that part of the
> > > series rsn. I'm traveling atm though, so response time will suffer a
> > > bit.
> > 
> > Any updates on testing results?
> 
> Yes I do. I'm using the patches you posted. Patches 1 to 10 work with no 
> problems. Ist patch 11 that breaks the openchrome xorg driver. Have to 
> do some digging to find the exact problem.

Thanks a lot for digging through these patches. As you've noted in patch
11, I don't set release_idlelock anywhere which results in the via driver
deadlocking when clients close. The same holds for the equivalent sis
patch. Updated patch series pushed to my kill-with-fire branch. Please
test and yell at me if it's still broken.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Daniel Vetter 
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villací­s Lasso 
>  wrote:
> 
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
> 
> Ouch!
> 
> Please let me know if you find anything further; I'd like to get a
> revert sent upstream in the next day or so.

Another patch to try is "drm/i915: Only clear the GPU domains upon a
successful finish" from the my-next branch available at:

http://cgit.freedesktop.org/~danvet/drm/log/?h=my-next

Or just the raw patch:

http://cgit.freedesktop.org/~danvet/drm/patch/?id=389a55581e30607af0fcde6cdb4e54f189cf46cf

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_edid: support CEA video modes

2011-12-13 Thread Jesse Barnes 
On Sun, 13 Nov 2011 01:31:35 +0100
Christian Schmidt  wrote:

> TFT/plasma televisions and projectors have become commonplace, and so
> has the use of PCs to drive them. Add the video modes specified by an
> EDID's CEA extension to the mode database for a connector.

Dave, Christian has a few patches outstanding for CEA mode handling.
Getting them in makes sense to me and this patch looks like it's
structured nicely at least (I haven't checked the CEA bits against the
specs though).

Any chance we can get them included for 3.3?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Alex Villací­s Lasso 

El 12/12/11 11:41, Keith Packard escribió:

On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villací­s 
Lasso  wrote:


Ran kernel with reverted patch for 6 hours without issues so far. Will
keep testing after work (issue happens with my home machine).

Thanks much. Let me know if it's still stable this evening; I can send a
revert along if you don't find any problems.


I just had a severe problem, but I am not sure if the patch (or its revert) is 
at fault.

I was running 3.2-rc5 at home, for an hour or so, when suddenly I could not launch any programs. I tried switching to the text console, but the login program restarted itself after typing "root", without waiting for the password. I then tried to reboot, 
but all of the installed kernels (even the stock Fedora ones) issued a kernel panic very early in the boot sequence, mentioning an attempt to kill init. By using a bootable USB stick, I could check the logs, which showed many segfaults at 
/lib64/ld-2.14.90.so . Even though running fsck -f on my / and /boot partitions (both ext4) showed no errors besides an unclean shutdown, the kernel panics on boot persisted. I eventually reinstalled the system from scratch, and kept my /home partition so 
that no important data was lost. I am still in the process of restoring my package list to the state before the crash.


Maybe the list corruption I experienced earlier was secondary damage, which now 
spread somewhere else and corrupted system files, but I do not have enough data 
to check this.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread batouzo 

(Send similar post to LKML / linux.kernel but no responses there yet)

Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.

Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
drm_vblank_cleanup+0x78/0x90 [drm]
Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
drm_vblank_cleanup+0x48/0x90 [drm]

It is Amd Bulldozer computer, with Radeon card:
01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
[Radeon HD 5450]

Debian stable. Builded with make-kpkg using gcc 4.4.5

   messages: http://pastebin.com/NXN5EPtG
config used: http://pastebin.com/AeVxEX7c


With radeon + kms the bug happens around 1 in 3 boot ups, right after
the radeon is enabled (with slub debugging) or later with no debug (few
seconds later or on shutdown esp. in rmmod).

When disabling radeon and KMS the bug was not seen;


Please fix this bug :) What to test to help fixing it?


Interesting part of the messages linked above is:


[   94.401991] fb0: radeondrmfb frame buffer device
[   94.401992] drm: registered panic notifier
[   94.402033] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0
on minor 0
[   94.402921]
=
[   94.402961] BUG kmalloc-16: Poison overwritten
[   94.402982]
-
[   94.402983]
[   94.403025] INFO: 0x880137dbbc38-0x880137dbbc3b. First byte
0x0 instead of 0x6b
[   94.403066] INFO: Allocated in drm_vblank_init+0x139/0x260 [drm]
age=253 cpu=3 pid=535
[   94.403103]  set_track+0x58/0x100
[   94.403119]  alloc_debug_processing+0x160/0x170
[   94.403140]  __slab_alloc+0x26d/0x440
[   94.403160]  drm_vblank_init+0x139/0x260 [drm]
[   94.403182]  drm_debugfs_create_files+0xcb/0x1a0 [drm]
[   94.403208]  drm_vblank_init+0x139/0x260 [drm]
[   94.403228]  __kmalloc+0x100/0x180
[   94.403247]  drm_vblank_init+0x139/0x260 [drm]
[   94.403276]  radeon_irq_kms_init+0x6d/0x160 [radeon]
[   94.403303]  evergreen_init+0x11c/0x2a0 [radeon]
[   94.403337]  radeon_device_init+0x3c9/0x470 [radeon]
[   94.403367]  radeon_driver_load_kms+0xad/0x160 [radeon]
[   94.403394]  drm_get_pci_dev+0x198/0x2c0 [drm]
[   94.403416]  local_pci_probe+0x55/0xd0
[   94.403433]  pci_device_probe+0x10a/0x130
[   94.403453]  driver_sysfs_add+0x72/0xa0
[   94.403474] INFO: Freed in drm_vblank_cleanup+0x78/0x90 [drm] age=235
cpu=0 pid=535
[   94.403508]  set_track+0x58/0x100
[   94.403524]  free_debug_processing+0x1f3/0x240
[   94.403545]  __slab_free+0x1a6/0x2b0
[   94.403562]  native_read_tsc+0x2/0x20
[   94.403580]  delay_tsc+0x42/0x80
[   94.403598]  drm_vblank_cleanup+0x78/0x90 [drm]
[   94.403625]  radeon_irq_kms_fini+0xd/0x60 [radeon]
[   94.403651]  evergreen_init+0x289/0x2a0 [radeon]
[   94.403677]  radeon_device_init+0x3c9/0x470 [radeon]
[   94.403704]  radeon_driver_load_kms+0xad/0x160 [radeon]
[   94.403731]  drm_get_pci_dev+0x198/0x2c0 [drm]
[   94.403751]  local_pci_probe+0x55/0xd0
[   94.403772]  pci_device_probe+0x10a/0x130
[   94.403791]  driver_sysfs_add+0x72/0xa0
[   94.404806]  driver_probe_device+0x8e/0x1b0
[   94.405782]  __driver_attach+0x93/0xa0
[   94.406031] INFO: Slab 0xea0004df6e80 objects=23 used=23 fp=0x
   (null) flags=0x2004080
[   94.406031] INFO: Object 0x880137dbbc38 @offset=7224
fp=0x880137dbb830
[   94.406031]
[   94.406031] Bytes b4 0x880137dbbc28:  06 0e ff ff 00 00 00 00 5a
5a 5a 5a 5a 5a 5a 5a ..��
[   94.406031]   Object 0x880137dbbc38:  00 00 00 00 6b 6b 6b 6b 6b
6b 6b 6b 6b 6b 6b a5 kkk�
[   94.406031]  Redzone 0x880137dbbc48:  bb bb bb bb bb bb bb bb
 
[   94.406031]  Padding 0x880137dbbd88:  5a 5a 5a 5a 5a 5a 5a 5a
 
[   94.406031] Pid: 466, comm: udevd Not tainted 3.1.4-norm007+dbg #1
[   94.406031] Call Trace:
[   94.406031]  [] ? check_bytes_and_report+0x110/0x150
[   94.406031]  [] ? check_object+0x1fe/0x250
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? alloc_debug_processing+0xee/0x170
[   94.406031]  [] ? __slab_alloc+0x26d/0x440
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? inode_init_always+0xfc/0x1b0
[   94.406031]  [] ? alloc_inode+0x32/0x90
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? __kmalloc_track_caller+0xf8/0x180
[   94.406031]  [] ? kmemdup+0x27/0x60
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? vfs_symlink+0x87/0xa0
[   94.406031]  [] ? sys_symlinkat+0xdc/0xf0
[   94.406031]  [] ? system_call_fastpath+0x16/0x1b
[   94.406031] FIX kmalloc-16: Restoring
0x880137dbbc38-0x880137dbbc3b=0x6b


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread James Simmons 

> Hi!
> 
> I'm not whether any drivers are still using the AGP backend?

Actually the openchrome projects KMS kernel uses a AGP backend.


> Calling unpopulate / (previous clear) each time unbind is done should be quite
> inefficient with that one, as AGP sets up its own data structures and copies
> page tables
> on each populate. That should really be avoided unless there is a good reason
> to have it.
> 
> /Thomas
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon stable patches

2011-12-13 Thread Greg KH 
On Tue, Dec 13, 2011 at 09:29:58AM -0500, Alex Deucher wrote:
> Hi Greg,
> 
> Can you cherry-pick the following patches back to the stable branches:
> b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11
> 1d33e1fc8dcce667a70387b666a8b6f60153d90f
> cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd
> They fix the internal panel setup on certain fusion laptops.  I've
> attached patches I cherry-picked myself against 3.1.x stable if you'd
> prefer that.

Thanks, all now applied.

Note, the email for stable has changed to sta...@vger.kernel.org,
sta...@kernel.org has been dead since August.

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Patches queued to drm-intel-fixes

2011-12-13 Thread Daniel Vetter 
Hi Keith,

I've noticed that you merged my patch "rm/i915: properly prefault for
pread/pwrite" into your -fixes branch (which I assume is headed for
3.2). Please remove that from your queue again for the following
reasons:

- The right thing to do is to fix up the prefault handlers in pagemap.h
- It's really ugly code (which Chris Wilson later on complained
about), so ugly actually that it confused you while reviewing it.
- It changes the semantics of pread/pwrite in funny ways (something
you actually complained about in review a while ago, too).
- This bug has been lying around for almost half a year already, so I
don't see the need for a rush now.
- It only papers over the underlying issue, the real minimal and
proper fix is queued up (and reviewed) in my-next in my own git repo
for 3.3.
- I actually managed to blow things up while playing with the prefault
stuff, so it's imo not really risk-free.
- But most important this late in the -rc cylce: It doesn't fix a regression.

I've also noticed that you have my patch "drm/i915: check ACTHD of all
rings" queued up in -fixes. I wouldn't have minded this getting merged
a few weeks ago into an early -rc but again I think it's too late for
this one for the following reasons:
- It touches on the hangcheck code, one of the most important pieces
to be able to debug issues and hence support users of our driver, but
also one of the least tested ones (we essentially only test it when
hitting actual hangs).
- A similar patch by Ben Widawsky actually blew things up for Chris Wilson.
- Again it doesn't fix a regression.

Dave, please reject a pull request for 3.2 containing these patches -
I've already embarrassed myself with the vt-d oneliner (which should
imo have been merged about 4 weeks ago, but mea culpa).

Yours, Daniel
-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Patches queued to drm-intel-fixes

2011-12-13 Thread Keith Packard 
On Wed, 14 Dec 2011 00:04:26 +0100, Daniel Vetter  
wrote:
> Hi Keith,
> 
> I've noticed that you merged my patch "rm/i915: properly prefault for
> pread/pwrite" into your -fixes branch (which I assume is headed for
> 3.2). Please remove that from your queue again for the following
> reasons:

Thanks! I'll rework the patch series before submitting it.

-- 
keith.pack...@intel.com


pgpCWhWutxFgL.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 10:26:15PM +0100, batouzo wrote:
> 
> (Send similar post to LKML / linux.kernel but no responses there yet)
> 
> Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
> 
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x78/0x90 [drm]
> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x48/0x90 [drm]
> 
> It is Amd Bulldozer computer, with Radeon card:
> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
> [Radeon HD 5450]
> 
> Debian stable. Builded with make-kpkg using gcc 4.4.5
> 
>messages: http://pastebin.com/NXN5EPtG
> config used: http://pastebin.com/AeVxEX7c
> 
> 
> With radeon + kms the bug happens around 1 in 3 boot ups, right after
> the radeon is enabled (with slub debugging) or later with no debug (few
> seconds later or on shutdown esp. in rmmod).
> 
> When disabling radeon and KMS the bug was not seen;
> 
> 
> Please fix this bug :) What to test to help fixing it?
> 
> 
> Interesting part of the messages linked above is:
> 

Do you boot your kernel with kexec ? Does the patch help :

http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch

If not please open bug on bugs.freedesktop.org against radeon driver.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread batouzo 
On 12/14/2011 12:31 AM, Jerome Glisse wrote:

>> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
>> drm_vblank_cleanup+0x78/0x90 [drm]
>> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
>> drm_vblank_cleanup+0x48/0x90 [drm]
>>
>> It is Amd Bulldozer computer, with Radeon card:
>> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
>> [Radeon HD 5450]
>>
>>messages: http://pastebin.com/NXN5EPtG
>> config used: http://pastebin.com/AeVxEX7c

> 
> Do you boot your kernel with kexec ? Does the patch help :

Nope. Already seen that kexec bugfix on LKML but I start system normally
not with kexec.

> http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch
> If not please open bug on bugs.freedesktop.org against radeon driver.

ok

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 6:33 PM, batouzo  wrote:
> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>
>>> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
>>> drm_vblank_cleanup+0x78/0x90 [drm]
>>> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
>>> drm_vblank_cleanup+0x48/0x90 [drm]
>>>
>>> It is Amd Bulldozer computer, with Radeon card:
>>> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
>>> [Radeon HD 5450]
>>>
>>>    messages: http://pastebin.com/NXN5EPtG
>>> config used: http://pastebin.com/AeVxEX7c
>
>>
>> Do you boot your kernel with kexec ? Does the patch help :
>
> Nope. Already seen that kexec bugfix on LKML but I start system normally
> not with kexec.
>
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch
>> If not please open bug on bugs.freedesktop.org against radeon driver.
>
> ok
>

Note that this patch might also help non kexec case.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse  wrote:
> On Tue, Dec 13, 2011 at 6:33 PM, batouzo  wrote:
>> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>>
 Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
 drm_vblank_cleanup+0x78/0x90 [drm]
 Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
 drm_vblank_cleanup+0x48/0x90 [drm]

 It is Amd Bulldozer computer, with Radeon card:
 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
 [Radeon HD 5450]

    messages: http://pastebin.com/NXN5EPtG
 config used: http://pastebin.com/AeVxEX7c
>>
>>>
>>> Do you boot your kernel with kexec ? Does the patch help :
>>
>> Nope. Already seen that kexec bugfix on LKML but I start system normally
>> not with kexec.
>>
>>> http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch
>>> If not please open bug on bugs.freedesktop.org against radeon driver.
>>
>> ok
>>
>
> Note that this patch might also help non kexec case.
>
> Cheers,
> Jerome

Oh and try booting with radeon.no_wb=1

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

2011-12-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=43655

--- Comment #4 from Alexandre Demers  2011-12-13 
17:48:47 PST ---
Strangely, when rebisecting, I found commit
a34815b96f9a21b3a2e2912dfd0d994acd2855e3 to be the bad one... It is really near
to the first one. So, I'm retesting both to be sure.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/omap: drm API update: addfb2

2011-12-13 Thread Rob Clark 
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH  wrote:
> On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> Update to reflect changes in:
>> "drm: add an fb creation ioctl that takes a pixel format v5"
>
> This one I'm going to have to wait for the drm api merges to happen, so
> I'll just wait for them to go into Linus's tree before taking them, ok?

oh, heh.. I found a couple small cleanups to this patch (adding a
"const" to a table, and such).. since this can't be applied until
drm-next is merged, if you don't mind I'd like to resend this one in a
patchset along with the patches adding drm_plane support, which I'm
pretty close to ready to send.

BR,
-R

> thanks,
>
> greg k-h
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: disconnect plane from fb/crtc when disabled

2011-12-13 Thread Rob Clark 
From: Rob Clark 

Since plane->fb and plane->crtc are set in drm_mode_setplane()
after update_plane(), They should be cleared after disable().

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e2c9386..6dad421 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -348,6 +348,9 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
ret = plane->funcs->disable_plane(plane);
if (ret)
DRM_ERROR("failed to disable plane with busy 
fb\n");
+   /* disconnect the plane from the fb and crtc: */
+   plane->fb = NULL;
+   plane->crtc = NULL;
}
}
 
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: add support for private planes

2011-12-13 Thread Rob Clark 
From: Rob Clark 

In cases where the scanout hw is sufficiently similar between "overlay"
and traditional crtc layers, it might be convenient to allow the driver
to create internal drm_plane helper objects used by the drm_crtc
implementation, rather than duplicate code between the plane and crtc.
A private plane is not exposed to userspace.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c |   22 +-
 include/drm/drm_crtc.h |3 ++-
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6dad421..d73746e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -557,7 +557,8 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
 int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
   unsigned long possible_crtcs,
   const struct drm_plane_funcs *funcs,
-  uint32_t *formats, uint32_t format_count)
+  const uint32_t *formats, uint32_t format_count,
+  bool priv)
 {
mutex_lock(&dev->mode_config.mutex);
 
@@ -576,8 +577,16 @@ int drm_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;
 
-   list_add_tail(&plane->head, &dev->mode_config.plane_list);
-   dev->mode_config.num_plane++;
+   /* private planes are not exposed to userspace, but depending on
+* display hardware, might be convenient to allow sharing programming
+* for the scanout engine with the crtc implementation.
+*/
+   if (!priv) {
+   list_add_tail(&plane->head, &dev->mode_config.plane_list);
+   dev->mode_config.num_plane++;
+   } else {
+   INIT_LIST_HEAD(&plane->head);
+   }
 
mutex_unlock(&dev->mode_config.mutex);
 
@@ -592,8 +601,11 @@ void drm_plane_cleanup(struct drm_plane *plane)
mutex_lock(&dev->mode_config.mutex);
kfree(plane->format_types);
drm_mode_object_put(dev, &plane->base);
-   list_del(&plane->head);
-   dev->mode_config.num_plane--;
+   /* if not added to a list, it must be a private plane */
+   if (!list_empty(&plane->head)) {
+   list_del(&plane->head);
+   dev->mode_config.num_plane--;
+   }
mutex_unlock(&dev->mode_config.mutex);
 }
 EXPORT_SYMBOL(drm_plane_cleanup);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index dd55727..1354ef5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -828,7 +828,8 @@ extern int drm_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
  unsigned long possible_crtcs,
  const struct drm_plane_funcs *funcs,
- uint32_t *formats, uint32_t format_count);
+ const uint32_t *formats, uint32_t format_count,
+ bool private);
 extern void drm_plane_cleanup(struct drm_plane *plane);
 
 extern void drm_encoder_cleanup(struct drm_encoder *encoder);
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] modetest: add drm_plane support

2011-12-13 Thread Rob Clark 
From: Rob Clark 

Signed-off-by: Rob Clark 
---
 tests/modetest/modetest.c |  166 ++---
 1 files changed, 157 insertions(+), 9 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..22ac620 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -51,6 +51,7 @@
 
 #include "xf86drm.h"
 #include "xf86drmMode.h"
+#include "drm_fourcc.h"
 #include "libkms.h"
 
 #ifdef HAVE_CAIRO
@@ -267,6 +268,49 @@ void dump_framebuffers(void)
printf("\n");
 }
 
+static void dump_planes(void)
+{
+   drmModePlaneRes *plane_resources;
+   drmModePlane *ovr;
+   int i, j;
+
+   plane_resources = drmModeGetPlaneResources(fd);
+   if (!plane_resources) {
+   fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+   strerror(errno));
+   return;
+   }
+
+   printf("Planes:\n");
+   printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n");
+   for (i = 0; i < plane_resources->count_planes; i++) {
+   ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+   if (!ovr) {
+   fprintf(stderr, "drmModeGetPlane failed: %s\n",
+   strerror(errno));
+   continue;
+   }
+
+   printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n",
+  ovr->plane_id, ovr->crtc_id, ovr->fb_id,
+  ovr->crtc_x, ovr->crtc_y, ovr->x, ovr->y,
+  ovr->gamma_size);
+
+   if (!ovr->count_formats)
+   continue;
+
+   printf("  formats:");
+   for (j = 0; j < ovr->count_formats; j++)
+   printf(" %4.4s", (char *)&ovr->formats[j]);
+   printf("\n");
+
+   drmModeFreePlane(ovr);
+   }
+   printf("\n");
+
+   return;
+}
+
 /*
  * Mode setting with the kernel interfaces is a bit of a chore.
  * First you have to find the connector in question and make sure the
@@ -280,11 +324,18 @@ struct connector {
drmModeModeInfo *mode;
drmModeEncoder *encoder;
int crtc;
+   int pipe;
unsigned int fb_id[2], current_fb_id;
struct timeval start;
 
int swap_count;
-}; 
+};
+
+struct plane {
+   uint32_t con_id;  /* the id of connector to bind to */
+   uint32_t w, h;
+   unsigned int fb_id;
+};
 
 static void
 connector_find_mode(struct connector *c)
@@ -351,6 +402,15 @@ connector_find_mode(struct connector *c)
 
if (c->crtc == -1)
c->crtc = c->encoder->crtc_id;
+
+   /* and figure out which crtc index it is: */
+   for (i = 0; i < resources->count_crtcs; i++) {
+   if (c->crtc == resources->crtcs[i]) {
+   c->pipe = i;
+   break;
+   }
+   }
+
 }
 
 static struct kms_bo *
@@ -534,13 +594,83 @@ page_flip_handler(int fd, unsigned int frame,
}
 }
 
+static int
+set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
+{
+   drmModePlaneRes *plane_resources;
+   drmModePlane *ovr;
+   uint32_t handles[4], pitches[4], offsets[4]; /* we only use [0] */
+   uint32_t plane_id = 0;
+   struct kms_bo *plane_bo;
+   uint32_t plane_flags = 0;
+   int i, crtc_x, crtc_y, crtc_w, crtc_h;
+
+   /* find an unused plane which can be connected to our crtc */
+   plane_resources = drmModeGetPlaneResources(fd);
+   if (!plane_resources) {
+   fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+   strerror(errno));
+   return -1;
+   }
+
+   for (i = 0; i < plane_resources->count_planes && !plane_id; i++) {
+   ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+   if (!ovr) {
+   fprintf(stderr, "drmModeGetPlane failed: %s\n",
+   strerror(errno));
+   return -1;
+   }
+
+   if ((ovr->possible_crtcs & (1 << c->pipe)) && !ovr->crtc_id)
+   plane_id = ovr->plane_id;
+
+   drmModeFreePlane(ovr);
+   }
+
+   if (!plane_id) {
+   fprintf(stderr, "failed to find plane!\n");
+   return -1;
+   }
+
+   /* TODO.. would be nice to test YUV overlays.. */
+   if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
+   return -1;
+
+   kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
+
+   /* just use single plane format for now.. */
+   if (drmModeAddFB2(fd, p->w, p->h, DRM_FORMAT_XRGB,
+   handles, pitches, offsets, &p->fb_id, plane_flags)) {
+   fprintf(stderr, "failed to add fb: %s\n", strerror(errno));
+   return -1;
+   }
+
+   /* ok, boring.. but for now put in middle of screen: */
+   crtc_x =

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread batouzo 
On 12/14/2011 12:47 AM, Jerome Glisse wrote:
> On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse  wrote:
>> On Tue, Dec 13, 2011 at 6:33 PM, batouzo  wrote:
>>> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>>>
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x78/0x90 [drm]
> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x48/0x90 [drm]
>
> It is Amd Bulldozer computer, with Radeon card:
> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
> [Radeon HD 5450]
>
>messages: http://pastebin.com/NXN5EPtG
> config used: http://pastebin.com/AeVxEX7c
>>>

 Do you boot your kernel with kexec ? Does the patch help :
>>>
>>> Nope. Already seen that kexec bugfix on LKML but I start system normally
>>> not with kexec.
>>>
 http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch
 If not please open bug on bugs.freedesktop.org against radeon driver.
>>>
>>> ok
>>>
>>
>> Note that this patch might also help non kexec case.
>>
>> Cheers,
>> Jerome
> 
> Oh and try booting with radeon.no_wb=1
> 
> Cheers,
> Jerome

Using that patch on 3.1.4 results in locking for 60 seconds on startup,
since it is now looking for firmware.

This wait was not present without that patch.

This looks familiar, like the 60 second wait when using netconsole
caused by netconsole attempt to look for NIC card firmware too early
(when / is not really mounted, just initramfs).

I will report soon does it fix the crash;

Though, the 60 second delay may influence the rarity of hitting BUG (it
was the case with netconsole's 60sec wait).
Should I just remove loading of this firmware?




[1.386916] pci :03:06.0: calling quirk_usb_early_handoff+0x0/0x575
[1.386918] pci :03:06.0: calling pci_fixup_video+0x0/0xa6
[1.386925] PCI: CLS 64 bytes, default 64
[1.387113] Unpacking initramfs...
[1.569824] Freeing initrd memory: 9080k freed
[1.572659] pci :00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55
[1.572906] pci :00:00.2: irq 72 for MSI/MSI-X
[1.573088] AMD-Vi: Enabling IOMMU at :00:00.2 cap 0x40
[1.634353] AMD-Vi: Lazy IO/TLB flushing enabled
[1.634387] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[1.634421] Placing 64MB software IO TLB between 8800b9a5e000 -
8800bda5e000
[1.634456] software IO TLB at phys 0xb9a5e000 - 0xbda5e000
[1.639283] audit: initializing netlink socket (disabled)
[1.639353] type=2000 audit(1323849178.636:1): initialized
[1.648286] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[1.663115] VFS: Disk quotas dquot_6.5.2
[1.663309] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[1.663769] msgmni has been set to 7808
[1.664318] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 253)
[1.664353] io scheduler noop registered
[1.664385] io scheduler deadline registered
[1.664684] io scheduler cfq registered (default)
[1.665691] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[1.667276] [drm] Initialized drm 1.1.0 20060810
[1.667404] [drm] radeon defaulting to kernel modesetting.
[1.667436] [drm] radeon kernel modesetting enabled.
[1.667559] radeon :01:00.0: PCI INT A -> GSI 24 (level, low) ->
IRQ 24
[1.667594] radeon :01:00.0: setting latency timer to 64
[1.668367] [drm] initializing kernel modesetting (CEDAR
0x1002:0x68F9 0x1458:0x21F1).
[1.668455] [drm] register mmio base: 0xFEA2
[1.668487] [drm] register mmio size: 131072
[1.668685] ATOM BIOS: GV
[1.668806] radeon :01:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[1.668842] radeon :01:00.0: GTT: 512M 0x2000 -
0x3FFF
[1.676059] [drm] Detected VRAM RAM=512M, BAR=256M
[1.676094] [drm] RAM width 64bits DDR
[1.676270] [TTM] Zone  kernel: Available graphics memory: 1998922 kiB.
[1.676303] [TTM] Initializing pool allocator.
[1.676440] [drm] radeon: 512M of VRAM memory ready
[1.676476] [drm] radeon: 512M of GTT memory ready.
[1.676621] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[1.676655] [drm] Driver supports precise vblank timestamp query.
[1.676759] radeon :01:00.0: irq 73 for MSI/MSI-X
[1.676763] radeon :01:00.0: radeon: using MSI.
[1.676903] [drm] radeon: irq initialized.
[1.676941] [drm] GART: num cpu pages 131072, num gpu pages 131072
[1.677602] [drm] Loading CEDAR Microcode
[2.636773] Refined TSC clocksource calibration: 3110.391 MHz.
[2.636809] Switching to clocksource tsc
[   62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin"
[   62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[   62.347222] radeon :01:00.0: disabling GPU acceleration
[   62.348334] radeon :01:00.0: 8801364be9a0 unpin not necessar

[PATCH] libdrm: fix sizes of memcpy to the drmModeAddFB2()

2011-12-13 Thread Joonyoung Shim 
The variables(bo_handles, pitches and offsets) are the array having 4
elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) *
4.

Signed-off-by: Joonyoung Shim 
---
 xf86drmMode.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index ffa6dc4..8065f20 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -267,9 +267,9 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
f.height = height;
f.pixel_format = pixel_format;
f.flags = flags;
-   memcpy(f.handles, bo_handles, sizeof(bo_handles));
-   memcpy(f.pitches, pitches, sizeof(pitches));
-   memcpy(f.offsets, offsets, sizeof(offsets));
+   memcpy(f.handles, bo_handles, sizeof(uint32_t) * 4);
+   memcpy(f.pitches, pitches, sizeof(uint32_t) * 4);
+   memcpy(f.offsets, offsets, sizeof(uint32_t) * 4);
 
if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, &f)))
return ret;
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm_framebuffer_cleanup cleanup..

2011-12-13 Thread Daniel Vetter 
On Fri, Dec 9, 2011 at 18:44, Dave Airlie  wrote:
> On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark  wrote:
>> On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter  wrote:
 +static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
 +{
 + ? ? struct drm_device *dev = fb->dev;
 + ? ? struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
 +
 + ? ? DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);
 +
 + ? ? drm_framebuffer_cleanup(fb);
>>>
>>> This is a bit a general mess in kms. All drivers need to call this, and
>>> for added hilarity
>>> - drm_crtc.c drm_mode_rmfb has a TODO that this is missing
>>> - nouveau/radeon only do this _after_ unref'ing the backing storage
>>> - gma500 also tries to restore the kernel console here which should be
>>> ?done in lastclose (because you might disable another userspace fb on
>>> ?another output).
>>>
>>> Can I prod you to write the patches to clean this up and move
>>> drm_framebuffer_cleanup into common code?
>>
>> fyi, I'm starting to look at this.. looks like crtc/encoder/connector
>> cleanup could also benefit from some similar treatment. ?I'll start w/
>> just fb, since that is a resource that is actually dynamically
>> created/destroyed, so seems a bit more critical..
>
> I'm not sure reversing the flow here is the right answer, this is
> mainly trying to avoid midlayering things, the driver controls when
> stuff happens and it controls init the framebuffer object it controls
> destroying it as well.

The above proposal was more in the light of eventually switching to
properly ref-counted framebuffers. The common kms code would then keep
track of the references it knows about from the current modeset
configuration and hence also responsible for dropping them (i.e. what
drm_framebuffer_cleanup currently does). The driver could then still
hold onto references it needs internally and is also still in control
of fb destruction - the driver's fb_destroy would be called when the
last reference disappears.

So I don't see an "inversion of control through stupid middle-layer"
issue here, more like "resource lifetime mess through lack of
refcounting". But I agree that we can keep the drm_framebuffer_cleanup
where it currently is until it completely disappears with proper fb
refcounting.

Cheers, Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

[PATCH 5/5] drm/exynos: Add plane support with fimd

2011-12-13 Thread Joonyoung Shim 
On 12/13/2011 07:48 AM, Rob Clark wrote:
> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae  wrote:
>> +static int
>> +exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
>> +struct drm_framebuffer *fb, int crtc_x, int crtc_y,
>> +unsigned int crtc_w, unsigned int crtc_h,
>> +uint32_t src_x, uint32_t src_y,
>> +uint32_t src_w, uint32_t src_h)
>> +{
>> +   struct exynos_plane *exynos_plane =
>> +   container_of(plane, struct exynos_plane, base);
>> +   struct exynos_drm_overlay *overlay =&exynos_plane->overlay;
>> +   struct exynos_drm_crtc_pos pos;
>> +   int ret;
>> +
>> +   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>> +
>> +   memset(&pos, 0, sizeof(struct exynos_drm_crtc_pos));
>> +   pos.crtc_x = crtc_x;
>> +   pos.crtc_y = crtc_y;
>> +   pos.crtc_w = crtc_w;
>> +   pos.crtc_h = crtc_h;
>> +
>> +   pos.fb_x = src_x;
>> +   pos.fb_y = src_y;
> also, I think src_x/src_y should be interpreted at 16.16/Q16 fixed
> point.  But elsewhere were I see fb_x/y used it, it doesn't appear to
> be interpreted this way.

Right, this will be fixed.

Thanks.

> Also, I *think* that comment was meant to apply to src_h/src_w
> (Jesse?), but you seem to ignore these parameters..
>
> BR,
> -R
>
>
>> +
>> +   /* TODO: scale feature */
>> +   ret = exynos_drm_overlay_update(overlay, fb,&crtc->mode,&pos);
>> +   if (ret<  0)
>> +   return ret;
>> +
>> +   exynos_drm_fn_encoder(crtc, overlay,
>> +   exynos_drm_encoder_crtc_mode_set);
>> +   exynos_drm_fn_encoder(crtc,&overlay->zpos,
>> +   exynos_drm_encoder_crtc_plane_commit);
>> +
>> +   exynos_plane->enabled = true;
>> +
>> +   return 0;
>> +}
>> +
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 5/5] drm/exynos: Add plane support with fimd

2011-12-13 Thread Joonyoung Shim 
On 12/13/2011 06:59 AM, Rob Clark wrote:
> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae  wrote:
>> From: Joonyoung Shim
>>
>> The exynos fimd supports 5 window overlays. Only one window overlay of
>> fimd is used by the crtc, so we need plane feature to use the rest
>> window overlays.
>>
>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
>> is the ioctl to decide for user to assign which window overlay.
>>
> btw, I think I will end up with a similar ioctl.. so thought I'd
> double check for consistency, is zorder interpreted from back to front
> or front to back?  Ie. higher numeric value in front or behind of
> lower numeric value?  Are negative values permitted?

The zpos of exynos plane is just the index of overlay of exynos fimd or
exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay.
It isn't the priority value but higher zpos will have higher priority
generally.

A negative value -1 is defined to special value. A exynos crtc should
use one overlay and -1 zpos means the overlay that crtc uses.

Thanks.

> BR,
> -R
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 43768] New: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:1101:i915_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed.

2011-12-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43768

 Bug #: 43768
   Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_translate.c:1101:i91
5_translate_token: Assertion `ifs->constant_flags[i]
== 0x0' failed.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com


mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master)

Run piglit glsl-fs-convolution-1 test on i915g.

$ ./bin/shader_runner tests/shaders/glsl-fs-convolution-1.shader_test -auto
src/gallium/drivers/i915/i915_fpc_translate.c:1101:i915_translate_token:
Assertion `ifs->constant_flags[i] == 0x0' failed.
Trace/breakpoint trap (core dumped)

(gdb) bt
#0  0x010eee18 in _debug_assert_fail (expr=0x1a68743 "ifs->constant_flags[i] ==
0x0", file=0x1a683d8 "src/gallium/drivers/i915/i915_fpc_translate.c", 
line=1101, function=0x1a6884b "i915_translate_token") at
src/gallium/auxiliary/util/u_debug.c:278
#1  0x0109e0ad in i915_translate_token (p=0x98611f8, token=0x98a23f8,
fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1101
#2  0x0109e372 in i915_translate_instructions (p=0x98611f8, tokens=0x9867890,
fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1178
#3  0x0109e90c in i915_translate_fragment_program (i915=0x96ce8c0,
fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1340
#4  0x010967d6 in i915_create_fs_state (pipe=0x96ce8c0, templ=0x98d977c) at
src/gallium/drivers/i915/i915_state.c:577
#5  0x010c0910 in aaline_create_fs_state (pipe=0x96ce8c0, fs=0x98d977c) at
src/gallium/auxiliary/draw/draw_pipe_aaline.c:856
#6  0x010c2a2f in aapoint_create_fs_state (pipe=0x96ce8c0, fs=0x98d977c) at
src/gallium/auxiliary/draw/draw_pipe_aapoint.c:839
#7  0x0191d608 in st_translate_fragment_program (st=0x97bc488, stfp=0x98c9420,
key=0xbfa60ca0) at src/mesa/state_tracker/st_program.c:710
#8  0x0191d729 in st_get_fp_variant (st=0x97bc488, stfp=0x98c9420,
key=0xbfa60ca0) at src/mesa/state_tracker/st_program.c:747
#9  0x019c913d in update_fp (st=0x97bc488) at
src/mesa/state_tracker/st_atom_shader.c:86
#10 0x019c543b in st_validate_state (st=0x97bc488) at
src/mesa/state_tracker/st_atom.c:177
#11 0x01918144 in st_draw_vbo (ctx=0x97663d8, arrays=0x97bf8a0,
prims=0xbfa60dec, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0,
max_index=3)
at src/mesa/state_tracker/st_draw.c:979
#12 0x019ab5ff in vbo_draw_arrays (ctx=0x97663d8, mode=7, start=0, count=4,
numInstances=1) at src/mesa/vbo/vbo_exec_array.c:620
#13 0x019ab757 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
src/mesa/vbo/vbo_exec_array.c:651
#14 0x0809cbf6 in piglit_draw_rect (x=-1, y=-1, w=2, h=2) at
piglit/tests/util/piglit-util-gl.c:647
#15 0x0807289d in piglit_display () at
piglit/tests/shaders/shader_runner.c:1095
#16 0x08074147 in display () at piglit/tests/util/piglit-framework.c:56
#17 0x0062ec1e in fghRedrawWindow (window=0x96c6a28) at freeglut_main.c:210
#18 fghcbDisplayWindow (window=0x96c6a28, enumerator=0xbfa61118) at
freeglut_main.c:227
#19 0x00632590 in fgEnumWindows (enumCallback=0x62eb20 ,
enumerator=0xbfa61118) at freeglut_structure.c:394
#20 0x0062f02e in fghDisplayAll () at freeglut_main.c:249
#21 glutMainLoopEvent () at freeglut_main.c:1450
#22 0x0062f935 in glutMainLoop () at freeglut_main.c:1498
#23 0x0807487e in main (argc=2, argv=0xbfa61384) at
piglit/tests/util/piglit-framework.c:294
(gdb) frame 1
#1  0x0109e0ad in i915_translate_token (p=0x98611f8, token=0x98a23f8,
fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1101
1101assert(ifs->constant_flags[i] == 0x0);
(gdb) info locals
i = 32
ifs = 0x98602f8
__FUNCTION__ = "i915_translate_token"
(gdb) print ifs->constant_flags[i]
$1 = 255 '\377'

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43769] New: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:658:i915_translate_instruction: Assertion `0' failed.

2011-12-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43769

 Bug #: 43769
   Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_translate.c:658:i915
_translate_instruction: Assertion `0' failed.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com


mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master)

Run piglit glsl-fs-discard-03 test on i915g.

$ ./bin/shader_runner tests/shaders/glsl-fs-discard-03.shader_test -auto
src/gallium/drivers/i915/i915_fpc_translate.c:658:i915_translate_instruction:
Assertion `0' failed.
Trace/breakpoint trap (core dumped)

(gdb) bt
#0  0x01126e18 in _debug_assert_fail (expr=0x1aa052a "0", file=0x1aa03d8
"src/gallium/drivers/i915/i915_fpc_translate.c", line=658, 
function=0x1aa0860 "i915_translate_instruction") at
src/gallium/auxiliary/util/u_debug.c:278
#1  0x010d4666 in i915_translate_instruction (p=0xa1b7528, inst=0xa1c08c8,
fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:658
#2  0x010d62fe in i915_translate_token (p=0xa1b7528, token=0xa1c08c8,
fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:1157
#3  0x010d6372 in i915_translate_instructions (p=0xa1b7528, tokens=0xa15af08,
fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:1178
#4  0x010d690c in i915_translate_fragment_program (i915=0xa0678c0,
fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:1340
#5  0x010ce7d6 in i915_create_fs_state (pipe=0xa0678c0, templ=0xa1ebee4) at
src/gallium/drivers/i915/i915_state.c:577
#6  0x010f8910 in aaline_create_fs_state (pipe=0xa0678c0, fs=0xa1ebee4) at
src/gallium/auxiliary/draw/draw_pipe_aaline.c:856
#7  0x010faa2f in aapoint_create_fs_state (pipe=0xa0678c0, fs=0xa1ebee4) at
src/gallium/auxiliary/draw/draw_pipe_aapoint.c:839
#8  0x01955608 in st_translate_fragment_program (st=0xa155488, stfp=0xa1dbb88,
key=0xbf932470) at src/mesa/state_tracker/st_program.c:710
#9  0x01955729 in st_get_fp_variant (st=0xa155488, stfp=0xa1dbb88,
key=0xbf932470) at src/mesa/state_tracker/st_program.c:747
#10 0x01a0113d in update_fp (st=0xa155488) at
src/mesa/state_tracker/st_atom_shader.c:86
#11 0x019fd43b in st_validate_state (st=0xa155488) at
src/mesa/state_tracker/st_atom.c:177
#12 0x01a07eec in st_Clear (ctx=0xa0ff3d8, mask=2) at
src/mesa/state_tracker/st_cb_clear.c:507
#13 0x0197eeb3 in _mesa_Clear (mask=16384) at src/mesa/main/clear.c:242
#14 0x08072795 in piglit_display () at
piglit/tests/shaders/shader_runner.c:1084
#15 0x08074147 in display () at piglit/tests/util/piglit-framework.c:56
#16 0x0076bc1e in fghRedrawWindow (window=0xa05fa28) at freeglut_main.c:210
#17 fghcbDisplayWindow (window=0xa05fa28, enumerator=0xbf9327b8) at
freeglut_main.c:227
#18 0x0076f590 in fgEnumWindows (enumCallback=0x76bb20 ,
enumerator=0xbf9327b8) at freeglut_structure.c:394
#19 0x0076c02e in fghDisplayAll () at freeglut_main.c:249
#20 glutMainLoopEvent () at freeglut_main.c:1450
#21 0x0076c935 in glutMainLoop () at freeglut_main.c:1498
#22 0x0807487e in main (argc=2, argv=0xbf932a24) at
piglit/tests/util/piglit-framework.c:294
(gdb) frame 1
#1  0x010d4666 in i915_translate_instruction (p=0xa1b7528, inst=0xa1c08c8,
fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:658
658  assert(0); /* not tested yet */
(gdb) l
653  T0_TEXKILL,/* opcode */
654  1);/* num_coord */
655  break;
656
657   case TGSI_OPCODE_KILP:
658  assert(0); /* not tested yet */
659  break;
660
661   case TGSI_OPCODE_LG2:
662  src0 = src_vector(p, &inst->Src[0], fs);

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 38661] [i915g] src/gallium/drivers/i915/i915_state_static.c:122:update_framebuffer: Assertion `offset == 0' failed.

2011-12-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=38661

--- Comment #3 from Vinson Lee  2011-12-12 16:50:10 PST ---
mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master)

Assert still occurs.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43770] New: [i915g] src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit_arith: Assertion `(((dest)>>29)&0x7) != 2' failed.

2011-12-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43770

 Bug #: 43770
   Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit
_arith: Assertion `(((dest)>>29)&0x7) != 2' failed.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com


mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master)

Run piglit fs-temp-array-mat3-index-col-row-rd test on i915g.

$ ./bin/shader_runner
tests/spec/glsl-1.20/execution/variable-indexing/fs-temp-array-mat3-index-col-row-rd.shader_test
-auto
Too many temps (16)
Too many temps (17)
Too many temps (18)
Too many temps (19)
Too many temps (20)
Too many temps (21)
Too many temps (22)
Too many temps (23)
Too many temps (24)
Too many temps (25)
Too many temps (26)
Too many temps (27)
Too many temps (28)
Too many temps (29)
Too many temps (30)
Too many temps (31)
Too many temps (32)
Too many temps (33)
Too many temps (34)
Too many temps (35)
Too many temps (36)
Too many temps (37)
Too many temps (38)
Too many temps (39)
Too many temps (40)
Too many temps (41)
Too many temps (42)
Too many temps (43)
Too many temps (44)
Too many temps (45)
Too many temps (46)
Too many temps (47)
Too many temps (48)
Too many temps (49)
Too many temps (50)
Too many temps (51)
Too many temps (52)
Too many temps (53)
Too many temps (54)
Too many temps (55)
Too many temps (56)
Too many temps (57)
Too many temps (58)
Too many temps (59)
Too many temps (60)
Too many temps (61)
Too many temps (62)
Too many temps (63)
Too many temps (64)
Too many temps (65)
Too many temps (66)
Too many temps (67)
i915_program_error: Exceeded max temporary reg
i915_program_error: bad opcode 0
i915_program_error: Exceeded max temporary reg
i915_program_error: bad opcode 0
i915_program_error: Exceeded max temporary reg
i915_program_error: Exceeded max temporary reg
i915_program_error: Exceeded max temporary reg
i915_program_error: bad opcode 0
i915_program_error: Exceeded max temporary reg
i915_program_error: Exceeded max temporary reg
i915_program_error: Exceeded max temporary reg
src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit_arith: Assertion
`(((dest)>>29)&0x7) != 2' failed.
Trace/breakpoint trap (core dumped)

(gdb) bt
#0  0x01093e18 in _debug_assert_fail (expr=0x1a0edfd "(((dest)>>29)&0x7) != 2",
file=0x1a0edd4 "src/gallium/drivers/i915/i915_fpc_emit.c", line=153, 
function=0x1a0ef40 "i915_emit_arith") at
src/gallium/auxiliary/util/u_debug.c:278
#1  0x0104a6fa in i915_emit_arith (p=0x826d840, op=318767104, dest=1090593605,
mask=15360, saturate=0, src0=1073741893, src1=0, src2=0)
at src/gallium/drivers/i915/i915_fpc_emit.c:153
#2  0x0104251f in i915_translate_instruction (p=0x826d840, inst=0x8266a40,
fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:884
#3  0x010432fe in i915_translate_token (p=0x826d840, token=0x8266a40,
fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:1157
#4  0x01043372 in i915_translate_instructions (p=0x826d840, tokens=0x82598f8,
fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:1178
#5  0x0104390c in i915_translate_fragment_program (i915=0x81068c0,
fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:1340
#6  0x0103b7d6 in i915_create_fs_state (pipe=0x81068c0, templ=0x828f134) at
src/gallium/drivers/i915/i915_state.c:577
#7  0x01065910 in aaline_create_fs_state (pipe=0x81068c0, fs=0x828f134) at
src/gallium/auxiliary/draw/draw_pipe_aaline.c:856
#8  0x01067a2f in aapoint_create_fs_state (pipe=0x81068c0, fs=0x828f134) at
src/gallium/auxiliary/draw/draw_pipe_aapoint.c:839
#9  0x018c2608 in st_translate_fragment_program (st=0x81f4488, stfp=0x827edd8,
key=0xbfe38da0) at src/mesa/state_tracker/st_program.c:710
#10 0x018c2729 in st_get_fp_variant (st=0x81f4488, stfp=0x827edd8,
key=0xbfe38da0) at src/mesa/state_tracker/st_program.c:747
#11 0x0196e13d in update_fp (st=0x81f4488) at
src/mesa/state_tracker/st_atom_shader.c:86
#12 0x0196a43b in st_validate_state (st=0x81f4488) at
src/mesa/state_tracker/st_atom.c:177
#13 0x01974eec in st_Clear (ctx=0x819e3d8, mask=2) at
src/mesa/state_tracker/st_cb_clear.c:507
#14 0x018ebeb3 in _mesa_Clear (mask=16384) at src/mesa/main/clear.c:242
#15 0x08072795 in piglit_display () at
piglit/tests/shaders/shader_runner.c:1084
#16 0x08074147 in display () at piglit/tests/util/piglit-framework.c:56
#17 0x007f2c1e in fghRedrawWindow (window=0x80fea28) at freeglut_main.c:210
#18 fghcbDisplayWindow (window=0x80fea28, enumerator=0xbfe390e8) at
freeglut_main.c:227
#19 0x007f6590 in fgEnumWindows (enumCallback=0x7f2b20 ,
enumerator=0xbfe390e8) at freeglut_structure.c:394
#20 0x007f302e in fghDisplayAll () at freeglut_main.c:249
#21 glutMainLoopEvent

[Bug 43771] New: [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap: Assertion `img_filter == 1' failed.

2011-12-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43771

 Bug #: 43771
   Summary: [i915g]
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:
lp_build_sample_mipmap: Assertion `img_filter == 1'
failed.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com


mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master)

Run piglit fragment-and-vertex-texturing on i915g. The test triggers an assert
on i915g but passes on llvmpipe.

$ ./bin/fragment-and-vertex-texturing -autoThe result should be a solid block
of half-bright yellow color
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap:
Assertion `img_filter == 1' failed.
Trace/breakpoint trap (core dumped)

(gdb) bt
#0  0x01131e18 in _debug_assert_fail (expr=0x1ac1858 "img_filter == 1",
file=0x1ac1824 "src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c", line=821, 
function=0x1ac19d1 "lp_build_sample_mipmap") at
src/gallium/auxiliary/util/u_debug.c:278
#1  0x011bddd1 in lp_build_sample_mipmap (bld=0xbfa61d08, img_filter=2,
mip_filter=2, s=0x866a61c, t=0x866a2ec, r=0x862a480, ilevel0=0x866f4d4,
ilevel1=0x0, 
lod_fpart=0x0, colors_lo_var=0x8665344, colors_hi_var=0x85e570c) at
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821
#2  0x011be85f in lp_build_sample_aos (bld=0xbfa61d08, unit=0, s=0x866a61c,
t=0x866a2ec, r=0x862a480, ddx=0xbfa61f40, ddy=0xbfa61f4c, lod_bias=0x0, 
explicit_lod=0x866b224, texel_out=0xbfa61fb0) at
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:1067
#3  0x011a89ae in lp_build_sample_soa (gallivm=0x8431fb8,
static_state=0x86654d4, dynamic_state=0x8664490, type=..., unit=0,
num_coords=2, 
coords=0xbfa61f34, ddx=0xbfa61f40, ddy=0xbfa61f4c, lod_bias=0x0,
explicit_lod=0x866b224, texel_out=0xbfa61fb0)
at src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c:1253
#4  0x0116fe1f in draw_llvm_sampler_soa_emit_fetch_texel (base=0x8664488,
gallivm=0x8431fb8, type=..., unit=0, num_coords=2, coords=0xbfa61f34, 
ddx=0xbfa61f40, ddy=0xbfa61f4c, lod_bias=0x0, explicit_lod=0x866b224,
texel=0xbfa61fb0) at src/gallium/auxiliary/draw/draw_llvm_sample.c:186
#5  0x011aceb4 in emit_tex (bld=0xbfa62060, inst=0x86b6a98,
modifier=LP_BLD_TEX_MODIFIER_EXPLICIT_LOD, texel=0xbfa61fb0)
at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1145
#6  0x011b06e5 in emit_instruction (bld=0xbfa62060, inst=0x86b6a98,
info=0x1d949e0, pc=0xbfa64758) at
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2169
#7  0x011b13c9 in lp_build_tgsi_soa (gallivm=0x8431fb8, tokens=0x8680678,
type=..., mask=0x0, consts_ptr=0x866bfcc, system_values_array=0x86648a4,
pos=0x0, 
inputs=0xbfa64aac, outputs=0xbfa648ac, sampler=0x8664488, info=0x865abd8)
at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2498
#8  0x0116c2e7 in generate_vs (llvm=0x848a6c8, builder=0x848a690,
outputs=0xbfa648ac, inputs=0xbfa64aac, system_values_array=0x86648a4, 
context_ptr=0x86260a8, draw_sampler=0x8664488, clamp_vertex_color=1 '\001')
at src/gallium/auxiliary/draw/draw_llvm.c:492
#9  0x0116ef0a in draw_llvm_generate (llvm=0x848a6c8, variant=0x8665490, elts=0
'\000') at src/gallium/auxiliary/draw/draw_llvm.c:1348
#10 0x0116c13e in draw_llvm_create_variant (llvm=0x848a6c8, num_inputs=3,
key=0xbfa65078) at src/gallium/auxiliary/draw/draw_llvm.c:447
#11 0x01171d71 in llvm_middle_end_prepare (middle=0x8494c50, in_prim=7, opt=3,
max_vertices=0x849204c)
at src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:174
#12 0x01115ec2 in vsplit_prepare (frontend=0x8492030, in_prim=7,
middle=0x8494c50, opt=3) at src/gallium/auxiliary/draw/draw_pt_vsplit.c:175
#13 0x0110bbaf in draw_pt_arrays (draw=0x84333f8, prim=7, start=0, count=4) at
src/gallium/auxiliary/draw/draw_pt.c:111
#14 0x0110c746 in draw_vbo (draw=0x84333f8, info=0xbfa65494) at
src/gallium/auxiliary/draw/draw_pt.c:501
#15 0x010d7a48 in i915_draw_vbo (pipe=0x84388d0, info=0xbfa65494) at
src/gallium/drivers/i915/i915_context.c:88
#16 0x0195b45f in st_draw_vbo (ctx=0x84d1538, arrays=0x852aa00,
prims=0xbfa6553c, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0,
max_index=3)
at src/mesa/state_tracker/st_draw.c:1058
#17 0x019ee5ff in vbo_draw_arrays (ctx=0x84d1538, mode=7, start=0, count=4,
numInstances=1) at src/mesa/vbo/vbo_exec_array.c:620
#18 0x019ee757 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
src/mesa/vbo/vbo_exec_array.c:651
#19 0x0809612e in piglit_draw_rect (x=-1, y=-1, w=2, h=2) at
piglit/tests/util/piglit-util-gl.c:647
#20 0x0806c960 in display () at
piglit/tests/texturing/fragment-and-vertex-texturing.c:147
#21 0x0806c9ab in piglit_display () at
piglit/tests/texturing/fragment-and-vertex-textu

[PATCH 5/5] drm/exynos: Add plane support with fimd

2011-12-13 Thread Inki Dae 
Hi, Rob.
below is my answer.

> -Original Message-
> From: Rob Clark [mailto:robdclark at gmail.com]
> Sent: Tuesday, December 13, 2011 9:48 AM
> To: Joonyoung Shim
> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 5/5] drm/exynos: Add plane support with fimd
> 
> On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim 
> wrote:
> > On 12/13/2011 06:59 AM, Rob Clark wrote:
> >>
> >> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae ?wrote:
> >>>
> >>> From: Joonyoung Shim
> >>>
> >>> The exynos fimd supports 5 window overlays. Only one window overlay of
> >>> fimd is used by the crtc, so we need plane feature to use the rest
> >>> window overlays.
> >>>
> >>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
> >>> is the ioctl to decide for user to assign which window overlay.
> >>>
> >> btw, I think I will end up with a similar ioctl.. so thought I'd
> >> double check for consistency, is zorder interpreted from back to front
> >> or front to back? ?Ie. higher numeric value in front or behind of
> >> lower numeric value? ?Are negative values permitted?
> >
> >
> > The zpos of exynos plane is just the index of overlay of exynos fimd or
> > exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay.
> > It isn't the priority value but higher zpos will have higher priority
> > generally.
> 
> I'm not sure that I quite understand that.. does that mean zpos=1 will
> be in front of zpos=0 (which would be in front of crtc, aka zpos=-1).
> Do you have a way to put overlays *behind* crtc layer (which
> presumably would be in some mode with an alpha channel?)
> 
> (IIRC, samsung has some public TRM type document.. if this is covered
> there, feel free to answer by just pointing me at the section I should
> read)
> 

I know that omap, at least omap3(Display Controller of the Display
Subsystem), has two modes. one is normal mode and another is alpha mode. and
they also have different overlay priority but Samsung exynos has fixed
priority to hardware overlays. so higher overlay always is in front of lower
overlay. in case of plane module for Samsung SoC, if zpos is -1 then crtc
has default overlay designated by machine code. so whether some overlay is
in front of crtc or not would be decided by default overlay.

Thank you,
Inki Dae.


> BR,
> -R
> 
> > A negative value -1 is defined to special value. A exynos crtc should
> > use one overlay and -1 zpos means the overlay that crtc uses.
> >
> > Thanks.
> >
> >> BR,
> >> -R
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >

[PATCH 2/2] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

2011-12-13 Thread Matthew Garrett 
On Fri, Dec 09, 2011 at 03:53:49PM -0800, Keith Packard wrote:
> RC6 should always work on IVB, and should work on SNB whenever IO
> remapping is disabled. RC6 never works on Ironlake. Make the default
> value for the parameter follow these guidelines. Setting the value
> to either 0 or 1 will force the specified behavior.

I still don't like this. We're in a situation where we clearly have to 
disable one feature or the other on SNB - but we're disabling the one 
that's going to be useful to a large number of people, and leaving the 
niche feature enabled. If we're going to merge this then let's turn off 
iommu on SNB by default.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[ANNOUNCE] libdrm 2.4.29

2011-12-13 Thread Chris Wilson 
This publishes some new API for Intel to be able to cap the number of
VMA that libdrm_intel caches amongst its bo. This is intended to be used
by clients to prevent applications (such as the xserver) from exhausting
their per-process limits on inactive GTT mmaps whilst also mitigating
against the costs of recreating those mmaps.
-Chris

Chris Wilson (6):
  intel: Clean up mmaps on freeing the buffer
  intel: Add an interface to limit vma caching
  intel: Evict cached VMA in order to make room for new mappings
  intel: Update map-count for an early error return during mapping
  intel: Remove the fresh assertions used to debug the vma cacheing
  configure: Bump version for 2.4.29

Dave Airlie (1):
  test/radeon: add missing files for dist

git tag: 2.4.29

http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.bz2
MD5:  96d5e3e9edd55f4b016fe3b5dd0a1953  libdrm-2.4.29.tar.bz2
SHA1: 054ca4f6b9145b1bb5192f3cba4dd1835fcc5977  libdrm-2.4.29.tar.bz2
SHA256: e2432dc93e933479132123a1dca382294c30f55bc895bb737b6bdd6f2b8c452e  
libdrm-2.4.29.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.gz
MD5:  2596e48b4d2663ed075f0a86e977cf99  libdrm-2.4.29.tar.gz
SHA1: 68d46937f5e725b439a8ed748211f0a27168caf3  libdrm-2.4.29.tar.gz
SHA256: d60ecf6fc52f92663ee80cc94560ead56b493e4b91d1ee99f2292f7ecdab40b2  
libdrm-2.4.29.tar.gz

-- 
Chris Wilson, Intel Open Source Technology Centre
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/6840bbf0/attachment.pgp>

Black screen with AMD A4-3300 support

2011-12-13 Thread Boszormenyi Zoltan 
Hi,

I have a new ASUS K53TA notebook with AMD A4-3300 CPU
and an extra Radeon HD6550M. I installed Fedora 16 on it but
I get only black screen even during installation unless booted
with nomodeset. But it's only VESA so there's no acceleration
and there's no native LCD 1366x768 resolution, only 1024x768,
so it's a bit blurry.

The machine boots up and I can login via ssh so I can debug it.
dmesg and Xorg.0.log says the integrated video is recognized
and handled. Only the screen is black. dmesg says something
about not being able to determine initial brightness setting.

Can anyone help me to get it to display X with KMS?

Thanks in advance,
Zolt?n B?sz?rm?nyi

EDID Override

2011-12-13 Thread Thorsten Schoel 
Dear all,

please find below a patch that will allow overriding a monitor's EDID 
with something provided by the user. This can be helpful in a number of 
situations as a quick google for "edid override" or similar suggests; I 
wrote it because my monitor is broken and doesn't provide any EDID at 
all. This is done through a module parameter named edid_override which 
is made up of three parts, each separated by a colon from the next. 
First is the name of a connector, second is the type of source for the 
information, third is the source of the information itself. If the 
second part is an 'f', the third will be the name of a file containing 
the EDID, if it is a 'w', the third will be the name of a firmware blob 
(i.e. the kernel firmware loading mechanism will be used to get the 
data), and if it is an 'r' th third part is raw EDID encoded as a stream 
of hexadecimal characters. 'd' as the second part will simply remove any 
previous edid override for the connector.

Since this is my first attempt at getting a patch into the kernel the 
patch might well be in need of some additional work which I will be 
pleased to provide if someone provides me with a description and 
explanation of what needs to be done.

The following points are on my mind. These are not things that I think 
have to be fixed but rather that I am unsure of:

- Is drm_edid.c, the file where all the logic and currently everything 
else is placed, really the right place for the definition of the module 
parameter or should this go elsewhere?

- Is it really desirable to have three different ways of fetching the 
EDID-data? Yet, having the raw EDID in hex (256 characters) on the 
kernel command line might not always be desirable. Loading the EDID as 
firmware may sometimes be more convenient than reading it from an 
arbitrary file. But if you look at it closely EDID data is not exactly 
what you think of when you think of firmware.

- Adding an override through sysfs doesn't work yet and I can't figure 
out why.

The patch was written and tested on Fedora 16, Linux 3.1. I have adopted 
it to 3.2-rc5 though. If anyone desires the 3.1 patch I can provide that 
as well. It is only marginally different though.

Best,
Thorsten

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: linux-3.2-edid-override.patch
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/6f0a0de4/attachment-0001.asc>

Black screen with AMD A4-3300 support

2011-12-13 Thread Joshua Roys 
On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
> I have a new ASUS K53TA notebook with AMD A4-3300 CPU
> and an extra Radeon HD6550M. I installed Fedora 16 on it but
> I get only black screen even during installation unless booted
> with nomodeset. But it's only VESA so there's no acceleration
> and there's no native LCD 1366x768 resolution, only 1024x768,
> so it's a bit blurry.
>

Hello,

Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 .  (The HP 
G4-1215DX also has a AMD A4-3300.)  After making the f16 kernel work, I 
ended up installing a f17/rawhide kernel from 
http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to fix other 
bugs, which will probably be the easiest solution for you.  I would be 
interested to hear if, after installing a newer kernel, suspend/resume 
worked for you.

Good luck,

Josh

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

2011-12-13 Thread Hans Verkuil 
(I've been away for the past two weeks, so I'm only now catching up)


On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote:
> On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann  wrote:
> > On Wednesday 07 December 2011, Semwal, Sumit wrote:
> >> Thanks for the excellent discussion - it indeed is very good learning
> >> for the relatively-inexperienced me :)
> >> 
> >> So, for the purpose of dma-buf framework, could I summarize the
> >> following and rework accordingly?:
> >> 1. remove mmap() dma_buf_op [and mmap fop], and introduce cpu_start(),
> >> cpu_finish() ops to bracket cpu accesses to the buffer. Also add
> >> DMABUF_CPU_START / DMABUF_CPU_FINI IOCTLs?
> > 
> > I think we'd be better off for now without the extra ioctls and
> > just document that a shared buffer must not be exported to user
> > space using mmap at all, to avoid those problems. Serialization
> > between GPU and CPU is on a higher level than the dma_buf framework
> > IMHO.
> 
> Agreed.
> 
> >> 2. remove sg_sync* ops for now (and we'll see if we need to add them
> >> later if needed)
> > 
> > Just removing the sg_sync_* operations is not enough. We have to make
> > the decision whether we want to allow
> > a) only coherent mappings of the buffer into kernel memory (requiring
> > an extension to the dma_map_ops on ARM to not flush caches at map/unmap
> > time)
> > b) not allowing any in-kernel mappings (same requirement on ARM, also
> > limits the usefulness of the dma_buf if we cannot access it from the
> > kernel or from user space)
> > c) only allowing streaming mappings, even if those are non-coherent
> > (requiring strict serialization between CPU (in-kernel) and dma users of
> > the buffer)
> 
> I think only allowing streaming access makes the most sense:
> - I don't see much (if any need) for the kernel to access a dma_buf -
> in all current usecases it just contains pixel data and no hw-specific
> things (like sg tables, command buffers, ..). At most I see the need
> for the kernel to access the buffer for dma bounce buffers, but that
> is internal to the dma subsystem (and hence does not need to be
> exposed).

There are a few situations where the kernel might actually access a dma_buf:

First of all there are some sensors that add meta data before the actual
pixel data, and a kernel driver might well want to read out that data and
process it. Secondly (and really very similar), video frames sent to/from
an FPGA can also contain meta data (Cisco does that on some of our products)
that the kernel may need to inspect.

I admit that these use-cases aren't very common, but they do exist.

> - Userspace can still access the contents through the exporting
> subsystem (e.g. use some gem mmap support). For efficiency reason gpu
> drivers are already messing around with cache coherency in a platform
> specific way (and hence violated the dma api a bit), so we could stuff
> the mmap coherency in there, too. When we later on extend dma_buf
> support so that other drivers than the gpu can export dma_bufs, we can
> then extend the official dma api with already a few drivers with
> use-patterns around.
> 
> But I still think that the kernel must not be required to enforce
> correct access ordering for the reasons outlined in my other mail.

I agree with Daniel on this.

BTW, the V4L2 subsystem has a clear concept of passing bufffer ownership: the
VIDIOC_QBUF and VIDIOC_DQBUF ioctls deal with that. Pretty much all V4L2 apps 
request the buffers, then mmap them, then call QBUF to give the ownership of 
those buffers to the kernel. While the kernel owns those buffers any access to 
the mmap'ped memory leads to undefined results. Only after calling DQBUF can 
userspace actually safely access that memory.

Allowing mmap() on the dma_buf's fd would actually make things easier for 
V4L2. It's an elegant way of mapping the memory.

Regards,

Hans

radeon stable patches

2011-12-13 Thread Alex Deucher 
Hi Greg,

Can you cherry-pick the following patches back to the stable branches:
b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11
1d33e1fc8dcce667a70387b666a8b6f60153d90f
cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd
They fix the internal panel setup on certain fusion laptops.  I've
attached patches I cherry-picked myself against 3.1.x stable if you'd
prefer that.

Thanks!

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-cleanup-atombios_adjust_pll.patch
Type: text/x-diff
Size: 2916 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/5c16aa3d/attachment-0003.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-kms-rework-DP-bridge-checks.patch
Type: text/x-diff
Size: 9888 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/5c16aa3d/attachment-0004.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0003-drm-radeon-kms-fix-DP-setup-on-TRAVIS-bridges.patch
Type: text/x-diff
Size: 1533 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/5c16aa3d/attachment-0005.patch>

[PATCH] radeon: Set macrotile shape on Evergreen hardware

2011-12-13 Thread Simon Farnsworth 
Evergreen and later Radeons let the driver choose a macro tile layout,
within certain constraints. If we don't set the appropriate fields
correctly, the card will use a layout that doesn't normally meet the
constraints on Evergreen tiling.

For now, select 8x8 aspect 1 macrotiles, as this makes it possible to
guarantee that we meet the hardware constraints. Once macrotiling is
reliable, we can consider a better API to let us exploit the hardware
capabilities.

Signed-off-by: Simon Farnsworth 
---

This doesn't fix my problems with enabling macro tiling, but it does help
somewhat. I also need to fix alignment in the DDX and Mesa to avoid
misrendering, at which point I see CP lockups instead.

I'm therefore sending this, the DDX patch, and the Mesa patch out in order
to avoid getting stuck in a world where I have an 80% fix, someone else has
an 80% fix, and if only we talked, we'd have a 100% fix.

 drivers/gpu/drm/radeon/atombios_crtc.c |4 
 drivers/gpu/drm/radeon/evergreen_cs.c  |9 +
 drivers/gpu/drm/radeon/evergreend.h|7 +++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 2b97262..f982975 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1113,6 +1113,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
else
tmp = rdev->config.evergreen.tile_config;

+   fb_format |= 
(EVERGREEN_GRPH_BANK_HEIGHT(EVERGREEN_ADDR_SURF_BANK_HEIGHT_8) |
+ 
EVERGREEN_GRPH_BANK_WIDTH(EVERGREEN_ADDR_SURF_BANK_WIDTH_8) |
+ 
EVERGREEN_GRPH_MACRO_TILE_ASPECT(EVERGREEN_ADDR_SURF_MACRO_TILE_ASPECT_1));
+
switch ((tmp & 0xf0) >> 4) {
case 0: /* 4 banks */
fb_format |= 
EVERGREEN_GRPH_NUM_BANKS(EVERGREEN_ADDR_SURF_4_BANK);
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index b53d1c6..a14a04e 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -532,6 +532,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
ib[idx] |= 
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
track->db_z_info |= 
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
+   ib[idx] |= 
(DB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
+   
DB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
+   
DB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
ib[idx] |= 
DB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
ib[idx] |= 
DB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
}
@@ -736,6 +739,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
*p, u32 reg, u32 idx)
return -EINVAL;
}
if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
+   ib[idx] |= (CB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
+   CB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
+   
CB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
ib[idx] |= 
CB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
ib[idx] |= 
CB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
}
@@ -1360,6 +1366,9 @@ static int evergreen_packet3_check(struct 
radeon_cs_parser *p,
if (reloc->lobj.tiling_flags & 
RADEON_TILING_MACRO) {
ib[idx+1+(i*8)+6] |= 
TEX_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
ib[idx+1+(i*8)+7] |= 
TEX_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
+   ib[idx+1+(i*8)+8] |= 
(TEX_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
+ 
TEX_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
+ 
TEX_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
}
}
texture = reloc->robj;
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index e00039e..3731e8f 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -903,6 +903,7 @@
 #   define DB_NUM_BANKS(x)  (((x) & 0x3) << 12)
 #

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

2011-12-13 Thread Arnd Bergmann 
On Monday 12 December 2011, Robert Morell wrote:
> > 
> > Doing a buffer sharing with something that is not GPL is not fun, as, if any
> > issue rises there, it would be impossible to discover if the problem is 
> > either
> > at the closed-source driver or at the open source one. At the time I was 
> > using
> > the Nvidia proprietary driver, it was very common to have unexplained issues
> > caused likely by bad code there at the buffer management code, causing X
> > applications and extensions (like xv) to break.
> >
> > We should really make this EXPORT_SYMBOL_GPL(), in order to be able to 
> > latter
> > debug future share buffer issues, when needed.
> 
> Sorry, I don't buy this argument.  Making these exports GPL-only is not
> likely to cause anybody to open-source their driver, but will rather
> just cause them to use yet more closed-source code that is even less
> debuggable than this would be, to those without access to the source.

But at least the broken module then won't be interacting with other modules
because it cannot share any buffers.

Arnd

[PATCH] radeon: Set macrotile shape on Evergreen hardware

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 03:08:53PM +, Simon Farnsworth wrote:
> Evergreen and later Radeons let the driver choose a macro tile layout,
> within certain constraints. If we don't set the appropriate fields
> correctly, the card will use a layout that doesn't normally meet the
> constraints on Evergreen tiling.
> 
> For now, select 8x8 aspect 1 macrotiles, as this makes it possible to
> guarantee that we meet the hardware constraints. Once macrotiling is
> reliable, we can consider a better API to let us exploit the hardware
> capabilities.
> 
> Signed-off-by: Simon Farnsworth 

NAK

We don't want to enforce those value in kernel. I am working on fixing
tiling accross the stack and such patch would only hurt us in the
future.

Cheers,
Jerome

> ---
> 
> This doesn't fix my problems with enabling macro tiling, but it does help
> somewhat. I also need to fix alignment in the DDX and Mesa to avoid
> misrendering, at which point I see CP lockups instead.
> 
> I'm therefore sending this, the DDX patch, and the Mesa patch out in order
> to avoid getting stuck in a world where I have an 80% fix, someone else has
> an 80% fix, and if only we talked, we'd have a 100% fix.
> 
>  drivers/gpu/drm/radeon/atombios_crtc.c |4 
>  drivers/gpu/drm/radeon/evergreen_cs.c  |9 +
>  drivers/gpu/drm/radeon/evergreend.h|7 +++
>  3 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index 2b97262..f982975 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -1113,6 +1113,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
>   else
>   tmp = rdev->config.evergreen.tile_config;
>  
> + fb_format |= 
> (EVERGREEN_GRPH_BANK_HEIGHT(EVERGREEN_ADDR_SURF_BANK_HEIGHT_8) |
> +   
> EVERGREEN_GRPH_BANK_WIDTH(EVERGREEN_ADDR_SURF_BANK_WIDTH_8) |
> +   
> EVERGREEN_GRPH_MACRO_TILE_ASPECT(EVERGREEN_ADDR_SURF_MACRO_TILE_ASPECT_1));
> +
>   switch ((tmp & 0xf0) >> 4) {
>   case 0: /* 4 banks */
>   fb_format |= 
> EVERGREEN_GRPH_NUM_BANKS(EVERGREEN_ADDR_SURF_4_BANK);
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index b53d1c6..a14a04e 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -532,6 +532,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
> *p, u32 reg, u32 idx)
>   ib[idx] |= 
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
>   track->db_z_info |= 
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
>   if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
> + ib[idx] |= 
> (DB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
> + 
> DB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
> + 
> DB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
>   ib[idx] |= 
> DB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
>   ib[idx] |= 
> DB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
>   }
> @@ -736,6 +739,9 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser 
> *p, u32 reg, u32 idx)
>   return -EINVAL;
>   }
>   if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
> + ib[idx] |= (CB_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
> + CB_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
> + 
> CB_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
>   ib[idx] |= 
> CB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
>   ib[idx] |= 
> CB_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
>   }
> @@ -1360,6 +1366,9 @@ static int evergreen_packet3_check(struct 
> radeon_cs_parser *p,
>   if (reloc->lobj.tiling_flags & 
> RADEON_TILING_MACRO) {
>   ib[idx+1+(i*8)+6] |= 
> TEX_TILE_SPLIT(evergreen_cs_get_tile_split(track->row_size));
>   ib[idx+1+(i*8)+7] |= 
> TEX_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
> + ib[idx+1+(i*8)+8] |= 
> (TEX_BANK_WIDTH(ADDR_SURF_BANK_WIDTH_8) |
> +   
> TEX_BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_8) |
> +   
> TEX_MACRO_TILE_ASPECT(ADDR_SURF_MACRO_TILE_ASPECT_1));
>   }
>

[PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread Jerome Glisse 
On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> Jerome pointed me to some accounting error in the DMA API debugging code and
> while I can't figure it out yet, I did notice some extreme slowness - which
> is due to the nouveau driver calling the unpopulate (now that unbind +
> unpopulate are squashed) quite a lot (this is using Gnome Shell - I think 
> GNOME2
> did not have those issues but I can't recall).
> 
> Anyhow these patches fix the 50% perf regression I saw and also some minor 
> bugs
> that I noticed.
> 

Gonna review those today and test them.

Cheers,
Jerome

[PATCH] drm: Enable reading 3D capabilities of 3D monitor

2011-12-13 Thread Adam Jackson 
On Fri, 2011-12-09 at 11:46 +, Kavuri, Sateesh wrote:

> + if ((multi_val == STRUCTURE_PRESENT) || 
> + (multi_val == STRUCTURE_MASK_PRESENT) ) {
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x01) == 
> 0x01)
> + caps->format |= 0x0; /* FRAME_PACKING */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x02) == 
> 0x02)
> + caps->format |= 0x1; 
> /*FIELD_ALTERNATIVE */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x04) == 
> 0x04)
> + caps->format |= 0x2; /* 
> LINE_ALTERNATIVE */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x08) == 
> 0x08)
> + caps->format |= 0x3; 
> /*SIDE_BY_SIDE_FULL */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x10) == 
> 0x10)
> + caps->format |= 0x4; /* L_DEPTH */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x20) == 
> 0x20)
> + caps->format |= 0x5; /* 
> L_DEPTH_GFX_GFX_DEPTH */
> + if ((edid_ext[i+15+hdmi_vic_len] & 0x40) == 
> 0x40)
> + caps->format |= 0x6; /* TOP_BOTTOM */
> + if ((edid_ext[i+14+hdmi_vic_len] & 0x01) == 
> 0x01)
> + caps->format |= 0x7; /* S_BY_S_HALF */
> + if ((edid_ext[i+14+hdmi_vic_len] & 0x80) == 
> 0x80)
> + caps->format |= 0x8; /* 
> S_BY_S_HALF_QUINCUNX */
> + }

This reads poorly, which makes me think it's wrong.  Is format supposed
to be a bitfield or an enum?

> +EXPORT_SYMBOL(drm_detect_3D_monitor);

I suspect this is poorly named.  There exist 3D displays which are not
HDMI.

> +#define VSIF_RESET_INDEX 0xFFF8
> +#define VSIF_RESET_BIT_22 0xFFBF
> +#define VSIF_SET_BIT_19 0x8
> +#define VSIF_RESET_BIT_20 0xFFEF
> +#define VSIF_RESET_BIT_17 0x1
> +#define VSIF_SET_BIT_16 0xFFFD
> +#define VSIF_SET_MASTER_BIT 0x40

i915 style is usually to write these as (1 << 22) I think.

More importantly, use semantic names for register contents.  "Bit 17"
doesn't mean anything.

> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8020798..5b4d09c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -798,6 +798,8 @@ extern int drm_mode_gamma_set_ioctl(struct drm_device 
> *dev,
>  extern u8 *drm_find_cea_extension(struct edid *edid);
>  extern bool drm_detect_hdmi_monitor(struct edid *edid);
>  extern bool drm_detect_monitor_audio(struct edid *edid);
> +extern bool drm_detect_3D_monitor(struct edid *edid);
> +//extern struct panel_3d_caps* drm_detect_3D_monitor(struct edid *edid);

Well, which is it?

> +enum s3d_formats {
> + FRAME_PACKING   = 0x0,
> + FIELD_ALTERNATIVE   = 0x1,
> + LINE_ALTERNATIVE= 0x2,
> + SIDE_BY_SIDE_FULL   = 0x3,
> + L_DEPTH = 0x4,
> + L_DEPTH_GFX_GFX_DEPTH   = 0x5,
> + TOP_BOTTOM  = 0x6, /* 0x7 is reserved for future */
> + SIDE_BY_SIDE_HALF   = 0x8  /* 0x9 onwards is reserved for future */
> +};

If format is supposed to be an enum, why aren't you using these symbolic
values?

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/353b0808/attachment.pgp>

[PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread Thomas Hellstrom 
On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
>
>> Jerome pointed me to some accounting error in the DMA API debugging code and
>> while I can't figure it out yet, I did notice some extreme slowness - which
>> is due to the nouveau driver calling the unpopulate (now that unbind +
>> unpopulate are squashed) quite a lot (this is using Gnome Shell - I think 
>> GNOME2
>> did not have those issues but I can't recall).
>>
>> Anyhow these patches fix the 50% perf regression I saw and also some minor 
>> bugs
>> that I noticed.
>>
>>  
> Gonna review those today and test them.
>
> Cheers,
> Jerome
>
Hi!

I'm not whether any drivers are still using the AGP backend?
Calling unpopulate / (previous clear) each time unbind is done should be 
quite
inefficient with that one, as AGP sets up its own data structures and 
copies page tables
on each populate. That should really be avoided unless there is a good 
reason to have it.

/Thomas

[PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread Konrad Rzeszutek Wilk 
On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> >>Jerome pointed me to some accounting error in the DMA API debugging code and
> >>while I can't figure it out yet, I did notice some extreme slowness - which
> >>is due to the nouveau driver calling the unpopulate (now that unbind +
> >>unpopulate are squashed) quite a lot (this is using Gnome Shell - I think 
> >>GNOME2
> >>did not have those issues but I can't recall).
> >>
> >>Anyhow these patches fix the 50% perf regression I saw and also some minor 
> >>bugs
> >>that I noticed.
> >>
> >Gonna review those today and test them.
> >
> >Cheers,
> >Jerome
> Hi!
> 
> I'm not whether any drivers are still using the AGP backend?

Uh, probably they do if the cards are AGP?
The problem I encountered was with an PCIe Nvidia card:

01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce 8600 GT] 
(rev a1

> Calling unpopulate / (previous clear) each time unbind is done
> should be quite
> inefficient with that one, as AGP sets up its own data structures
> and copies page tables
> on each populate. That should really be avoided unless there is a
> good reason to have it.

nouveau_bo_rd32 and nv50_crtc_cursor_set showed up as the callers that
were causing the unpopulate calls. It did happen _a lot_ when I moved the
cursor madly.

Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Keith Packard 
On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso  wrote:

> By using a bootable USB stick, I could check the logs, which
> showed many segfaults at /lib64/ld-2.14.90.so .

Ouch!

Please let me know if you find anything further; I'd like to get a
revert sent upstream in the next day or so.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/00b01562/attachment.pgp>

Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Daniel Vetter 
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso  palosanto.com> wrote:
> 
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
> 
> Ouch!
> 
> Please let me know if you find anything further; I'd like to get a
> revert sent upstream in the next day or so.

I think the revert is trtd. But if you revert it, please also
revert/disable the ilk vt-d workaound or apply one of Ben's patches,
because that one _does_ blow up, too.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 00/23] kill drm cruft with fire

2011-12-13 Thread Daniel Vetter 
On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote:
> 
> > > >> Testing this on via would be awesome! Iirc I haven't changed anything 
> > > >> in
> > > >> the via specific patches, but if it's more convenient you can also
> > > >> directly test my branch:
> > > >>
> > > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire
> > > >
> > > > Okay I tried the patches and it locked up the openchrome X server. I'm
> > > > going to try your branch tonight to see if it makes any difference. If 
> > > > it
> > > > still fails I will have to track down what the problem is.
> > >
> > > If you can bisect the issue, that would be awesome. Meanwhile my sis
> > > card arrived, so I'm hopefully get around to test that part of the
> > > series rsn. I'm traveling atm though, so response time will suffer a
> > > bit.
> > 
> > Any updates on testing results?
> 
> Yes I do. I'm using the patches you posted. Patches 1 to 10 work with no 
> problems. Ist patch 11 that breaks the openchrome xorg driver. Have to 
> do some digging to find the exact problem.

Thanks a lot for digging through these patches. As you've noted in patch
11, I don't set release_idlelock anywhere which results in the via driver
deadlocking when clients close. The same holds for the equivalent sis
patch. Updated patch series pushed to my kill-with-fire branch. Please
test and yell at me if it's still broken.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Daniel Vetter 
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso  palosanto.com> wrote:
> 
> > By using a bootable USB stick, I could check the logs, which
> > showed many segfaults at /lib64/ld-2.14.90.so .
> 
> Ouch!
> 
> Please let me know if you find anything further; I'd like to get a
> revert sent upstream in the next day or so.

Another patch to try is "drm/i915: Only clear the GPU domains upon a
successful finish" from the my-next branch available at:

http://cgit.freedesktop.org/~danvet/drm/log/?h=my-next

Or just the raw patch:

http://cgit.freedesktop.org/~danvet/drm/patch/?id=389a55581e30607af0fcde6cdb4e54f189cf46cf

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm_edid: support CEA video modes

2011-12-13 Thread Jesse Barnes 
On Sun, 13 Nov 2011 01:31:35 +0100
Christian Schmidt  wrote:

> TFT/plasma televisions and projectors have become commonplace, and so
> has the use of PCs to drive them. Add the video modes specified by an
> EDID's CEA extension to the mode database for a connector.

Dave, Christian has a few patches outstanding for CEA mode handling.
Getting them in makes sense to me and this patch looks like it's
structured nicely at least (I haven't checked the CEA bits against the
specs though).

Any chance we can get them included for 3.3?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/07b5e7e5/attachment.pgp>

Memory corruption starting in i915 code, in 3.2-rc5

2011-12-13 Thread Alex Villací­s Lasso 
El 12/12/11 11:41, Keith Packard escribi?:
> On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villac??s Lasso palosanto.com>  wrote:
>
>> Ran kernel with reverted patch for 6 hours without issues so far. Will
>> keep testing after work (issue happens with my home machine).
> Thanks much. Let me know if it's still stable this evening; I can send a
> revert along if you don't find any problems.
>
I just had a severe problem, but I am not sure if the patch (or its revert) is 
at fault.

I was running 3.2-rc5 at home, for an hour or so, when suddenly I could not 
launch any programs. I tried switching to the text console, but the login 
program restarted itself after typing "root", without waiting for the password. 
I then tried to reboot, 
but all of the installed kernels (even the stock Fedora ones) issued a kernel 
panic very early in the boot sequence, mentioning an attempt to kill init. By 
using a bootable USB stick, I could check the logs, which showed many segfaults 
at 
/lib64/ld-2.14.90.so . Even though running fsck -f on my / and /boot partitions 
(both ext4) showed no errors besides an unclean shutdown, the kernel panics on 
boot persisted. I eventually reinstalled the system from scratch, and kept my 
/home partition so 
that no important data was lost. I am still in the process of restoring my 
package list to the state before the crash.

Maybe the list corruption I experienced earlier was secondary damage, which now 
spread somewhere else and corrupted system files, but I do not have enough data 
to check this.

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread batouzo 

(Send similar post to LKML / linux.kernel but no responses there yet)

Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.

Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
drm_vblank_cleanup+0x78/0x90 [drm]
Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
drm_vblank_cleanup+0x48/0x90 [drm]

It is Amd Bulldozer computer, with Radeon card:
01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
[Radeon HD 5450]

Debian stable. Builded with make-kpkg using gcc 4.4.5

   messages: http://pastebin.com/NXN5EPtG
config used: http://pastebin.com/AeVxEX7c


With radeon + kms the bug happens around 1 in 3 boot ups, right after
the radeon is enabled (with slub debugging) or later with no debug (few
seconds later or on shutdown esp. in rmmod).

When disabling radeon and KMS the bug was not seen;


Please fix this bug :) What to test to help fixing it?


Interesting part of the messages linked above is:


[   94.401991] fb0: radeondrmfb frame buffer device
[   94.401992] drm: registered panic notifier
[   94.402033] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0
on minor 0
[   94.402921]
=
[   94.402961] BUG kmalloc-16: Poison overwritten
[   94.402982]
-
[   94.402983]
[   94.403025] INFO: 0x880137dbbc38-0x880137dbbc3b. First byte
0x0 instead of 0x6b
[   94.403066] INFO: Allocated in drm_vblank_init+0x139/0x260 [drm]
age=253 cpu=3 pid=535
[   94.403103]  set_track+0x58/0x100
[   94.403119]  alloc_debug_processing+0x160/0x170
[   94.403140]  __slab_alloc+0x26d/0x440
[   94.403160]  drm_vblank_init+0x139/0x260 [drm]
[   94.403182]  drm_debugfs_create_files+0xcb/0x1a0 [drm]
[   94.403208]  drm_vblank_init+0x139/0x260 [drm]
[   94.403228]  __kmalloc+0x100/0x180
[   94.403247]  drm_vblank_init+0x139/0x260 [drm]
[   94.403276]  radeon_irq_kms_init+0x6d/0x160 [radeon]
[   94.403303]  evergreen_init+0x11c/0x2a0 [radeon]
[   94.403337]  radeon_device_init+0x3c9/0x470 [radeon]
[   94.403367]  radeon_driver_load_kms+0xad/0x160 [radeon]
[   94.403394]  drm_get_pci_dev+0x198/0x2c0 [drm]
[   94.403416]  local_pci_probe+0x55/0xd0
[   94.403433]  pci_device_probe+0x10a/0x130
[   94.403453]  driver_sysfs_add+0x72/0xa0
[   94.403474] INFO: Freed in drm_vblank_cleanup+0x78/0x90 [drm] age=235
cpu=0 pid=535
[   94.403508]  set_track+0x58/0x100
[   94.403524]  free_debug_processing+0x1f3/0x240
[   94.403545]  __slab_free+0x1a6/0x2b0
[   94.403562]  native_read_tsc+0x2/0x20
[   94.403580]  delay_tsc+0x42/0x80
[   94.403598]  drm_vblank_cleanup+0x78/0x90 [drm]
[   94.403625]  radeon_irq_kms_fini+0xd/0x60 [radeon]
[   94.403651]  evergreen_init+0x289/0x2a0 [radeon]
[   94.403677]  radeon_device_init+0x3c9/0x470 [radeon]
[   94.403704]  radeon_driver_load_kms+0xad/0x160 [radeon]
[   94.403731]  drm_get_pci_dev+0x198/0x2c0 [drm]
[   94.403751]  local_pci_probe+0x55/0xd0
[   94.403772]  pci_device_probe+0x10a/0x130
[   94.403791]  driver_sysfs_add+0x72/0xa0
[   94.404806]  driver_probe_device+0x8e/0x1b0
[   94.405782]  __driver_attach+0x93/0xa0
[   94.406031] INFO: Slab 0xea0004df6e80 objects=23 used=23 fp=0x
   (null) flags=0x2004080
[   94.406031] INFO: Object 0x880137dbbc38 @offset=7224
fp=0x880137dbb830
[   94.406031]
[   94.406031] Bytes b4 0x880137dbbc28:  06 0e ff ff 00 00 00 00 5a
5a 5a 5a 5a 5a 5a 5a ..??
[   94.406031]   Object 0x880137dbbc38:  00 00 00 00 6b 6b 6b 6b 6b
6b 6b 6b 6b 6b 6b a5 kkk?
[   94.406031]  Redzone 0x880137dbbc48:  bb bb bb bb bb bb bb bb
 
[   94.406031]  Padding 0x880137dbbd88:  5a 5a 5a 5a 5a 5a 5a 5a
 
[   94.406031] Pid: 466, comm: udevd Not tainted 3.1.4-norm007+dbg #1
[   94.406031] Call Trace:
[   94.406031]  [] ? check_bytes_and_report+0x110/0x150
[   94.406031]  [] ? check_object+0x1fe/0x250
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? alloc_debug_processing+0xee/0x170
[   94.406031]  [] ? __slab_alloc+0x26d/0x440
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? inode_init_always+0xfc/0x1b0
[   94.406031]  [] ? alloc_inode+0x32/0x90
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? __kmalloc_track_caller+0xf8/0x180
[   94.406031]  [] ? kmemdup+0x27/0x60
[   94.406031]  [] ? shmem_symlink+0xd4/0x220
[   94.406031]  [] ? vfs_symlink+0x87/0xa0
[   94.406031]  [] ? sys_symlinkat+0xdc/0xf0
[   94.406031]  [] ? system_call_fastpath+0x16/0x1b
[   94.406031] FIX kmalloc-16: Restoring
0x880137dbbc38-0x880137dbbc3b=0x6b

[PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-13 Thread James Simmons 

> Hi!
> 
> I'm not whether any drivers are still using the AGP backend?

Actually the openchrome projects KMS kernel uses a AGP backend.


> Calling unpopulate / (previous clear) each time unbind is done should be quite
> inefficient with that one, as AGP sets up its own data structures and copies
> page tables
> on each populate. That should really be avoided unless there is a good reason
> to have it.
> 
> /Thomas
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

radeon stable patches

2011-12-13 Thread Greg KH 
On Tue, Dec 13, 2011 at 09:29:58AM -0500, Alex Deucher wrote:
> Hi Greg,
> 
> Can you cherry-pick the following patches back to the stable branches:
> b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11
> 1d33e1fc8dcce667a70387b666a8b6f60153d90f
> cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd
> They fix the internal panel setup on certain fusion laptops.  I've
> attached patches I cherry-picked myself against 3.1.x stable if you'd
> prefer that.

Thanks, all now applied.

Note, the email for stable has changed to stable at vger.kernel.org,
stable at kernel.org has been dead since August.

greg k-h

Patches queued to drm-intel-fixes

2011-12-13 Thread Keith Packard 
On Wed, 14 Dec 2011 00:04:26 +0100, Daniel Vetter  
wrote:
> Hi Keith,
> 
> I've noticed that you merged my patch "rm/i915: properly prefault for
> pread/pwrite" into your -fixes branch (which I assume is headed for
> 3.2). Please remove that from your queue again for the following
> reasons:

Thanks! I'll rework the patch series before submitting it.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/268bf21b/attachment.pgp>

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 10:26:15PM +0100, batouzo wrote:
> 
> (Send similar post to LKML / linux.kernel but no responses there yet)
> 
> Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
> 
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x78/0x90 [drm]
> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x48/0x90 [drm]
> 
> It is Amd Bulldozer computer, with Radeon card:
> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
> [Radeon HD 5450]
> 
> Debian stable. Builded with make-kpkg using gcc 4.4.5
> 
>messages: http://pastebin.com/NXN5EPtG
> config used: http://pastebin.com/AeVxEX7c
> 
> 
> With radeon + kms the bug happens around 1 in 3 boot ups, right after
> the radeon is enabled (with slub debugging) or later with no debug (few
> seconds later or on shutdown esp. in rmmod).
> 
> When disabling radeon and KMS the bug was not seen;
> 
> 
> Please fix this bug :) What to test to help fixing it?
> 
> 
> Interesting part of the messages linked above is:
> 

Do you boot your kernel with kexec ? Does the patch help :

http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch

If not please open bug on bugs.freedesktop.org against radeon driver.

Cheers,
Jerome

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 6:33 PM, batouzo  wrote:
> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>
>>> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
>>> drm_vblank_cleanup+0x78/0x90 [drm]
>>> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
>>> drm_vblank_cleanup+0x48/0x90 [drm]
>>>
>>> It is Amd Bulldozer computer, with Radeon card:
>>> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
>>> [Radeon HD 5450]
>>>
>>> ? ?messages: http://pastebin.com/NXN5EPtG
>>> config used: http://pastebin.com/AeVxEX7c
>
>>
>> Do you boot your kernel with kexec ? Does the patch help :
>
> Nope. Already seen that kexec bugfix on LKML but I start system normally
> not with kexec.
>
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch
>> If not please open bug on bugs.freedesktop.org against radeon driver.
>
> ok
>

Note that this patch might also help non kexec case.

Cheers,
Jerome

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

2011-12-13 Thread Jerome Glisse 
On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse  wrote:
> On Tue, Dec 13, 2011 at 6:33 PM, batouzo  wrote:
>> On 12/14/2011 12:31 AM, Jerome Glisse wrote:
>>
 Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
 drm_vblank_cleanup+0x78/0x90 [drm]
 Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
 drm_vblank_cleanup+0x48/0x90 [drm]

 It is Amd Bulldozer computer, with Radeon card:
 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
 [Radeon HD 5450]

 ? ?messages: http://pastebin.com/NXN5EPtG
 config used: http://pastebin.com/AeVxEX7c
>>
>>>
>>> Do you boot your kernel with kexec ? Does the patch help :
>>
>> Nope. Already seen that kexec bugfix on LKML but I start system normally
>> not with kexec.
>>
>>> http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch
>>> If not please open bug on bugs.freedesktop.org against radeon driver.
>>
>> ok
>>
>
> Note that this patch might also help non kexec case.
>
> Cheers,
> Jerome

Oh and try booting with radeon.no_wb=1

Cheers,
Jerome

[PATCH 2/2] drm/omap: drm API update: addfb2

2011-12-13 Thread Rob Clark 
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH  wrote:
> On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> Update to reflect changes in:
>> "drm: add an fb creation ioctl that takes a pixel format v5"
>
> This one I'm going to have to wait for the drm api merges to happen, so
> I'll just wait for them to go into Linus's tree before taking them, ok?

oh, heh.. I found a couple small cleanups to this patch (adding a
"const" to a table, and such).. since this can't be applied until
drm-next is merged, if you don't mind I'd like to resend this one in a
patchset along with the patches adding drm_plane support, which I'm
pretty close to ready to send.

BR,
-R

> thanks,
>
> greg k-h
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: disconnect plane from fb/crtc when disabled

2011-12-13 Thread Rob Clark 
From: Rob Clark 

Since plane->fb and plane->crtc are set in drm_mode_setplane()
after update_plane(), They should be cleared after disable().

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e2c9386..6dad421 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -348,6 +348,9 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
ret = plane->funcs->disable_plane(plane);
if (ret)
DRM_ERROR("failed to disable plane with busy 
fb\n");
+   /* disconnect the plane from the fb and crtc: */
+   plane->fb = NULL;
+   plane->crtc = NULL;
}
}

-- 
1.7.5.4

[PATCH 2/2] drm: add support for private planes

2011-12-13 Thread Rob Clark 
From: Rob Clark 

In cases where the scanout hw is sufficiently similar between "overlay"
and traditional crtc layers, it might be convenient to allow the driver
to create internal drm_plane helper objects used by the drm_crtc
implementation, rather than duplicate code between the plane and crtc.
A private plane is not exposed to userspace.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c |   22 +-
 include/drm/drm_crtc.h |3 ++-
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6dad421..d73746e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -557,7 +557,8 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
 int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
   unsigned long possible_crtcs,
   const struct drm_plane_funcs *funcs,
-  uint32_t *formats, uint32_t format_count)
+  const uint32_t *formats, uint32_t format_count,
+  bool priv)
 {
mutex_lock(&dev->mode_config.mutex);

@@ -576,8 +577,16 @@ int drm_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;

-   list_add_tail(&plane->head, &dev->mode_config.plane_list);
-   dev->mode_config.num_plane++;
+   /* private planes are not exposed to userspace, but depending on
+* display hardware, might be convenient to allow sharing programming
+* for the scanout engine with the crtc implementation.
+*/
+   if (!priv) {
+   list_add_tail(&plane->head, &dev->mode_config.plane_list);
+   dev->mode_config.num_plane++;
+   } else {
+   INIT_LIST_HEAD(&plane->head);
+   }

mutex_unlock(&dev->mode_config.mutex);

@@ -592,8 +601,11 @@ void drm_plane_cleanup(struct drm_plane *plane)
mutex_lock(&dev->mode_config.mutex);
kfree(plane->format_types);
drm_mode_object_put(dev, &plane->base);
-   list_del(&plane->head);
-   dev->mode_config.num_plane--;
+   /* if not added to a list, it must be a private plane */
+   if (!list_empty(&plane->head)) {
+   list_del(&plane->head);
+   dev->mode_config.num_plane--;
+   }
mutex_unlock(&dev->mode_config.mutex);
 }
 EXPORT_SYMBOL(drm_plane_cleanup);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index dd55727..1354ef5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -828,7 +828,8 @@ extern int drm_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
  unsigned long possible_crtcs,
  const struct drm_plane_funcs *funcs,
- uint32_t *formats, uint32_t format_count);
+ const uint32_t *formats, uint32_t format_count,
+ bool private);
 extern void drm_plane_cleanup(struct drm_plane *plane);

 extern void drm_encoder_cleanup(struct drm_encoder *encoder);
-- 
1.7.5.4

[PATCH] modetest: add drm_plane support

2011-12-13 Thread Rob Clark 
From: Rob Clark 

Signed-off-by: Rob Clark 
---
 tests/modetest/modetest.c |  166 ++---
 1 files changed, 157 insertions(+), 9 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..22ac620 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -51,6 +51,7 @@

 #include "xf86drm.h"
 #include "xf86drmMode.h"
+#include "drm_fourcc.h"
 #include "libkms.h"

 #ifdef HAVE_CAIRO
@@ -267,6 +268,49 @@ void dump_framebuffers(void)
printf("\n");
 }

+static void dump_planes(void)
+{
+   drmModePlaneRes *plane_resources;
+   drmModePlane *ovr;
+   int i, j;
+
+   plane_resources = drmModeGetPlaneResources(fd);
+   if (!plane_resources) {
+   fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+   strerror(errno));
+   return;
+   }
+
+   printf("Planes:\n");
+   printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n");
+   for (i = 0; i < plane_resources->count_planes; i++) {
+   ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+   if (!ovr) {
+   fprintf(stderr, "drmModeGetPlane failed: %s\n",
+   strerror(errno));
+   continue;
+   }
+
+   printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n",
+  ovr->plane_id, ovr->crtc_id, ovr->fb_id,
+  ovr->crtc_x, ovr->crtc_y, ovr->x, ovr->y,
+  ovr->gamma_size);
+
+   if (!ovr->count_formats)
+   continue;
+
+   printf("  formats:");
+   for (j = 0; j < ovr->count_formats; j++)
+   printf(" %4.4s", (char *)&ovr->formats[j]);
+   printf("\n");
+
+   drmModeFreePlane(ovr);
+   }
+   printf("\n");
+
+   return;
+}
+
 /*
  * Mode setting with the kernel interfaces is a bit of a chore.
  * First you have to find the connector in question and make sure the
@@ -280,11 +324,18 @@ struct connector {
drmModeModeInfo *mode;
drmModeEncoder *encoder;
int crtc;
+   int pipe;
unsigned int fb_id[2], current_fb_id;
struct timeval start;

int swap_count;
-}; 
+};
+
+struct plane {
+   uint32_t con_id;  /* the id of connector to bind to */
+   uint32_t w, h;
+   unsigned int fb_id;
+};

 static void
 connector_find_mode(struct connector *c)
@@ -351,6 +402,15 @@ connector_find_mode(struct connector *c)

if (c->crtc == -1)
c->crtc = c->encoder->crtc_id;
+
+   /* and figure out which crtc index it is: */
+   for (i = 0; i < resources->count_crtcs; i++) {
+   if (c->crtc == resources->crtcs[i]) {
+   c->pipe = i;
+   break;
+   }
+   }
+
 }

 static struct kms_bo *
@@ -534,13 +594,83 @@ page_flip_handler(int fd, unsigned int frame,
}
 }

+static int
+set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
+{
+   drmModePlaneRes *plane_resources;
+   drmModePlane *ovr;
+   uint32_t handles[4], pitches[4], offsets[4]; /* we only use [0] */
+   uint32_t plane_id = 0;
+   struct kms_bo *plane_bo;
+   uint32_t plane_flags = 0;
+   int i, crtc_x, crtc_y, crtc_w, crtc_h;
+
+   /* find an unused plane which can be connected to our crtc */
+   plane_resources = drmModeGetPlaneResources(fd);
+   if (!plane_resources) {
+   fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+   strerror(errno));
+   return -1;
+   }
+
+   for (i = 0; i < plane_resources->count_planes && !plane_id; i++) {
+   ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+   if (!ovr) {
+   fprintf(stderr, "drmModeGetPlane failed: %s\n",
+   strerror(errno));
+   return -1;
+   }
+
+   if ((ovr->possible_crtcs & (1 << c->pipe)) && !ovr->crtc_id)
+   plane_id = ovr->plane_id;
+
+   drmModeFreePlane(ovr);
+   }
+
+   if (!plane_id) {
+   fprintf(stderr, "failed to find plane!\n");
+   return -1;
+   }
+
+   /* TODO.. would be nice to test YUV overlays.. */
+   if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
+   return -1;
+
+   kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
+
+   /* just use single plane format for now.. */
+   if (drmModeAddFB2(fd, p->w, p->h, DRM_FORMAT_XRGB,
+   handles, pitches, offsets, &p->fb_id, plane_flags)) {
+   fprintf(stderr, "failed to add fb: %s\n", strerror(errno));
+   return -1;
+   }
+
+   /* ok, boring.. but for now put in middle of screen: */
+   crtc_x = c->mode-