[Bug 49198] New: glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

 Bug #: 49198
   Summary: glxinfo SIGSEGV in pthread_detach under
radeon_drm_cs_destroy under dri2_destroy_context
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: Other
OS/Version: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: bugs.freedesktop at karlt.net


OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL version string: 2.1 Mesa 8.0.2
OpenGL shading language version string: 1.20

#0  0x76002e98 in pthread_detach () from /lib64/libpthread.so.0
#1  0x747f2324 in pipe_thread_destroy (thread=)
at ../../../../../src/gallium/auxiliary/os/os_thread.h:78
#2  radeon_drm_cs_destroy (rcs=0x77fd7010) at radeon_drm_cs.c:475
#3  0x747e07b0 in r600_context_fini (ctx=0x642dd8)
at r600_hw_context.c:780
#4  0x747c4932 in r600_destroy_context (context=0x642ac0)
at r600_pipe.c:197
#5  0x7489397b in st_destroy_context (st=0x7a8ae0)
at state_tracker/st_context.c:268
#6  0x747ee324 in dri_destroy_context (cPriv=)
at dri_context.c:174
#7  0x747c1abb in driDestroyContext (pcp=0x6177e0)
at ../common/dri_util.c:277
#8  0x77bbf01f in dri2_destroy_context (context=0x617640)
at dri2_glx.c:132
#9  0x77b99b89 in glx_display_free (priv=0x613a30) at glxext.c:228
#10 0x77b99c16 in __glXCloseDisplay (dpy=0x607010, 
codes=) at glxext.c:275
#11 0x774c7f9c in XCloseDisplay () from /usr/lib64/libX11.so.6
#12 0x00403590 in main ()

Gentoo build with
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--libdir=/usr/lib64 --disable-dependency-tracking --enable-dri --enable-glx
--enable-texture-float --disable-debug --enable-egl --enable-gbm
--disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm
--enable-shared-dricore --enable-shared-glapi
--with-dri-drivers=,swrast,radeon,r200 --with-gallium-drivers=,swrast,r600
--with-egl-platforms=x11,drm --enable-gallium-egl --disable-d3d1x
--disable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --disable-vdpau
--disable-xa --disable-xvmc

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

[PATCH] mgag200: initial g200se driver

[Ville Syrjälä]

On Thu, Apr 26, 2012 at 02:48:45PM +0100, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This is a driver for the G200 server engines chips,
> it doesn't driver any of the Matrix G series desktop cards.

BTW I have a pile of modesetting and card initialization code
written for all mga chips from 2064W up to G550, except these
G200 server variants.

It's mostly in userspace but I wrote some wrappers for kernel APIs,
so most of the code looks like kernel code (not drm/kms code though).

It was a night/weekend project for me at some point, and my plan was
to make a kms driver out of it, but I ran out of steam before I got
that far. I suppose I should try to get off my ass and do something
useful with that code.

-- 
Ville Syrj?l?
syrjala at sci.fi
http://www.sci.fi/~syrjala/

Bug reports on the psb-gfx driver

[Kristoffer Eriksson]

Alan Cox skrev 2012-04-18 23:21:
>> That frequency seems about the same as the one I'm experiences. All though
>> some times it's more often, but I can't say I've done anything special at
>> the same time.
>>
>> 3.3.2-1-ARCH
>> Intel(R) Atom(TM) CPU Z520 @ 1.33GHz
>>
>> Attachment: dmesg ouput
>>
> What X display server are you using (fbdev or other ?). Also I see a few
> writes to the brightness in the log - did you fiddle with the brightness
> by hand at all ?
Alan,

Without looking at the code I can say that those brightness commands are 
not related to this
issue since Ive been having them since the first working kernel version.
Havent had time to look at the code but Ive understod them to happen 
simply when you
press a key to return from backlight suspend. Something like the default 
brightness setting that gets invoked
after return from suspend.

H?var see
[ 7659.177126] gma500 :00:02.0: Backlight lvds set brightness 186a186a

while I see
[] gma500 :00:02.0: Backlight lvds set brightness 7a127a12



>
> Either way I suspect the only way to find this is to verify a
> configuration it occurs on, go back a kernel, verify it doesn't happen
> there and then build a kernel to the point in the git tree before the
> gma500 patches were changed (to check its not caused by something else
> such as an ACPI change), then try and find which one caused it.
Will do further fresh builds to see if I can reproduce the blanking 
issue and also
test out the patch.


> That will be tedious but unfortunately I've got no documentation or other
> good ways to chase this down.
>
> Alan
>

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #52 from Alexandre Demers  
2012-04-26 14:19:41 PDT ---
(In reply to comment #51)
> Does the Mesa patch series at
> http://lists.freedesktop.org/archives/mesa-dev/2012-April/021211.html help?
> 
> Beware that it's only lightly tested, and I'll be away now for a long weekend.
> If there's a problem with the patches, I'll look into it next week.

No, it doesn't. But it's not worst either.

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

[pull] drm-intel-fixes for 3.4

[Daniel Vetter]

On Thu, Apr 26, 2012 at 05:35:01PM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Nothing major here and imo can wait a bit if you don't have anything
> important in drm-fixes yet:
> - VGA load-detect fix. This bug seems to be as old as the load-detect code
>   (2.6.30), but needs stupid userspace (upowerd trying to detect
>   connectors on dpms-off outputs) to actually kill the machine. And
>   obviously a machine without VGA-hotplug, otherwise we don't do load
>   detect.
> - 2 interger overflow fixes for unpriviledged ioctls from Xi Wang.

A tested-by for a regression fix just arrived, so I've thrown that in, too:
- Fix SDVO regression for low-res (pixelclock < 100MHz) digital outputs,
  introduce in 2.6.36.

Cheers, Daniel

The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:

  Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 6651819b4b4fc3caa6964c5d825eb4bb996f3905:

  drm/i915: handle input/output sdvo timings separately in mode_set (2012-04-26 
18:56:26 +0200)


Daniel Vetter (2):
  drm/i915: fixup load-detect on enabled, but not active pipe
  drm/i915: handle input/output sdvo timings separately in mode_set

Xi Wang (2):
  drm/i915: fix integer overflow in i915_gem_execbuffer2()
  drm/i915: fix integer overflow in i915_gem_do_execbuffer()

 drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 ++-
 drivers/gpu/drm/i915/intel_crt.c   |   29 +---
 drivers/gpu/drm/i915/intel_sdvo.c  |   34 +++-
 3 files changed, 36 insertions(+), 35 deletions(-)
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: handle input/output sdvo timings separately in mode_set

[Daniel Vetter]

I've picked this up for -fixes, with Jesse's irc r-b added.
-Daniel

On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
> We seem to have a decent confusion between the output timings and the
> input timings of the sdvo encoder. If I understand the code correctly,
> we use the original mode unchanged for the output timings, safe for
> the lvds case. And we should use the adjusted mode for input timings.
> 
> Clarify the situation by adding an explicit output_dtd to the sdvo
> mode_set function and streamline the code-flow by moving the input and
> output mode setting in the sdvo encode together.
> 
> Furthermore testing showed that the sdvo input timing needs the
> unadjusted dotclock, the sdvo chip will automatically compute the
> required pixel multiplier to get a dotclock above 100 MHz.
> 
> Fix this up when converting a drm mode to an sdvo dtd.
> 
> This regression was introduced in
> 
> commit c74696b9c890074c1e1ee3d7496fc71eb3680ced
> Author: Pavel Roskin 
> Date:   Thu Sep 2 14:46:34 2010 -0400
> 
> i915: revert some checks added by commit 32aad86f
> 
> particularly the following hunk:
> 
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 093e914..62d22ae 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder 
> *encoder,
> 
>  /* We have tried to get input timing in mode_fixup, and filled into
> adjusted_mode */
> -if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
> -intel_sdvo_get_dtd_from_mode(_dtd, adjusted_mode);
> +intel_sdvo_get_dtd_from_mode(_dtd, adjusted_mode);
> +if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
>  input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
> -} else
> -intel_sdvo_get_dtd_from_mode(_dtd, mode);
> 
>  /* If it's a TV, we already set the output timing in mode_fixup.
>   * Otherwise, the output timing is equal to the input timing.
> 
> Due to questions raised in review, below a more elaborate analysis of
> the bug at hand:
> 
> Sdvo seems to have two timings, one is the output timing which will be
> sent over whatever is connected on the other side of the sdvo chip (panel,
> hdmi screen, tv), the other is the input timing which will be generated by
> the gmch pipe. It looks like sdvo is expected to scale between the two.
> 
> To make things slightly more complicated, we have a bunch of special
> cases:
> - For lvds panel we always use a fixed output timing, namely
>   intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
> - Sdvo has an interface to generate a preferred input timing for a given
>   output timing. This is the confusing thing that I've tried to clear up
>   with the follow-on patches.
> - A special requirement is that the input pixel clock needs to be between
>   100MHz and 200MHz (likely to keep it within the electromechanical design
>   range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
>   doubled/quadrupled.
> 
> The thing this patch tries to fix is that the pipe needs to be
> explicitly instructed to double/quadruple the pixels and needs the
> correspondingly higher pixel clock, whereas the sdvo adaptor seems to
> do that itself and needs the unadjusted pixel clock. For the sdvo
> encode side we already set the pixel mutliplier with a different
> command (0x21).
> 
> This patch tries to fix this mess by:
> - Keeping the output mode timing in the unadjusted plain mode, safe
>   for the lvds case.
> - Storing the input timing in the adjusted_mode with the adjusted
>   pixel clock. This way we don't need to frob around with the core
>   crtc mode set code.
> - Fixing up the pixelclock when constructing the sdvo dtd timing
>   struct. This is why the first hunk of the patch is an integral part
>   of the series.
> - Dropping the is_tv special case because input_dtd is equivalent to
>   adjusted_mode after these changes. Follow-up patches clear this up
>   further (by simply ripping out intel_sdvo->input_dtd because it's
>   not needed).
> 
> v2: Extend commit message with an in-depth bug analysis.
> 
> Reported-and-Tested-by: Bernard Blackham 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c |   34 ++
>  1 files changed, 18 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 6898145..ab47c1e 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -733,6 +733,7 @@ static void intel_sdvo_get_dtd_from_mode(struct 
> intel_sdvo_dtd *dtd,
>   uint16_t width, height;
>   uint16_t h_blank_len, h_sync_len, v_blank_len, v_sync_len;
>   uint16_t h_sync_offset, v_sync_offset;
> + int mode_clock;
>  
>   width = mode->crtc_hdisplay;
>   height = 

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #51 from Michel D?nzer  2012-04-26 11:50:28 
PDT ---
Does the Mesa patch series at
http://lists.freedesktop.org/archives/mesa-dev/2012-April/021211.html help?

Beware that it's only lightly tested, and I'll be away now for a long weekend.
If there's a problem with the patches, I'll look into it next week.

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

[PATCH] drm/i915: handle input/output sdvo timings separately in mode_set

[Daniel Vetter]

On Wed, Apr 11, 2012 at 12:37:24AM +0200, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
> > Reported-and-Tested-by: Bernard Blackham 
> 
> This tested-by is actually a lie, I've mixed up a few bug reports. Bug
> reporter is currently on vacation and will test this stuff in 2 weeks.

Ok, I've lucked out and the bug reporter just said that this does indeed
work. Now I just need someone to grill himself by reviewing this stuff ...
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH v2] drm/exynos: add G2D driver

[Joonyoung Shim]

The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
This G2D driver is exynos drm specific and supports only G2D(version
4.1) of later Exynos series from Exynos4X12 because supporting DMA.

The G2D is performed by two tasks simply.
1. Configures the rendering parameters, such as foreground color and
   coordinates data by setting the drawing context registers.
2. Start the rendering process by setting thre relevant command
   registers accordingly.

The G2D version 4.1 supports DMA mode as host interface. User can make
command list to reduce HOST(ARM) loads. The contents of The command list
is setted to relevant registers of G2D by DMA.

The command list is composed Header and command sets and Tail.
- Header: The number of command set(4Bytes)
- Command set: Register offset(4Bytes) + Register data(4Bytes)
- Tail: Pointer of base address of the other command list(4Bytes)

By Tail field, the G2D can process many command lists without halt at
one go.

The G2D has following the rendering pipeline.
--> Primitive Drawing --> Rotation --> Clipping --> Bilinear Sampling
--> Color Key --> ROP --> Mask Operation --> Alpha Blending -->
Dithering --> FrameBuffer

And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- window clipping
- rotation
- flip
- 4 operand raster operation(ROP4)
- masking operation
- alpha blending
- color key
- dithering
- etc

User should make the command list to data and registers needed by
operation to use. The Exynos G2D driver only manages the command lists
received from user. Some registers needs memory base address(physical
address) of image. User doesn't know its physical address, so fills the
gem handle of that memory than address to command sets, then G2D driver
converts it to memory base address.

We adds three ioctls and one event for Exynos G2D.

- ioctls
DRM_EXYNOS_G2D_GET_VER: get the G2D hardware version
DRM_EXYNOS_G2D_SET_CMDLIST: set the command list from user to driver
DRM_EXYNOS_G2D_EXEC: execute the command lists setted to driver

- event
DRM_EXYNOS_G2D_EVENT: event to give notification completion of the
  command list to user

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
The validation check codes are added to this patch v2 to prevent
security problem from patch v1.

v2 changelog:

Some code clean and added to check follows about cmdlist from user.

1. size of cmdlist
2. registers offset validation: the registers offset shouldn't get out
the range - 0x0104 ~ 0x0880 and it has to be multiple of 4. The cmd
can't have registers offset for base address and the cmd_gem can have
only registers offset for base address.

 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   29 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   13 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  932 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h |   36 ++
 include/drm/exynos_drm.h|   57 ++
 7 files changed, 1074 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 135b618..7f50967 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -33,3 +33,9 @@ config DRM_EXYNOS_VIDI
depends on DRM_EXYNOS
help
  Choose this option if you want to use Exynos VIDI for DRM.
+
+config DRM_EXYNOS_G2D
+   bool "Exynos DRM G2D"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 353e1b7..eb651ca 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -14,5 +14,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 21658fa..ebcdc9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -40,6 +40,7 @@
 #include "exynos_drm_plane.h"
 #include "exynos_drm_vidi.h"
 #include "exynos_drm_dmabuf.h"
+#include "exynos_drm_g2d.h"

 #define DRIVER_NAME"exynos"
 #define DRIVER_DESC"Samsung SoC DRM"
@@ -148,9 +149,16 @@ static int exynos_drm_unload(struct drm_device *dev)

 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
+   struct drm_exynos_file_private *file_priv;
+

[pull] drm-intel-fixes for 3.4

[Daniel Vetter]

Hi Dave,

Nothing major here and imo can wait a bit if you don't have anything
important in drm-fixes yet:
- VGA load-detect fix. This bug seems to be as old as the load-detect code
  (2.6.30), but needs stupid userspace (upowerd trying to detect
  connectors on dpms-off outputs) to actually kill the machine. And
  obviously a machine without VGA-hotplug, otherwise we don't do load
  detect.
- 2 interger overflow fixes for unpriviledged ioctls from Xi Wang.

Yours, Daniel

The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:

  Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 44afb3a04391a74309d16180d1e4f8386fdfa745:

  drm/i915: fix integer overflow in i915_gem_do_execbuffer() (2012-04-23 
22:32:15 +0200)


Daniel Vetter (1):
  drm/i915: fixup load-detect on enabled, but not active pipe

Xi Wang (2):
  drm/i915: fix integer overflow in i915_gem_execbuffer2()
  drm/i915: fix integer overflow in i915_gem_do_execbuffer()

 drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 +++-
 drivers/gpu/drm/i915/intel_crt.c   |   29 +++-
 2 files changed, 18 insertions(+), 19 deletions(-)
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Nouveau] [PATCH v2 4/4] drm/nouveau: gpu lockup recovery

[Ben Skeggs]

On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
> 
> GPU reset is done by doing suspend / resume cycle with few tweaks:
> - CPU-only bo eviction
> - ignoring vm flush / fence timeouts
> - shortening waits
Okay.  I've thought about this a bit for a couple of days and think I'll
be able to coherently share my thoughts on this issue now :)

Firstly, while I agree that we need to become more resilient to errors,
I don't think that following in the radeon/intel footsteps with
something (imo, hackish) like this is the right choice for us
necessarily.

The *vast* majority of "lockups" we have are as a result of us badly
mishandling exceptions reported to us by the GPU.  There are a couple of
exceptions, however, they're very rare..

A very common example is where people gain DMA_PUSHERs for whatever
reason, and things go haywire eventually.  To handle a DMA_PUSHER
sanely, generally you have to drop all pending commands for the channel
(set GET=PUT, etc) and continue on.  However, this leaves us with fences
and semaphores unsignalled etc, causing issues further up the stack with
perfectly good channels hanging on attempting to sync with the crashed
channel etc.

The next most common example I can think of is nv4x hardware, getting a
LIMIT_COLOR/ZETA exception from PGRAPH, and then a hang.  The solution
is simple, learn how to handle the exception, log it, and PGRAPH
survives.

I strongly believe that if we focused our efforts on dealing with what
the GPU reports to us a lot better, we'll find we really don't need such
"lockup recovery".

I am, however, considering pulling the vm flush timeout error
propagation and break-out-of-waits-on-signals that builds on it.  As we
really do need to become better at having killable processes if things
go wrong :)

Ben.

> 
> Signed-off-by: Marcin Slusarz 
> ---
>  drivers/gpu/drm/nouveau/Makefile   |2 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c   |2 +-
>  drivers/gpu/drm/nouveau/nouveau_channel.c  |5 +-
>  drivers/gpu/drm/nouveau/nouveau_drv.c  |   56 ++-
>  drivers/gpu/drm/nouveau/nouveau_drv.h  |   45 -
>  drivers/gpu/drm/nouveau/nouveau_fence.c|7 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c  |   14 +++-
>  drivers/gpu/drm/nouveau/nouveau_notifier.c |3 +
>  drivers/gpu/drm/nouveau/nouveau_object.c   |6 +
>  drivers/gpu/drm/nouveau/nouveau_reset.c|  148 
> 
>  drivers/gpu/drm/nouveau/nouveau_state.c|6 +
>  drivers/gpu/drm/nouveau/nv50_graph.c   |   11 +-
>  12 files changed, 290 insertions(+), 15 deletions(-)
>  create mode 100644 drivers/gpu/drm/nouveau/nouveau_reset.c
> 
> diff --git a/drivers/gpu/drm/nouveau/Makefile 
> b/drivers/gpu/drm/nouveau/Makefile
> index 03860f5..77d0c33 100644
> --- a/drivers/gpu/drm/nouveau/Makefile
> +++ b/drivers/gpu/drm/nouveau/Makefile
> @@ -9,7 +9,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o 
> nouveau_mem.o \
>   nouveau_bo.o nouveau_fence.o nouveau_gem.o nouveau_ttm.o \
>   nouveau_hw.o nouveau_calc.o nouveau_bios.o nouveau_i2c.o \
>   nouveau_display.o nouveau_connector.o nouveau_fbcon.o \
> - nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o \
> + nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o nouveau_reset.o \
>nouveau_pm.o nouveau_volt.o nouveau_perf.o nouveau_temp.o \
>nouveau_mm.o nouveau_vm.o nouveau_mxm.o nouveau_gpio.o \
>   nv04_timer.o \
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 5b0dc50..7de6cad 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -936,7 +936,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict, 
> bool intr,
>   }
>  
>   /* Software copy if the card isn't up and running yet. */
> - if (!dev_priv->channel) {
> + if (!dev_priv->channel || nouveau_gpu_reset_in_progress(dev_priv->dev)) 
> {
>   ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, 
> no_wait_gpu, new_mem);
>   goto out;
>   }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c 
> b/drivers/gpu/drm/nouveau/nouveau_channel.c
> index 846afb0..c0fa5a7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_channel.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
> @@ -420,7 +420,7 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void 
> *data,
>   init->fb_ctxdma_handle,
>   init->tt_ctxdma_handle);
>   if (ret)
> - return ret;
> + goto out;
>   init->channel  = chan->id;
>  
>   if (nouveau_vram_pushbuf == 0) {
> @@ -450,6 +450,9 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void 
> *data,
>   if (ret 

[PATCH] mgag200: initial g200se driver

[Matt Turner]

On Thu, Apr 26, 2012 at 9:48 AM, Dave Airlie  wrote:
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> new file mode 100644
> index 000..a74f946
> --- /dev/null
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -0,0 +1,1494 @@
> +/*
> + * Copyright 2000,2001 Sven Luther.

Here...

> + * Copyright 2010 Matt Turner.
> + * Copyright 2011 Red Hat 
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License version 2. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * Authors: Matthew Garrett
> + * ? ? ? ? ? ? ? ? ? ? Matt Turner
> + * ? ? ? ? ? ? ? ? ? ? Sven Luther
> + * ? ? ? ? ? ? ? ? ? ? Thomas Witzel
> + * ? ? ? ? ? ? ? ? ? ? Alan Hourihane

and here, the copyrights and authorship for Sven Luther, Thomas
Witzel, and Alan Hourihane can be dropped. When I wrote glint_crtc.c,
I copied PM3DAC_CalculateClock from xf86-video-glint. With no remnants
of this function left, none of the code was written by them.

[Bug 33309] [855GM] GPU freeze due to overlay hang

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33309

--- Comment #17 from Daniel Vetter  2012-04-26 07:50:38 PDT 
---
On Thu, Apr 26, 2012 at 16:48,   wrote:
>
> The good news is that 3.3.0 with this patch seems stable, and I am still
> testing 3.3.3 with this patch and will report back if I manage to hang the
> GPU (or not).

Please also check whether 3.3.0 without the patch still crashes,
otherwise we don't really know whether it's the patch that fixes
things.

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

[Bug 33309] [855GM] GPU freeze due to overlay hang

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33309

--- Comment #16 from stefan  2012-04-26 07:48:56 PDT 
---
(In reply to comment #15)
> > --- Comment #14 from stefan  2012-03-26 13:17:45 
> > PDT ---
> Just add
> #define MI_WRITE_NOPID_REG (1 << 22)
> somewhere.
> Yours, Daniel

Hi Daniel,

sorry for answering so late. I had a few hangs with 3.3.0 with this patch
until I realised that I had relaxed fencing enabled (which I enabled out
of curiosity at some point). Since then I went back to a plain config and
had a GPU hang with the vanilla 3.3.3, I can attach the error state output
if you think it can still be useful.

The good news is that 3.3.0 with this patch seems stable, and I am still
testing 3.3.3 with this patch and will report back if I manage to hang the
GPU (or not).

Cheers,
Stefan.

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

[PATCH] mgag200: initial g200se driver

[Dave Airlie]

From: Dave Airlie 

This is a driver for the G200 server engines chips,
it doesn't driver any of the Matrix G series desktop cards.

It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards.

Its based on previous work done my Matthew Garrett but remodelled
to follow the same style and flow as the AST server driver. It also
works along the same lines as the AST server driver wrt memory management.

There is no userspace driver planned, xf86-video-modesetting should be used.
It also appears these GPUs have no ARGB hw cursors.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/Kconfig|1 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/mgag200/Kconfig|8 +
 drivers/gpu/drm/mgag200/Makefile   |5 +
 drivers/gpu/drm/mgag200/mgag200_drv.c  |  115 +++
 drivers/gpu/drm/mgag200/mgag200_drv.h  |  274 ++
 drivers/gpu/drm/mgag200/mgag200_fb.c   |  293 +++
 drivers/gpu/drm/mgag200/mgag200_i2c.c  |  129 +++
 drivers/gpu/drm/mgag200/mgag200_main.c |  388 +
 drivers/gpu/drm/mgag200/mgag200_mode.c | 1494 
 drivers/gpu/drm/mgag200/mgag200_reg.h  |  659 ++
 drivers/gpu/drm/mgag200/mgag200_ttm.c  |  452 ++
 12 files changed, 3819 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/mgag200/Kconfig
 create mode 100644 drivers/gpu/drm/mgag200/Makefile
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_drv.c
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_drv.h
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_fb.c
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_i2c.c
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_main.c
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_mode.c
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_reg.h
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_ttm.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 514049f..47b1d3a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -167,3 +167,4 @@ source "drivers/gpu/drm/gma500/Kconfig"

 source "drivers/gpu/drm/ast/Kconfig"

+source "drivers/gpu/drm/mgag200/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index bd76195..0d91e1a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_DRM_RADEON)+= radeon/
 obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915)  += i915/
+obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
new file mode 100644
index 000..9bc979f
--- /dev/null
+++ b/drivers/gpu/drm/mgag200/Kconfig
@@ -0,0 +1,8 @@
+config DRM_MGAG200
+   tristate "Kernel modesetting driver for MGA G200 server engines"
+   depends on DRM && PCI
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   select DRM_KMS_HELPER
+
diff --git a/drivers/gpu/drm/mgag200/Makefile b/drivers/gpu/drm/mgag200/Makefile
new file mode 100644
index 000..7db592e
--- /dev/null
+++ b/drivers/gpu/drm/mgag200/Makefile
@@ -0,0 +1,5 @@
+ccflags-y := -Iinclude/drm
+mgag200-y   := mgag200_main.o mgag200_mode.o \
+   mgag200_drv.o mgag200_fb.o mgag200_i2c.o mgag200_ttm.o
+
+obj-$(CONFIG_DRM_MGAG200) += mgag200.o
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
new file mode 100644
index 000..cf5cea2
--- /dev/null
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright 2010 Matt Turner.
+ * Copyright 2011 Red Hat 
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Authors: Matthew Garrett
+ * Matt Turner
+ */
+#include 
+#include 
+#include "drmP.h"
+#include "drm.h"
+
+#include "mgag200_drv.h"
+
+#include "drm_pciids.h"
+
+/*
+ * This is the generic driver code. This binds the driver to the drm core,
+ * which then performs further device association and calls our graphics init
+ * functions
+ */
+int mgag200_modeset = -1;
+
+MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
+module_param_named(modeset, mgag200_modeset, int, 0400);
+
+static struct drm_driver driver;
+
+static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
+   { PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A 
},
+   { PCI_VENDOR_ID_MATROX, 0x524, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_B 
},
+   { PCI_VENDOR_ID_MATROX, 0x530, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EV },
+   { PCI_VENDOR_ID_MATROX, 0x532, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_WB },
+   { PCI_VENDOR_ID_MATROX, 0x533, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EH },
+   { PCI_VENDOR_ID_MATROX, 0x534, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_ER },
+   

[Bug 49110] AMDILCFGStructurizer.cpp:1751:3: error: 'isCurrentDebugType' was not declared in this scope

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49110

--- Comment #2 from Fabio Pedretti  2012-04-26 06:14:49 
PDT ---
OK, I disabled mesa debug but now I get this (current git):

make[5]: *** No rule to make target
`../../../../../../src/gallium/drivers/radeon/libradeon.a', needed by
`libr600.a'.  Stop.

Full log at:
https://launchpadlibrarian.net/103127393/buildlog_ubuntu-precise-i386.mesa_8.1~git1204261417.a2f7ec~gd~p_FAILEDTOBUILD.txt.gz

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

[Bug 15851] Switcheroo: Intel card not working after passing OFF to discrete card

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=15851


Chris Wilson  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||chris at chris-wilson.co.uk
  Component|Video(DRI - Intel)  |Video(DRI - non Intel)
 AssignedTo|airlied at linux.ie|drivers_video-dri at 
kernel-bu
   ||gs.osdl.org




--- Comment #5 from Chris Wilson   2012-04-26 
12:15:28 ---
Can you verify that oops on a recent kernel?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[Christian König]

Hi Jerome,

I totally agree that we can remove the following debugfs files, since 
everything that just prints out or modifies register informations 
doesn't belongs into the kernel driver and should be moved to radeontool 
instead.
> static int r100_debugfs_rbbm_info(struct seq_file *m, void *data)
> static int r100_debugfs_cp_ring_info(struct seq_file *m, void *data)
> static int r100_debugfs_cp_csq_fifo(struct seq_file *m, void *data)
> static int r100_debugfs_mc_info(struct seq_file *m, void *data)
> static int rv370_debugfs_pcie_gart_info(struct seq_file *m, void *data)
> static int r420_debugfs_pipes_info(struct seq_file *m, void *data)
> static int r600_debugfs_mc_info(struct seq_file *m, void *data)
> static int rs400_debugfs_gart_info(struct seq_file *m, void *data)
> static int rv515_debugfs_pipes_info(struct seq_file *m, void *data)
> static int rv515_debugfs_ga_info(struct seq_file *m, void *data)

But I disagree that we should remove the following two, cause they print 
out driver internal data structures and it isn't easy to gain access to 
those, at least without a debugger and allot of patience.
> static int radeon_debugfs_fence_info(struct seq_file *m, void *data)
> static int radeon_debugfs_sa_info(struct seq_file *m, void *data)

Also I think I should mention that your patch doesn't touches the 
following two debugfs files, probably because of the same reason as the 
two above.
> static int radeon_mm_dump_table(struct seq_file *m, void *data)
> static int radeon_debugfs_pm_info(struct seq_file *m, void *data)

I also think that we should keep the ring debugfs file but of course not 
with the IB dumping facility, since otherwise we pretty much lose any 
possibility to look into multi ring lockups, which is something I 
currently spend most of my time on.
> static int radeon_debugfs_ring_info(struct seq_file *m, void *data)

Additionally I have some comments on the dumping patch itself, but going 
to write that in a separate mail.

Cheers,
Christian.

[PATCH] mgag200: initial g200se driver

[Adam Jackson]

On Thu, 2012-04-26 at 14:48 +0100, Dave Airlie wrote:

> +/*
> + * Our emulated hardware has two sets of memory. One is video RAM and can
> + * simply be used as a linear framebuffer - the other provides mmio access
> + * to the display registers. The latter can also be accessed via IO port
> + * access, but we map the range and use mmio to program them instead
> + */

I suspect this comment came from somewhere near the emulated cirrus card
in qemu?  G200's definitely not emulated hardware.

> +/*
> + * The meat of this driver. The core passes us a mode and we have to program
> + * it. The modesetting here is the bare minimum required to satisfy the qemu
> + * emulation of this hardware, and running this against a real device is
> + * likely to result in an inadequately programmed mode. We've already had
> + * the opportunity to modify the mode, so whatever we receive here should
> + * be something that can be correctly programmed and displayed
> + */

Yep, drm/cirrus all over the place here.

> +/*
> + * This is called after a mode is programmed. It should reverse anything done
> + * by the prepare function
> + */
> +static void mga_crtc_commit(struct drm_crtc *crtc)
> +{

This appears to be missing the analog of the "Reset tagfifo" commit from
the X driver for G200ER:

http://cgit.freedesktop.org/xorg/driver/xf86-video-mga/commit/?id=01ca2186ea028b2549de509b51726aa08519fce0

Which, admittedly, is in an odd place in the X driver.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120426/3e08797f/attachment.pgp>

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

--- Comment #3 from Vadim  2012-04-26 03:43:45 PDT ---
(In reply to comment #2)
> Any suggestions on how to accomplish that? I tried turning my code around and
> around, but so far with no success. What should help with the register count?
> 
> On the other hand, why is the register limit set so low? I just tested the
> program with Mesa 7.11, same hardware and r600 drivers - it works. This seems
> like a regression.
> If needed, there are binaries/source available for testing at
> http://thelarge.org

It's a hardware limit. The compiler in theory should optimize register
allocation, but the problem is that r600g still lacks real register allocator.
And probably some changes since 7.11 increased register usage in the TGSI IR.

I'll see if I can help with that shader somehow, but generally r600g needs a
better shader compiler. There is some work in progress on that, but I don't
know when it will be completed.

Also there is some experimental code that probably could help with that, but
currently it works only with evergreen GPUs. If you could use a gpu of the
evergreen class (IIRC it's all of 5xxx, some of 6xxx cards), then you might
want to try r600_shader_opt and r600_shader_opt_2 branches from the following
repo: https://github.com/VadimGirlin/mesa

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

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[Alex Deucher]

On Thu, Apr 26, 2012 at 9:36 AM, Jerome Glisse  wrote:
> 2012/4/26 David Airlie :
>>
>>
>> - Original Message -
>>> From: "Christian K?nig" 
>>> To: "j glisse" 
>>> Cc: "Jerome Glisse" , dri-devel at 
>>> lists.freedesktop.org
>>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>>> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>>>
>>> Hi Jerome,
>>>
>>> I totally agree that we can remove the following debugfs files, since
>>> everything that just prints out or modifies register informations
>>> doesn't belongs into the kernel driver and should be moved to
>>> radeontool
>>> instead.
>>
>> In the future with secure boot we will need a better mechanism to diagnose 
>> things
>> than a userspace tool mapping pci bars, which we can't allow to happen in a 
>> secure
>> boot environment, so dropping all the files might not be a good idea unless 
>> we
>> provide a mechanism for radeontool to use. We can't allow userspace to 
>> read/write
>> arbitrary registers and stay secure.
>>
>> Dave.
>
> Well those files are useless, each time i debug a lockup and try to
> use them i loose
> time on them as they never helped me so far and i seriously doubt they
> would help
> me in the future or anyone else.
>
> For secure boot my guess is that radeontool will become obsolete and
> by that time
> we might need to add some reg dumping. But none of the current files
> seems usefull
> to me.

We can always expose the mmio bar (and vbios for that matter) via
ioctl or sysfs for radeontool.  We should try and write a better
unified tool suite.

Alex

>
> The fence and sa files might make sense to debug the associated code
> as it's nice
> to be able to dump associated kernel struct.
>
> Cheers,
> Jerome
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[Jerome Glisse]

2012/4/26 David Airlie :
>
>
> - Original Message -
>> From: "Christian K?nig" 
>> To: "j glisse" 
>> Cc: "Jerome Glisse" , dri-devel at 
>> lists.freedesktop.org
>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>>
>> Hi Jerome,
>>
>> I totally agree that we can remove the following debugfs files, since
>> everything that just prints out or modifies register informations
>> doesn't belongs into the kernel driver and should be moved to
>> radeontool
>> instead.
>
> In the future with secure boot we will need a better mechanism to diagnose 
> things
> than a userspace tool mapping pci bars, which we can't allow to happen in a 
> secure
> boot environment, so dropping all the files might not be a good idea unless we
> provide a mechanism for radeontool to use. We can't allow userspace to 
> read/write
> arbitrary registers and stay secure.
>
> Dave.

Well those files are useless, each time i debug a lockup and try to
use them i loose
time on them as they never helped me so far and i seriously doubt they
would help
me in the future or anyone else.

For secure boot my guess is that radeontool will become obsolete and
by that time
we might need to add some reg dumping. But none of the current files
seems usefull
to me.

The fence and sa files might make sense to debug the associated code
as it's nice
to be able to dump associated kernel struct.

Cheers,
Jerome

RV670: wine: Diablo III Beta: GPU Lockup and slow framerate(9FPS avg.) 400MB compressed trace available.

[Mike Mestnik]

My system specs are here http://pastebin.com/35NwE0G1
dmsg http://pastebin.com/CDhuT4bU
http://c566453.r53.cf2.rackcdn.com/DIIILoackupLowFPS.trace.xz

This trace shows unbearable slowness and a GPU lockup at a specific map
location, "*GPU lockup CP detected."
*http://appdb.winehq.org/objectManager.php?sClass=version=25588

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

--- Comment #2 from Marko  2012-04-26 00:27:46 PDT ---
Any suggestions on how to accomplish that? I tried turning my code around and
around, but so far with no success. What should help with the register count?

On the other hand, why is the register limit set so low? I just tested the
program with Mesa 7.11, same hardware and r600 drivers - it works. This seems
like a regression.

If needed, there are binaries/source available for testing at
http://thelarge.org

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

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[David Airlie]

- Original Message -
> From: "Christian K?nig" 
> To: "j glisse" 
> Cc: "Jerome Glisse" , dri-devel at 
> lists.freedesktop.org
> Sent: Thursday, 26 April, 2012 10:11:12 AM
> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
> 
> Hi Jerome,
> 
> I totally agree that we can remove the following debugfs files, since
> everything that just prints out or modifies register informations
> doesn't belongs into the kernel driver and should be moved to
> radeontool
> instead.

In the future with secure boot we will need a better mechanism to diagnose 
things
than a userspace tool mapping pci bars, which we can't allow to happen in a 
secure
boot environment, so dropping all the files might not be a good idea unless we
provide a mechanism for radeontool to use. We can't allow userspace to 
read/write
arbitrary registers and stay secure.

Dave.

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41668

--- Comment #27 from dmotd  2012-04-25 
19:44:29 PDT ---
apologies for the many months without reply - i have not been in a position to
contribute after making the initial bug report.

i recently performed a system update and am currently running kernel 3.3.1 on
archlinux, i can confirm that this bug is still present, and i am still getting
occasional graphics freezes of the same nature to before. once again i can get
openbox to replace the affected x session, so basic rendering is still okay.

i did get an opportunity to test pci=nomsi for a while and noticed that while
there were no freezes of this nature, the 3d graphics rendering would sometimes
receive a slight unexplained performance hit (visual lag) that would remain for
the rest of the session, a minor effect but not debilitating to general use.

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

[PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Michael,

> On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:
>> On 03/11/2012 02:44 PM, Alan Cox wrote:
 This patch allows to load an EDID data set via the firmware interface.
 It contains data sets of frequently used screen resolutions (1024x768,
 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
 specified as a module parameter of the drm_kms_helper module, e.g.
 options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
 command line parameter.
>>> What if the DRM layer and driver are compiled in. They'll come up as
>>> console before the file system so the firmware request will hang ?
>> Admittedly I did not try to compile the DRM layer and driver into the
>> kernel. However, I created an error condition by specifying a
>> non-existing EDID file. In this case, the function returns with error,
>> the mode count remains 0, and the system continues to run as if the
>> edid_firmware= parameter had not been specified.
> Unfortunately, as of at least last month, my system hangs when I try to
> use your feature (just as described by Alan Cox); the log shows that
> during the boot process, there is a one-minute hang:
>
>[0.175207] [drm] radeon: power management initialized
>[   60.896507] [drm:edid_load] *ERROR* Requesting EDID firmware 
> "edid/1920x1200.bin" failed (err=-2)
>
> Is there any way to make your feature smarter about its timing with
> relation to file system accessibility?
Sure.

Please copy your EDID data file to the directory "firmware/edid" of the 
kernel source tree, configure

CONFIG_EXTRA_FIRMWARE="edid/1920x1200.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"

and rebuild/reboot your kernel.

Does it work then?

-Carsten.

[PATCH 24/24] drm/radeon: add faulty command buffer dump facilities

[Luca Tettamanti]

Hi Jerome,

On Wed, Apr 25, 2012 at 9:03 PM,   wrote:
> From: Jerome Glisse 
>
> This add a command buffer dumping facilities, that will
> dump command buffer and all associated bo that most likely
> triggered a lockup.
[cut]

I spotted this:

> +void radeon_fence_blob_faulty_ib(struct radeon_device *rdev, int ring)
> +{
> + ? ? ? struct radeon_fence *fence;
> + ? ? ? struct list_head *i;
> + ? ? ? unsigned long irq_flags;
> + ? ? ? uint32_t seq;
> +
> + ? ? ? write_lock_irqsave(>fence_lock, irq_flags);
> + ? ? ? seq = radeon_fence_read(rdev, ring);
> + ? ? ? list_for_each(i, >fence_drv[ring].emitted) {
> + ? ? ? ? ? ? ? fence = list_entry(i, struct radeon_fence, list);
> + ? ? ? ? ? ? ? if (fence->seq != seq && fence->ib) {
> + ? ? ? ? ? ? ? ? ? ? ? radeon_lockup_build_blob(rdev, fence->ib);

radeon_lockup_build_blob() will take a mutex and call vmalloc() inside
an atomic context.

Luca

[PATCH v2 4/4] drm/nouveau: gpu lockup recovery

[Marcin Slusarz]

On Wed, Apr 25, 2012 at 11:20:36PM +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
> 
> GPU reset is done by doing suspend / resume cycle with few tweaks:
> - CPU-only bo eviction
> - ignoring vm flush / fence timeouts
> - shortening waits
> 
> Signed-off-by: Marcin Slusarz 
> ---

What changed from v1:
- moved ioctl locking from drm core to nouveau
- made down_reads interruptible
- fixed build bug on 32-bit systems

[PATCH v2 4/4] drm/nouveau: gpu lockup recovery

[Marcin Slusarz]

Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.

GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
- ignoring vm flush / fence timeouts
- shortening waits

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/Makefile   |2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_channel.c  |5 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c  |   56 ++-
 drivers/gpu/drm/nouveau/nouveau_drv.h  |   45 -
 drivers/gpu/drm/nouveau/nouveau_fence.c|7 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c  |   14 +++-
 drivers/gpu/drm/nouveau/nouveau_notifier.c |3 +
 drivers/gpu/drm/nouveau/nouveau_object.c   |6 +
 drivers/gpu/drm/nouveau/nouveau_reset.c|  148 
 drivers/gpu/drm/nouveau/nouveau_state.c|6 +
 drivers/gpu/drm/nouveau/nv50_graph.c   |   11 +-
 12 files changed, 290 insertions(+), 15 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_reset.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 03860f5..77d0c33 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -9,7 +9,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o 
nouveau_mem.o \
  nouveau_bo.o nouveau_fence.o nouveau_gem.o nouveau_ttm.o \
  nouveau_hw.o nouveau_calc.o nouveau_bios.o nouveau_i2c.o \
  nouveau_display.o nouveau_connector.o nouveau_fbcon.o \
- nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o \
+ nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o nouveau_reset.o \
 nouveau_pm.o nouveau_volt.o nouveau_perf.o nouveau_temp.o \
 nouveau_mm.o nouveau_vm.o nouveau_mxm.o nouveau_gpio.o \
  nv04_timer.o \
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5b0dc50..7de6cad 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -936,7 +936,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict, 
bool intr,
}

/* Software copy if the card isn't up and running yet. */
-   if (!dev_priv->channel) {
+   if (!dev_priv->channel || nouveau_gpu_reset_in_progress(dev_priv->dev)) 
{
ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, 
no_wait_gpu, new_mem);
goto out;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c 
b/drivers/gpu/drm/nouveau/nouveau_channel.c
index 846afb0..c0fa5a7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_channel.c
+++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
@@ -420,7 +420,7 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
init->fb_ctxdma_handle,
init->tt_ctxdma_handle);
if (ret)
-   return ret;
+   goto out;
init->channel  = chan->id;

if (nouveau_vram_pushbuf == 0) {
@@ -450,6 +450,9 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
if (ret == 0)
atomic_inc(>users); /* userspace reference */
nouveau_channel_put();
+out:
+   if (ret == -EIO)
+   ret = nouveau_reset_device(dev);
return ret;
 }

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 090fff6..261e1f5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -237,7 +237,7 @@ nouveau_pci_suspend(struct pci_dev *pdev, pm_message_t 
pm_state)
if (!dev_priv->eng[e])
continue;

-   ret = dev_priv->eng[e]->fini(dev, e, true);
+   ret = dev_priv->eng[e]->fini(dev, e, 
!nouveau_gpu_reset_in_progress(dev));
if (ret) {
NV_ERROR(dev, "... engine %d failed: %d\n", e, ret);
goto out_abort;
@@ -443,11 +443,63 @@ nouveau_pci_resume(struct pci_dev *pdev)
return 0;
 }

+void intr_rwsem_init(struct intr_rwsem *r)
+{
+   init_rwsem(>rwsem);
+   mutex_init(>mutex);
+}
+
+int intr_rwsem_down_read_interruptible(struct intr_rwsem *r)
+{
+   while (down_read_trylock(>rwsem) == 0) {
+   int ret = mutex_lock_interruptible(>mutex);
+   if (ret)
+   return ret;
+   mutex_unlock(>mutex);
+   }
+   return 0;
+}
+
+void intr_rwsem_up_read(struct intr_rwsem *r)
+{
+   up_read(>rwsem);
+}
+
+void intr_rwsem_down_write(struct intr_rwsem *r)
+{
+   mutex_lock(>mutex);
+   down_write(>rwsem);
+}
+
+void intr_rwsem_up_write(struct intr_rwsem *r)
+{
+   up_write(>rwsem);
+   mutex_unlock(>mutex);
+}
+
+static long nouveau_ioctl(struct file *filp,
+ unsigned int cmd, 

[PATCH v2 3/4] drm/nv50: let applications hanging on vm flush to be killed

[Marcin Slusarz]

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nv50_graph.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c 
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
+++ b/drivers/gpu/drm/nouveau/nv50_graph.c
@@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int engine)
if ((tmp & 7) == 1)
idle = false;
}
+
+   if (fatal_signal_pending(current)) {
+   ret = -ERESTARTSYS;
+   break;
+   }
} while (!idle && !(timeout = ptimer->read(dev) - start > 20));

if (timeout) {
-- 
1.7.8.5

[PATCH v2 2/4] drm/nouveau: propagate errors from vm flushes

[Marcin Slusarz]

We need this for lockup recovery.

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  |9 +++--
 drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
 drivers/gpu/drm/nouveau/nouveau_vm.c  |   20 ++--
 drivers/gpu/drm/nouveau/nouveau_vm.h  |   18 +-
 drivers/gpu/drm/nouveau/nv50_fifo.c   |4 ++--
 drivers/gpu/drm/nouveau/nv50_graph.c  |   12 
 drivers/gpu/drm/nouveau/nv50_mpeg.c   |4 ++--
 drivers/gpu/drm/nouveau/nv50_vm.c |   30 --
 drivers/gpu/drm/nouveau/nv84_crypt.c  |4 ++--
 drivers/gpu/drm/nouveau/nva3_copy.c   |4 ++--
 drivers/gpu/drm/nouveau/nvc0_vm.c |3 ++-
 11 files changed, 67 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 638ae32..5b0dc50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1230,10 +1230,15 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
nouveau_vm *vm,
return ret;

if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
-   nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
+   ret = nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
else
if (nvbo->bo.mem.mem_type == TTM_PL_TT)
-   nouveau_vm_map_sg(vma, 0, size, node);
+   ret = nouveau_vm_map_sg(vma, 0, size, node);
+
+   if (ret) {
+   nouveau_vm_put(vma);
+   return ret;
+   }

list_add_tail(>head, >vma_list);
vma->refcount = 1;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 2f8e80a..d120baf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -320,7 +320,7 @@ struct nouveau_exec_engine {
int  (*object_new)(struct nouveau_channel *, int engine,
   u32 handle, u16 class);
void (*set_tile_region)(struct drm_device *dev, int i);
-   void (*tlb_flush)(struct drm_device *, int engine);
+   int (*tlb_flush)(struct drm_device *, int engine);
 };

 struct nouveau_instmem_engine {
@@ -387,7 +387,7 @@ struct nouveau_fifo_engine {
void (*destroy_context)(struct nouveau_channel *);
int  (*load_context)(struct nouveau_channel *);
int  (*unload_context)(struct drm_device *);
-   void (*tlb_flush)(struct drm_device *dev);
+   int  (*tlb_flush)(struct drm_device *dev);
 };

 struct nouveau_display_engine {
@@ -1246,7 +1246,7 @@ extern int  nv50_fifo_create_context(struct 
nouveau_channel *);
 extern void nv50_fifo_destroy_context(struct nouveau_channel *);
 extern int  nv50_fifo_load_context(struct nouveau_channel *);
 extern int  nv50_fifo_unload_context(struct drm_device *);
-extern void nv50_fifo_tlb_flush(struct drm_device *dev);
+extern int  nv50_fifo_tlb_flush(struct drm_device *dev);

 /* nvc0_fifo.c */
 extern int  nvc0_fifo_init(struct drm_device *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.c 
b/drivers/gpu/drm/nouveau/nouveau_vm.c
index 2bf6c03..e2d4853 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.c
@@ -27,7 +27,7 @@
 #include "nouveau_mm.h"
 #include "nouveau_vm.h"

-void
+int
 nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
 {
struct nouveau_vm *vm = vma->vm;
@@ -67,16 +67,16 @@ nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, 
struct nouveau_mem *node)
}
}

-   vm->flush(vm);
+   return vm->flush(vm);
 }

-void
+int
 nouveau_vm_map(struct nouveau_vma *vma, struct nouveau_mem *node)
 {
-   nouveau_vm_map_at(vma, 0, node);
+   return nouveau_vm_map_at(vma, 0, node);
 }

-void
+int
 nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 length,
  struct nouveau_mem *mem)
 {
@@ -110,10 +110,10 @@ nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 
length,
}
}

-   vm->flush(vm);
+   return vm->flush(vm);
 }

-void
+int
 nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta, u64 length)
 {
struct nouveau_vm *vm = vma->vm;
@@ -144,13 +144,13 @@ nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta, 
u64 length)
}
}

-   vm->flush(vm);
+   return vm->flush(vm);
 }

-void
+int
 nouveau_vm_unmap(struct nouveau_vma *vma)
 {
-   nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
+   return nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
 }

 static void
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.h 
b/drivers/gpu/drm/nouveau/nouveau_vm.h
index 4fb6e72..59dc206 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.h
@@ -73,7 +73,7 @@ struct nouveau_vm {
void (*map_sg)(struct nouveau_vma *, struct nouveau_gpuobj *,
   struct nouveau_mem *, u32 pte, u32 cnt, dma_addr_t *);
   

[PATCH v2 1/4] drm/nouveau: base fence timeout on time of emission

[Marcin Slusarz]

Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index a22b9ad..41ee17d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -44,6 +44,7 @@ struct nouveau_fence {

uint32_t sequence;
bool signalled;
+   unsigned long timeout;

void (*work)(void *priv, bool signalled);
void *priv;
@@ -172,6 +173,7 @@ nouveau_fence_emit(struct nouveau_fence *fence)
}
OUT_RING (chan, fence->sequence);
FIRE_RING(chan);
+   fence->timeout = jiffies + 3 * DRM_HZ;

return 0;
 }
@@ -230,7 +232,8 @@ __nouveau_fence_signalled(void *sync_obj, void *sync_arg)
 int
 __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr)
 {
-   unsigned long timeout = jiffies + (3 * DRM_HZ);
+   struct nouveau_fence *fence = nouveau_fence(sync_obj);
+   unsigned long timeout = fence->timeout;
unsigned long sleep_time = NSEC_PER_MSEC / 1000;
ktime_t t;
int ret = 0;
-- 
1.7.8.5

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

--- Comment #1 from Vadim  2012-04-25 16:06:28 PDT ---
Probably register limit. Shader uses 5 inputs + 8 outputs + 112 temps = 125
registers. I think it should work if you could make it less than 120.

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

Re: [RFC v2 3/5] i2c: Add of_i2c_get_adapter() function

[Stephen Warren]

On 04/25/2012 03:45 AM, Thierry Reding wrote:
 This function resolves an OF device node to an I2C adapter registered
 with the I2C core.

I think this is doing the same thing as a patch I posted recently:
http://www.spinics.net/lists/linux-i2c/msg07808.html

What's the advantage of one way over the other?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Apr 17 (pci-sysfs.c and vga_switcheroo.c)

[Bjorn Helgaas]

On Tue, Apr 17, 2012 at 12:40 PM, Randy Dunlap rdun...@xenotime.net wrote:
 On 04/16/2012 09:42 PM, Stephen Rothwell wrote:

 Hi all,

 Changes since 20120416:


 When CONFIG_VGA_ARB is not enabled:

 drivers/built-in.o: In function `boot_vga_show':
 pci-sysfs.c:(.text+0x1060f): undefined reference to `vga_default_device'


 and

 drivers/built-in.o: In function `boot_vga_show':
 pci-sysfs.c:(.text+0x8cc2): undefined reference to `vga_default_device'
 drivers/built-in.o: In function `vga_switcheroo_register_client':
 (.text+0x76671): undefined reference to `vga_default_device'
 drivers/built-in.o: In function `vga_switchto_stage1':
 vga_switcheroo.c:(.text+0x767f4): undefined reference to 
 `vga_set_default_device'

I assume this is related to 77b267c7549e3629ea55cf780aa3d474da7bc2d5
(vgaarb: Add support for setting the default video device) and that
Matthew will take care of whatever needs to be done (if it's not fixed
already).

Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Michael,


On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:

On 03/11/2012 02:44 PM, Alan Cox wrote:

This patch allows to load an EDID data set via the firmware interface.
It contains data sets of frequently used screen resolutions (1024x768,
1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
specified as a module parameter of the drm_kms_helper module, e.g.
options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
command line parameter.

What if the DRM layer and driver are compiled in. They'll come up as
console before the file system so the firmware request will hang ?

Admittedly I did not try to compile the DRM layer and driver into the
kernel. However, I created an error condition by specifying a
non-existing EDID file. In this case, the function returns with error,
the mode count remains 0, and the system continues to run as if the
edid_firmware= parameter had not been specified.

Unfortunately, as of at least last month, my system hangs when I try to
use your feature (just as described by Alan Cox); the log shows that
during the boot process, there is a one-minute hang:

   [0.175207] [drm] radeon: power management initialized
   [   60.896507] [drm:edid_load] *ERROR* Requesting EDID firmware 
edid/1920x1200.bin failed (err=-2)

Is there any way to make your feature smarter about its timing with
relation to file system accessibility?

Sure.

Please copy your EDID data file to the directory firmware/edid of the 
kernel source tree, configure


CONFIG_EXTRA_FIRMWARE=edid/1920x1200.bin
CONFIG_EXTRA_FIRMWARE_DIR=firmware

and rebuild/reboot your kernel.

Does it work then?

-Carsten.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH v2 4/4] drm/nouveau: gpu lockup recovery

[Ben Skeggs]

On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote:
 Overall idea:
 Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
 handle them at ioctl level, reset the GPU and repeat last ioctl.
 
 GPU reset is done by doing suspend / resume cycle with few tweaks:
 - CPU-only bo eviction
 - ignoring vm flush / fence timeouts
 - shortening waits
Okay.  I've thought about this a bit for a couple of days and think I'll
be able to coherently share my thoughts on this issue now :)

Firstly, while I agree that we need to become more resilient to errors,
I don't think that following in the radeon/intel footsteps with
something (imo, hackish) like this is the right choice for us
necessarily.

The *vast* majority of lockups we have are as a result of us badly
mishandling exceptions reported to us by the GPU.  There are a couple of
exceptions, however, they're very rare..

A very common example is where people gain DMA_PUSHERs for whatever
reason, and things go haywire eventually.  To handle a DMA_PUSHER
sanely, generally you have to drop all pending commands for the channel
(set GET=PUT, etc) and continue on.  However, this leaves us with fences
and semaphores unsignalled etc, causing issues further up the stack with
perfectly good channels hanging on attempting to sync with the crashed
channel etc.

The next most common example I can think of is nv4x hardware, getting a
LIMIT_COLOR/ZETA exception from PGRAPH, and then a hang.  The solution
is simple, learn how to handle the exception, log it, and PGRAPH
survives.

I strongly believe that if we focused our efforts on dealing with what
the GPU reports to us a lot better, we'll find we really don't need such
lockup recovery.

I am, however, considering pulling the vm flush timeout error
propagation and break-out-of-waits-on-signals that builds on it.  As we
really do need to become better at having killable processes if things
go wrong :)

Ben.

 
 Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
 ---
  drivers/gpu/drm/nouveau/Makefile   |2 +-
  drivers/gpu/drm/nouveau/nouveau_bo.c   |2 +-
  drivers/gpu/drm/nouveau/nouveau_channel.c  |5 +-
  drivers/gpu/drm/nouveau/nouveau_drv.c  |   56 ++-
  drivers/gpu/drm/nouveau/nouveau_drv.h  |   45 -
  drivers/gpu/drm/nouveau/nouveau_fence.c|7 +-
  drivers/gpu/drm/nouveau/nouveau_gem.c  |   14 +++-
  drivers/gpu/drm/nouveau/nouveau_notifier.c |3 +
  drivers/gpu/drm/nouveau/nouveau_object.c   |6 +
  drivers/gpu/drm/nouveau/nouveau_reset.c|  148 
 
  drivers/gpu/drm/nouveau/nouveau_state.c|6 +
  drivers/gpu/drm/nouveau/nv50_graph.c   |   11 +-
  12 files changed, 290 insertions(+), 15 deletions(-)
  create mode 100644 drivers/gpu/drm/nouveau/nouveau_reset.c
 
 diff --git a/drivers/gpu/drm/nouveau/Makefile 
 b/drivers/gpu/drm/nouveau/Makefile
 index 03860f5..77d0c33 100644
 --- a/drivers/gpu/drm/nouveau/Makefile
 +++ b/drivers/gpu/drm/nouveau/Makefile
 @@ -9,7 +9,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o 
 nouveau_mem.o \
   nouveau_bo.o nouveau_fence.o nouveau_gem.o nouveau_ttm.o \
   nouveau_hw.o nouveau_calc.o nouveau_bios.o nouveau_i2c.o \
   nouveau_display.o nouveau_connector.o nouveau_fbcon.o \
 - nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o \
 + nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o nouveau_reset.o \
nouveau_pm.o nouveau_volt.o nouveau_perf.o nouveau_temp.o \
nouveau_mm.o nouveau_vm.o nouveau_mxm.o nouveau_gpio.o \
   nv04_timer.o \
 diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
 b/drivers/gpu/drm/nouveau/nouveau_bo.c
 index 5b0dc50..7de6cad 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
 @@ -936,7 +936,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict, 
 bool intr,
   }
  
   /* Software copy if the card isn't up and running yet. */
 - if (!dev_priv-channel) {
 + if (!dev_priv-channel || nouveau_gpu_reset_in_progress(dev_priv-dev)) 
 {
   ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, 
 no_wait_gpu, new_mem);
   goto out;
   }
 diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c 
 b/drivers/gpu/drm/nouveau/nouveau_channel.c
 index 846afb0..c0fa5a7 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_channel.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
 @@ -420,7 +420,7 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void 
 *data,
   init-fb_ctxdma_handle,
   init-tt_ctxdma_handle);
   if (ret)
 - return ret;
 + goto out;
   init-channel  = chan-id;
  
   if (nouveau_vram_pushbuf == 0) {
 @@ -450,6 +450,9 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void 
 *data,
   if (ret == 0)
   atomic_inc(chan-users); /* userspace 

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

--- Comment #2 from Marko bgz.ma...@gmail.com 2012-04-26 00:27:46 PDT ---
Any suggestions on how to accomplish that? I tried turning my code around and
around, but so far with no success. What should help with the register count?

On the other hand, why is the register limit set so low? I just tested the
program with Mesa 7.11, same hardware and r600 drivers - it works. This seems
like a regression.

If needed, there are binaries/source available for testing at
http://thelarge.org

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/exynos: add G2D driver

[Joonyoung Shim]

The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
This G2D driver is exynos drm specific and supports only G2D(version
4.1) of later Exynos series from Exynos4X12 because supporting DMA.

The G2D is performed by two tasks simply.
1. Configures the rendering parameters, such as foreground color and
   coordinates data by setting the drawing context registers.
2. Start the rendering process by setting thre relevant command
   registers accordingly.

The G2D version 4.1 supports DMA mode as host interface. User can make
command list to reduce HOST(ARM) loads. The contents of The command list
is setted to relevant registers of G2D by DMA.

The command list is composed Header and command sets and Tail.
- Header: The number of command set(4Bytes)
- Command set: Register offset(4Bytes) + Register data(4Bytes)
- Tail: Pointer of base address of the other command list(4Bytes)

By Tail field, the G2D can process many command lists without halt at
one go.

The G2D has following the rendering pipeline.
-- Primitive Drawing -- Rotation -- Clipping -- Bilinear Sampling
-- Color Key -- ROP -- Mask Operation -- Alpha Blending --
Dithering -- FrameBuffer

And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- window clipping
- rotation
- flip
- 4 operand raster operation(ROP4)
- masking operation
- alpha blending
- color key
- dithering
- etc

User should make the command list to data and registers needed by
operation to use. The Exynos G2D driver only manages the command lists
received from user. Some registers needs memory base address(physical
address) of image. User doesn't know its physical address, so fills the
gem handle of that memory than address to command sets, then G2D driver
converts it to memory base address.

We adds three ioctls and one event for Exynos G2D.

- ioctls
DRM_EXYNOS_G2D_GET_VER: get the G2D hardware version
DRM_EXYNOS_G2D_SET_CMDLIST: set the command list from user to driver
DRM_EXYNOS_G2D_EXEC: execute the command lists setted to driver

- event
DRM_EXYNOS_G2D_EVENT: event to give notification completion of the
  command list to user

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
The validation check codes are added to this patch v2 to prevent
security problem from patch v1.

v2 changelog:

Some code clean and added to check follows about cmdlist from user.

1. size of cmdlist
2. registers offset validation: the registers offset shouldn't get out
the range - 0x0104 ~ 0x0880 and it has to be multiple of 4. The cmd
can't have registers offset for base address and the cmd_gem can have
only registers offset for base address.

 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   29 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   13 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  932 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h |   36 ++
 include/drm/exynos_drm.h|   57 ++
 7 files changed, 1074 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 135b618..7f50967 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -33,3 +33,9 @@ config DRM_EXYNOS_VIDI
depends on DRM_EXYNOS
help
  Choose this option if you want to use Exynos VIDI for DRM.
+
+config DRM_EXYNOS_G2D
+   bool Exynos DRM G2D
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 353e1b7..eb651ca 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -14,5 +14,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 21658fa..ebcdc9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -40,6 +40,7 @@
 #include exynos_drm_plane.h
 #include exynos_drm_vidi.h
 #include exynos_drm_dmabuf.h
+#include exynos_drm_g2d.h
 
 #define DRIVER_NAMEexynos
 #define DRIVER_DESCSamsung SoC DRM
@@ -148,9 +149,16 @@ static int exynos_drm_unload(struct drm_device *dev)
 
 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
+ 

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[Christian König]

Hi Jerome,

I totally agree that we can remove the following debugfs files, since 
everything that just prints out or modifies register informations 
doesn't belongs into the kernel driver and should be moved to radeontool 
instead.

static int r100_debugfs_rbbm_info(struct seq_file *m, void *data)
static int r100_debugfs_cp_ring_info(struct seq_file *m, void *data)
static int r100_debugfs_cp_csq_fifo(struct seq_file *m, void *data)
static int r100_debugfs_mc_info(struct seq_file *m, void *data)
static int rv370_debugfs_pcie_gart_info(struct seq_file *m, void *data)
static int r420_debugfs_pipes_info(struct seq_file *m, void *data)
static int r600_debugfs_mc_info(struct seq_file *m, void *data)
static int rs400_debugfs_gart_info(struct seq_file *m, void *data)
static int rv515_debugfs_pipes_info(struct seq_file *m, void *data)
static int rv515_debugfs_ga_info(struct seq_file *m, void *data)


But I disagree that we should remove the following two, cause they print 
out driver internal data structures and it isn't easy to gain access to 
those, at least without a debugger and allot of patience.

static int radeon_debugfs_fence_info(struct seq_file *m, void *data)
static int radeon_debugfs_sa_info(struct seq_file *m, void *data)


Also I think I should mention that your patch doesn't touches the 
following two debugfs files, probably because of the same reason as the 
two above.

static int radeon_mm_dump_table(struct seq_file *m, void *data)
static int radeon_debugfs_pm_info(struct seq_file *m, void *data)


I also think that we should keep the ring debugfs file but of course not 
with the IB dumping facility, since otherwise we pretty much lose any 
possibility to look into multi ring lockups, which is something I 
currently spend most of my time on.

static int radeon_debugfs_ring_info(struct seq_file *m, void *data)


Additionally I have some comments on the dumping patch itself, but going 
to write that in a separate mail.


Cheers,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[David Airlie]

- Original Message -
 From: Christian König deathsim...@vodafone.de
 To: j glisse j.gli...@gmail.com
 Cc: Jerome Glisse jgli...@redhat.com, dri-devel@lists.freedesktop.org
 Sent: Thursday, 26 April, 2012 10:11:12 AM
 Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
 
 Hi Jerome,
 
 I totally agree that we can remove the following debugfs files, since
 everything that just prints out or modifies register informations
 doesn't belongs into the kernel driver and should be moved to
 radeontool
 instead.

In the future with secure boot we will need a better mechanism to diagnose 
things
than a userspace tool mapping pci bars, which we can't allow to happen in a 
secure
boot environment, so dropping all the files might not be a good idea unless we
provide a mechanism for radeontool to use. We can't allow userspace to 
read/write
arbitrary registers and stay secure.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

--- Comment #3 from Vadim pt...@yandex.ru 2012-04-26 03:43:45 PDT ---
(In reply to comment #2)
 Any suggestions on how to accomplish that? I tried turning my code around and
 around, but so far with no success. What should help with the register count?
 
 On the other hand, why is the register limit set so low? I just tested the
 program with Mesa 7.11, same hardware and r600 drivers - it works. This seems
 like a regression.
 If needed, there are binaries/source available for testing at
 http://thelarge.org

It's a hardware limit. The compiler in theory should optimize register
allocation, but the problem is that r600g still lacks real register allocator.
And probably some changes since 7.11 increased register usage in the TGSI IR.

I'll see if I can help with that shader somehow, but generally r600g needs a
better shader compiler. There is some work in progress on that, but I don't
know when it will be completed.

Also there is some experimental code that probably could help with that, but
currently it works only with evergreen GPUs. If you could use a gpu of the
evergreen class (IIRC it's all of 5xxx, some of 6xxx cards), then you might
want to try r600_shader_opt and r600_shader_opt_2 branches from the following
repo: https://github.com/VadimGirlin/mesa

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 15851] Switcheroo: Intel card not working after passing OFF to discrete card

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=15851


Chris Wilson ch...@chris-wilson.co.uk changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||ch...@chris-wilson.co.uk
  Component|Video(DRI - Intel)  |Video(DRI - non Intel)
 AssignedTo|airl...@linux.ie|drivers_video-dri@kernel-bu
   ||gs.osdl.org




--- Comment #5 from Chris Wilson ch...@chris-wilson.co.uk  2012-04-26 
12:15:28 ---
Can you verify that oops on a recent kernel?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49110] AMDILCFGStructurizer.cpp:1751:3: error: 'isCurrentDebugType' was not declared in this scope

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49110

--- Comment #2 from Fabio Pedretti fabio@libero.it 2012-04-26 06:14:49 
PDT ---
OK, I disabled mesa debug but now I get this (current git):

make[5]: *** No rule to make target
`../../../../../../src/gallium/drivers/radeon/libradeon.a', needed by
`libr600.a'.  Stop.

Full log at:
https://launchpadlibrarian.net/103127393/buildlog_ubuntu-precise-i386.mesa_8.1~git1204261417.a2f7ec~gd~p_FAILEDTOBUILD.txt.gz

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[Jerome Glisse]

2012/4/26 David Airlie airl...@redhat.com:


 - Original Message -
 From: Christian König deathsim...@vodafone.de
 To: j glisse j.gli...@gmail.com
 Cc: Jerome Glisse jgli...@redhat.com, dri-devel@lists.freedesktop.org
 Sent: Thursday, 26 April, 2012 10:11:12 AM
 Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

 Hi Jerome,

 I totally agree that we can remove the following debugfs files, since
 everything that just prints out or modifies register informations
 doesn't belongs into the kernel driver and should be moved to
 radeontool
 instead.

 In the future with secure boot we will need a better mechanism to diagnose 
 things
 than a userspace tool mapping pci bars, which we can't allow to happen in a 
 secure
 boot environment, so dropping all the files might not be a good idea unless we
 provide a mechanism for radeontool to use. We can't allow userspace to 
 read/write
 arbitrary registers and stay secure.

 Dave.

Well those files are useless, each time i debug a lockup and try to
use them i loose
time on them as they never helped me so far and i seriously doubt they
would help
me in the future or anyone else.

For secure boot my guess is that radeontool will become obsolete and
by that time
we might need to add some reg dumping. But none of the current files
seems usefull
to me.

The fence and sa files might make sense to debug the associated code
as it's nice
to be able to dump associated kernel struct.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[Alex Deucher]

On Thu, Apr 26, 2012 at 9:36 AM, Jerome Glisse j.gli...@gmail.com wrote:
 2012/4/26 David Airlie airl...@redhat.com:


 - Original Message -
 From: Christian König deathsim...@vodafone.de
 To: j glisse j.gli...@gmail.com
 Cc: Jerome Glisse jgli...@redhat.com, dri-devel@lists.freedesktop.org
 Sent: Thursday, 26 April, 2012 10:11:12 AM
 Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

 Hi Jerome,

 I totally agree that we can remove the following debugfs files, since
 everything that just prints out or modifies register informations
 doesn't belongs into the kernel driver and should be moved to
 radeontool
 instead.

 In the future with secure boot we will need a better mechanism to diagnose 
 things
 than a userspace tool mapping pci bars, which we can't allow to happen in a 
 secure
 boot environment, so dropping all the files might not be a good idea unless 
 we
 provide a mechanism for radeontool to use. We can't allow userspace to 
 read/write
 arbitrary registers and stay secure.

 Dave.

 Well those files are useless, each time i debug a lockup and try to
 use them i loose
 time on them as they never helped me so far and i seriously doubt they
 would help
 me in the future or anyone else.

 For secure boot my guess is that radeontool will become obsolete and
 by that time
 we might need to add some reg dumping. But none of the current files
 seems usefull
 to me.

We can always expose the mmio bar (and vbios for that matter) via
ioctl or sysfs for radeontool.  We should try and write a better
unified tool suite.

Alex


 The fence and sa files might make sense to debug the associated code
 as it's nice
 to be able to dump associated kernel struct.

 Cheers,
 Jerome
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33309] [855GM] GPU freeze due to overlay hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=33309

--- Comment #16 from stefan fdo.12.ben...@xoxy.net 2012-04-26 07:48:56 PDT ---
(In reply to comment #15)
  --- Comment #14 from stefan fdo.12.ben...@xoxy.net 2012-03-26 13:17:45 
  PDT ---
 Just add
 #define MI_WRITE_NOPID_REG (1  22)
 somewhere.
 Yours, Daniel

Hi Daniel,

sorry for answering so late. I had a few hangs with 3.3.0 with this patch
until I realised that I had relaxed fencing enabled (which I enabled out
of curiosity at some point). Since then I went back to a plain config and
had a GPU hang with the vanilla 3.3.3, I can attach the error state output
if you think it can still be useful.

The good news is that 3.3.0 with this patch seems stable, and I am still
testing 3.3.3 with this patch and will report back if I manage to hang the
GPU (or not).

Cheers,
Stefan.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mgag200: initial g200se driver

[Adam Jackson]

On Thu, 2012-04-26 at 14:48 +0100, Dave Airlie wrote:

 +/*
 + * Our emulated hardware has two sets of memory. One is video RAM and can
 + * simply be used as a linear framebuffer - the other provides mmio access
 + * to the display registers. The latter can also be accessed via IO port
 + * access, but we map the range and use mmio to program them instead
 + */

I suspect this comment came from somewhere near the emulated cirrus card
in qemu?  G200's definitely not emulated hardware.

 +/*
 + * The meat of this driver. The core passes us a mode and we have to program
 + * it. The modesetting here is the bare minimum required to satisfy the qemu
 + * emulation of this hardware, and running this against a real device is
 + * likely to result in an inadequately programmed mode. We've already had
 + * the opportunity to modify the mode, so whatever we receive here should
 + * be something that can be correctly programmed and displayed
 + */

Yep, drm/cirrus all over the place here.

 +/*
 + * This is called after a mode is programmed. It should reverse anything done
 + * by the prepare function
 + */
 +static void mga_crtc_commit(struct drm_crtc *crtc)
 +{

This appears to be missing the analog of the Reset tagfifo commit from
the X driver for G200ER:

http://cgit.freedesktop.org/xorg/driver/xf86-video-mga/commit/?id=01ca2186ea028b2549de509b51726aa08519fce0

Which, admittedly, is in an odd place in the X driver.

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] drm-intel-fixes for 3.4

[Daniel Vetter]

Hi Dave,

Nothing major here and imo can wait a bit if you don't have anything
important in drm-fixes yet:
- VGA load-detect fix. This bug seems to be as old as the load-detect code
  (2.6.30), but needs stupid userspace (upowerd trying to detect
  connectors on dpms-off outputs) to actually kill the machine. And
  obviously a machine without VGA-hotplug, otherwise we don't do load
  detect.
- 2 interger overflow fixes for unpriviledged ioctls from Xi Wang.

Yours, Daniel

The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:

  Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 44afb3a04391a74309d16180d1e4f8386fdfa745:

  drm/i915: fix integer overflow in i915_gem_do_execbuffer() (2012-04-23 
22:32:15 +0200)


Daniel Vetter (1):
  drm/i915: fixup load-detect on enabled, but not active pipe

Xi Wang (2):
  drm/i915: fix integer overflow in i915_gem_execbuffer2()
  drm/i915: fix integer overflow in i915_gem_do_execbuffer()

 drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 +++-
 drivers/gpu/drm/i915/intel_crt.c   |   29 +++-
 2 files changed, 18 insertions(+), 19 deletions(-)
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: handle input/output sdvo timings separately in mode_set

[Daniel Vetter]

On Wed, Apr 11, 2012 at 12:37:24AM +0200, Daniel Vetter wrote:
 On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
  Reported-and-Tested-by: Bernard Blackham b-linux...@largestprime.net
 
 This tested-by is actually a lie, I've mixed up a few bug reports. Bug
 reporter is currently on vacation and will test this stuff in 2 weeks.

Ok, I've lucked out and the bug reporter just said that this does indeed
work. Now I just need someone to grill himself by reviewing this stuff ...
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: handle input/output sdvo timings separately in mode_set

[Daniel Vetter]

I've picked this up for -fixes, with Jesse's irc r-b added.
-Daniel

On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
 We seem to have a decent confusion between the output timings and the
 input timings of the sdvo encoder. If I understand the code correctly,
 we use the original mode unchanged for the output timings, safe for
 the lvds case. And we should use the adjusted mode for input timings.
 
 Clarify the situation by adding an explicit output_dtd to the sdvo
 mode_set function and streamline the code-flow by moving the input and
 output mode setting in the sdvo encode together.
 
 Furthermore testing showed that the sdvo input timing needs the
 unadjusted dotclock, the sdvo chip will automatically compute the
 required pixel multiplier to get a dotclock above 100 MHz.
 
 Fix this up when converting a drm mode to an sdvo dtd.
 
 This regression was introduced in
 
 commit c74696b9c890074c1e1ee3d7496fc71eb3680ced
 Author: Pavel Roskin pro...@gnu.org
 Date:   Thu Sep 2 14:46:34 2010 -0400
 
 i915: revert some checks added by commit 32aad86f
 
 particularly the following hunk:
 
 diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
 b/drivers/gpu/drm/i915/intel_sdvo.c
 index 093e914..62d22ae 100644
 --- a/drivers/gpu/drm/i915/intel_sdvo.c
 +++ b/drivers/gpu/drm/i915/intel_sdvo.c
 @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder 
 *encoder,
 
  /* We have tried to get input timing in mode_fixup, and filled into
 adjusted_mode */
 -if (intel_sdvo-is_tv || intel_sdvo-is_lvds) {
 -intel_sdvo_get_dtd_from_mode(input_dtd, adjusted_mode);
 +intel_sdvo_get_dtd_from_mode(input_dtd, adjusted_mode);
 +if (intel_sdvo-is_tv || intel_sdvo-is_lvds)
  input_dtd.part2.sdvo_flags = intel_sdvo-sdvo_flags;
 -} else
 -intel_sdvo_get_dtd_from_mode(input_dtd, mode);
 
  /* If it's a TV, we already set the output timing in mode_fixup.
   * Otherwise, the output timing is equal to the input timing.
 
 Due to questions raised in review, below a more elaborate analysis of
 the bug at hand:
 
 Sdvo seems to have two timings, one is the output timing which will be
 sent over whatever is connected on the other side of the sdvo chip (panel,
 hdmi screen, tv), the other is the input timing which will be generated by
 the gmch pipe. It looks like sdvo is expected to scale between the two.
 
 To make things slightly more complicated, we have a bunch of special
 cases:
 - For lvds panel we always use a fixed output timing, namely
   intel_sdvo-sdvo_lvds_fixed_mode, hence that special case.
 - Sdvo has an interface to generate a preferred input timing for a given
   output timing. This is the confusing thing that I've tried to clear up
   with the follow-on patches.
 - A special requirement is that the input pixel clock needs to be between
   100MHz and 200MHz (likely to keep it within the electromechanical design
   range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
   doubled/quadrupled.
 
 The thing this patch tries to fix is that the pipe needs to be
 explicitly instructed to double/quadruple the pixels and needs the
 correspondingly higher pixel clock, whereas the sdvo adaptor seems to
 do that itself and needs the unadjusted pixel clock. For the sdvo
 encode side we already set the pixel mutliplier with a different
 command (0x21).
 
 This patch tries to fix this mess by:
 - Keeping the output mode timing in the unadjusted plain mode, safe
   for the lvds case.
 - Storing the input timing in the adjusted_mode with the adjusted
   pixel clock. This way we don't need to frob around with the core
   crtc mode set code.
 - Fixing up the pixelclock when constructing the sdvo dtd timing
   struct. This is why the first hunk of the patch is an integral part
   of the series.
 - Dropping the is_tv special case because input_dtd is equivalent to
   adjusted_mode after these changes. Follow-up patches clear this up
   further (by simply ripping out intel_sdvo-input_dtd because it's
   not needed).
 
 v2: Extend commit message with an in-depth bug analysis.
 
 Reported-and-Tested-by: Bernard Blackham b-linux...@largestprime.net
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/intel_sdvo.c |   34 ++
  1 files changed, 18 insertions(+), 16 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
 b/drivers/gpu/drm/i915/intel_sdvo.c
 index 6898145..ab47c1e 100644
 --- a/drivers/gpu/drm/i915/intel_sdvo.c
 +++ b/drivers/gpu/drm/i915/intel_sdvo.c
 @@ -733,6 +733,7 @@ static void intel_sdvo_get_dtd_from_mode(struct 
 intel_sdvo_dtd *dtd,
   uint16_t width, height;
   uint16_t h_blank_len, h_sync_len, v_blank_len, v_sync_len;
   uint16_t h_sync_offset, v_sync_offset;
 + int mode_clock;
  
   width = mode-crtc_hdisplay;
   height = mode-crtc_vdisplay;
 @@ -747,7 +748,11 @@ static void 

Re: [pull] drm-intel-fixes for 3.4

[Daniel Vetter]

On Thu, Apr 26, 2012 at 05:35:01PM +0200, Daniel Vetter wrote:
 Hi Dave,
 
 Nothing major here and imo can wait a bit if you don't have anything
 important in drm-fixes yet:
 - VGA load-detect fix. This bug seems to be as old as the load-detect code
   (2.6.30), but needs stupid userspace (upowerd trying to detect
   connectors on dpms-off outputs) to actually kill the machine. And
   obviously a machine without VGA-hotplug, otherwise we don't do load
   detect.
 - 2 interger overflow fixes for unpriviledged ioctls from Xi Wang.

A tested-by for a regression fix just arrived, so I've thrown that in, too:
- Fix SDVO regression for low-res (pixelclock  100MHz) digital outputs,
  introduce in 2.6.36.

Cheers, Daniel

The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:

  Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 6651819b4b4fc3caa6964c5d825eb4bb996f3905:

  drm/i915: handle input/output sdvo timings separately in mode_set (2012-04-26 
18:56:26 +0200)


Daniel Vetter (2):
  drm/i915: fixup load-detect on enabled, but not active pipe
  drm/i915: handle input/output sdvo timings separately in mode_set

Xi Wang (2):
  drm/i915: fix integer overflow in i915_gem_execbuffer2()
  drm/i915: fix integer overflow in i915_gem_do_execbuffer()

 drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 ++-
 drivers/gpu/drm/i915/intel_crt.c   |   29 +---
 drivers/gpu/drm/i915/intel_sdvo.c  |   34 +++-
 3 files changed, 36 insertions(+), 35 deletions(-)
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #51 from Michel Dänzer mic...@daenzer.net 2012-04-26 11:50:28 PDT 
---
Does the Mesa patch series at
http://lists.freedesktop.org/archives/mesa-dev/2012-April/021211.html help?

Beware that it's only lightly tested, and I'll be away now for a long weekend.
If there's a problem with the patches, I'll look into it next week.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mgag200: initial g200se driver

[Ville Syrjälä]

On Thu, Apr 26, 2012 at 02:48:45PM +0100, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 This is a driver for the G200 server engines chips,
 it doesn't driver any of the Matrix G series desktop cards.

BTW I have a pile of modesetting and card initialization code
written for all mga chips from 2064W up to G550, except these
G200 server variants.

It's mostly in userspace but I wrote some wrappers for kernel APIs,
so most of the code looks like kernel code (not drm/kms code though).

It was a night/weekend project for me at some point, and my plan was
to make a kms driver out of it, but I ran out of steam before I got
that far. I suppose I should try to get off my ass and do something
useful with that code.

-- 
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mgag200: initial g200se driver

[Matt Turner]

On Thu, Apr 26, 2012 at 9:48 AM, Dave Airlie airl...@gmail.com wrote:
 diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
 b/drivers/gpu/drm/mgag200/mgag200_mode.c
 new file mode 100644
 index 000..a74f946
 --- /dev/null
 +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
 @@ -0,0 +1,1494 @@
 +/*
 + * Copyright 2000,2001 Sven Luther.

Here...

 + * Copyright 2010 Matt Turner.
 + * Copyright 2011 Red Hat m...@redhat.com
 + *
 + * This file is subject to the terms and conditions of the GNU General
 + * Public License version 2. See the file COPYING in the main
 + * directory of this archive for more details.
 + *
 + * Authors: Matthew Garrett
 + *                     Matt Turner
 + *                     Sven Luther
 + *                     Thomas Witzel
 + *                     Alan Hourihane

and here, the copyrights and authorship for Sven Luther, Thomas
Witzel, and Alan Hourihane can be dropped. When I wrote glint_crtc.c,
I copied PM3DAC_CalculateClock from xf86-video-glint. With no remnants
of this function left, none of the code was written by them.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #52 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-04-26 
14:19:41 PDT ---
(In reply to comment #51)
 Does the Mesa patch series at
 http://lists.freedesktop.org/archives/mesa-dev/2012-April/021211.html help?
 
 Beware that it's only lightly tested, and I'll be away now for a long weekend.
 If there's a problem with the patches, I'll look into it next week.

No, it doesn't. But it's not worst either.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49198] New: glxinfo SIGSEGV in pthread_detach under radeon_drm_cs_destroy under dri2_destroy_context

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49198

 Bug #: 49198
   Summary: glxinfo SIGSEGV in pthread_detach under
radeon_drm_cs_destroy under dri2_destroy_context
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: Other
OS/Version: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: bugs.freedesk...@karlt.net


OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL version string: 2.1 Mesa 8.0.2
OpenGL shading language version string: 1.20

#0  0x76002e98 in pthread_detach () from /lib64/libpthread.so.0
#1  0x747f2324 in pipe_thread_destroy (thread=optimized out)
at ../../../../../src/gallium/auxiliary/os/os_thread.h:78
#2  radeon_drm_cs_destroy (rcs=0x77fd7010) at radeon_drm_cs.c:475
#3  0x747e07b0 in r600_context_fini (ctx=0x642dd8)
at r600_hw_context.c:780
#4  0x747c4932 in r600_destroy_context (context=0x642ac0)
at r600_pipe.c:197
#5  0x7489397b in st_destroy_context (st=0x7a8ae0)
at state_tracker/st_context.c:268
#6  0x747ee324 in dri_destroy_context (cPriv=optimized out)
at dri_context.c:174
#7  0x747c1abb in driDestroyContext (pcp=0x6177e0)
at ../common/dri_util.c:277
#8  0x77bbf01f in dri2_destroy_context (context=0x617640)
at dri2_glx.c:132
#9  0x77b99b89 in glx_display_free (priv=0x613a30) at glxext.c:228
#10 0x77b99c16 in __glXCloseDisplay (dpy=0x607010, 
codes=optimized out) at glxext.c:275
#11 0x774c7f9c in XCloseDisplay () from /usr/lib64/libX11.so.6
#12 0x00403590 in main ()

Gentoo build with
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--libdir=/usr/lib64 --disable-dependency-tracking --enable-dri --enable-glx
--enable-texture-float --disable-debug --enable-egl --enable-gbm
--disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm
--enable-shared-dricore --enable-shared-glapi
--with-dri-drivers=,swrast,radeon,r200 --with-gallium-drivers=,swrast,r600
--with-egl-platforms=x11,drm --enable-gallium-egl --disable-d3d1x
--disable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --disable-vdpau
--disable-xa --disable-xvmc

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

--- Comment #4 from Vadim pt...@yandex.ru 2012-04-26 17:38:49 PDT ---
Created attachment 60642
  -- https://bugs.freedesktop.org/attachment.cgi?id=60642
lorentzTransform function

It seems you could replace the following lines in the lorentzTransform
function:

r.w = g*p.w - v.x*g*p.x - v.y*g*p.y - v.z*g*p.z;
r.x = -v.x*g*p.w + (1.0 + gm1*v.x*v.x/v2)*p.x + (gm1*v.x*v.y/v2)*p.y +
(gm1*v.x*v.z/v2)*p.z;
r.y = -v.y*g*p.w + (gm1*v.y*v.x/v2)*p.x + (1.0 + gm1*v.y*v.y/v2)*p.y +
(gm1*v.y*v.z/v2)*p.z,
r.z = -v.z*g*p.w + (gm1*v.z*v.x/v2)*p.x + (gm1*v.z*v.y/v2)*p.y +
(1.0+gm1*v.z*v.z/v2)*p.z;

with 

vec3 p3 = vec3(p.x, p.y, p.z);
float t = dot(v, p3);
float t2 = gm1*t/v2 - g*p.w;
r = vec4( v*t2 + p3, g * (p.w - t));

Attachment contains the complete text of the modified function with the
separate steps of the transformation in the comments. Please check if all steps
are correct. Anyway, it shows the direction.

Original shader uses 130 regs, 1262 vliw alu instructions on my system.
Modified version - 81 reg, 778 instructions.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-04-25 at 12:56 +1000, Ben Skeggs wrote:
 On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
  On 2012-04-23 21:03 -0400, Nick Bowler wrote:
   On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
 Following up on the above, the commit which introduces the panics 
 during
 boot is this one:

 commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
 Author: Jerome Glisse jgli...@redhat.com
 Date:   Wed Nov 9 17:15:26 2011 -0500
 
 drm/ttm: isolate dma data from ttm_tt V4
  [...]
dea7e0a ttm: fix agp since ttm tt rework

fixed that.
   
   Yes, I just tested this commit and the one immediately before it.  The
   one before crashes in the usual way, and dea7e0a boots (with the VGA
   output black as in the original report).  So this fixed the crash.
  
  OK, here's what I did:
  
   - Since dea7e0a is the first commit that both (a) boots and (b) has
 broken VGA, I checked it out on a new branch:
  
   git checkout -b crazy dea7e0a
  
   - Next, I reverted *all* (well, I missed one by accident) the remaining
 nouveau-specific commits between 3230cfc34 (drm/nouveau: enable the
 ttm dma pool when swiotlb is active V3) (i.e., the last commit that
 (a) boots and (b) has non-broken VGA) and dea7e0a:
  
   git revert --no-edit 0c101461e267..f7b24c42da1a
  
   - Amazingly, the resulting kernel booted and had working VGA, so I did
 a backwards bisect on this branch of reverts.  In a strange twist
 of fate, this actually managed to produce bootable kernels the entire
 time.  The bisection pinpointed the following commit as the culprit:
  
  commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
  Author: Ben Skeggs bske...@redhat.com
  Date:   Mon Nov 21 16:41:48 2011 +1000
  
  drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of 
  issues
  
  - moves out of nouveau_bios.c and demagics the logical state definitions
  - simplifies chipset-specific driver interface
  - makes most of gpio irq handling common, will use for nv4x hpd later
  - api extended to allow both direct gpio access, and access using the
logical function states
  - api extended to allow for future use of gpio extender chips
  - pre-nv50 was handled very badly, the main issue being that all GPIOs
were being treated as output-only.
  - fixes nvd0 so gpio changes actually stick, magic reg needs bashing
  
  Signed-off-by: Ben Skeggs bske...@redhat.com
 Excellent!  That makes things possible.
 
 Are you able to mount debugfs, and email /debugfs/dri/0/vbios.rom for me
 (privately if you wish) and I'll attempt to track down what broke for
 you.
Does this patch help you at all?

http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305

Cheers,
Ben.
 
 Thanks!
 Ben.
 
  
  Unfortunately, there are a number of seemingly non-trivial conflicts
  trying to revert just this one gigantic commit.  So to avoid any
  conflicts, I reverted all of the following (in this order) on top of
  3.3.3 (there are even more conflicts trying to revert on top of Linus'
  master):
  
7df898b1a70b (drm/nouveau/disp: check that panel power gpio is enabled 
  at init time)
52c4d767437b (drm/nouveau: move hpd enable/disable to common code)
47e5d5cb83d4 (drm/nv40/disp: implement support for hotplug irq)
a0b25635515e (drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a 
  number of issues)
  
  and my VGA is working again!
  
  Cheers,
 
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RV670: wine: Diablo III Beta: GPU Lockup and slow framerate(9FPS avg.) 400MB compressed trace available.

[Mike Mestnik]

My system specs are here http://pastebin.com/35NwE0G1
dmsg http://pastebin.com/CDhuT4bU
http://c566453.r53.cf2.rackcdn.com/DIIILoackupLowFPS.trace.xz

This trace shows unbearable slowness and a GPU lockup at a specific map
location, *GPU lockup CP detected.
*http://appdb.winehq.org/objectManager.php?sClass=versioniId=25588

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Bug reports on the psb-gfx driver

[Kristoffer Eriksson]

Alan Cox skrev 2012-04-18 23:21:

That frequency seems about the same as the one I'm experiences. All though
some times it's more often, but I can't say I've done anything special at
the same time.

3.3.2-1-ARCH
Intel(R) Atom(TM) CPU Z520 @ 1.33GHz

Attachment: dmesg ouput


What X display server are you using (fbdev or other ?). Also I see a few
writes to the brightness in the log - did you fiddle with the brightness
by hand at all ?

Alan,

Without looking at the code I can say that those brightness commands are 
not related to this

issue since Ive been having them since the first working kernel version.
Havent had time to look at the code but Ive understod them to happen 
simply when you
press a key to return from backlight suspend. Something like the default 
brightness setting that gets invoked

after return from suspend.

Håvar see
[ 7659.177126] gma500 :00:02.0: Backlight lvds set brightness 186a186a

while I see
[] gma500 :00:02.0: Backlight lvds set brightness 7a127a12





Either way I suspect the only way to find this is to verify a
configuration it occurs on, go back a kernel, verify it doesn't happen
there and then build a kernel to the point in the git tree before the
gma500 patches were changed (to check its not caused by something else
such as an ACPI change), then try and find which one caused it.
Will do further fresh builds to see if I can reproduce the blanking 
issue and also

test out the patch.



That will be tedious but unfortunately I've got no documentation or other
good ways to chase this down.

Alan



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel