[Bug 27010] New: mesa git build failure regarding winsys

[bugzilla-daemon]

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

   Summary: mesa git build failure regarding winsys
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: lind...@coyote.org


Created an attachment (id=33941)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33941)
build log

I get this error when building now. It worked fine before commit:
1d84808dc045d7fcf2fade8d1504bc25e7c5041a
gmake[5]: *** No rule to make target
`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
`egl_x11_radeon.so'.  Stop.
Attaching output and environment.


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

[Bug 27010] mesa git build failure regarding winsys

[bugzilla-daemon]

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





--- Comment #1 from Lars Lindley lind...@coyote.org  2010-03-11 00:32:51 PST 
---
Created an attachment (id=33942)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33942)
build environment


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

[Bug 27010] mesa git build failure regarding winsys

[bugzilla-daemon]

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


Lars Lindley lind...@coyote.org changed:

   What|Removed |Added

 OS/Version|All |Linux (All)
   Platform|Other   |x86-64 (AMD64)




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

[Bug 15276] latest git kernel: general protection fault: 0000 [#1]

[bugzilla-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=15276





--- Comment #53 from Michał Witkowski ne...@o2.pl  2010-03-11 09:44:37 ---
Will these patches apply to 2.6.33 or 2.6.34-rc1?

Cheers,
Michal

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of 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: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Michal Suchanek]

On 10 March 2010 22:04, Ville Syrjälä syrj...@sci.fi wrote:
 On Wed, Mar 10, 2010 at 06:11:29PM +, James Simmons wrote:

  I don't think so. There is another driver which does this -
  vesa/uvesa. For these it is not possible to change the resolution from
  fbdev, it just provides some framebuffer on top of which fb
  applications or fbcons run.

 Only because that is the only way to do it. The other options was to have
 x86emul in the kernel. That was not going to happen.

  I guess equivalent of xrandr would be what people would want but the
  current fbdev capabilities are far from that.
  Since KMS provides these capabilities already I would think adding a
  tool that manipulates KMS directly (kmset?) is the simplest way.

 Still would have to deal with the issue of keeping the graphical console
 in sync with the changes.

  There are other drivers that support multihead already (matroxfb, any
  other?) and have their own driver-specific inteface.

 Each crtc is treated as a seperate fbdev device. I don't recall any
 special ioctls. Maybe for mirroring which was never standardized.

 matroxfb does have a bunch of custom ioctls to change the crtc-output
 mapping. omapfb is another multihead fb driver and it's more complex
 than matroxfb. Trying to make it perform various tricks through the
 fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs)
 is something I've been doing but I would not recommend it for anyone
 who has the option of using a better API.

 I don't think the CRTC=fb_info makes much sense if the main use
 case is fbcon. fbcon will use a single fb device and so you can't see
 the console on multiple heads anyway which makes the whole thing
 somewhat pointless. And if you're trying to do something more complex
 you will be a lot better off bypassing fbdev altogether.


I guess it's also possible that somebody would want the fbdev/fbcons
cover multiple screens. This is not particularly useful with fbcons
(although curses WMs exist) but might be somewhat useful for graphical
fbdev applications.

Multiple views of the kernel virtual consoles on different heads might
be nice toy but it's probably too hard to be worth trying. And there
are always applications like jfbterm which could be perhaps slightly
adapted to use one of the other devices instead of a vc.

Thanks

Michal

--
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: [Intel-gfx] [PATCH 1/2] libdrm: Move intel_atomic.h to libdrm core for sharing.

[Julien Cristau]

 On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen suok...@gmail.com wrote:
  intel_atomic.h includes very usefull atomic operations for
  lock free parrallel access of variables. Moving these to
  core libdrm for code sharing with radeon.
 
  Signed-off-by: Pauli Nieminen suok...@gmail.com
  ---
   Makefile.am          |    2 +-
   configure.ac         |    2 +-
   intel/intel_atomic.h |   56 +-
   xf86atomic.h         |   93 
  ++
   4 files changed, 96 insertions(+), 57 deletions(-)
   create mode 100644 xf86atomic.h
 
  diff --git a/Makefile.am b/Makefile.am
  index ee3ccc7..295121f 100644
  --- a/Makefile.am
  +++ b/Makefile.am
  @@ -59,7 +59,7 @@ libdrm_la_SOURCES =                           \
         libdrm_lists.h
 
   libdrmincludedir = ${includedir}
  -libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
  +libdrminclude_HEADERS = xf86drm.h xf86drmMode.h xf86atomic.h
 

Should this really get installed?  I'm not sure this should be public
libdrm interface.

Cheers,
Julien

--
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: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Michal Suchanek]

On 10 March 2010 19:47, James Simmons jsimm...@infradead.org wrote:

  Yuck. See my other post about what fbdev really means in its historical
  context. The struct fb_info really maps better to drm_crtc than to
  drm_framebuffer. In fact take the case of the matrox fbdev driver. It
  creates two framebuffer devices even tho it used one static framebuffer.
  What the driver does is splits the framebuffer in two and assigned each
  part to a CRTC.
 
  The only problem with that is that it eats a lot of memory for the
  console which limits X when it starts. On cards with limited vram ,
  you might not have enough memory left for any meaningful acceleration
  when X starts.

 It would be nice to find a way to reclaim the console memory for X,
 but I'm not sure that can be done and still provide a good way to
 provide oops support.

        Ah, the power of flags. We had the same issue with user requesting a 
 mode
 change or fbcon asking for a different mode. We handled it with the flag
 FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you 
 will
 have to deal also with the ability to change the resolution with tools like 
 stty.
 I can easily see how to do this plus give you more memory like you want :-)
        For the oops are you talking about printing oops to the screen
 while X is running ? Otherwise if you experience a oops and go back to
 console mode you should be able to view it. The console text buffer is
 independent of the graphics card memory system.


Ability to print the oops over X does not seem to be that bad idea.
Since with KMS the kernel finally knows what X is doing with the
graphics it should be able to print it. Note that it may be the only
way to see it in situations when the console dies in one way or
another.

Thanks

Michal

--
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: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Michal Suchanek]

On 10 March 2010 18:42, James Simmons jsimm...@infradead.org wrote:

  At the moment the problem with fbset is what to do with it in the
  dual head case. Currently we create an fb console that is lowest
  common size of the two heads and set native modes on both,
 
  Does that mean that fbset is supposed to work (set resolution) on drmfb?

 No we've never hooked it up but it could be made work.

 I had it to the point of almost working. I plan on working on getting it
 working again.

  Schemes which would make a multihead setup look like a single screen
  get complicated quite easily. Perhaps an option to turn off some
  outputs so that the native resolution of one output is used (instead
  of clone) would work.
 

 I've only really got two answer for this:

 (a) hook up another /dev/dri/card_fb device and use the current KMS
 ioctls to control the framebuffer, have the drm callback into fbdev/fbcon
 to mention resizes etc. Or add one or two info gathering ioctls and
 allow use of the /dev/dri/control device to control stuff.

 (b) add a lot of ioctls to KMS fbdev device, which implement some sort
 of sane multi-output settings.

 Now the second sounds like a lot of work if not the correct solution,
 you basically needs a way to pretty much expose what the KMS ioctls
 expose on the fb device, and then upgrade fbset to make sense of it all.

 Yuck. See my other post about what fbdev really means in its historical
 context. The struct fb_info really maps better to drm_crtc than to
 drm_framebuffer. In fact take the case of the matrox fbdev driver. It
 creates two framebuffer devices even tho it used one static framebuffer.
 What the driver does is splits the framebuffer in two and assigned each
 part to a CRTC.


So you get the layering naturally. On fbset - fbev layer you can
choose from the resolutions available in the current output setup, in
kmset or whatever - drm layer you can set up the outputs, merge
multiple outputs into single cloned fbdev or separate them, ..

It's obviously nice if you can set the resolution on all of fbcons,
fbdev and drm layers but getting it work on at least one layer with
proper propagation up and down also works. BTW I don't know any
application which sets linux console (or xterm for that matter)
resolution through the terminal API.

Thanks

Michal

--
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: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver

[Matthew Garrett]

On Wed, Mar 10, 2010 at 10:15:26PM +0100, Rafael J. Wysocki wrote:
 On Wednesday 10 March 2010, Matthew Garrett wrote:
  As far as the ACPI video driver goes, acpi_get_physical_pci_device() 
  will give you something to work with.
 
 Hmm.  Did you mean acpi_get_physical_device()?

Ah, no, acpi_get_pci_dev.

 Which acpi_device should I call that for?

The video one. acpi_video_bus_check does something very similar to check 
whether the device actually exists.

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

--
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: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver

[Matthew Garrett]

As far as the ACPI video driver goes, acpi_get_physical_pci_device() 
will give you something to work with. For the console-switching case, I 
think the most reasonable plan is probably to add a flag to the console 
drivers to indicate whether or not they support reprogramming the 
hardware themselves, and then walk all active console drivers. There'd 
need to be a way for fb drivers to tell fbcon that they can handle it.

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

--
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] drm/i915: Convert some trace events to DEFINE_TRACE

[Li Zefan]

Use DECLARE_EVENT_CLASS to remove duplicate code:

   textdata bss dec hex filename
  146552732  15   1740243fa i915_trace_points.o.orig
  116252732  10   14367381f i915_trace_points.o

8 events are converted:

  i915_gem_object:  i915_gem_object_{unbind, destroy}
  i915_gem_request: i915_gem_request_{complete, retire, wait_begin, wait_end}
  i915_ring:i915_ring_{wait_begin, wait_end}

No functional change.

Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
 drivers/gpu/drm/i915/i915_trace.h |   86 +++--
 1 files changed, 25 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 01840d9..3038153 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -115,7 +115,7 @@ TRACE_EVENT(i915_gem_object_get_fence,
  __entry-obj, __entry-fence, __entry-tiling_mode)
 );
 
-TRACE_EVENT(i915_gem_object_unbind,
+DECLARE_EVENT_CLASS(i915_gem_object,
 
TP_PROTO(struct drm_gem_object *obj),
 
@@ -132,21 +132,18 @@ TRACE_EVENT(i915_gem_object_unbind,
TP_printk(obj=%p, __entry-obj)
 );
 
-TRACE_EVENT(i915_gem_object_destroy,
+DEFINE_EVENT(i915_gem_object, i915_gem_object_unbind,
 
TP_PROTO(struct drm_gem_object *obj),
 
-   TP_ARGS(obj),
+   TP_ARGS(obj)
+);
 
-   TP_STRUCT__entry(
-__field(struct drm_gem_object *, obj)
-),
+DEFINE_EVENT(i915_gem_object, i915_gem_object_destroy,
 
-   TP_fast_assign(
-  __entry-obj = obj;
-  ),
+   TP_PROTO(struct drm_gem_object *obj),
 
-   TP_printk(obj=%p, __entry-obj)
+   TP_ARGS(obj)
 );
 
 /* batch tracing */
@@ -197,8 +194,7 @@ TRACE_EVENT(i915_gem_request_flush,
  __entry-flush_domains, __entry-invalidate_domains)
 );
 
-
-TRACE_EVENT(i915_gem_request_complete,
+DECLARE_EVENT_CLASS(i915_gem_request,
 
TP_PROTO(struct drm_device *dev, u32 seqno),
 
@@ -217,64 +213,35 @@ TRACE_EVENT(i915_gem_request_complete,
TP_printk(dev=%u, seqno=%u, __entry-dev, __entry-seqno)
 );
 
-TRACE_EVENT(i915_gem_request_retire,
+DEFINE_EVENT(i915_gem_request, i915_gem_request_complete,
 
TP_PROTO(struct drm_device *dev, u32 seqno),
 
-   TP_ARGS(dev, seqno),
-
-   TP_STRUCT__entry(
-__field(u32, dev)
-__field(u32, seqno)
-),
-
-   TP_fast_assign(
-  __entry-dev = dev-primary-index;
-  __entry-seqno = seqno;
-  ),
-
-   TP_printk(dev=%u, seqno=%u, __entry-dev, __entry-seqno)
+   TP_ARGS(dev, seqno)
 );
 
-TRACE_EVENT(i915_gem_request_wait_begin,
+DEFINE_EVENT(i915_gem_request, i915_gem_request_retire,
 
TP_PROTO(struct drm_device *dev, u32 seqno),
 
-   TP_ARGS(dev, seqno),
-
-   TP_STRUCT__entry(
-__field(u32, dev)
-__field(u32, seqno)
-),
-
-   TP_fast_assign(
-  __entry-dev = dev-primary-index;
-  __entry-seqno = seqno;
-  ),
-
-   TP_printk(dev=%u, seqno=%u, __entry-dev, __entry-seqno)
+   TP_ARGS(dev, seqno)
 );
 
-TRACE_EVENT(i915_gem_request_wait_end,
+DEFINE_EVENT(i915_gem_request, i915_gem_request_wait_begin,
 
TP_PROTO(struct drm_device *dev, u32 seqno),
 
-   TP_ARGS(dev, seqno),
+   TP_ARGS(dev, seqno)
+);
 
-   TP_STRUCT__entry(
-__field(u32, dev)
-__field(u32, seqno)
-),
+DEFINE_EVENT(i915_gem_request, i915_gem_request_wait_end,
 
-   TP_fast_assign(
-  __entry-dev = dev-primary-index;
-  __entry-seqno = seqno;
-  ),
+   TP_PROTO(struct drm_device *dev, u32 seqno),
 
-   TP_printk(dev=%u, seqno=%u, __entry-dev, __entry-seqno)
+   TP_ARGS(dev, seqno)
 );
 
-TRACE_EVENT(i915_ring_wait_begin,
+DECLARE_EVENT_CLASS(i915_ring,
 
TP_PROTO(struct drm_device *dev),
 
@@ -291,21 +258,18 @@ TRACE_EVENT(i915_ring_wait_begin,
TP_printk(dev=%u, __entry-dev)
 );
 
-TRACE_EVENT(i915_ring_wait_end,
+DEFINE_EVENT(i915_ring, i915_ring_wait_begin,
 
TP_PROTO(struct drm_device *dev),
 
-   TP_ARGS(dev),
+   TP_ARGS(dev)
+);
 
-   TP_STRUCT__entry(
-__field(u32, dev)
-),
+DEFINE_EVENT(i915_ring, i915_ring_wait_end,
 
-   TP_fast_assign(
-  __entry-dev = dev-primary-index;
-  ),
+ 

Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Michel Dänzer]

On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote: 
 On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote:
  On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org 
  wrote:
 
  See my other post about what fbdev really means in its historical
  context. The struct fb_info really maps better to drm_crtc than to
  drm_framebuffer. In fact take the case of the matrox fbdev driver. It
  creates two framebuffer devices even tho it used one static framebuffer.
  What the driver does is splits the framebuffer in two and assigned each
  part to a CRTC.
 
  The only problem with that is that it eats a lot of memory for the
  console which limits X when it starts. On cards with limited vram ,
  you might not have enough memory left for any meaningful acceleration
  when X starts.
 
 It would be nice to find a way to reclaim the console memory for X,
 but I'm not sure that can be done and still provide a good way to
 provide oops support.

What do you think the average user will care about more?

  * Seeing kernel oops/panic output about once in a lifetime. 
  * Being able to start/use X in the first place and enabling it to
use all of VRAM.

Personally, I've never even seen any kernel oops/panic output despite
numerous opportunities for that in the couple of months I've been using
KMS. But I have spent considerable time and effort trying to get rid of
the pinned fbcon BO. If the oops/panic output is the only thing
preventing that, maybe that should only be enabled via some module
option for developers.


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

--
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: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Pauli Nieminen]

2010/3/11 Michel Dänzer mic...@daenzer.net:
 On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
 On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote:
  On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org 
  wrote:
 
  See my other post about what fbdev really means in its historical
  context. The struct fb_info really maps better to drm_crtc than to
  drm_framebuffer. In fact take the case of the matrox fbdev driver. It
  creates two framebuffer devices even tho it used one static framebuffer.
  What the driver does is splits the framebuffer in two and assigned each
  part to a CRTC.
 
  The only problem with that is that it eats a lot of memory for the
  console which limits X when it starts. On cards with limited vram ,
  you might not have enough memory left for any meaningful acceleration
  when X starts.

 It would be nice to find a way to reclaim the console memory for X,
 but I'm not sure that can be done and still provide a good way to
 provide oops support.

 What do you think the average user will care about more?

      * Seeing kernel oops/panic output about once in a lifetime.
      * Being able to start/use X in the first place and enabling it to
        use all of VRAM.

 Personally, I've never even seen any kernel oops/panic output despite
 numerous opportunities for that in the couple of months I've been using
 KMS. But I have spent considerable time and effort trying to get rid of
 the pinned fbcon BO. If the oops/panic output is the only thing
 preventing that, maybe that should only be enabled via some module
 option for developers.


+1

For me only way to capture oopses is netconsole. But I'm causing all
my oopses in radeon/ttm modules. That might prevent the system from
returning to framebuffer console.

Pinning framebuffer console is only for developers feature so it
should be non-default option. For users it is more important to have
all VRAM available when required and fully functional console if they
use it.
In case of kernel oops there should some different way to collect them
in users system. They should be stored in hard disk for easier
attaching to the bug report. Also oopses that are stored in hd can be
later uploaded automatically with kerneloops daemon.

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

radeon: bug using unsigned int

[Dan Carpenter]

drivers/gpu/drm/radeon/radeon_display.c +555 radeon_compute_pll_legacy(106) 
warn: unsigned 'error' is never less than zero.
   553  if (pll-flags  
RADEON_PLL_PREFER_CLOSEST_LOWER) {
   554  error = freq - 
current_freq;
   555  error = error  0 ? 
0x : error;
^

error is unsigned so it's never less than zero.

   556  } else
   557  error = 
abs(current_freq - freq);

regards,
dan carpenter

--
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 RFC] ttm: nouveau accelerated on Xen pv-ops kernel

[Pekka Paalanen]

I'm adding dri-devel@ to CC, since this suggested patch touches
TTM code, and none of the Nouveau code. TTM patches go via
dri-de...@.

Thanks.


On Wed, 10 Mar 2010 18:51:21 +0530
Arvind R arvin...@gmail.com wrote:

 Hi,
 Following is a simple patch that is needed in nouveau to get
 accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's
 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is
 almost the mainline merge), was substituted into the kernel-tree.
 All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm)
 used of the same day.
 
 Patch:
 diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
 nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
 --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
 10:19:28.0 +0530
 +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10
 17:28:59.0 +0530
 @@ -271,7 +271,10 @@
  */
 
 vma-vm_private_data = bo;
 -   vma-vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP |
 VM_DONTEXPAND;
 +   vma-vm_flags |= VM_RESERVED | VM_MIXEDMAP |
 VM_DONTEXPAND;
 +   if (!((bo-mem.placement  TTM_PL_MASK_MEM) 
 TTM_PL_FLAG_TT))
 +   vma-vm_flags |= VM_IO;
 +   vma-vm_page_prot = vma_get_vm_prot(vma-vm_flags);
 return 0;
  out_unref:
 ttm_bo_unref(bo);
 
 This patch is necessary because, in Xen, PFN of a page is
 virtualised. So physical addresses
 for DMA programming needs to use the MFN. Xen transparently does
 the correct translation
 using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set,
 then Xen assumes that the backing
 memory is in the IOMEM space, and PFN equals MFN. If not set,
 page_to_pfn() returns MFN.
 
 The patch enables the ttm_bo_vm_fault() handler to behave
 correctly under Xen, and has no
 side-effects on normal (not under Xen) operations. The use of
 TTM_PL_FLAG_TT in the
 check assumes that all other placements are backed by device
 memory or IO. If there are
 any other placements that use system memory, that flag has to be
 OR'ed into the check.
 
 The above patch has no implications on a normal kernel or a Xen
 pv_ops kernel booted without
 the Xen hypervisor. My testing is on a debian-lenny environment
 on a Core2 processor with
 nVidia GeForce 9400 GT.

-- 
Pekka Paalanen
http://www.iki.fi/pq/


--
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 00/14] cleanup radeon_asic.h

[Daniel Vetter]

Hi all,

This patch pile moves the static struct radeon_asic asic definitions
form radeon_asic.h into the asic-specific files, where I think they belong.
This way radeon_asic.h becomes a real header file that can be #included.
And indeed, with all the copypasting of function declarations, one has
gotten out of sync.

The next step would be to collect asic specific declarations in
radeon_asic.h - atm they are somewhat scattered. But this can easily be
done on the go and has way too much potential for conflicts with other
patches. So I didn't do this.

Tested on my rv570.

Comments higly welcome.

Yours, Daniel

Daniel Vetter (14):
  drm/radoen: move r100 asic struct to r100.c
  drm/radoen: move r200 asic struct to r200.c
  drm/radeon: move r300 asic structs to r300.c
  drm/radeon: move r420 asic struct to r420.c
  drm/radoen: move rs400 asic struct to rs400.c
  drm/radoen: move rs600 asic struct to rs600.c
  drm/radoen: move rs690 asic struct to rs690.c
  drm/radoen: move rv515 asic struct to rv515.c
  drm/radoen: move r520 asic struct to r520.c
  drm/radoen: move r600 asic struct to r600.c
  drm/radoen: move rv770 asic struct to rv770.c
  drm/radoen: move evergreen asic struct to evergreen.c
  drm/radoen: unconfuse return value of radeon_asic-clear_surface_reg
  drm/radeon: include radeon_asic.h in asic.c

 drivers/gpu/drm/radeon/evergreen.c   |   39 +++-
 drivers/gpu/drm/radeon/r100.c|   39 +++
 drivers/gpu/drm/radeon/r200.c|   38 +++
 drivers/gpu/drm/radeon/r300.c|   76 ++
 drivers/gpu/drm/radeon/r420.c|   39 +++
 drivers/gpu/drm/radeon/r520.c|   39 +++
 drivers/gpu/drm/radeon/r600.c|   43 +++-
 drivers/gpu/drm/radeon/radeon.h  |3 +-
 drivers/gpu/drm/radeon/radeon_asic.h |  494 ++
 drivers/gpu/drm/radeon/rs400.c   |   39 +++
 drivers/gpu/drm/radeon/rs600.c   |   43 +++-
 drivers/gpu/drm/radeon/rs690.c   |   39 +++
 drivers/gpu/drm/radeon/rv515.c   |   41 +++-
 drivers/gpu/drm/radeon/rv770.c   |   42 +++-
 14 files changed, 518 insertions(+), 496 deletions(-)


--
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 10/14] drm/radoen: move r600 asic struct to r600.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/r600.c|   43 ++
 drivers/gpu/drm/radeon/radeon_asic.h |   37 +
 2 files changed, 44 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index c522901..c45bbcc 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2950,3 +2950,46 @@ void r600_ioctl_wait_idle(struct radeon_device *rdev, 
struct radeon_bo *bo)
 {
WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
 }
+
+extern int rv370_get_pcie_lanes(struct radeon_device *rdev);
+void rv515_bandwidth_update(struct radeon_device *rdev);
+int r600_cs_parse(struct radeon_cs_parser *p);
+u32 rs600_get_vblank_counter(struct radeon_device *rdev, int crtc);
+int rs600_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+
+struct radeon_asic r600_asic = {
+   .init = r600_init,
+   .fini = r600_fini,
+   .suspend = r600_suspend,
+   .resume = r600_resume,
+   .cp_commit = r600_cp_commit,
+   .vga_set_state = r600_vga_set_state,
+   .gpu_reset = r600_gpu_reset,
+   .gart_tlb_flush = r600_pcie_gart_tlb_flush,
+   .gart_set_page = rs600_gart_set_page,
+   .ring_test = r600_ring_test,
+   .ring_ib_execute = r600_ring_ib_execute,
+   .irq_set = r600_irq_set,
+   .irq_process = r600_irq_process,
+   .get_vblank_counter = rs600_get_vblank_counter,
+   .fence_ring_emit = r600_fence_ring_emit,
+   .cs_parse = r600_cs_parse,
+   .copy_blit = r600_copy_blit,
+   .copy_dma = r600_copy_blit,
+   .copy = r600_copy_blit,
+   .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,
+   .get_pcie_lanes = rv370_get_pcie_lanes,
+   .set_pcie_lanes = NULL,
+   .set_clock_gating = NULL,
+   .set_surface_reg = r600_set_surface_reg,
+   .clear_surface_reg = r600_clear_surface_reg,
+   .bandwidth_update = rv515_bandwidth_update,
+   .hpd_init = r600_hpd_init,
+   .hpd_fini = r600_hpd_fini,
+   .hpd_sense = r600_hpd_sense,
+   .hpd_set_polarity = r600_hpd_set_polarity,
+   .ioctl_wait_idle = r600_ioctl_wait_idle,
+};
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 3137f2c..ba40f8a 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -231,42 +231,7 @@ void r600_hpd_set_polarity(struct radeon_device *rdev,
   enum radeon_hpd_id hpd);
 extern void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo 
*bo);
 
-static struct radeon_asic r600_asic = {
-   .init = r600_init,
-   .fini = r600_fini,
-   .suspend = r600_suspend,
-   .resume = r600_resume,
-   .cp_commit = r600_cp_commit,
-   .vga_set_state = r600_vga_set_state,
-   .gpu_reset = r600_gpu_reset,
-   .gart_tlb_flush = r600_pcie_gart_tlb_flush,
-   .gart_set_page = rs600_gart_set_page,
-   .ring_test = r600_ring_test,
-   .ring_ib_execute = r600_ring_ib_execute,
-   .irq_set = r600_irq_set,
-   .irq_process = r600_irq_process,
-   .get_vblank_counter = rs600_get_vblank_counter,
-   .fence_ring_emit = r600_fence_ring_emit,
-   .cs_parse = r600_cs_parse,
-   .copy_blit = r600_copy_blit,
-   .copy_dma = r600_copy_blit,
-   .copy = r600_copy_blit,
-   .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,
-   .get_pcie_lanes = rv370_get_pcie_lanes,
-   .set_pcie_lanes = NULL,
-   .set_clock_gating = NULL,
-   .set_surface_reg = r600_set_surface_reg,
-   .clear_surface_reg = r600_clear_surface_reg,
-   .bandwidth_update = rv515_bandwidth_update,
-   .hpd_init = r600_hpd_init,
-   .hpd_fini = r600_hpd_fini,
-   .hpd_sense = r600_hpd_sense,
-   .hpd_set_polarity = r600_hpd_set_polarity,
-   .ioctl_wait_idle = r600_ioctl_wait_idle,
-};
+extern struct radeon_asic r600_asic;
 
 /*
  * rv770,rv730,rv710,rv740
-- 
1.7.0


--
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 01/14] drm/radoen: move r100 asic struct to r100.c

[Daniel Vetter]

This is the first step to clean up radeon_asic.h and make it into a real
header file (i.e. kill the static struct definitions). Then it can be
included by the asic.c files to compile-check the declarations of
shared functions (some differ atm).

This first patch just moves the r100_asic struct to r100.c

To accomplish this, the declarations for a few shared functions had to
be moved from radeon_asic.h to radeon.h. They'll move back when this
cleanup is complete.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/r100.c|   38 
 drivers/gpu/drm/radeon/radeon.h  |   13 
 drivers/gpu/drm/radeon/radeon_asic.h |   52 +-
 3 files changed, 52 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..facf3d8 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3538,3 +3538,41 @@ int r100_init(struct radeon_device *rdev)
}
return 0;
 }
+
+struct radeon_asic r100_asic = {
+   .init = r100_init,
+   .fini = r100_fini,
+   .suspend = r100_suspend,
+   .resume = r100_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r100_gpu_reset,
+   .gart_tlb_flush = r100_pci_gart_tlb_flush,
+   .gart_set_page = r100_pci_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r100_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r100_fence_ring_emit,
+   .cs_parse = r100_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = NULL,
+   .copy = r100_copy_blit,
+   .get_engine_clock = radeon_legacy_get_engine_clock,
+   .set_engine_clock = radeon_legacy_set_engine_clock,
+   .get_memory_clock = radeon_legacy_get_memory_clock,
+   .set_memory_clock = NULL,
+   .get_pcie_lanes = NULL,
+   .set_pcie_lanes = NULL,
+   .set_clock_gating = radeon_legacy_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init = r100_hpd_init,
+   .hpd_fini = r100_hpd_fini,
+   .hpd_sense = r100_hpd_sense,
+   .hpd_set_polarity = r100_hpd_set_polarity,
+   .ioctl_wait_idle = NULL,
+};
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 829e26e..bf5a2e6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -862,6 +862,19 @@ union radeon_asic_config {
struct rv770_asic   rv770;
 };
 
+/* WIP: Declarations from radeon_asic.h
+ * These will move back to radeon_asic.h as soon as it has morphed into
+ * a real header. */
+uint32_t radeon_legacy_get_engine_clock(struct radeon_device *rdev);
+void radeon_legacy_set_engine_clock(struct radeon_device *rdev, uint32_t 
eng_clock);
+uint32_t radeon_legacy_get_memory_clock(struct radeon_device *rdev);
+void radeon_legacy_set_clock_gating(struct radeon_device *rdev, int enable);
+
+uint32_t radeon_atom_get_engine_clock(struct radeon_device *rdev);
+void radeon_atom_set_engine_clock(struct radeon_device *rdev, uint32_t 
eng_clock);
+uint32_t radeon_atom_get_memory_clock(struct radeon_device *rdev);
+void radeon_atom_set_memory_clock(struct radeon_device *rdev, uint32_t 
mem_clock);
+void radeon_atom_set_clock_gating(struct radeon_device *rdev, int enable);
 
 /*
  * IOCTL.
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index d3a157b..a2b4bd4 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -29,20 +29,6 @@
 #define __RADEON_ASIC_H__
 
 /*
- * common functions
- */
-uint32_t radeon_legacy_get_engine_clock(struct radeon_device *rdev);
-void radeon_legacy_set_engine_clock(struct radeon_device *rdev, uint32_t 
eng_clock);
-uint32_t radeon_legacy_get_memory_clock(struct radeon_device *rdev);
-void radeon_legacy_set_clock_gating(struct radeon_device *rdev, int enable);
-
-uint32_t radeon_atom_get_engine_clock(struct radeon_device *rdev);
-void radeon_atom_set_engine_clock(struct radeon_device *rdev, uint32_t 
eng_clock);
-uint32_t radeon_atom_get_memory_clock(struct radeon_device *rdev);
-void radeon_atom_set_memory_clock(struct radeon_device *rdev, uint32_t 
mem_clock);
-void radeon_atom_set_clock_gating(struct radeon_device *rdev, int enable);
-
-/*
  * r100,rv100,rs100,rv200,rs200
  */
 extern int r100_init(struct radeon_device *rdev);
@@ -83,43 +69,7 @@ bool r100_hpd_sense(struct radeon_device *rdev, enum 
radeon_hpd_id hpd);
 void r100_hpd_set_polarity(struct radeon_device *rdev,
   enum radeon_hpd_id hpd);
 
-static struct radeon_asic r100_asic = {
-   .init = 

[PATCH 07/14] drm/radoen: move rs690 asic struct to rs690.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon_asic.h |   38 +-
 drivers/gpu/drm/radeon/rs690.c   |   72 ++
 2 files changed, 73 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 2de7e08..9ff56ff 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -163,44 +163,8 @@ int rs690_suspend(struct radeon_device *rdev);
 uint32_t rs690_mc_rreg(struct radeon_device *rdev, uint32_t reg);
 void rs690_mc_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v);
 void rs690_bandwidth_update(struct radeon_device *rdev);
-static struct radeon_asic rs690_asic = {
-   .init = rs690_init,
-   .fini = rs690_fini,
-   .suspend = rs690_suspend,
-   .resume = rs690_resume,
-   .vga_set_state = r100_vga_set_state,
-   .gpu_reset = r300_gpu_reset,
-   .gart_tlb_flush = rs400_gart_tlb_flush,
-   .gart_set_page = rs400_gart_set_page,
-   .cp_commit = r100_cp_commit,
-   .ring_start = r300_ring_start,
-   .ring_test = r100_ring_test,
-   .ring_ib_execute = r100_ring_ib_execute,
-   .irq_set = rs600_irq_set,
-   .irq_process = rs600_irq_process,
-   .get_vblank_counter = rs600_get_vblank_counter,
-   .fence_ring_emit = r300_fence_ring_emit,
-   .cs_parse = r300_cs_parse,
-   .copy_blit = r100_copy_blit,
-   .copy_dma = r200_copy_dma,
-   .copy = r200_copy_dma,
-   .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,
-   .get_pcie_lanes = NULL,
-   .set_pcie_lanes = NULL,
-   .set_clock_gating = radeon_atom_set_clock_gating,
-   .set_surface_reg = r100_set_surface_reg,
-   .clear_surface_reg = r100_clear_surface_reg,
-   .bandwidth_update = rs690_bandwidth_update,
-   .hpd_init = rs600_hpd_init,
-   .hpd_fini = rs600_hpd_fini,
-   .hpd_sense = rs600_hpd_sense,
-   .hpd_set_polarity = rs600_hpd_set_polarity,
-   .ioctl_wait_idle = NULL,
-};
 
+extern struct radeon_asic rs690_asic;
 
 /*
  * rv515
diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
index 83b9174..5c84c0b 100644
--- a/drivers/gpu/drm/radeon/rs690.c
+++ b/drivers/gpu/drm/radeon/rs690.c
@@ -741,3 +741,75 @@ int rs690_init(struct radeon_device *rdev)
}
return 0;
 }
+
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+extern int r300_gpu_reset(struct radeon_device *rdev);
+void r100_cp_commit(struct radeon_device *rdev);
+void r300_ring_start(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+extern void r300_fence_ring_emit(struct radeon_device *rdev,
+   struct radeon_fence *fence);
+extern int r300_cs_parse(struct radeon_cs_parser *p);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+extern int r200_copy_dma(struct radeon_device *rdev,
+   uint64_t src_offset,
+   uint64_t dst_offset,
+   unsigned num_pages,
+   struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+int r100_ring_test(struct radeon_device *rdev);
+void rs400_gart_tlb_flush(struct radeon_device *rdev);
+int rs400_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+u32 rs600_get_vblank_counter(struct radeon_device *rdev, int crtc);
+void rs600_hpd_init(struct radeon_device *rdev);
+void rs600_hpd_fini(struct radeon_device *rdev);
+bool rs600_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd);
+void rs600_hpd_set_polarity(struct radeon_device *rdev,
+   enum radeon_hpd_id hpd);
+int rs600_irq_set(struct radeon_device *rdev);
+int rs600_irq_process(struct radeon_device *rdev);
+
+struct radeon_asic rs690_asic = {
+   .init = rs690_init,
+   .fini = rs690_fini,
+   .suspend = rs690_suspend,
+   .resume = rs690_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r300_gpu_reset,
+   .gart_tlb_flush = rs400_gart_tlb_flush,
+   .gart_set_page = rs400_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r300_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = rs600_irq_set,
+   .irq_process = 

[PATCH 13/14] drm/radoen: unconfuse return value of radeon_asic-clear_surface_reg

[Daniel Vetter]

No one cares about it, so set it to void.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon.h  |2 +-
 drivers/gpu/drm/radeon/radeon_asic.h |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index bf5a2e6..9187fd7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -782,7 +782,7 @@ struct radeon_asic {
int (*set_surface_reg)(struct radeon_device *rdev, int reg,
   uint32_t tiling_flags, uint32_t pitch,
   uint32_t offset, uint32_t obj_size);
-   int (*clear_surface_reg)(struct radeon_device *rdev, int reg);
+   void (*clear_surface_reg)(struct radeon_device *rdev, int reg);
void (*bandwidth_update)(struct radeon_device *rdev);
void (*hpd_init)(struct radeon_device *rdev);
void (*hpd_fini)(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 4db2e37..9a3bf44 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -59,7 +59,7 @@ int r100_copy_blit(struct radeon_device *rdev,
 int r100_set_surface_reg(struct radeon_device *rdev, int reg,
 uint32_t tiling_flags, uint32_t pitch,
 uint32_t offset, uint32_t obj_size);
-int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r100_clear_surface_reg(struct radeon_device *rdev, int reg);
 void r100_bandwidth_update(struct radeon_device *rdev);
 void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
 int r100_ring_test(struct radeon_device *rdev);
@@ -218,7 +218,7 @@ int r600_gpu_reset(struct radeon_device *rdev);
 int r600_set_surface_reg(struct radeon_device *rdev, int reg,
 uint32_t tiling_flags, uint32_t pitch,
 uint32_t offset, uint32_t obj_size);
-int r600_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r600_clear_surface_reg(struct radeon_device *rdev, int reg);
 void r600_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
 int r600_ring_test(struct radeon_device *rdev);
 int r600_copy_blit(struct radeon_device *rdev,
-- 
1.7.0


--
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 14/14] drm/radeon: include radeon_asic.h in asic.c

[Daniel Vetter]

And kill the temporary function declarations. Also drop a few
unnecessary forward declarations.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/evergreen.c   |   12 +-
 drivers/gpu/drm/radeon/r100.c|1 +
 drivers/gpu/drm/radeon/r200.c|   35 +
 drivers/gpu/drm/radeon/r300.c|   31 +-
 drivers/gpu/drm/radeon/r420.c|   38 +---
 drivers/gpu/drm/radeon/r520.c|   40 +-
 drivers/gpu/drm/radeon/r600.c|   12 +
 drivers/gpu/drm/radeon/radeon.h  |   14 
 drivers/gpu/drm/radeon/radeon_asic.h |   14 
 drivers/gpu/drm/radeon/rs400.c   |   35 +
 drivers/gpu/drm/radeon/rs600.c   |   30 +---
 drivers/gpu/drm/radeon/rs690.c   |   35 +
 drivers/gpu/drm/radeon/rv515.c   |   37 +--
 drivers/gpu/drm/radeon/rv770.c   |   33 +---
 14 files changed, 28 insertions(+), 339 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 618006a..a016694 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -25,15 +25,13 @@
 #include linux/platform_device.h
 #include drmP.h
 #include radeon.h
+#include radeon_asic.h
 #include radeon_drm.h
 #include rv770d.h
 #include atom.h
 #include avivod.h
 #include evergreen_reg.h
 
-static void evergreen_gpu_init(struct radeon_device *rdev);
-void evergreen_fini(struct radeon_device *rdev);
-
 bool evergreen_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd)
 {
bool connected = false;
@@ -766,14 +764,6 @@ void evergreen_fini(struct radeon_device *rdev)
radeon_dummy_page_fini(rdev);
 }
 
-void r600_vga_set_state(struct radeon_device *rdev, bool state);
-void r600_pcie_gart_tlb_flush(struct radeon_device *rdev);
-int rs600_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
-int r600_set_surface_reg(struct radeon_device *rdev, int reg,
-uint32_t tiling_flags, uint32_t pitch,
-uint32_t offset, uint32_t obj_size);
-int r600_clear_surface_reg(struct radeon_device *rdev, int reg);
-
 struct radeon_asic evergreen_asic = {
.init = evergreen_init,
.fini = evergreen_fini,
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index facf3d8..270fbdf 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -31,6 +31,7 @@
 #include radeon_drm.h
 #include radeon_reg.h
 #include radeon.h
+#include radeon_asic.h
 #include r100d.h
 #include rs100d.h
 #include rv200d.h
diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c
index 7dfeab3..990142f 100644
--- a/drivers/gpu/drm/radeon/r200.c
+++ b/drivers/gpu/drm/radeon/r200.c
@@ -30,6 +30,7 @@
 #include radeon_drm.h
 #include radeon_reg.h
 #include radeon.h
+#include radeon_asic.h
 
 #include r100d.h
 #include r200_reg_safe.h
@@ -508,40 +509,6 @@ void r200_set_safe_registers(struct radeon_device *rdev)
rdev-config.r100.reg_safe_bm_size = ARRAY_SIZE(r200_reg_safe_bm);
 }
 
-extern int r100_init(struct radeon_device *rdev);
-extern void r100_fini(struct radeon_device *rdev);
-extern int r100_suspend(struct radeon_device *rdev);
-extern int r100_resume(struct radeon_device *rdev);
-void r100_vga_set_state(struct radeon_device *rdev, bool state);
-int r100_gpu_reset(struct radeon_device *rdev);
-void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
-int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
-void r100_cp_commit(struct radeon_device *rdev);
-void r100_ring_start(struct radeon_device *rdev);
-int r100_ring_test(struct radeon_device *rdev);
-void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
-int r100_irq_set(struct radeon_device *rdev);
-int r100_irq_process(struct radeon_device *rdev);
-u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc);
-void r100_fence_ring_emit(struct radeon_device *rdev,
- struct radeon_fence *fence);
-int r100_cs_parse(struct radeon_cs_parser *p);
-int r100_copy_blit(struct radeon_device *rdev,
-  uint64_t src_offset,
-  uint64_t dst_offset,
-  unsigned num_pages,
-  struct radeon_fence *fence);
-int r100_set_surface_reg(struct radeon_device *rdev, int reg,
-uint32_t tiling_flags, uint32_t pitch,
-uint32_t offset, uint32_t obj_size);
-int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
-void r100_bandwidth_update(struct radeon_device *rdev);
-void r100_hpd_init(struct radeon_device *rdev);
-void r100_hpd_fini(struct radeon_device *rdev);
-bool r100_hpd_sense(struct radeon_device *rdev, enum 

[PATCH 09/14] drm/radoen: move r520 asic struct to r520.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/r520.c|   77 ++
 drivers/gpu/drm/radeon/radeon_asic.h |   40 +-
 2 files changed, 79 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index 2b8a5dd..554f667 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -309,3 +309,80 @@ int r520_init(struct radeon_device *rdev)
}
return 0;
 }
+
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+extern void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev);
+extern int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i, 
uint64_t addr);
+void r100_cp_commit(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+int r100_ring_test(struct radeon_device *rdev);
+int rs600_irq_set(struct radeon_device *rdev);
+int rs600_irq_process(struct radeon_device *rdev);
+u32 rs600_get_vblank_counter(struct radeon_device *rdev, int crtc);
+extern void r300_fence_ring_emit(struct radeon_device *rdev,
+   struct radeon_fence *fence);
+extern int r300_cs_parse(struct radeon_cs_parser *p);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+extern int r200_copy_dma(struct radeon_device *rdev,
+   uint64_t src_offset,
+   uint64_t dst_offset,
+   unsigned num_pages,
+   struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+extern void rv370_set_pcie_lanes(struct radeon_device *rdev, int lanes);
+extern int rv370_get_pcie_lanes(struct radeon_device *rdev);
+void rs600_hpd_init(struct radeon_device *rdev);
+void rs600_hpd_fini(struct radeon_device *rdev);
+bool rs600_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd);
+void rs600_hpd_set_polarity(struct radeon_device *rdev,
+   enum radeon_hpd_id hpd);
+void rv515_fini(struct radeon_device *rdev);
+int rv515_suspend(struct radeon_device *rdev);
+int rv515_gpu_reset(struct radeon_device *rdev);
+void rv515_ring_start(struct radeon_device *rdev);
+void rv515_bandwidth_update(struct radeon_device *rdev);
+
+struct radeon_asic r520_asic = {
+   .init = r520_init,
+   .fini = rv515_fini,
+   .suspend = rv515_suspend,
+   .resume = r520_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = rv515_gpu_reset,
+   .gart_tlb_flush = rv370_pcie_gart_tlb_flush,
+   .gart_set_page = rv370_pcie_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = rv515_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = rs600_irq_set,
+   .irq_process = rs600_irq_process,
+   .get_vblank_counter = rs600_get_vblank_counter,
+   .fence_ring_emit = r300_fence_ring_emit,
+   .cs_parse = r300_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .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,
+   .get_pcie_lanes = rv370_get_pcie_lanes,
+   .set_pcie_lanes = rv370_set_pcie_lanes,
+   .set_clock_gating = radeon_atom_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = rv515_bandwidth_update,
+   .hpd_init = rs600_hpd_init,
+   .hpd_fini = rs600_hpd_fini,
+   .hpd_sense = rs600_hpd_sense,
+   .hpd_set_polarity = rs600_hpd_set_polarity,
+   .ioctl_wait_idle = NULL,
+};
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 941ef08..3137f2c 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -115,7 +115,6 @@ extern int r420_resume(struct radeon_device *rdev);
 
 extern struct radeon_asic r420_asic;
 
-
 /*
  * rs400,rs480
  */
@@ -188,43 +187,8 @@ extern struct radeon_asic rv515_asic;
  */
 int r520_init(struct radeon_device *rdev);
 int r520_resume(struct radeon_device *rdev);
-static struct radeon_asic r520_asic = {
-   .init = r520_init,
-   .fini = rv515_fini,
-   .suspend = rv515_suspend,
-   .resume = r520_resume,
-   .vga_set_state = r100_vga_set_state,
-   .gpu_reset = rv515_gpu_reset,
-   

[PATCH 02/14] drm/radoen: move r200 asic struct to r200.c

[Daniel Vetter]

Like for the r100.

Because radeon_asic.h is not yet usable as a header file, I had to
copy a few shared function declarations into r200.c. Yes, this is
ugly but not actually worse than current state. And it'll all be
gone when this header untangling is done.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/r200.c|   71 ++
 drivers/gpu/drm/radeon/radeon_asic.h |   37 +-
 2 files changed, 72 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c
index 1146c99..7dfeab3 100644
--- a/drivers/gpu/drm/radeon/r200.c
+++ b/drivers/gpu/drm/radeon/r200.c
@@ -507,3 +507,74 @@ void r200_set_safe_registers(struct radeon_device *rdev)
rdev-config.r100.reg_safe_bm = r200_reg_safe_bm;
rdev-config.r100.reg_safe_bm_size = ARRAY_SIZE(r200_reg_safe_bm);
 }
+
+extern int r100_init(struct radeon_device *rdev);
+extern void r100_fini(struct radeon_device *rdev);
+extern int r100_suspend(struct radeon_device *rdev);
+extern int r100_resume(struct radeon_device *rdev);
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+int r100_gpu_reset(struct radeon_device *rdev);
+void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
+int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+void r100_cp_commit(struct radeon_device *rdev);
+void r100_ring_start(struct radeon_device *rdev);
+int r100_ring_test(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+int r100_irq_set(struct radeon_device *rdev);
+int r100_irq_process(struct radeon_device *rdev);
+u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc);
+void r100_fence_ring_emit(struct radeon_device *rdev,
+ struct radeon_fence *fence);
+int r100_cs_parse(struct radeon_cs_parser *p);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r100_bandwidth_update(struct radeon_device *rdev);
+void r100_hpd_init(struct radeon_device *rdev);
+void r100_hpd_fini(struct radeon_device *rdev);
+bool r100_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd);
+void r100_hpd_set_polarity(struct radeon_device *rdev,
+  enum radeon_hpd_id hpd);
+
+struct radeon_asic r200_asic = {
+   .init = r100_init,
+   .fini = r100_fini,
+   .suspend = r100_suspend,
+   .resume = r100_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r100_gpu_reset,
+   .gart_tlb_flush = r100_pci_gart_tlb_flush,
+   .gart_set_page = r100_pci_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r100_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r100_fence_ring_emit,
+   .cs_parse = r100_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .get_engine_clock = radeon_legacy_get_engine_clock,
+   .set_engine_clock = radeon_legacy_set_engine_clock,
+   .get_memory_clock = radeon_legacy_get_memory_clock,
+   .set_memory_clock = NULL,
+   .set_pcie_lanes = NULL,
+   .set_clock_gating = radeon_legacy_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init = r100_hpd_init,
+   .hpd_fini = r100_hpd_fini,
+   .hpd_sense = r100_hpd_sense,
+   .hpd_set_polarity = r100_hpd_set_polarity,
+   .ioctl_wait_idle = NULL,
+};
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index a2b4bd4..e2378ce 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -79,43 +79,8 @@ extern int r200_copy_dma(struct radeon_device *rdev,
uint64_t dst_offset,
unsigned num_pages,
struct radeon_fence *fence);
-static struct radeon_asic r200_asic = {
-   .init = r100_init,
-   .fini = r100_fini,
-   .suspend = r100_suspend,
-   .resume = r100_resume,
-   .vga_set_state = r100_vga_set_state,
-   .gpu_reset = r100_gpu_reset,
-   .gart_tlb_flush = r100_pci_gart_tlb_flush,
-   .gart_set_page = r100_pci_gart_set_page,
-   .cp_commit = r100_cp_commit,
-

[PATCH 12/14] drm/radoen: move evergreen asic struct to evergreen.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/evergreen.c   |   43 ++
 drivers/gpu/drm/radeon/radeon_asic.h |   35 +--
 2 files changed, 44 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index bd2e7aa..618006a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -765,3 +765,46 @@ void evergreen_fini(struct radeon_device *rdev)
rdev-bios = NULL;
radeon_dummy_page_fini(rdev);
 }
+
+void r600_vga_set_state(struct radeon_device *rdev, bool state);
+void r600_pcie_gart_tlb_flush(struct radeon_device *rdev);
+int rs600_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+int r600_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r600_clear_surface_reg(struct radeon_device *rdev, int reg);
+
+struct radeon_asic evergreen_asic = {
+   .init = evergreen_init,
+   .fini = evergreen_fini,
+   .suspend = evergreen_suspend,
+   .resume = evergreen_resume,
+   .cp_commit = NULL,
+   .gpu_reset = evergreen_gpu_reset,
+   .vga_set_state = r600_vga_set_state,
+   .gart_tlb_flush = r600_pcie_gart_tlb_flush,
+   .gart_set_page = rs600_gart_set_page,
+   .ring_test = NULL,
+   .ring_ib_execute = NULL,
+   .irq_set = NULL,
+   .irq_process = NULL,
+   .get_vblank_counter = NULL,
+   .fence_ring_emit = NULL,
+   .cs_parse = NULL,
+   .copy_blit = NULL,
+   .copy_dma = NULL,
+   .copy = NULL,
+   .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_pcie_lanes = NULL,
+   .set_clock_gating = NULL,
+   .set_surface_reg = r600_set_surface_reg,
+   .clear_surface_reg = r600_clear_surface_reg,
+   .bandwidth_update = evergreen_bandwidth_update,
+   .hpd_init = evergreen_hpd_init,
+   .hpd_fini = evergreen_hpd_fini,
+   .hpd_sense = evergreen_hpd_sense,
+   .hpd_set_polarity = evergreen_hpd_set_polarity,
+};
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 57dceeb..4db2e37 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -259,39 +259,6 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, enum 
radeon_hpd_id hpd);
 void evergreen_hpd_set_polarity(struct radeon_device *rdev,
enum radeon_hpd_id hpd);
 
-static struct radeon_asic evergreen_asic = {
-   .init = evergreen_init,
-   .fini = evergreen_fini,
-   .suspend = evergreen_suspend,
-   .resume = evergreen_resume,
-   .cp_commit = NULL,
-   .gpu_reset = evergreen_gpu_reset,
-   .vga_set_state = r600_vga_set_state,
-   .gart_tlb_flush = r600_pcie_gart_tlb_flush,
-   .gart_set_page = rs600_gart_set_page,
-   .ring_test = NULL,
-   .ring_ib_execute = NULL,
-   .irq_set = NULL,
-   .irq_process = NULL,
-   .get_vblank_counter = NULL,
-   .fence_ring_emit = NULL,
-   .cs_parse = NULL,
-   .copy_blit = NULL,
-   .copy_dma = NULL,
-   .copy = NULL,
-   .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_pcie_lanes = NULL,
-   .set_clock_gating = NULL,
-   .set_surface_reg = r600_set_surface_reg,
-   .clear_surface_reg = r600_clear_surface_reg,
-   .bandwidth_update = evergreen_bandwidth_update,
-   .hpd_init = evergreen_hpd_init,
-   .hpd_fini = evergreen_hpd_fini,
-   .hpd_sense = evergreen_hpd_sense,
-   .hpd_set_polarity = evergreen_hpd_set_polarity,
-};
+extern struct radeon_asic evergreen_asic;
 
 #endif
-- 
1.7.0


--
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 04/14] drm/radeon: move r420 asic struct to r420.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/r420.c|   75 ++
 drivers/gpu/drm/radeon/radeon_asic.h |   39 +-
 2 files changed, 77 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index c7593b8..2488edb 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -417,3 +417,78 @@ int r420_debugfs_pipes_info_init(struct radeon_device 
*rdev)
return 0;
 #endif
 }
+
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+void r100_cp_commit(struct radeon_device *rdev);
+int r100_ring_test(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+int r100_irq_set(struct radeon_device *rdev);
+int r100_irq_process(struct radeon_device *rdev);
+u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r100_bandwidth_update(struct radeon_device *rdev);
+void r100_hpd_init(struct radeon_device *rdev);
+void r100_hpd_fini(struct radeon_device *rdev);
+bool r100_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd);
+void r100_hpd_set_polarity(struct radeon_device *rdev,
+  enum radeon_hpd_id hpd);
+extern int r200_copy_dma(struct radeon_device *rdev,
+   uint64_t src_offset,
+   uint64_t dst_offset,
+   unsigned num_pages,
+   struct radeon_fence *fence);
+extern void r300_ring_start(struct radeon_device *rdev);
+extern void r300_fence_ring_emit(struct radeon_device *rdev,
+   struct radeon_fence *fence);
+extern int r300_cs_parse(struct radeon_cs_parser *p);
+extern void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev);
+extern int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i, 
uint64_t addr);
+extern void rv370_set_pcie_lanes(struct radeon_device *rdev, int lanes);
+extern int rv370_get_pcie_lanes(struct radeon_device *rdev);
+extern int r300_gpu_reset(struct radeon_device *rdev);
+
+struct radeon_asic r420_asic = {
+   .init = r420_init,
+   .fini = r420_fini,
+   .suspend = r420_suspend,
+   .resume = r420_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r300_gpu_reset,
+   .gart_tlb_flush = rv370_pcie_gart_tlb_flush,
+   .gart_set_page = rv370_pcie_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r300_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r300_fence_ring_emit,
+   .cs_parse = r300_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .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,
+   .get_pcie_lanes = rv370_get_pcie_lanes,
+   .set_pcie_lanes = rv370_set_pcie_lanes,
+   .set_clock_gating = radeon_atom_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init = r100_hpd_init,
+   .hpd_fini = r100_hpd_fini,
+   .hpd_sense = r100_hpd_sense,
+   .hpd_set_polarity = r100_hpd_set_polarity,
+   .ioctl_wait_idle = NULL,
+};
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index f93f8f7..ff408ff 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -112,43 +112,8 @@ extern int r420_init(struct radeon_device *rdev);
 extern void r420_fini(struct radeon_device *rdev);
 extern int r420_suspend(struct radeon_device *rdev);
 extern int r420_resume(struct radeon_device *rdev);
-static struct radeon_asic r420_asic = {
-   .init = r420_init,
-   .fini = r420_fini,
-   .suspend = r420_suspend,
-   .resume = r420_resume,
-   .vga_set_state = r100_vga_set_state,
-   .gpu_reset = r300_gpu_reset,
-   .gart_tlb_flush = rv370_pcie_gart_tlb_flush,
-   .gart_set_page = rv370_pcie_gart_set_page,
-   .cp_commit = r100_cp_commit,
-   .ring_start = 

[PATCH 08/14] drm/radoen: move rv515 asic struct to rv515.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon_asic.h |   38 +-
 drivers/gpu/drm/radeon/rv515.c   |   72 ++
 2 files changed, 73 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 9ff56ff..941ef08 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -180,44 +180,8 @@ void rv515_pcie_wreg(struct radeon_device *rdev, uint32_t 
reg, uint32_t v);
 void rv515_bandwidth_update(struct radeon_device *rdev);
 int rv515_resume(struct radeon_device *rdev);
 int rv515_suspend(struct radeon_device *rdev);
-static struct radeon_asic rv515_asic = {
-   .init = rv515_init,
-   .fini = rv515_fini,
-   .suspend = rv515_suspend,
-   .resume = rv515_resume,
-   .vga_set_state = r100_vga_set_state,
-   .gpu_reset = rv515_gpu_reset,
-   .gart_tlb_flush = rv370_pcie_gart_tlb_flush,
-   .gart_set_page = rv370_pcie_gart_set_page,
-   .cp_commit = r100_cp_commit,
-   .ring_start = rv515_ring_start,
-   .ring_test = r100_ring_test,
-   .ring_ib_execute = r100_ring_ib_execute,
-   .irq_set = rs600_irq_set,
-   .irq_process = rs600_irq_process,
-   .get_vblank_counter = rs600_get_vblank_counter,
-   .fence_ring_emit = r300_fence_ring_emit,
-   .cs_parse = r300_cs_parse,
-   .copy_blit = r100_copy_blit,
-   .copy_dma = r200_copy_dma,
-   .copy = r100_copy_blit,
-   .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,
-   .get_pcie_lanes = rv370_get_pcie_lanes,
-   .set_pcie_lanes = rv370_set_pcie_lanes,
-   .set_clock_gating = radeon_atom_set_clock_gating,
-   .set_surface_reg = r100_set_surface_reg,
-   .clear_surface_reg = r100_clear_surface_reg,
-   .bandwidth_update = rv515_bandwidth_update,
-   .hpd_init = rs600_hpd_init,
-   .hpd_fini = rs600_hpd_fini,
-   .hpd_sense = rs600_hpd_sense,
-   .hpd_set_polarity = rs600_hpd_set_polarity,
-   .ioctl_wait_idle = NULL,
-};
 
+extern struct radeon_asic rv515_asic;
 
 /*
  * r520,rv530,rv560,rv570,r580
diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
index bea747d..a27494f 100644
--- a/drivers/gpu/drm/radeon/rv515.c
+++ b/drivers/gpu/drm/radeon/rv515.c
@@ -1182,3 +1182,75 @@ void rv515_bandwidth_update(struct radeon_device *rdev)
}
rv515_bandwidth_avivo_update(rdev);
 }
+
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+extern void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev);
+extern int rv370_pcie_gart_set_page(struct radeon_device *rdev, int i, 
uint64_t addr);
+void r100_cp_commit(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+int r100_ring_test(struct radeon_device *rdev);
+int rs600_irq_set(struct radeon_device *rdev);
+int rs600_irq_process(struct radeon_device *rdev);
+u32 rs600_get_vblank_counter(struct radeon_device *rdev, int crtc);
+extern void r300_fence_ring_emit(struct radeon_device *rdev,
+   struct radeon_fence *fence);
+extern int r300_cs_parse(struct radeon_cs_parser *p);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+extern int r200_copy_dma(struct radeon_device *rdev,
+   uint64_t src_offset,
+   uint64_t dst_offset,
+   unsigned num_pages,
+   struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+extern void rv370_set_pcie_lanes(struct radeon_device *rdev, int lanes);
+extern int rv370_get_pcie_lanes(struct radeon_device *rdev);
+void rs600_hpd_init(struct radeon_device *rdev);
+void rs600_hpd_fini(struct radeon_device *rdev);
+bool rs600_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd);
+void rs600_hpd_set_polarity(struct radeon_device *rdev,
+   enum radeon_hpd_id hpd);
+
+struct radeon_asic rv515_asic = {
+   .init = rv515_init,
+   .fini = rv515_fini,
+   .suspend = rv515_suspend,
+   .resume = rv515_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = rv515_gpu_reset,
+   .gart_tlb_flush = rv370_pcie_gart_tlb_flush,
+   .gart_set_page = rv370_pcie_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = rv515_ring_start,

[PATCH 05/14] drm/radoen: move rs400 asic struct to rs400.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon_asic.h |   38 +-
 drivers/gpu/drm/radeon/rs400.c   |   72 ++
 2 files changed, 73 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index ff408ff..5671417 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -127,44 +127,8 @@ void rs400_gart_tlb_flush(struct radeon_device *rdev);
 int rs400_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
 uint32_t rs400_mc_rreg(struct radeon_device *rdev, uint32_t reg);
 void rs400_mc_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v);
-static struct radeon_asic rs400_asic = {
-   .init = rs400_init,
-   .fini = rs400_fini,
-   .suspend = rs400_suspend,
-   .resume = rs400_resume,
-   .vga_set_state = r100_vga_set_state,
-   .gpu_reset = r300_gpu_reset,
-   .gart_tlb_flush = rs400_gart_tlb_flush,
-   .gart_set_page = rs400_gart_set_page,
-   .cp_commit = r100_cp_commit,
-   .ring_start = r300_ring_start,
-   .ring_test = r100_ring_test,
-   .ring_ib_execute = r100_ring_ib_execute,
-   .irq_set = r100_irq_set,
-   .irq_process = r100_irq_process,
-   .get_vblank_counter = r100_get_vblank_counter,
-   .fence_ring_emit = r300_fence_ring_emit,
-   .cs_parse = r300_cs_parse,
-   .copy_blit = r100_copy_blit,
-   .copy_dma = r200_copy_dma,
-   .copy = r100_copy_blit,
-   .get_engine_clock = radeon_legacy_get_engine_clock,
-   .set_engine_clock = radeon_legacy_set_engine_clock,
-   .get_memory_clock = radeon_legacy_get_memory_clock,
-   .set_memory_clock = NULL,
-   .get_pcie_lanes = NULL,
-   .set_pcie_lanes = NULL,
-   .set_clock_gating = radeon_legacy_set_clock_gating,
-   .set_surface_reg = r100_set_surface_reg,
-   .clear_surface_reg = r100_clear_surface_reg,
-   .bandwidth_update = r100_bandwidth_update,
-   .hpd_init = r100_hpd_init,
-   .hpd_fini = r100_hpd_fini,
-   .hpd_sense = r100_hpd_sense,
-   .hpd_set_polarity = r100_hpd_set_polarity,
-   .ioctl_wait_idle = NULL,
-};
 
+extern struct radeon_asic rs400_asic;
 
 /*
  * rs600.
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index 626d518..4d5427a 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -536,3 +536,75 @@ int rs400_init(struct radeon_device *rdev)
}
return 0;
 }
+
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+extern int r300_gpu_reset(struct radeon_device *rdev);
+void r100_cp_commit(struct radeon_device *rdev);
+void r300_ring_start(struct radeon_device *rdev);
+int r100_irq_set(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+int r100_irq_set(struct radeon_device *rdev);
+int r100_irq_process(struct radeon_device *rdev);
+u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc);
+extern void r300_fence_ring_emit(struct radeon_device *rdev,
+   struct radeon_fence *fence);
+extern int r300_cs_parse(struct radeon_cs_parser *p);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+extern int r200_copy_dma(struct radeon_device *rdev,
+   uint64_t src_offset,
+   uint64_t dst_offset,
+   unsigned num_pages,
+   struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r100_bandwidth_update(struct radeon_device *rdev);
+void r100_hpd_init(struct radeon_device *rdev);
+void r100_hpd_fini(struct radeon_device *rdev);
+bool r100_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd);
+void r100_hpd_set_polarity(struct radeon_device *rdev,
+  enum radeon_hpd_id hpd);
+int r100_ring_test(struct radeon_device *rdev);
+
+struct radeon_asic rs400_asic = {
+   .init = rs400_init,
+   .fini = rs400_fini,
+   .suspend = rs400_suspend,
+   .resume = rs400_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r300_gpu_reset,
+   .gart_tlb_flush = rs400_gart_tlb_flush,
+   .gart_set_page = rs400_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r300_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter 

[PATCH 03/14] drm/radeon: move r300 asic structs to r300.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/r300.c|  105 ++
 drivers/gpu/drm/radeon/radeon_asic.h |   76 +
 2 files changed, 107 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 4cef90c..2592ba6 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1440,3 +1440,108 @@ int r300_init(struct radeon_device *rdev)
}
return 0;
 }
+
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
+int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
+void r100_cp_commit(struct radeon_device *rdev);
+int r100_ring_test(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+int r100_irq_set(struct radeon_device *rdev);
+int r100_irq_process(struct radeon_device *rdev);
+u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r100_bandwidth_update(struct radeon_device *rdev);
+void r100_hpd_init(struct radeon_device *rdev);
+void r100_hpd_fini(struct radeon_device *rdev);
+bool r100_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd);
+void r100_hpd_set_polarity(struct radeon_device *rdev,
+  enum radeon_hpd_id hpd);
+extern int r200_copy_dma(struct radeon_device *rdev,
+   uint64_t src_offset,
+   uint64_t dst_offset,
+   unsigned num_pages,
+   struct radeon_fence *fence);
+
+struct radeon_asic r300_asic = {
+   .init = r300_init,
+   .fini = r300_fini,
+   .suspend = r300_suspend,
+   .resume = r300_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r300_gpu_reset,
+   .gart_tlb_flush = r100_pci_gart_tlb_flush,
+   .gart_set_page = r100_pci_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r300_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r300_fence_ring_emit,
+   .cs_parse = r300_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .get_engine_clock = radeon_legacy_get_engine_clock,
+   .set_engine_clock = radeon_legacy_set_engine_clock,
+   .get_memory_clock = radeon_legacy_get_memory_clock,
+   .set_memory_clock = NULL,
+   .get_pcie_lanes = rv370_get_pcie_lanes,
+   .set_pcie_lanes = rv370_set_pcie_lanes,
+   .set_clock_gating = radeon_legacy_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init = r100_hpd_init,
+   .hpd_fini = r100_hpd_fini,
+   .hpd_sense = r100_hpd_sense,
+   .hpd_set_polarity = r100_hpd_set_polarity,
+   .ioctl_wait_idle = NULL,
+};
+
+struct radeon_asic r300_asic_pcie = {
+   .init = r300_init,
+   .fini = r300_fini,
+   .suspend = r300_suspend,
+   .resume = r300_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r300_gpu_reset,
+   .gart_tlb_flush = rv370_pcie_gart_tlb_flush,
+   .gart_set_page = rv370_pcie_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r300_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r300_fence_ring_emit,
+   .cs_parse = r300_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .get_engine_clock = radeon_legacy_get_engine_clock,
+   .set_engine_clock = radeon_legacy_set_engine_clock,
+   .get_memory_clock = radeon_legacy_get_memory_clock,
+   .set_memory_clock = NULL,
+   .set_pcie_lanes = rv370_set_pcie_lanes,
+   .set_clock_gating = radeon_legacy_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init 

[PATCH 06/14] drm/radoen: move rs600 asic struct to rs600.c

[Daniel Vetter]

Like for r200.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon_asic.h |   39 +
 drivers/gpu/drm/radeon/rs600.c   |   63 ++
 2 files changed, 64 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 5671417..2de7e08 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -151,44 +151,7 @@ bool rs600_hpd_sense(struct radeon_device *rdev, enum 
radeon_hpd_id hpd);
 void rs600_hpd_set_polarity(struct radeon_device *rdev,
enum radeon_hpd_id hpd);
 
-static struct radeon_asic rs600_asic = {
-   .init = rs600_init,
-   .fini = rs600_fini,
-   .suspend = rs600_suspend,
-   .resume = rs600_resume,
-   .vga_set_state = r100_vga_set_state,
-   .gpu_reset = r300_gpu_reset,
-   .gart_tlb_flush = rs600_gart_tlb_flush,
-   .gart_set_page = rs600_gart_set_page,
-   .cp_commit = r100_cp_commit,
-   .ring_start = r300_ring_start,
-   .ring_test = r100_ring_test,
-   .ring_ib_execute = r100_ring_ib_execute,
-   .irq_set = rs600_irq_set,
-   .irq_process = rs600_irq_process,
-   .get_vblank_counter = rs600_get_vblank_counter,
-   .fence_ring_emit = r300_fence_ring_emit,
-   .cs_parse = r300_cs_parse,
-   .copy_blit = r100_copy_blit,
-   .copy_dma = r200_copy_dma,
-   .copy = r100_copy_blit,
-   .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,
-   .get_pcie_lanes = NULL,
-   .set_pcie_lanes = NULL,
-   .set_clock_gating = radeon_atom_set_clock_gating,
-   .set_surface_reg = r100_set_surface_reg,
-   .clear_surface_reg = r100_clear_surface_reg,
-   .bandwidth_update = rs600_bandwidth_update,
-   .hpd_init = rs600_hpd_init,
-   .hpd_fini = rs600_hpd_fini,
-   .hpd_sense = rs600_hpd_sense,
-   .hpd_set_polarity = rs600_hpd_set_polarity,
-   .ioctl_wait_idle = NULL,
-};
-
+extern struct radeon_asic rs600_asic;
 
 /*
  * rs690,rs740
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index 47f046b..d3f75fd 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -681,3 +681,66 @@ int rs600_init(struct radeon_device *rdev)
}
return 0;
 }
+
+void r100_vga_set_state(struct radeon_device *rdev, bool state);
+extern int r300_gpu_reset(struct radeon_device *rdev);
+void r100_cp_commit(struct radeon_device *rdev);
+void r300_ring_start(struct radeon_device *rdev);
+void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
+u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc);
+extern void r300_fence_ring_emit(struct radeon_device *rdev,
+   struct radeon_fence *fence);
+extern int r300_cs_parse(struct radeon_cs_parser *p);
+int r100_copy_blit(struct radeon_device *rdev,
+  uint64_t src_offset,
+  uint64_t dst_offset,
+  unsigned num_pages,
+  struct radeon_fence *fence);
+extern int r200_copy_dma(struct radeon_device *rdev,
+   uint64_t src_offset,
+   uint64_t dst_offset,
+   unsigned num_pages,
+   struct radeon_fence *fence);
+int r100_set_surface_reg(struct radeon_device *rdev, int reg,
+uint32_t tiling_flags, uint32_t pitch,
+uint32_t offset, uint32_t obj_size);
+int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+int r100_ring_test(struct radeon_device *rdev);
+
+struct radeon_asic rs600_asic = {
+   .init = rs600_init,
+   .fini = rs600_fini,
+   .suspend = rs600_suspend,
+   .resume = rs600_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r300_gpu_reset,
+   .gart_tlb_flush = rs600_gart_tlb_flush,
+   .gart_set_page = rs600_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r300_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = rs600_irq_set,
+   .irq_process = rs600_irq_process,
+   .get_vblank_counter = rs600_get_vblank_counter,
+   .fence_ring_emit = r300_fence_ring_emit,
+   .cs_parse = r300_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .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,
+   .get_pcie_lanes = NULL,
+   .set_pcie_lanes = NULL,
+   

[Bug 26430] [KMS] Hw i2c patch doesn't work fully on rv280

[bugzilla-daemon]

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


Andrew Randrianasulu rand...@mail.ru changed:

   What|Removed |Added

  Attachment #9|0   |1
is obsolete||
  Attachment #33498|0   |1
is obsolete||




--- Comment #9 from Andrew Randrianasulu rand...@mail.ru  2010-03-11 06:02:13 
PST ---
Created an attachment (id=33953)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33953)
dmesg from 2.6.34-rc1-005

This is using 2.6.34-rc1 mainline kernel + patches from
http://article.gmane.org/gmane.comp.video.dri.devel/44144 


0001-i2c-algo-bit-Add-pre-and-post-xfer-hooks.patch ,
0002-drm-radeon-kms-use-new-pre-post_xfer-i2c-bit-algo-h.patch


-- 
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: My goal

[Bernie Thompson]

2010/3/10  aiv...@latnet.lv:
 Over the world are around 10 versions of multiseat:

There's also the USB multiseat case, which avoids shared resources
(VGA arbiter) and so can cleanly launch independent X instances for
each USB graphics device even now. Better yet, the USB topology can be
used (via udev scripts) to know exactly which keyboard, mouse,
keyboard, etc. go together so adding seats is completely plug and
play.

BUT it's a bit hackish on Linux today, because of the some assumptions
that need cleaned up (e.g. that all graphics are on PCIe).  Some of
that cleanup is happening (e.g. hal-libudev), but it could use a lot
more attention and experienced help on the USB case. Also on
whether/how to move USB graphics driver from fbdev-dri with matching
xorg driver, on better newgdm/consolekit integration, and then on
getting this into distros.

http://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/
to see stuff to get it running in the hal/gdmdynamic world.

A lot of discussion and work is on the libdlo list, but needs more
contact with experts on those lists with deeper expertise (dri, fbdev,
console, etc.)

Best wishes,
Bernie
http://plugable.com/

--
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: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Alex Deucher]

2010/3/11 Michel Dänzer mic...@daenzer.net:
 On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
 On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote:
  On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org 
  wrote:
 
  See my other post about what fbdev really means in its historical
  context. The struct fb_info really maps better to drm_crtc than to
  drm_framebuffer. In fact take the case of the matrox fbdev driver. It
  creates two framebuffer devices even tho it used one static framebuffer.
  What the driver does is splits the framebuffer in two and assigned each
  part to a CRTC.
 
  The only problem with that is that it eats a lot of memory for the
  console which limits X when it starts. On cards with limited vram ,
  you might not have enough memory left for any meaningful acceleration
  when X starts.

 It would be nice to find a way to reclaim the console memory for X,
 but I'm not sure that can be done and still provide a good way to
 provide oops support.

 What do you think the average user will care about more?

      * Seeing kernel oops/panic output about once in a lifetime.
      * Being able to start/use X in the first place and enabling it to
        use all of VRAM.

 Personally, I've never even seen any kernel oops/panic output despite
 numerous opportunities for that in the couple of months I've been using
 KMS. But I have spent considerable time and effort trying to get rid of
 the pinned fbcon BO. If the oops/panic output is the only thing
 preventing that, maybe that should only be enabled via some module
 option for developers.

I'm all for it!

Alex

--
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: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[James Simmons]

  It would be nice to find a way to reclaim the console memory for X,
  but I'm not sure that can be done and still provide a good way to
  provide oops support.
 
  What do you think the average user will care about more?
 
       * Seeing kernel oops/panic output about once in a lifetime.
       * Being able to start/use X in the first place and enabling it to
         use all of VRAM.
 
  Personally, I've never even seen any kernel oops/panic output despite
  numerous opportunities for that in the couple of months I've been using
  KMS. But I have spent considerable time and effort trying to get rid of
  the pinned fbcon BO. If the oops/panic output is the only thing
  preventing that, maybe that should only be enabled via some module
  option for developers.
 
 I'm all for it!

I'm looking into the details for this. It will require some changes to 
internal apis to make it to work.
--
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 26426] Xserver crash on r600SetTexOffset with 3d effects enabled

[bugzilla-daemon]

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





--- Comment #1 from Raúl rasas...@gmail.com  2010-03-11 07:32:04 PST ---
Just for your information. Today, I got the same crash with xserver 1.7.5.
Regards,


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

[Bug 15276] latest git kernel: general protection fault: 0000 [#1]

[bugzilla-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=15276





--- Comment #54 from Jérôme Glisse gli...@freedesktop.org  2010-03-11 
15:35:21 ---
They should, haven't tested them against those

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of 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: [PATCH 2/2] libdrm_radeon: Optimize cs_gem_reloc to do less looping.

[Michel Dänzer]

On Wed, 2010-03-10 at 20:42 +0200, Pauli Nieminen wrote: 
 bo-referenced_in_cs is checked if bo is already in cs. Adding and removing
 reference in bo is done with atomic operations to allow parallel access to a
 bo from multiple contexts.
 
 cs-id generation code quarentees there is not duplicated ids which limits
 number of cs-ids to 32. If there is more cs objects rest will get id 0.
 
 This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
 to 2.6%.
 
 Signed-off-by: Pauli Nieminen suok...@gmail.com

This also needs something like the below for configure to verify that
atomic ops are available.

diff --git a/configure.ac b/configure.ac
index fe00176..e419dd7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -173,7 +173,7 @@ if test x$HAVE_LIBUDEV = xyes; then
 fi
 AM_CONDITIONAL(HAVE_LIBUDEV, [test x$HAVE_LIBUDEV = xyes])
 
-if test x$INTEL != xno; then
+if test x$INTEL != xno || test x$RADEON != xno; then
 # Check for atomic intrinsics
 AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives,
 [
@@ -206,13 +206,23 @@ if test x$INTEL != xno; then
 fi
 
 if test x$drm_cv_atomic_primitives = xnone; then
-   if test x$INTEL != xauto; then
+   if test x$INTEL = xyes; then
AC_MSG_ERROR([libdrm_intel depends upon atomic operations, 
which were not found for your compiler/cpu. Try compiling with -march=native, 
or install the libatomics-op-dev package, or, failing both of those, disable 
support for Intel GPUs by passing --disable-intel to ./configure])
   else
INTEL=no
   fi
+   if test x$RADEON = xyes; then
+   AC_MSG_ERROR([libdrm_radeon depends upon atomic operations, 
which were not found for your compiler/cpu. Try compiling with -march=native, 
or install the libatomics-op-dev package, or, failing both of those, disable 
support for Radeon GPUs by passing --disable-radeon to ./configure])
+  else
+   RADEON=no
+  fi
 else
-  INTEL=yes
+   if test x$INTEL != xno; then
+   INTEL=yes
+   fi
+   if test x$RADEON != xno; then
+   RADEON=yes
+   fi
 fi
 fi
 



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

--
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 00/14] cleanup radeon_asic.h

[Jerome Glisse]

On Thu, Mar 11, 2010 at 02:06:02PM +0100, Daniel Vetter wrote:
 Hi all,
 
 This patch pile moves the static struct radeon_asic asic definitions
 form radeon_asic.h into the asic-specific files, where I think they belong.
 This way radeon_asic.h becomes a real header file that can be #included.
 And indeed, with all the copypasting of function declarations, one has
 gotten out of sync.
 
 The next step would be to collect asic specific declarations in
 radeon_asic.h - atm they are somewhat scattered. But this can easily be
 done on the go and has way too much potential for conflicts with other
 patches. So I didn't do this.
 
 Tested on my rv570.
 
 Comments higly welcome.
 
 Yours, Daniel

It all looks good from a quick read through of the patches. For
gathering asic function prototype i kind of started adding them
to radeon.h at the bottom (there is already a bunch of them). Thus
i think radeon_asic.h can be kill and extern declaration directly
put into radeon_asic.c

Cheers,
Jerome

 
 Daniel Vetter (14):
   drm/radoen: move r100 asic struct to r100.c
   drm/radoen: move r200 asic struct to r200.c
   drm/radeon: move r300 asic structs to r300.c
   drm/radeon: move r420 asic struct to r420.c
   drm/radoen: move rs400 asic struct to rs400.c
   drm/radoen: move rs600 asic struct to rs600.c
   drm/radoen: move rs690 asic struct to rs690.c
   drm/radoen: move rv515 asic struct to rv515.c
   drm/radoen: move r520 asic struct to r520.c
   drm/radoen: move r600 asic struct to r600.c
   drm/radoen: move rv770 asic struct to rv770.c
   drm/radoen: move evergreen asic struct to evergreen.c
   drm/radoen: unconfuse return value of radeon_asic-clear_surface_reg
   drm/radeon: include radeon_asic.h in asic.c
 
  drivers/gpu/drm/radeon/evergreen.c   |   39 +++-
  drivers/gpu/drm/radeon/r100.c|   39 +++
  drivers/gpu/drm/radeon/r200.c|   38 +++
  drivers/gpu/drm/radeon/r300.c|   76 ++
  drivers/gpu/drm/radeon/r420.c|   39 +++
  drivers/gpu/drm/radeon/r520.c|   39 +++
  drivers/gpu/drm/radeon/r600.c|   43 +++-
  drivers/gpu/drm/radeon/radeon.h  |3 +-
  drivers/gpu/drm/radeon/radeon_asic.h |  494 
 ++
  drivers/gpu/drm/radeon/rs400.c   |   39 +++
  drivers/gpu/drm/radeon/rs600.c   |   43 +++-
  drivers/gpu/drm/radeon/rs690.c   |   39 +++
  drivers/gpu/drm/radeon/rv515.c   |   41 +++-
  drivers/gpu/drm/radeon/rv770.c   |   42 +++-
  14 files changed, 518 insertions(+), 496 deletions(-)
 
 
 --
 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
 

--
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 26426] Xserver crash on r600SetTexOffset with 3d effects enabled

[bugzilla-daemon]

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


Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #33065|text/x-log  |text/plain
  mime type||
  Attachment #33065|0   |1
   is patch||




-- 
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: [PATCH 00/14] cleanup radeon_asic.h

[Alex Deucher]

On Thu, Mar 11, 2010 at 8:06 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Hi all,

 This patch pile moves the static struct radeon_asic asic definitions
 form radeon_asic.h into the asic-specific files, where I think they belong.
 This way radeon_asic.h becomes a real header file that can be #included.
 And indeed, with all the copypasting of function declarations, one has
 gotten out of sync.

 The next step would be to collect asic specific declarations in
 radeon_asic.h - atm they are somewhat scattered. But this can easily be
 done on the go and has way too much potential for conflicts with other
 patches. So I didn't do this.

 Tested on my rv570.

 Comments higly welcome.


I like keeping all the asic definitions in one file as you tend to
need to update them all at one time and having them spread across all
the asic files increases the likelihood of one or more of them getting
missed.  But I can live with it if other folks think it's a good idea.

Alex

 Yours, Daniel

 Daniel Vetter (14):
  drm/radoen: move r100 asic struct to r100.c
  drm/radoen: move r200 asic struct to r200.c
  drm/radeon: move r300 asic structs to r300.c
  drm/radeon: move r420 asic struct to r420.c
  drm/radoen: move rs400 asic struct to rs400.c
  drm/radoen: move rs600 asic struct to rs600.c
  drm/radoen: move rs690 asic struct to rs690.c
  drm/radoen: move rv515 asic struct to rv515.c
  drm/radoen: move r520 asic struct to r520.c
  drm/radoen: move r600 asic struct to r600.c
  drm/radoen: move rv770 asic struct to rv770.c
  drm/radoen: move evergreen asic struct to evergreen.c
  drm/radoen: unconfuse return value of radeon_asic-clear_surface_reg

This one should be applied.

  drm/radeon: include radeon_asic.h in asic.c

  drivers/gpu/drm/radeon/evergreen.c   |   39 +++-
  drivers/gpu/drm/radeon/r100.c        |   39 +++
  drivers/gpu/drm/radeon/r200.c        |   38 +++
  drivers/gpu/drm/radeon/r300.c        |   76 ++
  drivers/gpu/drm/radeon/r420.c        |   39 +++
  drivers/gpu/drm/radeon/r520.c        |   39 +++
  drivers/gpu/drm/radeon/r600.c        |   43 +++-
  drivers/gpu/drm/radeon/radeon.h      |    3 +-
  drivers/gpu/drm/radeon/radeon_asic.h |  494 
 ++
  drivers/gpu/drm/radeon/rs400.c       |   39 +++
  drivers/gpu/drm/radeon/rs600.c       |   43 +++-
  drivers/gpu/drm/radeon/rs690.c       |   39 +++
  drivers/gpu/drm/radeon/rv515.c       |   41 +++-
  drivers/gpu/drm/radeon/rv770.c       |   42 +++-
  14 files changed, 518 insertions(+), 496 deletions(-)


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


--
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 00/14] cleanup radeon_asic.h

[Daniel Vetter]

On Thu, Mar 11, 2010 at 10:54:09AM -0500, Alex Deucher wrote:
 I like keeping all the asic definitions in one file as you tend to
 need to update them all at one time and having them spread across all
 the asic files increases the likelihood of one or more of them getting
 missed.  But I can live with it if other folks think it's a good idea.
 
 Alex

I've also thought about putting all asic structs into one file but decided
against it for two reasons:
- putting the asics into the asic specific files allows us to mark
  asic-private functions as static. This makes code-reading easier. Of
  course, as someone who has just started to look at the radeon drm, I'm
  biased ;)
- there was no .c file around where they'd fit.

Creating a new radeon_asic.c file would be another option of course. If
you think that's much better, I could respin the series.

Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48

--
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 00/14] cleanup radeon_asic.h

[Daniel Vetter]

On Thu, Mar 11, 2010 at 04:46:01PM +0100, Jerome Glisse wrote:
 On Thu, Mar 11, 2010 at 02:06:02PM +0100, Daniel Vetter wrote:
  Hi all,
  
  This patch pile moves the static struct radeon_asic asic definitions
  form radeon_asic.h into the asic-specific files, where I think they belong.
  This way radeon_asic.h becomes a real header file that can be #included.
  And indeed, with all the copypasting of function declarations, one has
  gotten out of sync.
  
  The next step would be to collect asic specific declarations in
  radeon_asic.h - atm they are somewhat scattered. But this can easily be
  done on the go and has way too much potential for conflicts with other
  patches. So I didn't do this.
  
  Tested on my rv570.
  
  Comments higly welcome.
  
  Yours, Daniel
 
 It all looks good from a quick read through of the patches. For
 gathering asic function prototype i kind of started adding them
 to radeon.h at the bottom (there is already a bunch of them). Thus
 i think radeon_asic.h can be kill and extern declaration directly
 put into radeon_asic.c

Yes, I've noticed that radeon.h has started to accumulate some
declarations (because radeon_asic.h could not be included, I think).
IMHO radeon.h is already growing out of bounds, so my plan was to move
these declarations to radeon_asic.h. Most of the functions are only used
by the asic specific support code (eg. r600 the blit stuff) so would only
pollute the general namespace in radeon.h

Does that sound reasonable?

btw, radeon_asic.c doesn't exist here in my tree.

 Cheers,
 Jerome

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48

--
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: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Michal Suchanek]

On 11 March 2010 16:17, James Simmons jsimm...@infradead.org wrote:

  It would be nice to find a way to reclaim the console memory for X,
  but I'm not sure that can be done and still provide a good way to
  provide oops support.
 
  What do you think the average user will care about more?
 
       * Seeing kernel oops/panic output about once in a lifetime.
       * Being able to start/use X in the first place and enabling it to
         use all of VRAM.
 
  Personally, I've never even seen any kernel oops/panic output despite
  numerous opportunities for that in the couple of months I've been using
  KMS. But I have spent considerable time and effort trying to get rid of
  the pinned fbcon BO. If the oops/panic output is the only thing
  preventing that, maybe that should only be enabled via some module
  option for developers.

 I'm all for it!

 I'm looking into the details for this. It will require some changes to
 internal apis to make it to work.


Can't it print the oops on whatever is currently displayed?

It need not be a dedicated buffer as long as there is always some buffer.

But perhaps this is more complex than that.

Thanks

Michal

--
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 00/14] cleanup radeon_asic.h

[Rafał Miłecki]

2010/3/11 Alex Deucher alexdeuc...@gmail.com:
 I like keeping all the asic definitions in one file as you tend to
 need to update them all at one time and having them spread across all
 the asic files increases the likelihood of one or more of them getting
 missed.  But I can live with it if other folks think it's a good idea.

Same here. One file means easier editing. Maybe we could use some
other of proposed tricks?

-- 
Rafał

--
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 00/14] cleanup radeon_asic.h

[Alex Deucher]

2010/3/11 Jerome Glisse gli...@freedesktop.org:
 On Thu, Mar 11, 2010 at 05:24:22PM +0100, Rafał Miłecki wrote:
 2010/3/11 Alex Deucher alexdeuc...@gmail.com:
  I like keeping all the asic definitions in one file as you tend to
  need to update them all at one time and having them spread across all
  the asic files increases the likelihood of one or more of them getting
  missed.  But I can live with it if other folks think it's a good idea.

 Same here. One file means easier editing. Maybe we could use some
 other of proposed tricks?

 --
 Rafał

 I don't have strong feeling but Alex has a point, right now we often
 update them, maybe we should add radeon_asic.c and move asic init
 (function now in radeon_device.c) along structure there.

That seems like a good plan.

Alex

--
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 00/14] cleanup radeon_asic.h

[Daniel Vetter]

On Thu, Mar 11, 2010 at 05:34:28PM +0100, Jerome Glisse wrote:
 On Thu, Mar 11, 2010 at 05:24:22PM +0100, Rafał Miłecki wrote:
  2010/3/11 Alex Deucher alexdeuc...@gmail.com:
   I like keeping all the asic definitions in one file as you tend to
   need to update them all at one time and having them spread across all
   the asic files increases the likelihood of one or more of them getting
   missed.  But I can live with it if other folks think it's a good idea.
  
  Same here. One file means easier editing. Maybe we could use some
  other of proposed tricks?
  
  -- 
  Rafał
 
 I don't have strong feeling but Alex has a point, right now we often
 update them, maybe we should add radeon_asic.c and move asic init
 (function now in radeon_device.c) along structure there.

Ok, convinced. I'll respin the patch series along your idea (creating
radeon_asic.c) and resend.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48

--
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 00/14] cleanup radeon_asic.h

[Jerome Glisse]

On Thu, Mar 11, 2010 at 05:24:22PM +0100, Rafał Miłecki wrote:
 2010/3/11 Alex Deucher alexdeuc...@gmail.com:
  I like keeping all the asic definitions in one file as you tend to
  need to update them all at one time and having them spread across all
  the asic files increases the likelihood of one or more of them getting
  missed.  But I can live with it if other folks think it's a good idea.
 
 Same here. One file means easier editing. Maybe we could use some
 other of proposed tricks?
 
 -- 
 Rafał

I don't have strong feeling but Alex has a point, right now we often
update them, maybe we should add radeon_asic.c and move asic init
(function now in radeon_device.c) along structure there.

Cheers,
Jerome

--
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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Maxim Levitsky]

On Wed, 2010-03-10 at 13:04 +0100, Florian Mickler wrote:
 On Sun, 07 Mar 2010 12:39:15 +0200
 Maxim Levitsky maximlevit...@gmail.com wrote:
 
  On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote:
   On Sun, 07 Mar 2010 00:24:24 +0200
   Maxim Levitsky maximlevit...@gmail.com wrote:
   
On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
 On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
  On Sat, 06 Mar 2010 18:02:51 +0100
  Stephan Raue mailingli...@openelec.tv wrote:
  
   looks this like my problems that i have reported some days ago 
   with 
   Subject Problem using an Mesa based App with recent 
   xorg/mesa/xf86-video-intel (loop?) to Mesa-dev, xorg and 
   intel-gfx list?
   
   i have still this issue, but i dont know what you need for 
   informations 
   to fix the issues?
   
   with ati driver i dont have problems, only here with intel driver 
   on my 
   Thinkpad X200t with intel HDA Graphics card
   
 
 I now see that compiz hangs in same way.
 
 Attached are backtrace of the compiz, and backtrace of etracer which 
 did
 start full screen but became hung on resolution change.
 
 Best regards,
   Maxim Levitsky

Other info that might help:

I took a look at X and found that it was in normal waiting state
sleeping waiting for input.

Also, I found when 'unstable' mesa would appear to work when I start the
X while 'stable' one is used. It was compiz. When compiz is running
using stable mesa, an game does change the resolution 'usualy' without
hang even if uses unstable mesa.

Best regards,
Maxim Levitsky
   
   i found that the kernel updates for 2.6.34-rc1 did make the hang time
   out... this has to be some vblank issue, i assume...
  
  
  Note that I did try git master of linus tree, and that didn't help with
  the hang at all (now pulled it again, but don't see any  changes in drm
  code)
  
  Best regards,
  Maxim Levisky
 
 yeah. i'm sorry. My issues vanished with current git versions of
 libdrm,mesa,xserver,xf86-video-intel ... while trying to find out(in
 vain) which part of the stack did fix the issue, i noticed that the 
 xserver-patches in jesse's tree was which changed hung into
 timeout... 


Note that I updated the stack today, but nothing changed.

Best regards,
Maxim Levitsky


--
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 26430] [KMS] Hw i2c patch doesn't work fully on rv280

[bugzilla-daemon]

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





--- Comment #10 from Alex Deucher ag...@yahoo.com  2010-03-11 10:33:23 PST ---
Created an attachment (id=33961)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33961)
possible fix

Does this patch help?


-- 
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: [PATCHES] radeon drm kms i2c fixes

[Alex Deucher]

On Thu, Mar 11, 2010 at 1:00 PM, Jean Delvare kh...@linux-fr.org wrote:
 Hi Alex,

 On Wed, 10 Mar 2010 19:09:08 -0500, Alex Deucher wrote:
 Thanks to Jean for helping me with the i2c stuff.  I've attached
 Jean's bit algo patch as my radeon patch depends on it.  I'm not sure
 how we want to get that one upstream (either via drm or i2c).

 i2c tree probably. I think I can push it to Linus quickly, it's a small
 one, can't cause a regression, and rc2 isn't out yet.


Excellent.  thanks.

 Previously, the radeon drm registered i2c buses using the radeon algo
 which would use either the hw i2c engine or bit banging depending on
 the bus in question (some are hw capable, others are not, some chips
 don't have support for their hw engines yet, etc.).  The tricky part
 was that the radeon i2c bit buses require some gpio magic before and
 after a transaction which bit algo didn't previously support.
 Unfortunately, it exposed the internal bit algo bus as well we as the
 radeon algo bus which is bad.  With these patches, if the hw engine is
 supported, we use the radeon algo, if not, we use bit algo directly
 with the pre/post_xfer functions to fix up the gpios.

 Looks good. I have one suggestion of possible improvement for the
 future. You could turn rec-hw_capable into a function pointer,
 pointing to the appropriate r*_hw_i2c_xfer() function. This would be
 more efficient that looking up the right function each time
 radeon_hw_i2c_xfer() is called. This would also avoid checking the chip
 model at registration time, to decide between hardware and software
 implementation, as these tests could easily go out of sync with what
 is actually implemented, when you add support for newer chips.


I was actually thinking of doing something similar.  Adding a
hw_i2c_xfer callback to the radeon asic struct and checking that.  I
just haven't gotten around to it yet.

 I've tested on several radeons, but more tested would be nice.

 I have the following in my machine:
 02:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] 
 (rev 01)
 02:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] 
 (Secondary) (rev 01)

 Can I help with testing? I can follow your instructions.

Sure.  You need a kms-enabled graphics stack.  See this for more:
http://wiki.x.org/wiki/radeonBuildHowTo
Then, make sure you have the latest kernel bits and the patches I
posted.  Note that some users have reported problems with the hw i2c
engine on some r1xx-r3xx boards.  I suspect a problematic prescale or
a drive problem.  If you run into issues, please try the patch I
attached to this bug:
http://bugs.freedesktop.org/show_bug.cgi?id=26430

Alex

--
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 00/14] cleanup radeon_asic.h

[Dave Airlie]

2010/3/12 Jerome Glisse gli...@freedesktop.org:
 On Thu, Mar 11, 2010 at 05:24:22PM +0100, Rafał Miłecki wrote:
 2010/3/11 Alex Deucher alexdeuc...@gmail.com:
  I like keeping all the asic definitions in one file as you tend to
  need to update them all at one time and having them spread across all
  the asic files increases the likelihood of one or more of them getting
  missed.  But I can live with it if other folks think it's a good idea.

 Same here. One file means easier editing. Maybe we could use some
 other of proposed tricks?

 --
 Rafał

 I don't have strong feeling but Alex has a point, right now we often
 update them, maybe we should add radeon_asic.c and move asic init
 (function now in radeon_device.c) along structure there.


I've seen it sugggested earlier,

Just don't use declarations in the C file, that isn't acceptable coding.

If we add radeon_asic.h make sure to include that in places that
define the functions as well.

Last thing we want is declarations to diverge by accident.

Dave.

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

[arvin...@gmail.com: [Xen-devel] [Nouveau][Patch RFC] nouveau accelerated on Xen pv-ops kernel]

[Konrad Rzeszutek Wilk]

Hey DRI mailing list,

Below mentioned patch makes Nvidia and (possibly - haven't tested)
Radeon cards KMS work when using pv-ops with Xen.

I was wondering what kind of testing should be done for folks to be
comfortable with this patch? I've some NVidia and Radeon cards (PCI-e
, AGP and PCI) that I can pluck in but I am not sure about the edge
cases. Any thoughts?

The author of the patch has tested this with a NVidia GeForce 9400 in
bare-metal and in pv-ops environment without trouble.

Thanks.
- Forwarded message from Arvind R arvin...@gmail.com -

Date: Wed, 10 Mar 2010 18:51:21 +0530
From: Arvind R arvin...@gmail.com
To: nouv...@lists.freedesktop.org
Cc: xen-de...@lists.xensource.com
Subject: [Xen-devel] [Nouveau][Patch RFC] nouveau accelerated on Xen pv-ops
kernel

Hi,
Following is a simple patch that is needed in nouveau to get
accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's
2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is
almost the mainline merge), was substituted into the kernel-tree.
All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) used
of the same day.

Patch:
diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
--- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
10:19:28.0 +0530
+++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c  2010-03-10
17:28:59.0 +0530
@@ -271,7 +271,10 @@
 */

vma-vm_private_data = bo;
-   vma-vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+   vma-vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
+   if (!((bo-mem.placement  TTM_PL_MASK_MEM)  TTM_PL_FLAG_TT))
+   vma-vm_flags |= VM_IO;
+   vma-vm_page_prot = vma_get_vm_prot(vma-vm_flags);
return 0;
 out_unref:
ttm_bo_unref(bo);

This patch is necessary because, in Xen, PFN of a page is virtualised.
So physical addresses
for DMA programming needs to use the MFN. Xen transparently does the
correct translation
using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, then Xen
assumes that the backing
memory is in the IOMEM space, and PFN equals MFN. If not set,
page_to_pfn() returns MFN.

The patch enables the ttm_bo_vm_fault() handler to behave correctly
under Xen, and has no
side-effects on normal (not under Xen) operations. The use of
TTM_PL_FLAG_TT in the
check assumes that all other placements are backed by device memory or
IO. If there are
any other placements that use system memory, that flag has to be OR'ed
into the check.

The above patch has no implications on a normal kernel or a Xen pv_ops
kernel booted without
the Xen hypervisor. My testing is on a debian-lenny environment on a
Core2 processor with
nVidia GeForce 9400 GT.

___
Xen-devel mailing list
xen-de...@lists.xensource.com
http://lists.xensource.com/xen-devel

- End forwarded message -

--
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 00/14] cleanup radeon_asic.h

[Daniel Vetter]

On Fri, Mar 12, 2010 at 06:52:43AM +1000, Dave Airlie wrote:
  I don't have strong feeling but Alex has a point, right now we often
  update them, maybe we should add radeon_asic.c and move asic init
  (function now in radeon_device.c) along structure there.
 
 
 I've seen it sugggested earlier,
 
 Just don't use declarations in the C file, that isn't acceptable coding.
 
 If we add radeon_asic.h make sure to include that in places that
 define the functions as well.
 
 Last thing we want is declarations to diverge by accident.

Well, this is exactly what I'm trying to fix here. atm radeon_asic.h
contains static struct definitions (i.e. should be a C file) and is
therefore included only exactly _once_. And contains tons of declarations
for the functions it uses. Which are actually in one case not coherent
with the actual definitions!
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48

--
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 4/5] drm/radeon: include radeon_asic.h in the asic specific files

[Daniel Vetter]

In essence this creates a home for all asic specific declarations in
radeon_asic.h

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/evergreen.c |1 +
 drivers/gpu/drm/radeon/r100.c  |1 +
 drivers/gpu/drm/radeon/r200.c  |1 +
 drivers/gpu/drm/radeon/r300.c  |1 +
 drivers/gpu/drm/radeon/r420.c  |1 +
 drivers/gpu/drm/radeon/r520.c  |1 +
 drivers/gpu/drm/radeon/r600.c  |1 +
 drivers/gpu/drm/radeon/rs400.c |1 +
 drivers/gpu/drm/radeon/rs600.c |1 +
 drivers/gpu/drm/radeon/rs690.c |1 +
 drivers/gpu/drm/radeon/rv515.c |1 +
 drivers/gpu/drm/radeon/rv770.c |1 +
 12 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index bd2e7aa..9d6283e 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -25,6 +25,7 @@
 #include linux/platform_device.h
 #include drmP.h
 #include radeon.h
+#include radeon_asic.h
 #include radeon_drm.h
 #include rv770d.h
 #include atom.h
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..d1243c2 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -31,6 +31,7 @@
 #include radeon_drm.h
 #include radeon_reg.h
 #include radeon.h
+#include radeon_asic.h
 #include r100d.h
 #include rs100d.h
 #include rv200d.h
diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c
index 1146c99..85617c3 100644
--- a/drivers/gpu/drm/radeon/r200.c
+++ b/drivers/gpu/drm/radeon/r200.c
@@ -30,6 +30,7 @@
 #include radeon_drm.h
 #include radeon_reg.h
 #include radeon.h
+#include radeon_asic.h
 
 #include r100d.h
 #include r200_reg_safe.h
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 4cef90c..1042cea 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -30,6 +30,7 @@
 #include drm.h
 #include radeon_reg.h
 #include radeon.h
+#include radeon_asic.h
 #include radeon_drm.h
 #include r100_track.h
 #include r300d.h
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index c7593b8..2ab35ff 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 radeon_asic.h
 #include atom.h
 #include r100d.h
 #include r420d.h
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index 2b8a5dd..f6d8541 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -27,6 +27,7 @@
  */
 #include drmP.h
 #include radeon.h
+#include radeon_asic.h
 #include atom.h
 #include r520d.h
 
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index c522901..a3a5a20 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -31,6 +31,7 @@
 #include drmP.h
 #include radeon_drm.h
 #include radeon.h
+#include radeon_asic.h
 #include radeon_mode.h
 #include r600d.h
 #include atom.h
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index 626d518..1240e7d 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -28,6 +28,7 @@
 #include linux/seq_file.h
 #include drm/drmP.h
 #include radeon.h
+#include radeon_asic.h
 #include rs400d.h
 
 /* This files gather functions specifics to : rs400,rs480 */
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index 47f046b..7c6de4b 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -37,6 +37,7 @@
  */
 #include drmP.h
 #include radeon.h
+#include radeon_asic.h
 #include atom.h
 #include rs600d.h
 
diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
index 83b9174..c39cb50 100644
--- a/drivers/gpu/drm/radeon/rs690.c
+++ b/drivers/gpu/drm/radeon/rs690.c
@@ -27,6 +27,7 @@
  */
 #include drmP.h
 #include radeon.h
+#include radeon_asic.h
 #include atom.h
 #include rs690d.h
 
diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
index bea747d..26108b4 100644
--- a/drivers/gpu/drm/radeon/rv515.c
+++ b/drivers/gpu/drm/radeon/rv515.c
@@ -29,6 +29,7 @@
 #include drmP.h
 #include rv515d.h
 #include radeon.h
+#include radeon_asic.h
 #include atom.h
 #include rv515_reg_safe.h
 
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 37887de..7dc9ad0 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -29,6 +29,7 @@
 #include linux/platform_device.h
 #include drmP.h
 #include radeon.h
+#include radeon_asic.h
 #include radeon_drm.h
 #include rv770d.h
 #include atom.h
-- 
1.7.0


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

[PATCH 3/5] drm/radeon: unconfuse return value of radeon_asic-clear_surface_reg

[Daniel Vetter]

No one cares about it, so set it to void.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon.h  |2 +-
 drivers/gpu/drm/radeon/radeon_asic.h |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 63cc609..c51ae43 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -782,7 +782,7 @@ struct radeon_asic {
int (*set_surface_reg)(struct radeon_device *rdev, int reg,
   uint32_t tiling_flags, uint32_t pitch,
   uint32_t offset, uint32_t obj_size);
-   int (*clear_surface_reg)(struct radeon_device *rdev, int reg);
+   void (*clear_surface_reg)(struct radeon_device *rdev, int reg);
void (*bandwidth_update)(struct radeon_device *rdev);
void (*hpd_init)(struct radeon_device *rdev);
void (*hpd_fini)(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 2bc2623..4c0d3da 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -73,7 +73,7 @@ int r100_copy_blit(struct radeon_device *rdev,
 int r100_set_surface_reg(struct radeon_device *rdev, int reg,
 uint32_t tiling_flags, uint32_t pitch,
 uint32_t offset, uint32_t obj_size);
-int r100_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r100_clear_surface_reg(struct radeon_device *rdev, int reg);
 void r100_bandwidth_update(struct radeon_device *rdev);
 void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
 int r100_ring_test(struct radeon_device *rdev);
@@ -212,7 +212,7 @@ int r600_gpu_reset(struct radeon_device *rdev);
 int r600_set_surface_reg(struct radeon_device *rdev, int reg,
 uint32_t tiling_flags, uint32_t pitch,
 uint32_t offset, uint32_t obj_size);
-int r600_clear_surface_reg(struct radeon_device *rdev, int reg);
+void r600_clear_surface_reg(struct radeon_device *rdev, int reg);
 void r600_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
 int r600_ring_test(struct radeon_device *rdev);
 int r600_copy_blit(struct radeon_device *rdev,
-- 
1.7.0


--
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: [PATCHES] radeon drm kms i2c fixes

[Jean Delvare]

Hi Alex,

On Wed, 10 Mar 2010 19:09:08 -0500, Alex Deucher wrote:
 Thanks to Jean for helping me with the i2c stuff.  I've attached
 Jean's bit algo patch as my radeon patch depends on it.  I'm not sure
 how we want to get that one upstream (either via drm or i2c).

i2c tree probably. I think I can push it to Linus quickly, it's a small
one, can't cause a regression, and rc2 isn't out yet.

 Previously, the radeon drm registered i2c buses using the radeon algo
 which would use either the hw i2c engine or bit banging depending on
 the bus in question (some are hw capable, others are not, some chips
 don't have support for their hw engines yet, etc.).  The tricky part
 was that the radeon i2c bit buses require some gpio magic before and
 after a transaction which bit algo didn't previously support.
 Unfortunately, it exposed the internal bit algo bus as well we as the
 radeon algo bus which is bad.  With these patches, if the hw engine is
 supported, we use the radeon algo, if not, we use bit algo directly
 with the pre/post_xfer functions to fix up the gpios.

Looks good. I have one suggestion of possible improvement for the
future. You could turn rec-hw_capable into a function pointer,
pointing to the appropriate r*_hw_i2c_xfer() function. This would be
more efficient that looking up the right function each time
radeon_hw_i2c_xfer() is called. This would also avoid checking the chip
model at registration time, to decide between hardware and software
implementation, as these tests could easily go out of sync with what
is actually implemented, when you add support for newer chips.

 I've tested on several radeons, but more tested would be nice.

I have the following in my machine:
02:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] 
(rev 01)
02:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] 
(Secondary) (rev 01)

Can I help with testing? I can follow your instructions.

-- 
Jean Delvare

--
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 0/5] clean up radeon_asic.h v2

[Daniel Vetter]

Hi all,

All new patch pile to make radeon_asic.h into a real header file. Now all
the asic structs are gathered in the new radeon_asic.c file.

Tested on my rv570.

I've also added a new patch that gathers all r100 specific declarations
into radeon_asic.h (at least where it makes sense). This is just an example
to convince Jerome that radeon_asic.h might not be totally useless ;)

Again, comments higly welcome.

Yours, Daniel

Daniel Vetter (5):
  drm/radeon: create radeon_asic.c
  drm/radeon: move asic structs to radeon_asic.c
  drm/radeon: unconfuse return value of radeon_asic-clear_surface_reg
  drm/radeon: include radeon_asic.h in the asic specific files
  drm/radeon: collect r100 asic related declarations in radeon_asic.h

 drivers/gpu/drm/radeon/Makefile|2 +-
 drivers/gpu/drm/radeon/evergreen.c |1 +
 drivers/gpu/drm/radeon/r100.c  |1 +
 drivers/gpu/drm/radeon/r200.c  |1 +
 drivers/gpu/drm/radeon/r300.c  |1 +
 drivers/gpu/drm/radeon/r420.c  |1 +
 drivers/gpu/drm/radeon/r520.c  |1 +
 drivers/gpu/drm/radeon/r600.c  |1 +
 drivers/gpu/drm/radeon/radeon.h|   55 +---
 drivers/gpu/drm/radeon/radeon_asic.c   |  723 
 drivers/gpu/drm/radeon/radeon_asic.h   |  545 +++--
 drivers/gpu/drm/radeon/radeon_device.c |  199 -
 drivers/gpu/drm/radeon/rs400.c |1 +
 drivers/gpu/drm/radeon/rs600.c |1 +
 drivers/gpu/drm/radeon/rs690.c |1 +
 drivers/gpu/drm/radeon/rv515.c |1 +
 drivers/gpu/drm/radeon/rv770.c |1 +
 17 files changed, 793 insertions(+), 743 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_asic.c


--
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 1/5] drm/radeon: create radeon_asic.c

[Daniel Vetter]

And move asic init plus a few related functions from radeon_device.c
to it. This file will hold all the asic structures in the future,
but atm they're still stuck in radeon_asic.h.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/Makefile|2 +-
 drivers/gpu/drm/radeon/radeon.h|6 +
 drivers/gpu/drm/radeon/radeon_asic.c   |  236 
 drivers/gpu/drm/radeon/radeon_device.c |  199 ---
 4 files changed, 243 insertions(+), 200 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_asic.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index ed38262..3c91312 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -50,7 +50,7 @@ $(obj)/r600_cs.o: $(obj)/r600_reg_safe.h
 radeon-y := radeon_drv.o radeon_cp.o radeon_state.o radeon_mem.o \
radeon_irq.o r300_cmdbuf.o r600_cp.o
 # add KMS driver
-radeon-y += radeon_device.o radeon_kms.o \
+radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_atombios.o radeon_agp.o atombios_crtc.o radeon_combios.o \
atom.o radeon_fence.o radeon_ttm.o radeon_object.o radeon_gart.o \
radeon_legacy_crtc.o radeon_legacy_encoders.o radeon_connectors.o \
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 829e26e..63cc609 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -862,6 +862,12 @@ union radeon_asic_config {
struct rv770_asic   rv770;
 };
 
+/*
+ * asic initizalization from radeon_asic.c
+ */
+void radeon_agp_disable(struct radeon_device *rdev);
+int radeon_asic_init(struct radeon_device *rdev);
+
 
 /*
  * IOCTL.
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
new file mode 100644
index 000..9dffaed
--- /dev/null
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -0,0 +1,236 @@
+/*
+ * 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
+ */
+
+#include linux/console.h
+#include drm/drmP.h
+#include drm/drm_crtc_helper.h
+#include drm/radeon_drm.h
+#include linux/vgaarb.h
+#include linux/vga_switcheroo.h
+#include radeon_reg.h
+#include radeon.h
+#include radeon_asic.h
+#include atom.h
+
+/*
+ * Registers accessors functions.
+ */
+static uint32_t radeon_invalid_rreg(struct radeon_device *rdev, uint32_t reg)
+{
+   DRM_ERROR(Invalid callback to read register 0x%04X\n, reg);
+   BUG_ON(1);
+   return 0;
+}
+
+static void radeon_invalid_wreg(struct radeon_device *rdev, uint32_t reg, 
uint32_t v)
+{
+   DRM_ERROR(Invalid callback to write register 0x%04X with 0x%08X\n,
+ reg, v);
+   BUG_ON(1);
+}
+
+static void radeon_register_accessor_init(struct radeon_device *rdev)
+{
+   rdev-mc_rreg = radeon_invalid_rreg;
+   rdev-mc_wreg = radeon_invalid_wreg;
+   rdev-pll_rreg = radeon_invalid_rreg;
+   rdev-pll_wreg = radeon_invalid_wreg;
+   rdev-pciep_rreg = radeon_invalid_rreg;
+   rdev-pciep_wreg = radeon_invalid_wreg;
+
+   /* Don't change order as we are overridding accessor. */
+   if (rdev-family  CHIP_RV515) {
+   rdev-pcie_reg_mask = 0xff;
+   } else {
+   rdev-pcie_reg_mask = 0x7ff;
+   }
+   /* FIXME: not sure here */
+   if (rdev-family = CHIP_R580) {
+   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;
+   }

[PATCH 5/5] drm/radeon: collect r100 asic related declarations in radeon_asic.h

[Daniel Vetter]

This just an example to show what radeon_asic.h might be good for.
Before Jerome kills it ;)

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon.h  |   47 --
 drivers/gpu/drm/radeon/radeon_asic.h |   52 +++--
 2 files changed, 48 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c51ae43..f5d0823 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -729,8 +729,6 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
 struct drm_info_list *files,
 unsigned nfiles);
 int radeon_debugfs_fence_init(struct radeon_device *rdev);
-int r100_debugfs_rbbm_init(struct radeon_device *rdev);
-int r100_debugfs_cp_init(struct radeon_device *rdev);
 
 
 /*
@@ -1194,51 +1192,6 @@ extern int radeon_resume_kms(struct drm_device *dev);
 extern int radeon_suspend_kms(struct drm_device *dev, pm_message_t state);
 
 /* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */
-struct r100_mc_save {
-   u32 GENMO_WT;
-   u32 CRTC_EXT_CNTL;
-   u32 CRTC_GEN_CNTL;
-   u32 CRTC2_GEN_CNTL;
-   u32 CUR_OFFSET;
-   u32 CUR2_OFFSET;
-};
-extern void r100_cp_disable(struct radeon_device *rdev);
-extern int r100_cp_init(struct radeon_device *rdev, unsigned ring_size);
-extern void r100_cp_fini(struct radeon_device *rdev);
-extern void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
-extern int r100_pci_gart_init(struct radeon_device *rdev);
-extern void r100_pci_gart_fini(struct radeon_device *rdev);
-extern int r100_pci_gart_enable(struct radeon_device *rdev);
-extern void r100_pci_gart_disable(struct radeon_device *rdev);
-extern int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t 
addr);
-extern int r100_debugfs_mc_info_init(struct radeon_device *rdev);
-extern int r100_gui_wait_for_idle(struct radeon_device *rdev);
-extern void r100_ib_fini(struct radeon_device *rdev);
-extern int r100_ib_init(struct radeon_device *rdev);
-extern void r100_irq_disable(struct radeon_device *rdev);
-extern int r100_irq_set(struct radeon_device *rdev);
-extern void r100_mc_stop(struct radeon_device *rdev, struct r100_mc_save 
*save);
-extern void r100_mc_resume(struct radeon_device *rdev, struct r100_mc_save 
*save);
-extern void r100_vram_init_sizes(struct radeon_device *rdev);
-extern void r100_wb_disable(struct radeon_device *rdev);
-extern void r100_wb_fini(struct radeon_device *rdev);
-extern int r100_wb_init(struct radeon_device *rdev);
-extern void r100_hdp_reset(struct radeon_device *rdev);
-extern int r100_rb2d_reset(struct radeon_device *rdev);
-extern int r100_cp_reset(struct radeon_device *rdev);
-extern void r100_vga_render_disable(struct radeon_device *rdev);
-extern int r100_cs_track_check_pkt3_indx_buffer(struct radeon_cs_parser *p,
-   struct radeon_cs_packet *pkt,
-   struct radeon_bo *robj);
-extern int r100_cs_parse_packet0(struct radeon_cs_parser *p,
-   struct radeon_cs_packet *pkt,
-   const unsigned *auth, unsigned n,
-   radeon_packet0_check_t check);
-extern int r100_cs_packet_parse(struct radeon_cs_parser *p,
-   struct radeon_cs_packet *pkt,
-   unsigned idx);
-extern void r100_enable_bm(struct radeon_device *rdev);
-extern void r100_set_common_regs(struct radeon_device *rdev);
 
 /* rv200,rv250,rv280 */
 extern void r200_set_safe_registers(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 4c0d3da..a0b8280 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -45,10 +45,18 @@ void radeon_atom_set_clock_gating(struct radeon_device 
*rdev, int enable);
 /*
  * r100,rv100,rs100,rv200,rs200
  */
-extern int r100_init(struct radeon_device *rdev);
-extern void r100_fini(struct radeon_device *rdev);
-extern int r100_suspend(struct radeon_device *rdev);
-extern int r100_resume(struct radeon_device *rdev);
+struct r100_mc_save {
+   u32 GENMO_WT;
+   u32 CRTC_EXT_CNTL;
+   u32 CRTC_GEN_CNTL;
+   u32 CRTC2_GEN_CNTL;
+   u32 CUR_OFFSET;
+   u32 CUR2_OFFSET;
+};
+int r100_init(struct radeon_device *rdev);
+void r100_fini(struct radeon_device *rdev);
+int r100_suspend(struct radeon_device *rdev);
+int r100_resume(struct radeon_device *rdev);
 uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg);
 void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v);
 void r100_vga_set_state(struct radeon_device *rdev, bool state);
@@ -82,6 +90,42 @@ void r100_hpd_fini(struct radeon_device *rdev);
 bool 

[PATCH 2/5] drm/radeon: move asic structs to radeon_asic.c

[Daniel Vetter]

With these static structs gone, radeon_asic.h is a real header file
and can be used as such.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/radeon/radeon_asic.c |  487 +
 drivers/gpu/drm/radeon/radeon_asic.h |  489 --
 2 files changed, 487 insertions(+), 489 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 9dffaed..6d2a545 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -128,6 +128,493 @@ void radeon_agp_disable(struct radeon_device *rdev)
 /*
  * ASIC
  */
+static struct radeon_asic r100_asic = {
+   .init = r100_init,
+   .fini = r100_fini,
+   .suspend = r100_suspend,
+   .resume = r100_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r100_gpu_reset,
+   .gart_tlb_flush = r100_pci_gart_tlb_flush,
+   .gart_set_page = r100_pci_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r100_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r100_fence_ring_emit,
+   .cs_parse = r100_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = NULL,
+   .copy = r100_copy_blit,
+   .get_engine_clock = radeon_legacy_get_engine_clock,
+   .set_engine_clock = radeon_legacy_set_engine_clock,
+   .get_memory_clock = radeon_legacy_get_memory_clock,
+   .set_memory_clock = NULL,
+   .get_pcie_lanes = NULL,
+   .set_pcie_lanes = NULL,
+   .set_clock_gating = radeon_legacy_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init = r100_hpd_init,
+   .hpd_fini = r100_hpd_fini,
+   .hpd_sense = r100_hpd_sense,
+   .hpd_set_polarity = r100_hpd_set_polarity,
+   .ioctl_wait_idle = NULL,
+};
+
+static struct radeon_asic r200_asic = {
+   .init = r100_init,
+   .fini = r100_fini,
+   .suspend = r100_suspend,
+   .resume = r100_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r100_gpu_reset,
+   .gart_tlb_flush = r100_pci_gart_tlb_flush,
+   .gart_set_page = r100_pci_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r100_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r100_fence_ring_emit,
+   .cs_parse = r100_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .get_engine_clock = radeon_legacy_get_engine_clock,
+   .set_engine_clock = radeon_legacy_set_engine_clock,
+   .get_memory_clock = radeon_legacy_get_memory_clock,
+   .set_memory_clock = NULL,
+   .set_pcie_lanes = NULL,
+   .set_clock_gating = radeon_legacy_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init = r100_hpd_init,
+   .hpd_fini = r100_hpd_fini,
+   .hpd_sense = r100_hpd_sense,
+   .hpd_set_polarity = r100_hpd_set_polarity,
+   .ioctl_wait_idle = NULL,
+};
+
+static struct radeon_asic r300_asic = {
+   .init = r300_init,
+   .fini = r300_fini,
+   .suspend = r300_suspend,
+   .resume = r300_resume,
+   .vga_set_state = r100_vga_set_state,
+   .gpu_reset = r300_gpu_reset,
+   .gart_tlb_flush = r100_pci_gart_tlb_flush,
+   .gart_set_page = r100_pci_gart_set_page,
+   .cp_commit = r100_cp_commit,
+   .ring_start = r300_ring_start,
+   .ring_test = r100_ring_test,
+   .ring_ib_execute = r100_ring_ib_execute,
+   .irq_set = r100_irq_set,
+   .irq_process = r100_irq_process,
+   .get_vblank_counter = r100_get_vblank_counter,
+   .fence_ring_emit = r300_fence_ring_emit,
+   .cs_parse = r300_cs_parse,
+   .copy_blit = r100_copy_blit,
+   .copy_dma = r200_copy_dma,
+   .copy = r100_copy_blit,
+   .get_engine_clock = radeon_legacy_get_engine_clock,
+   .set_engine_clock = radeon_legacy_set_engine_clock,
+   .get_memory_clock = radeon_legacy_get_memory_clock,
+   .set_memory_clock = NULL,
+   .get_pcie_lanes = rv370_get_pcie_lanes,
+   .set_pcie_lanes = rv370_set_pcie_lanes,
+   .set_clock_gating = radeon_legacy_set_clock_gating,
+   .set_surface_reg = r100_set_surface_reg,
+   .clear_surface_reg = r100_clear_surface_reg,
+   .bandwidth_update = r100_bandwidth_update,
+   .hpd_init 

[patch 2/3] vmwgfx: depends on FB

[akpm]

From: Randy Dunlap randy.dun...@oracle.com

vmwfgx uses framebuffer interfaces, so it should depend on FB.
Otherwise it has these build errors (e.g., when CONFIG_FB=m):

drivers/built-in.o: In function `vmw_fb_close':
(.text+0x97713): undefined reference to `unregister_framebuffer'
drivers/built-in.o: In function `vmw_fb_close':
(.text+0x97754): undefined reference to `framebuffer_release'
drivers/built-in.o: In function `vmw_fb_init':
(.text+0x97e1c): undefined reference to `framebuffer_alloc'
drivers/built-in.o: In function `vmw_fb_init':
(.text+0x9838d): undefined reference to `register_framebuffer'
drivers/built-in.o: In function `vmw_fb_init':
(.text+0x9842a): undefined reference to `framebuffer_release'

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Cc: David Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/gpu/drm/vmwgfx/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/gpu/drm/vmwgfx/Kconfig~vmwgfx-depends-on-fb 
drivers/gpu/drm/vmwgfx/Kconfig
--- a/drivers/gpu/drm/vmwgfx/Kconfig~vmwgfx-depends-on-fb
+++ a/drivers/gpu/drm/vmwgfx/Kconfig
@@ -1,6 +1,6 @@
 config DRM_VMWGFX
tristate DRM driver for VMware Virtual GPU
-   depends on DRM  PCI
+   depends on DRM  PCI  FB
select FB_DEFERRED_IO
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
_

--
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/3] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m

[akpm]

From: Surbhi Palande surbhi.pala...@canonical.com

Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed when
it is open.  This leads to a no connectors reported error at startup. 
Blacklisting them, to always return a connected status for the default
lvds connector.

Addresses https://bugs.launchpad.net/bugs/515246

Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/gpu/drm/i915/intel_lvds.c |   14 ++
 1 file changed, 14 insertions(+)

diff -puN 
drivers/gpu/drm/i915/intel_lvds.c~drm-i915-blacklist-lid-status-sony-vgn-bx196vp-dell-inspiron-700m
 drivers/gpu/drm/i915/intel_lvds.c
--- 
a/drivers/gpu/drm/i915/intel_lvds.c~drm-i915-blacklist-lid-status-sony-vgn-bx196vp-dell-inspiron-700m
+++ a/drivers/gpu/drm/i915/intel_lvds.c
@@ -651,6 +651,20 @@ static const struct dmi_system_id bad_li
DMI_MATCH(DMI_BOARD_NAME, M5x0N),
},
},
+   {
+   .ident = Sony VGN-BX196VP,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+   DMI_MATCH(DMI_BOARD_NAME, VGN-BX196VP),
+   },
+   },
+   {
+   .ident = Dell Inspiron 700m,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, Dell Inc),
+   DMI_MATCH(DMI_BOARD_NAME, Inspiron 700m),
+   },
+   },
{ }
 };
 
_

--
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 1/3] drivers/gpu/drm/i915/intel_bios.c: fix continuation line formats

[akpm]

From: Joe Perches j...@perches.com

String constants that are continued on subsequent lines with \ will cause
spurious whitespace in the resulting output.

Signed-off-by: Joe Perches j...@perches.com
Cc: Dave Airlie airl...@linux.ie
Cc: Eric Anholt e...@anholt.net
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/gpu/drm/i915/intel_bios.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff -puN 
drivers/gpu/drm/i915/intel_bios.c~drivers-gpu-drm-i915-intel_biosc-fix-continuation-line-formats
 drivers/gpu/drm/i915/intel_bios.c
--- 
a/drivers/gpu/drm/i915/intel_bios.c~drivers-gpu-drm-i915-intel_biosc-fix-continuation-line-formats
+++ a/drivers/gpu/drm/i915/intel_bios.c
@@ -417,8 +417,7 @@ parse_edp(struct drm_i915_private *dev_p
edp = find_section(bdb, BDB_EDP);
if (!edp) {
if (SUPPORTS_EDP(dev_priv-dev)  dev_priv-edp_support) {
-   DRM_DEBUG_KMS(No eDP BDB found but eDP panel 
supported,\
-  assume 18bpp panel color depth.\n);
+   DRM_DEBUG_KMS(No eDP BDB found but eDP panel 
supported, assume 18bpp panel color depth.\n);
dev_priv-edp_bpp = 18;
}
return;
_

--
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 2/3] vmwgfx: depends on FB

[Jakob Bornecrantz]

On 11 mar 2010, at 22.01, a...@linux-foundation.org wrote:

From: Randy Dunlap randy.dun...@oracle.com

vmwfgx uses framebuffer interfaces, so it should depend on FB.
Otherwise it has these build errors (e.g., when CONFIG_FB=m):

drivers/built-in.o: In function `vmw_fb_close':
(.text+0x97713): undefined reference to `unregister_framebuffer'
drivers/built-in.o: In function `vmw_fb_close':
(.text+0x97754): undefined reference to `framebuffer_release'
drivers/built-in.o: In function `vmw_fb_init':
(.text+0x97e1c): undefined reference to `framebuffer_alloc'
drivers/built-in.o: In function `vmw_fb_init':
(.text+0x9838d): undefined reference to `register_framebuffer'
drivers/built-in.o: In function `vmw_fb_init':
(.text+0x9842a): undefined reference to `framebuffer_release'

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Cc: David Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org


Thanks and
Acked-by: Jakob Bornecrantz ja...@vmware.com

Cheers Jakob.


---

drivers/gpu/drm/vmwgfx/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/gpu/drm/vmwgfx/Kconfig~vmwgfx-depends-on-fb  
drivers/gpu/drm/vmwgfx/Kconfig

--- a/drivers/gpu/drm/vmwgfx/Kconfig~vmwgfx-depends-on-fb
+++ a/drivers/gpu/drm/vmwgfx/Kconfig
@@ -1,6 +1,6 @@
config DRM_VMWGFX
tristate DRM driver for VMware Virtual GPU
-   depends on DRM  PCI
+   depends on DRM  PCI  FB
select FB_DEFERRED_IO
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
_

--
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 3/3] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m

[Chris Wilson]

On Thu, 11 Mar 2010 14:01:40 -0800, a...@linux-foundation.org wrote:
 + {
 + .ident = Dell Inspiron 700m,
 + .matches = {
 + DMI_MATCH(DMI_SYS_VENDOR, Dell Inc),
 + DMI_MATCH(DMI_BOARD_NAME, Inspiron 700m),
 + },
 + },

The Inspiron 700m has a 855GME part, so is caught by (which is heading
upstream, if not already been pulled into Linus' tree):

commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Fri Feb 12 09:30:00 2010 -0800

drm/i915: give up on 8xx lid status

These old machines more often than not lie about their lid state.  So
don't use it to detect LVDS presence, but leave the event handler to
deal with lid open/close, when we might need to reset the mode.

Fixes kernel bug #15248

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@kernel.org
Signed-off-by: Eric Anholt e...@anholt.net

The Sony has a GMA 900, so does indeed need the quirk.
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre

--
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 23532] Qt apps using opengl graphicssystem break with KMS

[bugzilla-daemon]

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





--- Comment #7 from Michael Lothian m...@fireburn.co.uk  2010-03-11 14:37:25 
PST ---
I can't seem to find that git commit

Do you know if kwin's compositing should work with this? It doesn't appear to
atm


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

[Bug 27010] mesa git build failure regarding winsys

[bugzilla-daemon]

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


Nikolay Rysev mad.f...@gmail.com changed:

   What|Removed |Added

 CC||mad.f...@gmail.com




--- Comment #2 from Nikolay Rysev mad.f...@gmail.com  2010-03-11 16:35:25 PST 
---
I can also confirm this bug.

make[5]: Entering directory
`/home/madgnu/packages/src/mesa-build/src/gallium/winsys/drm/intel/egl'
gcc -c  -march=k8 -msse3 -O2 -pipe -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o
make[5]: *** Нет правила для сборки цели
`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', требуемой
для `egl_x11_i915.so'.  Останов.


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

[Bug 27031] New: Xpress 200M (rc410) hangs when going into hibernation or waking up from suspend

[bugzilla-daemon]

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

   Summary: Xpress 200M (rc410) hangs when going into hibernation or
waking up from suspend
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: acimmaru...@gmail.com


Created an attachment (id=33969)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33969)
DRM relevant kernel log

Hello,

I'm running Debian Squeeze. I pulled xserver-xorg-video-radeon version 6.12.191
and kernel 2.6.33 from the experimental repository. I activated KMS+DRI2 on my
hardware: ATI Radeon Xpress 200M IGP (5955) (RC410).

I did this in an attempt to make suspend/hibernate work (as they don't work
with version 6.12.4 in user modesetting).

I report that hibernate hangs before the laptop enters hibernation and the
screen goes blank but remains on, as a strange smoke-like glow appears.

Suspend doesn't work either. This time it manages to go into suspend mode, but
display never wakes up. Remains shut off. Only by pressing and holding the
power button can I reboot (in both cases: hibernate and suspend).

I checked the logs and found nothing relevant. There is, however, an error I
get from drm. I'm attaching the file so you can see it for yourselves.

Thanks for your hard work. The Radeon driver has indeed come a long way...it
only needs a little bit more polishing.

Andres Cimmarusti


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

[Bug 27031] Xpress 200M (rc410) hangs when going into hibernation or waking up from suspend

[bugzilla-daemon]

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





--- Comment #1 from Andres Cimmarusti acimmaru...@gmail.com  2010-03-11 
16:39:11 PST ---
Created an attachment (id=33970)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33970)
lspci --verbose (only VGA card in question)


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

[Bug 27031] Xpress 200M (rc410) hangs when going into hibernation or waking up from suspend

[bugzilla-daemon]

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





--- Comment #2 from Andres Cimmarusti acimmaru...@gmail.com  2010-03-11 
16:39:41 PST ---
Created an attachment (id=33971)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33971)
Xorg log


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

[Bug 27031] Xpress 200M (rc410) hangs when going into hibernation or waking up from suspend

[bugzilla-daemon]

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





--- Comment #3 from Andres Cimmarusti acimmaru...@gmail.com  2010-03-11 
16:40:43 PST ---
Created an attachment (id=33972)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33972)
my xorg.conf (mainly to enable page flipping and EXA)


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

[Bug 26430] [KMS] Hw i2c patch doesn't work fully on rv280

[bugzilla-daemon]

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





--- Comment #11 from Andrew Randrianasulu rand...@mail.ru  2010-03-11 
18:52:38 PST ---
(In reply to comment #10)
 Created an attachment (id=33961)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33961) [details]
 possible fix
 
 Does this patch help?
 

No, same errors in dmesg and wrong resolution in X afterward.


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

[Bug 26430] [KMS] Hw i2c patch doesn't work fully on rv280

[bugzilla-daemon]

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





--- Comment #12 from Andrew Randrianasulu rand...@mail.ru  2010-03-11 
18:54:04 PST ---
Created an attachment (id=33973)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=33973)
dmesg

Dmesg from  2.6.34-rc1 + i2c patches + possible fix


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

[Bug 26927] Blank LVDS Dell Studio 17

[bugzilla-daemon]

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


Damien Mir d...@mirabel-sil.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #6 from Damien Mir d...@mirabel-sil.com  2010-03-11 19:14:54 PST 
---
Somehow I cannot reproduce with 2.6.34rc1, or even with next + glisse/drm-next.

I am closing the bug report.


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