[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23670





--- Comment #6 from Shuang He shuang...@intel.com  2009-09-08 23:01:02 PST ---
(In reply to comment #5)
 (In reply to comment #4)
  Could you provide more details about the failing cases (maybe run conform 
  with
  -v 2)?  It looks like the failures are related to glCopyPixels(GL_DEPTH) and
  glDrawPixels(GL_DEPTH_COMPONENT) with pixel transfer ops.  I've tested those
  cases here with other test programs and found that
  glPixelTransfer(GL_DEPTH_SCALE/BIAS) works properly.
  
 
 For OGLC/copypix.c, it fails with glDrawPixels(GL_STENCIL_INDEX) and
 glCopyPixels(GL_STENCIL)
 

For OGLC/apfunc.c, it fails with glDrawPixels(GL_DEPTH_COMPONENT), with alpha
test enabled

OGLC/zbfunc.c fails with glDrawPixels(GL_RGBA, GL_FLOAT), with DEPTH func set
to GL_ALWAYS

And there's also other OGLC cases (like api-rasterpos.c, depthwrite.c,
spopTwoSided.c), seems to be impacted


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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

[PATCH] drm/radeon/kms: add initial connector properties

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This adds:
coherent mode: TMDS coherent mode for atom cards.
scaling mode: LVDS scaler mode
load detect: DAC load detection, DVI-I, VGA, TV
tmds pll: legacy TMDS pll selection
tv standard: TV standard selection.

TODO: other TV ones? dvi subconnector selection using std prop

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_atombios.c|   15 +-
 drivers/gpu/drm/radeon/radeon_combios.c |   48 +++--
 drivers/gpu/drm/radeon/radeon_connectors.c  |  241 ---
 drivers/gpu/drm/radeon/radeon_display.c |   81 
 drivers/gpu/drm/radeon/radeon_encoders.c|   10 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   29 +++-
 drivers/gpu/drm/radeon/radeon_mode.h|   20 ++-
 7 files changed, 379 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index a8fb392..aeebae1 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -702,9 +702,8 @@ bool radeon_atom_get_clock_info(struct drm_device *dev)
return false;
 }
 
-struct radeon_encoder_int_tmds *radeon_atombios_get_tmds_info(struct
- radeon_encoder
- *encoder)
+bool radeon_atombios_get_tmds_info(struct radeon_encoder *encoder,
+  struct radeon_encoder_int_tmds *tmds)
 {
struct drm_device *dev = encoder-base.dev;
struct radeon_device *rdev = dev-dev_private;
@@ -715,7 +714,6 @@ struct radeon_encoder_int_tmds 
*radeon_atombios_get_tmds_info(struct
uint8_t frev, crev;
uint16_t maxfreq;
int i;
-   struct radeon_encoder_int_tmds *tmds = NULL;
 
atom_parse_data_header(mode_info-atom_context, index, NULL, frev,
   crev, data_offset);
@@ -725,12 +723,6 @@ struct radeon_encoder_int_tmds 
*radeon_atombios_get_tmds_info(struct
   data_offset);
 
if (tmds_info) {
-   tmds =
-   kzalloc(sizeof(struct radeon_encoder_int_tmds), GFP_KERNEL);
-
-   if (!tmds)
-   return NULL;
-
maxfreq = le16_to_cpu(tmds_info-usMaxFrequency);
for (i = 0; i  4; i++) {
tmds-tmds_pll[i].freq =
@@ -756,8 +748,9 @@ struct radeon_encoder_int_tmds 
*radeon_atombios_get_tmds_info(struct
break;
}
}
+   return true;
}
-   return tmds;
+   return false;
 }
 
 union lvds_info {
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 2a027e0..e2ad8f7 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -994,48 +994,37 @@ static const struct radeon_tmds_pll 
default_tmds_pll[CHIP_LAST][4] = {
{{15000, 0xb0155}, {0x, 0xb01cb}, {0, 0}, {0, 0}},  /* 
CHIP_RS480 */
 };
 
-static struct radeon_encoder_int_tmds
-*radeon_legacy_get_tmds_info_from_table(struct radeon_device *rdev)
+bool radeon_legacy_get_tmds_info_from_table(struct radeon_encoder *encoder,
+   struct radeon_encoder_int_tmds 
*tmds)
 {
+   struct drm_device *dev = encoder-base.dev;
+   struct radeon_device *rdev = dev-dev_private;
int i;
-   struct radeon_encoder_int_tmds *tmds = NULL;
-
-   tmds = kzalloc(sizeof(struct radeon_encoder_int_tmds), GFP_KERNEL);
-
-   if (!tmds)
-   return NULL;
 
for (i = 0; i  4; i++) {
tmds-tmds_pll[i].value =
-   default_tmds_pll[rdev-family][i].value;
+   default_tmds_pll[rdev-family][i].value;
tmds-tmds_pll[i].freq = default_tmds_pll[rdev-family][i].freq;
}
 
-   return tmds;
+   return true;
 }
 
-struct radeon_encoder_int_tmds *radeon_combios_get_tmds_info(struct
-radeon_encoder
-*encoder)
+bool radeon_legacy_get_tmds_info_from_combios(struct radeon_encoder *encoder,
+ struct radeon_encoder_int_tmds 
*tmds)
 {
struct drm_device *dev = encoder-base.dev;
struct radeon_device *rdev = dev-dev_private;
uint16_t tmds_info;
int i, n;
uint8_t ver;
-   struct radeon_encoder_int_tmds *tmds = NULL;
 
if (rdev-bios == NULL)
-   return radeon_legacy_get_tmds_info_from_table(rdev);
-
+   return false;
+   
tmds_info = combios_get_table_offset(dev, COMBIOS_DFP_INFO_TABLE);
 
if (tmds_info) {
-   tmds =
-   

Power management in KMS

[Rafał Miłecki]

I'm thinking of organizing power management in KMS. There are my
ideas, would like to get your opinions.

First of all we need a few different power modes. I think radeonhd has
nice states for that:
1) OFF /* DPMS off */
2) IDLE /* DPMS on, no activity for some time */
3) SLOW_2D /* Simple 2D activity */
4) FAST_2D /* Advanced 2D activity, e.g. video playback */
5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select?
indirect rendering only? */
6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default
AtomBIOS setting. */
7) MAX /* Use theoretical chip maximum, maybe beyond default - not
selected automatically */

Filling states with engine/memory/voltage values can be grabbed from radeonhd.

About setting states I see 3 ways:

1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm().
That function asks 2D engine, 3D engine and DPMS for current state and
pickups the best solution.
Implementation:
We have to introduce radeon_state_of_2d(), radeon_state_of_3d(),
radeon_state_of_dpms().

2) From every part (2D, 3D, DPMS) we call setting function with proper
argument. Examples:
3D engine calls radeon_set_pm(FAST_3D);
2D engine calls radeon_set_pm(SLOW_2D);
DPMS calls radeon_set_pm(IDLE);
DPMS calls radeon_set_pm(WAKE_UP);
Implementation:
We have to store each element's state in our power manager. If we get
SLOW_2D, but FAST_3D is still running, we can not downclock.

3) We have some state properties in radeon_device and every patch
calls generic function radeon_pikcup_pm().
Implementation:
We have to create some rdev-state_of_2d, rdev-state_of_3d,
rdev-state_of_dpms, and use that in radeon_pikcup_pm().

Personally I'm for third method.

Do you have some comments? Preferred method? Suggestions?

-- 
Rafał

--
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: Power management in KMS

[Jerome Glisse]

On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote:
 I'm thinking of organizing power management in KMS. There are my
 ideas, would like to get your opinions.
 
 First of all we need a few different power modes. I think radeonhd has
 nice states for that:
 1) OFF /* DPMS off */
 2) IDLE /* DPMS on, no activity for some time */
 3) SLOW_2D /* Simple 2D activity */
 4) FAST_2D /* Advanced 2D activity, e.g. video playback */
 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select?
 indirect rendering only? */
 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default
 AtomBIOS setting. */
 7) MAX /* Use theoretical chip maximum, maybe beyond default - not
 selected automatically */
 
 Filling states with engine/memory/voltage values can be grabbed from radeonhd.
 
 About setting states I see 3 ways:
 
 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm().
 That function asks 2D engine, 3D engine and DPMS for current state and
 pickups the best solution.
 Implementation:
 We have to introduce radeon_state_of_2d(), radeon_state_of_3d(),
 radeon_state_of_dpms().
 
 2) From every part (2D, 3D, DPMS) we call setting function with proper
 argument. Examples:
 3D engine calls radeon_set_pm(FAST_3D);
 2D engine calls radeon_set_pm(SLOW_2D);
 DPMS calls radeon_set_pm(IDLE);
 DPMS calls radeon_set_pm(WAKE_UP);
 Implementation:
 We have to store each element's state in our power manager. If we get
 SLOW_2D, but FAST_3D is still running, we can not downclock.
 
 3) We have some state properties in radeon_device and every patch
 calls generic function radeon_pikcup_pm().
 Implementation:
 We have to create some rdev-state_of_2d, rdev-state_of_3d,
 rdev-state_of_dpms, and use that in radeon_pikcup_pm().
 
 Personally I'm for third method.
 
 Do you have some comments? Preferred method? Suggestions?
 

I have been thinking to PM too, getting hint from userspace is i believe
somethings we want, how this hint should be given needs more discussion,
i was thinking to either use a score (like 100 give me full power, ...)
or using asic specific level more or like what you propose with 2donly,
fast2d,3d, ... but which would be asic specific because on some asic
some stuff doesn't exist (like 2d doesn't on new hw).

From implementation pov i would like to merge all powermanagement we
have now into a single callback function, of course reussing common
sub functions accross asics. Basicly i want to shrink down the number
of callback as i think it became harder to follow what's happening on
a given asic. So it would be somethings like radeon_pm and each asic
would have it's own function (well some asic will likely share one
like r3xx  r4xx).

Cheers,
Jerome


--
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: Power management in KMS

[Rafał Miłecki]

It's about radeon's KMS and PM of course, sorry for not specifing.


W dniu 9 września 2009 10:50 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
 I'm thinking of organizing power management in KMS. There are my
 ideas, would like to get your opinions.

 First of all we need a few different power modes. I think radeonhd has
 nice states for that:
 1) OFF /* DPMS off */
 2) IDLE /* DPMS on, no activity for some time */
 3) SLOW_2D /* Simple 2D activity */
 4) FAST_2D /* Advanced 2D activity, e.g. video playback */
 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select?
 indirect rendering only? */
 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default
 AtomBIOS setting. */
 7) MAX /* Use theoretical chip maximum, maybe beyond default - not
 selected automatically */

 Filling states with engine/memory/voltage values can be grabbed from radeonhd.

 About setting states I see 3 ways:

 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm().
 That function asks 2D engine, 3D engine and DPMS for current state and
 pickups the best solution.
 Implementation:
 We have to introduce radeon_state_of_2d(), radeon_state_of_3d(),
 radeon_state_of_dpms().

 2) From every part (2D, 3D, DPMS) we call setting function with proper
 argument. Examples:
 3D engine calls radeon_set_pm(FAST_3D);
 2D engine calls radeon_set_pm(SLOW_2D);
 DPMS calls radeon_set_pm(IDLE);
 DPMS calls radeon_set_pm(WAKE_UP);
 Implementation:
 We have to store each element's state in our power manager. If we get
 SLOW_2D, but FAST_3D is still running, we can not downclock.

 3) We have some state properties in radeon_device and every patch
 calls generic function radeon_pikcup_pm().
 Implementation:
 We have to create some rdev-state_of_2d, rdev-state_of_3d,
 rdev-state_of_dpms, and use that in radeon_pikcup_pm().

 Personally I'm for third method.

 Do you have some comments? Preferred method? Suggestions?

Dave linked me to
http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/drm-radeon-pm.patch?revision=1.2.6.2view=markup

This patch uses timer to check if nothing has been rendered for some
time. That would be quite close to first solution.

-- 
Rafał Miłecki

--
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: Power management in KMS

[Pauli Nieminen]

2009/9/9 Jerome Glisse gli...@freedesktop.org

 On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote:
  I'm thinking of organizing power management in KMS. There are my
  ideas, would like to get your opinions.
 
  First of all we need a few different power modes. I think radeonhd has
  nice states for that:
  1) OFF /* DPMS off */
  2) IDLE /* DPMS on, no activity for some time */
  3) SLOW_2D /* Simple 2D activity */
  4) FAST_2D /* Advanced 2D activity, e.g. video playback */
  5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select?
  indirect rendering only? */
  6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default
  AtomBIOS setting. */
  7) MAX /* Use theoretical chip maximum, maybe beyond default - not
  selected automatically */
 
  Filling states with engine/memory/voltage values can be grabbed from
 radeonhd.
 
  About setting states I see 3 ways:
 
  1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm().
  That function asks 2D engine, 3D engine and DPMS for current state and
  pickups the best solution.
  Implementation:
  We have to introduce radeon_state_of_2d(), radeon_state_of_3d(),
  radeon_state_of_dpms().
 
  2) From every part (2D, 3D, DPMS) we call setting function with proper
  argument. Examples:
  3D engine calls radeon_set_pm(FAST_3D);
  2D engine calls radeon_set_pm(SLOW_2D);
  DPMS calls radeon_set_pm(IDLE);
  DPMS calls radeon_set_pm(WAKE_UP);
  Implementation:
  We have to store each element's state in our power manager. If we get
  SLOW_2D, but FAST_3D is still running, we can not downclock.
 
  3) We have some state properties in radeon_device and every patch
  calls generic function radeon_pikcup_pm().
  Implementation:
  We have to create some rdev-state_of_2d, rdev-state_of_3d,
  rdev-state_of_dpms, and use that in radeon_pikcup_pm().
 
  Personally I'm for third method.
 
  Do you have some comments? Preferred method? Suggestions?
 

 I have been thinking to PM too, getting hint from userspace is i believe
 somethings we want, how this hint should be given needs more discussion,
 i was thinking to either use a score (like 100 give me full power, ...)
 or using asic specific level more or like what you propose with 2donly,
 fast2d,3d, ... but which would be asic specific because on some asic
 some stuff doesn't exist (like 2d doesn't on new hw).

 From implementation pov i would like to merge all powermanagement we
 have now into a single callback function, of course reussing common
 sub functions accross asics. Basicly i want to shrink down the number
 of callback as i think it became harder to follow what's happening on
 a given asic. So it would be somethings like radeon_pm and each asic
 would have it's own function (well some asic will likely share one
 like r3xx  r4xx).

 Cheers,
 Jerome


This will need separate hint for PCIE-lanes, memory and engine because some
applications might transfer large amount of data with very little processing
(xv?) while some applications could do complex stuff in GPU and use very
little memory bandwidth (OpenCL?).
--
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: Power management in KMS

[Rafał Miłecki]

W dniu 9 września 2009 11:10 użytkownik Jerome Glisse
gli...@freedesktop.org napisał:
 I have been thinking to PM too, getting hint from userspace is i believe
 somethings we want, how this hint should be given needs more discussion,
 i was thinking to either use a score (like 100 give me full power, ...)
 or using asic specific level more or like what you propose with 2donly,
 fast2d,3d, ... but which would be asic specific because on some asic
 some stuff doesn't exist (like 2d doesn't on new hw).

You should really clarify this :) I thought you want to have whole PM
in KMS controlled by user space app.

Hope I can quote you selecting just 3 sentences:
glissemjg59: i am not saying that kernel should not do thing on it's 
own
glissekernel should powerdown when it has good reasons to do so
glissei am all for saving power
So if I understand you correctly, you just want to have alternative
way of forcing some low power mode (from user space app). I think it's
totally fine, just as long as it's additional method on control and
base power control is in KMS.

-- 
Rafał

--
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: Power management in KMS

[Rafał Miłecki]

W dniu 9 września 2009 11:10 użytkownik Jerome Glisse
gli...@freedesktop.org napisał:
 I have been thinking to PM too, getting hint from userspace is i believe
 somethings we want, how this hint should be given needs more discussion,
 i was thinking to either use a score (like 100 give me full power, ...)
 or using asic specific level more or like what you propose with 2donly,
 fast2d,3d, ... but which would be asic specific because on some asic
 some stuff doesn't exist (like 2d doesn't on new hw).

It's more about power level, not reference to used hardware blocks.

I get it like Use power level that is enough for rendering 2D. So
it's still valid for r6xx/r7xx.

-- 
Rafał

--
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

[Bug 23812] New: links2 triggers a lockdep trace in drm-next with KMS on

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23812

   Summary: links2 triggers a lockdep trace in drm-next with KMS on
   Product: DRI
   Version: DRI CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: astralst...@gen2.org


Created an attachment (id=29350)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29350)
Lockdep trace

Links2 (the text/low-graphic browser) with framebuffer support on triggers the
attached lockdep trace when exiting.
Both KMS and links2 work correctly afterwards.

KMS is enabled and working, drm-next commit
cecc6b63a5de547a345c491bb4c18c01a15984a4
The card is RV670, Mobility Radeon HD3850.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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

[Bug 23017] Direct color dri windowed visual is causing causing full black screen

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23017





--- Comment #11 from Stefan Dirsch sndir...@suse.de  2009-09-09 08:09:40 PST 
---
The glxgears issue is fixed in Mesa 7.5.1. Not sure if by accident or by
intention though.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

--
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

[Bug 23337] glxgears blanks the screen when window is focused (regression Mesa 7.4.4 -- 7.5)

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23337





--- Comment #4 from Stefan Dirsch sndir...@suse.de  2009-09-09 08:09:35 PST 
---
The issue is fixed in Mesa 7.5.1. Not sure if by accident or by intention
though.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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: Power management in KMS

[Matthew Garrett]

For the most part, the driver should just implement sensible power 
management itself. We don't want users to have to define complex power 
management policies. In almost every case, if the user triggers a 
graphics operation then they want it to complete as quickly as possible. 
Autmatically upclocking in response to this is pretty easy on most 
hardware. The only real problem comes with reclocking RAM on a 
multi-head system. This has to be done during the vblank interval to 
avoid data corruption, but syncing the vblanks on both displays may well 
be difficult or impossible.

There's a small number of cases where we can't reconfigure a power 
management state on the fly - the number of PCIe lanes is an example of 
this. Changing it simply takes too long, and we drop several frames in 
the process. The right kind of interface for that does require some 
thought.

-- 
Matthew Garrett | mj...@srcf.ucam.org

--
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

[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23670





--- Comment #7 from Brian Paul brian.e.p...@gmail.com  2009-09-09 08:43:00 
PST ---
Created an attachment (id=29352)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29352)
another patch for meta.c (IndexOffset/Bias check)

Can you see if this patch helps with the glDrawPixels(GL_STENCIL_INDEX) cases?

Also, the -v 2 output would be helpful.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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: Power management in KMS

[Michel Dänzer]

On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: 
 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select?
 indirect rendering only? */

FWIW: No, compiz (and any other GLX compositing manager, for that
matter) works with direct rendering with DRI2.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
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

[Bug 23816] New: 32bit mesa on 64bit os won't load r600_dri.so due to bad magic

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23816

   Summary: 32bit mesa on 64bit os won't load r600_dri.so due to bad
magic
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: kdeko...@yahoo.com


First the working case.

Using 64 bit Fedora 11 Kernel
radeon kernel modules from agd5f's r600 branch
libdrm from git compile without experimental apis in both 32bit and 64bit
binaries
mesa from git in both 32bit and 64bit binaries
ddx from git

With this setup I can get 64bit and 32bit hardware accelerated 3d, most things
work well.

I tried to do the same thing with the following

drm-next kernel 2.6.31-rc9
libdrm from git compiled with experimentals api in both 32bit and 64bin
binaries
mesa from git in both 32bit and 64bit binaries
ddx from git

mesa in 64bit mode works well. applications run accelerated with no problem.
mesa in 32bit mode fails

LIBGL_DEBUG=verbose gears
libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
libGL error: failed to get magic
libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so

file /usr/lib/dri/r600_dri.so
/usr/lib/dri/r600_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), dynamically linked, not stripped

also I see in my dmesg

ioctl32(gears:4095): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4} arg(ff8ea6cc)
on /dev/dri/card0

Looks to me like the 32bit mesa is not properly getting the cmd to the 64bit
drm in the kernel.

Since I am in Fedora, I am not running 32bit apps in a chroot. 32bit libs are
in /usr/lib and 64bit libs are in /usr/lib64.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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

[Bug 23017] Direct color dri windowed visual is causing causing full black screen

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23017





--- Comment #12 from Michel Dänzer mic...@daenzer.net  2009-09-09 09:16:08 
PST ---
(In reply to comment #11)
 The glxgears issue is fixed in Mesa 7.5.1. Not sure if by accident or by
 intention though.

See the reference to bug 23337 in comment #10. :)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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

[Bug 23785] NWN crashes after loading or starting game

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23785





--- Comment #2 from Nicolai Hähnle nhaeh...@gmail.com  2009-09-09 09:18:37 
PST ---
Thank you for the report.

Could you try running with the environment variable RADEON_DEBUG=vert set?
Warning, this will produce a huge amount of output. Only the last lines before
the crash are interesting (they will contain a dump of the vertex program which
we attempted to compile).

I don't have NWN here, and it would make it easier to understand what's going
wrong.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
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

[Bug 23337] glxgears blanks the screen when window is focused (regression Mesa 7.4.4 -- 7.5)

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23337


Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED




--- Comment #5 from Michel Dänzer mic...@daenzer.net  2009-09-09 09:18:03 PST 
---
Not a duplicate, fixed in 7.5.1 and Git mesa_7_4_branch.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
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: Power management in KMS

[Rafał Miłecki]

W dniu 9 września 2009 17:57 użytkownik Michel Dänzer
mic...@daenzer.net napisał:
 On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote:
 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select?
 indirect rendering only? */

 FWIW: No, compiz (and any other GLX compositing manager, for that
 matter) works with direct rendering with DRI2.

That are comments from radeonhd driver, which doesn't support DRI2. I
hope we will find some way to determine if we need speed for SLOW of
FAST 3D.

-- 
Rafał

--
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: Power management in KMS

[Alex Deucher]

I also think it should mostly be handled in the driver.  About the
only knobs we may want to enable userspace to mess with are say 3
power modes: low power (battery mode), default, and maybe a high power
mode later on.  The high power mode may require thermal monitoring
support depending on the chip.  GPM (and whatever kde uses) or the
user can then change the mode on the fly in reaction to events like AC
- DC, etc.; much like what is done for backlights now.

The driver itself would then handle the power state transitions based
on the selection from userspace.  For example, if the low power state
was selected, the driver would limit the max clocks and voltages based
on that.  As Matthew mentioned, the driver would adjust the engine
clock on the fly when commands come in, and then downclock again after
a certain period.  There would also be an idle mode where everything
would be down to the minimum (i.e., crtcs off, engines idle, etc.).
In that case we could drop the clocks and pcie lanes to the lowest
level.

I don't think there is really any need for 2D vs. 3D mode as most of
the useful 2D accel uses the 3D engine anyway.  So whenever we see
commands come in, we should treat it the same; upclock to the limit
imposed by the currently selected mode.

The power tables in the bios could be used for setting limits and
usable combinations (the hw can be picky about what combinations of
sclks and mclks modes it likes) and for getting the idle (and possibly
suspend) power modes.

Mem clocks and pcie lanes are trickier since you need to make sure you
have enough bandwidth available to supply all currently active clients
(displays, 2D, 3D, overlays, etc.).  It probably makes sense to only
adjust them during a mode set or a forced power state or the idle
state.  These require some more thought.  Driver hints may be useful
here.

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

[Bug 23785] NWN crashes after loading or starting game

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23785





--- Comment #3 from Nicolai Hähnle nhaeh...@gmail.com  2009-09-09 11:00:18 
PST ---
Created an attachment (id=29354)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29354)
Potential patch?

Okay, after actually looking at what the line of code actually does, here's a
potential (untested) patch that could fix it. Might be just an extremely silly
bug after all.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
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

[PATCH] drm/radeon/kms: wait for cp idle before stopping it.

[Jerome Glisse]

If we stop CP and that it's still processing thing GPU hang might
happen, this patch wait for CP idle (the wait can timeout) so we
can avoid shutting down CP at bad time. This is especialy usefull
when reseting the GPU as it seems GPU reset fails to properly reset
CP when the CP wasn't stop after being idle.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r100.c  |   18 
 drivers/gpu/drm/radeon/r100d.h |   60 
 2 files changed, 78 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4ceb675..4dd5ca5 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -490,6 +490,21 @@ int r100_copy_blit(struct radeon_device *rdev,
 /*
  * CP
  */
+static int r100_cp_wait_for_idle(struct radeon_device *rdev)
+{
+   unsigned i;
+   u32 tmp;
+
+   for (i = 0; i  rdev-usec_timeout; i++) {
+   tmp = RREG32(R_000E40_RBBM_STATUS);
+   if (!G_000E40_CP_CMDSTRM_BUSY(tmp)) {
+   return 0;
+   }
+   udelay(1);
+   }
+   return -1;
+}
+
 void r100_ring_start(struct radeon_device *rdev)
 {
int r;
@@ -718,6 +733,9 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
 
 void r100_cp_fini(struct radeon_device *rdev)
 {
+   if (r100_cp_wait_for_idle(rdev)) {
+   DRM_ERROR(Wait for CP idle timeout, shutting down CP.\n);
+   }
/* Disable ring */
r100_cp_disable(rdev);
radeon_ring_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r100d.h b/drivers/gpu/drm/radeon/r100d.h
index 6da7d92..1d951ab 100644
--- a/drivers/gpu/drm/radeon/r100d.h
+++ b/drivers/gpu/drm/radeon/r100d.h
@@ -73,4 +73,64 @@
 #define CP_PACKET0_GET_ONE_REG_WR(h) (((h)  15)  1)
 #define CP_PACKET3_GET_OPCODE(h) (((h)  8)  0xFF)
 
+/* Registers */
+#define R_000E40_RBBM_STATUS 0x000E40
+#define   S_000E40_CMDFIFO_AVAIL(x)(((x)  0x7F)  0)
+#define   G_000E40_CMDFIFO_AVAIL(x)(((x)  0)  0x7F)
+#define   C_000E40_CMDFIFO_AVAIL   0xFF80
+#define   S_000E40_HIRQ_ON_RBB(x)  (((x)  0x1)  8)
+#define   G_000E40_HIRQ_ON_RBB(x)  (((x)  8)  0x1)
+#define   C_000E40_HIRQ_ON_RBB 0xFEFF
+#define   S_000E40_CPRQ_ON_RBB(x)  (((x)  0x1)  9)
+#define   G_000E40_CPRQ_ON_RBB(x)  (((x)  9)  0x1)
+#define   C_000E40_CPRQ_ON_RBB 0xFDFF
+#define   S_000E40_CFRQ_ON_RBB(x)  (((x)  0x1)  10)
+#define   G_000E40_CFRQ_ON_RBB(x)  (((x)  10)  0x1)
+#define   C_000E40_CFRQ_ON_RBB 0xFBFF
+#define   S_000E40_HIRQ_IN_RTBUF(x)(((x)  0x1)  11)
+#define   G_000E40_HIRQ_IN_RTBUF(x)(((x)  11)  0x1)
+#define   C_000E40_HIRQ_IN_RTBUF   0xF7FF
+#define   S_000E40_CPRQ_IN_RTBUF(x)(((x)  0x1)  12)
+#define   G_000E40_CPRQ_IN_RTBUF(x)(((x)  12)  0x1)
+#define   C_000E40_CPRQ_IN_RTBUF   0xEFFF
+#define   S_000E40_CFRQ_IN_RTBUF(x)(((x)  0x1)  13)
+#define   G_000E40_CFRQ_IN_RTBUF(x)(((x)  13)  0x1)
+#define   C_000E40_CFRQ_IN_RTBUF   0xDFFF
+#define   S_000E40_CF_PIPE_BUSY(x) (((x)  0x1)  14)
+#define   G_000E40_CF_PIPE_BUSY(x) (((x)  14)  0x1)
+#define   C_000E40_CF_PIPE_BUSY0xBFFF
+#define   S_000E40_ENG_EV_BUSY(x)  (((x)  0x1)  15)
+#define   G_000E40_ENG_EV_BUSY(x)  (((x)  15)  0x1)
+#define   C_000E40_ENG_EV_BUSY 0x7FFF
+#define   S_000E40_CP_CMDSTRM_BUSY(x)  (((x)  0x1)  16)
+#define   G_000E40_CP_CMDSTRM_BUSY(x)  (((x)  16)  0x1)
+#define   C_000E40_CP_CMDSTRM_BUSY 0xFFFE
+#define   S_000E40_E2_BUSY(x)  (((x)  0x1)  17)
+#define   G_000E40_E2_BUSY(x)  (((x)  17)  0x1)
+#define   C_000E40_E2_BUSY 0xFFFD
+#define   S_000E40_RB2D_BUSY(x)(((x)  0x1)  18)
+#define   G_000E40_RB2D_BUSY(x)(((x)  18)  0x1)
+#define   C_000E40_RB2D_BUSY   0xFFFB
+#define   S_000E40_RB3D_BUSY(x)(((x)  0x1)  19)
+#define   G_000E40_RB3D_BUSY(x)(((x)  19)  0x1)
+#define   C_000E40_RB3D_BUSY   0xFFF7
+#define   S_000E40_SE_BUSY(x)  (((x)  0x1)  20)
+#define   G_000E40_SE_BUSY(x)  (((x)  20)  0x1)
+#define   C_000E40_SE_BUSY 0xFFEF
+#define   S_000E40_RE_BUSY(x)  

[PATCH] drm/radeon/kms: R3XX/R4XX AGP asic use PCI GART not PCIE GART

[Jerome Glisse]

R3XX/R4XX AGP asic use the old PCI GART block, not the new PCIE GART.
Make sure we pick the right GART when disabling AGP.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r300.c  |6 ++
 drivers/gpu/drm/radeon/r420.c  |9 +++--
 drivers/gpu/drm/radeon/radeon.h|4 
 drivers/gpu/drm/radeon/radeon_device.c |5 +
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index a5f82f7..9c17b78 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -181,6 +181,12 @@ int r300_gart_enable(struct radeon_device *rdev)
rdev-asic-gart_set_page = rv370_pcie_gart_set_page;
return rv370_pcie_gart_enable(rdev);
}
+   if (rdev-flags  RADEON_IS_PCI) {
+   rdev-asic-gart_disable = r100_pci_gart_disable;
+   rdev-asic-gart_tlb_flush = r100_pci_gart_tlb_flush;
+   rdev-asic-gart_set_page = r100_pci_gart_set_page;
+   return r100_pci_gart_enable(rdev);
+   }
return r100_pci_gart_enable(rdev);
 }
 
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 97426a6..029cee2 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -100,8 +100,13 @@ int r420_mc_init(struct radeon_device *rdev)
 
 void r420_mc_fini(struct radeon_device *rdev)
 {
-   rv370_pcie_gart_disable(rdev);
-   radeon_gart_table_vram_free(rdev);
+   if (rdev-flags  RADEON_IS_PCIE) {
+   rv370_pcie_gart_disable(rdev);
+   radeon_gart_table_vram_free(rdev);
+   } else {
+   r100_pci_gart_disable(rdev);
+   radeon_gart_table_ram_free(rdev);
+   }
radeon_gart_fini(rdev);
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 24574bc..fe86b20 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -935,5 +935,9 @@ static inline void radeon_ring_write(struct radeon_device 
*rdev, uint32_t v)
 
 /* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */
 void r100_cp_disable(struct radeon_device *rdev);
+void r100_pci_gart_disable(struct radeon_device *rdev);
+int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+int r100_pci_gart_enable(struct radeon_device *rdev);
+void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
 
 #endif
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index f2469c5..da8646a 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -499,10 +499,7 @@ int radeon_device_init(struct radeon_device *rdev,
 
if (radeon_agpmode == -1) {
rdev-flags = ~RADEON_IS_AGP;
-   if (rdev-family  CHIP_RV515 ||
-   rdev-family == CHIP_RV380 ||
-   rdev-family == CHIP_RV410 ||
-   rdev-family == CHIP_R423) {
+   if (rdev-family = CHIP_RV515) {
DRM_INFO(Forcing AGP to PCIE mode\n);
rdev-flags |= RADEON_IS_PCIE;
} else {
-- 
1.6.4.1


--
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

[PATCH] drm/radeon/kms: add R4XX mc register access helper.

[Jerome Glisse]

Atombios will use the mc register access helper and R4XX hw have a
bigger mc range than R3XX so add R4XX specific mc register access
helper.

igned-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r420.c  |   17 
 drivers/gpu/drm/radeon/r420d.h |   43 
 drivers/gpu/drm/radeon/radeon.h|4 +++
 drivers/gpu/drm/radeon/radeon_device.c |4 +++
 4 files changed, 68 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/r420d.h

diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 029cee2..551d699 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -29,6 +29,7 @@
 #include drmP.h
 #include radeon_reg.h
 #include radeon.h
+#include r420d.h
 
 /* r420,r423,rv410 depends on : */
 void r100_pci_gart_disable(struct radeon_device *rdev);
@@ -237,3 +238,19 @@ int r420_debugfs_pipes_info_init(struct radeon_device 
*rdev)
return 0;
 #endif
 }
+
+u32 r420_mc_rreg(struct radeon_device *rdev, u32 reg)
+{
+   u32 r;
+
+   WREG32(R_0001F8_MC_IND_INDEX, S_0001F8_MC_IND_ADDR(reg));
+   r = RREG32(R_0001FC_MC_IND_DATA);
+   return r;
+}
+
+void r420_mc_wreg(struct radeon_device *rdev, u32 reg, u32 v)
+{
+   WREG32(R_0001F8_MC_IND_INDEX, S_0001F8_MC_IND_ADDR(reg) |
+   S_0001F8_MC_IND_WR_EN(1));
+   WREG32(R_0001FC_MC_IND_DATA, v);
+}
diff --git a/drivers/gpu/drm/radeon/r420d.h b/drivers/gpu/drm/radeon/r420d.h
new file mode 100644
index 000..8b946c1
--- /dev/null
+++ b/drivers/gpu/drm/radeon/r420d.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2008 Advanced Micro Devices, Inc.
+ * Copyright 2008 Red Hat Inc.
+ * Copyright 2009 Jerome Glisse.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Dave Airlie
+ *  Alex Deucher
+ *  Jerome Glisse
+ */
+#ifndef R420D_H
+#define R420D_H
+
+#define R_0001F8_MC_IND_INDEX0x0001F8
+#define   S_0001F8_MC_IND_ADDR(x)  (((x)  0x7F)  0)
+#define   G_0001F8_MC_IND_ADDR(x)  (((x)  0)  0x7F)
+#define   C_0001F8_MC_IND_ADDR 0xFF80
+#define   S_0001F8_MC_IND_WR_EN(x) (((x)  0x1)  8)
+#define   G_0001F8_MC_IND_WR_EN(x) (((x)  8)  0x1)
+#define   C_0001F8_MC_IND_WR_EN0xFEFF
+#define R_0001FC_MC_IND_DATA 0x0001FC
+#define   S_0001FC_MC_IND_DATA(x)  (((x)  0x)  
0)
+#define   G_0001FC_MC_IND_DATA(x)  (((x)  0)  
0x)
+#define   C_0001FC_MC_IND_DATA 0x
+
+#endif
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fe86b20..868d7c1 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -940,4 +940,8 @@ int r100_pci_gart_set_page(struct radeon_device *rdev, int 
i, uint64_t addr);
 int r100_pci_gart_enable(struct radeon_device *rdev);
 void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
 
+/* r420,r423,rv410 */
+u32 r420_mc_rreg(struct radeon_device *rdev, u32 reg);
+void r420_mc_wreg(struct radeon_device *rdev, u32 reg, u32 v);
+
 #endif
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index da8646a..d1e356b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -266,6 +266,10 @@ void radeon_register_accessor_init(struct radeon_device 
*rdev)
rdev-pll_rreg = r100_pll_rreg;
rdev-pll_wreg = r100_pll_wreg;
}
+   if (rdev-family = CHIP_R420) {
+   rdev-mc_rreg = r420_mc_rreg;
+   rdev-mc_wreg = r420_mc_wreg;
+   }
if (rdev-family = CHIP_RV515) {
rdev-mc_rreg = rv515_mc_rreg;
rdev-mc_wreg = rv515_mc_wreg;
-- 
1.6.4.1

[PATCH] drm/radeon/kms: call r100_cp_disable rather than duplicating code.

[Jerome Glisse]

r100_cp_fini was duplicating code of r100_cp_disable, call r100_cp_disable
instead.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r100.c   |3 +--
 drivers/gpu/drm/radeon/radeon.h |3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 36d0ba2..4ceb675 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -719,8 +719,7 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
 void r100_cp_fini(struct radeon_device *rdev)
 {
/* Disable ring */
-   rdev-cp.ready = false;
-   WREG32(RADEON_CP_CSQ_CNTL, 0);
+   r100_cp_disable(rdev);
radeon_ring_fini(rdev);
DRM_INFO(radeon: cp finalized\n);
 }
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3299733..24574bc 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -933,4 +933,7 @@ static inline void radeon_ring_write(struct radeon_device 
*rdev, uint32_t v)
 #define radeon_clear_surface_reg(rdev, r) 
((rdev)-asic-clear_surface_reg((rdev), (r)))
 #define radeon_bandwidth_update(rdev) (rdev)-asic-bandwidth_update((rdev))
 
+/* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */
+void r100_cp_disable(struct radeon_device *rdev);
+
 #endif
-- 
1.6.4.1


--
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

[PATCH] drm/radeon/kms: Don't try to process irq when we are unloading

[Jerome Glisse]

If module is being unloaded we should not try to handle irq especialy
we should not call into drm helper or we could hard hang the computer
free_irq will call the irq handler to make sure we behave properly.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r100.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 5708c07..36d0ba2 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -319,6 +319,9 @@ int r100_irq_process(struct radeon_device *rdev)
if (!status) {
return IRQ_NONE;
}
+   if (rdev-shutdown) {
+   return IRQ_NONE;
+   }
while (status) {
/* SW interrupt */
if (status  RADEON_SW_INT_TEST) {
-- 
1.6.4.1


--
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] drm/radeon/kms: R3XX/R4XX AGP asic use PCI GART not PCIE GART

[Alex Deucher]

On Wed, Sep 9, 2009 at 4:24 PM, Jerome Glissejgli...@redhat.com wrote:
 R3XX/R4XX AGP asic use the old PCI GART block, not the new PCIE GART.
 Make sure we pick the right GART when disabling AGP.


Just to clarify which gart block is on what r3xx/r4xx asic; If the
card is chip family CHIP_R300, CHIP_R350, CHIP_RV350, or CHIP_R420, it
uses the AIC PCI gart.  If the chip family is CHIP_RV380, CHIP_R423,
or CHIP_RV410, then it uses PCIE gart.

Alex

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/r300.c          |    6 ++
  drivers/gpu/drm/radeon/r420.c          |    9 +++--
  drivers/gpu/drm/radeon/radeon.h        |    4 
  drivers/gpu/drm/radeon/radeon_device.c |    5 +
  4 files changed, 18 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
 index a5f82f7..9c17b78 100644
 --- a/drivers/gpu/drm/radeon/r300.c
 +++ b/drivers/gpu/drm/radeon/r300.c
 @@ -181,6 +181,12 @@ int r300_gart_enable(struct radeon_device *rdev)
                rdev-asic-gart_set_page = rv370_pcie_gart_set_page;
                return rv370_pcie_gart_enable(rdev);
        }
 +       if (rdev-flags  RADEON_IS_PCI) {
 +               rdev-asic-gart_disable = r100_pci_gart_disable;
 +               rdev-asic-gart_tlb_flush = r100_pci_gart_tlb_flush;
 +               rdev-asic-gart_set_page = r100_pci_gart_set_page;
 +               return r100_pci_gart_enable(rdev);
 +       }
        return r100_pci_gart_enable(rdev);
  }

 diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
 index 97426a6..029cee2 100644
 --- a/drivers/gpu/drm/radeon/r420.c
 +++ b/drivers/gpu/drm/radeon/r420.c
 @@ -100,8 +100,13 @@ int r420_mc_init(struct radeon_device *rdev)

  void r420_mc_fini(struct radeon_device *rdev)
  {
 -       rv370_pcie_gart_disable(rdev);
 -       radeon_gart_table_vram_free(rdev);
 +       if (rdev-flags  RADEON_IS_PCIE) {
 +               rv370_pcie_gart_disable(rdev);
 +               radeon_gart_table_vram_free(rdev);
 +       } else {
 +               r100_pci_gart_disable(rdev);
 +               radeon_gart_table_ram_free(rdev);
 +       }
        radeon_gart_fini(rdev);
  }

 diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
 index 24574bc..fe86b20 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -935,5 +935,9 @@ static inline void radeon_ring_write(struct radeon_device 
 *rdev, uint32_t v)

  /* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */
  void r100_cp_disable(struct radeon_device *rdev);
 +void r100_pci_gart_disable(struct radeon_device *rdev);
 +int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
 +int r100_pci_gart_enable(struct radeon_device *rdev);
 +void r100_pci_gart_tlb_flush(struct radeon_device *rdev);

  #endif
 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index f2469c5..da8646a 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -499,10 +499,7 @@ int radeon_device_init(struct radeon_device *rdev,

        if (radeon_agpmode == -1) {
                rdev-flags = ~RADEON_IS_AGP;
 -               if (rdev-family  CHIP_RV515 ||
 -                   rdev-family == CHIP_RV380 ||
 -                   rdev-family == CHIP_RV410 ||
 -                   rdev-family == CHIP_R423) {
 +               if (rdev-family = CHIP_RV515) {
                        DRM_INFO(Forcing AGP to PCIE mode\n);
                        rdev-flags |= RADEON_IS_PCIE;
                } else {
 --
 1.6.4.1


 --
 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

[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23816





--- Comment #1 from Michel Dänzer mic...@daenzer.net  2009-09-09 15:12:05 PST 
---
This is probably a duplicate of bug 22271.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
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

[Bug 23785] NWN crashes after loading or starting game

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23785





--- Comment #4 from Krzysztof A. Sobiecki sob...@gmail.com  2009-09-09 
16:05:31 PST ---
Created an attachment (id=29357)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29357)
Output of RADEON_DEBUG=all for unpatched Mesa

I might say that patch fixes crash, but unfortunately it also prevent rendering
of some parts of bodies or clothing.

On unpatched Mesa starting NWN with RADEON_DEBUG=vert produces empty log. I'm
attaching what I have produced using RADEON_DEBUG=all. I will also, in next
attachment, post RADEON_DEBUG=vert for patched Mesa.

My speculation:
I think that bugs lay deeper in code path, as seen in backtrace. Something
along produces broken object that is passed to rc_mesa_to_rc_program, with
trips over it. I don't know enough about Mesa code to trace it.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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] drm/radeon/kms: Don't try to process irq when we are unloading

[Dave Airlie]

On Wed, 9 Sep 2009, Jerome Glisse wrote:

 If module is being unloaded we should not try to handle irq especialy
 we should not call into drm helper or we could hard hang the computer
 free_irq will call the irq handler to make sure we behave properly.

Should you not just ack all irqs here before returning, else we'll
just get called again.

Dave.

 
 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/r100.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
 index 5708c07..36d0ba2 100644
 --- a/drivers/gpu/drm/radeon/r100.c
 +++ b/drivers/gpu/drm/radeon/r100.c
 @@ -319,6 +319,9 @@ int r100_irq_process(struct radeon_device *rdev)
   if (!status) {
   return IRQ_NONE;
   }
 + if (rdev-shutdown) {
 + return IRQ_NONE;
 + }
   while (status) {
   /* SW interrupt */
   if (status  RADEON_SW_INT_TEST) {
 

--
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

[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23670





--- Comment #8 from Shuang He shuang...@intel.com  2009-09-09 20:31:19 PST ---
(In reply to comment #7)
 Created an attachment (id=29352)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29352) [details]
 another patch for meta.c (IndexOffset/Bias check)
 
 Can you see if this patch helps with the glDrawPixels(GL_STENCIL_INDEX) cases?
 
 Also, the -v 2 output would be helpful.
 

No, this doesn't help. And I'll upload a small case for it


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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

[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23670





--- Comment #9 from Shuang He shuang...@intel.com  2009-09-09 20:35:15 PST ---
Created an attachment (id=29361)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29361)
small case

This case simply render a rectangle area in stencil buffer with
glDrawPixels(GL_STENCIL). then render a red rectangle to validate the result.
This case works with software rendering, but not with i965 driver.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
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