[PATCH v7 2/8] of: add helper to parse display timings

[Leela Krishna Amudala]

Hello Steffen,

On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
 wrote:
> Signed-off-by: Steffen Trumtrar 
> ---
>  .../devicetree/bindings/video/display-timings.txt  |  139 +++
>  drivers/of/Kconfig |6 +
>  drivers/of/Makefile|1 +
>  drivers/of/of_display_timings.c|  185 
> 
>  include/linux/of_display_timings.h |   20 +++
>  5 files changed, 351 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/display-timings.txt
>  create mode 100644 drivers/of/of_display_timings.c
>  create mode 100644 include/linux/of_display_timings.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 000..04c94a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,139 @@
> +display-timings bindings
> +==
> +
> +display-timings-node
> +
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - native-mode: the native mode for the display, in case multiple modes are
> +   provided. When omitted, assume the first node is the native.
> +
> +timings-subnode
> +---
> +
> +required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> +   in pixels
> +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
> in
> +   lines
> + - clock-frequency: displayclock in Hz
> +
> +optional properties:
> + - hsync-active : Hsync pulse is active low/high/ignored
> + - vsync-active : Vsync pulse is active low/high/ignored
> + - de-active : Data-Enable pulse is active low/high/ignored
> + - pixelclk-inverted : pixelclock is inverted/non-inverted/ignored
> + - interlaced (bool)
> + - doublescan (bool)
> +
> +All the optional properties that are not bool follow the following logic:
> +<1> : high active
> +<0> : low active
> +omitted : not used on hardware
> +
> +There are different ways of describing the capabilities of a display. The 
> devicetree
> +representation corresponds to the one commonly found in datasheets for 
> displays.
> +If a display supports multiple signal timings, the native-mode can be 
> specified.
> +
> +The parameters are defined as
> +
> +struct display_timing
> +===
> +
> +  
> +--+-+--+---+
> +  |  |?|  |  
>  |
> +  |  ||vback_porch |  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--###--+---+
> +  |  #?#  |  
>  |
> +  |  #|#  |  
>  |
> +  |  hback   #|#  hfront  | 
> hsync |
> +  |   porch  #|   hactive  #  porch   |  len 
>  |
> +  
> |<>#<---+--->#<>|<->|
> +  |  #|#  |  
>  |
> +  |  #|vactive #  |  
>  |
> +  |  #|#  |  
>  |
> +  |  #?#  |  
>  |
> +  
> +--###--+---+
> +  |  |?|  |  
>  |
> +  |  ||vfront_porch|  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--+-+--+---+
> +  |  |?|  |  
>  |
> +  |  ||vsync_len   |  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--+-+--+---+
> +
> +
> +Example:
> +
> +   display-timings {
> +   native-mode = <>;
> +   timing0: 1920p24 {
> +   /* 1920x1080p24 */
> +   clock = <5200>;
> +   hactive = <1920>;
> +   vactive = <1080>;
> +   hfront-porch = <25>;
> +   hback-porch = <25>;
> +   hsync-len = <25>;
> +   vback-porch = <2>;
> + 

[Bug 24857] Lightening and object selection in viewport is not working in Blender 3D

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

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

Laurent carlier  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
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/20121102/c7b6727e/attachment.html>

[Bug 24857] Lightening and object selection in viewport is not working in Blender 3D

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

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

--- Comment #7 from Hans Nieser  ---
With kernel 3.6.2 and xorg/mesa/libdrm from git the object selection problem is
no longer occuring on either my 4850 or 5850 radeons with r600g (has probably
been fixed long ago since I've used blender before on occasion without this
issue). Lighting is looking correct as well

-- 
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/20121102/e07a8748/attachment.html>

[Bug 27457] Blender artifacts when using box select

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

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

Laurent carlier  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
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/20121102/ffd5b51a/attachment.html>

[Bug 27457] Blender artifacts when using box select

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

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

--- Comment #3 from Willem Swart  ---
(In reply to comment #2)
> Note: classic r600 driver has been abandoned.
> Please use r600g (gallium driver) instead.
> 
> Is this still an issue with a newer driver/kernel?

Have not been able to reproduce the bug with current setup:

Radeon HD6950
Blender 2.64a-5
xf86-video-ati 1:6.14.6-2
ati-dri 9.0-1

-- 
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/20121102/ac16a5fe/attachment.html>

[REGRESSION] i915: failure to interoperate with HP ZR30w using an X230

[Theodore Ts'o]

Ping?

On Tue, Oct 30, 2012 at 04:32:21PM -0400, Theodore Ts'o wrote:
> On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
> > > [1] drm-intel-next-queued branch at 
> > > git://people.freedesktop.org/~danvet/drm-intel
> > 
> > Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
> 
> Confirmed, the drm-intel-fixes branch from Daniel's tree
> (3.7.0-rc2-00031-g1623392) works fine for me.
> 
> Do you know which commit(s) are likely to have fixed the problem, so we
> can cherry pick the appropriate fix(es) to the 3.6.x tree?
> 
> Thanks,
> 
>   - Ted

[Intel-gfx] [PATCH 0/3] drm/i915: eDP scaling mode change support

[Yuly Novikov]

Hi Jani,

Sorry for the delay, our branches have diverged significantly, and it took
me quite a while to merge your changes.
On the bright sight, I've tested the patch on SandyBridge LDVS and
IvyBridge eDP, and it works fine.

Regards,
Yuly.


On Fri, Oct 26, 2012 at 9:44 AM, Paulo Zanoni  wrote:

> Hi
>
> 2012/10/26 Jani Nikula :
> > [Dropped lkml, added intel-gfx]
> >
> > Hi Yuly, here's a slightly modified version of your patch, rebased on
> > drm-intel-next-queued. I kept your authorship, but any new errors are
> > totally mine...
> >
> > These are compile tested only; I'd appreciate if you could check it
> > still does what it says on the box!
>
> I have nothing to add or remove. Tested on HSW eDP, used "xrandr" to
> alternate the property values. Works fine.
>
> Being consistent on the default value between LVDS and eDP is
> certainly a nice thing.
>
> For the 3 patches:
> Reviewed-by: Paulo Zanoni 
> Tested-by: Paulo Zanoni 
>
> >
> > BR,
> > Jani.
> >
> >
> > Jani Nikula (1):
> >   drm/i915/lvds: move fitting mode from intel_lvds_connector to
> > intel_panel
> >
> > Yuly Novikov (2):
> >   drm/i915/dp: allow configuring eDP panel fitting scaling mode
> >   drm/i915/dp: change eDP default scaling mode to respect aspect ratio
> >
> >  drivers/gpu/drm/i915/intel_dp.c   |   31 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |1 +
> >  drivers/gpu/drm/i915/intel_lvds.c |   24 ++--
> >  3 files changed, 41 insertions(+), 15 deletions(-)
> >
> > --
> > 1.7.9.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121102/6ad3bbeb/attachment-0001.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #9 from Ilija Hadzic  ---
Just uploaded to https://bugs.freedesktop.org/show_bug.cgi?id=56680

Which should fix the Zaphod mode problem without breaking non-Zaphod mode.
Sorry about the goof.

-- 
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/20121102/e788937f/attachment.html>

[Bug 27443] radeonFreeTexImageData: Assertion `!image->base.Data' failed when running Ogre3D samples

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

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

Laurent carlier  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Laurent carlier  ---
Fixed with r600g / mesa from git / kernel 3.6.5

-> closing

-- 
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/20121102/d97a9b87/attachment.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #8 from dagg  ---
(In reply to comment #6)
> (In reply to comment #5)
> > I'm not sure, correct me if I'm wrong but Zaphod is for running seperate x
> > sessions on the same card?
> > I'm using a card per session.
> > 
> > anyway, I'll revert the patch and try, will report soon.
> 
> You are correct, but I'm wondering if that patch is causing a problem in
> your case.  You might try reverting that patch as well if the 2D tiling
> patch doesn't help.

issue confirmed, it was indeed that Zaphod patch.

-- 
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/20121102/adeeda01/attachment.html>

[Bug 28359] Regression running Second Life viewer on r600 (mipmap generation issue?)

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
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/20121102/54a00250/attachment.html>

[Bug 28359] Regression running Second Life viewer on r600 (mipmap generation issue?)

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

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

--- Comment #5 from Aidan Thornton  ---
Nope, doesn't affect r600g and I don't think it ever actually did (though I
wasn't using it at the time because it had - and still has - other unrelated
rendering issues that're harder to work around). Guess this probably wants
closing?

-- 
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/20121102/c20624ff/attachment.html>

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #16 from Alex Deucher  ---
(In reply to comment #15)
> You've focused on minor point about the inability of having open source
> 32-bit driver alongside 64-bit one. I don't know the cause of it, I only
> know that my distribution provides this kind of setup for closed source
> catalyst package:
> https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers

I'm not following.  You can have both 32-bit and 64-bit versions of the open
source driver installed.  If your distro doesn't allow it, it's broken.  If
other 32-bit and 64-bit libs also cannot both be installed, you may have bigger
problems.

> 
> To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri
> package mentioned in the link above - but I assume you mean xorg kind of
> drivers. If this is some sort of distro-related bug, please state it so I
> can nag other people about it ;-)

Is the 32-bit driver a recent version?  Often distros only provide out of date
32-bit drivers on 64-bit distros.

> 
> At the same time, I see my main point about display being fine in virtual
> desktop mode has been ignored? To reiterate: it doesn't seem to me that,
> since Wine is capable of rendering and display on the very same setup in
> different mode, there are some unfullfilled requirements that block said
> display. After all, as I described before, even in fullscreen mode there was
> some kind of output, albeit buggy to the point of being unusable. But
> without the crucial part of plumbing there would be no output at all.

The symptoms you are experiencing are commonly seen with an out of date 32-bit
3D driver.  If your 32-bit 3D driver is old, you may still be experiencing the
problem.  Also, there are several people on this bug report and the solution
may still be relevant for them even if it doesn't help in your case.

-- 
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/20121102/3ff25d5d/attachment.html>

[Bug 27132] piglit comparison between F12 7.7-4 and 7.9-git

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #8 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/62f644e1/attachment-0001.html>

[Bug 26933] r600 driver (rv730): piglit test failures

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #6 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/fc4eb9e3/attachment.html>

[Bug 26115] blit: lack of depth copies

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/9ea1d7f8/attachment.html>

[Bug 27025] Very slow start of The Sims 3

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/6b489712/attachment.html>

[Bug 34377] Radeon driver PCIe throughput not up to PCIe2.0 levels

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/f58ddcf4/attachment.html>

[Bug 27061] r600: software fallback for GL_DEPTH_COMPONENT*

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/8db09ceb/attachment.html>

[Bug 27434] [rv710] low 3d perfomance in general

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #9 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/2a8d990d/attachment.html>

[Bug 27173] r600 wierdness with shaders for blur effect in compiz

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/b9ccea44/attachment-0001.html>

[Bug 26769] r600: wrong fragment shader input when using gl_fragCoord.

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/3adbb04e/attachment.html>

[Bug 40936] register address overlap make line stipple error

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/c1c48fd6/attachment.html>

[Bug 32246] [RADEON:KMS:R600C] compiz 0.9 switcher segfaults in mipmap generation code

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #5 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/a6302eaf/attachment.html>

[Bug 28412] Thief 2 crashes in wine with the open source driver and not with fglrx

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/5ad1d45c/attachment.html>

[Bug 28359] Regression running Second Life viewer on r600 (mipmap generation issue?)

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/bda670d1/attachment.html>

[Bug 27723] Vtx endian setup error under big endain CPU

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/62cf17c0/attachment.html>

[Bug 26735] r600: rendering artifacts

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #12 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/7d214420/attachment-0001.html>

[Bug 29200] [wine] Warcraft 3 crashes after trying to launch again

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/fb19f979/attachment.html>

[Bug 29318] Marbleblast textures broken on r600

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/6b40cc35/attachment.html>

[Bug 29317] Neverwinter night cloak texture is broken on r600

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/1c2ccaea/attachment.html>

[Bug 24380] OpenGL fullscreen with KMS multihead

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/27e41b0b/attachment.html>

[Bug 26114] Black screen on The Sims 3 beginning

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #8 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/718f6168/attachment.html>

[Bug 26011] Rare font corruption in OpenArena

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #6 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/73e452ab/attachment.html>

[Bug 26525] Rendering bug due to ARB_texture_non_power_of_two

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #12 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/66b72f1a/attachment-0001.html>

[Bug 26997] r600: broken mipmap generation

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/b93a7ff7/attachment.html>

[Bug 27443] radeonFreeTexImageData: Assertion `!image->base.Data' failed when running Ogre3D samples

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #9 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/ba020169/attachment.html>

[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #6 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/9d2f5ef8/attachment.html>

[Bug 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/3ca3199d/attachment.html>

[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

-- 
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/20121102/a0da8bb7/attachment.html>

[Bug 27457] Blender artifacts when using box select

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/12b953ae/attachment.html>

[Bug 24860] Triple Buffer is very slow in Blender 3D

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/ce93dba2/attachment-0001.html>

[Bug 24857] Lightening and object selection in viewport is not working in Blender 3D

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #6 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/7f321d2a/attachment.html>

[Bug 23949] [RV620] r600 crash on resolution change & OpenGL start

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/d400f38f/attachment.html>

[Bug 36172] xf86-video-ati-git causes Gnome 3 crash (Radeon HD5770 - r800)

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #10 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

Gnome 3 runs fine for me on rv770 
(Kernel 3.6.4, xf86-video-ati git, libdrm git, mesa git)

-- 
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/20121102/d967e1bb/attachment.html>

[Bug 23436] RV620 locks up on starting/quiting 3D app

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #7 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?

-- 
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/20121102/4c0e62f9/attachment.html>

[Bug 25443] [nexuiz] Endless loading without kms

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andreas Boll  ---
Note: UMS is deprecated and newer cards are only supported by KMS

-- 
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/20121102/767bbc3b/attachment.html>

[Bug 32323] GL_EXT_texture_sRGB is broken

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.

Please use r600g (gallium driver) instead.
It should handle GL_EXT_texture_sRGB correctly.

-- 
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/20121102/8dd2a5d8/attachment.html>

[Bug 24542] r600 vertex processing broken in mesa 7.7

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Andreas Boll  ---
Note: classic r600 driver has been abandoned.

NV_vertex_program won't be implemented in r600g either.
Previosly the last bits of this extension got removed from mesa-core
(only swrast implemented it)
Please use the ARB_vertex_program extension instead.

-- 
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/20121102/6f73b55c/attachment-0001.html>

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #15 from mailbox.tec at gmail.com ---
(In reply to comment #14)
> You can install a 32 bit version of the open source 3D driver as well.  Just
> because the graphics in a game do not appear to be 3D, they generally still
> use a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since
> the apps are 32 bit.  Also there seem to be several possibly unrelated
> issues now piled onto this bug.

You've focused on minor point about the inability of having open source 32-bit
driver alongside 64-bit one. I don't know the cause of it, I only know that my
distribution provides this kind of setup for closed source catalyst package:
https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers

To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri
package mentioned in the link above - but I assume you mean xorg kind of
drivers. If this is some sort of distro-related bug, please state it so I can
nag other people about it ;-)

At the same time, I see my main point about display being fine in virtual
desktop mode has been ignored? To reiterate: it doesn't seem to me that, since
Wine is capable of rendering and display on the very same setup in different
mode, there are some unfullfilled requirements that block said display. After
all, as I described before, even in fullscreen mode there was some kind of
output, albeit buggy to the point of being unusable. But without the crucial
part of plumbing there would be no output at all.

-- 
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/20121102/e7317633/attachment.html>

[Bug 28223] Screen Blanks on launching racing game Vdrift

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

-- 
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/20121102/2f109fbf/attachment.html>

[Bug 34313] RV770 lock-up with OpenGL

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

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

--- Comment #26 from Bob Ham  ---
(In reply to comment #25)
> Is this still an issue with a newer driver/kernel?

I'll investigate.

-- 
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/20121102/a35e4465/attachment.html>

[Bug 34313] RV770 lock-up with OpenGL

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
Product|Mesa|DRI
Version|7.10|unspecified
  Component|Drivers/DRI/R600|DRM/Radeon

--- Comment #25 from Andreas Boll  ---
Is this still an issue with a newer driver/kernel?
Reassigning to drm/radeon.

-- 
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/20121102/0606e6c9/attachment.html>

[Bug 40931] r600g: interpret integer texture types as ints regresses VDPAU/XVMC decode.

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

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

Andreas Boll  changed:

   What|Removed |Added

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

--- Comment #9 from Andreas Boll  ---
Fixed with 86f97f7dc015092aa7fa1b0bdc4fe0a9f696d418

-- 
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/20121102/8eea9bf3/attachment.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #7 from Alex Deucher  ---


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

-- 
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/20121102/a4870767/attachment.html>

[Bug 25590] commit "drm: disable all the possible outputs/crtcs before entering KMS mode" introduces EDID errors

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/DRI/R600|DRM/Radeon

--- Comment #6 from Andreas Boll  ---
Is this still an issue with a newer kernel?
Reassigning to drm/radeon.

-- 
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/20121102/570ac1e7/attachment-0001.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #6 from Alex Deucher  ---
(In reply to comment #5)
> I'm not sure, correct me if I'm wrong but Zaphod is for running seperate x
> sessions on the same card?
> I'm using a card per session.
> 
> anyway, I'll revert the patch and try, will report soon.

You are correct, but I'm wondering if that patch is causing a problem in your
case.  You might try reverting that patch as well if the 2D tiling patch
doesn't 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/20121102/ddb9082e/attachment.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #5 from dagg  ---
(In reply to comment #4)
> Are you sure it's the 2D tiling commit?  Does just reverting that commit fix
> the issue?  I think it's probably another commit.  Does your tree have:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/
> ?id=39eac3104c2f08b4d78aab3f88fd104301eb4711
> Can you try again with git master?

Hello Alex,

I'm not sure, correct me if I'm wrong but Zaphod is for running seperate x
sessions on the same card?
I'm using a card per session.

anyway, I'll revert the patch and try, will report soon.

-- 
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/20121102/82947431/attachment.html>

[PATCH] drm: exynos: fix for mapping non contig dma buffers

[Inki Dae]

It's good patch. Right, there was my missing point. I thought each sgl would
always have 4k page. But dma mapping api, dma_alloc_alloc(), allocates
physical memory as continuously as possible so the sgl can have group of
pages.

Below is my comment.


> -Original Message-
> From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> Sent: Thursday, November 01, 2012 9:35 PM
> To: dri-devel at lists.freedesktop.org
> Cc: sw0312.kim at samsung.com; inki.dae at samsung.com; jy0922.shim at 
> samsung.com;
> kyungmin.park at samsung.com; prashanth.g at samsung.com; joshi at 
> samsung.com;
> s.shirish at samsung.com; r.sh.open at gmail.com; rahul.sharma at samsung.com
> Subject: [PATCH] drm: exynos: fix for mapping non contig dma buffers
> 
> This patch fixes the problem of mapping gem objects which are non-
> contigous
> dma buffers. These buffers are described using SG table and SG lists. Each
> valid SG List is pointing to a single page or group of pages which are
> physically contigous.
> 
> Current implementation just maps the first page of each SG List and leave
> the other pages unmapped, leading to a crash.
> 
> Given solution finds the page struct for all the pages in the SG list and
> map them one by one. This ensures all the pages of current SG list are
> mapped.
> Next SG list of the same buffer will be mapped when page fault occurs for
> the offset belongs to that list.
> 
> This patch is based on branch exynos-drm-next-iommu at
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> 
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |   34
> +++---
>  1 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 7057729..d2d6188 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -95,17 +95,43 @@ static int exynos_drm_gem_map_buf(struct
> drm_gem_object *obj,
>  {
>   struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
>   struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
> + struct scatterlist *sgl;
>   unsigned long pfn;
> + unsigned int phys_addr;
> + int ret, i;
> 
>   if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
>   if (!buf->pages)
>   return -EINTR;

Buf->pages should be checked in all cases. For this, see below comment.

> 
> - pfn = page_to_pfn(buf->pages[page_offset++]);
> - } else
> + sgl = buf->sgt->sgl;
> + for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
> + if (page_offset < (sgl->length >> PAGE_SHIFT))
> + break;
> + page_offset -=  (sgl->length >> PAGE_SHIFT);
> + }
> +
> + if (i >= buf->sgt->nents) {
> + DRM_ERROR("invalid page offset\n");
> + return -EINVAL;
> + }
> +
> + phys_addr = sg_phys(sgl);
> +
> + for (i = 0; i < (sgl->length >> PAGE_SHIFT); i++) {
> + pfn = __phys_to_pfn(phys_addr + (i << PAGE_SHIFT));
> + ret = vm_insert_mixed(vma, f_vaddr + (i <<
PAGE_SHIFT),
> + pfn);
> + if (ret < 0) {
> + DRM_ERROR("failed to map page.\n");
> + return ret;
> + }
> + }
> + return 0;
> + } else {
>   pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;

It seems like that you missed EXYNOS_BO_CONTIG type testing. With iommu,
buf->dma_addr has device address but not physical address. So correct it
like below,
pfn = page_to_pfn(buf->pages[0]) + page_offset;

And one more posting? :)

Thanks,
Inki Dae

> -
> - return vm_insert_mixed(vma, f_vaddr, pfn);
> + return vm_insert_mixed(vma, f_vaddr, pfn);
> + }
>  }
> 
>  static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
> --
> 1.7.0.4

[PATCH v2 4/4] drm: hold event_lock while accessing vblank_event_list

[Imre Deak]

Currently the only users of drm_vblank_off() are i915 and gma500,
neither of which holds the event_lock when calling this function.
Fix this by holding the event_lock while traversing the list.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_irq.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3a3d0ce..c6cd558 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -949,6 +949,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)

/* Send any queued vblank events, lest the natives grow disquiet */
seq = drm_vblank_count_and_time(dev, crtc, );
+
+   spin_lock(>event_lock);
list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
if (e->pipe != crtc)
continue;
@@ -965,6 +967,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
 e->event.sequence);
}
+   spin_unlock(>event_lock);

spin_unlock_irqrestore(>vbl_lock, irqflags);
 }
-- 
1.7.9.5

[PATCH v2 3/4] drm/exynos: fix lockdep for event_lock wrt. vbl_time_lock

[Imre Deak]

Currently the exynos driver calls drm_vblank_off() with the event_lock
held, while drm_vblank_off() will lock vbl_time and vblank_time_lock.
This lock dependency chain conflicts with the one in drm_handle_vblank()
where we first lock vblank_time_lock and then the event_lock.

Fix this by removing the above drm_vblank_off() calls which are in fact
never executed: drm_dev->vblank_disable_allowed is only ever non-zero
during driver init, until it's set in {fimd,vidi}_subdrv_probe. Both the
driver init and open code is protected by drm_global_mutex, so the
earliest page flip ioctl can happen only after vblank_disable_allowed is
set to 1. Thus {fimd,vidi}_finish_pageflip - with pending flip events -
will always get called with vblank_disable_allowed being 1.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   12 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   12 
 2 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e69b7c4..2eb131c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -623,7 +623,6 @@ static void fimd_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
struct drm_pending_vblank_event *e, *t;
struct timeval now;
unsigned long flags;
-   bool is_checked = false;

spin_lock_irqsave(_dev->event_lock, flags);

@@ -633,8 +632,6 @@ static void fimd_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
if (crtc != e->pipe)
continue;

-   is_checked = true;
-
do_gettimeofday();
e->event.sequence = 0;
e->event.tv_sec = now.tv_sec;
@@ -645,15 +642,6 @@ static void fimd_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
drm_vblank_put(drm_dev, crtc);
}

-   if (is_checked) {
-   /*
-* don't off vblank if vblank_disable_allowed is 1,
-* because vblank would be off by timer handler.
-*/
-   if (!drm_dev->vblank_disable_allowed)
-   drm_vblank_off(drm_dev, crtc);
-   }
-
spin_unlock_irqrestore(_dev->event_lock, flags);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index e26d455..4b0c16b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -382,7 +382,6 @@ static void vidi_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
struct drm_pending_vblank_event *e, *t;
struct timeval now;
unsigned long flags;
-   bool is_checked = false;

spin_lock_irqsave(_dev->event_lock, flags);

@@ -392,8 +391,6 @@ static void vidi_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
if (crtc != e->pipe)
continue;

-   is_checked = true;
-
do_gettimeofday();
e->event.sequence = 0;
e->event.tv_sec = now.tv_sec;
@@ -404,15 +401,6 @@ static void vidi_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
drm_vblank_put(drm_dev, crtc);
}

-   if (is_checked) {
-   /*
-* don't off vblank if vblank_disable_allowed is 1,
-* because vblank would be off by timer handler.
-*/
-   if (!drm_dev->vblank_disable_allowed)
-   drm_vblank_off(drm_dev, crtc);
-   }
-
spin_unlock_irqrestore(_dev->event_lock, flags);
 }

-- 
1.7.9.5

[PATCH v2 2/4] drm/exynos: call drm_vblank_put for each queued flip event

[Imre Deak]

It's guaranteed that for each event on pageflip_event_list we have
called drm_vblank_get() - see exynos_drm_crtc_page_flip() - so checking
for this is redundant.

Also we need to call drm_vblank_put() for each event on the list, not
only once, otherwise we'd leak vblank references if there are multiple
events on the list.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |8 +---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |8 +---
 drivers/gpu/drm/exynos/exynos_mixer.c|   11 +--
 3 files changed, 3 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 130a2b5..e69b7c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -642,17 +642,11 @@ static void fimd_finish_pageflip(struct drm_device 
*drm_dev, int crtc)

list_move_tail(>base.link, >base.file_priv->event_list);
wake_up_interruptible(>base.file_priv->event_wait);
+   drm_vblank_put(drm_dev, crtc);
}

if (is_checked) {
/*
-* call drm_vblank_put only in case that drm_vblank_get was
-* called.
-*/
-   if (atomic_read(_dev->vblank_refcount[crtc]) > 0)
-   drm_vblank_put(drm_dev, crtc);
-
-   /*
 * don't off vblank if vblank_disable_allowed is 1,
 * because vblank would be off by timer handler.
 */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index e4b8a8f..e26d455 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -401,17 +401,11 @@ static void vidi_finish_pageflip(struct drm_device 
*drm_dev, int crtc)

list_move_tail(>base.link, >base.file_priv->event_list);
wake_up_interruptible(>base.file_priv->event_wait);
+   drm_vblank_put(drm_dev, crtc);
}

if (is_checked) {
/*
-* call drm_vblank_put only in case that drm_vblank_get was
-* called.
-*/
-   if (atomic_read(_dev->vblank_refcount[crtc]) > 0)
-   drm_vblank_put(drm_dev, crtc);
-
-   /*
 * don't off vblank if vblank_disable_allowed is 1,
 * because vblank would be off by timer handler.
 */
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 614b2e9..5720e82 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -884,7 +884,6 @@ static void mixer_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
struct drm_pending_vblank_event *e, *t;
struct timeval now;
unsigned long flags;
-   bool is_checked = false;

spin_lock_irqsave(_dev->event_lock, flags);

@@ -894,7 +893,6 @@ static void mixer_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
if (crtc != e->pipe)
continue;

-   is_checked = true;
do_gettimeofday();
e->event.sequence = 0;
e->event.tv_sec = now.tv_sec;
@@ -902,16 +900,9 @@ static void mixer_finish_pageflip(struct drm_device 
*drm_dev, int crtc)

list_move_tail(>base.link, >base.file_priv->event_list);
wake_up_interruptible(>base.file_priv->event_wait);
+   drm_vblank_put(drm_dev, crtc);
}

-   if (is_checked)
-   /*
-* call drm_vblank_put only in case that drm_vblank_get was
-* called.
-*/
-   if (atomic_read(_dev->vblank_refcount[crtc]) > 0)
-   drm_vblank_put(drm_dev, crtc);
-
spin_unlock_irqrestore(_dev->event_lock, flags);
 }

-- 
1.7.9.5

[PATCH v2 1/4] drm/exynos: hold event_lock while accessing pageflip_event_list

[Imre Deak]

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index fce245f..2efa4b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -236,16 +236,21 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
goto out;
}

+   spin_lock_irq(>event_lock);
list_add_tail(>base.link,
_priv->pageflip_event_list);
+   spin_unlock_irq(>event_lock);

crtc->fb = fb;
ret = exynos_drm_crtc_mode_set_base(crtc, crtc->x, crtc->y,
NULL);
if (ret) {
crtc->fb = old_fb;
+
+   spin_lock_irq(>event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
list_del(>base.link);
+   spin_unlock_irq(>event_lock);

goto out;
}
-- 
1.7.9.5

[PATCH v2 0/4] drm/exynos,intel: fix locking for flip/vbl event list

[Imre Deak]

The patchset adds the missing event_lock when accessing the
vblank_event_list in drm_vblank_off() and as preparation for this
also fixes a few other issues in the exynos driver.

This is also a dependency for Rob Clark's drm_send_vblank_event()
rework as that would trigger a warning for the unhold event_lock without
this changeset.

The exynos changes are only compile tested, the rest is tested on an
Intel IVB machine on top of drm-intel-nightly + drm_send_vblank_event()
rework, with i-g-t/flip_test.

In v2:
- Instead of fixing the event_lock vs. vblank_time_lock lockdep issue in
  drm_handle_vblank(), fix it in the exynos driver. This looks like the
  more logical thing to do and this way we also have a smaller impact on
  the rest of DRM code.

Imre Deak (4):
  drm/exynos: hold event_lock while accessing pageflip_event_list
  drm/exynos: call drm_vblank_put for each queued flip event
  drm/exynos: fix lockdep for event_lock wrt. vbl_time_lock
  drm: hold event_lock while accessing vblank_event_list

 drivers/gpu/drm/drm_irq.c|3 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   20 +---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   20 +---
 drivers/gpu/drm/exynos/exynos_mixer.c|   11 +--
 5 files changed, 11 insertions(+), 48 deletions(-)

-- 
1.7.9.5

[Bug 56666] AMD SUMO GPU lockup when launching any heavy 3D application

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

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

--- Comment #1 from Alex Deucher  ---
Can you try mesa 8.0.x?  This might be a duplicate of bug 56405.  If 8.0.x
works, 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/20121102/56589360/attachment.html>

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

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

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

--- Comment #7 from Alex Deucher  ---
Can you try a mesa 8.0.x release?  This might be a duplicate of bug 56405.

-- 
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/20121102/4739e8f2/attachment.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #4 from Alex Deucher  ---
Are you sure it's the 2D tiling commit?  Does just reverting that commit fix
the issue?  I think it's probably another commit.  Does your tree have:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=39eac3104c2f08b4d78aab3f88fd104301eb4711
Can you try again with git master?

-- 
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/20121102/096d83f6/attachment.html>

[Bug 44852] 3D Acceleration initialization failed for Fusion Wrestler 9808

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #6 from Andreas Boll  ---
Is this still an issue with a newer driver/kernel?

-- 
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/20121102/daf6adab/attachment.html>

[PATCH] kms: Make libkms.h usable in C++

[Jakob Bornecrantz]

On Thu, Nov 1, 2012 at 10:40 AM, Laurent Pinchart
 wrote:
> Wrap the header in extern "C" { ... };.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jakob Bornecrantz 

[PATCH] kms: Return a negative error code in kms_bo_create()

[Jakob Bornecrantz]

On Thu, Nov 1, 2012 at 10:38 AM, Laurent Pinchart
 wrote:
> The function returns returns 0 on success or a negative value in case of an
> error, except when given invalid attributes in which case it returns the
> positive EINVAL value. Replace that with -EINVAL to allow the caller to detect
> errors with a < 0 check.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jakob Bornecrantz 

[Bug 48759] [Piglit] : Regression failure observed for Glean test bufferObject

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

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Andreas Boll  ---
Is this still an issue with a newer driver/kernel?

-- 
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/20121102/b5ab076d/attachment-0001.html>

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #14 from Alex Deucher  ---
(In reply to comment #13)
> (In reply to comment #12)
> > If they are 32-bit games, you'll hit the same issue.
> 
> Not meaning to question your expertise, but would you care to explain: if
> "wine requires 32-bit 3D driver" why virtual desktop (i.e. non-fullscreen)
> mode is running just fine? In my layman view this would mean wine's
> perfectly able to handle the 2D rendering and display on it's part without
> having to install 32-bit 3D driver (which in my case would require complete
> switch to closed source catalyst package and I'm a bit reluctant to do so).

You can install a 32 bit version of the open source 3D driver as well.  Just
because the graphics in a game do not appear to be 3D, they generally still use
a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since the apps
are 32 bit.  Also there seem to be several possibly unrelated issues now piled
onto this bug.

-- 
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/20121102/5ff4a00a/attachment.html>

[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #1 from Alex Deucher  ---
Please update to a newer xf86-video-ati snapshot.  You are missing some patches
required for proper support with kwin.  Please reopen if you are still having
issues with a newer snapshot.

-- 
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/20121102/ba3a0bb8/attachment.html>

[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #69414|text/plain  |image/jpeg
  mime type||

-- 
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/20121102/9adf98c3/attachment.html>

[Bug 49632] radeon: The kernel rejected CS,

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

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

Andreas Boll  changed:

   What|Removed |Added

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

-- 
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/20121102/6cf1c4d5/attachment.html>

[Bug 48455] Enabling R600_STREAMOUT causes graphical corruption

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

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

Andreas Boll  changed:

   What|Removed |Added

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

-- 
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/20121102/4b95df69/attachment.html>

[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)

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

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

Andreas Boll  changed:

   What|Removed |Added

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

-- 
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/20121102/a5fed077/attachment-0001.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/Radeon  |Drivers/Gallium/r600

-- 
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/20121102/fb2505d9/attachment.html>

[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)

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

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

--- Comment #7 from Martin Lambers  ---
I don't have access anymore to the AMD graphics card that originally exposed
the problem for me.

I can only confirm that the problem does not exist with Mesa 9.0 (from Ubuntu
12.10) with an Intel Sandybridge GPU:
OpenGL Version: 3.0 Mesa 9.0
OpenGL Renderer: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL Vendor: Intel Open Source Technology Center

Thanks for your work.

Martin

-- 
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/20121102/e62206e6/attachment.html>

[PATCH] drm: reduce default drm vblank off delay to 50ms

[Jesse Barnes]

On Fri, 02 Nov 2012 06:56:57 +0100
Mario Kleiner  wrote:
> Jesse, thanks for cc'ing me, much appreciated :)
> 
> Psychtoolbox should be fine with a 50 msecs vblank off delay. I think i 
> tested with values somewhere between 50 - 100 msecs at the time the drm 
> patches were made. The way i schedule swaps for a specific target time 
> 'twhen' is to:
> 
> 1. glXGetSyncValuesOML(msc,ust) as a baseline vblank count and time.
> 2. Some basic math to calculate targetMSC based on 'twhen' and step 1.
> 3. glXSwapBuffersMscOML(targetMSC);
> 
> So it should tolerate wrong vblank counts due to races, as long as 
> vblank doesn't get disabled between 1. and 3. A default vblank off delay 
> lower than maybe 1 refresh duration would make me nervous, given that 
> most kms drivers are not race-free and it is possible for a userspace 
> app or the x-server to get stalled for a couple of msecs.
> 
> E.g., radeon wouldn't allow this race-free, because the drm code assumes 
> that the hw vblank counter increments at leading edge of vblank, whereas 
> radeon hw does it at the traling edge, iirc. nouveau doesn't have any hw 
> vblank counter support, so it is "race free" until somebody fixes the 
> driver ;-) - ie., it would work with apps that use steps 1/2/3 above, 
> but broken for any other app.

Right, ok that clarifies things for me.  I knew you had some kind of
race between reading the hw value and scheduling things.  Is the above
in a comment somewhere in the vblank code?

> More trusting apps could get into more trouble with 50 msecs vs. 5000 
> msecs ...
> 
> What kind of race in your code do you mean? What does your commit 
> message "...now that we've dealt with the hw races in Mario's updated 
> code..." refer to?

I was vaguely referring to all the fixes from a couple of years ago,
plus a foggy recollection of the above (which I thought might have been
magically fixed somehow).

> I remember that Matthew Garret sent out a patch set a couple of months 
> ago which aimed to make this configurable per kms driver, so each driver 
> could opt into low vblank off delay if it was ready to do it properly. 
> That would make a lot of sense.

Yeah, that would also be fine with me.  Unfortunately, these simple
patches seem to rot on the vine and never get applied, so we're stuck
with our current 5s timeout (which is huge).

> That said, for the current intel-ddx it wouldn't even matter for X11/GLX 
> applications if the kernel returned random numbers instead of vblank 
> counts, because the OML_sync_control swap scheduling in the ddx is 
> totally broken, and even glXSwapBuffers is a wreck for any swapinterval 
> setting except 0 and 1 since triple-buffering was introduced a year ago 
> and introduced some bug. Psychtoolbox now detects this since a few 
> weeks, prints out critical warnings to the user and tries to work around 
> with glXSwapBuffers trickery.
> 
> I submitted a patch to fix the rather trivial but nasty bug. Jesse, if 
> you find some time, could you review it and convince Chris to merge it?
> Should be on the intel-gfx list and in your inbox, a simple . Subject line
> "[PATCH 2/3] ddx/dri2: Repair broken pageflip swap scheduling.", sent at 
> 7 October 2012.

Yeah, I'll check it out.  This code has changed a lot since I last
worked on it...

> I'll forward it again to you. Chris Wilson already gave me an off-list 
> review for that patch series after i pinged him. Unfortunately a rather 
> terse one, cited here:
> 
> "On Mon, 15 Oct 2012 16:46:52 +0200, Mario Kleiner 
>  wrote:
>  > Hi Chris,
>  >
>  > can you please check & merge at least the first two patches of the
>  > series into the intel ddx?
> 
> The first is along the right path, but I think you want to base the
> split on divisor==0. The second is broken in the DRI2 layer, as the
> SwapLimit mechanism exposes the multi-client race to a single client
> (i.e. there is no serialisation between the InvalidateEvent and the
> GetBuffers, and the InvalidateEvent is always broadcast too early.) The
> third is just plain wrong, as pageflip may be a blocking ioctl (and will
> impose client blocking) so anybody who wants to override SwapBuffersWait
> will also want to prevent the inherent wait due to the flip. In any
> event that option is to only paper over the loose DRI2 specification and
> the lack of client control...
> -Chris
> "
> 
> If i understood the comment wrt. to patch [2/3] "The first is along the 
> right path, but I think you want to base the split on divisor==0." 
> correctly, then that would be just as broken as the current 
> implementation, with some code obfuscation and confusion added, but i 
> don't know, maybe i just misunderstood his comment? I asked for 
> clarification, but he didn't respond to my followup e-mails. Maybe he 
> was just too busy to reply, maybe i'm just too pushy and annoying.
> 
> I will try to make some friendship with piglit and see if i can write 
> some tests when i find some time to catch such bugs earlier in 

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

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

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

Andreas Boll  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |XOrg CVS
  Component|Drivers/DRI/R600|DRM/Radeon

-- 
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/20121102/ee155aa4/attachment-0001.html>

[PATCH 46/51] drm/i915: Add support for atomic modesetting completion events

[Ville Syrjälä]

On Thu, Nov 01, 2012 at 11:39:58PM +0100, Daniel Vetter wrote:
> On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote:
> > On Thu, 1 Nov 2012 19:07:02 +0200
> > Ville Syrj?l?  wrote:
> > 
> > > On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
> > > > On Thu, 1 Nov 2012 12:12:35 +0100
> > > > Daniel Vetter  wrote:
> > > > 
> > > > > On Thu, Oct 25, 2012 at 8:05 PM,   
> > > > > wrote:
> > > > > > From: Ville Syrj?l? 
> > > > > >
> > > > > > Send completion events when the atomic modesetting operations has
> > > > > > finished succesfully.
> > > > > >
> > > > > > Signed-off-by: Ville Syrj?l? 
> > > > > 
> > > > > I have to admit I'm not on top of the latest ioctl/interface
> > > > > discussion, but one new requirement for the modeset (not the pageflip
> > > > > part) of the all this atomic stuff I've discovered is that the kernel
> > > > > needs to be able to select the crtcs for each output completely
> > > > > unrestricted. I think userspace should simply pass in abstract crtc
> > > > > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual
> > > > > crtcs it has selected.
> > > > > 
> > > > > We can't do that remapping internally because the crtc abstraction is 
> > > > > leaky:
> > > > > - wait_for_vblank requires the pipe id, which could then change on 
> > > > > every modeset
> > > > > - similarly userspace doing MI_WAIT for scanlines needs to know the
> > > > > actual hw pipe in use by a crtc.
> > > > > And current userspace presumes that the mapping between crtc->pipe
> > > > > doesn't change.
> > > > > 
> > > > > An example why the kernel needs to pick the crtc for userspace:
> > > > > - on ivb only pipe A has a 7x5 panel fitter, so usually you want to
> > > > > put the panel on the first crtc
> > > > > - but if you run in a 3 pipe configuration and have an eDP panel, it's
> > > > > better to put the eDP output on pipe C, since then pipes A will have
> > > > > full 4-lane fdi links to the pch ports (instead of otherwise only 2
> > > > > lanes each on links B)
> > > > > - similarly when we have a 3 pipe configuration with all encoders on
> > > > > the pch, we need to move the mode with the highest dotclock to pipe A
> > > > > (since that's the only one which will have 4 lanes, pipe B will only
> > > > > have 2 each).
> > > > > - afaik these kind of asymmetric constraints won't disappear anytime
> > > > > soon, haswell definitely still has some.
> > > > 
> > > > Yeah that's a good point... adding a virtual crtc layer would solve
> > > > this and let us preserve the existing ABI.
> > > 
> > > How would the state handling work? I mean if drm_crtc X currently has
> > > some state, drm_crtc Y has some other state, and then we do a modeset
> > > which would require swapping the roles of the crtcs, what would happen
> > > to the bits of state that we didn't specify?
> > > 
> > > If we'd do the remapping below the drm crtc layer, the state would
> > > always be tied to the drm crtc. But that would definitely require
> > > mostly uniform hardware "crtcs" so that the capabilities of the
> > > drm_crtcs wouldn't keep changing whenever the remap happens.
> > > 
> > > Well, I suppose we could tie the state to the virtual crtc instead,
> > > and doing an operation on a real drm_crtc would also change the
> > > state of the currently bound virtual crtc. And then changing the
> > > virtual<->real mapping would just copy the state over from the virtual
> > > crtc to the real drm_crtc.
> > > 
> > > And if we do it for crtcs, then we'd need to do it for planes as well,
> > > because the plane<->crtc mapping can be fixed or otherwise limited
> > > in some fashion.
> > > 
> > > Either way it sounds rather messy to me.
> > > 
> > > Another option would be just leave it up to userspace to make the
> > > correct choice between crtcs and planes. But then user space needs
> > > to be equipped with more hardware specific knowledge, so it's not
> > > a very appealing idea either.
> > 
> > Yeah it gets ugly one way or another.  From a userspace perspective,
> > keeping the ugliness in the kernel is nice, and if we have to do it
> > somewhere I guess I'd prefer that.
> 
> My tentative Grand Plan (tm) for the atomic modeset implementation of such
> things is to pimp the new struct intel_crtc_config to contain all the
> configuration state (so with Rob's atomic modeset proposal that would also
> embed the drm_crtc_state struct). It would also contain all the derived
> state like pll settings, fdi lanes, ...
> 
> Now the improve >mode_adjust stage, now called ->compute_config allocates
> such a struct for each crtc, does some prep, calls down into
> encoder->compute_config callbacks, then applies any fixups and screaming
> required to come up with a working global config. All rather hazy, I know
> ;-)
> 
> But e.g. for the above case of trying to squeeze the fdi links into the
> available sets of fdi lanes I guess we could first compute the upper bound
> for the fdi link requirements (the current 

[PATCH 2/2] drm/nouveau: convert to dev_pm_ops

[Dave Airlie]

From: Dave Airlie 

This is a precursor to dynamic power management support for nouveau,

we need to use pm ops for that, so first convert the driver to using pm ops
interfaces.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 93 +--
 drivers/gpu/drm/nouveau/nouveau_drm.h |  4 +-
 drivers/gpu/drm/nouveau/nouveau_vga.c |  5 +-
 3 files changed, 71 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ccae8c2..85aa1a6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -392,17 +392,12 @@ nouveau_drm_remove(struct pci_dev *pdev)
 }

 int
-nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t pm_state)
+nouveau_do_suspend(struct drm_device *dev)
 {
-   struct drm_device *dev = pci_get_drvdata(pdev);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_cli *cli;
int ret;

-   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF ||
-   pm_state.event == PM_EVENT_PRETHAW)
-   return 0;
-
NV_INFO(drm, "suspending fbcon...\n");
nouveau_fbcon_set_suspend(dev, 1);

@@ -431,13 +426,6 @@ nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t 
pm_state)
goto fail_client;

nouveau_agp_fini(drm);
-
-   pci_save_state(pdev);
-   if (pm_state.event == PM_EVENT_SUSPEND) {
-   pci_disable_device(pdev);
-   pci_set_power_state(pdev, PCI_D3hot);
-   }
-
return 0;

 fail_client:
@@ -450,24 +438,33 @@ fail_client:
return ret;
 }

-int
-nouveau_drm_resume(struct pci_dev *pdev)
+int nouveau_pmops_suspend(struct device *dev)
 {
-   struct drm_device *dev = pci_get_drvdata(pdev);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nouveau_cli *cli;
+   struct pci_dev *pdev = to_pci_dev(dev);
+   struct drm_device *drm_dev = pci_get_drvdata(pdev);
int ret;

-   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;

-   NV_INFO(drm, "re-enabling device...\n");
-   pci_set_power_state(pdev, PCI_D0);
-   pci_restore_state(pdev);
-   ret = pci_enable_device(pdev);
+   ret = nouveau_do_suspend(drm_dev);
if (ret)
return ret;
-   pci_set_master(pdev);
+
+   pci_save_state(pdev);
+   pci_disable_device(pdev);
+   pci_set_power_state(pdev, PCI_D3hot);
+
+   return 0;
+}
+
+int
+nouveau_do_resume(struct drm_device *dev)
+{
+   struct nouveau_drm *drm = nouveau_drm(dev);
+   struct nouveau_cli *cli;
+
+   NV_INFO(drm, "re-enabling device...\n");

nouveau_agp_reset(drm);

@@ -491,6 +488,42 @@ nouveau_drm_resume(struct pci_dev *pdev)
return 0;
 }

+int nouveau_pmops_resume(struct device *dev)
+{
+   struct pci_dev *pdev = to_pci_dev(dev);
+   struct drm_device *drm_dev = pci_get_drvdata(pdev);
+   int ret;
+
+   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   return 0;
+
+   pci_set_power_state(pdev, PCI_D0);
+   pci_restore_state(pdev);
+   ret = pci_enable_device(pdev);
+   if (ret)
+   return ret;
+   pci_set_master(pdev);
+
+   return nouveau_do_resume(drm_dev);
+}
+
+static int nouveau_pmops_freeze(struct device *dev)
+{
+   struct pci_dev *pdev = to_pci_dev(dev);
+   struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+   return nouveau_do_suspend(drm_dev);
+}
+
+static int nouveau_pmops_thaw(struct device *dev)
+{
+   struct pci_dev *pdev = to_pci_dev(dev);
+   struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+   return nouveau_do_resume(drm_dev);
+}
+
+
 static int
 nouveau_drm_open(struct drm_device *dev, struct drm_file *fpriv)
 {
@@ -643,14 +676,22 @@ nouveau_drm_pci_table[] = {
{}
 };

+static const struct dev_pm_ops nouveau_pm_ops = {
+   .suspend = nouveau_pmops_suspend,
+   .resume = nouveau_pmops_resume,
+   .freeze = nouveau_pmops_freeze,
+   .thaw = nouveau_pmops_thaw,
+   .poweroff = nouveau_pmops_freeze,
+   .restore = nouveau_pmops_resume,
+};
+
 static struct pci_driver
 nouveau_drm_pci_driver = {
.name = "nouveau",
.id_table = nouveau_drm_pci_table,
.probe = nouveau_drm_probe,
.remove = nouveau_drm_remove,
-   .suspend = nouveau_drm_suspend,
-   .resume = nouveau_drm_resume,
+   .driver.pm = _pm_ops,
 };

 static int __init
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h 
b/drivers/gpu/drm/nouveau/nouveau_drm.h
index 8194712..e0c99aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.h
@@ -129,8 +129,8 @@ nouveau_dev(struct drm_device *dev)
return nv_device(nouveau_drm(dev)->device);
 }

-int nouveau_drm_suspend(struct pci_dev *, 

[PATCH 1/2] drm/nouveau: Add interface to detect optimus and v1 support

[Dave Airlie]

From: Dave Airlie 

This is required to decide if we can auto-powerdown and how to implement it.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c | 30 ++
 drivers/gpu/drm/nouveau/nouveau_acpi.h |  4 
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 48783e1..d97f200 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -35,6 +35,14 @@ static struct nouveau_dsm_priv {
acpi_handle rom_handle;
 } nouveau_dsm_priv;

+bool nouveau_is_optimus(void) {
+   return nouveau_dsm_priv.optimus_detected;
+}
+
+bool nouveau_is_v1_dsm(void) {
+   return nouveau_dsm_priv.dsm_detected;
+}
+
 #define NOUVEAU_DSM_HAS_MUX 0x1
 #define NOUVEAU_DSM_HAS_OPT 0x2

@@ -183,9 +191,7 @@ static int nouveau_dsm_set_discrete_state(acpi_handle 
handle, enum vga_switchero

 static int nouveau_dsm_switchto(enum vga_switcheroo_client_id id)
 {
-   /* perhaps the _DSM functions are mutually exclusive, but prepare for
-* the future */
-   if (!nouveau_dsm_priv.dsm_detected && nouveau_dsm_priv.optimus_detected)
+   if (!nouveau_dsm_priv.dsm_detected)
return 0;
if (id == VGA_SWITCHEROO_IGD)
return nouveau_dsm_switch_mux(nouveau_dsm_priv.dhandle, 
NOUVEAU_DSM_LED_STAMINA);
@@ -201,7 +207,7 @@ static int nouveau_dsm_power_state(enum 
vga_switcheroo_client_id id,

/* Optimus laptops have the card already disabled in
 * nouveau_switcheroo_set_state */
-   if (!nouveau_dsm_priv.dsm_detected && nouveau_dsm_priv.optimus_detected)
+   if (!nouveau_dsm_priv.dsm_detected)
return 0;

return nouveau_dsm_set_discrete_state(nouveau_dsm_priv.dhandle, state);
@@ -283,24 +289,24 @@ static bool nouveau_dsm_detect(void)
has_optimus = 1;
}

-   if (vga_count == 2 && has_dsm && guid_valid) {
+   /* find the optimus DSM or the old v1 DSM */
+   if (has_optimus == 1) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
);
-   printk(KERN_INFO "VGA switcheroo: detected DSM switching method 
%s handle\n",
+   printk(KERN_INFO "VGA switcheroo: detected Optimus DSM method 
%s handle\n",
acpi_method_name);
-   nouveau_dsm_priv.dsm_detected = true;
+   nouveau_dsm_priv.optimus_detected = true;
ret = true;
-   }
-
-   if (has_optimus == 1) {
+   } else if (vga_count == 2 && has_dsm && guid_valid) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
);
-   printk(KERN_INFO "VGA switcheroo: detected Optimus DSM method 
%s handle\n",
+   printk(KERN_INFO "VGA switcheroo: detected DSM switching method 
%s handle\n",
acpi_method_name);
-   nouveau_dsm_priv.optimus_detected = true;
+   nouveau_dsm_priv.dsm_detected = true;
ret = true;
}

+
return ret;
 }

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h 
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 08af677..d0da230 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -4,6 +4,8 @@
 #define ROM_BIOS_PAGE 4096

 #if defined(CONFIG_ACPI)
+bool nouveau_is_optimus(void);
+bool nouveau_is_v1_dsm(void);
 void nouveau_register_dsm_handler(void);
 void nouveau_unregister_dsm_handler(void);
 void nouveau_switcheroo_optimus_dsm(void);
@@ -11,6 +13,8 @@ int nouveau_acpi_get_bios_chunk(uint8_t *bios, int offset, 
int len);
 bool nouveau_acpi_rom_supported(struct pci_dev *pdev);
 void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
 #else
+static inline bool nouveau_is_optimus(void) { return false; };
+static inline bool nouveau_is_v1_dsm(void) { return false; };
 static inline void nouveau_register_dsm_handler(void) {}
 static inline void nouveau_unregister_dsm_handler(void) {}
 static inline void nouveau_switcheroo_optimus_dsm(void) {}
-- 
1.7.12.1

[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown

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

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

--- Comment #3 from Andy Furniss  ---
(In reply to comment #2)
> Do you mean it's slower than without the commit or is it running mostly at
> the same speed when it's slowing down?

It's way slower than without the commit, but only temporarily then it recovers.

In case you have etqw, I am testing @1920x1080 fullscreen with everything
turned on/up as high as possible.

I've found another issue, but it's not related to this or llvm and could be
quite old as I've not left etqw running for ~30 mins for some months.

The issue is I run out of mem (4 gig). I'll open a new bug when I've had more
time to test with older kernels.

-- 
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/20121102/b38034ff/attachment.html>

[Bug 36965] GL_EXT_texture_sRGB (included in OpenGL 2.1) is broken (glean/texture_srgb broken too)

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

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

--- Comment #6 from Andreas Boll  ---
(In reply to comment #4)
> There is a lot of other code which plays role in handling sRGB textures. I
> don't think getteximage.c is relevant to this issue(s).
> 
> Nevertheless, it looks like Pavel's and Martin's issues are different bugs.
> 
> Pavel reported that GL_EXT_texture_sRGB_decode, which is only in 7.11, is
> broken specifically on r300g, but other drivers might be affected as well
> and it definitely looks like a Mesa core bug. Pavel, could you please add it
> as a new bug against Mesa core?
> 
> Martin's issue is likely related to the fact that piglit/glean/texture_srgb
> fails on r600g. Taking a look at it might be a good start.

the piglit passes for me on my rv770 with mesa from git (470952f)

@Martin: Can you test with a newer version of mesa (9.0 or mesa from git)?

-- 
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/20121102/a6149fc7/attachment.html>

[pull] drm-intel-next for 3.8

[Daniel Vetter]

Hi Dave,

Quite a pile since this is 4 weeks worth of patches:
- tons of hsw dp prep patches form Paulo
- round scheduled work items and timers to nearest second (Chris)
- some hw workarounds (Jesse)
- vlv dp support and related fixups (Vijay et al.)
- basic haswell dp support, not yet wired up for external ports (Paulo)
- edp support (Paulo)
- tons of refactorings to prepare for the above (Paulo)
- panel rework, unifiying code between lvds and edp panels (Jani)
- panel fitter scaling modes (Jani + Yuly Novikov)
- panel power improvements, should now work without the BIOS setting it up
- extracting some dp helpers from radeon/i915 and move them to
  drm_dp_helper.c
- randome pile of workarounds (Damien, Ben, ...)
- some cleanups for the register restore code for suspend/resume
- secure batchbuffer support, should enable tear-free blits on gen6+
  (Chris)
- random smaller fixlets and cleanups.

For Haswell display support, this is not yet everything, big things still
missing are:
- hdmi/dp encoder unification, otherwise we can't enable non-eDP outputs
- vga fixes (which essentially required forking all the fdi/pch code)

Both are already in -next-queued, so for the next pull I plan to move
Haswell out of experimental support.

Note that this also contains a -rc2 backmerge, which I've botched up
slightly:( Luckily Jani caught me and fixed things up, his patch is
included on top of what QA beat on.

For drm core stuff I have two series outstanding:
- kerneldoc/DocBook patches demanded by Lauren Pinchart. Note that the
  last patch in that series depends upon the dp helper refactoring
  included in here.
- relaunched hpd rework, requested by Alex Deucher.
Can you please look into slurping these into drm-next, too?

Yours, Daniel

The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:

  Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)

are available in the git repository at:

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

for you to fetch changes up to c8241969b44438c9335b59d375b627214bc36483:

  drm/i915: pass adjusted_mode to intel_choose_pipe_bpp_dither(), again 
(2012-11-02 09:57:28 +0100)


Adam Jackson (6):
  drm: Export drm_probe_ddc()
  drm/dp: Update DPCD defines
  drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
  drm/i915/dp: Be smarter about connection sense for branch devices
  drm/dp: Document DP spec versions for various DPCD registers
  drm/dp: Make sink count DP 1.2 aware

Ben Widawsky (3):
  drm/i915: Extract PCU communication
  drm/i915: Workaround to bump rc6 voltage to 450
  drm/i915: Add rc6vids to debugfs

Chris Wilson (5):
  drm/i915: Align the hangcheck wakeup to the nearest second
  drm/i915: Align the retire_requests worker to the nearest second
  drm/i915: Allow DRM_ROOT_ONLY|DRM_MASTER to submit privileged batchbuffers
  drm/i915: Document the multi-threaded FORCEWAKE bits
  drm/i915: Clear FORCEWAKE when taking over from BIOS

Damien Lespiau (9):
  drm/i915: Remove the disabling of VHR unit clock gating for HSW
  drm/i915: Document that we are implementing WaDisableBackToBackFlipFix
  drm/i915: Remove the WaDisableBackToBackFlipFix w/a for Haswell
  drm/i915: Fix the SCC/SSC typo in the SPLL bits definition
  drm/i915: Consolidate ILK_DSPCLK_GATE and PCH_DSPCLK_GATE
  drm/i915: Program DSPCLK_GATE_D only once on Ironlake
  drm/i915: Don't program DSPCLK_GATE_D twice on IVB and VLV
  drm/i915: Don't try to use SPR_SCALE when we don't have a sprite scaler
  drm/i915: VLV does not have a sprite scaler

Daniel Vetter (24):
  drm/i915: s/DRM_IRQ_ARGS/int irq, void *arg
  drm/i915: move hpd handling to (ibx|cpt)_irq_handler
  drm/i915: don't save/restore DP regs for kms
  drm/i915: don't save/restore irq regs for kms
  drm/i915: don't save/restore HWS_PGA reg for kms
  drm/i915/crt: don't set HOTPLUG bits on !PCH
  drm/i915/crt: explicitly set up HOTPLUG_BITS on resume
  drm/i915: don't save/restor ADPA for kms
  drm/i915: unconditionally use mt forcewake on hsw/ivb
  Merge tag 'v3.7-rc2' into drm-intel-next-queued
  drm: rename drm_dp_i2c_helper.c to drm_dp_helper.c
  drm: dp helper: extract drm_dp_channel_eq_ok
  drm: dp helper: extract drm_dp_clock_recovery_ok
  drm: extract helpers to compute new training values from sink request
  drm: extract dp link train delay functions from radeon
  drm/i915: use the new dp train delay helpers
  drm: extract dp link bw helpers
  drm: extract drm_dp_max_lane_count helper
  drm/i915/dp: actually nack test request
  drm/i915: make edp panel power sequence setup more robust
  drm/i915: enable/disable backlight for eDP
  drm/i915/eDP: compute the panel power clock divisor from the pch rawclock
  drm/i915/dp: compute the pch dp aux divider from the rawclk
   

[Bug 56666] New: AMD SUMO GPU lockup when launching any heavy 3D application

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

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

  Priority: medium
Bug ID: 5
  Assignee: dri-devel at lists.freedesktop.org
   Summary: AMD SUMO GPU lockup when launching any heavy 3D
application
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: runetmember at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 69423
  --> https://bugs.freedesktop.org/attachment.cgi?id=69423=edit
AMD SUMO GPU lockup when I launch Unigine Heaven 3

GPU lockup happen for me while launching any heavy 3D application on Radeon HD
6620G. For example GPU lockup 100% reproducible when I launch Unigine Heaven 3
(dmesg attached). It also may happen in web-browser, if browser use rendering
hardware acceleration (for example Firefox with enabled
"layers.acceleration.force-enabled" option).
Lockup is not reproducible when I launch same applications on discrete Radeon
HD 6650M GPU using DRI_PRIME feature, so I guess my issue related to AMD SUMO
GPU's (or maybe to more APU's).

Software:
Kubuntu 12.10 x86_64 updated from Xorg Edgers PPA.
Linux 3.7rc3. With Linux 3.5 and 3.6 is also reproducible,
Mesa: 9.1~git20121029.00e6819e
libdrm-radeon1: git20121025.bc494b31
xserver-xorg-video-radeon: git20120928.e8cb0b72
xserver-xorg-core: 1.13.0+git20120920.70e57668
KDE 4.9.2, desktop effects enabled.

Hardware:
Acer Aspire 7560G laptop, BIOS 2.04,
AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO)
Discrete AMD Radeon HD 6650M (TURKS)

-- 
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/20121102/4d6eddbd/attachment.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #3 from dagg  ---
(In reply to comment #0)
> Created attachment 69420 [details]
> seat 0 config
> 
> I'm running a multiseat setup with 2 radeon (ATI3650HD and ATI5450HD) and 1
> intel cpus, I'm using libdrm, mesa and xf86-video-ati from git on gentoo.
> 
> I'm syncing with the repos every thursday, yesterday I've syned with the
> repos and after boot today, all the screens connected to radeon are black.
> 
> in the sync last thursday everything worked ok, also when downgrading to
> xf86-video-ati-6.14.6, the system works.
> 
> when observing the commit logs on xf86-video-ati of this timeframe, the only
> commit is enabling 2D tiling.

thats gpus instead of cpus, my bad

-- 
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/20121102/8bcbaed4/attachment.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #2 from dagg  ---
xorg logs can be found at http://bpaste.net/show/55347/ (bad boot log) and at
http://bpaste.net/show/55346/ (good boot log)

-- 
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/20121102/dcc21238/attachment.html>

[Bug 56663] 2D tiling commit renders screen black on kdm

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

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

--- Comment #1 from dagg  ---
Created attachment 69421
  --> https://bugs.freedesktop.org/attachment.cgi?id=69421=edit
seat 1 config

-- 
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/20121102/b1355c06/attachment.html>

[Bug 56663] New: 2D tiling commit renders screen black on kdm

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

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

  Priority: medium
Bug ID: 56663
  Assignee: dri-devel at lists.freedesktop.org
   Summary: 2D tiling commit renders screen black on kdm
  Severity: major
Classification: Unclassified
OS: All
  Reporter: stompdagger1 at yahoo.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 69420
  --> https://bugs.freedesktop.org/attachment.cgi?id=69420=edit
seat 0 config

I'm running a multiseat setup with 2 radeon (ATI3650HD and ATI5450HD) and 1
intel cpus, I'm using libdrm, mesa and xf86-video-ati from git on gentoo.

I'm syncing with the repos every thursday, yesterday I've syned with the repos
and after boot today, all the screens connected to radeon are black.

in the sync last thursday everything worked ok, also when downgrading to
xf86-video-ati-6.14.6, the system works.

when observing the commit logs on xf86-video-ati of this timeframe, the only
commit is enabling 2D tiling.

-- 
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/20121102/f41fd7ed/attachment-0001.html>

[PATCH] drm: reduce default drm vblank off delay to 50ms

[Mario Kleiner]

On 30.10.12 20:28, Jesse Barnes wrote:
> On Tue, 30 Oct 2012 20:20:44 +0100
> Daniel Vetter  wrote:
>
>> On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes  
>> wrote:
>>> People keep whining about this, but no one seems to send a patch.  This
>>> *ought* to be safe now that we've dealt with the hw races in Mario's
>>> updated code, and fixed the bugs we know about in VT switch, DPMS, and
>>> multi-head configuraions.
>>>
>>> Signed-off-by: Jesse Barnes 
>>
>> Afaik the fundamental race of enabling the vblank is still there, so
>> this is just duct-tape. And our hw has the required registers (on
>> gen5+ at least) to close this race for real and abolish all "disable
>> vblank irq later to paper over races and smooth things out). Hence I
>> think we should dtrt and so
>>
>> Nacked-by: Daniel Vetter 
>>
>> Also discussed with Jesse on irc, we've had fun ;-)
>
> That's ridiculous.  Just because we have a race we can't fix wrt
> reading hw regs, doesn't mean we can't reduce the timeout.
>
> I nack your nack.
>

Jesse, thanks for cc'ing me, much appreciated :)

Psychtoolbox should be fine with a 50 msecs vblank off delay. I think i 
tested with values somewhere between 50 - 100 msecs at the time the drm 
patches were made. The way i schedule swaps for a specific target time 
'twhen' is to:

1. glXGetSyncValuesOML(msc,ust) as a baseline vblank count and time.
2. Some basic math to calculate targetMSC based on 'twhen' and step 1.
3. glXSwapBuffersMscOML(targetMSC);

So it should tolerate wrong vblank counts due to races, as long as 
vblank doesn't get disabled between 1. and 3. A default vblank off delay 
lower than maybe 1 refresh duration would make me nervous, given that 
most kms drivers are not race-free and it is possible for a userspace 
app or the x-server to get stalled for a couple of msecs.

E.g., radeon wouldn't allow this race-free, because the drm code assumes 
that the hw vblank counter increments at leading edge of vblank, whereas 
radeon hw does it at the traling edge, iirc. nouveau doesn't have any hw 
vblank counter support, so it is "race free" until somebody fixes the 
driver ;-) - ie., it would work with apps that use steps 1/2/3 above, 
but broken for any other app.

More trusting apps could get into more trouble with 50 msecs vs. 5000 
msecs ...

What kind of race in your code do you mean? What does your commit 
message "...now that we've dealt with the hw races in Mario's updated 
code..." refer to?

I remember that Matthew Garret sent out a patch set a couple of months 
ago which aimed to make this configurable per kms driver, so each driver 
could opt into low vblank off delay if it was ready to do it properly. 
That would make a lot of sense.

That said, for the current intel-ddx it wouldn't even matter for X11/GLX 
applications if the kernel returned random numbers instead of vblank 
counts, because the OML_sync_control swap scheduling in the ddx is 
totally broken, and even glXSwapBuffers is a wreck for any swapinterval 
setting except 0 and 1 since triple-buffering was introduced a year ago 
and introduced some bug. Psychtoolbox now detects this since a few 
weeks, prints out critical warnings to the user and tries to work around 
with glXSwapBuffers trickery.

I submitted a patch to fix the rather trivial but nasty bug. Jesse, if 
you find some time, could you review it and convince Chris to merge it?
Should be on the intel-gfx list and in your inbox, a simple . Subject line
"[PATCH 2/3] ddx/dri2: Repair broken pageflip swap scheduling.", sent at 
7 October 2012.

I'll forward it again to you. Chris Wilson already gave me an off-list 
review for that patch series after i pinged him. Unfortunately a rather 
terse one, cited here:

"On Mon, 15 Oct 2012 16:46:52 +0200, Mario Kleiner 
 wrote:
 > Hi Chris,
 >
 > can you please check & merge at least the first two patches of the
 > series into the intel ddx?

The first is along the right path, but I think you want to base the
split on divisor==0. The second is broken in the DRI2 layer, as the
SwapLimit mechanism exposes the multi-client race to a single client
(i.e. there is no serialisation between the InvalidateEvent and the
GetBuffers, and the InvalidateEvent is always broadcast too early.) The
third is just plain wrong, as pageflip may be a blocking ioctl (and will
impose client blocking) so anybody who wants to override SwapBuffersWait
will also want to prevent the inherent wait due to the flip. In any
event that option is to only paper over the loose DRI2 specification and
the lack of client control...
-Chris
"

If i understood the comment wrt. to patch [2/3] "The first is along the 
right path, but I think you want to base the split on divisor==0." 
correctly, then that would be just as broken as the current 
implementation, with some code obfuscation and confusion added, but i 
don't know, maybe i just misunderstood his comment? I asked for 
clarification, but he didn't respond to my followup e-mails. Maybe he 
was just too busy to 

[Bug 56659] New: DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay

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

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

  Priority: medium
Bug ID: 56659
  Assignee: dri-devel at lists.freedesktop.org
   Summary: DRI_PRIME: triangle, rendering inside of which occurs
with a noticeable delay
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: runetmember at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 69414
  --> https://bugs.freedesktop.org/attachment.cgi?id=69414=edit
Example of artifact

Hello!
Please look at attached screenshot - there is triangle where we still see part
of old frame, that was displayed on screen few frames before. I doesn't sure
about terminology, but from my point of view looks like rendering in this
triangle is lag behind rest of the screen.
This issue happen for me only for applications launched with enabled offloading
rendering (DRI_PRIME=1). It's reproducible not only in "Left 4 Dead 2" but also
in other applications. Even in Chromium (if you launch it with
"--ignore-gpu-blacklist" option that enabled hardware rendering on Mesa, and
"DRI_PRIME=1" that enable offloading rendering) display same artifact
(triangle) while scrolling pages. Also you may notice this artifact in
glxgears, if you you run it in fullscreen mode.

Software:
Kubuntu 12.10 x86_64 updated from Xorg Edgers PPA.
Mesa: 9.1~git20121029.00e6819e
libdrm-radeon1: git20121025.bc494b31
xserver-xorg-video-radeon: git20120928.e8cb0b72
xserver-xorg-core: 1.13.0+git20120920.70e57668
Enabled or disabled V-Sync in KWin settings doesn't make the difference.
Enabled or disabled V-Sync in game settings doesn't make the difference.
Screenshot taken with stock Kubuntu kernel (3.5.0-17). With 3.7rc3 kernel issue
still reproducible, but just a bit less noticeable.

Hardware:
Acer Aspire 7560G laptop,
AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO)
Discrete AMD Radeon HD 6650M (TURKS)

"xrandr --listproviders" output:
Providers: number : 2
Provider 0: id: 138 cap: 0xd, Source Output, Source Offload, Sink Offload
crtcs: 2 outputs: 3 associated providers: 1 name:radeon
Provider 1: id: 85 cap: 0xd, Source Output, Source Offload, Sink Offload crtcs:
6 outputs: 0 associated providers: 1 name:radeon

-- 
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/20121102/c1da9e8c/attachment.html>

[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown

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

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

--- Comment #2 from Alexandre Demers  ---
Do you mean it's slower than without the commit or is it running mostly at the
same speed when it's slowing down?

-- 
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/20121102/09bcd562/attachment-0001.html>

[PATCH] Fix nouveau hang after switcheroo

[Daniel J Blueman]

After switcherooing to integrated and starting X, when X fails to start
and causes a console switch, we get hit with a hanger (below). Fix
by checking if we're already in D3.

BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:1703]
 [] nv04_timer_read+0x28/0x70 [nouveau]
 [] nouveau_timer_wait_eq+0x7c/0xe0 [nouveau]
 [] nvd0_sor_dpms+0xde/0x1a0 [nouveau]
 [] ? fb_set_var+0xe9/0x3a0
 [] ? __pte_alloc+0xa9/0x160
 [] ? nvd0_sor_dp_link_set+0x2c0/0x2c0 [nouveau]
 [] drm_helper_connector_dpms+0xbc/0x100 [drm_kms_helper]
 [] drm_fb_helper_dpms.isra.13+0xa5/0xf0 [drm_kms_helper]
 [] drm_fb_helper_blank+0x49/0x80 [drm_kms_helper]
 [] fb_blank+0x56/0xc0
 [] do_fb_ioctl+0x59b/0x5f0
 [] ? vma_interval_tree_insert+0x83/0x90
 [] fb_ioctl+0x45/0x50
 [] do_vfs_ioctl+0x8a/0x340
 [] sys_ioctl+0x91/0xb0

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/nouveau/nvd0_display.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c 
b/drivers/gpu/drm/nouveau/nvd0_display.c
index c402fca..c3285bf 100644
--- a/drivers/gpu/drm/nouveau/nvd0_display.c
+++ b/drivers/gpu/drm/nouveau/nvd0_display.c
@@ -1364,6 +1364,10 @@ nvd0_sor_dpms(struct drm_encoder *encoder, int mode)
int or = nv_encoder->or;
u32 dpms_ctrl;

+   /* prevent hanging after hardware is in D3 */
+   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   return;
+
nv_encoder->last_dpms = mode;

list_for_each_entry(partner, >mode_config.encoder_list, head) {
-- 
1.7.10.4

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #13 from mailbox.tec at gmail.com ---
(In reply to comment #12)
> If they are 32-bit games, you'll hit the same issue.

Not meaning to question your expertise, but would you care to explain: if "wine
requires 32-bit 3D driver" why virtual desktop (i.e. non-fullscreen) mode is
running just fine? In my layman view this would mean wine's perfectly able to
handle the 2D rendering and display on it's part without having to install
32-bit 3D driver (which in my case would require complete switch to closed
source catalyst package and I'm a bit reluctant to do so).

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

[PATCH 46/51] drm/i915: Add support for atomic modesetting completion events

[Daniel Vetter]

On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote:
> On Thu, 1 Nov 2012 19:07:02 +0200
> Ville Syrj?l?  wrote:
> 
> > On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
> > > On Thu, 1 Nov 2012 12:12:35 +0100
> > > Daniel Vetter  wrote:
> > > 
> > > > On Thu, Oct 25, 2012 at 8:05 PM,   
> > > > wrote:
> > > > > From: Ville Syrj?l? 
> > > > >
> > > > > Send completion events when the atomic modesetting operations has
> > > > > finished succesfully.
> > > > >
> > > > > Signed-off-by: Ville Syrj?l? 
> > > > 
> > > > I have to admit I'm not on top of the latest ioctl/interface
> > > > discussion, but one new requirement for the modeset (not the pageflip
> > > > part) of the all this atomic stuff I've discovered is that the kernel
> > > > needs to be able to select the crtcs for each output completely
> > > > unrestricted. I think userspace should simply pass in abstract crtc
> > > > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual
> > > > crtcs it has selected.
> > > > 
> > > > We can't do that remapping internally because the crtc abstraction is 
> > > > leaky:
> > > > - wait_for_vblank requires the pipe id, which could then change on 
> > > > every modeset
> > > > - similarly userspace doing MI_WAIT for scanlines needs to know the
> > > > actual hw pipe in use by a crtc.
> > > > And current userspace presumes that the mapping between crtc->pipe
> > > > doesn't change.
> > > > 
> > > > An example why the kernel needs to pick the crtc for userspace:
> > > > - on ivb only pipe A has a 7x5 panel fitter, so usually you want to
> > > > put the panel on the first crtc
> > > > - but if you run in a 3 pipe configuration and have an eDP panel, it's
> > > > better to put the eDP output on pipe C, since then pipes A will have
> > > > full 4-lane fdi links to the pch ports (instead of otherwise only 2
> > > > lanes each on links B)
> > > > - similarly when we have a 3 pipe configuration with all encoders on
> > > > the pch, we need to move the mode with the highest dotclock to pipe A
> > > > (since that's the only one which will have 4 lanes, pipe B will only
> > > > have 2 each).
> > > > - afaik these kind of asymmetric constraints won't disappear anytime
> > > > soon, haswell definitely still has some.
> > > 
> > > Yeah that's a good point... adding a virtual crtc layer would solve
> > > this and let us preserve the existing ABI.
> > 
> > How would the state handling work? I mean if drm_crtc X currently has
> > some state, drm_crtc Y has some other state, and then we do a modeset
> > which would require swapping the roles of the crtcs, what would happen
> > to the bits of state that we didn't specify?
> > 
> > If we'd do the remapping below the drm crtc layer, the state would
> > always be tied to the drm crtc. But that would definitely require
> > mostly uniform hardware "crtcs" so that the capabilities of the
> > drm_crtcs wouldn't keep changing whenever the remap happens.
> > 
> > Well, I suppose we could tie the state to the virtual crtc instead,
> > and doing an operation on a real drm_crtc would also change the
> > state of the currently bound virtual crtc. And then changing the
> > virtual<->real mapping would just copy the state over from the virtual
> > crtc to the real drm_crtc.
> > 
> > And if we do it for crtcs, then we'd need to do it for planes as well,
> > because the plane<->crtc mapping can be fixed or otherwise limited
> > in some fashion.
> > 
> > Either way it sounds rather messy to me.
> > 
> > Another option would be just leave it up to userspace to make the
> > correct choice between crtcs and planes. But then user space needs
> > to be equipped with more hardware specific knowledge, so it's not
> > a very appealing idea either.
> 
> Yeah it gets ugly one way or another.  From a userspace perspective,
> keeping the ugliness in the kernel is nice, and if we have to do it
> somewhere I guess I'd prefer that.

My tentative Grand Plan (tm) for the atomic modeset implementation of such
things is to pimp the new struct intel_crtc_config to contain all the
configuration state (so with Rob's atomic modeset proposal that would also
embed the drm_crtc_state struct). It would also contain all the derived
state like pll settings, fdi lanes, ...

Now the improve >mode_adjust stage, now called ->compute_config allocates
such a struct for each crtc, does some prep, calls down into
encoder->compute_config callbacks, then applies any fixups and screaming
required to come up with a working global config. All rather hazy, I know
;-)

But e.g. for the above case of trying to squeeze the fdi links into the
available sets of fdi lanes I guess we could first compute the upper bound
for the fdi link requirements (the current wip stuff already pre-computes
the pipe_bpp from the fb->depth). Then check whether that fits, do any
readjustments (I already have a has_pch_encoder attribute, maybe at the
wrong spot still, but we should be able to know which outputs need fdi
links). If 

[PATCH 2/4] drm/doc: integrate crtc helper api into docbook

[Daniel Vetter]

On Thu, Nov 01, 2012 at 03:06:44PM +, Chris Wilson wrote:
> On Thu, 1 Nov 2012 15:49:16 +0100, Jakob Bornecrantz  gmail.com> wrote:
> > On Thu, Nov 1, 2012 at 2:45 PM, Daniel Vetter  
> > wrote:
> > > - Add the missing doc for drm_helper_move_panel_connectors_to_head.
> > > - Fixup any outdated stuff in existing sections. I've only looked at
> > >   those kerneldoc headers that actually resulted in a complaint from
> > >   the kerneldoc parser tool.
> > >
> > > v2:
> > > - Actually include the docbook snippet in the right patch.
> > > - Fix spelling fail.
> > >
> > > v3: It's now called drm_crtc_helper_set_mode, spotted by Laurent
> > > Pinchart.
> > >
> > > Acked-by: Laurent Pinchart 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  Documentation/DocBook/drm.tmpl|  4 +++
> > >  drivers/gpu/drm/drm_crtc_helper.c | 66 
> > > +--
> > >  2 files changed, 46 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/Documentation/DocBook/drm.tmpl 
> > > b/Documentation/DocBook/drm.tmpl
> > > index 270bc12..c2b31b9 100644
> > > --- a/Documentation/DocBook/drm.tmpl
> > > +++ b/Documentation/DocBook/drm.tmpl
> > > @@ -2106,6 +2106,10 @@ void intel_crt_init(struct drm_device *dev)
> > >  
> > >
> > >  
> > > +
> > > +  Modeset Helper Functions Reference
> > > +!Edrivers/gpu/drm/drm_crtc_helper.c
> > > +
> > >
> > >
> > >
> > > diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> > > b/drivers/gpu/drm/drm_crtc_helper.c
> > > index 7105168..2a7a886 100644
> > > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > > @@ -39,6 +39,17 @@
> > >  #include 
> > >  #include 
> > >
> > > +/**
> > > + * drm_helper_move_panel_connectors_to_head() - move panels to the front 
> > > in the
> > > + * connector list
> > > + * @dev: drm device to operate on
> > > + *
> > > + * Some userspace presumes that the first connected connector is the main
> > > + * display, where it's supposed to display e.g. the login screen. For
> > > + * laptops, this should be the main panel. Use this function to sort all
> > > + * (eDP/LVDS) panels to the front of the connector list, instead of
> > > + * painstakingly trying to initialize them in the right order.
> > > + */
> > >  void drm_helper_move_panel_connectors_to_head(struct drm_device *dev)
> > >  {
> > > struct drm_connector *connector, *tmp;
> > > @@ -82,22 +93,21 @@ static void drm_mode_validate_flag(struct 
> > > drm_connector *connector,
> > >
> > >  /**
> > >   * drm_helper_probe_single_connector_modes - get complete set of display 
> > > modes
> > > - * @dev: DRM device
> > > + * @connector: connector to probe
> > >   * @maxX: max width for modes
> > >   * @maxY: max height for modes
> > >   *
> > >   * LOCKING:
> > >   * Caller must hold mode config lock.
> > >   *
> > > - * Based on @dev's mode_config layout, scan all the connectors and try 
> > > to detect
> > > - * modes on them.  Modes will first be added to the connector's 
> > > probed_modes
> > > - * list, then culled (based on validity and the @maxX, @maxY parameters) 
> > > and
> > > - * put into the normal modes list.
> > > - *
> > > - * Intended to be used either at bootup time or when major configuration
> > > - * changes have occurred.
> > > + * Based on the helper callbacks implemented by @connector try to detect 
> > > all
> > > + * valid modes.  Modes will first be added to the connector's 
> > > probed_modes list,
> > > + * then culled (based on validity and the @maxX, @maxY parameters) and 
> > > put into
> > > + * the normal modes list.
> > >   *
> > > - * FIXME: take into account monitor limits
> > 
> > Should this really be removed? I'm guess it has been fixed or is not
> > really needed anymore but just making sure it shouldn't live somewhere
> > else.
> 
> Yes, the modes from an EDID are validated against the limits given by the
> EDID, which is as much information as we have. Higher levels can filter
> the modes based on alternate sources, ofc.
> 
> Granted removing a FIXME should be a separate commit giving good reason
> why it can be considered fixed. (i.e. treat it like the bug it warns
> about of its own right.)

We now call down into the connectors ->mode_valid callback. I've figured
that's about as much checking the helper function here should concern
itself with. Now ofc, most drivers don't bother to trouble themselves with
dotclock limits, but imo that's not a FIXME for the helper code.

And no, adding another common check is imo not the solution, since doing
the full mode checking requires the global configuration anyway ...

I guess I get bad marks for failing to mention that in the commit message
;-)

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

RE: [PATCH] drm: exynos: fix for mapping non contig dma buffers

[Inki Dae]

It's good patch. Right, there was my missing point. I thought each sgl would
always have 4k page. But dma mapping api, dma_alloc_alloc(), allocates
physical memory as continuously as possible so the sgl can have group of
pages.

Below is my comment.


 -Original Message-
 From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
 Sent: Thursday, November 01, 2012 9:35 PM
 To: dri-devel@lists.freedesktop.org
 Cc: sw0312@samsung.com; inki@samsung.com; jy0922.s...@samsung.com;
 kyungmin.p...@samsung.com; prashant...@samsung.com; jo...@samsung.com;
 s.shir...@samsung.com; r.sh.o...@gmail.com; rahul.sha...@samsung.com
 Subject: [PATCH] drm: exynos: fix for mapping non contig dma buffers
 
 This patch fixes the problem of mapping gem objects which are non-
 contigous
 dma buffers. These buffers are described using SG table and SG lists. Each
 valid SG List is pointing to a single page or group of pages which are
 physically contigous.
 
 Current implementation just maps the first page of each SG List and leave
 the other pages unmapped, leading to a crash.
 
 Given solution finds the page struct for all the pages in the SG list and
 map them one by one. This ensures all the pages of current SG list are
 mapped.
 Next SG list of the same buffer will be mapped when page fault occurs for
 the offset belongs to that list.
 
 This patch is based on branch exynos-drm-next-iommu at
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_gem.c |   34
 +++---
  1 files changed, 30 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 index 7057729..d2d6188 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 @@ -95,17 +95,43 @@ static int exynos_drm_gem_map_buf(struct
 drm_gem_object *obj,
  {
   struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
   struct exynos_drm_gem_buf *buf = exynos_gem_obj-buffer;
 + struct scatterlist *sgl;
   unsigned long pfn;
 + unsigned int phys_addr;
 + int ret, i;
 
   if (exynos_gem_obj-flags  EXYNOS_BO_NONCONTIG) {
   if (!buf-pages)
   return -EINTR;

Buf-pages should be checked in all cases. For this, see below comment.

 
 - pfn = page_to_pfn(buf-pages[page_offset++]);
 - } else
 + sgl = buf-sgt-sgl;
 + for_each_sg(buf-sgt-sgl, sgl, buf-sgt-nents, i) {
 + if (page_offset  (sgl-length  PAGE_SHIFT))
 + break;
 + page_offset -=  (sgl-length  PAGE_SHIFT);
 + }
 +
 + if (i = buf-sgt-nents) {
 + DRM_ERROR(invalid page offset\n);
 + return -EINVAL;
 + }
 +
 + phys_addr = sg_phys(sgl);
 +
 + for (i = 0; i  (sgl-length  PAGE_SHIFT); i++) {
 + pfn = __phys_to_pfn(phys_addr + (i  PAGE_SHIFT));
 + ret = vm_insert_mixed(vma, f_vaddr + (i 
PAGE_SHIFT),
 + pfn);
 + if (ret  0) {
 + DRM_ERROR(failed to map page.\n);
 + return ret;
 + }
 + }
 + return 0;
 + } else {
   pfn = (buf-dma_addr  PAGE_SHIFT) + page_offset;

It seems like that you missed EXYNOS_BO_CONTIG type testing. With iommu,
buf-dma_addr has device address but not physical address. So correct it
like below,
pfn = page_to_pfn(buf-pages[0]) + page_offset;

And one more posting? :)

Thanks,
Inki Dae

 -
 - return vm_insert_mixed(vma, f_vaddr, pfn);
 + return vm_insert_mixed(vma, f_vaddr, pfn);
 + }
  }
 
  static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
 --
 1.7.0.4

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