[PATCH] drm/radeon/kms: remove unneeded master create/destroy functions.
From: Dave Airlie airl...@redhat.com
We shouldn't need these at all in radeon kms mode.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_drv.c |5 ---
drivers/gpu/drm/radeon/radeon_kms.c | 49 ---
2 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 50fce49..7f50fb8 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -62,9 +62,6 @@ void radeon_driver_irq_preinstall_kms(struct drm_device *dev);
int radeon_driver_irq_postinstall_kms(struct drm_device *dev);
void radeon_driver_irq_uninstall_kms(struct drm_device *dev);
irqreturn_t radeon_driver_irq_handler_kms(DRM_IRQ_ARGS);
-int radeon_master_create_kms(struct drm_device *dev, struct drm_master
*master);
-void radeon_master_destroy_kms(struct drm_device *dev,
- struct drm_master *master);
int radeon_dma_ioctl_kms(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int radeon_gem_object_init(struct drm_gem_object *obj);
@@ -260,8 +257,6 @@ static struct drm_driver kms_driver = {
.get_vblank_counter = radeon_get_vblank_counter_kms,
.enable_vblank = radeon_enable_vblank_kms,
.disable_vblank = radeon_disable_vblank_kms,
- .master_create = radeon_master_create_kms,
- .master_destroy = radeon_master_destroy_kms,
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = radeon_debugfs_init,
.debugfs_cleanup = radeon_debugfs_cleanup,
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 709bd89..ba12862 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -201,55 +201,6 @@ void radeon_disable_vblank_kms(struct drm_device *dev, int
crtc)
/*
- * For multiple master (like multiple X).
- */
-struct drm_radeon_master_private {
- drm_local_map_t *sarea;
- drm_radeon_sarea_t *sarea_priv;
-};
-
-int radeon_master_create_kms(struct drm_device *dev, struct drm_master *master)
-{
- struct drm_radeon_master_private *master_priv;
- unsigned long sareapage;
- int ret;
-
- master_priv = kzalloc(sizeof(*master_priv), GFP_KERNEL);
- if (master_priv == NULL) {
- return -ENOMEM;
- }
- /* prebuild the SAREA */
- sareapage = max_t(unsigned long, SAREA_MAX, PAGE_SIZE);
- ret = drm_addmap(dev, 0, sareapage, _DRM_SHM,
-_DRM_CONTAINS_LOCK,
-master_priv-sarea);
- if (ret) {
- DRM_ERROR(SAREA setup failed\n);
- return ret;
- }
- master_priv-sarea_priv = master_priv-sarea-handle + sizeof(struct
drm_sarea);
- master_priv-sarea_priv-pfCurrentPage = 0;
- master-driver_priv = master_priv;
- return 0;
-}
-
-void radeon_master_destroy_kms(struct drm_device *dev,
- struct drm_master *master)
-{
- struct drm_radeon_master_private *master_priv = master-driver_priv;
-
- if (master_priv == NULL) {
- return;
- }
- if (master_priv-sarea) {
- drm_rmmap_locked(dev, master_priv-sarea);
- }
- kfree(master_priv);
- master-driver_priv = NULL;
-}
-
-
-/*
* IOCTL.
*/
int radeon_dma_ioctl_kms(struct drm_device *dev, void *data,
--
1.6.4.4
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] [RFC] drm/radeon/kms: don't require up to 64k allocations.
From: Dave Airlie airl...@redhat.com
This avoids needing to do a kmalloc PAGE_SIZE for the main
indirect buffer chunk, it adds an accessor for all reads from
the chunk and caches a single page at a time for subsequent
reads.
TODO:
r600 fixups.
---
drivers/gpu/drm/radeon/r100.c | 188 ++-
drivers/gpu/drm/radeon/r100_track.h | 84 +++-
drivers/gpu/drm/radeon/r200.c | 79 +++
drivers/gpu/drm/radeon/r300.c | 137 +
drivers/gpu/drm/radeon/radeon.h |3 +
drivers/gpu/drm/radeon/radeon_cs.c | 33 +--
6 files changed, 267 insertions(+), 257 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 737970b..9ab976d 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -863,13 +863,11 @@ int r100_cs_parse_packet0(struct radeon_cs_parser *p,
void r100_cs_dump_packet(struct radeon_cs_parser *p,
struct radeon_cs_packet *pkt)
{
- struct radeon_cs_chunk *ib_chunk;
volatile uint32_t *ib;
unsigned i;
unsigned idx;
ib = p-ib-ptr;
- ib_chunk = p-chunks[p-chunk_ib_idx];
idx = pkt-idx;
for (i = 0; i = (pkt-count + 1); i++, idx++) {
DRM_INFO(ib[%d]=0x%08X\n, idx, ib[idx]);
@@ -896,7 +894,7 @@ int r100_cs_packet_parse(struct radeon_cs_parser *p,
idx, ib_chunk-length_dw);
return -EINVAL;
}
- header = ib_chunk-kdata[idx];
+ header = radeon_get_ib_value(p, idx);
pkt-idx = idx;
pkt-type = CP_PACKET_GET_TYPE(header);
pkt-count = CP_PACKET_GET_COUNT(header);
@@ -939,7 +937,6 @@ int r100_cs_packet_parse(struct radeon_cs_parser *p,
*/
int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
{
- struct radeon_cs_chunk *ib_chunk;
struct drm_mode_object *obj;
struct drm_crtc *crtc;
struct radeon_crtc *radeon_crtc;
@@ -947,8 +944,9 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
int crtc_id;
int r;
uint32_t header, h_idx, reg;
+ volatile uint32_t *ib;
- ib_chunk = p-chunks[p-chunk_ib_idx];
+ ib = p-ib-ptr;
/* parse the wait until */
r = r100_cs_packet_parse(p, waitreloc, p-idx);
@@ -963,7 +961,7 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
return r;
}
- if (ib_chunk-kdata[waitreloc.idx + 1] != RADEON_WAIT_CRTC_VLINE) {
+ if (radeon_get_ib_value(p, waitreloc.idx + 1) !=
RADEON_WAIT_CRTC_VLINE) {
DRM_ERROR(vline wait had illegal wait until\n);
r = -EINVAL;
return r;
@@ -978,9 +976,9 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
p-idx += waitreloc.count;
p-idx += p3reloc.count;
- header = ib_chunk-kdata[h_idx];
- crtc_id = ib_chunk-kdata[h_idx + 5];
- reg = ib_chunk-kdata[h_idx] 2;
+ header = radeon_get_ib_value(p, h_idx);
+ crtc_id = radeon_get_ib_value(p, h_idx + 5);
+ reg = header 2;
mutex_lock(p-rdev-ddev-mode_config.mutex);
obj = drm_mode_object_find(p-rdev-ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
@@ -994,8 +992,9 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
if (!crtc-enabled) {
/* if the CRTC isn't enabled - we need to nop out the wait
until */
- ib_chunk-kdata[h_idx + 2] = PACKET2(0);
- ib_chunk-kdata[h_idx + 3] = PACKET2(0);
+
+ ib[h_idx + 2] = PACKET2(0);
+ ib[h_idx + 3] = PACKET2(0);
} else if (crtc_id == 1) {
switch (reg) {
case AVIVO_D1MODE_VLINE_START_END:
@@ -1011,8 +1010,8 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
r = -EINVAL;
goto out;
}
- ib_chunk-kdata[h_idx] = header;
- ib_chunk-kdata[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1;
+ ib[h_idx] = header;
+ ib[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1;
}
out:
mutex_unlock(p-rdev-ddev-mode_config.mutex);
@@ -1033,7 +1032,6 @@ out:
int r100_cs_packet_next_reloc(struct radeon_cs_parser *p,
struct radeon_cs_reloc **cs_reloc)
{
- struct radeon_cs_chunk *ib_chunk;
struct radeon_cs_chunk *relocs_chunk;
struct radeon_cs_packet p3reloc;
unsigned idx;
@@ -1044,7 +1042,6 @@ int r100_cs_packet_next_reloc(struct radeon_cs_parser *p,
return -EINVAL;
}
*cs_reloc = NULL;
- ib_chunk = p-chunks[p-chunk_ib_idx];
relocs_chunk = p-chunks[p-chunk_relocs_idx];
r = r100_cs_packet_parse(p, p3reloc, p-idx);
if (r) {
@@ -1057,7 +1054,7 @@ int r100_cs_packet_next_reloc(struct
[Patch] drm: create gitignore file for radeon
Got lots of untracked files after compiling. These files are generated, thus should be ignored by git. Cc:David Airlie airl...@linux.ie Signed-off-by: WANG Cong amw...@redhat.com --- diff --git a/drivers/gpu/drm/radeon/.gitignore b/drivers/gpu/drm/radeon/.gitignore new file mode 100644 index 000..403eb3a --- /dev/null +++ b/drivers/gpu/drm/radeon/.gitignore @@ -0,0 +1,3 @@ +mkregtable +*_reg_safe.h + -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [RFC] drm/radeon/kms: don't require up to 64k allocations.
On Wed, 2009-09-23 at 16:56 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com This avoids needing to do a kmalloc PAGE_SIZE for the main indirect buffer chunk, it adds an accessor for all reads from the chunk and caches a single page at a time for subsequent reads. FWIW, this works on my PowerBook but seems to drop x11perf -aa10text numbers from about 370k/s to about 315k/s. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [RFC] drm/radeon/kms: don't require up to 64k allocations.
From: Dave Airlie airl...@redhat.com This avoids needing to do a kmalloc PAGE_SIZE for the main indirect buffer chunk, it adds an accessor for all reads from the chunk and caches a single page at a time for subsequent reads. FWIW, this works on my PowerBook but seems to drop x11perf -aa10text numbers from about 370k/s to about 315k/s. Yeah I'm unsure how to bring back up the speed, two ideas I have are: 1) won't help you but on PCI/PCIE we can use the IB to read from and avoid copying the chunk since its all cache coherent 2) keep a bitmap of the pages, copy to the kpage and then to IB, then the IB copy from user can just copy any pages we don't hit. But since what we are doing now is inherently broken, getting order 5 pages once the system is running is not something we'd expect to work. I expect this solution is still faster than the vmalloc overhead. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: preventing GPU reset DoS
Am Mittwoch, den 23.09.2009, 06:10 +1000 schrieb Dave Airlie: I'm just wondering what other use-case we'd need anything more agressive? Hi, the computer rooms at my University came to my mind: There are students who want to do their homework for the computer graphics lectures. If it *is* possible to lock a machine for a longer time, they could lock up machine by machine by accident and the computer room guidelines say that it's forbidden to turn off/reset computers and the administrators aren't around all the time. This could also be done intentionally to annoy other users... Another scenario could be an Internet cafe or so. I don't care if I can or can not DoS myself on my own machine, but I see a potential problem in multi-user environments. Maybe having the possibility to adjust protection during run-time would be a nice to have feature. Kind regards - Fuddl signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24105] New: System Hangs while Running SpecViewPerf10
http://bugs.freedesktop.org/show_bug.cgi?id=24105 Summary: System Hangs while Running SpecViewPerf10 Product: Mesa Version: git Platform: x86 (IA32) OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: hysv...@gmail.com Created an attachment (id=29796) -- (http://bugs.freedesktop.org/attachment.cgi?id=29796) Xorg.0.log Asic : Radeon RV560XT Details of the X-stack: -- mesa/drm : 27 Aug -2009 mesa/mesa: 7.6 xorg/xserver : 1.6.0 xorg/xf86-video-ati: 27 Aug -2009 Steps to reproduce Problem: - Run ./Run_All.csh in SpecViewPerf10 Test Suite Observation : -- system hard hangs after some duration. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24105] System Hangs while Running SpecViewPerf10
http://bugs.freedesktop.org/show_bug.cgi?id=24105 --- Comment #1 from samit vats hysv...@gmail.com 2009-09-23 05:00:20 PST --- Created an attachment (id=29797) -- (http://bugs.freedesktop.org/attachment.cgi?id=29797) xorg.conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24105] System Hangs while Running SpecViewPerf10
http://bugs.freedesktop.org/show_bug.cgi?id=24105 --- Comment #2 from samit vats hysv...@gmail.com 2009-09-23 05:00:41 PST --- Created an attachment (id=29798) -- (http://bugs.freedesktop.org/attachment.cgi?id=29798) glxinfo -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24105] System Hangs while Running SpecViewPerf10
http://bugs.freedesktop.org/show_bug.cgi?id=24105 --- Comment #3 from samit vats hysv...@gmail.com 2009-09-23 05:00:57 PST --- Created an attachment (id=29799) -- (http://bugs.freedesktop.org/attachment.cgi?id=29799) lspci -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [RFC] drm/radeon/kms: don't require up to 64k allocations.
2009/9/23 Dave Airlie airl...@linux.ie
From: Dave Airlie airl...@redhat.com
This avoids needing to do a kmalloc PAGE_SIZE for the main
indirect buffer chunk, it adds an accessor for all reads from
the chunk and caches a single page at a time for subsequent
reads.
FWIW, this works on my PowerBook but seems to drop x11perf -aa10text
numbers from about 370k/s to about 315k/s.
Yeah I'm unsure how to bring back up the speed, two ideas I have are:
1) won't help you but on PCI/PCIE we can use the IB to read from and avoid
copying the chunk since its all cache coherent
2) keep a bitmap of the pages, copy to the kpage and then to IB, then
the IB copy from user can just copy any pages we don't hit.
But since what we are doing now is inherently broken, getting order 5
pages once the system is running is not something we'd expect to work. I
expect this solution is still faster than the vmalloc overhead.
Dave.
Maybe only forward iteration could perform better for this parsing. My idea
would be rewrite radeon_get_ib_value like this and correct parser
accordingly. Here it could also just plainly copy directly ths skipped pages
to IB quite easily.
static inline u32 radeon_get_ib_next_value(struct radeon_cs_parser *p,
unsigned skip)
{
int i = p-chunk_ib_idx;
skip += 1; /* advance to next element */
if (unlikely(p-pg_offset + skip = (PAGE_SIZE/4))) {
/* this could be function call to reduce code size because
this
is relative infrequent operation */
unsigned pages_to_skip;
skip -= (PAGE_SIZE/4) - p-pg_offset;
pages_to_skip = skip/(PAGE_SIZE/4);
skip -= pages_to_skip*(PAGE_SIZE/4);
p-pg_offset = 0;
p-pg_idx += pages_to_skip + 1;
if (DRM_COPY_FROM_USER(p-chunks[i].kpage,
p-chunks[i].user_ptr + (p-pg_idx *
PAGE_SIZE),
PAGE_SIZE))
return 0; /* Should we fail whole parsing here? */
}
p-pg_offset += skip;
return p-chunks[i].kpage[p-pg_offset];
}
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)
On Tue, 2009-09-22 at 17:32 -0500, Robert Noland wrote: Well, I don't have a log of the output without my patch... But, with my patch this is not the case. Running the demo multiple times produces different values. If it is of interest, I can revert the patch that broke the build and re-examine the output before any of these changes. Is it possible that the real issue is with freeglut? I just built the demo program on my i386 box with G45 hardware and mesa 7.4.4. The demo still produces the expected results, i.e. it seems to work fine. It may not be entirely thread safe, but the demo at least doesn't exhibit the problem here. robert. -- Robert Noland rnol...@2hip.net 2Hip Networks -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23901] radeon KMS sends no input signal to LCD (regression in 2.6.31)
http://bugs.freedesktop.org/show_bug.cgi?id=23901 --- Comment #9 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 12:12:41 PST --- This problem persists with drm-next as of September 23rd. Adam -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: preventing GPU reset DoS
Am Tuesday 22 September 2009 23:25:09 schrieb Pauli Nieminen: Too bad GPU reset is already now stopping this use case while it doesn't protect user from possible attack causing multiple GPU reset in row. So this long rendering operation blocking GPU is more like scheduler or mesa bug that it doesn't split rendering to small enough parts that we can scheduler something else in between for user interface. Is it possible to scheduler something els to GPU wile only part of GPU runs the slow and long running shader? If no then it looks like big limitation in hw design. I would hope the hardware people thought of this on newer GPUs, but at least I haven't seen anything to support context switching in the docs released by AMD. As for the rest, I agree that it's a problem. It is actually roughly the same problem as when the system goes into a swapping loop of death, except it may actually be easier to identify the culprit. After all, by simply checking which fences have already been written back by the GPU, we should be able to determine which client caused the currently executing command stream. That probably does require adding some more tracking, but perhaps it can be integrated into the existing fence mechanisms. The second part would be to punish applications that have caused GPU hangs. Frankly, killing them seems like a bad idea; it seems better to de-prioritize them and force them to wait before sending new command buffer. Another major worry is that we should somehow make sure that the X server - or alternative future display servers - will not become victims of this regime. After all, if the X server services an indirect rendering GLX client, it could also be hoodwinked by this client into submitting too-long-running command streams. If the DRM clients get appropriate feedback when they caused a GPU reset, the X server could potentially use this information to punish GLX clients accordingly. cu, Nicolai -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: preventing GPU reset DoS
On Wed, Sep 23, 2009 at 10:52 PM, Nicolai Hähnle nhaeh...@gmail.com wrote: Am Tuesday 22 September 2009 23:25:09 schrieb Pauli Nieminen: Too bad GPU reset is already now stopping this use case while it doesn't protect user from possible attack causing multiple GPU reset in row. So this long rendering operation blocking GPU is more like scheduler or mesa bug that it doesn't split rendering to small enough parts that we can scheduler something else in between for user interface. Is it possible to scheduler something els to GPU wile only part of GPU runs the slow and long running shader? If no then it looks like big limitation in hw design. I would hope the hardware people thought of this on newer GPUs, but at least I haven't seen anything to support context switching in the docs released by AMD. As for the rest, I agree that it's a problem. It is actually roughly the same problem as when the system goes into a swapping loop of death, except it may actually be easier to identify the culprit. After all, by simply checking which fences have already been written back by the GPU, we should be able to determine which client caused the currently executing command stream. Now I remember some talk that WDDM driver model requires preemptive scheduling from driver so maybe r600+ cards have preemptive scheduling support at least in some forms. That probably does require adding some more tracking, but perhaps it can be integrated into the existing fence mechanisms. The second part would be to punish applications that have caused GPU hangs. Frankly, killing them seems like a bad idea; it seems better to de-prioritize them and force them to wait before sending new command buffer. Problem here is that each GPU hang will last over 500ms before GPU is reset. It might be something like first lower the priority and then if hangs continue then start killing the application. I think that GPU hang is more like memory access violation in normal application so it should cause crash. Rendering of application will anyway be broken after reset because some of rendering operations failed and image would be corrupted. Another major worry is that we should somehow make sure that the X server - or alternative future display servers - will not become victims of this regime. After all, if the X server services an indirect rendering GLX client, it could also be hoodwinked by this client into submitting too-long-running command streams. If the DRM clients get appropriate feedback when they caused a GPU reset, the X server could potentially use this information to punish GLX clients accordingly. cu, Nicolai So we would need secure communication link with xserver so it could cooperate after GPU hang and penalize the broken application the way that is tough to be correct. In my option sending fatal signal is the best option but if all the problems in keeping broken application running can be fixed somehow then it could do something else. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23901] radeon KMS sends no input signal to LCD (regression in 2.6.31)
http://bugs.freedesktop.org/show_bug.cgi?id=23901 --- Comment #10 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 13:53:25 PST --- An attempted force dpms cycle (with 'xset dpms force suspend'), as suggested by Alex D., did not bring the LCD back on-line. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24124] New: Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85
http://bugs.freedesktop.org/show_bug.cgi?id=24124 Summary: Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85 Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: ad...@voicenet.com My ViewSonic G220fb is immediately switched to 1600x1...@85 with KMS enabled. As soon as this happens, the entire contents start to massively flicker. Once in Xorg, the flickering continues. It also continues if I switch to 1280x1...@85, though both 1600x1...@75 and 1280x1...@75 work just fine. Without KMS enabled, I can use both resolutions in Xorg @85 without any flickering. You can clearly see the flickering in this video: http://adam.npark.com/kms-flickering.mpg -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24124] Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85
http://bugs.freedesktop.org/show_bug.cgi?id=24124 --- Comment #1 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 14:19:43 PST --- Created an attachment (id=29817) -- (http://bugs.freedesktop.org/attachment.cgi?id=29817) Xorg.0.log file with KMS enabled -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24124] Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85
http://bugs.freedesktop.org/show_bug.cgi?id=24124 --- Comment #2 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 14:19:56 PST --- Created an attachment (id=29818) -- (http://bugs.freedesktop.org/attachment.cgi?id=29818) xrandr --verbose with KMS enabled. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] drm/edid: Fix standard timing parse for EDID = 1.2
Aspect ratio code of 0 means 1:1 before EDID 1.3.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8ed732a..9888c20 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -528,6 +528,7 @@ bad_std_timing(u8 a, u8 b)
*/
struct drm_display_mode *drm_mode_std(struct drm_device *dev,
struct std_timing *t,
+ int revision,
int timing_level)
{
struct drm_display_mode *mode;
@@ -546,9 +547,12 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
/* vrefresh_rate = vfreq + 60 */
vrefresh_rate = vfreq + 60;
/* the vdisplay is calculated based on the aspect ratio */
- if (aspect_ratio == 0)
- vsize = (hsize * 10) / 16;
- else if (aspect_ratio == 1)
+ if (aspect_ratio == 0) {
+ if (revision 3)
+ vsize = hsize;
+ else
+ vsize = (hsize * 10) / 16;
+ } else if (aspect_ratio == 1)
vsize = (hsize * 3) / 4;
else if (aspect_ratio == 2)
vsize = (hsize * 4) / 5;
@@ -797,7 +801,7 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
continue;
newmode = drm_mode_std(dev, edid-standard_timings[i],
- timing_level);
+ edid-revision, timing_level);
if (newmode) {
drm_mode_probed_add(connector, newmode);
modes++;
@@ -853,6 +857,7 @@ static int add_detailed_info(struct drm_connector
*connector,
std = data-data.timings[j];
newmode = drm_mode_std(dev, std,
+ edid-revision,
timing_level);
if (newmode) {
drm_mode_probed_add(connector,
newmode);
@@ -981,7 +986,9 @@ static int add_detailed_info_eedid(struct drm_connector
*connector,
struct drm_display_mode *newmode;
std = data-data.timings[j];
- newmode = drm_mode_std(dev, std, timing_level);
+ newmode = drm_mode_std(dev, std,
+ edid-revision,
+ timing_level);
if (newmode) {
drm_mode_probed_add(connector, newmode);
modes++;
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/4] drm/edid: Ignore bad standard timings.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3326987..dd35dc1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -502,6 +502,19 @@ static struct drm_display_mode *drm_find_dmt(struct
drm_device *dev,
}
return mode;
}
+
+/*
+ * 0 is reserved. The spec says 0x01 fill for unused timings. Some old
+ * monitors fill with ascii space (0x20) instead.
+ */
+static int
+bad_std_timing(u8 a, u8 b)
+{
+ return (a == 0x00 b == 0x00) ||
+ (a == 0x01 b == 0x01) ||
+ (a == 0x20 b == 0x20);
+}
+
/**
* drm_mode_std - convert standard mode info (width, height, refresh) into mode
* @t: standard timing params
@@ -525,6 +538,9 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
unsigned vfreq = (t-vfreq_aspect EDID_TIMING_VFREQ_MASK)
EDID_TIMING_VFREQ_SHIFT;
+ if (bad_std_timing(t-hsize, t-vfreq_aspect))
+ return NULL;
+
/* According to the EDID spec, the hdisplay = hsize * 8 + 248 */
hsize = t-hsize * 8 + 248;
/* vrefresh_rate = vfreq + 60 */
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] drm/edid: const cleanup
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 90d76ba..3326987 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -109,7 +109,9 @@ static struct edid_quirk {
/* Valid EDID header has these bytes */
-static u8 edid_header[] = { 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00 };
+static const u8 edid_header[] = {
+ 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
+};
/**
* edid_is_valid - sanity check EDID data
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] drm/edid: Detailed standard timing blocks have six timings, not five.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dd35dc1..8ed732a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -847,8 +847,7 @@ static int add_detailed_info(struct drm_connector
*connector,
case EDID_DETAIL_MONITOR_CPDATA:
break;
case EDID_DETAIL_STD_MODES:
- /* Five modes per detailed section */
- for (j = 0; j 5; i++) {
+ for (j = 0; j 6; i++) {
struct std_timing *std;
struct drm_display_mode *newmode;
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24124] Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85
http://bugs.freedesktop.org/show_bug.cgi?id=24124 --- Comment #3 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 17:00:15 PST --- This same combination of monitors works fine with an HD3450 and drm-next. No flickering at @85. Attaching Xorg.0.log file. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24124] Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85
http://bugs.freedesktop.org/show_bug.cgi?id=24124 --- Comment #4 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 17:00:45 PST --- Created an attachment (id=29819) -- (http://bugs.freedesktop.org/attachment.cgi?id=29819) Xorg.0.log file with KMS enabled on HD3450 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23901] radeon KMS sends no input signal to LCD (regression in 2.6.31)
http://bugs.freedesktop.org/show_bug.cgi?id=23901 --- Comment #11 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 17:01:15 PST --- This same combination of monitors works fine with an HD3450 and drm-next. The LCD stays on when the framebuffer kicks in. Attaching Xorg.0.log file from the HD3450. Adam -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23901] radeon KMS sends no input signal to LCD (regression in 2.6.31)
http://bugs.freedesktop.org/show_bug.cgi?id=23901 --- Comment #12 from Adam K Kirchhoff ad...@voicenet.com 2009-09-23 17:02:04 PST --- Created an attachment (id=29820) -- (http://bugs.freedesktop.org/attachment.cgi?id=29820) Xorg.0.log file with working correctly with KMS enabled, using the HD3450 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: don't require up to 64k allocations. (v2)
From: Dave Airlie airl...@redhat.com
This avoids needing to do a kmalloc PAGE_SIZE for the main
indirect buffer chunk, it adds an accessor for all reads from
the chunk and caches a single page at a time for subsequent
reads.
changes since v1:
Use a two page pool which should be the most common case
a single packet spanning PAGE_SIZE will be hit, but I'm
having trouble seeing anywhere we currently generate anything like that.
r600: untested conversion
hopefully proper short page copying at end
added parser_error flag to set deep errors instead of having to test
every ib value fetch.
can someone confirm my last_page_index math is right?
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 188 ++-
drivers/gpu/drm/radeon/r100_track.h | 69 -
drivers/gpu/drm/radeon/r200.c | 79 +++
drivers/gpu/drm/radeon/r300.c | 137 +
drivers/gpu/drm/radeon/r600_cs.c| 26 +++---
drivers/gpu/drm/radeon/radeon.h | 37 +++-
drivers/gpu/drm/radeon/radeon_cs.c | 105 ++--
7 files changed, 370 insertions(+), 271 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 737970b..9ab976d 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -863,13 +863,11 @@ int r100_cs_parse_packet0(struct radeon_cs_parser *p,
void r100_cs_dump_packet(struct radeon_cs_parser *p,
struct radeon_cs_packet *pkt)
{
- struct radeon_cs_chunk *ib_chunk;
volatile uint32_t *ib;
unsigned i;
unsigned idx;
ib = p-ib-ptr;
- ib_chunk = p-chunks[p-chunk_ib_idx];
idx = pkt-idx;
for (i = 0; i = (pkt-count + 1); i++, idx++) {
DRM_INFO(ib[%d]=0x%08X\n, idx, ib[idx]);
@@ -896,7 +894,7 @@ int r100_cs_packet_parse(struct radeon_cs_parser *p,
idx, ib_chunk-length_dw);
return -EINVAL;
}
- header = ib_chunk-kdata[idx];
+ header = radeon_get_ib_value(p, idx);
pkt-idx = idx;
pkt-type = CP_PACKET_GET_TYPE(header);
pkt-count = CP_PACKET_GET_COUNT(header);
@@ -939,7 +937,6 @@ int r100_cs_packet_parse(struct radeon_cs_parser *p,
*/
int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
{
- struct radeon_cs_chunk *ib_chunk;
struct drm_mode_object *obj;
struct drm_crtc *crtc;
struct radeon_crtc *radeon_crtc;
@@ -947,8 +944,9 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
int crtc_id;
int r;
uint32_t header, h_idx, reg;
+ volatile uint32_t *ib;
- ib_chunk = p-chunks[p-chunk_ib_idx];
+ ib = p-ib-ptr;
/* parse the wait until */
r = r100_cs_packet_parse(p, waitreloc, p-idx);
@@ -963,7 +961,7 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
return r;
}
- if (ib_chunk-kdata[waitreloc.idx + 1] != RADEON_WAIT_CRTC_VLINE) {
+ if (radeon_get_ib_value(p, waitreloc.idx + 1) !=
RADEON_WAIT_CRTC_VLINE) {
DRM_ERROR(vline wait had illegal wait until\n);
r = -EINVAL;
return r;
@@ -978,9 +976,9 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
p-idx += waitreloc.count;
p-idx += p3reloc.count;
- header = ib_chunk-kdata[h_idx];
- crtc_id = ib_chunk-kdata[h_idx + 5];
- reg = ib_chunk-kdata[h_idx] 2;
+ header = radeon_get_ib_value(p, h_idx);
+ crtc_id = radeon_get_ib_value(p, h_idx + 5);
+ reg = header 2;
mutex_lock(p-rdev-ddev-mode_config.mutex);
obj = drm_mode_object_find(p-rdev-ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
@@ -994,8 +992,9 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
if (!crtc-enabled) {
/* if the CRTC isn't enabled - we need to nop out the wait
until */
- ib_chunk-kdata[h_idx + 2] = PACKET2(0);
- ib_chunk-kdata[h_idx + 3] = PACKET2(0);
+
+ ib[h_idx + 2] = PACKET2(0);
+ ib[h_idx + 3] = PACKET2(0);
} else if (crtc_id == 1) {
switch (reg) {
case AVIVO_D1MODE_VLINE_START_END:
@@ -1011,8 +1010,8 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
r = -EINVAL;
goto out;
}
- ib_chunk-kdata[h_idx] = header;
- ib_chunk-kdata[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1;
+ ib[h_idx] = header;
+ ib[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1;
}
out:
mutex_unlock(p-rdev-ddev-mode_config.mutex);
@@ -1033,7 +1032,6 @@ out:
int r100_cs_packet_next_reloc(struct radeon_cs_parser *p,
struct radeon_cs_reloc **cs_reloc)
{
- struct
