[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #25 from Rafael Castillo  ---
nope the same, i guess you have something in your branch different than mesa
master maybe

-- 
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 v9 1/2] dmabuf-sync: Add a buffer synchronization framework

[Inki Dae]

This patch adds a buffer synchronization framework based on DMA BUF[1]
and and based on ww-mutexes[2] for lock mechanism, and is rebased on
linux-3.12-rc1

The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
user application. This framework can be used for all dma devices using
system memory as dma buffer, especially for most ARM based SoCs.

Changelog v9:
- Delete only one sync object matched at DEL_OBJ_FROM_RSV macro.
- Fix memory leak issue at dmabuf_sync_single_lock()

Changelog v8:
Consider the write-and-then-read ordering pointed out by David Herrmann,
- The ordering issue means that a task don't take a lock to the dmabuf
  so this task would be stalled even though this task requested a lock to
  the dmabuf between other task unlocked and tries to lock the dmabuf
  again. For this, we have added a wait event mechanism using only generic
  APIs, wait_event_timeout and wake_up functions.

  The below is how to handle the ordering issue using this mechanism:
  1. Check if there is a sync object added prior to current task's one.
  2. If exists, it unlocks the dmabuf so that other task can take a lock
 to the dmabuf first.
  3. Wait for the wake up event from other task: current task will be
 waked up when other task unlocks the dmabuf.
  4. Take a lock to the dmabuf again.
- Code cleanups.

Changelog v7:
Fix things pointed out by Konrad Rzeszutek Wilk,
- Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
- make sure to unlock and unreference all dmabuf objects
  when dmabuf_sync_fini() is called.
- Add more comments.
- code cleanups.

Changelog v6:
- Fix sync lock to multiple reads.
- Add select system call support.
  . Wake up poll_wait when a dmabuf is unlocked.
- Remove unnecessary the use of mutex lock.
- Add private backend ops callbacks.
  . This ops has one callback for device drivers to clean up their
sync object resource when the sync object is freed. For this,
device drivers should implement the free callback properly.
- Update document file.

Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
  to hook up to ttm and dma-buf for easy sharing of reservations across
  devices. However, the dmabuf sync can be used for all dma devices; v4l2
  and drm based drivers, so doesn't need the reservation_object anymore.
  With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

The mechanism of this framework has the following steps,
1. Register dmabufs to a sync object - A task gets a new sync object and
can add one or more dmabufs that the task wants to access.
This registering should be performed when a device context or an event
context such as a page flip event is created or before CPU accesses a shared
buffer.

dma_buf_sync_get(a sync object, a dmabuf);

2. Lock a sync object - A task tries to lock all dmabufs added in its own
sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead
lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
and DMA. Taking a lock means that others cannot access all locked dmabufs
until the task that locked the corresponding dmabufs, unlocks all the locked
dmabufs.
This locking should be performed before DMA or CPU accesses these dmabufs.

dma_buf_sync_lock(a sync object);

3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
object. The unlock means that the DMA or CPU accesses to the dmabufs have
been completed so that others may access them.
This unlocking should be performed after DMA or CPU has completed accesses
to the dmabufs.

dma_buf_sync_unlock(a sync object);

4. Unregister one or all dmabufs from a sync object - A task unregisters
the given dmabufs from the sync object. This means that the task dosen't
want to lock the dmabufs.
The unregistering should be performed after DMA or CPU has completed
accesses to the dmabufs or when dma_buf_sync_lock() is failed.

dma_buf_sync_put(a sync object, a dmabuf);
dma_buf_sync_put_all(a sync object);

The described steps may be summarized as:
get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put

This framework includes the following two features.
1. read (shared) and write (exclusive) locks - A task is required to declare
the access type when the task tries to register a dmabuf;
READ, WRITE, READ DMA, or WRITE DMA.

The below is example codes,
struct d

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

--- Comment #12 from Nicholas Miell  ---
(In reply to comment #11)
> > ARB_fragment_program_shadow may leave it undefined, but the GL spec ...
> 
> Which spec exactly? GL specifications only cover GLSL shaders.
> ARB_fragment_program is separate from that and has its own rules. The
> extension specification clearly states that behaviour is undefined.
> 
Section 8.23.1 of the GL 4.4 spec, which I paraphrased in comment #9.

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #24 from Johannes Obermayr  ---
$ find src/gallium/drivers/ -name "*.la" -delete -o -name "*.a" -delete -o
-name "*.so" -delete
$ make

to rebuild libradeon as well as libr600 and libradeonsi without linked-in
libradeon ...

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #23 from Rafael Castillo  ---
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_blit.o): In
function `r600_blit_decompress_depth':
r600_blit.c:(.text+0x1f00): multiple definition of `r600_blit_decompress_depth'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_blit.o):r600_blit.c:(.text+0x1fa0):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_blit.o): In
function `r600_decompress_color_textures':
r600_blit.c:(.text+0x23c0): multiple definition of
`r600_decompress_color_textures'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_blit.o):r600_blit.c:(.text+0x2780):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_query.o): In
function `r600_init_query_functions':
r600_query.c:(.text+0x280): multiple definition of `r600_init_query_functions'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_query.o):r600_query.c:(.text+0x2000):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_resource.o):
In function `r600_init_screen_resource_functions':
r600_resource.c:(.text+0x40): multiple definition of
`r600_init_screen_resource_functions'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_resource.o):r600_resource.c:(.text+0x80):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_resource.o):
In function `r600_init_context_resource_functions':
r600_resource.c:(.text+0x80): multiple definition of
`r600_init_context_resource_functions'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_resource.o):r600_resource.c:(.text+0xc0):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_texture.o):
In function `r600_init_flushed_depth_texture':
r600_texture.c:(.text+0x14e0): multiple definition of
`r600_init_flushed_depth_texture'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_texture.o):r600_texture.c:(.text+0x2e60):
first defined here
collect2: error: ld returned 1 exit status
gmake[3]: *** [egl_gallium.la] Error 1
gmake[3]: Leaving directory
`/var/tmp/portage/media-libs/mesa-/work/Mesa--amd64/src/gallium/targets/egl-static'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/var/tmp/portage/media-libs/mesa-/work/Mesa--amd64/src/gallium/targets'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/var/tmp/portage/media-libs/mesa-/work/Mesa--amd64/src'
make: *** [all-recursive] Error 1

im using gentoo with mesa- from x11 overlay and llvm- as well, maybe is
that

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

Johannes Obermayr  changed:

   What|Removed |Added

  Attachment #85550|0   |1
is obsolete||

--- Comment #22 from Johannes Obermayr  ---
Created attachment 86034
  --> https://bugs.freedesktop.org/attachment.cgi?id=86034&action=edit
new attemp with LIBADD += $(ELF_LIB)

I hate this automake / libtool because mine seems to be smart and I don't see
this errors ...

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #21 from Rafael Castillo  ---
bOOM

../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_blit.o): In
function `r600_blit_decompress_depth':
r600_blit.c:(.text+0x1f00): multiple definition of `r600_blit_decompress_depth'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_blit.o):r600_blit.c:(.text+0x1fa0):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_blit.o): In
function `r600_decompress_color_textures':
r600_blit.c:(.text+0x23c0): multiple definition of
`r600_decompress_color_textures'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_blit.o):r600_blit.c:(.text+0x2780):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_query.o): In
function `r600_init_query_functions':
r600_query.c:(.text+0x280): multiple definition of `r600_init_query_functions'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_query.o):r600_query.c:(.text+0x2000):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_resource.o):
In function `r600_init_screen_resource_functions':
r600_resource.c:(.text+0x40): multiple definition of
`r600_init_screen_resource_functions'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_resource.o):r600_resource.c:(.text+0x80):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_resource.o):
In function `r600_init_context_resource_functions':
r600_resource.c:(.text+0x80): multiple definition of
`r600_init_context_resource_functions'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_resource.o):r600_resource.c:(.text+0xc0):
first defined here
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(r600_texture.o):
In function `r600_init_flushed_depth_texture':
r600_texture.c:(.text+0x14e0): multiple definition of
`r600_init_flushed_depth_texture'
../../../../src/gallium/drivers/r600/.libs/libr600.a(r600_texture.o):r600_texture.c:(.text+0x2e60):
first defined here
../../../../src/gallium/drivers/radeon/.libs/libradeon.a(libradeon_la-radeon_llvm_emit.o):
In function `radeon_llvm_compile':
radeon_llvm_emit.c:(.text+0x1eb): undefined reference to `elf_version'
radeon_llvm_emit.c:(.text+0x243): undefined reference to `elf_memory'
radeon_llvm_emit.c:(.text+0x255): undefined reference to `elf_getshdrstrndx'
radeon_llvm_emit.c:(.text+0x267): undefined reference to `elf_nextscn'
radeon_llvm_emit.c:(.text+0x27e): undefined reference to `gelf_getshdr'
radeon_llvm_emit.c:(.text+0x29b): undefined reference to `elf_strptr'
radeon_llvm_emit.c:(.text+0x2cf): undefined reference to `elf_getdata'
radeon_llvm_emit.c:(.text+0x37e): undefined reference to `elf_getdata'
collect2: error: ld returned 1 exit status
gmake[3]: *** [egl_gallium.la] Error 1

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #20 from Rafael Castillo  ---
testing

-- 
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 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

--- Comment #11 from Grigori Goronzy  ---
> ARB_fragment_program_shadow may leave it undefined, but the GL spec ...

Which spec exactly? GL specifications only cover GLSL shaders.
ARB_fragment_program is separate from that and has its own rules. The extension
specification clearly states that behaviour is undefined.

Besides, OpenGL contradicts itself a little bit: in GL 4.4 spec, 15.2.1 it
states that behaviour is undefined for this case, too. It makes much more sense
anyway, shadow sampling is wildly different from sampling a texture normally in
terms of what the sampling result look like.

-- 
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 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

--- Comment #10 from Nicholas Miell  ---
To quote the Cg tutorial:

"Notice that the code for the shadow map query is virtually identical to the
code for the projective texture lookup in Example 9-6. To a Cg programmer,
shadow maps are like other projective textures, except that instead of
returning a texture color,tex2Dproj returns a value representing shadow
coverage. The underlying hardware implementation automatically recognizes when
a texture is a depth texture (instead of a color texture) and performs the
shadow map comparison instead of an ordinary texture fetch."

I suspect that the Cg compiler always compiles tex2Dproj to a TEX instruction
with the SHADOW2D target and relies on OpenGL implementations always
transparently using normal sampling on non-depth non-stencil textures.

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

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_drv.h between commit 6e1b4fdad515 ("drm/i915:
Delay disabling of VGA memory until vgacon->fbcon handoff is done") from
Linus' tree and commit eb14cb747bc5 ("drm/i915: Add state readout and
checking for has_dp_encoder and dp_m_n") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_drv.h
index 28cae80,b85354f..000
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -793,6 -814,13 +815,14 @@@ extern void hsw_pc8_disable_interrupts(
  extern void hsw_pc8_restore_interrupts(struct drm_device *dev);
  extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
  extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
 +extern void i915_disable_vga_mem(struct drm_device *dev);
+ extern void intel_dp_get_m_n(struct intel_crtc *crtc,
+struct intel_crtc_config *pipe_config);
+ extern int intel_dotclock_calculate(int link_freq,
+   const struct intel_link_m_n *m_n);
+ extern void ironlake_check_encoder_dotclock(const struct intel_crtc_config 
*pipe_config,
+   int dotclock);
+ 
+ extern bool intel_crtc_active(struct drm_crtc *crtc);
  
  #endif /* __INTEL_DRV_H__ */


pgpdRyjVZ6JZs.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit 7dc19d5affd7 ("drivers:
convert shrinkers to new count/scan API") from the  tree and commit
e656a6cba0fe ("drm/i915: inline vma_create into lookup_or_create_vma")
from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem.c
index df9253d,d00d24f..000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -4886,61 -4912,3 +4940,37 @@@ unsigned long i915_gem_obj_size(struct 
  
return 0;
  }
 +
 +static unsigned long
 +i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc)
 +{
 +  struct drm_i915_private *dev_priv =
 +  container_of(shrinker,
 +   struct drm_i915_private,
 +   mm.inactive_shrinker);
 +  struct drm_device *dev = dev_priv->dev;
 +  int nr_to_scan = sc->nr_to_scan;
 +  unsigned long freed;
 +  bool unlock = true;
 +
 +  if (!mutex_trylock(&dev->struct_mutex)) {
 +  if (!mutex_is_locked_by(&dev->struct_mutex, current))
 +  return 0;
 +
 +  if (dev_priv->mm.shrinker_no_lock_stealing)
 +  return 0;
 +
 +  unlock = false;
 +  }
 +
 +  freed = i915_gem_purge(dev_priv, nr_to_scan);
 +  if (freed < nr_to_scan)
 +  freed += __i915_gem_shrink(dev_priv, nr_to_scan,
 +  false);
 +  if (freed < nr_to_scan)
 +  freed += i915_gem_shrink_all(dev_priv);
 +
 +  if (unlock)
 +  mutex_unlock(&dev->struct_mutex);
 +  return freed;
 +}
- 
- struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
-struct i915_address_space *vm)
- {
-   struct i915_vma *vma;
-   list_for_each_entry(vma, &obj->vma_list, vma_link)
-   if (vma->vm == vm)
-   return vma;
- 
-   return NULL;
- }
- 
- struct i915_vma *
- i915_gem_obj_lookup_or_create_vma(struct drm_i915_gem_object *obj,
- struct i915_address_space *vm)
- {
-   struct i915_vma *vma;
- 
-   vma = i915_gem_obj_to_vma(obj, vm);
-   if (!vma)
-   vma = i915_gem_vma_create(obj, vm);
- 
-   return vma;
- }


pgp_b6b4IwnK8.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

--- Comment #9 from Nicholas Miell  ---
(In reply to comment #7)
>Trine 2 uses those old assembly-like shaders for some reason

It's the minimum spec target profile for Nvidia's Cg compiler.

> This cannot work
> as shadow sampling is only defined for depth textures. According to the
> ARB_fragment_program_shadow specification (Trine 2 uses those old
> assembly-like shaders for some reason), it is undefined behaviour to sample
> from non-depth textures.

ARB_fragment_program_shadow may leave it undefined, but the GL spec says the
texture unit operates in the normal manner and texture comparison is bypassed
if the currently bound texture's base internal format is not DEPTH_COMPONENT or
DEPTH_STENCIL.

-- 
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] drm/msm: Odd PTR_ERR usage

[Rob Clark]

On Mon, Sep 16, 2013 at 5:19 PM, Thomas Meyer  wrote:
> The variable priv->kms is not initialized yet.
>
> Found by "scripts/coccinelle/tests/odd_ptr_err.cocci".
> PTR_ERR should access the value just tested by IS_ERR.
>
> Signed-off-by: Thomas Meyer 

thanks, I've got it queued up

BR,
-R

> ---
>
> diff -u -p a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -199,7 +199,7 @@ static int msm_load(struct drm_device *d
>  * imx drm driver on iMX5
>  */
> dev_err(dev->dev, "failed to load kms\n");
> -   ret = PTR_ERR(priv->kms);
> +   ret = PTR_ERR(kms);
> goto fail;
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

--- Comment #8 from Grigori Goronzy  ---
Created attachment 86032
  --> https://bugs.freedesktop.org/attachment.cgi?id=86032&action=edit
Hack to force SAMPLE instruction even for 2D shadow samplers

-- 
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 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

--- Comment #7 from Grigori Goronzy  ---
This actually seems to be a bug in Trine 2. The fragment shader uses a shadow
sampler to sample the normal texture, which is RGBA. This cannot work as shadow
sampling is only defined for depth textures. According to the
ARB_fragment_program_shadow specification (Trine 2 uses those old assembly-like
shaders for some reason), it is undefined behaviour to sample from non-depth
textures. Obviously, Trine 2 relies on a certain behavior, i.e. that shadow
samplers are silently changed into normal 2D samplers when not sampling from
depth textures.

I have contacted Frozenbyte support, let's see if they'll do something about.
Otherwise we need to check if it is reasonably possible and sensible to
implement these undefined cases like other drivers. This might get ugly,
though.

If you just want to play the game and don't mind hacking mesa, try the nasty
patch I attached. This will break other applications, but makes Trine 2 work.

-- 
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 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

[bugzilla-daemon]

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

--- Comment #37 from Jose P.  ---
Created attachment 86031
  --> https://bugs.freedesktop.org/attachment.cgi?id=86031&action=edit
dmesg, xorg

I installed 3.12-rc1 from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc1-saucy/ , it didn't help
:(
Attached are the logs from dmesg (before and after running pm-suspend) and
Xorg.0.log (there were no messages after resuming from suspend)

-- 
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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

[bugzilla-daemon]

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

--- Comment #32 from Alexandre Demers  ---
(In reply to comment #31)
> Created attachment 85989 [details] [review]
> testing patch
> 
> Try this patch independent from any other patches.  It forces the engine and
> memory clocks of all performance levels within a power state to the lowest
> level.  If it works, then try and comment out either the sclk part or the
> mclk part and see if either helps.  That should help us narrow down whether
> it's a mclk problem or an sclk problem.

Running with the patch works fine over a vanilla kernel 3.12-rc1. The following
works also fine:
//if (pl->sclk > 25000)
//pl->sclk = 25000;
if (pl->mclk > 15000)
pl->mclk = 15000;
Which means sclk is working properly.

However, the opposite results in a blank screen before I can even get at the
login screen. It seems mclk is the problematic part.

-- 
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 64600] r600g pyrit OpenCL issue on HD6850

[bugzilla-daemon]

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

--- Comment #7 from darkbasic  ---
Created attachment 86011
  --> https://bugs.freedesktop.org/attachment.cgi?id=86011&action=edit
pyrit debug

Here it is, thanks.

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #49 from Tom Stellard  ---
Created attachment 86004
  --> https://bugs.freedesktop.org/attachment.cgi?id=86004&action=edit
Possible Fix #2

Can you try this patch, and if it doesn't work post the output with
R600_DEBUG=cs

-- 
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 64600] r600g pyrit OpenCL issue on HD6850

[bugzilla-daemon]

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

--- Comment #9 from darkbasic  ---
Created attachment 86014
  --> https://bugs.freedesktop.org/attachment.cgi?id=86014&action=edit
pyrit debug 10 minutes

I let it run for 10 minutes and still no compute shaders.

-- 
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 69321] starting openCL crashes/boots system

[bugzilla-daemon]

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

--- Comment #6 from udo  ---
FWIW: https://bugs.freedesktop.org/attachment.cgi?id=85794 fixes the problem

-- 
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: BUG: sleeping function called from invalid context on 3.10.10-rt7

[Daniel Vetter]

On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley  wrote:
> On 09/11/2013 03:31 PM, Peter Hurley wrote:
>>
>> [+cc dri-devel]
>>
>> On 09/11/2013 11:38 AM, Steven Rostedt wrote:
>>>
>>> On Wed, 11 Sep 2013 11:16:43 -0400
>>> Peter Hurley  wrote:
>>>
> The funny part is, there's a comment there that shows that this was
> done even for "PREEMPT_RT". Unfortunately, the call to
> "get_scanout_position()" can call functions that use the rt-mutex
> "sleeping spin locks" and it breaks there.
>
> I guess we need to ask the authors of the mainline patch exactly why
> that preempt_disable() is needed?


 The drm core associates a timestamp with each vertical blank frame #.
 Drm drivers can optionally support a 'high resolution' hw timestamp.
 The vblank frame #/timestamp tuple is user-space visible.

 The i915 drm driver supports a hw timestamp via this drm helper function
 which computes the timestamp from the crtc scan position (based on the
 pixel clock).

 For mainline, the preempt_disable/_enable() isn't actually necessary
 because every call tree that leads here already has preemption disabled.

 For -RT, the maybe i915 register spinlock (uncore.lock) should be raw?

>>>
>>> No, it should not. Note, any other lock that can be held when it is
>>> held would also need to be raw.
>>
>>
>> By that, you mean "any other lock" that might be claimed "would also need
>> to be raw"?  Hopefully not "any other lock" already held?
>>
>>> And by taking a quick audit of the code, I see this:
>>>
>>> spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
>>>
>>> /* Reset the chip */
>>>
>>> /* GEN6_GDRST is not in the gt power well, no need to check
>>>  * for fifo space for the write or forcewake the chip for
>>>  * the read
>>>  */
>>> __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL);
>>>
>>> /* Spin waiting for the device to ack the reset request */
>>> ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) &
>>> GEN6_GRDOM_FULL) == 0, 500);
>>>
>>> That spin is unacceptable in RT with preemption and interrupts disabled.
>>
>>
>> Yep. That would be bad.
>>
>> AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included
>> in the force-wake set, so raw reads of the registers would
>> probably be acceptable (thus obviating the need for claiming the
>> uncore.lock).
>>
>> Except that _ALL_ register access is disabled with the uncore.lock
>> during a gpu reset. Not sure if that's meant to include crtc registers
>> or not, or what other synchronization/serialization issues are being
>> handled/hidden by forcing all register accesses to wait during a gpu
>> reset.
>>
>> Hopefully an i915 expert can weigh in here?
>
>
>
> Daniel,
>
> Can you shed some light on whether the i915+ crtc registers (specifically
> those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter())
> read as part of the vblank counter/timestamp handling need to
> be prevented during gpu reset?

The depency here in the locking is a recent addition:

commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a
Author: Chris Wilson 
Date:   Fri Jul 19 20:36:51 2013 +0100

drm/i915: Serialize almost all register access

It's a (slightly) oversized hammer to work around a hardware issue -
we could break it down to register blocks, which can be accessed
concurrently, but that tends to be more fragile. But the chip really
dies if you access (even just reads) the same block concurrently :(

We could try break the spinlock protected section a bit in the reset
handler - register access on a hung gpu tends to be ill-defined
anyway.

> The implied wait with preemption and interrupts disabled is causing grief
> in -RT, but also a 4ms wait inside an irq handler seems like a bad idea.

Oops, the magic code in wait_for which is just there to make the imo
totally misguided kgdb support work papered over the aweful long wait
in atomic context ever since we've added this in

commit b6e45f866465f42b53d803b0c574da0fc508a0e9
Author: Keith Packard 
Date:   Fri Jan 6 11:34:04 2012 -0800

drm/i915: Move reset forcewake processing to gen6_do_reset

Reverting this change should be enough (code moved obviously a bit).

Cheers, Daniel

>
> Regards,
> Peter Hurley
>
>
>
>>> What's the real issue here?
>>
>>
>> That the vblank timestamp needs to be an accurate measurement of a
>> realtime event. Sleeping/servicing interrupts while reading
>> the registers necessary to compute the timestamp would be bad too.
>>
>> (edit: which hopefully Mario Kleiner clarified in his reply)
>>
>> My point earlier was three-fold:
>> 1. Don't need the preempt_disable() for mainline: all callers are already
>> holding interrupt-disabling spinlocks.
>> 2. -RT still needs to prevent scheduling there.
>> 3. the problem is i915-specific.
>>
>> [update: the radeon driver should also BUG like the i915 driver but
>> probably
>> should have mmio_idx_lock spinlock as raw]

Re: BUG: sleeping function called from invalid context on 3.10.10-rt7

[Peter Hurley]

On 09/11/2013 03:31 PM, Peter Hurley wrote:

[+cc dri-devel]

On 09/11/2013 11:38 AM, Steven Rostedt wrote:

On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley  wrote:


The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
"get_scanout_position()" can call functions that use the rt-mutex
"sleeping spin locks" and it breaks there.

I guess we need to ask the authors of the mainline patch exactly why
that preempt_disable() is needed?


The drm core associates a timestamp with each vertical blank frame #.
Drm drivers can optionally support a 'high resolution' hw timestamp.
The vblank frame #/timestamp tuple is user-space visible.

The i915 drm driver supports a hw timestamp via this drm helper function
which computes the timestamp from the crtc scan position (based on the
pixel clock).

For mainline, the preempt_disable/_enable() isn't actually necessary
because every call tree that leads here already has preemption disabled.

For -RT, the maybe i915 register spinlock (uncore.lock) should be raw?



No, it should not. Note, any other lock that can be held when it is
held would also need to be raw.


By that, you mean "any other lock" that might be claimed "would also need
to be raw"?  Hopefully not "any other lock" already held?


And by taking a quick audit of the code, I see this:

spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);

/* Reset the chip */

/* GEN6_GDRST is not in the gt power well, no need to check
 * for fifo space for the write or forcewake the chip for
 * the read
 */
__raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL);

/* Spin waiting for the device to ack the reset request */
ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & GEN6_GRDOM_FULL) 
== 0, 500);

That spin is unacceptable in RT with preemption and interrupts disabled.


Yep. That would be bad.

AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included
in the force-wake set, so raw reads of the registers would
probably be acceptable (thus obviating the need for claiming the uncore.lock).

Except that _ALL_ register access is disabled with the uncore.lock
during a gpu reset. Not sure if that's meant to include crtc registers
or not, or what other synchronization/serialization issues are being
handled/hidden by forcing all register accesses to wait during a gpu reset.

Hopefully an i915 expert can weigh in here?



Daniel,

Can you shed some light on whether the i915+ crtc registers (specifically
those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter())
read as part of the vblank counter/timestamp handling need to
be prevented during gpu reset?

The implied wait with preemption and interrupts disabled is causing grief
in -RT, but also a 4ms wait inside an irq handler seems like a bad idea.

Regards,
Peter Hurley



What's the real issue here?


That the vblank timestamp needs to be an accurate measurement of a
realtime event. Sleeping/servicing interrupts while reading
the registers necessary to compute the timestamp would be bad too.

(edit: which hopefully Mario Kleiner clarified in his reply)

My point earlier was three-fold:
1. Don't need the preempt_disable() for mainline: all callers are already
holding interrupt-disabling spinlocks.
2. -RT still needs to prevent scheduling there.
3. the problem is i915-specific.

[update: the radeon driver should also BUG like the i915 driver but probably
should have mmio_idx_lock spinlock as raw]



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

[Bug 69497] New: X1950XTX performance issue

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 69497
  Assignee: dri-devel@lists.freedesktop.org
   Summary: X1950XTX performance issue
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: darkba...@linuxsystems.it
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

I don't care much because I don't use this card anymore, but since I did some
benchmarks I will report it because I know there are still a lot of peoples who
use R300g.

http://openbenchmarking.org/result/1309172-SO-X1950XTX238

I got 37 fps in openarena with the X1950XTX, while it should be at least 70+
(http://www.phoronix.com/scan.php?page=article&item=amd_r300g_mesa92&num=2)

Kernel 3.12
System logs: http://openbenchmarking.org/system/1309172-SO-X1950XTX238/x1950xtx

-- 
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 64600] r600g pyrit OpenCL issue on HD6850

[bugzilla-daemon]

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

--- Comment #4 from Tom Stellard  ---
Created attachment 86005
  --> https://bugs.freedesktop.org/attachment.cgi?id=86005&action=edit
Possible Fix

Can you try this patch, and if it doesn't work post the output of
R600_DEBUG=cs.

-- 
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 67982] After boot, the APU is powered with its maximum voltage (trinity/ARUBA)

[bugzilla-daemon]

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

--- Comment #4 from Kertesz Laszlo  ---
I use the mainline linux kernel (now 3.12 rc1+) merged with your drm-fixes-3.12
already.
This behavior is there and seemingly unchanged since i tried dpm with the
kernel 3.11 when was in rc stage.

Here is what i get from sensors and the debugfs radeon info:

radeon-pci-0008
Adapter: PCI adapter
temp1: +0.0°C  (crit = +120.0°C, hyst = +90.0°C)

it8728-isa-0228
Adapter: ISA adapter
in0:  +0.90 V  (min =  +0.00 V, max =  +3.06 V)
in1:  +1.64 V  (min =  +0.00 V, max =  +3.06 V)
in2:  +2.03 V  (min =  +0.00 V, max =  +3.06 V)
in3:  +2.04 V  (min =  +0.00 V, max =  +3.06 V)
in4:  +2.02 V  (min =  +0.00 V, max =  +3.06 V)
in5:  +2.22 V  (min =  +0.00 V, max =  +3.06 V)
in6:  +2.22 V  (min =  +0.00 V, max =  +3.06 V)
3VSB: +3.36 V  (min =  +0.00 V, max =  +6.12 V)
Vbat: +3.31 V
fan1:1573 RPM  (min =0 RPM)
fan2:1046 RPM  (min =0 RPM)
fan3:   0 RPM  (min =0 RPM)
fan4:   0 RPM  (min =0 RPM)
fan5:   0 RPM  (min =0 RPM)
temp1:+31.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2: -8.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:+14.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = Intel PECI
intrusion0:  OK

Radeon HD 7560D clocks:
uvdvclk: 0 dclk: 0
power level 0sclk: 30400 vddc: 912

in0 is the CPU voltage - 0.9-1.44 volts, 1.44 is reached only in the erroneous
state sometimes, normal operations are between 0.9-1.36v. Troubling is this
initial high state because if you dont notice it youll get consitently high
temperatures because of the driver.
BTW when the dynamic voltage works, i have pretty much the same temperature as
with fglrx.

I wonder how vddc works - is it a totally separate voltage controlled
separately by the radeon driver? I have seen it 1.1 v or something when in0 was
0.9 (vdpau playback for example).
Or in0 and vddc are the same thing, and its control is somehow shared between
the acpi-cpufreq and radeon drivers?

-- 
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: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

17.09.2013, в 18:24, Alex Deucher  написал(а):

> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov  wrote:
>> Alex,
>> 
>> 10.09.2013, в 16:37, Alex Deucher  написал(а):
>> 
>>> The dummy page isn't really going to help much.  That page is just
>>> used as a safety placeholder for gart entries that aren't mapped on
>>> the GPU.  TTM (drivers/gpu/drm/ttm) actually does the allocation of
>>> the backing pages for the gart.
>> 
>>> You may want to look there.
>> 
>> Ah, sorry. Indeed. Though, my idea with:
>> 
>> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov  wrote:
>> 
>>> Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
>>> dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
>> 
>> doesn't make a sense at TTM part as well.
> 
> After the driver is loaded, you can dump some info from debugfs:
> r100_rbbm_info
> r100_cp_ring_info
> r100_cp_csq_fifo
> Which will dump a bunch of registers and internal fifos so we can see
> that the chip actually processed.
> 
> Alex

Reading of r100_cp_ring_info leads to a KP:

r100_debugfs_cp_ring_info():
count = (rdp + ring->ring_size - wdp) & ring->ptr_mask;
i = (rdp + j) & ring->ptr_mask;

for (j = 0; j <= count; j++) {
i = (rdp + j) & ring->ptr_mask;
--> Here at first iteration <--
--> count = 262080, i = 0 <--
seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
}

Reading of radeon_ring_gfx (which i've additionally tried to read) 
throws an MCE:

radeon_debugfs_ring_info():
count = (ring->ring_size / 4) - ring->ring_free_dw;
i = (ring->rptr + ring->ptr_mask + 1 - 32) & ring->ptr_mask;

for (j = 0; j <= (count + 32); j++) {
--> Here at first iteration <--
--> i = 262112, j = 0 <--
seq_printf(m, "r[%5d]=0x%08x\n", i, ring->ring[i]);
i = (i + 1) & ring->ptr_mask;
}

I'm attaching debug outputs on kernel built with these loops commented.


drm_parisc_debug.tgz
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67982] After boot, the APU is powered with its maximum voltage (trinity/ARUBA)

[bugzilla-daemon]

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

--- Comment #2 from Kertesz Laszlo  ---
I have further information on this.
It seems that before the X server is started, the CPU voltage is correctly
regulated - it's at 0.9 v, when not doing anything, which is the correct
behavior.

But after x starts, the voltage jumps to 1.34 or 1.44 and stays there until i
dpms off/on the monitor. It seems that vt switching doesnt always help here.

If it works correctly and restart just the x server, it will go up again to
1.34, as the first time and i have to do the dpms off/on thing to bring it back
to work.

Also it seems that this voltage increase kicks in only after i logged in and
the desktop (xfce) is loaded - at the lightdm login screen i still have 0.9v.

-- 
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 64600] r600g pyrit OpenCL issue on HD6850

[bugzilla-daemon]

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

--- Comment #8 from Tom Stellard  ---
(In reply to comment #7)
> Created attachment 86011 [details]
> pyrit debug
> 
> Here it is, thanks.

There are no compute shaders in this output.  You should let the program run
longer, if possible, to give it time to dump all the output.

-- 
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 67107] Xorg starts and crashes with DPM enable

[bugzilla-daemon]

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

Christopher Chmielewski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Christopher Chmielewski  ---
Thanks that patch did the trick!

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #51 from darkbasic  ---
Created attachment 86012
  --> https://bugs.freedesktop.org/attachment.cgi?id=86012&action=edit
bfgminer debug

Here is the stderr output of RADEON_DUMP_SHADERS=1 bfgminer --scrypt -o
stratum+tcp://stratum2.wemineltc.com:3334 -u user.1 -p password -v1

Thanks

-- 
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 67982] After boot, the APU is powered with its maximum voltage (trinity/ARUBA)

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
You might try again with the bapm fixes in my drm-fixes tree:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.12

-- 
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 64600] r600g pyrit OpenCL issue on HD6850

[bugzilla-daemon]

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

--- Comment #5 from darkbasic  ---
It hangs at calibrating now:

~ $ R600_DEBUG=cs pyrit benchmark
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Calibrating... ^CTerminato

Where should I find the output of R600_DEBUG=cs? There is nothing even in
dmesg.

-- 
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 64600] r600g pyrit OpenCL issue on HD6850

[bugzilla-daemon]

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

--- Comment #6 from Tom Stellard  ---
(In reply to comment #5)
> It hangs at calibrating now:
> 
> ~ $ R600_DEBUG=cs pyrit benchmark
> Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
> This code is distributed under the GNU General Public License v3+
> 
> Calibrating... ^CTerminato
> 
> Where should I find the output of R600_DEBUG=cs? There is nothing even in
> dmesg.

This bug was filed against Evergreen/NI GPUs.  If you are using SI, you will
need to use RADEON_DUMP_SHADERS=1

Otherwise, R600_DEBUG=cs will print output to stderr.

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #50 from darkbasic  ---
It doesn't work, but at least now it hangs at:

R600_DEBUG=cs bfgminer --scrypt -o stratum+tcp://stratum2.wemineltc.com:3334 -u
user.1 -p password -I 13 -v1

 [2013-09-17 21:03:59] Started bfgminer 3.2.0
 [2013-09-17 21:03:59] Started bfgminer 3.2.0
 [2013-09-17 21:03:59] Probing for an alive pool
 [2013-09-17 21:04:00] Network difficulty changed to 1.03k ( 7.39Gh/s)
 [2013-09-17 21:04:00] Stratum from pool 0 detected new block
 [2013-09-17 21:04:00] Pool 0 is hiding block contents from us
 [2013-09-17 21:04:24] Killing OCL 0Errore di segmentazione

and as soon as I press CTRL+C I get a segfault in dmesg:
[ 1275.112334] bfgminer[6407]: segfault at 2d0 ip 7f6a3d18ef01 sp
7fffc765cc10 error 4 in libpthread-2.15.so[7f6a3d185000+17000]

I don't know where to find the output of R600_DEBUG=cs, sorry.

-- 
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 69463] RadeonSI : xserver crashes with Segmentation Fault

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
(In reply to comment #2)
> 3: /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (XGetXCBConnection+0x7)
> [0x7f4c1c70d6c7]
> 4: /home/atitest/install/lib/libEGL.so.1 (0x7f4c1cd51000+0x14441)
> [0x7f4c1cd65441]

Looks like it's trying to use the X11 EGL backend, which can't work in the X
server. Was 'drm' included in the --with-egl-platforms= parameter to Mesa's
configure?

-- 
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 1/3] backlight: introduce backlight_device_registered

[Aaron Lu]

Introduce a new API for modules to query if a specific type of backlight
device has been registered. This is useful for some backlight device
provider module(e.g. ACPI video) to know if a native control
interface(e.g. the interface created by i915) is available and then do
things accordingly(e.g. avoid register its own on Win8 systems).

Signed-off-by: Aaron Lu 
---
 drivers/video/backlight/backlight.c | 31 +++
 include/linux/backlight.h   |  4 
 2 files changed, 35 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 94a403a..bf2d71d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -21,6 +21,9 @@
 #include 
 #endif
 
+static struct list_head bd_list_head;
+static struct mutex bd_list_mutex;
+
 static const char *const backlight_types[] = {
[BACKLIGHT_RAW] = "raw",
[BACKLIGHT_PLATFORM] = "platform",
@@ -349,10 +352,32 @@ struct backlight_device *backlight_device_register(const 
char *name,
mutex_unlock(&pmac_backlight_mutex);
 #endif
 
+   mutex_lock(&bd_list_mutex);
+   list_add(&new_bd->entry, &bd_list_head);
+   mutex_unlock(&bd_list_mutex);
+
return new_bd;
 }
 EXPORT_SYMBOL(backlight_device_register);
 
+bool backlight_device_registered(enum backlight_type type)
+{
+   bool found = false;
+   struct backlight_device *bd;
+
+   mutex_lock(&bd_list_mutex);
+   list_for_each_entry(bd, &bd_list_head, entry) {
+   if (bd->props.type == type) {
+   found = true;
+   break;
+   }
+   }
+   mutex_unlock(&bd_list_mutex);
+
+   return found;
+}
+EXPORT_SYMBOL(backlight_device_registered);
+
 /**
  * backlight_device_unregister - unregisters a backlight device object.
  * @bd: the backlight device object to be unregistered and freed.
@@ -364,6 +389,10 @@ void backlight_device_unregister(struct backlight_device 
*bd)
if (!bd)
return;
 
+   mutex_lock(&bd_list_mutex);
+   list_del(&bd->entry);
+   mutex_unlock(&bd_list_mutex);
+
 #ifdef CONFIG_PMAC_BACKLIGHT
mutex_lock(&pmac_backlight_mutex);
if (pmac_backlight == bd)
@@ -499,6 +528,8 @@ static int __init backlight_class_init(void)
 
backlight_class->dev_groups = bl_device_groups;
backlight_class->pm = &backlight_class_dev_pm_ops;
+   INIT_LIST_HEAD(&bd_list_head);
+   mutex_init(&bd_list_mutex);
return 0;
 }
 
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..5f9cd96 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -100,6 +100,9 @@ struct backlight_device {
/* The framebuffer notifier block */
struct notifier_block fb_notif;
 
+   /* list entry of all registered backlight devices */
+   struct list_head entry;
+
struct device dev;
 };
 
@@ -123,6 +126,7 @@ extern void devm_backlight_device_unregister(struct device 
*dev,
struct backlight_device *bd);
 extern void backlight_force_update(struct backlight_device *bd,
   enum backlight_update_reason reason);
+extern bool backlight_device_registered(enum backlight_type type);
 
 #define to_backlight_device(obj) container_of(obj, struct backlight_device, 
dev)
 
-- 
1.8.4.12.g2ea3df6

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

Re: [PATCH v2 1/3] backlight: introduce backlight_device_registered

[Igor Gnatenko]

On Tue, 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> Introduce a new API for modules to query if a specific type of backlight
> device has been registered. This is useful for some backlight device
> provider module(e.g. ACPI video) to know if a native control
> interface(e.g. the interface created by i915) is available and then do
> things accordingly(e.g. avoid register its own on Win8 systems).
> 
> Signed-off-by: Aaron Lu 
Tested-by: Igor Gnatenko 
> ---
>  drivers/video/backlight/backlight.c | 31 +++
>  include/linux/backlight.h   |  4 
>  2 files changed, 35 insertions(+)

-- 
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.12.0-0.rc1.git0.1.fc20.x86_64

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

[PATCH v2 0/3] Fix Win8 backlight issue

[Aaron Lu]

v1 has the subject of "Rework ACPI video driver" and is posted here:
http://lkml.org/lkml/2013/9/9/74
Since the objective is really to fix Win8 backlight issues, I changed
the subject in this version, sorry about that.

This patchset has three patches, the first introduced a new API named
backlight_device_registered in backlight layer that can be used for
backlight interface provider module to check if a specific type backlight
interface has been registered, see changelog for patch 1/3 for details.
Then patch 2/3 does the cleanup to sepeate the backlight control and
event delivery functionality in the ACPI video module and patch 3/3
solves some Win8 backlight control problems by avoiding register ACPI
video's backlight interface if:
1 Kernel cmdline option acpi_backlight=video is not given;
2 This is a Win8 system;
3 Native backlight control interface exists.

Technically, patch 2/3 is not required to fix the issue here. So if you
think it is not necessary, I can remove it from the series.

Apply on top of v3.12-rc1.

Aaron Lu (3):
  backlight: introduce backlight_device_registered
  ACPI / video: seperate backlight control and event interface
  ACPI / video: Do not register backlight if win8 and native interface
exists

 drivers/acpi/internal.h |   5 +-
 drivers/acpi/video.c| 442 
 drivers/acpi/video_detect.c |  14 +-
 drivers/video/backlight/backlight.c |  31 +++
 include/acpi/video.h|   2 +
 include/linux/backlight.h   |   4 +
 6 files changed, 300 insertions(+), 198 deletions(-)

-- 
1.8.4.12.g2ea3df6

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

[Bug 69328] Recoverable and unrecoverable lockups with opencl-example on trinity APU

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #12 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 69321 ***

-- 
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 69328] Recoverable and unrecoverable lockups with opencl-example on trinity APU

[bugzilla-daemon]

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

--- Comment #8 from slick...@gmx.com ---
> Do you the latest code from my opencl-example repo?  Older versions were 
> missing the rotl.cl file

Yes, that was it.  It passes all tests here now!

-- 
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 69328] Recoverable and unrecoverable lockups with opencl-example on trinity APU

[bugzilla-daemon]

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

--- Comment #11 from slick...@gmx.com ---
@Alex Deucher:

Reverting f0435ebb07d01a77ca0d98967a002898811a5206 also makes it work.

-- 
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 69321] starting openCL crashes/boots system

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||slick...@gmx.com

--- Comment #5 from Alex Deucher  ---
*** Bug 69328 has been marked as a duplicate of this bug. ***

-- 
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 2/3] ACPI / video: seperate backlight control and event interface

[Aaron Lu]

The backlight control and event delivery functionality provided by ACPI
video module is mixed together and registered all during video device
enumeration time. As a result, the two functionality are also removed
together on module unload time or by the acpi_video_unregister function.
The two functionalities are actually independent and one may be useful
while the other one may be broken, so it is desirable to seperate the
two functionalities such that it is clear and easy to disable one
functionality without affecting the other one.

APIs to selectively remove backlight control interface and/or event
delivery functionality can be easily added once needed.

Signed-off-by: Aaron Lu 
---
 drivers/acpi/video.c | 451 ++-
 include/acpi/video.h |   2 +
 2 files changed, 264 insertions(+), 189 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index aebcf63..5ad5a71 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -89,6 +89,8 @@ static bool use_bios_initial_backlight = 1;
 module_param(use_bios_initial_backlight, bool, 0644);
 
 static int register_count;
+static struct mutex video_list_lock;
+static struct list_head video_bus_head;
 static int acpi_video_bus_add(struct acpi_device *device);
 static int acpi_video_bus_remove(struct acpi_device *device);
 static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
@@ -157,6 +159,7 @@ struct acpi_video_bus {
struct acpi_video_bus_flags flags;
struct list_head video_device_list;
struct mutex device_list_lock;  /* protects video_device_list */
+   struct list_head entry;
struct input_dev *input;
char phys[32];  /* for input device */
struct notifier_block pm_nb;
@@ -884,79 +887,6 @@ static void acpi_video_device_find_cap(struct 
acpi_video_device *device)
 
if (acpi_has_method(device->dev->handle, "_DDC"))
device->cap._DDC = 1;
-
-   if (acpi_video_backlight_support()) {
-   struct backlight_properties props;
-   struct pci_dev *pdev;
-   acpi_handle acpi_parent;
-   struct device *parent = NULL;
-   int result;
-   static int count;
-   char *name;
-
-   result = acpi_video_init_brightness(device);
-   if (result)
-   return;
-   name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
-   if (!name)
-   return;
-   count++;
-
-   acpi_get_parent(device->dev->handle, &acpi_parent);
-
-   pdev = acpi_get_pci_dev(acpi_parent);
-   if (pdev) {
-   parent = &pdev->dev;
-   pci_dev_put(pdev);
-   }
-
-   memset(&props, 0, sizeof(struct backlight_properties));
-   props.type = BACKLIGHT_FIRMWARE;
-   props.max_brightness = device->brightness->count - 3;
-   device->backlight = backlight_device_register(name,
- parent,
- device,
- 
&acpi_backlight_ops,
- &props);
-   kfree(name);
-   if (IS_ERR(device->backlight))
-   return;
-
-   /*
-* Save current brightness level in case we have to restore it
-* before acpi_video_device_lcd_set_level() is called next time.
-*/
-   device->backlight->props.brightness =
-   acpi_video_get_brightness(device->backlight);
-
-   device->cooling_dev = thermal_cooling_device_register("LCD",
-   device->dev, &video_cooling_ops);
-   if (IS_ERR(device->cooling_dev)) {
-   /*
-* Set cooling_dev to NULL so we don't crash trying to
-* free it.
-* Also, why the hell we are returning early and
-* not attempt to register video output if cooling
-* device registration failed?
-* -- dtor
-*/
-   device->cooling_dev = NULL;
-   return;
-   }
-
-   dev_info(&device->dev->dev, "registered as cooling_device%d\n",
-device->cooling_dev->id);
-   result = sysfs_create_link(&device->dev->dev.kobj,
-   &device->cooling_dev->device.kobj,
-   "thermal_cooling");
-   if (result)
-   printk(KERN_ERR PREFIX "Create sysfs link\n");
-   result = sysfs_create_link(&device

[PATCH v2 3/3] ACPI / video: Do not register backlight if win8 and native interface exists

[Aaron Lu]

According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows 8 doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8.  The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".

So for Win8 systems, if there is native backlight control interface
registered by GPU driver, ACPI video will not register its own. For
users who prefer to keep ACPI video's backlight interface, the existing
kernel cmdline option acpi_backlight=video can be used.

This patch is an evolution from previous work done by Matthew Garrett,
Chun-Yi Lee, Seth Forshee and Rafael J. Wysocki.

Signed-off-by: Aaron Lu 
---
 drivers/acpi/internal.h |  5 ++---
 drivers/acpi/video.c| 27 +--
 drivers/acpi/video_detect.c | 14 --
 3 files changed, 19 insertions(+), 27 deletions(-)

diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 20f4233..453ae8d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
Video
   -- */
 #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
-bool acpi_video_backlight_quirks(void);
-#else
-static inline bool acpi_video_backlight_quirks(void) { return false; }
+bool acpi_osi_is_win8(void);
+bool acpi_video_verify_backlight_support(void);
 #endif
 
 #endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 5ad5a71..343db59 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device 
*device, int event)
unsigned long long level_current, level_next;
int result = -EINVAL;
 
-   /* no warning message if acpi_backlight=vendor is used */
-   if (!acpi_video_backlight_support())
+   /* no warning message if acpi_backlight=vendor or a quirk is used */
+   if (!acpi_video_verify_backlight_support())
return 0;
 
if (!device->brightness)
@@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus *video,
 static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
 {
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 1 : 0);
+ acpi_osi_is_win8() ? 1 : 0);
 }
 
 static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
 {
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 0 : 1);
+ acpi_osi_is_win8() ? 0 : 1);
 }
 
 static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
@@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level, void 
*context,
 
 static void acpi_video_dev_register_backlight(struct acpi_video_device *device)
 {
-   if (acpi_video_backlight_support()) {
+   if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
@@ -1677,23 +1677,6 @@ static int acpi_video_bus_unregister_backlight(struct 
acpi_video_bus *video)
return error;
 }
 
-int acpi_video_unregister_backlight(void)
-{
-   struct acpi_video_bus *video;
-   int error = 0;
-
-   mutex_lock(&video_list_lock);
-   list_for_each_entry(video, &video_bus_head, entry) {
-   error = acpi_video_bus_unregister_backlight(video);
-   if (error)
-   break;
-   }
-   mutex_unlock(&video_list_lock);
-
-   return error;
-}
-EXPORT_SYMBOL(acpi_video_unregister_backlight);
-
 static void acpi_video_dev_add_notify_handler(struct acpi_video_device *device)
 {
acpi_status status;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 940edbf..23d7d26 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
acpi_video_get_capabilities(NULL);
 }
 
-bool acpi_video_backlight_quirks(void)
+bool acpi_osi_is_win8(void)
 {
return acpi_gbl_osi_data >= ACPI_OSI_WIN_8;
 }
-EXPORT_SYMBOL(acpi_video_backlight_quirks);
+EXPORT_SYMBOL(acpi_osi_is_win8);
 
 /* Promote the vendor interface instead of the generic video module.
  * This function allow DMI blacklists to be implemented by externals
@@ -283,6 +284,15 @@ int acpi_video_backlight_support(void)
 }
 EXPORT_SYMBOL(acpi_video_backlight_support);
 
+bool acpi_video_verify_bac

Re: [PATCH v2 0/3] Fix Win8 backlight issue

[Igor Gnatenko]

On Tue, 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> v1 has the subject of "Rework ACPI video driver" and is posted here:
> http://lkml.org/lkml/2013/9/9/74
> Since the objective is really to fix Win8 backlight issues, I changed
> the subject in this version, sorry about that.
> 
> This patchset has three patches, the first introduced a new API named
> backlight_device_registered in backlight layer that can be used for
> backlight interface provider module to check if a specific type backlight
> interface has been registered, see changelog for patch 1/3 for details.
> Then patch 2/3 does the cleanup to sepeate the backlight control and
> event delivery functionality in the ACPI video module and patch 3/3
> solves some Win8 backlight control problems by avoiding register ACPI
> video's backlight interface if:
> 1 Kernel cmdline option acpi_backlight=video is not given;
> 2 This is a Win8 system;
> 3 Native backlight control interface exists.
> 
> Technically, patch 2/3 is not required to fix the issue here. So if you
> think it is not necessary, I can remove it from the series.
> 
> Apply on top of v3.12-rc1.
> 
> Aaron Lu (3):
>   backlight: introduce backlight_device_registered
>   ACPI / video: seperate backlight control and event interface
>   ACPI / video: Do not register backlight if win8 and native interface
> exists
> 
>  drivers/acpi/internal.h |   5 +-
>  drivers/acpi/video.c| 442 
> 
>  drivers/acpi/video_detect.c |  14 +-
>  drivers/video/backlight/backlight.c |  31 +++
>  include/acpi/video.h|   2 +
>  include/linux/backlight.h   |   4 +
>  6 files changed, 300 insertions(+), 198 deletions(-)
> 

Aaron, how about fix indicator on ThinkPads ?

-- 
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.1-300.fc20.x86_64

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

[3.12-rc1 regression] X fails to start on Latitude E6510 w/ NOUVEAU DRM driver

[Mikael Pettersson]

Dell Latitude E6510, CONFIG_DRM_NOUVEAU, 64-bit Fedora 17 user-space, Xorg 
drivers, and

01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev 
a2).

With 3.11 X starts fine, with 3.12-rc1 it fails with the following in 
Xorg.0.log:

...
[56.819] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
[56.842] (II) Module nouveau: vendor="X.Org Foundation"
[56.842]compiled for 1.12.2, module version = 0.0.16
[56.842]Module class: X.Org Video Driver
[56.842]ABI class: X.Org Video Driver, version 12.0
[56.842] (II) NOUVEAU driver 
[56.842] (II) NOUVEAU driver for NVIDIA chipset families :
[56.842]RIVA TNT(NV04)
[56.842]RIVA TNT2   (NV05)
[56.842]GeForce 256 (NV10)
[56.842]GeForce 2   (NV11, NV15)
[56.842]GeForce 4MX (NV17, NV18)
[56.842]GeForce 3   (NV20)
[56.842]GeForce 4Ti (NV25, NV28)
[56.842]GeForce FX  (NV3x)
[56.842]GeForce 6   (NV4x)
[56.842]GeForce 7   (G7x)
[56.842]GeForce 8   (G8x)
[56.842]GeForce GTX 200 (NVA0)
[56.842]GeForce GTX 400 (NVC0)
[56.842] (--) using VT number 7

[56.845] drmOpenDevice: node name is /dev/dri/card0
[56.845] drmOpenDevice: open result is 9, (OK)
[56.845] drmOpenByBusid: Searching for BusID pci::01:00.0
[56.845] drmOpenDevice: node name is /dev/dri/card0
[56.845] drmOpenDevice: open result is 9, (OK)
[56.845] drmOpenByBusid: drmOpenMinor returns 9
[56.845] drmOpenByBusid: drmGetBusid reports pci::01:00.0
[56.845] (EE) [drm] failed to open device
[56.845] (EE) No devices detected.

With 3.11 one instead sees:

...
[33.879] drmOpenByBusid: drmOpenMinor returns 9
[33.879] drmOpenByBusid: drmGetBusid reports pci::01:00.0
[33.879] (II) [drm] nouveau interface version: 1.1.1
[33.879] (II) Loading sub module "dri"
...

There are no messages in the kernel's log that indicate any problem.

stracing xinit shows:

964   open("/dev/dri/card0", O_RDWR)= 9
964   write(0, "[  1120.365] ", 13) = 13
964   write(0, "drmOpenDevice: open result is 9,"..., 38) = 38
964   write(0, "[  1120.365] ", 13) = 13
964   write(0, "drmOpenByBusid: drmOpenMinor ret"..., 39) = 39
964   ioctl(9, 0xc0106407, 0x7fffda0d4800) = 0
964   ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
964   ioctl(9, 0xc0106401, 0x7fffda0d4800) = 0
964   write(0, "[  1120.365] ", 13) = 13
964   write(0, "drmOpenByBusid: drmGetBusid repo"..., 53) = 53
964   ioctl(9, 0xc0086420, 0x7fffda0d4870) = -1 EINVAL (Invalid argument)
964   fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, 
st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, 
st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, 
st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
964   fstat(9, {st_dev=makedev(0, 5), st_ino=2348, st_mode=S_IFCHR|0660, 
st_nlink=1, st_uid=0, st_gid=39, st_blksize=4096, st_blocks=0, 
st_rdev=makedev(226, 0), st_atime=2013/09/17-11:25:35, 
st_mtime=2013/09/17-11:25:35, st_ctime=2013/09/17-11:43:58}) = 0
964   close(9)  = 0
964   write(0, "[  1120.366] ", 13) = 13
964   write(0, "(EE) [drm] failed to open device"..., 33) = 33

So it looke like that ioctl 0xc0086420 is the culprit.

Any ideas?  I may have time to try a bisection tomorrow.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] ACPI / video: Do not register backlight if win8 and native interface exists

[Igor Gnatenko]

On Tue, 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows 8 doesn't use the ACPI interface, including the fact that
> it's broken on a bunch of machines when the OS claims to support
> Windows 8.  The simplest thing to do appears to be to disable the
> ACPI backlight interface on these systems".
> 
> So for Win8 systems, if there is native backlight control interface
> registered by GPU driver, ACPI video will not register its own. For
> users who prefer to keep ACPI video's backlight interface, the existing
> kernel cmdline option acpi_backlight=video can be used.
> 
> This patch is an evolution from previous work done by Matthew Garrett,
> Chun-Yi Lee, Seth Forshee and Rafael J. Wysocki.
> 
> Signed-off-by: Aaron Lu 
Tested-by: Igor Gnatenko 
> ---
>  drivers/acpi/internal.h |  5 ++---
>  drivers/acpi/video.c| 27 +--
>  drivers/acpi/video_detect.c | 14 --
>  3 files changed, 19 insertions(+), 27 deletions(-)

-- 
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.12.0-0.rc1.git0.1.fc20.x86_64

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

Re: [PATCH v2 2/3] ACPI / video: seperate backlight control and event interface

[Igor Gnatenko]

On Tue, 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> The backlight control and event delivery functionality provided by ACPI
> video module is mixed together and registered all during video device
> enumeration time. As a result, the two functionality are also removed
> together on module unload time or by the acpi_video_unregister function.
> The two functionalities are actually independent and one may be useful
> while the other one may be broken, so it is desirable to seperate the
> two functionalities such that it is clear and easy to disable one
> functionality without affecting the other one.
> 
> APIs to selectively remove backlight control interface and/or event
> delivery functionality can be easily added once needed.
> 
> Signed-off-by: Aaron Lu 
Tested-by: Igor Gnatenko 
> ---
>  drivers/acpi/video.c | 451 
> ++-
>  include/acpi/video.h |   2 +
>  2 files changed, 264 insertions(+), 189 deletions(-)

-- 
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.12.0-0.rc1.git0.1.fc20.x86_64

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

[Bug 69328] Recoverable and unrecoverable lockups with opencl-example on trinity APU

[bugzilla-daemon]

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

--- Comment #10 from Alex Deucher  ---
git revert f0435ebb07d01a77ca0d98967a002898811a5206

-- 
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 69328] Recoverable and unrecoverable lockups with opencl-example on trinity APU

[bugzilla-daemon]

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

--- Comment #9 from slick...@gmx.com ---
@Alex Deucher:

I'm not that familiar with git, can you give me the command to do that,
starting with the checked out branch-master gentoo grabs to the build
directory?  It keeps .git there at least.

-- 
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 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)

[bugzilla-daemon]

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

--- Comment #17 from Stuart Foster  ---
removing the radeon.agpmode=-1 from the command line enabled the radeon dpm to
be initialized.

-- 
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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

[bugzilla-daemon]

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

--- Comment #31 from Alex Deucher  ---
Created attachment 85989
  --> https://bugs.freedesktop.org/attachment.cgi?id=85989&action=edit
testing patch

Try this patch independent from any other patches.  It forces the engine and
memory clocks of all performance levels within a power state to the lowest
level.  If it works, then try and comment out either the sclk part or the mclk
part and see if either helps.  That should help us narrow down whether it's a
mclk problem or an sclk problem.

-- 
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 05/12] drm/edid: Expose mandatory stereo modes for HDMI sinks

[Damien Lespiau]

On Mon, Sep 16, 2013 at 09:29:31PM +0300, Ville Syrjälä wrote:
> > +struct stereo_mandatory_mode {
> > +   int width, height, freq;

[..]

> > +   unsigned int interlace_flag, layouts;
> 
> What's the benefit of separating the two?

Just that we can easily cycle through the layout flags and add a mode
per flag without having to clear the interlace bit. Trade 16 bytes against 
one instruction or so, can do I guess.

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

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Deucher]

On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov  wrote:
> Alex,
>
> 10.09.2013, в 16:37, Alex Deucher  написал(а):
>
>> The dummy page isn't really going to help much.  That page is just
>> used as a safety placeholder for gart entries that aren't mapped on
>> the GPU.  TTM (drivers/gpu/drm/ttm) actually does the allocation of
>> the backing pages for the gart.
>
>> You may want to look there.
>
> Ah, sorry. Indeed. Though, my idea with:
>
> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov  wrote:
>
>> Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
>> dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
>
> doesn't make a sense at TTM part as well.

After the driver is loaded, you can dump some info from debugfs:
r100_rbbm_info
r100_cp_ring_info
r100_cp_csq_fifo
Which will dump a bunch of registers and internal fifos so we can see
that the chip actually processed.

Alex

>
> Konrad,
>
> 10.09.2013, 17:25, "Konrad Rzeszutek Wilk" :
>>
>> Is this platform enabling the SWIOTLB layer?
>
> Doesn't look like.
>
>> The reason I am asking is
>> b/c if you do indeed enable it you end up using the TTM DMA pool
>> which allocates pages using the dma_alloc_coherent - which means that
>> all of the pages that come out of TTM are already 'DMA' mapped.
>>
>> And that means the radeon_gart_bind and all its friends
>> use the DMA addresses that have been constructed by SWIOTLB IOMMU.
>>
>> Perhaps the PA-RISC IOMMU creates the DMA addresses differently?
>>
>> When the card gets programmed, you do end up using ttm_agp_bind right?
>> I am wondering if something like this:
>>
>> https://lkml.org/lkml/2010/12/6/512
>>
>> is needed to pass in the right DMA address?
>
> No idea how to modify ttm_agp_bind() this way, though doesn't matter if
> swiotlb isn't used anyway?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

[bugzilla-daemon]

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

--- Comment #30 from Alexandre Demers  ---
If there were any fixes pushed in kernel 3.12-rc1, none changed anything.

-- 
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 69328] Recoverable and unrecoverable lockups with opencl-example on trinity APU

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
I wonder if this may also be related to bug 69321.  Does reverting
f0435ebb07d01a77ca0d98967a002898811a5206 also help?

-- 
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: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Daniel Vetter]

On Tue, Sep 17, 2013 at 1:02 PM, Ville Syrjälä
 wrote:
>
> But the problem is that addfb2 can't supply more than 4. So we need a new
> ioctl if we want to collect all that information inside a single drm_fb
> object. If we do add another ioctl then I think we should go at least to
> 16, since we might also want to have separate buffers for each field in
> interlaced framebuffers. And then we need to clearly define which handle
> is which plane/field/eye. Something like this for example:


Blergh, I've thought we have gone with at least 6 buffers for the 3d
case. Meh :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Daniel Vetter]

On Tue, Sep 17, 2013 at 3:20 PM, Damien Lespiau
 wrote:
> On Tue, Sep 17, 2013 at 12:37:48PM +0200, Daniel Vetter wrote:
>> I guess we should start to check that. For 3d framebuffers with 2
>> separate buffer handles for each plane I think we need to add another flag
>> to addfb2, e.g.
>>
>> #define DRM_MODE_FB_3D_2_FRAMES (1<<1) /* separate left/right buffers, 
>> doubles plane count */
>>
>> and then also throw in the respective check code into the core that
>> userspace supplies sufficient amounts of buffers in framebuffer_check()
>> by adjusting drM_format_num_planes and drm_format_plane_cpp.
>
> Would we really need that flag? we can just count the number of buffers
> and decide from that number whether we're in the 1 or 2 buffer(s) case?

We do not know at addfb2 time that it'll be a 3d mode buffer, and
drivers might want to know that to internally assign the buffers to
left/right buffer handle pointers. Similar to how we already have a
flag for when the buffer is interlaced, which atm we don't support
(since we only support scan-out of progressive buffers to interlaced
modes, not interlaced to interlaced). So imo a flag here makes sense
so that the driver can properly check constraints and make sense of
the handles.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Ville Syrjälä]

On Tue, Sep 17, 2013 at 02:20:41PM +0100, Damien Lespiau wrote:
> On Tue, Sep 17, 2013 at 12:37:48PM +0200, Daniel Vetter wrote:
> > I guess we should start to check that. For 3d framebuffers with 2
> > separate buffer handles for each plane I think we need to add another flag
> > to addfb2, e.g.
> > 
> > #define DRM_MODE_FB_3D_2_FRAMES (1<<1) /* separate left/right buffers, 
> > doubles plane count */
> > 
> > and then also throw in the respective check code into the core that
> > userspace supplies sufficient amounts of buffers in framebuffer_check()
> > by adjusting drM_format_num_planes and drm_format_plane_cpp.
> 
> Would we really need that flag? we can just count the number of buffers
> and decide from that number whether we're in the 1 or 2 buffer(s) case?

I'd go with explicit flags. We have one for interlaced already. Although
ATM the interlaced flag must mean that the fields are interleaved in the
same buffer. But if we want separate buffers for each field, we need a
flag for that too. Or we just pretend the old interlace flag doesn't
exist yet and steal it for that purpose. I don't think anyone is using
the flag yet. But anyway we'd need a new ioctl :(

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Damien Lespiau]

On Tue, Sep 17, 2013 at 12:37:48PM +0200, Daniel Vetter wrote:
> I guess we should start to check that. For 3d framebuffers with 2
> separate buffer handles for each plane I think we need to add another flag
> to addfb2, e.g.
> 
> #define DRM_MODE_FB_3D_2_FRAMES (1<<1) /* separate left/right buffers, 
> doubles plane count */
> 
> and then also throw in the respective check code into the core that
> userspace supplies sufficient amounts of buffers in framebuffer_check()
> by adjusting drM_format_num_planes and drm_format_plane_cpp.

Would we really need that flag? we can just count the number of buffers
and decide from that number whether we're in the 1 or 2 buffer(s) case?

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

Re: about flashing firefox os on micromax a60 (amr6)

[Alex Deucher]

On Tue, Sep 17, 2013 at 1:18 AM, Prasad Mhatre  wrote:
> hello,
> I have micromax a60 and specs are as follows:-
> 
>
> original os was :android 2.1
> now currently os :android 2.2 frozen yogurt(flashed it)
>
> i want to flash firefox OS on it can you guide me to do so

You'll probably have better luck asking on a firefox mailing list.
This list mostly covers graphics drivers.

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

[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)

[bugzilla-daemon]

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

--- Comment #16 from Alex Deucher  ---
(In reply to Stuart Foster from comment #15)
> [drm] radeon: power management initialized
> 
> what do you think ?

dpm is not enabled.  You should see:

 [drm] radeon: dpm initialized

-- 
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 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.12 inclusive

[bugzilla-daemon]

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

--- Comment #16 from Alex Deucher  ---
Since this bug was opened before dpm was released, can you reproduce the
problems without dpm enabled?  If not, then these are two different issues.

-- 
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 69321] starting openCL crashes/boots system

[bugzilla-daemon]

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

--- Comment #4 from udo  ---
 mesa]# git bisect bad
f0435ebb07d01a77ca0d98967a002898811a5206 is the first bad commit
commit f0435ebb07d01a77ca0d98967a002898811a5206
Author: Tom Stellard 
Date:   Mon Aug 26 17:55:49 2013 -0700

r600g/compute: Don't flush the cs in pipe_context::launch_grid()

This is the state tracker's responsibility.

Reviewed-by: Marek Olšák 

:04 04 800ca408fbce3ab20ed2ee525775ccf4af8450da
bdad2d7895292c4d54838153e74f8eb1d1f4839b Msrc

-- 
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 69463] RadeonSI : xserver crashes with Segmentation Fault

[bugzilla-daemon]

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

--- Comment #1 from samit vats  ---
Created attachment 85971
  --> https://bugs.freedesktop.org/attachment.cgi?id=85971&action=edit
dmesg

-- 
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 69463] New: RadeonSI : xserver crashes with Segmentation Fault

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 69463
  Assignee: dri-devel@lists.freedesktop.org
   Summary: RadeonSI : xserver crashes with Segmentation Fault
  Severity: critical
Classification: Unclassified
OS: All
  Reporter: hysv...@gmail.com
  Hardware: Other
Status: NEW
   Version: 9.2
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 85970
  --> https://bugs.freedesktop.org/attachment.cgi?id=85970&action=edit
Xorg.log

Driver Stack Details:
=

1)Kernel-3.10.5-031005-generic
2)drm-2.4.46
3)Mesa-9.2   
4)Xorg-server-1.11.4
5)xf86-video-ati- master
6)glamor-0.5.1
7)LLVM-3.3

System Configuration:
=

Asic : Tahiti XT (ID-6798)
O.S. : Ubuntu-13.04 (64 bit)

X server crashes with Backtrace
===

0: /usr/bin/X (xorg_backtrace+0x28) [0x55f4f8]
1: /usr/bin/X (0x40+0x1631b9) [0x5631b9]
2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f4c1f21a000+0xfbd0)
[0x7f4c1f229bd0]
3: /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (XGetXCBConnection+0x7)
[0x7f4c1c70d6c7]
4: /home/atitest/install/lib/libEGL.so.1 (0x7f4c1cd51000+0x14441)
[0x7f4c1cd65441]
5: /home/atitest/install/lib/libEGL.so.1 (0x7f4c1cd51000+0xc7cb)
[0x7f4c1cd5d7cb]
6: /home/atitest/install/lib/libEGL.so.1 (0x7f4c1cd51000+0xcaf3)
[0x7f4c1cd5daf3]
7: /home/atitest/install/lib/libEGL.so.1 (eglInitialize+0xb2) [0x7f4c1cd58a62]
8: /home/atitest/install/lib/xorg/modules/libglamoregl.so
(glamor_egl_init+0xcf) [0x7f4c1cf70f7f]
9: /home/atitest/install/lib/xorg/modules/drivers/radeon_drv.so
(0x7f4c1a1f1000+0x4bce5) [0x7f4c1a23cce5]
10: /home/atitest/install/lib/xorg/modules/drivers/radeon_drv.so
(0x7f4c1a1f1000+0x45974) [0x7f4c1a236974]
11: /usr/bin/X (InitOutput+0x8ba) [0x4703ea]
12: /usr/bin/X (0x40+0x22f66) [0x422f66]
13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f4c1e290ea5]
14: /usr/bin/X (0x40+0x233dd) [0x4233dd]
Segmentation fault at address (nil)

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

-- 
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 2/2] dma-buf: Add user interfaces for dmabuf sync support

[Inki Dae]

This patch adds lock and poll callbacks to dma buf file operations,
and these callbacks will be called by fcntl and select system calls.

fcntl and select system calls can be used to wait for the completion
of DMA or CPU access to a shared dmabuf. The difference of them is
fcntl system call takes a lock after the completion but select system
call doesn't. So in case of fcntl system call, it's useful when a task
wants to access a shared dmabuf without any broken. On the other hand,
it's useful when a task wants to just wait for the completion.

Changelog v2:
- Add select system call support.
  . The purpose of this feature is to wait for the completion of DMA or
CPU access to a dmabuf without that caller locks the dmabuf again
after the completion.
That is useful when caller wants to be aware of the completion of
DMA access to the dmabuf, and the caller doesn't use intefaces for
the DMA device driver.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/base/dma-buf.c |   81 
 1 file changed, 81 insertions(+)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 3985751..73234ba 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static inline int is_dma_buf_file(struct file *);
@@ -106,10 +107,90 @@ static loff_t dma_buf_llseek(struct file *file, loff_t 
offset, int whence)
return base + offset;
 }
 
+static unsigned int dma_buf_poll(struct file *filp,
+   struct poll_table_struct *poll)
+{
+   struct dma_buf *dmabuf;
+   struct dmabuf_sync_reservation *robj;
+   int ret = 0;
+
+   if (!is_dma_buf_file(filp))
+   return POLLERR;
+
+   dmabuf = filp->private_data;
+   if (!dmabuf || !dmabuf->sync)
+   return POLLERR;
+
+   robj = dmabuf->sync;
+
+   mutex_lock(&robj->lock);
+
+   robj->polled = true;
+
+   /*
+* CPU or DMA access to this buffer has been completed, and
+* the blocked task has been waked up. Return poll event
+* so that the task can get out of select().
+*/
+   if (robj->poll_event) {
+   robj->poll_event = false;
+   mutex_unlock(&robj->lock);
+   return POLLIN | POLLOUT;
+   }
+
+   /*
+* There is no anyone accessing this buffer so just return.
+*/
+   if (!robj->locked) {
+   mutex_unlock(&robj->lock);
+   return POLLIN | POLLOUT;
+   }
+
+   poll_wait(filp, &robj->poll_wait, poll);
+
+   mutex_unlock(&robj->lock);
+
+   return ret;
+}
+
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+   struct dma_buf *dmabuf;
+   unsigned int type;
+   bool wait = false;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file->private_data;
+
+   if ((fl->fl_type & F_UNLCK) == F_UNLCK) {
+   dmabuf_sync_single_unlock(dmabuf);
+   return 0;
+   }
+
+   /* convert flock type to dmabuf sync type. */
+   if ((fl->fl_type & F_WRLCK) == F_WRLCK)
+   type = DMA_BUF_ACCESS_W;
+   else if ((fl->fl_type & F_RDLCK) == F_RDLCK)
+   type = DMA_BUF_ACCESS_R;
+   else
+   return -EINVAL;
+
+   if (fl->fl_flags & FL_SLEEP)
+   wait = true;
+
+   /* TODO. the locking to certain region should also be considered. */
+
+   return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
+   .poll   = dma_buf_poll,
+   .lock   = dma_buf_lock,
 };
 
 /*
-- 
1.7.9.5

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

[PATCH v9 0/2] Introduce buffer synchronization framework

[Inki Dae]

Hi all,

This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and is
rebased on linux-3.12-rc1

The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA but also
easy-to-use interfaces for device drivers and user application.
In addtion, this patch set suggests a way for enhancing performance.

Changelog v9:
- Delete only one sync object matched at DEL_OBJ_FROM_RSV macro.
- Fix memory leak issue at dmabuf_sync_single_lock()

Changelog v8:
Consider the write-and-then-read ordering pointed out by David Herrmann,
- The ordering issue means that a task don't take a lock to the dmabuf
  so this task would be stalled even though this task requested a lock to
  the dmabuf between other task unlocked and tries to lock the dmabuf
  again. For this, we have added a wait event mechanism using only generic
  APIs, wait_event_timeout and wake_up functions.

  The below is how to handle the ordering issue using this mechanism:
  1. Check if there is a sync object added prior to current task's one.
  2. If exists, it unlocks the dmabuf so that other task can take a lock
 to the dmabuf first.
  3. Wait for the wake up event from other task: current task will be
 waked up when other task unlocks the dmabuf.
  4. Take a lock to the dmabuf again.
- Code cleanups.

Changelog v7:
Fix things pointed out by Konrad Rzeszutek Wilk,
- Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
- Make sure to unlock and unreference all dmabuf objects
  when dmabuf_sync_fini() is called.
- Add more comments.
- Code cleanups.

Changelog v6:
- Fix sync lock to multiple reads.
- Add select system call support.
  . Wake up poll_wait when a dmabuf is unlocked.
- Remove unnecessary the use of mutex lock.
- Add private backend ops callbacks.
  . This ops has one callback for device drivers to clean up their
sync object resource when the sync object is freed. For this,
device drivers should implement the free callback properly.
- Update document file.

Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
  to hook up to ttm and dma-buf for easy sharing of reservations across
  devices. However, the dmabuf sync can be used for all dma devices; v4l2
  and drm based drivers, so doesn't need the reservation_object anymore.
  With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

For generic user mode interface, we have used fcntl and select system
call[3]. As you know, user application sees a buffer object as a dma-buf
file descriptor. So fcntl() call with the file descriptor means to lock
some buffer region being managed by the dma-buf object. And select() call
means to wait for the completion of CPU or DMA access to the dma-buf
without locking. For more detail, you can refer to the dma-buf-sync.txt
in Documentation/

There are some cases user-space process needs this buffer synchronization
framework. One of which is to primarily enhance GPU rendering performance
in case that 3D app draws somthing in a buffer using CPU, and other process
composes the buffer with its own backbuffer using GPU.

In case of 3D app, the app calls glFlush to submit 3d commands to GPU driver
instead of glFinish for more performance. The reason, we call glFlush, is
that glFinish blocks caller's task until the execution of the 3d commands is
completed. So that makes GPU and CPU more idle. As a result, 3d rendering
performance with glFinish is quite lower than glFlush.

However, the use of glFlush has one issue that the the buffer shared with
GPU could be broken when CPU accesses the buffer just after glFlush because
CPU cannot be aware of the completion of GPU access to the buffer.
Of course, the app can be aware of that time using eglWaitGL but this function
is valid only in case of the same context.

The below summarizes how app's window is displayed on Tizen[4] platform:
1. X client requests a window buffer to Xorg.
2. X client draws something in the window buffer using CPU.
3. X client requests SWAP to Xorg.
4. Xorg notifies a damage event to Composite Manager.
5. Composite Manager gets the window buffer (front buffer) through
   DRI2GetBuffers.
6. Composite Manager composes the window buffer and its own back buffer
   using GPU. At this time, eglSwapBuffers is called: internally, 3d
   commands are flushed to gpu driver.
7. Composite Manager requests SWAP to Xorg.
8. Xorg performs drm page flip. At this time, the window buffer is
   displayed on screen.

Web app based on HTML5 also has t

[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers

[bugzilla-daemon]

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

--- Comment #11 from Alexey  ---
Just check system monitor again - the same issue. So, no. It does not work
better:(

-- 
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 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers

[bugzilla-daemon]

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

--- Comment #10 from Alexey  ---
I've been built glamor and ati drivers from git.
Now I can use system monitor but g-c-c and firefox have the same issues.

-- 
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: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Ville Syrjälä]

On Tue, Sep 17, 2013 at 12:37:48PM +0200, Daniel Vetter wrote:
> On Tue, Sep 17, 2013 at 12:54:09PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 17, 2013 at 10:03:12AM +0100, Damien Lespiau wrote:
> > > On Tue, Sep 17, 2013 at 11:20:46AM +0300, Ville Syrjälä wrote:
> > >  > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > @@ -2131,6 +2131,17 @@ int drm_mode_setcrtc(struct drm_device *dev, 
> > > > > void *data,
> > > > >   goto out;
> > > > >   }
> > > > >  
> > > > > + /*
> > > > > +  * Do not allow the use of framebuffers consisting of 
> > > > > multiple
> > > > > +  * buffers with stereo modes until all the details API 
> > > > > details
> > > > > +  * are fleshed out (eg. interaction with drm_planes, 
> > > > > switch
> > > > > +  * between a 1 buffers and a 2 buffers fb, ...)
> > > > > +  */
> > > > > + if (fb->num_buffers > 1 && drm_mode_is_stereo(mode)) {
> > > > > + ret = -EINVAL;
> > > > > + goto out;
> > > > > + }
> > > > 
> > > > This would prevent planar buffers in stereo modes. I'm think we just
> > > > ignore the matter for now and let drivers deal with it. We don't have
> > > > enough handles anyway for planar stereo, so maybe we even want to add
> > > > separate left/right fb attachment properties to the planes instead of
> > > > tying it up in inside a single fb. Or we cook up addfb3 when we hit
> > > > this problem for real. I think we'd anyway need some kind of flag for
> > > > the fb if it contains both left and right buffers.
> > > 
> > > I'm quite happy to ignore 3 planes YUV stereo fbs for now :) (2 planes
> > > YUV stereo fbs still fit!).
> > > 
> > > Are you fine with this test though, or do you mean ignore the whole
> > > matter of forbidding this case (or just the multiplane stereo fb case)?
> > > I was just thinking that I missed the addition of this check in the page
> > > flip ioctl.
> > 
> > Yeah, I was thinking we that we can ignore this issue for now, and so we
> > wouldn't need the check. Currently for non-stereo cases the only thing
> > we check is that there is a valid handle for each plane. If userspace
> > passes more handles, we simply ignore the extra ones.
> 
> I guess we should start to check that. For 3d framebuffers with 2
> separate buffer handles for each plane I think we need to add another flag
> to addfb2, e.g.
> 
> #define DRM_MODE_FB_3D_2_FRAMES (1<<1) /* separate left/right buffers, 
> doubles plane count */
> 
> and then also throw in the respective check code into the core that
> userspace supplies sufficient amounts of buffers in framebuffer_check()
> by adjusting drM_format_num_planes and drm_format_plane_cpp.

Well, we shouldn't mix the plane vs. buffers/handles/whatever concepts. The
number of planes is clearly defined by the pixel format. But yes, we should
probably add a drm_format_num_buffers() function to figure out how many buffers
are required.

But the problem is that addfb2 can't supply more than 4. So we need a new
ioctl if we want to collect all that information inside a single drm_fb
object. If we do add another ioctl then I think we should go at least to
16, since we might also want to have separate buffers for each field in
interlaced framebuffers. And then we need to clearly define which handle
is which plane/field/eye. Something like this for example:

eye=left field=top plane=0 [plane=1 ...] [field=bottom plane=0 [plane=1 ...]]
 [eye=right field=top plane=0 [plane=1 ...] [field=bottom plane=0 [plane=1 
...]]]

so you first have all the planes for left/top, then all planes for
left/bottom, then right/top, and finally right/bottom.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Daniel Vetter]

On Tue, Sep 17, 2013 at 12:54:09PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 17, 2013 at 10:03:12AM +0100, Damien Lespiau wrote:
> > On Tue, Sep 17, 2013 at 11:20:46AM +0300, Ville Syrjälä wrote:
> >  > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -2131,6 +2131,17 @@ int drm_mode_setcrtc(struct drm_device *dev, 
> > > > void *data,
> > > > goto out;
> > > > }
> > > >  
> > > > +   /*
> > > > +* Do not allow the use of framebuffers consisting of 
> > > > multiple
> > > > +* buffers with stereo modes until all the details API 
> > > > details
> > > > +* are fleshed out (eg. interaction with drm_planes, 
> > > > switch
> > > > +* between a 1 buffers and a 2 buffers fb, ...)
> > > > +*/
> > > > +   if (fb->num_buffers > 1 && drm_mode_is_stereo(mode)) {
> > > > +   ret = -EINVAL;
> > > > +   goto out;
> > > > +   }
> > > 
> > > This would prevent planar buffers in stereo modes. I'm think we just
> > > ignore the matter for now and let drivers deal with it. We don't have
> > > enough handles anyway for planar stereo, so maybe we even want to add
> > > separate left/right fb attachment properties to the planes instead of
> > > tying it up in inside a single fb. Or we cook up addfb3 when we hit
> > > this problem for real. I think we'd anyway need some kind of flag for
> > > the fb if it contains both left and right buffers.
> > 
> > I'm quite happy to ignore 3 planes YUV stereo fbs for now :) (2 planes
> > YUV stereo fbs still fit!).
> > 
> > Are you fine with this test though, or do you mean ignore the whole
> > matter of forbidding this case (or just the multiplane stereo fb case)?
> > I was just thinking that I missed the addition of this check in the page
> > flip ioctl.
> 
> Yeah, I was thinking we that we can ignore this issue for now, and so we
> wouldn't need the check. Currently for non-stereo cases the only thing
> we check is that there is a valid handle for each plane. If userspace
> passes more handles, we simply ignore the extra ones.

I guess we should start to check that. For 3d framebuffers with 2
separate buffer handles for each plane I think we need to add another flag
to addfb2, e.g.

#define DRM_MODE_FB_3D_2_FRAMES (1<<1) /* separate left/right buffers, doubles 
plane count */

and then also throw in the respective check code into the core that
userspace supplies sufficient amounts of buffers in framebuffer_check()
by adjusting drM_format_num_planes and drm_format_plane_cpp.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60827] X under radeon driver crashes after resuming from hibernation

[bugzilla-daemon]

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

--- Comment #7 from archie...@gmail.com ---
The problem persists in Kernel 3.11.1

-- 
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 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

[bugzilla-daemon]

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

--- Comment #18 from Michel Dänzer  ---
(In reply to comment #12)
>  - Use correct register flags, so we don't overwrite the low dword
>when restoring multi-dword registers.

This doesn't seem to result in any difference for the code generated for the
first Sanctuary shader which spills registers.

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

exynos4: power domain issue with hdmi out

[Alban Browaeys]

Hi,

with Odroid U2 (exynos4412 quad) + a custom kernel based on linux-next
20130912 and before I am unable to get a hdmi output other than vertical
lines (a few whites on black background, sometimes yellow ) that are
static (no changes whatever the content sent to the hdmi output.

The issue disappeared as soon as I enabled fimd ... I narrowed it
further, ie nowI can get hdmi output without fimd but with pd_lcd0
commented as to avoid it goind into power off at boot. Find that via
fbcon enabled and content is displayed fined until the kernel turns off
the unused power domains (just before freeing unused kernel memory).

What could be the root issue ? Could pd_lcd0 wake up a parent item that
should be too by pd_tv ?

For one the non devicetree kernel from hardkernel setup s5p_fimd_device
even if it does not use it. So the issue would be hidden.
I also wonder if while developping s5p_device_hdmi such an issue
appeared .

Best regards
Alban

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

Re: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Ville Syrjälä]

On Tue, Sep 17, 2013 at 10:03:12AM +0100, Damien Lespiau wrote:
> On Tue, Sep 17, 2013 at 11:20:46AM +0300, Ville Syrjälä wrote:
>  > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -2131,6 +2131,17 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> > > *data,
> > >   goto out;
> > >   }
> > >  
> > > + /*
> > > +  * Do not allow the use of framebuffers consisting of multiple
> > > +  * buffers with stereo modes until all the details API details
> > > +  * are fleshed out (eg. interaction with drm_planes, switch
> > > +  * between a 1 buffers and a 2 buffers fb, ...)
> > > +  */
> > > + if (fb->num_buffers > 1 && drm_mode_is_stereo(mode)) {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > 
> > This would prevent planar buffers in stereo modes. I'm think we just
> > ignore the matter for now and let drivers deal with it. We don't have
> > enough handles anyway for planar stereo, so maybe we even want to add
> > separate left/right fb attachment properties to the planes instead of
> > tying it up in inside a single fb. Or we cook up addfb3 when we hit
> > this problem for real. I think we'd anyway need some kind of flag for
> > the fb if it contains both left and right buffers.
> 
> I'm quite happy to ignore 3 planes YUV stereo fbs for now :) (2 planes
> YUV stereo fbs still fit!).
> 
> Are you fine with this test though, or do you mean ignore the whole
> matter of forbidding this case (or just the multiplane stereo fb case)?
> I was just thinking that I missed the addition of this check in the page
> flip ioctl.

Yeah, I was thinking we that we can ignore this issue for now, and so we
wouldn't need the check. Currently for non-stereo cases the only thing
we check is that there is a valid handle for each plane. If userspace
passes more handles, we simply ignore the extra ones.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers

[bugzilla-daemon]

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

--- Comment #9 from Michel Dänzer  ---
Does it work better with glamor 0.5.1?

-- 
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: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

Alex,

10.09.2013, в 16:37, Alex Deucher  написал(а):

> The dummy page isn't really going to help much.  That page is just
> used as a safety placeholder for gart entries that aren't mapped on
> the GPU.  TTM (drivers/gpu/drm/ttm) actually does the allocation of
> the backing pages for the gart.  

> You may want to look there.

Ah, sorry. Indeed. Though, my idea with:

On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov  wrote:

> Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
> dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

doesn't make a sense at TTM part as well.

Konrad,

10.09.2013, 17:25, "Konrad Rzeszutek Wilk" :
>
> Is this platform enabling the SWIOTLB layer? 

Doesn't look like. 

> The reason I am asking is
> b/c if you do indeed enable it you end up using the TTM DMA pool
> which allocates pages using the dma_alloc_coherent - which means that
> all of the pages that come out of TTM are already 'DMA' mapped.
>
> And that means the radeon_gart_bind and all its friends
> use the DMA addresses that have been constructed by SWIOTLB IOMMU.
>
> Perhaps the PA-RISC IOMMU creates the DMA addresses differently?
>
> When the card gets programmed, you do end up using ttm_agp_bind right?
> I am wondering if something like this:
>
> https://lkml.org/lkml/2010/12/6/512
>
> is needed to pass in the right DMA address?

No idea how to modify ttm_agp_bind() this way, though doesn't matter if
swiotlb isn't used anyway?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/9] drm/edid: Expose mandatory stereo modes for HDMI sinks

[Damien Lespiau]

On Mon, Sep 16, 2013 at 06:35:12PM +0100, Damien Lespiau wrote:
> On Fri, Sep 13, 2013 at 04:10:24PM +, Joakim Plate wrote:
> > Damien Lespiau  intel.com> writes:
> > 
> > > +static const struct s3d_mandatory_mode s3d_mandatory_modes[] = {
> > > + { 1920, 1080, 24, 0,
> > > +   DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING 
> > },
> > > + { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE,
> > > +   DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> > > + { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE,
> > > +   DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> > > + { 1280, 720,  50, 0,
> > > +   DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING 
> > },
> > > + { 1280, 720,  60, 0,
> > > +   DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
> > > +};
> > 
> > 
> > I may be missing something here... But..
> 
> Oops, did not see your answer, please don't forget to include me in Cc:
> next time and not just the list.
> 
> > The frame packed modes are much higher in pixels than this and include 
> > frame 
> > packing.
> > 1080*2+45=2050
> > 720*2+30=1470
> > 
> > Unless you intend to hide the left/right split in mesa or other place, we 
> > need to get the ability to render to both fields somehow.
> > 
> > Either as the full 2050 pixels high or at 1080*2 and the driver adds the 
> > blanking.
> 
> Right, so at the moment, my proposition is that userspace is responsible for
> giving us a framebuffer with the right dimensions. For instance in
> intel-gpu-tools's testdisplay I have:

[...]

> and then adjust the timings if needed:

So, actually it seems that this will change a bit. User space still
needs to compute a correct fb size. In the case of frame packing, note
that user-space also needs to add the vblank lines, because it has to
know where to place the second eye starting at vdisplay + vblank.

The kernel will be in charge of tweaking the timings if needed though,
see:
http://lists.freedesktop.org/archives/dri-devel/2013-September/045386.html

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

Re: HDMI stereo support v4

[Damien Lespiau]

On Mon, Sep 16, 2013 at 06:48:43PM +0100, Damien Lespiau wrote:
> Next installment of the HDMI stereo 3D series, following:
>   http://lists.freedesktop.org/archives/dri-devel/2013-September/044885.html

Seems like a v5 is shapping up. I'll summarise the discussion with
Daniel on IRC yesterday and with Ville on the thread:

  - Let's adjust the timings (when it's needed) in the driver instead of
having user-space do it. This avoid leaking an implementation
detail, let user-space use the mode without having to tweak it and
Ville found that it'd be a bit impractical to match the 2D CEA VIC.
(Joakim Plate was wondering about this as well).

  - Make drivers opt-in to expose stereo modes, just like today with
interlaced modes, giving an opportunity for people to make it work
people exposing the modes.

  - For frame packing (where the framebuffer has to be twice as high +
vblank) we could also reject framebuffers with the wrong geometry.

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

Re: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Damien Lespiau]

On Tue, Sep 17, 2013 at 11:20:46AM +0300, Ville Syrjälä wrote:
 > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -2131,6 +2131,17 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> > *data,
> > goto out;
> > }
> >  
> > +   /*
> > +* Do not allow the use of framebuffers consisting of multiple
> > +* buffers with stereo modes until all the details API details
> > +* are fleshed out (eg. interaction with drm_planes, switch
> > +* between a 1 buffers and a 2 buffers fb, ...)
> > +*/
> > +   if (fb->num_buffers > 1 && drm_mode_is_stereo(mode)) {
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> 
> This would prevent planar buffers in stereo modes. I'm think we just
> ignore the matter for now and let drivers deal with it. We don't have
> enough handles anyway for planar stereo, so maybe we even want to add
> separate left/right fb attachment properties to the planes instead of
> tying it up in inside a single fb. Or we cook up addfb3 when we hit
> this problem for real. I think we'd anyway need some kind of flag for
> the fb if it contains both left and right buffers.

I'm quite happy to ignore 3 planes YUV stereo fbs for now :) (2 planes
YUV stereo fbs still fit!).

Are you fine with this test though, or do you mean ignore the whole
matter of forbidding this case (or just the multiplane stereo fb case)?
I was just thinking that I missed the addition of this check in the page
flip ioctl.

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

Re: [Intel-gfx] [PATCH 11/12] drm: Make drm_match_cea_mode() return the underlying 2D VIC for 3d modes

[Damien Lespiau]

On Tue, Sep 17, 2013 at 11:22:26AM +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2013 at 06:48:54PM +0100, Damien Lespiau wrote:
> > When scanning out a stereo mode, the AVI infoframe vic field has to be
> > the underlyng 2D VIC. Before that commit, we weren't matching the CEA
> > mode because of the extra stereo flag and then were setting the VIC
> > field in the AVI infoframe to 0.
> 
> I think this is where we hit problems. How do we identify the 2D VIC
> when the timings of the adjusted mode got mangled already to include
> both eyes?

Oh, indeed, that wouldn't work. Note that Daniel had the same remark as
you regarding the mangling of the modes, "leaking" how we implement the
modes (in theory hw could need a different way to be programmed). I
wondered about that as well and now that we have a couple of good
reasons, in kernel timing adjustment for stereo modes will happen in a
v5 of this series.

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

Re: [Intel-gfx] [PATCH 11/12] drm: Make drm_match_cea_mode() return the underlying 2D VIC for 3d modes

[Ville Syrjälä]

On Mon, Sep 16, 2013 at 06:48:54PM +0100, Damien Lespiau wrote:
> When scanning out a stereo mode, the AVI infoframe vic field has to be
> the underlyng 2D VIC. Before that commit, we weren't matching the CEA
> mode because of the extra stereo flag and then were setting the VIC
> field in the AVI infoframe to 0.

I think this is where we hit problems. How do we identify the 2D VIC
when the timings of the adjusted mode got mangled already to include
both eyes?

> 
> Signed-off-by: Damien Lespiau 
> ---
>  drivers/gpu/drm/drm_edid.c  |  4 ++--
>  drivers/gpu/drm/drm_modes.c | 18 --
>  include/drm/drm_crtc.h  |  2 +-
>  3 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9a36b6e..6b74698 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2401,7 +2401,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match)
>  
>   if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
>KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
> - drm_mode_equal_no_clocks(to_match, cea_mode))
> + drm_mode_equal_no_clocks_no_stereo(to_match, cea_mode))
>   return mode + 1;
>   }
>   return 0;
> @@ -2450,7 +2450,7 @@ static u8 drm_match_hdmi_mode(const struct 
> drm_display_mode *to_match)
>  
>   if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
>KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
> - drm_mode_equal_no_clocks(to_match, hdmi_mode))
> + drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
>   return mode + 1;
>   }
>   return 0;
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 504a602..76adee0 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -851,12 +851,16 @@ bool drm_mode_equal(const struct drm_display_mode 
> *mode1, const struct drm_displ
>   } else if (mode1->clock != mode2->clock)
>   return false;
>  
> - return drm_mode_equal_no_clocks(mode1, mode2);
> + if ((mode1->flags & DRM_MODE_FLAG_3D_MASK) !=
> + (mode2->flags & DRM_MODE_FLAG_3D_MASK))
> + return false;
> +
> + return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
>  }
>  EXPORT_SYMBOL(drm_mode_equal);
>  
>  /**
> - * drm_mode_equal_no_clocks - test modes for equality
> + * drm_mode_equal_no_clocks_no_stereo - test modes for equality
>   * @mode1: first mode
>   * @mode2: second mode
>   *
> @@ -864,12 +868,13 @@ EXPORT_SYMBOL(drm_mode_equal);
>   * None.
>   *
>   * Check to see if @mode1 and @mode2 are equivalent, but
> - * don't check the pixel clocks.
> + * don't check the pixel clocks nor the stereo layout.
>   *
>   * RETURNS:
>   * True if the modes are equal, false otherwise.
>   */
> -bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const 
> struct drm_display_mode *mode2)
> +bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
> + const struct drm_display_mode *mode2)
>  {
>   if (mode1->hdisplay == mode2->hdisplay &&
>   mode1->hsync_start == mode2->hsync_start &&
> @@ -881,12 +886,13 @@ bool drm_mode_equal_no_clocks(const struct 
> drm_display_mode *mode1, const struct
>   mode1->vsync_end == mode2->vsync_end &&
>   mode1->vtotal == mode2->vtotal &&
>   mode1->vscan == mode2->vscan &&
> - mode1->flags == mode2->flags)
> + (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
> +  (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>   return true;
>  
>   return false;
>  }
> -EXPORT_SYMBOL(drm_mode_equal_no_clocks);
> +EXPORT_SYMBOL(drm_mode_equal_no_clocks_no_stereo);
>  
>  /**
>   * drm_mode_validate_size - make sure modes adhere to size constraints
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index e685baf..f0c5530 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -943,7 +943,7 @@ extern void drm_mode_config_reset(struct drm_device *dev);
>  extern void drm_mode_config_cleanup(struct drm_device *dev);
>  extern void drm_mode_set_name(struct drm_display_mode *mode);
>  extern bool drm_mode_equal(const struct drm_display_mode *mode1, const 
> struct drm_display_mode *mode2);
> -extern bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, 
> const struct drm_display_mode *mode2);
> +extern bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode 
> *mode1, const struct drm_display_mode *mode2);
>  extern int drm_mode_width(const struct drm_display_mode *mode);
>  extern int drm_mode_height(const struct drm_display_mode *mode);
>  
> -- 
> 1.8.3.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/m

Re: [Intel-gfx] [PATCH 10/12] drm: Don't allow multiple buffers fb with stereo modes

[Ville Syrjälä]

On Mon, Sep 16, 2013 at 06:48:53PM +0100, Damien Lespiau wrote:
> There are a few things to be flushed out if we want to allow multiple
> buffers stereo framebuffers:
>   - What with drm_planes? what semantics do they follow, what is the
> hardware able to do with them?
>   - How do we define which buffer if the right/left one
>   - Do we allow flips between 1 buffer fbs and 2 buffers fbs (No.)
> 
> So for now, and until I get access to hardware that can do that, let's
> just disallow 2 buffers stereo framebuffers to not introduce ABI we
> wouldn't be able to change afterwards.
> 
> Signed-off-by: Damien Lespiau 
> ---
>  drivers/gpu/drm/drm_crtc.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 39f60ec..91d1c4b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2131,6 +2131,17 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> *data,
>   goto out;
>   }
>  
> + /*
> +  * Do not allow the use of framebuffers consisting of multiple
> +  * buffers with stereo modes until all the details API details
> +  * are fleshed out (eg. interaction with drm_planes, switch
> +  * between a 1 buffers and a 2 buffers fb, ...)
> +  */
> + if (fb->num_buffers > 1 && drm_mode_is_stereo(mode)) {
> + ret = -EINVAL;
> + goto out;
> + }

This would prevent planar buffers in stereo modes. I'm think we just
ignore the matter for now and let drivers deal with it. We don't have
enough handles anyway for planar stereo, so maybe we even want to add
separate left/right fb attachment properties to the planes instead of
tying it up in inside a single fb. Or we cook up addfb3 when we hit
this problem for real. I think we'd anyway need some kind of flag for
the fb if it contains both left and right buffers.

> +
>   drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
>  
>   hdisplay = mode->hdisplay;
> -- 
> 1.8.3.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)

[bugzilla-daemon]

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

--- Comment #15 from Stuart Foster  ---
Created attachment 108661
  --> https://bugzilla.kernel.org/attachment.cgi?id=108661&action=edit
Output from dmesg from vanilla kernel 3.12-rc1

Alex

With the release of kernel 3.12-rc1 I took the opportunity look at the display
stability of the kernel with non of the patches we discussed applied and I was
surprised to see that the display was unexpectedly stable. However I am
wondering if dpm is actually active for some reason and masking my original
issue. The following extracts from the attached dmesg log are what give me
grounds for concern:

Kernel command line: BOOT_IMAGE=Trial ro root=813 nf_conntrack.acct=1
userpte=nohigh radeon.modeset=1 radeon.agpmode=-1 radeon.audio=1 iommu=pt
iommu=1 radeon.dpm=1
Booting kernel: `-1' invalid for parameter `radeon.agpmode'

[drm] radeon: power management initialized

what do you think ?

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

Re: [PATCH] drm/ttm: fix the tt_populated check in ttm_tt_destroy()

[Thomas Hellstrom]

On 09/17/2013 06:21 AM, Ben Skeggs wrote:

From: Ben Skeggs 

After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up
inside the driver's unpopulate() hook when populate() has never yet
been called.

On nouveau, the first issue to be hit because of this is that
dma_address[] may be a NULL pointer.  After working around this,
ttm_pool_unpopulate() may potentially hit the same issue with
the pages[] array.

It seems to make more sense to avoid calling unpopulate on already
unpopulated TTMs than to add checks to all the implementations.

Signed-off-by: Ben Skeggs 
Cc: Jerome Glisse 
Cc: Thomas Hellstrom 
---
  drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5e93a52..210d503 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -170,7 +170,7 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
ttm_tt_unbind(ttm);
}
  
-	if (likely(ttm->pages != NULL)) {

+   if (ttm->state == tt_unbound) {
ttm->bdev->driver->ttm_tt_unpopulate(ttm);
}
  

Looks good to me.

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

about flashing firefox os on micromax a60 (amr6)

[Prasad Mhatre]

hello,
I have micromax a60 and specs are as follows:-


original os was :android 2.1
now currently os :android 2.2 frozen yogurt(flashed it)

i want to flash firefox OS on it can you guide me to do so

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

about flashing firefox os on micromax a60 (amr6)

[Prasad Mhatre]

hello,
I have micromax a60 and specs are as follows:-


original os was :android 2.1
now currently os :android 2.2 frozen yogurt(flashed it)

i want to flash firefox OS on it can you guide me to do so

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

[PATCH] drm/ttm: fix the tt_populated check in ttm_tt_destroy()

[Ben Skeggs]

From: Ben Skeggs 

After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up
inside the driver's unpopulate() hook when populate() has never yet
been called.

On nouveau, the first issue to be hit because of this is that
dma_address[] may be a NULL pointer.  After working around this,
ttm_pool_unpopulate() may potentially hit the same issue with
the pages[] array.

It seems to make more sense to avoid calling unpopulate on already
unpopulated TTMs than to add checks to all the implementations.

Signed-off-by: Ben Skeggs 
Cc: Jerome Glisse 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5e93a52..210d503 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -170,7 +170,7 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
ttm_tt_unbind(ttm);
}
 
-   if (likely(ttm->pages != NULL)) {
+   if (ttm->state == tt_unbound) {
ttm->bdev->driver->ttm_tt_unpopulate(ttm);
}
 
-- 
1.8.3.2

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

[Bug 69365] vgaswitcheroo crashes when passing "OFF" to the "switch" file

[bugzilla-daemon]

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

--- Comment #1 from Jose P.  ---
Seems to have been fixed in kernel 3.12-rc1 (from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc1-saucy/ ).
I don't know how to test it in a better way (other than simply running the
above command)... and I don't have other hardware to test it, so please close
it if you think it should be closed.

-- 
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 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.12 inclusive

[bugzilla-daemon]

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

Shawn Starr  changed:

   What|Removed |Added

Summary|[r600][RV635] GPU lockup CP |[r600][RV635] GPU lockup CP
   |stall / GPU resets over and |stall / GPU resets over and
   |over - Kernel 3.7 to 3.11   |over - Kernel 3.7 to 3.12
   |inclusive   |inclusive

-- 
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 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.11 inclusive

[bugzilla-daemon]

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

--- Comment #14 from Shawn Starr  ---
This is not Second Life related at all, I manged to get GPU to reset in the
following way:

1) Set /sys/class/drm/card0/device/power_dpm_state to Battery and leave
/sys/class/drm/card0/device/power_dpm_force_performance_level as 'auto mode.

2) have kwin enabled wih composite, rendering: XRender (not OpenGL as this will
show black windows with GLAMOR)
3) Browsed a webpage in Chromium/Chrome and it suddenly GPU reset

if I recall, In both places even when playing with Second Life, I set DPM power
state to Battery even though the laptop has AC plugged in as seen in this log
from the latest reset:

[   55.57] bridge0: port 2(vnet0) entered forwarding state
[   55.572229] bridge0: port 2(vnet0) entered forwarding state
[   70.624026] bridge0: port 2(vnet0) entered forwarding state
[  591.264107] device vnet1 entered promiscuous mode
[  591.273419] bridge0: port 3(vnet1) entered forwarding state
[  591.273425] bridge0: port 3(vnet1) entered forwarding state
[  606.303032] bridge0: port 3(vnet1) entered forwarding state
[  610.073896] perf samples too long (2506 > 2500), lowering
kernel.perf_event_max_sample_rate to 5
[ 1924.749108] switching from power state:
[ 1924.749113]  ui class: performance
[ 1924.749115]  internal class: none
[ 1924.749116]  caps: single_disp video 
[ 1924.749118]  uvdvclk: 0 dclk: 0
[ 1924.749120]  power level 0sclk: 11000 mclk: 40500 vddc: 900
[ 1924.749121]  power level 1sclk: 3 mclk: 7 vddc: 1100
[ 1924.749123]  power level 2sclk: 6 mclk: 7 vddc: 1100
[ 1924.749124]  status: c 
[ 1924.749125] switching to power state:
[ 1924.749126]  ui class: battery
[ 1924.749127]  internal class: none
[ 1924.749128]  caps: single_disp video 
[ 1924.749130]  uvdvclk: 0 dclk: 0
[ 1924.749131]  power level 0sclk: 11000 mclk: 40500 vddc: 900
[ 1924.749132]  power level 1sclk: 3 mclk: 40500 vddc: 900
[ 1924.749133]  power level 2sclk: 3 mclk: 40500 vddc: 900
[ 1924.749134]  status: r 
[ 6797.378014] hrtimer: interrupt took 14736 ns
[15919.834055] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[15919.839527] radeon :01:00.0: GPU lockup (waiting for 0x0011ebf9)
[15919.839532] radeon :01:00.0: failed to get a new IB (-35)
[15919.845308] [drm:radeon_cs_ib_chunk] *ERROR* Failed to get ib !
[15920.072129] radeon :01:00.0: Saved 1081 dwords of commands on ring 0.
[15920.072146] radeon :01:00.0: GPU softreset: 0x0009
[15920.072149] radeon :01:00.0:   R_008010_GRBM_STATUS  = 0xE4723030
[15920.072152] radeon :01:00.0:   R_008014_GRBM_STATUS2 = 0x00110103
[15920.072154] radeon :01:00.0:   R_000E50_SRBM_STATUS  = 0x20C0
[15920.072156] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[15920.072159] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x8002
[15920.072161] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x8086
[15920.072163] radeon :01:00.0:   R_008680_CP_STAT  = 0x80018645
[15920.072166] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[15920.129823] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x7FEF
[15920.129880] radeon :01:00.0: SRBM_SOFT_RESET=0x0100
[15920.131986] radeon :01:00.0:   R_008010_GRBM_STATUS  = 0xA0003030
[15920.131989] radeon :01:00.0:   R_008014_GRBM_STATUS2 = 0x0003
[15920.131991] radeon :01:00.0:   R_000E50_SRBM_STATUS  = 0x200080C0
[15920.131993] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[15920.131995] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[15920.131998] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[15920.132011] radeon :01:00.0:   R_008680_CP_STAT  = 0x8010
[15920.132014] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[15920.132021] radeon :01:00.0: GPU reset succeeded, trying to resume
[15920.149897] [drm] PCIE GART of 512M enabled (table at 0x0004).
[15920.149928] radeon :01:00.0: WB enabled
[15920.149931] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x88003715bc00
[15920.149934] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x88003715bc0c
[15920.181446] [drm] ring test on 0 succeeded in 1 usecs
[15920.389589] [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
(0xCAFEDEAD)
[15920.397386] [drm:r600_resume] *ERROR* r600 startup failed on resume
[15930.402047] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[15930.409147] radeon :01:00.0: GPU lockup (waiting for 0x0011ec1b
last fence id 0x0011ebff)
[15930.409150] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35).
[15930.415268] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-35).
[1593

[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.11 inclusive

[bugzilla-daemon]

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

--- Comment #15 from Shawn Starr  ---
(In reply to comment #14)
> 
> if I recall, In both places even when playing with Second Life, I set DPM
> power state to Battery even though the laptop has AC plugged in as seen in
> this log from the latest reset:
> 

The other time was performance mode, so doesn't matter if DPM is in Performance
or Battery state

-- 
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] gpu: host1x: use %pa to print dma_addr_t

[Randy Dunlap]

On 09/16/13 17:06, Olof Johansson wrote:
> On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches  wrote:
>> On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
>>> On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
>>>  wrote:
 On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
> This removes two warnings where dma_addr_t variables were printed using
> %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
>
>   drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects 
> argument of type 'unsigned int', but argument 5 has type 'dma_addr_t'
>   drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects 
> argument of type 'unsigned int', but argument 3 has type 'dma_addr_t'

 Hi Olof,

 I can't reproduce this. Does this perhaps depend on some other patch?
 When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c
 and those can indeed be fixed using an equivalent patch.
>>>
>>> You need to enable LPAE on a platform that also selects
>>> ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with
>>> multi_v7_defconfig you'll see them.
>>>
>>> However, see discussion on another of the emails in the series; I'll
>>> have to introduce a new format specifier instead.
>>
>> Or not.
>>
>> I don't know whether or not the dma_addr_t really needs a
>> fixed 18 byte output length for 64 bit uses.
>>
>> I think always using a cast for dma_addr_t addresses like:
>>
>> printk("dma_addr_t: %#llx\n", (u64)addr);
>>
>> would probably work just fine.
> 
> Sigh. Any color would do. I just want to get rid of the mostly-bogus
> warnings that makes it harder to spot real problems, I really don't
> care how they're resolved.
> 
> None of the affected platforms today use 64-bit DMA anyway, so casting
> down to u32 is equally acceptable. I'll repost with that instead.

Casting to u64 and using %llx is preferred for this throughout the kernel,
not u32.

That way you would never have to 'fix' those when those platforms use
64-bit DMA (this is where you say that they never will :).



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

[PATCH] drm/msm: Odd PTR_ERR usage

[Thomas Meyer]

The variable priv->kms is not initialized yet.

Found by "scripts/coccinelle/tests/odd_ptr_err.cocci".
PTR_ERR should access the value just tested by IS_ERR.

Signed-off-by: Thomas Meyer 
---

diff -u -p a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -199,7 +199,7 @@ static int msm_load(struct drm_device *d
 * imx drm driver on iMX5
 */
dev_err(dev->dev, "failed to load kms\n");
-   ret = PTR_ERR(priv->kms);
+   ret = PTR_ERR(kms);
goto fail;
}
 

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