Re: [PATCH] drm: fix a use-after-free when GPU acceleration disabled
Hi, Dave Why this patch hasn't been applied in your tree? I think you are the right maintainer. Huacai Chen On Tue, May 21, 2013 at 11:30 PM, Paul Menzel < paulepan...@users.sourceforge.net> wrote: > Am Dienstag, den 21.05.2013, 14:23 +0800 schrieb Huacai Chen: > > When GPU acceleration is disabled, drm_vblank_cleanup() will free the > > vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. > > But we found that drm_vblank_post_modeset() may be called after the > > cleanup, which use vblank_refcount and vblank_inmodeset. And this will > > cause a kernel panic. > > > > Fix this by return immediately if dev->num_crtcs is zero. This is the > > same thing that drm_vblank_pre_modeset() does. > > > > Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): > > [ 62.628906] [] drm_vblank_post_modeset+0x34/0xb4 > > [ 62.628906] [] atombios_crtc_dpms+0xb4/0x174 > > [ 62.628906] [] atombios_crtc_commit+0x18/0x38 > > [ 62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc > > [ 62.628906] [] > drm_crtc_helper_set_config+0x6d8/0x988 > > [ 62.628906] [] drm_fb_helper_set_par+0x94/0x104 > > [ 62.628906] [] fbcon_init+0x424/0x57c > > [ 62.628906] [] visual_init+0xb8/0x118 > > [ 62.628906] [] take_over_console+0x238/0x384 > > [ 62.628906] [] fbcon_takeover+0x7c/0xdc > > [ 62.628906] [] notifier_call_chain+0x44/0x94 > > [ 62.628906] [] > __blocking_notifier_call_chain+0x48/0x68 > > [ 62.628906] [] register_framebuffer+0x228/0x260 > > [ 62.628906] [] > drm_fb_helper_single_fb_probe+0x260/0x314 > > [ 62.628906] [] > drm_fb_helper_initial_config+0x200/0x234 > > [ 62.628906] [] radeon_fbdev_init+0xd4/0xf4 > > [ 62.628906] [] radeon_modeset_init+0x9bc/0xa18 > > [ 62.628906] [] radeon_driver_load_kms+0xdc/0x12c > > [ 62.628906] [] drm_get_pci_dev+0x148/0x238 > > [ 62.628906] [] local_pci_probe+0x5c/0xd0 > > [ 62.628906] [] work_for_cpu_fn+0x1c/0x30 > > [ 62.628906] [] process_one_work+0x274/0x3bc > > [ 62.628906] [] process_scheduled_works+0x24/0x44 > > [ 62.628906] [] worker_thread+0x31c/0x3f4 > > [ 62.628906] [] kthread+0x88/0x90 > > [ 62.628906] [] kernel_thread_helper+0x10/0x18 > > Nice commit message! > > > Signed-off-by: Huacai Chen > > Signed-off-by: Binbin Zhou > > Cc: > > --- > > drivers/gpu/drm/drm_irq.c |6 +- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > […] > > Acked-by: Paul Menzel > > > Thanks, > > Paul > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
These chipsets include the VP2 engine which is composed of a bitstream
processor (BSP) that decodes H.264 and a video processor (VP) which can
do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
driven by separate xtensa chips embedded in the hardware. This patch
provides the mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
This patch applies on top of nouveau/master (16a41bcc8).
This seems to work for me. There was one boot where my userspace
component didn't work right, but it could just as well be a bug
there. Subsequent attempts seem to work fine. Note that I'm not
particularly familiar with any of this stuff, so if something looks
odd, I probably didn't know any better. I did try to faithfully
reproduce whatever the blob did. A few questions/thoughts:
1. There's a LOT of similarity between BSP and VP setup/etc. Is it
worth it to create a core/xtensa.c or some such, similar to
falcon.c? Since it's only in two places, not that much code, and
there _are_ differences, I decided to keep them separate.
2. Firmware naming. Maarten suggested to use the falcon naming style,
which is nv$chipset_fuc$offset. However here, all the chips share
the same firmware. Also the offset would be 103 vs 00f, and is a
little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
left it the way I had it: nv84_bsp and nv84_vp.
3. Firmware load time. I chose to load the fw into memory in the ctor,
and then copy it in in init, due to some potentially bogus
suspend/resume concerns. Also e.g. mplayer likes to create/destroy
decoders at startup a few times. The downside is that ~200KB of
memory is gone. Let me know if I should change it to do the
request_firmware in init.
There's obviously a userspace piece to this, which I'm still working
on. But right now I have it working within certain parameters
(e.g. 1280x544 videos), and I'm relatively confident it can be
completed without further kernel-side changes.
There's also a hypothetical concern of "what if we create an open
firmware with a different user API". Ideally there'd be some way to
expose what kind of firmware is loaded, but I think that can be left
for "later".
drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c | 139 ++-
drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c | 4 +
drivers/gpu/drm/nouveau/core/engine/vp/nv84.c | 140 +++-
drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 1 +
drivers/gpu/drm/nouveau/core/subdev/vm/nv50.c | 2 +
5 files changed, 278 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
index 1d9f614..04880d9 100644
--- a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
+++ b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
@@ -29,6 +29,10 @@
struct nv84_bsp_priv {
struct nouveau_engine base;
+ u32 *fw;
+ long fw_size;
+ struct nouveau_gpuobj *gpu_fw;
+ void *vm_gpu_fw;
};
/***
@@ -37,6 +41,7 @@ struct nv84_bsp_priv {
static struct nouveau_oclass
nv84_bsp_sclass[] = {
+ { 0x74b0, &nouveau_object_ofuncs },
{},
};
@@ -44,11 +49,28 @@ nv84_bsp_sclass[] = {
* BSP context
**/
+static int
+nv84_bsp_engctx_ctor(struct nouveau_object *parent,
+struct nouveau_object *engine,
+struct nouveau_oclass *oclass, void *data, u32 size,
+struct nouveau_object **pobject)
+{
+ struct nouveau_engctx *engctx;
+ int ret;
+
+ ret = nouveau_engctx_create(parent, engine, oclass, NULL,
+ 0x1, 0x1000,
+ NVOBJ_FLAG_ZERO_ALLOC, &engctx);
+ *pobject = nv_object(engctx);
+ return ret;
+}
+
+
static struct nouveau_oclass
nv84_bsp_cclass = {
.handle = NV_ENGCTX(BSP, 0x84),
.ofuncs = &(struct nouveau_ofuncs) {
- .ctor = _nouveau_engctx_ctor,
+ .ctor = nv84_bsp_engctx_ctor,
.dtor = _nouveau_engctx_dtor,
.init = _nouveau_engctx_init,
.fini = _nouveau_engctx_fini,
@@ -61,6 +83,24 @@ nv84_bsp_cclass = {
* BSP engine/subdev functions
**/
+static void
+nv84_bsp_intr(struct nouveau_subdev *subdev)
+{
+ struct nv84_bsp_priv *priv = (void *)subdev;
+ u32 intr, unk104, unk10c, chan;
+
+ unk104 = nv_rd32(priv, 0x103d04);
+ intr = nv_rd32(priv, 0x103c20);
+ chan = nv_rd32(priv, 0x103c28);
+ unk10c = nv_rd32(priv, 0x103d0c);
+ nv_wr32(priv, 0x103c20, intr);
+ intr = nv_rd32(priv, 0x103c20);
+ if (unk10
Re: [PATCH] drm: fix a use-after-free when GPU acceleration disabled
On Mon, Jun 3, 2013 at 6:29 PM, Huacai Chen wrote: > Hi, Dave > > Why this patch hasn't been applied in your tree? I think you are the right > maintainer. > Because I missed it, i've stuck in my fixes queue now. thanks for pinging. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/i915: Use a custom restore_fbdev_mode hook
On Fri, May 31, 2013 at 08:07:04PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Disable sprite planes and cursors when restoring the fbdev mode.
>
> Should makes oopses more readable if they're not covered by sprites and
> cursors.
>
> v2: Rebased due to changes earlier in the series
Nice, this should fix the issue of the rogue cursor and the like if X
exits abnormally. Explicitly disabling it feels wrong, but as the cursor
is not integrated into the modesetting sequence I have no better
suggestion.
Reviewed-by: Chris Wilson
Comment inline.
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_fb.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index b34ccf3..e8389df 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -183,11 +183,25 @@ out:
> return ret;
> }
>
> +static bool intel_fb_restore_fbdev_mode(struct drm_fb_helper *helper)
> +{
> + struct drm_device *dev = helper->dev;
> + bool ret;
> +
> + intel_disable_cursors_and_sprites(dev);
> +
> + ret = drm_fb_helper_restore_fbdev_mode(helper);
> + if (ret)
> + DRM_DEBUG("failed to restore crtc mode\n");
Just return without the DBG here, and keep the DBG up a level where we
discard the error code.
> +
> + return ret;
> +}
> +
> static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
> .gamma_set = intel_crtc_fb_gamma_set,
> .gamma_get = intel_crtc_fb_gamma_get,
> .fb_probe = intelfb_create,
> - .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
> + .restore_fbdev_mode = intel_fb_restore_fbdev_mode,
> };
>
> static void intel_fbdev_destroy(struct drm_device *dev,
> @@ -291,7 +305,6 @@ void intel_fb_output_poll_changed(struct drm_device *dev)
>
> void intel_fb_restore_mode(struct drm_device *dev)
> {
> - int ret;
> drm_i915_private_t *dev_priv = dev->dev_private;
>
> if (INTEL_INFO(dev)->num_pipes == 0)
> @@ -299,11 +312,7 @@ void intel_fb_restore_mode(struct drm_device *dev)
>
> drm_modeset_lock_all(dev);
>
> - intel_disable_cursors_and_sprites(dev);
> -
> - ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
> - if (ret)
> - DRM_DEBUG("failed to restore crtc mode\n");
As above, I think this is the better location for the DBG.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/i915: Use container_of() in the fbdev code
On Fri, May 31, 2013 at 08:07:05PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Use container_of() instead of a cast to get struct intel_fbdev > from struct drm_fb_helper. > > Also populate the fb_info->par correctly with the drm_fb_helper pointer > instead of the intel_fbdev pointer. > > There's no actual functional change since the drm_fb_helper happens to > be the first member inside intel_fbdev. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/7] drm/i915: s/drm_i915_private_t/struct drm_i915_private/
On Fri, May 31, 2013 at 08:07:06PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > People don't like typedefs these days. Eliminate their use from intel_fb.c. > > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] drm/i915: Fix fbdev sprite disable code
On Fri, May 31, 2013 at 08:07:03PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> plane->enabled is never set, so this code didn't do anything.
>
> Fix the code for sprites by calling the new drm_plane_force_disable()
> function. That means the plane will remain off until someone explicitly
> turns it back on.
>
> And do the same for cursors and the old video overlays, since we only
> want to see the primary plane for fbdev.
>
> v2: Disable sprites/cursors until explicitly re-enabled
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 16
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fb.c | 9 ++---
> 3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 944b6d5..1d1a3fd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct
> drm_i915_error_state_buf *m,
> }
> }
> #endif
> +
> +void intel_disable_cursors_and_sprites(struct drm_device *dev)
> +{
> + struct drm_crtc *crtc;
> + struct drm_plane *plane;
> +
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
> + intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
> + }
> +
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->fb)
> + drm_plane_force_disable(plane);
This would be neater if drm_plane_force_disable did the check for
plane-fb itself.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 1/7] drm: Add fb_helper->restore_fbdev_mode hook
On Fri, May 31, 2013 at 08:07:01PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Drivers may need to turn off overlay planes, cursors, etc. when > restoring the fbdev mode. So allow drivers to provide their own > version of drm_fb_helper_restore_fbdev_mode() that can take care > of such details. > > Initially just plug in drm_fb_helper_restore_fbdev_mode for all > drivers. I really don't like the bool interface here, and it looks even more confusing when passing through the hooks. Can we have this changed to be a proper error code? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #28 from Marc Dietrich --- patch in comment 23 fixes gpu lockups for me in several webgl apps! Can this please be applied to llvm 3.3 branch? -- 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 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #29 from Marc Dietrich --- Created attachment 80202 --> https://bugs.freedesktop.org/attachment.cgi?id=80202&action=edit render defects in webgl demo still having issues with some webgl demos, e.g. http://www.chromeexperiments.com/detail/pearl-boy/?f=webgl see attached screenshot -- 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 59101] Gnome shell crashes after sleep mode
https://bugzilla.kernel.org/show_bug.cgi?id=59101 --- Comment #2 from Cyril N. 2013-06-03 11:27:12 --- dmesg : [149626.918841] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [149642.212632] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts [149644.616117] SELinux: initialized (dev proc, type proc), uses genfs_contexts [149654.440604] TCP: lp registered [152540.075830] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [152555.088551] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts [152557.274289] SELinux: initialized (dev proc, type proc), uses genfs_contexts [152599.209132] SELinux: initialized (dev proc, type proc), uses genfs_contexts [152622.306348] SELinux: initialized (dev proc, type proc), uses genfs_contexts [152630.547807] SELinux: initialized (dev proc, type proc), uses genfs_contexts > [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! seems to be the problem. Where is the xorg log file and how can I know the mesa version I'm using ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: Fix fbdev sprite disable code
On Fri, May 31, 2013 at 08:07:03PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> plane->enabled is never set, so this code didn't do anything.
>
> Fix the code for sprites by calling the new drm_plane_force_disable()
> function. That means the plane will remain off until someone explicitly
> turns it back on.
>
> And do the same for cursors and the old video overlays, since we only
> want to see the primary plane for fbdev.
>
> v2: Disable sprites/cursors until explicitly re-enabled
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 16
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fb.c | 9 ++---
> 3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 944b6d5..1d1a3fd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct
> drm_i915_error_state_buf *m,
> }
> }
> #endif
> +
> +void intel_disable_cursors_and_sprites(struct drm_device *dev)
> +{
> + struct drm_crtc *crtc;
> + struct drm_plane *plane;
> +
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
> + intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
> + }
I still think we should just move this into drm_fb_helper_restore_fbdev_mode:
- Cursors can be killed with crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
Or at least we should be able to do so, I've done a quick audit of all
drivers and none really cares about file_priv if the handle is 0. Of
course we should put that into a drm_cursor_force_disable helper to
prepare for a better world (atomic modeset and all ...).
vmwgfx needs to be fixed up slightly since it derefences file_priv
outside of a handle != 0 check, but that one can be trivially fixed for
both cursor_set callbacks by moving the driver_private dereference into
the if block.
- Legacy overlay stuff has been broken like that forever, and at least on
i8xx those are used much more often. Imo whoever's offended by gen2
being a bit broken can write a drm plane wrapper for the overlay stuff
(or better, move the code to drm planes and convert the ioctl to be a
shim around the real drm plane interfaces). I don't think we should add
hacks for that.
Cheers, Daniel
> +
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->fb)
> + drm_plane_force_disable(plane);
> + }
> +}
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d0a8c1a..f8e76cf 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -800,5 +800,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct
> drm_device *dev,
> extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev,
>enum transcoder pch_transcoder,
>bool enable);
> +extern void intel_disable_cursors_and_sprites(struct drm_device *dev);
>
> #endif /* __INTEL_DRV_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index 5fe525a..b34ccf3 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -293,22 +293,17 @@ void intel_fb_restore_mode(struct drm_device *dev)
> {
> int ret;
> drm_i915_private_t *dev_priv = dev->dev_private;
> - struct drm_mode_config *config = &dev->mode_config;
> - struct drm_plane *plane;
>
> if (INTEL_INFO(dev)->num_pipes == 0)
> return;
>
> drm_modeset_lock_all(dev);
>
> + intel_disable_cursors_and_sprites(dev);
> +
> ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
> if (ret)
> DRM_DEBUG("failed to restore crtc mode\n");
>
> - /* Be sure to shut off any planes that may be active */
> - list_for_each_entry(plane, &config->plane_list, head)
> - if (plane->enabled)
> - plane->funcs->disable_plane(plane);
> -
> drm_modeset_unlock_all(dev);
> }
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 6/7] drm/i915: s/drm_i915_private_t/struct drm_i915_private/
On Mon, Jun 03, 2013 at 11:09:00AM +0100, Chris Wilson wrote: > On Fri, May 31, 2013 at 08:07:06PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > People don't like typedefs these days. Eliminate their use from intel_fb.c. > > > > Signed-off-by: Ville Syrjälä > Reviewed-by: Chris Wilson Queued for -next, thanks for the patch. -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 5/7] drm/i915: Use container_of() in the fbdev code
On Mon, Jun 03, 2013 at 11:08:30AM +0100, Chris Wilson wrote: > On Fri, May 31, 2013 at 08:07:05PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Use container_of() instead of a cast to get struct intel_fbdev > > from struct drm_fb_helper. > > > > Also populate the fb_info->par correctly with the drm_fb_helper pointer > > instead of the intel_fbdev pointer. > > > > There's no actual functional change since the drm_fb_helper happens to > > be the first member inside intel_fbdev. > Reviewed-by: Chris Wilson Queued for -next, thanks for the patch. -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 v2 3/7] drm/i915: Fix fbdev sprite disable code
On Mon, Jun 03, 2013 at 02:00:00PM +0200, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 08:07:03PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > plane->enabled is never set, so this code didn't do anything.
> >
> > Fix the code for sprites by calling the new drm_plane_force_disable()
> > function. That means the plane will remain off until someone explicitly
> > turns it back on.
> >
> > And do the same for cursors and the old video overlays, since we only
> > want to see the primary plane for fbdev.
> >
> > v2: Disable sprites/cursors until explicitly re-enabled
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 16
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_fb.c | 9 ++---
> > 3 files changed, 19 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 944b6d5..1d1a3fd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct
> > drm_i915_error_state_buf *m,
> > }
> > }
> > #endif
> > +
> > +void intel_disable_cursors_and_sprites(struct drm_device *dev)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_plane *plane;
> > +
> > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> > + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
> > + intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
> > + }
>
> I still think we should just move this into drm_fb_helper_restore_fbdev_mode:
> - Cursors can be killed with crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
> Or at least we should be able to do so, I've done a quick audit of all
> drivers and none really cares about file_priv if the handle is 0. Of
> course we should put that into a drm_cursor_force_disable helper to
> prepare for a better world (atomic modeset and all ...).
>
> vmwgfx needs to be fixed up slightly since it derefences file_priv
> outside of a handle != 0 check, but that one can be trivially fixed for
> both cursor_set callbacks by moving the driver_private dereference into
> the if block.
>
> - Legacy overlay stuff has been broken like that forever, and at least on
> i8xx those are used much more often. Imo whoever's offended by gen2
> being a bit broken can write a drm plane wrapper for the overlay stuff
> (or better, move the code to drm planes and convert the ioctl to be a
> shim around the real drm plane interfaces). I don't think we should add
> hacks for that.
OK I give up. I did a quick check of the private plane stuff, and it
turns out they're not on plane_list, so I think just walking the list
and disabling everything there should be OK. Since you're happy w/
leaving the video overlay out in the cold for now, I'll shovel it all
into drm_fb_helper...
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm: Add drm_plane_force_disable()
From: Ville Syrjälä
drm_plane_force_disable() will forcibly disable the plane even if user
had previously requested the plane to be enabled.
This can be used to force planes to be off when restoring the fbdev
mode.
The code was simply pulled from drm_framebuffer_remove(), which now
calls the new function as well.
v2: Check plane->fb in drm_plane_force_disable(), drop bogus comment
about disabling crtc
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 29 +++--
include/drm/drm_crtc.h | 1 +
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..865ebfe 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -569,16 +569,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
}
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
- if (plane->fb == fb) {
- /* should turn off the crtc */
- ret = plane->funcs->disable_plane(plane);
- if (ret)
- DRM_ERROR("failed to disable plane with
busy fb\n");
- /* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(plane->fb);
- plane->fb = NULL;
- plane->crtc = NULL;
- }
+ if (plane->fb == fb)
+ drm_plane_force_disable(plane);
}
drm_modeset_unlock_all(dev);
}
@@ -867,6 +859,23 @@ void drm_plane_cleanup(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_cleanup);
+void drm_plane_force_disable(struct drm_plane *plane)
+{
+ int ret;
+
+ if (!plane->fb)
+ return;
+
+ ret = plane->funcs->disable_plane(plane);
+ if (ret)
+ DRM_ERROR("failed to disable plane with busy fb\n");
+ /* disconnect the plane from the fb and crtc: */
+ __drm_framebuffer_unreference(plane->fb);
+ plane->fb = NULL;
+ plane->crtc = NULL;
+}
+EXPORT_SYMBOL(drm_plane_force_disable);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..db7a885 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -894,6 +894,7 @@ extern int drm_plane_init(struct drm_device *dev,
const uint32_t *formats, uint32_t format_count,
bool priv);
extern void drm_plane_cleanup(struct drm_plane *plane);
+extern void drm_plane_force_disable(struct drm_plane *plane);
extern void drm_encoder_cleanup(struct drm_encoder *encoder);
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vmwgfx: Don't access file_priv in cursor_set when handle==0
From: Ville Syrjälä
We want to disable the cursor by calling ->cursor_set() with handle=0
from places where we don't have a file_priv, so don't try to access it
unless necessary.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3e3c7ab..d4607b2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -174,7 +174,6 @@ int vmw_du_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
uint32_t handle, uint32_t width, uint32_t height)
{
struct vmw_private *dev_priv = vmw_priv(crtc->dev);
- struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
struct vmw_surface *surface = NULL;
struct vmw_dma_buffer *dmabuf = NULL;
@@ -197,6 +196,8 @@ int vmw_du_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
}
if (handle) {
+ struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
+
ret = vmw_user_lookup_handle(dev_priv, tfile,
handle, &surface, &dmabuf);
if (ret) {
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/fb-helper: Disable cursors and planes when restoring fbdev mode
From: Ville Syrjälä
Cursors and plane can obscure whatever fbdev wants to show the user.
Disable them all in drm_fb_helper_restore_fbdev_mode.
After the cursors and planes have been disabled, user space needs to
explicitly re-enable them to make them visible again.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_helper.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0df0ebb..3d13ca6e2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -287,13 +287,27 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
*/
bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
{
+ struct drm_device *dev = fb_helper->dev;
+ struct drm_plane *plane;
bool error = false;
- int i, ret;
+ int i;
+
+ drm_warn_on_modeset_not_all_locked(dev);
- drm_warn_on_modeset_not_all_locked(fb_helper->dev);
+ list_for_each_entry(plane, &dev->mode_config.plane_list, head)
+ drm_plane_force_disable(plane);
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set =
&fb_helper->crtc_info[i].mode_set;
+ struct drm_crtc *crtc = mode_set->crtc;
+ int ret;
+
+ if (crtc->funcs->cursor_set) {
+ ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
+ if (ret)
+ error = true;
+ }
+
ret = drm_mode_set_config_internal(mode_set);
if (ret)
error = true;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm: fbdev mode restoration improvements v3
Third time's the charm maybe. Changes from v2: - Move the plane->fb NULL check into drm_plane_force_disable() - Cursors/planes are now disabled by drm_fb_helper directly, so no need for the new hook - Had to fix up vmwgfx not to look at file_priv in cursor_set when handle is 0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/i915: Drop bogus fbdev sprite disable code
From: Ville Syrjälä
plane->enabled is never set, so this code didn't do anything.
Also drm_fb_helper_restore_fbdev_mode() will now disable all cursors
and sprites for us, so we don't have to bother anymore.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fb.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 7a77d4c..7f3ac54 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -293,8 +293,6 @@ void intel_fb_restore_mode(struct drm_device *dev)
{
int ret;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_plane *plane;
if (INTEL_INFO(dev)->num_pipes == 0)
return;
@@ -305,10 +303,5 @@ void intel_fb_restore_mode(struct drm_device *dev)
if (ret)
DRM_DEBUG("failed to restore crtc mode\n");
- /* Be sure to shut off any planes that may be active */
- list_for_each_entry(plane, &config->plane_list, head)
- if (plane->enabled)
- plane->funcs->disable_plane(plane);
-
drm_modeset_unlock_all(dev);
}
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: Remove some unused stuff from drm_plane
From: Ville Syrjälä
There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly. Eliminate them.
v2: Remove all of it from kernel-doc too
Reviewed-by: Laurent Pinchart
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 2 +-
include/drm/drm_crtc.h | 11 ---
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 865ebfe..f00ba75 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1749,7 +1749,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
plane_resp->plane_id = plane->base.id;
plane_resp->possible_crtcs = plane->possible_crtcs;
- plane_resp->gamma_size = plane->gamma_size;
+ plane_resp->gamma_size = 0;
/*
* This ioctl is called twice, once to determine how much space is
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index db7a885..3c14b46 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -654,11 +654,7 @@ struct drm_plane_funcs {
* @format_count: number of formats supported
* @crtc: currently bound CRTC
* @fb: currently bound fb
- * @gamma_size: size of gamma table
- * @gamma_store: gamma correction table
- * @enabled: enabled flag
* @funcs: helper functions
- * @helper_private: storage for drver layer
* @properties: property tracking for this plane
*/
struct drm_plane {
@@ -674,14 +670,7 @@ struct drm_plane {
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
- /* CRTC gamma size for reporting to userspace */
- uint32_t gamma_size;
- uint16_t *gamma_store;
-
- bool enabled;
-
const struct drm_plane_funcs *funcs;
- void *helper_private;
struct drm_object_properties properties;
};
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65068] vgaswitcheroo doesn't deal with powered off dGPU on resume
https://bugs.freedesktop.org/show_bug.cgi?id=65068 --- Comment #7 from Alex Deucher --- (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > I'm not sure if this has anything to do with this bug, but the PCI config > > > space is all messed up when running on the integrated GPU: > > > > When you disable the GPU the hardware is physically powered off so you are > > accessing non-existent registers. You need to power up the GPU using > > vgaswitcheroo before loading/resuming the driver or access the config space > > with lspci. > > I guess what I was trying to say was, does having the device in this state > before you start suspend make the power management subsystem confused? Will > it try to "restore" the pci configuration space to 0xff? The reason you are getting 0xff is because you are accessing a disabled device. lspci would need to power up the GPU using vgaswitcheroo before accessing the hardware. > > The radeon GPU is definitely turned on by the firmware on resume and the > apple-gmux driver turns it off if that was the state of the system when > suspend was started. I suspect the gmux driver resumes first and disables the hardware before the radeon driver resumes. So the radeon driver resumes on disabled hardware. > > I tried a quick hack to call the "ON" function for vga-switcheroo from the > apple-gmux driver suspend hook. But that didn't work. However, if I do it > manually (i.e. echo ON > /sys/kernel/debug/vgaswitcheroo/switch) before > suspend, then it does seem to fix it. Some one needs to sort out the interactions between the the vgaswitcheroo drivers and the GPU drivers so that they do the right thing on suspend and resume and hw access from userspace utilities like lspci. -- 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 65068] vgaswitcheroo doesn't deal with powered off dGPU on resume
https://bugs.freedesktop.org/show_bug.cgi?id=65068 --- Comment #8 from Alex Deucher --- Additionally, since the audio device is part of the GPU, it needs to work properly with vgaswitcheroo. Dave Airlie was doing some work to support all of this properly, but it's not complete yet: http://cgit.freedesktop.org/~airlied/linux/log/?h=switchy-wip http://cgit.freedesktop.org/~airlied/linux/log/?h=nv-pm-ops2-wip -- 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 54867] bug in r300 compiler
https://bugs.freedesktop.org/show_bug.cgi?id=54867 --- Comment #2 from Tom Stellard --- Comment on attachment 80074 --> https://bugs.freedesktop.org/attachment.cgi?id=80074 s/signed/int/ Review of attachment 80074: - This patch looks good to me, but for the commit message, you need to wrap long lines to 80 or fewer characters (I actually wrap to 75, but I'm not sure what the standard convention is) and re-organize the commit message in the form of: Code area: Brief description Long description (if necessary) Link to fixed bugs For this patch, it should be something like: r300g/compiler: Fix unsigned comparison with less than zero rc_find_free_temporary_list() returns signed integer (in case of lack of free temporary registersreturns -1), so new_index in radeon_rename_regs() should be signed. https://bugs.freedesktop.org/show_bug.cgi?id=54867 -- 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 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=65270 --- Comment #1 from Alex Deucher --- Make sure you've installed the updated rlc and uvd microcode and that it is available to the driver during boot (in your initrd, etc.). You can grab the latest ucode here: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git or here: http://people.freedesktop.org/~agd5f/radeon_ucode/ You need BTC_rlc.bin and SUMO_uvd.bin for UVD on your chip. -- 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 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)
https://bugs.freedesktop.org/show_bug.cgi?id=65274 --- Comment #2 from Alex Deucher --- Make sure you have the updated rlc firmware as well. -- 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 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=65270 --- Comment #2 from Alex Deucher --- Is this a hybrid laptop with multiple GPUs? -- 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 50135] Unigine Heaven black stripes and weird shaders
https://bugs.freedesktop.org/show_bug.cgi?id=50135 --- Comment #10 from Simone Scanzoni --- Created attachment 80226 --> https://bugs.freedesktop.org/attachment.cgi?id=80226&action=edit Xonotic with shadow mapping Bug still present today in Mesa 9.2.0 (git-c754f7a), kernel 3.9.4. I saw a similar glitch also in Brütal Legend, Stacking and Costume Quest, especially with ambient occlusion, so I suppose all the games using the Buddha engine from Double Fine are affected. I think the bug title should be changed for the following reasons: The black stripes problem isn't specific to Unigine but happens with at least 4 different engines: Unigine, Buddha, DarkPlaces and K2. The 3 people who see the bug here all use an RV670. There is a workaround for the wrong shaders in the night time scenes. The black stripes problem seems related to shadows, because disabling them in Xonotic and Heroes of Newerth removes the stripes and disabling ambient occlusion in games using the Buddha engine reduces the stripes slightly. So I propose to change the title to: Broken shadows on RV670 I'm not sure if it's just a problem with shadow mapping because even if using stencil shadow volumes works in Xonotic the screenshot posted by Micael of the OgreSampleBrowser exhibit a similar problem and the text: "Technique Stencil". Could the output of any R600_DEBUG setting be useful? Attached a screenshot of the bug in Xonotic. -- 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 50135] Unigine Heaven black stripes and weird shaders
https://bugs.freedesktop.org/show_bug.cgi?id=50135 --- Comment #11 from Simone Scanzoni --- Created attachment 80228 --> https://bugs.freedesktop.org/attachment.cgi?id=80228&action=edit Xonotic with shadow mapping, sharp flavour The black stripes in Xonotic can be soft or sharp. -- 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 50135] Unigine Heaven black stripes and weird shaders
https://bugs.freedesktop.org/show_bug.cgi?id=50135 --- Comment #12 from Simone Scanzoni --- Created attachment 80229 --> https://bugs.freedesktop.org/attachment.cgi?id=80229&action=edit Xonotic with stencil shadow volumes Stencil shadow volumes work in Xonotic, so you can see how the shadows should be. -- 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 59101] Gnome shell crashes after sleep mode
https://bugzilla.kernel.org/show_bug.cgi?id=59101 --- Comment #3 from Alex Deucher 2013-06-03 14:01:39 --- (In reply to comment #2) > > > [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! > > seems to be the problem. -12 mean -ENOMEM. It seems the kernel is out of memory and the driver is not able to allocate the memory it needs to process the rendering commands. > > Where is the xorg log file and how can I know the mesa version I'm using ? the xorg log is usually /var/log/Xorg.0.log If you are using distro packages, you'll have to check and see what version of mesa you have installed using your package manager. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59101] Gnome shell crashes after sleep mode
https://bugzilla.kernel.org/show_bug.cgi?id=59101 --- Comment #4 from Cyril N. 2013-06-03 14:07:43 --- Created an attachment (id=103291) --> (https://bugzilla.kernel.org/attachment.cgi?id=103291) Xorg.0.log log file -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59101] Gnome shell crashes after sleep mode
https://bugzilla.kernel.org/show_bug.cgi?id=59101 --- Comment #5 from Cyril N. 2013-06-03 14:13:28 --- $> glxinfo | egrep -A2 "rendering|OpenGL" > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.4 > -- > OpenGL vendor string: X.Org > OpenGL renderer string: Gallium 0.4 on AMD CEDAR > OpenGL version string: 2.1 Mesa 9.1 > OpenGL shading language version string: 1.30 > OpenGL extensions: > GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, > GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_stencil_export And I uploaded my Xorg.0.log files. I hope it'll help ! :) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=65270 --- Comment #3 from Gerben Welter --- (In reply to comment #2) > Is this a hybrid laptop with multiple GPUs? No, this laptop has just the Radeon GPU. -- 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 50135] Unigine Heaven black stripes and weird shaders
https://bugs.freedesktop.org/show_bug.cgi?id=50135 --- Comment #13 from Simone Scanzoni --- Created attachment 80230 --> https://bugs.freedesktop.org/attachment.cgi?id=80230&action=edit Xonotic without shadows from realtime world lights Comparing this to the screenshot with stencil shadow volumes you can see which shadows are affected. -- 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 1/1] radeon: Fix system hang issue when using KMS with older cards
On Sun, Jun 2, 2013 at 10:47 AM, Adis Hamzić wrote:
> The current radeon driver initialization routines, when using KMS, are written
> so that the IRQ installation routine is called before initializing the WB
> buffer
> and the CP rings. With some ASICs, though, the IRQ routine tries to access the
> GFX_INDEX ring causing a call to RREG32 with the value of -1 in
> radeon_fence_read. This, in turn causes the system to completely hang with
> some
> cards, requiring a hard reset.
>
> A call stack that can cause such a hang looks like this (using rv515 ASIC for
> the
> example here):
> * rv515_init (rv515.c)
> * radeon_irq_kms_init (radeon_irq_kms.c)
> * drm_irq_install (drm_irq.c)
> * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
> * rs600_irq_process (rs600.c)
> * radeon_fence_process - due to SW interrupt (radeon_fence.c)
> * radeon_fence_read (radeon_fence.c)
> * hang due to RREG32(-1)
>
> The patch moves the IRQ installation to the card startup routine, after the
> ring
> has been initialized, but before the IRQ has been set. This fixes the issue,
> but
> requires a check to see if the IRQ is already installed, as is the case in the
> system resume codepath.
> I have tested the patch on three machines using the rv515, the rv770 and the
> evergreen ASIC. They worked without issues.
>
> This seems to be a known issue and has been reported on several bug tracking
> sites by various distributions (see links below). Most of reports recommend
> booting the system with KMS disabled and then enabling KMS by reloading the
> radeon module. For some reason, this was indeed a usable workaround, however,
> UMS is now deprecated and disabled by default.
>
> Bug reports:
> https://bugzilla.redhat.com/show_bug.cgi?id=845745
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789
> https://bbs.archlinux.org/viewtopic.php?id=156964
Thanks for tracking this down. I've applied it to my fixes tree.
Alex
>
> Signed-off-by: Adis Hamzić
> ---
> drivers/gpu/drm/radeon/evergreen.c | 10 ++
> drivers/gpu/drm/radeon/ni.c| 10 ++
> drivers/gpu/drm/radeon/r100.c | 9 ++---
> drivers/gpu/drm/radeon/r300.c | 9 ++---
> drivers/gpu/drm/radeon/r420.c | 10 ++
> drivers/gpu/drm/radeon/r520.c | 9 ++---
> drivers/gpu/drm/radeon/r600.c | 10 ++
> drivers/gpu/drm/radeon/rs400.c | 9 ++---
> drivers/gpu/drm/radeon/rs600.c | 9 ++---
> drivers/gpu/drm/radeon/rs690.c | 9 ++---
> drivers/gpu/drm/radeon/rv515.c | 9 ++---
> drivers/gpu/drm/radeon/rv770.c | 10 ++
> drivers/gpu/drm/radeon/si.c| 10 ++
> 13 files changed, 78 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 8546e3b..0f89ce3 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -4754,6 +4754,12 @@ static int evergreen_startup(struct radeon_device
> *rdev)
> rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
>
> /* Enable IRQ */
> + if (!rdev->irq.installed) {
> + r = radeon_irq_kms_init(rdev);
> + if (r)
> + return r;
> + }
> +
> r = r600_irq_init(rdev);
> if (r) {
> DRM_ERROR("radeon: IH init failed (%d).\n", r);
> @@ -4923,10 +4929,6 @@ int evergreen_init(struct radeon_device *rdev)
> if (r)
> return r;
>
> - r = radeon_irq_kms_init(rdev);
> - if (r)
> - return r;
> -
> rdev->ring[RADEON_RING_TYPE_GFX_INDEX].ring_obj = NULL;
> r600_ring_init(rdev, &rdev->ring[RADEON_RING_TYPE_GFX_INDEX], 1024 *
> 1024);
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 7969c0c..8458330 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -2025,6 +2025,12 @@ static int cayman_startup(struct radeon_device *rdev)
> }
>
> /* Enable IRQ */
> + if (!rdev->irq.installed) {
> + r = radeon_irq_kms_init(rdev);
> + if (r)
> + return r;
> + }
> +
> r = r600_irq_init(rdev);
> if (r) {
> DRM_ERROR("radeon: IH init failed (%d).\n", r);
> @@ -2190,10 +2196,6 @@ int cayman_init(struct radeon_device *rdev)
> if (r)
> return r;
>
> - r = radeon_irq_kms_init(rdev);
> - if (r)
> - return r;
> -
> ring->ring_obj = NULL;
> r600_ring_init(rdev, ring, 1024 * 1024);
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 4973bff..d0314ec 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -3869,6 +3869,12 @@ static int r100_startup(struct radeon_device *rdev)
> }
>
> /* Enable IRQ */
> + if (!rdev->irq.installed) {
> +
[Bug 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=65270 --- Comment #4 from Gerben Welter --- (In reply to comment #1) > Make sure you've installed the updated rlc and uvd microcode and that it is > available to the driver during boot (in your initrd, etc.). You can grab > the latest ucode here: > http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git > or here: > http://people.freedesktop.org/~agd5f/radeon_ucode/ > You need BTC_rlc.bin and SUMO_uvd.bin for UVD on your chip. Yeah, I grabbed those already otherwise the update of the initrd starts complaining they are missing. -- 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 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #4 from Michel Dänzer --- (In reply to comment #3) > R600_HYPERZ=0 /usr/bin/xscreensaver-demo > > and switching between screensavers crashed as often as without R600_HYPERZ=0. Beware that AFAIK the screensaver hacks aren't spawned from the xscreensaver-demo process but from the xscreensaver daemon process. Did you confirm that the latter saw the environment variable? -- 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 65254] opengl flicker in xbmc / glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=65254 --- Comment #6 from Michel Dänzer --- Can you also attach the output of glxinfo and xbmc (in particular anything related to its use of OpenGL)? -- 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 2/3] drm/vmwgfx: Don't access file_priv in cursor_set when handle==0
Thanks, looks good and is
Reviewed-by: Jakob Bornecrantz
Cheers, Jakob.
On Mon, Jun 3, 2013 at 3:10 PM, wrote:
> From: Ville Syrjälä
>
> We want to disable the cursor by calling ->cursor_set() with handle=0
> from places where we don't have a file_priv, so don't try to access it
> unless necessary.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 3e3c7ab..d4607b2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -174,7 +174,6 @@ int vmw_du_crtc_cursor_set(struct drm_crtc *crtc,
> struct drm_file *file_priv,
>uint32_t handle, uint32_t width, uint32_t
> height)
> {
> struct vmw_private *dev_priv = vmw_priv(crtc->dev);
> - struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
> struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
> struct vmw_surface *surface = NULL;
> struct vmw_dma_buffer *dmabuf = NULL;
> @@ -197,6 +196,8 @@ int vmw_du_crtc_cursor_set(struct drm_crtc *crtc,
> struct drm_file *file_priv,
> }
>
> if (handle) {
> + struct ttm_object_file *tfile =
> vmw_fpriv(file_priv)->tfile;
> +
> ret = vmw_user_lookup_handle(dev_priv, tfile,
> handle, &surface, &dmabuf);
> if (ret) {
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [i915] Backlight brighter since 3.9.0
On 05/20/2013 02:55 PM, Daniel Vetter wrote: On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote: Hallo, I hope this is the right place to ask, because I actually don't know whether it is a bug or a feature that I'm experiencing since linux 3.9: When I boot my system the backlight gets extremely bright compared to older kernel versions. It is most obvious when I leave X (more a yellow than a black background), but I have the impression, that the colors in X are brighter than usual, too. I used my spare time this afternoon to do a kernel bisect and learned that the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I don't have insight or understanding of the code: Is this behaviour intended and how could I change it to the old state or is it a bug and should I report it somewhere? My system is as follows: Intel i5-3570k with Intel HD 4000 my monitor is connected via HDMI. If you need any more information just tell me. Yeah, this is a feature. HDMI has (for oddball backwards compat with analog TV signals) a special mode which reduces the useable RGB value range by chopping off about 10% at the bottom and top end. This results in light colors getting brighter and dark colors getting darker. The above mentioned commit tries (to the best of our knowledge) to auto-set the option which most likely fits what the hdmi sink will do with the color data. You can either fix this up in the hdmi sink with the on-screen menu or by manually setting the "RBG Broadcast" property for the relevant hdmi connector to the setting you want. This property seems like it's generally useful for all GPUs that support range compression. Has anyone started the process of adding it to randrproto.txt as an official property? http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n1723 -- Aaron --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #3 from Tom Stellard --- Is this still an issue? -- 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 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #5 from Luzipher --- (In reply to comment #4) > Beware that AFAIK the screensaver hacks aren't spawned from the > xscreensaver-demo process but from the xscreensaver daemon process. Did you > confirm that the latter saw the environment variable? I'm very sure that the environment variable is seen. Today, I added it to my /etc/environment again, restarted, and confirmed it is there by echo $R600_HYPERZ, which printed 0, as expected. I'm starting X manually (with startx), so I'm quite certain that the xscreensaver daemon process also sees the variable. All the following tests have been done with R600_HYPERZ=0 in /etc/environment. As I mentioned in my previous comment, starting antmaze with the command R600_HYPERZ=0 /usr/lib/misc/xscreensaver/antmaze works more often. In fact I couldn't get it to crash in about 25 tries today. What did crash was again juggler3d on the third try when _closing_ its window. The command used was: R600_HYPERZ=0 /usr/lib/misc/xscreensaver/juggler3d Also, by using the xscreensaver-demo application (with R600_HYPERZ=0 in /etc/environment) and switching between random screensavers, I could trigger a crash quickly. -- 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 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #6 from Luzipher --- More info: I tried again with juggler3d and it crashed first time upon exit. flurry also triggered the crash on exit. So I now suspect that antmaze isn't problematic - it is not starting a screensaver that causes the crash, but closing one. As I switched screensavers randomly in xscreensaver-demo, I just by chance clicked on antmaze when I had a problematic screensaver selected previously. -- 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 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)
https://bugs.freedesktop.org/show_bug.cgi?id=65274 --- Comment #3 from russianneuroman...@ya.ru --- I sure, I download and overwrite it before trying rc4. md5 of currently used SUMO_rlc.bin: 687e72d53413710b0a3e9330333b2dbe. -- 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 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
https://bugs.freedesktop.org/show_bug.cgi?id=65192 --- Comment #7 from Luzipher --- Update: The crash just triggered with a fullscreen youtube video, after a few seconds of playing. -- 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 65310] New: [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576
https://bugs.freedesktop.org/show_bug.cgi?id=65310 Priority: medium Bug ID: 65310 Assignee: dri-devel@lists.freedesktop.org Summary: [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576 Severity: critical Classification: Unclassified OS: Linux (All) Reporter: david.ro...@mcgill.ca Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa I'm trying to build today's git/master on a slackware box. i get the following: /bin/sh ../../../../libtool --tag=CC --mode=compile /usr/bin/gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"9.2.0\" -DPACKAGE_STRING=\"Mesa\ 9.2.0\" -DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi\?product=Mesa\"; -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"9.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1 -DHAVE_PTHREAD=1 -DHAVE_LIBEXPAT=1 -I. -I../../../../src/gallium/drivers -I../../../../include -I../../../../include -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS -I/usr/include/libdrm -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -MT nvc0_vbo.lo -MD -MP -MF .deps/nvc0_vbo.Tpo -c -o nvc0_vbo.lo nvc0_vbo.c libtool: compile: /usr/bin/gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"9.2.0\" "-DPACKAGE_STRING=\"Mesa 9.2.0\"" "-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\""; -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"9.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1 -DHAVE_PTHREAD=1 -DHAVE_LIBEXPAT=1 -I. -I../../../../src/gallium/drivers -I../../../../include -I../../../../include -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS -I/usr/include/libdrm -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -MT nvc0_vbo.lo -MD -MP -MF .deps/nvc0_vbo.Tpo -c nvc0_vbo.c -fPIC -DPIC -o .libs/nvc0_vbo.o /tmp/cc6sw2Xe.s: Assembler messages: /tmp/cc6sw2Xe.s:1270: Error: missing or invalid displacement expression `-8589934576' /tmp/cc6sw2Xe.s:1277: Error: missing or invalid displacement expression `-8589934560' /tmp/cc6sw2Xe.s:1284: Error: missing or invalid displacement expression `-8589934544' /tmp/cc6sw2Xe.s:2073: Error: missing or invalid displacement expression `-8589934576' /tmp/cc6sw2Xe.s:2079: Error: missing or invalid displacement expression `-8589934560' /tmp/cc6sw2Xe.s:2085: Error: missing or invalid displacement expression `-8589934544' /tmp/cc6sw2Xe.s:2091: Error: missing or invalid displacement expression `-8589934528' /tmp/cc6sw2Xe.s:2097: Error: missing or invalid displacement expression `-8589934512' /tmp/cc6sw2Xe.s:2103: Error: missing or invalid displacement expression `-8589934496' /tmp/cc6sw2Xe.s:2109: Error: missing or invalid displacement expression `-8589934480' make: *** [nvc0_vbo.lo] Error 1 I've configured with: $ ./configure --prefix=/usr --with-state-trackers=dri --disable-egl --with-gallium-drivers=nouveau --disable-gallium-llvm Finally, I just upgraded gcc to 4.8.1 (from 4.7.2), so this could be a compiler regression. -- 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 65310] [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576
https://bugs.freedesktop.org/show_bug.cgi?id=65310 --- Comment #1 from David Ronis --- I just rebuilt with less aggressive optimization flags. Instead of -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block I tried -O2 -fomit-frame-pointer It now compiles, so I guess that this is a compiler regression. -- 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 65254] opengl flicker in xbmc / glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=65254 --- Comment #7 from Vladi --- Created attachment 80242 --> https://bugs.freedesktop.org/attachment.cgi?id=80242&action=edit glxinfo -- 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: [i915] Backlight brighter since 3.9.0
On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote: > On 05/20/2013 02:55 PM, Daniel Vetter wrote: > >On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote: > >>Hallo, > >> > >>I hope this is the right place to ask, because I actually don't know > >>whether it is a bug or a feature that I'm experiencing since linux 3.9: > >>When I boot my system the backlight gets extremely bright compared to older > >>kernel versions. It is most obvious when I leave X (more a yellow than a > >>black background), but I have the impression, that the colors in X are > >>brighter than usual, too. > >>I used my spare time this afternoon to do a kernel bisect and learned that > >>the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I > >>don't have insight or understanding of the code: Is this behaviour intended > >>and how could I change it to the old state or is it a bug and should I > >>report it somewhere? > >>My system is as follows: > >>Intel i5-3570k with Intel HD 4000 > >>my monitor is connected via HDMI. > >>If you need any more information just tell me. > > > >Yeah, this is a feature. HDMI has (for oddball backwards compat with > >analog TV signals) a special mode which reduces the useable RGB value > >range by chopping off about 10% at the bottom and top end. This results in > >light colors getting brighter and dark colors getting darker. > > > >The above mentioned commit tries (to the best of our knowledge) to > >auto-set the option which most likely fits what the hdmi sink will do with > >the color data. You can either fix this up in the hdmi sink with the > >on-screen menu or by manually setting the "RBG Broadcast" property for the > >relevant hdmi connector to the setting you want. > > This property seems like it's generally useful for all GPUs that > support range compression. Has anyone started the process of adding > it to randrproto.txt as an official property? > > http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n1723 Oops, I didn't know that we have some properties standardized there, especially since the existing pile of drm/kms drivers seem to only lously follow them. Should we move this into the kernel since that's essentially the place that defines them? -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: [i915] Backlight brighter since 3.9.0
On 06/03/2013 12:36 PM, Daniel Vetter wrote: On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote: On 05/20/2013 02:55 PM, Daniel Vetter wrote: On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote: Hallo, I hope this is the right place to ask, because I actually don't know whether it is a bug or a feature that I'm experiencing since linux 3.9: When I boot my system the backlight gets extremely bright compared to older kernel versions. It is most obvious when I leave X (more a yellow than a black background), but I have the impression, that the colors in X are brighter than usual, too. I used my spare time this afternoon to do a kernel bisect and learned that the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I don't have insight or understanding of the code: Is this behaviour intended and how could I change it to the old state or is it a bug and should I report it somewhere? My system is as follows: Intel i5-3570k with Intel HD 4000 my monitor is connected via HDMI. If you need any more information just tell me. Yeah, this is a feature. HDMI has (for oddball backwards compat with analog TV signals) a special mode which reduces the useable RGB value range by chopping off about 10% at the bottom and top end. This results in light colors getting brighter and dark colors getting darker. The above mentioned commit tries (to the best of our knowledge) to auto-set the option which most likely fits what the hdmi sink will do with the color data. You can either fix this up in the hdmi sink with the on-screen menu or by manually setting the "RBG Broadcast" property for the relevant hdmi connector to the setting you want. This property seems like it's generally useful for all GPUs that support range compression. Has anyone started the process of adding it to randrproto.txt as an official property? http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n1723 Oops, I didn't know that we have some properties standardized there, especially since the existing pile of drm/kms drivers seem to only lously follow them. Should we move this into the kernel since that's essentially the place that defines them? Maybe? I think I'm the only one who even tries to follow those, so "SHOULD" and "MUST" don't really mean a whole lot right now. One option would be to just abandon the idea of standardizing properties, but I do think standardization is good. Where that standard should live, though, is a another question. The kernel doesn't seem like the right place since RandR properties are useful on lots of platforms other than Linux. -Daniel -- Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [i915] Backlight brighter since 3.9.0
On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner wrote: > On 06/03/2013 12:36 PM, Daniel Vetter wrote: >> >> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote: >>> >>> On 05/20/2013 02:55 PM, Daniel Vetter wrote: On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote: > > Hallo, > > I hope this is the right place to ask, because I actually don't know > whether it is a bug or a feature that I'm experiencing since linux 3.9: > When I boot my system the backlight gets extremely bright compared to > older > kernel versions. It is most obvious when I leave X (more a yellow than > a > black background), but I have the impression, that the colors in X are > brighter than usual, too. > I used my spare time this afternoon to do a kernel bisect and learned > that > the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As > I > don't have insight or understanding of the code: Is this behaviour > intended > and how could I change it to the old state or is it a bug and should I > report it somewhere? > My system is as follows: > Intel i5-3570k with Intel HD 4000 > my monitor is connected via HDMI. > If you need any more information just tell me. Yeah, this is a feature. HDMI has (for oddball backwards compat with analog TV signals) a special mode which reduces the useable RGB value range by chopping off about 10% at the bottom and top end. This results in light colors getting brighter and dark colors getting darker. The above mentioned commit tries (to the best of our knowledge) to auto-set the option which most likely fits what the hdmi sink will do with the color data. You can either fix this up in the hdmi sink with the on-screen menu or by manually setting the "RBG Broadcast" property for the relevant hdmi connector to the setting you want. >>> >>> >>> This property seems like it's generally useful for all GPUs that >>> support range compression. Has anyone started the process of adding >>> it to randrproto.txt as an official property? >>> >>> >>> http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n1723 >> >> >> Oops, I didn't know that we have some properties standardized there, >> especially since the existing pile of drm/kms drivers seem to only lously >> follow them. Should we move this into the kernel since that's essentially >> the place that defines them? > > > Maybe? I think I'm the only one who even tries to follow those, so "SHOULD" > and "MUST" don't really mean a whole lot right now. One option would be to > just abandon the idea of standardizing properties, but I do think > standardization is good. Where that standard should live, though, is a > another question. The kernel doesn't seem like the right place since RandR > properties are useful on lots of platforms other than Linux. Yeah, I've read through that least and realized that for open-source drivers we have a different reality. And we do sometimes get bug reports from userspace guys complaining about the mismatch between the standard (followed by you guys) and the "evolved" standard (I know, lipstick on a pig) used by all the open-source drivers. My thinking behind putting this in the kernel is that current X open-source drivers just pass properties through (mostly) and that other compositors like wayland (or gralloc/hw_composer) would have one place to reference. Dunno what to do. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [i915] Backlight brighter since 3.9.0
On Mon, Jun 3, 2013 at 4:03 PM, Daniel Vetter wrote: > On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner wrote: >> On 06/03/2013 12:36 PM, Daniel Vetter wrote: >>> >>> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote: On 05/20/2013 02:55 PM, Daniel Vetter wrote: > > On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote: >> >> Hallo, >> >> I hope this is the right place to ask, because I actually don't know >> whether it is a bug or a feature that I'm experiencing since linux 3.9: >> When I boot my system the backlight gets extremely bright compared to >> older >> kernel versions. It is most obvious when I leave X (more a yellow than >> a >> black background), but I have the impression, that the colors in X are >> brighter than usual, too. >> I used my spare time this afternoon to do a kernel bisect and learned >> that >> the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As >> I >> don't have insight or understanding of the code: Is this behaviour >> intended >> and how could I change it to the old state or is it a bug and should I >> report it somewhere? >> My system is as follows: >> Intel i5-3570k with Intel HD 4000 >> my monitor is connected via HDMI. >> If you need any more information just tell me. > > > Yeah, this is a feature. HDMI has (for oddball backwards compat with > analog TV signals) a special mode which reduces the useable RGB value > range by chopping off about 10% at the bottom and top end. This results > in > light colors getting brighter and dark colors getting darker. > > The above mentioned commit tries (to the best of our knowledge) to > auto-set the option which most likely fits what the hdmi sink will do > with > the color data. You can either fix this up in the hdmi sink with the > on-screen menu or by manually setting the "RBG Broadcast" property for > the > relevant hdmi connector to the setting you want. This property seems like it's generally useful for all GPUs that support range compression. Has anyone started the process of adding it to randrproto.txt as an official property? http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n1723 >>> >>> >>> Oops, I didn't know that we have some properties standardized there, >>> especially since the existing pile of drm/kms drivers seem to only lously >>> follow them. Should we move this into the kernel since that's essentially >>> the place that defines them? >> >> >> Maybe? I think I'm the only one who even tries to follow those, so "SHOULD" >> and "MUST" don't really mean a whole lot right now. One option would be to >> just abandon the idea of standardizing properties, but I do think >> standardization is good. Where that standard should live, though, is a >> another question. The kernel doesn't seem like the right place since RandR >> properties are useful on lots of platforms other than Linux. > > Yeah, I've read through that least and realized that for open-source > drivers we have a different reality. And we do sometimes get bug > reports from userspace guys complaining about the mismatch between the > standard (followed by you guys) and the "evolved" standard (I know, > lipstick on a pig) used by all the open-source drivers. > > My thinking behind putting this in the kernel is that current X > open-source drivers just pass properties through (mostly) and that > other compositors like wayland (or gralloc/hw_composer) would have one > place to reference. Dunno what to do. We standardized on the scaler KMS connector properties, but the randr ones are still device specific for compatibility reasons. Also, things like the scaler are generally actually crtc properties rather than connector properties, but randr and KMS don't really have the same display object abstractions. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65316] New: [r600g] Game window turns completely black occasionally in WoW.
https://bugs.freedesktop.org/show_bug.cgi?id=65316 Priority: medium Bug ID: 65316 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g] Game window turns completely black occasionally in WoW. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ranki...@googlemail.com Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa When playing WoW in 32 bit mode, the game window occasionally turns completely black for a second or two before correctly redrawing itself. However, the UI elements remain visible throughout. I have reproduced this problem with a RV730XT card (HD4670 AGP) and a CAICOS HD6450, but not with my RV790. Note that the HD4670 AGP can only run in 32 bit mode, but the CAICOS runs WoW correctly in 64 bit mode. This is not a new problem (at all!), but I have only recently discovered that it happens with my CAICOS card in 32 bit mode while I was investigating a bug with the sound. -- 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 0/5] drm/tilcdc: bug fixes, mode selection improvements
On Mon, Jun 3, 2013 at 4:59 PM, Darren Etheridge wrote: > The series of patches that follow are intended to address issues that > have been found in the tilcdc drm driver. The patchset enables support > for screen resolutions with horizontal resolutions greater than 1024 > pixels. The patchset also addresses a limitation where certain > monitor timings would overflow LCD controller timing registers causing > either no monitor signal or a very corrupted display. This patchset > will stop monitor modes from being reported as valid if the lcd > controller cannot support them. Looks good, thanks! For the series: Signed-off-by: Rob Clark > Applies cleanly on 3.10rc4. > > Darren Etheridge (5): > drm/tilcdc: support pixel widths greater than 1024 > drm/tilcdc: adding some more devicetree config > drm/tilcdc: fixing off by one errors found on analyzer > drm/tilcdc: adding more guards to present selection of invalid modes > drm/tilcdc: whitespace fixes and tidyup > > .../devicetree/bindings/drm/tilcdc/tilcdc.txt |8 ++ > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 115 > +--- > drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +++- > drivers/gpu/drm/tilcdc/tilcdc_drv.h| 22 > drivers/gpu/drm/tilcdc/tilcdc_regs.h |1 + > 5 files changed, 147 insertions(+), 14 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64867] Hangs on Cayman (HD6950) when watching flash/using vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=64867 --- Comment #2 from Harald Judt --- I too get system hangs when watching a flash video in firefox. linux-3.8.13, libdrm, mesa etc. git. Screen simply becomes black (no signal) and machine is dead, leaving a hard reset as the only option. The dmesg is flooded with the following lines: radeon :01:00.0: GPU fault detected: 147 0x0d859002 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x12D8 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x05090002 [...] repeated a hundred times with only the first line changing a bit [...] then: radeon :01:00.0: GPU fault detected: 146 0x07151004 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [...] repeated a hundred times with only the first line changing a bit [...] Times indicate this goes on for approximately two minutes before the hang. -- 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 64867] Hangs on Cayman (HD6950) when watching flash/using vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=64867 --- Comment #3 from Alex Deucher --- (In reply to comment #2) > I too get system hangs when watching a flash video in firefox. linux-3.8.13, > libdrm, mesa etc. git. Screen simply becomes black (no signal) and machine > is dead, leaving a hard reset as the only option. The dmesg is flooded with > the following lines: > > radeon :01:00.0: GPU fault detected: 147 0x0d859002 > radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x12D8 > radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x05090002 > [...] repeated a hundred times with only the first line changing a bit [...] Something in the mesa drivers is emitting a command buffer without a proper virtual address for CB5. -- 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] video: display_timing: make parameter const
Hi,
On Monday 27 May 2013 14:33:05 Lucas Stach wrote:
> From: Steffen Trumtrar
>
> As the device_node pointer is not changed in of_get_display_timing and
> parse_timing_property it can be a const pointer.
>
> Signed-off-by: Steffen Trumtrar
Acked-by: Laurent Pinchart
> ---
> drivers/video/of_display_timing.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/of_display_timing.c
> b/drivers/video/of_display_timing.c index 56009bc..85c1a41 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -23,7 +23,7 @@
> * Every display_timing can be specified with either just the typical value
> or * a range consisting of min/typ/max. This function helps handling this
> **/
> -static int parse_timing_property(struct device_node *np, const char *name,
> +static int parse_timing_property(const struct device_node *np, const char
> *name, struct timing_entry *result)
> {
> struct property *prop;
> @@ -56,7 +56,8 @@ static int parse_timing_property(struct device_node *np,
> const char *name, * of_get_display_timing - parse display_timing entry from
> device_node * @np: device_node with the properties
> **/
> -static struct display_timing *of_get_display_timing(struct device_node *np)
> +static struct display_timing *of_get_display_timing(const struct
> device_node + *np)
> {
> struct display_timing *dt;
> u32 val = 0;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add drm_plane_force_disable()
Hi Ville,
Thanks for the patch.
On Monday 03 June 2013 16:10:40 ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> drm_plane_force_disable() will forcibly disable the plane even if user
> had previously requested the plane to be enabled.
>
> This can be used to force planes to be off when restoring the fbdev
> mode.
>
> The code was simply pulled from drm_framebuffer_remove(), which now
> calls the new function as well.
>
> v2: Check plane->fb in drm_plane_force_disable(), drop bogus comment
> about disabling crtc
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c | 29 +++--
> include/drm/drm_crtc.h | 1 +
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e7e9242..865ebfe 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -569,16 +569,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
> }
>
> list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> - if (plane->fb == fb) {
> - /* should turn off the crtc */
> - ret = plane->funcs->disable_plane(plane);
> - if (ret)
> - DRM_ERROR("failed to disable plane with
> busy fb\n");
> - /* disconnect the plane from the fb and crtc: */
> - __drm_framebuffer_unreference(plane->fb);
> - plane->fb = NULL;
> - plane->crtc = NULL;
> - }
> + if (plane->fb == fb)
> + drm_plane_force_disable(plane);
> }
> drm_modeset_unlock_all(dev);
> }
> @@ -867,6 +859,23 @@ void drm_plane_cleanup(struct drm_plane *plane)
> }
> EXPORT_SYMBOL(drm_plane_cleanup);
What about adding kerneldoc ? :-)
> +void drm_plane_force_disable(struct drm_plane *plane)
> +{
> + int ret;
> +
> + if (!plane->fb)
> + return;
> +
> + ret = plane->funcs->disable_plane(plane);
> + if (ret)
> + DRM_ERROR("failed to disable plane with busy fb\n");
> + /* disconnect the plane from the fb and crtc: */
> + __drm_framebuffer_unreference(plane->fb);
> + plane->fb = NULL;
> + plane->crtc = NULL;
> +}
> +EXPORT_SYMBOL(drm_plane_force_disable);
> +
> /**
> * drm_mode_create - create a new display mode
> * @dev: DRM device
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index adb3f9b..db7a885 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -894,6 +894,7 @@ extern int drm_plane_init(struct drm_device *dev,
> const uint32_t *formats, uint32_t format_count,
> bool priv);
> extern void drm_plane_cleanup(struct drm_plane *plane);
> +extern void drm_plane_force_disable(struct drm_plane *plane);
>
> extern void drm_encoder_cleanup(struct drm_encoder *encoder);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65327] New: running gnubik produces a segfault
https://bugs.freedesktop.org/show_bug.cgi?id=65327
Priority: medium
Bug ID: 65327
Assignee: dri-devel@lists.freedesktop.org
Summary: running gnubik produces a segfault
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: pin...@gmail.com
Hardware: x86 (IA32)
Status: NEW
Version: unspecified
Component: DRM/Radeon
Product: DRI
Created attachment 80263
--> https://bugs.freedesktop.org/attachment.cgi?id=80263&action=edit
bt full
X.Org X Server 1.13.3
Fedora release 18 (Spherical Cow)
bash-4.2$ lspci -v|grep ATI
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV350
AP [Radeon 9600] (prog-if 00 [VGA controller])
02:00.1 Display controller: Advanced Micro Devices [AMD] nee ATI RV350 AP
[Radeon 9600] (Secondary)
When I run gnubik (a game), the program segfaults immediately:
bash-4.2$ gnubik
Segmentation fault (core dumped)
bash-4.2$ dmesg|tail -n 1
[ 5769.578454] gnubik[7155]: segfault at 0 ip (null) sp bfafcbbc
error 4 in gnubik[8048000+16000]
bash-4.2$ rpm -q gnubik
gnubik-2.4-5.fc18.i686
bash-4.2$ gnubik -v|head -n 1
2.4
#0 0x in ?? ()
#1 0xb217e6f4 in generic_run () from /usr/lib/dri/r300_dri.so
#2 0xb214ae9c in draw_pt_fetch_run_linear ()
from /usr/lib/dri/r300_dri.so
it segfaults on line 646
(gdb) l translate/translate_generic.c:646
641 copy_size = tg->attrib[attr].copy_size;
642 if(likely(copy_size >= 0))
643memcpy(dst, src, copy_size);
644 else
645 {
646tg->attrib[attr].fetch( data, src, 0, 0 );
647
648if (0)
649 debug_printf("Fetch linear attr %d from %p
stride %d index %d: " 650 " %f, %f,
%f, %f \n", (gdb)
the bugtrace is attached
Should any additional info be required, I may provide it.
--
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 2/5] drm/tilcdc: adding some more devicetree config
Adding support for max-pixelclock and max-width device tree
entries. As some devices that use the tilcdc hardware module
have restrictions on the allowed/tested values. Also update DT
bindings document to reflect new parameters.
Signed-off-by: Darren Etheridge
---
.../devicetree/bindings/drm/tilcdc/tilcdc.txt |8 +++
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 23 ++-
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 -
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 22 +++
4 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index e5f1301..fff10da 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -10,6 +10,14 @@ Recommended properties:
services interrupts for this device.
- ti,hwmods: Name of the hwmod associated to the LCDC
+Optional properties:
+ - max-bandwidth: The maximum pixels per second that the memory
+ interface / lcd controller combination can sustain
+ - max-width: The maximum horizontal pixel width supported by
+ the lcd controller.
+ - max-pixelclock: The maximum pixel clock that can be supported
+ by the lcd controller in KHz.
+
Example:
fb: fb@4830e000 {
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 84fdf25..05f2b14 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -448,10 +448,29 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct
drm_display_mode *mode)
if (mode->vdisplay > 2048)
return MODE_VIRTUAL_Y;
+ /*
+* some devices have a maximum allowed pixel clock
+* configured from the DT
+*/
+ if (mode->clock > priv->max_pixelclock) {
+ DBG("Pruning mode, pixel clock too high");
+ return MODE_CLOCK_HIGH;
+ }
+
+ /*
+* some devices further limit the max horizontal resolution
+* configured from the DT
+*/
+ if (mode->hdisplay > priv->max_width)
+ return MODE_BAD_WIDTH;
+
/* filter out modes that would require too much memory bandwidth: */
- bandwidth = mode->hdisplay * mode->vdisplay * drm_mode_vrefresh(mode);
- if (bandwidth > priv->max_bandwidth)
+ bandwidth = mode->hdisplay * mode->vdisplay *
+ drm_mode_vrefresh(mode);
+ if (bandwidth > priv->max_bandwidth) {
+ DBG("Pruning mode, exceeds defined bandwidth limit");
return MODE_BAD;
+ }
return MODE_OK;
}
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 2b5461b..b40fa91 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -210,7 +210,20 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
#endif
if (of_property_read_u32(node, "max-bandwidth", &priv->max_bandwidth))
- priv->max_bandwidth = 1280 * 1024 * 60;
+ priv->max_bandwidth = TILCDC_DEFAULT_MAX_BANDWIDTH;
+
+ DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
+
+ if (of_property_read_u32(node, "ti,max-width", &priv->max_width))
+ priv->max_width = TILCDC_DEFAULT_MAX_WIDTH;
+
+ DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
+
+ if (of_property_read_u32(node, "ti,max-pixelclock",
+ &priv->max_pixelclock))
+ priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCLOCK;
+
+ DBG("Maximum Pixel Clock Value %dKHz", priv->max_pixelclock);
pm_runtime_enable(dev->dev);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 8242b5a..edb89a5 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -34,6 +34,18 @@
#include
#include
+/* Defaulting to pixel clock defined on AM335x */
+#define TILCDC_DEFAULT_MAX_PIXELCLOCK 126000
+/* Defaulting to max width as defined on AM335x */
+#define TILCDC_DEFAULT_MAX_WIDTH 2048
+/*
+ * This may need some tweaking, but want to allow at least 1280x1024@60
+ * with optimized DDR & EMIF settings tweaked 1920x1080@24 appears to
+ * be supportable
+ */
+#define TILCDC_DEFAULT_MAX_BANDWIDTH (1280*1024*60)
+
+
struct tilcdc_drm_private {
void __iomem *mmio;
@@ -43,6 +55,16 @@ struct tilcdc_drm_private {
/* don't attempt resolutions w/ higher W * H * Hz: */
uint32_t max_bandwidth;
+ /*
+* Pixel Clock will be restricted to some value as
+* defined in the device datasheet measured in KHz
+*/
+ uint32_t max_pixelclock;
+ /*
+* Max allowable width is limited on a per device basis
+* meas
[PATCH 0/5] drm/tilcdc: bug fixes, mode selection improvements
The series of patches that follow are intended to address issues that have been found in the tilcdc drm driver. The patchset enables support for screen resolutions with horizontal resolutions greater than 1024 pixels. The patchset also addresses a limitation where certain monitor timings would overflow LCD controller timing registers causing either no monitor signal or a very corrupted display. This patchset will stop monitor modes from being reported as valid if the lcd controller cannot support them. Applies cleanly on 3.10rc4. Darren Etheridge (5): drm/tilcdc: support pixel widths greater than 1024 drm/tilcdc: adding some more devicetree config drm/tilcdc: fixing off by one errors found on analyzer drm/tilcdc: adding more guards to present selection of invalid modes drm/tilcdc: whitespace fixes and tidyup .../devicetree/bindings/drm/tilcdc/tilcdc.txt |8 ++ drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 115 +--- drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +++- drivers/gpu/drm/tilcdc/tilcdc_drv.h| 22 drivers/gpu/drm/tilcdc/tilcdc_regs.h |1 + 5 files changed, 147 insertions(+), 14 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/tilcdc: fixing off by one errors found on analyzer
When hooking up to an HDMI analyzer noticed some timings were
off by one. Referring to the hardware technical reference manual
for the lcd controller some of the timing registers use 0 to
represent 1. This patch addresses that issue.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 05f2b14..4455a41 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -289,17 +289,22 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
reg = tilcdc_read(dev, LCDC_RASTER_TIMING_2_REG) & ~0x000fff00;
reg |= LCDC_AC_BIAS_FREQUENCY(info->ac_bias) |
LCDC_AC_BIAS_TRANSITIONS_PER_INT(info->ac_bias_intrpt);
+
+ /*
+* subtract one from hfp, hbp, hsw because the hardware uses
+* a value of 0 as 1
+*/
if (priv->rev == 2) {
- reg |= (hfp & 0x300) >> 8;
- reg |= (hbp & 0x300) >> 4;
- reg |= (hsw & 0x3c0) << 21;
+ reg |= ((hfp-1) & 0x300) >> 8;
+ reg |= ((hbp-1) & 0x300) >> 4;
+ reg |= ((hsw-1) & 0x3c0) << 21;
}
tilcdc_write(dev, LCDC_RASTER_TIMING_2_REG, reg);
reg = (((mode->hdisplay >> 4) - 1) << 4) |
- ((hbp & 0xff) << 24) |
- ((hfp & 0xff) << 16) |
- ((hsw & 0x3f) << 10);
+ (((hbp-1) & 0xff) << 24) |
+ (((hfp-1) & 0xff) << 16) |
+ (((hsw-1) & 0x3f) << 10);
if (priv->rev == 2)
reg |= (((mode->hdisplay >> 4) - 1) & 0x40) >> 3;
tilcdc_write(dev, LCDC_RASTER_TIMING_0_REG, reg);
@@ -307,7 +312,7 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
reg = ((mode->vdisplay - 1) & 0x3ff) |
((vbp & 0xff) << 24) |
((vfp & 0xff) << 16) |
- ((vsw & 0x3f) << 10);
+ (((vsw-1) & 0x3f) << 10);
tilcdc_write(dev, LCDC_RASTER_TIMING_1_REG, reg);
/*
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/tilcdc: adding more guards to present selection of invalid modes
The tilcdc has a number of limitations for the allowed sizes of
the various adjustable timing parameter. Some modes are outside
of these timings. This commit will prune modes that report timings
that will overflow the allowed sizes in the tilcdc.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 4455a41..283e0a6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -442,7 +442,12 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct
drm_display_mode *mode)
{
struct tilcdc_drm_private *priv = crtc->dev->dev_private;
unsigned int bandwidth;
+ uint32_t hbp, hfp, hsw, vbp, vfp, vsw;
+ /*
+* check to see if the width is within the range that
+* the LCD Controller physically supports
+*/
if (mode->hdisplay > tilcdc_crtc_max_width(crtc))
return MODE_VIRTUAL_X;
@@ -453,6 +458,47 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct
drm_display_mode *mode)
if (mode->vdisplay > 2048)
return MODE_VIRTUAL_Y;
+ DBG("Processing mode %dx%d@%d with pixel clock %d",
+ mode->hdisplay, mode->vdisplay,
+ drm_mode_vrefresh(mode), mode->clock);
+
+ hbp = mode->htotal - mode->hsync_end;
+ hfp = mode->hsync_start - mode->hdisplay;
+ hsw = mode->hsync_end - mode->hsync_start;
+ vbp = mode->vtotal - mode->vsync_end;
+ vfp = mode->vsync_start - mode->vdisplay;
+ vsw = mode->vsync_end - mode->vsync_start;
+
+ if ((hbp-1) & ~0x3ff) {
+ DBG("Pruning mode: Horizontal Back Porch out of range");
+ return MODE_HBLANK_WIDE;
+ }
+
+ if ((hfp-1) & ~0x3ff) {
+ DBG("Pruning mode: Horizontal Front Porch out of range");
+ return MODE_HBLANK_WIDE;
+ }
+
+ if ((hsw-1) & ~0x3ff) {
+ DBG("Pruning mode: Horizontal Sync Width out of range");
+ return MODE_HSYNC_WIDE;
+ }
+
+ if (vbp & ~0xff) {
+ DBG("Pruning mode: Vertical Back Porch out of range");
+ return MODE_VBLANK_WIDE;
+ }
+
+ if (vfp & ~0xff) {
+ DBG("Pruning mode: Vertical Front Porch out of range");
+ return MODE_VBLANK_WIDE;
+ }
+
+ if ((vsw-1) & ~0x3f) {
+ DBG("Pruning mode: Vertical Sync Width out of range");
+ return MODE_VSYNC_WIDE;
+ }
+
/*
* some devices have a maximum allowed pixel clock
* configured from the DT
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/tilcdc: whitespace fixes and tidyup
keeping checkpatch happy.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 283e0a6..6118651 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -42,7 +42,8 @@ struct tilcdc_crtc {
static void unref_worker(struct work_struct *work)
{
- struct tilcdc_crtc *tilcdc_crtc = container_of(work, struct
tilcdc_crtc, work);
+ struct tilcdc_crtc *tilcdc_crtc =
+ container_of(work, struct tilcdc_crtc, work);
struct drm_device *dev = tilcdc_crtc->base.dev;
struct drm_framebuffer *fb;
@@ -55,10 +56,12 @@ static void unref_worker(struct work_struct *work)
static void set_scanout(struct drm_crtc *crtc, int n)
{
static const uint32_t base_reg[] = {
- LCDC_DMA_FB_BASE_ADDR_0_REG,
LCDC_DMA_FB_BASE_ADDR_1_REG,
+ LCDC_DMA_FB_BASE_ADDR_0_REG,
+ LCDC_DMA_FB_BASE_ADDR_1_REG,
};
static const uint32_t ceil_reg[] = {
- LCDC_DMA_FB_CEILING_ADDR_0_REG,
LCDC_DMA_FB_CEILING_ADDR_1_REG,
+ LCDC_DMA_FB_CEILING_ADDR_0_REG,
+ LCDC_DMA_FB_CEILING_ADDR_1_REG,
};
static const uint32_t stat[] = {
LCDC_END_OF_FRAME0, LCDC_END_OF_FRAME1,
@@ -194,7 +197,8 @@ static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int
mode)
tilcdc_crtc->frame_done = false;
stop(crtc);
- /* if necessary wait for framedone irq which will still come
+ /*
+* if necessary wait for framedone irq which will still come
* before putting things to sleep..
*/
if (priv->rev == 2) {
@@ -504,7 +508,7 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct
drm_display_mode *mode)
* configured from the DT
*/
if (mode->clock > priv->max_pixelclock) {
- DBG("Pruning mode, pixel clock too high");
+ DBG("Pruning mode: pixel clock too high");
return MODE_CLOCK_HIGH;
}
@@ -519,7 +523,7 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct
drm_display_mode *mode)
bandwidth = mode->hdisplay * mode->vdisplay *
drm_mode_vrefresh(mode);
if (bandwidth > priv->max_bandwidth) {
- DBG("Pruning mode, exceeds defined bandwidth limit");
+ DBG("Pruning mode: exceeds defined bandwidth limit");
return MODE_BAD;
}
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/tilcdc: support pixel widths greater than 1024
TI LCD controller version 2 has an extended eleventh
bit that enables horizontal resolutions greater than
1024 pixels to be specified (upto 2048). This patch
adds support for setting this bit on LCDC V2.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 15 +++
drivers/gpu/drm/tilcdc/tilcdc_regs.h |1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 5dd3c7d..84fdf25 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -310,6 +310,21 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
((vsw & 0x3f) << 10);
tilcdc_write(dev, LCDC_RASTER_TIMING_1_REG, reg);
+ /*
+* be sure to set Bit 10 for the V2 LCDC controller,
+* otherwise limited to 1024 pixels width, stopping
+* 1920x1080 being suppoted.
+*/
+ if (priv->rev == 2) {
+ if ((mode->vdisplay - 1) & 0x400) {
+ tilcdc_set(dev, LCDC_RASTER_TIMING_2_REG,
+ LCDC_LPP_B10);
+ } else {
+ tilcdc_clear(dev, LCDC_RASTER_TIMING_2_REG,
+ LCDC_LPP_B10);
+ }
+ }
+
/* Configure display type: */
reg = tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
~(LCDC_TFT_MODE | LCDC_MONO_8BIT_MODE | LCDC_MONOCHROME_MODE |
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 17fd1b4..1bf5e25 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -80,6 +80,7 @@
#define LCDC_INVERT_PIXEL_CLOCK BIT(22)
#define LCDC_INVERT_HSYNCBIT(21)
#define LCDC_INVERT_VSYNCBIT(20)
+#define LCDC_LPP_B10 BIT(26)
/* LCDC Block */
#define LCDC_PID_REG 0x0
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/gem: Split drm_gem_mmap() into object search and object mapping
The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem.c | 83 +--
include/drm/drmP.h| 2 ++
2 files changed, 54 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index cf919e3..4321713 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -644,6 +644,55 @@ void drm_gem_vm_close(struct vm_area_struct *vma)
}
EXPORT_SYMBOL(drm_gem_vm_close);
+/**
+ * drm_gem_mmap_obj - memory map a GEM object
+ * @obj: the GEM object to map
+ * @obj_size: the object size to be mapped, in bytes
+ * @vma: VMA for the area to be mapped
+ *
+ * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops
+ * provided by the driver. Depending on their requirements, drivers can either
+ * provide a fault handler in their gem_vm_ops (in which case any accesses to
+ * the object will be trapped, to perform migration, GTT binding, surface
+ * register allocation, or performance monitoring), or mmap the buffer memory
+ * synchronously after calling drm_gem_mmap_obj.
+ *
+ * This function is mainly intended to implement the DMABUF mmap operation,
when
+ * the GEM object is not looked up based on its fake offset. To implement the
+ * DRM mmap operation, drivers should use the drm_gem_mmap() function.
+ *
+ * Return 0 or success or -EINVAL if the object size is smaller than the VMA
+ * size, or if no gem_vm_ops are provided.
+ */
+int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
+struct vm_area_struct *vma)
+{
+ struct drm_device *dev = obj->dev;
+
+ /* Check for valid size. */
+ if (obj_size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ if (!dev->driver->gem_vm_ops)
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ vma->vm_ops = dev->driver->gem_vm_ops;
+ vma->vm_private_data = obj;
+ vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+
+ /* Take a ref for this mapping of the object, so that the fault
+* handler can dereference the mmap offset's pointer to the object.
+* This reference is cleaned up by the corresponding vm_close
+* (which should happen whether the vma was created by this call, or
+* by a vm_open due to mremap or partial unmap or whatever).
+*/
+ drm_gem_object_reference(obj);
+
+ drm_vm_open_locked(dev, vma);
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_mmap_obj);
/**
* drm_gem_mmap - memory map routine for GEM objects
@@ -653,11 +702,9 @@ EXPORT_SYMBOL(drm_gem_vm_close);
* If a driver supports GEM object mapping, mmap calls on the DRM file
* descriptor will end up here.
*
- * If we find the object based on the offset passed in (vma->vm_pgoff will
+ * Look up the GEM object based on the offset passed in (vma->vm_pgoff will
* contain the fake offset we created when the GTT map ioctl was called on
- * the object), we set up the driver fault handler so that any accesses
- * to the object can be trapped, to perform migration, GTT binding, surface
- * register allocation, or performance monitoring.
+ * the object) and map it with a call to drm_gem_mmap_obj().
*/
int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
{
@@ -665,7 +712,6 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
struct drm_device *dev = priv->minor->dev;
struct drm_gem_mm *mm = dev->mm_private;
struct drm_local_map *map = NULL;
- struct drm_gem_object *obj;
struct drm_hash_item *hash;
int ret = 0;
@@ -686,32 +732,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
goto out_unlock;
}
- /* Check for valid size. */
- if (map->size < vma->vm_end - vma->vm_start) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- obj = map->handle;
- if (!obj->dev->driver->gem_vm_ops) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
- vma->vm_ops = obj->dev->driver->gem_vm_ops;
- vma->vm_private_data = map->handle;
- vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
-
- /* Take a ref for this mapping of the object, so that the fault
-* handler can dereference the mmap offset's pointer to the object.
-* This reference is cleaned up by the corresponding vm_close
-* (which should happen whether the vma was created by this call, or
-* by a vm_open due to mremap or partia
[PATCH v2 0/5] GEM CMA DMA-BUF support
Hello, Here's the second version of the GEM CMA DMA-BUF support patches. The code is based on the Exynos DRM DMA-BUF implementation. The exporter role has been successfully tested with the Renesas R-Car DU driver. Dave, is there a chance this could make it to v3.11 ? Changes compared to v1: - Added a mixing sg_free_table() in drm_gem_cma_dmabuf_map() - Implement drm_gem_cma_dmabuf_mmap() Laurent Pinchart (5): drm/gem: Split drm_gem_mmap() into object search and object mapping drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap drm: GEM CMA: Split object creation into object alloc and DMA memory alloc drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping drm: GEM CMA: Add DRM PRIME support drivers/gpu/drm/drm_gem.c | 83 +++--- drivers/gpu/drm/drm_gem_cma_helper.c | 408 +++--- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32 +-- include/drm/drmP.h| 2 + include/drm/drm_gem_cma_helper.h | 9 + 5 files changed, 438 insertions(+), 96 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm: GEM CMA: Split object creation into object alloc and DMA memory alloc
This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 83 +---
1 file changed, 48 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 0a7e011..8cce330 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -32,62 +32,73 @@ static unsigned int get_gem_mmap_offset(struct
drm_gem_object *obj)
return (unsigned int)obj->map_list.hash.key << PAGE_SHIFT;
}
-static void drm_gem_cma_buf_destroy(struct drm_device *drm,
- struct drm_gem_cma_object *cma_obj)
-{
- dma_free_writecombine(drm->dev, cma_obj->base.size, cma_obj->vaddr,
- cma_obj->paddr);
-}
-
/*
- * drm_gem_cma_create - allocate an object with the given size
+ * __drm_gem_cma_create - Create a GEM CMA object without allocating memory
+ * @drm: The drm device
+ * @size: The GEM object size
*
- * returns a struct drm_gem_cma_object* on success or ERR_PTR values
- * on failure.
+ * This function creates and initializes a GEM CMA object of the given size,
but
+ * doesn't allocate any memory to back the object.
+ *
+ * Return a struct drm_gem_cma_object* on success or ERR_PTR values on failure.
*/
-struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
- unsigned int size)
+static struct drm_gem_cma_object *
+__drm_gem_cma_create(struct drm_device *drm, unsigned int size)
{
struct drm_gem_cma_object *cma_obj;
struct drm_gem_object *gem_obj;
int ret;
- size = round_up(size, PAGE_SIZE);
-
cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
if (!cma_obj)
return ERR_PTR(-ENOMEM);
- cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
- &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
- if (!cma_obj->vaddr) {
- dev_err(drm->dev, "failed to allocate buffer with size %d\n",
size);
- ret = -ENOMEM;
- goto err_dma_alloc;
- }
-
gem_obj = &cma_obj->base;
ret = drm_gem_object_init(drm, gem_obj, size);
if (ret)
- goto err_obj_init;
+ goto error;
ret = drm_gem_create_mmap_offset(gem_obj);
- if (ret)
- goto err_create_mmap_offset;
+ if (ret) {
+ drm_gem_object_release(gem_obj);
+ goto error;
+ }
return cma_obj;
-err_create_mmap_offset:
- drm_gem_object_release(gem_obj);
+error:
+ kfree(cma_obj);
+ return ERR_PTR(ret);
+}
-err_obj_init:
- drm_gem_cma_buf_destroy(drm, cma_obj);
+/*
+ * drm_gem_cma_create - allocate an object with the given size
+ *
+ * returns a struct drm_gem_cma_object* on success or ERR_PTR values
+ * on failure.
+ */
+struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
+ unsigned int size)
+{
+ struct drm_gem_cma_object *cma_obj;
-err_dma_alloc:
- kfree(cma_obj);
+ size = round_up(size, PAGE_SIZE);
- return ERR_PTR(ret);
+ cma_obj = __drm_gem_cma_create(drm, size);
+ if (IS_ERR(cma_obj))
+ return cma_obj;
+
+ cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
+ &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
+ if (!cma_obj->vaddr) {
+ dev_err(drm->dev, "failed to allocate buffer with size %d\n",
+ size);
+ drm_gem_cma_free_object(&cma_obj->base);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return cma_obj;
}
EXPORT_SYMBOL_GPL(drm_gem_cma_create);
@@ -143,11 +154,13 @@ void drm_gem_cma_free_object(struct drm_gem_object
*gem_obj)
if (gem_obj->map_list.map)
drm_gem_free_mmap_offset(gem_obj);
- drm_gem_object_release(gem_obj);
-
cma_obj = to_drm_gem_cma_obj(gem_obj);
- drm_gem_cma_buf_destroy(gem_obj->dev, cma_obj);
+ if (cma_obj->vaddr)
+ dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
+ cma_obj->vaddr, cma_obj->paddr);
+
+ drm_gem_object_release(gem_obj);
kfree(cma_obj);
}
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
The dma-buf mmap code was copied from the GEM mmap implementation.
Replace it with the new drm_gem_mmap_obj() function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 32 +++
1 file changed, 3 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index be7cd97..3256693 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -136,10 +136,6 @@ static void omap_gem_dmabuf_kunmap(struct dma_buf *buffer,
kunmap(pages[page_num]);
}
-/*
- * TODO maybe we can split up drm_gem_mmap to avoid duplicating
- * some here.. or at least have a drm_dmabuf_mmap helper.
- */
static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct vm_area_struct *vma)
{
@@ -149,31 +145,9 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
if (WARN_ON(!obj->filp))
return -EINVAL;
- /* Check for valid size. */
- if (omap_gem_mmap_size(obj) < vma->vm_end - vma->vm_start) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- if (!obj->dev->driver->gem_vm_ops) {
- ret = -EINVAL;
- goto out_unlock;
- }
-
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
- vma->vm_ops = obj->dev->driver->gem_vm_ops;
- vma->vm_private_data = obj;
- vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
-
- /* Take a ref for this mapping of the object, so that the fault
-* handler can dereference the mmap offset's pointer to the object.
-* This reference is cleaned up by the corresponding vm_close
-* (which should happen whether the vma was created by this call, or
-* by a vm_open due to mremap or partial unmap or whatever).
-*/
- vma->vm_ops->open(vma);
-
-out_unlock:
+ ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
+ if (ret < 0)
+ return ret;
return omap_gem_mmap_obj(obj, vma);
}
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping
The CMA-specific mapping code will be used to implement dma-buf mmap
support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 8cce330..7a4db4e 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -228,13 +228,26 @@ const struct vm_operations_struct drm_gem_cma_vm_ops = {
};
EXPORT_SYMBOL_GPL(drm_gem_cma_vm_ops);
+static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object *cma_obj,
+ struct vm_area_struct *vma)
+{
+ int ret;
+
+ ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >> PAGE_SHIFT,
+ vma->vm_end - vma->vm_start, vma->vm_page_prot);
+ if (ret)
+ drm_gem_vm_close(vma);
+
+ return ret;
+}
+
/*
* drm_gem_cma_mmap - (struct file_operation)->mmap callback function
*/
int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
{
- struct drm_gem_object *gem_obj;
struct drm_gem_cma_object *cma_obj;
+ struct drm_gem_object *gem_obj;
int ret;
ret = drm_gem_mmap(filp, vma);
@@ -244,12 +257,7 @@ int drm_gem_cma_mmap(struct file *filp, struct
vm_area_struct *vma)
gem_obj = vma->vm_private_data;
cma_obj = to_drm_gem_cma_obj(gem_obj);
- ret = remap_pfn_range(vma, vma->vm_start, cma_obj->paddr >> PAGE_SHIFT,
- vma->vm_end - vma->vm_start, vma->vm_page_prot);
- if (ret)
- drm_gem_vm_close(vma);
-
- return ret;
+ return drm_gem_cma_mmap_obj(cma_obj, vma);
}
EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 321 ++-
include/drm/drm_gem_cma_helper.h | 9 +
2 files changed, 327 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7a4db4e..1dc2157 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -21,6 +21,9 @@
#include
#include
#include
+#if CONFIG_DMA_SHARED_BUFFER
+#include
+#endif
#include
#include
@@ -82,6 +85,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
unsigned int size)
{
struct drm_gem_cma_object *cma_obj;
+ struct sg_table *sgt = NULL;
+ int ret;
size = round_up(size, PAGE_SIZE);
@@ -94,11 +99,29 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
if (!cma_obj->vaddr) {
dev_err(drm->dev, "failed to allocate buffer with size %d\n",
size);
- drm_gem_cma_free_object(&cma_obj->base);
- return ERR_PTR(-ENOMEM);
+ ret = -ENOMEM;
+ goto error;
}
+ sgt = kzalloc(sizeof(*cma_obj->sgt), GFP_KERNEL);
+ if (sgt == NULL) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ ret = dma_get_sgtable(drm->dev, sgt, cma_obj->vaddr,
+ cma_obj->paddr, size);
+ if (ret < 0)
+ goto error;
+
+ cma_obj->sgt = sgt;
+
return cma_obj;
+
+error:
+ kfree(sgt);
+ drm_gem_cma_free_object(&cma_obj->base);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(drm_gem_cma_create);
@@ -156,9 +179,16 @@ void drm_gem_cma_free_object(struct drm_gem_object
*gem_obj)
cma_obj = to_drm_gem_cma_obj(gem_obj);
- if (cma_obj->vaddr)
+ if (cma_obj->vaddr) {
dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
cma_obj->vaddr, cma_obj->paddr);
+ if (cma_obj->sgt) {
+ sg_free_table(cma_obj->sgt);
+ kfree(cma_obj->sgt);
+ }
+ } else if (gem_obj->import_attach) {
+ drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
+ }
drm_gem_object_release(gem_obj);
@@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
*cma_obj, struct seq_file *m
}
EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
#endif
+
+/*
-
+ * DMA-BUF
+ */
+
+#if CONFIG_DMA_SHARED_BUFFER
+struct drm_gem_cma_dmabuf_attachment {
+ struct sg_table sgt;
+ enum dma_data_direction dir;
+};
+
+static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct device
*dev,
+struct dma_buf_attachment *attach)
+{
+ struct drm_gem_cma_dmabuf_attachment *cma_attach;
+
+ cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
+ if (!cma_attach)
+ return -ENOMEM;
+
+ cma_attach->dir = DMA_NONE;
+ attach->priv = cma_attach;
+
+ return 0;
+}
+
+static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+ struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
+ struct sg_table *sgt;
+
+ if (cma_attach == NULL)
+ return;
+
+ sgt = &cma_attach->sgt;
+
+ if (cma_attach->dir != DMA_NONE)
+ dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
+ cma_attach->dir);
+
+ sg_free_table(sgt);
+ kfree(cma_attach);
+ attach->priv = NULL;
+}
+
+static struct sg_table *
+drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
+{
+ struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
+ struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
+ struct drm_device *drm = cma_obj->base.dev;
+ struct scatterlist *rd, *wr;
+ struct sg_table *sgt;
+ unsigned int i;
+ int nents, ret;
+
+ DRM_DEBUG_PRIME("\n");
+
+ if (WARN_ON(dir == DMA_NONE))
+ return ERR_PTR(-EINVAL);
+
+ /* Return the cached mapping when possible. */
+ if (cma_attach->dir == dir)
+ return &cma_attach->sgt;
+
+ /* Two mappings with different directions for the same attachment are
+* not allowed.
+*/
+ if (WARN_ON(cma_attach->dir != DMA_NONE))
+ return ERR_PTR(-EBUSY);
+
+ sgt = &cma_attach->sgt;
+
+ ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
+ if (ret) {
+ DRM_ERROR("failed to alloc sgt.\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ mutex_lock(&drm->struct_mutex);
+
+
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #18 from Thilo Cestonaro --- Hey, latest raring with (ubuntu package versions) kernel- 3.8.0-23-generic mesa - 9.1.1-0ubuntu3 xserver-xorg-video-radeon - 7.1.0-0ubuntu2 xserver-xorg - 7.7+1ubuntu4 still showing the same problem. Greetings Thilo -- 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 65068] vgaswitcheroo doesn't deal with powered off dGPU on resume
https://bugs.freedesktop.org/show_bug.cgi?id=65068 --- Comment #6 from Austin Lund --- (In reply to comment #5) > (In reply to comment #4) > > I'm not sure if this has anything to do with this bug, but the PCI config > > space is all messed up when running on the integrated GPU: > > When you disable the GPU the hardware is physically powered off so you are > accessing non-existent registers. You need to power up the GPU using > vgaswitcheroo before loading/resuming the driver or access the config space > with lspci. I guess what I was trying to say was, does having the device in this state before you start suspend make the power management subsystem confused? Will it try to "restore" the pci configuration space to 0xff? The radeon GPU is definitely turned on by the firmware on resume and the apple-gmux driver turns it off if that was the state of the system when suspend was started. I tried a quick hack to call the "ON" function for vga-switcheroo from the apple-gmux driver suspend hook. But that didn't work. However, if I do it manually (i.e. echo ON > /sys/kernel/debug/vgaswitcheroo/switch) before suspend, then it does seem to fix it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/ae6d01b4/attachment.html>
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #53 from Austin Lund --- Fixed for my MacBookPro8,2 in 3.10-rc4. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/1e77e8f7/attachment.html>
[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"
On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk < konrad.wilk at oracle.com> wrote: > On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote: > > On 2013-05-26 23:09 +0200, Maarten Maathuis wrote: > > > > > My NV96 does not resume from suspend to ram (the screen stays black, > magic > > > sysrq keys do work) with the current linus git kernel, i bisected it > to the > > > following commit. > > > > > > drm/nv50/fifo: prevent races between clients updating playlists > > > b5096566f6e1ee2b88324772f020ae9bc0cfa9a0 > > > > > > It's not obvious to me how this causes problems, but reverting this > commit > > > does solve my problem. > > > > Same here on my NV86. > > And as well on this: > > 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 > GT] (rev a1) > > > Ben, any ideas? > I've pushed a fix[1] to my git tree. Will pull it across to the "normal" tree once I've hunted down another regression. Thanks, Ben. [1] http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=d37687a562f0b55cc848cfcdbf8d473a6c692c2d > > > Cheers, > >Sven > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/9c90d67f/attachment.html>
[PATCH] drm: fix a use-after-free when GPU acceleration disabled
Hi, Dave Why this patch hasn't been applied in your tree? I think you are the right maintainer. Huacai Chen On Tue, May 21, 2013 at 11:30 PM, Paul Menzel < paulepanter at users.sourceforge.net> wrote: > Am Dienstag, den 21.05.2013, 14:23 +0800 schrieb Huacai Chen: > > When GPU acceleration is disabled, drm_vblank_cleanup() will free the > > vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. > > But we found that drm_vblank_post_modeset() may be called after the > > cleanup, which use vblank_refcount and vblank_inmodeset. And this will > > cause a kernel panic. > > > > Fix this by return immediately if dev->num_crtcs is zero. This is the > > same thing that drm_vblank_pre_modeset() does. > > > > Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): > > [ 62.628906] [] drm_vblank_post_modeset+0x34/0xb4 > > [ 62.628906] [] atombios_crtc_dpms+0xb4/0x174 > > [ 62.628906] [] atombios_crtc_commit+0x18/0x38 > > [ 62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc > > [ 62.628906] [] > drm_crtc_helper_set_config+0x6d8/0x988 > > [ 62.628906] [] drm_fb_helper_set_par+0x94/0x104 > > [ 62.628906] [] fbcon_init+0x424/0x57c > > [ 62.628906] [] visual_init+0xb8/0x118 > > [ 62.628906] [] take_over_console+0x238/0x384 > > [ 62.628906] [] fbcon_takeover+0x7c/0xdc > > [ 62.628906] [] notifier_call_chain+0x44/0x94 > > [ 62.628906] [] > __blocking_notifier_call_chain+0x48/0x68 > > [ 62.628906] [] register_framebuffer+0x228/0x260 > > [ 62.628906] [] > drm_fb_helper_single_fb_probe+0x260/0x314 > > [ 62.628906] [] > drm_fb_helper_initial_config+0x200/0x234 > > [ 62.628906] [] radeon_fbdev_init+0xd4/0xf4 > > [ 62.628906] [] radeon_modeset_init+0x9bc/0xa18 > > [ 62.628906] [] radeon_driver_load_kms+0xdc/0x12c > > [ 62.628906] [] drm_get_pci_dev+0x148/0x238 > > [ 62.628906] [] local_pci_probe+0x5c/0xd0 > > [ 62.628906] [] work_for_cpu_fn+0x1c/0x30 > > [ 62.628906] [] process_one_work+0x274/0x3bc > > [ 62.628906] [] process_scheduled_works+0x24/0x44 > > [ 62.628906] [] worker_thread+0x31c/0x3f4 > > [ 62.628906] [] kthread+0x88/0x90 > > [ 62.628906] [] kernel_thread_helper+0x10/0x18 > > Nice commit message! > > > Signed-off-by: Huacai Chen > > Signed-off-by: Binbin Zhou > > Cc: > > --- > > drivers/gpu/drm/drm_irq.c |6 +- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > [?] > > Acked-by: Paul Menzel > > > Thanks, > > Paul > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/2a6a7126/attachment.html>
[PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0
These chipsets include the VP2 engine which is composed of a bitstream
processor (BSP) that decodes H.264 and a video processor (VP) which can
do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
driven by separate xtensa chips embedded in the hardware. This patch
provides the mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
This patch applies on top of nouveau/master (16a41bcc8).
This seems to work for me. There was one boot where my userspace
component didn't work right, but it could just as well be a bug
there. Subsequent attempts seem to work fine. Note that I'm not
particularly familiar with any of this stuff, so if something looks
odd, I probably didn't know any better. I did try to faithfully
reproduce whatever the blob did. A few questions/thoughts:
1. There's a LOT of similarity between BSP and VP setup/etc. Is it
worth it to create a core/xtensa.c or some such, similar to
falcon.c? Since it's only in two places, not that much code, and
there _are_ differences, I decided to keep them separate.
2. Firmware naming. Maarten suggested to use the falcon naming style,
which is nv$chipset_fuc$offset. However here, all the chips share
the same firmware. Also the offset would be 103 vs 00f, and is a
little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
left it the way I had it: nv84_bsp and nv84_vp.
3. Firmware load time. I chose to load the fw into memory in the ctor,
and then copy it in in init, due to some potentially bogus
suspend/resume concerns. Also e.g. mplayer likes to create/destroy
decoders at startup a few times. The downside is that ~200KB of
memory is gone. Let me know if I should change it to do the
request_firmware in init.
There's obviously a userspace piece to this, which I'm still working
on. But right now I have it working within certain parameters
(e.g. 1280x544 videos), and I'm relatively confident it can be
completed without further kernel-side changes.
There's also a hypothetical concern of "what if we create an open
firmware with a different user API". Ideally there'd be some way to
expose what kind of firmware is loaded, but I think that can be left
for "later".
drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c | 139 ++-
drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c | 4 +
drivers/gpu/drm/nouveau/core/engine/vp/nv84.c | 140 +++-
drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 1 +
drivers/gpu/drm/nouveau/core/subdev/vm/nv50.c | 2 +
5 files changed, 278 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
index 1d9f614..04880d9 100644
--- a/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
+++ b/drivers/gpu/drm/nouveau/core/engine/bsp/nv84.c
@@ -29,6 +29,10 @@
struct nv84_bsp_priv {
struct nouveau_engine base;
+ u32 *fw;
+ long fw_size;
+ struct nouveau_gpuobj *gpu_fw;
+ void *vm_gpu_fw;
};
/***
@@ -37,6 +41,7 @@ struct nv84_bsp_priv {
static struct nouveau_oclass
nv84_bsp_sclass[] = {
+ { 0x74b0, &nouveau_object_ofuncs },
{},
};
@@ -44,11 +49,28 @@ nv84_bsp_sclass[] = {
* BSP context
**/
+static int
+nv84_bsp_engctx_ctor(struct nouveau_object *parent,
+struct nouveau_object *engine,
+struct nouveau_oclass *oclass, void *data, u32 size,
+struct nouveau_object **pobject)
+{
+ struct nouveau_engctx *engctx;
+ int ret;
+
+ ret = nouveau_engctx_create(parent, engine, oclass, NULL,
+ 0x1, 0x1000,
+ NVOBJ_FLAG_ZERO_ALLOC, &engctx);
+ *pobject = nv_object(engctx);
+ return ret;
+}
+
+
static struct nouveau_oclass
nv84_bsp_cclass = {
.handle = NV_ENGCTX(BSP, 0x84),
.ofuncs = &(struct nouveau_ofuncs) {
- .ctor = _nouveau_engctx_ctor,
+ .ctor = nv84_bsp_engctx_ctor,
.dtor = _nouveau_engctx_dtor,
.init = _nouveau_engctx_init,
.fini = _nouveau_engctx_fini,
@@ -61,6 +83,24 @@ nv84_bsp_cclass = {
* BSP engine/subdev functions
**/
+static void
+nv84_bsp_intr(struct nouveau_subdev *subdev)
+{
+ struct nv84_bsp_priv *priv = (void *)subdev;
+ u32 intr, unk104, unk10c, chan;
+
+ unk104 = nv_rd32(priv, 0x103d04);
+ intr = nv_rd32(priv, 0x103c20);
+ chan = nv_rd32(priv, 0x103c28);
+ unk10c = nv_rd32(priv, 0x103d0c);
+ nv_wr32(priv, 0x103c20, intr);
+ intr = nv_rd32(priv, 0x103c20);
+ if (unk104 == 0
[PATCH] drm: fix a use-after-free when GPU acceleration disabled
On Mon, Jun 3, 2013 at 6:29 PM, Huacai Chen wrote: > Hi, Dave > > Why this patch hasn't been applied in your tree? I think you are the right > maintainer. > Because I missed it, i've stuck in my fixes queue now. thanks for pinging. Dave.
[PATCH v2 4/7] drm/i915: Use a custom restore_fbdev_mode hook
On Fri, May 31, 2013 at 08:07:04PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Disable sprite planes and cursors when restoring the fbdev mode.
>
> Should makes oopses more readable if they're not covered by sprites and
> cursors.
>
> v2: Rebased due to changes earlier in the series
Nice, this should fix the issue of the rogue cursor and the like if X
exits abnormally. Explicitly disabling it feels wrong, but as the cursor
is not integrated into the modesetting sequence I have no better
suggestion.
Reviewed-by: Chris Wilson
Comment inline.
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/intel_fb.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index b34ccf3..e8389df 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -183,11 +183,25 @@ out:
> return ret;
> }
>
> +static bool intel_fb_restore_fbdev_mode(struct drm_fb_helper *helper)
> +{
> + struct drm_device *dev = helper->dev;
> + bool ret;
> +
> + intel_disable_cursors_and_sprites(dev);
> +
> + ret = drm_fb_helper_restore_fbdev_mode(helper);
> + if (ret)
> + DRM_DEBUG("failed to restore crtc mode\n");
Just return without the DBG here, and keep the DBG up a level where we
discard the error code.
> +
> + return ret;
> +}
> +
> static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
> .gamma_set = intel_crtc_fb_gamma_set,
> .gamma_get = intel_crtc_fb_gamma_get,
> .fb_probe = intelfb_create,
> - .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
> + .restore_fbdev_mode = intel_fb_restore_fbdev_mode,
> };
>
> static void intel_fbdev_destroy(struct drm_device *dev,
> @@ -291,7 +305,6 @@ void intel_fb_output_poll_changed(struct drm_device *dev)
>
> void intel_fb_restore_mode(struct drm_device *dev)
> {
> - int ret;
> drm_i915_private_t *dev_priv = dev->dev_private;
>
> if (INTEL_INFO(dev)->num_pipes == 0)
> @@ -299,11 +312,7 @@ void intel_fb_restore_mode(struct drm_device *dev)
>
> drm_modeset_lock_all(dev);
>
> - intel_disable_cursors_and_sprites(dev);
> -
> - ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
> - if (ret)
> - DRM_DEBUG("failed to restore crtc mode\n");
As above, I think this is the better location for the DBG.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH 5/7] drm/i915: Use container_of() in the fbdev code
On Fri, May 31, 2013 at 08:07:05PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Use container_of() instead of a cast to get struct intel_fbdev > from struct drm_fb_helper. > > Also populate the fb_info->par correctly with the drm_fb_helper pointer > instead of the intel_fbdev pointer. > > There's no actual functional change since the drm_fb_helper happens to > be the first member inside intel_fbdev. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Intel-gfx] [PATCH 6/7] drm/i915: s/drm_i915_private_t/struct drm_i915_private/
On Fri, May 31, 2013 at 08:07:06PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > People don't like typedefs these days. Eliminate their use from intel_fb.c. > > Signed-off-by: Ville Syrj?l? Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 3/7] drm/i915: Fix fbdev sprite disable code
On Fri, May 31, 2013 at 08:07:03PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> plane->enabled is never set, so this code didn't do anything.
>
> Fix the code for sprites by calling the new drm_plane_force_disable()
> function. That means the plane will remain off until someone explicitly
> turns it back on.
>
> And do the same for cursors and the old video overlays, since we only
> want to see the primary plane for fbdev.
>
> v2: Disable sprites/cursors until explicitly re-enabled
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/intel_display.c | 16
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fb.c | 9 ++---
> 3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 944b6d5..1d1a3fd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct
> drm_i915_error_state_buf *m,
> }
> }
> #endif
> +
> +void intel_disable_cursors_and_sprites(struct drm_device *dev)
> +{
> + struct drm_crtc *crtc;
> + struct drm_plane *plane;
> +
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
> + intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
> + }
> +
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->fb)
> + drm_plane_force_disable(plane);
This would be neater if drm_plane_force_disable did the check for
plane-fb itself.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Intel-gfx] [PATCH v2 1/7] drm: Add fb_helper->restore_fbdev_mode hook
On Fri, May 31, 2013 at 08:07:01PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Drivers may need to turn off overlay planes, cursors, etc. when > restoring the fbdev mode. So allow drivers to provide their own > version of drm_fb_helper_restore_fbdev_mode() that can take care > of such details. > > Initially just plug in drm_fb_helper_restore_fbdev_mode for all > drivers. I really don't like the bool interface here, and it looks even more confusing when passing through the hooks. Can we have this changed to be a proper error code? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #28 from Marc Dietrich --- patch in comment 23 fixes gpu lockups for me in several webgl apps! Can this please be applied to llvm 3.3 branch? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/051fa482/attachment.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #29 from Marc Dietrich --- Created attachment 80202 --> https://bugs.freedesktop.org/attachment.cgi?id=80202&action=edit render defects in webgl demo still having issues with some webgl demos, e.g. http://www.chromeexperiments.com/detail/pearl-boy/?f=webgl see attached screenshot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/c0b69833/attachment.html>
[Bug 59101] Gnome shell crashes after sleep mode
https://bugzilla.kernel.org/show_bug.cgi?id=59101 --- Comment #2 from Cyril N. 2013-06-03 11:27:12 --- dmesg : [149626.918841] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [149642.212632] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts [149644.616117] SELinux: initialized (dev proc, type proc), uses genfs_contexts [149654.440604] TCP: lp registered [152540.075830] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! [152555.088551] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts [152557.274289] SELinux: initialized (dev proc, type proc), uses genfs_contexts [152599.209132] SELinux: initialized (dev proc, type proc), uses genfs_contexts [152622.306348] SELinux: initialized (dev proc, type proc), uses genfs_contexts [152630.547807] SELinux: initialized (dev proc, type proc), uses genfs_contexts > [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! seems to be the problem. Where is the xorg log file and how can I know the mesa version I'm using ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Intel-gfx] [PATCH v2 3/7] drm/i915: Fix fbdev sprite disable code
On Fri, May 31, 2013 at 08:07:03PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> plane->enabled is never set, so this code didn't do anything.
>
> Fix the code for sprites by calling the new drm_plane_force_disable()
> function. That means the plane will remain off until someone explicitly
> turns it back on.
>
> And do the same for cursors and the old video overlays, since we only
> want to see the primary plane for fbdev.
>
> v2: Disable sprites/cursors until explicitly re-enabled
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/intel_display.c | 16
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fb.c | 9 ++---
> 3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 944b6d5..1d1a3fd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct
> drm_i915_error_state_buf *m,
> }
> }
> #endif
> +
> +void intel_disable_cursors_and_sprites(struct drm_device *dev)
> +{
> + struct drm_crtc *crtc;
> + struct drm_plane *plane;
> +
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
> + intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
> + }
I still think we should just move this into drm_fb_helper_restore_fbdev_mode:
- Cursors can be killed with crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
Or at least we should be able to do so, I've done a quick audit of all
drivers and none really cares about file_priv if the handle is 0. Of
course we should put that into a drm_cursor_force_disable helper to
prepare for a better world (atomic modeset and all ...).
vmwgfx needs to be fixed up slightly since it derefences file_priv
outside of a handle != 0 check, but that one can be trivially fixed for
both cursor_set callbacks by moving the driver_private dereference into
the if block.
- Legacy overlay stuff has been broken like that forever, and at least on
i8xx those are used much more often. Imo whoever's offended by gen2
being a bit broken can write a drm plane wrapper for the overlay stuff
(or better, move the code to drm planes and convert the ioctl to be a
shim around the real drm plane interfaces). I don't think we should add
hacks for that.
Cheers, Daniel
> +
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->fb)
> + drm_plane_force_disable(plane);
> + }
> +}
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d0a8c1a..f8e76cf 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -800,5 +800,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct
> drm_device *dev,
> extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev,
>enum transcoder pch_transcoder,
>bool enable);
> +extern void intel_disable_cursors_and_sprites(struct drm_device *dev);
>
> #endif /* __INTEL_DRV_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index 5fe525a..b34ccf3 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -293,22 +293,17 @@ void intel_fb_restore_mode(struct drm_device *dev)
> {
> int ret;
> drm_i915_private_t *dev_priv = dev->dev_private;
> - struct drm_mode_config *config = &dev->mode_config;
> - struct drm_plane *plane;
>
> if (INTEL_INFO(dev)->num_pipes == 0)
> return;
>
> drm_modeset_lock_all(dev);
>
> + intel_disable_cursors_and_sprites(dev);
> +
> ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
> if (ret)
> DRM_DEBUG("failed to restore crtc mode\n");
>
> - /* Be sure to shut off any planes that may be active */
> - list_for_each_entry(plane, &config->plane_list, head)
> - if (plane->enabled)
> - plane->funcs->disable_plane(plane);
> -
> drm_modeset_unlock_all(dev);
> }
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH 6/7] drm/i915: s/drm_i915_private_t/struct drm_i915_private/
On Mon, Jun 03, 2013 at 11:09:00AM +0100, Chris Wilson wrote: > On Fri, May 31, 2013 at 08:07:06PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > People don't like typedefs these days. Eliminate their use from intel_fb.c. > > > > Signed-off-by: Ville Syrj?l? > Reviewed-by: Chris Wilson Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH 5/7] drm/i915: Use container_of() in the fbdev code
On Mon, Jun 03, 2013 at 11:08:30AM +0100, Chris Wilson wrote: > On Fri, May 31, 2013 at 08:07:05PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > Use container_of() instead of a cast to get struct intel_fbdev > > from struct drm_fb_helper. > > > > Also populate the fb_info->par correctly with the drm_fb_helper pointer > > instead of the intel_fbdev pointer. > > > > There's no actual functional change since the drm_fb_helper happens to > > be the first member inside intel_fbdev. > Reviewed-by: Chris Wilson Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH v2 3/7] drm/i915: Fix fbdev sprite disable code
On Mon, Jun 03, 2013 at 02:00:00PM +0200, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 08:07:03PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > plane->enabled is never set, so this code didn't do anything.
> >
> > Fix the code for sprites by calling the new drm_plane_force_disable()
> > function. That means the plane will remain off until someone explicitly
> > turns it back on.
> >
> > And do the same for cursors and the old video overlays, since we only
> > want to see the primary plane for fbdev.
> >
> > v2: Disable sprites/cursors until explicitly re-enabled
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 16
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_fb.c | 9 ++---
> > 3 files changed, 19 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 944b6d5..1d1a3fd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct
> > drm_i915_error_state_buf *m,
> > }
> > }
> > #endif
> > +
> > +void intel_disable_cursors_and_sprites(struct drm_device *dev)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_plane *plane;
> > +
> > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> > + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
> > + intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
> > + }
>
> I still think we should just move this into drm_fb_helper_restore_fbdev_mode:
> - Cursors can be killed with crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
> Or at least we should be able to do so, I've done a quick audit of all
> drivers and none really cares about file_priv if the handle is 0. Of
> course we should put that into a drm_cursor_force_disable helper to
> prepare for a better world (atomic modeset and all ...).
>
> vmwgfx needs to be fixed up slightly since it derefences file_priv
> outside of a handle != 0 check, but that one can be trivially fixed for
> both cursor_set callbacks by moving the driver_private dereference into
> the if block.
>
> - Legacy overlay stuff has been broken like that forever, and at least on
> i8xx those are used much more often. Imo whoever's offended by gen2
> being a bit broken can write a drm plane wrapper for the overlay stuff
> (or better, move the code to drm planes and convert the ioctl to be a
> shim around the real drm plane interfaces). I don't think we should add
> hacks for that.
OK I give up. I did a quick check of the private plane stuff, and it
turns out they're not on plane_list, so I think just walking the list
and disabling everything there should be OK. Since you're happy w/
leaving the video overlay out in the cold for now, I'll shovel it all
into drm_fb_helper...
--
Ville Syrj?l?
Intel OTC
[PATCH v2 1/3] drm: Add drm_plane_force_disable()
From: Ville Syrj?l?
drm_plane_force_disable() will forcibly disable the plane even if user
had previously requested the plane to be enabled.
This can be used to force planes to be off when restoring the fbdev
mode.
The code was simply pulled from drm_framebuffer_remove(), which now
calls the new function as well.
v2: Check plane->fb in drm_plane_force_disable(), drop bogus comment
about disabling crtc
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 29 +++--
include/drm/drm_crtc.h | 1 +
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..865ebfe 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -569,16 +569,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
}
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
- if (plane->fb == fb) {
- /* should turn off the crtc */
- ret = plane->funcs->disable_plane(plane);
- if (ret)
- DRM_ERROR("failed to disable plane with
busy fb\n");
- /* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(plane->fb);
- plane->fb = NULL;
- plane->crtc = NULL;
- }
+ if (plane->fb == fb)
+ drm_plane_force_disable(plane);
}
drm_modeset_unlock_all(dev);
}
@@ -867,6 +859,23 @@ void drm_plane_cleanup(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_cleanup);
+void drm_plane_force_disable(struct drm_plane *plane)
+{
+ int ret;
+
+ if (!plane->fb)
+ return;
+
+ ret = plane->funcs->disable_plane(plane);
+ if (ret)
+ DRM_ERROR("failed to disable plane with busy fb\n");
+ /* disconnect the plane from the fb and crtc: */
+ __drm_framebuffer_unreference(plane->fb);
+ plane->fb = NULL;
+ plane->crtc = NULL;
+}
+EXPORT_SYMBOL(drm_plane_force_disable);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..db7a885 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -894,6 +894,7 @@ extern int drm_plane_init(struct drm_device *dev,
const uint32_t *formats, uint32_t format_count,
bool priv);
extern void drm_plane_cleanup(struct drm_plane *plane);
+extern void drm_plane_force_disable(struct drm_plane *plane);
extern void drm_encoder_cleanup(struct drm_encoder *encoder);
--
1.8.1.5
[PATCH 2/3] drm/vmwgfx: Don't access file_priv in cursor_set when handle==0
From: Ville Syrj?l?
We want to disable the cursor by calling ->cursor_set() with handle=0
from places where we don't have a file_priv, so don't try to access it
unless necessary.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3e3c7ab..d4607b2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -174,7 +174,6 @@ int vmw_du_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
uint32_t handle, uint32_t width, uint32_t height)
{
struct vmw_private *dev_priv = vmw_priv(crtc->dev);
- struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
struct vmw_surface *surface = NULL;
struct vmw_dma_buffer *dmabuf = NULL;
@@ -197,6 +196,8 @@ int vmw_du_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
}
if (handle) {
+ struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
+
ret = vmw_user_lookup_handle(dev_priv, tfile,
handle, &surface, &dmabuf);
if (ret) {
--
1.8.1.5
[PATCH 3/3] drm/fb-helper: Disable cursors and planes when restoring fbdev mode
From: Ville Syrj?l?
Cursors and plane can obscure whatever fbdev wants to show the user.
Disable them all in drm_fb_helper_restore_fbdev_mode.
After the cursors and planes have been disabled, user space needs to
explicitly re-enable them to make them visible again.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_fb_helper.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0df0ebb..3d13ca6e2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -287,13 +287,27 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
*/
bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
{
+ struct drm_device *dev = fb_helper->dev;
+ struct drm_plane *plane;
bool error = false;
- int i, ret;
+ int i;
+
+ drm_warn_on_modeset_not_all_locked(dev);
- drm_warn_on_modeset_not_all_locked(fb_helper->dev);
+ list_for_each_entry(plane, &dev->mode_config.plane_list, head)
+ drm_plane_force_disable(plane);
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set =
&fb_helper->crtc_info[i].mode_set;
+ struct drm_crtc *crtc = mode_set->crtc;
+ int ret;
+
+ if (crtc->funcs->cursor_set) {
+ ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
+ if (ret)
+ error = true;
+ }
+
ret = drm_mode_set_config_internal(mode_set);
if (ret)
error = true;
--
1.8.1.5
[PATCH 0/3] drm: fbdev mode restoration improvements v3
Third time's the charm maybe. Changes from v2: - Move the plane->fb NULL check into drm_plane_force_disable() - Cursors/planes are now disabled by drm_fb_helper directly, so no need for the new hook - Had to fix up vmwgfx not to look at file_priv in cursor_set when handle is 0
[PATCH 1/2] drm/i915: Drop bogus fbdev sprite disable code
From: Ville Syrj?l?
plane->enabled is never set, so this code didn't do anything.
Also drm_fb_helper_restore_fbdev_mode() will now disable all cursors
and sprites for us, so we don't have to bother anymore.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_fb.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 7a77d4c..7f3ac54 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -293,8 +293,6 @@ void intel_fb_restore_mode(struct drm_device *dev)
{
int ret;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_plane *plane;
if (INTEL_INFO(dev)->num_pipes == 0)
return;
@@ -305,10 +303,5 @@ void intel_fb_restore_mode(struct drm_device *dev)
if (ret)
DRM_DEBUG("failed to restore crtc mode\n");
- /* Be sure to shut off any planes that may be active */
- list_for_each_entry(plane, &config->plane_list, head)
- if (plane->enabled)
- plane->funcs->disable_plane(plane);
-
drm_modeset_unlock_all(dev);
}
--
1.8.1.5
[PATCH v2 2/2] drm: Remove some unused stuff from drm_plane
From: Ville Syrj?l?
There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly. Eliminate them.
v2: Remove all of it from kernel-doc too
Reviewed-by: Laurent Pinchart
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 2 +-
include/drm/drm_crtc.h | 11 ---
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 865ebfe..f00ba75 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1749,7 +1749,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
plane_resp->plane_id = plane->base.id;
plane_resp->possible_crtcs = plane->possible_crtcs;
- plane_resp->gamma_size = plane->gamma_size;
+ plane_resp->gamma_size = 0;
/*
* This ioctl is called twice, once to determine how much space is
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index db7a885..3c14b46 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -654,11 +654,7 @@ struct drm_plane_funcs {
* @format_count: number of formats supported
* @crtc: currently bound CRTC
* @fb: currently bound fb
- * @gamma_size: size of gamma table
- * @gamma_store: gamma correction table
- * @enabled: enabled flag
* @funcs: helper functions
- * @helper_private: storage for drver layer
* @properties: property tracking for this plane
*/
struct drm_plane {
@@ -674,14 +670,7 @@ struct drm_plane {
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
- /* CRTC gamma size for reporting to userspace */
- uint32_t gamma_size;
- uint16_t *gamma_store;
-
- bool enabled;
-
const struct drm_plane_funcs *funcs;
- void *helper_private;
struct drm_object_properties properties;
};
--
1.8.1.5
[Bug 65068] vgaswitcheroo doesn't deal with powered off dGPU on resume
https://bugs.freedesktop.org/show_bug.cgi?id=65068 --- Comment #7 from Alex Deucher --- (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > I'm not sure if this has anything to do with this bug, but the PCI config > > > space is all messed up when running on the integrated GPU: > > > > When you disable the GPU the hardware is physically powered off so you are > > accessing non-existent registers. You need to power up the GPU using > > vgaswitcheroo before loading/resuming the driver or access the config space > > with lspci. > > I guess what I was trying to say was, does having the device in this state > before you start suspend make the power management subsystem confused? Will > it try to "restore" the pci configuration space to 0xff? The reason you are getting 0xff is because you are accessing a disabled device. lspci would need to power up the GPU using vgaswitcheroo before accessing the hardware. > > The radeon GPU is definitely turned on by the firmware on resume and the > apple-gmux driver turns it off if that was the state of the system when > suspend was started. I suspect the gmux driver resumes first and disables the hardware before the radeon driver resumes. So the radeon driver resumes on disabled hardware. > > I tried a quick hack to call the "ON" function for vga-switcheroo from the > apple-gmux driver suspend hook. But that didn't work. However, if I do it > manually (i.e. echo ON > /sys/kernel/debug/vgaswitcheroo/switch) before > suspend, then it does seem to fix it. Some one needs to sort out the interactions between the the vgaswitcheroo drivers and the GPU drivers so that they do the right thing on suspend and resume and hw access from userspace utilities like lspci. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/03a5ffe6/attachment.html>
[Bug 65068] vgaswitcheroo doesn't deal with powered off dGPU on resume
https://bugs.freedesktop.org/show_bug.cgi?id=65068 --- Comment #8 from Alex Deucher --- Additionally, since the audio device is part of the GPU, it needs to work properly with vgaswitcheroo. Dave Airlie was doing some work to support all of this properly, but it's not complete yet: http://cgit.freedesktop.org/~airlied/linux/log/?h=switchy-wip http://cgit.freedesktop.org/~airlied/linux/log/?h=nv-pm-ops2-wip -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/aee46092/attachment.html>
[Bug 54867] bug in r300 compiler
https://bugs.freedesktop.org/show_bug.cgi?id=54867 --- Comment #2 from Tom Stellard --- Comment on attachment 80074 --> https://bugs.freedesktop.org/attachment.cgi?id=80074 s/signed/int/ Review of attachment 80074: - This patch looks good to me, but for the commit message, you need to wrap long lines to 80 or fewer characters (I actually wrap to 75, but I'm not sure what the standard convention is) and re-organize the commit message in the form of: Code area: Brief description Long description (if necessary) Link to fixed bugs For this patch, it should be something like: r300g/compiler: Fix unsigned comparison with less than zero rc_find_free_temporary_list() returns signed integer (in case of lack of free temporary registersreturns -1), so new_index in radeon_rename_regs() should be signed. https://bugs.freedesktop.org/show_bug.cgi?id=54867 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130603/2c777b23/attachment.html>
