[PATCH 2/2] drm/i915: move panel connectors to the front

[Daniel Vetter]

On Wed, Oct 31, 2012 at 04:05:33PM -0400, Adam Jackson wrote:
> On 10/27/12 9:52 AM, Daniel Vetter wrote:
> >This essentially reverts
> >
> >commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> >Author: Adam Jackson 
> >Date:   Fri Jul 16 14:46:29 2010 -0400
> >
> > drm/i915: Initialize LVDS and eDP outputs before anything else
> >
> >simply because it doesn't scale: It misses SDVO and DVO panels,
> >and now with DDI encoders on haswell this is becoming unmanageable.
> >
> >Instead we simply sort the connector list after everything is
> >set up.
> >
> >Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Adam Jackson 

Slurped both this and the drm helper patch into dinq, thanks for the
review. I'll annoy Dave about including the doc patches into his tree
directly, he should get the pull which has the drm_dp_helper.c rename
tomorrow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v7 3/8] of: add generic videomode description

[Thierry Reding]

On Wed, Oct 31, 2012 at 10:28:03AM +0100, Steffen Trumtrar wrote:
[...]
> +config OF_VIDEOMODE
> + def_bool y
> + depends on VIDEOMODE
> + help
> +   helper to get videomodes from the devicetree
> +

I think patches 3 and 4 need to be swapped, since patch 4 introduces the
VIDEOMODE Kconfig symbol (as well as the videomode.h helper) that patch
3 uses.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121101/2d9c3a8c/attachment.pgp>

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

[Thierry Reding]

On Wed, Oct 31, 2012 at 10:28:02AM +0100, Steffen Trumtrar wrote:
[...]
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt
[...]
> @@ -0,0 +1,139 @@
> +display-timings bindings
> +==
> +
> +display-timings-node
> +

Maybe extend the underline to the length of the section and subsection
titles respectively?

> +struct display_timing
> +===

Same here.

> +config OF_DISPLAY_TIMINGS
> + def_bool y
> + depends on DISPLAY_TIMING

Maybe this should be called OF_DISPLAY_TIMING to match DISPLAY_TIMING,
or rename DISPLAY_TIMING to DISPLAY_TIMINGS for the sake of consistency?

> +/**
> + * of_get_display_timing_list - parse all display_timing entries from a 
> device_node
> + * @np: device_node with the subnodes
> + **/
> +struct display_timings *of_get_display_timing_list(struct device_node *np)

Perhaps this would better be named of_get_display_timings() to match the
return type?

> + disp = kzalloc(sizeof(*disp), GFP_KERNEL);

Shouldn't you be checking this for allocation failures?

> + disp->timings = kzalloc(sizeof(struct display_timing 
> *)*disp->num_timings,
> + GFP_KERNEL);

Same here.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121101/a8c7eb33/attachment.pgp>

[PATCH v7 1/8] video: add display_timing struct and helpers

[Thierry Reding]

On Wed, Oct 31, 2012 at 10:28:01AM +0100, Steffen Trumtrar wrote:
[...]
> +void timings_release(struct display_timings *disp)
> +{
> + int i;
> +
> + for (i = 0; i < disp->num_timings; i++)
> + kfree(disp->timings[i]);
> +}
> +
> +void display_timings_release(struct display_timings *disp)
> +{
> + timings_release(disp);
> + kfree(disp->timings);
> +}

I'm not quite sure I understand how these are supposed to be used. The
only use-case where a struct display_timings is dynamically allocated is
for the OF helpers. In that case, wouldn't it be more useful to have a
function that frees the complete structure, including the struct
display_timings itself? Something like this, which has all of the above
rolled into one:

void display_timings_free(struct display_timings *disp)
{
if (disp->timings) {
unsigned int i;

for (i = 0; i < disp->num_timings; i++)
kfree(disp->timings[i]);
}

kfree(disp->timings);
kfree(disp);
}

Is there a use-case where a struct display_timings is not dynamically
allocated? The only one I can think of is where it is defined as
platform data, but in that case you don't want to be calling
display_timing_release() on it anyway.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121101/ca4e700d/attachment.pgp>

[Bug 51787] performance regression with llvm shader compiler in ut2004

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

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

--- Comment #5 from almos  ---
(In reply to comment #4)
> This is not related to cpufreq. I've fixed my governor to the highest
> frequency and still experience these massive lags.

Since I cerated a startup script for ut2004 that does 'set all cores to
performance ; ut2004 ; set all cores to ondemand' the game runs smoothly
without any lag.

-- 
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/20121101/a0964440/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 #1 from Andy Furniss  ---
I see some slowdowns with etqw (can't test heaven) on HD4890 that seem to be
caused by this.

It's not constant - in fact mostly etqw with current head is the fastest I've
ever seen it.

It may, however, during a short timenetdemo just suddenly drop to 4fps for a
few seconds, or it may start slow ~10fps then go full speed.

With this reverted I haven't seen any slowdowns (yet).

-- 
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/20121101/127a2d8a/attachment.html>

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

[Ville Syrjälä]

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.

-- 
Ville Syrj?l?
Intel OTC

[Bug 51787] performance regression with llvm shader compiler in ut2004

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

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

--- Comment #4 from Tobias Jakobi  ---
This is not related to cpufreq. I've fixed my governor to the highest frequency
and still experience these massive lags.

-- 
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/20121101/53743e20/attachment.html>

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

[Rahul Sharma]

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;

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

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||klausenbusk at hotmail.com

--- Comment #8 from Alex Deucher  ---
*** Bug 56464 has been marked as a duplicate of 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/20121101/1fde61c1/attachment.html>

[Bug 49051] nouveau driver send my laptop to power down

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

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


Reinhard Karcher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 49051] nouveau driver send my laptop to power down

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

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





--- Comment #1 from Reinhard Karcher   2012-11-01 
16:18:43 ---
Using newest kernel from git (1e207eb1c3f0e8b690401f02fe08e7b53903f010), the
problem is gone.
The bug should be closed.

Reinhard

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

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

[Jakob Bornecrantz]

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.

Cheers, Jakob.

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

[Chris Wilson]

On Thu, 1 Nov 2012 15:49:16 +0100, Jakob Bornecrantz  
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.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 4/4] drm/doc: add new dp helpers into drm DocBook

[Daniel Vetter]

I didn't bother with documenting the really trivial new "extract
something from dpcd" helpers, but the i2c over aux ch is now
documented a bit.

v2: Clarify the comment for i2c_dp_aux_add_bus a bit.

v3: Fix more spelling fail spotted by Laurent Pinchart.

Acked-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl  |  6 ++
 drivers/gpu/drm/drm_dp_helper.c | 21 +
 include/drm/drm_dp_helper.h |  8 
 3 files changed, 35 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index fadc48b..6948bad 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2115,6 +2115,12 @@ void intel_crt_init(struct drm_device *dev)
 !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
 !Edrivers/gpu/drm/drm_fb_helper.c
 
+
+  Display Port Helper Functions Reference
+!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
+!Iinclude/drm/drm_dp_helper.h
+!Edrivers/gpu/drm/drm_dp_helper.c
+
   

   
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3c4cccd..89e1966 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -30,6 +30,15 @@
 #include 
 #include 

+/**
+ * DOC: dp helpers
+ *
+ * These functions contain some common logic and helpers at various abstraction
+ * levels to deal with Display Port sink devices and related things like DP aux
+ * channel transfers, EDID reading over DP aux channels, decoding certain DPCD
+ * blocks, ...
+ */
+
 /* Run a single AUX_CH I2C transaction, writing/reading data as necessary */
 static int
 i2c_algo_dp_aux_transaction(struct i2c_adapter *adapter, int mode,
@@ -193,6 +202,18 @@ i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter)
return 0;
 }

+/**
+ * i2c_dp_aux_add_bus() - register an i2c adapter using the aux ch helper
+ * @adapter: i2c adapter to register
+ *
+ * This registers an i2c adapater that uses dp aux channel as it's underlaying
+ * transport. The driver needs to fill out the _algo_dp_aux_data structure
+ * and store it in the algo_data member of the @adapter argument. This will be
+ * used by the i2c over dp aux algorithm to drive the hardware.
+ *
+ * RETURNS:
+ * 0 on success, -ERRNO on failure.
+ */
 int
 i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
 {
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c09d367..e8e1417 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -312,6 +312,14 @@
 #define MODE_I2C_READ  4
 #define MODE_I2C_STOP  8

+/**
+ * struct i2c_algo_dp_aux_data - driver interface structure for i2c over dp
+ *  aux algorithm
+ * @running: set by the algo indicating whether an i2c is ongoing or whether
+ *  the i2c bus is quiescent
+ * @address: i2c target address for the currently ongoing transfer
+ * @aux_ch: driver callback to transfer a single byte of the i2c payload
+ */
 struct i2c_algo_dp_aux_data {
bool running;
u16 address;
-- 
1.7.11.7

[PATCH 3/4] drm/doc: integrate fb helper reference into docs

[Daniel Vetter]

Again only minimal changes to make kerneldoc no longer shout. Plus a
little introduction in the form of a inline DOC: section to quickly
explain what this is all about.

v2: Fixup spelling fail.

Acked-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl  |  5 +
 drivers/gpu/drm/drm_fb_helper.c | 19 ++-
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index c2b31b9..fadc48b 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2110,6 +2110,11 @@ void intel_crt_init(struct drm_device *dev)
   Modeset Helper Functions Reference
 !Edrivers/gpu/drm/drm_crtc_helper.c
 
+
+  fbdev Helper Functions Reference
+!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
+!Edrivers/gpu/drm/drm_fb_helper.c
+
   

   
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4d58d7e..320dcbc 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,7 +41,14 @@ MODULE_AUTHOR("David Airlie, Jesse Barnes");
 MODULE_DESCRIPTION("DRM KMS helper");
 MODULE_LICENSE("GPL and additional rights");

-static LIST_HEAD(kernel_fb_helper_list);
+/**
+ * DOC: fbdev helpers
+ *
+ * The fb helper functions are useful to provide an fbdev on top of a drm 
kernel
+ * mode setting driver. They can be used mostly independantely from the crtc
+ * helper functions used by many drivers to implement the kernel mode setting
+ * interfaces.
+ */

 /* simple single crtc case helper function */
 int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
@@ -1291,12 +1298,14 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper)

 /**
  * drm_helper_initial_config - setup a sane initial connector configuration
- * @dev: DRM device
+ * @fb_helper: fb_helper device struct
+ * @bpp_sel: bpp value to use for the framebuffer configuration
  *
  * LOCKING:
- * Called at init time, must take mode config lock.
+ * Called at init time by the driver to set up the @fb_helper initial
+ * configuration, must take the mode config lock.
  *
- * Scan the CRTCs and connectors and try to put together an initial setup.
+ * Scans the CRTCs and connectors and tries to put together an initial setup.
  * At the moment, this is a cloned configuration across all heads with
  * a new framebuffer object as the backing store.
  *
@@ -1330,7 +1339,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);

 /**
  * drm_fb_helper_hotplug_event - respond to a hotplug notification by
- *   probing all the outputs attached to the fb.
+ *   probing all the outputs attached to the fb
  * @fb_helper: the drm_fb_helper
  *
  * LOCKING:
-- 
1.7.11.7

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

[Daniel Vetter]

- 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
+ * Intended to be use as a generic implementation of the ->probe() @connector
+ * callback for drivers that use the crtc helpers for output mode filtering and
+ * detection.
  *
  * RETURNS:
  * Number of modes found on @connector.
@@ -343,17 +353,24 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
 }

 /**
- * drm_crtc_set_mode - set a mode
+ * drm_crtc_helper_set_mode - internal helper to set a mode
  * @crtc: CRTC to program
  * @mode: mode to use
  * @x: width of mode
  * @y: height of mode
+ * @old_fb: old framebuffer, for cleanup
  *
  * LOCKING:
  * Caller must hold mode config lock.
  *
  * Try to set @mode on @crtc.  Give @crtc and its associated connectors a 
chance
- * to fixup or reject the mode prior to trying to set it.
+ * to fixup or reject the mode prior to trying to set it. This is an internal
+ * helper that drivers could e.g. use to update properties that require the
+ * entire output pipe to be disabled and re-enabled in a new configuration. For
+ * example for changing whether audio is enabled on a hdmi link or for changing
+ * panel fitter or dither attributes. It is also called by the
+ * drm_crtc_helper_set_config() helper function to drive the mode setting
+ * sequence.
  *
  * RETURNS:
  * True if the mode was set successfully, or false otherwise.
@@ -509,20 +526,19 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)

 /**
  * drm_crtc_helper_set_config - set a new config from userspace
- * @crtc: CRTC to setup
- * @crtc_info: user provided configuration
- * @new_mode: new mode to set
- * @connector_set: set of connectors for the new config
- * @fb: new framebuffer
+ * @set: mode set configuration
  *
  * LOCKING:
  * Caller must hold mode config lock.
  *
- * Setup a new configuration, provided by the user in @crtc_info, and enable
- * it.
+ * Setup a new configuration, provided by the upper layers (either an ioctl 
call
+ * from userspace or internally e.g. from the fbdev suppport code) in @set, and
+ * enable it. This is the main helper functions for drivers that 

[PATCH 1/4] drm/doc: Helpers are not a Midlayer!

[Daniel Vetter]

I'm devoting all my wrath to that fight, so don't misname it ;-)

v2: Make it clear that this section talks about kms helpers.

Acked-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index b030052..270bc12 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1621,10 +1621,10 @@ void intel_crt_init(struct drm_device *dev)
 
   

-  
+  

   
-Mid-layer Helper Functions
+Mode Setting Helper Functions
 
   The CRTC, encoder and connector functions provided by the drivers
   implement the DRM API. They're called by the DRM core and ioctl handlers
-- 
1.7.11.7

[PATCH] drm/udl: fix stride issues scanning out stride != width*bpp

[Dave Airlie]

From: Dave Airlie 

When buffer sharing with the i915 and using a 1680x1050 monitor,
the i915 gives is a 6912 buffer for the 6720 width, the code doesn't
render this properly as it uses one value to set the base address for
reading from the vmap and for where to start on the device.

This fixes it by calculating the values correctly for the device and
for the pixmap. No idea how I haven't seen this before now.

Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_drv.h  |  2 +-
 drivers/gpu/drm/udl/udl_fb.c   | 12 +++-
 drivers/gpu/drm/udl/udl_transfer.c |  5 +++--
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index fccd361..87aa5f5 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -104,7 +104,7 @@ udl_fb_user_fb_create(struct drm_device *dev,

 int udl_render_hline(struct drm_device *dev, int bpp, struct urb **urb_ptr,
 const char *front, char **urb_buf_ptr,
-u32 byte_offset, u32 byte_width,
+u32 byte_offset, u32 device_byte_offset, u32 byte_width,
 int *ident_ptr, int *sent_ptr);

 int udl_dumb_create(struct drm_file *file_priv,
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 69a2b16..d4ab3be 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -114,9 +114,10 @@ static void udlfb_dpy_deferred_io(struct fb_info *info,
list_for_each_entry(cur, >pagelist, lru) {

if (udl_render_hline(dev, (ufbdev->ufb.base.bits_per_pixel / 8),
- , (char *) info->fix.smem_start,
- , cur->index << PAGE_SHIFT,
- PAGE_SIZE, _identical, _sent))
+, (char *) info->fix.smem_start,
+, cur->index << PAGE_SHIFT,
+cur->index << PAGE_SHIFT,
+PAGE_SIZE, _identical, _sent))
goto error;
bytes_rendered += PAGE_SIZE;
}
@@ -187,10 +188,11 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
for (i = y; i < y + height ; i++) {
const int line_offset = fb->base.pitches[0] * i;
const int byte_offset = line_offset + (x * bpp);
-
+   const int dev_byte_offset = (fb->base.width * bpp * i) + (x * 
bpp);
if (udl_render_hline(dev, bpp, ,
 (char *) fb->obj->vmapping,
-, byte_offset, width * bpp,
+, byte_offset, dev_byte_offset,
+width * bpp,
 _identical, _sent))
goto error;
}
diff --git a/drivers/gpu/drm/udl/udl_transfer.c 
b/drivers/gpu/drm/udl/udl_transfer.c
index dc09552..142fee5 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -213,11 +213,12 @@ static void udl_compress_hline16(
  */
 int udl_render_hline(struct drm_device *dev, int bpp, struct urb **urb_ptr,
 const char *front, char **urb_buf_ptr,
-u32 byte_offset, u32 byte_width,
+u32 byte_offset, u32 device_byte_offset,
+u32 byte_width,
 int *ident_ptr, int *sent_ptr)
 {
const u8 *line_start, *line_end, *next_pixel;
-   u32 base16 = 0 + (byte_offset / bpp) * 2;
+   u32 base16 = 0 + (device_byte_offset / bpp) * 2;
struct urb *urb = *urb_ptr;
u8 *cmd = *urb_buf_ptr;
u8 *cmd_end = (u8 *) urb->transfer_buffer + urb->transfer_buffer_length;
-- 
1.7.12.1

[PATCH 4/4] drm/doc: add new dp helpers into drm DocBook

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 31 October 2012 10:11:50 Daniel Vetter wrote:
> I didn't bother with documenting the really trivial new "extract
> something from dpcd" helpers, but the i2c over aux ch is now
> documented a bit.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/drm.tmpl  |  6 ++
>  drivers/gpu/drm/drm_dp_helper.c | 20 
>  include/drm/drm_dp_helper.h |  7 +++
>  3 files changed, 33 insertions(+)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 15729eb..71edb57 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2115,6 +2115,12 @@ void intel_crt_init(struct drm_device *dev)
>  !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
>  !Edrivers/gpu/drm/drm_fb_helper.c
>  
> +
> +  Display Port Helper Functions Reference
> +!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
> +!Iinclude/drm/drm_dp_helper.h
> +!Edrivers/gpu/drm/drm_dp_helper.c
> +
>
> 
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 3c4cccd..2ff6482 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -30,6 +30,15 @@
>  #include 
>  #include 
> 
> +/**
> + * DOC: dp helpers
> + *
> + * These functions contain some come logic and helpers at various

s/come/core/

> + * abstraction levels to deal with Display Port sink devices and related
> + * things like DP aux channel transfers, EDID reading over DP aux channels,
> + * decoding certain DPCD blocks, ...
> + */
> +
>  /* Run a single AUX_CH I2C transaction, writing/reading data as necessary
> */ static int
>  i2c_algo_dp_aux_transaction(struct i2c_adapter *adapter, int mode,
> @@ -193,6 +202,17 @@ i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter)
>   return 0;
>  }
> 
> +/**
> + * i2c_dp_aux_add_bus() - register a i2c adaptar using the aux ch helper

s/a i2c adaptar/an I2C adapter/

(feel free to drop the caps if preferred)

> + * @adapter: i2c adapter to register
> + *
> + * This registers an i2c adapater that uses dp aux channel as it's
> + * underlaying transport. The driver needs to fill out the
> + * _algo_dp_aux_data structure which will be used by the the i2c over

s/the the/the/

> + * dp aux algo.

s/algo/algorithm/ ?

> + *
> + * RETURNS:
> + * 0 on success, -ERRNO on failure.
> + */
>  int
>  i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
>  {
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c09d367..3f94ede 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -312,6 +312,13 @@
>  #define MODE_I2C_READ4
>  #define MODE_I2C_STOP8
> 
> +/**
> + * struct i2c_algo_dp_aux_data - driver interface structure for i2c over dp
> + * aux algo

s/algo/algorithm/ ?

> + * @running: set by the algo indicating whether an i2c is ongoing or
> + * whether the i2c bus is quiescent
> + * @address: i2c target address for the currently ongoing transfer
> + * @aux_ch: driver callback to transfer a single byte of the i2c payload
> + */
>  struct i2c_algo_dp_aux_data {
>   bool running;
>   u16 address;
-- 
Regards,

Laurent Pinchart

[PATCH 3/4] drm/doc: integrate fb helper reference into docs

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 31 October 2012 10:11:49 Daniel Vetter wrote:
> Again only minimal changes to make kerneldoc no longer shout. Plus a
> little introduction in the form of a inline DOC: section to quickly
> explain what this is all about.
> 
> Signed-off-by: Daniel Vetter 

With the error below fixed,

Acked-by: Laurent Pinchart 

> ---
>  Documentation/DocBook/drm.tmpl  |  5 +
>  drivers/gpu/drm/drm_fb_helper.c | 19 ++-
>  2 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 43e706e..15729eb 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2110,6 +2110,11 @@ void intel_crt_init(struct drm_device *dev)
>Modeset Helper Functions Reference
>  !Edrivers/gpu/drm/drm_crtc_helper.c
>  
> +
> +  fbdev Helper Functions Reference
> +!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
> +!Edrivers/gpu/drm/drm_fb_helper.c
> +
>
> 
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c index 4d58d7e..b6e9893 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -41,7 +41,14 @@ MODULE_AUTHOR("David Airlie, Jesse Barnes");
>  MODULE_DESCRIPTION("DRM KMS helper");
>  MODULE_LICENSE("GPL and additional rights");
> 
> -static LIST_HEAD(kernel_fb_helper_list);
> +/**
> + * DOC: fbdev helpers
> + *
> + * The fb helper functions are useful to provide an fbdev on top of a drm
> + * kernel mode setting driver. They can be used mostly independantely from
> + * the crtc helper functions used by many drivers to implement the kernel
> + * mode setting interfaces.  static LIST_HEAD(kernel_fb_helper_list).
> + */

Unless you plan to modify the kerneldoc infrastructure to extract code from 
the comments and feed it to the compiler, I'm pretty sure this will break 
compilation ;-)

>  /* simple single crtc case helper function */
>  int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper
> *fb_helper) @@ -1291,12 +1298,14 @@ static void drm_setup_crtcs(struct
> drm_fb_helper *fb_helper)
> 
>  /**
>   * drm_helper_initial_config - setup a sane initial connector configuration
> - * @dev: DRM device
> + * @fb_helper: fb_helper device struct
> + * @bpp_sel: bpp value to use for the framebuffer configuration
>   *
>   * LOCKING:
> - * Called at init time, must take mode config lock.
> + * Called at init time by the driver to set up the @fb_helper initial
> + * configuration, must take mode config lock.
>   *
> - * Scan the CRTCs and connectors and try to put together an initial setup.
> + * Scans the CRTCs and connectors and tries to put together an initial
> + * setup. At the moment, this is a cloned configuration across all heads
> + * with a new framebuffer object as the backing store.
>   *
> @@ -1330,7 +1339,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
> 
>  /**
>   * drm_fb_helper_hotplug_event - respond to a hotplug notification by
> - *   probing all the outputs attached to the
> fb.
> + *   probing all the outputs attached to the fb
>   * @fb_helper: the drm_fb_helper
>   *
>   * LOCKING:

-- 
Regards,

Laurent Pinchart

[git pull] updated exynos-drm-fixes

[Inki Dae]

Hi Dave,

The below patch, "add support for ARCH_MULTIPLATFORM", makes exynos
drm driver to be complied for testing on different ARM DRM devices
without having to switch configs.
For this, you can refer to below link.
http://www.spinics.net/lists/dri-devel/msg29365.html

And this just flags ARCH_MULTIPLATFORM in Kconfig.

Thanks,
Inki Dae

2012/10/31  :
> Hi Dave,
>
> As I posted before, we have added a new git repository for Exynos drm
> to MAINTAINERS file so change it to new one like below,
>from git://git.infradead.org/users/kmpark/linux-samsung
>to git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
>
> And this pull request includes the following:
> - fix display on issue when user requested dpms mode changing.
> - add git repository for Exynos drm to MAINTAINERS file.
> - add support for ARCH_MULTIPLATFORM.
> - and code clean.
>
> If there is any problem, please let me know.
>
> Thanks,
> Inki Dae
>
> The following changes since commit 4936b172d699434547addbe452c2d600ea6a4baf:
>
>   Merge branch 'drm-nouveau-fixes' of 
> git://people.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-10-31 
> 13:46:09 +1000)
>
> are available in the git repository at:
>
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
> exynos-drm-fixes
>
> for you to fetch changes up to 2cdc53b355873ab54b6a348ee5bf022967fb4159:
>
>   drm: exynos: removed warning due to missing typecast for mixer driver data 
> (2012-10-31 06:11:40 -0700)
>
> 
> Inki Dae (2):
>   drm/exynos: fix display on issue
>   MAINTAINERS: Add git repository for Exynos DRM
>
> Rahul Sharma (1):
>   drm: exynos: removed warning due to missing typecast for mixer driver 
> data
>
> Rob Clark (1):
>   drm/exynos: add support for ARCH_MULTIPLATFORM
>
>  MAINTAINERS   |  1 +
>  drivers/gpu/drm/exynos/Kconfig|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |  1 +
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c   | 33 
> ++-
>  drivers/gpu/drm/exynos/exynos_mixer.c |  2 +-
>  5 files changed, 21 insertions(+), 18 deletions(-)

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

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

(text reflowed for review purpose to fit the e-mail line length limit)

On Wednesday 31 October 2012 10:11:48 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.
> 
> Signed-off-by: Daniel Vetter 

After fixing the small mistake below,

Acked-by: Laurent Pinchart 

> ---
>  Documentation/DocBook/drm.tmpl|  4 +++
>  drivers/gpu/drm/drm_crtc_helper.c | 54 
>  2 files changed, 34 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index ca45155..43e706e 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 1021f505..e2e19ef 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -92,22 +92,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
> + * Intended to be use as a generic implementation of the ->probe()
> + * @connector callback for drivers that use the crtc helpers for output
> + * mode filtering and conector detection.
>   *
>   * RETURNS:
>   * Number of modes found on @connector.
> @@ -353,17 +352,23 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
>  }
> 
>  /**
> - * drm_crtc_set_mode - set a mode
> + * drm_crtc_set_mode - internal helper to set a mode

The function is actually now called drm_crtc_helper_set_mode.

>   * @crtc: CRTC to program
>   * @mode: mode to use
>   * @x: width of mode
>   * @y: height of mode
> + * @old_fb: old framebuffer, for cleanup
>   *
>   * LOCKING:
>   * Caller must hold mode config lock.
>   *
>   * Try to set @mode on @crtc.  Give @crtc and its associated connectors a
> - * chance to fixup or reject the mode prior to trying to set it.
> + * chance to fixup or reject the mode prior to trying to set it. This is an
> + * internal helper that drivers could e.g. use to update properties that
> + * require the entire output pipe to be disabled and re-enabled in a new
> + * configuration. For example for changing whether audio is enabled on a
> + * hdmi link or for changing panel fitter or dither attributes. It is also
> + * called by the drm_crtc_helper_set_config() helper function.
>   *
>   * RETURNS:
>   * True if the mode was set successfully, or false otherwise.
> @@ -519,20 +524,19 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
> 
>  /**
>   * drm_crtc_helper_set_config - set a new config from userspace
> - * @crtc: CRTC to setup
> - * @crtc_info: user provided configuration
> - * @new_mode: new mode to set
> - * @connector_set: set of connectors for the new config
> - * @fb: new framebuffer
> + * @set: mode set configuration
>   *
>   * LOCKING:
>   * Caller must hold mode config lock.
>   *
> - * Setup a new configuration, provided by the user in @crtc_info, and
> - * enable it.
> + * Setup a new configuration, provided by the upper layers (either an ioctl
> + * call from userspace or internally e.g. from the fbdev suppport code) in
> + * @set, and enable it. This is the main helper functions for drivers that
> + * implement kernel mode setting with the crtc helper functions and the
> + * assorted ->prepare(), ->modeset() and ->commit() interfaces.
>   *
>   * RETURNS:
> - * Zero. (FIXME)
> + * Returns 0 on success, -ERRNO on failure.
>   */
>  int drm_crtc_helper_set_config(struct drm_mode_set *set)
>  {
> @@ -828,12 +832,14 @@ static int drm_helper_choose_crtc_dpms(struct drm_crtc
> *crtc) }
> 
>  /**
> - * 

[PATCH 1/4] drm/doc: Helpers are not a Midlayer!

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 31 October 2012 10:11:47 Daniel Vetter wrote:
> I'm devoting all my wrath to that fight, so don't misname it ;-)

Right, my bad :-)

> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/drm.tmpl | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index b030052..ca45155 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -1621,10 +1621,10 @@ void intel_crt_init(struct drm_device *dev)
>  
>
> 
> -  
> +  

Do you think we should come up with a more descriptive name ? We have 
different sets of helpers, what would you call this one ? Mode Set Helper 
Functions ?

>
> -Mid-layer Helper Functions
> +Helper Functions
>  
>The CRTC, encoder and connector functions provided by the drivers
>implement the DRM API. They're called by the DRM core and ioctl
> handlers

-- 
Regards,

Laurent Pinchart

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

[Daniel Vetter]

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.

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

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

[Stephen Warren]

On 10/31/2012 03:28 AM, Steffen Trumtrar wrote:

Patch description? The patch defines the DT binding as well, which isn't
mentioned in the patch subject.

> new file mode 100644
> index 000..04c94a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt

> +Usage in backend
> +

Everything before this point in the binding docs looks reasonable to me.
Everything after this point is Linux-specific/internal implementation
detail, and hence shouldn't be in the binding document.

I only read the DT binding.

[PATCH 2/2] drm/i915: lock event_lock for drm_vblank_off()

[Imre Deak]

On Wed, 2012-10-31 at 23:46 +0100, Daniel Vetter wrote:
> On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote:
> > drm_vblank_off() requires callers to hold the event_lock.
> > 
> > Signed-off-by: Imre Deak 
> 
> Hm, do we put this code through its paces already in flip_test by
> scheduling a vblank wait in the future (a second or so), and then
> disabling the display?

There isn't such a test case yet, but this bug is triggered with what we
have already, the 'wait-for-vblank + dpms off' test. But it might make
sense to delay the vblank as you say, in case disabling takes a long
time and the vblank arrives before we get to drm_vblank_off(). I can add
something for that.

--Imre

> -Daniel
> > ---
> >  drivers/gpu/drm/i915/intel_display.c |   15 +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index b453901..56f1119 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3413,6 +3413,7 @@ static void ironlake_crtc_disable(struct drm_crtc 
> > *crtc)
> > struct intel_encoder *encoder;
> > int pipe = intel_crtc->pipe;
> > int plane = intel_crtc->plane;
> > +   unsigned long flags;
> > u32 reg, temp;
> >  
> >  
> > @@ -3423,7 +3424,11 @@ static void ironlake_crtc_disable(struct drm_crtc 
> > *crtc)
> > encoder->disable(encoder);
> >  
> > intel_crtc_wait_for_pending_flips(crtc);
> > +
> > +   spin_lock_irqsave(>event_lock, flags);
> > drm_vblank_off(dev, pipe);
> > +   spin_unlock_irqrestore(>event_lock, flags);
> > +
> > intel_crtc_update_cursor(crtc, false);
> >  
> > intel_disable_plane(dev_priv, plane, pipe);
> > @@ -3495,6 +3500,7 @@ static void haswell_crtc_disable(struct drm_crtc 
> > *crtc)
> > int plane = intel_crtc->plane;
> > enum transcoder cpu_transcoder = intel_crtc->cpu_transcoder;
> > bool is_pch_port;
> > +   unsigned long flags;
> >  
> > if (!intel_crtc->active)
> > return;
> > @@ -3505,7 +3511,11 @@ static void haswell_crtc_disable(struct drm_crtc 
> > *crtc)
> > encoder->disable(encoder);
> >  
> > intel_crtc_wait_for_pending_flips(crtc);
> > +
> > +   spin_lock_irqsave(>event_lock, flags);
> > drm_vblank_off(dev, pipe);
> > +   spin_unlock_irqrestore(>event_lock, flags);
> > +
> > intel_crtc_update_cursor(crtc, false);
> >  
> > intel_disable_plane(dev_priv, plane, pipe);
> > @@ -3617,6 +3627,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
> > struct intel_encoder *encoder;
> > int pipe = intel_crtc->pipe;
> > int plane = intel_crtc->plane;
> > +   unsigned long flags;
> >  
> >  
> > if (!intel_crtc->active)
> > @@ -3627,7 +3638,11 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
> >  
> > /* Give the overlay scaler a chance to disable if it's on this pipe */
> > intel_crtc_wait_for_pending_flips(crtc);
> > +
> > +   spin_lock_irqsave(>event_lock, flags);
> > drm_vblank_off(dev, pipe);
> > +   spin_unlock_irqrestore(>event_lock, flags);
> > +
> > intel_crtc_dpms_overlay(intel_crtc, false);
> > intel_crtc_update_cursor(crtc, false);
> >  
> > -- 
> > 1.7.9.5
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH 1/2] drm: fix order of event_lock wrt. vblank_time_clock

[Imre Deak]

On Thu, 2012-11-01 at 00:03 +0200, Imre Deak wrote:
> drm_vblank_off() requires callers to hold the event_lock, while itself
> locking vbl_time and vblank_time_lock. This defines a dependency chain
> that conflicts with the one in drm_handle_vblank() where we first lock
> vblank_time_lock and then the event_lock. Fix this by reversing the
> locking order in drm_handle_vblank().
>
> This should've triggered a lockdep warning in the exynos driver, the
> rest of the drivers were ok, since they are not using drm_vblank_off(),
> or as in the case of the intel driver were not holding the event_lock
> when calling drm_vblank_off(). This latter issue is addressed in the
> next patch.

I just realized this is better solved by fixing the lock order in the
exynos driver. That way we can take the event_lock close to what it
really locks. Fixing things there will also leave the other drivers
unaffected.

I'll follow up with v2 doing this.

--Imre

> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_irq.c |   32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> Tested with i915, the rest of the drivers should be checked with
> lockdep enabled.
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3a3d0ce..2193d4a 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1236,17 +1236,21 @@ done:
>   return ret;
>  }
>  
> +/**
> + * drm_handle_vblank_events - send pending vblank events
> + * @dev: DRM device
> + * @crtc: crtc where the vblank(s) happened
> + *
> + * Must be called with @dev->event_lock held.
> + */
>  static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
>  {
>   struct drm_pending_vblank_event *e, *t;
>   struct timeval now;
> - unsigned long flags;
>   unsigned int seq;
>  
>   seq = drm_vblank_count_and_time(dev, crtc, );
>  
> - spin_lock_irqsave(>event_lock, flags);
> -
>   list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
>   if (e->pipe != crtc)
>   continue;
> @@ -1266,8 +1270,6 @@ static void drm_handle_vblank_events(struct drm_device 
> *dev, int crtc)
>e->event.sequence);
>   }
>  
> - spin_unlock_irqrestore(>event_lock, flags);
> -
>   trace_drm_vblank_event(crtc, seq);
>  }
>  
> @@ -1285,21 +1287,22 @@ bool drm_handle_vblank(struct drm_device *dev, int 
> crtc)
>   s64 diff_ns;
>   struct timeval tvblank;
>   unsigned long irqflags;
> + bool ret = false;
>  
>   if (!dev->num_crtcs)
>   return false;
>  
> + spin_lock_irqsave(>event_lock, irqflags);
> +
>   /* Need timestamp lock to prevent concurrent execution with
>* vblank enable/disable, as this would cause inconsistent
>* or corrupted timestamps and vblank counts.
>*/
> - spin_lock_irqsave(>vblank_time_lock, irqflags);
> + spin_lock(>vblank_time_lock);
>  
>   /* Vblank irq handling disabled. Nothing to do. */
> - if (!dev->vblank_enabled[crtc]) {
> - spin_unlock_irqrestore(>vblank_time_lock, irqflags);
> - return false;
> - }
> + if (!dev->vblank_enabled[crtc])
> + goto unlock_ret;
>  
>   /* Fetch corresponding timestamp for this vblank interval from
>* driver and store it in proper slot of timestamp ringbuffer.
> @@ -1340,7 +1343,12 @@ bool drm_handle_vblank(struct drm_device *dev, int 
> crtc)
>   DRM_WAKEUP(>vbl_queue[crtc]);
>   drm_handle_vblank_events(dev, crtc);
>  
> - spin_unlock_irqrestore(>vblank_time_lock, irqflags);
> - return true;
> + ret = true;
> +
> +unlock_ret:
> + spin_unlock(>vblank_time_lock);
> + spin_unlock_irqrestore(>event_lock, irqflags);
> +
> + return ret;
>  }
>  EXPORT_SYMBOL(drm_handle_vblank);

[pull] radeon drm-fixes-3.7

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

This request is mostly load detection fixes from Egbert and me.

The following changes since commit 4936b172d699434547addbe452c2d600ea6a4baf:

  Merge branch 'drm-nouveau-fixes' of 
git://people.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-10-31 
13:46:09 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.7

Alex Deucher (1):
  drm/radeon: add load detection support for ext DAC on R200 (v2)

Egbert Eich (6):
  DRM/Radeon: Fix Load Detection on legacy primary DAC.
  DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.
  DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.
  DRM/Radeon: Clean up code in TV DAC load detection.
  DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.
  DRM/radeon: For single CRTC GPUs move handling of CRTC_CRT_ON to 
crtc_dpms().

Igor Murzov (1):
  drm/radeon: fix ATPX function documentation

Peter Senna Tschudin (1):
  drivers/gpu/drm/radeon/evergreen_cs.c: Remove unnecessary semicolon

 drivers/gpu/drm/radeon/evergreen_cs.c   |2 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c|4 +-
 drivers/gpu/drm/radeon/radeon_connectors.c  |   28 +++-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |   15 ++-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  175 +++
 5 files changed, 184 insertions(+), 40 deletions(-)

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

[Laurent Pinchart]

Wrap the header in extern "C" { ... };.

Signed-off-by: Laurent Pinchart 
---
 libkms/libkms.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/libkms/libkms.h b/libkms/libkms.h
index 4664442..c00b159 100644
--- a/libkms/libkms.h
+++ b/libkms/libkms.h
@@ -29,6 +29,10 @@
 #ifndef _LIBKMS_H_
 #define _LIBKMS_H_

+#if defined(__cplusplus) || defined(c_plusplus)
+extern "C" {
+#endif
+
 /**
  * \file
  *
@@ -71,4 +75,8 @@ int kms_bo_map(struct kms_bo *bo, void **out);
 int kms_bo_unmap(struct kms_bo *bo);
 int kms_bo_destroy(struct kms_bo **bo);

+#if defined(__cplusplus) || defined(c_plusplus)
+};
+#endif
+
 #endif
-- 
Regards,

Laurent Pinchart

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

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

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

  Priority: medium
Bug ID: 56634
  Assignee: dri-devel at lists.freedesktop.org
   Summary: r600g: fix abysmal performance in Reaction Quake :
Huge slowdown
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: maxijac at free.fr
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/Gallium/r600
   Product: Mesa

http://cgit.freedesktop.org/mesa/mesa/commit/?id=fa58644855e44830e0b91dc627703c236fa6712a

Huge slowdown in Unigine-heaven (from ~25 fps to ~3 fps)

-- 
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/20121101/2ea29ba3/attachment.html>

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

[Laurent Pinchart]

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 
---
 libkms/api.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libkms/api.c b/libkms/api.c
index 4a05f3d..5befaa0 100644
--- a/libkms/api.c
+++ b/libkms/api.c
@@ -80,7 +80,7 @@ int kms_bo_create(struct kms_driver *kms, const unsigned 
*attr, struct kms_bo **
type = value;
break;
default:
-   return EINVAL;
+   return -EINVAL;
}
}

-- 
Regards,

Laurent Pinchart

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

[Jesse Barnes]

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.

However, we can't always hide hw details like that in the kernel
through generic interfaces (e.g. for sprites and all their
restrictions) so userspace will have to have some knowledge one way or
another, and maybe it's not that bad to push some of the other
limitation knowledge into our userspace code.

Ambivalent.

-- 
Jesse Barnes, Intel Open Source Technology Center

[pull] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Nothing big at all for -fixes, just small stuff:
- Two patches to fix bugs on i830M
- ums regression fixer due to kicking firmeware fbs (Chris)
- tune down a too loud warning (Jani)
- be more careful with sdvo infoframes, which fixes a long-standing
  sdvo-hdmi regression

Cheers, Daniel

The following changes since commit b8e902f24fdd16c4373ddc37a4e150c4afe9c6db:

  drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() (2012-10-23 10:15:21 
+1000)

are available in the git repository at:

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

for you to fetch changes up to 1623392af9da983f3ad088a75076c9da05e5600d:

  drm/i915: Only kick out vesafb if we takeover the fbcon with KMS (2012-10-26 
17:46:35 +0200)


Chris Wilson (1):
  drm/i915: Only kick out vesafb if we takeover the fbcon with KMS

Daniel Vetter (3):
  drm/i915: fix overlay on i830M
  drm/i915: VGA needs to be on pipe A on i830M
  drm/i915: clear the entire sdvo infoframe buffer

Jani Nikula (1):
  drm/i915: be less verbose about inability to provide vendor backlight

 drivers/gpu/drm/i915/i915_dma.c|3 +-
 drivers/gpu/drm/i915/intel_crt.c   |2 +-
 drivers/gpu/drm/i915/intel_overlay.c   |   14 ++--
 drivers/gpu/drm/i915/intel_panel.c |2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   62 +---
 drivers/gpu/drm/i915/intel_sdvo_regs.h |2 ++
 6 files changed, 59 insertions(+), 26 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 56620] r600g: ETQW renders garbage with --enable-r600-llvm-compiler

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

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

--- Comment #5 from Laurent carlier  ---
[lordh at archMain ~]$ /usr/bin/llvm-config32 --version
3.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/20121101/c49ac3e5/attachment.html>

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

[Jesse Barnes]

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.

-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

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

--- Comment #10 from Alexandre Demers  ---
The good news is: the code under resume() is not to be blamed for the lock
after coming back from suspend.

-- 
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/20121101/97755e74/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

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

--- Comment #9 from Alexandre Demers  ---
(In reply to comment #8)
> Created attachment 69370 [details] [review]
> possible fix
> 
> (In reply to comment #7)
> > Alex, would it be possible to print what is going on or if an error occurred
> > in evergreen_mc_stop()?
> > 
> > I see four things that could be going on:
> > 1- we are not using the right path for CAYMAN -> (ASIC_IS_DCE6(rdev));
> 
> cayman is DCE5.  It is using the correct code path.
> 
> > 2- lock mechanism synced with vblank is not working properly;
> 
> Locking makes updates atomic rather than double buffered.
> 
> > 3- all the registers should be locked at the same time, then all modified
> > and finally unlocked together, which is not done with the for loop where we
> > move through each at a time;
> 
> doesn't matter.
> 
> > 4- we are not setting the right registers.
> 
> The existing sequence should be correct.  It's the same sequence our hw team
> recommends.  I can't reproduce this on my cayman boards unfortunately and
> this patch fixes the exact same problem you are having for a number of other
> people :/
> 
> Maybe an issue with the icon or cursor, but I think those should be disabled
> when we disable mem requests in the crtc.  Does this patch help?

Not working either. Also, with 3.7.0-rc3 + this patch, the computer freezes
when coming back from suspend. I see Gnome-Shell for a couple of seconds, then
some garbage and it stops. Kernel 3.6 works fine on that matter. I'll test with
my split patches to see if it is caused by the same commit.

So, pretty much back to square 1, wherever that is.

-- 
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/20121101/ce7d3797/attachment-0001.html>

[PATCH 2/2] drm/i915: lock event_lock for drm_vblank_off()

[Imre Deak]

drm_vblank_off() requires callers to hold the event_lock.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b453901..56f1119 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3413,6 +3413,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
struct intel_encoder *encoder;
int pipe = intel_crtc->pipe;
int plane = intel_crtc->plane;
+   unsigned long flags;
u32 reg, temp;


@@ -3423,7 +3424,11 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
encoder->disable(encoder);

intel_crtc_wait_for_pending_flips(crtc);
+
+   spin_lock_irqsave(>event_lock, flags);
drm_vblank_off(dev, pipe);
+   spin_unlock_irqrestore(>event_lock, flags);
+
intel_crtc_update_cursor(crtc, false);

intel_disable_plane(dev_priv, plane, pipe);
@@ -3495,6 +3500,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
int plane = intel_crtc->plane;
enum transcoder cpu_transcoder = intel_crtc->cpu_transcoder;
bool is_pch_port;
+   unsigned long flags;

if (!intel_crtc->active)
return;
@@ -3505,7 +3511,11 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
encoder->disable(encoder);

intel_crtc_wait_for_pending_flips(crtc);
+
+   spin_lock_irqsave(>event_lock, flags);
drm_vblank_off(dev, pipe);
+   spin_unlock_irqrestore(>event_lock, flags);
+
intel_crtc_update_cursor(crtc, false);

intel_disable_plane(dev_priv, plane, pipe);
@@ -3617,6 +3627,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
struct intel_encoder *encoder;
int pipe = intel_crtc->pipe;
int plane = intel_crtc->plane;
+   unsigned long flags;


if (!intel_crtc->active)
@@ -3627,7 +3638,11 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)

/* Give the overlay scaler a chance to disable if it's on this pipe */
intel_crtc_wait_for_pending_flips(crtc);
+
+   spin_lock_irqsave(>event_lock, flags);
drm_vblank_off(dev, pipe);
+   spin_unlock_irqrestore(>event_lock, flags);
+
intel_crtc_dpms_overlay(intel_crtc, false);
intel_crtc_update_cursor(crtc, false);

-- 
1.7.9.5

[PATCH 1/2] drm: fix order of event_lock wrt. vblank_time_clock

[Imre Deak]

drm_vblank_off() requires callers to hold the event_lock, while itself
locking vbl_time and vblank_time_lock. This defines a dependency chain
that conflicts with the one in drm_handle_vblank() where we first lock
vblank_time_lock and then the event_lock. Fix this by reversing the
locking order in drm_handle_vblank().

This should've triggered a lockdep warning in the exynos driver, the
rest of the drivers were ok, since they are not using drm_vblank_off(),
or as in the case of the intel driver were not holding the event_lock
when calling drm_vblank_off(). This latter issue is addressed in the
next patch.

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

Tested with i915, the rest of the drivers should be checked with
lockdep enabled.

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3a3d0ce..2193d4a 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1236,17 +1236,21 @@ done:
return ret;
 }

+/**
+ * drm_handle_vblank_events - send pending vblank events
+ * @dev: DRM device
+ * @crtc: crtc where the vblank(s) happened
+ *
+ * Must be called with @dev->event_lock held.
+ */
 static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
 {
struct drm_pending_vblank_event *e, *t;
struct timeval now;
-   unsigned long flags;
unsigned int seq;

seq = drm_vblank_count_and_time(dev, crtc, );

-   spin_lock_irqsave(>event_lock, flags);
-
list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
if (e->pipe != crtc)
continue;
@@ -1266,8 +1270,6 @@ static void drm_handle_vblank_events(struct drm_device 
*dev, int crtc)
 e->event.sequence);
}

-   spin_unlock_irqrestore(>event_lock, flags);
-
trace_drm_vblank_event(crtc, seq);
 }

@@ -1285,21 +1287,22 @@ bool drm_handle_vblank(struct drm_device *dev, int crtc)
s64 diff_ns;
struct timeval tvblank;
unsigned long irqflags;
+   bool ret = false;

if (!dev->num_crtcs)
return false;

+   spin_lock_irqsave(>event_lock, irqflags);
+
/* Need timestamp lock to prevent concurrent execution with
 * vblank enable/disable, as this would cause inconsistent
 * or corrupted timestamps and vblank counts.
 */
-   spin_lock_irqsave(>vblank_time_lock, irqflags);
+   spin_lock(>vblank_time_lock);

/* Vblank irq handling disabled. Nothing to do. */
-   if (!dev->vblank_enabled[crtc]) {
-   spin_unlock_irqrestore(>vblank_time_lock, irqflags);
-   return false;
-   }
+   if (!dev->vblank_enabled[crtc])
+   goto unlock_ret;

/* Fetch corresponding timestamp for this vblank interval from
 * driver and store it in proper slot of timestamp ringbuffer.
@@ -1340,7 +1343,12 @@ bool drm_handle_vblank(struct drm_device *dev, int crtc)
DRM_WAKEUP(>vbl_queue[crtc]);
drm_handle_vblank_events(dev, crtc);

-   spin_unlock_irqrestore(>vblank_time_lock, irqflags);
-   return true;
+   ret = true;
+
+unlock_ret:
+   spin_unlock(>vblank_time_lock);
+   spin_unlock_irqrestore(>event_lock, irqflags);
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_handle_vblank);
-- 
1.7.9.5

[PATCH 2/2] drm/i915: lock event_lock for drm_vblank_off()

[Daniel Vetter]

On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote:
> drm_vblank_off() requires callers to hold the event_lock.
> 
> Signed-off-by: Imre Deak 

Hm, do we put this code through its paces already in flip_test by
scheduling a vblank wait in the future (a second or so), and then
disabling the display?
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b453901..56f1119 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3413,6 +3413,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
>   struct intel_encoder *encoder;
>   int pipe = intel_crtc->pipe;
>   int plane = intel_crtc->plane;
> + unsigned long flags;
>   u32 reg, temp;
>  
>  
> @@ -3423,7 +3424,11 @@ static void ironlake_crtc_disable(struct drm_crtc 
> *crtc)
>   encoder->disable(encoder);
>  
>   intel_crtc_wait_for_pending_flips(crtc);
> +
> + spin_lock_irqsave(>event_lock, flags);
>   drm_vblank_off(dev, pipe);
> + spin_unlock_irqrestore(>event_lock, flags);
> +
>   intel_crtc_update_cursor(crtc, false);
>  
>   intel_disable_plane(dev_priv, plane, pipe);
> @@ -3495,6 +3500,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
>   int plane = intel_crtc->plane;
>   enum transcoder cpu_transcoder = intel_crtc->cpu_transcoder;
>   bool is_pch_port;
> + unsigned long flags;
>  
>   if (!intel_crtc->active)
>   return;
> @@ -3505,7 +3511,11 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
>   encoder->disable(encoder);
>  
>   intel_crtc_wait_for_pending_flips(crtc);
> +
> + spin_lock_irqsave(>event_lock, flags);
>   drm_vblank_off(dev, pipe);
> + spin_unlock_irqrestore(>event_lock, flags);
> +
>   intel_crtc_update_cursor(crtc, false);
>  
>   intel_disable_plane(dev_priv, plane, pipe);
> @@ -3617,6 +3627,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
>   struct intel_encoder *encoder;
>   int pipe = intel_crtc->pipe;
>   int plane = intel_crtc->plane;
> + unsigned long flags;
>  
>  
>   if (!intel_crtc->active)
> @@ -3627,7 +3638,11 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
>  
>   /* Give the overlay scaler a chance to disable if it's on this pipe */
>   intel_crtc_wait_for_pending_flips(crtc);
> +
> + spin_lock_irqsave(>event_lock, flags);
>   drm_vblank_off(dev, pipe);
> + spin_unlock_irqrestore(>event_lock, flags);
> +
>   intel_crtc_dpms_overlay(intel_crtc, false);
>   intel_crtc_update_cursor(crtc, false);
>  
> -- 
> 1.7.9.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [git pull] updated exynos-drm-fixes

[Inki Dae]

Hi Dave,

The below patch, add support for ARCH_MULTIPLATFORM, makes exynos
drm driver to be complied for testing on different ARM DRM devices
without having to switch configs.
For this, you can refer to below link.
http://www.spinics.net/lists/dri-devel/msg29365.html

And this just flags ARCH_MULTIPLATFORM in Kconfig.

Thanks,
Inki Dae

2012/10/31  inki@samsung.com:
 Hi Dave,

 As I posted before, we have added a new git repository for Exynos drm
 to MAINTAINERS file so change it to new one like below,
from git://git.infradead.org/users/kmpark/linux-samsung
to git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos

 And this pull request includes the following:
 - fix display on issue when user requested dpms mode changing.
 - add git repository for Exynos drm to MAINTAINERS file.
 - add support for ARCH_MULTIPLATFORM.
 - and code clean.

 If there is any problem, please let me know.

 Thanks,
 Inki Dae

 The following changes since commit 4936b172d699434547addbe452c2d600ea6a4baf:

   Merge branch 'drm-nouveau-fixes' of 
 git://people.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-10-31 
 13:46:09 +1000)

 are available in the git repository at:


   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
 exynos-drm-fixes

 for you to fetch changes up to 2cdc53b355873ab54b6a348ee5bf022967fb4159:

   drm: exynos: removed warning due to missing typecast for mixer driver data 
 (2012-10-31 06:11:40 -0700)

 
 Inki Dae (2):
   drm/exynos: fix display on issue
   MAINTAINERS: Add git repository for Exynos DRM

 Rahul Sharma (1):
   drm: exynos: removed warning due to missing typecast for mixer driver 
 data

 Rob Clark (1):
   drm/exynos: add support for ARCH_MULTIPLATFORM

  MAINTAINERS   |  1 +
  drivers/gpu/drm/exynos/Kconfig|  2 +-
  drivers/gpu/drm/exynos/exynos_drm_connector.c |  1 +
  drivers/gpu/drm/exynos/exynos_drm_encoder.c   | 33 
 ++-
  drivers/gpu/drm/exynos/exynos_mixer.c |  2 +-
  5 files changed, 21 insertions(+), 18 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/udl: fix stride issues scanning out stride != width*bpp

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

When buffer sharing with the i915 and using a 1680x1050 monitor,
the i915 gives is a 6912 buffer for the 6720 width, the code doesn't
render this properly as it uses one value to set the base address for
reading from the vmap and for where to start on the device.

This fixes it by calculating the values correctly for the device and
for the pixmap. No idea how I haven't seen this before now.

Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/udl/udl_drv.h  |  2 +-
 drivers/gpu/drm/udl/udl_fb.c   | 12 +++-
 drivers/gpu/drm/udl/udl_transfer.c |  5 +++--
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index fccd361..87aa5f5 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -104,7 +104,7 @@ udl_fb_user_fb_create(struct drm_device *dev,
 
 int udl_render_hline(struct drm_device *dev, int bpp, struct urb **urb_ptr,
 const char *front, char **urb_buf_ptr,
-u32 byte_offset, u32 byte_width,
+u32 byte_offset, u32 device_byte_offset, u32 byte_width,
 int *ident_ptr, int *sent_ptr);
 
 int udl_dumb_create(struct drm_file *file_priv,
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 69a2b16..d4ab3be 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -114,9 +114,10 @@ static void udlfb_dpy_deferred_io(struct fb_info *info,
list_for_each_entry(cur, fbdefio-pagelist, lru) {
 
if (udl_render_hline(dev, (ufbdev-ufb.base.bits_per_pixel / 8),
- urb, (char *) info-fix.smem_start,
- cmd, cur-index  PAGE_SHIFT,
- PAGE_SIZE, bytes_identical, bytes_sent))
+urb, (char *) info-fix.smem_start,
+cmd, cur-index  PAGE_SHIFT,
+cur-index  PAGE_SHIFT,
+PAGE_SIZE, bytes_identical, bytes_sent))
goto error;
bytes_rendered += PAGE_SIZE;
}
@@ -187,10 +188,11 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
for (i = y; i  y + height ; i++) {
const int line_offset = fb-base.pitches[0] * i;
const int byte_offset = line_offset + (x * bpp);
-
+   const int dev_byte_offset = (fb-base.width * bpp * i) + (x * 
bpp);
if (udl_render_hline(dev, bpp, urb,
 (char *) fb-obj-vmapping,
-cmd, byte_offset, width * bpp,
+cmd, byte_offset, dev_byte_offset,
+width * bpp,
 bytes_identical, bytes_sent))
goto error;
}
diff --git a/drivers/gpu/drm/udl/udl_transfer.c 
b/drivers/gpu/drm/udl/udl_transfer.c
index dc09552..142fee5 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -213,11 +213,12 @@ static void udl_compress_hline16(
  */
 int udl_render_hline(struct drm_device *dev, int bpp, struct urb **urb_ptr,
 const char *front, char **urb_buf_ptr,
-u32 byte_offset, u32 byte_width,
+u32 byte_offset, u32 device_byte_offset,
+u32 byte_width,
 int *ident_ptr, int *sent_ptr)
 {
const u8 *line_start, *line_end, *next_pixel;
-   u32 base16 = 0 + (byte_offset / bpp) * 2;
+   u32 base16 = 0 + (device_byte_offset / bpp) * 2;
struct urb *urb = *urb_ptr;
u8 *cmd = *urb_buf_ptr;
u8 *cmd_end = (u8 *) urb-transfer_buffer + urb-transfer_buffer_length;
-- 
1.7.12.1

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

RE: [PATCH v7 5/8] fbmon: add videomode helpers

[Manjunathappa, Prakash]

Hi Steffen,

On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
 Add a function to convert from the generic videomode to a fb_videomode.
 
 Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
 ---
  drivers/video/fbmon.c |   36 
  include/linux/fb.h|2 ++
  2 files changed, 38 insertions(+)
 
 diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
 index cef6557..b9e6ab3 100644
 --- a/drivers/video/fbmon.c
 +++ b/drivers/video/fbmon.c
 @@ -1373,6 +1373,42 @@ int fb_get_mode(int flags, u32 val, struct 
 fb_var_screeninfo *var, struct fb_inf
   kfree(timings);
   return err;
  }
 +
 +#if IS_ENABLED(CONFIG_VIDEOMODE)
 +int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode 
 *fbmode)
 +{
 + fbmode-xres = vm-hactive;
 + fbmode-left_margin = vm-hback_porch;
 + fbmode-right_margin = vm-hfront_porch;
 + fbmode-hsync_len = vm-hsync_len;
 +
 + fbmode-yres = vm-vactive;
 + fbmode-upper_margin = vm-vback_porch;
 + fbmode-lower_margin = vm-vfront_porch;
 + fbmode-vsync_len = vm-vsync_len;
 +
 + fbmode-pixclock = KHZ2PICOS(vm-pixelclock / 1000);
 +
 + fbmode-sync = 0;
 + fbmode-vmode = 0;
 + if (vm-hah)
 + fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
 + if (vm-vah)
 + fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
 + if (vm-interlaced)
 + fbmode-vmode |= FB_VMODE_INTERLACED;
 + if (vm-doublescan)
 + fbmode-vmode |= FB_VMODE_DOUBLE;
 +

pixelclk-inverted property of the panel is not percolated fb_videomode.
Please let me know if I am missing something.

Thanks,
Prakash

 + fbmode-refresh = 60;
 + fbmode-flag = 0;
 +
 + return 0;
 +}
 +EXPORT_SYMBOL_GPL(videomode_to_fb_videomode);
 +#endif
 +
 +
  #else
  int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
  {
 diff --git a/include/linux/fb.h b/include/linux/fb.h
 index c7a9571..46c665b 100644
 --- a/include/linux/fb.h
 +++ b/include/linux/fb.h
 @@ -714,6 +714,8 @@ extern void fb_destroy_modedb(struct fb_videomode 
 *modedb);
  extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
  extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
  
 +extern int videomode_to_fb_videomode(struct videomode *vm, struct 
 fb_videomode *fbmode);
 +
  /* drivers/video/modedb.c */
  #define VESA_MODEDB_SIZE 34
  extern void fb_var_to_videomode(struct fb_videomode *mode,
 -- 
 1.7.10.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-fbdev in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

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

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

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

--- Comment #10 from Alexandre Demers alexandre.f.dem...@gmail.com ---
The good news is: the code under resume() is not to be blamed for the lock
after coming back from suspend.

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

[Bug 56620] r600g: ETQW renders garbage with --enable-r600-llvm-compiler

[bugzilla-daemon]

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

--- Comment #5 from Laurent carlier lordhea...@gmail.com ---
[lordh@archMain ~]$ /usr/bin/llvm-config32 --version
3.1

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

[pull] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Nothing big at all for -fixes, just small stuff:
- Two patches to fix bugs on i830M
- ums regression fixer due to kicking firmeware fbs (Chris)
- tune down a too loud warning (Jani)
- be more careful with sdvo infoframes, which fixes a long-standing
  sdvo-hdmi regression

Cheers, Daniel

The following changes since commit b8e902f24fdd16c4373ddc37a4e150c4afe9c6db:

  drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() (2012-10-23 10:15:21 
+1000)

are available in the git repository at:

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

for you to fetch changes up to 1623392af9da983f3ad088a75076c9da05e5600d:

  drm/i915: Only kick out vesafb if we takeover the fbcon with KMS (2012-10-26 
17:46:35 +0200)


Chris Wilson (1):
  drm/i915: Only kick out vesafb if we takeover the fbcon with KMS

Daniel Vetter (3):
  drm/i915: fix overlay on i830M
  drm/i915: VGA needs to be on pipe A on i830M
  drm/i915: clear the entire sdvo infoframe buffer

Jani Nikula (1):
  drm/i915: be less verbose about inability to provide vendor backlight

 drivers/gpu/drm/i915/i915_dma.c|3 +-
 drivers/gpu/drm/i915/intel_crt.c   |2 +-
 drivers/gpu/drm/i915/intel_overlay.c   |   14 ++--
 drivers/gpu/drm/i915/intel_panel.c |2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   62 +---
 drivers/gpu/drm/i915/intel_sdvo_regs.h |2 ++
 6 files changed, 59 insertions(+), 26 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: fix order of event_lock wrt. vblank_time_clock

[Imre Deak]

On Thu, 2012-11-01 at 00:03 +0200, Imre Deak wrote:
 drm_vblank_off() requires callers to hold the event_lock, while itself
 locking vbl_time and vblank_time_lock. This defines a dependency chain
 that conflicts with the one in drm_handle_vblank() where we first lock
 vblank_time_lock and then the event_lock. Fix this by reversing the
 locking order in drm_handle_vblank().

 This should've triggered a lockdep warning in the exynos driver, the
 rest of the drivers were ok, since they are not using drm_vblank_off(),
 or as in the case of the intel driver were not holding the event_lock
 when calling drm_vblank_off(). This latter issue is addressed in the
 next patch.

I just realized this is better solved by fixing the lock order in the
exynos driver. That way we can take the event_lock close to what it
really locks. Fixing things there will also leave the other drivers
unaffected.

I'll follow up with v2 doing this.

--Imre

 
 Signed-off-by: Imre Deak imre.d...@intel.com
 ---
  drivers/gpu/drm/drm_irq.c |   32 
  1 file changed, 20 insertions(+), 12 deletions(-)
 
 Tested with i915, the rest of the drivers should be checked with
 lockdep enabled.
 
 diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
 index 3a3d0ce..2193d4a 100644
 --- a/drivers/gpu/drm/drm_irq.c
 +++ b/drivers/gpu/drm/drm_irq.c
 @@ -1236,17 +1236,21 @@ done:
   return ret;
  }
  
 +/**
 + * drm_handle_vblank_events - send pending vblank events
 + * @dev: DRM device
 + * @crtc: crtc where the vblank(s) happened
 + *
 + * Must be called with @dev-event_lock held.
 + */
  static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
  {
   struct drm_pending_vblank_event *e, *t;
   struct timeval now;
 - unsigned long flags;
   unsigned int seq;
  
   seq = drm_vblank_count_and_time(dev, crtc, now);
  
 - spin_lock_irqsave(dev-event_lock, flags);
 -
   list_for_each_entry_safe(e, t, dev-vblank_event_list, base.link) {
   if (e-pipe != crtc)
   continue;
 @@ -1266,8 +1270,6 @@ static void drm_handle_vblank_events(struct drm_device 
 *dev, int crtc)
e-event.sequence);
   }
  
 - spin_unlock_irqrestore(dev-event_lock, flags);
 -
   trace_drm_vblank_event(crtc, seq);
  }
  
 @@ -1285,21 +1287,22 @@ bool drm_handle_vblank(struct drm_device *dev, int 
 crtc)
   s64 diff_ns;
   struct timeval tvblank;
   unsigned long irqflags;
 + bool ret = false;
  
   if (!dev-num_crtcs)
   return false;
  
 + spin_lock_irqsave(dev-event_lock, irqflags);
 +
   /* Need timestamp lock to prevent concurrent execution with
* vblank enable/disable, as this would cause inconsistent
* or corrupted timestamps and vblank counts.
*/
 - spin_lock_irqsave(dev-vblank_time_lock, irqflags);
 + spin_lock(dev-vblank_time_lock);
  
   /* Vblank irq handling disabled. Nothing to do. */
 - if (!dev-vblank_enabled[crtc]) {
 - spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
 - return false;
 - }
 + if (!dev-vblank_enabled[crtc])
 + goto unlock_ret;
  
   /* Fetch corresponding timestamp for this vblank interval from
* driver and store it in proper slot of timestamp ringbuffer.
 @@ -1340,7 +1343,12 @@ bool drm_handle_vblank(struct drm_device *dev, int 
 crtc)
   DRM_WAKEUP(dev-vbl_queue[crtc]);
   drm_handle_vblank_events(dev, crtc);
  
 - spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
 - return true;
 + ret = true;
 +
 +unlock_ret:
 + spin_unlock(dev-vblank_time_lock);
 + spin_unlock_irqrestore(dev-event_lock, irqflags);
 +
 + return ret;
  }
  EXPORT_SYMBOL(drm_handle_vblank);


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

Re: [PATCH 2/2] drm/i915: lock event_lock for drm_vblank_off()

[Imre Deak]

On Wed, 2012-10-31 at 23:46 +0100, Daniel Vetter wrote:
 On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote:
  drm_vblank_off() requires callers to hold the event_lock.
  
  Signed-off-by: Imre Deak imre.d...@intel.com
 
 Hm, do we put this code through its paces already in flip_test by
 scheduling a vblank wait in the future (a second or so), and then
 disabling the display?

There isn't such a test case yet, but this bug is triggered with what we
have already, the 'wait-for-vblank + dpms off' test. But it might make
sense to delay the vblank as you say, in case disabling takes a long
time and the vblank arrives before we get to drm_vblank_off(). I can add
something for that.

--Imre

 -Daniel
  ---
   drivers/gpu/drm/i915/intel_display.c |   15 +++
   1 file changed, 15 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index b453901..56f1119 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -3413,6 +3413,7 @@ static void ironlake_crtc_disable(struct drm_crtc 
  *crtc)
  struct intel_encoder *encoder;
  int pipe = intel_crtc-pipe;
  int plane = intel_crtc-plane;
  +   unsigned long flags;
  u32 reg, temp;
   
   
  @@ -3423,7 +3424,11 @@ static void ironlake_crtc_disable(struct drm_crtc 
  *crtc)
  encoder-disable(encoder);
   
  intel_crtc_wait_for_pending_flips(crtc);
  +
  +   spin_lock_irqsave(dev-event_lock, flags);
  drm_vblank_off(dev, pipe);
  +   spin_unlock_irqrestore(dev-event_lock, flags);
  +
  intel_crtc_update_cursor(crtc, false);
   
  intel_disable_plane(dev_priv, plane, pipe);
  @@ -3495,6 +3500,7 @@ static void haswell_crtc_disable(struct drm_crtc 
  *crtc)
  int plane = intel_crtc-plane;
  enum transcoder cpu_transcoder = intel_crtc-cpu_transcoder;
  bool is_pch_port;
  +   unsigned long flags;
   
  if (!intel_crtc-active)
  return;
  @@ -3505,7 +3511,11 @@ static void haswell_crtc_disable(struct drm_crtc 
  *crtc)
  encoder-disable(encoder);
   
  intel_crtc_wait_for_pending_flips(crtc);
  +
  +   spin_lock_irqsave(dev-event_lock, flags);
  drm_vblank_off(dev, pipe);
  +   spin_unlock_irqrestore(dev-event_lock, flags);
  +
  intel_crtc_update_cursor(crtc, false);
   
  intel_disable_plane(dev_priv, plane, pipe);
  @@ -3617,6 +3627,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
  struct intel_encoder *encoder;
  int pipe = intel_crtc-pipe;
  int plane = intel_crtc-plane;
  +   unsigned long flags;
   
   
  if (!intel_crtc-active)
  @@ -3627,7 +3638,11 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
   
  /* Give the overlay scaler a chance to disable if it's on this pipe */
  intel_crtc_wait_for_pending_flips(crtc);
  +
  +   spin_lock_irqsave(dev-event_lock, flags);
  drm_vblank_off(dev, pipe);
  +   spin_unlock_irqrestore(dev-event_lock, flags);
  +
  intel_crtc_dpms_overlay(intel_crtc, false);
  intel_crtc_update_cursor(crtc, false);
   
  -- 
  1.7.9.5
  
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
 


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

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

[Laurent Pinchart]

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 laurent.pinch...@ideasonboard.com
---
 libkms/api.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libkms/api.c b/libkms/api.c
index 4a05f3d..5befaa0 100644
--- a/libkms/api.c
+++ b/libkms/api.c
@@ -80,7 +80,7 @@ int kms_bo_create(struct kms_driver *kms, const unsigned 
*attr, struct kms_bo **
type = value;
break;
default:
-   return EINVAL;
+   return -EINVAL;
}
}
 
-- 
Regards,

Laurent Pinchart

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

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

[Laurent Pinchart]

Wrap the header in extern C { ... };.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 libkms/libkms.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/libkms/libkms.h b/libkms/libkms.h
index 4664442..c00b159 100644
--- a/libkms/libkms.h
+++ b/libkms/libkms.h
@@ -29,6 +29,10 @@
 #ifndef _LIBKMS_H_
 #define _LIBKMS_H_
 
+#if defined(__cplusplus) || defined(c_plusplus)
+extern C {
+#endif
+
 /**
  * \file
  *
@@ -71,4 +75,8 @@ int kms_bo_map(struct kms_bo *bo, void **out);
 int kms_bo_unmap(struct kms_bo *bo);
 int kms_bo_destroy(struct kms_bo **bo);
 
+#if defined(__cplusplus) || defined(c_plusplus)
+};
+#endif
+
 #endif
-- 
Regards,

Laurent Pinchart

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

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

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 56634
  Assignee: dri-devel@lists.freedesktop.org
   Summary: r600g: fix abysmal performance in Reaction Quake :
Huge slowdown
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: maxi...@free.fr
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/Gallium/r600
   Product: Mesa

http://cgit.freedesktop.org/mesa/mesa/commit/?id=fa58644855e44830e0b91dc627703c236fa6712a

Huge slowdown in Unigine-heaven (from ~25 fps to ~3 fps)

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

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

[Daniel Vetter]

On Thu, Oct 25, 2012 at 8:05 PM,  ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com

 Send completion events when the atomic modesetting operations has
 finished succesfully.

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

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 AB will have
full 4-lane fdi links to the pch ports (instead of otherwise only 2
lanes each on links BC)
- 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 BC will only
have 2 each).
- afaik these kind of asymmetric constraints won't disappear anytime
soon, haswell definitely still has some.

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

Re: [PATCH 1/4] drm/doc: Helpers are not a Midlayer!

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 31 October 2012 10:11:47 Daniel Vetter wrote:
 I'm devoting all my wrath to that fight, so don't misname it ;-)

Right, my bad :-)

 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  Documentation/DocBook/drm.tmpl | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index b030052..ca45155 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -1621,10 +1621,10 @@ void intel_crt_init(struct drm_device *dev)
  /sect2
/sect1
 
 -  !-- Internals: mid-layer helper functions --
 +  !-- Internals: helper functions --

Do you think we should come up with a more descriptive name ? We have 
different sets of helpers, what would you call this one ? Mode Set Helper 
Functions ?

sect1
 -titleMid-layer Helper Functions/title
 +titleHelper Functions/title
  para
The CRTC, encoder and connector functions provided by the drivers
implement the DRM API. They're called by the DRM core and ioctl
 handlers

-- 
Regards,

Laurent Pinchart

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

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

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

(text reflowed for review purpose to fit the e-mail line length limit)

On Wednesday 31 October 2012 10:11:48 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.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

After fixing the small mistake below,

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  Documentation/DocBook/drm.tmpl|  4 +++
  drivers/gpu/drm/drm_crtc_helper.c | 54 
  2 files changed, 34 insertions(+), 24 deletions(-)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index ca45155..43e706e 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2106,6 +2106,10 @@ void intel_crt_init(struct drm_device *dev)
  /listitem
/itemizedlist
  /sect2
 +sect2
 +  titleModeset Helper Functions Reference/title
 +!Edrivers/gpu/drm/drm_crtc_helper.c
 +/sect2
/sect1
 
!-- Internals: vertical blanking --
 diff --git a/drivers/gpu/drm/drm_crtc_helper.c
 b/drivers/gpu/drm/drm_crtc_helper.c index 1021f505..e2e19ef 100644
 --- a/drivers/gpu/drm/drm_crtc_helper.c
 +++ b/drivers/gpu/drm/drm_crtc_helper.c
 @@ -92,22 +92,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
 + * Intended to be use as a generic implementation of the -probe()
 + * @connector callback for drivers that use the crtc helpers for output
 + * mode filtering and conector detection.
   *
   * RETURNS:
   * Number of modes found on @connector.
 @@ -353,17 +352,23 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
  }
 
  /**
 - * drm_crtc_set_mode - set a mode
 + * drm_crtc_set_mode - internal helper to set a mode

The function is actually now called drm_crtc_helper_set_mode.

   * @crtc: CRTC to program
   * @mode: mode to use
   * @x: width of mode
   * @y: height of mode
 + * @old_fb: old framebuffer, for cleanup
   *
   * LOCKING:
   * Caller must hold mode config lock.
   *
   * Try to set @mode on @crtc.  Give @crtc and its associated connectors a
 - * chance to fixup or reject the mode prior to trying to set it.
 + * chance to fixup or reject the mode prior to trying to set it. This is an
 + * internal helper that drivers could e.g. use to update properties that
 + * require the entire output pipe to be disabled and re-enabled in a new
 + * configuration. For example for changing whether audio is enabled on a
 + * hdmi link or for changing panel fitter or dither attributes. It is also
 + * called by the drm_crtc_helper_set_config() helper function.
   *
   * RETURNS:
   * True if the mode was set successfully, or false otherwise.
 @@ -519,20 +524,19 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
 
  /**
   * drm_crtc_helper_set_config - set a new config from userspace
 - * @crtc: CRTC to setup
 - * @crtc_info: user provided configuration
 - * @new_mode: new mode to set
 - * @connector_set: set of connectors for the new config
 - * @fb: new framebuffer
 + * @set: mode set configuration
   *
   * LOCKING:
   * Caller must hold mode config lock.
   *
 - * Setup a new configuration, provided by the user in @crtc_info, and
 - * enable it.
 + * Setup a new configuration, provided by the upper layers (either an ioctl
 + * call from userspace or internally e.g. from the fbdev suppport code) in
 + * @set, and enable it. This is the main helper functions for drivers that
 + * implement kernel mode setting with the crtc helper functions and the
 + * assorted -prepare(), -modeset() and -commit() interfaces.
   *
   * RETURNS:
 - * Zero. (FIXME)
 + * Returns 0 on success, -ERRNO on failure.
   */
  int drm_crtc_helper_set_config(struct drm_mode_set *set)
  {
 @@ -828,12 +832,14 @@ static int drm_helper_choose_crtc_dpms(struct drm_crtc
 *crtc) }
 
  /**

Re: [PATCH 3/4] drm/doc: integrate fb helper reference into docs

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 31 October 2012 10:11:49 Daniel Vetter wrote:
 Again only minimal changes to make kerneldoc no longer shout. Plus a
 little introduction in the form of a inline DOC: section to quickly
 explain what this is all about.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

With the error below fixed,

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  Documentation/DocBook/drm.tmpl  |  5 +
  drivers/gpu/drm/drm_fb_helper.c | 19 ++-
  2 files changed, 19 insertions(+), 5 deletions(-)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 43e706e..15729eb 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2110,6 +2110,11 @@ void intel_crt_init(struct drm_device *dev)
titleModeset Helper Functions Reference/title
  !Edrivers/gpu/drm/drm_crtc_helper.c
  /sect2
 +sect2
 +  titlefbdev Helper Functions Reference/title
 +!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
 +!Edrivers/gpu/drm/drm_fb_helper.c
 +/sect2
/sect1
 
!-- Internals: vertical blanking --
 diff --git a/drivers/gpu/drm/drm_fb_helper.c
 b/drivers/gpu/drm/drm_fb_helper.c index 4d58d7e..b6e9893 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -41,7 +41,14 @@ MODULE_AUTHOR(David Airlie, Jesse Barnes);
  MODULE_DESCRIPTION(DRM KMS helper);
  MODULE_LICENSE(GPL and additional rights);
 
 -static LIST_HEAD(kernel_fb_helper_list);
 +/**
 + * DOC: fbdev helpers
 + *
 + * The fb helper functions are useful to provide an fbdev on top of a drm
 + * kernel mode setting driver. They can be used mostly independantely from
 + * the crtc helper functions used by many drivers to implement the kernel
 + * mode setting interfaces.  static LIST_HEAD(kernel_fb_helper_list).
 + */

Unless you plan to modify the kerneldoc infrastructure to extract code from 
the comments and feed it to the compiler, I'm pretty sure this will break 
compilation ;-)

  /* simple single crtc case helper function */
  int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper
 *fb_helper) @@ -1291,12 +1298,14 @@ static void drm_setup_crtcs(struct
 drm_fb_helper *fb_helper)
 
  /**
   * drm_helper_initial_config - setup a sane initial connector configuration
 - * @dev: DRM device
 + * @fb_helper: fb_helper device struct
 + * @bpp_sel: bpp value to use for the framebuffer configuration
   *
   * LOCKING:
 - * Called at init time, must take mode config lock.
 + * Called at init time by the driver to set up the @fb_helper initial
 + * configuration, must take mode config lock.
   *
 - * Scan the CRTCs and connectors and try to put together an initial setup.
 + * Scans the CRTCs and connectors and tries to put together an initial
 + * setup. At the moment, this is a cloned configuration across all heads
 + * with a new framebuffer object as the backing store.
   *
 @@ -1330,7 +1339,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
 
  /**
   * drm_fb_helper_hotplug_event - respond to a hotplug notification by
 - *   probing all the outputs attached to the
 fb.
 + *   probing all the outputs attached to the fb
   * @fb_helper: the drm_fb_helper
   *
   * LOCKING:

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 4/4] drm/doc: add new dp helpers into drm DocBook

[Laurent Pinchart]

Hi Daniel,

Thanks for the patch.

On Wednesday 31 October 2012 10:11:50 Daniel Vetter wrote:
 I didn't bother with documenting the really trivial new extract
 something from dpcd helpers, but the i2c over aux ch is now
 documented a bit.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  Documentation/DocBook/drm.tmpl  |  6 ++
  drivers/gpu/drm/drm_dp_helper.c | 20 
  include/drm/drm_dp_helper.h |  7 +++
  3 files changed, 33 insertions(+)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index 15729eb..71edb57 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -2115,6 +2115,12 @@ void intel_crt_init(struct drm_device *dev)
  !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
  !Edrivers/gpu/drm/drm_fb_helper.c
  /sect2
 +sect2
 +  titleDisplay Port Helper Functions Reference/title
 +!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
 +!Iinclude/drm/drm_dp_helper.h
 +!Edrivers/gpu/drm/drm_dp_helper.c
 +/sect2
/sect1
 
!-- Internals: vertical blanking --
 diff --git a/drivers/gpu/drm/drm_dp_helper.c
 b/drivers/gpu/drm/drm_dp_helper.c index 3c4cccd..2ff6482 100644
 --- a/drivers/gpu/drm/drm_dp_helper.c
 +++ b/drivers/gpu/drm/drm_dp_helper.c
 @@ -30,6 +30,15 @@
  #include drm/drm_dp_helper.h
  #include drm/drmP.h
 
 +/**
 + * DOC: dp helpers
 + *
 + * These functions contain some come logic and helpers at various

s/come/core/

 + * abstraction levels to deal with Display Port sink devices and related
 + * things like DP aux channel transfers, EDID reading over DP aux channels,
 + * decoding certain DPCD blocks, ...
 + */
 +
  /* Run a single AUX_CH I2C transaction, writing/reading data as necessary
 */ static int
  i2c_algo_dp_aux_transaction(struct i2c_adapter *adapter, int mode,
 @@ -193,6 +202,17 @@ i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter)
   return 0;
  }
 
 +/**
 + * i2c_dp_aux_add_bus() - register a i2c adaptar using the aux ch helper

s/a i2c adaptar/an I2C adapter/

(feel free to drop the caps if preferred)

 + * @adapter: i2c adapter to register
 + *
 + * This registers an i2c adapater that uses dp aux channel as it's
 + * underlaying transport. The driver needs to fill out the
 + * i2c_algo_dp_aux_data structure which will be used by the the i2c over

s/the the/the/

 + * dp aux algo.

s/algo/algorithm/ ?

 + *
 + * RETURNS:
 + * 0 on success, -ERRNO on failure.
 + */
  int
  i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
  {
 diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
 index c09d367..3f94ede 100644
 --- a/include/drm/drm_dp_helper.h
 +++ b/include/drm/drm_dp_helper.h
 @@ -312,6 +312,13 @@
  #define MODE_I2C_READ4
  #define MODE_I2C_STOP8
 
 +/**
 + * struct i2c_algo_dp_aux_data - driver interface structure for i2c over dp
 + * aux algo

s/algo/algorithm/ ?

 + * @running: set by the algo indicating whether an i2c is ongoing or
 + * whether the i2c bus is quiescent
 + * @address: i2c target address for the currently ongoing transfer
 + * @aux_ch: driver callback to transfer a single byte of the i2c payload
 + */
  struct i2c_algo_dp_aux_data {
   bool running;
   u16 address;
-- 
Regards,

Laurent Pinchart

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

[PATCH 1/4] drm/doc: Helpers are not a Midlayer!

[Daniel Vetter]

I'm devoting all my wrath to that fight, so don't misname it ;-)

v2: Make it clear that this section talks about kms helpers.

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 Documentation/DocBook/drm.tmpl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index b030052..270bc12 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1621,10 +1621,10 @@ void intel_crt_init(struct drm_device *dev)
 /sect2
   /sect1
 
-  !-- Internals: mid-layer helper functions --
+  !-- Internals: kms helper functions --
 
   sect1
-titleMid-layer Helper Functions/title
+titleMode Setting Helper Functions/title
 para
   The CRTC, encoder and connector functions provided by the drivers
   implement the DRM API. They're called by the DRM core and ioctl handlers
-- 
1.7.11.7

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

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

[Daniel Vetter]

- 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 laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 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)
 /listitem
   /itemizedlist
 /sect2
+sect2
+  titleModeset Helper Functions Reference/title
+!Edrivers/gpu/drm/drm_crtc_helper.c
+/sect2
   /sect1
 
   !-- Internals: vertical blanking --
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 drm/drm_fb_helper.h
 #include drm/drm_edid.h
 
+/**
+ * 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
+ * Intended to be use as a generic implementation of the -probe() @connector
+ * callback for drivers that use the crtc helpers for output mode filtering and
+ * detection.
  *
  * RETURNS:
  * Number of modes found on @connector.
@@ -343,17 +353,24 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
 }
 
 /**
- * drm_crtc_set_mode - set a mode
+ * drm_crtc_helper_set_mode - internal helper to set a mode
  * @crtc: CRTC to program
  * @mode: mode to use
  * @x: width of mode
  * @y: height of mode
+ * @old_fb: old framebuffer, for cleanup
  *
  * LOCKING:
  * Caller must hold mode config lock.
  *
  * Try to set @mode on @crtc.  Give @crtc and its associated connectors a 
chance
- * to fixup or reject the mode prior to trying to set it.
+ * to fixup or reject the mode prior to trying to set it. This is an internal
+ * helper that drivers could e.g. use to update properties that require the
+ * entire output pipe to be disabled and re-enabled in a new configuration. For
+ * example for changing whether audio is enabled on a hdmi link or for changing
+ * panel fitter or dither attributes. It is also called by the
+ * drm_crtc_helper_set_config() helper function to drive the mode setting
+ * sequence.
  *
  * RETURNS:
  * True if the mode was set successfully, or false otherwise.
@@ -509,20 +526,19 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
 
 /**
  * drm_crtc_helper_set_config - set a new config from userspace
- * @crtc: CRTC to setup
- * @crtc_info: user provided configuration
- * @new_mode: new mode to set
- * @connector_set: set of connectors for the new config
- * @fb: new framebuffer
+ * @set: mode set configuration
  *
  * LOCKING:
  * Caller must hold mode config lock.
  *
- * Setup a new configuration, provided by the user in @crtc_info, and enable
- * it.
+ * Setup a new configuration, provided by the upper 

[PATCH 3/4] drm/doc: integrate fb helper reference into docs

[Daniel Vetter]

Again only minimal changes to make kerneldoc no longer shout. Plus a
little introduction in the form of a inline DOC: section to quickly
explain what this is all about.

v2: Fixup spelling fail.

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 Documentation/DocBook/drm.tmpl  |  5 +
 drivers/gpu/drm/drm_fb_helper.c | 19 ++-
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index c2b31b9..fadc48b 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2110,6 +2110,11 @@ void intel_crt_init(struct drm_device *dev)
   titleModeset Helper Functions Reference/title
 !Edrivers/gpu/drm/drm_crtc_helper.c
 /sect2
+sect2
+  titlefbdev Helper Functions Reference/title
+!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
+!Edrivers/gpu/drm/drm_fb_helper.c
+/sect2
   /sect1
 
   !-- Internals: vertical blanking --
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4d58d7e..320dcbc 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,7 +41,14 @@ MODULE_AUTHOR(David Airlie, Jesse Barnes);
 MODULE_DESCRIPTION(DRM KMS helper);
 MODULE_LICENSE(GPL and additional rights);
 
-static LIST_HEAD(kernel_fb_helper_list);
+/**
+ * DOC: fbdev helpers
+ *
+ * The fb helper functions are useful to provide an fbdev on top of a drm 
kernel
+ * mode setting driver. They can be used mostly independantely from the crtc
+ * helper functions used by many drivers to implement the kernel mode setting
+ * interfaces.
+ */
 
 /* simple single crtc case helper function */
 int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
@@ -1291,12 +1298,14 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper)
 
 /**
  * drm_helper_initial_config - setup a sane initial connector configuration
- * @dev: DRM device
+ * @fb_helper: fb_helper device struct
+ * @bpp_sel: bpp value to use for the framebuffer configuration
  *
  * LOCKING:
- * Called at init time, must take mode config lock.
+ * Called at init time by the driver to set up the @fb_helper initial
+ * configuration, must take the mode config lock.
  *
- * Scan the CRTCs and connectors and try to put together an initial setup.
+ * Scans the CRTCs and connectors and tries to put together an initial setup.
  * At the moment, this is a cloned configuration across all heads with
  * a new framebuffer object as the backing store.
  *
@@ -1330,7 +1339,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
 
 /**
  * drm_fb_helper_hotplug_event - respond to a hotplug notification by
- *   probing all the outputs attached to the fb.
+ *   probing all the outputs attached to the fb
  * @fb_helper: the drm_fb_helper
  *
  * LOCKING:
-- 
1.7.11.7

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

[PATCH 4/4] drm/doc: add new dp helpers into drm DocBook

[Daniel Vetter]

I didn't bother with documenting the really trivial new extract
something from dpcd helpers, but the i2c over aux ch is now
documented a bit.

v2: Clarify the comment for i2c_dp_aux_add_bus a bit.

v3: Fix more spelling fail spotted by Laurent Pinchart.

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 Documentation/DocBook/drm.tmpl  |  6 ++
 drivers/gpu/drm/drm_dp_helper.c | 21 +
 include/drm/drm_dp_helper.h |  8 
 3 files changed, 35 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index fadc48b..6948bad 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2115,6 +2115,12 @@ void intel_crt_init(struct drm_device *dev)
 !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
 !Edrivers/gpu/drm/drm_fb_helper.c
 /sect2
+sect2
+  titleDisplay Port Helper Functions Reference/title
+!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
+!Iinclude/drm/drm_dp_helper.h
+!Edrivers/gpu/drm/drm_dp_helper.c
+/sect2
   /sect1
 
   !-- Internals: vertical blanking --
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3c4cccd..89e1966 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -30,6 +30,15 @@
 #include drm/drm_dp_helper.h
 #include drm/drmP.h
 
+/**
+ * DOC: dp helpers
+ *
+ * These functions contain some common logic and helpers at various abstraction
+ * levels to deal with Display Port sink devices and related things like DP aux
+ * channel transfers, EDID reading over DP aux channels, decoding certain DPCD
+ * blocks, ...
+ */
+
 /* Run a single AUX_CH I2C transaction, writing/reading data as necessary */
 static int
 i2c_algo_dp_aux_transaction(struct i2c_adapter *adapter, int mode,
@@ -193,6 +202,18 @@ i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter)
return 0;
 }
 
+/**
+ * i2c_dp_aux_add_bus() - register an i2c adapter using the aux ch helper
+ * @adapter: i2c adapter to register
+ *
+ * This registers an i2c adapater that uses dp aux channel as it's underlaying
+ * transport. The driver needs to fill out the i2c_algo_dp_aux_data structure
+ * and store it in the algo_data member of the @adapter argument. This will be
+ * used by the i2c over dp aux algorithm to drive the hardware.
+ *
+ * RETURNS:
+ * 0 on success, -ERRNO on failure.
+ */
 int
 i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
 {
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c09d367..e8e1417 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -312,6 +312,14 @@
 #define MODE_I2C_READ  4
 #define MODE_I2C_STOP  8
 
+/**
+ * struct i2c_algo_dp_aux_data - driver interface structure for i2c over dp
+ *  aux algorithm
+ * @running: set by the algo indicating whether an i2c is ongoing or whether
+ *  the i2c bus is quiescent
+ * @address: i2c target address for the currently ongoing transfer
+ * @aux_ch: driver callback to transfer a single byte of the i2c payload
+ */
 struct i2c_algo_dp_aux_data {
bool running;
u16 address;
-- 
1.7.11.7

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

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

[Jesse Barnes]

On Thu, 1 Nov 2012 12:12:35 +0100
Daniel Vetter dan...@ffwll.ch wrote:

 On Thu, Oct 25, 2012 at 8:05 PM,  ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  Send completion events when the atomic modesetting operations has
  finished succesfully.
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
 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 AB will have
 full 4-lane fdi links to the pch ports (instead of otherwise only 2
 lanes each on links BC)
 - 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 BC 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.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.7

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Hi Dave,

This request is mostly load detection fixes from Egbert and me.

The following changes since commit 4936b172d699434547addbe452c2d600ea6a4baf:

  Merge branch 'drm-nouveau-fixes' of 
git://people.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-10-31 
13:46:09 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.7

Alex Deucher (1):
  drm/radeon: add load detection support for ext DAC on R200 (v2)

Egbert Eich (6):
  DRM/Radeon: Fix Load Detection on legacy primary DAC.
  DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.
  DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.
  DRM/Radeon: Clean up code in TV DAC load detection.
  DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.
  DRM/radeon: For single CRTC GPUs move handling of CRTC_CRT_ON to 
crtc_dpms().

Igor Murzov (1):
  drm/radeon: fix ATPX function documentation

Peter Senna Tschudin (1):
  drivers/gpu/drm/radeon/evergreen_cs.c: Remove unnecessary semicolon

 drivers/gpu/drm/radeon/evergreen_cs.c   |2 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c|4 +-
 drivers/gpu/drm/radeon/radeon_connectors.c  |   28 +++-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |   15 ++-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  175 +++
 5 files changed, 184 insertions(+), 40 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Jakob Bornecrantz]

On Thu, Nov 1, 2012 at 2:45 PM, Daniel Vetter daniel.vet...@ffwll.ch 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 laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  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)
  /listitem
/itemizedlist
  /sect2
 +sect2
 +  titleModeset Helper Functions Reference/title
 +!Edrivers/gpu/drm/drm_crtc_helper.c
 +/sect2
/sect1

!-- Internals: vertical blanking --
 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 drm/drm_fb_helper.h
  #include drm/drm_edid.h

 +/**
 + * 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.

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

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

[Chris Wilson]

On Thu, 1 Nov 2012 15:49:16 +0100, Jakob Bornecrantz wallbra...@gmail.com 
wrote:
 On Thu, Nov 1, 2012 at 2:45 PM, Daniel Vetter daniel.vet...@ffwll.ch 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 laurent.pinch...@ideasonboard.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   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)
   /listitem
 /itemizedlist
   /sect2
  +sect2
  +  titleModeset Helper Functions Reference/title
  +!Edrivers/gpu/drm/drm_crtc_helper.c
  +/sect2
 /sect1
 
 !-- Internals: vertical blanking --
  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 drm/drm_fb_helper.h
   #include drm/drm_edid.h
 
  +/**
  + * 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.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49051] nouveau driver send my laptop to power down

[bugzilla-daemon]

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





--- Comment #1 from Reinhard Karcher reinhard.karc...@gmx.net  2012-11-01 
16:18:43 ---
Using newest kernel from git (1e207eb1c3f0e8b690401f02fe08e7b53903f010), the
problem is gone.
The bug should be closed.

Reinhard

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49051] nouveau driver send my laptop to power down

[bugzilla-daemon]

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


Reinhard Karcher reinhard.karc...@gmx.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ville Syrjälä]

On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
 On Thu, 1 Nov 2012 12:12:35 +0100
 Daniel Vetter dan...@ffwll.ch wrote:
 
  On Thu, Oct 25, 2012 at 8:05 PM,  ville.syrj...@linux.intel.com wrote:
   From: Ville Syrjälä ville.syrj...@linux.intel.com
  
   Send completion events when the atomic modesetting operations has
   finished succesfully.
  
   Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  
  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 AB will have
  full 4-lane fdi links to the pch ports (instead of otherwise only 2
  lanes each on links BC)
  - 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 BC 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.

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

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

[Jesse Barnes]

On Thu, 1 Nov 2012 19:07:02 +0200
Ville Syrjälä ville.syrj...@linux.intel.com 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 dan...@ffwll.ch wrote:
  
   On Thu, Oct 25, 2012 at 8:05 PM,  ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
   
Send completion events when the atomic modesetting operations has
finished succesfully.
   
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
   
   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 AB will have
   full 4-lane fdi links to the pch ports (instead of otherwise only 2
   lanes each on links BC)
   - 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 BC 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.

However, we can't always hide hw details like that in the kernel
through generic interfaces (e.g. for sprites and all their
restrictions) so userspace will have to have some knowledge one way or
another, and maybe it's not that bad to push some of the other
limitation knowledge into our userspace code.

Ambivalent.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 CC||klausenb...@hotmail.com

--- Comment #8 from Alex Deucher ag...@yahoo.com ---
*** Bug 56464 has been marked as a duplicate of this bug. ***

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

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

[Stephen Warren]

On 10/31/2012 03:28 AM, Steffen Trumtrar wrote:

Patch description? The patch defines the DT binding as well, which isn't
mentioned in the patch subject.

 new file mode 100644
 index 000..04c94a3
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/display-timings.txt

 +Usage in backend
 +

Everything before this point in the binding docs looks reasonable to me.
Everything after this point is Linux-specific/internal implementation
detail, and hence shouldn't be in the binding document.

I only read the DT binding.

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

Re: [PATCH v7 3/8] of: add generic videomode description

[Thierry Reding]

On Wed, Oct 31, 2012 at 10:28:03AM +0100, Steffen Trumtrar wrote:
[...]
 +config OF_VIDEOMODE
 + def_bool y
 + depends on VIDEOMODE
 + help
 +   helper to get videomodes from the devicetree
 +

I think patches 3 and 4 need to be swapped, since patch 4 introduces the
VIDEOMODE Kconfig symbol (as well as the videomode.h helper) that patch
3 uses.

Thierry


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

Re: [PATCH 2/2] drm/i915: move panel connectors to the front

[Daniel Vetter]

On Wed, Oct 31, 2012 at 04:05:33PM -0400, Adam Jackson wrote:
 On 10/27/12 9:52 AM, Daniel Vetter wrote:
 This essentially reverts
 
 commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
 Author: Adam Jackson a...@redhat.com
 Date:   Fri Jul 16 14:46:29 2010 -0400
 
  drm/i915: Initialize LVDS and eDP outputs before anything else
 
 simply because it doesn't scale: It misses SDVO and DVO panels,
 and now with DDI encoders on haswell this is becoming unmanageable.
 
 Instead we simply sort the connector list after everything is
 set up.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 Reviewed-by: Adam Jackson a...@redhat.com

Slurped both this and the drm helper patch into dinq, thanks for the
review. I'll annoy Dave about including the doc patches into his tree
directly, he should get the pull which has the drm_dp_helper.c rename
tomorrow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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 wallbra...@gmail.com 
 wrote:
  On Thu, Nov 1, 2012 at 2:45 PM, Daniel Vetter daniel.vet...@ffwll.ch 
  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 laurent.pinch...@ideasonboard.com
   Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
   ---
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)
/listitem
  /itemizedlist
/sect2
   +sect2
   +  titleModeset Helper Functions Reference/title
   +!Edrivers/gpu/drm/drm_crtc_helper.c
   +/sect2
  /sect1
  
  !-- Internals: vertical blanking --
   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 drm/drm_fb_helper.h
#include drm/drm_edid.h
  
   +/**
   + * 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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ä ville.syrj...@linux.intel.com 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 dan...@ffwll.ch wrote:
   
On Thu, Oct 25, 2012 at 8:05 PM,  ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com

 Send completion events when the atomic modesetting operations has
 finished succesfully.

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

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 AB will have
full 4-lane fdi links to the pch ports (instead of otherwise only 2
lanes each on links BC)
- 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 BC 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 there's no way to fit it, reassign pipes a bit or try
dithering. Once that works, call into encoders ...

Or maybe we could do a 

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

[bugzilla-daemon]

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

--- Comment #13 from mailbox@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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

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

Signed-off-by: Dave Airlie airl...@redhat.com
---
 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,
buffer);
-   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,
buffer);
-   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

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

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

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

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 airl...@redhat.com
---
 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 = nouveau_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 

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

[bugzilla-daemon]

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

--- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com ---
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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel