[PATCH 1/1] media: Entities with sink pads must have at least one enabled link

[Sakari Ailus]

On Wed, Nov 14, 2012 at 11:58:42AM +0100, Laurent Pinchart wrote:
> I think my preference would go for a helper function that drivers can use, 
> possibly first waiting until a second driver requires this kind of checks 
> before implementing it.

I'd like to see a driver that doesn't. Quite likelye either it has no
configurable links or it's broken. :-)

-- 
Sakari Ailus
e-mail: sakari.ailus at iki.fi  XMPP: sailus at retiisi.org.uk

[PATCH 1/1] media: Entities with sink pads must have at least one enabled link

[Sakari Ailus]

Hi Sylwester,

Thanks for the comments.

On Wed, Nov 14, 2012 at 10:23:19AM +0100, Sylwester Nawrocki wrote:
> On 11/13/2012 03:24 PM, Sakari Ailus wrote:
> > Hi all,
> > 
> > Comments would be appreciated, either positive or negative. The omap3isp
> > driver does the same check itself currently, but I think this is more
> > generic than that.
> > 
> > Thanks.
> > 
> > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote:
> >> If an entity has sink pads, at least one of them must be connected to
> >> another pad with an enabled link. If a driver with multiple sink pads has
> >> more strict requirements the check should be done in the driver itself.
> >>
> >> Just requiring one sink pad is connected with an enabled link is enough
> >> API-wise: entities with sink pads with only disabled links should not be
> >> allowed to stream in the first place, but also in a different operation 
> >> mode
> >> a device might require only one of its pads connected with an active link.
> >>
> >> If an entity has an ability to function as a source entity another logical
> >> entity connected to the aforementioned one should be used for the purpose.
> 
> Why not leave it to individual drivers ? I'm not sure if it is a good idea
> not to allow an entity with sink pads to be used as a source only. It might
> be appropriate for most of the cases but likely not all. I'm inclined not to
> add this requirement in the API. Just my opinion though.

I'm just wondering what would be the use case for that.

What comes closest is generating a test pattern, but even that should be a
separate subdev: the test pattern can be enabled by enabling the link from
the test pattern generator subdev.

As it seems not everyone is outright happy about the idea of making this
mandatory, then how about making it optional?

I'd hate having a link validate function for each subdev e.g. in the OMAP 3
ISP driver that just checks that its sink pad is actually connected with an
enabled link. That'd be lots of mostly useless code. If this is done in the
framework, the drivers will be spared from copying this code in a number of
places. Which was why I originally wrote this patch. The alternative is to
re-parse the whole graph in the driver which I'd also like to avoid.

One opion I can think of is to call link_validate op of struct
media_entity_operations also for disabled links on entities that are
connected through active links (on V4L2 to a video node right before
streaming, for example).

That'd make it easy to perform the check in the drivers.

What do you think?

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus at iki.fi  XMPP: sailus at retiisi.org.uk

Regression due to "mm: fix-up zone present pages"

[Bob Liu]

On Wed, Nov 14, 2012 at 6:09 PM, Daniel Vetter  
wrote:
> Hi all,
>
> Our QA noticed a regression in one of our i915/GEM testcases in 3.7:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=56859
>
> Direct link to dmesg of the machine:
> https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that the
> machine is 32bit, which seems to be important since Chris Wilson
> confirmed the bug on his 32bit Sandybridge machine, whereas mine here
> with a 64bit kernel works flawlessly.
>
> The testcase is gem_tiled_swapping:
>
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/gem_tiled_swapping.c
>
> Quick high-level description of the workload:
>
> It allocates a working set larger than available memory, then fills it
> by writing it through the gpu gart (required to get a linear view of
> tiled buffers) and afterwards reads it to check whether anything got
> corrupted. Since the working set is too large to fit into ram, this
> will force all buffers through swap. We've written this testcase to
> exercise the reswizzle swapin path since some platforms have a tiling
> layout depending upon physical pfn (awesome feature btw), but not snb.
> So within the kernel this workload simply grabs the backing storage
> from shmemfs with shmem_read_mapping_page_gfp and then binds them into
> the gpu pagetables (the GTT). This happens in the i915_gem_fault
> fucntion. Unbinding in this workload happens either directly (if the
> gem code can't get enough memory) or through our shrinker
> (i915_gem_inactive_shrink). Swapout is then left to shmemfs to handle.
> All the above stuff is in drivers/gpu/drm/i915_gem.c
>
> Testcase fails because it detects a mismatch between what has been
> written and what has been read back.
>
> Our qa people bisected the regression to
>
> commit 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125
> Author: Jianguo Wu 
> Date:   Mon Oct 8 16:33:06 2012 -0700
>
> mm: fix-up zone present pages
>
> and confirmed the revert on top of the latest drm-intel-nightly branch
> (which is based on top of 3.7-rc2 and contains the -next stuff for
> 3.8). They've also tested the for-QA branch which had latest Linus
> upstream merged in, which did not fix the problem. For reference the
> intel trees are at (but I don't think it matters really that it's not
> plain upstream, nothing really changed in the relevant i915/gem paths
> compared to upstream):
>
> http://cgit.freedesktop.org/~danvet/drm-intel
>
> I have no idea how that early boot zone init fix could even corrupt
> swapping in such a fashion, so ideas highly welcome. QA people are
> cc'ed, and hopefully I haven't missed anyone else on the cc list.
>

You can take a look at this thread:
[PATCH] mm: fix a regression with HIGHMEM introduced by changeset 7f1290f2f2a4d
http://lkml.org/lkml/2012/11/5/866

I think it's the same problem.

-- 
Regards,
--Bob

[PATCH] drm/exynos: fix overlay updating issue

[Inki Dae]

This patch fixes a issue that overlay data aren't applied
to real hardware when dpms off goes to on after setcrtc
was requested like below,
dpms off -> setcrtc -> dpms off -> dpms on

For this, it makes encoder's dpms to be updated when
setcrtc is requested.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 241ad1e..d971c95 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -423,6 +423,8 @@ void exynos_drm_encoder_crtc_dpms(struct drm_encoder 
*encoder, void *data)
if (!encoder->crtc)
manager->pipe = -1;
}
+
+   exynos_encoder->dpms = mode;
 }

 void exynos_drm_encoder_crtc_pipe(struct drm_encoder *encoder, void *data)
-- 
1.7.4.1

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

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

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


Marcin Slusarz  changed:

   What|Removed |Added

 CC||marcin.slusarz at gmail.com




--- Comment #2 from Marcin Slusarz   2012-11-14 
20:28:08 ---
Please attach dmesgs from both 3.6.x and 3.7-rcLatest.
What's the problem with bisection? If you can't continue because of build
error, please attach it too.

I hope ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69 is not a culprit... (146 files
changed, 14219 insertions(+), 11099 deletions(-))

-- 
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] drm: exynos: fix for loosing display mode header during mode adjustment

[Inki Dae]

2012/11/9 Rahul Sharma 

> This patch is to preserve the display mode header during the mode
> adjustment.
> Display mode header is overwritten with the adjusted mode header which is
> throwing the stack dump.
>
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index ee110c9..c7844ea 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1974,6 +1974,8 @@ static void hdmi_mode_fixup(void *ctx, struct
> drm_connector *connector,
>  {
> struct drm_display_mode *m;
> struct hdmi_context *hdata = ctx;
> +   struct drm_mode_object base;
> +   struct list_head head;
>

Remove base and head,


> int index;
>
> DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
> @@ -2002,7 +2004,13 @@ static void hdmi_mode_fixup(void *ctx, struct
> drm_connector *connector,
> if (index >= 0) {
>

And declare them here.

Thanks,
Inki Dae


> DRM_INFO("desired mode doesn't exist so\n");
> DRM_INFO("use the most suitable mode among
> modes.\n");
> +
> +   /* preserve display mode header while copying. */
> +   head = adjusted_mode->head;
> +   base = adjusted_mode->base;
> memcpy(adjusted_mode, m, sizeof(*m));
> +   adjusted_mode->head = head;
> +   adjusted_mode->base = base;
> break;
> }
> }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/66f05448/attachment.html>

[PATCH 2/2] drm/exynos: release fb pended by page flip

[Inki Dae]

This patch releases the fb pended by page flip after fbdev is
restored propely. And fixes invalid memory access when drm is
released while doing pageflip.

This patch makes fb's refcount to be increased when setcrtc and
pageflip are requested. In other words, it increases fb's refcount
only if dma is going to access memory region to fb and decreases
old fb's because the old fb isn't accessed by dma anymore.

This could guarantee releasing gem buffer to the fb after dma
access to the gem buffer has been completed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   18 +++-
 5 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2efa4b0..2a52b7e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,6 +32,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_encoder.h"
 #include "exynos_drm_plane.h"
+#include "exynos_drm_fb.h"

 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc,\
drm_crtc)
@@ -137,8 +138,26 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
return ret;

plane->crtc = crtc;
+
+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
plane->fb = crtc->fb;

+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane->fb);
+
exynos_drm_fn_encoder(crtc, , exynos_drm_encoder_crtc_pipe);

return 0;
@@ -168,6 +187,24 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
x, y, crtc_w, crtc_h);
if (ret)
return ret;
+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
+   plane->fb = crtc->fb;
+
+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane->fb);

exynos_drm_crtc_commit(crtc);

@@ -243,7 +280,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,

crtc->fb = fb;
ret = exynos_drm_crtc_mode_set_base(crtc, crtc->x, crtc->y,
-   NULL);
+   old_fb);
if (ret) {
crtc->fb = old_fb;

@@ -254,6 +291,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,

goto out;
}
+
+   exynos_drm_fb_set_pending(old_fb, false);
+   exynos_drm_fb_set_pending(fb, true);
}
 out:
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ef4cd3..f100035 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -43,11 +43,15 @@
  * @fb: drm framebuffer obejct.
  * @buf_cnt: a buffer count to drm framebuffer.
  * @exynos_gem_obj: array of exynos specific gem object containing a gem 
object.
+ * @pending: indicate whehter a fb was pended by page flip.
+ * if true, the fb should be released after fbdev is restored to avoid
+ * accessing invalid memory region.
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
unsigned intbuf_cnt;
struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
+   boolpending;
 };

 static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
@@ -228,6 +232,25 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return fb;
 }

+void exynos_drm_fb_set_pending(struct drm_framebuffer *fb, bool pending)
+{
+   struct exynos_drm_fb *exynos_fb;
+
+   exynos_fb = to_exynos_fb(fb);
+
+   exynos_fb->pending = pending;
+}
+
+void exynos_drm_release_pended_fb(struct drm_framebuffer *fb)
+{
+   struct exynos_drm_fb *exynos_fb;
+
+

[PATCH 1/2] drm/exynos: remove unnecessary code.

[Inki Dae]

plane->fb will be set to new fb after update_plane callback is called
by drm_mode_set_plane()

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 60b877a..862ca1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -204,7 +204,6 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
return ret;

plane->crtc = crtc;
-   plane->fb = crtc->fb;

exynos_plane_commit(plane);
exynos_plane_dpms(plane, DRM_MODE_DPMS_ON);
-- 
1.7.4.1

[PATCH 0/2] drm/exynos: fix invalid memory access

[Inki Dae]

This patch releases the fb pended by page flip after fbdev is
restored propely. And fixes invalid memory access when drm is
released while doing pageflip.

This patch makes fb's refcount to be increased when setcrtc and
pageflip are requested. In other words, it increases fb's refcount
only if dma is going to access memory region to fb and decreases
old fb's because the old fb isn't accessed by dma anymore.

This could guarantee releasing gem buffer to the fb after dma
access to the gem buffer has been completed.

Inki Dae (2):
  drm/exynos: remove unnecessary code.
  drm/exynos: release fb pended by page flip

 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   19 +++-
 5 files changed, 96 insertions(+), 3 deletions(-)

-- 
1.7.4.1

[PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR

[Greg Kroah-Hartman]

On Wed, Nov 14, 2012 at 11:22:37AM -0600, Andy Gross wrote:
> Return -ENOMEM if dmm_txn_init cannot allocate a refill engine.
> 
> v2: Fix typing issue seen with newer compilers
> 
> Signed-off-by: Andy Gross 
> Signed-off-by: Rob Clark 
> ---
>  drivers/staging/omapdrm/omap_dmm_tiler.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

This doesn't apply anymore, care to refresh it against my latest tree?

thanks,

greg k-h

[Bug 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen

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

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

--- Comment #19 from Alex Deucher  ---
(In reply to comment #18)
> > As far as I understand, expected usage of MLAA with Mesa is to enable it
> > only for the applications where you want it (games etc) with either
> > app-specific drirc settings or environment variables.
> It is probably so. A **huge** problem for me is a common lack of
> documentation. I'm okay with English and not too lazy to read but I could
> hardly find what to read, though. I mean - relevant while not obsolete.
> Things usually work in default configuration, which may not be optimal for
> some cases, and if I want to do something about it - this is where troubles
> begin - for me and maybe for developers who have to answer my sometimes
> stupid questions. All this video stuff looks so complicated and chaotic for
> me due to lack of documentation... I even did not comprehend if mesa is
> commonly responsible only for 3D rendering how comes erroneously enabled
> MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't
> they?

MLAA affects all rendering that goes through OpenGL.  While the text rendering
for non-GL X apps may be rendered by the ddx using xrendr, the pixmaps end up
going though OpenGL if you are using an OpenGL compositor (gnome
shell/compiz/kwin/etc.).  When the application window is composited to the
front buffer by the OpenGL compositor, the MLAA is applied.

-- 
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/20121114/7c743efe/attachment.html>

[Bug 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen

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

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

--- Comment #18 from ka.nick at mail.ru ---
(In reply to comment #17)
> I suspect that it works as intended though it's not what one might expect
> comparing to similar options in proprietary drivers.
I think you're completely right. In my case the issue was provoked by two
things: first, the program I use (GTK driconf o.9.1) suggests MLAA to be set to
8 as default value (however, resets it to 0 by default), and second, that it
did not actually work for me in mesa 8.0. So I was misled a little bit after I
installed mesa 9...

> As far as I understand, expected usage of MLAA with Mesa is to enable it
> only for the applications where you want it (games etc) with either
> app-specific drirc settings or environment variables.
It is probably so. A **huge** problem for me is a common lack of documentation.
I'm okay with English and not too lazy to read but I could hardly find what to
read, though. I mean - relevant while not obsolete. Things usually work in
default configuration, which may not be optimal for some cases, and if I want
to do something about it - this is where troubles begin - for me and maybe for
developers who have to answer my sometimes stupid questions. All this video
stuff looks so complicated and chaotic for me due to lack of documentation... I
even did not comprehend if mesa is commonly responsible only for 3D rendering
how comes erroneously enabled MLAA blurs fonts, too. Fonts currently are
rendered by DDX driver, aren't they?

> So I don't think it's a bug, though perhaps it would be nice to make Mesa
> behave more like other drivers.
Or at least, make things documented somehow. Currently the tuning knobs are
spread across three areas: drirc (which is created somehow, or not, often
beyond the user control); environment variables (hardly documented), Xorg.conf.
Oh yes, there is fourth: USE flags/.configure options. A little bit to
complicated...

Just the same, thank you guys for what you do.

-- 
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/20121114/500ba688/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

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

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

--- Comment #31 from Alexandre Demers  ---
Here are the videos. Sorry, they were recorded with my iPod and they are
inverted.

Normal boot sequence before the culprit commit (kernel 3.6)
http://www.filedropper.com/k36
A normal boot sequence with kernel 3.6 from grub 2 to booting console.
Resolution is kept from grub to console, there is no sync problem and no purple
flicker.

A problematic boot with kernel 3.7-rc5 using gfxpayload=keep in Grub 2.
http://www.filedropper.com/k37keep
It starts normally, the booting console uses the same resolution as Grub 2.
However, possibly when radeon driver kicks in, there is a purple flicker
followed by a wrong (badly synced) display (shifted by about half a screen to
the right). The result could have been a black screen, a couple of interlaced
vertical lines or a different shifted display.

A non problematic boot with kernel 3.7-rc5 using gfxpayload=text in Grub 2.
http://www.filedropper.com/k37text
It doesn't show the purple flicker we see in the previous video, it just
flickers as a normal boot would do, but it does show the purple color from time
to time. However, the display is OK.

A problematic suspend/resume sequence with 3.7-rc5 (gfxpayload doesn't change
anything)
http://www.filedropper.com/k37suspend
Going in suspend mode just after booting up. When resuming, X/gdm briefly
appears, then it crashes. The computer continue to run, but the display stays
black and no input can be used (tried to switch console and reboot but it
doesn't work). Often, it will reboot by itself after some time. Suspend and
resume work great before the culprit commit or if I remove the changes in
"...mc_stop()"

-- 
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/20121114/23d4af52/attachment-0001.html>

[PATCH] drm/radeon: fix logic error in atombios_encoders.c

[Michel Dänzer]

On Mit, 2012-11-14 at 09:13 -0500, alexdeucher at gmail.com wrote: 
> From: Alex Deucher 
> 
> Fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=50431
> 
> Reported-by: David Binderman 
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

Reviewed-by: Michel D?nzer 


>  drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index ba498f8..010bae1 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
> *encoder, int mode)
>   atombios_dig_transmitter_setup(encoder, 
> ATOM_TRANSMITTER_ACTION_SETUP, 0, 0);
>   atombios_dig_transmitter_setup(encoder, 
> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
>   /* some early dce3.2 boards have a bug in their 
> transmitter control table */
> - if ((rdev->family != CHIP_RV710) || (rdev->family != 
> CHIP_RV730))
> + if ((rdev->family != CHIP_RV710) && (rdev->family != 
> CHIP_RV730))

Ouch, the compiler didn't warn about this always evaluating to true?


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH v9 5/6] drm_modes: add videomode helpers

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 01:49:44PM +0100, Thierry Reding wrote:
> On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote:
> [...]
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> [...]
> > @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
> > vdisplay, int vrefresh,
> >  }
> >  EXPORT_SYMBOL(drm_gtf_mode);
> >  
> > +#if IS_ENABLED(CONFIG_VIDEOMODE)
> > +int display_mode_from_videomode(struct videomode *vm, struct 
> > drm_display_mode *dmode)
> 
> Given that this is still a DRM core function, maybe it should get a drm_
> prefix? Also the line is too long, so you may want to wrap the argument
> list.
> 
> Thierry

Yes, seems to fit better to the rest of the file.

Regards,
Steffen

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

[PATCH v9 3/6] fbmon: add videomode helpers

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 01:12:07PM +0100, Thierry Reding wrote:
> On Wed, Nov 14, 2012 at 12:43:20PM +0100, Steffen Trumtrar wrote:
> > Add a function to convert from the generic videomode to a fb_videomode.
> > 
> > Signed-off-by: Steffen Trumtrar 
> > ---
> >  drivers/video/fbmon.c |   38 ++
> >  include/linux/fb.h|5 +
> >  2 files changed, 43 insertions(+)
> > 
> > diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> > index cef6557..cccef17 100644
> > --- a/drivers/video/fbmon.c
> > +++ b/drivers/video/fbmon.c
> > @@ -31,6 +31,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #ifdef CONFIG_PPC_OF
> >  #include 
> >  #include 
> > @@ -1373,6 +1374,43 @@ 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 fb_videomode_from_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;
> > +   if (vm->de)
> > +   fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
> > +   fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive);
> 
> CodingStyle that you should have spaces around '*'. Also I'm not sure if
> that formula is correct. Shouldn't the blanking intervals be counted as
> well? So:
> 
>   unsigned int htotal = vm->hactive + vm->hfront_porch +
> vm->hback_porch + vm->hsync_len;
>   unsigned int vtotal = vm->vactive + vm->vfront_porch +
> vm->vback_porch + vm->vsync_len;
> 
>   fbmode->refresh = (vm->pixelclock * 1000) / (htotal * vtotal);
> 
> ?
> 

Sounds correct. Done.

> > +   fbmode->flag = 0;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
> > +#endif
> > +
> > +
> 
> Gratuitous blank line.
> 
> >  #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..6a3a675 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  struct vm_area_struct;
> >  struct fb_info;
> > @@ -714,6 +715,10 @@ 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);
> >  
> > +#if IS_ENABLED(CONFIG_VIDEOMODE)
> > +extern int fb_videomode_from_videomode(struct videomode *vm,
> > +  struct fb_videomode *fbmode);
> > +#endif
> >  /* drivers/video/modedb.c */
> 
> These in turn could use an extra blank line.
> 
> Thierry



> ___
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


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

please add datasheet URL to dri.freedesktop.org/wiki/SMedia

[Eric Anholt]

Paul Wise  writes:

> Hi all,
>
> Sean from OpenMoko recently released the SMedia Glamo datasheets[1].
> Could someone with permission add them to the wiki page[2]?
>
> My account (PaulWise) does not appear to be able to edit the page.
>
>  1. http://people.openmoko.org/sean/datasheets/glamo3362/
>  2. http://dri.freedesktop.org/wiki/SMedia

I noticed this marked todo in my mail.  I've added you to the dri.fdo
edit group.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121114/97dbdfdf/attachment.pgp>

[PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR

[Rob Clark]

On Wed, Nov 14, 2012 at 11:22 AM, Andy Gross  wrote:
> Return -ENOMEM if dmm_txn_init cannot allocate a refill engine.
>
> v2: Fix typing issue seen with newer compilers
>
> Signed-off-by: Andy Gross 

Signed-off-by: Rob Clark  ---
>  drivers/staging/omapdrm/omap_dmm_tiler.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
> b/drivers/staging/omapdrm/omap_dmm_tiler.c
> index 3ae3955..1499521 100644
> --- a/drivers/staging/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
> @@ -279,7 +279,7 @@ static int fill(struct tcm_area *area, struct page 
> **pages,
>
> txn = dmm_txn_init(omap_dmm, area->tcm);
> if (IS_ERR_OR_NULL(txn))
> -   return PTR_ERR(txn);
> +   return -ENOMEM;
>
> tcm_for_each_slice(slice, *area, area_s) {
> struct pat_area p_area = {
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

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

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


Alan  changed:

   What|Removed |Added

Summary|GeForce 6150SE: system  |[BISECTED]GeForce 6150SE:
   |hangs on X-server start |system hangs on X-server
   |with garbled screen |start with garbled screen




-- 
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 v9 2/6] video: add of helper for videomode

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 01:00:45PM +0100, Thierry Reding wrote:
> On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
> [...]
> > +display-timings bindings
> > +
> > +
> > +display timings node
> 
> I didn't express myself very clearly here =). The way I think this
> should be written is "display-timings node".
> 
> > +required properties:
> > + - hactive, vactive: Display resolution
> > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing 
> > parameters
> > +   in pixels
> > +   vfront-porch, vback-porch, vsync-len: Vertical display timing 
> > parameters in
> > +   lines
> > + - clock-frequency: displayclock in Hz
> 
> I still think "displayclock" should be two words: "display clock".
> 
> > +/**
> > + * of_get_display_timings - parse all display_timing entries from a 
> > device_node
> > + * @np: device_node with the subnodes
> > + **/
> > +struct display_timings *of_get_display_timings(struct device_node *np)
> > +{
> [...]
> > +   disp->num_timings = 0;
> > +   disp->native_mode = 0;
> > +
> > +   for_each_child_of_node(timings_np, entry) {
> > +   struct display_timing *dt;
> > +
> > +   dt = of_get_display_timing(entry);
> > +   if (!dt) {
> > +   /* to not encourage wrong devicetrees, fail in case of 
> > an error */
> > +   pr_err("%s: error in timing %d\n", __func__, 
> > disp->num_timings+1);
> > +   goto timingfail;
> 
> I believe you're still potentially leaking memory here. In case you have
> 5 entries for instance, and the last one fails to parse, then this will
> cause the memory allocated for the 4 correct entries to be lost.
> 
> Can't you just call display_timings_release() in this case and then jump
> to dispfail? That would still leak the native_mode device node. Maybe it
> would be better to keep timingfail but modify it to free the display
> timings with display_timings_release() instead? See below.
> 
> > +   }
> > +
> > +   if (native_mode == entry)
> > +   disp->native_mode = disp->num_timings;
> > +
> > +   disp->timings[disp->num_timings] = dt;
> > +   disp->num_timings++;
> > +   }
> > +   of_node_put(timings_np);
> > +   of_node_put(native_mode);
> > +
> > +   if (disp->num_timings > 0)
> > +   pr_info("%s: got %d timings. Using timing #%d as default\n", 
> > __func__,
> > +   disp->num_timings , disp->native_mode + 1);
> > +   else {
> > +   pr_err("%s: no valid timings specified\n", __func__);
> > +   display_timings_release(disp);
> > +   return NULL;
> > +   }
> > +   return disp;
> > +
> > +timingfail:
> > +   if (native_mode)
> > +   of_node_put(native_mode);
> > +   kfree(disp->timings);
> 
> Call display_timings_release(disp) instead of kfree(disp->timings)?
> 

Yes. That would be the appropriate way to fail here. Done.

> > diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
> > new file mode 100644
> > index 000..4138758
> > --- /dev/null
> > +++ b/include/linux/of_videomode.h
> > @@ -0,0 +1,16 @@
> > +/*
> > + * Copyright 2012 Steffen Trumtrar 
> > + *
> > + * videomode of-helpers
> > + *
> > + * This file is released under the GPLv2
> > + */
> > +
> > +#ifndef __LINUX_OF_VIDEOMODE_H
> > +#define __LINUX_OF_VIDEOMODE_H
> > +
> > +#include 
> > +#include 
> > +
> > +int of_get_videomode(struct device_node *np, struct videomode *vm, int 
> > index);
> > +#endif /* __LINUX_OF_VIDEOMODE_H */
> 
> Nit: should have a blank line before #endif.
> 
> Thierry



> ___
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


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

[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test

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

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


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #1 from Alex Deucher   2012-11-14 
14:13:53 ---
Good catch.  Thanks!  Patch queued.

-- 
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 v9 6/6] drm_modes: add of_videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:23PM +0100, Steffen Trumtrar wrote:
[...]
> +EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
> +#endif
>  /**

Nit: there should be a blank line between the last two.

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/20121114/b0917da7/attachment.pgp>

[Bug 50091] GeForce 6150SE: system hangs on X-server start with garbled screen

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

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





--- Comment #1 from schaefer.frank at gmx.net  2012-11-14 13:50:31 ---
Last good commit is 
5787640db6ae722aeadb394d480c7ca21b603e34
drm/nv04-nv40/instmem: remove use of nouveau_gpuobj_new_fake()

First bad commit is
ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69
drm/nouveau: port all engines to new engine module format

Can't test 16 commits inbetween (70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9 to
ac1499d9573f4aadd1d2beac11fe23af8ce90c24).

-- 
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 v9 5/6] drm_modes: add videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
[...]
> @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
> vdisplay, int vrefresh,
>  }
>  EXPORT_SYMBOL(drm_gtf_mode);
>  
> +#if IS_ENABLED(CONFIG_VIDEOMODE)
> +int display_mode_from_videomode(struct videomode *vm, struct 
> drm_display_mode *dmode)

Given that this is still a DRM core function, maybe it should get a drm_
prefix? Also the line is too long, so you may want to wrap the argument
list.

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/20121114/476e294f/attachment.pgp>

[PATCH v9 4/6] fbmon: add of_videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:21PM +0100, Steffen Trumtrar wrote:
[...]
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
[...]
> +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
> +static void dump_fb_videomode(struct fb_videomode *m)

static inline?

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/20121114/cc2311dd/attachment.pgp>

[PATCH v9 3/6] fbmon: add videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:20PM +0100, Steffen Trumtrar wrote:
> Add a function to convert from the generic videomode to a fb_videomode.
> 
> Signed-off-by: Steffen Trumtrar 
> ---
>  drivers/video/fbmon.c |   38 ++
>  include/linux/fb.h|5 +
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index cef6557..cccef17 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #ifdef CONFIG_PPC_OF
>  #include 
>  #include 
> @@ -1373,6 +1374,43 @@ 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 fb_videomode_from_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;
> + if (vm->de)
> + fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
> + fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive);

CodingStyle that you should have spaces around '*'. Also I'm not sure if
that formula is correct. Shouldn't the blanking intervals be counted as
well? So:

unsigned int htotal = vm->hactive + vm->hfront_porch +
  vm->hback_porch + vm->hsync_len;
unsigned int vtotal = vm->vactive + vm->vfront_porch +
  vm->vback_porch + vm->vsync_len;

fbmode->refresh = (vm->pixelclock * 1000) / (htotal * vtotal);

?

> + fbmode->flag = 0;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
> +#endif
> +
> +

Gratuitous blank line.

>  #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..6a3a675 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct vm_area_struct;
>  struct fb_info;
> @@ -714,6 +715,10 @@ 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);
>  
> +#if IS_ENABLED(CONFIG_VIDEOMODE)
> +extern int fb_videomode_from_videomode(struct videomode *vm,
> +    struct fb_videomode *fbmode);
> +#endif
>  /* drivers/video/modedb.c */

These in turn could use an extra blank line.

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/20121114/503e0c89/attachment.pgp>

[PATCH v9 2/6] video: add of helper for videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
[...]
> +optional properties:
> + - native-mode: the native mode for the display, in case multiple modes are
> + provided. When omitted, assume the first node is the native.

I forgot: The first sentence in this description should also start with
a capital letter as you terminate with a full stop.

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/20121114/1a73073a/attachment.pgp>

[PATCH v9 1/6] video: add display_timing and videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:18PM +0100, Steffen Trumtrar wrote:
[...]
> diff --git a/include/linux/videomode.h b/include/linux/videomode.h
[...]
> +int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
> +   unsigned int index);
> +#endif

Nit: should have a blank line before the #endif.

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/20121114/d5905222/attachment.pgp>

[PATCH v9 2/6] video: add of helper for videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
[...]
> +display-timings bindings
> +
> +
> +display timings node

I didn't express myself very clearly here =). The way I think this
should be written is "display-timings node".

> +required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> +   in pixels
> +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
> in
> +   lines
> + - clock-frequency: displayclock in Hz

I still think "displayclock" should be two words: "display clock".

> +/**
> + * of_get_display_timings - parse all display_timing entries from a 
> device_node
> + * @np: device_node with the subnodes
> + **/
> +struct display_timings *of_get_display_timings(struct device_node *np)
> +{
[...]
> + disp->num_timings = 0;
> + disp->native_mode = 0;
> +
> + for_each_child_of_node(timings_np, entry) {
> + struct display_timing *dt;
> +
> + dt = of_get_display_timing(entry);
> + if (!dt) {
> + /* to not encourage wrong devicetrees, fail in case of 
> an error */
> + pr_err("%s: error in timing %d\n", __func__, 
> disp->num_timings+1);
> + goto timingfail;

I believe you're still potentially leaking memory here. In case you have
5 entries for instance, and the last one fails to parse, then this will
cause the memory allocated for the 4 correct entries to be lost.

Can't you just call display_timings_release() in this case and then jump
to dispfail? That would still leak the native_mode device node. Maybe it
would be better to keep timingfail but modify it to free the display
timings with display_timings_release() instead? See below.

> + }
> +
> + if (native_mode == entry)
> + disp->native_mode = disp->num_timings;
> +
> + disp->timings[disp->num_timings] = dt;
> + disp->num_timings++;
> + }
> + of_node_put(timings_np);
> + of_node_put(native_mode);
> +
> + if (disp->num_timings > 0)
> + pr_info("%s: got %d timings. Using timing #%d as default\n", 
> __func__,
> + disp->num_timings , disp->native_mode + 1);
> + else {
> + pr_err("%s: no valid timings specified\n", __func__);
> + display_timings_release(disp);
> + return NULL;
> + }
> + return disp;
> +
> +timingfail:
> + if (native_mode)
> + of_node_put(native_mode);
> + kfree(disp->timings);

Call display_timings_release(disp) instead of kfree(disp->timings)?

> diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
> new file mode 100644
> index 000..4138758
> --- /dev/null
> +++ b/include/linux/of_videomode.h
> @@ -0,0 +1,16 @@
> +/*
> + * Copyright 2012 Steffen Trumtrar 
> + *
> + * videomode of-helpers
> + *
> + * This file is released under the GPLv2
> + */
> +
> +#ifndef __LINUX_OF_VIDEOMODE_H
> +#define __LINUX_OF_VIDEOMODE_H
> +
> +#include 
> +#include 
> +
> +int of_get_videomode(struct device_node *np, struct videomode *vm, int 
> index);
> +#endif /* __LINUX_OF_VIDEOMODE_H */

Nit: should have a blank line before #endif.

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/20121114/a129718a/attachment.pgp>

[PATCH v9 6/6] drm_modes: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get drm_display_mode from devicetree.

Signed-off-by: Steffen Trumtrar 
---
 drivers/gpu/drm/drm_modes.c |   35 ++-
 include/drm/drmP.h  |6 ++
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 42ea099..c3ae5d2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,7 +35,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 

 /**
  * drm_mode_debug_printmodeline - debug print a mode
@@ -540,6 +541,38 @@ int display_mode_from_videomode(struct videomode *vm, 
struct drm_display_mode *d
 EXPORT_SYMBOL_GPL(display_mode_from_videomode);
 #endif

+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode 
*dmode,
+   unsigned int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, , index);
+   if (ret)
+   return ret;
+
+   display_mode_from_videomode(, dmode);
+
+   pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+   vm.vactive, np->name);
+   drm_mode_debug_printmodeline(dmode);
+
+   return 0;
+
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 1e0d846..e8f46a1 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #if defined(__alpha__) || defined(__powerpc__)
 #include/* For pte_wrprotect */
@@ -1459,6 +1460,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
 extern int display_mode_from_videomode(struct videomode *vm,
   struct drm_display_mode *dmode);
 #endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_drm_display_mode(struct device_node *np,
+  struct drm_display_mode *dmode,
+  unsigned int index);
+#endif

 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

[PATCH v9 5/6] drm_modes: add videomode helpers

[Steffen Trumtrar]

Add conversion from videomode to drm_display_mode

Signed-off-by: Steffen Trumtrar 
---
 drivers/gpu/drm/drm_modes.c |   36 
 include/drm/drmP.h  |6 ++
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..42ea099 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
vdisplay, int vrefresh,
 }
 EXPORT_SYMBOL(drm_gtf_mode);

+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode 
*dmode)
+{
+   dmode->hdisplay = vm->hactive;
+   dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+   dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+   dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+   dmode->vdisplay = vm->vactive;
+   dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+   dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+   dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+   dmode->clock = vm->pixelclock / 1000;
+
+   dmode->flags = 0;
+   if (vm->hah)
+   dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+   else
+   dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+   if (vm->vah)
+   dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+   else
+   dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+   if (vm->interlaced)
+   dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+   if (vm->doublescan)
+   dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+   drm_mode_set_name(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_mode_from_videomode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..1e0d846 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #if defined(__alpha__) || defined(__powerpc__)
 #include/* For pte_wrprotect */
 #endif
@@ -1454,6 +1455,11 @@ extern struct drm_display_mode *
 drm_mode_create_from_cmdline_mode(struct drm_device *dev,
  struct drm_cmdline_mode *cmd);

+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int display_mode_from_videomode(struct videomode *vm,
+  struct drm_display_mode *dmode);
+#endif
+
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
 extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

[PATCH v9 4/6] fbmon: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get fb_videomode from devicetree.

Signed-off-by: Steffen Trumtrar 
---
 drivers/video/fbmon.c |   42 +-
 include/linux/fb.h|6 ++
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cccef17..3a48abd 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #ifdef CONFIG_PPC_OF
 #include 
 #include 
@@ -1410,6 +1410,46 @@ int fb_videomode_from_videomode(struct videomode *vm, 
struct fb_videomode *fbmod
 EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
 #endif

+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_fb_videomode(struct fb_videomode *m)
+{
+   pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u 
%u\n",
+m->xres, m->yres, m->refresh, m->pixclock, m->left_margin,
+m->right_margin, m->upper_margin, m->lower_margin,
+m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+   unsigned int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, , index);
+   if (ret)
+   return ret;
+
+   fb_videomode_from_videomode(, fb);
+
+   pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+   vm.vactive, np->name);
+   dump_fb_videomode(fb);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_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 6a3a675..8aeece8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 struct vm_area_struct;
 struct fb_info;
@@ -715,6 +717,10 @@ 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);

+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+  unsigned int index);
+#endif
 #if IS_ENABLED(CONFIG_VIDEOMODE)
 extern int fb_videomode_from_videomode(struct videomode *vm,
   struct fb_videomode *fbmode);
-- 
1.7.10.4

[PATCH v9 3/6] fbmon: add videomode helpers

[Steffen Trumtrar]

Add a function to convert from the generic videomode to a fb_videomode.

Signed-off-by: Steffen Trumtrar 
---
 drivers/video/fbmon.c |   38 ++
 include/linux/fb.h|5 +
 2 files changed, 43 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..cccef17 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_PPC_OF
 #include 
 #include 
@@ -1373,6 +1374,43 @@ 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 fb_videomode_from_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;
+   if (vm->de)
+   fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
+   fbmode->refresh = (vm->pixelclock*1000) / (vm->hactive * vm->vactive);
+   fbmode->flag = 0;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_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..6a3a675 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 struct vm_area_struct;
 struct fb_info;
@@ -714,6 +715,10 @@ 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);

+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(struct videomode *vm,
+  struct fb_videomode *fbmode);
+#endif
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
 extern void fb_var_to_videomode(struct fb_videomode *mode,
-- 
1.7.10.4

[PATCH v9 2/6] video: add of helper for videomode

[Steffen Trumtrar]

This adds support for reading display timings from DT or/and convert one of 
those
timings to a videomode.
The of_display_timing implementation supports multiple children where each
property can have up to 3 values. All children are read into an array, that
can be queried.
of_get_videomode converts exactly one of that timings to a struct videomode.

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Philipp Zabel 
Acked-by: Stephen Warren 
---
 .../devicetree/bindings/video/display-timings.txt  |  107 ++
 drivers/video/Kconfig  |   13 ++
 drivers/video/Makefile |2 +
 drivers/video/of_display_timing.c  |  211 
 drivers/video/of_videomode.c   |   47 +
 include/linux/of_display_timings.h |   20 ++
 include/linux/of_videomode.h   |   16 ++
 7 files changed, 416 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 include/linux/of_display_timings.h
 create mode 100644 include/linux/of_videomode.h

diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
index 000..c9d9e1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,107 @@
+display-timings bindings
+
+
+display timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: the native mode for the display, in case multiple modes are
+   provided. When omitted, assume the first node is the native.
+
+timings subnode
+---
+
+required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+   in pixels
+   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+   lines
+ - clock-frequency: displayclock in Hz
+
+optional properties:
+ - hsync-active: Hsync pulse is active low/high/ignored
+ - vsync-active: Vsync pulse is active low/high/ignored
+ - de-active: Data-Enable pulse is active low/high/ignored
+ - pixelclk-inverted: pixelclock is inverted/non-inverted/ignored
+ - interlaced (bool)
+ - doublescan (bool)
+
+All the optional properties that are not bool follow the following logic:
+<1>: high active
+<0>: low active
+omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The 
devicetree
+representation corresponds to the one commonly found in datasheets for 
displays.
+If a display supports multiple signal timings, the native-mode can be 
specified.
+
+The parameters are defined as
+
+struct display_timing
+=
+
+  +--+-+--+---+
+  |  |?|  |   |
+  |  ||vback_porch |  |   |
+  |  |?|  |   |
+  +--###--+---+
+  |  #?#  |   |
+  |  #|#  |   |
+  |  hback   #|#  hfront  | hsync |
+  |   porch  #|   hactive  #  porch   |  len  |
+  |<>#<---+--->#<>|<->|
+  |  #|#  |   |
+  |  #|vactive #  |   |
+  |  #|#  |   |
+  |  #?#  |   |
+  +--###--+---+
+  |  |?|  |   |
+  |  ||vfront_porch|  |   |
+  |  |?|  |   |
+  +--+-+--+---+
+  |  |?|  |   |
+  |  ||vsync_len   |  |   |
+  |  |?|  |   |
+  +--+-+--+---+
+
+
+Example:
+
+   display-timings {
+   native-mode = <>;
+   timing0: 1920p24 {
+   /* 1920x1080p24 */
+   

[PATCH v9 1/6] video: add display_timing and videomode

[Steffen Trumtrar]

Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.

Every timing parameter can be specified as a single value or a range
.

Also, add helper functions to convert from display timings to a generic 
videomode
structure. This videomode can then be converted to the corresponding subsystem
mode representation (e.g. fb_videomode).

Signed-off-by: Steffen Trumtrar 
---
 drivers/video/Kconfig  |6 
 drivers/video/Makefile |2 ++
 drivers/video/display_timing.c |   24 ++
 drivers/video/videomode.c  |   45 ++
 include/linux/display_timing.h |   69 
 include/linux/videomode.h  |   39 +++
 6 files changed, 185 insertions(+)
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/videomode.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
  This framework adds support for low-level control of the video 
  output switch.

+config DISPLAY_TIMING
+   bool
+
+config VIDEOMODE
+   bool
+
 menuconfig FB
tristate "Support for frame buffer devices"
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL)  += vfb.o

 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..ac9bbbc
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , 
Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include 
+#include 
+#include 
+
+void display_timings_release(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);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..087374a
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,45 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , 
Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ unsigned int index)
+{
+   struct display_timing *dt;
+
+   dt = display_timings_get(disp, index);
+   if (!dt)
+   return -EINVAL;
+
+   vm->pixelclock = display_timing_get_value(>pixelclock, 0);
+   vm->hactive = display_timing_get_value(>hactive, 0);
+   vm->hfront_porch = display_timing_get_value(>hfront_porch, 0);
+   vm->hback_porch = display_timing_get_value(>hback_porch, 0);
+   vm->hsync_len = display_timing_get_value(>hsync_len, 0);
+
+   vm->vactive = display_timing_get_value(>vactive, 0);
+   vm->vfront_porch = display_timing_get_value(>vfront_porch, 0);
+   vm->vback_porch = display_timing_get_value(>vback_porch, 0);
+   vm->vsync_len = display_timing_get_value(>vsync_len, 0);
+
+   vm->vah = dt->vsync_pol_active;
+   vm->hah = dt->hsync_pol_active;
+   vm->de = dt->de_pol_active;
+   vm->pixelclk_pol = dt->pixelclk_pol;
+
+   vm->interlaced = dt->interlaced;
+   vm->doublescan = dt->doublescan;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_from_timing);
diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h
new file mode 100644
index 000..caee2a8
--- /dev/null
+++ b/include/linux/display_timing.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2012 Steffen Trumtrar 
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_DISPLAY_TIMINGS_H
+#define __LINUX_DISPLAY_TIMINGS_H
+
+#include 
+
+struct timing_entry {
+   u32 min;
+   u32 typ;
+   u32 max;
+};
+
+struct display_timing {
+   struct timing_entry pixelclock;
+
+   struct timing_entry hactive;
+   struct timing_entry hfront_porch;
+   struct timing_entry hback_porch;
+   struct timing_entry hsync_len;
+
+   struct timing_entry vactive;
+   struct timing_entry vfront_porch;
+   struct timing_entry vback_porch;
+ 

[PATCH v9 0/6] of: add display helper

[Steffen Trumtrar]

Hi!

Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct 
foo))
- include headers were necessary
- misc minor bufixes

Regards,
Steffen


Steffen Trumtrar (6):
  video: add display_timing and videomode
  video: add of helper for videomode
  fbmon: add videomode helpers
  fbmon: add of_videomode helpers
  drm_modes: add videomode helpers
  drm_modes: add of_videomode helpers

 .../devicetree/bindings/video/display-timings.txt  |  107 ++
 drivers/gpu/drm/drm_modes.c|   69 +++
 drivers/video/Kconfig  |   19 ++
 drivers/video/Makefile |4 +
 drivers/video/display_timing.c |   24 +++
 drivers/video/fbmon.c  |   78 
 drivers/video/of_display_timing.c  |  211 
 drivers/video/of_videomode.c   |   47 +
 drivers/video/videomode.c  |   45 +
 include/drm/drmP.h |   12 ++
 include/linux/display_timing.h |   69 +++
 include/linux/fb.h |   11 +
 include/linux/of_display_timings.h |   20 ++
 include/linux/of_videomode.h   |   16 ++
 include/linux/videomode.h  |   39 
 15 files changed, 771 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/of_display_timings.h
 create mode 100644 include/linux/of_videomode.h
 create mode 100644 include/linux/videomode.h

-- 
1.7.10.4

[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test

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

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Other   |Video(DRI - non Intel)
 AssignedTo|drivers_other at kernel-bugs.o |drivers_video-dri at 
kernel-bu
   |sdl.org |gs.osdl.org




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

linux-next: Tree for Nov 14 (gpu/drm/i915)

[Andrew Morton]

On Wed, 14 Nov 2012 11:41:49 -0800
Randy Dunlap  wrote:

> On 11/13/2012 09:30 PM, Stephen Rothwell wrote:
> 
> > Hi all,
> > 
> > News: next-20121115 (i.e. tomorrow) will be the last release until
> > next-20121126 (which should be just be after -rc7, I guess - assuming
> > that Linus does not release v3.7 before then), so if you want something
> > in linux-next for a reasonable amount of testing, it should probably be
> > committed tomorrow.
> > 
> > Changes since 20121113:
> > 
> 
> 
> 
> on i386:
> 
> ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!
> 
> Reference to that symbol is found in
> i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
> i915_gem_execbuffer.c:
> 
> static struct eb_objects *
> eb_create(int size)
> {
>   struct eb_objects *eb;
>   int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
>   BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));
> 

Where to start.

- eb_create() has no business assuming that the hlist_head has any
  particular size.  We could easily add some conditionally-compiled
  debug fields in there, and drm blows up.

- The assertion is obviously true at present, so I assume that gcc
  screwed up and failed to reduce all that to a compile-time constant.

- We have a BUILD_BUG_ON_NOT_POWER_OF_2().  Use it?

- This code is using PAGE_SIZE to scale a kernel data structure. 
  PAGE_SIZE can vary by a factor of 16, depending on Kconfig.  This
  can result in 64k PAGE_SIZE machines exhibiting different beahviour
  from that which the testers saw.

  Don't do it.  It's better to hard-wire 4096.

[PATCH v8 1/6] video: add display_timing and videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:10:15PM +0100, Steffen Trumtrar wrote:
> On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote:
> > On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote:
> > > On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
> > > > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
> > > > [...]
> > > > > diff --git a/drivers/video/display_timing.c 
> > > > > b/drivers/video/display_timing.c
> > > > [...]
> > > > > +void display_timings_release(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);
> > > > > +}
> > > > 
> > > > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
> > > > be used from modules.
> > > > 
> > > > Thierry
> > > 
> > > Yes. Just in time. I was just starting to type the send-email command ;-)
> > 
> > Great! In that case don't forget to also look at my other email before
> > sending. =)
> > 
> Sure.

Besides those comments (and those from other people) I think your
patchset is in pretty good shape. Have you thought about how and when
you want to get things merged?

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/20121114/9bcd3f0a/attachment.pgp>

[PATCH v8 1/6] video: add display_timing and videomode

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote:
> On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote:
> > On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
> > > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
> > > [...]
> > > > diff --git a/drivers/video/display_timing.c 
> > > > b/drivers/video/display_timing.c
> > > [...]
> > > > +void display_timings_release(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);
> > > > +}
> > > 
> > > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
> > > be used from modules.
> > > 
> > > Thierry
> > 
> > Yes. Just in time. I was just starting to type the send-email command ;-)
> 
> Great! In that case don't forget to also look at my other email before
> sending. =)
> 
Sure.


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

[PATCH v8 1/6] video: add display_timing and videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote:
> On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
> > On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
> > [...]
> > > diff --git a/drivers/video/display_timing.c 
> > > b/drivers/video/display_timing.c
> > [...]
> > > +void display_timings_release(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);
> > > +}
> > 
> > I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
> > be used from modules.
> > 
> > Thierry
> 
> Yes. Just in time. I was just starting to type the send-email command ;-)

Great! In that case don't forget to also look at my other email before
sending. =)

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/20121114/413fe4c5/attachment.pgp>

[PATCH v8 2/6] video: add of helper for videomode

[Thierry Reding]

On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
[...]
> diff --git a/include/linux/of_display_timings.h 
> b/include/linux/of_display_timings.h
[...]
> +#ifndef __LINUX_OF_DISPLAY_TIMINGS_H
> +#define __LINUX_OF_DISPLAY_TIMINGS_H
> +
> +#include 
> +
> +#define OF_USE_NATIVE_MODE -1
> +
> +struct display_timings *of_get_display_timings(struct device_node *np);
> +int of_display_timings_exists(struct device_node *np);

This either needs to include linux/of.h or a forward declaration of
struct device_node. Otherwise this will fail to compile if the file
where this is included from doesn't pull linux/of.h in explicitly.

> diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
[...]
> +#ifndef __LINUX_OF_VIDEOMODE_H
> +#define __LINUX_OF_VIDEOMODE_H
> +
> +#include 
> +
> +int of_get_videomode(struct device_node *np, struct videomode *vm, int 
> index);

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/20121114/0fed625a/attachment.pgp>

[PATCH v8 1/6] video: add display_timing and videomode

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
> On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
> [...]
> > diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
> [...]
> > +void display_timings_release(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);
> > +}
> 
> I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
> be used from modules.
> 
> Thierry

Yes. Just in time. I was just starting to type the send-email command ;-)

Regards,
Steffen


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

[PATCH 1/1] media: Entities with sink pads must have at least one enabled link

[Laurent Pinchart]

Hi Sylwester,

On Wednesday 14 November 2012 10:23:19 Sylwester Nawrocki wrote:
> On 11/13/2012 03:24 PM, Sakari Ailus wrote:
> > Hi all,
> > 
> > Comments would be appreciated, either positive or negative. The omap3isp
> > driver does the same check itself currently, but I think this is more
> > generic than that.
> > 
> > Thanks.
> > 
> > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote:
> >> If an entity has sink pads, at least one of them must be connected to
> >> another pad with an enabled link. If a driver with multiple sink pads has
> >> more strict requirements the check should be done in the driver itself.
> >> 
> >> Just requiring one sink pad is connected with an enabled link is enough
> >> API-wise: entities with sink pads with only disabled links should not be
> >> allowed to stream in the first place, but also in a different operation
> >> mode a device might require only one of its pads connected with an
> >> active link.
> >> 
> >> If an entity has an ability to function as a source entity another
> >> logical entity connected to the aforementioned one should be used for the
> >> purpose.
> 
> Why not leave it to individual drivers ? I'm not sure if it is a good idea
> not to allow an entity with sink pads to be used as a source only. It might
> be appropriate for most of the cases but likely not all. I'm inclined not to
> add this requirement in the API. Just my opinion though.

I have mixed feelings about this patch too, which is why I've asked Sakari to 
cross-post it. It's pretty easy to add this check to the core now, but pushing 
it back to drivers late if we realize it's too restrictive would be difficult. 
I think my preference would go for a helper function that drivers can use, 
possibly first waiting until a second driver requires this kind of checks 
before implementing it.

-- 
Regards,

Laurent Pinchart

[PATCH v8 1/6] video: add display_timing and videomode

[Thierry Reding]

On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
[...]
> diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
[...]
> +void display_timings_release(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);
> +}

I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
be used from modules.

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/20121114/cff56431/attachment.pgp>

linux-next: Tree for Nov 14 (gpu/drm/i915)

[Randy Dunlap]

On 11/13/2012 09:30 PM, Stephen Rothwell wrote:

> Hi all,
> 
> News: next-20121115 (i.e. tomorrow) will be the last release until
> next-20121126 (which should be just be after -rc7, I guess - assuming
> that Linus does not release v3.7 before then), so if you want something
> in linux-next for a reasonable amount of testing, it should probably be
> committed tomorrow.
> 
> Changes since 20121113:
> 



on i386:

ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!

Reference to that symbol is found in
i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
i915_gem_execbuffer.c:

static struct eb_objects *
eb_create(int size)
{
struct eb_objects *eb;
int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));


-- 
~Randy

[PATCH v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR

[Andy Gross]

Return -ENOMEM if dmm_txn_init cannot allocate a refill engine.

v2: Fix typing issue seen with newer compilers

Signed-off-by: Andy Gross 
---
 drivers/staging/omapdrm/omap_dmm_tiler.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 3ae3955..1499521 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -279,7 +279,7 @@ static int fill(struct tcm_area *area, struct page **pages,

txn = dmm_txn_init(omap_dmm, area->tcm);
if (IS_ERR_OR_NULL(txn))
-   return PTR_ERR(txn);
+   return -ENOMEM;

tcm_for_each_slice(slice, *area, area_s) {
struct pat_area p_area = {
-- 
1.7.5.4

Regression due to "mm: fix-up zone present pages"

[Daniel Vetter]

Hi all,

Our QA noticed a regression in one of our i915/GEM testcases in 3.7:

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

Direct link to dmesg of the machine:
https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that the
machine is 32bit, which seems to be important since Chris Wilson
confirmed the bug on his 32bit Sandybridge machine, whereas mine here
with a 64bit kernel works flawlessly.

The testcase is gem_tiled_swapping:

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/gem_tiled_swapping.c

Quick high-level description of the workload:

It allocates a working set larger than available memory, then fills it
by writing it through the gpu gart (required to get a linear view of
tiled buffers) and afterwards reads it to check whether anything got
corrupted. Since the working set is too large to fit into ram, this
will force all buffers through swap. We've written this testcase to
exercise the reswizzle swapin path since some platforms have a tiling
layout depending upon physical pfn (awesome feature btw), but not snb.
So within the kernel this workload simply grabs the backing storage
from shmemfs with shmem_read_mapping_page_gfp and then binds them into
the gpu pagetables (the GTT). This happens in the i915_gem_fault
fucntion. Unbinding in this workload happens either directly (if the
gem code can't get enough memory) or through our shrinker
(i915_gem_inactive_shrink). Swapout is then left to shmemfs to handle.
All the above stuff is in drivers/gpu/drm/i915_gem.c

Testcase fails because it detects a mismatch between what has been
written and what has been read back.

Our qa people bisected the regression to

commit 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125
Author: Jianguo Wu 
Date:   Mon Oct 8 16:33:06 2012 -0700

mm: fix-up zone present pages

and confirmed the revert on top of the latest drm-intel-nightly branch
(which is based on top of 3.7-rc2 and contains the -next stuff for
3.8). They've also tested the for-QA branch which had latest Linus
upstream merged in, which did not fix the problem. For reference the
intel trees are at (but I don't think it matters really that it's not
plain upstream, nothing really changed in the relevant i915/gem paths
compared to upstream):

http://cgit.freedesktop.org/~danvet/drm-intel

I have no idea how that early boot zone init fix could even corrupt
swapping in such a fashion, so ideas highly welcome. QA people are
cc'ed, and hopefully I haven't missed anyone else on the cc list.

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

[PATCH v2 1/2] drm: Add NVIDIA Tegra20 support

[Mark Zhang]

On 11/14/2012 01:37 AM, Stephen Warren wrote:
> On 11/13/2012 12:15 AM, Mark Zhang wrote:
>> On 11/13/2012 05:55 AM, Thierry Reding wrote:
>>> This commit adds a KMS driver for the Tegra20 SoC. This includes basic
>>> support for host1x and the two display controllers found on the Tegra20
>>> SoC. Each display controller can drive a separate RGB/LVDS output.
> 
> Mark, when you're replying to a long patch, it's useful to quote only
> the code you're directly responding to; slowly scrolling through your
> email to find your comments is rather error-prone and time-consuming.
>

Sure. Sorry for the inconvenience. Thanks.

> Thanks for the feedback though.
> 

[PATCH 1/1] media: Entities with sink pads must have at least one enabled link

[Sylwester Nawrocki]

Hi Sakari,

On 11/13/2012 03:24 PM, Sakari Ailus wrote:
> Hi all,
> 
> Comments would be appreciated, either positive or negative. The omap3isp
> driver does the same check itself currently, but I think this is more
> generic than that.
> 
> Thanks.
> 
> On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote:
>> If an entity has sink pads, at least one of them must be connected to
>> another pad with an enabled link. If a driver with multiple sink pads has
>> more strict requirements the check should be done in the driver itself.
>>
>> Just requiring one sink pad is connected with an enabled link is enough
>> API-wise: entities with sink pads with only disabled links should not be
>> allowed to stream in the first place, but also in a different operation mode
>> a device might require only one of its pads connected with an active link.
>>
>> If an entity has an ability to function as a source entity another logical
>> entity connected to the aforementioned one should be used for the purpose.

Why not leave it to individual drivers ? I'm not sure if it is a good idea
not to allow an entity with sink pads to be used as a source only. It might
be appropriate for most of the cases but likely not all. I'm inclined not to
add this requirement in the API. Just my opinion though.

--
Thanks,
Sylwester

[PATCH] drm/ttm: remove unneeded preempt_disable/enable

[Thomas Hellstrom]

On 11/09/2012 01:10 PM, Akinobu Mita wrote:
> It is unnecessary to disable preemption explicitly while calling
> copy_highpage().  Because copy_highpage() will do it again through
> kmap_atomic/kunmap_atomic.
>
> Signed-off-by: Akinobu Mita 
> Cc: dri-devel at lists.freedesktop.org
> Cc: David Airlie 
> ---
>   drivers/gpu/drm/ttm/ttm_tt.c | 4 
>   1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index bf82601..7d759a4 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -308,9 +308,7 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
>   if (unlikely(to_page == NULL))
>   goto out_err;
>   
> - preempt_disable();
>   copy_highpage(to_page, from_page);
> - preempt_enable();
>   page_cache_release(from_page);
>   }
>   
> @@ -358,9 +356,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
> *persistent_swap_storage)
>   ret = PTR_ERR(to_page);
>   goto out_err;
>   }
> - preempt_disable();
>   copy_highpage(to_page, from_page);
> - preempt_enable();
>   set_page_dirty(to_page);
>   mark_page_accessed(to_page);
>   page_cache_release(to_page);

Reviewed-by: Thomas Hellstrom 

[PATCH] ttm_get_pages() will OOPS with highmem allocation

[Thomas Hellstrom]

On 11/13/2012 07:31 PM, Jonathan Morton wrote:
> Reposting from this kernel bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=50241
>
> I've tested the patch and it solves a highly repeatable OOPS with the
> CedarView driver that I'm porting.
>
>
> >From 3552913d3a1c2d3c4ce158e91dc18cd12b522cb2 Mon Sep 17 00:00:00 2001
> From: Yakui Zhao 
> Date: Tue, 7 Feb 2012 15:33:13 -0500
> Subject: [PATCH] Clear the ttm page allocated from high memory zone correctly
>
> The TTM page can be allocated from high memory. In such case it is
> wrong to use the page_address(page) as the virtual address for the high memory
> page.
>
> Signed-off-by: Zhao Yakui 
> ---
>   drivers/gpu/drm/ttm/ttm_page_alloc.c |5 -
>   1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index d948575..df976d9 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -708,7 +708,10 @@ int ttm_get_pages(struct list_head *pages, int flags,
>   /* clear the pages coming from the pool if requested */
>   if (flags & TTM_PAGE_FLAG_ZERO_ALLOC) {
>   list_for_each_entry(p, pages, lru) {
> - clear_page(page_address(p));
> + if (PageHighMem(p))
> + clear_highpage(p);
> + else
> + clear_page(page_address(p));
>   }
>   }
>   

This is a pretty bad bug. I think the only reason it hasn't been hit 
more often is that TTM_PAGE_FLAG_ZERO_ALLOC may not be used that often.
Please resend this patch with

Cc: stable at vger.kernel.org
Reviewed-by: Thomas Hellstrom 

Thanks,
Thomas

[PATCH] drm/radeon: fix logic error in atombios_encoders.c

[Alex Deucher]

On Wed, Nov 14, 2012 at 9:32 AM, Michel D?nzer  wrote:
> On Mit, 2012-11-14 at 09:13 -0500, alexdeucher at gmail.com wrote:
>> From: Alex Deucher 
>>
>> Fixes:
>> https://bugzilla.kernel.org/show_bug.cgi?id=50431
>>
>> Reported-by: David Binderman 
>> Signed-off-by: Alex Deucher 
>> Cc: stable at vger.kernel.org
>
> Reviewed-by: Michel D?nzer 
>
>
>>  drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index ba498f8..010bae1 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
>> *encoder, int mode)
>>   atombios_dig_transmitter_setup(encoder, 
>> ATOM_TRANSMITTER_ACTION_SETUP, 0, 0);
>>   atombios_dig_transmitter_setup(encoder, 
>> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
>>   /* some early dce3.2 boards have a bug in their 
>> transmitter control table */
>> - if ((rdev->family != CHIP_RV710) || (rdev->family != 
>> CHIP_RV730))
>> + if ((rdev->family != CHIP_RV710) && (rdev->family != 
>> CHIP_RV730))
>
> Ouch, the compiler didn't warn about this always evaluating to true?

Nope.  At least not on any of my machines.

>
>
> --
> Earthling Michel D?nzer   |   http://www.amd.com
> Libre software enthusiast |  Debian, X and DRI developer

[PATCH] drm/radeon: fix logic error in atombios_encoders.c

[alexdeuc...@gmail.com]

From: Alex Deucher 

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

Reported-by: David Binderman 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index ba498f8..010bae1 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_SETUP, 0, 0);
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
/* some early dce3.2 boards have a bug in their 
transmitter control table */
-   if ((rdev->family != CHIP_RV710) || (rdev->family != 
CHIP_RV730))
+   if ((rdev->family != CHIP_RV710) && (rdev->family != 
CHIP_RV730))
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
}
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && 
connector) {
-- 
1.7.7.5

[Bug 41971] [kms] Muxless radeon takes 20 seconds to fetch rom

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

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

Mike Lothian  changed:

   What|Removed |Added

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

--- Comment #17 from Mike Lothian  ---
I'm not sure when this was fixed but it's now no longer an issue

-- 
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/20121114/23743209/attachment-0001.html>

Re: [PATCH] ttm_get_pages() will OOPS with highmem allocation

[Thomas Hellstrom]

On 11/13/2012 07:31 PM, Jonathan Morton wrote:

Reposting from this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=50241

I've tested the patch and it solves a highly repeatable OOPS with the
CedarView driver that I'm porting.


From 3552913d3a1c2d3c4ce158e91dc18cd12b522cb2 Mon Sep 17 00:00:00 2001
From: Yakui Zhao yakui.z...@intel.com
Date: Tue, 7 Feb 2012 15:33:13 -0500
Subject: [PATCH] Clear the ttm page allocated from high memory zone correctly

The TTM page can be allocated from high memory. In such case it is
wrong to use the page_address(page) as the virtual address for the high memory
page.

Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index d948575..df976d9 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -708,7 +708,10 @@ int ttm_get_pages(struct list_head *pages, int flags,
/* clear the pages coming from the pool if requested */
if (flags  TTM_PAGE_FLAG_ZERO_ALLOC) {
list_for_each_entry(p, pages, lru) {
-   clear_page(page_address(p));
+   if (PageHighMem(p))
+   clear_highpage(p);
+   else
+   clear_page(page_address(p));
}
}
  


This is a pretty bad bug. I think the only reason it hasn't been hit 
more often is that TTM_PAGE_FLAG_ZERO_ALLOC may not be used that often.

Please resend this patch with

Cc: sta...@vger.kernel.org
Reviewed-by: Thomas Hellstrom thellst...@vmware.com

Thanks,
Thomas


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

Re: [PATCH] drm/ttm: remove unneeded preempt_disable/enable

[Thomas Hellstrom]

On 11/09/2012 01:10 PM, Akinobu Mita wrote:

It is unnecessary to disable preemption explicitly while calling
copy_highpage().  Because copy_highpage() will do it again through
kmap_atomic/kunmap_atomic.

Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie airl...@linux.ie
---
  drivers/gpu/drm/ttm/ttm_tt.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index bf82601..7d759a4 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -308,9 +308,7 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
if (unlikely(to_page == NULL))
goto out_err;
  
-		preempt_disable();

copy_highpage(to_page, from_page);
-   preempt_enable();
page_cache_release(from_page);
}
  
@@ -358,9 +356,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file *persistent_swap_storage)

ret = PTR_ERR(to_page);
goto out_err;
}
-   preempt_disable();
copy_highpage(to_page, from_page);
-   preempt_enable();
set_page_dirty(to_page);
mark_page_accessed(to_page);
page_cache_release(to_page);


Reviewed-by: Thomas Hellstrom thellst...@vmware.com

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

[PATCH 0/2] drm/exynos: fix invalid memory access

[Inki Dae]

This patch releases the fb pended by page flip after fbdev is
restored propely. And fixes invalid memory access when drm is
released while doing pageflip.

This patch makes fb's refcount to be increased when setcrtc and
pageflip are requested. In other words, it increases fb's refcount
only if dma is going to access memory region to fb and decreases
old fb's because the old fb isn't accessed by dma anymore.

This could guarantee releasing gem buffer to the fb after dma
access to the gem buffer has been completed.

Inki Dae (2):
  drm/exynos: remove unnecessary code.
  drm/exynos: release fb pended by page flip

 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   19 +++-
 5 files changed, 96 insertions(+), 3 deletions(-)

-- 
1.7.4.1

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

[PATCH 1/2] drm/exynos: remove unnecessary code.

[Inki Dae]

plane-fb will be set to new fb after update_plane callback is called
by drm_mode_set_plane()

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 60b877a..862ca1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -204,7 +204,6 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
return ret;
 
plane-crtc = crtc;
-   plane-fb = crtc-fb;
 
exynos_plane_commit(plane);
exynos_plane_dpms(plane, DRM_MODE_DPMS_ON);
-- 
1.7.4.1

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

[PATCH 2/2] drm/exynos: release fb pended by page flip

[Inki Dae]

This patch releases the fb pended by page flip after fbdev is
restored propely. And fixes invalid memory access when drm is
released while doing pageflip.

This patch makes fb's refcount to be increased when setcrtc and
pageflip are requested. In other words, it increases fb's refcount
only if dma is going to access memory region to fb and decreases
old fb's because the old fb isn't accessed by dma anymore.

This could guarantee releasing gem buffer to the fb after dma
access to the gem buffer has been completed.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   23 
 drivers/gpu/drm/exynos/exynos_drm_fb.h|6 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   18 +++-
 5 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2efa4b0..2a52b7e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,6 +32,7 @@
 #include exynos_drm_drv.h
 #include exynos_drm_encoder.h
 #include exynos_drm_plane.h
+#include exynos_drm_fb.h
 
 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc,\
drm_crtc)
@@ -137,8 +138,26 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
return ret;
 
plane-crtc = crtc;
+
+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
plane-fb = crtc-fb;
 
+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane-fb);
+
exynos_drm_fn_encoder(crtc, pipe, exynos_drm_encoder_crtc_pipe);
 
return 0;
@@ -168,6 +187,24 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
x, y, crtc_w, crtc_h);
if (ret)
return ret;
+   /*
+* If old_fb exists, unreference the fb.
+*
+* This means that memory region to the fb isn't accessed by the dma
+* of this plane anymore.
+*/
+   if (old_fb)
+   drm_framebuffer_unreference(old_fb);
+
+   plane-fb = crtc-fb;
+
+   /*
+* Take a reference to new fb.
+*
+* Taking a reference means that this plane's dma is going to access
+* memory region to the new fb.
+*/
+   drm_framebuffer_reference(plane-fb);
 
exynos_drm_crtc_commit(crtc);
 
@@ -243,7 +280,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 
crtc-fb = fb;
ret = exynos_drm_crtc_mode_set_base(crtc, crtc-x, crtc-y,
-   NULL);
+   old_fb);
if (ret) {
crtc-fb = old_fb;
 
@@ -254,6 +291,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 
goto out;
}
+
+   exynos_drm_fb_set_pending(old_fb, false);
+   exynos_drm_fb_set_pending(fb, true);
}
 out:
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ef4cd3..f100035 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -43,11 +43,15 @@
  * @fb: drm framebuffer obejct.
  * @buf_cnt: a buffer count to drm framebuffer.
  * @exynos_gem_obj: array of exynos specific gem object containing a gem 
object.
+ * @pending: indicate whehter a fb was pended by page flip.
+ * if true, the fb should be released after fbdev is restored to avoid
+ * accessing invalid memory region.
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
unsigned intbuf_cnt;
struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
+   boolpending;
 };
 
 static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
@@ -228,6 +232,25 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return fb;
 }
 
+void exynos_drm_fb_set_pending(struct drm_framebuffer *fb, bool pending)
+{
+   struct exynos_drm_fb *exynos_fb;
+
+   exynos_fb = to_exynos_fb(fb);
+
+   exynos_fb-pending = pending;
+}
+
+void exynos_drm_release_pended_fb(struct drm_framebuffer *fb)
+{
+

Re: [PATCH] drm: exynos: fix for loosing display mode header during mode adjustment

[Inki Dae]

2012/11/9 Rahul Sharma rahul.sha...@samsung.com

 This patch is to preserve the display mode header during the mode
 adjustment.
 Display mode header is overwritten with the adjusted mode header which is
 throwing the stack dump.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c |8 
  1 files changed, 8 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index ee110c9..c7844ea 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -1974,6 +1974,8 @@ static void hdmi_mode_fixup(void *ctx, struct
 drm_connector *connector,
  {
 struct drm_display_mode *m;
 struct hdmi_context *hdata = ctx;
 +   struct drm_mode_object base;
 +   struct list_head head;


Remove base and head,


 int index;

 DRM_DEBUG_KMS([%d] %s\n, __LINE__, __func__);
 @@ -2002,7 +2004,13 @@ static void hdmi_mode_fixup(void *ctx, struct
 drm_connector *connector,
 if (index = 0) {


And declare them here.

Thanks,
Inki Dae


 DRM_INFO(desired mode doesn't exist so\n);
 DRM_INFO(use the most suitable mode among
 modes.\n);
 +
 +   /* preserve display mode header while copying. */
 +   head = adjusted_mode-head;
 +   base = adjusted_mode-base;
 memcpy(adjusted_mode, m, sizeof(*m));
 +   adjusted_mode-head = head;
 +   adjusted_mode-base = base;
 break;
 }
 }
 --
 1.7.0.4

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

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

Re: [PATCH 1/1] media: Entities with sink pads must have at least one enabled link

[Sylwester Nawrocki]

Hi Sakari,

On 11/13/2012 03:24 PM, Sakari Ailus wrote:
 Hi all,
 
 Comments would be appreciated, either positive or negative. The omap3isp
 driver does the same check itself currently, but I think this is more
 generic than that.
 
 Thanks.
 
 On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote:
 If an entity has sink pads, at least one of them must be connected to
 another pad with an enabled link. If a driver with multiple sink pads has
 more strict requirements the check should be done in the driver itself.

 Just requiring one sink pad is connected with an enabled link is enough
 API-wise: entities with sink pads with only disabled links should not be
 allowed to stream in the first place, but also in a different operation mode
 a device might require only one of its pads connected with an active link.

 If an entity has an ability to function as a source entity another logical
 entity connected to the aforementioned one should be used for the purpose.

Why not leave it to individual drivers ? I'm not sure if it is a good idea
not to allow an entity with sink pads to be used as a source only. It might
be appropriate for most of the cases but likely not all. I'm inclined not to
add this requirement in the API. Just my opinion though.

--
Thanks,
Sylwester

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

Regression due to mm: fix-up zone present pages

[Daniel Vetter]

Hi all,

Our QA noticed a regression in one of our i915/GEM testcases in 3.7:

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

Direct link to dmesg of the machine:
https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that the
machine is 32bit, which seems to be important since Chris Wilson
confirmed the bug on his 32bit Sandybridge machine, whereas mine here
with a 64bit kernel works flawlessly.

The testcase is gem_tiled_swapping:

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/gem_tiled_swapping.c

Quick high-level description of the workload:

It allocates a working set larger than available memory, then fills it
by writing it through the gpu gart (required to get a linear view of
tiled buffers) and afterwards reads it to check whether anything got
corrupted. Since the working set is too large to fit into ram, this
will force all buffers through swap. We've written this testcase to
exercise the reswizzle swapin path since some platforms have a tiling
layout depending upon physical pfn (awesome feature btw), but not snb.
So within the kernel this workload simply grabs the backing storage
from shmemfs with shmem_read_mapping_page_gfp and then binds them into
the gpu pagetables (the GTT). This happens in the i915_gem_fault
fucntion. Unbinding in this workload happens either directly (if the
gem code can't get enough memory) or through our shrinker
(i915_gem_inactive_shrink). Swapout is then left to shmemfs to handle.
All the above stuff is in drivers/gpu/drm/i915_gem.c

Testcase fails because it detects a mismatch between what has been
written and what has been read back.

Our qa people bisected the regression to

commit 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125
Author: Jianguo Wu wujian...@huawei.com
Date:   Mon Oct 8 16:33:06 2012 -0700

mm: fix-up zone present pages

and confirmed the revert on top of the latest drm-intel-nightly branch
(which is based on top of 3.7-rc2 and contains the -next stuff for
3.8). They've also tested the for-QA branch which had latest Linus
upstream merged in, which did not fix the problem. For reference the
intel trees are at (but I don't think it matters really that it's not
plain upstream, nothing really changed in the relevant i915/gem paths
compared to upstream):

http://cgit.freedesktop.org/~danvet/drm-intel

I have no idea how that early boot zone init fix could even corrupt
swapping in such a fashion, so ideas highly welcome. QA people are
cc'ed, and hopefully I haven't missed anyone else on the cc list.

Yours, 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 v8 1/6] video: add display_timing and videomode

[Thierry Reding]

On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
[...]
 diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
[...]
 +void display_timings_release(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);
 +}

I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
be used from modules.

Thierry


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

Re: [PATCH 1/1] media: Entities with sink pads must have at least one enabled link

[Laurent Pinchart]

Hi Sylwester,

On Wednesday 14 November 2012 10:23:19 Sylwester Nawrocki wrote:
 On 11/13/2012 03:24 PM, Sakari Ailus wrote:
  Hi all,
  
  Comments would be appreciated, either positive or negative. The omap3isp
  driver does the same check itself currently, but I think this is more
  generic than that.
  
  Thanks.
  
  On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote:
  If an entity has sink pads, at least one of them must be connected to
  another pad with an enabled link. If a driver with multiple sink pads has
  more strict requirements the check should be done in the driver itself.
  
  Just requiring one sink pad is connected with an enabled link is enough
  API-wise: entities with sink pads with only disabled links should not be
  allowed to stream in the first place, but also in a different operation
  mode a device might require only one of its pads connected with an
  active link.
  
  If an entity has an ability to function as a source entity another
  logical entity connected to the aforementioned one should be used for the
  purpose.
 
 Why not leave it to individual drivers ? I'm not sure if it is a good idea
 not to allow an entity with sink pads to be used as a source only. It might
 be appropriate for most of the cases but likely not all. I'm inclined not to
 add this requirement in the API. Just my opinion though.

I have mixed feelings about this patch too, which is why I've asked Sakari to 
cross-post it. It's pretty easy to add this check to the core now, but pushing 
it back to drivers late if we realize it's too restrictive would be difficult. 
I think my preference would go for a helper function that drivers can use, 
possibly first waiting until a second driver requires this kind of checks 
before implementing it.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v8 1/6] video: add display_timing and videomode

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
 On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
 [...]
  diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
 [...]
  +void display_timings_release(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);
  +}
 
 I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
 be used from modules.
 
 Thierry

Yes. Just in time. I was just starting to type the send-email command ;-)

Regards,
Steffen


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 2/6] video: add of helper for videomode

[Thierry Reding]

On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
[...]
 diff --git a/include/linux/of_display_timings.h 
 b/include/linux/of_display_timings.h
[...]
 +#ifndef __LINUX_OF_DISPLAY_TIMINGS_H
 +#define __LINUX_OF_DISPLAY_TIMINGS_H
 +
 +#include linux/display_timing.h
 +
 +#define OF_USE_NATIVE_MODE -1
 +
 +struct display_timings *of_get_display_timings(struct device_node *np);
 +int of_display_timings_exists(struct device_node *np);

This either needs to include linux/of.h or a forward declaration of
struct device_node. Otherwise this will fail to compile if the file
where this is included from doesn't pull linux/of.h in explicitly.

 diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
[...]
 +#ifndef __LINUX_OF_VIDEOMODE_H
 +#define __LINUX_OF_VIDEOMODE_H
 +
 +#include linux/videomode.h
 +
 +int of_get_videomode(struct device_node *np, struct videomode *vm, int 
 index);

Same here.

Thierry


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

Re: [PATCH v8 1/6] video: add display_timing and videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote:
 On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
  On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
  [...]
   diff --git a/drivers/video/display_timing.c 
   b/drivers/video/display_timing.c
  [...]
   +void display_timings_release(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);
   +}
  
  I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
  be used from modules.
  
  Thierry
 
 Yes. Just in time. I was just starting to type the send-email command ;-)

Great! In that case don't forget to also look at my other email before
sending. =)

Thierry


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

Re: [PATCH v8 1/6] video: add display_timing and videomode

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote:
 On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote:
  On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
   On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
   [...]
diff --git a/drivers/video/display_timing.c 
b/drivers/video/display_timing.c
   [...]
+void display_timings_release(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);
+}
   
   I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
   be used from modules.
   
   Thierry
  
  Yes. Just in time. I was just starting to type the send-email command ;-)
 
 Great! In that case don't forget to also look at my other email before
 sending. =)
 
Sure.


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/6] video: add display_timing and videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:10:15PM +0100, Steffen Trumtrar wrote:
 On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote:
  On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote:
   On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
[...]
 diff --git a/drivers/video/display_timing.c 
 b/drivers/video/display_timing.c
[...]
 +void display_timings_release(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);
 +}

I think this is still missing an EXPORT_SYMBOL_GPL. Otherwise it can't
be used from modules.

Thierry
   
   Yes. Just in time. I was just starting to type the send-email command ;-)
  
  Great! In that case don't forget to also look at my other email before
  sending. =)
  
 Sure.

Besides those comments (and those from other people) I think your
patchset is in pretty good shape. Have you thought about how and when
you want to get things merged?

Thierry


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

[PATCH v9 6/6] drm_modes: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get drm_display_mode from devicetree.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
 drivers/gpu/drm/drm_modes.c |   35 ++-
 include/drm/drmP.h  |6 ++
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 42ea099..c3ae5d2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,7 +35,8 @@
 #include linux/export.h
 #include drm/drmP.h
 #include drm/drm_crtc.h
-#include linux/videomode.h
+#include linux/of.h
+#include linux/of_videomode.h
 
 /**
  * drm_mode_debug_printmodeline - debug print a mode
@@ -540,6 +541,38 @@ int display_mode_from_videomode(struct videomode *vm, 
struct drm_display_mode *d
 EXPORT_SYMBOL_GPL(display_mode_from_videomode);
 #endif
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode 
*dmode,
+   unsigned int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, vm, index);
+   if (ret)
+   return ret;
+
+   display_mode_from_videomode(vm, dmode);
+
+   pr_info(%s: got %dx%d display mode from %s\n, __func__, vm.hactive,
+   vm.vactive, np-name);
+   drm_mode_debug_printmodeline(dmode);
+
+   return 0;
+
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 1e0d846..e8f46a1 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
 #include linux/cdev.h
 #include linux/mutex.h
 #include linux/slab.h
+#include linux/of.h
 #include linux/videomode.h
 #if defined(__alpha__) || defined(__powerpc__)
 #include asm/pgtable.h   /* For pte_wrprotect */
@@ -1459,6 +1460,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
 extern int display_mode_from_videomode(struct videomode *vm,
   struct drm_display_mode *dmode);
 #endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_drm_display_mode(struct device_node *np,
+  struct drm_display_mode *dmode,
+  unsigned int index);
+#endif
 
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

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

[PATCH v9 1/6] video: add display_timing and videomode

[Steffen Trumtrar]

Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.

Every timing parameter can be specified as a single value or a range
min typ max.

Also, add helper functions to convert from display timings to a generic 
videomode
structure. This videomode can then be converted to the corresponding subsystem
mode representation (e.g. fb_videomode).

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
 drivers/video/Kconfig  |6 
 drivers/video/Makefile |2 ++
 drivers/video/display_timing.c |   24 ++
 drivers/video/videomode.c  |   45 ++
 include/linux/display_timing.h |   69 
 include/linux/videomode.h  |   39 +++
 6 files changed, 185 insertions(+)
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/videomode.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
  This framework adds support for low-level control of the video 
  output switch.
 
+config DISPLAY_TIMING
+   bool
+
+config VIDEOMODE
+   bool
+
 menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL)  += vfb.o
 
 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..ac9bbbc
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/display_timing.h
+#include linux/export.h
+#include linux/slab.h
+
+void display_timings_release(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);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..087374a
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,45 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/export.h
+#include linux/errno.h
+#include linux/display_timing.h
+#include linux/kernel.h
+#include linux/videomode.h
+
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ unsigned int index)
+{
+   struct display_timing *dt;
+
+   dt = display_timings_get(disp, index);
+   if (!dt)
+   return -EINVAL;
+
+   vm-pixelclock = display_timing_get_value(dt-pixelclock, 0);
+   vm-hactive = display_timing_get_value(dt-hactive, 0);
+   vm-hfront_porch = display_timing_get_value(dt-hfront_porch, 0);
+   vm-hback_porch = display_timing_get_value(dt-hback_porch, 0);
+   vm-hsync_len = display_timing_get_value(dt-hsync_len, 0);
+
+   vm-vactive = display_timing_get_value(dt-vactive, 0);
+   vm-vfront_porch = display_timing_get_value(dt-vfront_porch, 0);
+   vm-vback_porch = display_timing_get_value(dt-vback_porch, 0);
+   vm-vsync_len = display_timing_get_value(dt-vsync_len, 0);
+
+   vm-vah = dt-vsync_pol_active;
+   vm-hah = dt-hsync_pol_active;
+   vm-de = dt-de_pol_active;
+   vm-pixelclk_pol = dt-pixelclk_pol;
+
+   vm-interlaced = dt-interlaced;
+   vm-doublescan = dt-doublescan;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_from_timing);
diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h
new file mode 100644
index 000..caee2a8
--- /dev/null
+++ b/include/linux/display_timing.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_DISPLAY_TIMINGS_H
+#define __LINUX_DISPLAY_TIMINGS_H
+
+#include linux/types.h
+
+struct timing_entry {
+   u32 min;
+   u32 typ;
+   u32 max;
+};
+
+struct display_timing {
+   struct timing_entry pixelclock;
+
+   struct timing_entry hactive;
+   

[PATCH v9 5/6] drm_modes: add videomode helpers

[Steffen Trumtrar]

Add conversion from videomode to drm_display_mode

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
 drivers/gpu/drm/drm_modes.c |   36 
 include/drm/drmP.h  |6 ++
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..42ea099 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include linux/export.h
 #include drm/drmP.h
 #include drm/drm_crtc.h
+#include linux/videomode.h
 
 /**
  * drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
vdisplay, int vrefresh,
 }
 EXPORT_SYMBOL(drm_gtf_mode);
 
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int display_mode_from_videomode(struct videomode *vm, struct drm_display_mode 
*dmode)
+{
+   dmode-hdisplay = vm-hactive;
+   dmode-hsync_start = dmode-hdisplay + vm-hfront_porch;
+   dmode-hsync_end = dmode-hsync_start + vm-hsync_len;
+   dmode-htotal = dmode-hsync_end + vm-hback_porch;
+
+   dmode-vdisplay = vm-vactive;
+   dmode-vsync_start = dmode-vdisplay + vm-vfront_porch;
+   dmode-vsync_end = dmode-vsync_start + vm-vsync_len;
+   dmode-vtotal = dmode-vsync_end + vm-vback_porch;
+
+   dmode-clock = vm-pixelclock / 1000;
+
+   dmode-flags = 0;
+   if (vm-hah)
+   dmode-flags |= DRM_MODE_FLAG_PHSYNC;
+   else
+   dmode-flags |= DRM_MODE_FLAG_NHSYNC;
+   if (vm-vah)
+   dmode-flags |= DRM_MODE_FLAG_PVSYNC;
+   else
+   dmode-flags |= DRM_MODE_FLAG_NVSYNC;
+   if (vm-interlaced)
+   dmode-flags |= DRM_MODE_FLAG_INTERLACE;
+   if (vm-doublescan)
+   dmode-flags |= DRM_MODE_FLAG_DBLSCAN;
+   drm_mode_set_name(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_mode_from_videomode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..1e0d846 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
 #include linux/cdev.h
 #include linux/mutex.h
 #include linux/slab.h
+#include linux/videomode.h
 #if defined(__alpha__) || defined(__powerpc__)
 #include asm/pgtable.h   /* For pte_wrprotect */
 #endif
@@ -1454,6 +1455,11 @@ extern struct drm_display_mode *
 drm_mode_create_from_cmdline_mode(struct drm_device *dev,
  struct drm_cmdline_mode *cmd);
 
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int display_mode_from_videomode(struct videomode *vm,
+  struct drm_display_mode *dmode);
+#endif
+
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
 extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

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

[PATCH v9 0/6] of: add display helper

[Steffen Trumtrar]

Hi!

Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct 
foo))
- include headers were necessary
- misc minor bufixes

Regards,
Steffen


Steffen Trumtrar (6):
  video: add display_timing and videomode
  video: add of helper for videomode
  fbmon: add videomode helpers
  fbmon: add of_videomode helpers
  drm_modes: add videomode helpers
  drm_modes: add of_videomode helpers

 .../devicetree/bindings/video/display-timings.txt  |  107 ++
 drivers/gpu/drm/drm_modes.c|   69 +++
 drivers/video/Kconfig  |   19 ++
 drivers/video/Makefile |4 +
 drivers/video/display_timing.c |   24 +++
 drivers/video/fbmon.c  |   78 
 drivers/video/of_display_timing.c  |  211 
 drivers/video/of_videomode.c   |   47 +
 drivers/video/videomode.c  |   45 +
 include/drm/drmP.h |   12 ++
 include/linux/display_timing.h |   69 +++
 include/linux/fb.h |   11 +
 include/linux/of_display_timings.h |   20 ++
 include/linux/of_videomode.h   |   16 ++
 include/linux/videomode.h  |   39 
 15 files changed, 771 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/of_display_timings.h
 create mode 100644 include/linux/of_videomode.h
 create mode 100644 include/linux/videomode.h

-- 
1.7.10.4

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

[PATCH v9 3/6] fbmon: add videomode helpers

[Steffen Trumtrar]

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 |   38 ++
 include/linux/fb.h|5 +
 2 files changed, 43 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..cccef17 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
 #include linux/pci.h
 #include linux/slab.h
 #include video/edid.h
+#include linux/videomode.h
 #ifdef CONFIG_PPC_OF
 #include asm/prom.h
 #include asm/pci-bridge.h
@@ -1373,6 +1374,43 @@ 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 fb_videomode_from_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;
+   if (vm-de)
+   fbmode-sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
+   fbmode-refresh = (vm-pixelclock*1000) / (vm-hactive * vm-vactive);
+   fbmode-flag = 0;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_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..6a3a675 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -14,6 +14,7 @@
 #include linux/backlight.h
 #include linux/slab.h
 #include asm/io.h
+#include linux/videomode.h
 
 struct vm_area_struct;
 struct fb_info;
@@ -714,6 +715,10 @@ 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);
 
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(struct videomode *vm,
+  struct fb_videomode *fbmode);
+#endif
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
 extern void fb_var_to_videomode(struct fb_videomode *mode,
-- 
1.7.10.4

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

[PATCH v9 4/6] fbmon: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get fb_videomode from devicetree.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
 drivers/video/fbmon.c |   42 +-
 include/linux/fb.h|6 ++
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cccef17..3a48abd 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,7 +31,7 @@
 #include linux/pci.h
 #include linux/slab.h
 #include video/edid.h
-#include linux/videomode.h
+#include linux/of_videomode.h
 #ifdef CONFIG_PPC_OF
 #include asm/prom.h
 #include asm/pci-bridge.h
@@ -1410,6 +1410,46 @@ int fb_videomode_from_videomode(struct videomode *vm, 
struct fb_videomode *fbmod
 EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
 #endif
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_fb_videomode(struct fb_videomode *m)
+{
+   pr_debug(fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u 
%u\n,
+m-xres, m-yres, m-refresh, m-pixclock, m-left_margin,
+m-right_margin, m-upper_margin, m-lower_margin,
+m-hsync_len, m-vsync_len, m-sync, m-vmode, m-flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+   unsigned int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, vm, index);
+   if (ret)
+   return ret;
+
+   fb_videomode_from_videomode(vm, fb);
+
+   pr_info(%s: got %dx%d display mode from %s\n, __func__, vm.hactive,
+   vm.vactive, np-name);
+   dump_fb_videomode(fb);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_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 6a3a675..8aeece8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -15,6 +15,8 @@
 #include linux/slab.h
 #include asm/io.h
 #include linux/videomode.h
+#include linux/of.h
+#include linux/of_videomode.h
 
 struct vm_area_struct;
 struct fb_info;
@@ -715,6 +717,10 @@ 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);
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+  unsigned int index);
+#endif
 #if IS_ENABLED(CONFIG_VIDEOMODE)
 extern int fb_videomode_from_videomode(struct videomode *vm,
   struct fb_videomode *fbmode);
-- 
1.7.10.4

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

[PATCH v9 2/6] video: add of helper for videomode

[Steffen Trumtrar]

This adds support for reading display timings from DT or/and convert one of 
those
timings to a videomode.
The of_display_timing implementation supports multiple children where each
property can have up to 3 values. All children are read into an array, that
can be queried.
of_get_videomode converts exactly one of that timings to a struct videomode.

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Stephen Warren swar...@nvidia.com
---
 .../devicetree/bindings/video/display-timings.txt  |  107 ++
 drivers/video/Kconfig  |   13 ++
 drivers/video/Makefile |2 +
 drivers/video/of_display_timing.c  |  211 
 drivers/video/of_videomode.c   |   47 +
 include/linux/of_display_timings.h |   20 ++
 include/linux/of_videomode.h   |   16 ++
 7 files changed, 416 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 include/linux/of_display_timings.h
 create mode 100644 include/linux/of_videomode.h

diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
index 000..c9d9e1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,107 @@
+display-timings bindings
+
+
+display timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: the native mode for the display, in case multiple modes are
+   provided. When omitted, assume the first node is the native.
+
+timings subnode
+---
+
+required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+   in pixels
+   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+   lines
+ - clock-frequency: displayclock in Hz
+
+optional properties:
+ - hsync-active: Hsync pulse is active low/high/ignored
+ - vsync-active: Vsync pulse is active low/high/ignored
+ - de-active: Data-Enable pulse is active low/high/ignored
+ - pixelclk-inverted: pixelclock is inverted/non-inverted/ignored
+ - interlaced (bool)
+ - doublescan (bool)
+
+All the optional properties that are not bool follow the following logic:
+1: high active
+0: low active
+omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The 
devicetree
+representation corresponds to the one commonly found in datasheets for 
displays.
+If a display supports multiple signal timings, the native-mode can be 
specified.
+
+The parameters are defined as
+
+struct display_timing
+=
+
+  +--+-+--+---+
+  |  |↑|  |   |
+  |  ||vback_porch |  |   |
+  |  |↓|  |   |
+  +--###--+---+
+  |  #↑#  |   |
+  |  #|#  |   |
+  |  hback   #|#  hfront  | hsync |
+  |   porch  #|   hactive  #  porch   |  len  |
+  |#---+---#|-|
+  |  #|#  |   |
+  |  #|vactive #  |   |
+  |  #|#  |   |
+  |  #↓#  |   |
+  +--###--+---+
+  |  |↑|  |   |
+  |  ||vfront_porch|  |   |
+  |  |↓|  |   |
+  +--+-+--+---+
+  |  |↑|  |   |
+  |  ||vsync_len   |  |   |
+  |  |↓|  |   |
+  +--+-+--+---+
+
+
+Example:
+
+   display-timings {
+   native-mode = timing0;
+   timing0: 1920p24 {
+  

Re: [PATCH v9 2/6] video: add of helper for videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
[...]
 +display-timings bindings
 +
 +
 +display timings node

I didn't express myself very clearly here =). The way I think this
should be written is display-timings node.

 +required properties:
 + - hactive, vactive: Display resolution
 + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
 +   in pixels
 +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
 in
 +   lines
 + - clock-frequency: displayclock in Hz

I still think displayclock should be two words: display clock.

 +/**
 + * of_get_display_timings - parse all display_timing entries from a 
 device_node
 + * @np: device_node with the subnodes
 + **/
 +struct display_timings *of_get_display_timings(struct device_node *np)
 +{
[...]
 + disp-num_timings = 0;
 + disp-native_mode = 0;
 +
 + for_each_child_of_node(timings_np, entry) {
 + struct display_timing *dt;
 +
 + dt = of_get_display_timing(entry);
 + if (!dt) {
 + /* to not encourage wrong devicetrees, fail in case of 
 an error */
 + pr_err(%s: error in timing %d\n, __func__, 
 disp-num_timings+1);
 + goto timingfail;

I believe you're still potentially leaking memory here. In case you have
5 entries for instance, and the last one fails to parse, then this will
cause the memory allocated for the 4 correct entries to be lost.

Can't you just call display_timings_release() in this case and then jump
to dispfail? That would still leak the native_mode device node. Maybe it
would be better to keep timingfail but modify it to free the display
timings with display_timings_release() instead? See below.

 + }
 +
 + if (native_mode == entry)
 + disp-native_mode = disp-num_timings;
 +
 + disp-timings[disp-num_timings] = dt;
 + disp-num_timings++;
 + }
 + of_node_put(timings_np);
 + of_node_put(native_mode);
 +
 + if (disp-num_timings  0)
 + pr_info(%s: got %d timings. Using timing #%d as default\n, 
 __func__,
 + disp-num_timings , disp-native_mode + 1);
 + else {
 + pr_err(%s: no valid timings specified\n, __func__);
 + display_timings_release(disp);
 + return NULL;
 + }
 + return disp;
 +
 +timingfail:
 + if (native_mode)
 + of_node_put(native_mode);
 + kfree(disp-timings);

Call display_timings_release(disp) instead of kfree(disp-timings)?

 diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
 new file mode 100644
 index 000..4138758
 --- /dev/null
 +++ b/include/linux/of_videomode.h
 @@ -0,0 +1,16 @@
 +/*
 + * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
 + *
 + * videomode of-helpers
 + *
 + * This file is released under the GPLv2
 + */
 +
 +#ifndef __LINUX_OF_VIDEOMODE_H
 +#define __LINUX_OF_VIDEOMODE_H
 +
 +#include linux/videomode.h
 +#include linux/of.h
 +
 +int of_get_videomode(struct device_node *np, struct videomode *vm, int 
 index);
 +#endif /* __LINUX_OF_VIDEOMODE_H */

Nit: should have a blank line before #endif.

Thierry


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

Re: [PATCH v9 1/6] video: add display_timing and videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:18PM +0100, Steffen Trumtrar wrote:
[...]
 diff --git a/include/linux/videomode.h b/include/linux/videomode.h
[...]
 +int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
 +   unsigned int index);
 +#endif

Nit: should have a blank line before the #endif.

Thierry


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

Re: [PATCH v9 2/6] video: add of helper for videomode

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
[...]
 +optional properties:
 + - native-mode: the native mode for the display, in case multiple modes are
 + provided. When omitted, assume the first node is the native.

I forgot: The first sentence in this description should also start with
a capital letter as you terminate with a full stop.

Thierry


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

[PATCH] drm/exynos: fix overlay updating issue

[Inki Dae]

This patch fixes a issue that overlay data aren't applied
to real hardware when dpms off goes to on after setcrtc
was requested like below,
dpms off - setcrtc - dpms off - dpms on

For this, it makes encoder's dpms to be updated when
setcrtc is requested.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 241ad1e..d971c95 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -423,6 +423,8 @@ void exynos_drm_encoder_crtc_dpms(struct drm_encoder 
*encoder, void *data)
if (!encoder-crtc)
manager-pipe = -1;
}
+
+   exynos_encoder-dpms = mode;
 }
 
 void exynos_drm_encoder_crtc_pipe(struct drm_encoder *encoder, void *data)
-- 
1.7.4.1

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

Re: [PATCH v9 3/6] fbmon: add videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:20PM +0100, 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 |   38 ++
  include/linux/fb.h|5 +
  2 files changed, 43 insertions(+)
 
 diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
 index cef6557..cccef17 100644
 --- a/drivers/video/fbmon.c
 +++ b/drivers/video/fbmon.c
 @@ -31,6 +31,7 @@
  #include linux/pci.h
  #include linux/slab.h
  #include video/edid.h
 +#include linux/videomode.h
  #ifdef CONFIG_PPC_OF
  #include asm/prom.h
  #include asm/pci-bridge.h
 @@ -1373,6 +1374,43 @@ 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 fb_videomode_from_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;
 + if (vm-de)
 + fbmode-sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
 + fbmode-refresh = (vm-pixelclock*1000) / (vm-hactive * vm-vactive);

CodingStyle that you should have spaces around '*'. Also I'm not sure if
that formula is correct. Shouldn't the blanking intervals be counted as
well? So:

unsigned int htotal = vm-hactive + vm-hfront_porch +
  vm-hback_porch + vm-hsync_len;
unsigned int vtotal = vm-vactive + vm-vfront_porch +
  vm-vback_porch + vm-vsync_len;

fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal);

?

 + fbmode-flag = 0;
 +
 + return 0;
 +}
 +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
 +#endif
 +
 +

Gratuitous blank line.

  #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..6a3a675 100644
 --- a/include/linux/fb.h
 +++ b/include/linux/fb.h
 @@ -14,6 +14,7 @@
  #include linux/backlight.h
  #include linux/slab.h
  #include asm/io.h
 +#include linux/videomode.h
  
  struct vm_area_struct;
  struct fb_info;
 @@ -714,6 +715,10 @@ 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);
  
 +#if IS_ENABLED(CONFIG_VIDEOMODE)
 +extern int fb_videomode_from_videomode(struct videomode *vm,
 +struct fb_videomode *fbmode);
 +#endif
  /* drivers/video/modedb.c */

These in turn could use an extra blank line.

Thierry


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

[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk
  Component|Other   |Video(DRI - non Intel)
 AssignedTo|drivers_other@kernel-bugs.o |drivers_video-dri@kernel-bu
   |sdl.org |gs.osdl.org




-- 
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 v9 4/6] fbmon: add of_videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:21PM +0100, Steffen Trumtrar wrote:
[...]
 diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
[...]
 +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
 +static void dump_fb_videomode(struct fb_videomode *m)

static inline?

Thierry


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

Re: [PATCH v9 5/6] drm_modes: add videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote:
[...]
 diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
[...]
 @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
 vdisplay, int vrefresh,
  }
  EXPORT_SYMBOL(drm_gtf_mode);
  
 +#if IS_ENABLED(CONFIG_VIDEOMODE)
 +int display_mode_from_videomode(struct videomode *vm, struct 
 drm_display_mode *dmode)

Given that this is still a DRM core function, maybe it should get a drm_
prefix? Also the line is too long, so you may want to wrap the argument
list.

Thierry


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

Re: [PATCH v9 6/6] drm_modes: add of_videomode helpers

[Thierry Reding]

On Wed, Nov 14, 2012 at 12:43:23PM +0100, Steffen Trumtrar wrote:
[...]
 +EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
 +#endif
  /**

Nit: there should be a blank line between the last two.

Thierry


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

Re: [PATCH v9 2/6] video: add of helper for videomode

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 01:00:45PM +0100, Thierry Reding wrote:
 On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
 [...]
  +display-timings bindings
  +
  +
  +display timings node
 
 I didn't express myself very clearly here =). The way I think this
 should be written is display-timings node.
 
  +required properties:
  + - hactive, vactive: Display resolution
  + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing 
  parameters
  +   in pixels
  +   vfront-porch, vback-porch, vsync-len: Vertical display timing 
  parameters in
  +   lines
  + - clock-frequency: displayclock in Hz
 
 I still think displayclock should be two words: display clock.
 
  +/**
  + * of_get_display_timings - parse all display_timing entries from a 
  device_node
  + * @np: device_node with the subnodes
  + **/
  +struct display_timings *of_get_display_timings(struct device_node *np)
  +{
 [...]
  +   disp-num_timings = 0;
  +   disp-native_mode = 0;
  +
  +   for_each_child_of_node(timings_np, entry) {
  +   struct display_timing *dt;
  +
  +   dt = of_get_display_timing(entry);
  +   if (!dt) {
  +   /* to not encourage wrong devicetrees, fail in case of 
  an error */
  +   pr_err(%s: error in timing %d\n, __func__, 
  disp-num_timings+1);
  +   goto timingfail;
 
 I believe you're still potentially leaking memory here. In case you have
 5 entries for instance, and the last one fails to parse, then this will
 cause the memory allocated for the 4 correct entries to be lost.
 
 Can't you just call display_timings_release() in this case and then jump
 to dispfail? That would still leak the native_mode device node. Maybe it
 would be better to keep timingfail but modify it to free the display
 timings with display_timings_release() instead? See below.
 
  +   }
  +
  +   if (native_mode == entry)
  +   disp-native_mode = disp-num_timings;
  +
  +   disp-timings[disp-num_timings] = dt;
  +   disp-num_timings++;
  +   }
  +   of_node_put(timings_np);
  +   of_node_put(native_mode);
  +
  +   if (disp-num_timings  0)
  +   pr_info(%s: got %d timings. Using timing #%d as default\n, 
  __func__,
  +   disp-num_timings , disp-native_mode + 1);
  +   else {
  +   pr_err(%s: no valid timings specified\n, __func__);
  +   display_timings_release(disp);
  +   return NULL;
  +   }
  +   return disp;
  +
  +timingfail:
  +   if (native_mode)
  +   of_node_put(native_mode);
  +   kfree(disp-timings);
 
 Call display_timings_release(disp) instead of kfree(disp-timings)?
 

Yes. That would be the appropriate way to fail here. Done.

  diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
  new file mode 100644
  index 000..4138758
  --- /dev/null
  +++ b/include/linux/of_videomode.h
  @@ -0,0 +1,16 @@
  +/*
  + * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
  + *
  + * videomode of-helpers
  + *
  + * This file is released under the GPLv2
  + */
  +
  +#ifndef __LINUX_OF_VIDEOMODE_H
  +#define __LINUX_OF_VIDEOMODE_H
  +
  +#include linux/videomode.h
  +#include linux/of.h
  +
  +int of_get_videomode(struct device_node *np, struct videomode *vm, int 
  index);
  +#endif /* __LINUX_OF_VIDEOMODE_H */
 
 Nit: should have a blank line before #endif.
 
 Thierry



 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50091] GeForce 6150SE: system hangs on X-server start with garbled screen

[bugzilla-daemon]

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





--- Comment #1 from schaefer.fr...@gmx.net  2012-11-14 13:50:31 ---
Last good commit is 
5787640db6ae722aeadb394d480c7ca21b603e34
drm/nv04-nv40/instmem: remove use of nouveau_gpuobj_new_fake()

First bad commit is
ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69
drm/nouveau: port all engines to new engine module format

Can't test 16 commits inbetween (70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9 to
ac1499d9573f4aadd1d2beac11fe23af8ce90c24).

-- 
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 v9 3/6] fbmon: add videomode helpers

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 01:12:07PM +0100, Thierry Reding wrote:
 On Wed, Nov 14, 2012 at 12:43:20PM +0100, 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 |   38 ++
   include/linux/fb.h|5 +
   2 files changed, 43 insertions(+)
  
  diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
  index cef6557..cccef17 100644
  --- a/drivers/video/fbmon.c
  +++ b/drivers/video/fbmon.c
  @@ -31,6 +31,7 @@
   #include linux/pci.h
   #include linux/slab.h
   #include video/edid.h
  +#include linux/videomode.h
   #ifdef CONFIG_PPC_OF
   #include asm/prom.h
   #include asm/pci-bridge.h
  @@ -1373,6 +1374,43 @@ 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 fb_videomode_from_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;
  +   if (vm-de)
  +   fbmode-sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
  +   fbmode-refresh = (vm-pixelclock*1000) / (vm-hactive * vm-vactive);
 
 CodingStyle that you should have spaces around '*'. Also I'm not sure if
 that formula is correct. Shouldn't the blanking intervals be counted as
 well? So:
 
   unsigned int htotal = vm-hactive + vm-hfront_porch +
 vm-hback_porch + vm-hsync_len;
   unsigned int vtotal = vm-vactive + vm-vfront_porch +
 vm-vback_porch + vm-vsync_len;
 
   fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal);
 
 ?
 

Sounds correct. Done.

  +   fbmode-flag = 0;
  +
  +   return 0;
  +}
  +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
  +#endif
  +
  +
 
 Gratuitous blank line.
 
   #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..6a3a675 100644
  --- a/include/linux/fb.h
  +++ b/include/linux/fb.h
  @@ -14,6 +14,7 @@
   #include linux/backlight.h
   #include linux/slab.h
   #include asm/io.h
  +#include linux/videomode.h
   
   struct vm_area_struct;
   struct fb_info;
  @@ -714,6 +715,10 @@ 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);
   
  +#if IS_ENABLED(CONFIG_VIDEOMODE)
  +extern int fb_videomode_from_videomode(struct videomode *vm,
  +  struct fb_videomode *fbmode);
  +#endif
   /* drivers/video/modedb.c */
 
 These in turn could use an extra blank line.
 
 Thierry



 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix logic error in atombios_encoders.c

[alexdeucher]

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

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

Reported-by: David Binderman dcb...@hotmail.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index ba498f8..010bae1 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_SETUP, 0, 0);
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
/* some early dce3.2 boards have a bug in their 
transmitter control table */
-   if ((rdev-family != CHIP_RV710) || (rdev-family != 
CHIP_RV730))
+   if ((rdev-family != CHIP_RV710)  (rdev-family != 
CHIP_RV730))
atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
}
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder))  
connector) {
-- 
1.7.7.5

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

[Bug 50431] drivers/gpu/drm/radeon/atombios_encoders.c:1628: possible bad if test

[bugzilla-daemon]

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


Alex Deucher alexdeuc...@gmail.com changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #1 from Alex Deucher alexdeuc...@gmail.com  2012-11-14 14:13:53 
---
Good catch.  Thanks!  Patch queued.

-- 
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 v9 5/6] drm_modes: add videomode helpers

[Steffen Trumtrar]

On Wed, Nov 14, 2012 at 01:49:44PM +0100, Thierry Reding wrote:
 On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote:
 [...]
  diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
 [...]
  @@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
  vdisplay, int vrefresh,
   }
   EXPORT_SYMBOL(drm_gtf_mode);
   
  +#if IS_ENABLED(CONFIG_VIDEOMODE)
  +int display_mode_from_videomode(struct videomode *vm, struct 
  drm_display_mode *dmode)
 
 Given that this is still a DRM core function, maybe it should get a drm_
 prefix? Also the line is too long, so you may want to wrap the argument
 list.
 
 Thierry

Yes, seems to fit better to the rest of the file.

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: fix logic error in atombios_encoders.c

[Michel Dänzer]

On Mit, 2012-11-14 at 09:13 -0500, alexdeuc...@gmail.com wrote: 
 From: Alex Deucher alexander.deuc...@amd.com
 
 Fixes:
 https://bugzilla.kernel.org/show_bug.cgi?id=50431
 
 Reported-by: David Binderman dcb...@hotmail.com
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc: sta...@vger.kernel.org

Reviewed-by: Michel Dänzer michel.daen...@amd.com


  drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
 b/drivers/gpu/drm/radeon/atombios_encoders.c
 index ba498f8..010bae1 100644
 --- a/drivers/gpu/drm/radeon/atombios_encoders.c
 +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
 @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
 *encoder, int mode)
   atombios_dig_transmitter_setup(encoder, 
 ATOM_TRANSMITTER_ACTION_SETUP, 0, 0);
   atombios_dig_transmitter_setup(encoder, 
 ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
   /* some early dce3.2 boards have a bug in their 
 transmitter control table */
 - if ((rdev-family != CHIP_RV710) || (rdev-family != 
 CHIP_RV730))
 + if ((rdev-family != CHIP_RV710)  (rdev-family != 
 CHIP_RV730))

Ouch, the compiler didn't warn about this always evaluating to true?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

Summary|GeForce 6150SE: system  |[BISECTED]GeForce 6150SE:
   |hangs on X-server start |system hangs on X-server
   |with garbled screen |start with garbled screen




-- 
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] drm/radeon: fix logic error in atombios_encoders.c

[Alex Deucher]

On Wed, Nov 14, 2012 at 9:32 AM, Michel Dänzer mic...@daenzer.net wrote:
 On Mit, 2012-11-14 at 09:13 -0500, alexdeuc...@gmail.com wrote:
 From: Alex Deucher alexander.deuc...@amd.com

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

 Reported-by: David Binderman dcb...@hotmail.com
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc: sta...@vger.kernel.org

 Reviewed-by: Michel Dänzer michel.daen...@amd.com


  drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
 b/drivers/gpu/drm/radeon/atombios_encoders.c
 index ba498f8..010bae1 100644
 --- a/drivers/gpu/drm/radeon/atombios_encoders.c
 +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
 @@ -1625,7 +1625,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder 
 *encoder, int mode)
   atombios_dig_transmitter_setup(encoder, 
 ATOM_TRANSMITTER_ACTION_SETUP, 0, 0);
   atombios_dig_transmitter_setup(encoder, 
 ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
   /* some early dce3.2 boards have a bug in their 
 transmitter control table */
 - if ((rdev-family != CHIP_RV710) || (rdev-family != 
 CHIP_RV730))
 + if ((rdev-family != CHIP_RV710)  (rdev-family != 
 CHIP_RV730))

 Ouch, the compiler didn't warn about this always evaluating to true?

Nope.  At least not on any of my machines.



 --
 Earthling Michel Dänzer   |   http://www.amd.com
 Libre software enthusiast |  Debian, X and DRI developer
___
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 (boot/grub2 and suspend/resume) (CAYMAN)

[bugzilla-daemon]

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

--- Comment #31 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Here are the videos. Sorry, they were recorded with my iPod and they are
inverted.

Normal boot sequence before the culprit commit (kernel 3.6)
http://www.filedropper.com/k36
A normal boot sequence with kernel 3.6 from grub 2 to booting console.
Resolution is kept from grub to console, there is no sync problem and no purple
flicker.

A problematic boot with kernel 3.7-rc5 using gfxpayload=keep in Grub 2.
http://www.filedropper.com/k37keep
It starts normally, the booting console uses the same resolution as Grub 2.
However, possibly when radeon driver kicks in, there is a purple flicker
followed by a wrong (badly synced) display (shifted by about half a screen to
the right). The result could have been a black screen, a couple of interlaced
vertical lines or a different shifted display.

A non problematic boot with kernel 3.7-rc5 using gfxpayload=text in Grub 2.
http://www.filedropper.com/k37text
It doesn't show the purple flicker we see in the previous video, it just
flickers as a normal boot would do, but it does show the purple color from time
to time. However, the display is OK.

A problematic suspend/resume sequence with 3.7-rc5 (gfxpayload doesn't change
anything)
http://www.filedropper.com/k37suspend
Going in suspend mode just after booting up. When resuming, X/gdm briefly
appears, then it crashes. The computer continue to run, but the display stays
black and no input can be used (tried to switch console and reboot but it
doesn't work). Often, it will reboot by itself after some time. Suspend and
resume work great before the culprit commit or if I remove the changes in
...mc_stop()

-- 
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 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen

[bugzilla-daemon]

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

--- Comment #18 from ka.n...@mail.ru ---
(In reply to comment #17)
 I suspect that it works as intended though it's not what one might expect
 comparing to similar options in proprietary drivers.
I think you're completely right. In my case the issue was provoked by two
things: first, the program I use (GTK driconf o.9.1) suggests MLAA to be set to
8 as default value (however, resets it to 0 by default), and second, that it
did not actually work for me in mesa 8.0. So I was misled a little bit after I
installed mesa 9...

 As far as I understand, expected usage of MLAA with Mesa is to enable it
 only for the applications where you want it (games etc) with either
 app-specific drirc settings or environment variables.
It is probably so. A **huge** problem for me is a common lack of documentation.
I'm okay with English and not too lazy to read but I could hardly find what to
read, though. I mean - relevant while not obsolete. Things usually work in
default configuration, which may not be optimal for some cases, and if I want
to do something about it - this is where troubles begin - for me and maybe for
developers who have to answer my sometimes stupid questions. All this video
stuff looks so complicated and chaotic for me due to lack of documentation... I
even did not comprehend if mesa is commonly responsible only for 3D rendering
how comes erroneously enabled MLAA blurs fonts, too. Fonts currently are
rendered by DDX driver, aren't they?

 So I don't think it's a bug, though perhaps it would be nice to make Mesa
 behave more like other drivers.
Or at least, make things documented somehow. Currently the tuning knobs are
spread across three areas: drirc (which is created somehow, or not, often
beyond the user control); environment variables (hardly documented), Xorg.conf.
Oh yes, there is fourth: USE flags/.configure options. A little bit to
complicated...

Just the same, thank you guys for what you do.

-- 
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 56865] Mesa 9.0 extremely slow and produces fading output on radeon Evergreen

[bugzilla-daemon]

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

--- Comment #19 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #18)
  As far as I understand, expected usage of MLAA with Mesa is to enable it
  only for the applications where you want it (games etc) with either
  app-specific drirc settings or environment variables.
 It is probably so. A **huge** problem for me is a common lack of
 documentation. I'm okay with English and not too lazy to read but I could
 hardly find what to read, though. I mean - relevant while not obsolete.
 Things usually work in default configuration, which may not be optimal for
 some cases, and if I want to do something about it - this is where troubles
 begin - for me and maybe for developers who have to answer my sometimes
 stupid questions. All this video stuff looks so complicated and chaotic for
 me due to lack of documentation... I even did not comprehend if mesa is
 commonly responsible only for 3D rendering how comes erroneously enabled
 MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't
 they?

MLAA affects all rendering that goes through OpenGL.  While the text rendering
for non-GL X apps may be rendered by the ddx using xrendr, the pixmaps end up
going though OpenGL if you are using an OpenGL compositor (gnome
shell/compiz/kwin/etc.).  When the application window is composited to the
front buffer by the OpenGL compositor, the MLAA is applied.

-- 
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 v2] drm/omap: Fix usage of IS_ERR_OR_NULL and PTR_ERR

[Andy Gross]

Return -ENOMEM if dmm_txn_init cannot allocate a refill engine.

v2: Fix typing issue seen with newer compilers

Signed-off-by: Andy Gross andy.gr...@ti.com
---
 drivers/staging/omapdrm/omap_dmm_tiler.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 3ae3955..1499521 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -279,7 +279,7 @@ static int fill(struct tcm_area *area, struct page **pages,
 
txn = dmm_txn_init(omap_dmm, area-tcm);
if (IS_ERR_OR_NULL(txn))
-   return PTR_ERR(txn);
+   return -ENOMEM;
 
tcm_for_each_slice(slice, *area, area_s) {
struct pat_area p_area = {
-- 
1.7.5.4

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

Re: linux-next: Tree for Nov 14 (gpu/drm/i915)

[Andrew Morton]

On Wed, 14 Nov 2012 11:41:49 -0800
Randy Dunlap rdun...@infradead.org wrote:

 On 11/13/2012 09:30 PM, Stephen Rothwell wrote:
 
  Hi all,
  
  News: next-20121115 (i.e. tomorrow) will be the last release until
  next-20121126 (which should be just be after -rc7, I guess - assuming
  that Linus does not release v3.7 before then), so if you want something
  in linux-next for a reasonable amount of testing, it should probably be
  committed tomorrow.
  
  Changes since 20121113:
  
 
 
 
 on i386:
 
 ERROR: __build_bug_on_failed [drivers/gpu/drm/i915/i915.ko] undefined!
 
 Reference to that symbol is found in
 i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
 i915_gem_execbuffer.c:
 
 static struct eb_objects *
 eb_create(int size)
 {
   struct eb_objects *eb;
   int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
   BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));
 

Where to start.

- eb_create() has no business assuming that the hlist_head has any
  particular size.  We could easily add some conditionally-compiled
  debug fields in there, and drm blows up.

- The assertion is obviously true at present, so I assume that gcc
  screwed up and failed to reduce all that to a compile-time constant.

- We have a BUILD_BUG_ON_NOT_POWER_OF_2().  Use it?

- This code is using PAGE_SIZE to scale a kernel data structure. 
  PAGE_SIZE can vary by a factor of 16, depending on Kconfig.  This
  can result in 64k PAGE_SIZE machines exhibiting different beahviour
  from that which the testers saw.

  Don't do it.  It's better to hard-wire 4096.

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