date:20140324

On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka  wrote:
>> > > -> All hell breaks loose if Xorg dies and takes all it's mappings with it
>> > > (in master_destroy, since the Xorg /dev fd is the master) and leaves the
>> > > driver hanging in the air if there's an interrupt still pending (or
>> > > anything else fwiw).
>> >
>> > For me that crash happened when xorg exited with a fatal error too.
>>
>> Is this fatal error itself a regression or have you seen that on older
>> kernels, too?
>
> In my case that Xorg error was not kernel-related at all. It happened
> because of unknown symbol because I used mga_dri.so from Debian 6 in
> Debian 7 (mga_dri.so isn't shipped in Debian 7 anymore). I can still play
> quake with that old mga_dri.so, although in some other scenario it causes
> failure because of unknown symbol. I should probably recompile mga_dri on
> my own.
>
>> Like I've said the entire teardown sequence for legacy drm drivers is
>> terminally busted, so the only hope we have is to reapply this missing
>> duct-tape which made your X crash. But if that itself isn't a regression
>> there's no way to fix the current drm/mga driver without a complete
>> rewrite as a new-style kernel modesetting driver.
>> -Daniel
>
> If someone understands the locking issues I pointed out above, it could be
> easy to fix.

The locking issue isn't your problem, the real issue is that putting a
irq_uninstall into core code will break all the new (properly working)
drivers. And you can't really fix this in mga itself since the
lifetime rules of the register mappings are totally broken. It's a
fundamental misdesign of the legacy drm driver architecture and the
_only_ way to fix this bug for real is to rewrite this all. Which was
done for all the still used drivers like i915, radeon, nouveau, ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 04/11] drm/gma500: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()

2014-03-24 Thread Patrik Jakobsson

On Mon, Mar 24, 2014 at 9:39 PM, Daniel Vetter  wrote:

> On Mon, Mar 24, 2014 at 03:53:11PM +, Damien Lespiau wrote:
> > There are only a few users of the DRM_LOG_KMS() macro. We can simplify
> > the DRM code a bit by replacing them by DRM_DEBUG_KMS().
> >
> > Cc: Patrik Jakobsson 
> > Signed-off-by: Damien Lespiau 
>
> Note that the point here of using LOG_KMS is to esssentially have
> continuations. Which means your patch here will make the output extremely
> noisy and hard to read.
>

The noise is already there (tons of empty lines) so this patch will not make
it any worse. It needs to be fixed like in i915. I'll put it on my
todo-list.

Acked-by: Patrik Jakobsson 



> But the current code is already racy which annoyed me sufficently a while
> ago in i915's copy to fix it all up properly in
>
> commit 84fcb46977e57bafba40bde32067bacc1e510f9c
> Author: Daniel Vetter 
> Date:   Wed Nov 27 16:03:01 2013 +0100
>
> drm/i915/sdvo: Fix up debug output to not split lines
>
> It leads to a big mess when stuff interleaves. Especially with the new
> patch I've submitted for the drm core to no longer artificially split
> up debug messages.
>
> v2: The size parameter to snprintf includes the terminating 0, but the
> return value does not. Adjust the logic accordingly. Spotted by Mika.
>
> Cc: Mika Kuoppala 
> Reviewed-by: Mika Kuoppala 
> Signed-off-by: Daniel Vetter 
>
> Just my 2c.
>
> Cheers, Daniel
> > ---
> >  drivers/gpu/drm/gma500/psb_intel_sdvo.c | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > index 07d3a9e..681efec 100644
> > --- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > @@ -406,18 +406,18 @@ static void psb_intel_sdvo_debug_write(struct
> psb_intel_sdvo *psb_intel_sdvo, u8
> >   DRM_DEBUG_KMS("%s: W: %02X ",
> >   SDVO_NAME(psb_intel_sdvo), cmd);
> >   for (i = 0; i < args_len; i++)
> > - DRM_LOG_KMS("%02X ", ((u8 *)args)[i]);
> > + DRM_DEBUG_KMS("%02X ", ((u8 *)args)[i]);
> >   for (; i < 8; i++)
> > - DRM_LOG_KMS("   ");
> > + DRM_DEBUG_KMS("   ");
> >   for (i = 0; i < ARRAY_SIZE(sdvo_cmd_names); i++) {
> >   if (cmd == sdvo_cmd_names[i].cmd) {
> > - DRM_LOG_KMS("(%s)", sdvo_cmd_names[i].name);
> > + DRM_DEBUG_KMS("(%s)", sdvo_cmd_names[i].name);
> >   break;
> >   }
> >   }
> >   if (i == ARRAY_SIZE(sdvo_cmd_names))
> > - DRM_LOG_KMS("(%02X)", cmd);
> > - DRM_LOG_KMS("\n");
> > + DRM_DEBUG_KMS("(%02X)", cmd);
> > + DRM_DEBUG_KMS("\n");
> >  }
> >
> >  static const char *cmd_status_names[] = {
> > @@ -512,9 +512,9 @@ static bool psb_intel_sdvo_read_response(struct
> psb_intel_sdvo *psb_intel_sdvo,
> >   }
> >
> >   if (status <= SDVO_CMD_STATUS_SCALING_NOT_SUPP)
> > - DRM_LOG_KMS("(%s)", cmd_status_names[status]);
> > + DRM_DEBUG_KMS("(%s)", cmd_status_names[status]);
> >   else
> > - DRM_LOG_KMS("(??? %d)", status);
> > + DRM_DEBUG_KMS("(??? %d)", status);
> >
> >   if (status != SDVO_CMD_STATUS_SUCCESS)
> >   goto log_fail;
> > @@ -525,13 +525,13 @@ static bool psb_intel_sdvo_read_response(struct
> psb_intel_sdvo *psb_intel_sdvo,
> > SDVO_I2C_RETURN_0 + i,
> > &((u8 *)response)[i]))
> >   goto log_fail;
> > - DRM_LOG_KMS(" %02X", ((u8 *)response)[i]);
> > + DRM_DEBUG_KMS(" %02X", ((u8 *)response)[i]);
> >   }
> > - DRM_LOG_KMS("\n");
> > + DRM_DEBUG_KMS("\n");
> >   return true;
> >
> >  log_fail:
> > - DRM_LOG_KMS("... failed\n");
> > + DRM_DEBUG_KMS("... failed\n");
> >   return false;
> >  }
> >
> > --
> > 1.8.3.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> 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/20140324/e75005cc/attachment-0001.html>

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

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

Gr?goire Paris  changed:

   What|Removed |Added

 CC||postmaster at greg0ire.fr

--- Comment #58 from Gr?goire Paris  ---
@Tilman Sauerbeck : did you file a new bug ? If not, shouldn't this bug be
reopened ?

-- 
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/20140324/82c38052/attachment-0001.html>

[PATCH 00/11] A few patches around DRM logging

On Mon, Mar 24, 2014 at 03:53:07PM +, Damien Lespiau wrote:
> As patch 8/11 explains, I noticed that we where evaluating the arguments to
> drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good
> reason. By pulling the test on drm_debug before calling drm_ut_debug_printk(),
> we skip those instructions that only need to be executed when logging is on.
> 
> The remaining patches are bonus clean-ups, with the main goal of removing
> DRM_LOG* macros that are not really used throughout the code base. After that,
> it's possible to simplify a bit drm_ut_debug_printk(). All pretty
> straightforward cleanups, but still worthwhile IMHO.
> 
> For driver-specific patches (why some of you are Cced in that series), I'd 
> love
> if you could take the time to throw a Acked-by/Reviewed-by tag. Also, do you
> have any objection if the driver specific patch go through the DRM tree?
> should people judge that series worthwhile, of course.

Except for the gma500 patch this series is

Reviewed-by: Daniel Vetter 

For the gma500 I've replied with my opinion but will defer to Patrik.
-Daniel

> 
> -- 
> Damien
> 
> Damien Lespiau (11):
>   drm: Refresh the explanation of debug categories
>   drm: Remove the unused (and unusable) DRM_LOG_MODE()
>   drm/exynos: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
>   drm/gma500: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
>   drm/i915: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
>   staging: imx-drm: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
>   drm: Remove the now unused DRM_LOG* macros
>   drm: Pull the test on drm_debug in the logging macros
>   drm: drm_ut_debug_printk() isn't called with NULL anywmore
>   drm: Remove the prefix argument of drm_ut_debug_printk()
>   drm: Remove the ',' after the function name in debug logs
> 
>  drivers/gpu/drm/drm_stub.c|  24 +++
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |   2 +-
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  20 +++---
>  drivers/gpu/drm/i915/dvo_ch7xxx.c |   4 +-
>  drivers/gpu/drm/i915/dvo_ivch.c   |  30 -
>  drivers/gpu/drm/i915/dvo_ns2501.c |  10 +--
>  drivers/gpu/drm/i915/dvo_sil164.c |  10 +--
>  drivers/gpu/drm/i915/dvo_tfp410.c |  24 +++
>  drivers/staging/imx-drm/ipuv3-plane.c |   2 +-
>  include/drm/drmP.h| 106 
> +++---
>  11 files changed, 98 insertions(+), 136 deletions(-)
> 
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 04/11] drm/gma500: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()

On Mon, Mar 24, 2014 at 03:53:11PM +, Damien Lespiau wrote:
> There are only a few users of the DRM_LOG_KMS() macro. We can simplify
> the DRM code a bit by replacing them by DRM_DEBUG_KMS().
> 
> Cc: Patrik Jakobsson 
> Signed-off-by: Damien Lespiau 

Note that the point here of using LOG_KMS is to esssentially have
continuations. Which means your patch here will make the output extremely
noisy and hard to read.

But the current code is already racy which annoyed me sufficently a while
ago in i915's copy to fix it all up properly in

commit 84fcb46977e57bafba40bde32067bacc1e510f9c 
 
Author: Daniel Vetter

Date:   Wed Nov 27 16:03:01 2013 +0100  
 

drm/i915/sdvo: Fix up debug output to not split lines

It leads to a big mess when stuff interleaves. Especially with the new
patch I've submitted for the drm core to no longer artificially split
up debug messages.

v2: The size parameter to snprintf includes the terminating 0, but the
return value does not. Adjust the logic accordingly. Spotted by Mika.

Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
Signed-off-by: Daniel Vetter 

Just my 2c.

Cheers, Daniel
> ---
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
> b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> index 07d3a9e..681efec 100644
> --- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> @@ -406,18 +406,18 @@ static void psb_intel_sdvo_debug_write(struct 
> psb_intel_sdvo *psb_intel_sdvo, u8
>   DRM_DEBUG_KMS("%s: W: %02X ",
>   SDVO_NAME(psb_intel_sdvo), cmd);
>   for (i = 0; i < args_len; i++)
> - DRM_LOG_KMS("%02X ", ((u8 *)args)[i]);
> + DRM_DEBUG_KMS("%02X ", ((u8 *)args)[i]);
>   for (; i < 8; i++)
> - DRM_LOG_KMS("   ");
> + DRM_DEBUG_KMS("   ");
>   for (i = 0; i < ARRAY_SIZE(sdvo_cmd_names); i++) {
>   if (cmd == sdvo_cmd_names[i].cmd) {
> - DRM_LOG_KMS("(%s)", sdvo_cmd_names[i].name);
> + DRM_DEBUG_KMS("(%s)", sdvo_cmd_names[i].name);
>   break;
>   }
>   }
>   if (i == ARRAY_SIZE(sdvo_cmd_names))
> - DRM_LOG_KMS("(%02X)", cmd);
> - DRM_LOG_KMS("\n");
> + DRM_DEBUG_KMS("(%02X)", cmd);
> + DRM_DEBUG_KMS("\n");
>  }
>  
>  static const char *cmd_status_names[] = {
> @@ -512,9 +512,9 @@ static bool psb_intel_sdvo_read_response(struct 
> psb_intel_sdvo *psb_intel_sdvo,
>   }
>  
>   if (status <= SDVO_CMD_STATUS_SCALING_NOT_SUPP)
> - DRM_LOG_KMS("(%s)", cmd_status_names[status]);
> + DRM_DEBUG_KMS("(%s)", cmd_status_names[status]);
>   else
> - DRM_LOG_KMS("(??? %d)", status);
> + DRM_DEBUG_KMS("(??? %d)", status);
>  
>   if (status != SDVO_CMD_STATUS_SUCCESS)
>   goto log_fail;
> @@ -525,13 +525,13 @@ static bool psb_intel_sdvo_read_response(struct 
> psb_intel_sdvo *psb_intel_sdvo,
> SDVO_I2C_RETURN_0 + i,
> &((u8 *)response)[i]))
>   goto log_fail;
> - DRM_LOG_KMS(" %02X", ((u8 *)response)[i]);
> + DRM_DEBUG_KMS(" %02X", ((u8 *)response)[i]);
>   }
> - DRM_LOG_KMS("\n");
> + DRM_DEBUG_KMS("\n");
>   return true;
>  
>  log_fail:
> - DRM_LOG_KMS("... failed\n");
> + DRM_DEBUG_KMS("... failed\n");
>   return false;
>  }
>  
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[DRM] drm_get_connector_name internal static string buffer causes a race

On Mon, Mar 24, 2014 at 12:06:21PM +, Dmitry Malkin wrote:
> 
> Hello guys,
> 
> I've been playing with reloading intel gfx driver (i915) in a cycle, for a 
> while,
> and at some point I've found a non-deterministic kernel crash with a 
> highly-variable
> iteration dependency -- 2 to 200 driver reload iterations.
> 
> The apparent race is over the shared internal string buffer in 
> drm_get_connector_name().
> It is mostly harmless, due to its results being mostly used for log output, 
> but in at least one
> case  -- drm_sysfs_connector_add() -- this leads to a more critical error.
> 
> Race scenario:
> 
> - drm_sysfs_connector_add()
>- drm_get_connector_name()
> vs.
> - anything that generates log messages involving DRM connectors
>- drm_get_connector_name()
> 
>  (and many other from drm_crtc.c) shares with caller const char* to internal 
> static char buffer.
> If something call it from other thread, while main thread strore and use 
> returned pointer it may overwrite connector name.
> 
> Here are we go: registering HDMI connecter  (drm_sysfs_connector_add store 
> and use pointer from drm_get_connector_name)
> and the same time got VGA connector name down through the stack. (the second 
> thread is upowerd who watch continuously sysfs)

Yeah, in my recent kerneldoc series I've noticed this too and added FIXME
comments. There's a lot more than just those you've pointed out. The
problem is that fixing these will be an awful lot of work since you need
to add proper cleanup code (calling kfree()) to all the required places.

So a full subsystem wide code audit for every single use-site of these.
-Daniel

> 
> Mar 24 14:23:04 haswell01 kernel: [  417.570043] [ cut here 
> ]
> Mar 24 14:23:04 haswell01 kernel: [  417.570045] WARNING: CPU: 0 PID: 12700 
> at /build/buildd/linux-3.13.0/lib/kobject.c:223 
> kobject_add_internal+0x224/0x330()
> Mar 24 14:23:04 haswell01 kernel: [  417.570046] kobject_add_internal failed 
> for card0-VGA-1 with -EEXIST, don't try to register things with the same name 
> in the same directory.
> Mar 24 14:23:04 haswell01 kernel: [  417.570047] Modules linked in: i915(+) 
> video drm_kms_helper drm i2c_algo_bit snd_hda_codec_realtek 
> snd_hda_codec_hdmi bnep rfcomm bluetooth x86_pkg_temp_thermal intel_p
> owerclamp coretemp kvm_intel snd_hda_codec kvm snd_hwdep snd_pcm hid_generic 
> snd_page_alloc crct10dif_pclmul snd_seq_midi crc32_pclmul ghash_clmulni_intel 
> snd_seq_midi_event usbhid snd_rawmidi hid aesni_in
> tel aes_x86_64 lrw gf128mul ppdev glue_helper ablk_helper cryptd snd_seq 
> snd_seq_device snd_timer snd mei_me psmouse lpc_ich soundcore mei mac_hid 
> parport_pc serio_raw nls_iso8859_1 lp parport e1000e ahci
> ptp libahci pps_core [last unloaded: video]
> Mar 24 14:23:04 haswell01 kernel: [  417.570068] CPU: 0 PID: 12700 Comm: 
> modprobe Tainted: GW3.13.0-19-generic #39-Ubuntu
> Mar 24 14:23:04 haswell01 kernel: [  417.570069] Hardware name:   
>/DQ87PG, BIOS PGQ8710H.86A.0144.2014.0113.1604 01/13/2014
> Mar 24 14:23:04 haswell01 kernel: [  417.570069]  0009 
> 8804051295f8 81711075 880405129640
> Mar 24 14:23:04 haswell01 kernel: [  417.570071]  880405129630 
> 810662cd 88040776a410 ffef
> Mar 24 14:23:04 haswell01 kernel: [  417.570074]   
> 8804048dcc10 880407769000 880405129690
> Mar 24 14:23:04 haswell01 kernel: [  417.570076] Call Trace:
> Mar 24 14:23:04 haswell01 kernel: [  417.570078]  [] 
> dump_stack+0x45/0x56
> Mar 24 14:23:04 haswell01 kernel: [  417.570080]  [] 
> warn_slowpath_common+0x7d/0xa0
> Mar 24 14:23:04 haswell01 kernel: [  417.570081]  [] 
> warn_slowpath_fmt+0x4c/0x50
> Mar 24 14:23:04 haswell01 kernel: [  417.570082]  [] ? 
> sysfs_create_dir_ns+0x73/0xc0
> Mar 24 14:23:04 haswell01 kernel: [  417.570084]  [] 
> kobject_add_internal+0x224/0x330
> Mar 24 14:23:04 haswell01 kernel: [  417.570086]  [] 
> kobject_add+0x65/0xb0
> Mar 24 14:23:04 haswell01 kernel: [  417.570088]  [] 
> device_add+0x125/0x640
> Mar 24 14:23:04 haswell01 kernel: [  417.570090]  [] 
> device_create_groups_vargs+0xe0/0x110
> Mar 24 14:23:04 haswell01 kernel: [  417.570092]  [] 
> device_create+0x41/0x50
> Mar 24 14:23:04 haswell01 kernel: [  417.570097]  [] 
> drm_sysfs_connector_add+0x69/0x230 [drm]
> Mar 24 14:23:04 haswell01 kernel: [  417.570110]  [] 
> intel_hdmi_init_connector+0x111/0x260 [i915]
> Mar 24 14:23:04 haswell01 kernel: [  417.570119]  [] 
> intel_ddi_init+0x270/0x2a0 [i915]
> Mar 24 14:23:04 haswell01 kernel: [  417.570130]  [] 
> intel_setup_outputs+0x4c6/0x750 [i915]
> Mar 24 14:23:04 haswell01 kernel: [  417.570139]  [] 
> intel_modeset_init+0x607/0x8f0 [i915]
> Mar 24 14:23:04 haswell01 kernel: [  417.570147]  [] 
> i915_driver_load+0xbb4/0xe70 [i915]
> Mar 24 14:23:04 haswell01 kernel: [  417.570153]  [] 
> drm_dev_register+0xa2/0x1e0 [drm]
> Mar 24 14:23:04 haswell01 kernel: [  417.570158]  []

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

On Mon, Mar 24, 2014 at 01:17:12PM -0400, Mikulas Patocka wrote:
> 
> 
> On Mon, 24 Mar 2014, Daniel Vetter wrote:
> 
> > On Mon, Mar 24, 2014 at 07:45:47AM +1000, Dave Airlie wrote:
> > > On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr  wrote:
> > > > On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
> > > >> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr  wrote:
> > > >> >
> > > >> > which did end up flawless on 3.12.0-rc2+, too
> > > >> > (but failed to improve the issue on 3.14.0-rc7+).
> > > >> >
> > > >> > So, for all intents and purposes, drm infrastructure seems 
> > > >> > unavoidably
> > > >> > (neither dri disable nor libdrm upgrade helps) affected.
> > > >> > Does anyone know which change caused that issue?
> > > >> > (I'm asking because bisect here would be relatively painful).
> > > >>
> > > >> So 3.12-rc2 works. Does 3.13 work? Is this a regression in the current
> > > >> 3.14 rc only, or did it happen already in the previous release?
> > > >
> > > > Hmm, given that Mikulas in
> > > > https://lkml.org/lkml/2014/2/26/537
> > > > offered a diff of linux-3.13.5 files, it truly seems (shock! ack! noo!)
> > > > that that indeed may have been a regression at <= 3.13 proper even
> > > > (which may pose interesting questions about the level of testing 
> > > > coverage
> > > > we still enjoy [not!?] in this hardware area).
> 
> That patch drops a mutex, so it is not correct. There is mutex resursion - 
> we need to uninstall the irq in drm_master_destroy, because here we are 
> committed to destroy the device. But the routine that uninstalls the irq 
> takes struct_mutex, which is already held in drm_master_destroy.
> 
> I suppose that the person who maintains drm reworks the patch so that it's 
> correct:
> 
> - could we use a different mutex to protect the irq in drm_irq.c? Or 
> possibly no mutex at all and use cmpxchg to manipulate the variable 
> dev->irq_enabled? - this seems like the best solution. But I am not sure 
> if the code in drm_irq.c somehow depends on the facts that other parts of 
> the drm subsystem take struct_mutex.
> 
> - could we pass a new argument to drm_irq_uninstall that tells it not to 
> take the mutex? drm_master_destroy would set this argument to 1. 
> drm_master_destroy is mostly called with struct_mutex held, but there may 
> be places in vmwgfx_drv.c where drm_master_put (which calls 
> drm_master_destroy) may be called without struct_mutex held.
> 
> Is it true that drm_master_destroy can be called without struct_mutex 
> held? I don't know.
> 
> 
> I think drm maintainer should sort out the above issues and modify the 
> patch accordingly.
> 
> > > > Oh well, seems I'll have to prepare/build 3.13 now...
> > > 
> > > It's > 15 year old hardware, so yes I believe we have close to 0
> > > testing coverage on it outside of distros,
> > > 
> > > I'm not even sure I have one anymore, I might be able to test an MGA in 
> > > one box.
> > 
> > I haven't done a full read of all the related code, but this smells like a
> > similar bug I've hit all over the place in the i810 driver (another one of
> > those undead drm drivers of yonders). Ingredients:
> > 
> > 1) Xorg creates a drm mapping of the register space.
> > 2) Xorg tells the hw-specific drm which drm mapping has the hw registers,
> > and the driver uses that. Iirc this has been done as some form of OS
> > abstraction. Also note that these mappings aren't refcounted, so the first
> > guy to call drm_rmmap wins.
> > 
> > -> All hell breaks loose if Xorg dies and takes all it's mappings with it
> > (in master_destroy, since the Xorg /dev fd is the master) and leaves the
> > driver hanging in the air if there's an interrupt still pending (or
> > anything else fwiw).
> 
> For me that crash happened when xorg exited with a fatal error too.

Is this fatal error itself a regression or have you seen that on older
kernels, too?

Like I've said the entire teardown sequence for legacy drm drivers is
terminally busted, so the only hope we have is to reapply this missing
duct-tape which made your X crash. But if that itself isn't a regression
there's no way to fix the current drm/mga driver without a complete
rewrite as a new-style kernel modesetting driver.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 76501] fences regression

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

--- Comment #6 from Ortwin Gl?ck  ---
interestingly also the last good commit produces the following log:
[7.573975] [drm] UVD initialized successfully.
[7.574210] [drm] Enabling audio 0 support
[7.574240] [drm] ib test on ring 0 succeeded in 0 usecs
[7.574263] [drm] ib test on ring 3 succeeded in 0 usecs
[   17.730386] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[   17.730390] radeon :01:00.0: GPU lockup (waiting for 0x0002
last fence id 0x)
[   17.730393] [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait failed (-35).
[   17.730397] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
ring 5 (-35).


So that seems unrelated to the issue at hand.

-- 
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/20140324/309a8e53/attachment.html>

[Bug 76501] fences regression

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

--- Comment #5 from Ortwin Gl?ck  ---
Created attachment 96316
  --> https://bugs.freedesktop.org/attachment.cgi?id=96316=edit
first bad commit

-- 
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/20140324/823f9495/attachment.html>

[Bug 76501] fences regression

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

--- Comment #4 from Ortwin Gl?ck  ---
Created attachment 96315
  --> https://bugs.freedesktop.org/attachment.cgi?id=96315=edit
last good commit

-- 
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/20140324/b776e78a/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #8 from jeroen  ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Probably a duplicate of bug 71753.
> > 
> > Yes I read that report. What I don't understand is how the audio clock, uvd
> > clock, hdmi clock, etc relate to each other.
> > 
> > For audio I use the realtek chip and it's SPDIF. I guess with the audio
> > clock, the HDMI audio clock is used? Which in my case is not used I guess.
> 
> They are not really related on the hw side.  UVD decodes as fast as it can
> based on it's own clocks.  When the decoded frame is displayed is up to the
> application.  The audio chip has it's own clock and the display has it's own
> clock.  The hdmi audio information is embedded in the display stream.  The
> monitor uses special packets that the GPU embeds in the display stream to
> reconstruct the audio stream on the monitor based on the display clock. 
> There seem to be cases where the hdmi stream is not set up properly so the
> audio clock is not recovered properly on the monitor side.

Okay, but doesnt that mean in this case it is a problem with the display
(HDMI?) clock, as I am not using HDMI audio?

Is there a way I could get more detailed logging of what is happening on my
system?

-- 
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/20140324/f837d1cb/attachment-0001.html>

[PATCH] drm/cma: include as needed

2014-03-24 Thread Shawn Guo

The following error and warnings will be seen when compiling a C file
which includes  but without 
being included before.

include/drm/drm_gem_cma_helper.h:5:24: error: field ?base? has incomplete type
include/drm/drm_gem_cma_helper.h: In function ?to_drm_gem_cma_obj?:
include/drm/drm_gem_cma_helper.h:16:9: warning: initialization from 
incompatible pointer type [enabled by default]
include/drm/drm_gem_cma_helper.h: At top level:
include/drm/drm_gem_cma_helper.h:24:34: warning: ?struct drm_mode_create_dumb? 
declared inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:24:34: warning: its scope is only this 
definition or declaration, which is probably not what you want [enabled by 
default]
include/drm/drm_gem_cma_helper.h:24:34: warning: ?struct drm_device? declared 
inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:24:34: warning: ?struct drm_file? declared 
inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:28:10: warning: ?struct drm_device? declared 
inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:28:10: warning: ?struct drm_file? declared 
inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:35:3: warning: ?struct drm_device? declared 
inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:46:14: warning: ?struct drm_device? declared 
inside parameter list [enabled by default]

Fix them by including  in drm_gem_cma_helper.h.

Signed-off-by: Shawn Guo 
---
 include/drm/drm_gem_cma_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 89b4d7d..2a3cea9 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -1,6 +1,8 @@
 #ifndef __DRM_GEM_CMA_HELPER_H__
 #define __DRM_GEM_CMA_HELPER_H__

+#include 
+
 struct drm_gem_cma_object {
struct drm_gem_object base;
dma_addr_t paddr;
-- 
1.8.3.2

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #7 from Alex Deucher  ---
(In reply to comment #6)
> (In reply to comment #5)
> > Probably a duplicate of bug 71753.
> 
> Yes I read that report. What I don't understand is how the audio clock, uvd
> clock, hdmi clock, etc relate to each other.
> 
> For audio I use the realtek chip and it's SPDIF. I guess with the audio
> clock, the HDMI audio clock is used? Which in my case is not used I guess.

They are not really related on the hw side.  UVD decodes as fast as it can
based on it's own clocks.  When the decoded frame is displayed is up to the
application.  The audio chip has it's own clock and the display has it's own
clock.  The hdmi audio information is embedded in the display stream.  The
monitor uses special packets that the GPU embeds in the display stream to
reconstruct the audio stream on the monitor based on the display clock.  There
seem to be cases where the hdmi stream is not set up properly so the audio
clock is not recovered properly on the monitor side.

-- 
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/20140324/ba69e33f/attachment.html>

[Bug 72701] Screen freeze when using radeon driver

2014-03-24 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #6 from klod  ---
Well, "radeon.runpm=0" allows me to boot and use the system, but with much
higher temperature and shorter battery life. I wouldn't call that "fixing the
issue", as it's still worse than what I have with 3.12 and "radeon.dpm=1"
parameter.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #6 from jeroen  ---
(In reply to comment #5)
> Probably a duplicate of bug 71753.

Yes I read that report. What I don't understand is how the audio clock, uvd
clock, hdmi clock, etc relate to each other.

For audio I use the realtek chip and it's SPDIF. I guess with the audio clock,
the HDMI audio clock is used? Which in my case is not used I guess.

-- 
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/20140324/3918dd93/attachment.html>

[Bug 72701] Screen freeze when using radeon driver

2014-03-24 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #5 from Alex Deucher  ---
(In reply to klod from comment #4)
> Just a few questions:
> 
> 1. - What are "PX" and "non-PX" cards?

PX = PowerXpress.  PX systems are laptops with two GPUs, an integrated and a
discrete GPU.

> 
> 2. - Aren't these going to disable power management in my GPU? What's the
> difference between applying those and using "radeon.runpm=0" in grub? 
> 

It does not disable power management.  It only disables the special handling
for PX systems which gets incorrectly applied to non-PX systems in certain
cases.  When you apply the patches you shouldn't need to add the radeon.runpm=0
option.  If radeon.runpm=0 fixes the issue, so should the patches.

> 3. - How can I apply those? 
> 

If you are using git:
git am 

Otherwise:
patch -p1 -i 

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #5 from Alex Deucher  ---
Probably a duplicate of bug 71753.

-- 
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/20140324/3122c9a0/attachment.html>

[Bug 72701] Screen freeze when using radeon driver

2014-03-24 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #4 from klod  ---
Just a few questions:

1. - What are "PX" and "non-PX" cards?

2. - Aren't these going to disable power management in my GPU? What's the
difference between applying those and using "radeon.runpm=0" in grub? 

3. - How can I apply those? 

Thank you ! :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #4 from jeroen  ---
Sorry for not providing that information.

OpenELEC uses XBMC to play the videos. XBMC has the option to display stats
(http://wiki.xbmc.org/?title=Codecinfo). One of the stats is the actual video
frame rate. Other useful stats are the amount of frames dropped and skipped.

When I look at for example the numbers 23.95 and 23.92 it seems it is off by
1/1000 or 2/1000 respectively.

-- 
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/20140324/68847c71/attachment.html>

[RFCv3 08/14] drm: Replace crtc fb with primary plane fb (v2)

2014-03-24 Thread Matt Roper

On Wed, Mar 19, 2014 at 12:57:21PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:53PM -0700, Matt Roper wrote:
> > Now that CRTC's have a primary plane, there's no need to track the
> > framebuffer in the CRTC.  Replace all references to the CRTC fb
> > with the primary plane's fb.
> > 
> > Also note that this simplifies framebuffer removal slightly; we no
> > longer need to scan all CRTC's and disable the ones that were using the
> > framebuffer since the existing loop over all planes will take care
> > of disabling the primary plane (and on most hardware, the CRTC by
> > extension).
> > 
> > v2: Fixup several lingering crtc->fb instances that were missed in the
> > first patch iteration.
> > 
> > Tested-by: Rob Clark 
> > Signed-off-by: Matt Roper 
> 
> Giant patch again, and I don't think there's any sane way we can avoid
> this big sed job. Put I think we can make it less intrusive.
> 
> First: Have you looked into cocinelle to do this? I'm not sure whether
> cocinelle is sufficiently type aware, but the upside of using it is that
> it's much easier to regenerate the patch.

Good idea!  Yeah, I think Coccinelle should do this pretty easily with
just:

@@ struct drm_crtc *crtc; @@
-   crtc->fb
+   crtc->primary->fb

@@ struct drm_crtc crtc; @@
-   crtc.fb
+   crtc.primary->fb

> In any case I think we need to split this into the usual 3 phases to avoid
> flag days:
> 
> 1) Switch to crtc->primary->fb all over the core, but keep crtc->fb fully
> functional. I.e. update it before calling into drivers and use that to
> update crtc->primary->fb on return (e.g. in the pageflip ioctl).

I'm starting to worry that this may be more tricky than it sounded when
I first read your email.  To be safe, it seems like we'll need to
sandwich all the various ->funcs-> driver calls in the core between
prepare_crtc_fbs() / finish_crtc_fbs() or similar since it's hard to
predict in a universal way when a driver might decide to go look at a
crtc's framebuffer (or even which crtcs it will decide to look at).
However even if we do that wrapping, there may be cases where the driver
calls back into a core helper function after modifying crtc->fb and the
core won't have that updated value unless we throw in extra sync-up
points.  

Is this pretty much what you had in mind or am I overlooking a much
simpler way to accomplish this?


Matt

> 
> 2) Switch drivers over to look at crtc->primary->fb. This way we can even
> split up the patch into per-driver patches which gives driver maintainers
> more wiggle room.
> 
> 3) Kill crtc->fb.
> 
> Steps 2&3 don't block merging of the universal planes support at all. So
> we could get the core support in all early for 3.16, then let driver
> maintainers pick up patche for 2 and shortly before the 3.16 merge window
> opens send a pull request with all the stragglers and step 3.
> 
> No comments on the actual patch, the few functional changes hidden in the
> massive diff looked ok. But hard to review properly ;-)
> 
> Cheers, Daniel
> 
> > ---
> >  drivers/gpu/drm/ast/ast_mode.c   |  12 +--
> >  drivers/gpu/drm/bochs/bochs_kms.c|   4 +-
> >  drivers/gpu/drm/cirrus/cirrus_mode.c |  10 +-
> >  drivers/gpu/drm/drm_crtc.c   |  56 --
> >  drivers/gpu/drm/drm_crtc_helper.c|  21 ++--
> >  drivers/gpu/drm/drm_fb_helper.c  |   6 +-
> >  drivers/gpu/drm/gma500/cdv_intel_display.c   |   2 +-
> >  drivers/gpu/drm/gma500/cdv_intel_dp.c|   2 +-
> >  drivers/gpu/drm/gma500/cdv_intel_hdmi.c  |   3 +-
> >  drivers/gpu/drm/gma500/cdv_intel_lvds.c  |   2 +-
> >  drivers/gpu/drm/gma500/gma_display.c |  17 ++--
> >  drivers/gpu/drm/gma500/mdfld_dsi_output.c|   2 +-
> >  drivers/gpu/drm/gma500/mdfld_intel_display.c |  17 ++--
> >  drivers/gpu/drm/gma500/oaktrail_crtc.c   |  13 +--
> >  drivers/gpu/drm/gma500/psb_intel_display.c   |   2 +-
> >  drivers/gpu/drm/gma500/psb_intel_lvds.c  |   2 +-
> >  drivers/gpu/drm/gma500/psb_intel_sdvo.c  |   2 +-
> >  drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
> >  drivers/gpu/drm/i915/i915_irq.c  |   4 +-
> >  drivers/gpu/drm/i915/intel_display.c | 147 
> > ++-
> >  drivers/gpu/drm/i915/intel_dp.c  |   5 +-
> >  drivers/gpu/drm/i915/intel_fbdev.c   |   6 +-
> >  drivers/gpu/drm/i915/intel_overlay.c |   4 +-
> >  drivers/gpu/drm/i915/intel_pm.c  |  36 +++
> >  drivers/gpu/drm/mgag200/mgag200_mode.c   |  28 ++---
> >  drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c |  28 ++---
> >  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c |  22 ++--
> >  drivers/gpu/drm/nouveau/dispnv04/crtc.c  |  20 ++--
> >  drivers/gpu/drm/nouveau/dispnv04/dfp.c   |   2 +-
> >  drivers/gpu/drm/nouveau/nouveau_display.c|   8 +-
> >  drivers/gpu/drm/nouveau/nv50_display.c   |  17 ++--
> >

[Bug 76490] No output after radeon module is loaded (R9 270X)

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

--- Comment #4 from Gustavo Lopes  ---
No, it still stalls.

-- 
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/20140324/be885041/attachment-0001.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #3 from Christian K?nig  ---
(In reply to comment #0)
> 23.976fps becomes 23.92/23.95 and sometimes goes to 22.93fps
> 25fps becomes 25.02 or 25.05fps
> 29.97 interlaced decodes with around 58fps instead of 59.94fps.

That the refresh frequency is a bit off might happen, but not that much.

How did you measured those nunmbers?

-- 
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/20140324/fda9d467/attachment.html>

[PATCH 12/12] drm/nouveau: support for probing GK20A

Set the correct subdev/engine classes when GK20A (0xea) is probed.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c 
b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
index 987edbc30a09..8509dd57de1f 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
@@ -156,6 +156,26 @@ nve0_identify(struct nouveau_device *device)
device->oclass[NVDEV_ENGINE_PPP] = _ppp_oclass;
device->oclass[NVDEV_ENGINE_PERFMON] = _perfmon_oclass;
break;
+   case 0xea:
+   device->cname = "GK20A";
+   device->oclass[NVDEV_SUBDEV_MC ] =  nvc3_mc_oclass;
+   device->oclass[NVDEV_SUBDEV_BUS] =  nvc0_bus_oclass;
+   device->oclass[NVDEV_SUBDEV_TIMER  ] = _timer_oclass;
+   device->oclass[NVDEV_SUBDEV_FB ] =  nvea_fb_oclass;
+   device->oclass[NVDEV_SUBDEV_IBUS   ] = _ibus_oclass;
+   device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass;
+   device->oclass[NVDEV_SUBDEV_VM ] = _vmmgr_oclass;
+   device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
+   device->oclass[NVDEV_ENGINE_DMAOBJ ] = _dmaeng_oclass;
+   device->oclass[NVDEV_ENGINE_FIFO   ] =  nvea_fifo_oclass;
+   /* TODO will need an implementation for this at some point... */
+#if 0
+   device->oclass[NVDEV_ENGINE_SW ] =  nvc0_software_oclass;
+#endif
+   device->oclass[NVDEV_ENGINE_GR ] =  nvea_graph_oclass;
+   device->oclass[NVDEV_ENGINE_COPY2  ] = _copy2_oclass;
+   device->oclass[NVDEV_ENGINE_PERFMON] = _perfmon_oclass;
+   break;
case 0xf0:
device->cname = "GK110";
device->oclass[NVDEV_SUBDEV_VBIOS  ] = _bios_oclass;
-- 
1.9.1

[PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

GK20A does not embed a dedicated COPY engine and thus cannot allocate
the copy channel that nouveau_accel_init() attempts to create. It also
lacks any display hardware, so the creation of a software channel does
not apply neither.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ef27949057c3..f2394e84eae6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -171,6 +171,11 @@ nouveau_accel_init(struct nouveau_drm *drm)
return;
}

+   if (device->chipset == 0xea) {
+   /* gk20a does not have CE0/CE1 */
+   arg0 = NVE0_CHANNEL_IND_ENGINE_GR;
+   arg1 = 1;
+   } else
if (device->card_type >= NV_E0) {
ret = nouveau_channel_new(drm, >client, NVDRM_DEVICE,
  NVDRM_CHAN + 1,
@@ -207,6 +212,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
return;
}

+   /* Need to figure out how to handle sw for gk20a */
+   if (device->chipset == 0xea)
+   goto skip_sw_init;
+
ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
 nouveau_abi16_swclass(drm), NULL, 0, );
if (ret == 0) {
@@ -233,6 +242,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
return;
}

+skip_sw_init:
if (device->card_type < NV_C0) {
ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>notify);
-- 
1.9.1

[PATCH 10/12] drm/nouveau/graph: add GK20A support

Add a GR device for GK20A based on NVE4, with the correct classes
definitions (GK20A's 3D class is 0xa297).

Most of the NVE4 code can be used on GK20A, so make relevant bits of
NVE4 available to other chips as well.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/Makefile   |  1 +
 .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c|  4 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |  9 +++
 drivers/gpu/drm/nouveau/core/engine/graph/nve4.c   |  2 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvea.c   | 75 ++
 .../gpu/drm/nouveau/core/include/engine/graph.h|  1 +
 6 files changed, 89 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/nvea.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 708d2e33835f..032a4744f843 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -270,6 +270,7 @@ nouveau-y += core/engine/graph/nvc8.o
 nouveau-y += core/engine/graph/nvd7.o
 nouveau-y += core/engine/graph/nvd9.o
 nouveau-y += core/engine/graph/nve4.o
+nouveau-y += core/engine/graph/nvea.o
 nouveau-y += core/engine/graph/nvf0.o
 nouveau-y += core/engine/graph/nv108.o
 nouveau-y += core/engine/mpeg/nv31.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
index e2de73ee5eee..3904073f860d 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
@@ -804,7 +804,7 @@ nve4_grctx_init_unk[] = {
{}
 };

-static void
+void
 nve4_grctx_generate_mods(struct nvc0_graph_priv *priv, struct nvc0_grctx *info)
 {
u32 magic[GPC_MAX][2];
@@ -962,7 +962,7 @@ nve4_grctx_generate_main(struct nvc0_graph_priv *priv, 
struct nvc0_grctx *info)
nv_mask(priv, 0x41be10, 0x0080, 0x0080);
 }

-static struct nvc0_graph_init *
+struct nvc0_graph_init *
 nve4_grctx_init_hub[] = {
nvc0_grctx_init_base,
nve4_grctx_init_unk40xx,
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h 
b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
index b0ab6de270b2..904f09b540c5 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
@@ -221,6 +221,8 @@ void nvc0_grctx_generate_r418bb8(struct nvc0_graph_priv *);
 void nve4_grctx_generate_r418bb8(struct nvc0_graph_priv *);
 void nvc0_grctx_generate_r406800(struct nvc0_graph_priv *);

+void nve4_grctx_generate_mods(struct nvc0_graph_priv *, struct nvc0_grctx *);
+
 extern struct nouveau_oclass *nvc0_grctx_oclass;
 extern struct nvc0_graph_init *nvc0_grctx_init_hub[];
 extern struct nvc0_graph_init nvc0_grctx_init_base[];
@@ -237,12 +239,17 @@ extern struct nvc0_graph_init nvc0_grctx_init_gpc_1[];
 extern struct nvc0_graph_init nvc0_grctx_init_tpc[];
 extern struct nvc0_graph_init nvc0_grctx_init_icmd[];
 extern struct nvc0_graph_init nvd9_grctx_init_icmd[]; //
+extern struct nvc0_graph_init nve4_grctx_init_icmd[];
+
+extern struct nvc0_graph_init *nve4_grctx_init_hub[];
+extern struct nvc0_graph_init *nve4_grctx_init_gpc[];

 extern struct nvc0_graph_mthd nvc0_grctx_init_mthd[];
 extern struct nvc0_graph_init nvc0_grctx_init_902d[];
 extern struct nvc0_graph_init nvc0_grctx_init_9039[];
 extern struct nvc0_graph_init nvc0_grctx_init_90c0[];
 extern struct nvc0_graph_init nvc0_grctx_init_mthd_magic[];
+extern struct nvc0_graph_init nve4_grctx_init_a097[];

 void nvc1_grctx_generate_mods(struct nvc0_graph_priv *, struct nvc0_grctx *);
 void nvc1_grctx_generate_unkn(struct nvc0_graph_priv *);
@@ -277,6 +284,8 @@ extern struct nvc0_graph_init nvf0_grctx_init_unk60xx[];

 extern struct nouveau_oclass *nv108_grctx_oclass;

+extern struct nvc0_graph_init *nve4_graph_init_mmio[];
+
 #define mmio_data(s,a,p) do {  
\
info->buffer[info->buffer_nr] = round_up(info->addr, (a)); \
info->addr = info->buffer[info->buffer_nr++] + (s);\
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
index 05ec09c88517..442857c5c120 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
@@ -298,7 +298,7 @@ nve4_graph_init(struct nouveau_object *object)
return nvc0_graph_init_ctxctl(priv);
 }

-static struct nvc0_graph_init *
+struct nvc0_graph_init *
 nve4_graph_init_mmio[] = {
nve4_graph_init_regs,
nvc0_graph_init_unk40xx,
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvea.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/nvea.c
new file mode 100644
index ..d5e6a1adcacb
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvea.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of

[PATCH 09/12] drm/nouveau/graph: pad firmware code at load time

Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
run from non-prepadded firmware files.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
index f997a18f5760..367e72daf8b1 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
@@ -768,6 +768,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 
fuc_base,
nv_wr32(priv, fuc_base + 0x0188, i >> 6);
nv_wr32(priv, fuc_base + 0x0184, code->data[i]);
}
+
+   /* code must be padded to 0x40 */
+   for (; i < (((code->size / 4) + 0x3f) & ~0x3f); i++)
+   nv_wr32(priv, fuc_base + 0x0184, 0);
 }

 static void
-- 
1.9.1

[PATCH 08/12] drm/nouveau/graph: enable when using external firmware

nvc0_graph_ctor() would only let the graphics engine be enabled if its
oclass has a proper microcode linked to it. This prevents GR from being
enabled at all on chips that rely exclusively on external firmware, even
though such a use-case is valid.

Relax the conditions enabling the GR engine to also include the case
where an external firmware has also been loaded.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
index 6ef8bf181b2d..f997a18f5760 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
@@ -1133,10 +1133,14 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct 
nouveau_object *engine,
struct nvc0_graph_oclass *oclass = (void *)bclass;
struct nouveau_device *device = nv_device(parent);
struct nvc0_graph_priv *priv;
+   bool use_fw;
int ret, i;

+   use_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false);
+
ret = nouveau_graph_create(parent, engine, bclass,
-  (oclass->fecs.ucode != NULL), );
+  (oclass->fecs.ucode != NULL) || use_fw,
+  );
*pobject = nv_object(priv);
if (ret)
return ret;
@@ -1146,7 +1150,7 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct 
nouveau_object *engine,

priv->base.units = nvc0_graph_units;

-   if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", false)) {
+   if (use_fw) {
nv_info(priv, "using external firmware\n");
if (nvc0_graph_ctor_fw(priv, "fuc409c", >fuc409c) ||
nvc0_graph_ctor_fw(priv, "fuc409d", >fuc409d) ||
-- 
1.9.1

[PATCH 07/12] drm/nouveau/fb: add GK20A support

Add a simple FB device for GK20A, as well as a RAM implementation based
on contiguous DMA memory allocations suitable for chips that use system
memory as video RAM.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/Makefile |   2 +
 drivers/gpu/drm/nouveau/core/include/subdev/fb.h |   1 +
 drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c|  56 
 drivers/gpu/drm/nouveau/core/subdev/fb/priv.h|   1 +
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c | 168 +++
 5 files changed, 228 insertions(+)
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 592141e62dda..708d2e33835f 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -100,6 +100,7 @@ nouveau-y += core/subdev/fb/nvaa.o
 nouveau-y += core/subdev/fb/nvaf.o
 nouveau-y += core/subdev/fb/nvc0.o
 nouveau-y += core/subdev/fb/nve0.o
+nouveau-y += core/subdev/fb/nvea.o
 nouveau-y += core/subdev/fb/ramnv04.o
 nouveau-y += core/subdev/fb/ramnv10.o
 nouveau-y += core/subdev/fb/ramnv1a.o
@@ -114,6 +115,7 @@ nouveau-y += core/subdev/fb/ramnva3.o
 nouveau-y += core/subdev/fb/ramnvaa.o
 nouveau-y += core/subdev/fb/ramnvc0.o
 nouveau-y += core/subdev/fb/ramnve0.o
+nouveau-y += core/subdev/fb/ramnvea.o
 nouveau-y += core/subdev/fb/sddr3.o
 nouveau-y += core/subdev/fb/gddr5.o
 nouveau-y += core/subdev/gpio/base.o
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/fb.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
index d7ecafbae1ca..3905816755ba 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
@@ -105,6 +105,7 @@ extern struct nouveau_oclass *nvaa_fb_oclass;
 extern struct nouveau_oclass *nvaf_fb_oclass;
 extern struct nouveau_oclass *nvc0_fb_oclass;
 extern struct nouveau_oclass *nve0_fb_oclass;
+extern struct nouveau_oclass *nvea_fb_oclass;

 #include 

diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c 
b/drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c
new file mode 100644
index ..62dbec48481e
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "nvc0.h"
+
+struct nvea_fb_priv {
+   struct nouveau_fb base;
+};
+
+static int
+nvea_fb_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+struct nouveau_oclass *oclass, void *data, u32 size,
+struct nouveau_object **pobject)
+{
+   struct nvea_fb_priv *priv;
+   int ret;
+
+   ret = nouveau_fb_create(parent, engine, oclass, );
+   *pobject = nv_object(priv);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+struct nouveau_oclass *
+nvea_fb_oclass = &(struct nouveau_fb_impl) {
+   .base.handle = NV_SUBDEV(FB, 0xea),
+   .base.ofuncs = &(struct nouveau_ofuncs) {
+   .ctor = nvea_fb_ctor,
+   .dtor = _nouveau_fb_dtor,
+   .init = _nouveau_fb_init,
+   .fini = _nouveau_fb_fini,
+   },
+   .memtype = nvc0_fb_memtype_valid,
+   .ram = _ram_oclass,
+}.base;
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h 
b/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
index edaf95dee612..0b95a25504d3 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
@@ -32,6 +32,7 @@ extern struct nouveau_oclass nva3_ram_oclass;
 extern struct nouveau_oclass nvaa_ram_oclass;
 extern struct nouveau_oclass nvc0_ram_oclass;
 extern struct nouveau_oclass nve0_ram_oclass;
+extern struct nouveau_oclass nvea_ram_oclass;

 int nouveau_sddr3_calc(struct nouveau_ram *ram);
 int nouveau_gddr5_calc(struct

[PATCH 06/12] drm/nouveau/ibus: add GK20A support

Add support for initializing the priv ring of GK20A. This is done by the
BIOS on desktop GPUs, but needs to be done by hand on Tegra.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/Makefile   |   1 +
 drivers/gpu/drm/nouveau/core/include/subdev/ibus.h |   1 +
 drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c| 110 +
 3 files changed, 112 insertions(+)
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index a90087bbdf88..592141e62dda 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -132,6 +132,7 @@ nouveau-y += core/subdev/i2c/nv94.o
 nouveau-y += core/subdev/i2c/nvd0.o
 nouveau-y += core/subdev/ibus/nvc0.o
 nouveau-y += core/subdev/ibus/nve0.o
+nouveau-y += core/subdev/ibus/nvea.o
 nouveau-y += core/subdev/instmem/base.o
 nouveau-y += core/subdev/instmem/nv04.o
 nouveau-y += core/subdev/instmem/nv40.o
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h
index 88814f159d89..056a42f92705 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h
@@ -30,5 +30,6 @@ nouveau_ibus(void *obj)

 extern struct nouveau_oclass nvc0_ibus_oclass;
 extern struct nouveau_oclass nve0_ibus_oclass;
+extern struct nouveau_oclass nvea_ibus_oclass;

 #endif
diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c 
b/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
new file mode 100644
index ..151851286e99
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
@@ -0,0 +1,110 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+struct nvea_ibus_priv {
+   struct nouveau_ibus base;
+};
+
+static void
+nvea_ibus_init_priv_ring(struct nvea_ibus_priv *priv)
+{
+   nv_mask(priv, 0x137250, 0x3f, 0);
+
+   nv_mask(priv, 0x000200, 0x20, 0);
+   udelay(20);
+   nv_mask(priv, 0x000200, 0x20, 0x20);
+
+   nv_wr32(priv, 0x12004c, 0x4);
+   nv_wr32(priv, 0x122204, 0x2);
+   nv_rd32(priv, 0x122204);
+}
+
+static void
+nvea_ibus_intr(struct nouveau_subdev *subdev)
+{
+   struct nvea_ibus_priv *priv = (void *)subdev;
+   u32 status0 = nv_rd32(priv, 0x120058);
+   s32 retry = 100;
+   u32 command;
+
+   if (status0 & 0x7) {
+   nv_debug(priv, "resetting priv ring\n");
+   nvea_ibus_init_priv_ring(priv);
+   }
+
+   /* Acknowledge interrupt */
+   nv_mask(priv, 0x12004c, 0x2, 0x2);
+
+   while (--retry >= 0) {
+   command = nv_rd32(priv, 0x12004c) & 0x3f;
+   if (command == 0)
+   break;
+   }
+
+   if (retry < 0)
+   nv_warn(priv, "timeout waiting for ringmaster ack\n");
+}
+
+static int
+nvea_ibus_init(struct nouveau_object *object)
+{
+   struct nvea_ibus_priv *priv = (void *)object;
+   int ret;
+
+   ret = _nouveau_ibus_init(object);
+   if (ret)
+   return ret;
+
+   nvea_ibus_init_priv_ring(priv);
+
+   return 0;
+}
+
+static int
+nvea_ibus_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+  struct nouveau_oclass *oclass, void *data, u32 size,
+  struct nouveau_object **pobject)
+{
+   struct nvea_ibus_priv *priv;
+   int ret;
+
+   ret = nouveau_ibus_create(parent, engine, oclass, );
+   *pobject = nv_object(priv);
+   if (ret)
+   return ret;
+
+   nv_subdev(priv)->intr = nvea_ibus_intr;
+   return 0;
+}
+
+struct nouveau_oclass
+nvea_ibus_oclass = {
+   .handle = NV_SUBDEV(IBUS, 0xea),
+   .ofuncs = &(struct nouveau_ofuncs) {
+   .ctor = nvea_ibus_ctor,
+   .dtor =

[PATCH 05/12] drm/nouveau/fifo: add GK20A support

GK20A's FIFO is compatible with NVE0, but only features 128 channels and
1 runlist.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/Makefile   |  1 +
 drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h|  1 +
 drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c| 35 ++
 drivers/gpu/drm/nouveau/core/include/engine/fifo.h |  1 +
 4 files changed, 38 insertions(+)
 create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index d310c195bdfe..a90087bbdf88 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -237,6 +237,7 @@ nouveau-y += core/engine/fifo/nv50.o
 nouveau-y += core/engine/fifo/nv84.o
 nouveau-y += core/engine/fifo/nvc0.o
 nouveau-y += core/engine/fifo/nve0.o
+nouveau-y += core/engine/fifo/nvea.o
 nouveau-y += core/engine/fifo/nv108.o
 nouveau-y += core/engine/graph/ctxnv40.o
 nouveau-y += core/engine/graph/ctxnv50.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h 
b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
index 014344ebee66..e96b32bb1bbc 100644
--- a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
@@ -8,6 +8,7 @@ int  nve0_fifo_ctor(struct nouveau_object *, struct 
nouveau_object *,
struct nouveau_object **);
 void nve0_fifo_dtor(struct nouveau_object *);
 int  nve0_fifo_init(struct nouveau_object *);
+int  nve0_fifo_fini(struct nouveau_object *, bool);

 struct nve0_fifo_impl {
struct nouveau_oclass base;
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c 
b/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
new file mode 100644
index ..5e3a9514df5d
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "nve0.h"
+
+struct nouveau_oclass *
+nvea_fifo_oclass = &(struct nve0_fifo_impl) {
+   .base.handle = NV_ENGINE(FIFO, 0xea),
+   .base.ofuncs = &(struct nouveau_ofuncs) {
+   .ctor = nve0_fifo_ctor,
+   .dtor = nve0_fifo_dtor,
+   .init = nve0_fifo_init,
+   .fini = nve0_fifo_fini,
+   },
+   .channels = 128,
+}.base;
diff --git a/drivers/gpu/drm/nouveau/core/include/engine/fifo.h 
b/drivers/gpu/drm/nouveau/core/include/engine/fifo.h
index 26b6b2bb1112..823356f45137 100644
--- a/drivers/gpu/drm/nouveau/core/include/engine/fifo.h
+++ b/drivers/gpu/drm/nouveau/core/include/engine/fifo.h
@@ -109,6 +109,7 @@ extern struct nouveau_oclass *nv50_fifo_oclass;
 extern struct nouveau_oclass *nv84_fifo_oclass;
 extern struct nouveau_oclass *nvc0_fifo_oclass;
 extern struct nouveau_oclass *nve0_fifo_oclass;
+extern struct nouveau_oclass *nvea_fifo_oclass;
 extern struct nouveau_oclass *nv108_fifo_oclass;

 void nv04_fifo_intr(struct nouveau_subdev *);
-- 
1.9.1

[PATCH 04/12] drm/nouveau/bar/nvc0: support chips without BAR3

Adapt the NVC0 BAR driver to make it able to support chips that do not
expose a BAR3. When this happens, BAR1 is then used for USERD mapping
and the BAR alloc() functions is disabled, making GPU objects unable
to rely on BAR for data access and falling back to PRAMIN.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 101 +
 1 file changed, 52 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c 
b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
index 3f30db62e656..5da1b9447af0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
@@ -79,87 +79,88 @@ nvc0_bar_unmap(struct nouveau_bar *bar, struct nouveau_vma 
*vma)
 }

 static int
-nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
- struct nouveau_oclass *oclass, void *data, u32 size,
- struct nouveau_object **pobject)
+nvc0_bar_init_vm(struct nvc0_bar_priv *priv, int nr, int bar)
 {
-   struct nouveau_device *device = nv_device(parent);
-   struct nvc0_bar_priv *priv;
+   struct nouveau_device *device = nv_device(>base);
struct nouveau_gpuobj *mem;
struct nouveau_vm *vm;
+   resource_size_t bar_len;
int ret;

-   ret = nouveau_bar_create(parent, engine, oclass, );
-   *pobject = nv_object(priv);
-   if (ret)
-   return ret;
-
-   /* BAR3 */
ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x1000, 0, 0,
-   >bar[0].mem);
-   mem = priv->bar[0].mem;
+   >bar[nr].mem);
+   mem = priv->bar[nr].mem;
if (ret)
return ret;

ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x8000, 0, 0,
-   >bar[0].pgd);
+   >bar[nr].pgd);
if (ret)
return ret;

-   ret = nouveau_vm_new(device, 0, nv_device_resource_len(device, 3), 0, 
);
+   bar_len = nv_device_resource_len(device, bar);
+
+   ret = nouveau_vm_new(device, 0, bar_len, 0, );
if (ret)
return ret;

atomic_inc(>engref[NVDEV_SUBDEV_BAR]);

-   ret = nouveau_gpuobj_new(nv_object(priv), NULL,
-(nv_device_resource_len(device, 3) >> 12) * 8,
-0x1000, NVOBJ_FLAG_ZERO_ALLOC,
->pgt[0].obj[0]);
-   vm->pgt[0].refcount[0] = 1;
-   if (ret)
-   return ret;
+   /*
+* Bootstrap page table lookup.
+*/
+   if (bar == 3) {
+   ret = nouveau_gpuobj_new(nv_object(priv), NULL,
+(bar_len >> 12) * 8, 0x1000,
+NVOBJ_FLAG_ZERO_ALLOC,
+   >pgt[0].obj[0]);
+   vm->pgt[0].refcount[0] = 1;
+   if (ret)
+   return ret;
+   }

-   ret = nouveau_vm_ref(vm, >bar[0].vm, priv->bar[0].pgd);
+   ret = nouveau_vm_ref(vm, >bar[nr].vm, priv->bar[nr].pgd);
nouveau_vm_ref(NULL, , NULL);
if (ret)
return ret;

-   nv_wo32(mem, 0x0200, lower_32_bits(priv->bar[0].pgd->addr));
-   nv_wo32(mem, 0x0204, upper_32_bits(priv->bar[0].pgd->addr));
-   nv_wo32(mem, 0x0208, lower_32_bits(nv_device_resource_len(device, 3) - 
1));
-   nv_wo32(mem, 0x020c, upper_32_bits(nv_device_resource_len(device, 3) - 
1));
+   nv_wo32(mem, 0x0200, lower_32_bits(priv->bar[nr].pgd->addr));
+   nv_wo32(mem, 0x0204, upper_32_bits(priv->bar[nr].pgd->addr));
+   nv_wo32(mem, 0x0208, lower_32_bits(bar_len - 1));
+   nv_wo32(mem, 0x020c, upper_32_bits(bar_len - 1));

-   /* BAR1 */
-   ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x1000, 0, 0,
-   >bar[1].mem);
-   mem = priv->bar[1].mem;
-   if (ret)
-   return ret;
+   return 0;
+}

-   ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x8000, 0, 0,
-   >bar[1].pgd);
-   if (ret)
-   return ret;
+static int
+nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+ struct nouveau_oclass *oclass, void *data, u32 size,
+ struct nouveau_object **pobject)
+{
+   struct nouveau_device *device = nv_device(parent);
+   struct nvc0_bar_priv *priv;
+   bool has_bar3 = nv_device_resource_len(device, 3) != 0;
+   int ret;

-   ret = nouveau_vm_new(device, 0, nv_device_resource_len(device, 1), 0, 
);
+   ret = nouveau_bar_create(parent, engine, oclass, );
+   *pobject = nv_object(priv);
if (ret)
return ret;

-   atomic_inc(>engref[NVDEV_SUBDEV_BAR]);
+   /* BAR3 */
+   if (has_bar3) {
+   ret = nvc0_bar_init_vm(priv, 0, 3);
+   if (ret)
+

[PATCH 03/12] drm/nouveau/bar: only ioremap BAR3 if it exists

Some chips that use system memory exclusively (e.g. GK20A) do not
expose 2 BAR regions. For them only BAR1 exists, and it should be used
for USERD mapping. Do not map BAR3 if its resource does not exist.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
index bdf594116f3f..d713eeb75b13 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
@@ -110,6 +110,7 @@ nouveau_bar_create_(struct nouveau_object *parent,
 {
struct nouveau_device *device = nv_device(parent);
struct nouveau_bar *bar;
+   bool has_bar3 = nv_device_resource_len(device, 3) != 0;
int ret;

ret = nouveau_subdev_create_(parent, engine, oclass, 0, "BARCTL",
@@ -118,8 +119,10 @@ nouveau_bar_create_(struct nouveau_object *parent,
if (ret)
return ret;

-   bar->iomem = ioremap(nv_device_resource_start(device, 3),
-nv_device_resource_len(device, 3));
+   if (has_bar3)
+   bar->iomem = ioremap(nv_device_resource_start(device, 3),
+nv_device_resource_len(device, 3));
+
return 0;
 }

-- 
1.9.1

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

GK20A's timer is directly attached to the system timer and cannot be
calibrated. Skip the calibration phase on that chip since the
corresponding registers do not exist.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c 
b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
index c0bdd10358d7..822fe0d8a871 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
@@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object)
if (ret)
return ret;

+   /* gk20a does not have the calibration registers */
+   if (device->chipset == 0xea)
+   goto skip_clk_init;
+
/* aim for 31.25MHz, which gives us nanosecond timestamps */
d = 100 / 32;

@@ -235,20 +239,23 @@ nv04_timer_init(struct nouveau_object *object)
d >>= 1;
}

-   /* restore the time before suspend */
-   lo = priv->suspend_time;
-   hi = (priv->suspend_time >> 32);
-
nv_debug(priv, "input frequency : %dHz\n", f);
nv_debug(priv, "input multiplier: %d\n", m);
nv_debug(priv, "numerator   : 0x%08x\n", n);
nv_debug(priv, "denominator : 0x%08x\n", d);
nv_debug(priv, "timer frequency : %dHz\n", (f * m) * d / n);
-   nv_debug(priv, "time low: 0x%08x\n", lo);
-   nv_debug(priv, "time high   : 0x%08x\n", hi);

nv_wr32(priv, NV04_PTIMER_NUMERATOR, n);
nv_wr32(priv, NV04_PTIMER_DENOMINATOR, d);
+
+skip_clk_init:
+   /* restore the time before suspend */
+   lo = priv->suspend_time;
+   hi = (priv->suspend_time >> 32);
+
+   nv_debug(priv, "time low: 0x%08x\n", lo);
+   nv_debug(priv, "time high   : 0x%08x\n", hi);
+
nv_wr32(priv, NV04_PTIMER_INTR_0, 0x);
nv_wr32(priv, NV04_PTIMER_INTR_EN_0, 0x);
nv_wr32(priv, NV04_PTIMER_TIME_1, hi);
-- 
1.9.1

[PATCH 01/12] drm/nouveau: fix missing newline

Add a missing newline at the end of a DRM_INFO message.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b2a674531fba..ef27949057c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -322,7 +322,7 @@ nouveau_get_hdmi_dev(struct drm_device *dev)
struct pci_dev *pdev = dev->pdev;

if (!pdev) {
-   DRM_INFO("not a PCI device; no HDMI");
+   DRM_INFO("not a PCI device; no HDMI\n");
drm->hdmi_device = NULL;
return;
}
-- 
1.9.1

[PATCH 00/12] drm/nouveau: support for GK20A, cont'd

Hi everyone,

Here is the second batch of patches to add GK20A support to Nouveau. This time
we are adding the actual chip support, and this series brings the driver to a
point where a slightly-tweaked Mesa successfully runs shaders and renders
triangles on GBM! Many thanks to Thierry Reding and the people on the
#nouveau IRC channel for their help without which we would not have reached
this milestone.

A few lines of hacks (not included here) are still needed to deal with cached
mappings triggering external aborts and CPU/GPU memory coherency issues, but I
hope to understand and address these issues next.

Most of the changes below have already been seen (and sometimes reviewed) in an
earlier patchset. What has been added is proper PGRAPH support (still needing
an external firmware and mostly reusing NVE4's code) as well as a better RAM
implementation.

How to represent and manage VRAM has been the hardest part to deal with, since
GK20A shares the system memory with the CPU without any kind of partition. I
have tried various approaches (included some in which no RAM object ever gets
instanciated) and finally decided to go for one using DMA-contiguous memory
allocations and relying on BAR mappings for kernel access and exposure to
user-space, as it fits better with existing code and keeps us safe from most of
the CPU/GPU memory coherency issues (at the cost of some performance).

Looking forward to your review of these few patches! :)

Cheers,
Alex.

Alexandre Courbot (12):
  drm/nouveau: fix missing newline
  drm/nouveau/timer: skip calibration on GK20A
  drm/nouveau/bar: only ioremap BAR3 if it exists
  drm/nouveau/bar/nvc0: support chips without BAR3
  drm/nouveau/fifo: add GK20A support
  drm/nouveau/ibus: add GK20A support
  drm/nouveau/fb: add GK20A support
  drm/nouveau/graph: enable when using external firmware
  drm/nouveau/graph: pad firmware code at load time
  drm/nouveau/graph: add GK20A support
  drm/nouveau: support GK20A in nouveau_accel_init()
  drm/nouveau: support for probing GK20A

 drivers/gpu/drm/nouveau/Makefile   |   5 +
 drivers/gpu/drm/nouveau/core/engine/device/nve0.c  |  20 +++
 drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h|   1 +
 drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c|  35 +
 .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c|   4 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c   |  12 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |   9 ++
 drivers/gpu/drm/nouveau/core/engine/graph/nve4.c   |   2 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvea.c   |  75 +
 drivers/gpu/drm/nouveau/core/include/engine/fifo.h |   1 +
 .../gpu/drm/nouveau/core/include/engine/graph.h|   1 +
 drivers/gpu/drm/nouveau/core/include/subdev/fb.h   |   1 +
 drivers/gpu/drm/nouveau/core/include/subdev/ibus.h |   1 +
 drivers/gpu/drm/nouveau/core/subdev/bar/base.c |   7 +-
 drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 101 +++--
 drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c  |  56 +++
 drivers/gpu/drm/nouveau/core/subdev/fb/priv.h  |   1 +
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c   | 168 +
 drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c| 110 ++
 drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c   |  19 ++-
 drivers/gpu/drm/nouveau/nouveau_drm.c  |  12 +-
 21 files changed, 578 insertions(+), 63 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
 create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/nvea.c
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c
 create mode 100644 drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c

-- 
1.9.1

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #2 from Christian K?nig  ---
HDMI refresh rate seems to be off, UVD decoding speed is completely unrelated
to this.

-- 
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/20140324/c003f63d/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

Christian K?nig  changed:

   What|Removed |Added

Summary|[AMD Fusion E-350] Radeon   |[AMD Fusion E-350] HDMI
   |UVD giving incorrect fps|refresh rates doesn't match
   |when playing videos |expectations

-- 
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/20140324/a1ba2459/attachment.html>

[Bug 76564] [AMD Fusion E-350] Radeon UVD giving incorrect fps when playing videos

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

--- Comment #1 from jeroen  ---
Created attachment 96303
  --> https://bugs.freedesktop.org/attachment.cgi?id=96303=edit
lspci output

-- 
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/20140324/73723bdb/attachment.html>

[Bug 76564] New: [AMD Fusion E-350] Radeon UVD giving incorrect fps when playing videos

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

Priority: medium
Bug ID: 76564
Assignee: dri-devel at lists.freedesktop.org
Summary: [AMD Fusion E-350] Radeon UVD giving incorrect fps
when playing videos
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: jeroenk61 at hotmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: 10.1
Component: Drivers/Gallium/r600
Product: Mesa

Created attachment 96302
--> https://bugs.freedesktop.org/attachment.cgi?id=96302=edit
dmesg

I'm currently experiencing problems when playing videos on my AMD fusion e-350
with HD6310 graphics(r600) with OpenELEC 4 beta2, which uses Mesa 10.1 and the
latest Linux 3.13 kernel. This is with the system connected through HDMI to my
television.
Either the video is being decoded too slow, which causes skipped frames, or it
is decoding too fast, which causes missed frames.

23.976fps becomes 23.92/23.95 and sometimes goes to 22.93fps
25fps becomes 25.02 or 25.05fps
29.97 interlaced decodes with around 58fps instead of 59.94fps.

It is if like the clock that is used for decoding is all over the place (PLL
issue?)

I confirmed with the old OpenELEC 3, which uses AMD's fglrx, and everything is
playing perfectly and the fps is spot on, as in. 23.98fps, 25fps and 59.94fps.

I also tried disabling the new VDPAU hardware acceleration and VDPAU mixer, but
with no effect.
All tests were done with the television frame rate being matched to the
content, so for example in the case of 23.976fps content the television is at
the same frequency.

--
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/20140324/9e730746/attachment.html>

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

2014-03-24 Thread Mikulas Patocka



On Mon, 24 Mar 2014, Daniel Vetter wrote:

> On Mon, Mar 24, 2014 at 01:17:12PM -0400, Mikulas Patocka wrote:

> > > > > Hmm, given that Mikulas in
> > > > > https://lkml.org/lkml/2014/2/26/537
> > > > > offered a diff of linux-3.13.5 files, it truly seems (shock! ack! 
> > > > > noo!)
> > > > > that that indeed may have been a regression at <= 3.13 proper even
> > > > > (which may pose interesting questions about the level of testing 
> > > > > coverage
> > > > > we still enjoy [not!?] in this hardware area).
> > 
> > That patch drops a mutex, so it is not correct. There is mutex resursion - 
> > we need to uninstall the irq in drm_master_destroy, because here we are 
> > committed to destroy the device. But the routine that uninstalls the irq 
> > takes struct_mutex, which is already held in drm_master_destroy.
> > 
> > I suppose that the person who maintains drm reworks the patch so that it's 
> > correct:
> > 
> > - could we use a different mutex to protect the irq in drm_irq.c? Or 
> > possibly no mutex at all and use cmpxchg to manipulate the variable 
> > dev->irq_enabled? - this seems like the best solution. But I am not sure 
> > if the code in drm_irq.c somehow depends on the facts that other parts of 
> > the drm subsystem take struct_mutex.
> > 
> > - could we pass a new argument to drm_irq_uninstall that tells it not to 
> > take the mutex? drm_master_destroy would set this argument to 1. 
> > drm_master_destroy is mostly called with struct_mutex held, but there may 
> > be places in vmwgfx_drv.c where drm_master_put (which calls 
> > drm_master_destroy) may be called without struct_mutex held.
> > 
> > Is it true that drm_master_destroy can be called without struct_mutex 
> > held? I don't know.
> > 
> > 
> > I think drm maintainer should sort out the above issues and modify the 
> > patch accordingly.
> > 
> > > -> All hell breaks loose if Xorg dies and takes all it's mappings with it
> > > (in master_destroy, since the Xorg /dev fd is the master) and leaves the
> > > driver hanging in the air if there's an interrupt still pending (or
> > > anything else fwiw).
> > 
> > For me that crash happened when xorg exited with a fatal error too.
> 
> Is this fatal error itself a regression or have you seen that on older
> kernels, too?

In my case that Xorg error was not kernel-related at all. It happened 
because of unknown symbol because I used mga_dri.so from Debian 6 in 
Debian 7 (mga_dri.so isn't shipped in Debian 7 anymore). I can still play 
quake with that old mga_dri.so, although in some other scenario it causes 
failure because of unknown symbol. I should probably recompile mga_dri on 
my own.

> Like I've said the entire teardown sequence for legacy drm drivers is
> terminally busted, so the only hope we have is to reapply this missing
> duct-tape which made your X crash. But if that itself isn't a regression
> there's no way to fix the current drm/mga driver without a complete
> rewrite as a new-style kernel modesetting driver.
> -Daniel

If someone understands the locking issues I pointed out above, it could be 
easy to fix.

Mikulas

[Bug 76559] screen corruption after going from VT to X

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

--- Comment #2 from Fabio Pedretti  ---
Created attachment 96297
  --> https://bugs.freedesktop.org/attachment.cgi?id=96297=edit
Xorg log after the corruption has been reproduced (X -> VT -> X) and restored
changing resolution

-- 
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/20140324/e5868001/attachment-0001.html>

[Bug 76559] screen corruption after going from VT to X

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

--- Comment #1 from Fabio Pedretti  ---
Created attachment 96296
  --> https://bugs.freedesktop.org/attachment.cgi?id=96296=edit
dmesg

-- 
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/20140324/5619e3c5/attachment.html>

[Bug 76559] New: screen corruption after going from VT to X

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

  Priority: medium
Bug ID: 76559
  Assignee: dri-devel at lists.freedesktop.org
   Summary: screen corruption after going from VT to X
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: fabio.ped at libero.it
  Hardware: x86 (IA32)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

I have a MacBook Pro with a RV530 with an external Philips 22" monitor
connected (the notebook screen is disabled in X). After switching to VT and
then coming back to X the screen is corrupted (like if every odd line has an
offset). The same happens after suspend. A screenshot doesn't show the problem.
I then usually change resolution with the Ubuntu tool (selecting a different
resolution and then reapplying the previous one) and that restore the screen.

Attached dmesg and Xorg log after the X -> VT -> X cycle.

-- 
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/20140324/73fc9456/attachment.html>

[Bug 76558] New: GPU lockup: radeon: wait for empty RBBM fifo failed ! when playing sauerbraten

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

  Priority: high
Bug ID: 76558
  Assignee: dri-devel at lists.freedesktop.org
   Summary: GPU lockup: radeon: wait for empty RBBM fifo failed !
when playing sauerbraten
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: fabio.ped at libero.it
  Hardware: x86 (IA32)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 96295
  --> https://bugs.freedesktop.org/attachment.cgi?id=96295=edit
dmesg after the lockup, got switching to a VT

I am using kernel 3.11.0-18.32 (default Ubuntu 13.10 kernel) with mesa from git
on a RV530. The system is usually very stable, however when running
sauerbreaten with wake6 map (sauerbraten-wake6 package on Debian/Ubuntu) this
way:
sauerbraten -lwake6

after some minutes I get the following lockup:

[ 8425.176130] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[ 8425.176144] radeon :01:00.0: GPU lockup (waiting for 0x2845
last fence id 0x2844)
[ 8425.349835] radeon: wait for empty RBBM fifo failed ! Bad things might
happen.
[ 8425.523469] Failed to wait GUI idle while programming pipes. Bad things
might happen.
[ 8425.524520] radeon :01:00.0: Saved 59 dwords of commands on ring 0.
[ 8425.530923] radeon :01:00.0: (rs600_asic_reset:401)
RBBM_STATUS=0x9401C100
[ 8426.029068] radeon :01:00.0: (rs600_asic_reset:421)
RBBM_STATUS=0x9401C100
[ 8426.526183] radeon :01:00.0: (rs600_asic_reset:429)
RBBM_STATUS=0x9400C100
[ 8427.023299] radeon :01:00.0: (rs600_asic_reset:437)
RBBM_STATUS=0x9400C100
[ 8427.023370] radeon :01:00.0: failed to reset GPU
[ 8427.024701] radeon :01:00.0: GPU reset failed
[ 8427.028124] radeon :01:00.0: couldn't schedule ib
[ 8427.028133] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
[ 8427.057855] radeon :01:00.0: couldn't schedule ib
...

Full dmesg is attached. After the lockup I can switch to/from console, but I
have to reboot because the screen is corrupted/flashing.

-- 
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/20140324/d0f07574/attachment.html>

3.14 radeon regression: radeon is broken (pci bug?)

2014-03-24 Thread Bjorn Helgaas

On Sat, Mar 22, 2014 at 9:18 AM, Andy Lutomirski  wrote:
> On Fri, Mar 21, 2014 at 9:37 AM, Bjorn Helgaas  wrote:
>> On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski  
>> wrote:
>>> On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher  
>>> wrote:
 On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski  
 wrote:
> My system works on a 3.13 Fedora kernel.  It does not work on a
> more-or-less identically configured 3.14-rc7+ kernel.  The symptom is
> that the Plymouth password prompt flashes and them the screen goes
> blank.  Hitting escape brings back the text console, and all is well
> until X tries to start.  Then I get a blank screen.  killall -9 Xorg
> from ssh causes these errors to be logged:
>
>
> [  226.239747] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  226.239751] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD34 (len 55, WS 0, PS 0) @ 0xCD57
> [  231.241492] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  231.241496] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
> [  236.243111] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  236.243115] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
> [  241.244625] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  241.244628] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>
>
> lspci -vvvxxxnn on 3.14-rc7+ says:
>
> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
> (rev ff) (prog-if ff)
> !!! Unknown header type 7f
> Kernel driver in use: radeon
> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98] (rev ff)
> (prog-if ff)
> !!! Unknown header type 7f
> Kernel driver in use: snd_hda_intel
> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> (oops!)
>
> On 3.13, it says:
>
> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
> (prog-if 00 [VGA controller])
> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
> 6450 1 GB DDR3 [174b:e164]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 92
> Region 0: Memory at e000 (64-bit, prefetchable) [size=256M]
> Region 2: Memory at f4a2 (64-bit, non-prefetchable) 
> [size=128K]
> Region 4: I/O ports at c000 [size=256]
> Expansion ROM at f4a0 [disabled] [size=128K]
> Capabilities: 
> Kernel driver in use: radeon
> 00: 02 10 79 67 07 04 10 00 00 00 00 03 10 00 80 00
> 10: 0c 00 00 e0 00 00 00 00 04 00 a2 f4 00 00 00 00
> 20: 01 c0 00 00 00 00 00 00 00 00 00 00 4b 17 64 e1
> 30: 00 00 a0 f4 50 00 00 00 00 00 00 00 0a 01 00 00
>
> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98]
> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
> 6450 1GB DDR3 [174b:aa98]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 96
> Region 0: Memory at f4a4 (64-bit, non-prefetchable) [size=16K]
> Capabilities: 
> Kernel driver in use: snd_hda_intel
> 00: 02 10 98 aa 06 04 10 00 00 00 03 04 10 00 80 00
> 10: 04 00 a4 f4 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 98 aa
> 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 02 00 00
>
> Logs attached.
>>
>> Hi Andy,
>>
>> I'm really sorry that you tripped over this, but

[PATCH 11/11] drm: Remove the ', ' after the function name in debug logs

Right now a debug message looks like:

  [drm:drm_ioctl], pid=860, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCRTC

That first comma looks weird as we already have ']' as a separator.
Remove it.

If anyone sees this commit message and also thinks that auth=1 isn't the
most useful info to have here, let's just say I'd happily review a patch
removing it. If I don't get annoyed enough to submit a patch, that is.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_stub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 9b14873..ed8a995 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -106,7 +106,7 @@ void drm_ut_debug_printk(const char *function_name, const 
char *format, ...)
vaf.fmt = format;
vaf.va = 

-   printk(KERN_DEBUG "[" DRM_NAME ":%s], %pV", function_name, );
+   printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, );

va_end(args);
 }
-- 
1.8.3.1

[PATCH 10/11] drm: Remove the prefix argument of drm_ut_debug_printk()

This is always DRM_NAME, so we can just make it part of the format
string instead of asking prink to do it for us.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_stub.c |  6 ++
 include/drm/drmP.h | 17 ++---
 2 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 0b1a912..9b14873 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -97,9 +97,7 @@ int drm_err(const char *func, const char *format, ...)
 }
 EXPORT_SYMBOL(drm_err);

-void drm_ut_debug_printk(const char *prefix,
-const char *function_name,
-const char *format, ...)
+void drm_ut_debug_printk(const char *function_name, const char *format, ...)
 {
struct va_format vaf;
va_list args;
@@ -108,7 +106,7 @@ void drm_ut_debug_printk(const char *prefix,
vaf.fmt = format;
vaf.va = 

-   printk(KERN_DEBUG "[%s:%s], %pV", prefix, function_name, );
+   printk(KERN_DEBUG "[" DRM_NAME ":%s], %pV", function_name, );

va_end(args);
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 87b558a..2f49510 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -121,9 +121,8 @@ struct videomode;
 #define DRM_UT_KMS 0x04
 #define DRM_UT_PRIME   0x08

-extern __printf(3, 4)
-void drm_ut_debug_printk(const char *prefix,
-const char *function_name,
+extern __printf(2, 3)
+void drm_ut_debug_printk(const char *function_name,
 const char *format, ...);
 extern __printf(2, 3)
 int drm_err(const char *func, const char *format, ...);
@@ -209,27 +208,23 @@ int drm_err(const char *func, const char *format, ...);
 #define DRM_DEBUG(fmt, args...)
\
do {\
if (unlikely(drm_debug & DRM_UT_CORE))  \
-   drm_ut_debug_printk(DRM_NAME, __func__, \
-   fmt, ##args);   \
+   drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)

 #define DRM_DEBUG_DRIVER(fmt, args...) \
do {\
if (unlikely(drm_debug & DRM_UT_DRIVER))\
-   drm_ut_debug_printk(DRM_NAME, __func__, \
-   fmt, ##args);   \
+   drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
 #define DRM_DEBUG_KMS(fmt, args...)\
do {\
if (unlikely(drm_debug & DRM_UT_KMS))   \
-   drm_ut_debug_printk(DRM_NAME, __func__, \
-   fmt, ##args);   \
+   drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
 #define DRM_DEBUG_PRIME(fmt, args...)  \
do {\
if (unlikely(drm_debug & DRM_UT_PRIME)) \
-   drm_ut_debug_printk(DRM_NAME, __func__, \
-   fmt, ##args);   \
+   drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
 #else
 #define DRM_DEBUG_DRIVER(fmt, args...) do { } while (0)
-- 
1.8.3.1

[PATCH 09/11] drm: drm_ut_debug_printk() isn't called with NULL anywmore

The DRM_LOG* macros where the only sites where drm_ut_debug_printk was
called with NULL arguments for prefix and function_name. Now that they
are gone, we can remove that case.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_stub.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 81ed832..0b1a912 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -108,11 +108,7 @@ void drm_ut_debug_printk(const char *prefix,
vaf.fmt = format;
vaf.va = 

-   if (function_name)
-   printk(KERN_DEBUG "[%s:%s], %pV", prefix,
-  function_name, );
-   else
-   printk(KERN_DEBUG "%pV", );
+   printk(KERN_DEBUG "[%s:%s], %pV", prefix, function_name, );

va_end(args);
 }
-- 
1.8.3.1

[PATCH 08/11] drm: Pull the test on drm_debug in the logging macros

In the logging code, we are currently checking is we need to output in
drm_ut_debug_printk(). This is too late. The problem is that when we write
something like:

DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
 connector->base.id,
 drm_get_connector_name(connector),
 connector->encoder->base.id,
 drm_get_encoder_name(connector->encoder));

We start by evaluating the arguments (so call drm_get_connector_name() and
drm_get_connector_name()) before ending up in drm_ut_debug_printk() which will
then does nothing.

This means we execute a lot of instructions (drm_get_connector_name(), in turn,
calls snprintf() for example) to happily discard them in the normal case,
drm.debug=0.

So, let's put the test on drm_debug earlier, in the macros themselves.
Sprinkle an unlikely() as well for good measure.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_stub.c | 26 --
 include/drm/drmP.h | 27 +++
 2 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index dc2c609..81ed832 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -97,26 +97,24 @@ int drm_err(const char *func, const char *format, ...)
 }
 EXPORT_SYMBOL(drm_err);

-void drm_ut_debug_printk(unsigned int request_level,
-const char *prefix,
+void drm_ut_debug_printk(const char *prefix,
 const char *function_name,
 const char *format, ...)
 {
struct va_format vaf;
va_list args;

-   if (drm_debug & request_level) {
-   va_start(args, format);
-   vaf.fmt = format;
-   vaf.va = 
-
-   if (function_name)
-   printk(KERN_DEBUG "[%s:%s], %pV", prefix,
-  function_name, );
-   else
-   printk(KERN_DEBUG "%pV", );
-   va_end(args);
-   }
+   va_start(args, format);
+   vaf.fmt = format;
+   vaf.va = 
+
+   if (function_name)
+   printk(KERN_DEBUG "[%s:%s], %pV", prefix,
+  function_name, );
+   else
+   printk(KERN_DEBUG "%pV", );
+
+   va_end(args);
 }
 EXPORT_SYMBOL(drm_ut_debug_printk);

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3055b36..87b558a 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -121,9 +121,8 @@ struct videomode;
 #define DRM_UT_KMS 0x04
 #define DRM_UT_PRIME   0x08

-extern __printf(4, 5)
-void drm_ut_debug_printk(unsigned int request_level,
-const char *prefix,
+extern __printf(3, 4)
+void drm_ut_debug_printk(const char *prefix,
 const char *function_name,
 const char *format, ...);
 extern __printf(2, 3)
@@ -209,24 +208,28 @@ int drm_err(const char *func, const char *format, ...);
 #if DRM_DEBUG_CODE
 #define DRM_DEBUG(fmt, args...)
\
do {\
-   drm_ut_debug_printk(DRM_UT_CORE, DRM_NAME,  \
-   __func__, fmt, ##args); \
+   if (unlikely(drm_debug & DRM_UT_CORE))  \
+   drm_ut_debug_printk(DRM_NAME, __func__, \
+   fmt, ##args);   \
} while (0)

 #define DRM_DEBUG_DRIVER(fmt, args...) \
do {\
-   drm_ut_debug_printk(DRM_UT_DRIVER, DRM_NAME,\
-   __func__, fmt, ##args); \
+   if (unlikely(drm_debug & DRM_UT_DRIVER))\
+   drm_ut_debug_printk(DRM_NAME, __func__, \
+   fmt, ##args);   \
} while (0)
-#define DRM_DEBUG_KMS(fmt, args...)\
+#define DRM_DEBUG_KMS(fmt, args...)\
do {\
-   drm_ut_debug_printk(DRM_UT_KMS, DRM_NAME,   \
-__func__, fmt, ##args);\
+   if (unlikely(drm_debug & DRM_UT_KMS))   \
+   drm_ut_debug_printk(DRM_NAME, __func__, \
+   fmt, ##args);   \
} while (0)
 #define DRM_DEBUG_PRIME(fmt, args...)  \
do {\
-   drm_ut_debug_printk(DRM_UT_PRIME, DRM_NAME, \
-

[PATCH 07/11] drm: Remove the now unused DRM_LOG* macros

Signed-off-by: Damien Lespiau 
---
 include/drm/drmP.h | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 1455e58..3055b36 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -228,30 +228,11 @@ int drm_err(const char *func, const char *format, ...);
drm_ut_debug_printk(DRM_UT_PRIME, DRM_NAME, \
__func__, fmt, ##args); \
} while (0)
-#define DRM_LOG(fmt, args...)  \
-   do {\
-   drm_ut_debug_printk(DRM_UT_CORE, NULL,  \
-   NULL, fmt, ##args); \
-   } while (0)
-#define DRM_LOG_KMS(fmt, args...)  \
-   do {\
-   drm_ut_debug_printk(DRM_UT_KMS, NULL,   \
-   NULL, fmt, ##args); \
-   } while (0)
-#define DRM_LOG_DRIVER(fmt, args...)   \
-   do {\
-   drm_ut_debug_printk(DRM_UT_DRIVER, NULL,\
-   NULL, fmt, ##args); \
-   } while (0)
 #else
 #define DRM_DEBUG_DRIVER(fmt, args...) do { } while (0)
 #define DRM_DEBUG_KMS(fmt, args...)do { } while (0)
 #define DRM_DEBUG_PRIME(fmt, args...)  do { } while (0)
 #define DRM_DEBUG(fmt, arg...)  do { } while (0)
-#define DRM_LOG(fmt, arg...)   do { } while (0)
-#define DRM_LOG_KMS(fmt, args...) do { } while (0)
-#define DRM_LOG_DRIVER(fmt, arg...) do { } while (0)
-
 #endif

 /*@}*/
-- 
1.8.3.1

[PATCH 06/11] staging: imx-drm: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()

There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().

Cc: Philipp Zabel 
Cc: Lucas Stach 
Signed-off-by: Damien Lespiau 
---
 drivers/staging/imx-drm/ipuv3-plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipuv3-plane.c 
b/drivers/staging/imx-drm/ipuv3-plane.c
index 34b642a..5128dc39 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -68,7 +68,7 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct 
drm_framebuffer *fb,

cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
if (!cma_obj) {
-   DRM_LOG_KMS("entry is null.\n");
+   DRM_DEBUG_KMS("entry is null.\n");
return -EFAULT;
}

-- 
1.8.3.1

[PATCH 05/11] drm/i915: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()

There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/dvo_ch7xxx.c |  4 ++--
 drivers/gpu/drm/i915/dvo_ivch.c   | 30 +++---
 drivers/gpu/drm/i915/dvo_ns2501.c | 10 +-
 drivers/gpu/drm/i915/dvo_sil164.c | 10 +-
 drivers/gpu/drm/i915/dvo_tfp410.c | 24 
 5 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c 
b/drivers/gpu/drm/i915/dvo_ch7xxx.c
index af42e94..a0f5bdd 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -340,9 +340,9 @@ static void ch7xxx_dump_regs(struct intel_dvo_device *dvo)
for (i = 0; i < CH7xxx_NUM_REGS; i++) {
uint8_t val;
if ((i % 8) == 0)
-   DRM_LOG_KMS("\n %02X: ", i);
+   DRM_DEBUG_KMS("\n %02X: ", i);
ch7xxx_readb(dvo, i, );
-   DRM_LOG_KMS("%02X ", val);
+   DRM_DEBUG_KMS("%02X ", val);
}
 }

diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
index baaf65b..0f1865d 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -377,41 +377,41 @@ static void ivch_dump_regs(struct intel_dvo_device *dvo)
uint16_t val;

ivch_read(dvo, VR00, );
-   DRM_LOG_KMS("VR00: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR00: 0x%04x\n", val);
ivch_read(dvo, VR01, );
-   DRM_LOG_KMS("VR01: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR01: 0x%04x\n", val);
ivch_read(dvo, VR30, );
-   DRM_LOG_KMS("VR30: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR30: 0x%04x\n", val);
ivch_read(dvo, VR40, );
-   DRM_LOG_KMS("VR40: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR40: 0x%04x\n", val);

/* GPIO registers */
ivch_read(dvo, VR80, );
-   DRM_LOG_KMS("VR80: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR80: 0x%04x\n", val);
ivch_read(dvo, VR81, );
-   DRM_LOG_KMS("VR81: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR81: 0x%04x\n", val);
ivch_read(dvo, VR82, );
-   DRM_LOG_KMS("VR82: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR82: 0x%04x\n", val);
ivch_read(dvo, VR83, );
-   DRM_LOG_KMS("VR83: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR83: 0x%04x\n", val);
ivch_read(dvo, VR84, );
-   DRM_LOG_KMS("VR84: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR84: 0x%04x\n", val);
ivch_read(dvo, VR85, );
-   DRM_LOG_KMS("VR85: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR85: 0x%04x\n", val);
ivch_read(dvo, VR86, );
-   DRM_LOG_KMS("VR86: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR86: 0x%04x\n", val);
ivch_read(dvo, VR87, );
-   DRM_LOG_KMS("VR87: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR87: 0x%04x\n", val);
ivch_read(dvo, VR88, );
-   DRM_LOG_KMS("VR88: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR88: 0x%04x\n", val);

/* Scratch register 0 - AIM Panel type */
ivch_read(dvo, VR8E, );
-   DRM_LOG_KMS("VR8E: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR8E: 0x%04x\n", val);

/* Scratch register 1 - Status register */
ivch_read(dvo, VR8F, );
-   DRM_LOG_KMS("VR8F: 0x%04x\n", val);
+   DRM_DEBUG_KMS("VR8F: 0x%04x\n", val);
 }

 static void ivch_destroy(struct intel_dvo_device *dvo)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 954acb2..8155ded 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -490,15 +490,15 @@ static void ns2501_dump_regs(struct intel_dvo_device *dvo)
uint8_t val;

ns2501_readb(dvo, NS2501_FREQ_LO, );
-   DRM_LOG_KMS("NS2501_FREQ_LO: 0x%02x\n", val);
+   DRM_DEBUG_KMS("NS2501_FREQ_LO: 0x%02x\n", val);
ns2501_readb(dvo, NS2501_FREQ_HI, );
-   DRM_LOG_KMS("NS2501_FREQ_HI: 0x%02x\n", val);
+   DRM_DEBUG_KMS("NS2501_FREQ_HI: 0x%02x\n", val);
ns2501_readb(dvo, NS2501_REG8, );
-   DRM_LOG_KMS("NS2501_REG8: 0x%02x\n", val);
+   DRM_DEBUG_KMS("NS2501_REG8: 0x%02x\n", val);
ns2501_readb(dvo, NS2501_REG9, );
-   DRM_LOG_KMS("NS2501_REG9: 0x%02x\n", val);
+   DRM_DEBUG_KMS("NS2501_REG9: 0x%02x\n", val);
ns2501_readb(dvo, NS2501_REGC, );
-   DRM_LOG_KMS("NS2501_REGC: 0x%02x\n", val);
+   DRM_DEBUG_KMS("NS2501_REGC: 0x%02x\n", val);
 }

 static void ns2501_destroy(struct intel_dvo_device *dvo)
diff --git a/drivers/gpu/drm/i915/dvo_sil164.c 
b/drivers/gpu/drm/i915/dvo_sil164.c
index 4debd32..7b3e9e9 100644
--- a/drivers/gpu/drm/i915/dvo_sil164.c
+++ b/drivers/gpu/drm/i915/dvo_sil164.c
@@ -246,15 +246,15 @@ static void sil164_dump_regs(struct intel_dvo_device *dvo)
uint8_t val;

sil164_readb(dvo, SIL164_FREQ_LO, );
-   DRM_LOG_KMS("SIL164_FREQ_LO: 0x%02x\n", val);
+   DRM_DEBUG_KMS("SIL164_FREQ_LO: 0x%02x\n",

[PATCH 04/11] drm/gma500: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()

There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().

Cc: Patrik Jakobsson 
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/gma500/psb_intel_sdvo.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index 07d3a9e..681efec 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -406,18 +406,18 @@ static void psb_intel_sdvo_debug_write(struct 
psb_intel_sdvo *psb_intel_sdvo, u8
DRM_DEBUG_KMS("%s: W: %02X ",
SDVO_NAME(psb_intel_sdvo), cmd);
for (i = 0; i < args_len; i++)
-   DRM_LOG_KMS("%02X ", ((u8 *)args)[i]);
+   DRM_DEBUG_KMS("%02X ", ((u8 *)args)[i]);
for (; i < 8; i++)
-   DRM_LOG_KMS("   ");
+   DRM_DEBUG_KMS("   ");
for (i = 0; i < ARRAY_SIZE(sdvo_cmd_names); i++) {
if (cmd == sdvo_cmd_names[i].cmd) {
-   DRM_LOG_KMS("(%s)", sdvo_cmd_names[i].name);
+   DRM_DEBUG_KMS("(%s)", sdvo_cmd_names[i].name);
break;
}
}
if (i == ARRAY_SIZE(sdvo_cmd_names))
-   DRM_LOG_KMS("(%02X)", cmd);
-   DRM_LOG_KMS("\n");
+   DRM_DEBUG_KMS("(%02X)", cmd);
+   DRM_DEBUG_KMS("\n");
 }

 static const char *cmd_status_names[] = {
@@ -512,9 +512,9 @@ static bool psb_intel_sdvo_read_response(struct 
psb_intel_sdvo *psb_intel_sdvo,
}

if (status <= SDVO_CMD_STATUS_SCALING_NOT_SUPP)
-   DRM_LOG_KMS("(%s)", cmd_status_names[status]);
+   DRM_DEBUG_KMS("(%s)", cmd_status_names[status]);
else
-   DRM_LOG_KMS("(??? %d)", status);
+   DRM_DEBUG_KMS("(??? %d)", status);

if (status != SDVO_CMD_STATUS_SUCCESS)
goto log_fail;
@@ -525,13 +525,13 @@ static bool psb_intel_sdvo_read_response(struct 
psb_intel_sdvo *psb_intel_sdvo,
  SDVO_I2C_RETURN_0 + i,
  &((u8 *)response)[i]))
goto log_fail;
-   DRM_LOG_KMS(" %02X", ((u8 *)response)[i]);
+   DRM_DEBUG_KMS(" %02X", ((u8 *)response)[i]);
}
-   DRM_LOG_KMS("\n");
+   DRM_DEBUG_KMS("\n");
return true;

 log_fail:
-   DRM_LOG_KMS("... failed\n");
+   DRM_DEBUG_KMS("... failed\n");
return false;
 }

-- 
1.8.3.1

[PATCH 03/11] drm/exynos: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()

There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().

Cc: Inki Dae 
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e7c2f2d..5fa342e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -90,7 +90,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
/* RGB formats use only one buffer */
buffer = exynos_drm_fb_buffer(fb, 0);
if (!buffer) {
-   DRM_LOG_KMS("buffer is null.\n");
+   DRM_DEBUG_KMS("buffer is null.\n");
return -EFAULT;
}

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index fcb0652..2c765d5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -87,7 +87,7 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
struct exynos_drm_gem_buf *buffer = exynos_drm_fb_buffer(fb, i);

if (!buffer) {
-   DRM_LOG_KMS("buffer is null\n");
+   DRM_DEBUG_KMS("buffer is null\n");
return -EFAULT;
}

-- 
1.8.3.1

[PATCH 02/11] drm: Remove the unused (and unusable) DRM_LOG_MODE()

This macro was trying to use the non existing DRM_UT_MODE debug category
and looks like it should be covered by DRM_LOG_KMS().

Signed-off-by: Damien Lespiau 
---
 include/drm/drmP.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 97900b7..1455e58 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -238,11 +238,6 @@ int drm_err(const char *func, const char *format, ...);
drm_ut_debug_printk(DRM_UT_KMS, NULL,   \
NULL, fmt, ##args); \
} while (0)
-#define DRM_LOG_MODE(fmt, args...) \
-   do {\
-   drm_ut_debug_printk(DRM_UT_MODE, NULL,  \
-   NULL, fmt, ##args); \
-   } while (0)
 #define DRM_LOG_DRIVER(fmt, args...)   \
do {\
drm_ut_debug_printk(DRM_UT_DRIVER, NULL,\
@@ -255,7 +250,6 @@ int drm_err(const char *func, const char *format, ...);
 #define DRM_DEBUG(fmt, arg...)  do { } while (0)
 #define DRM_LOG(fmt, arg...)   do { } while (0)
 #define DRM_LOG_KMS(fmt, args...) do { } while (0)
-#define DRM_LOG_MODE(fmt, arg...) do { } while (0)
 #define DRM_LOG_DRIVER(fmt, arg...) do { } while (0)

 #endif
-- 
1.8.3.1

[PATCH 01/11] drm: Refresh the explanation of debug categories

That comment wasn't super-readable, so I tried to improve it:

- Put the comment before the values it's documenting
- Add a mention to PRIME
- Reword things a bit to be a lighter read
- Add a note about the option to set the debug value at run-time

Signed-off-by: Damien Lespiau 
---
 include/drm/drmP.h | 57 ++
 1 file changed, 27 insertions(+), 30 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3857450..97900b7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -88,41 +88,38 @@ struct videomode;
 #include 
 #include 

-#define DRM_UT_CORE0x01
-#define DRM_UT_DRIVER  0x02
-#define DRM_UT_KMS 0x04
-#define DRM_UT_PRIME   0x08
 /*
- * Three debug levels are defined.
- * drm_core, drm_driver, drm_kms
- * drm_core level can be used in the generic drm code. For example:
- * drm_ioctl, drm_mm, drm_memory
- * The macro definition of DRM_DEBUG is used.
- * DRM_DEBUG(fmt, args...)
- * The debug info by using the DRM_DEBUG can be obtained by adding
- * the boot option of "drm.debug=1".
+ * 4 debug categories are defined:
+ *
+ * CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c, drm_memory.c, ...
+ *  This is the category used by the DRM_DEBUG() macro.
+ *
+ * DRIVER: Used in the vendor specific part of the driver: i915, radeon, ...
+ *This is the category used by the DRM_DEBUG_DRIVER() macro.
  *
- * drm_driver level can be used in the specific drm driver. It is used
- * to add the debug info related with the drm driver. For example:
- * i915_drv, i915_dma, i915_gem, radeon_drv,
- * The macro definition of DRM_DEBUG_DRIVER can be used.
- * DRM_DEBUG_DRIVER(fmt, args...)
- * The debug info by using the DRM_DEBUG_DRIVER can be obtained by
- * adding the boot option of "drm.debug=0x02"
+ * KMS: used in the modesetting code.
+ * This is the category used by the DRM_DEBUG_KMS() macro.
  *
- * drm_kms level can be used in the KMS code related with specific drm driver.
- * It is used to add the debug info related with KMS mode. For example:
- * the connector/crtc ,
- * The macro definition of DRM_DEBUG_KMS can be used.
- * DRM_DEBUG_KMS(fmt, args...)
- * The debug info by using the DRM_DEBUG_KMS can be obtained by
- * adding the boot option of "drm.debug=0x04"
+ * PRIME: used in the prime code.
+ *   This is the category used by the DRM_DEBUG_PRIME() macro.
  *
- * If we add the boot option of "drm.debug=0x06", we can get the debug info by
- * using the DRM_DEBUG_KMS and DRM_DEBUG_DRIVER.
- * If we add the boot option of "drm.debug=0x05", we can get the debug info by
- * using the DRM_DEBUG_KMS and DRM_DEBUG.
+ * Enabling verbose debug messages is done through the drm.debug parameter,
+ * each category being enabled by a bit.
+ *
+ * drm.debug=0x1 will enable CORE messages
+ * drm.debug=0x2 will enable DRIVER messages
+ * drm.debug=0x3 will enable CORE and DRIVER messages
+ * ...
+ * drm.debug=0xf will enable all messages
+ *
+ * An interesting feature is that it's possible to enable verbose logging at
+ * run-time by echoing the debug value in its sysfs node:
+ *   # echo 0xf > /sys/module/drm/parameters/debug
  */
+#define DRM_UT_CORE0x01
+#define DRM_UT_DRIVER  0x02
+#define DRM_UT_KMS 0x04
+#define DRM_UT_PRIME   0x08

 extern __printf(4, 5)
 void drm_ut_debug_printk(unsigned int request_level,
-- 
1.8.3.1

[PATCH 00/11] A few patches around DRM logging

As patch 8/11 explains, I noticed that we where evaluating the arguments to
drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good
reason. By pulling the test on drm_debug before calling drm_ut_debug_printk(),
we skip those instructions that only need to be executed when logging is on.

The remaining patches are bonus clean-ups, with the main goal of removing
DRM_LOG* macros that are not really used throughout the code base. After that,
it's possible to simplify a bit drm_ut_debug_printk(). All pretty
straightforward cleanups, but still worthwhile IMHO.

For driver-specific patches (why some of you are Cced in that series), I'd love
if you could take the time to throw a Acked-by/Reviewed-by tag. Also, do you
have any objection if the driver specific patch go through the DRM tree?
should people judge that series worthwhile, of course.

-- 
Damien

Damien Lespiau (11):
  drm: Refresh the explanation of debug categories
  drm: Remove the unused (and unusable) DRM_LOG_MODE()
  drm/exynos: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
  drm/gma500: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
  drm/i915: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
  staging: imx-drm: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()
  drm: Remove the now unused DRM_LOG* macros
  drm: Pull the test on drm_debug in the logging macros
  drm: drm_ut_debug_printk() isn't called with NULL anywmore
  drm: Remove the prefix argument of drm_ut_debug_printk()
  drm: Remove the ',' after the function name in debug logs

 drivers/gpu/drm/drm_stub.c|  24 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   2 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  20 +++---
 drivers/gpu/drm/i915/dvo_ch7xxx.c |   4 +-
 drivers/gpu/drm/i915/dvo_ivch.c   |  30 -
 drivers/gpu/drm/i915/dvo_ns2501.c |  10 +--
 drivers/gpu/drm/i915/dvo_sil164.c |  10 +--
 drivers/gpu/drm/i915/dvo_tfp410.c |  24 +++
 drivers/staging/imx-drm/ipuv3-plane.c |   2 +-
 include/drm/drmP.h| 106 +++---
 11 files changed, 98 insertions(+), 136 deletions(-)

-- 
1.8.3.1

[BUG] Circular locking dependency - DRM/CMA/MM/hotplug/...

2014-03-24 Thread Michal Nazarewicz

true;
>  }
> -- 
> Code Aurora Forum chooses to take this file under the GPL v 2 license only.
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Micha? ?mina86? Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/bfcfa73d/attachment-0001.sig>

[Bug 76490] No output after radeon module is loaded (R9 270X)

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

--- Comment #3 from Alex Deucher  ---
Does booting with radeon.runpm=0 on the kernel command line in grub also help?

-- 
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/20140324/0ca02cc4/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

--- Comment #4 from Alex Deucher  ---
Created attachment 96290
  --> https://bugs.freedesktop.org/attachment.cgi?id=96290=edit
testing patch

Does the attached patch help?  It disables most dpm features.  If so can you
narrow down which specific features are problematic?

-- 
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/20140324/1c3dafc4/attachment.html>

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] ERROR Timeout setting UVD clocks!

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

--- Comment #4 from Alex Deucher  ---
(In reply to comment #3)
> same problem here. UVD is initialised properly but setting clocks timesout.

If this is a regression, can you bisect?

-- 
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/20140324/380cd386/attachment.html>

[Bug 72701] Screen freeze when using radeon driver

2014-03-24 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #3 from Alex Deucher  ---
These patches should fix it:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9babd35ad72af631547c7ca294bc2e931cc40e58
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7848865914c6a63ead674f0f5604b77df7d3874f

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 00/12] drm/nouveau: support for GK20A, cont'd

2014-03-24 Thread Lucas Stach

Hi Alexandre,

Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
> Hi everyone,
[...]
> 
> A few lines of hacks (not included here) are still needed to deal with cached
> mappings triggering external aborts and CPU/GPU memory coherency issues, but I
> hope to understand and address these issues next.

For the coherency issue part you may want to look at my Nouveau on ARM
series. Most of it never made it upstream, as I lacked the time to work
further on this, but it solves the coherency issue from the kernel.

It does so by doing the necessary manual cache flushes/invalidates on
buffer access, so costs some performance. To avoid this you really want
to get writecombined mappings into the kernel<->userspace interface.
Simply mapping the pushbuf as WC/US has brought a 7% performance
increase in OpenArena when I last tested this. This test was done with
only one PCIe lane, so the perf increase may be even better with a more
adequate interconnect.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

2014-03-24 Thread Mikulas Patocka



On Mon, 24 Mar 2014, Daniel Vetter wrote:

> On Mon, Mar 24, 2014 at 07:45:47AM +1000, Dave Airlie wrote:
> > On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr  wrote:
> > > On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
> > >> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr  wrote:
> > >> >
> > >> > which did end up flawless on 3.12.0-rc2+, too
> > >> > (but failed to improve the issue on 3.14.0-rc7+).
> > >> >
> > >> > So, for all intents and purposes, drm infrastructure seems unavoidably
> > >> > (neither dri disable nor libdrm upgrade helps) affected.
> > >> > Does anyone know which change caused that issue?
> > >> > (I'm asking because bisect here would be relatively painful).
> > >>
> > >> So 3.12-rc2 works. Does 3.13 work? Is this a regression in the current
> > >> 3.14 rc only, or did it happen already in the previous release?
> > >
> > > Hmm, given that Mikulas in
> > > https://lkml.org/lkml/2014/2/26/537
> > > offered a diff of linux-3.13.5 files, it truly seems (shock! ack! noo!)
> > > that that indeed may have been a regression at <= 3.13 proper even
> > > (which may pose interesting questions about the level of testing coverage
> > > we still enjoy [not!?] in this hardware area).

That patch drops a mutex, so it is not correct. There is mutex resursion - 
we need to uninstall the irq in drm_master_destroy, because here we are 
committed to destroy the device. But the routine that uninstalls the irq 
takes struct_mutex, which is already held in drm_master_destroy.

I suppose that the person who maintains drm reworks the patch so that it's 
correct:

- could we use a different mutex to protect the irq in drm_irq.c? Or 
possibly no mutex at all and use cmpxchg to manipulate the variable 
dev->irq_enabled? - this seems like the best solution. But I am not sure 
if the code in drm_irq.c somehow depends on the facts that other parts of 
the drm subsystem take struct_mutex.

- could we pass a new argument to drm_irq_uninstall that tells it not to 
take the mutex? drm_master_destroy would set this argument to 1. 
drm_master_destroy is mostly called with struct_mutex held, but there may 
be places in vmwgfx_drv.c where drm_master_put (which calls 
drm_master_destroy) may be called without struct_mutex held.

Is it true that drm_master_destroy can be called without struct_mutex 
held? I don't know.


I think drm maintainer should sort out the above issues and modify the 
patch accordingly.

> > > Oh well, seems I'll have to prepare/build 3.13 now...
> > 
> > It's > 15 year old hardware, so yes I believe we have close to 0
> > testing coverage on it outside of distros,
> > 
> > I'm not even sure I have one anymore, I might be able to test an MGA in one 
> > box.
> 
> I haven't done a full read of all the related code, but this smells like a
> similar bug I've hit all over the place in the i810 driver (another one of
> those undead drm drivers of yonders). Ingredients:
> 
> 1) Xorg creates a drm mapping of the register space.
> 2) Xorg tells the hw-specific drm which drm mapping has the hw registers,
> and the driver uses that. Iirc this has been done as some form of OS
> abstraction. Also note that these mappings aren't refcounted, so the first
> guy to call drm_rmmap wins.
> 
> -> All hell breaks loose if Xorg dies and takes all it's mappings with it
> (in master_destroy, since the Xorg /dev fd is the master) and leaves the
> driver hanging in the air if there's an interrupt still pending (or
> anything else fwiw).

For me that crash happened when xorg exited with a fatal error too.

Mikulas

[DRM] drm_get_connector_name internal static string buffer causes a race

2014-03-24 Thread Dmitry Malkin

 14:23:16 haswell01 kernel: [  429.326282]  [] 
intel_modeset_cleanup+0xd0/0x100 [i915]
Mar 24 14:23:16 haswell01 kernel: [  429.326288]  [] 
i915_driver_unload+0x290/0x340 [i915]
Mar 24 14:23:16 haswell01 kernel: [  429.326294]  [] 
drm_dev_unregister+0x2c/0xe0 [drm]
Mar 24 14:23:16 haswell01 kernel: [  429.326299]  [] 
drm_put_dev+0x3b/0x70 [drm]
Mar 24 14:23:16 haswell01 kernel: [  429.326304]  [] 
i915_pci_remove+0x1d/0x20 [i915]
Mar 24 14:23:16 haswell01 kernel: [  429.326307]  [] 
pci_device_remove+0x3b/0xb0
Mar 24 14:23:16 haswell01 kernel: [  429.326310]  [] 
__device_release_driver+0x7f/0xf0
Mar 24 14:23:16 haswell01 kernel: [  429.326313]  [] 
device_release_driver+0x23/0x30
Mar 24 14:23:16 haswell01 kernel: [  429.326315]  [] 
unbind_store+0xbd/0xe0
Mar 24 14:23:16 haswell01 kernel: [  429.326317]  [] 
drv_attr_store+0x24/0x40
Mar 24 14:23:16 haswell01 kernel: [  429.326320]  [] 
sysfs_write_file+0x128/0x1c0
Mar 24 14:23:16 haswell01 kernel: [  429.326323]  [] 
vfs_write+0xb4/0x1f0
Mar 24 14:23:16 haswell01 kernel: [  429.326325]  [] 
SyS_write+0x49/0xa0
Mar 24 14:23:16 haswell01 kernel: [  429.326328]  [] 
tracesys+0xe1/0xe6
Mar 24 14:23:16 haswell01 kernel: [  429.326329] Code: 58 c7 81 e8 7d 98 4e 00 
48 83 c4 50 89 d8 5b 41 5c 41 5d 5d c3 bb fe ff ff ff eb e0 66 0f 1f 84 00 00 
00 00 00 0f 1f 44 00 00 55 <48> 8b 7f 30 48 8b 36 48 89 e5 e8 bb 22 00 00 5d c3 
66 0f 1f 84
Mar 24 14:23:16 haswell01 kernel: [  429.326351] RIP  [] 
sysfs_remove_file_ns+0x6/0x20
Mar 24 14:23:16 haswell01 kernel: [  429.326353]  RSP 
Mar 24 14:23:16 haswell01 kernel: [  429.326355] CR2: 002f
Mar 24 14:23:16 haswell01 kernel: [  429.326356] ---[ end trace 
8cd466c131375550 ]---



-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/4995bd56/attachment-0001.html>

[pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked()

2014-03-24 Thread Bjorn Helgaas

On Sun, Mar 23, 2014 at 8:53 AM, Fengguang Wu  wrote:
> Hi Bjorn,
>
> On Fri, Mar 21, 2014 at 12:42:33PM -0600, Bjorn Helgaas wrote:
>> On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu  
>> wrote:
>> > // CC Stephane for RAPL related bug
>> >
>> > Bjorn, sorry this bug report is mis-titled. The only new bug that show
>> > up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so
>> > it's hard to reproduce and the bisect is likely not accurate.  I'll
>> > retry the bisect with more repeat count. Sorry for the disturbing!
>>
>> This testing is potentially very useful, but only if we don't have
>> many false positives.  I spent a lot of time trying to figure this
>> out, and it turned out not to be a problem at all.
>
> I'm sorry for the false report! I'll be careful and improve the
> process. Currently there are many false positives in our internal
> boot error bisects. And we rely on human reviews to select good
> bisects out of the noises. In this case both the script and me made
> mistakes, which lead to the wrong report.
>
>> As a procedural question, can you help me figure out how to handle a
>> report like this?  What I *hoped* for would be:
>>
>>   - the config you used
>
> Yes.
>
>>   - the dmesg log from the newest good commit
>
> I'll attach it if the first bad commit's parent commit(s) has some
> noise errors. In this case it may help decide whether the bisect is
> wrong: in some cases one bug will hide another one; or the bug message
> may change from one to the other.
>
>>   - the dmesg log from the oldest bad commit (the one you bisected to)
>
> OK, I've fixed the script to attach it (rather than attaching the
> branch HEAD's dmesg).
>
>>   - maybe a hint about how I can reproduce the problem, e.g., the qemu
>> config I need
>
> OK, fixed the reporting script to include the QEMU commands for
> reproducing the problem.
>
>> You did supply the config, which is good.  But you only supplied one
>> dmesg log, and it doesn't seem to be from the oldest bad commit.  In
>> fact, it seems to be from some commit that isn't actually in either
>> Linus' tree or in linux-next.  So I don't know what the connection is
>> with the bad commit.
>
> Sorry the dmesg file is from the internal merge-and-testing branch's
> HEAD -- where the bisect starts.  I'll attach the first bad commit's
> dmesg instead.
>
>> What should I do to try to debug a report like this?  Where should I start?
>
> Thank you very much for the suggestions!

Excellent, thanks!  I think these will make it much easier to figure
out where to start.

Bjorn

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

On Mon, Mar 24, 2014 at 07:45:47AM +1000, Dave Airlie wrote:
> On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr  wrote:
> > On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
> >> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr  wrote:
> >> >
> >> > which did end up flawless on 3.12.0-rc2+, too
> >> > (but failed to improve the issue on 3.14.0-rc7+).
> >> >
> >> > So, for all intents and purposes, drm infrastructure seems unavoidably
> >> > (neither dri disable nor libdrm upgrade helps) affected.
> >> > Does anyone know which change caused that issue?
> >> > (I'm asking because bisect here would be relatively painful).
> >>
> >> So 3.12-rc2 works. Does 3.13 work? Is this a regression in the current
> >> 3.14 rc only, or did it happen already in the previous release?
> >
> > Hmm, given that Mikulas in
> > https://lkml.org/lkml/2014/2/26/537
> > offered a diff of linux-3.13.5 files, it truly seems (shock! ack! noo!)
> > that that indeed may have been a regression at <= 3.13 proper even
> > (which may pose interesting questions about the level of testing coverage
> > we still enjoy [not!?] in this hardware area).
> >
> > Oh well, seems I'll have to prepare/build 3.13 now...
> 
> It's > 15 year old hardware, so yes I believe we have close to 0
> testing coverage on it outside of distros,
> 
> I'm not even sure I have one anymore, I might be able to test an MGA in one 
> box.

I haven't done a full read of all the related code, but this smells like a
similar bug I've hit all over the place in the i810 driver (another one of
those undead drm drivers of yonders). Ingredients:

1) Xorg creates a drm mapping of the register space.
2) Xorg tells the hw-specific drm which drm mapping has the hw registers,
and the driver uses that. Iirc this has been done as some form of OS
abstraction. Also note that these mappings aren't refcounted, so the first
guy to call drm_rmmap wins.

-> All hell breaks loose if Xorg dies and takes all it's mappings with it
(in master_destroy, since the Xorg /dev fd is the master) and leaves the
driver hanging in the air if there's an interrupt still pending (or
anything else fwiw).

In my case with i810 it was some subtle thing with error codes somewhere
else (iirc, been a while) which made Xorg fall over a bit differently and
so crash the kernel. Presuming this is the case I think we need a proper
bisect here to figure out the root-cause and re-apply the lost duct-tape.

"Properly" fixing the underlying bug for any sane definition of "proper"
is impossible - the legacy drm driver model is just too broken for that.
And for new-style drivers killing the irq support when they don't expect
it is not cool, since those drivers are sane and assume full control over
all hw interactions (not like their legacy bethren).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Linaro-mm-sig] [PATCH] dma-buf: add meta data attachment

Hi all,

Adding piles more people.

For the first case of caching the iommu mapping there's different
answers, depening upon the exact case:

1) You need to fix your userspace to not constantly re-establish the sharing.

2) We need to add streaming dma support for real to dma-bufs so that
the mapping can be kept while we transfer ownership around. Thus far
no one really needed this though since usually you don't actually do
cpu access.

3) You need opportunistic caching of imported/exported buffer objects
and their mappings. For this you need a) subsystem import/export
support which guarantees you to hand out the same dma-buf/native
object again upon re-export or re-import (drm has it) b) some
opportunistic caching of buffer objects (pretty much are real gpu drm
drivers have it). No need of any metadata scheme, and given how much
fun I've had implemented this for drm I don't you can make your
metadata scheme work in a sane or correct way wrt lifetimes.

For caching the iommu mapping if the iommu is the same for multiple devices:

1) We need some way to figure out which iommu serves which devices.

2) The exporter needs to consult this and might just hand out the same
sg mapping out again if it wants to.

No need for importers to do fancy stuff, or attach any
importer-visible metadata to dma-bufs. Of course duplicating this code
all over the place is a but uncool, so I expect that eventually we'll
have a generic exporter implementation, at least for non-swappable
buffers. drm/gem is a bit special here ...

In general I don't like the idea of arbitrary metadata at all, sounds
prone to abuse with crazy lifetime/refcounting rules for the objects
involved. Also I think for a lot of your examples (like debugging) it
would be much better if we have a standardized piece of metadata so
that all drivers/platforms can use the same tooling.

And it feels like I'm writing such a mail every few months ...

Cheers, Daniel

On Mon, Mar 24, 2014 at 7:20 AM, Bin Wang  wrote:
> Hi Sumit,
>
> On 03/21/2014 07:26 PM, Sumit Semwal wrote:
>> Hi Bin Wang,
>>
>> On 21 March 2014 10:34, Bin Wang  wrote:
>>> we found there'd be varied specific data connected to a dmabuf, like
>>> the iommu mapping of buffer, the dma descriptors (that can be shared
>>> between several components). Though these info might be able to be
>>> generated every time before dma operations, for performance sake,
>>> it's better to be kept before really invalid.
>> Thanks for your patch!
>> I think we'd need to have more specific details on what does 'meta
>> data' mean here; more specific comments inline.
>>> Change-Id: I89d43dc3fe1ee3da91c42074da5df71b968e6d3c
>>> Signed-off-by: Bin Wang 
>>> ---
>>>   drivers/base/dma-buf.c  |  100 
>>> +++
>>>   include/linux/dma-buf.h |   22 ++
>>>   2 files changed, 122 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
>>> index 08fe897..5c82e60 100644
>>> --- a/drivers/base/dma-buf.c
>>> +++ b/drivers/base/dma-buf.c
>>> @@ -50,6 +50,7 @@ static int dma_buf_release(struct inode *inode, struct 
>>> file *file)
>>>
>>>  BUG_ON(dmabuf->vmapping_counter);
>>>
>>> +   dma_buf_meta_release(dmabuf);
>>>  dmabuf->ops->release(dmabuf);
>>>
>>>  mutex_lock(_list.lock);
>>> @@ -138,6 +139,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
>>> struct dma_buf_ops *ops,
>>>
>>>  mutex_init(>lock);
>>>  INIT_LIST_HEAD(>attachments);
>>> +   INIT_LIST_HEAD(>metas);
>>>
>> I am not sure I understand the relationship of 'meta data' with
>> 'dma-buf', or 'attachments' - do you mean to have a list of some
>> meta-data that is unrelated to the attachments to the dma-buf? I think
>> it'd help to explain whether meta-data is specific to each dma-buf,
>> and there's a list of them, or this meta-data is related to each
>> importer device attachment?
>> If it's related to each importer, it should really be added as part of
>> the dma_buf_attachment, and not separately.
> The "meta-data" here can be any kind of data related to the dmabuf, , it's 
> specific
> for each dmabuf.
>
> For example, we have iommu for a VPU device, VPU driver has
> to map the dmabuf to get an IOVA address before it can access the buffer. This
> dmabuf would be reused many times during the video playback, for performance
> concern we don't want this dmabuf be map/unmaped by iommu driver every time
> of VPU HW data transfer, since the physical pages not changed and iommu IOVA
> plenty.
>
> Another example, in our SoC, device A and device B use the same dma chain 
> format,
> and these drivers share dmabuf between each other, thus the "dma chain"
> array doesn't need to be generated every timer for each device.
>
> So here, with the help from the "meta-data", only the "first time" we need to 
> generate
> the "meta-data" from scratch, and later we can just reuse it until the buffer 
> freed.
>
> The "meta-data" is

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

2014-03-24 Thread Dave Airlie

On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr  wrote:
> On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
>> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr  wrote:
>> >
>> > which did end up flawless on 3.12.0-rc2+, too
>> > (but failed to improve the issue on 3.14.0-rc7+).
>> >
>> > So, for all intents and purposes, drm infrastructure seems unavoidably
>> > (neither dri disable nor libdrm upgrade helps) affected.
>> > Does anyone know which change caused that issue?
>> > (I'm asking because bisect here would be relatively painful).
>>
>> So 3.12-rc2 works. Does 3.13 work? Is this a regression in the current
>> 3.14 rc only, or did it happen already in the previous release?
>
> Hmm, given that Mikulas in
> https://lkml.org/lkml/2014/2/26/537
> offered a diff of linux-3.13.5 files, it truly seems (shock! ack! noo!)
> that that indeed may have been a regression at <= 3.13 proper even
> (which may pose interesting questions about the level of testing coverage
> we still enjoy [not!?] in this hardware area).
>
> Oh well, seems I'll have to prepare/build 3.13 now...

It's > 15 year old hardware, so yes I believe we have close to 0
testing coverage on it outside of distros,

I'm not even sure I have one anymore, I might be able to test an MGA in one box.

Dave.

[Bug 76490] No output after radeon module is loaded (R9 270X)

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

--- Comment #2 from Gustavo Lopes  ---
Things seem to work fine with radeon.dpm=0.

-- 
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/20140324/ebba1264/attachment.html>

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

2014-03-24 Thread Sebastian Hesselbarth

On 03/23/2014 09:03 PM, Russell King - ARM Linux wrote:
> On Sun, Mar 23, 2014 at 07:12:05PM +0100, Sebastian Hesselbarth wrote:
>> On 03/23/2014 11:19 AM, Jean-Francois Moine wrote:
>>> On Fri, 21 Mar 2014 14:37:52 +0100
>>> Sebastian Hesselbarth  wrote:
> Required properties;
> -  - compatible: must be "nxp,tda998x"
> +  - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"

 There is a "DT is ABI" policy and although there is no mainline Linux
 user of current compatible, the correct way would be to deprecate
 "nxp,tda998x" and introduce new compatibles.
>>>
>>> Pratically, what is this way?
>>
>> Currently, there is no effective way to deprecate a binding or
>> compatible. You just add the one(s) that are more sensible and
>> you mark the old one as DEPRECATED by simply writing it in the
>> binding doc.
>>
>> The driver should support the old binding at least for a while.
>
> It doesn't need to - it's only been in development trees so far, and
> never been in a mainline full release.  Until it does, the binding
> does not become stable.

Ok, I see. Thanks for the clarification. A note about it would
have been nice though. Anyway, sorry for the noise.

Sebastian

[Bug 76531] linux-3.14-rc7 radeon/nouveau runtime-suspend never coming back

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

--- Comment #2 from Bruno  ---
Created attachment 96263
  --> https://bugs.freedesktop.org/attachment.cgi?id=96263=edit
Kernel log, nouveau_pmops_runtime_suspend() returning -EBUSY

Kernel log, nouveau_pmops_runtime_suspend() returning -EBUSY


What enlightenment complains about on stderr:
E_RANDR Event: Screen Change: 320 200
E_RANDR Event: Output Change
Output: 97
No Crtc
Mode: 0
Output Connected
Looping Our Crtc Configs
Looping Our Output Configs on this Crtc: 95
Found Output 97 on Crtc: 95
Output Has No Crtc Assigned
E_RANDR Event: Output Change
Output: 98
No Crtc
Mode: 0
Output Disconnected
Looping Our Crtc Configs
Looping Our Output Configs on this Crtc: 95
Looping Our Output Configs on this Crtc: 96



xrandr --verbose:
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192
LVDS-1 connected primary 1280x800+0+0 (0x64) normal (normal left inverted right
x axis y axis) 286mm x 179mm
Identifier: 0x61
Timestamp:  385919
Subpixel:   unknown
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter:
EDID:
00000610909c01010101
10110103801d12780a90b59958528e26
1e50540001010101010101010101
010101010101521c008f50202e303020
36001eb31018000100061020
0a2000fe0042
31455730332056320a2000fe
00436f6c6f72204c43440a20202000af
dithering depth: auto
supported: auto, 6 bpc, 8 bpc
dithering mode: auto
supported: auto, off, static 2x2, dynamic 2x2
scaling mode: Full
supported: None, Full, Center, Full aspect
color vibrance: 150
range: (0, 200)
vibrant hue: 90
range: (0, 180)
  1280x800 (0x64)   72.5MHz -HSync -VSync *current +preferred
h: width  1280 start 1328 end 1360 total 1423 skew0 clock   50.9KHz
v: height  800 start  803 end  809 total  846   clock   60.2Hz
  1024x768 (0x65)   63.5MHz -HSync +VSync
h: width  1024 start 1072 end 1176 total 1328 skew0 clock   47.8KHz
v: height  768 start  771 end  775 total  798   clock   59.9Hz
  800x600 (0x66)   38.2MHz -HSync +VSync
h: width   800 start  832 end  912 total 1024 skew0 clock   37.4KHz
v: height  600 start  603 end  607 total  624   clock   59.9Hz
  640x480 (0x67)   23.8MHz -HSync +VSync
h: width   640 start  664 end  720 total  800 skew0 clock   29.7KHz
v: height  480 start  483 end  487 total  500   clock   59.4Hz
  720x400 (0x68)   22.2MHz -HSync +VSync
h: width   720 start  744 end  808 total  896 skew0 clock   24.8KHz
v: height  400 start  403 end  413 total  417   clock   59.6Hz
  640x400 (0x69)   20.0MHz -HSync +VSync
h: width   640 start  664 end  720 total  800 skew0 clock   25.0KHz
v: height  400 start  403 end  409 total  417   clock   60.0Hz
  640x350 (0x6a)   17.5MHz -HSync +VSync
h: width   640 start  664 end  720 total  800 skew0 clock   21.9KHz
v: height  350 start  353 end  363 total  366   clock   59.8Hz
DP-1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x62
Timestamp:  385919
Subpixel:   unknown
Clones:
CRTCs:  1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter:
dithering depth: auto
supported: auto, 6 bpc, 8 bpc
dithering mode: auto
supported: auto, off, static 2x2, dynamic 2x2
scaling mode: Full
supported: None, Full, Center, Full aspect
color vibrance: 150
range: (0, 200)
vibrant hue: 90
range: (0, 180)
underscan vborder: 0
range: (0, 128)
underscan hborder: 0
range: (0, 128)
underscan: off
supported: auto, off, on


Nothing useful in Xorg log:
[   105.060] (II) NOUVEAU(0): EDID vendor "APP", prod id 40080
[   105.060] (II) NOUVEAU(0): Printing DDC gathered Modelines:
[   105.060] (II) NOUVEAU(0): Modeline "1280x800"x0.0   72.50  1280 1328 1360
1423  800 803 809 846 -hsync -vsync (50.9 kHz eP)
[   116.307] (II) NOUVEAU(0): EDID vendor "APP",

[Bug 76531] linux-3.14-rc7 radeon/nouveau runtime-suspend never coming back

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

--- Comment #1 from Bruno  ---
Created attachment 96260
  --> https://bugs.freedesktop.org/attachment.cgi?id=96260=edit
Kernel log, nouveau_pmops_runtime_suspend() returning -EINVAL

Kernel log for nouveau_pmops_runtime_suspend() returning -EINVAL

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 76531] New: linux-3.14-rc7 radeon/nouveau runtime-suspend never coming back