Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi LAurent,
On Thu, Aug 11, 2011 at 19:19, Laurent Pinchart
wrote:
> On Monday 01 August 2011 11:49:46 Geert Uytterhoeven wrote:
>> As several of the FOURCC formats duplicate formats you can already specify
>> in some other way (e.g. the RGB and greyscale formats), and as FOURCC makes
>> life easier for the application writer, I'm wondering whether it makes sense
>> to add FOURCC support in the generic layer for drivers that don't support
>> it? I.e. the generic layer would fill in fb_var_screeninfo depending on the
>> requested FOURCC mode, if possible.
>
> That's a good idea, but I'd like to add that in a second step. I'm working on
> a proof-of-concept by porting a driver to the FOURCC-based API first.
Sure! I was just mentioning it, so we keep it in the back of our head and don't
make decisions now that would make it impossible to add that later.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #26 from Vladimir Ysikov 2011-08-13 03:57:02 PDT --- Created an attachment (id=50174) --> (https://bugs.freedesktop.org/attachment.cgi?id=50174) dmesg log Radeon HD4850 kernel 3.0.1 mesa-git [behem0th@ArchLinux ~]$ unigine-heaven Engine::init(): can't create log file Loading "/opt/unigine-heaven/bin/../data/heaven_2.5.cfg"... Engine::init(): clear video settings for "Gallium 0.4 on AMD RV770 2.1 Mesa 7.12-devel (git-e09b706)" Loading "libGL.so.1"... Loading "libopenal.so.1"... AL lib: pulseaudio.c:612: Context did not connect: Connection refused Set 640x480 windowed video mode Received signal SIGFPE, floating point exception [behem0th@ArchLinux ~]$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. floating point exception -- 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
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #27 from Vladimir Ysikov 2011-08-13 03:58:08 PDT --- Created an attachment (id=50175) --> (https://bugs.freedesktop.org/attachment.cgi?id=50175) Xorg.log -- 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
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #15 from Alex 2011-08-13 07:11:16 PDT --- Forgot to say I filed a bug asking to build ia32-libs in xorg-edgers PPA (as done for lucid and maverick) : --> https://bugs.launchpad.net/xorg-server/+bug/824346 -- 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
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #28 from Sven Arvidsson 2011-08-13 07:50:36 PDT --- (In reply to comment #26) [...] > kernel 3.0.1 [...] > Received signal SIGFPE, floating point exception > You need a more recent kernel. -- 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: Empty /proc/dri/0/bufs queues -
On Don, 2011-08-11 at 17:08 -0400, Vipin wrote: > > *I think the first message got discarded, posting a second one* It didn't, maybe it was delayed via the moderation queue. > Empty /proc/dri/0 bufs, queues files > Is this an expected behavior ? Yes, these aren't relevant with KMS. > /sys/kernel/debug/dri/ > > There are two directories 0 & 64, what does the 64 entry signify ? It corresponds to the control device node /dev/dri/controlD64 . There are legacy/control/render nodes, but I don't remember the details about the distinction. > The contents of /sys/kernel/debug/dri/0 contains 15 radeon_ib_00xx > Does this mean, the card has 15 indirect buffers ? The card imposes no restrictions on the number of indirect buffers (IBs) that can be allocated. The radeon driver pre-allocates 16 IBs for dispatching commands to the GPU. > Also, does this interface shows me the ringbuffer data like i915. Yes. > The kernel log shows entries like these (massive amounts) > Aug 11 13:19:01 gilubuntu1 kernel: [ 4251.705377] [drm:drm_ioctl], > pid=1544, cmd=0xc0086464, nr=0x64, dev 0xe200, auth=1 > Aug 11 13:19:01 gilubuntu1 kernel: [ 4251.705394] [drm:r600_irq_set], > r600_irq_set: sw int > > Shouldn't it have other debug entries other than these two ? It should, they might be drowned by these two. Or maybe you need to enable more debugging messages e.g. with drm.debug=0x3 or =0x7. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark
https://bugs.freedesktop.org/show_bug.cgi?id=39882 --- Comment #8 from Alex Deucher 2011-08-13 10:28:00 PDT --- Created an attachment (id=50185) View: https://bugs.freedesktop.org/attachment.cgi?id=50185 Review: https://bugs.freedesktop.org/review?bug=39882&attachment=50185 fix This patch fixes the issue. -- 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
[Bug 36939] multitexturing is messed up in quake wars (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=36939 almos changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #12 from almos 2011-08-13 10:33:30 PDT --- Now this problem appeared again. With medium shader detail all human deployables and the strogg AVT loose detail textures and lightmaps as approached. With high shader detail the wheels of some vehicles do this as well. -- 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
[PATCH] drm/radeon/kms: don't try to be smart in the hpd handler
From: Alex Deucher
Attempting to try and turn off disconnected display hw in the
hotput handler lead to more problems than it helped. For
now just register an event and only attempt the do something
interesting with DP. Other connectors are just too problematic:
- Some systems have an HPD pin assigned to LVDS, but it's rarely
if ever connected properly and we don't really care about hpd
events on LVDS anyway since it's always connected.
- The HPD pin is wired up correctly for eDP, but we don't really
have to do anything since the events since it's always connected.
- Some HPD pins fire more than once when you connect/disconnect
- etc.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39882
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atombios_dp.c | 12
drivers/gpu/drm/radeon/radeon_connectors.c | 14 ++
drivers/gpu/drm/radeon/radeon_mode.h |1 +
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 645b84b..7ad43c6 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -613,6 +613,18 @@ static bool radeon_dp_get_link_status(struct
radeon_connector *radeon_connector,
return true;
}
+bool radeon_dp_needs_link_train(struct radeon_connector *radeon_connector)
+{
+ u8 link_status[DP_LINK_STATUS_SIZE];
+ struct radeon_connector_atom_dig *dig = radeon_connector->con_priv;
+
+ if (!radeon_dp_get_link_status(radeon_connector, link_status))
+ return false;
+ if (dp_channel_eq_ok(link_status, dig->dp_lane_count))
+ return false;
+ return true;
+}
+
struct radeon_dp_link_train_info {
struct radeon_device *rdev;
struct drm_encoder *encoder;
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index b8ccdd7..df7ed82 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -64,18 +64,16 @@ void radeon_connector_hotplug(struct drm_connector
*connector)
if (connector->dpms != DRM_MODE_DPMS_ON)
return;
- /* powering up/down the eDP panel generates hpd events which
-* can interfere with modesetting.
-*/
- if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
- return;
+ /* just deal with DP (not eDP) here. */
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ int saved_dpms = connector->dpms;
- /* pre-r600 did not always have the hpd pins mapped accurately to
connectors */
- if (rdev->family >= CHIP_R600) {
- if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd))
+ if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd) &&
+ radeon_dp_needs_link_train(radeon_connector))
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
else
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ connector->dpms = saved_dpms;
}
}
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 6df4e3c..f2e8267 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -476,6 +476,7 @@ extern void radeon_dp_set_link_config(struct drm_connector
*connector,
struct drm_display_mode *mode);
extern void radeon_dp_link_train(struct drm_encoder *encoder,
struct drm_connector *connector);
+extern bool radeon_dp_needs_link_train(struct radeon_connector
*radeon_connector);
extern u8 radeon_dp_getsinktype(struct radeon_connector *radeon_connector);
extern bool radeon_dp_getdpcd(struct radeon_connector *radeon_connector);
extern void atombios_dig_encoder_setup(struct drm_encoder *encoder, int
action, int panel_mode);
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40062] New: in etqw the strogg radar is black
https://bugs.freedesktop.org/show_bug.cgi?id=40062 Summary: in etqw the strogg radar is black Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: aaalmo...@gmail.com Created an attachment (id=50186) --> (https://bugs.freedesktop.org/attachment.cgi?id=50186) stderr with RADEON_DEBUG=fp With shader detail=high the strogg radar becomes completely black. I think this corresponds to the two compiler errors (log attached). -- 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
[Bug 40062] in etqw the strogg radar is black (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=40062 almos changed: What|Removed |Added Summary|in etqw the strogg radar is |in etqw the strogg radar is |black |black (regression) --- Comment #1 from almos 2011-08-13 10:46:18 PDT --- I forgot to mention that this used to work couple of months ago. -- 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
[Bug 40062] in etqw the strogg radar is black (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=40062 --- Comment #2 from Alex Deucher 2011-08-13 11:51:23 PDT --- Can you bisect? -- 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 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
On Fri, Aug 12, 2011 at 7:21 PM, Jerome Glisse wrote:
>> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> index 3832fe1..0438296 100644
>> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> @@ -223,6 +223,14 @@ void ttm_eu_fence_buffer_objects(struct list_head
>> *list, void *sync_obj)
>> bo = entry->bo;
>> entry->old_sync_obj = bo->sync_obj;
>
> Here we should set entry->old_sync_obj_read &
> entry->old_sync_obj_write to NULL so
> we don't get bite by uninitialized memory (if caller fail or forget to do so)
OK, thanks. It's fixed in the attached patch. There are no other changes.
Marek
From 1abe40ba3cffb8fd4d593cdbe060c04dbdc0687c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Sun, 7 Aug 2011 05:36:50 +0200
Subject: [PATCH] drm/ttm: add a way to bo_wait for either the last read or last write (v2)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
reading that buffer, and a CPU wants to map that buffer for read, it needs to
only wait for the last write. If there were no write, there wouldn't be any
waiting needed.
This, or course, requires user space drivers to send read/write flags
with each relocation (like we have read/write domains in radeon, so we can
actually use those for something useful now).
Now how this patch works:
The read/write flags should passed to ttm_validate_buffer. TTM maintains
separate sync objects of the last read and write for each buffer, in addition
to the sync object of the last use of a buffer. ttm_bo_wait then operates
with one the sync objects.
Signed-off-by: Marek Olšák
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c|3 +-
drivers/gpu/drm/nouveau/nouveau_gem.c |5 +-
drivers/gpu/drm/radeon/radeon_cs.c |1 +
drivers/gpu/drm/radeon/radeon_object.h |2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 97 ++
drivers/gpu/drm/ttm/ttm_bo_util.c | 26 +++--
drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 19 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |1 +
include/drm/ttm/ttm_bo_api.h| 16 +-
include/drm/ttm/ttm_execbuf_util.h |6 ++
11 files changed, 139 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 890d50e..e87e24b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1104,7 +1104,8 @@ nouveau_bo_vma_del(struct nouveau_bo *nvbo, struct nouveau_vma *vma)
if (vma->node) {
if (nvbo->bo.mem.mem_type != TTM_PL_SYSTEM) {
spin_lock(&nvbo->bo.bdev->fence_lock);
- ttm_bo_wait(&nvbo->bo, false, false, false);
+ ttm_bo_wait(&nvbo->bo, false, false, false,
+TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
nouveau_vm_unmap(vma);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 5f0bc57..322bf62 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -589,7 +589,8 @@ nouveau_gem_pushbuf_reloc_apply(struct drm_device *dev,
}
spin_lock(&nvbo->bo.bdev->fence_lock);
- ret = ttm_bo_wait(&nvbo->bo, false, false, false);
+ ret = ttm_bo_wait(&nvbo->bo, false, false, false,
+ TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
if (ret) {
NV_ERROR(dev, "reloc wait_idle failed: %d\n", ret);
@@ -825,7 +826,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void *data,
nvbo = nouveau_gem_object(gem);
spin_lock(&nvbo->bo.bdev->fence_lock);
- ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait);
+ ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait, TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
drm_gem_object_unreference_unlocked(gem);
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c
index fae00c0..14e8531 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -80,6 +80,7 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
p->relocs[i].lobj.wdomain = r->write_domain;
p->relocs[i].lobj.rdomain = r->read_domains;
p->relocs[i].lobj.tv.bo = &p->relocs[i].robj->tbo;
+ p->relocs[i].lobj.tv.usage = TTM_USAGE_READWRITE;
p->relocs[i].handle = r->handle;
p->relocs[i].flags = r->flags;
radeon_bo_list_add_object(&p->relocs[i].lobj,
diff --git a/drive
[Bug 38478] r600g fails to identify the screen refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=38478 Stephen Kitt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Stephen Kitt 2011-08-13 16:06:22 PDT --- I've just figured out what was going on - I noticed after rebooting (to check whether the bug was fixed in 3.0) that the IRQ used by my Radeon card was disabled. It's shared with some of the USB ports and an interrupt arrives before all the drivers have initialised correctly. Reloading the uhci-hcd module re-enables the interrupt and restores full functionality! -- 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
[PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi LAurent,
On Thu, Aug 11, 2011 at 19:19, Laurent Pinchart
wrote:
> On Monday 01 August 2011 11:49:46 Geert Uytterhoeven wrote:
>> As several of the FOURCC formats duplicate formats you can already specify
>> in some other way (e.g. the RGB and greyscale formats), and as FOURCC makes
>> life easier for the application writer, I'm wondering whether it makes sense
>> to add FOURCC support in the generic layer for drivers that don't support
>> it? I.e. the generic layer would fill in fb_var_screeninfo depending on the
>> requested FOURCC mode, if possible.
>
> That's a good idea, but I'd like to add that in a second step. I'm working on
> a proof-of-concept by porting a driver to the FOURCC-based API first.
Sure! I was just mentioning it, so we keep it in the back of our head and don't
make decisions now that would make it impossible to add that later.
Gr{oetje,eeting}s,
? ? ? ? ? ? ? ? ? ? ? ? Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #26 from Vladimir Ysikov 2011-08-13 03:57:02 PDT --- Created an attachment (id=50174) --> (https://bugs.freedesktop.org/attachment.cgi?id=50174) dmesg log Radeon HD4850 kernel 3.0.1 mesa-git [behem0th at ArchLinux ~]$ unigine-heaven Engine::init(): can't create log file Loading "/opt/unigine-heaven/bin/../data/heaven_2.5.cfg"... Engine::init(): clear video settings for "Gallium 0.4 on AMD RV770 2.1 Mesa 7.12-devel (git-e09b706)" Loading "libGL.so.1"... Loading "libopenal.so.1"... AL lib: pulseaudio.c:612: Context did not connect: Connection refused Set 640x480 windowed video mode Received signal SIGFPE, floating point exception [behem0th at ArchLinux ~]$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. floating point exception -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #27 from Vladimir Ysikov 2011-08-13 03:58:08 PDT --- Created an attachment (id=50175) --> (https://bugs.freedesktop.org/attachment.cgi?id=50175) Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Reverting rc6 by default
On Fri, Aug 12, 2011 at 12:53:52PM -0700, Keith Packard wrote: > Can you send me your kernel .config file? I'm still not having any luck > reproducing your problems, using an X201s with the 1.22 BIOS version. > > I'm wondering if the trouble is caused by the the selection of kernel config > parameters Kernel config attached. Bye Francesco -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.1.0-rc1 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_NEED_DMA_MAP_STATE is not set CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_KTIME_SCALAR=y CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_FHANDLE is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y # CONFIG_OPROFILE is not set CONFIG_
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #15 from Alex 2011-08-13 07:11:16 PDT --- Forgot to say I filed a bug asking to build ia32-libs in xorg-edgers PPA (as done for lucid and maverick) : --> https://bugs.launchpad.net/xorg-server/+bug/824346 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #28 from Sven Arvidsson 2011-08-13 07:50:36 PDT --- (In reply to comment #26) [...] > kernel 3.0.1 [...] > Received signal SIGFPE, floating point exception > You need a more recent kernel. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Empty /proc/dri/0/bufs queues -
On Don, 2011-08-11 at 17:08 -0400, Vipin wrote: > > *I think the first message got discarded, posting a second one* It didn't, maybe it was delayed via the moderation queue. > Empty /proc/dri/0 bufs, queues files > Is this an expected behavior ? Yes, these aren't relevant with KMS. > /sys/kernel/debug/dri/ > > There are two directories 0 & 64, what does the 64 entry signify ? It corresponds to the control device node /dev/dri/controlD64 . There are legacy/control/render nodes, but I don't remember the details about the distinction. > The contents of /sys/kernel/debug/dri/0 contains 15 radeon_ib_00xx > Does this mean, the card has 15 indirect buffers ? The card imposes no restrictions on the number of indirect buffers (IBs) that can be allocated. The radeon driver pre-allocates 16 IBs for dispatching commands to the GPU. > Also, does this interface shows me the ringbuffer data like i915. Yes. > The kernel log shows entries like these (massive amounts) > Aug 11 13:19:01 gilubuntu1 kernel: [ 4251.705377] [drm:drm_ioctl], > pid=1544, cmd=0xc0086464, nr=0x64, dev 0xe200, auth=1 > Aug 11 13:19:01 gilubuntu1 kernel: [ 4251.705394] [drm:r600_irq_set], > r600_irq_set: sw int > > Shouldn't it have other debug entries other than these two ? It should, they might be drowned by these two. Or maybe you need to enable more debugging messages e.g. with drm.debug=0x3 or =0x7. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark
https://bugs.freedesktop.org/show_bug.cgi?id=39882 --- Comment #8 from Alex Deucher 2011-08-13 10:28:00 PDT --- Created an attachment (id=50185) View: https://bugs.freedesktop.org/attachment.cgi?id=50185 Review: https://bugs.freedesktop.org/review?bug=39882&attachment=50185 fix This patch fixes the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36939] multitexturing is messed up in quake wars (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=36939 almos changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #12 from almos 2011-08-13 10:33:30 PDT --- Now this problem appeared again. With medium shader detail all human deployables and the strogg AVT loose detail textures and lightmaps as approached. With high shader detail the wheels of some vehicles do this as well. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: don't try to be smart in the hpd handler
From: Alex Deucher
Attempting to try and turn off disconnected display hw in the
hotput handler lead to more problems than it helped. For
now just register an event and only attempt the do something
interesting with DP. Other connectors are just too problematic:
- Some systems have an HPD pin assigned to LVDS, but it's rarely
if ever connected properly and we don't really care about hpd
events on LVDS anyway since it's always connected.
- The HPD pin is wired up correctly for eDP, but we don't really
have to do anything since the events since it's always connected.
- Some HPD pins fire more than once when you connect/disconnect
- etc.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39882
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/atombios_dp.c | 12
drivers/gpu/drm/radeon/radeon_connectors.c | 14 ++
drivers/gpu/drm/radeon/radeon_mode.h |1 +
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 645b84b..7ad43c6 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -613,6 +613,18 @@ static bool radeon_dp_get_link_status(struct
radeon_connector *radeon_connector,
return true;
}
+bool radeon_dp_needs_link_train(struct radeon_connector *radeon_connector)
+{
+ u8 link_status[DP_LINK_STATUS_SIZE];
+ struct radeon_connector_atom_dig *dig = radeon_connector->con_priv;
+
+ if (!radeon_dp_get_link_status(radeon_connector, link_status))
+ return false;
+ if (dp_channel_eq_ok(link_status, dig->dp_lane_count))
+ return false;
+ return true;
+}
+
struct radeon_dp_link_train_info {
struct radeon_device *rdev;
struct drm_encoder *encoder;
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index b8ccdd7..df7ed82 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -64,18 +64,16 @@ void radeon_connector_hotplug(struct drm_connector
*connector)
if (connector->dpms != DRM_MODE_DPMS_ON)
return;
- /* powering up/down the eDP panel generates hpd events which
-* can interfere with modesetting.
-*/
- if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
- return;
+ /* just deal with DP (not eDP) here. */
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ int saved_dpms = connector->dpms;
- /* pre-r600 did not always have the hpd pins mapped accurately to
connectors */
- if (rdev->family >= CHIP_R600) {
- if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd))
+ if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd) &&
+ radeon_dp_needs_link_train(radeon_connector))
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
else
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ connector->dpms = saved_dpms;
}
}
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 6df4e3c..f2e8267 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -476,6 +476,7 @@ extern void radeon_dp_set_link_config(struct drm_connector
*connector,
struct drm_display_mode *mode);
extern void radeon_dp_link_train(struct drm_encoder *encoder,
struct drm_connector *connector);
+extern bool radeon_dp_needs_link_train(struct radeon_connector
*radeon_connector);
extern u8 radeon_dp_getsinktype(struct radeon_connector *radeon_connector);
extern bool radeon_dp_getdpcd(struct radeon_connector *radeon_connector);
extern void atombios_dig_encoder_setup(struct drm_encoder *encoder, int
action, int panel_mode);
--
1.7.1.1
[Bug 40062] New: in etqw the strogg radar is black
https://bugs.freedesktop.org/show_bug.cgi?id=40062 Summary: in etqw the strogg radar is black Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: aaalmosss at gmail.com Created an attachment (id=50186) --> (https://bugs.freedesktop.org/attachment.cgi?id=50186) stderr with RADEON_DEBUG=fp With shader detail=high the strogg radar becomes completely black. I think this corresponds to the two compiler errors (log attached). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40062] in etqw the strogg radar is black (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=40062 almos changed: What|Removed |Added Summary|in etqw the strogg radar is |in etqw the strogg radar is |black |black (regression) --- Comment #1 from almos 2011-08-13 10:46:18 PDT --- I forgot to mention that this used to work couple of months ago. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40062] in etqw the strogg radar is black (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=40062 --- Comment #2 from Alex Deucher 2011-08-13 11:51:23 PDT --- Can you bisect? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
On Fri, Aug 12, 2011 at 7:21 PM, Jerome Glisse wrote: >> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c >> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c >> index 3832fe1..0438296 100644 >> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c >> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c >> @@ -223,6 +223,14 @@ void ttm_eu_fence_buffer_objects(struct list_head >> *list, void *sync_obj) >> ? ? ? ? ? ? ? ?bo = entry->bo; >> ? ? ? ? ? ? ? ?entry->old_sync_obj = bo->sync_obj; > > Here we should set entry->old_sync_obj_read & > entry->old_sync_obj_write to NULL so > we don't get bite by uninitialized memory (if caller fail or forget to do so) OK, thanks. It's fixed in the attached patch. There are no other changes. Marek -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-ttm-add-a-way-to-bo_wait-for-either-the-last-rea.patch Type: text/x-diff Size: 18479 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110813/5a52dcc2/attachment.patch>
[Bug 38478] r600g fails to identify the screen refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=38478 Stephen Kitt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Stephen Kitt 2011-08-13 16:06:22 PDT --- I've just figured out what was going on - I noticed after rebooting (to check whether the bug was fixed in 3.0) that the IRQ used by my Radeon card was disabled. It's shared with some of the USB ports and an interrupt arrives before all the drivers have initialised correctly. Reloading the uhci-hcd module re-enables the interrupt and restores full functionality! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
