date:20161005

[PATCH libdrm] Fix strict aliasing violation in drmHandleEvent

2016-10-05 Thread Felix Janda

&buffer[i], e and vblank have been pointers of different types but
refering to the same memory location, thus breaking the strict
aliasing rules.

Fix this by working exclusively with pointers to char.

Signed-off-by: Felix Janda 
---
 xf86drmMode.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 228c6e4..cc776c1 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -885,10 +885,10 @@ int drmModeCrtcSetGamma(int fd, uint32_t crtc_id, 
uint32_t size,

 int drmHandleEvent(int fd, drmEventContextPtr evctx)
 {
-   char buffer[1024];
-   int len, i;
-   struct drm_event *e;
-   struct drm_event_vblank *vblank;
+   char buffer[1024], *p;
+   int len;
+   struct drm_event e;
+   struct drm_event_vblank vblank;

/* The DRM read semantics guarantees that we always get only
 * complete events. */
@@ -896,39 +896,39 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
len = read(fd, buffer, sizeof buffer);
if (len == 0)
return 0;
-   if (len < (int)sizeof *e)
+   if (len < (int)sizeof e)
return -1;

-   i = 0;
-   while (i < len) {
-   e = (struct drm_event *) &buffer[i];
-   switch (e->type) {
+   p = buffer;
+   while (p < buffer + len) {
+   e = *(struct drm_event *) p;
+   switch (e.type) {
case DRM_EVENT_VBLANK:
if (evctx->version < 1 ||
evctx->vblank_handler == NULL)
break;
-   vblank = (struct drm_event_vblank *) e;
+   vblank = *(struct drm_event_vblank *) p;
evctx->vblank_handler(fd,
- vblank->sequence,
- vblank->tv_sec,
- vblank->tv_usec,
- U642VOID (vblank->user_data));
+ vblank.sequence,
+ vblank.tv_sec,
+ vblank.tv_usec,
+ U642VOID (vblank.user_data));
break;
case DRM_EVENT_FLIP_COMPLETE:
if (evctx->version < 2 ||
evctx->page_flip_handler == NULL)
break;
-   vblank = (struct drm_event_vblank *) e;
+   vblank = *(struct drm_event_vblank *) p;
evctx->page_flip_handler(fd,
-vblank->sequence,
-vblank->tv_sec,
-vblank->tv_usec,
-U642VOID (vblank->user_data));
+vblank.sequence,
+vblank.tv_sec,
+vblank.tv_usec,
+U642VOID (vblank.user_data));
break;
default:
break;
}
-   i += e->length;
+   p += e.length;
}

return 0;
-- 
2.7.3

[Intel-gfx] [PATCH 5/6] drm/i915/gen9: Get rid of redundant watermark values

2016-10-05 Thread Chris Wilson

On Wed, Oct 05, 2016 at 06:44:04PM -0300, Paulo Zanoni wrote:
> Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index dd15ae2..c580d3d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3378,6 +3378,8 @@ static void skylake_update_primary_plane(struct
> > drm_plane *plane,
> > Â   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> > >base.crtc);
> > Â   struct drm_framebuffer *fb = plane_state->base.fb;
> > Â   const struct skl_wm_values *wm = &dev_priv->wm.skl_results;
> > +   const struct skl_plane_wm *p_wm =
> > +   &crtc_state->wm.skl.optimal.planes[0];
> 
> I wish someone would do a patch to convert all these hardcoded values
> to PLANE_X, and convert "int"s Â to "enum plane"s everywhere.

Note that this is not PLANE_A, but setting up a shorthand local for

const struct skl_plane_wm *p_wm = crtc_state->wm.skl.optimal.planes;

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

2016-10-05 Thread Julia Lawall



On Wed, 5 Oct 2016, Jani Nikula wrote:

> On Wed, 05 Oct 2016, Daniel Vetter  wrote:
> > Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> > into a lint/checker pass over the entire kernel. I think that'd would
> > be more robust instead of trying to approximate the real kerneldoc
> > parser. Otoh that parser is a horror show of a perl/regex driven state
> > machine ;-)
> >
> > Jani, can you pls digg out these patches? Can't find them right now ...
>
> Expanding the massive Cc: with linux-doc list...
>
> Here goes. It's a quick hack from months ago, but still seems to
> somewhat work. At least for the kernel-doc parts. The reStructuredText
> lint part isn't all that great, and doesn't have mapping to line numbers
> like the Sphinx kernel-doc extension does. Anyway I'm happy how this
> integrates with kernel build CHECK and C=1/C=2.
>
> I guess Julia's goal is to automate the *fixing* of some of the error
> classes from kernel-doc. Not sure how well this could be made to
> integrate with any of that.

No, my work doesn't fix anything.  Coccinelle can't actually process
comments.  I just correlated the parsed comment with the function header.

julia

>
> BR,
> Jani.
>
>
> From 1244efa0f63a7b13795e8c37f81733a3c8bfc56a Mon Sep 17 00:00:00 2001
> From: Jani Nikula 
> Date: Tue, 31 May 2016 18:11:33 +0300
> Subject: [PATCH] kernel-doc-rst-lint: add tool to check kernel-doc and rst
>  correctness
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> Cc: Jani Nikula 
>
> Simple kernel-doc and reStructuredText lint tool that can be used
> independently and as a kernel build CHECK tool to validate kernel-doc
> comments.
>
> Independent usage:
> $ kernel-doc-rst-lint FILE
>
> Kernel CHECK usage:
> $ make CHECK=scripts/kernel-doc-rst-lint C=1  # (or C=2)
>
> Depends on docutils and the rst-lint package
> https://pypi.python.org/pypi/restructuredtext_lint
>
> Signed-off-by: Jani Nikula 
> ---
>  scripts/kernel-doc-rst-lint | 106 
> 
>  1 file changed, 106 insertions(+)
>  create mode 100755 scripts/kernel-doc-rst-lint
>
> diff --git a/scripts/kernel-doc-rst-lint b/scripts/kernel-doc-rst-lint
> new file mode 100755
> index ..7e0157679f83
> --- /dev/null
> +++ b/scripts/kernel-doc-rst-lint
> @@ -0,0 +1,106 @@
> +#!/usr/bin/env python
> +# coding=utf-8
> +#
> +# Copyright Â© 2016 Intel Corporation
> +#
> +# Permission is hereby granted, free of charge, to any person obtaining a
> +# copy of this software and associated documentation files (the "Software"),
> +# to deal in the Software without restriction, including without limitation
> +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom the
> +# Software is furnished to do so, subject to the following conditions:
> +#
> +# The above copyright notice and this permission notice (including the next
> +# paragraph) shall be included in all copies or substantial portions of the
> +# Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> +# IN THE SOFTWARE.
> +#
> +# Authors:
> +#Jani Nikula 
> +#
> +# Simple kernel-doc and reStructuredText lint tool that can be used
> +# independently and as a kernel build CHECK tool to validate kernel-doc
> +# comments.
> +#
> +# Independent usage:
> +# $ kernel-doc-rst-lint FILE
> +#
> +# Kernel CHECK usage:
> +# $ make CHECK=scripts/kernel-doc-rst-lint C=1   # (or C=2)
> +#
> +# Depends on docutils and the rst-lint package
> +# https://pypi.python.org/pypi/restructuredtext_lint
> +#
> +
> +import os
> +import subprocess
> +import sys
> +
> +from docutils.parsers.rst import directives
> +from docutils.parsers.rst import Directive
> +from docutils.parsers.rst import roles
> +from docutils import nodes, statemachine
> +import restructuredtext_lint
> +
> +class DummyDirective(Directive):
> +required_argument = 1
> +optional_arguments = 0
> +option_spec = { }
> +has_content = True
> +
> +def run(self):
> +return []
> +
> +# Fake the Sphinx C Domain directives and roles
> +directives.register_directive('c:function', DummyDirective)
> +directives.register_directive('c:type', DummyDirective)
> +roles.register_generic_role('c:func', nodes.emphasis)
> +roles.register_generic_role('c:type', nodes.emphasis)
> +
> +# We accept but ignore parameters to be compatible with how the kernel build
> +# invokes CHECK.
> +if len(sys.argv) < 2:
> +sys.stderr.write('usage: kern

[PATCH 02/11] drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu before wait

2016-10-05 Thread Sumit Semwal

Hi Lucas,

On 23 September 2016 at 18:25, Daniel Vetter  wrote:
> On Mon, Aug 29, 2016 at 08:08:25AM +0100, Chris Wilson wrote:
>> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
>> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
>> need to handle such conversion in the caller. The only challenge are
>> those callers that wish to differentiate the error code between the
>> nonblocking busy check and potentially blocking wait.
>>
>> Signed-off-by: Chris Wilson 
>> Cc: Lucas Stach 
>> Cc: Russell King 
>> Cc: Christian Gmeiner 
>
> Reviewed-by: Daniel Vetter 
>
Could you please let me know if this is in your tree already, or would
you like me to take it via drm-misc (in which case, an Acked-by would
be fabulous!)

Thanks and best,
Sumit.

[Intel-gfx] [PATCH 05/11] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait

2016-10-05 Thread Sumit Semwal

Hi Thomas, Sinclair,

On 23 September 2016 at 18:26, Daniel Vetter  wrote:
> On Mon, Aug 29, 2016 at 08:08:28AM +0100, Chris Wilson wrote:
>> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
>> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
>> need to handle such conversion in the caller. The only challenge are
>> those callers that wish to differentiate the error code between the
>> nonblocking busy check and potentially blocking wait.
>>
>> Signed-off-by: Chris Wilson 
>> Cc: Sinclair Yeh 
>> Cc: Thomas Hellstrom 
>> Reviewed-by: Sinclair Yeh 
>
> Reviewed-by: Daniel Vetter 
>
Could you please let me know if this patch is already queued up at
your end, or should I just take it via drm-misc with Sinclair's r-b?

Thanks and Best,
Sumit.

[PATCH 2/3] drm/fb_cma_helper: Add panic handling

2016-10-05 Thread Noralf Trønnes

Den 05.10.2016 15:22, skrev Laurent Pinchart:
> Hi Noralf,
>
> Thank you for the patch.
>
> On Sunday 11 Sep 2016 20:47:41 Noralf TrÃ¸nnes wrote:
>> This enables panic message output for fb cma helper framebuffers.
>>
>> Signed-off-by: Noralf TrÃ¸nnes 
>> ---
>>   drivers/gpu/drm/drm_fb_cma_helper.c | 10 ++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>> b/drivers/gpu/drm/drm_fb_cma_helper.c index 1fd6eac..2f1b012 100644
>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>> @@ -126,9 +126,19 @@ int drm_fb_cma_create_handle(struct drm_framebuffer
>> *fb, }
>>   EXPORT_SYMBOL(drm_fb_cma_create_handle);
>>
>> +static void *drm_fb_cma_panic_vmap(struct drm_framebuffer *fb)
>> +{
>> +struct drm_fb_cma *fb_cma = to_fb_cma(fb);
>> +struct drm_gem_cma_object *cma_obj = fb_cma->obj[0];
>> +
>> +/* A PRIME imported buffer will not have it's vaddr set. */
> Does this mean that, if the framebuffer that happens to be displayed when a
> panic occurs is imported, no message will be printed ? I understand how
> supporting such cases is difficult, but I'm wondering how we could proceed to
> ensure that a panic can be displayed in most (if not all) cases.

If we can vmap all cma buffers, then it's simple:
- Add dma_buf_vmap() call to drm_gem_cma_prime_import_sg_table()
- Add dma_buf_vunmap() call to drm_gem_cma_free_object()

If not then it looks more complicated, since this is atomic context.
There is dma_buf_kmap_atomic(), but there are no users.
And drm_gem_prime_dmabuf_ops doesn't support .kmap_atomic either
(returns NULL).

omapdrm is the only dma_buf provider I can find that actually uses
kmap_atomic() instead of just returning NULL or relying on an existing
virtual address. It has it's own .gem_prime_import/export functions to
accomplish this.

> Similarly, it looks like your code only handles single-planar formats, but
> there's no explicit check for that in patch 1/3. The easiest fix is to reject
> multi-planar framebuffers, but that would again result in silent panics in
> some cases.

That's correct if we talk about the default panic_draw_xy() function:
drm_framebuffer_panic_draw_xy(). Most likely this function can be extended
to support multi-planar formats, but Daniel said we could wait with that.
And the driver can also implement it's own .panic_draw_xy() function.

>> +return cma_obj ? cma_obj->vaddr : NULL;
> Can cma_obj be NULL here ? I thought that framebuffer objects were always
> created with at least one GEM object.

I was trying to be very careful since a panic is about something gone
very wrong. But in that case I should have checked that fb_cma isn't NULL
also before dereferencing it.
Maybe I'm over the top paranoid :-)

Noralf.

>> +}
>> +
>>   static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
>>  .destroy= drm_fb_cma_destroy,
>>  .create_handle  = drm_fb_cma_create_handle,
>> +.panic_vmap = drm_fb_cma_panic_vmap,
>>   };
>>
>>   static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,

[Intel-gfx] [PATCH 04/11] drm/nouveau: Remove call to reservation_object_test_signaled_rcu before wait

2016-10-05 Thread Sumit Semwal

Hi Ben,

On 23 September 2016 at 18:25, Daniel Vetter  wrote:
> On Mon, Aug 29, 2016 at 08:08:27AM +0100, Chris Wilson wrote:
>> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
>> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
>> need to handle such conversion in the caller. The only challenge are
>> those callers that wish to differentiate the error code between the
>> nonblocking busy check and potentially blocking wait.
>>
>> Signed-off-by: Chris Wilson 
>> Cc: Ben Skeggs 
>
> Reviewed-by: Daniel Vetter 
>
May I please know if this patch is already in your queue, or should I
take it through drm-misc (in which case an Acked-by would be highly
appreciated :) )


Best,
Sumit.

[PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

2016-10-05 Thread Sumit Semwal

Hi Alex,

On 23 September 2016 at 18:24, Daniel Vetter  wrote:
> On Mon, Aug 29, 2016 at 08:08:24AM +0100, Chris Wilson wrote:
>> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
>> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
>> need to handle such conversion in the caller. The only challenge are
>> those callers that wish to differentiate the error code between the
>> nonblocking busy check and potentially blocking wait.
>>
>> Signed-off-by: Chris Wilson 
>> Cc: Alex Deucher 
>> Cc: Christian KÃ¶nig 
>
> Reviewed-by: Daniel Vetter 
>> ---
I couldn't find if its already applied to your tree, or your acked-by;
could you please let me know if it's there, or if you'd like me to
pick it up via drm-misc (and an Acked-by would be appreciated in the
latter case :) )

Best,
Sumit.

[PATCH] drm/fb-helper: fix sphinx markup for DRM_FB_HELPER_DEFAULT_OPS

2016-10-05 Thread Stefan Christ

Fix invalid sphinx markup in the comment for the newly added
DRM_FB_HELPER_DEFAULT_OPS.

Signed-off-by: Stefan Christ 
---
Hi, 

> > If I'm not mistaken v1 of this patch is already in drm-misc so you may
> > want to send a patch that fix just the line above.
> 
> Yup, I need an incremental patch which applies on top of drm-misc or
> linux-next. Sorry if this wasn't clear.
> -Daniel

Thanks for the head-ups. Here is a fix patch for it. Actually I should have
come up with the same idea myself seeing the patch queued for the next pull
request.

I have not added a "Fixes:" trailer in the commit message. If this is necessary
I can resend it, when I see the offending patch in Linus master tree with a
commit id.

Kind regards,
Stefan Christ
---
 include/drm/drm_fb_helper.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 3c5f599..ed8edfe 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -218,7 +218,7 @@ struct drm_fb_helper {
 };

 /**
- * @DRM_FB_HELPER_DEFAULT_OPS:
+ * define DRM_FB_HELPER_DEFAULT_OPS - helper define for drm drivers
  *
  * Helper define to register default implementations of drm_fb_helper
  * functions. To be used in struct fb_ops of drm drivers.
-- 
2.1.4

kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

2016-10-05 Thread Markus Heiser


Am 05.10.2016 um 16:04 schrieb Jani Nikula :

> On Wed, 05 Oct 2016, Daniel Vetter  wrote:
>> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
>> into a lint/checker pass over the entire kernel. I think that'd would
>> be more robust instead of trying to approximate the real kerneldoc
>> parser. Otoh that parser is a horror show of a perl/regex driven state
>> machine ;-)
>> 
>> Jani, can you pls digg out these patches? Can't find them right now ...
> 
> Expanding the massive Cc: with linux-doc list...
> 
> Here goes. It's a quick hack from months ago, but still seems to
> somewhat work. At least for the kernel-doc parts. The reStructuredText
> lint part isn't all that great, and doesn't have mapping to line numbers
> like the Sphinx kernel-doc extension does. Anyway I'm happy how this
> integrates with kernel build CHECK and C=1/C=2.
> 
> I guess Julia's goal is to automate the *fixing* of some of the error
> classes from kernel-doc. Not sure how well this could be made to
> integrate with any of that.
> 
> BR,
> Jani.

Another lint alternative: 

 use the lint from the linuxdoc project 

install the linuxdoc package:

*  https://return42.github.io/linuxdoc/install.html

e.g.::

 pip install --user git+http://github.com/return42/linuxdoc.git

and run kernel-lintdoc with the file/folder to lint as argument / e.g.::

 kernel-lintdoc include/media/

-- Markus --


> 
> 
> From 1244efa0f63a7b13795e8c37f81733a3c8bfc56a Mon Sep 17 00:00:00 2001
> From: Jani Nikula 
> Date: Tue, 31 May 2016 18:11:33 +0300
> Subject: [PATCH] kernel-doc-rst-lint: add tool to check kernel-doc and rst
> correctness
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> Cc: Jani Nikula 
> 
> Simple kernel-doc and reStructuredText lint tool that can be used
> independently and as a kernel build CHECK tool to validate kernel-doc
> comments.
> 
> Independent usage:
> $ kernel-doc-rst-lint FILE
> 
> Kernel CHECK usage:
> $ make CHECK=scripts/kernel-doc-rst-lint C=1  # (or C=2)
> 
> Depends on docutils and the rst-lint package
> https://pypi.python.org/pypi/restructuredtext_lint
> 
> Signed-off-by: Jani Nikula 
> ---
> scripts/kernel-doc-rst-lint | 106 
> 1 file changed, 106 insertions(+)
> create mode 100755 scripts/kernel-doc-rst-lint
> 
> diff --git a/scripts/kernel-doc-rst-lint b/scripts/kernel-doc-rst-lint
> new file mode 100755
> index ..7e0157679f83
> --- /dev/null
> +++ b/scripts/kernel-doc-rst-lint
> @@ -0,0 +1,106 @@
> +#!/usr/bin/env python
> +# coding=utf-8
> +#
> +# Copyright Â© 2016 Intel Corporation
> +#
> +# Permission is hereby granted, free of charge, to any person obtaining a
> +# copy of this software and associated documentation files (the "Software"),
> +# to deal in the Software without restriction, including without limitation
> +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom the
> +# Software is furnished to do so, subject to the following conditions:
> +#
> +# The above copyright notice and this permission notice (including the next
> +# paragraph) shall be included in all copies or substantial portions of the
> +# Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> +# IN THE SOFTWARE.
> +#
> +# Authors:
> +#Jani Nikula 
> +#
> +# Simple kernel-doc and reStructuredText lint tool that can be used
> +# independently and as a kernel build CHECK tool to validate kernel-doc
> +# comments.
> +#
> +# Independent usage:
> +# $ kernel-doc-rst-lint FILE
> +#
> +# Kernel CHECK usage:
> +# $ make CHECK=scripts/kernel-doc-rst-lint C=1   # (or C=2)
> +#
> +# Depends on docutils and the rst-lint package
> +# https://pypi.python.org/pypi/restructuredtext_lint
> +#
> +
> +import os
> +import subprocess
> +import sys
> +
> +from docutils.parsers.rst import directives
> +from docutils.parsers.rst import Directive
> +from docutils.parsers.rst import roles
> +from docutils import nodes, statemachine
> +import restructuredtext_lint
> +
> +class DummyDirective(Directive):
> +required_argument = 1
> +optional_arguments = 0
> +option_spec = { }
> +has_content = True
> +
> +def run(self):
> +return []
> +
> +# Fake the Sphinx C Domain directives and roles
> +directives.register_directive('c:function', DummyDirective)
> +directives.register_directive('c:type', DummyDirective)
> +roles.register_generic_role('c:func', nodes.emphasis)
> +roles.register_gen

[Intel-gfx] [PATCH 5/6] drm/i915/gen9: Get rid of redundant watermark values

2016-10-05 Thread Paulo Zanoni

Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> Now that we've make skl_wm_levels make a little more sense, we can
> remove all of the redundant wm information. Up until now we'd been
> storing two copies of all of the skl watermarks: one being the
> skl_pipe_wm structs, the other being the global wm struct in
> drm_i915_private containing the raw register values. This is
> confusing
> and problematic, since it means we're prone to accidentally letting
> the
> two copies go out of sync. So, get rid of all of the functions
> responsible for computing the register values and just use a single
> helper, skl_write_wm_level(), to convert and write the new watermarks
> on
> the fly.

I like the direction of this patch too, but there are some small
possible problems. See below.


> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Matt Roper 
> ---
> Â drivers/gpu/drm/i915/i915_drv.hÂ Â Â Â Â Â |Â Â Â 2 -
> Â drivers/gpu/drm/i915/intel_display.c |Â Â 14 ++-
> Â drivers/gpu/drm/i915/intel_drv.hÂ Â Â Â Â |Â Â Â 6 +-
> Â drivers/gpu/drm/i915/intel_pm.cÂ Â Â Â Â Â | 203 -
> --
> Â drivers/gpu/drm/i915/intel_sprite.cÂ Â |Â Â Â 8 +-
> Â 5 files changed, 88 insertions(+), 145 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 0f97d43..63519ac 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1643,8 +1643,6 @@ struct skl_ddb_allocation {
> Â struct skl_wm_values {
> Â unsigned dirty_pipes;
> Â struct skl_ddb_allocation ddb;
> - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
> Â };
> Â 
> Â struct skl_wm_level {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index dd15ae2..c580d3d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3378,6 +3378,8 @@ static void skylake_update_primary_plane(struct
> drm_plane *plane,
> Â struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> >base.crtc);
> Â struct drm_framebuffer *fb = plane_state->base.fb;
> Â const struct skl_wm_values *wm = &dev_priv->wm.skl_results;
> + const struct skl_plane_wm *p_wm =
> + &crtc_state->wm.skl.optimal.planes[0];

I wish someone would do a patch to convert all these hardcoded values
to PLANE_X, and convert "int"s Â to "enum plane"s everywhere.


> Â int pipe = intel_crtc->pipe;
> Â u32 plane_ctl;
> Â unsigned int rotation = plane_state->base.rotation;
> @@ -3414,7 +3416,7 @@ static void skylake_update_primary_plane(struct
> drm_plane *plane,
> Â intel_crtc->adjusted_y = src_y;
> Â 
> Â if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc->base))
> - skl_write_plane_wm(intel_crtc, wm, 0);
> + skl_write_plane_wm(intel_crtc, p_wm, &wm->ddb, 0);
> Â 
> Â I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
> Â I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
> @@ -3448,6 +3450,8 @@ static void
> skylake_disable_primary_plane(struct drm_plane *primary,
> Â struct drm_device *dev = crtc->dev;
> Â struct drm_i915_private *dev_priv = to_i915(dev);
> Â struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *cstate = to_intel_crtc_state(crtc-
> >state);
> + const struct skl_plane_wm *p_wm = &cstate-
> >wm.skl.optimal.planes[0];
> Â int pipe = intel_crtc->pipe;
> Â 
> Â /*
> @@ -3455,7 +3459,8 @@ static void
> skylake_disable_primary_plane(struct drm_plane *primary,
> Â Â * plane's visiblity isn't actually changing neither is its
> watermarks.
> Â Â */
> Â if (!crtc->primary->state->visible)
> - skl_write_plane_wm(intel_crtc, &dev_priv-
> >wm.skl_results, 0);
> + skl_write_plane_wm(intel_crtc, p_wm,
> + Â Â Â &dev_priv->wm.skl_results.ddb,
> 0);
> Â 
> Â I915_WRITE(PLANE_CTL(pipe, 0), 0);
> Â I915_WRITE(PLANE_SURF(pipe, 0), 0);
> @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct
> drm_crtc *crtc, u32 base,
> Â struct drm_device *dev = crtc->dev;
> Â struct drm_i915_private *dev_priv = to_i915(dev);
> Â struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *cstate = to_intel_crtc_state(crtc-
> >state);
> Â const struct skl_wm_values *wm = &dev_priv->wm.skl_results;
> + const struct skl_plane_wm *p_wm =
> + &cstate->wm.skl.optimal.planes[PLANE_CURSOR];
> Â int pipe = intel_crtc->pipe;
> Â uint32_t cntl = 0;
> Â 
> Â if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes &
> drm_crtc_mask(crtc))
> - skl_write_cursor_wm(intel_crtc, wm);
> + skl_write_cursor_wm(intel_crtc, p_wm, &wm->ddb);
> Â 
> Â if (plane_state && plane_state->base.visible) {
> Â cntl = MCURSOR_GAMMA_ENABLE;
> diff --git a/drivers/gpu/drm/

[PATCH] drm: Fix up kerneldoc for new drm_gem_dmabuf_export()

2016-10-05 Thread Chris Wilson

I hit send before completing a make htmldoc, and lo I forgot to fix up
the cut'n'paste.

Fixes: a4fce9cb782a ("drm/prime: Take a ref on the drm_dev when exporting...")
Reported-by: kbuild test robot 
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/drm_prime.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 875df8d719fb..b22a94dd7b53 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -285,7 +285,8 @@ static void drm_gem_unmap_dma_buf(struct dma_buf_attachment 
*attach,

 /**
  * drm_gem_dmabuf_export - dma_buf export implementation for GEM
- * @dma_buf: buffer to be exported
+ * @dev: parent device for the exported dmabuf
+ * @exp_info: the export information used by dma_buf_export()
  *
  * This wraps dma_buf_export() for use by generic GEM drivers that are using
  * drm_gem_dmabuf_release(). In addition to calling dma_buf_export(), we take
-- 
2.9.3

[Bug 97643] Shader crashes radeon driver and brings the whole system down

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

Cris  changed:

   What|Removed |Added

Version|12.0|git

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/d566886f/attachment.html>

[Bug 97643] Shader crashes radeon driver and brings the whole system down

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

Cris  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #9 from Cris  ---
(In reply to almos from comment #8)
> (In reply to Cris from comment #7)
> > (In reply to Nicolai HÃ¤hnle from comment #6)
> > > Cris, do please try with more recent Mesa + LLVM as well.
> > > 
> > > If that still crashes, can you provide a backtrace of where mpv crashes?
> > > dmesg output from the crash could also give some context.
> > 
> > I did, I upgraded to llvm-3.9.0 and mesa-git, and the issue went away. Most
> > conservative distros might have a hard time though.
> > 
> > Thanks anyway.
> 
> Doesn't that mean that a userspace code can crash the kernel, but the most
> recent version of that code doesn't do it? Ideally, the kernel should be
> more resilient than that IMHO.

It's crashing now and I'm using -git (llvm, mesa, radeon). When it doesn't,
it's unbearably slow. It definitely shouldn't happen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/e19cba36/attachment-0001.html>

[Intel-gfx] [PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

2016-10-05 Thread Paulo Zanoni

Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> Having skl_wm_level contain all of the watermarks for each plane is
> annoying since it prevents us from having any sort of object to
> represent a single watermark level, something we take advantage of in
> the next commit to cut down on all of the copy paste code in here.

I'd like to start my review pointing that I really like this patch. I
agree the current form is annoying.

See below for some details.


> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Matt Roper 
> ---
> Â drivers/gpu/drm/i915/i915_drv.hÂ Â |Â Â Â 6 +-
> Â drivers/gpu/drm/i915/intel_drv.h |Â Â Â 6 +-
> Â drivers/gpu/drm/i915/intel_pm.cÂ Â | 208 +--
> 
> Â 3 files changed, 100 insertions(+), 120 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index d26e5999..0f97d43 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1648,9 +1648,9 @@ struct skl_wm_values {
> Â };
> Â 
> Â struct skl_wm_level {
> - bool plane_en[I915_MAX_PLANES];
> - uint16_t plane_res_b[I915_MAX_PLANES];
> - uint8_t plane_res_l[I915_MAX_PLANES];
> + bool plane_en;
> + uint16_t plane_res_b;
> + uint8_t plane_res_l;
> Â };
> Â 
> Â /*
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 35ba282..d684f4f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -468,9 +468,13 @@ struct intel_pipe_wm {
> Â bool sprites_scaled;
> Â };
> Â 
> -struct skl_pipe_wm {
> +struct skl_plane_wm {
> Â struct skl_wm_level wm[8];
> Â struct skl_wm_level trans_wm;
> +};
> +
> +struct skl_pipe_wm {
> + struct skl_plane_wm planes[I915_MAX_PLANES];
> Â uint32_t linetime;
> Â };
> Â 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index af96888..250f12d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3668,67 +3668,52 @@ static int
> Â skl_compute_wm_level(const struct drm_i915_private *dev_priv,
> Â Â Â Â Â Â struct skl_ddb_allocation *ddb,
> Â Â Â Â Â Â struct intel_crtc_state *cstate,
> + Â Â Â Â Â struct intel_plane *intel_plane,
> Â Â Â Â Â Â int level,
> Â Â Â Â Â Â struct skl_wm_level *result)
> Â {
> Â struct drm_atomic_state *state = cstate->base.state;
> Â struct intel_crtc *intel_crtc = to_intel_crtc(cstate-
> >base.crtc);
> - struct drm_plane *plane;
> - struct intel_plane *intel_plane;
> - struct intel_plane_state *intel_pstate;
> + struct drm_plane *plane = &intel_plane->base;
> + struct intel_plane_state *intel_pstate = NULL;
> Â uint16_t ddb_blocks;
> Â enum pipe pipe = intel_crtc->pipe;
> Â int ret;
> + int i = skl_wm_plane_id(intel_plane);
> +
> + if (state)
> + intel_pstate =
> + intel_atomic_get_existing_plane_state(state,
> + Â Â Â Â Â Â intel_
> plane);
> Â 
> Â /*
> - Â * We'll only calculate watermarks for planes that are
> actually
> - Â * enabled, so make sure all other planes are set as
> disabled.
> + Â * Note: If we start supporting multiple pending atomic
> commits against
> + Â * the same planes/CRTC's in the future, plane->state will
> no longer be
> + Â * the correct pre-state to use for the calculations here
> and we'll
> + Â * need to change where we get the 'unchanged' plane data
> from.
> + Â *
> + Â * For now this is fine because we only allow one queued
> commit against
> + Â * a CRTC.Â Â Even if the plane isn't modified by this
> transaction and we
> + Â * don't have a plane lock, we still have the CRTC's lock,
> so we know
> + Â * that no other transactions are racing with us to update
> it.
> Â Â */
> - memset(result, 0, sizeof(*result));
> -
> - for_each_intel_plane_mask(&dev_priv->drm,
> - Â Â intel_plane,
> - Â Â cstate->base.plane_mask) {
> - int i = skl_wm_plane_id(intel_plane);
> -
> - plane = &intel_plane->base;
> - intel_pstate = NULL;
> - if (state)
> - intel_pstate =
> - intel_atomic_get_existing_plane_stat
> e(state,
> - Â Â Â Â 
> Â Â intel_plane);
> + if (!intel_pstate)
> + intel_pstate = to_intel_plane_state(plane->state);
> Â 
> - /*
> - Â * Note: If we start supporting multiple pending
> atomic commits
> - Â * against the same planes/CRTC's in the future,
> plane->state
> - Â * will no longer be the correct pre-state to use
> for the
> - Â * calculations here and we'll need to change where
> w

[Intel-gfx] [PATCH 2/6] drm/i915/skl: Remove linetime from skl_wm_values

2016-10-05 Thread Paulo Zanoni

Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> Next part of cleaning up the watermark code for skl. This is easy,
> since
> it seems that we never actually needed to keep track of the linetime
> in
> the skl_wm_values struct anyway.

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Matt Roper 
> ---
> Â drivers/gpu/drm/i915/i915_drv.hÂ Â Â Â Â Â | 1 -
> Â drivers/gpu/drm/i915/intel_display.c | 6 --
> Â drivers/gpu/drm/i915/intel_pm.cÂ Â Â Â Â Â | 7 +--
> Â 3 files changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 85e541c..d26e5999 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1643,7 +1643,6 @@ struct skl_ddb_allocation {
> Â struct skl_wm_values {
> Â unsigned dirty_pipes;
> Â struct skl_ddb_allocation ddb;
> - uint32_t wm_linetime[I915_MAX_PIPES];
> Â uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> Â uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
> Â };
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 17733af..a71d05a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14832,6 +14832,8 @@ static void intel_begin_crtc_commit(struct
> drm_crtc *crtc,
> Â struct drm_device *dev = crtc->dev;
> Â struct drm_i915_private *dev_priv = to_i915(dev);
> Â struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *intel_cstate =
> + to_intel_crtc_state(crtc->state);
> Â struct intel_crtc_state *old_intel_state =
> Â to_intel_crtc_state(old_crtc_state);
> Â bool modeset = needs_modeset(crtc->state);
> @@ -14848,13 +14850,13 @@ static void intel_begin_crtc_commit(struct
> drm_crtc *crtc,
> Â intel_color_load_luts(crtc->state);
> Â }
> Â 
> - if (to_intel_crtc_state(crtc->state)->update_pipe)
> + if (intel_cstate->update_pipe)
> Â intel_update_pipe_config(intel_crtc,
> old_intel_state);
> Â else if (INTEL_GEN(dev_priv) >= 9) {
> Â skl_detach_scalers(intel_crtc);
> Â 
> Â I915_WRITE(PIPE_WM_LINETIME(pipe),
> - Â Â Â dev_priv->wm.skl_hw.wm_linetime[pipe]);
> + Â Â Â intel_cstate->wm.skl.optimal.linetime);
> Â }
> Â }
> Â 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 0383516..af96888 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3839,8 +3839,6 @@ static void skl_compute_wm_results(struct
> drm_device *dev,
> Â temp |= PLANE_WM_EN;
> Â 
> Â r->plane_trans[pipe][PLANE_CURSOR] = temp;
> -
> - r->wm_linetime[pipe] = p_wm->linetime;
> Â }
> Â 
> Â static void skl_ddb_entry_write(struct drm_i915_private *dev_priv,
> @@ -4069,7 +4067,6 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
> Â Â Â Â Â Â struct skl_wm_values *src,
> Â Â Â Â Â Â enum pipe pipe)
> Â {
> - dst->wm_linetime[pipe] = src->wm_linetime[pipe];
> Â memcpy(dst->plane[pipe], src->plane[pipe],
> Â Â Â Â Â Â Â Â sizeof(dst->plane[pipe]));
> Â memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
> @@ -4320,8 +4317,6 @@ static void skl_pipe_wm_get_hw_state(struct
> drm_crtc *crtc)
> Â 
> Â max_level = ilk_wm_max_level(dev);
> Â 
> - hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
> -
> Â for (level = 0; level <= max_level; level++) {
> Â for (i = 0; i < intel_num_planes(intel_crtc); i++)
> Â hw->plane[pipe][i][level] =
> @@ -4338,7 +4333,7 @@ static void skl_pipe_wm_get_hw_state(struct
> drm_crtc *crtc)
> Â 
> Â hw->dirty_pipes |= drm_crtc_mask(crtc);
> Â 
> - active->linetime = hw->wm_linetime[pipe];
> + active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
> Â 
> Â for (level = 0; level <= max_level; level++) {
> Â for (i = 0; i < intel_num_planes(intel_crtc); i++) {

[Intel-gfx] [PATCH 1/6] drm/i915/skl: Move per-pipe ddb allocations into crtc states

2016-10-05 Thread Paulo Zanoni

Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> First part of cleaning up all of the skl watermark code. This moves
> the
> structures for storing the ddb allocations of each pipe into
> intel_crtc_state, along with moving the structures for storing the
> current ddb allocations active on hardware into intel_crtc.
> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Matt Roper 
> ---
> Â drivers/gpu/drm/i915/i915_drv.hÂ Â Â Â Â Â |Â Â 1 -
> Â drivers/gpu/drm/i915/intel_display.c | 16 ---
> Â drivers/gpu/drm/i915/intel_drv.hÂ Â Â Â Â |Â Â 8 +---
> Â drivers/gpu/drm/i915/intel_pm.cÂ Â Â Â Â Â | 40 +++---
> --
> Â 4 files changed, 30 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index f8c66ee..85e541c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1636,7 +1636,6 @@ static inline bool skl_ddb_entry_equal(const
> struct skl_ddb_entry *e1,
> Â }
> Â 
> Â struct skl_ddb_allocation {
> - struct skl_ddb_entry pipe[I915_MAX_PIPES];
> Â struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
> /* packed/uv */
> Â struct skl_ddb_entry
> y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
> Â };
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a366656..17733af 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14235,12 +14235,11 @@ static void skl_update_crtcs(struct
> drm_atomic_state *state,
> Â Â Â Â Â Â unsigned int *crtc_vblank_mask)
> Â {
> Â struct drm_device *dev = state->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> Â struct intel_atomic_state *intel_state =
> to_intel_atomic_state(state);
> Â struct drm_crtc *crtc;
> + struct intel_crtc *intel_crtc;
> Â struct drm_crtc_state *old_crtc_state;
> - struct skl_ddb_allocation *new_ddb = &intel_state-
> >wm_results.ddb;
> - struct skl_ddb_allocation *cur_ddb = &dev_priv-
> >wm.skl_hw.ddb;
> + struct intel_crtc_state *cstate;
> Â unsigned int updated = 0;
> Â bool progress;
> Â enum pipe pipe;
> @@ -14258,12 +14257,14 @@ static void skl_update_crtcs(struct
> drm_atomic_state *state,
> Â for_each_crtc_in_state(state, crtc, old_crtc_state,
> i) {
> Â bool vbl_wait = false;
> Â unsigned int cmask = drm_crtc_mask(crtc);
> - pipe = to_intel_crtc(crtc)->pipe;
> +
> + intel_crtc = to_intel_crtc(crtc);
> + cstate = to_intel_crtc_state(crtc->state);
> + pipe = intel_crtc->pipe;
> Â 
> Â if (updated & cmask || !crtc->state->active)
> Â continue;
> - if (skl_ddb_allocation_overlaps(state,
> cur_ddb, new_ddb,
> - pipe))
> + if (skl_ddb_allocation_overlaps(state,
> intel_crtc))
> Â continue;
> Â 
> Â updated |= cmask;
> @@ -14274,7 +14275,8 @@ static void skl_update_crtcs(struct
> drm_atomic_state *state,
> Â Â * then we need to wait for a vblank to pass
> for the
> Â Â * new ddb allocation to take effect.
> Â Â */
> - if (!skl_ddb_allocation_equals(cur_ddb,
> new_ddb, pipe) &&
> + if (!skl_ddb_entry_equal(&cstate-
> >wm.skl.ddb,
> + Â &intel_crtc-
> >hw_ddb) &&
> Â Â Â Â Â !crtc->state->active_changed &&
> Â Â Â Â Â intel_state->wm_results.dirty_pipes !=
> updated)
> Â vbl_wait = true;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index f48e79a..35ba282 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -496,6 +496,7 @@ struct intel_crtc_wm_state {
> Â struct {
> Â /* gen9+ only needs 1-step wm programming */
> Â struct skl_pipe_wm optimal;
> + struct skl_ddb_entry ddb;
> Â 
> Â /* cached plane data rate */
> Â unsigned plane_data_rate[I915_MAX_PLANES];
> @@ -733,6 +734,9 @@ struct intel_crtc {
> Â bool cxsr_allowed;
> Â } wm;
> Â 
> + /* gen9+: ddb allocation currently being used */
> + struct skl_ddb_entry hw_ddb;
> +
> Â int scanline_offset;
> Â 
> Â struct {
> @@ -1755,9 +1759,7 @@ bool skl_ddb_allocation_equals(const struct
> skl_ddb_allocation *old,
> Â Â Â Â Â Â Â Â const struct skl_ddb_allocation *new,
> Â Â Â Â Â Â Â Â enum pipe pipe);
> Â bool skl_ddb_allocation_overlaps(struct drm_atomic_state *stat

kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

2016-10-05 Thread Jani Nikula

On Wed, 05 Oct 2016, Daniel Vetter  wrote:
> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
> parser. Otoh that parser is a horror show of a perl/regex driven state
> machine ;-)
>
> Jani, can you pls digg out these patches? Can't find them right now ...

Expanding the massive Cc: with linux-doc list...

Here goes. It's a quick hack from months ago, but still seems to
somewhat work. At least for the kernel-doc parts. The reStructuredText
lint part isn't all that great, and doesn't have mapping to line numbers
like the Sphinx kernel-doc extension does. Anyway I'm happy how this
integrates with kernel build CHECK and C=1/C=2.

I guess Julia's goal is to automate the *fixing* of some of the error
classes from kernel-doc. Not sure how well this could be made to
integrate with any of that.

BR,
Jani.


>From 1244efa0f63a7b13795e8c37f81733a3c8bfc56a Mon Sep 17 00:00:00 2001
From: Jani Nikula 
Date: Tue, 31 May 2016 18:11:33 +0300
Subject: [PATCH] kernel-doc-rst-lint: add tool to check kernel-doc and rst
 correctness
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula 

Simple kernel-doc and reStructuredText lint tool that can be used
independently and as a kernel build CHECK tool to validate kernel-doc
comments.

Independent usage:
$ kernel-doc-rst-lint FILE

Kernel CHECK usage:
$ make CHECK=scripts/kernel-doc-rst-lint C=1# (or C=2)

Depends on docutils and the rst-lint package
https://pypi.python.org/pypi/restructuredtext_lint

Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc-rst-lint | 106 
 1 file changed, 106 insertions(+)
 create mode 100755 scripts/kernel-doc-rst-lint

diff --git a/scripts/kernel-doc-rst-lint b/scripts/kernel-doc-rst-lint
new file mode 100755
index ..7e0157679f83
--- /dev/null
+++ b/scripts/kernel-doc-rst-lint
@@ -0,0 +1,106 @@
+#!/usr/bin/env python
+# coding=utf-8
+#
+# Copyright Â© 2016 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+# Authors:
+#Jani Nikula 
+#
+# Simple kernel-doc and reStructuredText lint tool that can be used
+# independently and as a kernel build CHECK tool to validate kernel-doc
+# comments.
+#
+# Independent usage:
+# $ kernel-doc-rst-lint FILE
+#
+# Kernel CHECK usage:
+# $ make CHECK=scripts/kernel-doc-rst-lint C=1 # (or C=2)
+#
+# Depends on docutils and the rst-lint package
+# https://pypi.python.org/pypi/restructuredtext_lint
+#
+
+import os
+import subprocess
+import sys
+
+from docutils.parsers.rst import directives
+from docutils.parsers.rst import Directive
+from docutils.parsers.rst import roles
+from docutils import nodes, statemachine
+import restructuredtext_lint
+
+class DummyDirective(Directive):
+required_argument = 1
+optional_arguments = 0
+option_spec = { }
+has_content = True
+
+def run(self):
+return []
+
+# Fake the Sphinx C Domain directives and roles
+directives.register_directive('c:function', DummyDirective)
+directives.register_directive('c:type', DummyDirective)
+roles.register_generic_role('c:func', nodes.emphasis)
+roles.register_generic_role('c:type', nodes.emphasis)
+
+# We accept but ignore parameters to be compatible with how the kernel build
+# invokes CHECK.
+if len(sys.argv) < 2:
+sys.stderr.write('usage: kernel-doc-rst-lint [IGNORED OPTIONS] FILE\n');
+sys.exit(1)
+
+infile = sys.argv[len(sys.argv) - 1]
+cmd = ['scripts/kernel-doc', '-rst', infile]
+
+try:
+p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, 
universal_newlines=True)
+out, err = p.communicate()
+
+# python2 needs conversion to unicode.
+# python3 with universal_newlines=True returns strings.
+if sys.version_info.major < 3:
+out

[PATCH 1/2] drm/fb_cma_helper: Add drm_fb_cma_setup_fence() helper

2016-10-05 Thread Marek Vasut

On 10/03/2016 03:54 PM, Daniel Vetter wrote:
> On Sun, Oct 2, 2016 at 7:19 PM, Marek Vasut  wrote:
 /**
  * drm_fb_cma_extract_and_attach_fence() - Extract fence from plane and
 attach to planestate
  * @plane: Which plane
  * @state: Plane state attach fence to
  *
  * If the plane fb has an dma-buf attached, fish out the exclusive
  * fence and attach it to plane state for the atomic helper to wait
  * on.
  */
>>>
>>> That choice of color is ok with me too, but then you need to have a
>>> pile of text to explain where it should be used (i.e. directly as the
>>> prepare_fb hook).
>>
>> There can be more stuff in the prepare_fb hook though.
> 
> There's 3 things prepare/cleanup_fb should do:
> - pin/upin the backing storage. CMA memory is always pinned, so nothing to do.
> - setup/tear down iommu mappings: Already done when allocating CMA
> memory, again nothing to do.
> - grab fences in prepare.
> 
> So for plain cma drivers this hook is indeed the complete
> implementation they need for prepare_fb. I guess you could mention in
> the kernel-doc that cma based drivers don't need a cleanup_fb, hence
> why there is none.

OK, understood. I'll roll V3 shortly.

-- 
Best regards,
Marek Vasut

[PATCH 00/15] improve function-level documentation

2016-10-05 Thread Julia Lawall



On Wed, 5 Oct 2016, Daniel Vetter wrote:

> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
> parser. Otoh that parser is a horror show of a perl/regex driven state
> machine ;-)

Sure.  To my recollection, I found around 2000 issues.  Many I ignored, eg
functions that simply have no documentation abuot the parameters,
functions that document their local variables, when these were more
interesting than the parameters etc.  But the set of patches is not
exhaustive with respect to the remaining interesting ones either.

julia

>
> Jani, can you pls digg out these patches? Can't find them right now ...
> -Daniel
>
>
> On Sat, Oct 1, 2016 at 9:46 PM, Julia Lawall  wrote:
> > These patches fix cases where the documentation above a function definition
> > is not consistent with the function header.  Issues are detected using the
> > semantic patch below (http://coccinelle.lip6.fr/).  Basically, the semantic
> > patch parses a file to find comments, then matches each function header,
> > and checks that the name and parameter list in the function header are
> > compatible with the comment that preceeds it most closely.
> >
> > // 
> > @initialize:ocaml@
> > @@
> >
> > let tbl = ref []
> > let fnstart = ref []
> > let success = Hashtbl.create 101
> > let thefile = ref ""
> > let parsed = ref []
> > let nea = ref []
> >
> > let parse file =
> >   thefile := List.nth (Str.split (Str.regexp "linux-next/") file) 1;
> >   let i = open_in file in
> >   let startline = ref 0 in
> >   let fn = ref "" in
> >   let ids = ref [] in
> >   let rec inside n =
> > let l = input_line i in
> > let n = n + 1 in
> > match Str.split_delim (Str.regexp_string "*/") l with
> >   before::after::_ ->
> > (if not (!fn = "")
> > then tbl := (!startline,n,!fn,List.rev !ids)::!tbl);
> > startline := 0;
> > fn := "";
> > ids := [];
> > outside n
> > | _ ->
> > (match Str.split (Str.regexp "[ \t]+") l with
> >   "*"::name::rest ->
> > let len = String.length name in
> > (if !fn = "" && len > 2 && String.sub name (len-2) 2 = "()"
> > then fn := String.sub name 0 (len-2)
> > else if !fn = "" && (not (rest = [])) && List.hd rest = "-"
> > then
> >   if String.get name (len-1) = ':'
> >   then fn := String.sub name 0 (len-1)
> >   else fn := name
> > else if not(!fn = "") && len > 2 &&
> >   String.get name 0 = '@' && String.get name (len-1) = ':'
> > then ids := (String.sub name 1 (len-2)) :: !ids);
> > | _ -> ());
> > inside n
> >   and outside n =
> > let l = input_line i in
> > let n = n + 1 in
> > if String.length l > 2 && String.sub l 0 3 = "/**"
> > then
> >   begin
> > startline := n;
> > inside n
> >   end
> > else outside n in
> >   try outside 0 with End_of_file -> ()
> >
> > let hashadd tbl k v =
> >   let cell =
> > try Hashtbl.find tbl k
> > with Not_found ->
> >   let cell = ref [] in
> >   Hashtbl.add tbl k cell;
> >   cell in
> >   cell := v :: !cell
> >
> > @script:ocaml@
> > @@
> >
> > tbl := [];
> > fnstart := [];
> > Hashtbl.clear success;
> > parsed := [];
> > nea := [];
> > parse (List.hd (Coccilib.files()))
> >
> > @r@
> > identifier f;
> > position p;
> > @@
> >
> > f at p(...) { ... }
> >
> > @script:ocaml@
> > p << r.p;
> > f << r.f;
> > @@
> >
> > parsed := f :: !parsed;
> > fnstart := (List.hd p).line :: !fnstart
> >
> > @param@
> > identifier f;
> > type T;
> > identifier i;
> > parameter list[n] ps;
> > parameter list[n1] ps1;
> > position p;
> > @@
> >
> > f at p(ps,T i,ps1) { ... }
> >
> > @script:ocaml@
> > @@
> >
> > tbl := List.rev (List.sort compare !tbl)
> >
> > @script:ocaml@
> > p << param.p;
> > f << param.f;
> > @@
> >
> > let myline = (List.hd p).line in
> > let prevline =
> >   List.fold_left
> > (fun prev x ->
> >   if x < myline
> >   then max x prev
> >   else prev)
> > 0 !fnstart in
> > let _ =
> >   List.exists
> > (function (st,fn,nm,ids) ->
> >   if prevline < st && myline > st && prevline < fn && myline > fn
> >   then
> > begin
> >   (if not (String.lowercase f = String.lowercase nm)
> >   then
> > Printf.printf "%s:%d %s doesn't match preceding comment: %s\n"
> >   !thefile myline f nm);
> >   true
> > end
> >   else false)
> > !tbl in
> > ()
> >
> > @script:ocaml@
> > p << param.p;
> > n << param.n;
> > n1 << param.n1;
> > i << param.i;
> > f << param.f;
> > @@
> >
> > let myline = (List.hd p).line in
> > let prevline =
> >   List.fold_left
> > (fun prev x ->
> >   if x < myline
> >   then max x prev
> >   else prev)
> >

[Intel-gfx] [PATCH 3/6] drm/i915: Add enable_sagv option

2016-10-05 Thread Paulo Zanoni

Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> This option allows us to manually control the SAGV at module load
> time.
> This can be useful in situations such as trying to debug watermark
> changes, since enabled SAGV + incorrect watermarks = total GPU
> annihilation.

I'm not a huge fan of adding options that are only for very limited
debugging situations, especially simple ones that can always just be
re-implemented during debugging sessions such as this one. Anyway, I'm
not opposed to adding the option since it's marked as unsafe anyway,
I'm just stating my general opinion. See more below.


> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Matt Roper 
> ---
> Â drivers/gpu/drm/i915/i915_params.cÂ Â Â |Â Â 5 +
> Â drivers/gpu/drm/i915/i915_params.hÂ Â Â |Â Â 1 +
> Â drivers/gpu/drm/i915/intel_display.c | 16 +---
> Â 3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 768ad89..f462cd4 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -62,6 +62,7 @@ struct i915_params i915 __read_mostly = {
> Â .inject_load_failure = 0,
> Â .enable_dpcd_backlight = false,
> Â .enable_gvt = false,
> + .enable_sagv = -1,
> Â };
> Â 
> Â module_param_named(modeset, i915.modeset, int, 0400);
> @@ -233,3 +234,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> Â module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> Â MODULE_PARM_DESC(enable_gvt,
> Â "Enable support for Intel GVT-g graphics virtualization host
> support(default:false)");
> +
> +module_param_named_unsafe(enable_sagv, i915.enable_sagv, int, 0400);
> +MODULE_PARM_DESC(enable_sagv,
> + "Enable the SAGV (gen9+ only)(1=enabled, 0=disabled,
> -1=driver discretion [default])");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 3a0dd78..a7db125 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -65,6 +65,7 @@ struct i915_params {
> Â bool enable_dp_mst;
> Â bool enable_dpcd_backlight;
> Â bool enable_gvt;
> + int enable_sagv;
> Â };
> Â 
> Â extern struct i915_params i915 __read_mostly;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a71d05a..dd15ae2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -16904,12 +16904,22 @@ intel_modeset_setup_hw_state(struct
> drm_device *dev)
> Â pll->on = false;
> Â }
> Â 
> - if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
> + if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> Â vlv_wm_get_hw_state(dev);
> - else if (IS_GEN9(dev))
> + } else if (IS_GEN9(dev)) {
> Â skl_wm_get_hw_state(dev);
> - else if (HAS_PCH_SPLIT(dev))
> +
> + if (i915.enable_sagv != -1) {
> + if (i915.enable_sagv)
> + intel_enable_sagv(dev_priv);
> + else
> + intel_disable_sagv(dev_priv);
> +
> + dev_priv->sagv_status =
> I915_SAGV_NOT_CONTROLLED;

Adding this code to the middle of a get_hw_state() if-ladder doesn't
seem to be the best approach. My suggestion would be to create
intel_setup_sagv() (or intel_init_sagv) and then call it from somewhere
(maybe the end of this function?).

Also, I915_SAGV_NOT_CONTROLLED is only used on Skylake. By setting
sagv_status to to you're making i915.enable_sagv behave differently on
SKL compared to "all the other" (aka only KBL now) platforms. It would
probably be better to have unified behavior, maybe by reworking the
I915_SAGV_NOT_CONTROLLED handling or just adding a new flag or
something else.


> + }
> + } else if (HAS_PCH_SPLIT(dev)) {
> Â ilk_wm_get_hw_state(dev);
> + }
> Â 
> Â for_each_intel_crtc(dev, crtc) {
> Â unsigned long put_domains;

[PATCH] drm/bridge: Call drm_connector_cleanup directly

2016-10-05 Thread Marek Vasut

On 10/05/2016 04:20 PM, Gustavo Padovan wrote:
> Hi Marek,
> 
> 2016-10-05 Marek Vasut :
> 
>> On 10/05/2016 03:21 PM, Daniel Vetter wrote:
>>> On Wed, Oct 05, 2016 at 11:03:20AM +0200, Gustavo Padovan wrote:
 Hi Marek,

 2016-10-05 Marek Vasut :

> Remove the unnecessary wrapper functions around drm_connector_cleanup().
>
> Signed-off-by: Marek Vasut 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 7 +--
>  drivers/gpu/drm/bridge/nxp-ptn3460.c  | 7 +--
>  drivers/gpu/drm/bridge/parade-ps8622.c| 7 +--
>  3 files changed, 3 insertions(+), 18 deletions(-)

 Reviewed-by: Gustavo Padovan 
>>>
>>> Yeah, nice little cleanup. Applied to drm-misc.
>>
>> So while we're at it, I also found drivers with code like [1]. Is
>> calling the drm_connector_unregister() necessary in there at all ?
>> Or shall we convert it the same way as the three drivers above ?
> 
> drm_connector_register/unregister() are not necessary anymore as this is
> handled by drm_dev_register() now. So these drivers can be clean up as
> well.

OK, got it. Patch is out.

-- 
Best regards,
Marek Vasut

[PATCH] drm/bridge: Drop drm_connector_unregister and call drm_connector_cleanup directly

2016-10-05 Thread Marek Vasut

Drop unneeded drm_connector_unregister() and remove the unnecessary
wrapper functions around drm_connector_cleanup().

Signed-off-by: Marek Vasut 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
 drivers/gpu/drm/bridge/dw-hdmi.c   | 8 +---
 drivers/gpu/drm/bridge/tc358767.c  | 8 +---
 3 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 001b075..6e0447f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -999,18 +999,11 @@ analogix_dp_detect(struct drm_connector *connector, bool 
force)
return status;
 }

-static void analogix_dp_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-
-}
-
 static const struct drm_connector_funcs analogix_dp_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = analogix_dp_detect,
-   .destroy = analogix_dp_connector_destroy,
+   .destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 66ad8e6..ab7023e 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1477,12 +1477,6 @@ dw_hdmi_connector_mode_valid(struct drm_connector 
*connector,
return mode_status;
 }

-static void dw_hdmi_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
 static void dw_hdmi_connector_force(struct drm_connector *connector)
 {
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
@@ -1499,7 +1493,7 @@ static const struct drm_connector_funcs 
dw_hdmi_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = dw_hdmi_connector_detect,
-   .destroy = dw_hdmi_connector_destroy,
+   .destroy = drm_connector_cleanup,
.force = dw_hdmi_connector_force,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index a09825d..44d476e 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1165,17 +1165,11 @@ static const struct drm_connector_helper_funcs 
tc_connector_helper_funcs = {
.best_encoder = tc_connector_best_encoder,
 };

-static void tc_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
 static const struct drm_connector_funcs tc_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = tc_connector_detect,
-   .destroy = tc_connector_destroy,
+   .destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-- 
2.9.3

[PATCH 2/3] drm/fb_cma_helper: Add panic handling

2016-10-05 Thread Laurent Pinchart

Hi Noralf,

Thank you for the patch.

On Sunday 11 Sep 2016 20:47:41 Noralf TrÃ¸nnes wrote:
> This enables panic message output for fb cma helper framebuffers.
> 
> Signed-off-by: Noralf TrÃ¸nnes 
> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index 1fd6eac..2f1b012 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -126,9 +126,19 @@ int drm_fb_cma_create_handle(struct drm_framebuffer
> *fb, }
>  EXPORT_SYMBOL(drm_fb_cma_create_handle);
> 
> +static void *drm_fb_cma_panic_vmap(struct drm_framebuffer *fb)
> +{
> + struct drm_fb_cma *fb_cma = to_fb_cma(fb);
> + struct drm_gem_cma_object *cma_obj = fb_cma->obj[0];
> +
> + /* A PRIME imported buffer will not have it's vaddr set. */

Does this mean that, if the framebuffer that happens to be displayed when a 
panic occurs is imported, no message will be printed ? I understand how 
supporting such cases is difficult, but I'm wondering how we could proceed to 
ensure that a panic can be displayed in most (if not all) cases.

Similarly, it looks like your code only handles single-planar formats, but 
there's no explicit check for that in patch 1/3. The easiest fix is to reject 
multi-planar framebuffers, but that would again result in silent panics in 
some cases.

> + return cma_obj ? cma_obj->vaddr : NULL;

Can cma_obj be NULL here ? I thought that framebuffer objects were always 
created with at least one GEM object.

> +}
> +
>  static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
>   .destroy= drm_fb_cma_destroy,
>   .create_handle  = drm_fb_cma_create_handle,
> + .panic_vmap = drm_fb_cma_panic_vmap,
>  };
> 
>  static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,

-- 
Regards,

Laurent Pinchart

[PATCH] drm/bridge: Call drm_connector_cleanup directly

2016-10-05 Thread Gustavo Padovan

Hi Marek,

2016-10-05 Marek Vasut :

> On 10/05/2016 03:21 PM, Daniel Vetter wrote:
> > On Wed, Oct 05, 2016 at 11:03:20AM +0200, Gustavo Padovan wrote:
> >> Hi Marek,
> >>
> >> 2016-10-05 Marek Vasut :
> >>
> >>> Remove the unnecessary wrapper functions around drm_connector_cleanup().
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Cc: Daniel Vetter 
> >>> ---
> >>>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 7 +--
> >>>  drivers/gpu/drm/bridge/nxp-ptn3460.c  | 7 +--
> >>>  drivers/gpu/drm/bridge/parade-ps8622.c| 7 +--
> >>>  3 files changed, 3 insertions(+), 18 deletions(-)
> >>
> >> Reviewed-by: Gustavo Padovan 
> > 
> > Yeah, nice little cleanup. Applied to drm-misc.
> 
> So while we're at it, I also found drivers with code like [1]. Is
> calling the drm_connector_unregister() necessary in there at all ?
> Or shall we convert it the same way as the three drivers above ?

drm_connector_register/unregister() are not necessary anymore as this is
handled by drm_dev_register() now. So these drivers can be clean up as
well.

Gustavo

[PATCH V3] drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks

2016-10-05 Thread Marek Vasut

On 10/05/2016 03:18 PM, Daniel Vetter wrote:
> On Sun, Oct 02, 2016 at 07:01:24PM +0200, Marek Vasut wrote:
>> Add .prepare_fb and .cleanup_fb plane hooks into the drm_simple_kms.
>> These can be used by drivers to call ie. the drm_fb_cma_setup_fence()
>> helper.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Noralf TrÃ¸nnes 
>> Cc: Daniel Vetter 
>> Cc: David Airlie 
>> ---
>> V2: Fix the documentation style to play well with make htmldocs
>> V3: Re-add the clause about finding more details in drm_plane_helper_funcs
> 
> Real pretty now I think ;-) Applied to drm-misc, thanks.

Appreciate your patience with my borderline clueless hacking, thanks.

> -Daniel
> 
>> ---
>>  drivers/gpu/drm/drm_simple_kms_helper.c | 26 ++
>>  include/drm/drm_simple_kms_helper.h | 20 
>>  2 files changed, 46 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
>> b/drivers/gpu/drm/drm_simple_kms_helper.c
>> index 7b6d26e..7bae08c 100644
>> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
>> @@ -125,7 +125,33 @@ static void drm_simple_kms_plane_atomic_update(struct 
>> drm_plane *plane,
>>  pipe->funcs->update(pipe, pstate);
>>  }
>>  
>> +static int drm_simple_kms_plane_prepare_fb(struct drm_plane *plane,
>> +   struct drm_plane_state *state)
>> +{
>> +struct drm_simple_display_pipe *pipe;
>> +
>> +pipe = container_of(plane, struct drm_simple_display_pipe, plane);
>> +if (!pipe->funcs || !pipe->funcs->prepare_fb)
>> +return 0;
>> +
>> +return pipe->funcs->prepare_fb(pipe, state);
>> +}
>> +
>> +static void drm_simple_kms_plane_cleanup_fb(struct drm_plane *plane,
>> +struct drm_plane_state *state)
>> +{
>> +struct drm_simple_display_pipe *pipe;
>> +
>> +pipe = container_of(plane, struct drm_simple_display_pipe, plane);
>> +if (!pipe->funcs || !pipe->funcs->cleanup_fb)
>> +return;
>> +
>> +pipe->funcs->cleanup_fb(pipe, state);
>> +}
>> +
>>  static const struct drm_plane_helper_funcs 
>> drm_simple_kms_plane_helper_funcs = {
>> +.prepare_fb = drm_simple_kms_plane_prepare_fb,
>> +.cleanup_fb = drm_simple_kms_plane_cleanup_fb,
>>  .atomic_check = drm_simple_kms_plane_atomic_check,
>>  .atomic_update = drm_simple_kms_plane_atomic_update,
>>  };
>> diff --git a/include/drm/drm_simple_kms_helper.h 
>> b/include/drm/drm_simple_kms_helper.h
>> index 5d112f7..01a8436 100644
>> --- a/include/drm/drm_simple_kms_helper.h
>> +++ b/include/drm/drm_simple_kms_helper.h
>> @@ -69,6 +69,26 @@ struct drm_simple_display_pipe_funcs {
>>   */
>>  void (*update)(struct drm_simple_display_pipe *pipe,
>> struct drm_plane_state *plane_state);
>> +
>> +/**
>> + * @prepare_fb:
>> + *
>> + * Optional, called by struct &drm_plane_helper_funcs ->prepare_fb .
>> + * Please read the documentation for the ->prepare_fb hook in
>> + * struct &drm_plane_helper_funcs for more details.
>> + */
>> +int (*prepare_fb)(struct drm_simple_display_pipe *pipe,
>> +  struct drm_plane_state *plane_state);
>> +
>> +/**
>> + * @cleanup_fb:
>> + *
>> + * Optional, called by struct &drm_plane_helper_funcs ->cleanup_fb .
>> + * Please read the documentation for the ->cleanup_fb hook in
>> + * struct &drm_plane_helper_funcs for more details.
>> + */
>> +void (*cleanup_fb)(struct drm_simple_display_pipe *pipe,
>> +   struct drm_plane_state *plane_state);
>>  };
>>  
>>  /**
>> -- 
>> 2.9.3
>>
> 


-- 
Best regards,
Marek Vasut

[PATCH] drm/bridge: Call drm_connector_cleanup directly

2016-10-05 Thread Marek Vasut

On 10/05/2016 03:21 PM, Daniel Vetter wrote:
> On Wed, Oct 05, 2016 at 11:03:20AM +0200, Gustavo Padovan wrote:
>> Hi Marek,
>>
>> 2016-10-05 Marek Vasut :
>>
>>> Remove the unnecessary wrapper functions around drm_connector_cleanup().
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Daniel Vetter 
>>> ---
>>>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 7 +--
>>>  drivers/gpu/drm/bridge/nxp-ptn3460.c  | 7 +--
>>>  drivers/gpu/drm/bridge/parade-ps8622.c| 7 +--
>>>  3 files changed, 3 insertions(+), 18 deletions(-)
>>
>> Reviewed-by: Gustavo Padovan 
> 
> Yeah, nice little cleanup. Applied to drm-misc.

So while we're at it, I also found drivers with code like [1]. Is
calling the drm_connector_unregister() necessary in there at all ?
Or shall we convert it the same way as the three drivers above ?

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/bridge/tc358767.c#n1168

> -Daniel
> 


-- 
Best regards,
Marek Vasut

[PATCH v4 1/3] drm/prime: Pass the right module owner through to dma_buf_export()

2016-10-05 Thread Petri Latvala

For the series:

Reviewed-by: Petri Latvala 

On 10/05/2016 03:21 PM, Chris Wilson wrote:
> dma_buf_export() adds a reference to the owning module to the dmabuf (to
> prevent the driver from being unloaded whilst a third party still refers
> to the dmabuf). However, drm_gem_prime_export() was passing its own
> THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right
> owner from the device->fops instead.
>
> v2: Use C99 initializers to zero out unset elements of
> dma_buf_export_info
> v3: Extract the right module from dev->fops.
>
> Testcase: igt/vgem_basic/unload
> Reported-by: Petri Latvala 
> Signed-off-by: Chris Wilson 
> Cc: Petri Latvala 
> Cc: Christian KÃ¶nig 
> Cc: stable at vger.kernel.org
> Tested-by: Petri Latvala 
> ---
>   drivers/gpu/drm/drm_prime.c | 17 ++---
>   include/drm/drmP.h  |  3 ++-
>   2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 57201d68cf61..80907b34d857 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -397,14 +397,17 @@ static const struct dma_buf_ops 
> drm_gem_prime_dmabuf_ops =  {
>* using the PRIME helpers.
>*/
>   struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> -  struct drm_gem_object *obj, int flags)
> +  struct drm_gem_object *obj,
> +  int flags)
>   {
> - DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> -
> - exp_info.ops = &drm_gem_prime_dmabuf_ops;
> - exp_info.size = obj->size;
> - exp_info.flags = flags;
> - exp_info.priv = obj;
> + struct dma_buf_export_info exp_info = {
> + .exp_name = KBUILD_MODNAME, /* white lie for debug */
> + .owner = dev->driver->fops->owner,
> + .ops = &drm_gem_prime_dmabuf_ops,
> + .size = obj->size,
> + .flags = flags,
> + .priv = obj,
> + };
>   
>   if (dev->driver->gem_prime_res_obj)
>   exp_info.resv = dev->driver->gem_prime_res_obj(obj);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 0e99669159c1..81fcd553edf7 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1012,7 +1012,8 @@ static inline int drm_debugfs_remove_files(const struct 
> drm_info_list *files,
>   #endif
>   
>   extern struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> - struct drm_gem_object *obj, int flags);
> + struct drm_gem_object *obj,
> + int flags);
>   extern int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>   struct drm_file *file_priv, uint32_t handle, uint32_t flags,
>   int *prime_fd);

[Bug 97894] Crash in u_transfer_unmap_vtbl when unmapping a buffer mapped in different context

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

Nicolai HÃ¤hnle  changed:

   What|Removed |Added

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

--- Comment #5 from Nicolai HÃ¤hnle  ---
Fixed in Mesa master (commit e56e1f8119f28eebbe6fbe7040c80a6dd884f5fd).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/88c32364/attachment.html>

[PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-05 Thread Daniel Vetter

On Wed, Oct 05, 2016 at 03:40:14PM +0200, Benjamin Gaignard wrote:
> because with ion it is up to userland to decide which heap to use
> and until now userland doesn't have any way to get device constraints...
> 
> I will prefer let a central allocator (in kernel) decide from the
> attached devices
> which allocator is the best. It is what I have implemented in smaf.

And how does that work? Atm there's no interfaces at all in the kernel to
allocate a buffer suitable for 2 devices at the same time. Seems
incomplete if this is the direction you want to go to. Also, it's against
the direction we all discussed ad XDC, where the clear consensus was to
have most of that haggling in userspace (with the kernel exporting a
little bit more information to userspace than what it does now).
-Daniel

> 
> Benjamin
> 
> 
> 2016-10-05 15:19 GMT+02:00 Daniel Vetter :
> > On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote:
> >> version 10 changes:
> >>  - rebased on kernel 4.8 tag
> >>  - minor typo fix
> >>
> >> version 9 changes:
> >>  - rebased on 4.8-rc5
> >>  - struct dma_attrs doesn't exist anymore so update CMA allocator
> >>to compile with new dma_*_attr functions
> >>  - add example SMAF use case in cover letter
> >>
> >> version 8 changes:
> >>  - rework of the structures used within ioctl
> >>by adding a version field and padding to be futur proof
> >>  - rename fake secure moduel to test secure module
> >>  - fix the various remarks done on the previous patcheset
> >>
> >> version 7 changes:
> >>  - rebased on kernel 4.6-rc7
> >>  - simplify secure module API
> >>  - add vma ops to be able to detect mmap/munmap calls
> >>  - add ioctl to get number and allocator names
> >>  - update libsmaf with adding tests
> >>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
> >>  - add debug log in fake secure module
> >>
> >> version 6 changes:
> >>  - rebased on kernel 4.5-rc4
> >>  - fix mmapping bug while requested allocation size isn't a a multiple of
> >>PAGE_SIZE (add a test for this in libsmaf)
> >>
> >> version 5 changes:
> >>  - rebased on kernel 4.3-rc6
> >>  - rework locking schema and make handle status use an atomic_t
> >>  - add a fake secure module to allow performing tests without trusted
> >>environment
> >>
> >> version 4 changes:
> >>  - rebased on kernel 4.3-rc3
> >>  - fix missing EXPORT_SYMBOL for smaf_create_handle()
> >>
> >> version 3 changes:
> >>  - Remove ioctl for allocator selection instead provide the name of
> >>the targeted allocator with allocation request.
> >>Selecting allocator from userland isn't the prefered way of working
> >>but is needed when the first user of the buffer is a software component.
> >>  - Fix issues in case of error while creating smaf handle.
> >>  - Fix module license.
> >>  - Update libsmaf and tests to care of the SMAF API evolution
> >>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
> >>
> >> version 2 changes:
> >>  - Add one ioctl to allow allocator selection from userspace.
> >>This is required for the uses case where the first user of
> >>the buffer is a software IP which can't perform dma_buf attachement.
> >>  - Add name and ranking to allocator structure to be able to sort them.
> >>  - Create a tiny library to test SMAF:
> >>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
> >>  - Fix one issue when try to secure buffer without secure module registered
> >>
> >> SMAF aim to solve two problems: allocating memory that fit with hardware 
> >> IPs
> >> constraints and secure those data from bus point of view.
> >>
> >> One example of SMAF usage is camera preview: on SoC you may use either an 
> >> USB
> >> webcam or the built-in camera interface and the frames could be send 
> >> directly
> >> to the dipslay Ip or handle by GPU.
> >> Most of USB interfaces and GPU have mmu but almost all built-in camera
> >> interace and display Ips don't have mmu so when selecting how allocate
> >> buffer you need to be aware of each devices constraints (contiguous memroy,
> >> stride, boundary, alignment ...).
> >> ION has solve this problem by let userland decide which allocator (heap) 
> >> to use
> >> but this require to adapt userland for each platform and sometime for each
> >> use case.
> >>
> >> To be sure to select the best allocation method for devices SMAF implement
> >> deferred allocation mechanism: memory allocation is only done when the 
> >> first
> >> device effectively required it.
> >> Allocator modules have to implement a match() to let SMAF know if they are
> >> compatibles with devices needs.
> >> This patch set provide an example of allocator module which use
> >> dma_{alloc/free/mmap}_attrs() and check if at least one device have
> >> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
> >>
> >> In the same camera preview use case, SMAF allow to protect the data from 
> >> being
> >> read by unauthorized IPs (i.e. a malware to dump camera stream).

[Intel-gfx] [PATCH v3 3/3] drm/vgem: Keep a reference to the dmabuf when mmaped

2016-10-05 Thread Daniel Vetter

On Wed, Oct 05, 2016 at 02:40:09PM +0100, Chris Wilson wrote:
> On Wed, Oct 05, 2016 at 03:11:00PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 30, 2016 at 02:59:59PM +0100, Chris Wilson wrote:
> > > In order to keep the dmabuf alive whilst the mmap is, we need to hold a
> > > reference to the dmabuf and not the backing object. This is important as
> > > the dmabuf not only keeps the object alive, but also the device so that
> > > 
> > >   dmabuf = vgem_create_dmabuf();
> > >   ptr = mmap(... dmabuf ...);
> > >   close(dmabuf);
> > > 
> > > persists across module-unload as well as device closure.
> > 
> > I don't see where we grab the ref to the dma-buf here instead of the
> > backing storage. And doesn't the exact same issue happen when you use dumb
> > mmap? Or maybe I'm just a bit confused about what's going on here ...
> 
> The reference to the dmabuf is in vma->vm_file, which was used to keep
> the module alive. So this might be overzealous, in that there shouldn't
> be a way to get back from the shmemfs object to the module. However,
> that does make me aware of a failure path we have in patches that do add
> callbacks from shmemfs to the driver...
> 
> At least using the ptr after closing the module is ok. So this patch is
> not required.

I think if we entirely redirect the mmap to shmem, and not forget to also
update vm_file, the driver could get unloaded without ill effects. I'll
leave this one out for now, picked up 1&2 from v4 to -misc meanwhile.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-05 Thread Benjamin Gaignard

because with ion it is up to userland to decide which heap to use
and until now userland doesn't have any way to get device constraints...

I will prefer let a central allocator (in kernel) decide from the
attached devices
which allocator is the best. It is what I have implemented in smaf.

Benjamin


2016-10-05 15:19 GMT+02:00 Daniel Vetter :
> On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote:
>> version 10 changes:
>>  - rebased on kernel 4.8 tag
>>  - minor typo fix
>>
>> version 9 changes:
>>  - rebased on 4.8-rc5
>>  - struct dma_attrs doesn't exist anymore so update CMA allocator
>>to compile with new dma_*_attr functions
>>  - add example SMAF use case in cover letter
>>
>> version 8 changes:
>>  - rework of the structures used within ioctl
>>by adding a version field and padding to be futur proof
>>  - rename fake secure moduel to test secure module
>>  - fix the various remarks done on the previous patcheset
>>
>> version 7 changes:
>>  - rebased on kernel 4.6-rc7
>>  - simplify secure module API
>>  - add vma ops to be able to detect mmap/munmap calls
>>  - add ioctl to get number and allocator names
>>  - update libsmaf with adding tests
>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>  - add debug log in fake secure module
>>
>> version 6 changes:
>>  - rebased on kernel 4.5-rc4
>>  - fix mmapping bug while requested allocation size isn't a a multiple of
>>PAGE_SIZE (add a test for this in libsmaf)
>>
>> version 5 changes:
>>  - rebased on kernel 4.3-rc6
>>  - rework locking schema and make handle status use an atomic_t
>>  - add a fake secure module to allow performing tests without trusted
>>environment
>>
>> version 4 changes:
>>  - rebased on kernel 4.3-rc3
>>  - fix missing EXPORT_SYMBOL for smaf_create_handle()
>>
>> version 3 changes:
>>  - Remove ioctl for allocator selection instead provide the name of
>>the targeted allocator with allocation request.
>>Selecting allocator from userland isn't the prefered way of working
>>but is needed when the first user of the buffer is a software component.
>>  - Fix issues in case of error while creating smaf handle.
>>  - Fix module license.
>>  - Update libsmaf and tests to care of the SMAF API evolution
>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>
>> version 2 changes:
>>  - Add one ioctl to allow allocator selection from userspace.
>>This is required for the uses case where the first user of
>>the buffer is a software IP which can't perform dma_buf attachement.
>>  - Add name and ranking to allocator structure to be able to sort them.
>>  - Create a tiny library to test SMAF:
>>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>  - Fix one issue when try to secure buffer without secure module registered
>>
>> SMAF aim to solve two problems: allocating memory that fit with hardware IPs
>> constraints and secure those data from bus point of view.
>>
>> One example of SMAF usage is camera preview: on SoC you may use either an USB
>> webcam or the built-in camera interface and the frames could be send directly
>> to the dipslay Ip or handle by GPU.
>> Most of USB interfaces and GPU have mmu but almost all built-in camera
>> interace and display Ips don't have mmu so when selecting how allocate
>> buffer you need to be aware of each devices constraints (contiguous memroy,
>> stride, boundary, alignment ...).
>> ION has solve this problem by let userland decide which allocator (heap) to 
>> use
>> but this require to adapt userland for each platform and sometime for each
>> use case.
>>
>> To be sure to select the best allocation method for devices SMAF implement
>> deferred allocation mechanism: memory allocation is only done when the first
>> device effectively required it.
>> Allocator modules have to implement a match() to let SMAF know if they are
>> compatibles with devices needs.
>> This patch set provide an example of allocator module which use
>> dma_{alloc/free/mmap}_attrs() and check if at least one device have
>> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
>>
>> In the same camera preview use case, SMAF allow to protect the data from 
>> being
>> read by unauthorized IPs (i.e. a malware to dump camera stream).
>> Until now I have only see access rights protection at process/thread level
>> (PKeys/MPK) or on file (SELinux) but nothing allow to drive data bus 
>> firewalls.
>> SMAF propose an interface to control and implement those firewalls.
>> Like IOMMU, firewalls IPs can help to protect memory from malicious/faulty 
>> devices
>> that are attempting DMA attacks.
>>
>> Secure modules are responsibles of granting and revoking devices access 
>> rights
>> on the memory. Secure module is also called to check if CPU map memory into
>> kernel and user address spaces.
>> An example of secure module implementation can be found here:
>> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
>> This code isn't ye

[PATCH] drm/bridge: Call drm_connector_cleanup directly

2016-10-05 Thread Daniel Vetter

On Wed, Oct 05, 2016 at 11:03:20AM +0200, Gustavo Padovan wrote:
> Hi Marek,
> 
> 2016-10-05 Marek Vasut :
> 
> > Remove the unnecessary wrapper functions around drm_connector_cleanup().
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/bridge/analogix-anx78xx.c | 7 +--
> >  drivers/gpu/drm/bridge/nxp-ptn3460.c  | 7 +--
> >  drivers/gpu/drm/bridge/parade-ps8622.c| 7 +--
> >  3 files changed, 3 insertions(+), 18 deletions(-)
> 
> Reviewed-by: Gustavo Padovan 

Yeah, nice little cleanup. Applied to drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-05 Thread Daniel Vetter

On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote:
> version 10 changes:
>  - rebased on kernel 4.8 tag
>  - minor typo fix
> 
> version 9 changes:
>  - rebased on 4.8-rc5
>  - struct dma_attrs doesn't exist anymore so update CMA allocator
>to compile with new dma_*_attr functions
>  - add example SMAF use case in cover letter
> 
> version 8 changes:
>  - rework of the structures used within ioctl
>by adding a version field and padding to be futur proof
>  - rename fake secure moduel to test secure module
>  - fix the various remarks done on the previous patcheset
> 
> version 7 changes:
>  - rebased on kernel 4.6-rc7
>  - simplify secure module API
>  - add vma ops to be able to detect mmap/munmap calls
>  - add ioctl to get number and allocator names
>  - update libsmaf with adding tests
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>  - add debug log in fake secure module
> 
> version 6 changes:
>  - rebased on kernel 4.5-rc4
>  - fix mmapping bug while requested allocation size isn't a a multiple of
>PAGE_SIZE (add a test for this in libsmaf)
> 
> version 5 changes:
>  - rebased on kernel 4.3-rc6
>  - rework locking schema and make handle status use an atomic_t
>  - add a fake secure module to allow performing tests without trusted
>environment
> 
> version 4 changes:
>  - rebased on kernel 4.3-rc3
>  - fix missing EXPORT_SYMBOL for smaf_create_handle()
> 
> version 3 changes:
>  - Remove ioctl for allocator selection instead provide the name of
>the targeted allocator with allocation request.
>Selecting allocator from userland isn't the prefered way of working
>but is needed when the first user of the buffer is a software component.
>  - Fix issues in case of error while creating smaf handle.
>  - Fix module license.
>  - Update libsmaf and tests to care of the SMAF API evolution
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
> 
> version 2 changes:
>  - Add one ioctl to allow allocator selection from userspace.
>This is required for the uses case where the first user of
>the buffer is a software IP which can't perform dma_buf attachement.
>  - Add name and ranking to allocator structure to be able to sort them.
>  - Create a tiny library to test SMAF:
>https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>  - Fix one issue when try to secure buffer without secure module registered
> 
> SMAF aim to solve two problems: allocating memory that fit with hardware IPs
> constraints and secure those data from bus point of view.
> 
> One example of SMAF usage is camera preview: on SoC you may use either an USB
> webcam or the built-in camera interface and the frames could be send directly
> to the dipslay Ip or handle by GPU.
> Most of USB interfaces and GPU have mmu but almost all built-in camera
> interace and display Ips don't have mmu so when selecting how allocate
> buffer you need to be aware of each devices constraints (contiguous memroy,
> stride, boundary, alignment ...).
> ION has solve this problem by let userland decide which allocator (heap) to 
> use
> but this require to adapt userland for each platform and sometime for each
> use case.
> 
> To be sure to select the best allocation method for devices SMAF implement
> deferred allocation mechanism: memory allocation is only done when the first
> device effectively required it.
> Allocator modules have to implement a match() to let SMAF know if they are
> compatibles with devices needs.
> This patch set provide an example of allocator module which use
> dma_{alloc/free/mmap}_attrs() and check if at least one device have
> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
> 
> In the same camera preview use case, SMAF allow to protect the data from being
> read by unauthorized IPs (i.e. a malware to dump camera stream).
> Until now I have only see access rights protection at process/thread level 
> (PKeys/MPK) or on file (SELinux) but nothing allow to drive data bus 
> firewalls.
> SMAF propose an interface to control and implement those firewalls.
> Like IOMMU, firewalls IPs can help to protect memory from malicious/faulty 
> devices
> that are attempting DMA attacks.
> 
> Secure modules are responsibles of granting and revoking devices access rights
> on the memory. Secure module is also called to check if CPU map memory into
> kernel and user address spaces.
> An example of secure module implementation can be found here:
> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
> This code isn't yet part of the patch set because it depends on generic TEE
> which is still under discussion (https://lwn.net/Articles/644646/)
> 
> For allocation part of SMAF code I get inspirated by Sumit Semwal work about
> constraint aware allocator.

semi-random review comment, and a bit late: Why not implement smaf as a
new heap in ion? I think consensus is pretty much that we'll be stuck with
ion forever, and I think it's better to have 1 central

[PATCH V3] drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks

2016-10-05 Thread Daniel Vetter

On Sun, Oct 02, 2016 at 07:01:24PM +0200, Marek Vasut wrote:
> Add .prepare_fb and .cleanup_fb plane hooks into the drm_simple_kms.
> These can be used by drivers to call ie. the drm_fb_cma_setup_fence()
> helper.
> 
> Signed-off-by: Marek Vasut 
> Cc: Noralf TrÃ¸nnes 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
> V2: Fix the documentation style to play well with make htmldocs
> V3: Re-add the clause about finding more details in drm_plane_helper_funcs

Real pretty now I think ;-) Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 26 ++
>  include/drm/drm_simple_kms_helper.h | 20 
>  2 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 7b6d26e..7bae08c 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -125,7 +125,33 @@ static void drm_simple_kms_plane_atomic_update(struct 
> drm_plane *plane,
>   pipe->funcs->update(pipe, pstate);
>  }
>  
> +static int drm_simple_kms_plane_prepare_fb(struct drm_plane *plane,
> +struct drm_plane_state *state)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> + if (!pipe->funcs || !pipe->funcs->prepare_fb)
> + return 0;
> +
> + return pipe->funcs->prepare_fb(pipe, state);
> +}
> +
> +static void drm_simple_kms_plane_cleanup_fb(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> + if (!pipe->funcs || !pipe->funcs->cleanup_fb)
> + return;
> +
> + pipe->funcs->cleanup_fb(pipe, state);
> +}
> +
>  static const struct drm_plane_helper_funcs drm_simple_kms_plane_helper_funcs 
> = {
> + .prepare_fb = drm_simple_kms_plane_prepare_fb,
> + .cleanup_fb = drm_simple_kms_plane_cleanup_fb,
>   .atomic_check = drm_simple_kms_plane_atomic_check,
>   .atomic_update = drm_simple_kms_plane_atomic_update,
>  };
> diff --git a/include/drm/drm_simple_kms_helper.h 
> b/include/drm/drm_simple_kms_helper.h
> index 5d112f7..01a8436 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -69,6 +69,26 @@ struct drm_simple_display_pipe_funcs {
>*/
>   void (*update)(struct drm_simple_display_pipe *pipe,
>  struct drm_plane_state *plane_state);
> +
> + /**
> +  * @prepare_fb:
> +  *
> +  * Optional, called by struct &drm_plane_helper_funcs ->prepare_fb .
> +  * Please read the documentation for the ->prepare_fb hook in
> +  * struct &drm_plane_helper_funcs for more details.
> +  */
> + int (*prepare_fb)(struct drm_simple_display_pipe *pipe,
> +   struct drm_plane_state *plane_state);
> +
> + /**
> +  * @cleanup_fb:
> +  *
> +  * Optional, called by struct &drm_plane_helper_funcs ->cleanup_fb .
> +  * Please read the documentation for the ->cleanup_fb hook in
> +  * struct &drm_plane_helper_funcs for more details.
> +  */
> + void (*cleanup_fb)(struct drm_simple_display_pipe *pipe,
> +struct drm_plane_state *plane_state);
>  };
>  
>  /**
> -- 
> 2.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: Release resources with a safer function

2016-10-05 Thread Daniel Vetter

On Sun, Oct 02, 2016 at 08:01:22AM +0200, Christophe JAILLET wrote:
> We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing
> resources allocated with 'ida_simple_get()'.
> 
> This as been spotted with the following coccinelle script which tries to
> detect missing 'ida_simple_remove()' call in error handling paths.
> 
> ///
> @@
> expression x;
> identifier l;
> @@
> 
> *   x = ida_simple_get(...);
> ...
> if (...) {
> ...
> }
> ...
> if (...) {
>...
>goto l;
> }
> ...
> *   l: ... when != ida_simple_remove(...);
> 
> Signed-off-by: Christophe JAILLET 

kerneldoc for ida_simple_get/remove is rather sparse, would be great to
improve that a bit. Merged this one to drm-misc now, follow-up patch for
the place Ville spotted would be great too.
-Daniel

> ---
>  drivers/gpu/drm/drm_connector.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 26bb78c76481..2e7430283043 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -250,10 +250,10 @@ int drm_connector_init(struct drm_device *dev,
>   connector->debugfs_entry = NULL;
>  out_put_type_id:
>   if (ret)
> - ida_remove(connector_ida, connector->connector_type_id);
> + ida_simple_remove(connector_ida, connector->connector_type_id);
>  out_put_id:
>   if (ret)
> - ida_remove(&config->connector_ida, connector->index);
> + ida_simple_remove(&config->connector_ida, connector->index);
>  out_put:
>   if (ret)
>   drm_mode_object_unregister(dev, &connector->base);
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/2] ARM: davinci: initial infrastructure for LCDC

2016-10-05 Thread Karl Beldan

On Wed, Oct 05, 2016 at 03:05:30PM +0200, Bartosz Golaszewski wrote:
> After discussing the matter with Laurent Pinchart it turned out that
> using ti,tilcdc,panel was wrong and we should go with the new
> simple-vga-dac driver proposed by Maxime Ripard and currently being
> reviewed.
> 
> The da850-lcdk board on which I'm working has a THS8135 video DAC for
> which the new driver seems to be best suited and we'll be able to
> query the connected display for supported modes instead of hardcoding
> them in the dt as is needed for the panel driver.
> 

I meant to point to these new changes but then it slipped my mind, it is
clearly the way to go.

Regards, 
Karl


> In the meantime I'm posting two patches based on Karl Beldan's
> previous work that can already be merged.
> 
> The first one adds OF_DEV_AUXDATA entry to da8xx-dt.c. I changed the
> compatible string to the new one we're introducing in the tilcdc
> driver.
> 
> The second adds the lcd pins and the display node to da850.dtsi. As
> suggested by Sekhar: I moved the pins node, which was previously in
> da850-lcdk.dts, to da850.dtsi. I also squashed Karl's two patches and
> removed the panel node.
> 
> Tested on a da850-lcdk with an LCD display connected over VGA with
> two patches already posted to the drm mailing list:
> 
>   drm: tilcdc: add a da850-specific compatible string
>   drm: tilcdc: add a workaround for failed clk_set_rate()
> 
> and some additional work-in-progress/hacks on top of that.
> 
> Karl Beldan (2):
>   ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc
>   ARM: dts: da850: add a node for the LCD controller
> 
>  arch/arm/boot/dts/da850.dtsi | 29 +
>  arch/arm/mach-davinci/da8xx-dt.c |  1 +
>  2 files changed, 30 insertions(+)
> 
> -- 
> 2.9.3
>

[PATCH 00/15] improve function-level documentation

2016-10-05 Thread Daniel Vetter

Jani Nikula has a patch with a scrip to make the one kernel-doc parser
into a lint/checker pass over the entire kernel. I think that'd would
be more robust instead of trying to approximate the real kerneldoc
parser. Otoh that parser is a horror show of a perl/regex driven state
machine ;-)

Jani, can you pls digg out these patches? Can't find them right now ...
-Daniel


On Sat, Oct 1, 2016 at 9:46 PM, Julia Lawall  wrote:
> These patches fix cases where the documentation above a function definition
> is not consistent with the function header.  Issues are detected using the
> semantic patch below (http://coccinelle.lip6.fr/).  Basically, the semantic
> patch parses a file to find comments, then matches each function header,
> and checks that the name and parameter list in the function header are
> compatible with the comment that preceeds it most closely.
>
> // 
> @initialize:ocaml@
> @@
>
> let tbl = ref []
> let fnstart = ref []
> let success = Hashtbl.create 101
> let thefile = ref ""
> let parsed = ref []
> let nea = ref []
>
> let parse file =
>   thefile := List.nth (Str.split (Str.regexp "linux-next/") file) 1;
>   let i = open_in file in
>   let startline = ref 0 in
>   let fn = ref "" in
>   let ids = ref [] in
>   let rec inside n =
> let l = input_line i in
> let n = n + 1 in
> match Str.split_delim (Str.regexp_string "*/") l with
>   before::after::_ ->
> (if not (!fn = "")
> then tbl := (!startline,n,!fn,List.rev !ids)::!tbl);
> startline := 0;
> fn := "";
> ids := [];
> outside n
> | _ ->
> (match Str.split (Str.regexp "[ \t]+") l with
>   "*"::name::rest ->
> let len = String.length name in
> (if !fn = "" && len > 2 && String.sub name (len-2) 2 = "()"
> then fn := String.sub name 0 (len-2)
> else if !fn = "" && (not (rest = [])) && List.hd rest = "-"
> then
>   if String.get name (len-1) = ':'
>   then fn := String.sub name 0 (len-1)
>   else fn := name
> else if not(!fn = "") && len > 2 &&
>   String.get name 0 = '@' && String.get name (len-1) = ':'
> then ids := (String.sub name 1 (len-2)) :: !ids);
> | _ -> ());
> inside n
>   and outside n =
> let l = input_line i in
> let n = n + 1 in
> if String.length l > 2 && String.sub l 0 3 = "/**"
> then
>   begin
> startline := n;
> inside n
>   end
> else outside n in
>   try outside 0 with End_of_file -> ()
>
> let hashadd tbl k v =
>   let cell =
> try Hashtbl.find tbl k
> with Not_found ->
>   let cell = ref [] in
>   Hashtbl.add tbl k cell;
>   cell in
>   cell := v :: !cell
>
> @script:ocaml@
> @@
>
> tbl := [];
> fnstart := [];
> Hashtbl.clear success;
> parsed := [];
> nea := [];
> parse (List.hd (Coccilib.files()))
>
> @r@
> identifier f;
> position p;
> @@
>
> f at p(...) { ... }
>
> @script:ocaml@
> p << r.p;
> f << r.f;
> @@
>
> parsed := f :: !parsed;
> fnstart := (List.hd p).line :: !fnstart
>
> @param@
> identifier f;
> type T;
> identifier i;
> parameter list[n] ps;
> parameter list[n1] ps1;
> position p;
> @@
>
> f at p(ps,T i,ps1) { ... }
>
> @script:ocaml@
> @@
>
> tbl := List.rev (List.sort compare !tbl)
>
> @script:ocaml@
> p << param.p;
> f << param.f;
> @@
>
> let myline = (List.hd p).line in
> let prevline =
>   List.fold_left
> (fun prev x ->
>   if x < myline
>   then max x prev
>   else prev)
> 0 !fnstart in
> let _ =
>   List.exists
> (function (st,fn,nm,ids) ->
>   if prevline < st && myline > st && prevline < fn && myline > fn
>   then
> begin
>   (if not (String.lowercase f = String.lowercase nm)
>   then
> Printf.printf "%s:%d %s doesn't match preceding comment: %s\n"
>   !thefile myline f nm);
>   true
> end
>   else false)
> !tbl in
> ()
>
> @script:ocaml@
> p << param.p;
> n << param.n;
> n1 << param.n1;
> i << param.i;
> f << param.f;
> @@
>
> let myline = (List.hd p).line in
> let prevline =
>   List.fold_left
> (fun prev x ->
>   if x < myline
>   then max x prev
>   else prev)
> 0 !fnstart in
> let _ =
>   List.exists
> (function (st,fn,nm,ids) ->
>   if prevline < st && myline > st && prevline < fn && myline > fn
>   then
> begin
>   (if List.mem i ids then hashadd success (st,fn,nm) i);
>   (if ids = [] (* arg list seems not obligatory *)
>   then ()
>   else if not (List.mem i ids)
>   then
> Printf.printf "%s:%d %s doesn't appear in ids: %s\n"
>   !thefile myline i (String.concat " " ids)
>   else if List.length ids <= n || List.length ids <= n1
>   then
> (if not (List.mem f !nea)
> then
>   begin
> nea := f :: !nea;
> Print

[PATCH 0/3] drm: Add panic handling

2016-10-05 Thread Daniel Vetter

Needs review from David Herrmann, pls keep him on cc for anything
related to panic handling.
-Daniel

On Sun, Oct 2, 2016 at 3:47 PM, Noralf TrÃ¸nnes  wrote:
> Ping.
>
>
> Den 11.09.2016 20:47, skrev Noralf TrÃ¸nnes:
>>
>> This patchset adds a way for DRM drivers to display kernel messages
>> during panic().
>>
>> This version have lots of changes based on Daniel's review of the RFC
>> where he proposed a different way of interacting with the driver.
>>
>> I have used this script to run some tests on the rendering code:
>> https://gist.github.com/notro/4f42ec20e1be1d47c98fa749ca53c805
>>
>>
>> Noralf.
>>
>>
>> Noralf TrÃ¸nnes (3):
>>drm: Add support for panic message output
>>drm/fb_cma_helper: Add panic handling
>>drm/simpledrm: Add panic handling
>>
>>   drivers/gpu/drm/Kconfig   |   1 +
>>   drivers/gpu/drm/Makefile  |   2 +-
>>   drivers/gpu/drm/drm_drv.c |   3 +
>>   drivers/gpu/drm/drm_fb_cma_helper.c   |  10 +
>>   drivers/gpu/drm/drm_framebuffer.c | 108 +
>>   drivers/gpu/drm/drm_internal.h|   4 +
>>   drivers/gpu/drm/drm_panic.c   | 640
>> ++
>>   drivers/gpu/drm/simpledrm/simpledrm_kms.c |  11 +
>>   include/drm/drm_framebuffer.h |  40 ++
>>   9 files changed, 818 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/gpu/drm/drm_panic.c
>>
>> --
>> 2.8.2
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

[PATCH v2] drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-10-05 Thread Daniel Vetter

On Wed, Oct 05, 2016 at 11:00:03AM +0200, Gustavo Padovan wrote:
> Hi Stefan,
> 
> 2016-10-04 Stefan Christ :
> 
> > The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> > implementations for functions in struct fb_ops. A drm driver can use it
> > like:
> > 
> > static struct fb_ops drm_fbdev_cma_ops = {
> > .owner  = THIS_MODULE,
> > DRM_FB_HELPER_DEFAULT_OPS,
> > /* driver specific implementations */
> > };
> > 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Stefan Christ 
> > ---
> > v2: Fix sphinx error:
> >  warning: Cannot understand  * @DRM_FB_HELPER_DEFAULT_OPS:
> > ---
> >  include/drm/drm_fb_helper.h | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index db8d478..f7d7126 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -214,6 +214,19 @@ struct drm_fb_helper {
> > bool delayed_hotplug;
> >  };
> >  
> > +/**
> > + * define DRM_FB_HELPER_DEFAULT_OPS - helper define for drm drivers
> 
> If I'm not mistaken v1 of this patch is already in drm-misc so you may
> want to send a patch that fix just the line above.

Yup, I need an incremental patch which applies on top of drm-misc or
linux-next. Sorry if this wasn't clear.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v3 3/3] drm/vgem: Keep a reference to the dmabuf when mmaped

2016-10-05 Thread Daniel Vetter

On Fri, Sep 30, 2016 at 02:59:59PM +0100, Chris Wilson wrote:
> In order to keep the dmabuf alive whilst the mmap is, we need to hold a
> reference to the dmabuf and not the backing object. This is important as
> the dmabuf not only keeps the object alive, but also the device so that
> 
>   dmabuf = vgem_create_dmabuf();
>   ptr = mmap(... dmabuf ...);
>   close(dmabuf);
> 
> persists across module-unload as well as device closure.

I don't see where we grab the ref to the dma-buf here instead of the
backing storage. And doesn't the exact same issue happen when you use dumb
mmap? Or maybe I'm just a bit confused about what's going on here ...
-Daniel

> 
> Testcase: igt/vgem_basic/unload
> Signed-off-by: Chris Wilson 
> Cc: Petri Latvala 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 17 +++--
>  1 file changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index f36c14729b55..74a83e41efa9 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -198,7 +198,6 @@ static struct drm_ioctl_desc vgem_ioctls[] = {
>  
>  static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
>  {
> - unsigned long flags = vma->vm_flags;
>   int ret;
>  
>   ret = drm_gem_mmap(filp, vma);
> @@ -208,7 +207,7 @@ static int vgem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>   /* Keep the WC mmaping set by drm_gem_mmap() but our pages
>* are ordinary and not special.
>*/
> - vma->vm_flags = flags | VM_DONTEXPAND | VM_DONTDUMP;
> + vma->vm_flags &= ~(VM_IO | VM_PFNMAP);
>   return 0;
>  }
>  
> @@ -281,21 +280,11 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>  {
>   int ret;
>  
> - if (obj->size < vma->vm_end - vma->vm_start)
> - return -EINVAL;
> -
> - if (!obj->filp)
> - return -ENODEV;
> -
> - ret = obj->filp->f_op->mmap(obj->filp, vma);
> + ret = drm_gem_mmap_obj(obj, obj->size, vma);
>   if (ret)
>   return ret;
>  
> - fput(vma->vm_file);
> - vma->vm_file = get_file(obj->filp);
> - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> - vma->vm_page_prot = 
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> -
> + vma->vm_flags &= ~(VM_IO | VM_PFNMAP);
>   return 0;
>  }
>  
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

2016-10-05 Thread Bartosz Golaszewski

From: Karl Beldan 

Add pins used by the LCD controller and a disabled LCDC node to be
reused in device trees including da850.dtsi.

Signed-off-by: Karl Beldan 
[Bartosz:
  - added the commit description
  - changed the dt node name to a generic one
  - added a da850-specific compatible string
  - removed the tilcdc,panel node
  - moved the pins definitions to da850.dtsi as suggested by
Sekhar Nori (was in: da850-lcdk.dts)]
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850.dtsi | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..32908ae 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -186,6 +186,27 @@
0xc 0x 0x
>;
};
+   lcd_pins: pinmux_lcd_pins {
+   pinctrl-single,bits = <
+   /*
+* LCD_D[2], LCD_D[3], LCD_D[4], 
LCD_D[5],
+* LCD_D[6], LCD_D[7]
+*/
+   0x40 0x2200 0xff00
+   /*
+* LCD_D[10], LCD_D[11], LCD_D[12], 
LCD_D[13],
+* LCD_D[14], LCD_D[15], LCD_D[0], 
LCD_D[1]
+*/
+   0x44 0x 0x
+   /* LCD_D[8], LCD_D[9] */
+   0x48 0x0022 0x00ff
+
+   /* LCD_PCLK */
+   0x48 0x0200 0x0f00
+   /* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC 
*/
+   0x4c 0x0222 0x0fff
+   >;
+   };

};
edma0: edma at 0 {
@@ -399,6 +420,14 @@
<&edma0 0 1>;
dma-names = "tx", "rx";
};
+
+   display: display at 213000 {
+   compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
+   reg = <0x213000 0x1000>;
+   interrupt-parent = <&intc>;
+   interrupts = <52>;
+   status = "disabled";
+   };
};
aemif: aemif at 6800 {
compatible = "ti,da850-aemif";
-- 
2.9.3

[PATCH 1/2] ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc

2016-10-05 Thread Bartosz Golaszewski

From: Karl Beldan 

This is required for tilcdc to be able to acquire a functional clock
on da850 SoCs.

Signed-off-by: Karl Beldan 
[Bartosz:
  - added the commit description
  - changed the compatible string to 'ti,da850-tilcdc']
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e92..697da3d 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -38,6 +38,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] 
__initdata = {
   NULL),
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d0, "davinci-mcasp.0", 
NULL),
OF_DEV_AUXDATA("ti,da850-aemif", 0x6800, "ti-aemif", NULL),
+   OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
{}
 };

-- 
2.9.3

[PATCH 0/2] ARM: davinci: initial infrastructure for LCDC

2016-10-05 Thread Bartosz Golaszewski

After discussing the matter with Laurent Pinchart it turned out that
using ti,tilcdc,panel was wrong and we should go with the new
simple-vga-dac driver proposed by Maxime Ripard and currently being
reviewed.

The da850-lcdk board on which I'm working has a THS8135 video DAC for
which the new driver seems to be best suited and we'll be able to
query the connected display for supported modes instead of hardcoding
them in the dt as is needed for the panel driver.

In the meantime I'm posting two patches based on Karl Beldan's
previous work that can already be merged.

The first one adds OF_DEV_AUXDATA entry to da8xx-dt.c. I changed the
compatible string to the new one we're introducing in the tilcdc
driver.

The second adds the lcd pins and the display node to da850.dtsi. As
suggested by Sekhar: I moved the pins node, which was previously in
da850-lcdk.dts, to da850.dtsi. I also squashed Karl's two patches and
removed the panel node.

Tested on a da850-lcdk with an LCD display connected over VGA with
two patches already posted to the drm mailing list:

  drm: tilcdc: add a da850-specific compatible string
  drm: tilcdc: add a workaround for failed clk_set_rate()

and some additional work-in-progress/hacks on top of that.

Karl Beldan (2):
  ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc
  ARM: dts: da850: add a node for the LCD controller

 arch/arm/boot/dts/da850.dtsi | 29 +
 arch/arm/mach-davinci/da8xx-dt.c |  1 +
 2 files changed, 30 insertions(+)

-- 
2.9.3

Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)

2016-10-05 Thread Daniel Vetter

On Wed, Oct 05, 2016 at 02:43:37PM +0200, Gerd Hoffmann wrote:
> On Mi, 2016-10-05 at 12:30 +0200, Daniel Vetter wrote:
> > On Wed, Oct 05, 2016 at 08:34:57AM +0200, Gerd Hoffmann wrote:
> > > On Di, 2016-10-04 at 09:43 +0200, Gerd Hoffmann wrote:
> > > >   Hi,
> > > > 
> > > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > > b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > > index a59d0e309bfc..1fcf739bf509 100644
> > > > > --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > > +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > > @@ -68,6 +68,10 @@ int drm_virtio_init(struct drm_driver *driver,
> > > > > struct virtio_device *vdev)
> > > > > dev->pdev = pdev;
> > > > > if (vga)
> > > > > virtio_pci_kick_out_firmware_fb(pdev);
> > > > > +
> > > > > +   ret = drm_dev_set_unique(dev, dev_name(dev->pdev));
> > > > > +   if (ret)
> > > > > +   goto err_free;
> > > > > }
> > > > 
> > > > Approach looks sensible to me, I'll give it a try ...
> > > 
> > > Well, dev_name() returns a string without the "pci:" prefix, we have to
> > > add that to make things actually work, like this:
> > 
> > Hm right, I missed that in digging through the piles of layers of struct
> > device naming.
> > 
> > > 
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > @@ -60,13 +60,22 @@ int drm_virtio_init(struct drm_driver *driver,
> > > struct virtio_device *vdev)
> > >  
> > > if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
> > > struct pci_dev *pdev = to_pci_dev(vdev->dev.parent);
> > > +   const char *pname = dev_name(&pdev->dev);
> > > bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
> > > +   char unique[20];
> > 
> > Iirc we kfree this on unload. Needs to be a kasprintf I think.
> 
> drm_dev_set_unique() does this:
> 
> dev->unique = kstrdup(name, GFP_KERNEL);
> 
> So it should not matter at all where the caller stores name.
> Or do you mean something else?

Oh, missed that. r-b stands as-is.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 5/5] drm/fsl-dcu: only init fbdev if required

2016-10-05 Thread Stefan Agner

There is no need to request a CMA backed framebuffer if fbdev
emulation is not enabled.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 07969f5..86dd4e3 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -87,7 +87,8 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned long 
flags)
goto done;
dev->irq_enabled = true;

-   fsl_dcu_fbdev_init(dev);
+   if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION))
+   fsl_dcu_fbdev_init(dev);

return 0;
 done:
-- 
2.10.0

[PATCH v2 4/5] drm/fsl-dcu: enable pixel clock when enabling CRTC

2016-10-05 Thread Stefan Agner

The pixel clock should not be on if the CRTC is not in use, hence
move clock enable/disable calls into CRTC callbacks.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |  2 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 21 +
 2 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 5ad1d68..b2d5e18 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -51,6 +51,7 @@ static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
   DCU_MODE_DCU_MODE(DCU_MODE_OFF));
regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
 DCU_UPDATE_MODE_READREG);
+   clk_disable_unprepare(fsl_dev->pix_clk);
 }

 static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
@@ -58,6 +59,7 @@ static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;

+   clk_prepare_enable(fsl_dev->pix_clk);
regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
   DCU_MODE_DCU_MODE_MASK,
   DCU_MODE_DCU_MODE(DCU_MODE_NORMAL));
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 68db834..07969f5 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -267,12 +267,6 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
return ret;
}

-   ret = clk_prepare_enable(fsl_dev->pix_clk);
-   if (ret < 0) {
-   dev_err(dev, "failed to enable pix clk\n");
-   goto disable_dcu_clk;
-   }
-
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
@@ -285,10 +279,6 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
enable_irq(fsl_dev->irq);

return 0;
-
-disable_dcu_clk:
-   clk_disable_unprepare(fsl_dev->clk);
-   return ret;
 }
 #endif

@@ -402,18 +392,12 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
goto disable_clk;
}

-   ret = clk_prepare_enable(fsl_dev->pix_clk);
-   if (ret < 0) {
-   dev_err(dev, "failed to enable pix clk\n");
-   goto unregister_pix_clk;
-   }
-
fsl_dev->tcon = fsl_tcon_init(dev);

drm = drm_dev_alloc(driver, dev);
if (IS_ERR(drm)) {
ret = PTR_ERR(drm);
-   goto disable_pix_clk;
+   goto unregister_pix_clk;
}

fsl_dev->dev = dev;
@@ -434,8 +418,6 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)

 unref:
drm_dev_unref(drm);
-disable_pix_clk:
-   clk_disable_unprepare(fsl_dev->pix_clk);
 unregister_pix_clk:
clk_unregister(fsl_dev->pix_clk);
 disable_clk:
@@ -448,7 +430,6 @@ static int fsl_dcu_drm_remove(struct platform_device *pdev)
struct fsl_dcu_drm_device *fsl_dev = platform_get_drvdata(pdev);

clk_disable_unprepare(fsl_dev->clk);
-   clk_disable_unprepare(fsl_dev->pix_clk);
clk_unregister(fsl_dev->pix_clk);
drm_put_dev(fsl_dev->drm);

-- 
2.10.0

[PATCH v2 3/5] drm/fsl-dcu: do not transfer registers in mode_set_nofb

2016-10-05 Thread Stefan Agner

Do not schedule a transfer of mode settings early. Modes should
get applied on on CRTC enable where we also enable the pixel clock.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 3371635..5ad1d68 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -116,8 +116,6 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 DCU_THRESHOLD_LS_BF_VS(BF_VS_VAL) |
 DCU_THRESHOLD_OUT_BUF_HIGH(BUF_MAX_VAL) |
 DCU_THRESHOLD_OUT_BUF_LOW(BUF_MIN_VAL));
-   regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
-DCU_UPDATE_MODE_READREG);
return;
 }

-- 
2.10.0

[PATCH v2 3/5] drm/fsl-dcu: do not transfer register in mode_set_nofb

2016-10-05 Thread Stefan Agner

Do not schedule a transfer of mode settings early. Modes should
get applied on on CRTC enable where we also enable the pixel clock.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 3371635..5ad1d68 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -116,8 +116,6 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 DCU_THRESHOLD_LS_BF_VS(BF_VS_VAL) |
 DCU_THRESHOLD_OUT_BUF_HIGH(BUF_MAX_VAL) |
 DCU_THRESHOLD_OUT_BUF_LOW(BUF_MIN_VAL));
-   regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
-DCU_UPDATE_MODE_READREG);
return;
 }

-- 
2.10.0

[PATCH v2 2/5] drm/fsl-dcu: do not transfer registers on plane init

2016-10-05 Thread Stefan Agner

There is no need to explicitly initiate a register transfer and
turn off the DCU after initializing the plane registers. In fact,
this is harmful and leads to unnecessary flickers if the DCU has
been left on by the bootloader.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index a7e5486..9e6f7d8 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -211,11 +211,6 @@ void fsl_dcu_drm_init_planes(struct drm_device *dev)
for (j = 1; j <= fsl_dev->soc->layer_regs; j++)
regmap_write(fsl_dev->regmap, DCU_CTRLDESCLN(i, j), 0);
}
-   regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
-  DCU_MODE_DCU_MODE_MASK,
-  DCU_MODE_DCU_MODE(DCU_MODE_OFF));
-   regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
-DCU_UPDATE_MODE_READREG);
 }

 struct drm_plane *fsl_dcu_drm_primary_create_plane(struct drm_device *dev)
-- 
2.10.0

[PATCH v2 2/5] drm/fsl-dcu: do not explicitly transfer registers on plane init

2016-10-05 Thread Stefan Agner

There is no need to explicitly initiate a register transfer and
turn off the DCU after initializing the plane registers. In fact,
this is harmful and leads to unnecessary flickers if the DCU has
been left on by the bootloader.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index a7e5486..9e6f7d8 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -211,11 +211,6 @@ void fsl_dcu_drm_init_planes(struct drm_device *dev)
for (j = 1; j <= fsl_dev->soc->layer_regs; j++)
regmap_write(fsl_dev->regmap, DCU_CTRLDESCLN(i, j), 0);
}
-   regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
-  DCU_MODE_DCU_MODE_MASK,
-  DCU_MODE_DCU_MODE(DCU_MODE_OFF));
-   regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
-DCU_UPDATE_MODE_READREG);
 }

 struct drm_plane *fsl_dcu_drm_primary_create_plane(struct drm_device *dev)
-- 
2.10.0

[PATCH v2 1/5] drm/fsl-dcu: enable TCON bypass mode by default

2016-10-05 Thread Stefan Agner

Do not use encoder disable/enable callbacks to control bypass
mode as this seems to mess with the signals not liked by
displays. This also makes more sense since the encoder is
already defined to be parallel RGB/LVDS at creation time.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |  1 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 38 ---
 2 files changed, 5 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 0884c45..68db834 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -273,6 +273,7 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
goto disable_dcu_clk;
}

+   fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 26edcc8..ec88719 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -20,38 +20,6 @@
 #include "fsl_dcu_drm_drv.h"
 #include "fsl_tcon.h"

-static int
-fsl_dcu_drm_encoder_atomic_check(struct drm_encoder *encoder,
-struct drm_crtc_state *crtc_state,
-struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static void fsl_dcu_drm_encoder_disable(struct drm_encoder *encoder)
-{
-   struct drm_device *dev = encoder->dev;
-   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
-
-   if (fsl_dev->tcon)
-   fsl_tcon_bypass_disable(fsl_dev->tcon);
-}
-
-static void fsl_dcu_drm_encoder_enable(struct drm_encoder *encoder)
-{
-   struct drm_device *dev = encoder->dev;
-   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
-
-   if (fsl_dev->tcon)
-   fsl_tcon_bypass_enable(fsl_dev->tcon);
-}
-
-static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
-   .atomic_check = fsl_dcu_drm_encoder_atomic_check,
-   .disable = fsl_dcu_drm_encoder_disable,
-   .enable = fsl_dcu_drm_encoder_enable,
-};
-
 static void fsl_dcu_drm_encoder_destroy(struct drm_encoder *encoder)
 {
drm_encoder_cleanup(encoder);
@@ -68,13 +36,15 @@ int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device 
*fsl_dev,
int ret;

encoder->possible_crtcs = 1;
+
+   /* Use bypass mode for parallel RGB/LVDS encoder */
+   fsl_tcon_bypass_enable(fsl_dev->tcon);
+
ret = drm_encoder_init(fsl_dev->drm, encoder, &encoder_funcs,
   DRM_MODE_ENCODER_LVDS, NULL);
if (ret < 0)
return ret;

-   drm_encoder_helper_add(encoder, &encoder_helper_funcs);
-
return 0;
 }

-- 
2.10.0

[PATCH v2 0/5] drm/fsl-dcu: initialization fixes

2016-10-05 Thread Stefan Agner

Hi All,

This is an assortment of fixes which solve issues seen using an
external RGB converter and makes sure that pixel clock is only
on when really required.

Meng, would be good if you can test it on a LS1021a.

--
Stefan

Changes since v1:
- add patch to no not transfer registers in mode_set_nofb
- add patch which only init fbdev if required
- remove disable unprepare pixel clock on module remove (already disabled
  in CRTC disable callback).
- remove unused label

Stefan Agner (5):
  drm/fsl-dcu: enable TCON bypass mode by default
  drm/fsl-dcu: do not transfer registers on plane init
  drm/fsl-dcu: do not transfer registers in mode_set_nofb
  drm/fsl-dcu: enable pixel clock when enabling CRTC
  drm/fsl-dcu: only init fbdev if required

 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  |  4 +--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 25 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  5 
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c   | 38 +++--
 4 files changed, 10 insertions(+), 62 deletions(-)

-- 
2.10.0

Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)

2016-10-05 Thread Gerd Hoffmann

On Mi, 2016-10-05 at 12:30 +0200, Daniel Vetter wrote:
> On Wed, Oct 05, 2016 at 08:34:57AM +0200, Gerd Hoffmann wrote:
> > On Di, 2016-10-04 at 09:43 +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > index a59d0e309bfc..1fcf739bf509 100644
> > > > --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > > @@ -68,6 +68,10 @@ int drm_virtio_init(struct drm_driver *driver,
> > > > struct virtio_device *vdev)
> > > > dev->pdev = pdev;
> > > > if (vga)
> > > > virtio_pci_kick_out_firmware_fb(pdev);
> > > > +
> > > > +   ret = drm_dev_set_unique(dev, dev_name(dev->pdev));
> > > > +   if (ret)
> > > > +   goto err_free;
> > > > }
> > > 
> > > Approach looks sensible to me, I'll give it a try ...
> > 
> > Well, dev_name() returns a string without the "pci:" prefix, we have to
> > add that to make things actually work, like this:
> 
> Hm right, I missed that in digging through the piles of layers of struct
> device naming.
> 
> > 
> > --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > @@ -60,13 +60,22 @@ int drm_virtio_init(struct drm_driver *driver,
> > struct virtio_device *vdev)
> >  
> > if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
> > struct pci_dev *pdev = to_pci_dev(vdev->dev.parent);
> > +   const char *pname = dev_name(&pdev->dev);
> > bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
> > +   char unique[20];
> 
> Iirc we kfree this on unload. Needs to be a kasprintf I think.

drm_dev_set_unique() does this:

dev->unique = kstrdup(name, GFP_KERNEL);

So it should not matter at all where the caller stores name.
Or do you mean something else?

cheers,
  Gerd

[Intel-gfx] [PATCH v3 3/3] drm/vgem: Keep a reference to the dmabuf when mmaped

2016-10-05 Thread Chris Wilson

On Wed, Oct 05, 2016 at 03:11:00PM +0200, Daniel Vetter wrote:
> On Fri, Sep 30, 2016 at 02:59:59PM +0100, Chris Wilson wrote:
> > In order to keep the dmabuf alive whilst the mmap is, we need to hold a
> > reference to the dmabuf and not the backing object. This is important as
> > the dmabuf not only keeps the object alive, but also the device so that
> > 
> > dmabuf = vgem_create_dmabuf();
> > ptr = mmap(... dmabuf ...);
> > close(dmabuf);
> > 
> > persists across module-unload as well as device closure.
> 
> I don't see where we grab the ref to the dma-buf here instead of the
> backing storage. And doesn't the exact same issue happen when you use dumb
> mmap? Or maybe I'm just a bit confused about what's going on here ...

The reference to the dmabuf is in vma->vm_file, which was used to keep
the module alive. So this might be overzealous, in that there shouldn't
be a way to get back from the shmemfs object to the module. However,
that does make me aware of a failure path we have in patches that do add
callbacks from shmemfs to the driver...

At least using the ptr after closing the module is ok. So this patch is
not required.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 98037] HD6450 KMS failure

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #127027|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/da17792b/attachment.html>

[PATCH v4 3/3] drm/vgem: Keep a reference to the dmabuf when mmaped

2016-10-05 Thread Chris Wilson

In order to keep the dmabuf alive whilst the mmap is, we need to hold a
reference to the dmabuf and not the backing object. This is important as
the dmabuf not only keeps the object alive, but also the device so that

dmabuf = vgem_create_dmabuf();
ptr = mmap(... dmabuf ...);
close(dmabuf);

persists across module-unload as well as device closure.

Testcase: igt/vgem_basic/unload
Signed-off-by: Chris Wilson 
Cc: Petri Latvala 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index f36c14729b55..74a83e41efa9 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -198,7 +198,6 @@ static struct drm_ioctl_desc vgem_ioctls[] = {

 static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
 {
-   unsigned long flags = vma->vm_flags;
int ret;

ret = drm_gem_mmap(filp, vma);
@@ -208,7 +207,7 @@ static int vgem_mmap(struct file *filp, struct 
vm_area_struct *vma)
/* Keep the WC mmaping set by drm_gem_mmap() but our pages
 * are ordinary and not special.
 */
-   vma->vm_flags = flags | VM_DONTEXPAND | VM_DONTDUMP;
+   vma->vm_flags &= ~(VM_IO | VM_PFNMAP);
return 0;
 }

@@ -281,21 +280,11 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
 {
int ret;

-   if (obj->size < vma->vm_end - vma->vm_start)
-   return -EINVAL;
-
-   if (!obj->filp)
-   return -ENODEV;
-
-   ret = obj->filp->f_op->mmap(obj->filp, vma);
+   ret = drm_gem_mmap_obj(obj, obj->size, vma);
if (ret)
return ret;

-   fput(vma->vm_file);
-   vma->vm_file = get_file(obj->filp);
-   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
-   vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
-
+   vma->vm_flags &= ~(VM_IO | VM_PFNMAP);
return 0;
 }

-- 
2.9.3

[PATCH v4 2/3] drm/prime: Take a ref on the drm_dev when exporting a dma_buf

2016-10-05 Thread Chris Wilson

dma_buf may live a long time, longer than the last direct user of the
driver. We already hold a reference to the owner module (that prevents
the object code from disappearing), but there is no reference to the
drm_dev - so the pointers to the driver backend themselves may vanish.

v2: Resist temptation to fix the bug in armada_gem.c not setting the
correct flags on the exported dma-buf (it should pass the flags through
and not be arbitrarily setting O_RDWR).

Use a common wrapper for exporting the dmabuf and acquiring the
reference to the drm_device.

Testcase: igt/vgem_basic/unload
Suggested-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Cc: Petri Latvala 
Cc: Daniel Vetter 
Cc: stable at vger.kernel.org
Tested-by: Petri Latvala 
---
 drivers/gpu/drm/armada/armada_gem.c|  2 +-
 drivers/gpu/drm/drm_prime.c| 30 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  2 +-
 drivers/gpu/drm/tegra/gem.c|  2 +-
 drivers/gpu/drm/udl/udl_dmabuf.c   |  2 +-
 include/drm/drmP.h |  4 
 6 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index cb8f0347b934..a5e428d27d2f 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -547,7 +547,7 @@ armada_gem_prime_export(struct drm_device *dev, struct 
drm_gem_object *obj,
exp_info.flags = O_RDWR;
exp_info.priv = obj;

-   return dma_buf_export(&exp_info);
+   return drm_gem_dmabuf_export(dev, &exp_info);
 }

 struct drm_gem_object *
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 80907b34d857..875df8d719fb 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -284,18 +284,46 @@ static void drm_gem_unmap_dma_buf(struct 
dma_buf_attachment *attach,
 }

 /**
+ * drm_gem_dmabuf_export - dma_buf export implementation for GEM
+ * @dma_buf: buffer to be exported
+ *
+ * This wraps dma_buf_export() for use by generic GEM drivers that are using
+ * drm_gem_dmabuf_release(). In addition to calling dma_buf_export(), we take
+ * a reference to the drm_device which is released by drm_gem_dmabuf_release().
+ *
+ * Returns the new dmabuf.
+ */
+struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
+ struct dma_buf_export_info *exp_info)
+{
+   struct dma_buf *dma_buf;
+
+   dma_buf = dma_buf_export(exp_info);
+   if (!IS_ERR(dma_buf))
+   drm_dev_ref(dev);
+
+   return dma_buf;
+}
+EXPORT_SYMBOL(drm_gem_dmabuf_export);
+
+/**
  * drm_gem_dmabuf_release - dma_buf release implementation for GEM
  * @dma_buf: buffer to be released
  *
  * Generic release function for dma_bufs exported as PRIME buffers. GEM drivers
  * must use this in their dma_buf ops structure as the release callback.
+ * drm_gem_dmabuf_release() should be used in conjunction with
+ * drm_gem_dmabuf_export().
  */
 void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 {
struct drm_gem_object *obj = dma_buf->priv;
+   struct drm_device *dev = obj->dev;

/* drop the reference on the export fd holds */
drm_gem_object_unreference_unlocked(obj);
+
+   drm_dev_unref(dev);
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_release);

@@ -412,7 +440,7 @@ struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
if (dev->driver->gem_prime_res_obj)
exp_info.resv = dev->driver->gem_prime_res_obj(obj);

-   return dma_buf_export(&exp_info);
+   return drm_gem_dmabuf_export(dev, &exp_info);
 }
 EXPORT_SYMBOL(drm_gem_prime_export);

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 10265bb35604..97c9d68b45df 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -283,7 +283,7 @@ struct dma_buf *i915_gem_prime_export(struct drm_device 
*dev,
return ERR_PTR(ret);
}

-   dma_buf = dma_buf_export(&exp_info);
+   dma_buf = drm_gem_dmabuf_export(dev, &exp_info);
if (IS_ERR(dma_buf))
return dma_buf;

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index aa60d9909ea2..95e622e31931 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -613,7 +613,7 @@ struct dma_buf *tegra_gem_prime_export(struct drm_device 
*drm,
exp_info.flags = flags;
exp_info.priv = gem;

-   return dma_buf_export(&exp_info);
+   return drm_gem_dmabuf_export(drm, &exp_info);
 }

 struct drm_gem_object *tegra_gem_prime_import(struct drm_device *drm,
diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c b/drivers/gpu/drm/udl/udl_dmabuf.c
index e2243edd1ce3..ac90ffdb5912 100644
--- a/drivers/gpu/drm/udl/udl_dmabuf.c
+++ b/drivers/gpu/drm/udl/udl_dmabuf.c
@@ -209,7 +209,7 @@ struct dma_buf *udl_gem_prime_export(struct drm_device *dev,
exp_info.flags = flags;

[PATCH v4 1/3] drm/prime: Pass the right module owner through to dma_buf_export()

2016-10-05 Thread Chris Wilson

dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right
owner from the device->fops instead.

v2: Use C99 initializers to zero out unset elements of
dma_buf_export_info
v3: Extract the right module from dev->fops.

Testcase: igt/vgem_basic/unload
Reported-by: Petri Latvala 
Signed-off-by: Chris Wilson 
Cc: Petri Latvala 
Cc: Christian KÃ¶nig 
Cc: stable at vger.kernel.org
Tested-by: Petri Latvala 
---
 drivers/gpu/drm/drm_prime.c | 17 ++---
 include/drm/drmP.h  |  3 ++-
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 57201d68cf61..80907b34d857 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -397,14 +397,17 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
=  {
  * using the PRIME helpers.
  */
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
-struct drm_gem_object *obj, int flags)
+struct drm_gem_object *obj,
+int flags)
 {
-   DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
-
-   exp_info.ops = &drm_gem_prime_dmabuf_ops;
-   exp_info.size = obj->size;
-   exp_info.flags = flags;
-   exp_info.priv = obj;
+   struct dma_buf_export_info exp_info = {
+   .exp_name = KBUILD_MODNAME, /* white lie for debug */
+   .owner = dev->driver->fops->owner,
+   .ops = &drm_gem_prime_dmabuf_ops,
+   .size = obj->size,
+   .flags = flags,
+   .priv = obj,
+   };

if (dev->driver->gem_prime_res_obj)
exp_info.resv = dev->driver->gem_prime_res_obj(obj);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 0e99669159c1..81fcd553edf7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1012,7 +1012,8 @@ static inline int drm_debugfs_remove_files(const struct 
drm_info_list *files,
 #endif

 extern struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
-   struct drm_gem_object *obj, int flags);
+   struct drm_gem_object *obj,
+   int flags);
 extern int drm_gem_prime_handle_to_fd(struct drm_device *dev,
struct drm_file *file_priv, uint32_t handle, uint32_t flags,
int *prime_fd);
-- 
2.9.3

[Bug 98028] Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Nicolai HÃ¤hnle  ---
Thanks for the additional info. Running llc on those shaders under Valgrind
doesn't show anything either, but this may be a limitation of Valgrind in
connection with LLVM's internal allocator.

That this is exposed by the game's operator overrides is curious. If the
bisection result is solid, we can't put the blame on those overrides though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/7bc69f04/attachment.html>

[Bug 98037] HD6450 KMS failure

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Will Lewis  ---
Created attachment 127027
  --> https://bugs.freedesktop.org/attachment.cgi?id=127027&action=edit
Xorg log

X started successfully, with output only to the attached DVI connector.  xrandr
--output HDMI-0 --mode 1920x1080 failed to light up the TV through the HDMI
connector.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/55a74e17/attachment.html>

[Bug 98002] Mud rendering bug in Portal 2

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

Nicolai HÃ¤hnle  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core
 QA Contact|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org

--- Comment #5 from Nicolai HÃ¤hnle  ---
I still don't know what causes the surfaces to be too bright. However, the
excessive brightness also appears with llvmpipe, so this bug doesn't seem
specific to radeonsi. Reassigning to Mesa core.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/02eedc67/attachment.html>

Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)

2016-10-05 Thread Daniel Vetter

On Wed, Oct 05, 2016 at 08:34:57AM +0200, Gerd Hoffmann wrote:
> On Di, 2016-10-04 at 09:43 +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > index a59d0e309bfc..1fcf739bf509 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > > @@ -68,6 +68,10 @@ int drm_virtio_init(struct drm_driver *driver,
> > > struct virtio_device *vdev)
> > > dev->pdev = pdev;
> > > if (vga)
> > > virtio_pci_kick_out_firmware_fb(pdev);
> > > +
> > > +   ret = drm_dev_set_unique(dev, dev_name(dev->pdev));
> > > +   if (ret)
> > > +   goto err_free;
> > > }
> > 
> > Approach looks sensible to me, I'll give it a try ...
> 
> Well, dev_name() returns a string without the "pci:" prefix, we have to
> add that to make things actually work, like this:

Hm right, I missed that in digging through the piles of layers of struct
device naming.

> 
> --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> @@ -60,13 +60,22 @@ int drm_virtio_init(struct drm_driver *driver,
> struct virtio_device *vdev)
>  
> if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
> struct pci_dev *pdev = to_pci_dev(vdev->dev.parent);
> +   const char *pname = dev_name(&pdev->dev);
> bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
> +   char unique[20];

Iirc we kfree this on unload. Needs to be a kasprintf I think.
>  
> -   DRM_INFO("pci: %s detected\n",
> -vga ? "virtio-vga" : "virtio-gpu-pci");
> +   DRM_INFO("pci: %s detected at %s\n",
> +vga ? "virtio-vga" : "virtio-gpu-pci",
> +pname);
> dev->pdev = pdev;
> if (vga)
> virtio_pci_kick_out_firmware_fb(pdev);
> +
> +   snprintf(unique, sizeof(unique), "pci:%s", pname);
> +   ret = drm_dev_set_unique(dev, unique);
> +   if (ret)
> +   goto err_free;
> +

I think once we can nuke the pci_setbusid stuff we might want a
drm_dev_pci_set_unique, which takes the struct pci_device and wraps the
above magic. But that can wait, we still have a few years on the uabi
clock for that.

Strictly speaking this is an issue for virtgpu too, but since virtgpu is
newer than the last broken libdrm release I think we'll be fine.

With the kasprintf change above:

Reviewed-by: Daniel Vetter 

> }
>  
> ret = drm_dev_register(dev, 0);
> 
> And a partial revert of commit a742946a1ba57e24e8be205ea87224c05b38c380
> to re-export drm_dev_set_unique().
> 
> Pushed to git://git.kraxel.org/linux drm-qemu
> 
> cheers,
>   Gerd
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 6/6] drm/i915/gen9: Add ddb changes to atomic debug output

2016-10-05 Thread Lyude

Finally, add some debugging output for ddb changes in the atomic debug
output. This makes it a lot easier to spot bugs from incorrect ddb
allocations.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 57 +
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7708646..2691428 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4030,6 +4030,61 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
   sizeof(dst->ddb.plane[pipe]));
 }

+static void
+skl_print_wm_changes(const struct drm_atomic_state *state)
+{
+   const struct drm_device *dev = state->dev;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct intel_atomic_state *intel_state =
+   to_intel_atomic_state(state);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   const struct drm_plane *plane;
+   const struct intel_plane *intel_plane;
+   const struct drm_plane_state *pstate;
+   const struct skl_ddb_allocation *old_ddb = &dev_priv->wm.skl_hw.ddb;
+   const struct skl_ddb_allocation *new_ddb = &intel_state->wm_results.ddb;
+   enum pipe pipe;
+   int id;
+   int i, j;
+
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   if (!crtc->state)
+   continue;
+
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   for_each_plane_in_state(state, plane, pstate, j) {
+   const struct skl_ddb_entry *old, *new;
+
+   intel_plane = to_intel_plane(plane);
+   id = skl_wm_plane_id(intel_plane);
+   old = &old_ddb->plane[pipe][id];
+   new = &new_ddb->plane[pipe][id];
+
+   if (intel_plane->pipe != pipe)
+   continue;
+
+   if (skl_ddb_entry_equal(old, new))
+   continue;
+
+   if (id != PLANE_CURSOR) {
+   DRM_DEBUG_ATOMIC("[PLANE:%d:plane %d%c] ddb (%d 
- %d) -> (%d - %d)\n",
+plane->base.id, id + 1,
+pipe_name(pipe),
+old->start, old->end,
+new->start, new->end);
+   } else {
+   DRM_DEBUG_ATOMIC("[PLANE:%d:cursor %c] ddb (%d 
- %d) -> (%d - %d)\n",
+plane->base.id,
+pipe_name(pipe),
+old->start, old->end,
+new->start, new->end);
+   }
+   }
+   }
+}
+
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
@@ -4091,6 +4146,8 @@ skl_compute_wm(struct drm_atomic_state *state)
intel_cstate->update_wm_pre = true;
}

+   skl_print_wm_changes(state);
+
return 0;
 }

-- 
2.7.4

[PATCH 5/6] drm/i915/gen9: Get rid of redundant watermark values

2016-10-05 Thread Lyude

Now that we've make skl_wm_levels make a little more sense, we can
remove all of the redundant wm information. Up until now we'd been
storing two copies of all of the skl watermarks: one being the
skl_pipe_wm structs, the other being the global wm struct in
drm_i915_private containing the raw register values. This is confusing
and problematic, since it means we're prone to accidentally letting the
two copies go out of sync. So, get rid of all of the functions
responsible for computing the register values and just use a single
helper, skl_write_wm_level(), to convert and write the new watermarks on
the fly.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 -
 drivers/gpu/drm/i915/intel_display.c |  14 ++-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 203 ---
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
 5 files changed, 88 insertions(+), 145 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f97d43..63519ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1643,8 +1643,6 @@ struct skl_ddb_allocation {
 struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
-   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
-   uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
 };

 struct skl_wm_level {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dd15ae2..c580d3d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3378,6 +3378,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
const struct skl_wm_values *wm = &dev_priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   &crtc_state->wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
@@ -3414,7 +3416,7 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_y = src_y;

if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc->base))
-   skl_write_plane_wm(intel_crtc, wm, 0);
+   skl_write_plane_wm(intel_crtc, p_wm, &wm->ddb, 0);

I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
@@ -3448,6 +3450,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+   const struct skl_plane_wm *p_wm = &cstate->wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;

/*
@@ -3455,7 +3459,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
 * plane's visiblity isn't actually changing neither is its watermarks.
 */
if (!crtc->primary->state->visible)
-   skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
+   skl_write_plane_wm(intel_crtc, p_wm,
+  &dev_priv->wm.skl_results.ddb, 0);

I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
@@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
const struct skl_wm_values *wm = &dev_priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   &cstate->wm.skl.optimal.planes[PLANE_CURSOR];
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;

if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & drm_crtc_mask(crtc))
-   skl_write_cursor_wm(intel_crtc, wm);
+   skl_write_cursor_wm(intel_crtc, p_wm, &wm->ddb);

if (plane_state && plane_state->base.visible) {
cntl = MCURSOR_GAMMA_ENABLE;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d684f4f..958dc72 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1765,9 +1765,11 @@ bool skl_ddb_allocation_equals(const struct 
skl_ddb_allocation *old,
 bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
 struct intel_crtc *intel_crtc);
 void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
-const struc

[PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

2016-10-05 Thread Lyude

Having skl_wm_level contain all of the watermarks for each plane is
annoying since it prevents us from having any sort of object to
represent a single watermark level, something we take advantage of in
the next commit to cut down on all of the copy paste code in here.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |   6 +-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 208 +--
 3 files changed, 100 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d26e5999..0f97d43 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1648,9 +1648,9 @@ struct skl_wm_values {
 };

 struct skl_wm_level {
-   bool plane_en[I915_MAX_PLANES];
-   uint16_t plane_res_b[I915_MAX_PLANES];
-   uint8_t plane_res_l[I915_MAX_PLANES];
+   bool plane_en;
+   uint16_t plane_res_b;
+   uint8_t plane_res_l;
 };

 /*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 35ba282..d684f4f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -468,9 +468,13 @@ struct intel_pipe_wm {
bool sprites_scaled;
 };

-struct skl_pipe_wm {
+struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+};
+
+struct skl_pipe_wm {
+   struct skl_plane_wm planes[I915_MAX_PLANES];
uint32_t linetime;
 };

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index af96888..250f12d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3668,67 +3668,52 @@ static int
 skl_compute_wm_level(const struct drm_i915_private *dev_priv,
 struct skl_ddb_allocation *ddb,
 struct intel_crtc_state *cstate,
+struct intel_plane *intel_plane,
 int level,
 struct skl_wm_level *result)
 {
struct drm_atomic_state *state = cstate->base.state;
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
-   struct drm_plane *plane;
-   struct intel_plane *intel_plane;
-   struct intel_plane_state *intel_pstate;
+   struct drm_plane *plane = &intel_plane->base;
+   struct intel_plane_state *intel_pstate = NULL;
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int ret;
+   int i = skl_wm_plane_id(intel_plane);
+
+   if (state)
+   intel_pstate =
+   intel_atomic_get_existing_plane_state(state,
+ intel_plane);

/*
-* We'll only calculate watermarks for planes that are actually
-* enabled, so make sure all other planes are set as disabled.
+* Note: If we start supporting multiple pending atomic commits against
+* the same planes/CRTC's in the future, plane->state will no longer be
+* the correct pre-state to use for the calculations here and we'll
+* need to change where we get the 'unchanged' plane data from.
+*
+* For now this is fine because we only allow one queued commit against
+* a CRTC.  Even if the plane isn't modified by this transaction and we
+* don't have a plane lock, we still have the CRTC's lock, so we know
+* that no other transactions are racing with us to update it.
 */
-   memset(result, 0, sizeof(*result));
-
-   for_each_intel_plane_mask(&dev_priv->drm,
- intel_plane,
- cstate->base.plane_mask) {
-   int i = skl_wm_plane_id(intel_plane);
-
-   plane = &intel_plane->base;
-   intel_pstate = NULL;
-   if (state)
-   intel_pstate =
-   intel_atomic_get_existing_plane_state(state,
- 
intel_plane);
+   if (!intel_pstate)
+   intel_pstate = to_intel_plane_state(plane->state);

-   /*
-* Note: If we start supporting multiple pending atomic commits
-* against the same planes/CRTC's in the future, plane->state
-* will no longer be the correct pre-state to use for the
-* calculations here and we'll need to change where we get the
-* 'unchanged' plane data from.
-*
-* For now this is fine because we only allow one queued commit
-* against a CRTC.  Even if the plane isn't modified by this
-* transaction and we don't have a plane lock, we still have
-* the CRTC's lock, so we know that no other transactions are
-* racing with us to update it

[PATCH 3/6] drm/i915: Add enable_sagv option

2016-10-05 Thread Lyude

This option allows us to manually control the SAGV at module load time.
This can be useful in situations such as trying to debug watermark
changes, since enabled SAGV + incorrect watermarks = total GPU
annihilation.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_params.c   |  5 +
 drivers/gpu/drm/i915/i915_params.h   |  1 +
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..f462cd4 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -62,6 +62,7 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = false,
.enable_gvt = false,
+   .enable_sagv = -1,
 };

 module_param_named(modeset, i915.modeset, int, 0400);
@@ -233,3 +234,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host 
support(default:false)");
+
+module_param_named_unsafe(enable_sagv, i915.enable_sagv, int, 0400);
+MODULE_PARM_DESC(enable_sagv,
+   "Enable the SAGV (gen9+ only)(1=enabled, 0=disabled, -1=driver 
discretion [default])");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 3a0dd78..a7db125 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -65,6 +65,7 @@ struct i915_params {
bool enable_dp_mst;
bool enable_dpcd_backlight;
bool enable_gvt;
+   int enable_sagv;
 };

 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a71d05a..dd15ae2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -16904,12 +16904,22 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
pll->on = false;
}

-   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
+   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
vlv_wm_get_hw_state(dev);
-   else if (IS_GEN9(dev))
+   } else if (IS_GEN9(dev)) {
skl_wm_get_hw_state(dev);
-   else if (HAS_PCH_SPLIT(dev))
+
+   if (i915.enable_sagv != -1) {
+   if (i915.enable_sagv)
+   intel_enable_sagv(dev_priv);
+   else
+   intel_disable_sagv(dev_priv);
+
+   dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
+   }
+   } else if (HAS_PCH_SPLIT(dev)) {
ilk_wm_get_hw_state(dev);
+   }

for_each_intel_crtc(dev, crtc) {
unsigned long put_domains;
-- 
2.7.4

[PATCH 2/6] drm/i915/skl: Remove linetime from skl_wm_values

2016-10-05 Thread Lyude

Next part of cleaning up the watermark code for skl. This is easy, since
it seems that we never actually needed to keep track of the linetime in
the skl_wm_values struct anyway.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 -
 drivers/gpu/drm/i915/intel_display.c | 6 --
 drivers/gpu/drm/i915/intel_pm.c  | 7 +--
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 85e541c..d26e5999 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1643,7 +1643,6 @@ struct skl_ddb_allocation {
 struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
-   uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
 };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 17733af..a71d05a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14832,6 +14832,8 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *intel_cstate =
+   to_intel_crtc_state(crtc->state);
struct intel_crtc_state *old_intel_state =
to_intel_crtc_state(old_crtc_state);
bool modeset = needs_modeset(crtc->state);
@@ -14848,13 +14850,13 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
intel_color_load_luts(crtc->state);
}

-   if (to_intel_crtc_state(crtc->state)->update_pipe)
+   if (intel_cstate->update_pipe)
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_GEN(dev_priv) >= 9) {
skl_detach_scalers(intel_crtc);

I915_WRITE(PIPE_WM_LINETIME(pipe),
-  dev_priv->wm.skl_hw.wm_linetime[pipe]);
+  intel_cstate->wm.skl.optimal.linetime);
}
 }

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0383516..af96888 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3839,8 +3839,6 @@ static void skl_compute_wm_results(struct drm_device *dev,
temp |= PLANE_WM_EN;

r->plane_trans[pipe][PLANE_CURSOR] = temp;
-
-   r->wm_linetime[pipe] = p_wm->linetime;
 }

 static void skl_ddb_entry_write(struct drm_i915_private *dev_priv,
@@ -4069,7 +4067,6 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
 struct skl_wm_values *src,
 enum pipe pipe)
 {
-   dst->wm_linetime[pipe] = src->wm_linetime[pipe];
memcpy(dst->plane[pipe], src->plane[pipe],
   sizeof(dst->plane[pipe]));
memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
@@ -4320,8 +4317,6 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)

max_level = ilk_wm_max_level(dev);

-   hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
-
for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++)
hw->plane[pipe][i][level] =
@@ -4338,7 +4333,7 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)

hw->dirty_pipes |= drm_crtc_mask(crtc);

-   active->linetime = hw->wm_linetime[pipe];
+   active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));

for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++) {
-- 
2.7.4

[PATCH 1/6] drm/i915/skl: Move per-pipe ddb allocations into crtc states

2016-10-05 Thread Lyude

First part of cleaning up all of the skl watermark code. This moves the
structures for storing the ddb allocations of each pipe into
intel_crtc_state, along with moving the structures for storing the
current ddb allocations active on hardware into intel_crtc.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_display.c | 16 ---
 drivers/gpu/drm/i915/intel_drv.h |  8 +---
 drivers/gpu/drm/i915/intel_pm.c  | 40 +++-
 4 files changed, 30 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8c66ee..85e541c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1636,7 +1636,6 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 }

 struct skl_ddb_allocation {
-   struct skl_ddb_entry pipe[I915_MAX_PIPES];
struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a366656..17733af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14235,12 +14235,11 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 unsigned int *crtc_vblank_mask)
 {
struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_crtc *crtc;
+   struct intel_crtc *intel_crtc;
struct drm_crtc_state *old_crtc_state;
-   struct skl_ddb_allocation *new_ddb = &intel_state->wm_results.ddb;
-   struct skl_ddb_allocation *cur_ddb = &dev_priv->wm.skl_hw.ddb;
+   struct intel_crtc_state *cstate;
unsigned int updated = 0;
bool progress;
enum pipe pipe;
@@ -14258,12 +14257,14 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
bool vbl_wait = false;
unsigned int cmask = drm_crtc_mask(crtc);
-   pipe = to_intel_crtc(crtc)->pipe;
+
+   intel_crtc = to_intel_crtc(crtc);
+   cstate = to_intel_crtc_state(crtc->state);
+   pipe = intel_crtc->pipe;

if (updated & cmask || !crtc->state->active)
continue;
-   if (skl_ddb_allocation_overlaps(state, cur_ddb, new_ddb,
-   pipe))
+   if (skl_ddb_allocation_overlaps(state, intel_crtc))
continue;

updated |= cmask;
@@ -14274,7 +14275,8 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 * then we need to wait for a vblank to pass for the
 * new ddb allocation to take effect.
 */
-   if (!skl_ddb_allocation_equals(cur_ddb, new_ddb, pipe) 
&&
+   if (!skl_ddb_entry_equal(&cstate->wm.skl.ddb,
+&intel_crtc->hw_ddb) &&
!crtc->state->active_changed &&
intel_state->wm_results.dirty_pipes != updated)
vbl_wait = true;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f48e79a..35ba282 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -496,6 +496,7 @@ struct intel_crtc_wm_state {
struct {
/* gen9+ only needs 1-step wm programming */
struct skl_pipe_wm optimal;
+   struct skl_ddb_entry ddb;

/* cached plane data rate */
unsigned plane_data_rate[I915_MAX_PLANES];
@@ -733,6 +734,9 @@ struct intel_crtc {
bool cxsr_allowed;
} wm;

+   /* gen9+: ddb allocation currently being used */
+   struct skl_ddb_entry hw_ddb;
+
int scanline_offset;

struct {
@@ -1755,9 +1759,7 @@ bool skl_ddb_allocation_equals(const struct 
skl_ddb_allocation *old,
   const struct skl_ddb_allocation *new,
   enum pipe pipe);
 bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
-const struct skl_ddb_allocation *old,
-const struct skl_ddb_allocation *new,
-enum pipe pipe);
+struct intel_crtc *intel_crtc);
 void

[PATCH 0/6] Start of skl watermark cleanup

2016-10-05 Thread Lyude

While it (mostly) works, the code for handling watermarks on Skylake has been
kind of ugly for a while. As well a lot of it isn't that friendly to atomic
transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
full cleanup, it's a good start. As well, we add a couple of features for
making debugging watermarks a little easier.

Cc: Maarten Lankhorst 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Matt Roper 

Lyude (6):
  drm/i915/skl: Move per-pipe ddb allocations into crtc states
  drm/i915/skl: Remove linetime from skl_wm_values
  drm/i915: Add enable_sagv option
  drm/i915/gen9: Make skl_wm_level per-plane
  drm/i915/gen9: Get rid of redundant watermark values
  drm/i915/gen9: Add ddb changes to atomic debug output

 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/i915_params.c   |   5 +
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/intel_display.c |  52 +++--
 drivers/gpu/drm/i915/intel_drv.h |  20 +-
 drivers/gpu/drm/i915/intel_pm.c  | 437 ---
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
 7 files changed, 260 insertions(+), 273 deletions(-)

-- 
2.7.4

[PULL] topic/drm-misc

2016-10-05 Thread Daniel Vetter

Hi Dave,

Another attempt, this time rebased and without the pipe crc patches:
- display_info cleanups from Ville
- make prime/gem lookups faster with rbtrees (Chris)
- misc stuff all over

Cheers, Daniel


The following changes since commit c2cbc38b9715bd8318062e600668fc30e5a3fbfa:

  drm: virtio: reinstate drm_virtio_set_busid() (2016-10-04 13:10:30 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-10-05

for you to fetch changes up to 0546d685f07cc4fc5748fd36e57d167877c2842d:

  drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it 
(2016-10-04 08:23:17 +0200)


Baoyou Xie (3):
  drm/rockchip: add missing header dependencies
  drm/rockchip: mark symbols static where possible
  drm/mediatek: mark symbols static where possible

Chris Wilson (1):
  drm: Convert prime dma-buf <-> handle to rbtree

Daniel Vetter (1):
  drm: Document caveats around atomic event handling

Emilio LÃ³pez (1):
  uapi: add missing install of sync_file.h

Joe Perches (1):
  drm: Simplify drm_printk to reduce object size quite a bit

Stefan Christ (1):
  drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops

Tomeu Vizoso (2):
  drm/bridge: analogix_dp: Add analogix_dp_psr_supported
  drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support 
it

Ville SyrjÃ¤lÃ¤ (10):
  drm/edid: Clear old audio latency values before parsing the new EDID
  drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID
  drm/edid: Make max_tmds_clock kHz instead of MHz
  drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info
  drm/edid: Don't pass around drm_display_info needlessly
  drm/edid: Reduce the number of times we parse the CEA extension block
  drm/edid: Clear the old cea_rev when there's no CEA extension in the new 
EDID
  drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()
  drm/i915: Replace a bunch of connector->base.display_info with a local 
variable
  drm/i915: Account for sink max TMDS clock when checking the port clock

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |   4 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |   8 +
 drivers/gpu/drm/drm_drv.c  |   5 +-
 drivers/gpu/drm/drm_edid.c | 248 +++--
 drivers/gpu/drm/drm_irq.c  |  32 ++-
 drivers/gpu/drm/drm_prime.c|  85 ++-
 drivers/gpu/drm/i915/intel_display.c   |  14 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |   9 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  11 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |   1 +
 include/drm/bridge/analogix_dp.h   |   1 +
 include/drm/drmP.h |  35 ++-
 include/drm/drm_connector.h|  15 +-
 include/drm/drm_crtc.h |  56 +++--
 include/drm/drm_fb_helper.h|  13 ++
 include/uapi/linux/Kbuild  |   1 +
 19 files changed, 361 insertions(+), 188 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/6] R-Car DU fixes and cleanups

2016-10-05 Thread Gustavo Padovan

Hi Laurent,

2016-10-04 Laurent Pinchart :

> Hello,
> 
> This patch series contains five simple cleanups and fixes for the rcar-du-drm
> driver, as well as an argument constification patch for video/of.
> 
> The patches themselves are straightforward, see individual commit messages for
> details. Patch 2/6 (normally merged through the DRM tree) depends on patch 1/6
> (normally merged through the fbdev tree). As they don't conflict with patches
> 3/6 to 6/6, we can either merge the whole series through the DRM tree, or
> merge patches 1/6 and 2/6 through the fbdev tree and the rest through the DRM
> tree.
> 
> My preference would go for merging the whole series through the DRM tree to
> avoid potential conflicts with the other patches I'm working on for v4.10.
> There is no foreseen conflict at the moment, but I might rework encoder
> handling in the driver that could possibly result in a conflict. Dave, Tomi,
> any preference ? If you're fine with patches not going through your tree,
> could you please ack them ?
> 
> Cc: David Airlie 
> Cc: Tomi Valkeinen 
> 
> Laurent Pinchart (6):
>   video: of: Constify node argument to display timing functions
>   drm: rcar-du: Constify node argument to rcar_du_lvds_connector_init()
>   drm: rcar-du: Bring HDMI encoder comments in line with the driver
>   drm: rcar-du: Remove test for impossible error condition
>   drm: rcar-du: Remove memory allocation error message
>   drm: rcar-du: Fix crash in encoder failure error path
> 
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c |  6 --
>  drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c |  4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 +-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  4 +---
>  drivers/video/of_display_timing.c |  6 +++---
>  include/video/of_display_timing.h | 15 ---
>  8 files changed, 21 insertions(+), 28 deletions(-)

For 1 to 6

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH] drm/bridge: Call drm_connector_cleanup directly

2016-10-05 Thread Gustavo Padovan

Hi Marek,

2016-10-05 Marek Vasut :

> Remove the unnecessary wrapper functions around drm_connector_cleanup().
> 
> Signed-off-by: Marek Vasut 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 7 +--
>  drivers/gpu/drm/bridge/nxp-ptn3460.c  | 7 +--
>  drivers/gpu/drm/bridge/parade-ps8622.c| 7 +--
>  3 files changed, 3 insertions(+), 18 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH v2] drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-10-05 Thread Gustavo Padovan

Hi Stefan,

2016-10-04 Stefan Christ :

> The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> implementations for functions in struct fb_ops. A drm driver can use it
> like:
> 
> static struct fb_ops drm_fbdev_cma_ops = {
> .owner  = THIS_MODULE,
> DRM_FB_HELPER_DEFAULT_OPS,
> /* driver specific implementations */
> };
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Stefan Christ 
> ---
> v2: Fix sphinx error:
>  warning: Cannot understand  * @DRM_FB_HELPER_DEFAULT_OPS:
> ---
>  include/drm/drm_fb_helper.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index db8d478..f7d7126 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -214,6 +214,19 @@ struct drm_fb_helper {
>   bool delayed_hotplug;
>  };
>  
> +/**
> + * define DRM_FB_HELPER_DEFAULT_OPS - helper define for drm drivers

If I'm not mistaken v1 of this patch is already in drm-misc so you may
want to send a patch that fix just the line above.

Gustavo

Unix Device Memory Allocation project

2016-10-05 Thread Benjamin Gaignard

Hi,

Do you already have in mind a list of targeted driver/backend/plugin ?
How do you expect to enumerate devices capabilities ? by adding a new
generic ioctl or a configuration file in userland ?

Maybe it is to early for those questions but anyway I'm interested by
this memory allocation thread.

Regards,
Benjamin

2016-10-05 1:47 GMT+02:00 James Jones :
> Hello everyone,
>
> As many are aware, we took up the issue of surface/memory allocation at XDC
> this year.  The outcome of that discussion was the beginnings of a design
> proposal for a library that would server as a cross-device, cross-process
> surface allocator.  In the past week I've started to condense some of my
> notes from that discussion down to code & a design document.  I've posted
> the first pieces to a github repository here:
>
>   https://github.com/cubanismo/allocator
>
> This isn't anything close to usable code yet.  Just headers and docs, and
> incomplete ones at that.  However, feel free to check it out if you're
> interested in discussing the design.
>
> Thanks,
> -James
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org â Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Bug 173041] Nouveau random hangs in g84_gr_tlb_flush (NVIDIA GT240)

2016-10-05 Thread bugzilla-dae...@bugzilla.kernel.org

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

madicine6 at gmail.com changed:

   What|Removed |Added

 CC||madicine6 at gmail.com

--- Comment #1 from madicine6 at gmail.com ---
before 4.8 I had lockups, they were not random though. if I would not run any
graphic intense things, like games, it worked alright. after upgrade to 4.8
luckups are constant and totally random.
GPU: GeForce GTS 450

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

[Intel-gfx] [PATCH 05/11] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait

2016-10-05 Thread Sinclair Yeh

Hi,

I'm preparing a fixes pull request, and I'll include this one if it
hasn't been applied by others already.

Sinclair


On Wed, Oct 05, 2016 at 09:41:22PM +0530, Sumit Semwal wrote:
> Hi Thomas, Sinclair,
> 
> On 23 September 2016 at 18:26, Daniel Vetter  wrote:
> > On Mon, Aug 29, 2016 at 08:08:28AM +0100, Chris Wilson wrote:
> >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> >> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> >> need to handle such conversion in the caller. The only challenge are
> >> those callers that wish to differentiate the error code between the
> >> nonblocking busy check and potentially blocking wait.
> >>
> >> Signed-off-by: Chris Wilson 
> >> Cc: Sinclair Yeh 
> >> Cc: Thomas Hellstrom 
> >> Reviewed-by: Sinclair Yeh 
> >
> > Reviewed-by: Daniel Vetter 
> >
> Could you please let me know if this patch is already queued up at
> your end, or should I just take it via drm-misc with Sinclair's r-b?
> 
> Thanks and Best,
> Sumit.

[Bug 98002] Mud rendering bug in Portal 2

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from Nicolai HÃ¤hnle  ---
Those black objects could well be bug 96512. We may have to revisit it somehow.

Meanwhile, the first incorrect rendering of the issue here happens @514365 with
program 3332, vertex shader source @79150, fragment shader @79234. There's no
shadow sampling involved, so it must be a different bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/37ab4f8b/attachment.html>

Voltage Settings Not Applied with AMDGPU Driver

2016-10-05 Thread Kristy-Leigh Minehan

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

To summarize:

When writing to /sys/class/drm/card0/pp_table, clocks are applied
correctly, the TDP/TDC/Max Power Delivery Limit is applied, but voltages
are not.

If they've modified in the VBIOS, they are applied.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/b4a98f5c/attachment.html>

[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Andy Furniss  ---
(In reply to Ernst SjÃ¶strand from comment #6)
> Do you think I can get both false positives and false negatives?
> Have tested a bit more but still behaving in a silly way...

I guess your issue not as clear cut as mine then.

If you find that you can sometimes boot and sometimes not on the same kernel
after power off, then that's going to be quite a pain and time consuming to
find.

It's not really normal to have to power off - I haven't needed to for ages,
just that with my recent boot up issue I knew I did need to as when I first
built it it worked from a reboot, but not the next day from off. I though your
issue may be similar, but apparently not.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/43f8e64d/attachment.html>

[PATCH V2] OMAPDSS: Kconfig: Add HDMI for OMAP4 and OMAP5 dependencies

2016-10-05 Thread Tomi Valkeinen

On 05/10/16 05:07, Adam Ford wrote:
> Make "HDMI for OMAP4" and "HDMI for OMAP5" depend on ARCH_OMAP4
> and SOC_OMAP5/DRA7XX respectively.
> 
> Signed-off-by: Adam Ford 
> 
> Changes in v2: Add dependancy for DRA7XX or OMAP5

You don't say it, but I presume this is just to make those kconfig
options disappear automatically if you don't have the specific ARCH_*
enabled?

I don't like these, as they will just clutter the Kconfig file. Here you
only added a few dependencies, but there are a lot more. VENC is only
there for some SoC versions, SDI is there only for some, same for
RFBI... And with every new SoC type we'd need to update all these.

Just disable the HDMI from the Kconfig if you don't want it included.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/a6778ae2/attachment.sig>

Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)

2016-10-05 Thread Gerd Hoffmann

On Di, 2016-10-04 at 09:43 +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > index a59d0e309bfc..1fcf739bf509 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> > @@ -68,6 +68,10 @@ int drm_virtio_init(struct drm_driver *driver,
> > struct virtio_device *vdev)
> > dev->pdev = pdev;
> > if (vga)
> > virtio_pci_kick_out_firmware_fb(pdev);
> > +
> > +   ret = drm_dev_set_unique(dev, dev_name(dev->pdev));
> > +   if (ret)
> > +   goto err_free;
> > }
> 
> Approach looks sensible to me, I'll give it a try ...

Well, dev_name() returns a string without the "pci:" prefix, we have to
add that to make things actually work, like this:

--- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
@@ -60,13 +60,22 @@ int drm_virtio_init(struct drm_driver *driver,
struct virtio_device *vdev)

if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
struct pci_dev *pdev = to_pci_dev(vdev->dev.parent);
+   const char *pname = dev_name(&pdev->dev);
bool vga = (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
+   char unique[20];

-   DRM_INFO("pci: %s detected\n",
-vga ? "virtio-vga" : "virtio-gpu-pci");
+   DRM_INFO("pci: %s detected at %s\n",
+vga ? "virtio-vga" : "virtio-gpu-pci",
+pname);
dev->pdev = pdev;
if (vga)
virtio_pci_kick_out_firmware_fb(pdev);
+
+   snprintf(unique, sizeof(unique), "pci:%s", pname);
+   ret = drm_dev_set_unique(dev, unique);
+   if (ret)
+   goto err_free;
+
}

ret = drm_dev_register(dev, 0);

And a partial revert of commit a742946a1ba57e24e8be205ea87224c05b38c380
to re-export drm_dev_set_unique().

Pushed to git://git.kraxel.org/linux drm-qemu

cheers,
  Gerd

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #9 from iuno at posteo.net ---
I have the same problem with my Hawaii card and my WQHD 144 Hz monitor. It is
not X related and the effect is visible on the framebuffer console, too.

120 Hz setting does flicker like seen in comment 7.
144 Hz setting has a flickering vertical bar a few pixels wide on the left
side, a vertical bar in the center of the screen and overall blurred image.

The OSD of the monitor shows that the input is 2568 pixels wide, has a 214 KHz
horizontal and 139 Hz vertical refresh rate. When using with Intel GPU (which
works correctly) it shows 2560 px, 222 KHz and 144 Hz.

Tried both radeon (linux 4.7.6) and amdgpu (linux 4.8)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/1bb14d1d/attachment.html>

Unix Device Memory Allocation project

2016-10-05 Thread Rob Clark

This would be a purely userspace interface (in that user just
interacts w/ a userspace shared lib, the driver specific backend may
do it's own ioctls to query whatever is needed from the hw)..

So might be something like, for each device in the sharing use-case, call:

  allocator_dev_t allocator_load(int fd);

where loader figures out what backend to dlopen() based on the fd.
There could probably be, for example, a generic liballocator-v4l.so
that works for all v4l devices.  And for gl drivers, this would be a
gbm sorta thing.  For some APIs which don't expose a device fd, we
might need some sort of extension within that API.  (For example
OpenMAX..  but maybe if we wait long enough that problem just goes
away.)

a bit handwavey at the moment..

BR,
-R

On Wed, Oct 5, 2016 at 4:42 AM, Benjamin Gaignard
 wrote:
> Hi,
>
> Do you already have in mind a list of targeted driver/backend/plugin ?
> How do you expect to enumerate devices capabilities ? by adding a new
> generic ioctl or a configuration file in userland ?
>
> Maybe it is to early for those questions but anyway I'm interested by
> this memory allocation thread.
>
> Regards,
> Benjamin
>
> 2016-10-05 1:47 GMT+02:00 James Jones :
>> Hello everyone,
>>
>> As many are aware, we took up the issue of surface/memory allocation at XDC
>> this year.  The outcome of that discussion was the beginnings of a design
>> proposal for a library that would server as a cross-device, cross-process
>> surface allocator.  In the past week I've started to condense some of my
>> notes from that discussion down to code & a design document.  I've posted
>> the first pieces to a github repository here:
>>
>>   https://github.com/cubanismo/allocator
>>
>> This isn't anything close to usable code yet.  Just headers and docs, and
>> incomplete ones at that.  However, feel free to check it out if you're
>> interested in discussing the design.
>>
>> Thanks,
>> -James
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Study Group
>
> Linaro.org â Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98021] Applications and games crash after opengl version overrides

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

Christian KÃ¶nig  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/f670f573/attachment.html>

[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Ernst SjÃ¶strand  ---
Do you think I can get both false positives and false negatives?
Have tested a bit more but still behaving in a silly way...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/5aa201ee/attachment-0001.html>

[Bug 98021] Applications and games crash after opengl version overrides

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Stepan Bakshaev  ---
I got it. linux 4.8 is enough for enable 4.3 in stock. Sorry for bother you. I
check time by time https://www.x.org/wiki/RadeonFeature/. it does not mention
about all requirements for opengl 4.3. There is only llmv 3.8 as requirements.
I saw Alex Deucher updates that wiki page. May be he will add next time linux
4.8 in footnotes.

Thank you and whole team for pushing radeon driver forward!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/c0301532/attachment.html>

[Bug 98002] Mud rendering bug in Portal 2

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Michel DÃ¤nzer  ---
(In reply to ClÃ©ment GuÃ©rin from comment #2)
> Nice. I also noticed that the heroe's hands a completely black during the
> final boss scene. Should I open a separate issue?

Sounds like bug 96512.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/761ce3e3/attachment.html>

[Bug 97980] [amdgpu] New kernel warning during shutdown

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

pankaj  changed:

   What|Removed |Added

   Keywords||have-backtrace
   Hardware|Other   |IA64 (Itanium)
   Priority|medium  |lowest
   Severity|normal  |blocker
 OS|All |NetBSD
URL||https://bugs.freedesktop.or
   ||g

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/688a6838/attachment.html>

[Bug 98002] Mud rendering bug in Portal 2

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from ClÃ©ment GuÃ©rin  ---
Nice. I also noticed that the heroe's hands a completely black during the final
boss scene. Should I open a separate issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/1c6b4544/attachment.html>

[Bug 97969] [radeonsi, bisected: fb827c0] Video decoding shows green artifacts

2016-10-05 Thread bugzilla-dae...@freedesktop.org

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Alexandre Demers  ---
(In reply to Nicolai HÃ¤hnle from comment #8)
> Now that I actually got to test this on radeon rather than just amdgpu, the
> problem was pretty obvious. It's fixed for me with
> https://patchwork.freedesktop.org/patch/113573/. I apologize for the
> inconvenience.

Tested and it seems fixed over here. Closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161005/04852056/attachment-0001.html>

[PATCH] drm/bridge: Call drm_connector_cleanup directly

2016-10-05 Thread Marek Vasut

Remove the unnecessary wrapper functions around drm_connector_cleanup().

Signed-off-by: Marek Vasut 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/bridge/analogix-anx78xx.c | 7 +--
 drivers/gpu/drm/bridge/nxp-ptn3460.c  | 7 +--
 drivers/gpu/drm/bridge/parade-ps8622.c| 7 +--
 3 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index f9f03bc..a2a8236 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1001,16 +1001,11 @@ static enum drm_connector_status anx78xx_detect(struct 
drm_connector *connector,
return connector_status_connected;
 }

-static void anx78xx_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_cleanup(connector);
-}
-
 static const struct drm_connector_funcs anx78xx_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = anx78xx_detect,
-   .destroy = anx78xx_connector_destroy,
+   .destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 93f3dac..f1a9993 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -245,16 +245,11 @@ static enum drm_connector_status ptn3460_detect(struct 
drm_connector *connector,
return connector_status_connected;
 }

-static void ptn3460_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_cleanup(connector);
-}
-
 static const struct drm_connector_funcs ptn3460_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
-   .destroy = ptn3460_connector_destroy,
+   .destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c 
b/drivers/gpu/drm/bridge/parade-ps8622.c
index f1b39a2..6f7c2f9 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -483,16 +483,11 @@ static enum drm_connector_status ps8622_detect(struct 
drm_connector *connector,
return connector_status_connected;
 }

-static void ps8622_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_cleanup(connector);
-}
-
 static const struct drm_connector_funcs ps8622_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
-   .destroy = ps8622_connector_destroy,
+   .destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-- 
2.9.3

92 matches

Mail list logo