Re: r200 lockup in radeon_cp_texture/radeon_freelist_get
On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger wrote: > On 19.02.2009 12:23, Arkadi Shishlov wrote: >> Roland Scheidegger wrote: >>> I suspect you're hitting a r200 asic bug, which isn't present in rv250 >>> and other r200 family members. There are workarounds in the driver for >>> this (see r200UpdateTextureState), but to my knowledge they are >>> insufficient for two-pass ATI_fragment_shader shaders. There's also a >> >> You're right. I changed video card to RV280 9250SE and lockup goes away. >> Nice picture, a little slower than fglrx, probably due to 9250 being >> slower than 8500. > doom3 is actually a performance mystery to me. On my 9000pro, > performance seemed to be similar to fglrx, however using another OS it > was vastly faster, and I always wondered how it could be tweaked... > Hyperz doesn't seem to help much, neither does the mipmap optimization, > yet still somehow it must be possible to make it run much faster. > >> >>> mesa test which last I heard showed errors (progs/tests/afsmultiarb) >>> (you can switch the test between one and two pass shaders). >>> If this is the problem, you could try running doom3 using the arb path I >>> think something like doom3 +seta r_renderer arb might work, however arb >>> path looks ugly (r_renderer defaults to "best" which will then choose >>> "r200" on this card). >> >> Yes, its ugly and incorrect, some walls are not opaque but blends over >> another walls. > Oh, that sounds like a bug. Ugly yes but I didn't see that. > >> >>> Unfortunately I don't know how this could be fixed, as documentation for >>> these asic bugs is nonexistent (or at least non-public). >> >> If lockup could be reliable reproduced with simple test - like >> afsmultiarb in fresh X without WM - will it be helpfull to get mmio >> trace from fglrx and r200 drivers to compare? > I think at least some of the asic bugs do not necessarily result in a > lockup but also could result in misrendering. Someone might be able to > figure out what fglrx does, I guess of particular interest would be the > writes to these debug regs (0x2D90 through 0x2DBC). That said, it might > not be easy to figure this out completely (could depend on which texture > units are enabled in what pass, and depending on filtering on each of > those). Or it could even be some completely unrelated bug. > > >> >> In the light of recent progress with AMD's attitude, can't you just ask >> fglrx guys about R200 bug? > R200 is understandably not exactly top priority, and it seemed like the > usual docs didn't cover it. Though maybe Alex wants to comment on this. Unfortunately, r200 is so old, it hard to find much information on it anymore. Alex -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 lockup in radeon_cp_texture/radeon_freelist_get
On Thu, Feb 19, 2009 at 9:51 AM, Stephane Marchesin wrote: > On Thu, Feb 19, 2009 at 15:46, Alex Deucher wrote: >> On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger >> wrote: >>> On 19.02.2009 12:23, Arkadi Shishlov wrote: >>>> Roland Scheidegger wrote: >>>>> I suspect you're hitting a r200 asic bug, which isn't present in rv250 >>>>> and other r200 family members. There are workarounds in the driver for >>>>> this (see r200UpdateTextureState), but to my knowledge they are >>>>> insufficient for two-pass ATI_fragment_shader shaders. There's also a >>>> >>>> You're right. I changed video card to RV280 9250SE and lockup goes away. >>>> Nice picture, a little slower than fglrx, probably due to 9250 being >>>> slower than 8500. >>> doom3 is actually a performance mystery to me. On my 9000pro, >>> performance seemed to be similar to fglrx, however using another OS it >>> was vastly faster, and I always wondered how it could be tweaked... >>> Hyperz doesn't seem to help much, neither does the mipmap optimization, >>> yet still somehow it must be possible to make it run much faster. >>> >>>> >>>>> mesa test which last I heard showed errors (progs/tests/afsmultiarb) >>>>> (you can switch the test between one and two pass shaders). >>>>> If this is the problem, you could try running doom3 using the arb path I >>>>> think something like doom3 +seta r_renderer arb might work, however arb >>>>> path looks ugly (r_renderer defaults to "best" which will then choose >>>>> "r200" on this card). >>>> >>>> Yes, its ugly and incorrect, some walls are not opaque but blends over >>>> another walls. >>> Oh, that sounds like a bug. Ugly yes but I didn't see that. >>> >>>> >>>>> Unfortunately I don't know how this could be fixed, as documentation for >>>>> these asic bugs is nonexistent (or at least non-public). >>>> >>>> If lockup could be reliable reproduced with simple test - like >>>> afsmultiarb in fresh X without WM - will it be helpfull to get mmio >>>> trace from fglrx and r200 drivers to compare? >>> I think at least some of the asic bugs do not necessarily result in a >>> lockup but also could result in misrendering. Someone might be able to >>> figure out what fglrx does, I guess of particular interest would be the >>> writes to these debug regs (0x2D90 through 0x2DBC). That said, it might >>> not be easy to figure this out completely (could depend on which texture >>> units are enabled in what pass, and depending on filtering on each of >>> those). Or it could even be some completely unrelated bug. >>> >>> >>>> >>>> In the light of recent progress with AMD's attitude, can't you just ask >>>> fglrx guys about R200 bug? >>> R200 is understandably not exactly top priority, and it seemed like the >>> usual docs didn't cover it. Though maybe Alex wants to comment on this. >> >> Unfortunately, r200 is so old, it hard to find much information on it >> anymore. >> > > The r200 docs were released under NDA to selected people. So I don't > think the r200 docs have completely disappeared off the earh ;) well, we still have those, but those don't seem to cover whatever quirk or errata seems to be at play here. That's the stuff that's hard to dig up. Alex -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/4] add r6xx/r7xx drm support
The following 4 patches against the drm-next branch of Dave's drm-2.6 tree adds support for r6xx and r7xx chips to the radeon drm. It's currently only used for EXA and Xv in the DDX. They can also be downloaded directly from here: http://www.botchco.com/alex/xorg/r6xx_drm/ 0001-radeon-prep-for-r6xx-r7xx-support.patch 0002-radeon-add-r6xx-r7xx-microcode.patch 0003-radeon-add-initial-support-for-R6xx-R7xx-GPUs.patch 0004-radeon-add-R6xx-R7xx-pci-ids.patch Thanks, Alex -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] radeon: prep for r6xx/r7xx support
>From 9a3a1352ea4ee08c4f1c5f0eb8c9f204c342da18 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 24 Feb 2009 14:02:13 -0500
Subject: [PATCH] radeon: prep for r6xx/r7xx support
- add r6xx/r7xx regs and macros
- add r6xx/r7xx chip families
- fix register access for regs with offsets >= 0x1
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_cp.c | 14 +
drivers/gpu/drm/radeon/radeon_drv.h | 504 ++-
include/drm/radeon_drm.h|5 +-
3 files changed, 521 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 8338353..e42b6a2 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -89,6 +89,20 @@ u32 radeon_get_scratch(drm_radeon_private_t
*dev_priv, int index)
return RADEON_READ(RADEON_SCRATCH_REG0 + 4*index);
}
+u32 RADEON_READ_MM(drm_radeon_private_t *dev_priv, int addr)
+{
+ u32 ret;
+
+ if (addr < 0x1)
+ ret = DRM_READ32(dev_priv->mmio, addr);
+ else {
+ DRM_WRITE32(dev_priv->mmio, RADEON_MM_INDEX, addr);
+ ret = DRM_READ32(dev_priv->mmio, RADEON_MM_DATA);
+ }
+
+ return ret;
+}
+
static u32 R500_READ_MCIND(drm_radeon_private_t *dev_priv, int addr)
{
u32 ret;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index aa078cb..9326c73 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -134,6 +134,16 @@ enum radeon_family {
CHIP_RV560,
CHIP_RV570,
CHIP_R580,
+ CHIP_R600,
+ CHIP_RV610,
+ CHIP_RV630,
+ CHIP_RV620,
+ CHIP_RV635,
+ CHIP_RV670,
+ CHIP_RS780,
+ CHIP_RV770,
+ CHIP_RV730,
+ CHIP_RV710,
CHIP_LAST,
};
@@ -317,6 +327,26 @@ typedef struct drm_radeon_private {
int num_gb_pipes;
int track_flush;
drm_local_map_t *mmio;
+
+ /* r6xx/r7xx pipe/shader config */
+ int r600_max_pipes;
+ int r600_max_tile_pipes;
+ int r600_max_simds;
+ int r600_max_backends;
+ int r600_max_gprs;
+ int r600_max_threads;
+ int r600_max_stack_entries;
+ int r600_max_hw_contexts;
+ int r600_max_gs_threads;
+ int r600_sx_max_export_size;
+ int r600_sx_max_export_pos_size;
+ int r600_sx_max_export_smx_size;
+ int r600_sq_num_cf_insts;
+ int r700_sx_num_of_sets;
+ int r700_sc_prim_fifo_size;
+ int r700_sc_hiz_tile_fifo_size;
+ int r700_sc_earlyz_tile_fifo_fize;
+
} drm_radeon_private_t;
typedef struct drm_radeon_buf_priv {
@@ -366,6 +396,7 @@ extern int radeon_engine_reset(struct drm_device
*dev, void *data, struct drm_fi
extern int radeon_fullscreen(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int radeon_cp_buffers(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern u32 radeon_read_fb_location(drm_radeon_private_t *dev_priv);
+extern u32 RADEON_READ_MM(drm_radeon_private_t *dev_priv, int addr);
extern void radeon_freelist_reset(struct drm_device * dev);
extern struct drm_buf *radeon_freelist_get(struct drm_device * dev);
@@ -436,6 +467,8 @@ extern int r300_do_cp_cmdbuf(struct drm_device *dev,
/* Register definitions, register access macros and drmAddMap constants
* for Radeon kernel driver.
*/
+#define RADEON_MM_INDEX0x
+#define RADEON_MM_DATA 0x0004
#define RADEON_AGP_COMMAND 0x0f60
#define RADEON_AGP_COMMAND_PCI_CONFIG 0x0060 /* offset in PCI config */
@@ -645,6 +678,19 @@ extern u32
radeon_get_scratch(drm_radeon_private_t *dev_priv, int index);
#define GET_SCRATCH(dev_priv, x) radeon_get_scratch(dev_priv, x)
+#define R600_SCRATCH_REG0 0x8500
+#define R600_SCRATCH_REG1 0x8504
+#define R600_SCRATCH_REG2 0x8508
+#define R600_SCRATCH_REG3 0x850c
+#define R600_SCRATCH_REG4 0x8510
+#define R600_SCRATCH_REG5 0x8514
+#define R600_SCRATCH_REG6 0x8518
+#define R600_SCRATCH_REG7 0x851c
+#define R600_SCRATCH_UMSK 0x8540
+#define R600_SCRATCH_ADDR 0x8544
+
+#define R600_SCRATCHOFF(x) (R600_SCRATCH_REG_OFFSET + 4*(x))
+
#define RADEON_GEN_INT_CNTL0x0040
# define RADEON_CRTC_VBLANK_MASK (1 << 0)
# define RADEON_CRTC2_VBLANK_MASK (1 << 9)
@@ -924,6 +970,7 @@ extern u32 radeon_get_scratch(drm_radeon_private_t
*dev_priv, int index);
#define RADEON_CP_RB_CNTL 0x0704
# define RADEON_BUF_SWAP_32BIT(2 << 16)
# define RADEON_RB_NO_UPDATE (1 << 27)
+# define RADEON_RB_RPTR_WR_ENA(1 << 31)
#define RADEON_CP_RB_RPTR_ADDR 0x070c
#define RADEON_CP_RB_RPT
[PATCH 2/4] radeon: add r6xx/r7xx microcode
This patch is huge and just adds microcode for r6xx/r7xx chips. It can be downloaded here: http://www.botchco.com/alex/xorg/r6xx_drm/0002-radeon-add-r6xx-r7xx-microcode.patch -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] radeon: add R6xx/R7xx pci ids
>From 273bbce8cd34e27d63571e9b150f346024e1cb7c Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 24 Feb 2009 17:13:42 -0500
Subject: [PATCH] radeon: add R6xx/R7xx pci ids
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h | 108 ++
1 files changed, 108 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 5165f24..8bcacc2 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -243,6 +243,114 @@
{0x1002, 0x796d, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS740|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART}, \
{0x1002, 0x796e, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS740|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART}, \
{0x1002, 0x796f, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS740|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART}, \
+ {0x1002, 0x9400, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9401, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9402, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9403, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9405, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x940A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x940B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x940F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9440, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9441, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9442, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9444, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9446, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x944A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x944B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x944C, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x944E, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9450, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9452, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9456, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x945A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x945B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x946A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x946B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x947A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x947B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9480, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9487, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9488, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9489, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x948F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9490, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9491, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9498, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x949C, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x949E, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x949F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94C0, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV610|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94C1, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV610|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94C3, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV610|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94C4, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV610|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94C5, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV610|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94C6, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV610|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94C7, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV610|RADEON_NEW_MEMMAP}, \
+ {0x1
[PATCH] RS600: fix interrupt handling
for drm-next
http://www.botchco.com/alex/xorg/r6xx_drm/0001-RS600-fix-interrupt-handling.patch
>From c2c973f860ceaf8b8491cf541e9ed2126d6673bd Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Fri, 6 Mar 2009 11:43:47 -0500
Subject: [PATCH] RS600: fix interrupt handling
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_drv.c |4 ++--
drivers/gpu/drm/radeon/radeon_irq.c | 14 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 1e3b255..2cb4f32 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -46,7 +46,7 @@ static int radeon_suspend(struct drm_device *dev,
pm_message_t state)
drm_radeon_private_t *dev_priv = dev->dev_private;
/* Disable *all* interrupts */
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690)
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600)
RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
RADEON_WRITE(RADEON_GEN_INT_CNTL, 0);
return 0;
@@ -57,7 +57,7 @@ static int radeon_resume(struct drm_device *dev)
drm_radeon_private_t *dev_priv = dev->dev_private;
/* Restore interrupt registers */
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690)
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600)
RADEON_WRITE(R500_DxMODE_INT_MASK, dev_priv->r500_disp_irq_reg);
RADEON_WRITE(RADEON_GEN_INT_CNTL, dev_priv->irq_enable_reg);
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_irq.c
b/drivers/gpu/drm/radeon/radeon_irq.c
index 8289e16..9836c70 100644
--- a/drivers/gpu/drm/radeon/radeon_irq.c
+++ b/drivers/gpu/drm/radeon/radeon_irq.c
@@ -65,7 +65,7 @@ int radeon_enable_vblank(struct drm_device *dev, int crtc)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690) {
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600) {
switch (crtc) {
case 0:
r500_vbl_irq_set_state(dev, R500_D1MODE_INT_MASK, 1);
@@ -100,7 +100,7 @@ void radeon_disable_vblank(struct drm_device *dev, int crtc)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690) {
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600) {
switch (crtc) {
case 0:
r500_vbl_irq_set_state(dev, R500_D1MODE_INT_MASK, 0);
@@ -135,7 +135,7 @@ static inline u32
radeon_acknowledge_irqs(drm_radeon_private_t *dev_priv, u32 *r
u32 irq_mask = RADEON_SW_INT_TEST;
*r500_disp_int = 0;
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690) {
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600) {
/* vbl interrupts in a different place */
if (irqs & R500_DISPLAY_INT_STATUS) {
@@ -202,7 +202,7 @@ irqreturn_t radeon_driver_irq_handler(DRM_IRQ_ARGS)
DRM_WAKEUP(&dev_priv->swi_queue);
/* VBLANK interrupt */
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690) {
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600) {
if (r500_disp_int & R500_D1_VBLANK_INTERRUPT)
drm_handle_vblank(dev, 0);
if (r500_disp_int & R500_D2_VBLANK_INTERRUPT)
@@ -265,7 +265,7 @@ u32 radeon_get_vblank_counter(struct drm_device
*dev, int crtc)
return -EINVAL;
}
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690) {
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600) {
if (crtc == 0)
return RADEON_READ(R500_D1CRTC_FRAME_COUNT);
else
@@ -327,7 +327,7 @@ void radeon_driver_irq_preinstall(struct drm_device * dev)
u32 dummy;
/* Disable *all* interrupts */
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690)
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600)
RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
RADEON_WRITE(RADEON_GEN_INT_CNTL, 0);
@@ -357,7 +357,7 @@ void radeon_driver_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
- if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690)
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600)
RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
/* Disable *all* interrupts */
RADEON_WRITE(RADEON_GEN_INT_CNTL, 0);
--
1.5.6.3
--
Open Source Business Conference (OSBC), Mar
[PATCH] R6xx/R7xx: fix possible oops in r600_page_table_cleanup()
Please apply to both drm-next and drm-rawhide
http://www.botchco.com/alex/xorg/r6xx_drm/0001-R6xx-R7xx-fix-possible-oops-in-r600_page_table_clea.patch
>From 453ed78a62d3125ecdb2a1e5ea27b3368fa66330 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Sat, 7 Mar 2009 18:16:42 -0500
Subject: [PATCH] R6xx/R7xx: fix possible oops in r600_page_table_cleanup()
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index dc19dbe..ca4eb2f 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -121,6 +121,9 @@ void r600_page_table_cleanup(struct drm_device
*dev, struct drm_ati_pcigart_info
int pages;
int i;
+ if (!entry)
+ return;
+
if (gart_info->bus_addr) {
max_pages = (gart_info->table_size / sizeof(u32));
pages = (entry->pages <= max_pages)
--
1.5.6.3
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] radeon: call the correct idle function, logic got inverted.
On Mon, Mar 9, 2009 at 12:34 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This calls the correct idle function for the R600 and previous chips.
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_cp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
> b/drivers/gpu/drm/radeon/radeon_cp.c
> index 15cfe56..f5b7e47 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -1702,7 +1702,7 @@ void radeon_do_release(struct drm_device * dev)
> if (dev_priv) {
> if (dev_priv->cp_running) {
> /* Stop the cp */
> - if ((dev_priv->flags & RADEON_FAMILY_MASK) <
> CHIP_R600) {
> + if ((dev_priv->flags & RADEON_FAMILY_MASK) >=
> CHIP_R600) {
> while ((ret = r600_do_cp_idle(dev_priv)) != 0)
> {
> DRM_DEBUG("radeon_do_cp_idle %d\n",
> ret);
> #ifdef __linux__
> --
> 1.6.0.6
>
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix r600 pci mapping calls.
On Mon, Mar 9, 2009 at 12:34 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This realigns the r600 pci mapping calls with the ati pcigart ones,
> fixing the direction and using the correct interface.
>
> Suggested by Jerome Glisse.
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cp.c
> b/drivers/gpu/drm/radeon/r600_cp.c
> index f915f11..be2bba6 100644
> --- a/drivers/gpu/drm/radeon/r600_cp.c
> +++ b/drivers/gpu/drm/radeon/r600_cp.c
> @@ -132,8 +132,8 @@ void r600_page_table_cleanup(struct drm_device *dev,
> struct drm_ati_pcigart_info
> for (i = 0; i < pages; i++) {
> if (!entry->busaddr[i])
> break;
> - pci_unmap_single(dev->pdev, entry->busaddr[i],
> - PAGE_SIZE, PCI_DMA_TODEVICE);
> + pci_unmap_page(dev->pdev, entry->busaddr[i],
> + PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
> }
> if (gart_info->gart_table_location == DRM_ATI_GART_MAIN)
> gart_info->bus_addr = 0;
> @@ -165,10 +165,10 @@ int r600_page_table_init(struct drm_device *dev)
>
> gart_idx = 0;
> for (i = 0; i < pages; i++) {
> - entry->busaddr[i] = pci_map_single(dev->pdev,
> - page_address(entry->
> - pagelist[i]),
> - PAGE_SIZE,
> PCI_DMA_TODEVICE);
> + entry->busaddr[i] = pci_map_page(dev->pdev,
> + entry->pagelist[i], 0,
> + PAGE_SIZE,
> + PCI_DMA_BIDIRECTIONAL);
> if (entry->busaddr[i] == 0) {
> DRM_ERROR("unable to map PCIGART pages!\n");
> r600_page_table_cleanup(dev, gart_info);
> --
> 1.6.0.6
>
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix r600 writeback setup.
On Mon, Mar 9, 2009 at 12:34 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes 2 bugs:
> 1. the AGP calculation wasn't consistent with the PCI(E) calc for the
> RPTR_ADDR registers. This consolidates the writes and fixes it up.
>
> 2. The scratch address was being incorrectly calculated, this breaks
> it out into a lot more linear steps.
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 35 ++-
> 1 files changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cp.c
> b/drivers/gpu/drm/radeon/r600_cp.c
> index 6f2cc74..04fde35 100644
> --- a/drivers/gpu/drm/radeon/r600_cp.c
> +++ b/drivers/gpu/drm/radeon/r600_cp.c
> @@ -1630,6 +1630,7 @@ static void r600_cp_init_ring_buffer(struct drm_device
> *dev,
> {
> struct drm_radeon_master_private *master_priv;
> u32 ring_start;
> + u64 rptr_addr;
>
> if (((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RV770))
> r700_gfx_init(dev, dev_priv);
> @@ -1684,21 +1685,20 @@ static void r600_cp_init_ring_buffer(struct
> drm_device *dev,
>
> #if __OS_HAS_AGP
> if (dev_priv->flags & RADEON_IS_AGP) {
> - /* XXX */
> - RADEON_WRITE(R600_CP_RB_RPTR_ADDR,
> - (dev_priv->ring_rptr->offset
> - - dev->agp->base + dev_priv->gart_vm_start) >>
> 8);
> - RADEON_WRITE(R600_CP_RB_RPTR_ADDR_HI, 0);
> + rptr_addr = dev_priv->ring_rptr->offset
> + - dev->agp->base +
> + dev_priv->gart_vm_start;
> } else
> #endif
> {
> - RADEON_WRITE(R600_CP_RB_RPTR_ADDR,
> - dev_priv->ring_rptr->offset
> - - ((unsigned long) dev->sg->virtual)
> - + dev_priv->gart_vm_start);
> -
> - RADEON_WRITE(R600_CP_RB_RPTR_ADDR_HI, 0);
> + rptr_addr = dev_priv->ring_rptr->offset
> + - ((unsigned long) dev->sg->virtual)
> + + dev_priv->gart_vm_start;
> }
> + RADEON_WRITE(R600_CP_RB_RPTR_ADDR,
> + rptr_addr & 0x);
> + RADEON_WRITE(R600_CP_RB_RPTR_ADDR_HI,
> + upper_32_bits(rptr_addr));
>
> #ifdef __BIG_ENDIAN
> RADEON_WRITE(R600_CP_RB_CNTL,
> @@ -1747,8 +1747,17 @@ static void r600_cp_init_ring_buffer(struct drm_device
> *dev,
> * We simply put this behind the ring read pointer, this works
> * with PCI GART as well as (whatever kind of) AGP GART
> */
> - RADEON_WRITE(R600_SCRATCH_ADDR, ((RADEON_READ(R600_CP_RB_RPTR_ADDR)
> << 8)
> - + R600_SCRATCH_REG_OFFSET) >> 8);
> + {
> + u64 scratch_addr;
> +
> + scratch_addr = RADEON_READ(R600_CP_RB_RPTR_ADDR);
> + scratch_addr |= ((u64)RADEON_READ(R600_CP_RB_RPTR_ADDR_HI))
> << 32;
> + scratch_addr += R600_SCRATCH_REG_OFFSET;
> + scratch_addr >>= 8;
> + scratch_addr &= 0x;
> +
> + RADEON_WRITE(R600_SCRATCH_ADDR, (uint32_t)scratch_addr);
> + }
>
> RADEON_WRITE(R600_SCRATCH_UMSK, 0x7);
>
> --
> 1.6.0.6
>
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon: don't call irq changes on r600 suspend/resume
On Tue, Mar 10, 2009 at 3:41 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Until we sort out r600 IRQs don't do this.
>
> Signed-off-by: Dave Airlie
Should be ok since GEN_INT_CNTL is unassigned register space on
r6xx/r7xx, but better safe than sorry.
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_drv.c | 6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 2cb4f32..13a60f4 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -45,6 +45,9 @@ static int radeon_suspend(struct drm_device *dev,
> pm_message_t state)
> {
> drm_radeon_private_t *dev_priv = dev->dev_private;
>
> + if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R600)
> + return 0;
> +
> /* Disable *all* interrupts */
> if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600)
> RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
> @@ -56,6 +59,9 @@ static int radeon_resume(struct drm_device *dev)
> {
> drm_radeon_private_t *dev_priv = dev->dev_private;
>
> + if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R600)
> + return 0;
> +
> /* Restore interrupt registers */
> if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS600)
> RADEON_WRITE(R500_DxMODE_INT_MASK,
> dev_priv->r500_disp_irq_reg);
> --
> 1.6.2
>
>
> --
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: fix r600 writeback across suspend/resume
On Tue, Mar 10, 2009 at 3:41 AM, Dave Airlie wrote: > From: Dave Airlie > > This update was done in mainline radeon, but not in the r600. > > Signed-off-by: Dave Airlie Acked-by: Alex Deucher > --- > drivers/gpu/drm/radeon/r600_cp.c | 3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/r600_cp.c > b/drivers/gpu/drm/radeon/r600_cp.c > index 04fde35..490f353 100644 > --- a/drivers/gpu/drm/radeon/r600_cp.c > +++ b/drivers/gpu/drm/radeon/r600_cp.c > @@ -1737,9 +1737,6 @@ static void r600_cp_init_ring_buffer(struct drm_device > *dev, > > RADEON_WRITE(R600_CP_DEBUG, (1 << 27) | (1 << 28)); > > - /* Start with assuming that writeback doesn't work */ > - dev_priv->writeback_works = 0; > - > /* Initialize the scratch register pointer. This will cause > * the scratch register values to be written out to memory > * whenever they are updated. > -- > 1.6.2 > > > -- > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: r600 ptes are 64-bit, cleanup cleanup function.
On Fri, Mar 13, 2009 at 12:14 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cp.c
> b/drivers/gpu/drm/radeon/r600_cp.c
> index 490f353..76eb0d5 100644
> --- a/drivers/gpu/drm/radeon/r600_cp.c
> +++ b/drivers/gpu/drm/radeon/r600_cp.c
> @@ -125,7 +125,7 @@ void r600_page_table_cleanup(struct drm_device *dev,
> struct drm_ati_pcigart_info
> return;
>
> if (gart_info->bus_addr) {
> - max_pages = (gart_info->table_size / sizeof(u32));
> + max_pages = (gart_info->table_size / sizeof(u64));
> pages = (entry->pages <= max_pages)
> ? entry->pages : max_pages;
>
> --
> 1.6.0.6
>
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon: fix logic in r600_page_table_init() to match ati_gart
[PATCH] radeon: fix logic in r600_page_table_init() to match ati_gart
This fixes page table init on rs600.
Signed-off-by: Alex Deucher
please apply to both drm-next and drm-rawhide
http://www.botchco.com/alex/xorg/drm-rawhide/0001-radeon-fix-logic-in-r600_page_table_init-to-match.patch
>From d1a93f61cabcce5ed6d864c630a4592e14af944d Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 16 Mar 2009 15:31:56 -0400
Subject: [PATCH] radeon: fix logic in r600_page_table_init() to match ati_gart
This fixes page table init on rs600.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index ca4eb2f..dee3840 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -172,7 +172,6 @@ int r600_page_table_init(struct drm_device *dev)
if (entry->busaddr[i] == 0) {
DRM_ERROR("unable to map PCIGART pages!\n");
r600_page_table_cleanup(dev, gart_info);
- ret = -EINVAL;
goto done;
}
entry_addr = entry->busaddr[i];
@@ -191,6 +190,7 @@ int r600_page_table_init(struct drm_device *dev)
entry_addr += ATI_PCIGART_PAGE_SIZE;
}
}
+ ret = 1;
done:
return ret;
}
@@ -2089,7 +2089,7 @@ int r600_do_init_cp(struct drm_device *dev,
drm_radeon_init_t *init,
dev_priv->gart_info.addr,
dev_priv->pcigart_offset);
- if (r600_page_table_init(dev)) {
+ if (!r600_page_table_init(dev)) {
DRM_ERROR("Failed to init GART table\n");
r600_do_cleanup_cp(dev);
return -EINVAL;
--
1.5.6.3
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] AVIVO: fix dac load detection
http://www.botchco.com/alex/xorg/drm-rawhide/0001-AVIVO-fix-dac-load-detection.patch >From 543cdebab5266bc45cbda6b431d26fe4ebf89984 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Wed, 18 Mar 2009 12:03:16 -0400 Subject: [PATCH] AVIVO: fix dac load detection Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_encoders.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c index a191644..3c1e1b8 100644 --- a/drivers/gpu/drm/radeon/radeon_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_encoders.c @@ -1557,7 +1557,8 @@ atombios_dac_load_detect(struct drm_encoder *encoder) args.sDacload.ucMisc = 0; - if (radeon_encoder->encoder_id == ENCODER_OBJECT_ID_INTERNAL_DAC1) + if ((radeon_encoder->encoder_id == ENCODER_OBJECT_ID_INTERNAL_DAC1) || + (radeon_encoder->encoder_id == ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1)) args.sDacload.ucDacType = ATOM_DAC_A; else args.sDacload.ucDacType = ATOM_DAC_B; -- 1.5.6.3 -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon: add some new pci ids
http://www.botchco.com/alex/xorg/0001-radeon-add-some-new-pci-ids.patch
for drm-next
>From 4e91d985755227efcdd6f3ddab90286c3a8ed492 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 19 Mar 2009 20:38:04 -0400
Subject: [PATCH] radeon: add some new pci ids
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index c2fd3c5..ecb9761 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -354,6 +354,8 @@
{0x1002, 0x9612, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9613, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9614, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9615, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9616, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0, 0, 0}
#define r128_PCI_IDS \
--
1.5.6.3
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] RS780: load the right microcode
http://www.botchco.com/alex/xorg/r6xx_drm/0001-RS780-load-the-right-microcode.patch
>From 4299cc7ee205006851a7a791602efa8512613f16 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Sun, 29 Mar 2009 20:40:34 -0400
Subject: [PATCH] RS780: load the right microcode
Copy/paste error. The RV670 microcode should work ok, so it's
not a show stopper.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cp.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index dee3840..d4e66da 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -388,17 +388,17 @@ static void
r600_cp_load_microcode(drm_radeon_private_t *dev_priv)
DRM_INFO("Loading RS780 CP Microcode\n");
for (i = 0; i < PM4_UCODE_SIZE; i++) {
RADEON_WRITE(R600_CP_ME_RAM_DATA,
-RV670_cp_microcode[i][0]);
+RS780_cp_microcode[i][0]);
RADEON_WRITE(R600_CP_ME_RAM_DATA,
-RV670_cp_microcode[i][1]);
+RS780_cp_microcode[i][1]);
RADEON_WRITE(R600_CP_ME_RAM_DATA,
-RV670_cp_microcode[i][2]);
+RS780_cp_microcode[i][2]);
}
RADEON_WRITE(R600_CP_PFP_UCODE_ADDR, 0);
DRM_INFO("Loading RS780 PFP Microcode\n");
for (i = 0; i < PFP_UCODE_SIZE; i++)
- RADEON_WRITE(R600_CP_PFP_UCODE_DATA,
RV670_pfp_microcode[i]);
+ RADEON_WRITE(R600_CP_PFP_UCODE_DATA,
RS780_pfp_microcode[i]);
}
RADEON_WRITE(R600_CP_PFP_UCODE_ADDR, 0);
RADEON_WRITE(R600_CP_ME_RAM_WADDR, 0);
--
1.5.6.3
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: macro/micro tiling scanout buffers on radeon
On 3/30/09, Roland Scheidegger wrote: > On 30.03.2009 06:23, Dave Airlie wrote: > > On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie wrote: > >> Does anyone remember why we've only done macro tiling on the radeon > >> for the color buffer so far? > >> > > > > /me discovers the reason ouch. > > > > So the 2D engine can't deal with a microtiled surface as a source, > > > > so short of using the 3D engine to do blits etc, microtiling isn't > > probably going to be useful for color buffers. > > True. I remember though, I experimented with this for 3D, ignoring any > 2D corruption (not to mention it didn't work for 3D neither cause > r100/r200 can't scan out from microtiled buffers), and using microtiling > for color buffers did not have any performance benefits quite the > contrary it was definitely slower. It's possible though this has changed > with r300 (though of course with things like render-to-texture it could > potentially end up faster on those old chips as well in some situations). > I think micro-tiling was mostly added for texture sampling, although there may be some gains to be had on newer chips for other things depending on what you are using the surface for. Alex > Roland > > > > > > > For texture tiling I'm going to have to with keeping two copies as > > with this limitation we can't copy back from VRAM a micro-tiled > > texture with the blitter. Again we'd have to use the 3D engine to do > > it. > > You could untile manually though I agree that sucks. Using the 3D engine > instead of blitter though probably wouldn't be unreasonable, I guess > this kind of operation is limited by bandwidth anyway so performance > should be the same. > > > Roland > > > > -- > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 3/3_v2]: [DRM/I915] : Sync the default modes for LVDS output device
On 4/1/09, Eric Anholt wrote: > On Mon, 2009-03-23 at 11:30 +0800, yakui_zhao wrote: > > Subject: [DRM/I915]: Sync the default modes for LVDS output device > > From: Zhao Yakui > > > > Sync the default modes for the LVDS output device > > This covers: > > Add the default modes for the LVDS output device. > > The bit of edid->feature.msc indicates whether the display device is > not > > continous-frequency. And it is used to determine whether the default modes > will > > be added to the output device. > > But for the LVDS output device the edid->feature.msc will always be > set.Even > > when there is no edid, the correponding bit in the fake edid will be set. > > In such case the default modes will be added to LVDS output device. > > If not, the different modes are obtained by using KMS/UMS. > > > > Signed-off-by: Zhao Yakui > > These giant tables of modes are insane. Especially having a bunch of > different refresh rates when the LVDS actually has a fixed refresh rate. > Just generate a mode at each appropriate size using GTF or CVT. > > I'm not really sold on the whole idea of the kernel generating these > fake modes for LVDS, given that we can support any size and that the > refresh rate is a lie since we're always using the fixed mode. Any > other opinions on this? > Maybe a common drm mode function helper that will add a bunch of common (4:3 and 16:9) modes that fixed mode encoders like LVDS can call. We certainly don't need to add modes with differing refresh rates. Alex > > -- > Eric Anholt > e...@anholt.net eric.anh...@intel.com > > > > -- > > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon: Add RV790 (HD 4890) support
http://www.botchco.com/alex/xorg/0001-radeon-Add-RV790-HD-4890-support.patch
>From 668d2937797e8788efbd1225493c65f3e22b5774 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 9 Apr 2009 12:09:40 -0400
Subject: [PATCH] radeon: Add RV790 (HD 4890) support
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cp.c |4 ++--
include/drm/drm_pciids.h |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index c3f12e6..b38d23b 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -478,13 +478,13 @@ static void
r700_cp_load_microcode(drm_radeon_private_t *dev_priv)
if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV770)) {
RADEON_WRITE(R600_CP_PFP_UCODE_ADDR, 0);
- DRM_INFO("Loading RV770 PFP Microcode\n");
+ DRM_INFO("Loading RV770/RV790 PFP Microcode\n");
for (i = 0; i < R700_PFP_UCODE_SIZE; i++)
RADEON_WRITE(R600_CP_PFP_UCODE_DATA,
RV770_pfp_microcode[i]);
RADEON_WRITE(R600_CP_PFP_UCODE_ADDR, 0);
RADEON_WRITE(R600_CP_ME_RAM_WADDR, 0);
- DRM_INFO("Loading RV770 CP Microcode\n");
+ DRM_INFO("Loading RV770/RV790 CP Microcode\n");
for (i = 0; i < R700_PM4_UCODE_SIZE; i++)
RADEON_WRITE(R600_CP_ME_RAM_DATA,
RV770_cp_microcode[i]);
RADEON_WRITE(R600_CP_ME_RAM_WADDR, 0);
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index c2fd3c5..1c4d333 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -268,6 +268,8 @@
{0x1002, 0x9456, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x945A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x945B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9460, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9462, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x946A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x946B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x947A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
--
1.5.6.3
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Fwd: Initial R6xx/R7xx Mesa 3D driver
Meant to sent this to dri-devel as well. Note, this is not a release per se. the driver is still incomplete. we are just moving development out into the public. Alex -- Forwarded message -- From: Alex Deucher Date: Fri, Apr 17, 2009 at 2:49 PM Subject: Initial R6xx/R7xx Mesa 3D driver To: "radeo...@opensuse.org" , xorg-driver-ati , "mesa3d-...@lists.sourceforge.net" This is a quick email to announce the release of the initial 3D driver for R6xx/R7xx hardware. It's available on the r6xx-r7xx-support branch of mesa: http://cgit.freedesktop.org/mesa/mesa/?h=r6xx-r7xx-support To test this branch, you will need updated drm kernel modules and radeon drm headers from the r6xx-r7xx-3d branch of my drm tree: http://cgit.freedesktop.org/~agd5f/drm/?h=r6xx-r7xx-3d This will be moving to the main drm tree soon. We will be syncing this code up with the work going on in the radeon-rewrite branch of mesa over the next few weeks. For now you can get it on the r6xx-rewrite branch of my mesa, tree: http://cgit.freedesktop.org/~agd5f/mesa/?h=r6xx-rewrite This will shortly be moving to the main mesa tree soon as well. Many thanks to Richard Li and Cooper Yuan as they have done most of the work on this so far. Alex -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: KMS with VESA ?
On Wed, Apr 29, 2009 at 10:32 AM, Abraham Varricatt wrote: > As of now, I know it's non-existent. But I want to know the > difficulties involved in attempting it (KMS+VESA)? At the moment, the > only chipsets that work with KMS are the intel ones. So, I'm thinking, > why not find out why no-one seems to be interested in doing a VESA > driver? > > Perhaps I'm naive, but if we have such a driver around, it "should" > make it possible for anyone to use KMS on their Linux systems, > correct? A very limited sub-set of features, true, but it will be > better than nothing. It already exists in the form of the various kernel vesa framebuffer drivers. You can't do acceleration with vesa so there's little need for anything more than framebuffer support. Alex -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 13364] New: BUG: unable to handle kernel paging request at 429a4c40
On Tue, May 26, 2009 at 6:39 PM, Andrew Morton wrote: > On Fri, 22 May 2009 17:59:49 GMT > bugzilla-dae...@bugzilla.kernel.org wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=13364 > > The wheels seem to have fallen off the DRM code lately :( > > This one might be related to Alex's r6xx/r7xx changes, dunno. > r6xx/r7xx patches were added during the 2.6.30 merge window, so they aren't in 2.6.29. I've requested some more info in the bug report. Alex -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: get lvds info for ..._KLDSCP_LVTMA encoder
2009/6/24 Rafał Miłecki : > Khem, hi, my first patch here and my first touching kernel code ever. > > I try to make my RV620 work in console using radeon KMS. Using > Jerome's WIP code and my own hacks I discovered this quite general bug > in treating encoders. > > Before patch: > Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-1: unable to read EDID > block. > Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: VGA-1: no EDID data > Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID > block. > Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data > Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-3: unable to read EDID > block. > Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: HDMI Type B-1: > no EDID data > Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID > block. > Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data > Jun 23 15:15:49 linux-aodr kernel: [drm:drm_helper_initial_config] > *ERROR* connectors have no modes, using standard modes > Jun 23 15:15:49 linux-aodr kernel: > [drm_mode:drm_mode_debug_printmodeline], Modeline 11:"800x600" 60315 > 4 800 840 968 1056 600 601 605 628 0x10 0x5 > Jun 23 15:15:49 linux-aodr kernel: > [drm_mode:drm_mode_debug_printmodeline], Modeline 12:"800x600" 60315 > 4 800 840 968 1056 600 601 605 628 0x10 0x5 > Jun 23 15:15:49 linux-aodr kernel: > [drm_mode:drm_mode_debug_printmodeline], Modeline 13:"800x600" 60315 > 4 800 840 968 1056 600 601 605 628 0x10 0x5 > Jun 23 15:15:49 linux-aodr kernel: [drm] fb mappable at 0xC9001180 > Jun 23 15:15:49 linux-aodr kernel: [drm] vram apper at 0xC000 > Jun 23 15:15:49 linux-aodr kernel: [drm] size 1996800 > Jun 23 15:15:49 linux-aodr kernel: [drm] fb depth is 24 > Jun 23 15:15:49 linux-aodr kernel: [drm] pitch is 3328 > Jun 23 15:15:49 linux-aodr kernel: Console: switching to colour frame > buffer device 100x37 > > Witch patch applied: > Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-1: unable to read EDID > block. > Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: VGA-1: no EDID data > Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID > block. > Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data > Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-3: unable to read EDID > block. > Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: HDMI Type B-1: > no EDID data > Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID > block. > Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data > Jun 23 15:25:20 linux-aodr kernel: > [drm_mode:drm_mode_debug_printmodeline], Modeline 11:"1600x900" 59954 > 88540 1600 1614 1626 1630 900 902 904 906 0x48 0x0 > Jun 23 15:25:20 linux-aodr kernel: [drm] fb mappable at 0xC90011E0 > Jun 23 15:25:20 linux-aodr kernel: [drm] vram apper at 0xC000 > Jun 23 15:25:20 linux-aodr kernel: [drm] size 576 > Jun 23 15:25:20 linux-aodr kernel: [drm] fb depth is 24 > Jun 23 15:25:20 linux-aodr kernel: [drm] pitch is 6400 > Jun 23 15:25:20 linux-aodr kernel: Console: switching to colour frame > buffer device 200x56 > Jun 23 15:25:20 linux-aodr kernel: > [drm_mode:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 > 0 0 0x0 0x0 > Jun 23 15:25:20 linux-aodr kernel: > [drm_mode:drm_mode_debug_printmodeline], Modeline 13:"1600x900" 59954 > 88540 1600 1614 1626 1630 900 902 904 906 0x48 0x0 > Jun 23 15:25:20 linux-aodr kernel: > [drm_mode:drm_mode_debug_printmodeline], Modeline 13:"1600x900" 59954 > 88540 1600 1614 1626 1630 900 902 904 906 0x48 0x0 > > So this just makes radeon drm call radeon_atombios_get_lvds_info to > get mode for PANEL. > > I'm not sure how would you like to apply this and if this actually is > important for 2.6.31. As we support up to R5xx only here, can we hit > this bug actually? Can hardware below R6xx use > ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA? Only DCE 3.0/3.1 cards have ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA, so you'll only see this on rv620/rv635/rv780/rv770 hw. The proper fix is attached. We'll need to get lvds info for other encoder types as well since newer cards only have uniphy blocks. http://www.botchco.com/alex/xorg/0001-r6xx-r7xx-get-lvds-info-for-the-encoders-for-laptop.patch Alex From 604b24fe44c6212bb6af5cbd443ceaa0f84c7804 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Sun, 28 Jun 2009 20:58:50 -0400 Subject: [PATCH] r6xx/r7xx: get lvds info for the encoders for laptop panels MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit
Re: [PATCH] drm/radeon: get lvds info for ..._KLDSCP_LVTMA encoder
2009/6/30 Rafał Miłecki : > W dniu 29 czerwca 2009 03:03 użytkownik Alex Deucher > napisał: >> 2009/6/24 Rafał Miłecki : >>> Khem, hi, my first patch here and my first touching kernel code ever. >>> >>> I try to make my RV620 work in console using radeon KMS. Using >>> Jerome's WIP code and my own hacks I discovered this quite general bug >>> in treating encoders. >>> >>> Before patch: >>> Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-1: unable to read EDID >>> block. >>> Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: VGA-1: no EDID data >>> Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID >>> block. >>> Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data >>> Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-3: unable to read EDID >>> block. >>> Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: HDMI Type B-1: >>> no EDID data >>> Jun 23 15:15:49 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID >>> block. >>> Jun 23 15:15:49 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data >>> Jun 23 15:15:49 linux-aodr kernel: [drm:drm_helper_initial_config] >>> *ERROR* connectors have no modes, using standard modes >>> Jun 23 15:15:49 linux-aodr kernel: >>> [drm_mode:drm_mode_debug_printmodeline], Modeline 11:"800x600" 60315 >>> 4 800 840 968 1056 600 601 605 628 0x10 0x5 >>> Jun 23 15:15:49 linux-aodr kernel: >>> [drm_mode:drm_mode_debug_printmodeline], Modeline 12:"800x600" 60315 >>> 4 800 840 968 1056 600 601 605 628 0x10 0x5 >>> Jun 23 15:15:49 linux-aodr kernel: >>> [drm_mode:drm_mode_debug_printmodeline], Modeline 13:"800x600" 60315 >>> 4 800 840 968 1056 600 601 605 628 0x10 0x5 >>> Jun 23 15:15:49 linux-aodr kernel: [drm] fb mappable at 0xC9001180 >>> Jun 23 15:15:49 linux-aodr kernel: [drm] vram apper at 0xC000 >>> Jun 23 15:15:49 linux-aodr kernel: [drm] size 1996800 >>> Jun 23 15:15:49 linux-aodr kernel: [drm] fb depth is 24 >>> Jun 23 15:15:49 linux-aodr kernel: [drm] pitch is 3328 >>> Jun 23 15:15:49 linux-aodr kernel: Console: switching to colour frame >>> buffer device 100x37 >>> >>> Witch patch applied: >>> Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-1: unable to read EDID >>> block. >>> Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: VGA-1: no EDID data >>> Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID >>> block. >>> Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data >>> Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-3: unable to read EDID >>> block. >>> Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: HDMI Type B-1: >>> no EDID data >>> Jun 23 15:25:20 linux-aodr kernel: i2c-adapter i2c-2: unable to read EDID >>> block. >>> Jun 23 15:25:20 linux-aodr kernel: radeon :01:00.0: LVDS-1: no EDID data >>> Jun 23 15:25:20 linux-aodr kernel: >>> [drm_mode:drm_mode_debug_printmodeline], Modeline 11:"1600x900" 59954 >>> 88540 1600 1614 1626 1630 900 902 904 906 0x48 0x0 >>> Jun 23 15:25:20 linux-aodr kernel: [drm] fb mappable at 0xC90011E0 >>> Jun 23 15:25:20 linux-aodr kernel: [drm] vram apper at 0xC000 >>> Jun 23 15:25:20 linux-aodr kernel: [drm] size 576 >>> Jun 23 15:25:20 linux-aodr kernel: [drm] fb depth is 24 >>> Jun 23 15:25:20 linux-aodr kernel: [drm] pitch is 6400 >>> Jun 23 15:25:20 linux-aodr kernel: Console: switching to colour frame >>> buffer device 200x56 >>> Jun 23 15:25:20 linux-aodr kernel: >>> [drm_mode:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 >>> 0 0 0x0 0x0 >>> Jun 23 15:25:20 linux-aodr kernel: >>> [drm_mode:drm_mode_debug_printmodeline], Modeline 13:"1600x900" 59954 >>> 88540 1600 1614 1626 1630 900 902 904 906 0x48 0x0 >>> Jun 23 15:25:20 linux-aodr kernel: >>> [drm_mode:drm_mode_debug_printmodeline], Modeline 13:"1600x900" 59954 >>> 88540 1600 1614 1626 1630 900 902 904 906 0x48 0x0 >>> >>> So this just makes radeon drm call radeon_atombios_get_lvds_info to >>> get mode for PANEL. >>> >>> I'm not sure how would you like to apply this and if this actually is >>> important for 2.6.31. As we support up to R5xx only here, can we hit >>> this bug actually? Ca
Re: [PATCH] drm: clarify scaling property names
On Tue, Jun 30, 2009 at 5:33 PM, Jesse Barnes wrote:
> Now that we're using the scaling property in the Intel driver I noticed
> that the names were a bit confusing. I've corrected them according to
> our discussion on IRC, though I've left out potential new additions for
> a new scaling property with an integer (or two) for the scaling
> factor. None of the drivers implement that today, but if someone wants
> to do it, I think it could be done with the addition of a single new
> type and a new property to describe the scaling factor in the X and Y
> directions.
>
> Signed-off-by: Jesse Barnes
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 8fab789..21d518f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -68,10 +68,10 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> */
> static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> {
> - { DRM_MODE_SCALE_NON_GPU, "Non-GPU" },
> - { DRM_MODE_SCALE_FULLSCREEN, "Fullscreen" },
> - { DRM_MODE_SCALE_NO_SCALE, "No scale" },
> - { DRM_MODE_SCALE_ASPECT, "Aspect" },
> + { DRM_MODE_SCALE_NON_GPU, "Software" },
> + { DRM_MODE_SCALE_FULLSCREEN, "Full" },
> + { DRM_MODE_SCALE_NO_SCALE, "None" },
How about changing "None" to "Center" or adding "Center" as an
alternate method as center tends to be what people look for as
alternative to scaled modes.
Alex
> + { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
>
> --
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: clarify scaling property names
On Wed, Jul 1, 2009 at 5:23 AM, Maarten Maathuis wrote: > DRM_MODE_SCALE_NON_GPU was intended to let the monitor do the scaling, > in case you have a CRT or the monitors scalers are better. > I think your new name choice is less than ideal. Good point. I think we should have: None (sw or monitor scaling) Center (1 to 1 pixels) Full (scale to native res) Aspect (scale to native res, keep aspect) Alex -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: clarify scaling property names
On Wed, Jul 1, 2009 at 12:11 PM, Jesse Barnes wrote: > On Wed, 1 Jul 2009 11:23:50 +0200 > Maarten Maathuis wrote: > >> DRM_MODE_SCALE_NON_GPU was intended to let the monitor do the scaling, >> in case you have a CRT or the monitors scalers are better. >> I think your new name choice is less than ideal. > > If that's what it's supposed to be, then yes, it's not ideal. There > was some debate on the IRC channel about what it meant... > > If it's a monitor thing, how is it different from "none" or "center"? > Is there some way of telling the monitor to scale or not? "none" and "center" would send different mode timing to the monitor. In the driver, you either send the actual mode timing to the monitor (scale == none) or you send native mode timing (scale == center || scale == full || scale == aspect). For example with DVI monitors some users prefer to use the GPU's scaler over the monitor's and vice versa. Alex -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: clarify scaling property names
On Wed, Jul 1, 2009 at 12:19 PM, Alex Deucher wrote: > On Wed, Jul 1, 2009 at 12:11 PM, Jesse Barnes wrote: >> On Wed, 1 Jul 2009 11:23:50 +0200 >> Maarten Maathuis wrote: >> >>> DRM_MODE_SCALE_NON_GPU was intended to let the monitor do the scaling, >>> in case you have a CRT or the monitors scalers are better. >>> I think your new name choice is less than ideal. >> >> If that's what it's supposed to be, then yes, it's not ideal. There >> was some debate on the IRC channel about what it meant... >> >> If it's a monitor thing, how is it different from "none" or "center"? >> Is there some way of telling the monitor to scale or not? > > "none" and "center" would send different mode timing to the monitor. > In the driver, you either send the actual mode timing to the monitor > (scale == none) or you send native mode timing (scale == center || > scale == full || scale == aspect). For example with DVI monitors some > users prefer to use the GPU's scaler over the monitor's and vice > versa. I.e., with "none", a monitor would get actual 800x600 timing for a mode, even if the monitor's native mode was 1024x768. The monitor would then to the scaling or centering, etc. Alex -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: clarify scaling property names
On Wed, Jul 1, 2009 at 1:04 PM, Jesse Barnes wrote:
> On Wed, 1 Jul 2009 12:22:17 -0400
> Alex Deucher wrote:
>
>> On Wed, Jul 1, 2009 at 12:19 PM, Alex Deucher
>> wrote:
>> > On Wed, Jul 1, 2009 at 12:11 PM, Jesse
>> > Barnes wrote:
>> >> On Wed, 1 Jul 2009 11:23:50 +0200
>> >> Maarten Maathuis wrote:
>> >>
>> >>> DRM_MODE_SCALE_NON_GPU was intended to let the monitor do the
>> >>> scaling, in case you have a CRT or the monitors scalers are
>> >>> better. I think your new name choice is less than ideal.
>> >>
>> >> If that's what it's supposed to be, then yes, it's not ideal.
>> >> There was some debate on the IRC channel about what it meant...
>> >>
>> >> If it's a monitor thing, how is it different from "none" or
>> >> "center"? Is there some way of telling the monitor to scale or not?
>> >
>> > "none" and "center" would send different mode timing to the monitor.
>> > In the driver, you either send the actual mode timing to the monitor
>> > (scale == none) or you send native mode timing (scale == center ||
>> > scale == full || scale == aspect). For example with DVI monitors
>> > some users prefer to use the GPU's scaler over the monitor's and
>> > vice versa.
>>
>> I.e., with "none", a monitor would get actual 800x600 timing for a
>> mode, even if the monitor's native mode was 1024x768. The monitor
>> would then to the scaling or centering, etc.
>
> Here's an updated patch. Thanks Alex and Maarten.
>
> --
>
> Now that we're using the scaling property in the Intel driver I noticed
> that the names were a bit confusing. I've corrected them according to
> our discussion on IRC and the mailing list, though I've left out
> potential new additions for a new scaling property with an integer (or
> two) for the scaling factor. None of the drivers implement that today,
> but if someone wants to do it, I think it could be done with the
> addition of a single new type and a new property to describe the
> scaling factor in the X and Y directions.
>
> Signed-off-by: Jesse Barnes
Acked-by: Alex Deucher
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 8fab789..41ed5b8 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -68,10 +68,10 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> */
> static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> {
> - { DRM_MODE_SCALE_NON_GPU, "Non-GPU" },
> - { DRM_MODE_SCALE_FULLSCREEN, "Fullscreen" },
> - { DRM_MODE_SCALE_NO_SCALE, "No scale" },
> - { DRM_MODE_SCALE_ASPECT, "Aspect" },
> + { DRM_MODE_SCALE_NONE, "None" },
> + { DRM_MODE_SCALE_FULLSCREEN, "Full" },
> + { DRM_MODE_SCALE_CENTER, "Center" },
> + { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 9564ca4..1e02ade 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -335,7 +335,7 @@ static bool intel_lvds_mode_fixup(struct drm_encoder
> *encoder,
> I915_WRITE(BCLRPAT_B, 0);
>
> switch (lvds_priv->fitting_mode) {
> - case DRM_MODE_SCALE_NO_SCALE:
> + case DRM_MODE_SCALE_CENTER:
> /*
> * For centered modes, we have to calculate border widths &
> * heights and modify the values programmed into the CRTC.
> @@ -671,9 +671,8 @@ static int intel_lvds_set_property(struct drm_connector
> *connector,
> connector->encoder) {
> struct drm_crtc *crtc = connector->encoder->crtc;
> struct intel_lvds_priv *lvds_priv = intel_output->dev_priv;
> - if (value == DRM_MODE_SCALE_NON_GPU) {
> - DRM_DEBUG_KMS(I915_LVDS,
> - "non_GPU property is unsupported\n");
> + if (value == DRM_MODE_SCALE_NONE) {
> + DRM_DEBUG_KMS(I915_LVDS, "no scaling not
> supported\n");
> return 0;
> }
> if (lvds_priv->fitting_mode == value) {
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index ae304cc..b56fc4b 100644
&
[PATCH] radeon: add some missing pci ids
Also, fix ordering for a couple others
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 45c1867..7174818 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -43,6 +43,7 @@
{0x1002, 0x4A4F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4A50, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4A54, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R420|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x4B48, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4B49, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4B4A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4B4B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R420|RADEON_NEW_MEMMAP}, \
@@ -262,6 +263,7 @@
{0x1002, 0x9440, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9441, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9442, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9443, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9444, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9446, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x944A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -346,12 +348,12 @@
{0x1002, 0x9599, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV635|RADEON_NEW_MEMMAP}, \
{0x1002, 0x959B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV635|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95C0, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x95C2, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x95C4, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95C5, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95C6, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95C7, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95C9, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
- {0x1002, 0x95C2, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
- {0x1002, 0x95C4, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95CC, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95CD, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95CE, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV620|RADEON_NEW_MEMMAP}, \
--
1.5.6.3
From 9808498607ff09e7503c79e84a112ada84e139e7 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 1 Jul 2009 13:03:52 -0400
Subject: [PATCH] radeon: add some missing pci ids
Also, fix ordering for a couple others
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 45c1867..7174818 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -43,6 +43,7 @@
{0x1002, 0x4A4F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4A50, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4A54, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R420|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x4B48, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4B49, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4B4A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R420|RADEON_NEW_MEMMAP}, \
{0x1002, 0x4B4B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R420|RADEON_NEW_MEMMAP}, \
@@ -262,6 +263,7 @@
{0x1002, 0x9440, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9441, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9442, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9443, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9444, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9446, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x944A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -346,12 +348,12 @@
{0x1002, 0x9599, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV635|RADEON_NEW_MEMMAP}, \
{0x1002, 0x959B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV635|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x95C0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV620|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x95C2, PCI_ANY_ID, PCI_ANY_ID
[PATCH] radeon KMS: get lvds info for DIG LVTMA and UNIPHY encoders
Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
panels can be driven by KLDSCP_LVTMA or UNIPHY.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index c8ef0d1..ea15284 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1700,8 +1700,14 @@ radeon_add_atom_encoder(struct drm_device *dev,
uint32_t encoder_id, uint32_t su
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
DRM_MODE_ENCODER_TMDS);
- radeon_encoder->enc_priv =
radeon_atombios_set_dig_info(radeon_encoder);
+ if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
+ radeon_encoder->rmx_type = RMX_FULL;
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
DRM_MODE_ENCODER_LVDS);
+ radeon_encoder->enc_priv =
radeon_atombios_get_lvds_info(radeon_encoder);
+ } else {
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
DRM_MODE_ENCODER_TMDS);
+ radeon_encoder->enc_priv =
radeon_atombios_set_dig_info(radeon_encoder);
+ }
drm_encoder_helper_add(encoder, &radeon_atom_dig_helper_funcs);
break;
}
--
1.5.6.3
From 8a2d4603cbada64b106e6a043c3b08c120818d9e Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 1 Jul 2009 13:06:50 -0400
Subject: [PATCH] radeon KMS: get lvds info for DIG LVTMA and UNIPHY encoders
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
panels can be driven by KLDSCP_LVTMA or UNIPHY.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index c8ef0d1..ea15284 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1700,8 +1700,14 @@ radeon_add_atom_encoder(struct drm_device *dev, uint32_t encoder_id, uint32_t su
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs, DRM_MODE_ENCODER_TMDS);
- radeon_encoder->enc_priv = radeon_atombios_set_dig_info(radeon_encoder);
+ if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
+ radeon_encoder->rmx_type = RMX_FULL;
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs, DRM_MODE_ENCODER_LVDS);
+ radeon_encoder->enc_priv = radeon_atombios_get_lvds_info(radeon_encoder);
+ } else {
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs, DRM_MODE_ENCODER_TMDS);
+ radeon_encoder->enc_priv = radeon_atombios_set_dig_info(radeon_encoder);
+ }
drm_encoder_helper_add(encoder, &radeon_atom_dig_helper_funcs);
break;
}
--
1.5.6.3
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] radeon KMS: get lvds info for DIG LVTMA and UNIPHY encoders
Ignore this one for now. Doesn't hurt, but r6xx dig stuff needs more work.
Alex
2009/7/1 Alex Deucher :
> Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
> panels can be driven by KLDSCP_LVTMA or UNIPHY.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_encoders.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
> b/drivers/gpu/drm/radeon/radeon_encoders.c
> index c8ef0d1..ea15284 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -1700,8 +1700,14 @@ radeon_add_atom_encoder(struct drm_device *dev,
> uint32_t encoder_id, uint32_t su
> case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
> case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
> case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> - drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
> DRM_MODE_ENCODER_TMDS);
> - radeon_encoder->enc_priv =
> radeon_atombios_set_dig_info(radeon_encoder);
> + if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
> + radeon_encoder->rmx_type = RMX_FULL;
> + drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
> DRM_MODE_ENCODER_LVDS);
> + radeon_encoder->enc_priv =
> radeon_atombios_get_lvds_info(radeon_encoder);
> + } else {
> + drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
> DRM_MODE_ENCODER_TMDS);
> + radeon_encoder->enc_priv =
> radeon_atombios_set_dig_info(radeon_encoder);
> + }
> drm_encoder_helper_add(encoder, &radeon_atom_dig_helper_funcs);
> break;
> }
> --
> 1.5.6.3
>
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon: fix quirk for MSI laptop
The line mux for the connector in the bios tables
is used for enumerating drm connectors. Since
this laptop has a quirk where the same line much is
listed for both VGA and LVDS, the connectors get
combined. Setting the line mux on LVDS to an unused
value prevents both encoders from being combined into
the same connector. This should fix bko bug 13720.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 1f5a1a4..fcfe5c0 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -103,7 +103,8 @@ static inline struct radeon_i2c_bus_rec
radeon_lookup_gpio(struct drm_device
static bool radeon_atom_apply_quirks(struct drm_device *dev,
uint32_t supported_device,
int *connector_type,
-struct radeon_i2c_bus_rec *i2c_bus)
+struct radeon_i2c_bus_rec *i2c_bus,
+uint8_t *line_mux)
{
/* Asus M2A-VM HDMI board lists the DVI port as HDMI */
@@ -127,8 +128,10 @@ static bool radeon_atom_apply_quirks(struct
drm_device *dev,
if ((dev->pdev->device == 0x5653) &&
(dev->pdev->subsystem_vendor == 0x1462) &&
(dev->pdev->subsystem_device == 0x0291)) {
- if (*connector_type == DRM_MODE_CONNECTOR_LVDS)
+ if (*connector_type == DRM_MODE_CONNECTOR_LVDS) {
i2c_bus->valid = false;
+ *line_mux = 53;
+ }
}
/* Funky macbooks */
@@ -526,7 +529,7 @@ bool
radeon_get_atom_connector_info_from_supported_devices_table(struct
if (!radeon_atom_apply_quirks
(dev, (1 << i), &bios_connectors[i].connector_type,
-&bios_connectors[i].ddc_bus))
+&bios_connectors[i].ddc_bus, &bios_connectors[i].line_mux))
continue;
bios_connectors[i].valid = true;
--
1.5.6.3
From c9aed0292e125d1be9bcc8a9e1acfa041d424b00 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 6 Jul 2009 11:39:18 -0400
Subject: [PATCH] radeon: fix quirk for MSI laptop
The line mux for the connector in the bios tables
is used for enumerating drm connectors. Since
this laptop has a quirk where the same line much is
listed for both VGA and LVDS, the connectors get
combined. Setting the line mux on LVDS to an unused
value prevents both encoders from being combined into
the same connector. This should fix bko bug 13720.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c
index 1f5a1a4..fcfe5c0 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -103,7 +103,8 @@ static inline struct radeon_i2c_bus_rec radeon_lookup_gpio(struct drm_device
static bool radeon_atom_apply_quirks(struct drm_device *dev,
uint32_t supported_device,
int *connector_type,
- struct radeon_i2c_bus_rec *i2c_bus)
+ struct radeon_i2c_bus_rec *i2c_bus,
+ uint8_t *line_mux)
{
/* Asus M2A-VM HDMI board lists the DVI port as HDMI */
@@ -127,8 +128,10 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
if ((dev->pdev->device == 0x5653) &&
(dev->pdev->subsystem_vendor == 0x1462) &&
(dev->pdev->subsystem_device == 0x0291)) {
- if (*connector_type == DRM_MODE_CONNECTOR_LVDS)
+ if (*connector_type == DRM_MODE_CONNECTOR_LVDS) {
i2c_bus->valid = false;
+ *line_mux = 53;
+ }
}
/* Funky macbooks */
@@ -526,7 +529,7 @@ bool radeon_get_atom_connector_info_from_supported_devices_table(struct
if (!radeon_atom_apply_quirks
(dev, (1 << i), &bios_connectors[i].connector_type,
- &bios_connectors[i].ddc_bus))
+ &bios_connectors[i].ddc_bus, &bios_connectors[i].line_mux))
continue;
bios_connectors[i].valid = true;
--
1.5.6.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon KMS: get lvds info for DIG LVTMA and UNIPHY encoders
Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
panels can be driven by KLDSCP_LVTMA or UNIPHY.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index c8ef0d1..ea15284 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1700,8 +1700,14 @@ radeon_add_atom_encoder(struct drm_device *dev,
uint32_t encoder_id, uint32_t su
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
DRM_MODE_ENCODER_TMDS);
- radeon_encoder->enc_priv =
radeon_atombios_set_dig_info(radeon_encoder);
+ if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
+ radeon_encoder->rmx_type = RMX_FULL;
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
DRM_MODE_ENCODER_LVDS);
+ radeon_encoder->enc_priv =
radeon_atombios_get_lvds_info(radeon_encoder);
+ } else {
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs,
DRM_MODE_ENCODER_TMDS);
+ radeon_encoder->enc_priv =
radeon_atombios_set_dig_info(radeon_encoder);
+ }
drm_encoder_helper_add(encoder, &radeon_atom_dig_helper_funcs);
break;
}
--
1.5.6.3
From 8a2d4603cbada64b106e6a043c3b08c120818d9e Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 1 Jul 2009 13:06:50 -0400
Subject: [PATCH] radeon KMS: get lvds info for DIG LVTMA and UNIPHY encoders
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
panels can be driven by KLDSCP_LVTMA or UNIPHY.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index c8ef0d1..ea15284 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1700,8 +1700,14 @@ radeon_add_atom_encoder(struct drm_device *dev, uint32_t encoder_id, uint32_t su
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs, DRM_MODE_ENCODER_TMDS);
- radeon_encoder->enc_priv = radeon_atombios_set_dig_info(radeon_encoder);
+ if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
+ radeon_encoder->rmx_type = RMX_FULL;
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs, DRM_MODE_ENCODER_LVDS);
+ radeon_encoder->enc_priv = radeon_atombios_get_lvds_info(radeon_encoder);
+ } else {
+ drm_encoder_init(dev, encoder, &radeon_atom_enc_funcs, DRM_MODE_ENCODER_TMDS);
+ radeon_encoder->enc_priv = radeon_atombios_set_dig_info(radeon_encoder);
+ }
drm_encoder_helper_add(encoder, &radeon_atom_dig_helper_funcs);
break;
}
--
1.5.6.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Make xorg.conf NoAccel/DRI options work under KMS
On Thu, Jul 9, 2009 at 11:15 AM, Keith Packard wrote: > On Wed, 2009-07-08 at 20:28 +0100, Julien Cristau wrote: > >> DRI2 init can fail for various reasons, and it's easier to test if you >> don't have to hack the driver. No particular opinion on kms without >> uxa, though. > > Right, which is why I also fixed the DRI option parsing in the KMS case > (which was broken before). > > Any thoughts on whether NoAccel remains useful though? Might be useful to bring up a shadowfb or noaccel X if the user is having accel problems, just to have a desktop. Alex -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Make xorg.conf NoAccel/DRI options work under KMS
On Thu, Jul 9, 2009 at 4:45 PM, Keith Packard wrote: > On Thu, 2009-07-09 at 11:37 -0400, Alex Deucher wrote: > >> Might be useful to bring up a shadowfb or noaccel X if the user is >> having accel problems, just to have a desktop. > > That's been the traditional answer, but at this point, NoAccel is a > completely separate path through our driver as it requires that the > framebuffer be mapped to userspace at driver startup time, rather than > only during unaccelerated operations. > > Which means that instead of being a reasonable 'fail over' plan, it > turns out to just be an additional source of bugs. In fact, noaccel has > never worked with KMS, and yet we've seen no reports of trouble... How about having your accel prepare funcs return false when noaccel is set. Alex -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon kms: Add PLL flag to prefer frequencies <= the target freq
This is needed when using fractional feedback dividers on some IGP
chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c |6 +-
drivers/gpu/drm/radeon/radeon_mode.h|1 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 3efcf1a..bc312f3 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -491,7 +491,11 @@ void radeon_compute_pll(struct radeon_pll *pll,
tmp += (uint64_t)pll->reference_freq *
1000 * frac_feedback_div;
current_freq = radeon_div(tmp, ref_div
* post_div);
- error = abs(current_freq - freq);
+ if (flags &
RADEON_PLL_PREFER_CLOSEST_LOWER) {
+ error = freq - current_freq;
+ error = error < 0 ? 0x
: error;
+ } else
+ error = abs(current_freq -
freq);
vco_diff = abs(vco - best_vco);
if ((best_vco == 0 && error <
best_error) ||
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 9173b68..e9b95ed 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -124,6 +124,7 @@ struct radeon_tmds_pll {
#define RADEON_PLL_PREFER_LOW_POST_DIV (1 << 8)
#define RADEON_PLL_PREFER_HIGH_POST_DIV (1 << 9)
#define RADEON_PLL_USE_FRAC_FB_DIV (1 << 10)
+#define RADEON_PLL_PREFER_CLOSEST_LOWER (1 << 11)
struct radeon_pll {
uint16_t reference_freq;
--
1.5.6.3
From 04bd5370d2694378e6bb1f6b87d3426702ebc1bd Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 13 Jul 2009 10:55:11 -0400
Subject: [PATCH] radeon kms: Add PLL flag to prefer frequencies <= the target freq
This is needed when using fractional feedback dividers on some IGP
chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c |6 +-
drivers/gpu/drm/radeon/radeon_mode.h|1 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 3efcf1a..bc312f3 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -491,7 +491,11 @@ void radeon_compute_pll(struct radeon_pll *pll,
tmp += (uint64_t)pll->reference_freq * 1000 * frac_feedback_div;
current_freq = radeon_div(tmp, ref_div * post_div);
- error = abs(current_freq - freq);
+ if (flags & RADEON_PLL_PREFER_CLOSEST_LOWER) {
+ error = freq - current_freq;
+ error = error < 0 ? 0x : error;
+ } else
+ error = abs(current_freq - freq);
vco_diff = abs(vco - best_vco);
if ((best_vco == 0 && error < best_error) ||
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h
index 9173b68..e9b95ed 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -124,6 +124,7 @@ struct radeon_tmds_pll {
#define RADEON_PLL_PREFER_LOW_POST_DIV (1 << 8)
#define RADEON_PLL_PREFER_HIGH_POST_DIV (1 << 9)
#define RADEON_PLL_USE_FRAC_FB_DIV (1 << 10)
+#define RADEON_PLL_PREFER_CLOSEST_LOWER (1 << 11)
struct radeon_pll {
uint16_t reference_freq;
--
1.5.6.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] radeon kms: enable frac fb divs on rs600/rs690/rs740
Allows us to hit dot clocks much closer, especially on
chips with non-27 Mhz reference clocks like most IGP chips.
This fixes most flickering and blanking problems with
non-exact dot clocks on these chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index c0080cc..e64a199 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -203,6 +203,12 @@ void atombios_crtc_set_pll(struct drm_crtc *crtc,
struct drm_display_mode *mode)
if (ASIC_IS_AVIVO(rdev)) {
uint32_t ss_cntl;
+ if ((rdev->family == CHIP_RS600) ||
+ (rdev->family == CHIP_RS690) ||
+ (rdev->family == CHIP_RS740))
+ pll_flags |= (RADEON_PLL_USE_FRAC_FB_DIV |
+ RADEON_PLL_PREFER_CLOSEST_LOWER);
+
if (ASIC_IS_DCE32(rdev) && mode->clock > 20)/*
range limits??? */
pll_flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
else
--
1.5.6.3
From 9b39908a43ba5ee030f4f581669a3f58c53f5ad7 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 13 Jul 2009 11:03:28 -0400
Subject: [PATCH] radeon kms: enable frac fb divs on rs600/rs690/rs740
Allows us to hit dot clocks much closer, especially on
chips with non-27 Mhz reference clocks like most IGP chips.
This fixes most flickering and blanking problems with
non-exact dot clocks on these chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index c0080cc..e64a199 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -203,6 +203,12 @@ void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode *mode)
if (ASIC_IS_AVIVO(rdev)) {
uint32_t ss_cntl;
+ if ((rdev->family == CHIP_RS600) ||
+ (rdev->family == CHIP_RS690) ||
+ (rdev->family == CHIP_RS740))
+ pll_flags |= (RADEON_PLL_USE_FRAC_FB_DIV |
+ RADEON_PLL_PREFER_CLOSEST_LOWER);
+
if (ASIC_IS_DCE32(rdev) && mode->clock > 20) /* range limits??? */
pll_flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
else
--
1.5.6.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] radeon kms: Add PLL flag to prefer frequencies <= the target freq
This should be 1/2. this patch is required for "radeon kms: enable
frac fb divs on rs600/rs690/rs740"
On Mon, Jul 13, 2009 at 11:08 AM, Alex Deucher wrote:
> This is needed when using fractional feedback dividers on some IGP
> chips.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 6 +-
> drivers/gpu/drm/radeon/radeon_mode.h | 1 +
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 3efcf1a..bc312f3 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -491,7 +491,11 @@ void radeon_compute_pll(struct radeon_pll *pll,
> tmp += (uint64_t)pll->reference_freq *
> 1000 * frac_feedback_div;
> current_freq = radeon_div(tmp, ref_div
> * post_div);
>
> - error = abs(current_freq - freq);
> + if (flags &
> RADEON_PLL_PREFER_CLOSEST_LOWER) {
> + error = freq - current_freq;
> + error = error < 0 ?
> 0x : error;
> + } else
> + error = abs(current_freq -
> freq);
> vco_diff = abs(vco - best_vco);
>
> if ((best_vco == 0 && error <
> best_error) ||
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 9173b68..e9b95ed 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -124,6 +124,7 @@ struct radeon_tmds_pll {
> #define RADEON_PLL_PREFER_LOW_POST_DIV (1 << 8)
> #define RADEON_PLL_PREFER_HIGH_POST_DIV (1 << 9)
> #define RADEON_PLL_USE_FRAC_FB_DIV (1 << 10)
> +#define RADEON_PLL_PREFER_CLOSEST_LOWER (1 << 11)
>
> struct radeon_pll {
> uint16_t reference_freq;
> --
> 1.5.6.3
>
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon kms: fix hotspot handling on pre-avivo chips
Need to adjust CUR_OFFSET for xorigin
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_cursor.c |9 +++--
drivers/gpu/drm/radeon/radeon_mode.h |1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 5f8ce37..b13c79e 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -111,9 +111,11 @@ static void radeon_set_cursor(struct drm_crtc
*crtc, struct drm_gem_object *obj,
if (ASIC_IS_AVIVO(rdev))
WREG32(AVIVO_D1CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
gpu_addr);
- else
+ else {
+ radeon_crtc->legacy_cursor_offset = gpu_addr -
radeon_crtc->legacy_display_base_addr;
/* offset is from DISP(2)_BASE_ADDRESS */
- WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
(gpu_addr-radeon_crtc->legacy_display_base_addr));
+ WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
radeon_crtc->legacy_cursor_offset);
+ }
}
int radeon_crtc_cursor_set(struct drm_crtc *crtc,
@@ -245,6 +247,9 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
(RADEON_CUR_LOCK
| ((xorigin ? 0 : x) << 16)
| (yorigin ? 0 : y)));
+ /* offset is from DISP(2)_BASE_ADDRESS */
+ WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
(radeon_crtc->legacy_cursor_offset +
+ (yorigin
* 256)));
}
radeon_lock_cursor(crtc, false);
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 38c1dd0..ba89b59 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -187,6 +187,7 @@ struct radeon_crtc {
int cursor_width;
int cursor_height;
uint32_t legacy_display_base_addr;
+ uint32_t legacy_cursor_offset;
};
#define RADEON_USE_RMX 1
--
1.5.6.3
From 22345f906106b66a1cfd699cb7732f3a7c0d1700 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 13 Jul 2009 13:46:53 -0400
Subject: [PATCH] radeon kms: fix hotspot handling on pre-avivo chips
Need to adjust CUR_OFFSET for xorigin
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_cursor.c |9 +++--
drivers/gpu/drm/radeon/radeon_mode.h |1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c b/drivers/gpu/drm/radeon/radeon_cursor.c
index 5f8ce37..b13c79e 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -111,9 +111,11 @@ static void radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object *obj,
if (ASIC_IS_AVIVO(rdev))
WREG32(AVIVO_D1CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset, gpu_addr);
- else
+ else {
+ radeon_crtc->legacy_cursor_offset = gpu_addr - radeon_crtc->legacy_display_base_addr;
/* offset is from DISP(2)_BASE_ADDRESS */
- WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, (gpu_addr-radeon_crtc->legacy_display_base_addr));
+ WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, radeon_crtc->legacy_cursor_offset);
+ }
}
int radeon_crtc_cursor_set(struct drm_crtc *crtc,
@@ -245,6 +247,9 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
(RADEON_CUR_LOCK
| ((xorigin ? 0 : x) << 16)
| (yorigin ? 0 : y)));
+ /* offset is from DISP(2)_BASE_ADDRESS */
+ WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, (radeon_crtc->legacy_cursor_offset +
+ (yorigin * 256)));
}
radeon_lock_cursor(crtc, false);
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h
index 38c1dd0..ba89b59 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -187,6 +187,7 @@ struct radeon_crtc {
int cursor_width;
int cursor_height;
uint32_t legacy_display_base_addr;
+ uint32_t legacy_cursor_offset;
};
#define RADEON_USE_RMX 1
--
1.5.6.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
r600 dri driver
I'm planning to merge this to master soon. It's still pretty raw, but at this point it will run gears and most of the basic demos. It shares a lot of the common radeon code so I'd like to get it merged sooner rather than later to avoid the need to constantly keep it up to date with the latest changes in master. It currently needs a special drm branch to actually function, but it should build against libdrm from master. Consider it experimental like r300g for now. Let me know if you have any objections. Thanks, Alex -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r600 dri driver
On Wed, Jul 15, 2009 at 5:59 PM, Alex Deucher wrote: > I'm planning to merge this to master soon. It's still pretty raw, but > at this point it will run gears and most of the basic demos. It > shares a lot of the common radeon code so I'd like to get it merged > sooner rather than later to avoid the need to constantly keep it up to > date with the latest changes in master. It currently needs a special > drm branch to actually function, but it should build against libdrm > from master. Consider it experimental like r300g for now. Let me > know if you have any objections. I've gone ahead and merged it. If anyone finds any regressions in the other radeon/r200/r300 drivers due to the merge let me know. Alex -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm_pciids.txt
On Sun, Jul 26, 2009 at 2:41 PM, wrote: > Hello all, > > I'm not sure of whether I'm mailing this to the correct addresses or not, so > bare with me. I noticed that the file 'shared-core/drm_pciids.txt' contains > 2 entries in the 'sis' group that actually have the same pci vender id as > 'xgi'. The only difference is that the id's are upper cased in the 'sis' > group (0x18CA) & lower case in the 'xgi' group (0x18ca). Since the cards in > the 'sis' group that have this id are listed as Volari cards, I was > wondering if the uppercase was intentional. The uppercase causes the > create_(os)_pci_list.sh script to choke & then skip the cards. If this is > the case & if drm currently can't handle these cards, then I understand. > Otherwise, I'm going to find a way to ensure that all of the id's are > converted to lowercase before processing. xgi is a combination of the old sis and trident graphics groups, so some of the hardware overlaps. Alex -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: add some new r7xx pci ids
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 7174818..9d4c004 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -257,9 +257,12 @@
{0x1002, 0x940F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R600|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94A0, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94A1, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94A3, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94B1, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94B3, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94B4, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94B5, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94B9, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9440, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9441, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9442, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV770|RADEON_NEW_MEMMAP}, \
@@ -288,6 +291,7 @@
{0x1002, 0x948F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9490, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9491, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9495, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9498, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x949C, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x949E, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV730|RADEON_NEW_MEMMAP}, \
@@ -325,6 +329,7 @@
{0x1002, 0x9552, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9553, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9555, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9557, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9580, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV630|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9581, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV630|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9583, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV630|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
--
1.5.6.3
From d0d1653b1697d042e48e9a66ccf9690a46bc9e32 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 3 Aug 2009 17:01:53 -0400
Subject: [PATCH] drm/radeon: add some new r7xx pci ids
Signed-off-by: Alex Deucher
---
include/drm/drm_pciids.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 7174818..9d4c004 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -257,9 +257,12 @@
{0x1002, 0x940F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R600|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94A0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94A1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94A3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94B1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94B3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94B4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_NEW_MEMMAP}, \
{0x1002, 0x94B5, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x94B9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV740|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9440, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9441, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9442, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV770|RADEON_NEW_MEMMAP}, \
@@ -288,6 +291,7 @@
{0x1002, 0x948F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9490, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9491, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x9495, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x9498, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x949C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730|RADEON_NEW_MEMMAP}, \
{0x1002, 0x949E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV730
[PATCH] drm/radeon: Add support for RS880 chips
These are new AMD IGP chips
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cp.c| 22 +++---
drivers/gpu/drm/radeon/radeon_drv.h |1 +
include/drm/drm_pciids.h|5 +
3 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index 146f357..20f1790 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -384,8 +384,9 @@ static void
r600_cp_load_microcode(drm_radeon_private_t *dev_priv)
DRM_INFO("Loading RV670 PFP Microcode\n");
for (i = 0; i < PFP_UCODE_SIZE; i++)
RADEON_WRITE(R600_CP_PFP_UCODE_DATA,
RV670_pfp_microcode[i]);
- } else if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780)) {
- DRM_INFO("Loading RS780 CP Microcode\n");
+ } else if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780) ||
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS880)) {
+ DRM_INFO("Loading RS780/RS880 CP Microcode\n");
for (i = 0; i < PM4_UCODE_SIZE; i++) {
RADEON_WRITE(R600_CP_ME_RAM_DATA,
RS780_cp_microcode[i][0]);
@@ -396,7 +397,7 @@ static void
r600_cp_load_microcode(drm_radeon_private_t *dev_priv)
}
RADEON_WRITE(R600_CP_PFP_UCODE_ADDR, 0);
- DRM_INFO("Loading RS780 PFP Microcode\n");
+ DRM_INFO("Loading RS780/RS880 PFP Microcode\n");
for (i = 0; i < PFP_UCODE_SIZE; i++)
RADEON_WRITE(R600_CP_PFP_UCODE_DATA,
RS780_pfp_microcode[i]);
}
@@ -783,6 +784,7 @@ static void r600_gfx_init(struct drm_device *dev,
break;
case CHIP_RV610:
case CHIP_RS780:
+ case CHIP_RS880:
case CHIP_RV620:
dev_priv->r600_max_pipes = 1;
dev_priv->r600_max_tile_pipes = 1;
@@ -917,7 +919,8 @@ static void r600_gfx_init(struct drm_device *dev,
((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV630) ||
((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV610) ||
((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV620) ||
- ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780))
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780) ||
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS880))
RADEON_WRITE(R600_DB_DEBUG, R600_PREZ_MUST_WAIT_FOR_POSTZ_DONE);
else
RADEON_WRITE(R600_DB_DEBUG, 0);
@@ -935,7 +938,8 @@ static void r600_gfx_init(struct drm_device *dev,
sq_ms_fifo_sizes = RADEON_READ(R600_SQ_MS_FIFO_SIZES);
if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV610) ||
((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV620) ||
- ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780)) {
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780) ||
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS880)) {
sq_ms_fifo_sizes = (R600_CACHE_FIFO_SIZE(0xa) |
R600_FETCH_FIFO_HIWATER(0xa) |
R600_DONE_FIFO_HIWATER(0xe0) |
@@ -978,7 +982,8 @@ static void r600_gfx_init(struct drm_device *dev,
R600_NUM_ES_STACK_ENTRIES(0));
} else if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV610) ||
((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV620) ||
- ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780)) {
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780) ||
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS880)) {
/* no vertex cache */
sq_config &= ~R600_VC_ENABLE;
@@ -1035,7 +1040,8 @@ static void r600_gfx_init(struct drm_device *dev,
if (((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV610) ||
((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV620) ||
- ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780))
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS780) ||
+ ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RS880))
RADEON_WRITE(R600_VGT_CACHE_INVALIDATION,
R600_CACHE_INVALIDATION(R600_TC_ONLY));
else
RADEON_WRITE(R600_VGT_CACHE_INVALIDATION,
R600_CACHE_INVALIDATION(R600_VC_AND_TC));
@@ -1078,6 +1084,7 @@ static void r600_gfx_init(struct drm_device *dev,
break;
case CHIP_RV610:
case CHIP_RS780:
+ case CHIP_RS880:
case CHIP_R
Re: [PATCH] drm/radeon: Save and restore AtomBIOS scratch regs during S/R
On Fri, Aug 14, 2009 at 5:09 PM, Yang Zhao wrote:
> Signed-off-by: Yang Zhao
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 ++
> drivers/gpu/drm/radeon/radeon_atombios.c | 28
> drivers/gpu/drm/radeon/radeon_device.c | 5 +
> drivers/gpu/drm/radeon/radeon_mode.h | 2 ++
> 4 files changed, 37 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index b1d945b..ab213d2 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -75,6 +75,7 @@ extern int radeon_connector_table;
> #define RADEON_IB_POOL_SIZE 16
> #define RADEON_DEBUGFS_MAX_NUM_FILES 32
> #define RADEONFB_CONN_LIMIT 4
> +#define RADEON_ATOMBIOS_NUM_SCRATCH 8
>
> enum radeon_family {
> CHIP_R100,
> @@ -689,6 +690,7 @@ struct radeon_device {
> struct radeon_asic *asic;
> struct radeon_gem gem;
> struct radeon_pm pm;
> + uint32_t
> atombios_scratch[RADEON_ATOMBIOS_NUM_SCRATCH];
> struct mutex cs_mutex;
> struct radeon_wb wb;
> bool gpu_lockup;
> diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
> b/drivers/gpu/drm/radeon/radeon_atombios.c
> index fcfe5c0..2292443 100644
> --- a/drivers/gpu/drm/radeon/radeon_atombios.c
> +++ b/drivers/gpu/drm/radeon/radeon_atombios.c
> @@ -971,6 +971,34 @@ void radeon_atom_initialize_bios_scratch_regs(struct
> drm_device *dev)
>
> }
>
> +void radeon_atom_save_bios_scratch_regs(struct radeon_device *rdev)
> +{
> + uint32_t scratch_reg;
> + int i;
> +
> + if (rdev->family >= CHIP_R600)
> + scratch_reg = R600_BIOS_0_SCRATCH;
> + else
> + scratch_reg = RADEON_BIOS_0_SCRATCH;
> +
> + for (i = 0; i < RADEON_ATOMBIOS_NUM_SCRATCH; i++)
> + rdev->atombios_scratch[i] = RREG32(scratch_reg + (i * 4));
> +}
> +
> +void radeon_atom_restore_bios_scratch_regs(struct radeon_device *rdev)
> +{
> + uint32_t scratch_reg;
> + int i;
> +
> + if (rdev->family >= CHIP_R600)
> + scratch_reg = R600_BIOS_0_SCRATCH;
> + else
> + scratch_reg = RADEON_BIOS_0_SCRATCH;
> +
> + for (i = 0; i < RADEON_ATOMBIOS_NUM_SCRATCH; i++)
> + WREG32(scratch_reg + (i * 4), rdev->atombios_scratch[i]);
> +}
> +
> void radeon_atom_output_lock(struct drm_encoder *encoder, bool lock)
> {
> struct drm_device *dev = encoder->dev;
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 9ff6dcb..4d9baff 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -715,6 +715,9 @@ int radeon_suspend_kms(struct drm_device *dev,
> pm_message_t state)
> /* wait for gpu to finish processing current batch */
> radeon_fence_wait_last(rdev);
>
> + if (rdev->is_atom_bios)
> + radeon_atom_save_bios_scratch_regs(rdev);
> +
> radeon_cp_disable(rdev);
> radeon_gart_disable(rdev);
>
> @@ -782,6 +785,8 @@ int radeon_resume_kms(struct drm_device *dev)
> goto out;
> }
> out:
> + if (rdev->is_atom_bios)
> + radeon_atom_restore_bios_scratch_regs(rdev);
> fb_set_suspend(rdev->fbdev_info, 0);
> release_console_sem();
>
We need to save/restore the scratch regs on atom and pre-atom cards.
Other than that, looks good. We should also probably re-probe on
resume in case the user has changed monitors during suspend.
Alex
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 3b09a1f..9d469a8 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -356,6 +356,8 @@ extern void radeon_combios_output_lock(struct drm_encoder
> *encoder, bool lock);
> extern void radeon_combios_initialize_bios_scratch_regs(struct drm_device
> *dev);
> extern void radeon_atom_output_lock(struct drm_encoder *encoder, bool lock);
> extern void radeon_atom_initialize_bios_scratch_regs(struct drm_device *dev);
> +extern void radeon_atom_save_bios_scratch_regs(struct radeon_device *rdev);
> +extern void radeon_atom_restore_bios_scratch_regs(struct radeon_device
> *rdev);
> extern void
> radeon_atombios_encoder_crtc_scratch_regs(struct drm_encoder *encoder, int
> crtc);
> extern void
> --
> 1.6.3.3
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> --
> __
Re: [PATCH] drm/radeon: Save and restore AtomBIOS scratch regs during S/R
On Fri, Aug 14, 2009 at 5:09 PM, Yang Zhao wrote:
> Signed-off-by: Yang Zhao
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 ++
> drivers/gpu/drm/radeon/radeon_atombios.c | 28
> drivers/gpu/drm/radeon/radeon_device.c | 5 +
> drivers/gpu/drm/radeon/radeon_mode.h | 2 ++
> 4 files changed, 37 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index b1d945b..ab213d2 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -75,6 +75,7 @@ extern int radeon_connector_table;
> #define RADEON_IB_POOL_SIZE 16
> #define RADEON_DEBUGFS_MAX_NUM_FILES 32
> #define RADEONFB_CONN_LIMIT 4
> +#define RADEON_ATOMBIOS_NUM_SCRATCH 8
>
> enum radeon_family {
> CHIP_R100,
> @@ -689,6 +690,7 @@ struct radeon_device {
> struct radeon_asic *asic;
> struct radeon_gem gem;
> struct radeon_pm pm;
> + uint32_t
> atombios_scratch[RADEON_ATOMBIOS_NUM_SCRATCH];
> struct mutex cs_mutex;
> struct radeon_wb wb;
> bool gpu_lockup;
> diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
> b/drivers/gpu/drm/radeon/radeon_atombios.c
> index fcfe5c0..2292443 100644
> --- a/drivers/gpu/drm/radeon/radeon_atombios.c
> +++ b/drivers/gpu/drm/radeon/radeon_atombios.c
> @@ -971,6 +971,34 @@ void radeon_atom_initialize_bios_scratch_regs(struct
> drm_device *dev)
>
> }
>
> +void radeon_atom_save_bios_scratch_regs(struct radeon_device *rdev)
> +{
> + uint32_t scratch_reg;
> + int i;
> +
> + if (rdev->family >= CHIP_R600)
> + scratch_reg = R600_BIOS_0_SCRATCH;
> + else
> + scratch_reg = RADEON_BIOS_0_SCRATCH;
> +
> + for (i = 0; i < RADEON_ATOMBIOS_NUM_SCRATCH; i++)
> + rdev->atombios_scratch[i] = RREG32(scratch_reg + (i * 4));
> +}
> +
> +void radeon_atom_restore_bios_scratch_regs(struct radeon_device *rdev)
> +{
> + uint32_t scratch_reg;
> + int i;
> +
> + if (rdev->family >= CHIP_R600)
> + scratch_reg = R600_BIOS_0_SCRATCH;
> + else
> + scratch_reg = RADEON_BIOS_0_SCRATCH;
> +
> + for (i = 0; i < RADEON_ATOMBIOS_NUM_SCRATCH; i++)
> + WREG32(scratch_reg + (i * 4), rdev->atombios_scratch[i]);
> +}
> +
> void radeon_atom_output_lock(struct drm_encoder *encoder, bool lock)
> {
> struct drm_device *dev = encoder->dev;
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 9ff6dcb..4d9baff 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -715,6 +715,9 @@ int radeon_suspend_kms(struct drm_device *dev,
> pm_message_t state)
> /* wait for gpu to finish processing current batch */
> radeon_fence_wait_last(rdev);
>
> + if (rdev->is_atom_bios)
> + radeon_atom_save_bios_scratch_regs(rdev);
> +
> radeon_cp_disable(rdev);
> radeon_gart_disable(rdev);
>
> @@ -782,6 +785,8 @@ int radeon_resume_kms(struct drm_device *dev)
> goto out;
> }
> out:
> + if (rdev->is_atom_bios)
> + radeon_atom_restore_bios_scratch_regs(rdev);
> fb_set_suspend(rdev->fbdev_info, 0);
> release_console_sem();
>
Also we should probably move this up before the card is posted
(asic_init()) since the init functions may write to those regs which
we will then overwrite with the saved versions. Probably not a big
deal though.
Alex
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 3b09a1f..9d469a8 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -356,6 +356,8 @@ extern void radeon_combios_output_lock(struct drm_encoder
> *encoder, bool lock);
> extern void radeon_combios_initialize_bios_scratch_regs(struct drm_device
> *dev);
> extern void radeon_atom_output_lock(struct drm_encoder *encoder, bool lock);
> extern void radeon_atom_initialize_bios_scratch_regs(struct drm_device *dev);
> +extern void radeon_atom_save_bios_scratch_regs(struct radeon_device *rdev);
> +extern void radeon_atom_restore_bios_scratch_regs(struct radeon_device
> *rdev);
> extern void
> radeon_atombios_encoder_crtc_scratch_regs(struct drm_encoder *encoder, int
> crtc);
> extern void
> --
> 1.6.3.3
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> --
> __
Re: [PATCH] libdrm_radeon: Fix loops so that compiler can optimize them.
On Tue, Aug 18, 2009 at 11:51 AM, Pauli Nieminen wrote:
> GCC did war about optimization not possible because possible forever loop.
>
> Signed-off-by: Pauli Nieminen
Acked-by: Alex Deucher
> ---
> libdrm/radeon/radeon_cs_gem.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libdrm/radeon/radeon_cs_gem.c b/libdrm/radeon/radeon_cs_gem.c
> index 264b067..a0db53b 100644
> --- a/libdrm/radeon/radeon_cs_gem.c
> +++ b/libdrm/radeon/radeon_cs_gem.c
> @@ -354,21 +354,21 @@ static void cs_gem_print(struct radeon_cs *cs, FILE
> *file)
> unsigned opcode;
> unsigned reg;
> unsigned cnt;
> - int i, j;
> + unsigned int i, j;
>
> for (i = 0; i < cs->cdw;) {
> - cnt = CP_PACKET_GET_COUNT(cs->packets[i]);
> + cnt = CP_PACKET_GET_COUNT(cs->packets[i]) + 1;
> switch (CP_PACKET_GET_TYPE(cs->packets[i])) {
> case PACKET_TYPE0:
> - fprintf(file, "Pkt0 at %d (%d dwords):\n", i, cnt + 1);
> + fprintf(file, "Pkt0 at %d (%d dwords):\n", i, cnt);
> reg = CP_PACKET0_GET_REG(cs->packets[i]);
> if (CP_PACKET0_GET_ONE_REG_WR(cs->packets[i++])) {
> - for (j = 0; j <= cnt; j++) {
> + for (j = 0; j < cnt; j++) {
> fprintf(file, " 0x%08X -> 0x%04X\n",
> cs->packets[i++], reg);
> }
> } else {
> - for (j = 0; j <= cnt; j++) {
> + for (j = 0; j < cnt; j++) {
> fprintf(file, " 0x%08X -> 0x%04X\n",
> cs->packets[i++], reg);
> reg += 4;
> @@ -410,7 +410,7 @@ static void cs_gem_print(struct radeon_cs *cs, FILE *file)
> fprintf(file, "Unknow opcode 0x%02X at %d\n", opcode, i);
> return;
> }
> - for (j = 0; j <= cnt; j++) {
> + for (j = 0; j < cnt; j++) {
> fprintf(file, " 0x%08X\n", cs->packets[i++]);
> }
> break;
> --
> 1.6.0.4
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm_radeon: Optimize copy of table to cs buffer with specialized call.
On Tue, Aug 18, 2009 at 11:51 AM, Pauli Nieminen wrote:
> Using this call in OUT_BATCH_TABLE reduces radeonEmitState cpu usage from
> 9% to 5% and emit_vpu goes from 7% to 1.5%. I did use calgrind to profile
> gears for cpu hotspots with r500 card.
>
> Signed-off-by: Pauli Nieminen
Acked-by: Alex Deucher
> ---
> libdrm/radeon/radeon_cs.h | 9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/libdrm/radeon/radeon_cs.h b/libdrm/radeon/radeon_cs.h
> index 7efec7e..1117a85 100644
> --- a/libdrm/radeon/radeon_cs.h
> +++ b/libdrm/radeon/radeon_cs.h
> @@ -201,6 +201,15 @@ static inline void radeon_cs_write_qword(struct
> radeon_cs *cs, uint64_t qword)
> }
> }
>
> +static inline void radeon_cs_write_table(struct radeon_cs *cs, void *data,
> uint32_t size)
> +{
> + memcpy(cs->packets + cs->cdw, data, size * 4);
> + cs->cdw += size;
> + if (cs->section) {
> + cs->section_cdw += size;
> + }
> +}
> +
> static inline void radeon_cs_space_set_flush(struct radeon_cs *cs, void
> (*fn)(void *), void *data)
> {
> cs->space_flush_fn = fn;
> --
> 1.6.0.4
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
drm patches for getting proper Z pipes on rv530
RV530 cards can have up to 2 Z pipes. You need to check
GB_PIPE_SELECT2 to find out how many are enabled. Mesa would need to
be updated as well. Untested.
Alex
From 0f194fff3d5c3d75a2b58b564a2de2a39ea67436 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 19 Aug 2009 16:47:09 -0400
Subject: [PATCH] drm/radeon: add GET_PARAM support for Z pipes
Needed for occlusion queries on rv530 chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_cp.c|9 +
drivers/gpu/drm/radeon/radeon_drv.h |2 ++
drivers/gpu/drm/radeon/radeon_state.c |3 +++
include/drm/radeon_drm.h |1 +
4 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c b/drivers/gpu/drm/radeon/radeon_cp.c
index d835682..7a52c46 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -406,6 +406,15 @@ static void radeon_init_pipes(drm_radeon_private_t *dev_priv)
{
uint32_t gb_tile_config, gb_pipe_sel = 0;
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV530) {
+ uint32_t z_pipe_sel = RADEON_READ(RV530_GB_PIPE_SELECT2);
+ if ((z_pipe_sel & 3) == 3)
+ dev_priv->num_z_pipes = 2;
+ else
+ dev_priv->num_z_pipes = 1;
+ } else
+ dev_priv->num_z_pipes = 1;
+
/* RS4xx/RS6xx/R4xx/R5xx */
if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R420) {
gb_pipe_sel = RADEON_READ(R400_GB_PIPE_SELECT);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h
index 3933f82..09ce2a2 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -329,6 +329,7 @@ typedef struct drm_radeon_private {
resource_size_t fb_aper_offset;
int num_gb_pipes;
+ int num_z_pipes;
int track_flush;
drm_local_map_t *mmio;
@@ -689,6 +690,7 @@ extern void r600_page_table_cleanup(struct drm_device *dev, struct drm_ati_pciga
/* pipe config regs */
#define R400_GB_PIPE_SELECT 0x402c
+#define RV530_GB_PIPE_SELECT2 0x4124
#define R500_DYN_SCLK_PWMEM_PIPE0x000d /* PLL */
#define R300_GB_TILE_CONFIG 0x4018
# define R300_ENABLE_TILING (1 << 0)
diff --git a/drivers/gpu/drm/radeon/radeon_state.c b/drivers/gpu/drm/radeon/radeon_state.c
index 46645f3..2882f40 100644
--- a/drivers/gpu/drm/radeon/radeon_state.c
+++ b/drivers/gpu/drm/radeon/radeon_state.c
@@ -3081,6 +3081,9 @@ static int radeon_cp_getparam(struct drm_device *dev, void *data, struct drm_fil
case RADEON_PARAM_NUM_GB_PIPES:
value = dev_priv->num_gb_pipes;
break;
+ case RADEON_PARAM_NUM_Z_PIPES:
+ value = dev_priv->num_z_pipes;
+ break;
default:
DRM_DEBUG("Invalid parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index f81c323..42a83c7 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -707,6 +707,7 @@ typedef struct drm_radeon_indirect {
#define RADEON_PARAM_FB_LOCATION 14 /* FB location */
#define RADEON_PARAM_NUM_GB_PIPES 15 /* num GB pipes */
#define RADEON_PARAM_DEVICE_ID 16
+#define RADEON_PARAM_NUM_Z_PIPES 17 /* num Z pipes */
typedef struct drm_radeon_getparam {
int param;
--
1.5.6.3
From 5206d5eeecb9d3edb4f71c6cc700354aa5f94940 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 19 Aug 2009 17:02:45 -0400
Subject: [PATCH] drm/radeon/kms: add GET_PARAM support for Z pipes
Needed for occlusion queries on rv530 chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r300.c |4 +++-
drivers/gpu/drm/radeon/r420.c | 13 -
drivers/gpu/drm/radeon/r520.c |1 -
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_kms.c |3 +++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index c47579d..053f4ec 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -448,6 +448,7 @@ void r300_gpu_init(struct radeon_device *rdev)
/* rv350,rv370,rv380 */
rdev->num_gb_pipes = 1;
}
+ rdev->num_z_pipes = 1;
gb_tile_config = (R300_ENABLE_TILING | R300_TILE_SIZE_16);
switch (rdev->num_gb_pipes) {
case 2:
@@ -486,7 +487,8 @@ void r300_gpu_init(struct radeon_device *rdev)
printk(KERN_WARNING "Failed to wait MC idle while "
"programming pipes. Bad things might happen.\n");
}
- DRM_INFO("radeon: %d pipes initialized.\n", rdev->num_gb_pipes);
+ DRM_INFO("radeon: %d quad pipes, %d Z pipes initialized.\n",
+ rdev->num_gb_pipes, rdev->num_z_pipes);
}
int r300_ga_reset(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index dea497a..223cad0 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -165,7
Re: drm patches for getting proper Z pipes on rv530
And of course, bump the minor number. On Wed, Aug 19, 2009 at 5:07 PM, Alex Deucher wrote: > RV530 cards can have up to 2 Z pipes. You need to check > GB_PIPE_SELECT2 to find out how many are enabled. Mesa would need to > be updated as well. Untested. > > Alex > From 59246da9aa0bbc3801b4c4cdbdf6a4736f6a97a4 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Wed, 19 Aug 2009 17:29:22 -0400 Subject: [PATCH] drm/radeon: bump minor version for Z pipe changes Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_drv.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h index 09ce2a2..6fa32da 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.h +++ b/drivers/gpu/drm/radeon/radeon_drv.h @@ -100,9 +100,10 @@ * 1.28- Add support for VBL on CRTC2 * 1.29- R500 3D cmd buffer support * 1.30- Add support for occlusion queries + * 1.31- Add support for num Z pipes from GET_PARAM */ #define DRIVER_MAJOR 1 -#define DRIVER_MINOR 30 +#define DRIVER_MINOR 31 #define DRIVER_PATCHLEVEL 0 /* -- 1.5.6.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
UPDATED: drm/mesa patches for getting num Z pipes from drm for rv530
Previous drm patches had some problems. Untested.
Alex
From 15562cf73b3d050e82cd9756733106da0f37c1f2 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 19 Aug 2009 19:11:39 -0400
Subject: [PATCH] drm/radeon: add GET_PARAM/INFO support for Z pipes
Needed for occlusion queries on rv530 chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r300.c |4 +++-
drivers/gpu/drm/radeon/r420.c | 13 -
drivers/gpu/drm/radeon/r520.c |1 -
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_cp.c|9 +
drivers/gpu/drm/radeon/radeon_drv.h |5 -
drivers/gpu/drm/radeon/radeon_kms.c |3 +++
drivers/gpu/drm/radeon/radeon_state.c |3 +++
include/drm/radeon_drm.h |2 ++
9 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index c47579d..053f4ec 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -448,6 +448,7 @@ void r300_gpu_init(struct radeon_device *rdev)
/* rv350,rv370,rv380 */
rdev->num_gb_pipes = 1;
}
+ rdev->num_z_pipes = 1;
gb_tile_config = (R300_ENABLE_TILING | R300_TILE_SIZE_16);
switch (rdev->num_gb_pipes) {
case 2:
@@ -486,7 +487,8 @@ void r300_gpu_init(struct radeon_device *rdev)
printk(KERN_WARNING "Failed to wait MC idle while "
"programming pipes. Bad things might happen.\n");
}
- DRM_INFO("radeon: %d pipes initialized.\n", rdev->num_gb_pipes);
+ DRM_INFO("radeon: %d quad pipes, %d Z pipes initialized.\n",
+ rdev->num_gb_pipes, rdev->num_z_pipes);
}
int r300_ga_reset(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index dea497a..223cad0 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -165,7 +165,18 @@ void r420_pipes_init(struct radeon_device *rdev)
printk(KERN_WARNING "Failed to wait GUI idle while "
"programming pipes. Bad things might happen.\n");
}
- DRM_INFO("radeon: %d pipes initialized.\n", rdev->num_gb_pipes);
+
+ if (rdev->family == CHIP_RV530) {
+ tmp = RREG32(0x4124);
+ if ((tmp & 3) == 3)
+ rdev->num_z_pipes = 2;
+ else
+ rdev->num_z_pipes = 1;
+ } else
+ rdev->num_z_pipes = 1;
+
+ DRM_INFO("radeon: %d quad pipes, %d Z pipes initialized.\n",
+ rdev->num_gb_pipes, rdev->num_z_pipes);
}
void r420_gpu_init(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index 09fb0b6..ebd6b0f 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -177,7 +177,6 @@ void r520_gpu_init(struct radeon_device *rdev)
*/
/* workaround for RV530 */
if (rdev->family == CHIP_RV530) {
- WREG32(0x4124, 1);
WREG32(0x4128, 0xFF);
}
r420_pipes_init(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 79ad982..b519fb2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -655,6 +655,7 @@ struct radeon_device {
intusec_timeout;
enum radeon_pll_errata pll_errata;
intnum_gb_pipes;
+ intnum_z_pipes;
intdisp_priority;
/* BIOS */
uint8_t*bios;
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c b/drivers/gpu/drm/radeon/radeon_cp.c
index d835682..7a52c46 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -406,6 +406,15 @@ static void radeon_init_pipes(drm_radeon_private_t *dev_priv)
{
uint32_t gb_tile_config, gb_pipe_sel = 0;
+ if ((dev_priv->flags & RADEON_FAMILY_MASK) == CHIP_RV530) {
+ uint32_t z_pipe_sel = RADEON_READ(RV530_GB_PIPE_SELECT2);
+ if ((z_pipe_sel & 3) == 3)
+ dev_priv->num_z_pipes = 2;
+ else
+ dev_priv->num_z_pipes = 1;
+ } else
+ dev_priv->num_z_pipes = 1;
+
/* RS4xx/RS6xx/R4xx/R5xx */
if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R420) {
gb_pipe_sel = RADEON_READ(R400_GB_PIPE_SELECT);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h
index 3933f82..6fa32da 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -100,9 +100,10 @@
* 1.28- Add support for VBL on CRTC2
* 1.29- R500 3D cmd buffer support
* 1.30- Add support for occlusion queries
+ * 1.31- Add support for num Z pipes from GET_PARAM
*/
#define DRIVER_MAJOR 1
-#define DRIVER_MINOR 30
+#define DRIVER_MINOR 31
#define DRIVER_PATCHLEVEL 0
/*
@@ -329,6 +330,7 @@ typedef struct drm_radeon_private {
resource_size_t fb_aper_offset;
int num_gb_pipes;
+ int num_z_pipes;
int track_flush;
drm_local_map_t *mmio;
@@ -689,6 +691,7 @@ extern void r600_page_table_cleanup(struct drm_device *dev, struct drm_ati_pciga
/* pipe config regs */
#define R400_GB_PIPE_SELE
Re: UPDATED: drm/mesa patches for getting num Z pipes from drm for rv530
On Thu, Aug 20, 2009 at 4:59 AM, Maciej Cencora wrote:
> 2009/8/20 Alex Deucher :
>> Previous drm patches had some problems. Untested.
>>
>> Alex
>>
>> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> --
>> ___
>> Dri-devel mailing list
>> Dri-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>>
>>
>
> I haven't tested these yet, but I have two comments:
> - please set default num_z_pipes to 2 when dri.minor < 31 (using
> rv530_emit_query_finish_single_z on non-KMS seems to trigger GPU hang
> on my 2 pipe RV535, and using rv530_emit_query_finish_double_z on
> single Z pipe card results in incorrect values - as Dave has
> reported),
> - r300 variable is unused in rv530_emit_query_finish_double_z function.
Updated.
Alex
From c784772c0c1360211b5ef546e4552b4e19d22f5e Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Thu, 20 Aug 2009 10:56:35 -0400
Subject: [PATCH] r300: add support for getting Z pipe info from drm
Needed for occulsion queries on rv530 chips
Signed-off-by: Alex Deucher
---
src/mesa/drivers/dri/r300/r300_context.c | 24 +++-
src/mesa/drivers/dri/r300/r300_context.h |1 -
src/mesa/drivers/dri/radeon/radeon_bocs_wrapper.h |8 +++
src/mesa/drivers/dri/radeon/radeon_screen.c | 18 +++
src/mesa/drivers/dri/radeon/radeon_screen.h |1 +
5 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/r300/r300_context.c b/src/mesa/drivers/dri/r300/r300_context.c
index ca8021d..6f7f577 100644
--- a/src/mesa/drivers/dri/r300/r300_context.c
+++ b/src/mesa/drivers/dri/r300/r300_context.c
@@ -239,8 +239,8 @@ static void r300_emit_query_finish(radeonContextPtr radeon)
struct radeon_query_object *query = radeon->query.current;
BATCH_LOCALS(radeon);
- BEGIN_BATCH_NO_AUTOSTATE(3 * 2 *r300->num_z_pipes + 2);
- switch (r300->num_z_pipes) {
+ BEGIN_BATCH_NO_AUTOSTATE(3 * 2 *r300->radeon.radeonScreen->num_gb_pipes + 2);
+ switch (r300->radeon.radeonScreen->num_gb_pipes) {
case 4:
OUT_BATCH_REGVAL(R300_SU_REG_DEST, R300_RASTER_PIPE_SELECT_3);
OUT_BATCH_REGSEQ(R300_ZB_ZPASS_ADDR, 1);
@@ -266,7 +266,7 @@ static void r300_emit_query_finish(radeonContextPtr radeon)
}
OUT_BATCH_REGVAL(R300_SU_REG_DEST, R300_RASTER_PIPE_SELECT_ALL);
END_BATCH();
- query->curr_offset += r300->num_z_pipes * sizeof(uint32_t);
+ query->curr_offset += r300->radeon.radeonScreen->num_gb_pipes * sizeof(uint32_t);
assert(query->curr_offset < RADEON_QUERY_PAGE_SIZE);
query->emitted_begin = GL_FALSE;
}
@@ -288,10 +288,8 @@ static void rv530_emit_query_finish_single_z(radeonContextPtr radeon)
query->emitted_begin = GL_FALSE;
}
-#if 0
static void rv530_emit_query_finish_double_z(radeonContextPtr radeon)
{
- r300ContextPtr r300 = (r300ContextPtr)radeon;
BATCH_LOCALS(radeon);
struct radeon_query_object *query = radeon->query.current;
@@ -309,7 +307,6 @@ static void rv530_emit_query_finish_double_z(radeonContextPtr radeon)
assert(query->curr_offset < RADEON_QUERY_PAGE_SIZE);
query->emitted_begin = GL_FALSE;
}
-#endif
static void r300_init_vtbl(radeonContextPtr radeon)
{
@@ -319,11 +316,12 @@ static void r300_init_vtbl(radeonContextPtr radeon)
radeon->vtbl.swtcl_flush = r300_swtcl_flush;
radeon->vtbl.pre_emit_atoms = r300_vtbl_pre_emit_atoms;
radeon->vtbl.fallback = r300_fallback;
- if (radeon->radeonScreen->chip_family == CHIP_FAMILY_RV530)
- /* single Z gives me correct results on my hw need to check if we ever need
- * double z */
- radeon->vtbl.emit_query_finish = rv530_emit_query_finish_single_z;
- else
+ if (radeon->radeonScreen->chip_family == CHIP_FAMILY_RV530) {
+ if (radeon->radeonScreen->num_z_pipes == 2)
+ radeon->vtbl.emit_query_finish = rv530_emit_query_finish_double_z;
+ else
+ radeon->vtbl.emit_query_finish = rv530_emit_query_finish_single_z;
+ } else
radeon->vtbl.emit_query_finish = r300_emit_query_finish;
}
@@ -397,10 +395,6 @@ static void r300InitConstValues(GLcontext *ctx, radeonScreenPtr screen)
ctx->Const.FragmentProgram.MaxNativeAddressRegs = 0;
}
- if (r300->radeon.radeonScreen->chip_family == CHIP_FAMILY_RV530)
- r300->num_z_pipes = 2;
- else
- r300->num_z_pipes = r300->radeon.radeonScreen->num_gb_pipes;
}
static void r300ParseOptions(r300ContextPtr r300, radeonScreenPtr screen)
diff --git a/src/
Re: [PATCH 3/3] radeon: Use request_firmware()
On Wed, Aug 26, 2009 at 9:07 PM, Dave Airlie wrote:
> On Mon, Aug 24, 2009 at 3:58 AM, Ben Hutchings wrote:
>> Based on a patch by Jaswinder Singh Rajput . For Radeon 100- to 500-series,
>> firmware blobs look like:
>> struct { __be32 datah; __be32 datal; } cp_ucode[256];
>>For Radeon 600-series, firmware blobs look like:
>>__be32 pm4_ucode[PM4_UCODE_SIZE * 3];
>> __be32 pfp_ucode[PFP_UCODE_SIZE];
>>For Radeon 700-series, firmware blobs look like:
>>__be32 pm4_ucode[R700_PM4_UCODE_SIZE];
>> __be32 pfp_ucode[R700_PFP_UCODE_SIZE];
>>Signed-off-by: Ben Hutchings --- This has been tested in Debian as a patch to
>>2.6.30. Ben.
>
> Something annoyed my reply formatting, but anyhoo, the mga and r128
> patches are fine.
>
> This patch has a few issues before I can put it into drm-next.
>
> 1. r600/r700 firmware probably should be split into two files, we have
> more firmware
> releases coming for another part of the chip, and I'm not sure how we can
> handle
> merging or versioning if we put all 3 into one blob. Maybe Alex can comment on
> AMDs preferred format.
I'll be easier to keep the various firmwares separate for r6xx/r7xx.
So that means separate files for the CP and the PFP microcode. If you
can split it up that way it would be much appreciated.
Thanks,
Alex
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] i830 and SiS 3D Drivers
I'm not sure they are the "official" maintainers, but as far as I recall, Thomas Winischhofer has done a lot with Sis and DRI, etc. (like make the driver actually work) (http://www.webit.com/tw/linuxsis630.shtml), and Matthew Sottek has done much of the work for i810/830. Alex - FROM: Alan Hourihane DATE: 04/03/2002 04:41:38 SUBJECT: RE: [Dri-devel] i830 and SiS 3D Drivers On Tue, Apr 02, 2002 at 08:01:04 -0700, Jens Owen wrote: > Just FYI. > > I noticed the i830 and SiS 3D drivers are not being built on the trunk. > If they aren't supported enough to have them on by default, then I'll > skip converting them to the new drmCommand interface. If they are ever > supported, the maintainer can make the updates. > The i830 and SiS drivers haven't been ported to Mesa 4.x - unfortunately. I can see these two starting to lag as there isn't a maintainer as far as I know. Alan. __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] OT: S3 Savage utah-glx XF 4.x driver working
I just saw over at the utah-glx project that the S3 savage 3D driver is working with XF 4.x. It's not DRI, but for those who are interested, I thought I'd point it out... maybe a good start for those looking to port to the DRI. Alex __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SiS Specifications
I don't think the docs are much help with regard to 3D. there actually is a working sis DRI driver for 300 series chips that can be found here: http://www.winischhofer.net/linuxsis630.shtml perhaps it could be synced up to the current DRI tree. Alex Might want to post this on the site somewhere - appears that utah-glx has posted specs for some SiS chipsets (300 & 630). http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download -Al __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Xv and OpenGL -- new module idea
I'm pretty unfamiliar with OpenGL programming. I have an idea for an xfree module that I suspect would not be too hard to implement, but I wanted to get some other opinions on it. What I'd like to do is create a module called perhaps ogl-xv or glx-xv that would provide a generic Xv adapter on the front end and on the back end would implement it using openGL calls to basically create an RGB or YUV texture to render the video to. this would have the advantage of acceleration on cards with accelerated 3D, and would provide generic Xv support to cards lacking an overlay engine by using SW mesa, and it could provide for more than one Xv adapter, so you could theoretically have more than one Xv at a time. Alex __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Xv and OpenGL -- new module idea
On Mon, 2002-09-30 at 22:14, Alex Deucher wrote: > I'm pretty unfamiliar with OpenGL programming. I have an idea for an > xfree module that I suspect would not be too hard to implement, but I > wanted to get some other opinions on it. What I'd like to do is create > a module called perhaps ogl-xv or glx-xv that would provide a generic > Xv adapter on the front end and on the back end would implement it > using openGL calls to basically create an RGB or YUV texture to render > the video to. One problem I see is that the X server currently can't use 3D acceleration with the DRI; that would also be a way to achieve accelerated indirect rendering, so it would definitely be a worthwhile project though. Unless I'm missing something, couldn't the module just be an openGL client? I've been looking at the v4l Xv module. I was envisioning a solution where I would just adapt the existing module and replace the hardware specific code with OpenGL code to create a texture for the video to render to. in that sense the module would just be either a DRI client (if it was available) or a Mesa client if the actual X server didn't support DRI. or perhaps I've just way off... > this would have the advantage of acceleration on cards with accelerated > 3D, and would provide generic Xv support to cards lacking an overlay > engine by using SW mesa, But that might be slower than not using Xv at all. > and it could provide for more than one Xv adapter, so you could > theoretically have more than one Xv at a time. That would certainly be nice, although one adapter seems to be enough usually. yeah usually, but another use for the second head of a dual head card. it'd be nice to have Xv on the second head. __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Xv and OpenGL -- new module idea
yeah xawtv has an opengl plugin as well. I'll take a look if I ever get a chance to. thanks for the suggestion. Alex --- Stefan Lange <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > I'm pretty unfamiliar with OpenGL programming. I have an idea for > an > > xfree module that I suspect would not be too hard to implement, but > I > > wanted to get some other opinions on it. What I'd like to do is > create > > a module called perhaps ogl-xv or glx-xv that would provide a > generic > > Xv adapter on the front end and on the back end would implement it > > using openGL calls to basically create an RGB or YUV texture to > render > > the video to. this would have the advantage of acceleration on > cards > > with accelerated 3D, and would provide generic Xv support to cards > > lacking an overlay engine by using SW mesa, and it could provide > for > > more than one Xv adapter, so you could theoretically have more than > one > > Xv at a time. > > > > Disclaimer: I'm _not_ a programmer, and I don't know anything about > GL > or XV, so this is merely a blind guess: > > you might want to look at the code of mplayer's -vo gl and -vo gl2, > which provide opengl-video-overlays, to get started > > regards > Stefan > > > > > Alex > > > __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Xpert]Savage and nVidia DRI drivers
I'd be interested in helping out with the savage work. I don't know much about the DRI, but I can help test. I'm actually working (slowly) on adding dual head (duoview) support to the savage driver for the mobile savages. I've started on the code, but I've been so busy lately that I've had no time to do much with it. I'd like to do the dual head support so that each head was just a view port into a single frame buffer, but there is no example code for this in any other X driver (I've modeled it after the radeon and mga drivers); doing this would allow for DRI on both heads. As an added bonus, the savage chips have 2 video scalers so each head could theoretically have Xv support. just my 2 cents. Alex I've just started two branches on DRI CVS, savage-0-0-1-branch and nv-0-0-1-branch, for the development of drivers for the Savage chips (in particular the Savage4) and the older nVidia chips (such as the Riva TNT Vanta). Both these cards are very old by now and the interest of a DRI driver diminishes every day - including mine -, so I've decided that it should be now or never. I chose now, even though my PhD is demanding more and more time from me. This endeavor has no time plan. Actually my main interest is the learning experience of making a DRI driver from ground up - experience which I plan to share by writing a thorough HOWTO describing the steps and explaining the working of a driver from the high-level structure to the low-level implementation details. (You already can see the very first writings on http://dri.sf.net/doc/howto/) I have the Savage4 specifications (BCI documentation still missing), not thanks to S3 of whom I'm waiting for a final answer until today. I don't have any documentation from nVidia - I confess I haven't contact them yet but the impression I have is that no documentation is made available. There is support for both these chips in the Utah-GLX project. Also the proprietary nVidia Linux drivers come with some source code (which was also the basis for the Utah-GLX drivers). The plan is to: 1. Make the existing 2D drivers DRI aware. 2. Make a simple DRM which dispatches buffers to the card trhough MMIO 3. Make the Mesa driver, hopefully reusing some of the Utah-GLX code (but probably 4. Implement proper DMA in the kernel. The nVidia driver will follow the Savage a little from behind to avoid making the same mistakes twice. In the beginning it will be mainly coding - I won't make any debugging with the cards myself until the Mach64 is finished and in the trunk (hopefully it won't take long, but it's not done yet). People which are interested in having these drivers see the light of day (I know that the Savage chip is common on laptops and AFAIK there no nVidia proprietary drivers for non-Linux non-x86 platforms) are surely welcome to help, as they can turn this small project of mine in something definite. I know that Max Lingua has better documentation for the Savage4 than I and he even has the beginnings of a driver but long time I don't hear from him, and I already had asked him to commit whatever he had to cvs much before with no answer to that. José Fonseca __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: xfree86, DRI, and multiple heads: thoughts and ideas
--- Ian Romanick <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > --- Ian Romanick <[EMAIL PROTECTED]> wrote: > >> > > Close, but not quite exactly. The goal would be to modify the > interface > between libglx.a (the part that handles the high-level GLX protocol > stuff) and libGLcore.a (the part that does the drawing) to be the > same > as the interface between libGL and the client-side DRI driver. Then > a > "client-side" DRI driver would be loaded instead of libGLcore.a. > That > wouldn't change any of the issues in the client-side driver with > buffer > locations changing. Ok I've started taking a look at this, unfortunately, I can't seem to find where libGL and GLCore live in the course tree. According to the FAQ: "The GLcore extension source code resides at xc/programs/Xserver/GL/mesa/src/ . " and, "3.3.2. Where does libGL reside? The GLcore extension source code resides at xc/lib/GL/GL/ . " However, the directories seems to be empty. I remember some talk a while back about changing the tree around, but I didn't think that actually happened. Anyway, if someone would be so kind as to point me in the right direction I'd appreciate it. and just to double check, DRI aware drivers live here: xc/lib/GL/mesa/src/drv glx lives here: xc/lib/GL/glx/ how do these files relate: xc/programs/Xserver/GL/mesa/src/X/ Also, in regards to 3D with xinerama, I have an idea. if we can get HW indirect rendering 3D working on indepenant heads, one could run dmx (dmx.sf.net) and use glproxy to get xinerama working. (can't seem to access sourceforge ATM). it's not optimal, but it's an interim solution. thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Savage Driver status
XvMC is an extension for Xvideo that does things like motion compensation and iDCT in hardware. I'm not sure if that has anything to do with your problem. Also I'm not sure if the savage mx/ix cards even have hw motion comp, etc. that might have been added in the savage4 and 2000 cores. regardless, it seems to be disabled due to lack of memory. a few other users have S3's driver working on on 4.2.0. read more here: http://probo.probo.com/pipermail/savage40/2003-July/date.html I have a savage/IX laptop, but someone is borrowing it at the moment so I don't have access to it, otherwise I'd help out with the driver. Alex --- Maximo <[EMAIL PROTECTED]> wrote: > Rick, > > I'm currently working on savage driver to make it work on > xfree86 > 4.3.0 but i didn't test it on xfree86 4.2.0 i only know that it > compiles on > that version. Looking at your log i found this message: > (--) SAVAGEInitMC: There is no enough memory! > (**) SAVAGE(0): XvMC is not enabled > > It's probably here where your problem lies. does your card has enough > > memory? People here probably will give you an better explanation than > i, so > i'll let them explain. > > bye. > Maximo > At 06:28 AM 30/8/2003, Rick Harris wrote: > >Hi all, > > > >Just a quick note to put the feelers out on how the S3 Savage DRI > Driver > >is coming along. > > > >Am particularly interested in getting this to work on a Savage/IX-MV > >chipset (M7 BIOS) found in many older laptops. > > > >These are my experiences thus far using the S3.zip package from > >http://www.linux.org.uk/~alan/S3.zip > > > >All drivers compile/install fine using 4.2.0 XFree source, 2.4.21 > >Kernel, 2.95.3 Gcc after editing the file > >xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/savage_drv.c > >and force it to use the do_munmap function that only takes 2 > >parameters not 3 (by commenting out #ifdef) > >AND > >running dos2unix on the source files in > >xc/programs/Xserver/hw/xfree86/drivers/savage/ > > > >No editing pte_offset to pte_offset_kernel was required. > > > >Nothing new there, it's all in this list's archives, but here comes > the > >juicy part. > > > > > >After starting X, it gives the errors: > >(EE) SAVAGE(0): DRI isn't enabled > >(EE) SAVAGE(0): Direct rendering disabled > > > >An 'lsmod' while X was running indicated that the savage.o DRM > kernel > >module isn't being used: > >Module SizeUsed by Not tainted > >savage 45312 0 > >agpgart 16048 1 > > > >A 'glxinfo' confirms this: > >direct rendering: No > > > >Looking at the lines 773 to 778 in > >/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c > >It seems that if the Chipset used isn't either a S3_TWISTER or an > >S3_PROSAVAGE, then DRI is disabled. > >Deleting lines 773-774 & 777-778 bypassed the check & DRI is now > forced. > > > >startx > > > >The desktop is garbled, only the bottom inch of it is visible, & has > >been re-located to the top of the screen. Below this is just > blackness, > >like the whole screen has been shifted upwards. > >Here is a pic of what the garbledness looks like, you can see the > whole > >desktop in this picture however -> > >http://mightylegends.zapto.org/downloads/S3_driver/root.jpeg > >Switching to a console VT & then back to X fixes the problem. > > > >The previous '(EE) DRI disabled' errors have disappeared to be > replaced > >with one new one: > >(EE) SAVAGE(0): Memory manager initialization to (0,0) (1024,-1) > failed. > > > >Running 'glxgears' kills X with the error: > >X connection to :0.0 broken (explicit kill or server shutdown) > >xterm: fatal IO error 32 (Broken pipe) or KillClient on X server > ":0.0" > >login: fatal IO error 32 (Broken pipe) or KillClient on X server > ":0.0" > >xterm: fatal IO error 32 (Broken pipe) or KillClient on X server > ":0.0" > >xinit: fatal IO error 32 (Broken pipe) or KillClient on X server > ":0.0" > > > > > >This is where I've hit a wall on what it could be, or how in heck I > go > >about debugging it. Maybe problems within > >/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_accel.c > >where X's Memory Manager appears to be set-up, or something further > up > >the chain. > > > >I'd be willing to hear from anyone who has come up against this, can > >help, or of similar works to get DRI supported under IX-MV chipsets. > >Do let me know if I maybe going completely the wrong way about this. > > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Faster transfer to video memory
--- Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Sat, 2003-08-30 at 13:06, Jouni Tulkki wrote: > > Is there a way to make moving images and textures to video memory > faster? > > Currently I'm using Radeon 9500 Pro and AGP 8x. > > Curious, how do use AGP without the DRI being enabled? :) (And how 8x > when the X server only supports up to 4x yet? :) I saw on dri-patches that someone (keith?) added 8x support to CVS a few weeks back. radeon rv280 cards support 8x. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 2 questions about radeon driver
I have two questions for you about the radeon driver. the first relates to the CP and accel. I'm attempting to convert the Xv code to use the CP. how do you check to find out if the driver is using CP or MMIO accel? I considered using info->directRenderingEnabled, but as far as I can see the radeon can use the CP for accel even if the DRI is disabled. It's probably obvious, I'm just missing it. secondly, is there a way we could switch to software rendering if the total width or height of or all rendering windows is larger than 2048? Since we seem to be hw limited by that, it'd be nice if the driver would just switch to software after 2048 rather than just showing a blank window or in some cases locking up the video card. It might be too much of a pain in the butt though... thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] svideo output scrambled
the open source radeon Xfree drivers do not support tv out yet. You might check with the GATOS people (http://gatos.sf.net). it works in the console because the BIOS is driving the outputs rather than the driver. Alex --- Chris Ison <[EMAIL PROTECTED]> wrote: > I'm wondering if there is a way to easily correct the svideo output > in > the radeon driver (r200). Its currently "out of sync" and flickers > badly, but it does try to display something. It works fine for linux > consoles. Windows has the svideo output set to 50Hz if thats of any > help. > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] High-resolution monitors (T221)
Linus, Some dell OEM radeon cards offered Dual DVI ports and I believe there are some other oems (tyan?) that will be offering Dual DVI cards. the radeon 9000s and newer only have one tdms trandsmitter built in, but an additional external one can be added on to drive the second DVI port. for multi-head 3D on radeon hardware, check out my mergedfb patch: http://bugs.xfree86.org/show_bug.cgi?id=276 Unfortunately, due to a hardware limitation with the scissor registers, you are limited to 2048x2048 for 3D. your framebuffer can be as large as 8192x8192 (limits for the 2D engine). you can use mergedfb at resolutions higher than 2048x2048, however, any 3D windows larger than 2048x2048 will not display. Alex --- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > Ok, this is pretty off-topic, but I'm wondering what the status is > for > open-source support of 3D-capable drivers for such studly monitors as > the > IBM T221. > > Yes, it's still expensive as hell, but it isn't nearly as bad as it > was a > few years ago when it was very limited availability, and cost USD > $20k+. > These days it is "only" $9k or so and apparently is actually > available in > the sales channel. > > The thing is a 3840x2400 pixel monster, and to drive it at reasonable > frequencies you actually need to support a quad DVI setup where it > looks > basically like four monitors running at 1920x1200. And from what I > can > gather by googling, the outputs need to be synchronized, so you > really > need to have a card like the NVidia Quadro4 XGL or similar (ie you > can > apparetly _not_ drive it with multiple separate video cards). > > Apparently it also does work with just a single DVI thing (ie reports > of > it working with the Radeon 8500 at least on macs), probably at a much > reduced frequency (ie a single DVI link should be able to drive the > thing > at something like 10Hz refresh rate - I think the Radeon 8500 > supports two > links on its single DVI-I interface, so should get up to 20Hz?). > > The binary-only NVidia driver supports it at the full 40Hz frequency, > so I > know I can get the thing to work under Linux in case I decide to > waste the > money on it (or, preferably, convince my employer to do so ;) > > However, I was wondering if anybody knows of somebody using it with > proper > opensource drivers.. Or is just otherwise confident for some > technical > reason that it should work.. > > I'd want 3D acceleration to work, but I don't care if it ends up > being > limited to smaller areas (ie if the canvas size has to be limited to > 2048x1536 or something, who cares?). > > Damn, but it's a drool-inducing piece of hardware. > > Linus > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Xv on i830 broken?
I think it worked in the past, but I think something got broken recently. I've seen several reports of it being broken recently on the xfree MLs. there are some bugs for it on xfree bugzilla. Alex --- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > Is Xv output supposed to work on i830-based setups? I seem to get > just a > blue overlay when I try using mplayer or similar. Normal shm-X11 > works > fine, but both Xv and SDL do not (SDL will try to use Xv - but I > checked > it just in case it was an mplayer Xv usage bug. I can't imagine that > both > the native mplayer Xv filter _and_ the SDL code is broken, so I > assume > it's the X server itself). > > Linus > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
An card from the 300 series sis cards should work: 300, 305, 540, 630/S/ST, 730 Alex --- Martin Spott <[EMAIL PROTECTED]> wrote: > Eric Anholt <[EMAIL PROTECTED]> wrote: > > > If anyone wants to test, [...] > > Which video card would you recommend for trying ? I'd see if I can > get > one, > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends > are ! > -- > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI and Silicon Motion
This is probably better asked on dri-devel (cc:ed). --- Cheshire Cat Fish <[EMAIL PROTECTED]> wrote: > I am investigating supporting DRI and OpenGL for the Silicon Motion > driver. > I'm new to both of those, so some of these may be newbie sounding > questions. > > 1) I have the OpenGL code from the Windows 2000 Silicon Motion > driver. Can > this code be mostly used "as is"? Or will the Linux code be entirely > > different? How did you obtain this code? If it was not under an agreement with SMI, then it probably won't be included the DRI for legal reasons. I've never programmed for windows, but I'd imagine their Direct rendering API and that of the DRI are pretty different. Still, the source would be a good guide for development. Basically you would want to create a new driver modeled after an existing DRI driver, then fill in support for the hw using the windows driver as a reference. You also have to make the 2D driver DRI aware. > > 2) In the DRI Users Guide, section 3.2-Graphics Hardware, Silicon > Motion is > not listed as currently being supported. Is this still the case? Is > anyone > working on this? Or am I starting from scratch? SMI hardware is currently not supported and no one is actively working on it yet. > > 3) How big of a task am I looking at here? Since I alrady have the > Win2k OGL > code to base my work on, it seems to me it shouldn't be too hard to > drop > that code in and hook it up to DRI. A few weeks maybe? Or am I > missing > something fundamental? > It's a pretty big task. To start off, I recommend reading the DRI FAQ: http://dri.sourceforge.net/doc/faq/ This will give you a better understanding of how the DRI works. Good Luck, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: [Dri-devel] Rage128 and Radeon patches
I haven't tried multiple radeon cards, but I seem to recall several people having this problem right around when 4.3.0 was released. I don't think a "proper" fix ever went in and I think the issue was to be revisited later. I don't know if it's needed anymore or not. Alex --- Jon Smirl <[EMAIL PROTECTED]> wrote: > --- Alex Deucher <[EMAIL PROTECTED]> wrote: > > > 2) access ROM directly instead of relying on copy > > > in low RAM. This allows multiple cards. Required > > > MPP_TB_CONFIG fix in driver. > > > > Is this patch necessary for xfree86? It may address > > some of the issues > > in the email threads I sent out yesterday (ie, > > problems with multiple > > radeon cards and xfree86). if so would you consider > > making one? > > > > Xfree code does not have the patch, but is Xfree > experiencing the bug? Xfree accesses the hardware very > differently than the framebuffer drivers. > > I suspect that you would see this problem if you were > using something else for your primary video and a > Radeon for secondary. The first time you ran Xfree it > would work. But when you exited and restarted Xfree it > would hang when starting the secondary display. > > Where does XFree reset the secondary card? The code > below needs to run right after the reset in the radeon > driver. I added it to my Rage128 driver too but I have > not observed the problem with them. > > Framebuffer code is different and triggers the bug the > first time the secondary display is accessed. > > /* Fix from ATI for problem with Radeon hardware not > leaving ROM enabled */ > unsigned int temp; > temp = INREG(RADEON_MPP_TB_CONFIG); > temp &= 0x00ffu; > temp |= 0x04 << 24; > OUTREG(RADEON_MPP_TB_CONFIG, temp); > temp = INREG(RADEON_MPP_TB_CONFIG); > > > = > Jon Smirl > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] xfree86, DRI, and multiple heads: thoughts and ideas
Dualhead... Right now there is dualhead support for the following cards in xfree86: radeon matrox sis via chips 3dlabs (Sven mentioned that he had this quasi-working on the newer cards, although I don't know the state of his driver) The following cards have hw dualhead support, but no driver support for it: i830/845 mach64 rage128 savage trident smi I don't suppose there is much interest in adding dualhead support for these cards. Is there anything in the pipeline? I've studied the other dualhead drivers pretty extensively, and I think I could provide a generic dualhead capable skeleton driver and a howto document. Would anyone find this to be a benefit? perhaps to be included in xfree for future driver writers? Are databooks for any of these cards readily available anywhere? I might be willing to try my hand at this again if I could get databooks. Next, mergedfb... I've been thinking about creating generic xfree support functions to replace the chipset specific ones for mergedfb. This would make it easier to add mergedfb to other chipsets that support dualhead. Where should this live? also, as far as pseudo-xinerama, should that be made part of the generic mergedfb code or part of xinerama proper? i.e., to extend xinerama to handle both multi-card and single card xinerama. Or is all of this going to be refactored in xfree 5? multihead and DRI... There's been some recent work in the DRI tree to track GLX extension state per screen (http://marc.theaimsgroup.com/?l=dri-patches&m=106123210307564&w=2). What other things need to happen to get the DRI working on multiple graphics cards? On a related note, I've been thinking about alternative ways to implement mergedfb on radeon hardware. what if instead of creating a single framebuffer with two viewports, we stuck with the old style pScrn based multi-head code, but made each head a client of the DRI? the 3D engine would be shared by each head. This seems to be the way the 2D engine works in pScrn based multi-head now. I can see this working ok for independant heads, but what about when using xinerama? what would need to be done in that case? perhaps glxproxy from dmx (dmx.sf.net) would be of use in this case. would doing this potentially get around the issues with the scissor registers limiting us to 2048x2048 for 3D? I could see potential issues with 3D windows that spanned heads since they would be trading access to the hardware back and forth. Thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage128 and Radeon patches
--- Jon Smirl <[EMAIL PROTECTED]> wrote: > Hopefully these is the last versions. They implement: > 1) add every know PCI ID > 2) access ROM directly instead of relying on copy in > low RAM. This allows multiple cards. Required > MPP_TB_CONFIG fix in driver. Is this patch necessary for xfree86? It may address some of the issues in the email threads I sent out yesterday (ie, problems with multiple radeon cards and xfree86). if so would you consider making one? Alex > 3) implemented kernel 2.6 module parameters > 4) Cleaned up error paths and made sure resources are > released on errors. Both build without compiler > warnings now. You can ins/rm mod multiple times > without problem. Just don't do it from a window in > your X server. > 5) Driver marks both primary and secondary devices as > being in use. > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
There aren't really any major brands that make sis cards that I've heard of... usually they are sold labeled as "3D video card" or "Super VGA card" with no discernable manufacturer on the box. some older oem notebooks (clevos and such) use 630 chips; Sony made slim desktops (LX-700/800/900) for a while with 630s as well. you can still find 300/305 PCI/AGP cards on some websites usually labeled as "sis 305 32mb" or similar. Alex --- Martin Spott <[EMAIL PROTECTED]> wrote: > Alex Deucher <[EMAIL PROTECTED]> wrote: > >> Eric Anholt <[EMAIL PROTECTED]> wrote: > >> > >> > If anyone wants to test, [...] > >> > >> Which video card would you recommend for trying ? I'd see if I can > >> get one, > >> > > An card from the 300 series sis cards should work: > > > 300, 305, 540, 630/S/ST, 730 > > On SiS' website they only talk about the chips themselves. Would > anyone > suggest an AGP card that applies or does this fall under unwanted > commercial promotion ? > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends > are ! > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Weekly IRC meeting - 3dlabs and savage
from the log: To do that we're going to "port" the *OLD* 500TX driver to DRI. :) 500tx is a what? anholt: The GLINT before the MX. ... anholt: It should be *much* faster. The Delta does all the geometry setup. This is the mode the current gamma driver uses. hmm Part of this work may lead into making some updates to the gamma driver. Does anyone have *any* docs for any of the GLINT chips? Even the old leaked TI docs for the Permedia2 would be helpful. :) Sven Luther did some DRI work a while back for permedia/2/3 and he is currently working on a 2D driver for the new wildcat VP cards. I think 3dlabs is pretty good about giving databooks out to developers, at least they used to be. You might just want to ask them. Also there is the tdlabs-0-0-1-branch branch in cvs http://www.geocrawler.com/archives/3/680/2002/8/0/9462918/ http://www.mail-archive.com/[EMAIL PROTECTED]/msg08196.html and, from the log: fxkuehl: I have a Savage/IX (or something similar) in my ThinkPad T21. ... so is the savage4 the same sort of thing as a savage mx/ix? ... anholt: I believe so. Actually the savage mx/ix chips are based on the old savage3D core, while the DRI driver is for savage4/prosavage cores. I don't know how similar they are and whether the driver S3/VIA released will work on the older savage3D based chips like the mx or ix. they might need a separate driver much like the radeon r100 vs. r200. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
315 is NOT from the 300 series! it will NOT work! that is the new series from sis and has a new core. Check out Thomas' page for more info: http://www.winischhofer.net/linuxsisvga.shtml from the page: "There are currently four groups of SiS VGA controllers: * The old series (5597/5598, 6326/AGP/DVD, 530, 620), * the 300 series (300, 540, 630/S/ST, 730), * the 315 series (315/E/H/PRO, 550, 650, 651, M650, 740, 661FX, M661FX, 741), and * the Xabre series (330)." Alex --- Martin Spott <[EMAIL PROTECTED]> wrote: > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > [...] you can still find > > 300/305 PCI/AGP cards on some websites usually labeled as "sis 305 > > 32mb" or similar. > > Thanks for explaining. I assume I found a card with an SiS 315. > I'll see if it works, otherwise I'll give it to a friend running > Windows ;-) > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends > are ! > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Weekly IRC meeting - 3dlabs and savage
The 2D driver supports all savage chips, but the 3D driver seems to
only support the Prosavage and Twister (savage4 core) integrated chips:
from savage_driver.c:
if ((psav->Chipset == S3_TWISTER)
|| (psav->Chipset == S3_PROSAVAGE)) {
/* Setup DRI after visuals have been established */
psav->directRenderingEnabled = SAVAGEDRIScreenInit(pScreen);
} else
psav->directRenderingEnabled = FALSE;
I don't know how different the savage3D and savage4 cores are. There
may also be some issues with shared vs. discrete video ram.
Alex
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> >
> > Actually the savage mx/ix chips are based on the old savage3D core,
> > while the DRI driver is for savage4/prosavage cores. I don't know
> how
> > similar they are and whether the driver S3/VIA released will work
> on
> > the older savage3D based chips like the mx or ix. they might need
> a
> > separate driver much like the radeon r100 vs. r200.
>
> Alan Cox in a previous email said the savage driver from S3 was for:
> Savage MX/IX/ SuperSavage/ ProSavage/ Twister/K
>
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Weekly IRC meeting - 3dlabs and savage
--- Ian Romanick <[EMAIL PROTECTED]> wrote: > I'm aware of Sven's work, and I have been in contact with him. I > haven't persued getting docs form 3dlabs yet, but I may do so in the > future. IBM's lawyers are *VERY* picky, so getting docs under NDA > for > use in open-source projects is *VERY* difficult for IBMers. I still > don't have R100 or R200 docs, and I've been working on those drivers > for > over a year and a half. :( Bummer. > > > fxkuehl: I have a Savage/IX (or something similar) in my > ThinkPad > > T21. > > ... > > so is the savage4 the same sort of thing as a savage > mx/ix? > > ... > > anholt: I believe so. > > > > Actually the savage mx/ix chips are based on the old savage3D core, > > while the DRI driver is for savage4/prosavage cores. I don't know > how > > similar they are and whether the driver S3/VIA released will work > on > > the older savage3D based chips like the mx or ix. they might need > a > > separate driver much like the radeon r100 vs. r200. > > Are you sure about that? Once-upon-a-time I tried to get the old > Utah-GLX driver to work on it but had no luck at all. I was still > pretty green back then, but it didn't seem like the chips were very > compatible. The chip that I have, according to WinS3ID is "Savage/IX > > w/MV (294)". The chip ID is 0x8c12, subvendor 0x1014, subdevice > 0x017f. > This same chip is in all the IBM T20 & T21 laptops AFAIK. > > It's interesting that there's not even 3D acceleration for this > particular chip in Windows. That would be a nice open-source coup. > :) I'm agreeing with you :) I don't think the cores are compatible. The savage driver in utah-glx was for the savage3D, mx, ix. it did not support the savage4 core (as I recall). If you read the utah-glx archives, some of the current develpers have it running on a savage ix. the S3/VIA driver seems to only support the savage 4 core. If we ever get the DRI working on savage we'll probably have to pull from both (utah and S3) to get it working. I have a thinkpad t20 with a savage IX, and there was an opengl ICD for windows. It tried quake3, but it was real slow and crashed with in a few seconds. > > In any case, I would really *NOT* like to see another driver end up > like > the r100 / r200 driver. The MGA driver, where multiple chips in the > same family are supported by the same binary, is a much better model > to Is it worth trying to merged the two (down the road), or just leave them alone? > follow, IMHO. My plan with the 500TX driver is to eventually merge > it > with the gamma driver and re-name that driver to glint. gamma is a > very > bad name for that driver since the gamma isn't even really used! > Looking at the existing 500TX code, the existing gamma code, and > Sven's > work in the tdlabs branch, it seems like the drivers for all the > chips > in the GLINT family should be quite similar. That family may be the > poster child for a unified driver architecture. :) Sounds good! I can't wait! Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri.freedesktop.org webcvs view?
Is there a web based CVS viewer on freedesktop.org like there is on xfree86 or sourceforge? I personally find it useful when I don't have access to my PC. it's also nice for reference. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Weekly IRC meeting - 3dlabs and savage
The r100 and r200 of course. :) Alex --- Ian Romanick <[EMAIL PROTECTED]> wrote: > > Merge which? The r100 & r200 or the 500TX & gamma? I think it would > be > a good idea to merge both, but "merging" the GLINT drivers will be > much > easier (since one of them hasn't been created yet!). How many times > has > the same bug been fixed in the r200 driver, then discovered and fixed > in > the r100 driver a week later? That just makes us look bad. > > > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
looks like the post size limit ate my first attempt to post this. Anyway, I was finally able to access DRI cvs (from dri.freedesktop.org), so I pulled the latest tree and created a radeon mergedfb patch against it. I've done some testing and it seems to work fine. The patch only touches the 2D driver. I talked to Kevin E. Marin about merging it and he suggested I get it into the DRI tree. I think this patch adds a useful feature and I'd like to see it get merged. Thoughts? Patch and notes about it are available here: http://bugs.xfree86.org/show_bug.cgi?id=276 For those of you that aren't familiar with it, mergedfb creates a single large framebuffer and then positions the 2 crtcs as vieports into it. Since it is a single framebuffer, the DRI works on both heads. It not only provides dualhead 3D, but also has some otehr nice features that are not available with xinerama based dualhead mode. Thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: xfree86, DRI, and multiple heads: thoughts and ideas
you could look at a register dump of the windows drivers and reverse engineer support. Also the xfree86 driver makes some references to the two display pipes, so you may be able to extrapolate support based on that. I'm not sure of the status with regards to the i830/45/55/65 parts documentation. intel has databooks for the i810 on their website, but that chip only had one crtc. Do the databooks that the xfree developers have have the info for the second crtc, or does intel consider that to be propietary? You could try asking intel for databooks... Alex --- Brad Hards <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, 29 Aug 2003 00:31 am, Alex Deucher wrote: > > The following cards have hw dualhead support, but no driver support > for > > it: > > i830/845 > I'm interested in working on this, even if it is just to control the > second > output (ie to make it mirror the main head without having to reboot > with the > external display attached. > But how does one figure out the right registers to change without the > > documentation? > > Brad __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
--- Keith Whitwell <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > looks like the post size limit ate my first attempt to post this. > > > > Anyway, I was finally able to access DRI cvs (from > > dri.freedesktop.org), so I pulled the latest tree and created a > radeon > > mergedfb patch against it. I've done some testing and it seems to > work > > fine. The patch only touches the 2D driver. I talked to Kevin E. > > Marin about merging it and he suggested I get it into the DRI tree. > I > > think this patch adds a useful feature and I'd like to see it get > > merged. Thoughts? > > I'd like to see something like this merged, definitely. Your code > looks fine > on a first pass, my only question is whether this is something that > can be > done largely or partly in shared device-independent code, and just > have > drivers hook that code in. > > It seems like a lot of cards have this type of capability and lots of > drivers > are doing this somewhat independently of one another. Is there some > common > code that can be abstracted out? (Looking quickly over the code > indicates > that a big percentage of it looks pretty hw-independent). I agree. Most of it is HW independant. This was discussed several times on the xfree86 devel ML, and everyone agrees that it should be factored out into common code, however, when that will happen is kind of hazy. I thought about trying to do some of the work myself, but I guess we need a consensus on what's the best "mergedfb" API. the usual "5.0" material response. Also the Pseudo-xinerama stuff should also be folded into the next version of the real xinerama extension, but once again that's 5.0 material. Everyone is busy, so I don't know when the commom code would be written, much less an API agreed on. Thomas' sis mergedfb code (which my radeon code is based on) is already in the xfree86 tree. Both of our implementations plus the mga driver share the same mergedfb options so they are consistent. I don't want to write the common code only it have it be a waste of time due to a refactoring of X internals planned for 5.0 or because my API is lacking. > > And the other question is why didn't Kevin want it in the XFree86 > tree? Is > there going to be a problem merging this code at some point in the > future, or > did he just think DRI was a natural home for it? Just curious > really... He thought since it allowed for 3D in a dualhead configuration, it would be a better fit in the DRI tree. that's probably why most people would use it since xinerama works well for 2D-only dualhead. Thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] adding sis 6326 support to the sis DRI
Eric, Now that you are finishing up the sis 300 series DRI port, how hard would it be to add support for the 6326? there were databooks for it flaoting around and there was a utah-glx driver as well. It's a pretty basic 3D engine; it's it similar to the 300 series, it might be trivial to add support, but then again, I'm not too familiar with sis hardware internals. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
Factoring it out is not a problem. the question is what to do with it when I pull it out. create an external external libray like libXMergedFB.so or something like that? what's the preferred method? any existing examples I can look at? Alex --- Michel Dänzer <[EMAIL PROTECTED]> wrote: > > As a first step, it shouldn't be too much work factoring out the > common > helper functions, possibly into a new module? > ... > > I wouldn't worry too much about 5.x yet, that's still in the distant > future AFAICT. IMHO the pains that code duplication will cause in the > meantime (we've seen over and over that even the tiniest duplication > can > cause considerable grief) greatly outweigh the potential 'waste' of > time > factoring out the common code. (As a side note, I'd expect this to be > much easier than merging the Radeon 3D drivers :) > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] adding sis 6326 support to the sis DRI
--- Alan Cox <[EMAIL PROTECTED]> wrote: > > basic 3D engine; it's it similar to the 300 series, it might be > trivial > > to add support, but then again, I'm not too familiar with sis > hardware > > internals. > > I actually took a brief look. The 6326 is a simple PIO engine that > needs > triangles fed it the right way. I've actually hacked up code borrowed > from Utah-glx and drawn triangles with it. > > You also only have one texture unit, but mesa seems to have code to > cope > with that. > > I'd love to see 6326 support if only because it gives you most of the > code to plug in S3 virge and any other crude triangle drawing > engines. > I've got the docs if you want them. There's actually already S3 virge support in a DRI CVS branch, perhaps that could be used as a model for the 6326. > > You *might* need to pass the vertex lists to the kernel to ensure you > can't lock them up (ie kernel does the actual loads into the > registers > and pretends to be a DMA engine) but that could be fixed later on. > > Alan > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
I did some basic work on factoring out the common code and discussed it with Thomas Winischhofer (Sis maintainer and driving force behind mergedfb development). He is of the opinion that it is still too early to create a generic API for mergedfb. There is still no consensus on what the final look should be and whether or not we have a flexible enough model right now. Plus there are some new features in the pipeline that may require some reworking of the current common code (absolute offsets and panning domains). It's more of a pain to have to constantly update the common code. So at the moment I guess I'm inclined to agree. thoughts? Alex --- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Wed, 2003-09-10 at 15:46, Alex Deucher wrote: > > > > > > It seems like a lot of cards have this type of capability and > lots of > > > drivers are doing this somewhat independently of one another. Is > there > > > some common code that can be abstracted out? (Looking quickly > over > > > the code indicates that a big percentage of it looks pretty > > > hw-independent). > > > > I agree. Most of it is HW independant. This was discussed several > > times on the xfree86 devel ML, and everyone agrees that it should > be > > factored out into common code, however, when that will happen is > kind > > of hazy. I thought about trying to do some of the work myself, but > I > > guess we need a consensus on what's the best "mergedfb" API. the > usual > > "5.0" material response. > > As a first step, it shouldn't be too much work factoring out the > common > helper functions, possibly into a new module? > > > Everyone is busy, so I don't know when the commom code would be > > written, much less an API agreed on. Thomas' sis mergedfb code > (which > > my radeon code is based on) is already in the xfree86 tree. Both > of > > our implementations plus the mga driver share the same mergedfb > options > > so they are consistent. > > > > I don't want to write the common code only it have it be a waste of > > time due to a refactoring of X internals planned for 5.0 or because > my > > API is lacking. > > I wouldn't worry too much about 5.x yet, that's still in the distant > future AFAICT. IMHO the pains that code duplication will cause in the > meantime (we've seen over and over that even the tiniest duplication > can > cause considerable grief) greatly outweigh the potential 'waste' of > time > factoring out the common code. (As a side note, I'd expect this to be > much easier than merging the Radeon 3D drivers :) > > > -- > Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI > developer > Software libre enthusiast \ > http://svcs.affero.net/rm.php?r=daenzer > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Thu, 2003-09-11 at 17:32, Alex Deucher wrote: > > I did some basic work on factoring out the common code and > discussed it > > with Thomas Winischhofer (Sis maintainer and driving force behind > > mergedfb development). He is of the opinion that it is still too > early > > to create a generic API for mergedfb. There is still no consensus > on > > what the final look should be and whether or not we have a flexible > > enough model right now. Plus there are some new features in the > > pipeline that may require some reworking of the current common code > > (absolute offsets and panning domains). It's more of a pain to > have to > > constantly update the common code. > > And it's less painful to do the same changes in all the drivers, > possibly introducing inconsistencies? > > I agree. I definitely would like to get over to the common code at some point, just not quite yet. right now there are just two drivers using it (sis and radeon) so it's not too hard to keep them in sync. FWIW, you can take a look at what I have done so far as far as factoring out the common code: http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/common/xf86mergedfb.c http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/common/xf86mergedfb.h if/when I get it working, I may attempt to maintain both the in-driver and common version so I can keep it up to date. What I don't want to happen is to have the common code merged, and have people start using it, only to find out later that it is flawed somehow. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
How about a mergedfb branch if not the trunk? I'm pretty good about keeping things up to date. I'm not yet an expert with CVS, but it won't take long ;) Alex --- Alexander Stohr <[EMAIL PROTECTED]> wrote: > > you would wonder how other developers could enjoy having > a look on your updates at the time that they do happen. > nothing worse than a driver which is based on that design > but is outdated by weeks or even months relative to the > top of the tree of your ongoing development. > > i would suggest having all your works going on in a CVS > repository, prefereably some development branch like > the texmem one. as the whole discussion takes place > here at dri-devel and the major benefits seem to be > (at least for me) on the dri project's behalf, > i would vote for basing it at the dri's CVS server system. > (lets hope that thing is working reliable for the next time.) > > to clarify, i would not mind having such a tree undergoing > deep changes in a short time - anyone who wants can take > an older snapshot or do its snapshot himselves. its just > the point of sharing will improve any sort of growth here. > > of course there can be personal reasons like not beeing > friend of CVS, having lots of broken code for long times > or just the fact that a shared code database does need > some sort of merger with other people's code any now and > then. my personal expirience is that a compile any now > and then plus some people that are testing such a codebase > for functionality is a sufficient means for good results. > > -Alex. > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] good news for savage users or not ???
S3/VIA released the source to their 2D/3D/XvMC driver that was based on xfree86 4.2.0. it has not yet been ported to 4.3.0. if you don't mind using 4.2.0, you can find instructions on how to build and install their driver here: http://probo.probo.com/pipermail/savage40/2003-July/41.html There are some people working on porting it to 4.3.0, but it's not working at the moment. Alex --- "Panagiotis D. Ritsos" <[EMAIL PROTECTED]> wrote: > Hi..its silly question time. Isn't the Savage Twister chipset > supported > when it comes to 3D and OpenGL? I though it was so...I've seen a > webpage > having both the Twister and the CLE266 driver. I've tested the latter > on > my Epia nad it works (seems to...) fine. I though that was the case > for > the Twister > (I am not a developer...I just use them!! Excuse my ignorance...) > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RMrgeFB:The patch vs DRICVS dosen't break things too bad, maby not at all.
Are you sure have mergedfb set up correctly? 3D should work on both heads, not just one. check the man page for all the mergedfb options: http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/radeon.4.html Are you using pageflipping? If so, turn it off. it has some issues in certain modes with mergedfb. It only seems to work reliably when crtc2 is RightOf or Below crtc1. Also if you mix clone and dualhead metamodes and switch to a clone mode, the display on CRTC1 has a weird framebuffer shift problem. pageflipping is not recommended. I'm not sure why you are seeing problems in quake. mergedfb only touched the 2D driver. Alex --- Mike Mestnik <[EMAIL PROTECTED]> wrote: > I just updated CVS and patched in > http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/mergedfb-dri.diff > Most everything that warked b4 still workes, there is a small problem > with quake3. Small meaning > not ought of the ordinary for DRICVS, things like textures on the > floor appere to be behind what > there infront of. > > Just wanted to let you know that it workes well enuff to get put in. > There has been a bug when > DRI is disabeled(DualHead) that I think should get some attention. > OpenGL apps work /w SW on one > head but are blank on the secondary(I thaught it was the primary, did > this change for any one > else?). This is also true of MergedFB on my system. Putting the > app(gears) so it's on both > dosen't tear the way Xv dose, but the one half is blank. > > I'm running with my primary on the Right plugged into the DVI port of > a VGA/DVI 8500 LE. The left > side is smaller that the right, and in some modes the right is > uselesly torn. Wish I could get > screen shots of what the DAC can do. > > mike > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] XGI?
Is anyone on either of these lists familiar with XGI? It seems to be a new GPU manufacturer consisting of a merger of Trident and the SiS graphics division. here's their website: http://www.xgitech.com/index.htm They have some interesting products products (dual GPU solution). Some of their other stuff looks similar to existing SiS and trident products. They mention linux support, but I see no links to drivers anywhere. does anyone know anymore about this company? Are they writing xfree drivers or with any existing drivers work with these chips? SiS has has a bad record of giving out specs on it's newer chips; trident I guess has been a little bit better. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XGI?
I wonder how the new company will be with respect to giving out datasheets? like sis or like trident? Alex --- Thomas Winischhofer <[EMAIL PROTECTED]> wrote: > Russ Dill wrote: > > On Mon, 2003-09-15 at 11:03, Alex Deucher wrote: > > > >>Is anyone on either of these lists familiar with XGI? It seems to > be a > >>new GPU manufacturer consisting of a merger of Trident and the SiS > >>graphics division. > >> > >>here's their website: > >>http://www.xgitech.com/index.htm > >> > >>They have some interesting products products (dual GPU solution). > Some > >>of their other stuff looks similar to existing SiS and trident > >>products. They mention linux support, but I see no links to > drivers > >>anywhere. does anyone know anymore about this company? Are they > >>writing xfree drivers or with any existing drivers work with these > >>chips? SiS has has a bad record of giving out specs on it's newer > >>chips; trident I guess has been a little bit better. > > I guess this company will do it like SiS did in the past: Make the > chips, but leave the integration into boards to other manufacturers. > (The "embedded-and-customized"-hell will never end...) > > My bet would be that ECS and MSI will be among the first to design > boards for these chips. > > > SiS spins off their 3D buisness and it gets named Xabre > > Trident buys/merges, whatever with Xabre, and the new company is > named > > XGI > > I think they it became official on the 13 or 14th, don't remember. > So > > for now, its just the Xabre products and the trident products > > (cyberblade2, etc). > > The "Volari"'s specs look indeed like the Xabre's, except for that > "Cipher" video processor and the dual-GPU option. Apart from this > (and > 3D, of course), these chips should be well supported by the current > SiS > driver (well, as soon as I get the PCI IDs) > > Thomas > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] XGI?
Will the drivers for both current and future chips be open source? What sort of feature set will the drivers support (2D, 3D, video, multi-head, etc.)? Will databooks be available to developers? Thanks, Alex --- "Chen Yukun (Jade)" <[EMAIL PROTECTED]> wrote: > Now in XGI, the unit from Trident will focus on Notebook market and > the one > seperated from Sis will focus on Desktop. Two series of chip will > both be > supported currently. But from the next chip , two chips will be > merged into > one. The h/w will be redesigned and all the driver will be re-coded. > > Also, both trident and Sis have the linux driver, which is release > with > Linux OS, for almost all their own chips. > > -Original Message- > From: Alex Deucher [mailto:[EMAIL PROTECTED] > Sent: Monday, September 15, 2003 5:30 PM > To: Thomas Winischhofer; [EMAIL PROTECTED] > Cc: Alex Deucher; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Dri-devel] XGI? > > > I wonder how the new company will be with respect to giving out > datasheets? like sis or like trident? > > Alex > > --- Thomas Winischhofer <[EMAIL PROTECTED]> wrote: > > Russ Dill wrote: > > > On Mon, 2003-09-15 at 11:03, Alex Deucher wrote: > > > > > >>Is anyone on either of these lists familiar with XGI? It seems > to > > be a > > >>new GPU manufacturer consisting of a merger of Trident and the > SiS > > >>graphics division. > > >> > > >>here's their website: > > >>http://www.xgitech.com/index.htm > > >> > > >>They have some interesting products products (dual GPU solution). > > > Some > > >>of their other stuff looks similar to existing SiS and trident > > >>products. They mention linux support, but I see no links to > > drivers > > >>anywhere. does anyone know anymore about this company? Are they > > >>writing xfree drivers or with any existing drivers work with > these > > >>chips? SiS has has a bad record of giving out specs on it's > newer > > >>chips; trident I guess has been a little bit better. > > > > I guess this company will do it like SiS did in the past: Make the > > chips, but leave the integration into boards to other > manufacturers. > > (The "embedded-and-customized"-hell will never end...) > > > > My bet would be that ECS and MSI will be among the first to design > > boards for these chips. > > > > > SiS spins off their 3D buisness and it gets named Xabre > > > Trident buys/merges, whatever with Xabre, and the new company is > > named > > > XGI > > > I think they it became official on the 13 or 14th, don't > remember. > > So > > > for now, its just the Xabre products and the trident products > > > (cyberblade2, etc). > > > > The "Volari"'s specs look indeed like the Xabre's, except for that > > "Cipher" video processor and the dual-GPU option. Apart from this > > (and > > 3D, of course), these chips should be well supported by the current > > SiS > > driver (well, as soon as I get the PCI IDs) > > > > Thomas > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] enabling DRI on savage MX
I don't think the drivers S3 released will work properly on savage3D
based cores like the MX/IX chips. They were designed for savage4 cores
like the prosavage and twister. You may want to compare the S3 driver
to the utah-glx savage driver. the utah driver only supports savage3D
cores, but not savage4 cores. The cores are probably different enough
that the s3 drivers won't "just work." You would need to adapt the S3
driver to work on MX/IX using utah-glx as a reference.
Alex
--- "Dimitry N. Naldaev" <[EMAIL PROTECTED]> wrote:
> � � �� 16
2003 21:10 Dimitry N. Naldaev ���:
> > � ����� �� 10
2003 02:16 Alex Deucher ���:
> > > The 2D driver supports all savage chips,
> >
> yesterday I did more testing S3 driver on my motebook and there is
> results
> by default DRI is not enabled
> The 2D driver does not work with enlightenment window manager --- the
> screen
> corrupted, see screenshot in attachment e-bug.png (I have bzip2ed it
> to fit
> 100kb limit of DRI mail list)
>
> After that I force init DRI by doing
> >
> > > from savage_driver.c:
> >
> > #if 0
> >
> > >if ((psav->Chipset == S3_TWISTER)
> > >
> > > || (psav->Chipset == S3_PROSAVAGE)) {
> > >
> > > /* Setup DRI after visuals have been established */
> > > psav->directRenderingEnabled =
> SAVAGEDRIScreenInit(pScreen);
> > > } else
> > > psav->directRenderingEnabled = FALSE;
> >
> > # else
> > psav->directRenderingEnabled = SAVAGEDRIScreenInit(pScreen);
> > #endif
> >
> In the case enlightenment work withoiut screen corruption
> glxinfo reports DRI enabled
> full output of glxinfo attached
>
> but when I start glxgears Xserver crashes
> full X log also attached
>
> there is an error :
> (EE) SAVAGE(0): Memory manager initialization to (0,0) (1024,-1)
> failed
> this happens inside SavageInitAccel function: the call
> xf86InitFBManager
> return an error...
> Yep... I find what happens... but I'll fix this when I'll return to
> home...
>
> Because savage MX have only 8MB vidio memory there is a question what
> things
> mast stay in vidio memory and what things can go in agp space?
>
> > Using AGP dma|
> DBflag:0
> name of display: :2.0
> display: :2 screen: 0
> direct rendering: Yes
> server glx vendor string: SGI
> server glx version string: 1.2
> server glx extensions:
> GLX_EXT_visual_info, GLX_EXT_visual_rating,
> GLX_EXT_import_context
> client glx vendor string: SGI
> client glx version string: 1.2
> client glx extensions:
> GLX_EXT_visual_info, GLX_EXT_visual_rating,
> GLX_EXT_import_context
> GLX extensions:
> GLX_EXT_visual_info, GLX_EXT_visual_rating,
> GLX_EXT_import_context
> OpenGL vendor string: S3 Graphics Inc.
> OpenGL renderer string: Mesa DRI SAVAGE Linux_1.1.18
> OpenGL version string: 1.2 Mesa 3.4.2
> OpenGL extensions:
> GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr,
> GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint,
> GL_EXT_compiled_vertex_array, GL_EXT_histogram,
> GL_EXT_packed_pixels,
> GL_EXT_polygon_offset, GL_EXT_rescale_normal,
> GL_EXT_stencil_wrap,
> GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object,
> GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos,
>
> GL_MESA_resize_buffers, GL_NV_texgen_reflection,
> GL_PGI_misc_hints,
> GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp
> glu version: 1.3
> glu extensions:
> GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
>
>visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
> id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
>
--
> 0x22 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0
> None
> 0x23 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0
> None
> 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0
> Slow
> 0x25 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0
> Slow
> 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0
> Slow
> 0x27 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0
> Slow
> 0x28 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0
> Slow
> 0x29 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0
> Slow
> > If some fields are empty or look unusual you may have an old
version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux
Re: [Dri-devel] DRI savage driver status
for 3D, what version of mesa are you using? are you using the right libGL? For 2D look in xc/programs/Xserver/hw/xfree86/drivers/savage Try the 2D driver with 3D disabled and see if you still get corruption. it may be that the 3D side is stomping on the something from the 2D side. Alex --- Rafael Maximo <[EMAIL PROTECTED]> wrote: > Hi, > > Some of you already know that i'm trying to work on the > savage > driver, i'm working on the 3D driver (/lib/GL/mesa/src/drv) and now > it is > compiling and i'll test it but i got some other problems. After > compiling > everything (2D, 3D, kernel modules, etc.) my screen on xfree 4.3.0 is > a > little corrupted (http://max.brz.net/screen.png), on XFree86 log it > says > that direct rendering is enable (http://max.brz.net/XFree86_log.txt) > but i > got something different from glxinfo > (http://max.brz.net/glxinfo.txt). > > First i need to fix 2D driver but where should i look at > first, is > there any specific function that i should study? And why direct > rendering > is not enable? Is it a driver problem or a config problem? Here is > the > output of dmesg http://max.brz.net/dmesg.txt (agpgart and savage > module > were loaded with modprobe) > > Please send me any information that could help me make the > savage > driver works. > > bye. > > Rafael Máximo > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] READ ME FOR VERSION MISMATCH ERRORS
If you are getting version mismatch errors with the sanpshots, you need a newer version of the xfree86 server. DRI just merged in the changes from the Xfree86 tree and a newer XFree86 binary is needed. you can either build it yourself from CVS, or download the gcc 3.x one I've provided here: http://www.botchco.com/alex/radeon/mergedfb/cvs/cvs-2003-7-31/final/XFree86 gcc 2.x version here: http://www.xfree86.org/~alanh/ Alex PS, Jose, do you think you can add the XFree86 binary or a link to download it to the snapshots? __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI savage driver status
you might compare it to Tim's old 2D driver (shipped with 4.3.0) and see what's changed...assuming his driver works for you in 2D. Alex --- Rafael Maximo <[EMAIL PROTECTED]> wrote: > > Hi, > > I decided to focus on 2D problem first but i don't know how > I can > debug the 2D driver and found where is the problem. I would > appreciate any > information or docs about debugging this kind of problem. > > I'm using the 2D driver on savage_1-0-0_branch and i didn't > change > anything except Imakefile because it is pointing to wrong directorys. > > Thanks. > > > Rafael Máximo > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
