RFC: radeon i2c algo
The attached set of patches adds an i2c algo for radeon hardware. It
transparently supports bit-banging i2c on all asics and uses the hw
i2c engine on supported asics (r1xx-r5xx right now, support for newer
chips can be added later). For the bit banging, it encapsulates the
gpio masking that needs to be done before using the lines, so
i2c_transfer can be used directly and the buses can be used for other
drivers like tuners, thermal chips, etc. I used i2c-bit-algo in the
radeon i2c algo, is that kosher? It seems to make more sense than
dragging i2c-bit-algo into the driver. Thoughts?
Alex
From 336b19d162f7b501288bd2b4eb676c84e5435516 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 22 Dec 2009 15:04:48 -0500
Subject: [PATCH] drm/radeon/kms: add radeon i2c algo
Currently just a wrapper around bit algo
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_combios.c| 40 +---
drivers/gpu/drm/radeon/radeon_connectors.c | 14 +
drivers/gpu/drm/radeon/radeon_display.c|4 -
drivers/gpu/drm/radeon/radeon_i2c.c| 91 +---
drivers/gpu/drm/radeon/radeon_mode.h | 25 +---
5 files changed, 102 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c
index 6bab8b8..47b7d92 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2345,23 +2345,21 @@ void radeon_external_tmds_setup(struct drm_encoder *encoder)
switch (tmds->dvo_chip) {
case DVO_SIL164:
/* sil 164 */
- radeon_i2c_do_lock(tmds->i2c_bus, 1);
- radeon_i2c_sw_put_byte(tmds->i2c_bus,
- tmds->slave_addr,
- 0x08, 0x30);
- radeon_i2c_sw_put_byte(tmds->i2c_bus,
+ radeon_i2c_put_byte(tmds->i2c_bus,
+tmds->slave_addr,
+0x08, 0x30);
+ radeon_i2c_put_byte(tmds->i2c_bus,
tmds->slave_addr,
0x09, 0x00);
- radeon_i2c_sw_put_byte(tmds->i2c_bus,
- tmds->slave_addr,
- 0x0a, 0x90);
- radeon_i2c_sw_put_byte(tmds->i2c_bus,
- tmds->slave_addr,
- 0x0c, 0x89);
- radeon_i2c_sw_put_byte(tmds->i2c_bus,
+ radeon_i2c_put_byte(tmds->i2c_bus,
+tmds->slave_addr,
+0x0a, 0x90);
+ radeon_i2c_put_byte(tmds->i2c_bus,
+tmds->slave_addr,
+0x0c, 0x89);
+ radeon_i2c_put_byte(tmds->i2c_bus,
tmds->slave_addr,
0x08, 0x3b);
- radeon_i2c_do_lock(tmds->i2c_bus, 0);
break;
case DVO_SIL1178:
/* sil 1178 - untested */
@@ -2446,11 +2444,9 @@ bool radeon_combios_external_tmds_setup(struct drm_encoder *encoder)
index++;
val = RBIOS8(index);
index++;
- radeon_i2c_do_lock(tmds->i2c_bus, 1);
- radeon_i2c_sw_put_byte(tmds->i2c_bus,
- slave_addr,
- reg, val);
- radeon_i2c_do_lock(tmds->i2c_bus, 0);
+ radeon_i2c_put_byte(tmds->i2c_bus,
+slave_addr,
+reg, val);
break;
default:
DRM_ERROR("Unknown id %d\n", id >> 13);
@@ -2503,11 +2499,9 @@ bool radeon_combios_external_tmds_setup(struct drm_encoder *encoder)
reg = id & 0x1fff;
val = RBIOS8(index);
index += 1;
- radeon_i2c_do_lock(tmds->i2c_bus, 1);
- radeon_i2c_sw_put_byte(tmds->i2c_bus,
- tmds->slave_addr,
- reg, val);
- radeon_i2c_do_lock(tmds->i2c_bus, 0);
+ radeon_i2c_put_byte(tmds->i2c_bus,
+ tmds->slave_addr,
+ reg, val);
break;
default:
DRM_ERROR("Unknown id %d\n", id >> 13);
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 8da06e1..d7a2081 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -465,10 +465,8 @@ static enum drm_connector_status radeon_lvds_detect(struct drm_connector *connec
ret = connector_status_connected;
else {
if (radeon_connector->ddc_bus) {
- radeon_i2c_do_lock(radeon_connector->ddc_bus, 1);
radeon_connector->edid = drm_get_edid(&radeon_connector->base,
&radeon_connector->ddc_bus->adapter);
- radeon_i2c_do_lock(radeon_connector->ddc_bus, 0);
if (radeon_connector->edid)
ret = connector_status_connected;
}
@@ -573,17 +571,13 @@ static enum drm_connector_status radeon_vga_detect(struct drm_connector *connect
if (!encoder)
ret = connector_status_disconnected;
- radeon_i2c_do_lock(radeon_connector->ddc_bus, 1);
dret = radeon_ddc_probe(radeon_connector);
- radeon_i2c_do_lock(radeon_connector->ddc_bus, 0);
if (dret) {
if (radeon_connector->edid) {
kfree(radeon_connector->edid);
radeon_connector->edid = NULL;
}
- radeon_i2c_do_lock(radeon_connector->ddc_bus, 1);
radeon_connector->edid = drm_get_edid(&radeon_connector->base, &radeon_connector->ddc_bus->adapter);
- radeon_i2c_do_lock(radeon_connector->ddc_bus, 0);
if (!radeon_connector->edid) {
DRM_ERROR("%s: probed
[Bug 25776] New: [regression] crash on loading radeon module on 2.6.33-rc1 vanilla
http://bugs.freedesktop.org/show_bug.cgi?id=25776 Summary: [regression] crash on loading radeon module on 2.6.33- rc1 vanilla Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: high Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: uz...@o2.pl radeon loaded with modeset=1 crash with some data notated (could be usefull): BUG: unable to handle kernel NULL pointer dereference ar 0x48 IP ttm_bo_reserve+0x1d [ttm] RIP: ttm_bo_reserve+0x1d Call Trace: rv770_suspend+0x4d/0xb0 rv770_init+0x243/0x290 want more info? please write down. haven't check without nomodeset last time on 2.6.32-rc8 it was ok. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Fix crash getting TV info with no BIOS.
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_combios.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index fd94dbc..dd481dd 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -641,6 +641,9 @@ radeon_combios_get_tv_info(struct radeon_device *rdev)
uint16_t tv_info;
enum radeon_tv_std tv_std = TV_STD_NTSC;
+ if (rdev->bios == NULL)
+ return tv_std;
+
tv_info = combios_get_table_offset(dev, COMBIOS_TV_INFO_TABLE);
if (tv_info) {
if (RBIOS8(tv_info + 6) == 'T') {
--
1.6.5.7
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Only flush the HDP read cache for BOs which are in VRAM.
From: Michel Dänzer
The HDP read cache should only affect CPU reads from VRAM.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_gem.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 60df2d7..188bf9b 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -125,13 +125,15 @@ int radeon_gem_set_domain(struct drm_gem_object *gobj,
return 0;
}
if (domain == RADEON_GEM_DOMAIN_CPU) {
+ uint32_t cur_placement;
/* Asking for cpu access wait for object idle */
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, &cur_placement, false);
if (r) {
printk(KERN_ERR "Failed to wait for object !\n");
return r;
}
- radeon_hdp_flush(robj->rdev);
+ if (cur_placement == TTM_PL_VRAM)
+ radeon_hdp_flush(robj->rdev);
}
return 0;
}
@@ -301,6 +303,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
struct drm_radeon_gem_wait_idle *args = data;
struct drm_gem_object *gobj;
struct radeon_bo *robj;
+ uint32_t cur_placement = 0;
int r;
gobj = drm_gem_object_lookup(dev, filp, args->handle);
@@ -308,11 +311,12 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
void *data,
return -EINVAL;
}
robj = gobj->driver_private;
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, &cur_placement, false);
mutex_lock(&dev->struct_mutex);
drm_gem_object_unreference(gobj);
mutex_unlock(&dev->struct_mutex);
- radeon_hdp_flush(robj->rdev);
+ if (cur_placement == TTM_PL_VRAM)
+ radeon_hdp_flush(robj->rdev);
return r;
}
--
1.6.5.7
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Storage class should be before const qualifier
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser
---
drivers/gpu/drm/i915/intel_display.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 52cd9b0..2256ac7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2448,7 +2448,7 @@ static void pineview_enable_cxsr(struct drm_device *dev,
unsigned long clock,
* A value of 5us seems to be a good balance; safe for very low end
* platforms but not overly aggressive on lower latency configs.
*/
-const static int latency_ns = 5000;
+static const int latency_ns = 5000;
static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
{
@@ -2559,7 +2559,7 @@ static void g4x_update_wm(struct drm_device *dev, int
planea_clock,
/* Calc sr entries for one plane configs */
if (sr_hdisplay && (!planea_clock || !planeb_clock)) {
/* self-refresh has much higher latency */
- const static int sr_latency_ns = 12000;
+ static const int sr_latency_ns = 12000;
sr_clock = planea_clock ? planea_clock : planeb_clock;
line_time_us = ((sr_hdisplay * 1000) / sr_clock);
@@ -2598,7 +2598,7 @@ static void i965_update_wm(struct drm_device *dev, int
planea_clock,
/* Calc sr entries for one plane configs */
if (sr_hdisplay && (!planea_clock || !planeb_clock)) {
/* self-refresh has much higher latency */
- const static int sr_latency_ns = 12000;
+ static const int sr_latency_ns = 12000;
sr_clock = planea_clock ? planea_clock : planeb_clock;
line_time_us = ((sr_hdisplay * 1000) / sr_clock);
@@ -2667,7 +2667,7 @@ static void i9xx_update_wm(struct drm_device *dev, int
planea_clock,
if (HAS_FW_BLC(dev) && sr_hdisplay &&
(!planea_clock || !planeb_clock)) {
/* self-refresh has much higher latency */
- const static int sr_latency_ns = 6000;
+ static const int sr_latency_ns = 6000;
sr_clock = planea_clock ? planea_clock : planeb_clock;
line_time_us = ((sr_hdisplay * 1000) / sr_clock);
--
1.6.3.3
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25779] New: Crash in radeon using the drm-radeon-testing branch of drm-next
http://bugs.freedesktop.org/show_bug.cgi?id=25779 Summary: Crash in radeon using the drm-radeon-testing branch of drm-next Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: kdeko...@yahoo.com [drm] TMDS-9: set mode 1680x1050 26 executing set pll executing set crtc timing [drm] TMDS-15: set mode 1280x1024 28 Console: switching to colour frame buffer device 160x64 fb0: radeondrmfb frame buffer device registered panic notifier [drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0 dracut: Starting plymouth daemon BUG: unable to handle kernel NULL pointer dereference at 0080 IP: [] atombios_crtc_set_base+0x64/0x5ab [radeon] PGD 213ff7067 PUD 2135c2067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/kernel/uevent_seqnum CPU 1 Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core Pid: 186, comm: plymouthd Not tainted 2.6.32 #10 P5E-VM HDMI RIP: 0010:[] [] atombios_crtc_set_base+0x64/0x5ab [radeon] RSP: 0018:880213f7db88 EFLAGS: 00010286 RAX: RBX: 880213761000 RCX: 880213f22540 RDX: RSI: RDI: 880213761000 RBP: 880213f7dbe8 R08: 000e R09: 880213762000 R10: 880213762008 R11: 880213fcbe40 R12: R13: 88021376 R14: R15: 880210d8e201 FS: 7fdc8f5d1700() GS:88002828() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0080 CR3: 000213f47000 CR4: 06e0 After using git pull --rebase and rebuilding the git tree at 9cb5af651634bc2dcc68b58a949a67c251ae222a I would boot the kernel and get this crash. I also rebuild libdrm and xf86-video-ati at the same time. Reverting to an earlier kernel is fine. DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process plymouthd (pid: 186, threadinfo 880213f7c000, task 88021375c5f0) Stack: 0001 880213e07218 1344dc00 880213f22540 <0> 0009 88021344dc08 880213f7dbe8 a00c2d70 <0> 88021366b000 88021366b328 880210d8e201 Call Trace: [] drm_crtc_helper_set_config+0x62f/0x778 [drm_kms_helper] [] drm_mode_setcrtc+0x2d2/0x301 [drm] [] ? drm_mode_object_find+0x56/0x65 [drm] [] ? drm_mode_setcrtc+0x0/0x301 [drm] [] drm_ioctl+0x237/0x2f5 [drm] [] ? tty_ioctl+0x7af/0x7ce [] vfs_ioctl+0x6f/0x87 [] do_vfs_ioctl+0x47b/0x4c1 [] sys_ioctl+0x56/0x79 [] system_call_fastpath+0x16/0x1b Code: 13 d1 0c a0 48 c7 c2 b0 2d 0c a0 48 c7 c6 20 d1 0c a0 bf 01 00 00 00 45 31 f6 e8 cd 38 f9 ff e9 3c 05 00 00 48 8b 80 a8 00 00 00 <4c> 8b b8 80 00 00 00 4c 89 ff e8 20 ff ff ff 85 c0 41 89 c6 0f RIP [] atombios_crtc_set_base+0x64/0x5ab [radeon] RSP CR2: 0080 ---[ end trace b0de8d06b46486f0 ]--- dracut: error: unexpectedly disconnected from boot status daemon -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25779] Crash in radeon using the drm-radeon-testing branch of drm-next
http://bugs.freedesktop.org/show_bug.cgi?id=25779 --- Comment #1 from Kevin DeKorte 2009-12-23 08:14:36 PST --- Card is an rv635 card 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3600 Series (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 01da Flags: bus master, fast devsel, latency 0, IRQ 29 Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fe9e (64-bit, non-prefetchable) [size=64K] I/O ports at d000 [size=256] [virtual] Expansion ROM at fe90 [disabled] [size=128K] Capabilities: Kernel driver in use: radeon Kernel modules: radeon -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Fix warnings on drm_handle_t to pointer conversions
A drm_handle_t can be safely converted to a pointer and back even on a
64bit platform (where the size is not the same).
Signed-off-by: Luca Tettamanti
---
I looked at the kernel part of the ioctl and it seems that the handle is
always a 32bit quantity, but please double check this patch :)
xf86drm.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 220aaa1..fcaf3f5 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -959,7 +959,7 @@ int drmAddMap(int fd, drm_handle_t offset, drmSize size,
drmMapType type,
if (drmIoctl(fd, DRM_IOCTL_ADD_MAP, &map))
return -errno;
if (handle)
- *handle = (drm_handle_t)map.handle;
+ *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
@@ -967,7 +967,7 @@ int drmRmMap(int fd, drm_handle_t handle)
{
drm_map_t map;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if(drmIoctl(fd, DRM_IOCTL_RM_MAP, &map))
return -errno;
@@ -2103,7 +2103,7 @@ int drmAddContextPrivateMapping(int fd, drm_context_t
ctx_id,
drm_ctx_priv_map_t map;
map.ctx_id = ctx_id;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if (drmIoctl(fd, DRM_IOCTL_SET_SAREA_CTX, &map))
return -errno;
@@ -2120,7 +2120,7 @@ int drmGetContextPrivateMapping(int fd, drm_context_t
ctx_id,
if (drmIoctl(fd, DRM_IOCTL_GET_SAREA_CTX, &map))
return -errno;
if (handle)
- *handle = (drm_handle_t)map.handle;
+ *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
Luca
--
La mia opinione puo` essere cambiata, ma non il fatto che ho ragione.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25776] [regression] crash on loading radeon module on 2.6.33-rc1 vanilla
http://bugs.freedesktop.org/show_bug.cgi?id=25776 --- Comment #1 from Luca Tettamanti 2009-12-23 12:41:44 PST --- It happens when firmware for the interrupt controller is missing; a proper fallback should already be present in airlied's tree: http://thread.gmane.org/gmane.linux.kernel/930688/focus=930693 In the meanwhile install the missing bit (R700_rlc.bin) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Fix warnings on drm_handle_t to pointer conversions
On Wed, 2009-12-23 at 21:36 +0100, Luca Tettamanti wrote:
> A drm_handle_t can be safely converted to a pointer and back even on a
> 64bit platform (where the size is not the same).
>
> Signed-off-by: Luca Tettamanti
> ---
> I looked at the kernel part of the ioctl and it seems that the handle is
> always a 32bit quantity, but please double check this patch :)
It's size varies with architecture on non-linux. This patch shouldn't
cause issues, however I would personally really like to see drm_handle_t
used consistently and correctly. If handle were declared as
drm_handle_t it would avoid a lot of casting in libdrm and would have
allowed me to reliably use arbitrary handles for maps on both i386 and
amd64, by defining drm_handle_t to off_t. As it happens, that requires
minor touching of some of the DDX drivers though.
robert.
> xf86drm.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 220aaa1..fcaf3f5 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -959,7 +959,7 @@ int drmAddMap(int fd, drm_handle_t offset, drmSize size,
> drmMapType type,
> if (drmIoctl(fd, DRM_IOCTL_ADD_MAP, &map))
> return -errno;
> if (handle)
> - *handle = (drm_handle_t)map.handle;
> + *handle = (drm_handle_t)(unsigned long)map.handle;
> return 0;
> }
>
> @@ -967,7 +967,7 @@ int drmRmMap(int fd, drm_handle_t handle)
> {
> drm_map_t map;
>
> -map.handle = (void *)handle;
> +map.handle = (void *)(unsigned long)handle;
>
> if(drmIoctl(fd, DRM_IOCTL_RM_MAP, &map))
> return -errno;
> @@ -2103,7 +2103,7 @@ int drmAddContextPrivateMapping(int fd, drm_context_t
> ctx_id,
> drm_ctx_priv_map_t map;
>
> map.ctx_id = ctx_id;
> -map.handle = (void *)handle;
> +map.handle = (void *)(unsigned long)handle;
>
> if (drmIoctl(fd, DRM_IOCTL_SET_SAREA_CTX, &map))
> return -errno;
> @@ -2120,7 +2120,7 @@ int drmGetContextPrivateMapping(int fd, drm_context_t
> ctx_id,
> if (drmIoctl(fd, DRM_IOCTL_GET_SAREA_CTX, &map))
> return -errno;
> if (handle)
> - *handle = (drm_handle_t)map.handle;
> + *handle = (drm_handle_t)(unsigned long)map.handle;
>
> return 0;
> }
>
>
> Luca
--
Robert Noland
2Hip Networks
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Fix warnings on drm_handle_t to pointer conversions
On Wed, Dec 23, 2009 at 10:05 PM, Robert Noland wrote: > On Wed, 2009-12-23 at 21:36 +0100, Luca Tettamanti wrote: >> A drm_handle_t can be safely converted to a pointer and back even on a >> 64bit platform (where the size is not the same). >> >> Signed-off-by: Luca Tettamanti >> --- >> I looked at the kernel part of the ioctl and it seems that the handle is >> always a 32bit quantity, but please double check this patch :) > > It's size varies with architecture on non-linux. Ah, I see. The handle is a long under BSD. > This patch shouldn't cause issues, Yes, under BSD the cast is superfluous, but harmless. > however I would personally really like to see drm_handle_t > used consistently and correctly. If handle were declared as > drm_handle_t it would avoid a lot of casting in libdrm and would have > allowed me to reliably use arbitrary handles for maps on both i386 and > amd64, by defining drm_handle_t to off_t. As it happens, that requires > minor touching of some of the DDX drivers though. struct drm_map is used as an ioctl argument, so changing the type there would break the ABI. Furthermore I fear that using a type whose size changes between i386 and amd64 would result in additional fun in maintaining the 32 bit compat interface ;-) Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Fix warnings on drm_handle_t to pointer conversions
On Wed, 2009-12-23 at 22:55 +0100, Luca Tettamanti wrote: > On Wed, Dec 23, 2009 at 10:05 PM, Robert Noland wrote: > > On Wed, 2009-12-23 at 21:36 +0100, Luca Tettamanti wrote: > >> A drm_handle_t can be safely converted to a pointer and back even on a > >> 64bit platform (where the size is not the same). > >> > >> Signed-off-by: Luca Tettamanti > >> --- > >> I looked at the kernel part of the ioctl and it seems that the handle is > >> always a 32bit quantity, but please double check this patch :) > > > > It's size varies with architecture on non-linux. > > Ah, I see. The handle is a long under BSD. > > > This patch shouldn't cause issues, > > Yes, under BSD the cast is superfluous, but harmless. > > > however I would personally really like to see drm_handle_t > > used consistently and correctly. If handle were declared as > > drm_handle_t it would avoid a lot of casting in libdrm and would have > > allowed me to reliably use arbitrary handles for maps on both i386 and > > amd64, by defining drm_handle_t to off_t. As it happens, that requires > > minor touching of some of the DDX drivers though. > > struct drm_map is used as an ioctl argument, so changing the type > there would break the ABI. Furthermore I fear that using a type whose > size changes between i386 and amd64 would result in additional fun in > maintaining the 32 bit compat interface ;-) I personally vote for just making it an off_t, which is always 64 bits for us. I just had to overhaul all of our mmap stuff and since I still only have 32 bits to work with on i386, I could only steal the upper 4 bits for a globally unique map id, which limits map size to 256MB. On amd64, I stole the upper 24 bits for the map id which still allows any single map to be up to 1TB in size. robert. > Luca -- Robert Noland 2Hip Networks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm/radeon/kms: pm: single frame corruptions on reclocking
I applied patches from http://www.botchco.com/alex/xorg/pm/ and now engine reclocks between 110MHz and 680MHz. The problem is I see ~10 black horizontal lines for a one frame time on almost every reclock. I tried to fix this or at least understand it somehow but without success. 1) Putting 500ms delay after every reclock doesn't improve anything 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve 3) Calling atombios_crtc_set_pll after reclocking doesn't improve 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve I tested 4th as SetEngineClock seems to play mostly with 0x0180 and ClockSource seems to be the only reading that register. Effects were horrible, don't ever call this AtomBIOS cammand ;) Do you have any other ideas? -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/23 Rafał Miłecki : > I applied patches from http://www.botchco.com/alex/xorg/pm/ and now > engine reclocks between 110MHz and 680MHz. > > The problem is I see ~10 black horizontal lines for a one frame time > on almost every reclock. I tried to fix this or at least understand it > somehow but without success. > > 1) Putting 500ms delay after every reclock doesn't improve anything > 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve > 3) Calling atombios_crtc_set_pll after reclocking doesn't improve No need to mess with the pixel clocks. > 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve > You shouldn't need to mess with this either. > Do you have any other ideas? I suspect the reclock is missing the blanking period. Try removing the debugging output in my patch as that adds additional latency. Also, if the latency of the reclock is too long, we may want to trigger the reclock on a vline irq say 3/4 of the way down the screen to give us some additional time. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher napisał: > 2009/12/23 Rafał Miłecki : >> Do you have any other ideas? > > I suspect the reclock is missing the blanking period. Try removing > the debugging output in my patch as that adds additional latency. > Also, if the latency of the reclock is too long, we may want to > trigger the reclock on a vline irq say 3/4 of the way down the screen > to give us some additional time. I remove DRM_INFOs and also moved radeon_get_power_state calls from IRQ handler to line before rdev->pm.vblank_callback = true;. This didn't help. I guess you may be right with this VBLANK. We may receive that too late and don't hit vblank. Maybe with low engine we even parse IRQs slower? Does VLINE come "just always"? It doesn't seem we enable this interrupt anywhere. -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/23 Rafał Miłecki : > W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher > napisał: >> 2009/12/23 Rafał Miłecki : >>> Do you have any other ideas? >> >> I suspect the reclock is missing the blanking period. Try removing >> the debugging output in my patch as that adds additional latency. >> Also, if the latency of the reclock is too long, we may want to >> trigger the reclock on a vline irq say 3/4 of the way down the screen >> to give us some additional time. > > I remove DRM_INFOs and also moved radeon_get_power_state calls from > IRQ handler to line before rdev->pm.vblank_callback = true;. This > didn't help. Too bad. > > I guess you may be right with this VBLANK. We may receive that too > late and don't hit vblank. Maybe with low engine we even parse IRQs > slower? Nope. the CPU processes interrupts. The irq handler is part of the driver and runs on the host. > > Does VLINE come "just always"? It doesn't seem we enable this > interrupt anywhere. It's not enabled at the moment as nothing uses it. You can set it to fire an interrupt at a particular vline during scanout. The info needed is in the r5xx and r6xx modesetting docs and in the reg headers and code in the driver. One possible problem is that we use the vline stuff (not the interrupt, just the vline) for Xv anti-tearing stuff, so you may run into issues there. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Thu, 2009-12-24 at 03:24 +0100, Rafał Miłecki wrote: > W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher > napisał: > > 2009/12/23 Rafał Miłecki : > >> Do you have any other ideas? > > > > I suspect the reclock is missing the blanking period. Try removing > > the debugging output in my patch as that adds additional latency. > > Also, if the latency of the reclock is too long, we may want to > > trigger the reclock on a vline irq say 3/4 of the way down the screen > > to give us some additional time. > > I remove DRM_INFOs and also moved radeon_get_power_state calls from > IRQ handler to line before rdev->pm.vblank_callback = true;. This > didn't help. > > I guess you may be right with this VBLANK. We may receive that too > late and don't hit vblank. Maybe with low engine we even parse IRQs > slower? I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
