[REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-08 Thread Tom Gundersen 
Hi David,

On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann  wrote:
> Attached are two patches. The first one should fix this issue, the
> second one is the rebased ioremap_wc() patch from the other thread.
>
> Does this fix the issue (and the speed-problems)?

Sadly, no. I added a few printk's to verify that the function you
added is called (it is), but still the same oops.

The slowdown is (still) fixed though :-)

dmesg attached.

Cheers,

Tom
-- next part --
A non-text attachment was scrubbed...
Name: dmesg-i915-oops
Type: application/octet-stream
Size: 141121 bytes
Desc: not available
URL:

Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-08 Thread Tom Gundersen 
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen t...@jklm.no wrote:
 Hi David,

 On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no wrote:
 On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrm...@gmail.com 
 wrote:
 Attached are two patches. The first one should fix this issue, the
 second one is the rebased ioremap_wc() patch from the other thread.

 Does this fix the issue (and the speed-problems)?

 Sadly, no. I added a few printk's to verify that the function you
 added is called (it is), but still the same oops.

 A few more datapoints:

 Triggers:
 X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded)
 X86_SYSFB=y and FB_SIMPLE=y

 Does not trigger:
 X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we
 fall back to efifb)
 X86_SYSFB=n and FB_EFI=y
 X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded)

 Does this make any sense?

 Thanks a lot for these results. I think I got it know. I will write a
 patch that marks the resource as busy. See:
   kernel/resource.c iomem_map_sanity_check()
 It also contains a hint that we should set this for driver-resources
 which not directly map to hardware resources (such as veasfb and,
 obviously, simplefb).

 Following a diff which hopefully fixes this. The other two patches
 should still be required, though. I will try to write a proper patch
 tomorrow.

 Thanks a lot for these extensive tests, Tom!

No problem. Thanks for the fix, it works for me!

Cheers,

Tom

 diff --git a/arch/x86/kernel/sysfb_simplefb.c 
 b/arch/x86/kernel/sysfb_simplefb.c
 index 22513e9..b7bb615 100644
 --- a/arch/x86/kernel/sysfb_simplefb.c
 +++ b/arch/x86/kernel/sysfb_simplefb.c
 @@ -79,7 +79,7 @@ __init int create_simplefb(const struct screen_info *si,

 /* setup IORESOURCE_MEM as framebuffer memory */
 memset(res, 0, sizeof(res));
 -   res.flags = IORESOURCE_MEM;
 +   res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 res.name = simplefb_resname;
 res.start = si-lfb_base;
 res.end = si-lfb_base + len - 1;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/6] SimpleDRM Driver

2013-09-08 Thread Tom Gundersen 
Hi David,

On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 With the upcoming 3.12 merge-window, I thought people might find themselves 
 with
 nothing to do, so here's a new SimpleDRM series. Comments welcome!

 This depends on the tip/x86/fb series in the x86-tip tree:
   http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/fb
 Which, as far as I understood, will be pushed into 3.12 by the x86 people.

 FYI, this is now merged in Linus' tree. See:
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=228abe73ad67665d71eacd6a8a347dd76b0115ae

 So hopefully we can get SimpleDRM ready for 3.13.

Now that simplefb works for me, I finally got around to testing this.
Just a couple of comments:

 * I guess you need to add the modalias platform:simple-framebuffer
in addition to the of:... one to get module auto loading working.

 * the driver currently doesn't work with your IORESOURCE_BUSY fix to
sysfb (as might be expected(?)):
simple-framebuffer simple-framebuffer.0: cannot reserve VMEM
simple-framebuffer: probe of simple-framebuffer.0 failed with error -5

* except for that, fbcon on top of the fbdev fallback support works
fine for me. I didn't yet try the drm driver itself, what clients (if
any) are supposed to work with this, kmscon, weston?

Cheers,

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

Re: [PATCH 3/9] drm: Make sure every ioctl structure has a typedef

2013-09-08 Thread Daniel Vetter 
On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote:
 Just for consistency.
 
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com

Afaik kernel coding style is to echew typdefs for normal structures as
much as possible. The only exception is for truly opaque types used in
abstractions, like dma_addr_t or pid_t.

All the typedefs we still have here go back to the old days of a drm core
shared between *bsd and linux. Since that's long gone they imo should all
die, but certainly we shouldn't add new ones.

Aside: My patcha apply script will also bitch about new usages of
drm_i915_private_t ;-)

Cheers, Daniel
 ---
  include/uapi/drm/drm.h | 29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
 index b8604d2..0430fab 100644
 --- a/include/uapi/drm/drm.h
 +++ b/include/uapi/drm/drm.h
 @@ -799,6 +799,11 @@ typedef struct drm_client drm_client_t;
  typedef enum drm_stat_type drm_stat_type_t;
  typedef struct drm_stats drm_stats_t;
  typedef struct drm_set_version drm_set_version_t;
 +typedef struct drm_modeset_ctl drm_modeset_ctl_t;
 +typedef struct drm_gem_close drm_gem_close_t;
 +typedef struct drm_gem_flink drm_gem_flink_t;
 +typedef struct drm_gem_open drm_gem_open_t;
 +typedef struct drm_get_cap drm_get_cap_t;
  typedef struct drm_block drm_block_t;
  typedef struct drm_control drm_control_t;
  typedef struct drm_buf_desc drm_buf_desc_t;
 @@ -815,6 +820,7 @@ typedef struct drm_ctx_res drm_ctx_res_t;
  typedef struct drm_draw drm_draw_t;
  typedef enum drm_lock_flags drm_lock_flags_t;
  typedef struct drm_lock drm_lock_t;
 +typedef struct drm_prime_handle drm_prime_handle_t;
  typedef struct drm_agp_mode drm_agp_mode_t;
  typedef struct drm_agp_info drm_agp_info_t;
  typedef struct drm_agp_buffer drm_agp_buffer_t;
 @@ -823,6 +829,29 @@ typedef struct drm_scatter_gather drm_scatter_gather_t;
  typedef enum drm_vblank_seq_type drm_vblank_seq_type_t;
  typedef union drm_wait_vblank drm_wait_vblank_t;
  typedef struct drm_update_draw drm_update_draw_t;
 +typedef struct drm_mode_card_res drm_mode_card_res_t;
 +typedef struct drm_mode_crtc drm_mode_crtc_t;
 +typedef struct drm_mode_cursor drm_mode_cursor_t;
 +typedef struct drm_mode_crtc_lut drm_mode_crtc_lut_t;
 +typedef struct drm_mode_get_encoder drm_mode_get_encoder_t;
 +typedef struct drm_mode_get_connector drm_mode_get_connector_t;
 +typedef struct drm_mode_mode_cmd drm_mode_mode_cmd_t;
 +typedef struct drm_mode_get_property drm_mode_get_property_t;
 +typedef struct drm_mode_connector_set_property 
 drm_mode_connector_set_property_t;
 +typedef struct drm_mode_get_blob drm_mode_get_blob_t;
 +typedef struct drm_mode_fb_cmd drm_mode_fb_cmd_t;
 +typedef struct drm_mode_crtc_page_flip drm_mode_crtc_page_flip_t;
 +typedef struct drm_mode_fb_dirty_cmd drm_mode_fb_dirty_cmd_t;
 +typedef struct drm_mode_create_dumb drm_mode_create_dumb_t;
 +typedef struct drm_mode_map_dumb drm_mode_map_dumb_t;
 +typedef struct drm_mode_destroy_dumb drm_mode_destroy_dumb_t;
 +typedef struct drm_mode_get_plane_res drm_mode_get_plane_res_t;
 +typedef struct drm_mode_get_plane drm_mode_get_plane_t;
 +typedef struct drm_mode_set_plane drm_mode_set_plane_t;
 +typedef struct drm_mode_fb_cmd2 drm_mode_fb_cmd2_t;
 +typedef struct drm_mode_obj_get_properties drm_mode_obj_get_properties_t;
 +typedef struct drm_mode_obj_set_property drm_mode_obj_set_property_t;
 +typedef struct drm_mode_cursor2 drm_mode_cursor2_t;
  
  typedef struct drm_clip_rect drm_clip_rect_t;
  typedef struct drm_drawable_info drm_drawable_info_t;
 -- 
 1.8.3.1
 
 ___
 dri-devel mailing list
 dri-devel@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stereo 3D v3

2013-09-08 Thread Daniel Vetter 
On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote:
 Follow up of:
  http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html

 Let's try again! This time, intead of a magic connector property to select if
 we want to return more modeinfo flags to userspace, this series introduces a
 new SET_CAP ioctl.

 So the flow goes as following:
   1/ the DRM client (limited to the DRM master) can notify it knows about 
 those
  flags through SET_CAP

 Is this capability dropped along with a change in master then?

Yeah, I think it would make sense to store this flag in the master
structure. But David Herrmann has some big plans for the drm master
stuff, so would be good to have his opinion on this. David?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] drm/radeon kexec fixes

2013-09-08 Thread Markus Trippelsdorf 
Here are a couple of patches that get kexec working with radeon devices.
I've tested this on my RS780. 
Comments or flames are welcome.
Thanks.

Markus Trippelsdorf (3):
  kexec: get rid of late printk
  drm/radeon: Implement radeon_pci_shutdown
  drm/radeon: get rid of r100_restore_sanity hack

 drivers/gpu/drm/radeon/r100.c| 27 ---
 drivers/gpu/drm/radeon/r300.c|  2 --
 drivers/gpu/drm/radeon/r420.c|  2 --
 drivers/gpu/drm/radeon/r520.c|  2 --
 drivers/gpu/drm/radeon/radeon_asic.h |  1 -
 drivers/gpu/drm/radeon/radeon_drv.c  | 10 ++
 drivers/gpu/drm/radeon/rs400.c   |  2 --
 drivers/gpu/drm/radeon/rs600.c   |  2 --
 drivers/gpu/drm/radeon/rs690.c   |  2 --
 drivers/gpu/drm/radeon/rv515.c   |  2 --
 kernel/kexec.c   |  1 -
 11 files changed, 10 insertions(+), 43 deletions(-)

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

[PATCH 1/3] kexec: get rid of late printk

2013-09-08 Thread Markus Trippelsdorf 
kexec calls:
 printk(KERN_EMERG Starting new kernel\n);
late before calling machine_shutdown().
However at this point the underlying fb device may have already been
shutdown. This causes the kernel to hang.
Fix by simply getting rid of the printk call.

Signed-off-by: Markus Trippelsdorf mar...@trippelsdorf.de
---
 kernel/kexec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 59f7b55..f33fa9f 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1679,7 +1679,6 @@ int kernel_kexec(void)
 #endif
{
kernel_restart_prepare(NULL);
-   printk(KERN_EMERG Starting new kernel\n);
machine_shutdown();
}
 
-- 
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/radeon: Implement radeon_pci_shutdown

2013-09-08 Thread Markus Trippelsdorf 
Currently radeon devices are not properbly shutdown during kexec. This
cases a varity of issues, e.g. dpm initialization failures.
Fix this by implementing a radeon_pci_shutdown function, that unloads
the driver cleanly.

Signed-off-by: Markus Trippelsdorf mar...@trippelsdorf.de
---
 drivers/gpu/drm/radeon/radeon_drv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index cb4445f..d71edee 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -380,6 +380,15 @@ static const struct file_operations radeon_driver_kms_fops 
= {
 #endif
 };
 
+
+static void
+radeon_pci_shutdown(struct pci_dev *pdev)
+{
+   struct drm_device *dev = pci_get_drvdata(pdev);
+
+   radeon_driver_unload_kms(dev);
+}
+
 static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP |
@@ -453,6 +462,7 @@ static struct pci_driver radeon_kms_pci_driver = {
.remove = radeon_pci_remove,
.suspend = radeon_pci_suspend,
.resume = radeon_pci_resume,
+   .shutdown = radeon_pci_shutdown,
 };
 
 static int __init radeon_init(void)
-- 
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/radeon: get rid of r100_restore_sanity hack

2013-09-08 Thread Markus Trippelsdorf 
Now that radeon devices are properly shutdown during kexec, we can get
rid of r100_restore_sanity.

Signed-off-by: Markus Trippelsdorf mar...@trippelsdorf.de
---
 drivers/gpu/drm/radeon/r100.c| 27 ---
 drivers/gpu/drm/radeon/r300.c|  2 --
 drivers/gpu/drm/radeon/r420.c|  2 --
 drivers/gpu/drm/radeon/r520.c|  2 --
 drivers/gpu/drm/radeon/radeon_asic.h |  1 -
 drivers/gpu/drm/radeon/rs400.c   |  2 --
 drivers/gpu/drm/radeon/rs600.c   |  2 --
 drivers/gpu/drm/radeon/rs690.c   |  2 --
 drivers/gpu/drm/radeon/rv515.c   |  2 --
 9 files changed, 42 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9fc61dd..d53dcd8 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3938,31 +3938,6 @@ void r100_fini(struct radeon_device *rdev)
rdev-bios = NULL;
 }
 
-/*
- * Due to how kexec works, it can leave the hw fully initialised when it
- * boots the new kernel. However doing our init sequence with the CP and
- * WB stuff setup causes GPU hangs on the RN50 at least. So at startup
- * do some quick sanity checks and restore sane values to avoid this
- * problem.
- */
-void r100_restore_sanity(struct radeon_device *rdev)
-{
-   u32 tmp;
-
-   tmp = RREG32(RADEON_CP_CSQ_CNTL);
-   if (tmp) {
-   WREG32(RADEON_CP_CSQ_CNTL, 0);
-   }
-   tmp = RREG32(RADEON_CP_RB_CNTL);
-   if (tmp) {
-   WREG32(RADEON_CP_RB_CNTL, 0);
-   }
-   tmp = RREG32(RADEON_SCRATCH_UMSK);
-   if (tmp) {
-   WREG32(RADEON_SCRATCH_UMSK, 0);
-   }
-}
-
 int r100_init(struct radeon_device *rdev)
 {
int r;
@@ -3975,8 +3950,6 @@ int r100_init(struct radeon_device *rdev)
radeon_scratch_init(rdev);
/* Initialize surface registers */
radeon_surface_init(rdev);
-   /* sanity check some register to avoid hangs like after kexec */
-   r100_restore_sanity(rdev);
/* TODO: disable VGA need to use VGA request */
/* BIOS*/
if (!radeon_get_bios(rdev)) {
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index d8dd269..57ba534 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1480,8 +1480,6 @@ int r300_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
-   /* restore some register to sane defaults */
-   r100_restore_sanity(rdev);
/* BIOS*/
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 4e796ec..9ee3360 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -371,8 +371,6 @@ int r420_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
-   /* restore some register to sane defaults */
-   r100_restore_sanity(rdev);
/* BIOS*/
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index e1aece7..4709c10 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -256,8 +256,6 @@ int r520_init(struct radeon_device *rdev)
radeon_scratch_init(rdev);
/* Initialize surface registers */
radeon_surface_init(rdev);
-   /* restore some register to sane defaults */
-   r100_restore_sanity(rdev);
/* TODO: disable VGA need to use VGA request */
/* BIOS*/
if (!radeon_get_bios(rdev)) {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 818bbe6..6eee9e2 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -122,7 +122,6 @@ void r100_mc_resume(struct radeon_device *rdev, struct 
r100_mc_save *save);
 void r100_vram_init_sizes(struct radeon_device *rdev);
 int r100_cp_reset(struct radeon_device *rdev);
 void r100_vga_render_disable(struct radeon_device *rdev);
-void r100_restore_sanity(struct radeon_device *rdev);
 int r100_cs_track_check_pkt3_indx_buffer(struct radeon_cs_parser *p,
 struct radeon_cs_packet *pkt,
 struct radeon_bo *robj);
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index b8074a8..23bbf89 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -510,8 +510,6 @@ int rs400_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
-   /* restore some register to sane defaults */
-   r100_restore_sanity(rdev);
/* BIOS*/

[Bug 67800] Computer freezes several hours (trinity)

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67800

Kertesz Laszlo laszlo.kert...@gmail.com changed:

   What|Removed |Added

Summary|Computer freezes after idle |Computer freezes several
   |for several hours (trinity) |hours (trinity)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/6] SimpleDRM Driver

2013-09-08 Thread David Herrmann 
Hi

On Sun, Sep 8, 2013 at 1:33 PM, Tom Gundersen t...@jklm.no wrote:
 Hi David,

 On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 With the upcoming 3.12 merge-window, I thought people might find themselves 
 with
 nothing to do, so here's a new SimpleDRM series. Comments welcome!

 This depends on the tip/x86/fb series in the x86-tip tree:
   http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/fb
 Which, as far as I understood, will be pushed into 3.12 by the x86 people.

 FYI, this is now merged in Linus' tree. See:
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=228abe73ad67665d71eacd6a8a347dd76b0115ae

 So hopefully we can get SimpleDRM ready for 3.13.

 Now that simplefb works for me, I finally got around to testing this.
 Just a couple of comments:

  * I guess you need to add the modalias platform:simple-framebuffer
 in addition to the of:... one to get module auto loading working.

Yes, sounds good.

  * the driver currently doesn't work with your IORESOURCE_BUSY fix to
 sysfb (as might be expected(?)):
 simple-framebuffer simple-framebuffer.0: cannot reserve VMEM
 simple-framebuffer: probe of simple-framebuffer.0 failed with error -5

Yes, if the simple-framebuffer region is already marked BUSY,
simpleDRM must not (and doesn't have to) call __request_region() (or
request_mem_region()). I have to remove that call if the BUSY fix gets
applied.

 * except for that, fbcon on top of the fbdev fallback support works
 fine for me. I didn't yet try the drm driver itself, what clients (if
 any) are supposed to work with this, kmscon, weston?

Obviously, simpledrm doesn't support double-buffering, page-flipping
or other advanced techniques. So I currently doubt you can use any
real application on it as they all at least require 2 buffers. I
haven't decided whether to emulate these in the kernel driver or to
rely on user-space to deal with this reduced driver. It's quite likely
I will go with both. That means, a compatibility option that makes
simpledrm emulate any required techniques (multiple FBs,
page-flipping) but also user-space patches to maybe some day be able
to disable the kernel emulation.

Thanks a lot for testing all this. I will try to get the fixes into
rc2. The speed-improvements might have to wait for 3.13, though.

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

Re: [PATCH 1/9] drm: Move the GET_CAP macros next to the corresponding ioctl structure

2013-09-08 Thread David Herrmann 
Hi

On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau damien.lesp...@intel.com wrote:
 It's a tiny bit more logical to find the different capabilities you can
 use with the GET_CAP ioctl next to the structure rather than putting
 them at the end of the file.

 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  include/uapi/drm/drm.h | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

 diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
 index 272580c..4b683f9 100644
 --- a/include/uapi/drm/drm.h
 +++ b/include/uapi/drm/drm.h
 @@ -611,6 +611,16 @@ struct drm_gem_open {
 __u64 size;
  };

 +#define DRM_CAP_DUMB_BUFFER 0x1
 +#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
 +#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
 +#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
 +#define DRM_CAP_PRIME 0x5
 +#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
 +
 +#define DRM_PRIME_CAP_IMPORT 0x1
 +#define DRM_PRIME_CAP_EXPORT 0x2
 +

Makes sense. Would you mind also adding tabs between the name and
literal? Makes it much more readable. And I think it's fine to use
moves to fix coding-style issues.

Thanks
David

  /** DRM_IOCTL_GET_CAP ioctl argument type */
  struct drm_get_cap {
 __u64 capability;
 @@ -774,16 +784,6 @@ struct drm_event_vblank {
 __u32 reserved;
  };

 -#define DRM_CAP_DUMB_BUFFER 0x1
 -#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
 -#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
 -#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
 -#define DRM_CAP_PRIME 0x5
 -#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
 -
 -#define DRM_PRIME_CAP_IMPORT 0x1
 -#define DRM_PRIME_CAP_EXPORT 0x2
 -
  /* typedef area */
  #ifndef __KERNEL__
  typedef struct drm_clip_rect drm_clip_rect_t;
 --
 1.8.3.1

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

Re: Stereo 3D v3

2013-09-08 Thread David Herrmann 
Hi

On Sun, Sep 8, 2013 at 1:59 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote:
 Follow up of:
  http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html

 Let's try again! This time, intead of a magic connector property to select 
 if
 we want to return more modeinfo flags to userspace, this series introduces a
 new SET_CAP ioctl.

 So the flow goes as following:
   1/ the DRM client (limited to the DRM master) can notify it knows about 
 those
  flags through SET_CAP

 Is this capability dropped along with a change in master then?

 Yeah, I think it would make sense to store this flag in the master
 structure. But David Herrmann has some big plans for the drm master
 stuff, so would be good to have his opinion on this. David?

The series implements SET_CAP as a per _file_ capability set, not per
master. I like it this way. Note that with SET_VERSION, we already
have a per _master_ capability set. Compared to SET_CAP it only allows
incremental capability changes, but that's fine I think.

However, the problem with per-master capabilities (SET_VERSION) is
that we currently have no way to control which master a
graphics-server gets assigned to. If it's started in background, it
will get the same master as the foreground compositor. Therefore, we
don't want per-master client-capabilities. It's wrong and breaks
existing setups (same as SET_VERSION, and everyone knows that). I also
don't see a reason to bind capabilities to a master object.

SET_CAP describes what the *calling client* understands and can work
with. And this is logically bound to drm_file (as it represents a
client). On the other hand, GET_CAP describes what the *device*
understands and provides. This is obviously bound to a drm_device. A
drm_master object allows to split GET_CAP capabilities and resources
across multiple logical master objects. But these resemble a
drm_device much more than a drm_file.

So no, this capability is not dropped with a change in master. It's
independent of the active/bound master. It just describes what a
client sees or not sees.

Regarding my drm_master plans: I don't plan on changing the concept, I
just plan on adding ioctls to control master objects and allow
*multiple* active masters per device, but each with different
resources.
Just as a hint: with the current setup, we only have one master.
Seriously, add debug-prints to drm_master_create() and watch. The
problem is, chances are pretty low that a compositors starts while no
master is active. At least on my system.. here all compositors share a
master-object.

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

Re: [PATCH 6/9] drm: Add a DRM_CAP_STEREO_3D capability for SET_CAP ioctl

2013-09-08 Thread David Herrmann 
Hi

On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau damien.lesp...@intel.com wrote:
 This capability allows user space to control the delivery of modes with
 the 3D flags set. This is to not play games with current user space
 users not knowing anything about stereo 3D flags and that could try
 to set a mode with one or several of those bits set.

 So, the plan is to remove the stereo 3D flags from the user mode
 modeinfo structure by default, and let them through if we are being told
 otherwise.

 stereo_allowed is bound to the drm_file structure to make it a
 per-client setting, not a global one.

 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/drm_crtc.c  | 16 +---
  drivers/gpu/drm/drm_ioctl.c | 14 +-
  include/drm/drmP.h  |  3 +++
  include/uapi/drm/drm.h  |  9 +
  4 files changed, 38 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index a691764..ff9646f 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1257,12 +1257,14 @@ EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
   * drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
   * @out: drm_mode_modeinfo struct to return to the user
   * @in: drm_display_mode to use
 + * @file_priv: drm file from the ioctl call
   *
   * Convert a drm_display_mode into a drm_mode_modeinfo structure to return to
   * the user.
   */
  static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out,
 - const struct drm_display_mode *in)
 + const struct drm_display_mode *in,
 + const struct drm_file *file_priv)
  {
 WARN(in-hdisplay  USHRT_MAX || in-hsync_start  USHRT_MAX ||
  in-hsync_end  USHRT_MAX || in-htotal  USHRT_MAX ||
 @@ -1287,6 +1289,13 @@ static void drm_crtc_convert_to_umode(struct 
 drm_mode_modeinfo *out,
 out-type = in-type;
 strncpy(out-name, in-name, DRM_DISPLAY_MODE_LEN);
 out-name[DRM_DISPLAY_MODE_LEN-1] = 0;
 +
 +   /*
 +* If user-space hasn't configured the driver to expose the stereo 3D
 +* flags, clear them.
 +*/
 +   if (!file_priv-stereo_allowed)
 +   out-flags = ~DRM_MODE_FLAG_3D_MASK;

So just to be clear: Whenever a mode is present with 3D flags, it is
also a valid non-3D mode? Is this guaranteed? Don't you want to add a
mode twice, once without 3D flags and once with? You could then just
skip all 3D modes for clients that don't support it.

I have no idea how the 3D flags are specified, just want to go sure
this doesn't break. So whenever a mode with 3D flags is present on a
device, it can be set by a client dropping the 3D flags and it will be
a valid mono-mode?

Cheers
David

  }

  /**
 @@ -1556,7 +1565,8 @@ int drm_mode_getcrtc(struct drm_device *dev,

 if (crtc-enabled) {

 -   drm_crtc_convert_to_umode(crtc_resp-mode, crtc-mode);
 +   drm_crtc_convert_to_umode(crtc_resp-mode, crtc-mode,
 + file_priv);
 crtc_resp-mode_valid = 1;

 } else {
 @@ -1655,7 +1665,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
 *data,
 copied = 0;
 mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
 long)out_resp-modes_ptr;
 list_for_each_entry(mode, connector-modes, head) {
 -   drm_crtc_convert_to_umode(u_mode, mode);
 +   drm_crtc_convert_to_umode(u_mode, mode, file_priv);
 if (copy_to_user(mode_ptr + copied,
  u_mode, sizeof(u_mode))) {
 ret = -EFAULT;
 diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
 index e471cd9..a716641 100644
 --- a/drivers/gpu/drm/drm_ioctl.c
 +++ b/drivers/gpu/drm/drm_ioctl.c
 @@ -304,7 +304,19 @@ int drm_getcap(struct drm_device *dev, void *data, 
 struct drm_file *file_priv)
   */
  int drm_setcap(struct drm_device *dev, void *data, struct drm_file 
 *file_priv)
  {
 -   return -EINVAL;
 +   struct drm_set_cap *req = data;
 +
 +   switch (req-capability) {
 +   case DRM_CAP_STEREO_3D:
 +   if (req-value  1)
 +   return -EINVAL;
 +   file_priv-stereo_allowed = req-value;
 +   break;
 +   default:
 +   return -EINVAL;
 +   }
 +
 +   return 0;
  }

  /**
 diff --git a/include/drm/drmP.h b/include/drm/drmP.h
 index b9c321b..0df654c 100644
 --- a/include/drm/drmP.h
 +++ b/include/drm/drmP.h
 @@ -431,6 +431,9 @@ struct drm_file {
 struct drm_master *master; /* master this node is currently 
 associated with
   N.B. not always minor-master */

 +   /* true when the client has asked us to expose stereo 3D

Re: [PATCH 6/9] drm: Add a DRM_CAP_STEREO_3D capability for SET_CAP ioctl

2013-09-08 Thread Damien Lespiau 
On Sun, Sep 08, 2013 at 03:50:29PM +0200, David Herrmann wrote:
 Hi
 
 On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau damien.lesp...@intel.com 
 wrote:
  This capability allows user space to control the delivery of modes with
  the 3D flags set. This is to not play games with current user space
  users not knowing anything about stereo 3D flags and that could try
  to set a mode with one or several of those bits set.
 
  So, the plan is to remove the stereo 3D flags from the user mode
  modeinfo structure by default, and let them through if we are being told
  otherwise.
 
  stereo_allowed is bound to the drm_file structure to make it a
  per-client setting, not a global one.
 
  Signed-off-by: Damien Lespiau damien.lesp...@intel.com
  ---
   drivers/gpu/drm/drm_crtc.c  | 16 +---
   drivers/gpu/drm/drm_ioctl.c | 14 +-
   include/drm/drmP.h  |  3 +++
   include/uapi/drm/drm.h  |  9 +
   4 files changed, 38 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
  index a691764..ff9646f 100644
  --- a/drivers/gpu/drm/drm_crtc.c
  +++ b/drivers/gpu/drm/drm_crtc.c
  @@ -1257,12 +1257,14 @@ EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
* drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
* @out: drm_mode_modeinfo struct to return to the user
* @in: drm_display_mode to use
  + * @file_priv: drm file from the ioctl call
*
* Convert a drm_display_mode into a drm_mode_modeinfo structure to return 
  to
* the user.
*/
   static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out,
  - const struct drm_display_mode *in)
  + const struct drm_display_mode *in,
  + const struct drm_file *file_priv)
   {
  WARN(in-hdisplay  USHRT_MAX || in-hsync_start  USHRT_MAX ||
   in-hsync_end  USHRT_MAX || in-htotal  USHRT_MAX ||
  @@ -1287,6 +1289,13 @@ static void drm_crtc_convert_to_umode(struct 
  drm_mode_modeinfo *out,
  out-type = in-type;
  strncpy(out-name, in-name, DRM_DISPLAY_MODE_LEN);
  out-name[DRM_DISPLAY_MODE_LEN-1] = 0;
  +
  +   /*
  +* If user-space hasn't configured the driver to expose the stereo 
  3D
  +* flags, clear them.
  +*/
  +   if (!file_priv-stereo_allowed)
  +   out-flags = ~DRM_MODE_FLAG_3D_MASK;
 
 So just to be clear: Whenever a mode is present with 3D flags, it is
 also a valid non-3D mode? Is this guaranteed? Don't you want to add a
 mode twice, once without 3D flags and once with? You could then just
 skip all 3D modes for clients that don't support it.
 
 I have no idea how the 3D flags are specified, just want to go sure
 this doesn't break. So whenever a mode with 3D flags is present on a
 device, it can be set by a client dropping the 3D flags and it will be
 a valid mono-mode?

So yes, that's exactly what happens right now. I was actually thinking
about a v4 of the series with what you said in the first paragraph: just
add the 3D modes to the list, one mode per 3D layout, and drop those
modes from the list given back to userspace when the stereo_allowed
isn't set. That seems quite a bit better than the convoluted approach
here.

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

Re: Stereo 3D v3

2013-09-08 Thread Damien Lespiau 
On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote:
 The series implements SET_CAP as a per _file_ capability set, not per
 master. I like it this way. Note that with SET_VERSION, we already
 have a per _master_ capability set. Compared to SET_CAP it only allows
 incremental capability changes, but that's fine I think.
 
 However, the problem with per-master capabilities (SET_VERSION) is
 that we currently have no way to control which master a
 graphics-server gets assigned to. If it's started in background, it
 will get the same master as the foreground compositor. Therefore, we
 don't want per-master client-capabilities. It's wrong and breaks
 existing setups (same as SET_VERSION, and everyone knows that). I also
 don't see a reason to bind capabilities to a master object.
 
 SET_CAP describes what the *calling client* understands and can work
 with. And this is logically bound to drm_file (as it represents a
 client). On the other hand, GET_CAP describes what the *device*
 understands and provides. This is obviously bound to a drm_device. A
 drm_master object allows to split GET_CAP capabilities and resources
 across multiple logical master objects. But these resemble a
 drm_device much more than a drm_file.
 
 So no, this capability is not dropped with a change in master. It's
 independent of the active/bound master. It just describes what a
 client sees or not sees.

Right, that sums it up. Note that while I've made stereo_allowed a per
fd thing (which is what I wanted in that case, alter the reality viewed
by the process opening the file), SET_CAP itself it marked as master
only. This can be changed in the future to provide per-cap access
restrictions if needed.

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

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60791

--- Comment #17 from Brian Hall hal...@gmail.com ---
Fixed it!

The problem was in atom.c, my bisect was correct. Starting with the bad 3.10.5
atom.c, I copied it into the good 3.10.4 tree, commented out the reset data
block part, rebuilt, and that fixed it. Commenting out the reset divmul part,
without removing the reset data block part, did not fix the corruption.

So I generated a patch, and applied that to a 3.11 tree. Fixed the corruption
on 3.11. This is the first time I've booted anything higher than 3.10.4 without
this problem. Now I'm running 3.11+fix_radeon_dvi_corruption.patch on DVI and
there's no corruption during boot or on my desktop.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60791

--- Comment #18 from Brian Hall hal...@gmail.com ---
Created attachment 107621
  -- https://bugzilla.kernel.org/attachment.cgi?id=107621action=edit
fixes radeon DVI display corruption

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61011] New: Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

Bug ID: 61011
   Summary: Radeon Screen Corruption since merged patch of Bug
60639
   Product: Drivers
   Version: 2.5
Kernel Version: 3.10.5
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: hams...@freenet.de
Regression: No

Created attachment 107641
  -- https://bugzilla.kernel.org/attachment.cgi?id=107641action=edit
This is the result

I own a board: 880GMH/U3S3 with radeon chipset HD 4250.
Since I upgraded to kernel 3.10.5 I get some screen corruption (shown in
attached picture). Then I used git bisect to track down the commit between the
last working kernel 3.10.2 and 3.10.5. The commit in question is
6f8bbaf568c7f2c497558bfd04654c0b9841ad57 which points to
https://bugzilla.kernel.org/show_bug.cgi?id=60639.

Without this commit I was able to build and run the 3.11.0 kernel release.
This is also the version, which attached log files refers to.

As reference: I created an thread
https://bbs.archlinux.org/viewtopic.php?id=169361 where I first described my
problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

--- Comment #1 from hams...@freenet.de ---
Created attachment 107651
  -- https://bugzilla.kernel.org/attachment.cgi?id=107651action=edit
dmesg output from working kernel

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

--- Comment #2 from hams...@freenet.de ---
Created attachment 107661
  -- https://bugzilla.kernel.org/attachment.cgi?id=107661action=edit
Xorg0.log output from working kernel

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

--- Comment #3 from hams...@freenet.de ---
Created attachment 107671
  -- https://bugzilla.kernel.org/attachment.cgi?id=107671action=edit
dmesg output from non working kernel

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

--- Comment #4 from hams...@freenet.de ---
Created attachment 107681
  -- https://bugzilla.kernel.org/attachment.cgi?id=107681action=edit
Xorg0.log output from non working kernel

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

hams...@freenet.de changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=60639

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/9] drm: Make sure every ioctl structure has a typedef

2013-09-08 Thread Damien Lespiau 
On Sun, Sep 08, 2013 at 01:58:29PM +0200, Daniel Vetter wrote:
 On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote:
  Just for consistency.
  
  Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 
 Afaik kernel coding style is to echew typdefs for normal structures as
 much as possible. The only exception is for truly opaque types used in
 abstractions, like dma_addr_t or pid_t.
 
 All the typedefs we still have here go back to the old days of a drm core
 shared between *bsd and linux. Since that's long gone they imo should all
 die, but certainly we shouldn't add new ones.

I figured that since we where talking about user space API, the kernel
rules wouldn't apply there and we could have some consistency, but I
certainly can just drop those patches.

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

Re: [PATCH 3/9] drm: Make sure every ioctl structure has a typedef

2013-09-08 Thread Daniel Vetter 
On Sun, Sep 8, 2013 at 9:36 PM, Damien Lespiau damien.lesp...@intel.com wrote:
 On Sun, Sep 08, 2013 at 01:58:29PM +0200, Daniel Vetter wrote:
 On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote:
  Just for consistency.
 
  Signed-off-by: Damien Lespiau damien.lesp...@intel.com

 Afaik kernel coding style is to echew typdefs for normal structures as
 much as possible. The only exception is for truly opaque types used in
 abstractions, like dma_addr_t or pid_t.

 All the typedefs we still have here go back to the old days of a drm core
 shared between *bsd and linux. Since that's long gone they imo should all
 die, but certainly we shouldn't add new ones.

 I figured that since we where talking about user space API, the kernel
 rules wouldn't apply there and we could have some consistency, but I
 certainly can just drop those patches.

I've thought typedefs are even frowned upon in the ioctl abi -
magically changing sized types cause pain since they need 32bit compat
wrappers. And otherwise I haven't really seen them much for structures
...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stereo 3D v3

2013-09-08 Thread Daniel Vetter 
On Sun, Sep 8, 2013 at 5:03 PM, Damien Lespiau damien.lesp...@intel.com wrote:
 On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote:
 The series implements SET_CAP as a per _file_ capability set, not per
 master. I like it this way. Note that with SET_VERSION, we already
 have a per _master_ capability set. Compared to SET_CAP it only allows
 incremental capability changes, but that's fine I think.

 However, the problem with per-master capabilities (SET_VERSION) is
 that we currently have no way to control which master a
 graphics-server gets assigned to. If it's started in background, it
 will get the same master as the foreground compositor. Therefore, we
 don't want per-master client-capabilities. It's wrong and breaks
 existing setups (same as SET_VERSION, and everyone knows that). I also
 don't see a reason to bind capabilities to a master object.

 SET_CAP describes what the *calling client* understands and can work
 with. And this is logically bound to drm_file (as it represents a
 client). On the other hand, GET_CAP describes what the *device*
 understands and provides. This is obviously bound to a drm_device. A
 drm_master object allows to split GET_CAP capabilities and resources
 across multiple logical master objects. But these resemble a
 drm_device much more than a drm_file.

 So no, this capability is not dropped with a change in master. It's
 independent of the active/bound master. It just describes what a
 client sees or not sees.

 Right, that sums it up. Note that while I've made stereo_allowed a per
 fd thing (which is what I wanted in that case, alter the reality viewed
 by the process opening the file), SET_CAP itself it marked as master
 only. This can be changed in the future to provide per-cap access
 restrictions if needed.

Ok, I admit defaut, master doesn't make sense here ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68451

--- Comment #16 from Peter Kraus peter.kr...@geeksonbikes.net ---
Hi there,

any update on this one? Can I / do I need to test anything? It's a bit of a
bummer...

Or is this a bug in Dota?

The behaviour is there also with linux-3.11.

Peter

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] kexec: get rid of late printk

2013-09-08 Thread Bruno Prémont 
On Sun, 08 September 2013 Daniel Vetter dan...@ffwll.ch wrote:
 On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  kexec calls:
   printk(KERN_EMERG Starting new kernel\n);
  late before calling machine_shutdown().
  However at this point the underlying fb device may have already been
  shutdown. This causes the kernel to hang.
  Fix by simply getting rid of the printk call.
 
  Signed-off-by: Markus Trippelsdorf mar...@trippelsdorf.de
 
 Shouldn't this be taken care of with the suspend/resume_console calls?
 At least that's my understanding how it works in the suspend/hibernate
 code, maybe kexec needs similar treatment ...

Is it suspend/resume_console? Shouldn't the fbcon be short-circuited
or disabled once there is no more underlying fb?
Serial console, if present, as well as netconsole if network device
is still alive should continue working I would say.

Bruno

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

[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

--- Comment #5 from Alex Deucher alexdeuc...@gmail.com ---
This is a duplicate of bug 60791.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60791

--- Comment #19 from Alex Deucher alexdeuc...@gmail.com ---
Please attach a copy of your vbios.

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/pci bus id
echo 1  rom
cat rom  /tmp/vbios.rom
echo 0  rom

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] New: With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

  Priority: medium
Bug ID: 69120
  Assignee: dri-devel@lists.freedesktop.org
   Summary: With dpm=1 vdpau is not usable
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: john.etted...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 9.2
 Component: Drivers/Gallium/r600
   Product: Mesa

Hello,

with radeon.dpm=0 (or not set), vdpau output works very fine.
But if I switch to radeon.dpm=1 it becomes unusable.
mplayer tells me that my computer is too slow, video stutters to a crazy
extent, same in xbmc.
With dpm set to 1, I am still able to watch videos normally if not using
vdpau.

I have a Radeon 4670, Linux 3.11, Mesa 9.2 and Radeon 1:7.2.0.

I tried to change power_dpm_state and power_dpm_force_performance_level to see
if it would help.
power_dpm_state stays at performance but even if I set
power_dpm_force_performance_level to high, but it always reverts to auto...
This doesn't help at all...

I am not sure what else to attach.
Thank you

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60791

--- Comment #20 from Brian Hall hal...@gmail.com ---
Created attachment 107711
  -- https://bugzilla.kernel.org/attachment.cgi?id=107711action=edit
copy of video bios

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

--- Comment #1 from Dieter Nützel die...@nuetzel-hh.de ---
Hello John,

I see nearly the same with all 3.11-rcX and final plus 3.12-next.
Only diffence with dpm=0 I get partially mosaic with bigger videos (1280x720
H.264 and 1920x1080 H.264) from time to time.

But my system is much slower than yours:

poor Duron 1800 ;-)
RV730 AGP (4650)
Mesa 9.2 and git master
3.11 and 3.12-next

power_dpm_force_performance_level didn't works for me, too.

 I am not sure what else to attach.

Maybe your dmesg.log, Xorg.0.log and your vbios.

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/pci bus id
echo 1  rom
cat rom  /tmp/vbios.rom
echo 0  rom

Mine comming, here.
(With dual DVI monitor configuration I got something in dmesg)
[drm:rv770_dpm_set_power_state] *ERROR*
rv770_restrict_performance_levels_before_switch failed

Regards,
   Dieter

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

--- Comment #2 from Dieter Nützel die...@nuetzel-hh.de ---
Created attachment 85467
  -- https://bugs.freedesktop.org/attachment.cgi?id=85467action=edit
dmesg-3.11-dmp-1-two-displays.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

--- Comment #3 from Dieter Nützel die...@nuetzel-hh.de ---
Created attachment 85468
  -- https://bugs.freedesktop.org/attachment.cgi?id=85468action=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

--- Comment #4 from Dieter Nützel die...@nuetzel-hh.de ---
Created attachment 85469
  -- https://bugs.freedesktop.org/attachment.cgi?id=85469action=edit
copy of video bios

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

--- Comment #5 from Dieter Nützel die...@nuetzel-hh.de ---
# radeontool regmatch 0x0718
0x0718  0x20010002 (536936450)

# radeontool regmatch 0x071c
0x071c  0x021f2111 (35594513)

# radeontool regmatch 0x0720
0x0720  0x102774da (271021274)

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730
Pro AGP [Radeon HD 4600 Series] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Device 0028
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16
Memory at c000 (32-bit, prefetchable) [size=256M]
I/O ports at a800 [size=256]
Memory at dfdf (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dfdc [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] AGP version 3.0
Kernel driver in use: radeon

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67800] Computer freezes after several hours (trinity)

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67800

Kertesz Laszlo laszlo.kert...@gmail.com changed:

   What|Removed |Added

Summary|Computer freezes several|Computer freezes after
   |hours (trinity) |several hours (trinity)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67800] Computer freezes after several hours (trinity)

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67800

--- Comment #13 from Kertesz Laszlo laszlo.kert...@gmail.com ---
The freezes are still happening, both with kernel 3.11 stable or the later git
versions, mesa 9.2 stable or with the 9.3 devel git.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64201

--- Comment #45 from Aaron Watry awa...@gmail.com ---
(In reply to comment #43)
 I patched llvm with
 
 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184089.
 html
 
 using
 
 patch -N -p1 -i p2.patch
 
 But still got lock-ups.
 Any hints? :/

I just did a fresh install of Ubuntu 3.04 64bit on an Athlon 64 with a radeonsi
6850.

I did a checkout of LLVM/clang master and applied only the following patch:
http://llvm-reviews.chandlerc.com/file/data/lzktdebskepaizauyiqg/PHID-FILE-ke45wuyidarlnthfbtcg/D1449.diff

Without that patch, libclc won't currently build for the radeonsi target.

Along with that I checked out git copies of Mesa, drm, and libclc.  I upgraded
the kernel to 3.11 from the Ubuntu mainline ppa, but I didn't enable dpm
(machine wouldn't boot with it enabled, and I was too busy to debug that).

With this done and all of the aforementioned packages compiled and installed to
/usr/local, I have been running 'bfgminer -v1 --benchmark' without a single
lockup for 20 minutes now on a radeonsi 6850 that used to exhibit the same lock
ups that we have been discussing, and which also seem to have been cured on the
5400 card I was esting on before.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64201

--- Comment #46 from Aaron Watry awa...@gmail.com ---
Autocorrect got the best of me...  s/radeonsi/radeon/g

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] nouveau: fix reclocking on nv40

2013-09-08 Thread Ben Skeggs 
On Sun, Sep 8, 2013 at 9:25 PM, Pali Rohár pali.ro...@gmail.com wrote:
 On Wednesday 21 August 2013 02:24:01 Ben Skeggs wrote:
 On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár
 pali.ro...@gmail.com wrote:
  On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
  In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
  introduced error which cause that reclocking on nv40 not
  working anymore. There is missing assigment of return value
  from pll_calc to ret.
 
  Signed-off-by: Pali Rohár pali.ro...@gmail.com
  Signed-off-by: Martin Peres martin.pe...@labri.fr
  ---
 
   drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
  b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
  100644
  --- a/drivers/gpu/drm/nouveau/nv40_pm.c
  +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
  @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev,
  u32 reg, struct nvbios_pll *pll, if (clk 
  pll-vco1.max_freq)
 
pll-vco2.max_freq = 0;
 
  - pclk-pll_calc(pclk, pll, clk, coef);
  + ret = pclk-pll_calc(pclk, pll, clk, coef);
 
if (ret == 0)
 
return -ERANGE;
 
  Hello, it is possible to include this patch in 3.11?
  Or it is too late now and need to wait for 3.12?

 I've picked up the patch and will submit it in my next
 3.11-fixes pull request.

 Thanks,
 Ben.


 Hello, now I see that patch is in 3.11, thanks! Ben, what do you
 think, can be this patch backported to older kernels?
Personally, I don't care at all.  The current PM code is a dead end,
and completely not supported (hence why it's hidden behind a magic
parameter).  If I had my way it'd have been completely ripped out
already.

If someone wants to backport and test it on earlier kernels though, by
all means, go ahead :)

Thanks,
Ben.


 --
 Pali Rohár
 pali.ro...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61011] Radeon Screen Corruption since merged patch of Bug 60639

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=61011

hams...@freenet.de changed:

   What|Removed |Added

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

--- Comment #6 from hams...@freenet.de ---


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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

2013-09-08 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60791

hams...@freenet.de changed:

   What|Removed |Added

 CC||hams...@freenet.de

--- Comment #21 from hams...@freenet.de ---
*** Bug 61011 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

--- Comment #6 from John john.etted...@gmail.com ---
Hello Dieter,

thanks for the suggestions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69120] With dpm=1 vdpau is not usable

2013-09-08 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69120

--- Comment #7 from John john.etted...@gmail.com ---
Created attachment 85476
  -- https://bugs.freedesktop.org/attachment.cgi?id=85476action=edit
John's vbios

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nv10/plane: add plane support for nv10-nv40

2013-09-08 Thread Ben Skeggs 
On Sun, Sep 8, 2013 at 10:33 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 ---

 This has received light testing on NV18 and NV34 cards, using the modetest
 tool. Userspace support to use this for xv is not yet ready.

 I decided against creating a new pvideo engine -- that just seems way too
 heavy-handed compared to the ~10 lines of code in disp/nv04.c to deal with the
 PVIDEO interrupts.

 Even though there are two possible planes, they are sufficiently linked
 together that I decided to just expose them as one, and do a
 double-buffering-style thing, similar to what xf86-video-nouveau did pre-KMS.
Merged: 
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=289d94b9e87eb09eb16a525e105d3a57a9f2e872

Thanks!
Ben.


  drivers/gpu/drm/nouveau/core/engine/disp/nv04.c |   9 +
  drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c   |   1 +
  drivers/gpu/drm/nouveau/dispnv04/Makefile   |   1 +
  drivers/gpu/drm/nouveau/dispnv04/disp.c |   2 +
  drivers/gpu/drm/nouveau/dispnv04/disp.h |   3 +
  drivers/gpu/drm/nouveau/dispnv04/hw.c   |  10 +-
  drivers/gpu/drm/nouveau/dispnv04/overlay.c  | 320 
 
  7 files changed, 342 insertions(+), 4 deletions(-)
  create mode 100644 drivers/gpu/drm/nouveau/dispnv04/overlay.c

 diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c 
 b/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
 index 05e903f..a0bc8a8 100644
 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
 +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
 @@ -59,6 +59,7 @@ nv04_disp_intr(struct nouveau_subdev *subdev)
 struct nv04_disp_priv *priv = (void *)subdev;
 u32 crtc0 = nv_rd32(priv, 0x600100);
 u32 crtc1 = nv_rd32(priv, 0x602100);
 +   u32 pvideo;

 if (crtc0  0x0001) {
 nouveau_event_trigger(priv-base.vblank, 0);
 @@ -69,6 +70,14 @@ nv04_disp_intr(struct nouveau_subdev *subdev)
 nouveau_event_trigger(priv-base.vblank, 1);
 nv_wr32(priv, 0x602100, 0x0001);
 }
 +
 +   if (nv_device(priv)-chipset = 0x10 
 +   nv_device(priv)-chipset = 0x40) {
 +   pvideo = nv_rd32(priv, 0x8100);
 +   if (pvideo  ~0x11)
 +   nv_info(priv, PVIDEO intr: %08x\n, pvideo);
 +   nv_wr32(priv, 0x8100, pvideo);
 +   }
  }

  static int
 diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c 
 b/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
 index 64aa4ed..062c048 100644
 --- a/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
 +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
 @@ -33,6 +33,7 @@ nv04_mc_intr[] = {
 { 0x0001, NVDEV_ENGINE_MPEG },  /* NV17- MPEG/ME */
 { 0x0100, NVDEV_ENGINE_FIFO },
 { 0x1000, NVDEV_ENGINE_GR },
 +   { 0x0001, NVDEV_ENGINE_DISP },
 { 0x0002, NVDEV_ENGINE_VP },/* NV40- */
 { 0x0010, NVDEV_SUBDEV_TIMER },
 { 0x0100, NVDEV_ENGINE_DISP },  /* NV04- PCRTC0 */
 diff --git a/drivers/gpu/drm/nouveau/dispnv04/Makefile 
 b/drivers/gpu/drm/nouveau/dispnv04/Makefile
 index ea3f5b8..424a489 100644
 --- a/drivers/gpu/drm/nouveau/dispnv04/Makefile
 +++ b/drivers/gpu/drm/nouveau/dispnv04/Makefile
 @@ -5,6 +5,7 @@ nouveau-y += dispnv04/dac.o
  nouveau-y += dispnv04/dfp.o
  nouveau-y += dispnv04/disp.o
  nouveau-y += dispnv04/hw.o
 +nouveau-y += dispnv04/overlay.o
  nouveau-y += dispnv04/tvmodesnv17.o
  nouveau-y += dispnv04/tvnv04.o
  nouveau-y += dispnv04/tvnv17.o
 diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
 b/drivers/gpu/drm/nouveau/dispnv04/disp.c
 index 4908d3f..b13ff0f 100644
 --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
 +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
 @@ -140,6 +140,8 @@ nv04_display_create(struct drm_device *dev)
 func-save(encoder);
 }

 +   nouveau_overlay_init(dev);
 +
 return 0;
  }

 diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h 
 b/drivers/gpu/drm/nouveau/dispnv04/disp.h
 index 9928187..bb5c1bd 100644
 --- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
 +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
 @@ -123,6 +123,9 @@ int nv04_tv_create(struct drm_connector *, struct 
 dcb_output *);
  /* nv17_tv.c */
  int nv17_tv_create(struct drm_connector *, struct dcb_output *);

 +/* overlay.c */
 +void nouveau_overlay_init(struct drm_device *dev);
 +
  static inline bool
  nv_two_heads(struct drm_device *dev)
  {
 diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c 
 b/drivers/gpu/drm/nouveau/dispnv04/hw.c
 index ffd2641..b1c5cd6 100644
 --- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
 +++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
 @@ -27,6 +27,7 @@
  #include hw.h

  #include subdev/bios/pll.h
 +#include subdev/fb.h
  #include subdev/clock.h
  #include subdev/timer.h

 @@ -664,6 +665,7 @@ nv_load_state_ext(struct drm_device *dev, int head,
 struct nouveau_drm *drm =

Re: [PATCH] drm/nv84-: write fence value on exit, and restore value on init.

2013-09-08 Thread Ben Skeggs 
On Wed, Sep 4, 2013 at 10:37 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 Op 04-09-13 05:21, Ben Skeggs schreef:
 On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 This increases the chance slightly that recovery from lockup can happen
 succesfully.
 I'd *really* love to see proof of this.  When channels die, all
 outstanding fences are marked as signalled.  This should do absolutely
 nothing...
 nv84+ heavily rely on fences though, and a race like this is possible:
 - channel 0 uses a bo from channel 1, queues a wait somewhere in the command 
 stream for it.
 - channel 1 dies cleanly, but userspace creates a new channel in its place, 
 fence counter is reset to 0.
 - channel 0 reaches the NV84_SUBCHAN_SEMAPHORE_TRIGGER.ACQUIRE_GEQUAL op, 
 waits on fence in channel 1 to signal forever.
Ok, this isn't exactly the issue you implied in the commit message.
But yes, this could possibly be an issue for sure.  I don't think this
is the right way to fix it however.  I'll have a bit of a think on the
problem and see what I can come up with.

Thanks,
Ben.


 Channel 0 could be the global drm channel used for buffer moves, which would 
 result in a hang. This may seem unlikely, but I believe that parallel piglit 
 runs could trigger it.

 If not, simply creating an operation that takes a few seconds in channel 0 
 and then queuing a command that uses a bo from channel 1 while chan1 is still 
 busy, then deleting/recreating chan1 could trigger it.

 ~Maarten

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