[Bug 27206] Blurred screen with latest drm-next-radeon and KMS
http://bugs.freedesktop.org/show_bug.cgi?id=27206 --- Comment #9 from DF5JT ke4...@bloatware.de 2010-03-22 00:59:48 PST --- (In reply to comment #8) (In reply to comment #6) (In reply to comment #5) Created an attachment (id=34264) -- (http://bugs.freedesktop.org/attachment.cgi?id=34264) [details] [details] [details] dmesg from garbled screen Kernel is compiled from up to date git drm-next-radeon on x86 platform with Fedora 12 userland. Plus all patches from: http://people.freedesktop.org/~agd5f/pm2/ which could all be applied cleanly. Which ones didn't apply? I wouldn't recommend that patch set unless you apply all of them (they apply to drm-radeon-testing). Do you still have problems without those patches applied? I pulled a clean, full tree from airlied's drm-next-radeon tree and applied all the 30 patches from your repo and that's what doesn't work. However, there is a slight chance that this is actually hardware related. I have had the LCD inverter changed last week, because of a backlight failure and I have now found out that it was a temperature related problem (notebook staying in a rather cool room overnight), which spontaneously disappears when the laptop gets back to room temperature. It likely is a problem either with the GPU itself or the video RAM and I expect to have it replaced either tomorrow or day after. I will report back as soon as I am sure that my hardware is running flawlessly. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h
On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu olva...@gmail.com wrote: On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek sedat.di...@googlemail.com wrote: [...] Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps (master GIT incl. gallium-st-api-dri merge) $ cat oa_benchmark.txt s...@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 21 | egrep -e '[0-9]+ frames' 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms Thanks for your work! Unless I have some magic power that I am not aware of, the boost should be attributed to r300g developers. I think, it is helpful to benchmark from time to time. I was comparing the both branches 7.8 and 7.9-devel in general and especiall r300g dri/st. Indeed, Chapeau to all contributors to r300g development. -- Sedat -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PCI quirks: RS780/RS880: work around missing MSI initialization
On Mon, 22 Mar 2010 12:28:00 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Mon, Mar 22, 2010 at 4:52 AM, Clemens Ladisch clem...@ladisch.de wrote: AMD says in section 2.5.4 (GFX MSI Enable) of #43291 (AMD 780G Family Register Programming Requirements): The SBIOS must enable internal graphics MSI capability in GCCFG by setting the following: NBCFG.NB_CNTL.STRAP_MSI_ENABLE='1' Quite a few BIOS writers misinterpret this sentence and think that enabling MSI is an optional feature. However, clearing that bit just prevents delivery of MSI messages but does not remove the MSI PCI capabilities registers, and so leaves these devices unusable for any driver that attempts to use MSI. Setting that bit is not possible after the BIOS has locked down the configuration registers, so we have to manually disable MSI for the affected devices. This fixes the codec communication errors in the HDA driver when accessing the HDMI audio device, and allows us to get rid of the overcautious quirk in radeon_irq_kms.c. Looks good. This works properly on my rs780. Tested-by: Alex Deucher alexdeuc...@gamil.com Great, applied to my for-linus branch. I'll send it over to Linus this week. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.34-rc2: Reported regressions from 2.6.33
On Sun, 21 Mar 2010, Rafael J. Wysocki wrote: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15495 Subject : Flood of SELinux denials on polkitd Submitter : Alex Villacis Lasso avill...@ceibo.fiec.espol.edu.ec Date : 2010-03-09 16:47 (13 days old) Fixed by commit 3836a03d978e68b0ae00d3589089343c998cd4ff (anon_inodes: mark the anon inode private), I'm pretty sure. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luc Verhaegen wrote: On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote: I've been busy trying to get a release out the door, so I haven't looked at these patches yet. I won't have a chance to look at the patches until at least late next week. I also wasn't at FOSDEM, so I don't have any of the background info. I've grouped the slides and the recordings at the top of my blog entry about this. The patches themselves are actually copies of eachother, with minor differences to adjust for changes of the tree around it (there are 16 or so versions of the sdk done from 7.0 through 7.8). Any actual patch is small, and it is build system only. If these patches try to enforce a stable interface between core Mesa and the classic DRI drivers, we're not interested. At all. This has been discussed and rejected many, many times before. Ah, prepossession. Ask yourself, did the fact that xf86 video drivers were out of tree, ever stop anyone from _really_ bad api breakage stunts? The difference, and I think this is significant, is that the functionality provided by the xf86 video drivers through the X server hasn't changed much in quite some time. The amount of functionality added in every single major release of Mesa which requires driver changes is significant. We're far enough behind the state of the GL spec and the closed-source drivers that I don't really want anything that will slow us down. You can't aim a stable interface at a moving target. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkunq7sACgkQX1gOwKyEAw8dqwCfR9/JjfCecV0Q4Po4AdnJaTOE QrQAoJu1+zMz5shOHrhmOSL+L2um190q =+eep -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27221] Big 3D performance regression and broken textures on R200
http://bugs.freedesktop.org/show_bug.cgi?id=27221 --- Comment #6 from Pauli suok...@gmail.com 2010-03-22 11:38:34 PST --- I tested UrbanTerror with mesa 7.9 and kernel 2.6.34-rc1 (KMS). - No texture problems for me. - ramerates are definedly in slow side but not unplayable. I can have playable (35+ minimum) fps at 800x600 while 1024x768 is close to playable. 1024x768 has problem that minimum fps drops quite a lot (18 fps is lowest that I noticed) sometimes which is not good for shooters. Games is clearly GPU limited (cpufreq is selecting the lowest speed and cpu use stays around 50%). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/4] radeon: perform memory reclocking in atomic context
This is fast enough and rare enough that it's worth making sure that it
happens in the vblank, which means doing it in irq context. The alternative
is visual corruption and potential machine crashes.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/gpu/drm/radeon/r100.c| 26 +-
drivers/gpu/drm/radeon/r600.c| 24
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
drivers/gpu/drm/radeon/rs600.c | 14 ++
5 files changed, 57 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9a7d16b..08e22fe 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -197,11 +197,13 @@ void r100_set_power_state(struct radeon_device *rdev)
/* set memory clock */
if (rdev-asic-set_memory_clock (mclk !=
rdev-pm.current_mclk)) {
- radeon_sync_with_vblank(rdev);
- radeon_pm_debug_check_in_vbl(rdev, false);
- radeon_set_memory_clock(rdev, mclk);
- radeon_pm_debug_check_in_vbl(rdev, true);
- rdev-pm.current_mclk = mclk;
+if (!rdev-pm.active_crtcs) {
+radeon_set_memory_clock(rdev, mclk);
+rdev-pm.current_mclk = mclk;
+} else {
+rdev-pm.new_mclk = mclk;
+}
+radeon_sync_with_vblank(rdev);
DRM_INFO(Setting: m: %d\n, mclk);
}
@@ -485,11 +487,25 @@ int r100_irq_process(struct radeon_device *rdev)
if (status RADEON_CRTC_VBLANK_STAT) {
drm_handle_vblank(rdev-ddev, 0);
rdev-pm.vblank_sync = true;
+ if (rdev-pm.new_mclk) {
+ radeon_pm_debug_check_in_vbl(rdev, false);
+ radeon_set_memory_clock(rdev,
rdev-pm.new_mclk);
+ radeon_pm_debug_check_in_vbl(rdev, true);
+ rdev-pm.current_mclk = rdev-pm.new_mclk;
+ rdev-pm.new_mclk = 0;
+ }
wake_up(rdev-irq.vblank_queue);
}
if (status RADEON_CRTC2_VBLANK_STAT) {
drm_handle_vblank(rdev-ddev, 1);
rdev-pm.vblank_sync = true;
+ if (rdev-pm.new_mclk) {
+ radeon_pm_debug_check_in_vbl(rdev, false);
+ radeon_set_memory_clock(rdev,
rdev-pm.new_mclk);
+ radeon_pm_debug_check_in_vbl(rdev, true);
+ rdev-pm.current_mclk = rdev-pm.new_mclk;
+ rdev-pm.new_mclk = 0;
+ }
wake_up(rdev-irq.vblank_queue);
}
if (status RADEON_FP_DETECT_STAT) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index adc558b..a89821b 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -299,11 +299,13 @@ void r600_set_power_state(struct radeon_device *rdev)
/* set memory clock */
if (rdev-asic-set_memory_clock (mclk !=
rdev-pm.current_mclk)) {
+ if (!rdev-pm.active_crtcs) {
+ radeon_set_memory_clock(rdev, mclk);
+ rdev-pm.current_mclk = mclk;
+ } else {
+ rdev-pm.new_mclk = mclk;
+ }
radeon_sync_with_vblank(rdev);
- radeon_pm_debug_check_in_vbl(rdev, false);
- radeon_set_memory_clock(rdev, mclk);
- radeon_pm_debug_check_in_vbl(rdev, true);
- rdev-pm.current_mclk = mclk;
DRM_INFO(Setting: m: %d\n, mclk);
}
@@ -3020,6 +3022,13 @@ restart_ih:
if (disp_int LB_D1_VBLANK_INTERRUPT) {
drm_handle_vblank(rdev-ddev, 0);
rdev-pm.vblank_sync = true;
+ if (rdev-pm.new_mclk) {
+
radeon_pm_debug_check_in_vbl(rdev, false);
+ radeon_set_memory_clock(rdev,
rdev-pm.new_mclk);
+
radeon_pm_debug_check_in_vbl(rdev, true);
+ rdev-pm.current_mclk =
rdev-pm.new_mclk;
+
[PATCH 4/4] radeon: Run engine reclocking during vblank
Reclocking the engine during screen refresh can cause corruption on some
hardware. Do it during vblank instead, and make sure that we're really
in vblank.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/gpu/drm/radeon/r100.c| 54 +
drivers/gpu/drm/radeon/r600.c| 54 ++
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
4 files changed, 81 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 08e22fe..cdd55b2 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -189,11 +189,14 @@ void r100_set_power_state(struct radeon_device *rdev)
/* reclocking the engine appears to be ok as long as the engine
is idle
* no need for vblank waiting
*/
- if (sclk != rdev-pm.current_sclk) {
- radeon_set_engine_clock(rdev, sclk);
- rdev-pm.current_sclk = sclk;
- DRM_INFO(Setting: e: %d\n, sclk);
- }
+if (sclk != rdev-pm.current_sclk) {
+if (!rdev-pm.active_crtcs) {
+radeon_set_engine_clock(rdev, sclk);
+rdev-pm.current_sclk = sclk;
+} else {
+rdev-pm.new_mclk = sclk;
+}
+}
/* set memory clock */
if (rdev-asic-set_memory_clock (mclk !=
rdev-pm.current_mclk)) {
@@ -461,6 +464,7 @@ int r100_irq_process(struct radeon_device *rdev)
{
uint32_t status, msi_rearm;
bool queue_hotplug = false;
+ int i = 0;
/* reset gui idle ack. the status bit is broken */
rdev-irq.gui_idle_acked = false;
@@ -487,24 +491,44 @@ int r100_irq_process(struct radeon_device *rdev)
if (status RADEON_CRTC_VBLANK_STAT) {
drm_handle_vblank(rdev-ddev, 0);
rdev-pm.vblank_sync = true;
- if (rdev-pm.new_mclk) {
- radeon_pm_debug_check_in_vbl(rdev, false);
- radeon_set_memory_clock(rdev,
rdev-pm.new_mclk);
+ if (rdev-pm.new_mclk || rdev-pm.new_sclk) {
+ while (!radeon_pm_debug_check_in_vbl(rdev,
false) i 100) {
+ udelay(1);
+ i++;
+ }
+ if (i==100) {
+ dev_err(rdev-dev, Failed to sync with
vblank\n);
+ } else if (rdev-pm.new_mclk) {
+ radeon_set_memory_clock(rdev,
rdev-pm.new_mclk);
+ rdev-pm.current_mclk =
rdev-pm.new_mclk;
+ } else if (rdev-pm.new_sclk) {
+ radeon_set_engine_clock(rdev,
rdev-pm.new_sclk);
+ rdev-pm.current_sclk =
rdev-pm.new_sclk;
+ }
radeon_pm_debug_check_in_vbl(rdev, true);
- rdev-pm.current_mclk = rdev-pm.new_mclk;
- rdev-pm.new_mclk = 0;
+ rdev-pm.new_mclk = rdev-pm.new_sclk = 0;
}
wake_up(rdev-irq.vblank_queue);
}
if (status RADEON_CRTC2_VBLANK_STAT) {
drm_handle_vblank(rdev-ddev, 1);
rdev-pm.vblank_sync = true;
- if (rdev-pm.new_mclk) {
- radeon_pm_debug_check_in_vbl(rdev, false);
- radeon_set_memory_clock(rdev,
rdev-pm.new_mclk);
+ if (rdev-pm.new_mclk || rdev-pm.new_sclk) {
+ while (!radeon_pm_debug_check_in_vbl(rdev,
false) i 100) {
+ udelay(1);
+ i++;
+ }
+ if (i==100) {
+ dev_err(rdev-dev, Failed to sync with
vblank\n);
+ } else if (rdev-pm.new_mclk) {
+ radeon_set_memory_clock(rdev,
rdev-pm.new_mclk);
+ rdev-pm.current_mclk =
rdev-pm.new_mclk;
+ } else if (rdev-pm.new_sclk) {
+ radeon_set_engine_clock(rdev,
rdev-pm.new_sclk);
+ rdev-pm.current_sclk =
rdev-pm.new_sclk;
+ }
[PATCH 1/4] radeon: Allow execution of scripts in atomic context
We want to perform radeon memory reclocking in interrupt context, so need
to ensure that we don't do anything that may sleep. Add an alternate
entry point to the atom interpreter that flags things appropriately and
make behaviour conditional on that.
Signed-off-by: Matthew Garrett m...@redhat.com.
---
drivers/gpu/drm/radeon/atom.c | 26 --
drivers/gpu/drm/radeon/atom.h |4 +++-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
3 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 247f8ee..bd5c5b5 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -651,6 +651,8 @@ static void atom_op_delay(atom_exec_context *ctx, int *ptr,
int arg)
SDEBUG( count: %d\n, count);
if (arg == ATOM_UNIT_MICROSEC)
udelay(count);
+ else if (ctx-ctx-atomic)
+ mdelay(count);
else
schedule_timeout_uninterruptible(msecs_to_jiffies(count));
}
@@ -1191,8 +1193,9 @@ static int atom_execute_table_locked(struct atom_context
*ctx, int index, uint32
int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params)
{
int r;
+ unsigned long flags;
- mutex_lock(ctx-mutex);
+ spin_lock_irqsave(ctx-spinlock, flags);
/* reset reg block */
ctx-reg_block = 0;
/* reset fb window */
@@ -1200,7 +1203,26 @@ int atom_execute_table(struct atom_context *ctx, int
index, uint32_t * params)
/* reset io mode */
ctx-io_mode = ATOM_IO_MM;
r = atom_execute_table_locked(ctx, index, params);
- mutex_unlock(ctx-mutex);
+ spin_unlock_irqrestore(ctx-spinlock, flags);
+ return r;
+}
+
+int atom_execute_table_atomic(struct atom_context *ctx, int index, uint32_t *
params)
+{
+ int r;
+ unsigned long flags;
+ spin_lock_irqsave(ctx-spinlock, flags);
+ /* reset reg block */
+ ctx-reg_block = 0;
+ /* reset fb window */
+ ctx-fb_base = 0;
+ /* reset io mode */
+ ctx-io_mode = ATOM_IO_MM;
+ /* be atomic */
+ ctx-atomic = true;
+ r = atom_execute_table_locked(ctx, index, params);
+ ctx-atomic = false;
+ spin_unlock_irqrestore(ctx-spinlock, flags);
return r;
}
diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h
index cd1b64a..c26f5e1 100644
--- a/drivers/gpu/drm/radeon/atom.h
+++ b/drivers/gpu/drm/radeon/atom.h
@@ -121,7 +121,7 @@ struct card_info {
struct atom_context {
struct card_info *card;
- struct mutex mutex;
+ spinlock_t spinlock;
void *bios;
uint32_t cmd_table, data_table;
uint16_t *iio;
@@ -135,12 +135,14 @@ struct atom_context {
int cs_equal, cs_above;
int io_mode;
uint32_t *scratch;
+ bool atomic;
};
extern int atom_debug;
struct atom_context *atom_parse(struct card_info *, void *);
int atom_execute_table(struct atom_context *, int, uint32_t *);
+int atom_execute_table_atomic(struct atom_context *, int, uint32_t *);
int atom_asic_init(struct atom_context *);
void atom_destroy(struct atom_context *);
bool atom_parse_data_header(struct atom_context *ctx, int index, uint16_t
*size,
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 75f7b1e..3a711a9 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -384,7 +384,7 @@ int radeon_atombios_init(struct radeon_device *rdev)
atom_card_info-pll_write = cail_pll_write;
rdev-mode_info.atom_context = atom_parse(atom_card_info, rdev-bios);
- mutex_init(rdev-mode_info.atom_context-mutex);
+ spin_lock_init(rdev-mode_info.atom_context-spinlock);
radeon_atom_initialize_bios_scratch_regs(rdev-ddev);
atom_allocate_fb_scratch(rdev-mode_info.atom_context);
return 0;
--
1.6.5.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] radeon: Reclock r520 memory by hand
The r520 atom tables sleep for long enough that it's impossible to reclock
memory during an interrupt. Implement this by hand instead in order to
avoid the delay.
Signed-off-by: Matthew Garrett m...@redhat.com
---
drivers/gpu/drm/radeon/r500_reg.h|4 ++-
drivers/gpu/drm/radeon/r520.c| 39 ++
drivers/gpu/drm/radeon/radeon.h |2 +
drivers/gpu/drm/radeon/radeon_asic.c |2 +-
drivers/gpu/drm/radeon/radeon_asic.h |3 ++
drivers/gpu/drm/radeon/radeon_atombios.c | 21
drivers/gpu/drm/radeon/radeon_cp.c |2 +-
drivers/gpu/drm/radeon/radeon_drv.h |1 +
drivers/gpu/drm/radeon/radeon_pm.c |8 -
9 files changed, 77 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r500_reg.h
b/drivers/gpu/drm/radeon/r500_reg.h
index 0cf2ad2..b3e798f 100644
--- a/drivers/gpu/drm/radeon/r500_reg.h
+++ b/drivers/gpu/drm/radeon/r500_reg.h
@@ -258,7 +258,7 @@
#defineR520_MC_AGP_TOP_SHIFT 16
#define R520_MC_AGP_BASE 0x06
#define R520_MC_AGP_BASE_2 0x07
-
+#define R520_MC_ARB_RATIO_CLK_SEQ 0x16
#define AVIVO_MC_INDEX 0x0070
#define R520_MC_STATUS 0x00
@@ -279,6 +279,8 @@
# define R520_MEM_NUM_CHANNELS_SHIFT 24
# define R520_MC_CHANNEL_SIZE (1 23)
+#define AVIVO_SPLL_FUNC_CNTL 0x /* PLL */
+#define AVIVO_MPLL_FUNC_CNTL 0x0004 /* PLL */
#define AVIVO_CP_DYN_CNTL 0x000f /* PLL */
# define AVIVO_CP_FORCEON(1 0)
#define AVIVO_E2_DYN_CNTL 0x0011 /* PLL */
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index 870111e..fda7c11 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -26,6 +26,8 @@
* Jerome Glisse
*/
#include drmP.h
+#include radeon_drm.h
+#include radeon_drv.h
#include radeon.h
#include radeon_asic.h
#include atom.h
@@ -127,6 +129,8 @@ void r520_mc_init(struct radeon_device *rdev)
radeon_vram_location(rdev, rdev-mc, 0);
if (!(rdev-flags RADEON_IS_AGP))
radeon_gtt_location(rdev, rdev-mc);
+ rdev-clock.fbdiv =
+ (RADEON_READ_PLL(rdev-ddev, AVIVO_MPLL_FUNC_CNTL) 0x1fe0)
5;
radeon_update_bandwidth_info(rdev);
}
@@ -303,3 +307,38 @@ int r520_init(struct radeon_device *rdev)
}
return 0;
}
+
+void r520_set_memory_clock(struct radeon_device *rdev, uint32_t mem_clock)
+{
+ int mpll, spll, hclk, sclk, fbdiv, index, factor;
+ struct drm_radeon_private *dev_priv = rdev-ddev-dev_private;
+
+ mpll = RADEON_READ_PLL(rdev-ddev, AVIVO_MPLL_FUNC_CNTL);
+ fbdiv = (mpll 0x1fe0) 5;
+
+ /* Set new fbdiv */
+ factor = rdev-clock.default_mclk / mem_clock;
+ fbdiv = rdev-clock.fbdiv / factor;
+
+ mpll = ~0x1fe0;
+ mpll |= ((fbdiv 5) | (1 24));
+ mpll = ~(1 25);
+
+ spll = RADEON_READ_PLL(rdev-ddev, AVIVO_SPLL_FUNC_CNTL);
+
+ hclk = fbdiv 5;
+ hclk += 0x20;
+ hclk *= 8;
+
+ sclk = spll * 0x1fe0;
+ sclk += 0x20;
+ sclk *= 6;
+ sclk = sclk 5;
+
+ index = hclk/sclk;
+
+ R500_WRITE_MCIND(R520_MC_ARB_RATIO_CLK_SEQ,
+rdev-pm.mc_arb_init_values[index]);
+ RADEON_WRITE_PLL(AVIVO_MPLL_FUNC_CNTL, mpll);
+ radeon_atom_initialize_memory_controller(rdev);
+}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ac403e4..d706974 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -163,6 +163,7 @@ struct radeon_clock {
uint32_t default_sclk;
uint32_t default_dispclk;
uint32_t dp_extclk;
+ uint32_t fbdiv;
};
/*
@@ -728,6 +729,7 @@ struct radeon_pm {
u32 current_sclk;
u32 current_mclk;
u32 new_mclk;
+ u32 *mc_arb_init_values;
struct radeon_i2c_chan *i2c_bus;
/* r6xx+ only */
u32 low_simd_mask;
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 1df1e89..80487e0 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -529,7 +529,7 @@ static struct radeon_asic r520_asic = {
.get_engine_clock = radeon_atom_get_engine_clock,
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
- .set_memory_clock = radeon_atom_set_memory_clock,
+ .set_memory_clock = r520_set_memory_clock,
.get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = rv370_set_pcie_lanes,
.set_clock_gating = radeon_atom_set_clock_gating,
diff --git
Re: 2.6.34-rc2: Reported regressions from 2.6.33
On Monday 22 March 2010, Linus Torvalds wrote: On Sun, 21 Mar 2010, Rafael J. Wysocki wrote: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15495 Subject : Flood of SELinux denials on polkitd Submitter : Alex Villacis Lasso avill...@ceibo.fiec.espol.edu.ec Date: 2010-03-09 16:47 (13 days old) Fixed by commit 3836a03d978e68b0ae00d3589089343c998cd4ff (anon_inodes: mark the anon inode private), I'm pretty sure. Thanks, closed. Rafael -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] A tiny problem regarding with the mesa source layout and DRI driver development
On Mon, Mar 22, 2010 at 1:29 PM, LiYe omni.l...@gmail.com wrote: I'm interested in openGL implementation and the DRI driver development. Specifically, I want to learn how an OpenGL command was implemented and how it was converted into direct rendering context and transferred to the hardware. I know this is a quite complicated and time-consuming task, but it would be great if I can start the learning cruve with my newbie background. So I'm trying to look into the mesa codes. However, it seems quite large and monolithic and I cannot find a suitable breaking point. So I wrote this to ask for some experienced advice. For an overview of how DRI works in codes(not in theory as explained in documents), where should I start with? I would suggest getting an IDE that has decent code browsing capabilities (I personally like to play with the KDevelop4 beta even though it's still a bit flaky) and just start stepping through your favourite driver in a debugger. Note that your life will be less painful if you have a second machine from which you can SSH in, so that your gdb session doesn't live on the same X server as the OpenGL application that you're debugging. cu, Nicolai -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen l...@skynet.be wrote: In particular, the Mesa core - classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell. In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel put all the drivers in one repository? So, all of: * drm * firmware * libdrm * xorg * mesa/dri * mesa/gallium * libxvmc * libvdpau (add more here) of the same driver stack, in one repository? Why not? Mind you, I'm not advocating for any change at all, but as long as you feel the need to move stuff around, why not try finding a goal that people actually find useful? Of course, my suggestion is probably crap, too. [snip] The real question is: where is the most pain, and how can we reduce it. And the most pain is between the driver specific parts. Nobody has ever had to feel the pain of a separation between Mesa core and drivers. And since a git log I've just done tells me that you have committed only twice to the Mesa repository within the last year or so, maybe you should listen to the opinion of people who *have* been active in the Mesa tree when it comes to that subject, and are working on drivers that are probably significantly more involved than whatever Unichrome does. 2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs. The kernel people can have theirs. What stops anyone from getting the drm code of a released driver stack into the next kernel version? But when anyone decides they need a new driver stack which requires a new drm module, it should be easy to replace the stock kernel module. And that has worked so well in the past. cu, Nicolai -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Mon, Mar 22, 2010 at 10:46:37PM +0100, Nicolai Haehnle wrote: On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen l...@skynet.be wrote: In particular, the Mesa core - classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell. In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel put all the drivers in one repository? So, all of: * drm * firmware * libdrm * xorg * mesa/dri * mesa/gallium * libxvmc * libvdpau (add more here) of the same driver stack, in one repository? Why not? Mind you, I'm not advocating for any change at all, but as long as you feel the need to move stuff around, why not try finding a goal that people actually find useful? Of course, my suggestion is probably crap, too. Great, seems we agree on something here. [snip] The real question is: where is the most pain, and how can we reduce it. And the most pain is between the driver specific parts. Nobody has ever had to feel the pain of a separation between Mesa core and drivers. And since a git log I've just done tells me that you have committed only twice to the Mesa repository within the last year or so, maybe you should listen to the opinion of people who *have* been active in the Mesa tree when it comes to that subject, and are working on drivers that are probably significantly more involved than whatever Unichrome does. Heh. 2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs. The kernel people can have theirs. What stops anyone from getting the drm code of a released driver stack into the next kernel version? But when anyone decides they need a new driver stack which requires a new drm module, it should be easy to replace the stock kernel module. And that has worked so well in the past. Yes, it did. And people for more than a year still pulled the mesa/drm tree and built and installed it, as doing this often solved their driver stack internal problems for them. Luc Verhaegen. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27211] endless PROTECTION_FAULT logs, Nouveau drm, TNT card
http://bugs.freedesktop.org/show_bug.cgi?id=27211 --- Comment #5 from Brent bzipiti...@hotmail.com 2010-03-22 17:40:00 PST --- Thank you for that clarification. To /etc/modprobe.d/modprobe.conf, I added this line: options nouveau noaccel=1 And now I can use the Nouveau driver. Both the text screen and the graphics screen work. Also had to make a config file for X to stop it from defaulting to vesa, with xorg --config. I have HAL running, and seems without any config file, X tries for the nv driver first, then fbdev, then vesa. X is now using Nouveau. A clarification of my original report. The computer did finish booting up. I just couldn't tell because the text screen was blank, the disk never quit spinning, and I was still setting up the system and hadn't yet switched to runlevel 5. So long as it was trying to display the text screen, those errors were being logged. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
