[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Rob Clark]

On Fri, Nov 4, 2016 at 9:23 PM, Eric Engestrom  wrote:
> On Friday, 2016-11-04 13:50:25 -0400, Rob Clark wrote:
>> On Fri, Nov 4, 2016 at 1:32 PM, Eric Engestrom
>>  wrote:
>> > On Friday, 2016-11-04 13:12:51 -0400, Rob Clark wrote:
>> >> On Fri, Nov 4, 2016 at 12:27 PM, Ville Syrjälä
>> >>  wrote:
>> >> > On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark wrote:
>> >> >> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>> >> >>
>> >> >> drm: make drm_get_format_name thread-safe
>> >> >>
>> >> >> Signed-off-by: Eric Engestrom 
>> >> >> [danvet: Clarify that the returned pointer must be freed with
>> >> >> kfree().]
>> >> >> Signed-off-by: Daniel Vetter 
>> >> >>
>> >> >> Note: I think we need to be a bit careful about follow-up audits of
>> >> >> callers of this..  now that you need to kfree the return value I think
>> >> >> it is fairly easy for new patches to introduce new callers which leak
>> >> >> the return value.  We probably should have left the function as-is and
>> >> >> introduce a new variant, or something like that.
>> >> >>
>> >> >> Signed-off-by: Rob Clark 
>> >> >> ---
>> >> >>  drivers/gpu/drm/drm_fourcc.c | 5 -
>> >> >>  1 file changed, 4 insertions(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/drm_fourcc.c 
>> >> >> b/drivers/gpu/drm/drm_fourcc.c
>> >> >> index cbb8b77..2be9ea8 100644
>> >> >> --- a/drivers/gpu/drm/drm_fourcc.c
>> >> >> +++ b/drivers/gpu/drm/drm_fourcc.c
>> >> >> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>> >> >>   */
>> >> >>  char *drm_get_format_name(uint32_t format)
>> >> >>  {
>> >> >> - char *buf = kmalloc(32, GFP_KERNEL);
>> >> >> + char *buf = kmalloc(32, GFP_ATOMIC);
>> >> >> +
>> >> >> + if (!buf)
>> >> >> + return NULL;
>> >
>> > Unrelated bug, thanks for that fix too :)
>> >
>> >> >>
>> >> >>   snprintf(buf, 32,
>> >> >>"%c%c%c%c %s-endian (0x%08x)",
>> >> >
>> >> > Why aren't we using kasprintf()?
>> >
>> > Because I didn't know it was a thing :(
>> > Patch using it incoming.
>>
>> Thanks
>>
>> >> >
>> >> > Or we could have just made the caller provide the buffer...
>> >>
>> >> I guess kasprintf() would do the job (although still not address the
>> >> fact that we still always do the sprintf bits, rather than only doing
>> >> it when debug logs are enabled)..  caller provided buffer would be
>> >> better.  And make it more obvious that something needs to be fixed
>> >> when merging/rebasing patches that started life before this change
>> >> landed.
>> >>
>> >> I still kinda like the idea of making vsprintf know about fourcc's
>> >> with a new format string, and just making drm_get_format_name() go
>> >> away.
>> >>
>> >> But I don't really have time atm to re-work all the callers of
>> >> drm_get_format_name().  So I guess unless someone else does, I'd go w/
>> >> kasprintf() for now.
>> >
>> > That sounds cleaner to me indeed, I'll send a patch doing that tonight.
>> > Any idea for the name? drm_get_format_name_safe(uint32_t, char*)?
>> > I could also keep the same name and rely on the function signature
>> > change to make sure any merging of the old function call will break the
>> > compilation and be noticed that way.
>>
>> I think if fxn signature changes, we can keep the same name.  What I
>> get nervous about is fxn sig+name stays same but semantics change ;-)
>>
>> btw, if this isn't what you were already planning, I'd suggest:
>>
>>char *drm_get_format_name(uint32_t, char *);
>>
>> so we can keep it inline w/ DRM_DEBUG_xyz() macros.
>
> This was exactly my idea.
>
>> Or maybe something like:
>>
>>typedef char drm_format_name_buf[MAX_SIZE]
>>char *drm_get_format_name(uint32_t, drm_format_name_buf);
>>
>> ??
>
> I didn't think of that, but that would avoid mistakes about the size of
> the buffer. Modifying the code now, I'll send the patch in a few minutes.

I guess it would be worth a double check if gcc could catch the error
if someone passes in a too-small buffer, but assuming it does, I think
this approach would be simpler/safer than the "make it look like
snprintf()" approach.. but if compiler doesn't catch it, maybe it is
better to go w/ Ville's approach.

/me hoping at least a modern gcc is clever enough..

BR,
-R


> Cheers,
>   Eric

[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi

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

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

--- Comment #7 from Marek Olšák  ---
The pinned_memory mapping gets complicated if 2 memory ranges don't intersect
but the pages they touch do intersect.

-- 
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/20161104/e61fb438/attachment.html>

[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi

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

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

--- Comment #6 from Marek Olšák  ---
I think we should just drop draw calls with a 0-sized index buffer.

For GL_AMD_pinned_memory, I think we can just map whole pages that intersect
the mapped range.

-- 
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/20161104/e146f5c3/attachment.html>

[Bug 98351] LibreOffice' OpenGL backend hangs GPU (ring 0&3 stalled)

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

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

--- Comment #2 from Clemens Eisserer  ---
I've just tried to reproduce - and the issue seems to be gone with kernel 4.8.4
:)

Thanks :)

-- 
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/20161104/d1b3957c/attachment.html>

redraw issues on i915 since 4.9-rc

[Norbert Preining]

Dear all,

since 4.9-rc series started I see heavy redraw problems on i915. Starting
or resizing for example the digikam window messes up completely the content.

I have seen this at least since rc2 (I often wait till rc2), and 
confirm that 4.8.0 does not exhibit these problems.

A screenshot of the redraw problems is attached.

hardware:
i915 :00:02.0: fb0: inteldrmfb frame buffer device

Xorg:
(II) Module modesetting: vendor="X.Org Foundation"
   compiled for 1.18.4, module version = 1.18.4
   Module class: X.Org Video Driver
   ABI class: X.Org Video Driver, version 20.0

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated 
Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Sony Corporation Haswell-ULT Integrated Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 40
Memory at df40 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at 1000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915

sofware:
Debian/sid uptodate


Thanks a lot

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13
-- next part --
A non-text attachment was scrubbed...
Name: digikam-screenshot.jpg
Type: image/jpeg
Size: 271932 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161104/3caf2533/attachment-0001.jpg>

[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi

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

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

--- Comment #5 from Nicolai Hähnle  ---
Okay, so I could reproduce this after all with the web demo.

There is a bug in X-Plane and also questionable behaviour of the driver. The
bug in X-Plane is that it uses GL_AMD_pinned_memory with a size that is not a
multiple of a page; as per the spec, the driver is allowed to reject that, and
we do (apparently unlike the closed source driver...). X-Plane doesn't check
this error condition, and continues rendering, hence the crash, which would
also happen with a simple sequence of:

  glGenBuffers(1, );
  glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, bo);
  glDrawElements(...);

Somewhat surprisingly, the OpenGL spec never states that a draw call that goes
outside the element/index buffer should flag a GL_INVALID_OPERATION. There is
also no mention of this in the GL_ARB_robust_buffer_access_behavior extension,
which is surprising.

The patch you provide may or may not go in the right direction - I'm not sure.
If we want to check that, we should do it in api_validate.c, but I'm not
convinced that we should. Meanwhile, that check wouldn't properly fix the issue
in X-Plane. To work around the bug in X-Plane, you need to run with:

MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory ./X-Plane-x86_64 --force_run

which will work with an unmodified driver.

-- 
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/20161104/0a80319a/attachment-0001.html>

[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Ville Syrjälä]

On Fri, Nov 04, 2016 at 01:50:25PM -0400, Rob Clark wrote:
> On Fri, Nov 4, 2016 at 1:32 PM, Eric Engestrom
>  wrote:
> > On Friday, 2016-11-04 13:12:51 -0400, Rob Clark wrote:
> >> On Fri, Nov 4, 2016 at 12:27 PM, Ville Syrjälä
> >>  wrote:
> >> > On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark wrote:
> >> >> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >> >>
> >> >> drm: make drm_get_format_name thread-safe
> >> >>
> >> >> Signed-off-by: Eric Engestrom 
> >> >> [danvet: Clarify that the returned pointer must be freed with
> >> >> kfree().]
> >> >> Signed-off-by: Daniel Vetter 
> >> >>
> >> >> Note: I think we need to be a bit careful about follow-up audits of
> >> >> callers of this..  now that you need to kfree the return value I think
> >> >> it is fairly easy for new patches to introduce new callers which leak
> >> >> the return value.  We probably should have left the function as-is and
> >> >> introduce a new variant, or something like that.
> >> >>
> >> >> Signed-off-by: Rob Clark 
> >> >> ---
> >> >>  drivers/gpu/drm/drm_fourcc.c | 5 -
> >> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> >> index cbb8b77..2be9ea8 100644
> >> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> >> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
> >> >>   */
> >> >>  char *drm_get_format_name(uint32_t format)
> >> >>  {
> >> >> - char *buf = kmalloc(32, GFP_KERNEL);
> >> >> + char *buf = kmalloc(32, GFP_ATOMIC);
> >> >> +
> >> >> + if (!buf)
> >> >> + return NULL;
> >
> > Unrelated bug, thanks for that fix too :)
> >
> >> >>
> >> >>   snprintf(buf, 32,
> >> >>"%c%c%c%c %s-endian (0x%08x)",
> >> >
> >> > Why aren't we using kasprintf()?
> >
> > Because I didn't know it was a thing :(
> > Patch using it incoming.
> 
> Thanks
> 
> >> >
> >> > Or we could have just made the caller provide the buffer...
> >>
> >> I guess kasprintf() would do the job (although still not address the
> >> fact that we still always do the sprintf bits, rather than only doing
> >> it when debug logs are enabled)..  caller provided buffer would be
> >> better.  And make it more obvious that something needs to be fixed
> >> when merging/rebasing patches that started life before this change
> >> landed.
> >>
> >> I still kinda like the idea of making vsprintf know about fourcc's
> >> with a new format string, and just making drm_get_format_name() go
> >> away.
> >>
> >> But I don't really have time atm to re-work all the callers of
> >> drm_get_format_name().  So I guess unless someone else does, I'd go w/
> >> kasprintf() for now.
> >
> > That sounds cleaner to me indeed, I'll send a patch doing that tonight.
> > Any idea for the name? drm_get_format_name_safe(uint32_t, char*)?
> > I could also keep the same name and rely on the function signature
> > change to make sure any merging of the old function call will break the
> > compilation and be noticed that way.
> 
> I think if fxn signature changes, we can keep the same name.  What I
> get nervous about is fxn sig+name stays same but semantics change ;-)
> 
> btw, if this isn't what you were already planning, I'd suggest:
> 
>char *drm_get_format_name(uint32_t, char *);

I would model it after snprintf(): drm_get_format_name(buf,size,format)

Although I guess you could have it return the string instead of
int for extra ease of use.

But yeah, having the ability to register custom printf conversions would
be pretty nice.

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Ville Syrjälä]

On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> 
> drm: make drm_get_format_name thread-safe
> 
> Signed-off-by: Eric Engestrom 
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vetter 
> 
> Note: I think we need to be a bit careful about follow-up audits of
> callers of this..  now that you need to kfree the return value I think
> it is fairly easy for new patches to introduce new callers which leak
> the return value.  We probably should have left the function as-is and
> introduce a new variant, or something like that.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..2be9ea8 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>   */
>  char *drm_get_format_name(uint32_t format)
>  {
> - char *buf = kmalloc(32, GFP_KERNEL);
> + char *buf = kmalloc(32, GFP_ATOMIC);
> +
> + if (!buf)
> + return NULL;
>  
>   snprintf(buf, 32,
>"%c%c%c%c %s-endian (0x%08x)",

Why aren't we using kasprintf()?

Or we could have just made the caller provide the buffer...

> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[git pull] drm fixes for 4.9-rc4

[Theodore Ts'o]

On Fri, Nov 04, 2016 at 01:38:25PM -0700, Linus Torvalds wrote:
> On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie  wrote:
> >
> > There are a set of fixes for an oops we've been seeing around MST
> > display unplug,
> 
> Side note: I heard from a couple of people at the KS that said that
> they had had problems with suspend/resume after plugging in to a 4k
> display (but _only_ a 4k display - apparently normal FHD displays
> didn't show this). I think at least one was USB3/Thunderbolt. Ted with
> a Lenovo laptop (intel GPU) was one, I forget who else mentioned this.

Actually, it's after a unplugging from a Dell 30" monitor with a 3k
display (2560 x 1920).  This is after I've carefully deactivated the
video output to the Dell 30" monitor, unplugged the Dell 30" monitor
(at which point the system becomes non-responsive for 2-3 seconds for
reasons unknown), and only suspending after the system has recovered
from the unplug.

At that point, it's a 20-30% chance that the system will never come
back after a suspend.  So I have to make a point of saving all of my
editor buffers, etc., since I never can know whether my laptop will
come back.

This was happening for years and years on the T540p laptop, as well as
my new T460 laptop.  I've complained about this in the past, and
gotten no response, and I've just gotten used to the fact that if I'm
transitioning from home (where I have the 30" display) to work,
there's a good chance the resume will lock up, and I will be forced to
push the power button for 8 seconds to forcibly power down the laptop
to recover from the suspend.  :-(

I agree with Linus's suspicion that I probably need to bite the bullet
and just buy a new SST monitor, and that will probably make the
problem go away.  But if the bug can be fixed, that would be really
great.

Thanks,

- Ted

[PATCHv2 2/2] v4l: vsp1: Provide a writeback video device

[Kieran Bingham]

When the VSP1 is used in an active display pipeline, the output of the
WPF can supply the LIF entity directly and simultaneously write to
memory.

Support this functionality in the VSP1 driver, by extending the WPF
source pads, and establishing a V4L2 video device node connected to the
new source.

The source will be able to perform pixel format conversion, but not
rescaling, and as such the output from the memory node will always be
of the same dimensions as the display output.

Signed-off-by: Kieran Bingham 

---
Changes since RFC
 - Fix checkpatch.pl warnings
 - Adapt to use a single source pad for the Writeback and LIF
 - Use WPF properties to determine when to create links instead of VSP
 - Remove incorrect vsp1_video_verify_format() changes
 - Spelling and grammar fixes
---
 drivers/media/platform/vsp1/vsp1.h   |   1 +
 drivers/media/platform/vsp1/vsp1_drm.c   |  19 
 drivers/media/platform/vsp1/vsp1_drv.c   |   5 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   1 +
 drivers/media/platform/vsp1/vsp1_video.c | 150 ++-
 drivers/media/platform/vsp1/vsp1_video.h |   5 ++
 drivers/media/platform/vsp1/vsp1_wpf.c   |  19 +++-
 7 files changed, 193 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 85387a64179a..a2d462264312 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -54,6 +54,7 @@ struct vsp1_uds;
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
 #define VSP1_HAS_HGO   (1 << 7)
 #define VSP1_HAS_HGT   (1 << 8)
+#define VSP1_HAS_WPF_WRITEBACK (1 << 9)

 struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 0daf5f2c06e2..9bb7c1a04157 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -27,6 +27,7 @@
 #include "vsp1_lif.h"
 #include "vsp1_pipe.h"
 #include "vsp1_rwpf.h"
+#include "vsp1_video.h"


 /* 
-
@@ -479,6 +480,13 @@ void vsp1_du_atomic_flush(struct device *dev)
__func__, rpf->entity.index);
}

+   /*
+* If we have a writeback node attached, we use this opportunity to
+* update the video buffers.
+*/
+   if (pipe->output->video && pipe->output->video->frame_end)
+   pipe->output->video->frame_end(pipe);
+
/* Configure all entities in the pipeline. */
list_for_each_entry(entity, >entities, list_pipe) {
/* Disconnect unused RPFs from the pipeline. */
@@ -590,6 +598,16 @@ int vsp1_drm_create_links(struct vsp1_device *vsp1)
if (ret < 0)
return ret;

+   if (vsp1->wpf[0]->has_writeback) {
+   /* Connect the video device to the WPF for Writeback support */
+   ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
+   RWPF_PAD_SOURCE,
+   >wpf[0]->video->video.entity,
+   0, flags);
+   if (ret < 0)
+   return ret;
+   }
+
return 0;
 }

@@ -620,6 +638,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->bru = >bru->entity;
pipe->lif = >lif->entity;
pipe->output = vsp1->wpf[0];
+   pipe->output->pipe = pipe;

return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 3b084976094b..42fa822b38d3 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -408,7 +408,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
vsp1->wpf[i] = wpf;
list_add_tail(>entity.list_dev, >entities);

-   if (vsp1->info->uapi) {
+   if (vsp1->info->uapi || wpf->has_writeback) {
struct vsp1_video *video = vsp1_video_create(vsp1, wpf);

if (IS_ERR(video)) {
@@ -705,7 +705,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
.model = "VSP2-D",
.gen = 3,
-   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP,
+   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP
+ | VSP1_HAS_WPF_WRITEBACK,
.rpf_count = 5,
.wpf_count = 2,
.num_bru_inputs = 5,
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index b4ffc38f48af..7502b467294a 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -53,6 +53,7 @@ struct vsp1_rwpf {

u32 mult_alpha;
u32 outfmt;
+   

[PATCHv2 1/2] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"

[Kieran Bingham]

This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
the DU continuously")

The DU output mode does not rely on frames being supplied on the WPF as
its pipeline is supplied from DRM. For the upcoming WPF writeback
functionality, we will choose to enable writeback mode if there is an
output buffer, or disable it (leaving the existing display pipeline
unharmed) otherwise.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 94b428596c4f..f10401065cd3 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -296,11 +296,6 @@ static struct v4l2_rect vsp1_video_partition(struct 
vsp1_pipeline *pipe,
  * This function completes the current buffer by filling its sequence number,
  * time stamp and payload size, and hands it back to the videobuf core.
  *
- * When operating in DU output mode (deep pipeline to the DU through the LIF),
- * the VSP1 needs to constantly supply frames to the display. In that case, if
- * no other buffer is queued, reuse the one that has just been processed 
instead
- * of handing it back to the videobuf core.
- *
  * Return the next queued buffer or NULL if the queue is empty.
  */
 static struct vsp1_vb2_buffer *
@@ -322,12 +317,6 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
done = list_first_entry(>irqqueue,
struct vsp1_vb2_buffer, queue);

-   /* In DU output mode reuse the buffer if the list is singular. */
-   if (pipe->lif && list_is_singular(>irqqueue)) {
-   spin_unlock_irqrestore(>irqlock, flags);
-   return done;
-   }
-
list_del(>queue);

if (!list_empty(>irqqueue))
-- 
2.7.4

[PATCHv2 0/2] vsp1 writeback prototype

[Kieran Bingham]

Resending this patch series to bring in dri-devel, and interested parties.
Apologies for the resend to linux-media and linux-renesas-soc.

This short series extends the VSP1 on the RCar platforms to allow creating a
V4L2 video node on display pipelines where the hardware allows writing to
memory simultaneously.

In this instance, the hardware restricts the output to match the display size
(no rescaling) but does allow pixel format conversion.

A current limitation (that the DRI devs might have ideas about) is that the vb2
buffers are swapped on the atomic_flush() calls rather than on vsync events.

Ideally swapping buffers would occur on every vsync such that the output rate
of the video node would match the display rate, however the timing here proves
more difficult to synchronise the updates from a vysnc and flush without adding
latency to the flush.

Is there anything I can do to synchronise the v4l2 buffers with the DRM/KMS
interfaces currently? Or does anyone have any suggestions for extending as
such?

And of course ideas on anything that could be done generically to support other
targets as well would be worth considering - though currently this
implementation is very RCar/VSP1 specific.


Kieran Bingham (2):
  Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
  v4l: vsp1: Provide a writeback video device

 drivers/media/platform/vsp1/vsp1.h   |   1 +
 drivers/media/platform/vsp1/vsp1_drm.c   |  19 
 drivers/media/platform/vsp1/vsp1_drv.c   |   5 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   1 +
 drivers/media/platform/vsp1/vsp1_video.c | 161 ---
 drivers/media/platform/vsp1/vsp1_video.h |   5 +
 drivers/media/platform/vsp1/vsp1_wpf.c   |  19 +++-
 7 files changed, 193 insertions(+), 18 deletions(-)

-- 
2.7.4

redraw issues on i915 since 4.9-rc

[Chris Wilson]

On Sat, Nov 05, 2016 at 02:25:19AM +0900, Norbert Preining wrote:
> Hi Chris,
> 
> > https://cgit.freedesktop.org/drm-intel/
> 
> I pulled from there and rebuild my kernel. Rebooting and everything
> is fine. Looks much better!!!
> 
> > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e
> 
> Do you want me to test this patch only on top of master? (If it applies!!!)

It won't apply directly, but you could try testing that commit and its
parent to see if my hunch was correct.

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/3] drm/amdgpu: add the interface of waiting multiple fences (v3)

[Deucher, Alexander]

> -Original Message-
> From: Sumit Semwal [mailto:sumit.semwal at linaro.org]
> Sent: Friday, November 04, 2016 1:15 PM
> To: Alex Deucher
> Cc: amd-gfx at lists.freedesktop.org; DRI mailing list; Zhang, Jerry; Deucher,
> Alexander
> Subject: Re: [PATCH 2/3] drm/amdgpu: add the interface of waiting multiple
> fences (v3)
> 
> Hi Alex,
> 
> Thanks for the patch!
> 
> On 3 November 2016 at 11:41, Alex Deucher 
> wrote:
> > From: Junwei Zhang 
> >
> > v2: agd: rebase and squash in all the previous optimizations and
> > changes so everything compiles.
> > v3: squash in Slava's 32bit build fix
> >
> > Signed-off-by: Junwei Zhang 
> > Reviewed-by: Monk Liu 
> > Reviewed-by: Jammy Zhou 
> > Signed-off-by: Alex Deucher 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu.h |   2 +
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 171
> 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   1 +
> >  include/uapi/drm/amdgpu_drm.h   |  27 +
> >  4 files changed, 201 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 8d0c689..c2050c0 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> 
> > +
> > +   r = fence_wait_any_timeout(array, fence_count, true, timeout);
> 
> With the change proposed about returning index of signalled fence in
> patch 1/3, I don't think this would build?

Yes, Sorry, I messed up the order when I rebased the patches.  It should be 2 1 
3.

Alex

> 
> Best regards,
> Sumit.

[PATCH variant 1] drm: make drm_get_format_name atomic/irq safe again

[Eric Engestrom]

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

drm: make drm_get_format_name thread-safe

Signed-off-by: Eric Engestrom 
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter 

Note (Rob Clark):
I think we need to be a bit careful about follow-up audits of callers of
this..  now that you need to kfree the return value I think it is fairly
easy for new patches to introduce new callers which leak the return
value.  We probably should have left the function as-is and introduce
a new variant, or something like that.

Suggested-by: Rob Clark  (GFP_ATOMIC)
Suggested-by: Ville Syrjälä  (kasprintf)
Signed-off-by: Eric Engestrom 
---

I'll send another variant tonight that moves the allocation to the
callers (sounds cleaner to me, although there'll be some code
duplication and more opportunities to make mistakes I guess).

---
 drivers/gpu/drm/drm_fourcc.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 29c56b4..66dcf21 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -87,9 +87,7 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
  */
 char *drm_get_format_name(uint32_t format)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   return kasprintf(GFP_ATOMIC,
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -97,8 +95,6 @@ char *drm_get_format_name(uint32_t format)
 printable_char((format >> 24) & 0x7f),
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
-
-   return buf;
 }
 EXPORT_SYMBOL(drm_get_format_name);

-- 
Cheers,
  Eric

[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Eric Engestrom]

On Friday, 2016-11-04 13:12:51 -0400, Rob Clark wrote:
> On Fri, Nov 4, 2016 at 12:27 PM, Ville Syrjälä
>  wrote:
> > On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark wrote:
> >> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >>
> >> drm: make drm_get_format_name thread-safe
> >>
> >> Signed-off-by: Eric Engestrom 
> >> [danvet: Clarify that the returned pointer must be freed with
> >> kfree().]
> >> Signed-off-by: Daniel Vetter 
> >>
> >> Note: I think we need to be a bit careful about follow-up audits of
> >> callers of this..  now that you need to kfree the return value I think
> >> it is fairly easy for new patches to introduce new callers which leak
> >> the return value.  We probably should have left the function as-is and
> >> introduce a new variant, or something like that.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  drivers/gpu/drm/drm_fourcc.c | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index cbb8b77..2be9ea8 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
> >>   */
> >>  char *drm_get_format_name(uint32_t format)
> >>  {
> >> - char *buf = kmalloc(32, GFP_KERNEL);
> >> + char *buf = kmalloc(32, GFP_ATOMIC);
> >> +
> >> + if (!buf)
> >> + return NULL;

Unrelated bug, thanks for that fix too :)

> >>
> >>   snprintf(buf, 32,
> >>"%c%c%c%c %s-endian (0x%08x)",
> >
> > Why aren't we using kasprintf()?

Because I didn't know it was a thing :(
Patch using it incoming.

> >
> > Or we could have just made the caller provide the buffer...
> 
> I guess kasprintf() would do the job (although still not address the
> fact that we still always do the sprintf bits, rather than only doing
> it when debug logs are enabled)..  caller provided buffer would be
> better.  And make it more obvious that something needs to be fixed
> when merging/rebasing patches that started life before this change
> landed.
> 
> I still kinda like the idea of making vsprintf know about fourcc's
> with a new format string, and just making drm_get_format_name() go
> away.
> 
> But I don't really have time atm to re-work all the callers of
> drm_get_format_name().  So I guess unless someone else does, I'd go w/
> kasprintf() for now.

That sounds cleaner to me indeed, I'll send a patch doing that tonight.
Any idea for the name? drm_get_format_name_safe(uint32_t, char*)?
I could also keep the same name and rely on the function signature
change to make sure any merging of the old function call will break the
compilation and be noticed that way.

Looks like I'm obviously not qualified to choose which is the best
option, so I'll leave that to you guys :)

Cheers,
  Eric

[v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Daniel Kurtz]

On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
 wrote:
>
> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
> [...]
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> [...]
>>>
>>> +
>>> +/* Firmware */
>>> +#define PS_FW_NAME "ps864x_fw.bin"
>>> +
>>
>> From where I can download this firmware image?
>
> I suppose this FW bits have to be added to linux-firmware repository first, 
> before this patch can be accepted.

All PS8640 devices should already ship with working firmware.
The firmware update procedure is only used in the unlikely event where
one wants to update the bridge to a different firmware provided by
Parade.

Why must the lack of firmware really block landing this driver?

If this is really so, can we just land the functional part of the
driver first, and add the firmware update in a follow-up patch.

>
> Regards,
> Matthias

linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Liviu Dudau]

On Sat, Nov 05, 2016 at 03:55:03AM +1100, Stephen Rothwell wrote:
> Hi Liviu,
> 
> On Fri, 4 Nov 2016 15:48:02 + Liviu Dudau  wrote:
> >
> > Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> > alone should be good. Baoyou's patch is in my tree to stop him repeatedly
> > send me the same patch over and over again :) But yes, I will add my
> > Signed-off-by for that one.
> 
> Sorry, but this is not sufficient.  Please read section 11 of
> Documentation/SubmittingPatches (or
> Documentation/process/submitting-patches.rst where it has been moved
> recently).  If you are in the path of a patch to Linus, you must add a
> Signed-off-by line, and as the person who committed those patches to
> the tree, you are in the path.

Thanks for correcting me. I will add my Signed-off-bys to the relevant
patches.

Best regards,
Liviu

> -- 
> Cheers,
> Stephen Rothwell

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

On Thu, 3 Nov 2016 17:19:58 + Liviu Dudau  wrote:
>
> I have revamped the mali-dp tree and rebased it on the newer
> version of drm-next (which includes the drm-misc change) and pushed the
> updated patch in my tree.

Thanks for that.  However, several of the commits in your tree now have
no Signed-off-by from you as the committer :-(

-- 
Cheers,
Stephen Rothwell

[PATCH] drm/vc4: Use runtime autosuspend to avoid thrashing V3D power state.

[Eric Anholt]

The pm_runtime_put() we were using immediately released power on the
device, which meant that we were generally turning the device off and
on once per frame.  In many profiles I've looked at, that added up to
about 1% of CPU time, but this could get worse in the case of frequent
rendering and readback (as may happen in X rendering).  By keeping the
device on until we've been idle for a couple of frames, we drop the
overhead of runtime PM down to sub-.1%.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 9 ++---
 drivers/gpu/drm/vc4/vc4_gem.c | 6 --
 drivers/gpu/drm/vc4/vc4_v3d.c | 2 ++
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index b087404c2784..7abfe088f2d1 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -61,21 +61,24 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT0);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT1:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT1);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT2:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT2);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_SUPPORTS_BRANCHES:
case DRM_VC4_PARAM_SUPPORTS_ETC1:
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 303f23c96220..db920771bfb5 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -709,8 +709,10 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
}

mutex_lock(>power_lock);
-   if (--vc4->power_refcount == 0)
-   pm_runtime_put(>v3d->pdev->dev);
+   if (--vc4->power_refcount == 0) {
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
+   }
mutex_unlock(>power_lock);

kfree(exec);
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index e6d3c6028341..7cc346ad9b0b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -222,6 +222,8 @@ static int vc4_v3d_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}

+   pm_runtime_use_autosuspend(dev);
+   pm_runtime_set_autosuspend_delay(dev, 40); /* a little over 2 frames. */
pm_runtime_enable(dev);

return 0;
-- 
2.10.2

[PATCH 2/2] drm/amdgpu: add the interface of waiting multiple fences (v4)

[Alex Deucher]

From: Junwei Zhang 

v2: agd: rebase and squash in all the previous optimizations and
changes so everything compiles.
v3: squash in Slava's 32bit build fix
v4: rebase on drm-next (fence -> dma_fence),
squash in Monk's ioctl update patch

Signed-off-by: Junwei Zhang 
Reviewed-by: Monk Liu 
Reviewed-by: Jammy Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 173 
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |   2 +-
 include/uapi/drm/amdgpu_drm.h   |  28 ++
 5 files changed, 205 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index dc98ceb..7a94a3c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1212,6 +1212,8 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *filp);
 int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp);
 int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, struct drm_file 
*filp);
+int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);

 int amdgpu_gem_metadata_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2728805..2004836 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1130,6 +1130,179 @@ int amdgpu_cs_wait_ioctl(struct drm_device *dev, void 
*data,
 }

 /**
+ * amdgpu_cs_get_fence - helper to get fence from drm_amdgpu_fence
+ *
+ * @adev: amdgpu device
+ * @filp: file private
+ * @user: drm_amdgpu_fence copied from user space
+ */
+static struct dma_fence *amdgpu_cs_get_fence(struct amdgpu_device *adev,
+struct drm_file *filp,
+struct drm_amdgpu_fence *user)
+{
+   struct amdgpu_ring *ring;
+   struct amdgpu_ctx *ctx;
+   struct dma_fence *fence;
+   int r;
+
+   r = amdgpu_cs_get_ring(adev, user->ip_type, user->ip_instance,
+  user->ring, );
+   if (r)
+   return ERR_PTR(r);
+
+   ctx = amdgpu_ctx_get(filp->driver_priv, user->ctx_id);
+   if (ctx == NULL)
+   return ERR_PTR(-EINVAL);
+
+   fence = amdgpu_ctx_get_fence(ctx, ring, user->seq_no);
+   amdgpu_ctx_put(ctx);
+
+   return fence;
+}
+
+/**
+ * amdgpu_cs_wait_all_fence - wait on all fences to signal
+ *
+ * @adev: amdgpu device
+ * @filp: file private
+ * @wait: wait parameters
+ * @fences: array of drm_amdgpu_fence
+ */
+static int amdgpu_cs_wait_all_fences(struct amdgpu_device *adev,
+struct drm_file *filp,
+union drm_amdgpu_wait_fences *wait,
+struct drm_amdgpu_fence *fences)
+{
+   uint32_t fence_count = wait->in.fence_count;
+   unsigned i;
+   long r = 1;
+
+   for (i = 0; i < fence_count; i++) {
+   struct dma_fence *fence;
+   unsigned long timeout = amdgpu_gem_timeout(wait->in.timeout_ns);
+
+   fence = amdgpu_cs_get_fence(adev, filp, [i]);
+   if (IS_ERR(fence))
+   return PTR_ERR(fence);
+   else if (!fence)
+   continue;
+
+   r = dma_fence_wait_timeout(fence, true, timeout);
+   if (r < 0)
+   return r;
+
+   if (r == 0)
+   break;
+   }
+
+   memset(wait, 0, sizeof(*wait));
+   wait->out.status = (r > 0);
+
+   return 0;
+}
+
+/**
+ * amdgpu_cs_wait_any_fence - wait on any fence to signal
+ *
+ * @adev: amdgpu device
+ * @filp: file private
+ * @wait: wait parameters
+ * @fences: array of drm_amdgpu_fence
+ */
+static int amdgpu_cs_wait_any_fence(struct amdgpu_device *adev,
+   struct drm_file *filp,
+   union drm_amdgpu_wait_fences *wait,
+   struct drm_amdgpu_fence *fences)
+{
+   unsigned long timeout = amdgpu_gem_timeout(wait->in.timeout_ns);
+   uint32_t fence_count = wait->in.fence_count;
+   uint32_t first = ~0;
+   struct dma_fence **array;
+   unsigned i;
+   long r;
+
+   /* Prepare the fence array */
+   array = (struct dma_fence **)kcalloc(fence_count, sizeof(struct 
dma_fence *),
+   GFP_KERNEL);
+   if (array == NULL)
+   return -ENOMEM;
+
+   for (i = 0; i < fence_count; i++) {
+   struct dma_fence *fence;
+
+   fence = amdgpu_cs_get_fence(adev, filp, [i]);
+

[PATCH 1/2] dma-buf: return index of the first signaled fence (v2)

[Alex Deucher]

From: "monk.liu" 

Return the index of the first signaled fence.  This information
is useful in some APIs like Vulkan.

v2: rebase on drm-next (fence -> dma_fence)

Signed-off-by: monk.liu 
Signed-off-by: Alex Deucher 
Cc: Sumit Semwal 
---

This is the same patch set I send out yesterday, I just
squashed the amdgpu patches together and rebased everything on
the fence -> dma_fence renaming.  This is used by our VK driver
and we are planning to use it in mesa as well.

drivers/dma-buf/dma-fence.c | 20 +++-
 include/linux/dma-fence.h   |  2 +-
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 9ef3c2f..dd00990 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -402,14 +402,18 @@ dma_fence_default_wait(struct dma_fence *fence, bool 
intr, signed long timeout)
 EXPORT_SYMBOL(dma_fence_default_wait);

 static bool
-dma_fence_test_signaled_any(struct dma_fence **fences, uint32_t count)
+dma_fence_test_signaled_any(struct dma_fence **fences, uint32_t count,
+   uint32_t *idx)
 {
int i;

for (i = 0; i < count; ++i) {
struct dma_fence *fence = fences[i];
-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   if (idx)
+   *idx = i;
return true;
+   }
}
return false;
 }
@@ -421,6 +425,7 @@ dma_fence_test_signaled_any(struct dma_fence **fences, 
uint32_t count)
  * @count: [in]number of fences to wait on
  * @intr:  [in]if true, do an interruptible wait
  * @timeout:   [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
+ * @idx:   [out]   the first signaled fence index, meaninful only on 
Returns positive
  *
  * Returns -EINVAL on custom fence wait implementation, -ERESTARTSYS if
  * interrupted, 0 if the wait timed out, or the remaining timeout in jiffies
@@ -432,7 +437,7 @@ dma_fence_test_signaled_any(struct dma_fence **fences, 
uint32_t count)
  */
 signed long
 dma_fence_wait_any_timeout(struct dma_fence **fences, uint32_t count,
-  bool intr, signed long timeout)
+  bool intr, signed long timeout, uint32_t *idx)
 {
struct default_wait_cb *cb;
signed long ret = timeout;
@@ -443,8 +448,11 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, 
uint32_t count,

if (timeout == 0) {
for (i = 0; i < count; ++i)
-   if (dma_fence_is_signaled(fences[i]))
+   if (dma_fence_is_signaled(fences[i])) {
+   if (idx)
+   *idx = i;
return 1;
+   }

return 0;
}
@@ -467,6 +475,8 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, 
uint32_t count,
if (dma_fence_add_callback(fence, [i].base,
   dma_fence_default_wait_cb)) {
/* This fence is already signaled */
+   if (idx)
+   *idx = i;
goto fence_rm_cb;
}
}
@@ -477,7 +487,7 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, 
uint32_t count,
else
set_current_state(TASK_UNINTERRUPTIBLE);

-   if (dma_fence_test_signaled_any(fences, count))
+   if (dma_fence_test_signaled_any(fences, count, idx))
break;

ret = schedule_timeout(ret);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index ba60c04..e578fe7 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -382,7 +382,7 @@ signed long dma_fence_wait_timeout(struct dma_fence *,
   bool intr, signed long timeout);
 signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
   uint32_t count,
-  bool intr, signed long timeout);
+  bool intr, signed long timeout, uint32_t 
*idx);

 /**
  * dma_fence_wait - sleep until the fence gets signaled
-- 
2.5.5

[PATCH 1/2] dma-buf: return index of the first signaled fence (v2)

[Sumit Semwal]

Hi Alex,

Thanks for the patches.

On 4 November 2016 at 14:16, Alex Deucher  wrote:
> From: "monk.liu" 
>
> Return the index of the first signaled fence.  This information
> is useful in some APIs like Vulkan.
>
> v2: rebase on drm-next (fence -> dma_fence)
>
> Signed-off-by: monk.liu 
> Signed-off-by: Alex Deucher 
> Cc: Sumit Semwal 
> ---
>
> This is the same patch set I send out yesterday, I just
> squashed the amdgpu patches together and rebased everything on
> the fence -> dma_fence renaming.  This is used by our VK driver
> and we are planning to use it in mesa as well.
>

Would you be ok if I apply this and the amdgpu patch both together via
drm-misc, or would you like me to notify you once I merge this for you
to take the amdgpu patch via your tree? I'm fine either ways, but
perhaps drm-misc would be a bit neater.

> drivers/dma-buf/dma-fence.c | 20 +++-
>  include/linux/dma-fence.h   |  2 +-
>  2 files changed, 16 insertions(+), 6 deletions(-)
>

Best regards,
Sumit.

linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Liviu Dudau]

On Fri, Nov 04, 2016 at 04:38:54PM +1100, Stephen Rothwell wrote:
> Hi Liviu,
> 
> On Thu, 3 Nov 2016 17:19:58 + Liviu Dudau  wrote:
> >
> > I have revamped the mali-dp tree and rebased it on the newer
> > version of drm-next (which includes the drm-misc change) and pushed the
> > updated patch in my tree.
> 
> Thanks for that.  However, several of the commits in your tree now have
> no Signed-off-by from you as the committer :-(

Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
alone should be good. Baoyou's patch is in my tree to stop him repeatedly
send me the same patch over and over again :) But yes, I will add my
Signed-off-by for that one.

Many thanks,
Liviu

> 
> -- 
> Cheers,
> Stephen Rothwell

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

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

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

--- Comment #16 from Peter Wu  ---
(In reply to Alex Deucher from comment #15)
> (In reply to Peter Wu from comment #14)
[..]
> > The Windows 8 requirements state that the discrete GPU is render-only[0],
> > but the Win10 reqs have no such requirement[1]. (Are these the same specs
> > you had in mind? If not, could you share the right one?) On my new hybrid
> > nvidia laptop, there are actually DP/HDMI ports to the dGPU (HDMI with
> > audio).
> 
> I had access to the PR3 spec internally.  I'm not sure if it's available
> publicly or not.  Support for displays was not included in the information I
> saw or from talking with our internal hybrid graphics architects.  It's
> possible the spec has been updated since I last talked to them earlier this
> year.  I can double check.
> 
> Does your new laptop use PR3 or the older nvidia proprietary ACPI method?

The laptop (Clevo P651RA) uses PR3 (confirmed via a Windows 10 trace):
https://github.com/Bumblebee-Project/bbswitch/issues/115#issuecomment-218622306

> > Have you been working on this or should I have a look?
> 
> I have not been.  Please have a look.  Thanks!

Ok, do you have any certainty about the earliest BIOS date where _PR3 is used?
E.g. if the minimum date is lowered to 2014 without checking for _PR3, would it
be likely to miss out some models?

-- 
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/20161104/5b292b35/attachment.html>

[Bug 185681] amdgpu: powerplay initialization failed

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

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

--- Comment #7 from René Linder  ---
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/powerplay?h=drm-fixes-4.9=025f8bfb84cbcaa78df31ab00d7e3c5f979e9e27

there is the iceland_get_evv_voltage who works ... and the new
smu7_get_evv_voltage uses generally the pptable in the beginning and thats
wrong.

There is a if for the V0 path but to late and wrong:


This must be switched bevore hwmgr->pptable (table_info) is requested. 
  if ((hwmgr->pp_table_version == PP_TABLE_V0)
|| !phm_get_sclk_for_voltage_evv(hwmgr,
Wrong part 2 should be hwmgr and not table_info:   
table_info->vddc_lookup_table, vv_id, )) {
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_ClockStretcher)) {
for (j = 1; j < sclk_table->count; j++) {
if (sclk_table->entries[j].clk == sclk &&
sclk_table->entries[j].cks_enable == 0) {
sclk += 5000;
break;
}
}
}

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

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

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

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

--- Comment #15 from Alex Deucher  ---
(In reply to Peter Wu from comment #14)
> (In reply to Alex Deucher from comment #12)
> [..]
> > > Lowering the minumum from 2015 to 2014 should work for nouveau:
> > > https://lists.freedesktop.org/archives/nouveau/2016-July/025619.html
> > > 
> > 
> > For further clarify on your research, the current hybrid graphics spec
> > requires no connectors on the dGPU and hence no audio devices.  For devices
> > with connectors on the dGPU, they should use the older vendor specific
> > methods and PR3 should not be exposed.
> 
> The list was mentioned because of the BIOS dates and whether _PR3 is used.
> 
> The Windows 8 requirements state that the discrete GPU is render-only[0],
> but the Win10 reqs have no such requirement[1]. (Are these the same specs
> you had in mind? If not, could you share the right one?) On my new hybrid
> nvidia laptop, there are actually DP/HDMI ports to the dGPU (HDMI with
> audio).
> 

I had access to the PR3 spec internally.  I'm not sure if it's available
publicly or not.  Support for displays was not included in the information I
saw or from talking with our internal hybrid graphics architects.  It's
possible the spec has been updated since I last talked to them earlier this
year.  I can double check.

Does your new laptop use PR3 or the older nvidia proprietary ACPI method?

>  [0]:
> https://msdn.microsoft.com/en-us/library/windows/hardware/dn265510(v=vs.85).
> aspx
>  [1]:
> https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/
> compatibility/systems#systemfundamentalsgraphicshybridgraphicsmultigpu
> 
> > > You can try to ask Mika, see v4.7-rc2-3-g9d26d3a. Maybe the presence of a
> > > power resource (_PR3 or flags.power_resources) can be used as a hint 
> > > whether
> > > to enable port PM.
> > 
> > Yes, the presence of _PR3 would be a great way to determine when to enable
> > it.
> 
> Have you been working on this or should I have a look?

I have not been.  Please have a look.  Thanks!

-- 
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/20161104/98f1ee2d/attachment.html>

[PATCH v8 05/12] drm/i915: don't whitelist oacontrol in cmd parser

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Being able to program OACONTROL from a non-privileged batch buffer is
> not sufficient to be able to configure the OA unit. This was originally
> allowed to help enable Mesa to expose OA counters via the
> INTEL_performance_query extension, but the current implementation based
> on programming OACONTROL via a batch buffer isn't able to report useable
> data without a more complete OA unit configuration. Mesa handles the
> possibility that writes to OACONTROL may not be allowed and so only
> advertises the extension after explicitly testing that a write to
> OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
> should be ok for userspace.
> 
> Removing this simplifies adding a new kernel api for configuring the OA
> unit without needing to consider the possibility that userspace might
> trample on OACONTROL state which we'd like to start managing within
> the kernel instead. In particular running any Mesa based GL application
> currently results in clearing OACONTROL when initializing which would
> disable the capturing of metrics.
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
Seems reasonable.
Reviewed-by: Sourab Gupta 

[Bug 185681] amdgpu: powerplay initialization failed

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

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

--- Comment #6 from René Linder  ---
I found some missing / wrong parts, if i look at the handle of PP_TABLE_V0 and
PP_TABLE_V1 Handling there is through the whole code everytime a direct access
to V0 = hwmgr->  V1 = table_info->

And i never found in the V0 source parts any pptable fill... i removed now the
smu7_get_evv_voltage from the V0 and now it seems to work partialy... I think
there is going something forget on the rework of the old explicit iceland code
path.

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

[PATCH v8 09/12] drm/i915: Add dev.i915.perf_stream_paranoid sysctl option

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Consistent with the kernel.perf_event_paranoid sysctl option that can
> allow non-root users to access system wide cpu metrics, this can
> optionally allow non-root users to access system wide OA counter metrics
> from Gen graphics hardware.
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_perf.c | 50 
> +++-
>  2 files changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 01438fb..a138f86 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2171,6 +2171,7 @@ struct drm_i915_private {
>   bool initialized;
>  
>   struct kobject *metrics_kobj;
> + struct ctl_table_header *sysctl_header;
>  
>   struct mutex lock;
>   struct list_head streams;
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 8d07c41..4e42073 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -64,6 +64,11 @@
>  #define POLL_FREQUENCY 200
>  #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
>  
> +/* for sysctl proc_dointvec_minmax of dev.i915.perf_stream_paranoid */
> +static int zero;
> +static int one = 1;
> +static u32 i915_perf_stream_paranoid = true;
> +
>  /* The maximum exponent the hardware accepts is 63 (essentially it selects 
> one
>   * of the 64bit timestamp bits to trigger reports from) but there's currently
>   * no known use case for sampling as infrequently as once per 47 thousand 
> years.
> @@ -1207,7 +1212,13 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
> *dev_priv,
>   }
>   }
>  
> - if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
> + /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
> +  * we check a dev.i915.perf_stream_paranoid sysctl option
> +  * to determine if it's ok to access system wide OA counters
> +  * without CAP_SYS_ADMIN privileges.
> +  */
> + if (!specific_ctx &&
> + i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
>   DRM_ERROR("Insufficient privileges to open system-wide i915 
> perf stream\n");
>   ret = -EACCES;
>   goto err_ctx;
> @@ -1454,6 +1465,39 @@ void i915_perf_unregister(struct drm_i915_private 
> *dev_priv)
>   dev_priv->perf.metrics_kobj = NULL;
>  }
>  
> +static struct ctl_table oa_table[] = {
> + {
> +  .procname = "perf_stream_paranoid",
> +  .data = _perf_stream_paranoid,
> +  .maxlen = sizeof(i915_perf_stream_paranoid),
> +  .mode = 0644,
> +  .proc_handler = proc_dointvec_minmax,
> +  .extra1 = ,
> +  .extra2 = ,
> +  },
> + {}
> +};
> +
> +static struct ctl_table i915_root[] = {
> + {
> +  .procname = "i915",
> +  .maxlen = 0,
> +  .mode = 0555,
> +  .child = oa_table,
> +  },
> + {}
> +};
> +
> +static struct ctl_table dev_root[] = {
> + {
> +  .procname = "dev",
> +  .maxlen = 0,
> +  .mode = 0555,
> +  .child = i915_root,
> +  },
> + {}
> +};
> +
>  void i915_perf_init(struct drm_i915_private *dev_priv)
>  {
>   if (!IS_HASWELL(dev_priv))
> @@ -1484,6 +1528,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
>   dev_priv->perf.oa.n_builtin_sets =
>   i915_oa_n_builtin_metric_sets_hsw;
>  
> + dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
> +
>   dev_priv->perf.initialized = true;
>  }
>  
> @@ -1492,6 +1538,8 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
>   if (!dev_priv->perf.initialized)
>   return;
>  
> + unregister_sysctl_table(dev_priv->perf.sysctl_header);
> +
>   memset(_priv->perf.oa.ops, 0, sizeof(dev_priv->perf.oa.ops));
>   dev_priv->perf.initialized = false;
>  }

Looks fine.
Reviewed-by: Sourab Gupta  

[PATCH v8 08/12] drm/i915: advertise available metrics via sysfs

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Each metric set is given a sysfs entry like:
> 
> /sys/class/drm/card0/metrics//id
> 
> This allows userspace to enumerate the specific sets that are available
> for the current system. The 'id' file contains an unsigned integer that
> can be used to open the associated metric set via
> DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
> specific OA unit register configuration that can be reliably used by
> userspace as a key to lookup corresponding counter meta data and
> normalization equations.
> 
> The guid registry is currently maintained as part of gputop along with
> the XML metric set descriptions and code generation scripts, ref:
> 
>  https://github.com/rib/gputop
>  > gputop-data/guids.xml
>  > scripts/update-guids.py
>  > gputop-data/oa-*.xml
>  > scripts/i915-perf-kernelgen.py
> 
>  $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
Looks good to me.
Reviewed-by: Sourab Gupta 

[PATCH v8 02/12] drm/i915: Add i915 perf infrastructure

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
> 
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system calls including read() to read typed and sized
> records; ioctl() to enable or disable capture and poll() to wait for
> data.
> 
> A stream is opened something like:
> 
>   uint64_t properties[] = {
>   /* Single context sampling */
>   DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> 
>   /* Include OA reports in samples */
>   DRM_I915_PERF_PROP_SAMPLE_OA, true,
> 
>   /* OA unit configuration */
>   DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
>   DRM_I915_PERF_PROP_OA_FORMAT, report_format,
>   DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
>};
>struct drm_i915_perf_open_param parm = {
>   .flags = I915_PERF_FLAG_FD_CLOEXEC |
>I915_PERF_FLAG_FD_NONBLOCK |
>I915_PERF_FLAG_DISABLED,
>   .properties_ptr = (uint64_t)properties,
>   .num_properties = sizeof(properties) / 16,
>};
>int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );
> 
> Records read all start with a common { type, size } header with
> DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> contain an extensible number of fields and it's the
> DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> determine what's included in every sample.
> 
> No specific streams are supported yet so any attempt to open a stream
> will return an error.
> 
> v2:
> use i915_gem_context_get() - Chris Wilson
> v3:
> update read() interface to avoid passing state struct - Chris Wilson
> fix some rebase fallout, with i915-perf init/deinit
> v4:
> s/DRM_IORW/DRM_IOW/ - Emil Velikov
> 
> Signed-off-by: Robert Bragg 
> ---
>  drivers/gpu/drm/i915/Makefile|   3 +
>  drivers/gpu/drm/i915/i915_drv.c  |   4 +
>  drivers/gpu/drm/i915/i915_drv.h  |  91 
>  drivers/gpu/drm/i915/i915_perf.c | 443 
> +++
>  include/uapi/drm/i915_drm.h  |  67 ++
>  5 files changed, 608 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/i915_perf.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 6123400..8d4e25f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -113,6 +113,9 @@ i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
>  # virtual gpu code
>  i915-y += i915_vgpu.o
>  
> +# perf code
> +i915-y += i915_perf.o
> +
>  ifeq ($(CONFIG_DRM_I915_GVT),y)
>  i915-y += intel_gvt.o
>  include $(src)/gvt/Makefile
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index af3559d..685c96e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -836,6 +836,8 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv,
>  
>   intel_detect_preproduction_hw(dev_priv);
>  
> + i915_perf_init(dev_priv);
> +
>   return 0;
>  
>  err_workqueues:
> @@ -849,6 +851,7 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv,
>   */
>  static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
>  {
> + i915_perf_fini(dev_priv);
>   i915_gem_load_cleanup(_priv->drm);
>   i915_workqueues_cleanup(dev_priv);
>  }
> @@ -2556,6 +2559,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
> DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
> i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
> i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
> DRM_RENDER_ALLOW),
>  };
>  
>  static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5a260db..7a65c0b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1767,6 +1767,84 @@ struct intel_wm_config {
>   bool sprites_scaled;
>  };
>  
> +struct i915_perf_stream;
> +
> +struct i915_perf_stream_ops {
> + /* Enables the collection of HW samples, either in response to
> +  * I915_PERF_IOCTL_ENABLE or implicitly called when stream is
> +  * opened without I915_PERF_FLAG_DISABLED.
> +  */
> + void (*enable)(struct i915_perf_stream *stream);
> +
> + /* Disables the collection of HW samples, either in response to
> +  * I915_PERF_IOCTL_DISABLE or implicitly called before
> +  * destroying the stream.
> +  */
> + void (*disable)(struct i915_perf_stream *stream);
> +
> + /* Return: true if any i915 perf records are ready to read()
> +  * for this stream.
> +  */
> + 

[PATCH] drm/dp: Make space for null terminator in the DP device ID char array

[Dhinakaran Pandiyan]

The DP device identification string read from the DPCD registers is 6
characters long at max. and we store it in a char array of the same length
without space for the NULL terminator. Fix this by increasing the array
size to 7 and initialize it to an empty string.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e6fe82..3a39312 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -544,7 +544,7 @@ void drm_dp_downstream_debug(struct seq_file *m,
 DP_DETAILED_CAP_INFO_AVAILABLE;
int clk;
int bpc;
-   char id[6];
+   char id[7] = "";
int len;
uint8_t rev[2];
int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
-- 
2.7.4

[Bug 98492] X-Plane 10 Core Dumping when using Real-Weather or any clouds

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

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

--- Comment #4 from Amarildo  ---
(In reply to Nicolai Hähnle from comment #1)
> Hi Amarildo, could you provide a backtrace with debug symbols of radeonsi?
> Also, if you could reproduce this with an apitrace and upload it somewhere,
> that would be very helpful.

Absolutely. I just need to know what is the exact command to launch the
simulator with. Could you specify it to me? 

I ran it with `GALLIUM_DDEBUG="pipelined 2000"` and I'm attatching the
resulting files now.

In the mean time I'll record it and upload the video yo YouTube.

Cheers

-- 
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/20161104/b1b9174a/attachment.html>

[Bug 98492] X-Plane 10 Core Dumping when using Real-Weather or any clouds

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

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

--- Comment #3 from Amarildo  ---
Created attachment 127759
  --> https://bugs.freedesktop.org/attachment.cgi?id=127759=edit
GALLIUM_DDEBUG-2

GALLIUM_DDEBUG 2

-- 
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/20161104/2a04d54e/attachment.html>

[Bug 98492] X-Plane 10 Core Dumping when using Real-Weather or any clouds

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

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

--- Comment #2 from Amarildo  ---
Created attachment 127758
  --> https://bugs.freedesktop.org/attachment.cgi?id=127758=edit
GALLIUM_DDEBUG-1

GALLIUM_DDEBUG="pipelined 2000"
FILE 1

-- 
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/20161104/f71c9576/attachment.html>

[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Rob Clark]

On Fri, Nov 4, 2016 at 1:32 PM, Eric Engestrom
 wrote:
> On Friday, 2016-11-04 13:12:51 -0400, Rob Clark wrote:
>> On Fri, Nov 4, 2016 at 12:27 PM, Ville Syrjälä
>>  wrote:
>> > On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark wrote:
>> >> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>> >>
>> >> drm: make drm_get_format_name thread-safe
>> >>
>> >> Signed-off-by: Eric Engestrom 
>> >> [danvet: Clarify that the returned pointer must be freed with
>> >> kfree().]
>> >> Signed-off-by: Daniel Vetter 
>> >>
>> >> Note: I think we need to be a bit careful about follow-up audits of
>> >> callers of this..  now that you need to kfree the return value I think
>> >> it is fairly easy for new patches to introduce new callers which leak
>> >> the return value.  We probably should have left the function as-is and
>> >> introduce a new variant, or something like that.
>> >>
>> >> Signed-off-by: Rob Clark 
>> >> ---
>> >>  drivers/gpu/drm/drm_fourcc.c | 5 -
>> >>  1 file changed, 4 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> >> index cbb8b77..2be9ea8 100644
>> >> --- a/drivers/gpu/drm/drm_fourcc.c
>> >> +++ b/drivers/gpu/drm/drm_fourcc.c
>> >> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>> >>   */
>> >>  char *drm_get_format_name(uint32_t format)
>> >>  {
>> >> - char *buf = kmalloc(32, GFP_KERNEL);
>> >> + char *buf = kmalloc(32, GFP_ATOMIC);
>> >> +
>> >> + if (!buf)
>> >> + return NULL;
>
> Unrelated bug, thanks for that fix too :)
>
>> >>
>> >>   snprintf(buf, 32,
>> >>"%c%c%c%c %s-endian (0x%08x)",
>> >
>> > Why aren't we using kasprintf()?
>
> Because I didn't know it was a thing :(
> Patch using it incoming.

Thanks

>> >
>> > Or we could have just made the caller provide the buffer...
>>
>> I guess kasprintf() would do the job (although still not address the
>> fact that we still always do the sprintf bits, rather than only doing
>> it when debug logs are enabled)..  caller provided buffer would be
>> better.  And make it more obvious that something needs to be fixed
>> when merging/rebasing patches that started life before this change
>> landed.
>>
>> I still kinda like the idea of making vsprintf know about fourcc's
>> with a new format string, and just making drm_get_format_name() go
>> away.
>>
>> But I don't really have time atm to re-work all the callers of
>> drm_get_format_name().  So I guess unless someone else does, I'd go w/
>> kasprintf() for now.
>
> That sounds cleaner to me indeed, I'll send a patch doing that tonight.
> Any idea for the name? drm_get_format_name_safe(uint32_t, char*)?
> I could also keep the same name and rely on the function signature
> change to make sure any merging of the old function call will break the
> compilation and be noticed that way.

I think if fxn signature changes, we can keep the same name.  What I
get nervous about is fxn sig+name stays same but semantics change ;-)

btw, if this isn't what you were already planning, I'd suggest:

   char *drm_get_format_name(uint32_t, char *);

so we can keep it inline w/ DRM_DEBUG_xyz() macros.  Or maybe something like:

   typedef char drm_format_name_buf[MAX_SIZE]
   char *drm_get_format_name(uint32_t, drm_format_name_buf);

??

BR,
-R


> Looks like I'm obviously not qualified to choose which is the best
> option, so I'll leave that to you guys :)
>
> Cheers,
>   Eric

[PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver

[Kevin Hilman]

Bartosz Golaszewski  writes:

> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski 

Reviewed-by: Kevin Hilman 

[PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver

[Kevin Hilman]

Bartosz Golaszewski  writes:

> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski 

Reviewed-by: Kevin Hilman 

[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

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

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

--- Comment #13 from Johannes Hirte  ---
(In reply to Alex Deucher from comment #12)
> Created attachment 127736 [details] [review]
> possible fix
> 
> This should fix it.

Yes, this fixes the panic on reboot/unloading the driver.

-- 
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/20161104/8095454c/attachment.html>

[git pull] drm fixes for 4.9-rc4

[Linus Torvalds]

On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie  wrote:
>
> There are a set of fixes for an oops we've been seeing around MST
> display unplug,

Side note: I heard from a couple of people at the KS that said that
they had had problems with suspend/resume after plugging in to a 4k
display (but _only_ a 4k display - apparently normal FHD displays
didn't show this). I think at least one was USB3/Thunderbolt. Ted with
a Lenovo laptop (intel GPU) was one, I forget who else mentioned this.

I wonder if MST may have been involved. That would explain the "only
happens for 4k" issue - I assume pretty much all MST displays are 4k.

suspend/resume might obviously fall very much under that "unplug"
issue and maybe this pull request thus already fixes it, but there
might be something that is specific to _just_ suspend/resume too.

Mind taking a look?

Linus

[PATCH v8 02/12] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

ddress_space
> *vm,
> > u64 min_size, u64 alignment,
> > @@ -3607,6 +3694,10 @@ int intel_engine_cmd_parser(struct
> intel_engine_cs *engine,
> >   u32 batch_len,
> >   bool is_master);
> >
> > +/* i915_perf.c */
> > +extern void i915_perf_init(struct drm_i915_private *dev_priv);
> > +extern void i915_perf_fini(struct drm_i915_private *dev_priv);
> > +
> >  /* i915_suspend.c */
> >  extern int i915_save_state(struct drm_device *dev);
> >  extern int i915_restore_state(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> > new file mode 100644
> > index 000..c45cf92
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -0,0 +1,443 @@
> > +/*
> > + * Copyright © 2015-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:
> > + *   Robert Bragg 
> > + */
> > +
> > +#include 
> > +
> > +#include "i915_drv.h"
> > +
> > +struct perf_open_properties {
> > + u32 sample_flags;
> > +
> > + u64 single_context:1;
> > + u64 ctx_handle;
> > +};
> > +
> > +static ssize_t i915_perf_read_locked(struct i915_perf_stream *stream,
> > +  struct file *file,
> > +  char __user *buf,
> > +  size_t count,
> > +  loff_t *ppos)
> > +{
> > + /* Note we keep the offset (aka bytes read) separate from any
> > +  * error status so that the final check for whether we return
> > +  * the bytes read with a higher precedence than any error (see
> > +  * comment below) doesn't need to be handled/duplicated in
> > +  * stream->ops->read() implementations.
> > +  */
> > + size_t offset = 0;
> > + int ret = stream->ops->read(stream, buf, count, );
> > +
> > + /* If we've successfully copied any data then reporting that
> > +  * takes precedence over any internal error status, so the
> > +  * data isn't lost.
> > +  *
> > +  * For example ret will be -ENOSPC whenever there is more
> > +  * buffered data than can be copied to userspace, but that's
> > +  * only interesting if we weren't able to copy some data
> > +  * because it implies the userspace buffer is too small to
> > +  * receive a single record (and we never split records).
> > +  *
> > +  * Another case with ret == -EFAULT is more of a grey area
> > +  * since it would seem like bad form for userspace to ask us
> > +  * to overrun its buffer, but the user knows best:
> > +  *
> > +  *   http://yarchive.net/comp/linux/partial_reads_writes.html
> > +  */
> > + return offset ?: (ret ?: -EAGAIN);
> > +}
> > +
> > +static ssize_t i915_perf_read(struct file *file,
> > +   char __user *buf,
> > +   size_t count,
> > +   loff_t *ppos)
> > +{
> > + struct i915_perf_stream *stream = file->private_data;
> > + struct drm_i915_private *dev_priv = stream->dev_priv;
> > + ssize_t ret;
> > +
> > + if (!(file->f_flags & O_NONBLOCK)) {
> > + /* Allow false positives from stream->ops->wait_unlocked.
> > +  */
> > + do {
> > + ret = stream->ops->wait_unlocked(stream);
> > + if (ret)
> > + return ret;
> > +
> > + mutex_lock(_priv->perf.lock);
>
> Should interruptible version be used here, to allow for reads to be
> interrupted?
>

Now that we don't have the context pin hook on haswell we could /almost/
get away without this lock except for its use to synchronize
i915_perf_register with i915_perf_open_ioctl.

Most of the i915-perf state access is synchronized as a result of being
fops driven, so this perf.lock was added to deal with a few entrypoints
outside of fops such as the contect pinning hook we used to have (though we
avoid it in the hrtimer callback).

Although the recent change to remove the pin hook has made the lock look a
bit redundant for now, I think I'd prefer to leave the locks as they are to
avoid the churn with the gen8+ patches where we do have some other
entrypoints into i915-perf outside of the fops.

Given that though, there's currently not really much argument either way
for them being interruptible. The expectation I have atm is that there
shouldn't be anything running async within i915-perf outside of fops that's
expected to be long running. We will probably also want to consider the
risk of bouncing lots of reads, starving userspace and increasing the risk
of a buffer overflow if this is interruptible.

- Robert
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161104/b52b433c/attachment-0001.html>

[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Rob Clark]

On Fri, Nov 4, 2016 at 12:27 PM, Ville Syrjälä
 wrote:
> On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark wrote:
>> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>>
>> drm: make drm_get_format_name thread-safe
>>
>> Signed-off-by: Eric Engestrom 
>> [danvet: Clarify that the returned pointer must be freed with
>> kfree().]
>> Signed-off-by: Daniel Vetter 
>>
>> Note: I think we need to be a bit careful about follow-up audits of
>> callers of this..  now that you need to kfree the return value I think
>> it is fairly easy for new patches to introduce new callers which leak
>> the return value.  We probably should have left the function as-is and
>> introduce a new variant, or something like that.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/drm_fourcc.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index cbb8b77..2be9ea8 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>>   */
>>  char *drm_get_format_name(uint32_t format)
>>  {
>> - char *buf = kmalloc(32, GFP_KERNEL);
>> + char *buf = kmalloc(32, GFP_ATOMIC);
>> +
>> + if (!buf)
>> + return NULL;
>>
>>   snprintf(buf, 32,
>>"%c%c%c%c %s-endian (0x%08x)",
>
> Why aren't we using kasprintf()?
>
> Or we could have just made the caller provide the buffer...

I guess kasprintf() would do the job (although still not address the
fact that we still always do the sprintf bits, rather than only doing
it when debug logs are enabled)..  caller provided buffer would be
better.  And make it more obvious that something needs to be fixed
when merging/rebasing patches that started life before this change
landed.

I still kinda like the idea of making vsprintf know about fourcc's
with a new format string, and just making drm_get_format_name() go
away.

But I don't really have time atm to re-work all the callers of
drm_get_format_name().  So I guess unless someone else does, I'd go w/
kasprintf() for now.

BR,
-R

>> --
>> 2.7.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC

[Bug 98238] witcher 2: objects are black when changing lod

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

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

--- Comment #4 from almos  ---
I forgot to mention that I reported this against Mesa 12.0.3 and LLVM 3.9.0,
but the situation was the same when I played the game earlier with Mesa 11.x. I
also tried 13.0-dev, but aside from some increase in performance (the worst
part is when defending the wall in Vergen at the end of chapter 2), I saw no
change in visuals. In the game's launcher there is an option to select between
OpenGL 2.1 and 3.2, but I see absolutely no difference between them.

-- 
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/20161104/21e815c9/attachment.html>

redraw issues on i915 since 4.9-rc

[Chris Wilson]

On Fri, Nov 04, 2016 at 08:40:47PM +0900, Norbert Preining wrote:
> Dear all,
> 
> since 4.9-rc series started I see heavy redraw problems on i915. Starting
> or resizing for example the digikam window messes up completely the content.
> 
> I have seen this at least since rc2 (I often wait till rc2), and 
> confirm that 4.8.0 does not exhibit these problems.
> 
> A screenshot of the redraw problems is attached.

The fencing looks correct. To me it looks like we filled the vma with
the wrong set of pages from the parent object.

https://cgit.freedesktop.org/drm-intel/ #drm-intel-nightly contains one
interesting patch wrt to the partial vma->pages
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you mind testing -nightly to see if I'm barking up the wrong tree?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

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

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

Cris  changed:

   What|Removed |Added

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

--- Comment #11 from Cris  ---
No longer an issue. Recompiled llvm-git and mesa-git and everything works fine
with no frame drops, including lower resolution videos (which were grinding
everything to a halt).

-- 
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/20161104/da157071/attachment.html>

[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Rob Clark]

On Fri, Nov 4, 2016 at 11:32 AM, Rob Clark  wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom 
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vetter 
>
> Note: I think we need to be a bit careful about follow-up audits of
> callers of this..  now that you need to kfree the return value I think
> it is fairly easy for new patches to introduce new callers which leak
> the return value.  We probably should have left the function as-is and
> introduce a new variant, or something like that.

btw, the new kfree the result approach moves the snprintf stuff
outside the 'if (drm_debug & FOO)' check.. which is perhaps also a bit
unfortunate..

I wonder how much the rest of the kernel would hate it if we pimped
out vsprintf.c to give us a special fmt string for fourcc formats?  I
guess it would also be useful for v4l..

It's too bad the kernel doesn't have something like register_printf_function()..


BR,
-R

> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..2be9ea8 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>   */
>  char *drm_get_format_name(uint32_t format)
>  {
> -   char *buf = kmalloc(32, GFP_KERNEL);
> +   char *buf = kmalloc(32, GFP_ATOMIC);
> +
> +   if (!buf)
> +   return NULL;
>
> snprintf(buf, 32,
>  "%c%c%c%c %s-endian (0x%08x)",
> --
> 2.7.4
>

[Spice-devel] [drm/qxl 5/6] qxl: Don't notify userspace when monitors config is unchanged

[Christophe Fergeau]

On Thu, Nov 03, 2016 at 06:42:38PM +, Emil Velikov wrote:
> Hi guys,
> 
> On 2 November 2016 at 16:31, Christophe Fergeau  
> wrote:
> > Hey,
> >
> > On Mon, Oct 31, 2016 at 08:00:09AM -0400, Frediano Ziglio wrote:
> >> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> >> > b/drivers/gpu/drm/qxl/qxl_display.c
> >> > index 156b7de..edb90f6 100644
> >> > --- a/drivers/gpu/drm/qxl/qxl_display.c
> >> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
> >> > @@ -57,11 +57,18 @@ static void qxl_alloc_client_monitors_config(struct
> >> > qxl_device *qdev, unsigned c
> >> > qdev->client_monitors_config->count = count;
> >> >  }
> >> >
> >> > +enum MonitorsConfigCopyStatus {
> >> > +   MONITORS_CONFIG_COPIED,
> >> > +   MONITORS_CONFIG_UNCHANGED,
> >> > +   MONITORS_CONFIG_BAD_CRC,
> >> > +};
> >> > +
> >>
> >> I don't remember exactly kernel style, a
> >>
> >> typedef enum {
> >>   MONITORS_CONFIG_COPIED,
> >>   MONITORS_CONFIG_UNCHANGED,
> >>   MONITORS_CONFIG_BAD_CRC,
> >> } MonitorsConfigCopyStatus;
> >>
> >> could make following code shorter.
> >
> > A git grep enum in qxl/ returns a dozen results, none of these using
> > typedef, I guess I just followed that style.
> >
> Kernel coding style advises against both typedefs and CamelCase. We do
> have a few "offenders" but it's better to not add more.
> 
> Ftw when in doubt do search/grep through the document - I don't thinks
> there's many people who've read the thing in one go :-)

Ah thanks, I'll get rid of the CamelCase!

Christophe
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161104/8881115e/attachment.sig>

[Spice-devel] [drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Christophe Fergeau]

On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote:
> > Or maybe other parts of the
> > kernel/userspace rely on this rounding down.
> 
> This is where I suspect we could run in trouble.  Odd resolutions simply
> don't happen on physical hardware, all usual resolutions are a multiple
> of 8, most of them are even a multiple of 16.
> 
> Various image/video formats use 16x16 blocks.
> The qemu vnc server operates on 16x16 blocks too (and we had bugs in the
> past with odd resolutions).
> 
> Also scanlines and cachelines align nicely if you don't use odd
> resolutions.
> 
> > I unfortunately don't know
> > :(
> 
> I don't have definitive answers too, just a gut feeling that this might
> cause trouble.

I think this might be fine actually, there is already one such
resolution in the kernel, which is 1366x768 (1366 is only a multiple of
2). There is already a bit of a hack to handle it anyway, see
fixup_mode_1366x768() in drm_edid.c.

> 
> Maybe we should add a module option for this?  So there is an easy
> (as-in: doesn't require a kernel rebuild) way out in case it causes
> trouble in certain setups?

This seems a bit overkill to me, but I can look into it if needed.

Christophe
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161104/6199a45d/attachment.sig>

[PATCH 1/3] dma-buf: return index of the first signaled fence

[Sumit Semwal]

Hi Alex,

Thanks for this patch. Adding Gustavo as well.

On 3 November 2016 at 11:41, Alex Deucher  wrote:
> From: "monk.liu" 
>
> Return the index of the first signaled fence.  This information
> is useful in some APIs like Vulkan.
>
> Signed-off-by: monk.liu 
> Signed-off-by: Alex Deucher 
> Cc: Sumit Semwal 
> ---
>  drivers/dma-buf/fence.c | 19 ++-
>  include/linux/fence.h   |  2 +-
>  2 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
> index 64478f9..32fdce1 100644
> --- a/drivers/dma-buf/fence.c
> +++ b/drivers/dma-buf/fence.c
> @@ -397,14 +397,17 @@ out:
>  EXPORT_SYMBOL(fence_default_wait);
>
>  static bool
> -fence_test_signaled_any(struct fence **fences, uint32_t count)
> +fence_test_signaled_any(struct fence **fences, uint32_t count, uint32_t *idx)
>  {
Looks sane to me; Gustavo, comments?

Best regards,
Sumit.

[PATCH 2/3] drm/amdgpu: add the interface of waiting multiple fences (v3)

[Sumit Semwal]

On 4 November 2016 at 11:14, Sumit Semwal  wrote:
> Hi Alex,
>
> Thanks for the patch!
>
> On 3 November 2016 at 11:41, Alex Deucher  wrote:
>> From: Junwei Zhang 
>>
>> v2: agd: rebase and squash in all the previous optimizations and
>> changes so everything compiles.
>> v3: squash in Slava's 32bit build fix
>>
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> 
>> +
>> +   r = fence_wait_any_timeout(array, fence_count, true, timeout);
>
> With the change proposed about returning index of signalled fence in
> patch 1/3, I don't think this would build?
>
O, just noticed - perhaps just a reordering of patches so that this is
1/3 (or even a separate patch?) and dma-buf change for index + amdgpu
change for the index are 2/3 and 3/3, should solve it.


> Best regards,
> Sumit.

[PATCH] drm: make drm_get_format_name atomic/irq safe again

[Rob Clark]

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

drm: make drm_get_format_name thread-safe

Signed-off-by: Eric Engestrom 
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter 

Note: I think we need to be a bit careful about follow-up audits of
callers of this..  now that you need to kfree the return value I think
it is fairly easy for new patches to introduce new callers which leak
the return value.  We probably should have left the function as-is and
introduce a new variant, or something like that.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_fourcc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..2be9ea8 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
  */
 char *drm_get_format_name(uint32_t format)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
+   char *buf = kmalloc(32, GFP_ATOMIC);
+
+   if (!buf)
+   return NULL;

snprintf(buf, 32,
 "%c%c%c%c %s-endian (0x%08x)",
-- 
2.7.4

[PATCH 2/3] drm/amdgpu: add the interface of waiting multiple fences (v3)

[Sumit Semwal]

Hi Alex,

Thanks for the patch!

On 3 November 2016 at 11:41, Alex Deucher  wrote:
> From: Junwei Zhang 
>
> v2: agd: rebase and squash in all the previous optimizations and
> changes so everything compiles.
> v3: squash in Slava's 32bit build fix
>
> Signed-off-by: Junwei Zhang 
> Reviewed-by: Monk Liu 
> Reviewed-by: Jammy Zhou 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |   2 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 171 
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   1 +
>  include/uapi/drm/amdgpu_drm.h   |  27 +
>  4 files changed, 201 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 8d0c689..c2050c0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

> +
> +   r = fence_wait_any_timeout(array, fence_count, true, timeout);

With the change proposed about returning index of signalled fence in
patch 1/3, I don't think this would build?

Best regards,
Sumit.

[Bug 98351] LibreOffice' OpenGL backend hangs GPU (ring 0&3 stalled)

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

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

--- Comment #1 from Nicolai Hähnle  ---
Thank you for the report. I cannot reproduce this on Tonga. Does this still
happen for you with a later kernel and/or Mesa git? There have been some hang
fixes relatively recently.

Are there any messages in dmesg before the "ring stalled" messages?

-- 
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/20161104/328d7aa2/attachment.html>

[PATCH v8 04/12] drm/i915: return EACCES for check_cmd() failures

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> check_cmd() is checking whether a command adheres to certain
> restrictions that ensure it's safe to execute within a privileged batch
> buffer. Returning false implies a privilege problem, not that the
> command is invalid.
> 
> The distinction makes the difference between allowing the buffer to be
> executed as an unprivileged batch buffer or returning an EINVAL error to
> userspace without executing anything.
> 
> In a case where userspace may want to test whether it can successfully
> write to a register that needs privileges the distinction may be
> important and an EINVAL error may be considered fatal.
> 
> In particular this is currently true for Mesa, which includes a test for
> whether OACONTROL can be written too, but Mesa treats any error when
> flushing a batch buffer as fatal, calling exit(1).
> 
> As it is currently Mesa can gracefully handle a failure to write to
> OACONTROL if the command parser is disabled, but if we were to remove
> OACONTROL from the parser's whitelist then the returned EINVAL would
> break Mesa applications as they attempt an OACONTROL write.
> 
> This bumps the command parser version from 7 to 8, as the change is
> visible to userspace.
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
Well, looks reasonable to me.

Reviewed-by: Sourab Gupta 

[PATCH 2/2] drm/vc4: Add support for rendering with ETC1 textures.

[Eric Anholt]

The validation for it ends up being quite simple, but I hadn't got
around to it before merging the driver.  For backwards compatibility,
we also need to add a flag so that the userspace GL driver can easily
tell if the kernel will allow ETC1 textures (on an old kernel, it will
continue to convert to RGBA8)

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c  | 1 +
 drivers/gpu/drm/vc4/vc4_validate.c | 7 +++
 include/uapi/drm/vc4_drm.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 8703f56b7947..b087404c2784 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -78,6 +78,7 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
pm_runtime_put(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_SUPPORTS_BRANCHES:
+   case DRM_VC4_PARAM_SUPPORTS_ETC1:
args->value = true;
break;
default:
diff --git a/drivers/gpu/drm/vc4/vc4_validate.c 
b/drivers/gpu/drm/vc4/vc4_validate.c
index 26503e307438..e18f88203d32 100644
--- a/drivers/gpu/drm/vc4/vc4_validate.c
+++ b/drivers/gpu/drm/vc4/vc4_validate.c
@@ -644,6 +644,13 @@ reloc_tex(struct vc4_exec_info *exec,
cpp = 1;
break;
case VC4_TEXTURE_TYPE_ETC1:
+   /* ETC1 is arranged as 64-bit blocks, where each block is 4x4
+* pixels.
+*/
+   cpp = 8;
+   width = (width + 3) >> 2;
+   height = (height + 3) >> 2;
+   break;
case VC4_TEXTURE_TYPE_BW1:
case VC4_TEXTURE_TYPE_A4:
case VC4_TEXTURE_TYPE_A1:
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index ad7edc3edf7c..69caa21f0cb2 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -286,6 +286,7 @@ struct drm_vc4_get_hang_state {
 #define DRM_VC4_PARAM_V3D_IDENT1   1
 #define DRM_VC4_PARAM_V3D_IDENT2   2
 #define DRM_VC4_PARAM_SUPPORTS_BRANCHES3
+#define DRM_VC4_PARAM_SUPPORTS_ETC14

 struct drm_vc4_get_param {
__u32 param;
-- 
2.10.1

[PATCH 1/2] drm/vc4: Fix termination of the initial scan for branch targets.

[Eric Anholt]

The loop is scanning until the original max_ip (size of the BO), but
we want to not examine any code after the PROG_END's delay slots.
There was a block trying to do that, except that we had some early
continue statements if the signal wasn't a PROG_END or a BRANCH.

The failure mode would be that a valid shader is rejected because some
undefined memory after the PROG_END slots is parsed as a branch and
the rest of its setup is illegal.  I haven't seen this in the wild,
but valgrind was complaining when about this up in the userland
simulator mode.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c 
b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
index 2543cf5b8b51..917321ce832f 100644
--- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c
+++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
@@ -608,9 +608,7 @@ static bool
 vc4_validate_branches(struct vc4_shader_validation_state *validation_state)
 {
uint32_t max_branch_target = 0;
-   bool found_shader_end = false;
int ip;
-   int shader_end_ip = 0;
int last_branch = -2;

for (ip = 0; ip < validation_state->max_ip; ip++) {
@@ -621,8 +619,13 @@ vc4_validate_branches(struct vc4_shader_validation_state 
*validation_state)
uint32_t branch_target_ip;

if (sig == QPU_SIG_PROG_END) {
-   shader_end_ip = ip;
-   found_shader_end = true;
+   /* There are two delay slots after program end is
+* signaled that are still executed, then we're
+* finished.  validation_state->max_ip is the
+* instruction after the last valid instruction in the
+* program.
+*/
+   validation_state->max_ip = ip + 3;
continue;
}

@@ -676,15 +679,9 @@ vc4_validate_branches(struct vc4_shader_validation_state 
*validation_state)
}
set_bit(after_delay_ip, validation_state->branch_targets);
max_branch_target = max(max_branch_target, after_delay_ip);
-
-   /* There are two delay slots after program end is signaled
-* that are still executed, then we're finished.
-*/
-   if (found_shader_end && ip == shader_end_ip + 2)
-   break;
}

-   if (max_branch_target > shader_end_ip) {
+   if (max_branch_target > validation_state->max_ip - 3) {
DRM_ERROR("Branch landed after QPU_SIG_PROG_END");
return false;
}
-- 
2.10.1

[Bug 98492] X-Plane 10 Core Dumping when using Real-Weather or any clouds

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

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

--- Comment #1 from Nicolai Hähnle  ---
Hi Amarildo, could you provide a backtrace with debug symbols of radeonsi?
Also, if you could reproduce this with an apitrace and upload it somewhere,
that would be very helpful.

-- 
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/20161104/4b753bde/attachment-0001.html>

Ping: [PATCH] radeon: avoid boot hang in Xen Dom0

[Alex Deucher]

On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich  wrote:
 On 13.09.16 at 17:54,  wrote:
>> While a hard hang in atom_asic_init() likely points at a deeper problem
>> in the driver, restore the capability to boot a Xen Dom0 by simply
>> avoiding the call there: Other than for Xen DomU, Dom0 owning a device
>> does not really mean is has got passed through to it.
>>
>> In case it is of interest for further investigation, lspci for the
>> offending device says:
>>
>> ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
>>
>> Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized 
>> environments"
>
> I may have overlooked a different fix dealing with the problem; if
> so, I'd appreciate that fix being pointed out.

Already fixed:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=884031f0aacf57dad1575f96714efc80de9b19cc

Alex

>
> Thanks, Jan
>
>> Signed-off-by: Jan Beulich 
>> ---
>>  drivers/gpu/drm/radeon/radeon_device.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> --- 4.8-rc6/drivers/gpu/drm/radeon/radeon_device.c
>> +++ 4.8-rc6-radeon-Xen-boot/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -34,6 +34,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "radeon_reg.h"
>>  #include "radeon.h"
>>  #include "atom.h"
>> @@ -642,7 +643,7 @@ void radeon_gtt_location(struct radeon_d
>>  static bool radeon_device_is_virtual(void)
>>  {
>>  #ifdef CONFIG_X86
>> - return boot_cpu_has(X86_FEATURE_HYPERVISOR);
>> + return boot_cpu_has(X86_FEATURE_HYPERVISOR) && !xen_initial_domain();
>>  #else
>>   return false;
>>  #endif
>>
>>
>>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

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

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

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #29 from Nicolai Hähnle  ---
Closing as per previous comment.

-- 
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/20161104/b0347084/attachment.html>

[Bug 98238] witcher 2: objects are black when changing lod

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

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

--- Comment #3 from Nicolai Hähnle  ---
Can you test with latest master/trunk of both Mesa and LLVM? The versions you
mention in Comment #1 are all quite old.

-- 
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/20161104/0ca97842/attachment.html>

Ping: [PATCH] radeon: avoid boot hang in Xen Dom0

[Jan Beulich]

>>> On 04.11.16 at 15:32,  wrote:
> On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich  wrote:
> On 13.09.16 at 17:54,  wrote:
>>> While a hard hang in atom_asic_init() likely points at a deeper problem
>>> in the driver, restore the capability to boot a Xen Dom0 by simply
>>> avoiding the call there: Other than for Xen DomU, Dom0 owning a device
>>> does not really mean is has got passed through to it.
>>>
>>> In case it is of interest for further investigation, lspci for the
>>> offending device says:
>>>
>>> ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
>>>
>>> Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized 
>>> environments"
>>
>> I may have overlooked a different fix dealing with the problem; if
>> so, I'd appreciate that fix being pointed out.
> 
> Already fixed:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=88 
> 4031f0aacf57dad1575f96714efc80de9b19cc

Hmm, that indeed should make the immediate problem go away.
Nevertheless I do think that Xen Dom0 should be treated just
like native here. Only DomU should be forced through that extra
path.

I did also notice that the equivalent function under amdgpu/ has
gone away again during the 4.9 merge window...

Jan

[PATCH] drm/sun4i: Propagate error to the caller

[Maxime Ripard]

On Fri, Nov 04, 2016 at 07:13:52AM +0100, Christophe JAILLET wrote:
> If 'sun4i_layers_init()' returns an error, propagate it instead of
> returning -EINVAL unconditionally.
> 
> Signed-off-by: Christophe JAILLET 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161104/873dafd5/attachment.sig>

[PATCH 1/2] drm/edid: Add the missing "Hz" to VIC 58,59 comment

[Andrzej Hajda]

On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> All the VICs apart from 58 and 59 have the word "Hz" included in the
> comment. Include it for 59 and 59 as well.
>
> Cc: Shashank Sharma 
> Cc: Andrzej Hajda 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

> ---
>  drivers/gpu/drm/drm_edid.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933b41cd..7eec18925b70 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -957,13 +957,13 @@ static const struct drm_display_mode edid_cea_modes[] = 
> {
>  798, 858, 0, 480, 489, 495, 525, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
> .vrefresh = 240, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /* 58 - 720(1440)x480i at 240 */
> + /* 58 - 720(1440)x480i at 240Hz */
>   { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 54000, 720, 739,
>  801, 858, 0, 480, 488, 494, 525, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
>   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 240, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> - /* 59 - 720(1440)x480i at 240 */
> + /* 59 - 720(1440)x480i at 240Hz */
>   { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 54000, 720, 739,
>  801, 858, 0, 480, 488, 494, 525, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |

[Bug 185681] amdgpu: powerplay initialization failed

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

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

--- Comment #5 from René Linder  ---
If i go back to where the Powermanagment (smu7_hwmgr.c) where the commit
change:

Since Commit: ab4f06d3adcc5165b13ed2e657050fd1808f319b (agd5f/linux
origin/drm-fixes-4.9
-iceland_hwmgr_init(hwmgr);
+topaz_set_asic_special_caps(hwmgr);
+hwmgr->feature_mask &= ~(PP_SMC_VOLTAGE_CONTROL_MASK |

And the Problem is that it get an empty table back here:
struct phm_ppt_v1_information *table_info =
(struct phm_ppt_v1_information *)hwmgr->pptable;
struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table = NULL;

printk("Table info");
if (table_info == NULL) {
printk("failed\n");
return -EINVAL;
}
printk("successfull");

dmesg Output of this Part:
[9.616470] [drm] Memory usable by graphics device = 2048M
[9.616473] [drm] Replacing VGA console driver
[9.616513] [drm] ACPI BIOS requests an excessive sleep of 5000 ms, using
1500 ms instead
[9.623922] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[9.623924] [drm] Driver supports precise vblank timestamp query.
[9.627447] vga_switcheroo: enabled
[9.627897] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[9.639545] ATOM BIOS: HP
[9.639562] [drm] GPU posting now...
[9.643523] [drm] Changing default dispclk from 0Mhz to 600Mhz
[9.646378] [TTM] Zone  kernel: Available graphics memory: 1910192 kiB
[9.646380] [TTM] Initializing pool allocator
[9.646387] [TTM] Initializing DMA pool allocator
[9.646413] amdgpu :0a:00.0: VRAM: 1024M 0x -
0x3FFF (1024M used)
[9.646415] amdgpu :0a:00.0: GTT: 1865M 0x4000 -
0xB496BFFF
[9.646426] [drm] Detected VRAM RAM=1024M, BAR=256M
[9.646428] [drm] RAM width 64bits DDR3
[9.646448] [drm] amdgpu: 1024M of VRAM memory ready
[9.646450] [drm] amdgpu: 1865M of GTT memory ready.
[9.646470] [drm] GART: num cpu pages 477548, num gpu pages 477548
[9.648496] [drm] PCIE GART of 1865M enabled (table at 0x0004).
[9.648543] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[9.648544] [drm] Driver supports precise vblank timestamp query.
[9.648598] amdgpu :0a:00.0: amdgpu: using MSI.
[9.648633] [drm] amdgpu: irq initialized.
[9.648642] Table info
[9.648643] failed
[9.648644] Get EVV Voltage Failed.  Abort Driver loading!
[9.648646] amdgpu: powerplay initialization failed
[9.648706] [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block
 failed -22
[9.648713] amdgpu :0a:00.0: amdgpu_init failed
[9.650148] [TTM] Finalizing pool allocator
[9.650152] [TTM] Finalizing DMA pool allocator
[9.650181] [TTM] Zone  kernel: Used memory at exit: 0 kiB
[9.650182] [drm] amdgpu: ttm finalized
[9.650187] amdgpu :0a:00.0: Fatal error during GPU init
[9.650193] [drm] amdgpu: finishing device.
[9.650195] [TTM] Memory type 2 has not been initialized
[9.650232] vga_switcheroo: disabled
[9.650546] amdgpu: probe of :0a:00.0 failed with error -22

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

[PATCH] drm/sun4i: Propagate error to the caller

[Christophe JAILLET]

If 'sun4i_layers_init()' returns an error, propagate it instead of
returning -EINVAL unconditionally.

Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 628712e6edd6..ee4e5f987b6f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -145,7 +145,7 @@ static int sun4i_drv_bind(struct device *dev)
drv->layers = sun4i_layers_init(drm);
if (IS_ERR(drv->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
-   ret = -EINVAL;
+   ret = PTR_ERR(drv->layers);
goto free_drm;
}

-- 
2.9.3

[PATCH v5] drm/fsl-dcu: Implement gamma_lut atomic crtc properties

[Meng Yi]

Hi Stefan,

> 
> How did you actually test that? I have a hard time to get anything useable 
> with
> this code.
> 
> The display looks completely borked (colors are way off, and at random either
> too dark or too bright).
> 
> I then also added Gamma 1.0 (and different values) to the Monitor section of
> xorg.conf, but still not really usable.
> 

I just did few more test using libdrm which had been modified for testing 
gamma. 
And I find you are right. It's my negligence that just tested one case for 
gamma using all 0xff;


.

> > drm_crtc_send_vblank_event(crtc, event);
> > spin_unlock_irq(>dev->event_lock);
> > }
> > +
> > +   if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut)
> > +   fsl_crtc_gamma_set(crtc, (struct drm_color_lut *)
> > +  crtc->state->gamma_lut->data, 256);
> 
> So this is called while the CRTC is enabled. Others do it there too, but I 
> think in
> our case we should not. The reference manual says:
> 
> "The gamma table can only be read or written when the 2D-ACE is not enabled
> or during the vertical blanking period."
> 

Yes, now gamma correction function behavior weird.
When setting gamma table within crtc enable during initializing, it works 
correctly. And not right during runtime so far.


Thanks,
Meng

Ping: [PATCH] radeon: avoid boot hang in Xen Dom0

[Jan Beulich]

>>> On 13.09.16 at 17:54,  wrote:
> While a hard hang in atom_asic_init() likely points at a deeper problem
> in the driver, restore the capability to boot a Xen Dom0 by simply
> avoiding the call there: Other than for Xen DomU, Dom0 owning a device
> does not really mean is has got passed through to it.
> 
> In case it is of interest for further investigation, lspci for the
> offending device says:
> 
> ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
> 
> Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized 
> environments"

I may have overlooked a different fix dealing with the problem; if
so, I'd appreciate that fix being pointed out.

Thanks, Jan

> Signed-off-by: Jan Beulich 
> ---
>  drivers/gpu/drm/radeon/radeon_device.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- 4.8-rc6/drivers/gpu/drm/radeon/radeon_device.c
> +++ 4.8-rc6-radeon-Xen-boot/drivers/gpu/drm/radeon/radeon_device.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "radeon_reg.h"
>  #include "radeon.h"
>  #include "atom.h"
> @@ -642,7 +643,7 @@ void radeon_gtt_location(struct radeon_d
>  static bool radeon_device_is_virtual(void)
>  {
>  #ifdef CONFIG_X86
> - return boot_cpu_has(X86_FEATURE_HYPERVISOR);
> + return boot_cpu_has(X86_FEATURE_HYPERVISOR) && !xen_initial_domain();
>  #else
>   return false;
>  #endif
> 
> 
> 

[PATCH v8 10/12] drm/i915: add oa_event_min_timer_exponent sysctl

[Robert Bragg]

On Wed, Nov 2, 2016 at 6:29 AM, sourab gupta  wrote:

> On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> > The minimal sampling period is now configurable via a
> > dev.i915.oa_min_timer_exponent sysctl parameter.
> >
> > Following the precedent set by perf, the default is the minimum that
> > won't (on its own) exceed the default kernel.perf_event_max_sample_rate
> > default of 10 samples/s.
> >
> > Signed-off-by: Robert Bragg 
> > Reviewed-by: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/i915_perf.c | 42 --
> --
> >  1 file changed, 30 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> > index 4e42073..e3c6f51 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -82,6 +82,22 @@ static u32 i915_perf_stream_paranoid = true;
> >  #define INVALID_CTX_ID 0x
> >
> >
> > +/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
> > +static int oa_exponent_max = OA_EXPONENT_MAX;
> > +
> > +/* Theoretically we can program the OA unit to sample every 160ns but
> don't
> > + * allow that by default unless root...
> > + *
> > + * The period is derived from the exponent as:
> > + *
> > + *   period = 80ns * 2^(exponent + 1)
> > + *
> > + * Referring to perf's kernel.perf_event_max_sample_rate for a
> precedent
> > + * (10 by default); with an OA exponent of 6 we get a period of
> 10.240
> > + * microseconds - just under 10Hz
> > + */
> > +static u32 i915_oa_min_timer_exponent = 6;
>
> For HSW, the timestamp period is 80ns, so the exponent of 6 translates
> to sampling rate of ~10Hz. But the timestamp period may change for
> other platforms, leading to different values of oa_min_timer_exponent
> corresponding to sampling rate of ~10Hz. Do we plan to have this
> value platform specific subsequently, or the guidance value of ~10Hz
> min sampling rate needn't be strictly followed?
>

actually it's bothered me a bit that I've been lazy with not having this
adapt for gen9+ in later patches

I think it would probably be better to make this a Hz based threshold for
userspace, otherwise any userspace policy here needs to be adapted for each
system with a different timestamp frequency which isn't great.

I've updated the patch locally to make this an oa_max_sample_rate parameter
in Hz, which I'll aim to test on haswell tomorrow and send out.

Thanks,
- Robert
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161104/e60f1a57/attachment.html>

[Bug 98505] [Topaz] Regression introduces in 4.8-rc3

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

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

--- Comment #14 from Peter Wu  ---
(In reply to Alex Deucher from comment #12)
[..]
> > Lowering the minumum from 2015 to 2014 should work for nouveau:
> > https://lists.freedesktop.org/archives/nouveau/2016-July/025619.html
> > 
> 
> For further clarify on your research, the current hybrid graphics spec
> requires no connectors on the dGPU and hence no audio devices.  For devices
> with connectors on the dGPU, they should use the older vendor specific
> methods and PR3 should not be exposed.

The list was mentioned because of the BIOS dates and whether _PR3 is used.

The Windows 8 requirements state that the discrete GPU is render-only[0], but
the Win10 reqs have no such requirement[1]. (Are these the same specs you had
in mind? If not, could you share the right one?) On my new hybrid nvidia
laptop, there are actually DP/HDMI ports to the dGPU (HDMI with audio).

 [0]:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn265510(v=vs.85).aspx
 [1]:
https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/compatibility/systems#systemfundamentalsgraphicshybridgraphicsmultigpu

> > You can try to ask Mika, see v4.7-rc2-3-g9d26d3a. Maybe the presence of a
> > power resource (_PR3 or flags.power_resources) can be used as a hint whether
> > to enable port PM.
> 
> Yes, the presence of _PR3 would be a great way to determine when to enable
> it.

Have you been working on this or should I have a look?

-- 
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/20161104/4ddf9b25/attachment-0001.html>

[PATCH] dma-buf/fence-array: enable_signaling from wq

[Chris Wilson]

On Thu, Nov 03, 2016 at 07:34:02PM -0400, Rob Clark wrote:
> On Thu, Nov 3, 2016 at 5:41 PM, Chris Wilson  
> wrote:
> > static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
> > {
> > struct dma_fence_array *array = to_dma_fence_array(fence);
> > int num_pending = atomic_read(>num_pending);
> > int i;
> >
> > for (i = 0; i < array->num_fences; i++)
> > if (is_signaled(array->fences[i]) && !--num_pending) {
> > atomic_set(>num_pending, 0);
> > return false;
> > }
> >
> > dma_fence_get(>base);
> > queue_work(system_unbound_wq, >enable_signaling_worker);
> > }
> 
> hmm, I guess just to try to avoid the wq?

Yeah, not all fences are capable of reporting the current status, and
some others may only report signaled() after enable_signaling, but for
i915/nouveau even msm can report the current status without the extra
step. For those it seems worth skipping the wq.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre