[PATCH 01/16] gpu: ipu-v3: Add Video Deinterlacer unit

2016-07-10 Thread Paul Gortmaker 
On Thu, Jul 7, 2016 at 7:03 PM, Steve Longerbeam  
wrote:
> Adds the Video Deinterlacer (VDIC) unit.
>
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/gpu/ipu-v3/Makefile |   2 +-
>  drivers/gpu/ipu-v3/ipu-common.c |  11 ++
>  drivers/gpu/ipu-v3/ipu-prv.h|   6 +
>  drivers/gpu/ipu-v3/ipu-vdi.c| 266 
> 
>  include/video/imx-ipu-v3.h  |  27 
>  5 files changed, 311 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c
>
> diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
> index 107ec23..aeba9dc 100644
> --- a/drivers/gpu/ipu-v3/Makefile
> +++ b/drivers/gpu/ipu-v3/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
>
>  imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
> -   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o
> +   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o ipu-vdi.o
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 99dcacf..30dc115 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -833,6 +833,14 @@ static int ipu_submodules_init(struct ipu_soc *ipu,
> goto err_ic;
> }
>
> +   ret = ipu_vdi_init(ipu, dev, ipu_base + devtype->vdi_ofs,
> +  IPU_CONF_VDI_EN | IPU_CONF_ISP_EN |
> +  IPU_CONF_IC_INPUT);
> +   if (ret) {
> +   unit = "vdi";
> +   goto err_vdi;
> +   }
> +
> ret = ipu_di_init(ipu, dev, 0, ipu_base + devtype->disp0_ofs,
>   IPU_CONF_DI0_EN, ipu_clk);
> if (ret) {
> @@ -887,6 +895,8 @@ err_dc:
>  err_di_1:
> ipu_di_exit(ipu, 0);
>  err_di_0:
> +   ipu_vdi_exit(ipu);
> +err_vdi:
> ipu_ic_exit(ipu);
>  err_ic:
> ipu_csi_exit(ipu, 1);
> @@ -971,6 +981,7 @@ static void ipu_submodules_exit(struct ipu_soc *ipu)
> ipu_dc_exit(ipu);
> ipu_di_exit(ipu, 1);
> ipu_di_exit(ipu, 0);
> +   ipu_vdi_exit(ipu);
> ipu_ic_exit(ipu);
> ipu_csi_exit(ipu, 1);
> ipu_csi_exit(ipu, 0);
> diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
> index bfb1e8a..845f64c 100644
> --- a/drivers/gpu/ipu-v3/ipu-prv.h
> +++ b/drivers/gpu/ipu-v3/ipu-prv.h
> @@ -138,6 +138,7 @@ struct ipu_dc_priv;
>  struct ipu_dmfc_priv;
>  struct ipu_di;
>  struct ipu_ic_priv;
> +struct ipu_vdi;
>  struct ipu_smfc_priv;
>
>  struct ipu_devtype;
> @@ -169,6 +170,7 @@ struct ipu_soc {
> struct ipu_di   *di_priv[2];
> struct ipu_csi  *csi_priv[2];
> struct ipu_ic_priv  *ic_priv;
> +   struct ipu_vdi  *vdi_priv;
> struct ipu_smfc_priv*smfc_priv;
>  };
>
> @@ -199,6 +201,10 @@ int ipu_ic_init(struct ipu_soc *ipu, struct device *dev,
> unsigned long base, unsigned long tpmem_base);
>  void ipu_ic_exit(struct ipu_soc *ipu);
>
> +int ipu_vdi_init(struct ipu_soc *ipu, struct device *dev,
> +unsigned long base, u32 module);
> +void ipu_vdi_exit(struct ipu_soc *ipu);
> +
>  int ipu_di_init(struct ipu_soc *ipu, struct device *dev, int id,
> unsigned long base, u32 module, struct clk *ipu_clk);
>  void ipu_di_exit(struct ipu_soc *ipu, int id);
> diff --git a/drivers/gpu/ipu-v3/ipu-vdi.c b/drivers/gpu/ipu-v3/ipu-vdi.c
> new file mode 100644
> index 000..1303bcc
> --- /dev/null
> +++ b/drivers/gpu/ipu-v3/ipu-vdi.c
> @@ -0,0 +1,266 @@
> +/*
> + * Copyright (C) 2012 Mentor Graphics Inc.
> + * Copyright (C) 2005-2009 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> + * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * for more details.
> + */
> +#include 
> +#include 

You have a u32 field in a struct called "modules" but aside from that, I do not
see anything in this code requiring module.h -- did I miss something?

You might want export.h for EXPORT_SYMBOL though.

Paul.
--

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu-prv.h"
> +

[...]

[Bug 96877] Bioshock Infinite: LLVM triggered Diagnostic Handler: Illegal instruction detected: Operand has incorrect register class.

2016-07-10 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=96877

--- Comment #2 from Nicolai Hähnle  ---
Created attachment 124989
  --> https://bugs.freedesktop.org/attachment.cgi?id=124989=edit
Treat insert and extract equally in selectMOVRELOffsetImpl

The attached patch fixes the bug for me.

-- 
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/20160710/9db069a1/attachment-0001.html>

Re: DRM_FBDEV_EMULATION with 2 or more displays

2016-07-10 Thread Alexander Shiyan 
>Среда,  6 июля 2016, 14:52 +03:00 от Alexander Shiyan mail.ru>:
>
>Hello.
>
>I have a question to experts of GPU/DRM subsystem.
>Can I use a frame buffer for each display or subsystem involves only a
>single frame buffer in emulation mode (DRM_FBDEV_EMULATION option)?
>In my current configuration is created, only one frame buffer for the FIRST 
>display (fb0).
>Are there any options for creating individual framebuffers?
>
>[drm] Initialized drm 1.1.0 20060810
>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>[drm] No driver support for vblank timestamp query.
>imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
>imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
>imx-drm display-subsystem: bound display at di0 (ops imx_pd_ops)
>imx-drm display-subsystem: bound display at di1 (ops imx_pd_ops)
>imx-drm display-subsystem: fb0:  frame buffer device
>[drm] Initialized imx-drm 1.0.0 20120507 on minor 0
>imx-ipuv3 4000.ipu: IPUv3EX probed
>
>Thanks!
>---

Can anyone answer this question?

---

[Bug 96881] ViennaCL fails dense_blas-bench-opencl benchmark with doubles on AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0)

2016-07-10 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=96881

Bug ID: 96881
   Summary: ViennaCL fails dense_blas-bench-opencl benchmark with
doubles on AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0)
   Product: Mesa
   Version: 11.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: ubizjak at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

The dense_blas-bench-opencl benchmark from ViennaCL suite fails with doubles on
AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0):

$ ./dense_blas-bench-opencl 

--
   Device Info
--

Name:AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0)
Vendor:  AMD
Type:GPU 
Available:   1
Max Compute Units:   10
Max Work Group Size: 256
Global Mem Size: 1073741824
Local Mem Size:  32768
Local Mem Type:  1
Host Unified Memory: 1


Benchmark : BLAS

sCOPY : 64.3 GB/s
sAXPY : 95.4 GB/s
sDOT : 85.3 GB/s
sGEMV-N : 20.8 GB/s
sGEMV-T : 44.3 GB/s
sGEMM-NN : 126 GFLOPs/s
sGEMM-NT : 87.6 GFLOPs/s
sGEMM-TN : 90.5 GFLOPs/s
sGEMM-TT : 72.3 GFLOPs/s

Build Status = -2 ( Err = -11 )
Log: unsupported call to function __subdf3 in av_cpu
Sources: #pragma OPENCL EXTENSION cl_khr_fp64 : enable

__kernel void av_cpu( 
  __global double * vec1, 
  uint4 size1, 
...

It looks like DFmode (double) instructions are not enabled correctly in LLVM
for targets that report cl_khr_fp64 extension.

clinfo reports:

Number of platforms   1
  Platform Name   Clover
  Platform Vendor Mesa
  Platform VersionOpenCL 1.1 MESA 11.2.2
  Platform ProfileFULL_PROFILE
  Platform Extensions cl_khr_icd
  Platform Extensions function suffix MESA

  Platform Name   Clover
Number of devices 1
  Device Name AMD CYPRESS (DRM 2.43.0, LLVM
3.8.0)
  Device Vendor   AMD
  Device Vendor ID0x1002
  Device Version  OpenCL 1.1 MESA 11.2.2
  Driver Version  11.2.2
  Device OpenCL C Version OpenCL C 1.1 
  Device Type GPU
  Device Profile  FULL_PROFILE
  Max compute units   10
  Max clock frequency 850MHz
  Max work item dimensions3
  Max work item sizes 256x256x256
  Max work group size 256
  Preferred work group size multiple  64
  Preferred / native vector sizes 
char16 / 16  
short8 / 8   
int  4 / 4   
long 2 / 2   
half 0 / 0(n/a)
float4 / 4   
double   2 / 2   
(cl_khr_fp64)
  Half-precision Floating-point support   (n/a)
  Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest  Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add   No
Support is emulated in software   No
Correctly-rounded divide and sqrt operations  No
  Double-precision Floating-point support (cl_khr_fp64)
Denormals Yes
Infinity and NANs Yes
Round to nearest  Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add   Yes
Support is emulated in software   No
Correctly-rounded divide and sqrt operations  No
...

-- 
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/20160710/c8340a6f/attachment.html>

vga_switcheroo audio runpm

2016-07-10 Thread Lukas Wunner 
Hi Peter,

> [12:42] Lekensteyn: Should the video card always be powered up when a
> register is read from the HDMI audio controller? Or would it be
> better to leave the video card suspended and just fail the HDA
> register reads?

It should probably be powered up.


> [12:43] Lekensteyn: I'm trying to figure out how vga_switcheroo should
  handle this, maybe l1k has an idea?
> [12:48] Lekensteyn: The current implemented policy is that the video card
> dictates the power state and that the HDMI audio device has to
> adapt (even if it is seemingly in use)

This current architecture seems to have come about historically (Dave
Airlie first implemented vga_switcheroo with manual power control,
then added runtime pm in a second step).

It may also be motivated by the fact that the driver core is currently
not supporting dependencies between devices beyond the hierarchical
parent/child relationship.

Rafael Wysocki (cc:) posted a series in January addressing the latter
problem with so-called "device links". The series was reposted recently
by Marek Szyprowski:
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1170031.html

The vga_switcheroo audio handling should probably be reworked to use such
"device links". The result would be that the GPU won't runtime suspend
as long as a ref is held for the audio card. The audio card needs to then
make sure that it releases any refs if it has nothing to do.

The "device links" series seems to impose more restrictions than we
actually need here, it seems to require that the "supplier" is bound
to a driver before the "consumer" may probe. IOW nouveau needs to be
bound before snd_hda_audio can probe. I'm not sure if that additional
(unnecessary) restriction is a problem.

I've recently tried to add runtime pm for muxed laptops to vga_switcheroo,
this is something that Pierre Moreau (cc:) has expressed an interest in
for his MacBook Pro. I came across a major roadblock in the form of
vga_switcheroo_set_dynamic_switch(). That function is called from the
DRM driver when the GPU runtime suspends and resumes. It takes the
vgasr_mutex. The problem is, if the user initiates a switch of the mux,
that mutex is already taken in vga_switcheroo_debugfs_write(). If the
GPU we're switching to is asleep, it'll wake up for the switch and
we'll get a deadlock when the DRM driver subsequently calls
vga_switcheroo_set_dynamic_switch().

I would like to get rid of vga_switcheroo_set_dynamic_switch() to solve
this. The function has two purposes: Number one, vga_switcheroo updates
its internal power state representation for the GPU. That is actually
pointless for driver power control because we can always query the
driver core for this information (e.g. pm_runtime_suspended()).
The second purpose is to switch the audio client on and off. If we would
use a "device link" to express the dependency between the audio device
and the GPU, we wouldn't need this. So moving to "device links" is
a prerequisite to make runtime pm work for muxed laptops.

If you want to take a stab at using "device links" for vga_switcheroo
then please go ahead as I'm swamped with other work. (I've reverse-
engineered retrieval of Apple device properties from EFI this week,
which is needed for Thunderbolt.) Let me know if you have any questions
or need stuff reviewed or whatever. Since the "device links" series
hasn't landed yet, it's still possible I think to ask for feature
requests should it not work for this particular use case. The
linux-pm at vger.kernel.org mailing list is the right place to inquire
about the series.

Thanks for raising this important question.

Lukas

[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"

2016-07-10 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=90481

--- Comment #14 from at46n at t-online.de ---
I'm also affected by this bug with my r7 260x on Ubuntu 16.04. If I'm able to
switch to a tty my system give my an endless amount of messages with "radeon
000:01:00.0: ring 0 stalled for more than 10004msec". Last time I also got 
"[drm:ci_dpm_enable [radeon]] *ERROR* ci_start_dpm failed
[drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed
[drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed"

-- 
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/20160710/e07a9e6f/attachment-0001.html>

[Bug 121831] New: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo

2016-07-10 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=121831

Bug ID: 121831
   Summary: Several kmemcheck: Caught 64-bit read from
uninitialized memory in radeo
   Product: Drivers
   Version: 2.5
Kernel Version: 4.7-rc6
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: casteyde.christian at free.fr
Regression: No

Created attachment 222631
  --> https://bugzilla.kernel.org/attachment.cgi?id=222631=edit
dmesg output

Slackware 64 14.1
With kmemcheck activated, I get the following warnings:
[ 1185.586288] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
(8801c2cd5d08)
[ 1185.586292] 60f11c8168509ab40188010001000100
[ 1185.586314]  i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u
[ 1185.586335]  ^
[ 1185.586337] RIP: 0010:[]  []
fence_signal+0x1d/0xe0
[ 1185.586343] RSP: 0018:8801b560fa20  EFLAGS: 00010282
[ 1185.586345] RAX: 0003 RBX: 8801c2cd5cc0 RCX:
0002
[ 1185.586346] RDX: 8002 RSI: 8801b5591fa0 RDI:
8801c2cd5cc0
[ 1185.586348] RBP: 8801b560fa50 R08:  R09:
0001
[ 1185.586349] R10:  R11:  R12:
0003
[ 1185.586350] R13: 8801c2cd5cc0 R14: 021ae410 R15:
8800a949
[ 1185.586352] FS:  7fe3e0e408c0() GS:8801c740()
knlGS:
[ 1185.586353] CS:  0010 DS:  ES:  CR0: 80050033
[ 1185.586355] CR2: 8801c7060c90 CR3: 0001b558d000 CR4:
000406f0
[ 1185.586356]  [] radeon_fence_signaled+0x4a/0x80
[ 1185.586360]  [] radeon_sa_bo_free+0x37/0xb0
[ 1185.586364]  [] radeon_ib_free+0x29/0x40
[ 1185.586369]  [] radeon_cs_parser_fini+0xc5/0x120
[ 1185.586372]  [] radeon_cs_ioctl+0x2fb/0x7d0
[ 1185.586374]  [] drm_ioctl+0x13e/0x530
[ 1185.586378]  [] radeon_drm_ioctl+0x47/0x80
[ 1185.586381]  [] do_vfs_ioctl+0x8e/0x670
[ 1185.586384]  [] SyS_ioctl+0x3c/0x70
[ 1185.586386]  [] entry_SYSCALL_64_fastpath+0x18/0xa8
[ 1185.586391]  [] 0x
[ 1197.075973] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
(8800a2cf4ac8)
[ 1197.075977] 02003f003f00
[ 1197.075999]  i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u
[ 1197.076019]  ^
[ 1197.076021] RIP: 0010:[]  []
fence_signal_locked+0x16/0xc0
[ 1197.076028] RSP: 0018:8801c7403d18  EFLAGS: 00010082
[ 1197.076029] RAX: 001a RBX: 8800a2cf4b10 RCX:

[ 1197.076031] RDX: 8800a949 RSI: 0003 RDI:
8800a2cf4a80
[ 1197.076032] RBP: 8801c7403d48 R08:  R09:
0001
[ 1197.076033] R10:  R11: 8200b540 R12:
8800a2cf4a80
[ 1197.076034] R13: 8800a9491ea8 R14:  R15:
0003
[ 1197.076036] FS:  () GS:8801c740()
knlGS:
[ 1197.076038] CS:  0010 DS:  ES:  CR0: 80050033
[ 1197.076039] CR2: 8801c29c016c CR3: 02006000 CR4:
000406f0
[ 1197.076040]  [] radeon_fence_check_signaled+0x41/0x80
[ 1197.076044]  [] __wake_up_common+0x4d/0x80
[ 1197.076334]  [] __wake_up+0x34/0x50
[ 1197.076336]  [] radeon_fence_process+0x26/0x30
[ 1197.076338]  [] evergreen_irq_process+0x92a/0x17e0
[ 1197.076342]  [] radeon_driver_irq_handler_kms+0x19/0x40
[ 1197.076345]  [] handle_irq_event_percpu+0x64/0x100
[ 1197.076349]  [] handle_irq_event+0x34/0x60
[ 1197.076352]  [] handle_edge_irq+0xbe/0x150
[ 1197.076356]  [] handle_irq+0x68/0x180
[ 1197.076360]  [] do_IRQ+0x68/0x130
[ 1197.076362]  [] ret_from_intr+0x0/0x19
[ 1197.076367]  [] cpuidle_enter+0x12/0x20
[ 1197.076371]  [] call_cpuidle+0x25/0x40
[ 1197.076373]  [] cpu_startup_entry+0x1b3/0x290
[ 1197.076375]  [] rest_init+0x12c/0x140
[ 1197.076379]  [] start_kernel+0x354/0x361
[ 1197.076384]  [] x86_64_start_reservations+0x2f/0x31
[ 1197.076387]  [] x86_64_start_kernel+0xeb/0xf0
[ 1197.076390]  [] 0x
[ 1207.836251] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
(8800a2cf4348)
etc.

In gdb:
(gdb) l *0x8158521d
0x8158521d is in fence_signal (drivers/dma-buf/fence.c:114).
109 unsigned long flags;
110
111 if (!fence)
112 return -EINVAL;
113
114 if (!ktime_to_ns(fence->timestamp)) {
115 fence->timestamp = ktime_get();
116 smp_mb__before_atomic();
117 }

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

[Bug 96877] Bioshock Infinite: LLVM triggered Diagnostic Handler: Illegal instruction detected: Operand has incorrect register class.

2016-07-10 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=96877

--- Comment #1 from Nicolai Hähnle  ---
Created attachment 124987
  --> https://bugs.freedesktop.org/attachment.cgi?id=124987=edit
Reduced test case, fails with llc -march=amdgcn -verify-machineinstrs

I can reproduce this, and I obtained the attached reduced testcase which has an
error since r274954 "AMDGPU: Improve offset folding for register indexing". I'm
not sure how that change is related to the particular error that I get...

-- 
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/20160710/750e3ed9/attachment.html>

[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap

2016-07-10 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=36522

--- Comment #13 from Christian Casteyde  ---
Update:
Still present in 4.7-rc6

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

[PATCH] dma-buf/sync_file: only enable fence signalling during wait

2016-07-10 Thread Maarten Lankhorst 
Op 08-07-16 om 17:44 schreef Gustavo Padovan:
> From: Gustavo Padovan 
>
> Signalling doesn't need to be enabled at sync_file creation, it is only
> required if userspace waiting the fence to signal through poll().
>
> Thus we delay fence_add_callback() until poll is called. It only adds the
> callback the first time poll() is called. This avoid re-adding the same
> callback multiple times.
>
> v2: rebase and update to work with new fence support for sync_file
>
> Signed-off-by: Gustavo Padovan 
> ---
> This patch applies on top of my latest sync_file changes to support
> fence_array: https://lkml.org/lkml/2016/7/4/534
>
>  drivers/dma-buf/sync_file.c | 23 ++-
>  include/linux/sync_file.h   |  2 ++
>  2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 61a687c..1db4a64 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -86,8 +86,6 @@ struct sync_file *sync_file_create(struct fence *fence)
>fence->ops->get_timeline_name(fence), fence->context,
>fence->seqno);
>  
> - fence_add_callback(fence, _file->cb, fence_check_cb_func);
> -
>   return sync_file;
>  }
>  EXPORT_SYMBOL(sync_file_create);
> @@ -269,9 +267,6 @@ static struct sync_file *sync_file_merge(const char 
> *name, struct sync_file *a,
>   goto err;
>   }
>  
> - fence_add_callback(sync_file->fence, _file->cb,
> -fence_check_cb_func);
> -
>   strlcpy(sync_file->name, name, sizeof(sync_file->name));
>   return sync_file;
>  
> @@ -286,7 +281,6 @@ static void sync_file_free(struct kref *kref)
>   struct sync_file *sync_file = container_of(kref, struct sync_file,
>kref);
>  
> - fence_remove_callback(sync_file->fence, _file->cb);
>   fence_put(sync_file->fence);
>   kfree(sync_file);
>  }
> @@ -306,13 +300,24 @@ static unsigned int sync_file_poll(struct file *file, 
> poll_table *wait)
>  
>   poll_wait(file, _file->wq, wait);
>  
> + if (!sync_file->enabled) {
> + fence_add_callback(sync_file->fence, _file->cb,
> +fence_check_cb_func);
> + sync_file->enabled = true;
> + }
Won't this blow up completely with 2 threads polling at the same time?

~Maarten

[PATCH 12/16] gpu: ipu-v3: Fix CSI0 blur in NTSC format

2016-07-10 Thread Steve Longerbeam 


On 07/08/2016 10:34 AM, Philipp Zabel wrote:
> Am Donnerstag, den 07.07.2016, 16:03 -0700 schrieb Steve Longerbeam:
>> From: Suresh Dhandapani 
>>
>> This patch will change the register IPU_CSI0_CCIR_CODE_2 value from
>> 0x40596 to 0x405A6. The change is related to the Start of field 1
>> first blanking line command bit[5-3] for NTSC format only. This
>> change is dependent with ADV chip where the NEWAVMODE is set to 0
>> in register 0x31. Setting NEWAVMODE to "0" in ADV means "EAV/SAV
>> codes generated to suit analog devices encoders".
>>
>> Signed-off-by: Suresh Dhandapani 
>> ---
>>   drivers/gpu/ipu-v3/ipu-csi.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
>> index 0eac28c..ec81958 100644
>> --- a/drivers/gpu/ipu-v3/ipu-csi.c
>> +++ b/drivers/gpu/ipu-v3/ipu-csi.c
>> @@ -422,7 +422,7 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
>>   
>>  ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
>>CSI_CCIR_CODE_1);
>> -ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
>> +ipu_csi_write(csi, 0x405A6, CSI_CCIR_CODE_2);
>>  ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
>>  } else {
>>  dev_err(csi->ipu->dev,
> This looks like a very hardware specific hack? I'll at least have to
> test if that also works with other analog decoders.

Hi Philipp,

Yes it's a hack, but it has always been a hack (hardcoded values). And the
reason is simple, nobody AFAIK (including me) understands how to program
these CSI_CCIR_CODE registers, the description in the reference manual is
complete gibberish.

The reason we made this change is that, in discussions with Analog Devices,
they recommended setting NEWAVMODE, which changes the positions of
the AV codes sent by the ADV7180 on the bt.656 bus. It took Suresh at least
a full day of reverse engineering (Suresh correct me if I am wrong) to hit
on the correct values in these registers to regain stable video after 
switching
the ADV7180 to NEWAVMODE.

Steve

[Bug 96877] Bioshock Infinite: LLVM triggered Diagnostic Handler: Illegal instruction detected: Operand has incorrect register class.

2016-07-10 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=96877

Bug ID: 96877
   Summary: Bioshock Infinite: LLVM triggered Diagnostic Handler:
Illegal instruction detected: Operand has incorrect
register class.
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: haagch at frickel.club
QA Contact: dri-devel at lists.freedesktop.org

This happens on my HD 7970M.

"Very Low" graphics settings work fine but trying to start with "Medium"
settings throws this error before it even gets to the menu.

The files are bit too big for bugzilla I think, so

Here is an stderr log with R600_DEBUG="vs,ps,gs,tes,tcs":
http://haagch.frickel.club/files/err.txt.gz

Here is an apitrace that causes the error:
http://haagch.frickel.club/files/bioshock.i386.trace.xz

Happened with latest mesa git and llvm 3.9.0svn_r274975 and now with
3.9.0svn_r275008 too.

-- 
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/20160710/cd3b8fe4/attachment.html>

[PATCH 2/2] drm/vc4: Squash commit for Mario's precise vblank timestamping.

2016-07-10 Thread Eric Anholt 
Mario Kleiner  writes:

> Hi Eric,
>
> thanks for all the infos and help! Both your patches look good and i 
> have successfully tested them on top of with my vblank timestamping patch.
>
> So for both:
>
> Reviewed-and-tested-by: Mario Kleiner 
>
> Will you squash 2/2 into my patch or should i resend my patch with yours 
> squashed in?

I'll squash it in.  Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160710/171bb9f0/attachment.sig>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

2016-07-10 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=80419

--- Comment #141 from Alassane Maiga  ---
Well I can reliably make it stop locking the system completely now. I switch to
console with ctrl+alt+f2 as soon as the game locks up and then back as soon as
the ring stall messages start to fill up the screen. When I am back the game is
not frozen anymore, but extremely slow. In fact all opengl related rendering
becomes slow. And I get this message each time I switch to console :
"GPU fault detected 146 0x0904xxxc
VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00029E48
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x040C"

How should I give more information?

If I restart the performance comes back to normal

-- 
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/20160710/1f9ed23d/attachment-0001.html>

[Bug 96866] REGRESSION System frozen after resume

2016-07-10 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=96866

Christopher M. Penalver  changed:

   What|Removed |Added

Summary|System frozen after resume, |REGRESSION System frozen
   |on Ubuntu 16.04 kernel  |after resume
   |4.4.0-22|
   Severity|critical|normal

--- Comment #1 from Christopher M. Penalver  ---
1) Edited title as not a Ubuntu bug, but an upstream one as per original
reporter (reproducible in mainline 4.7-rc6 and a regression).
2) Issue after suspend isn't Critical.

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

[PATCH] drm/vc4: remove redundant ret status check

2016-07-10 Thread Colin King 
From: Colin Ian King 

At the current point where ret is being checked for non-zero it has
not changed since it was initialized to zero, hence the check and the
label unref are redundant and can be removed.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 54d0471..0e4cf27 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -195,8 +195,6 @@ static int vc4_drm_bind(struct device *dev)
vc4_bo_cache_init(drm);

drm_mode_config_init(drm);
-   if (ret)
-   goto unref;

vc4_gem_init(drm);

@@ -218,7 +216,6 @@ unbind_all:
component_unbind_all(dev, drm);
 gem_destroy:
vc4_gem_destroy(drm);
-unref:
drm_dev_unref(drm);
vc4_bo_cache_destroy(drm);
return ret;
-- 
2.8.1

[PATCH v3 0/7] lib: string: add functions to case-convert strings

2016-07-10 Thread Chris Metcalf 
On 7/8/2016 6:43 PM, Markus Mayer wrote:
> This series introduces a family of generic string case conversion
> functions. This kind of functionality is needed in several places in
> the kernel. Right now, everybody seems to be implementing their own
> copy of this functionality.
>
> Based on the discussion of the previous version of this series[1] and
> the use cases found in the kernel, it does look like having several
> flavours of case conversion functions is beneficial. The use cases fall
> into three categories:
>  - copying a string and converting the case while specifying a
>maximum length to mimic strlcpy()
>  - copying a string and converting the case without specifying a
>length to mimic strcpy()
>  - converting the case of a string in-place (i.e. modifying the
>string that was passed in)
>
> Consequently, I am proposing these new functions:
>  void strlcpytoupper(char *dst, const char *src, size_t len);
>  void strlcpytolower(char *dst, const char *src, size_t len);
>  void strcpytoupper(char *dst, const char *src);
>  void strcpytolower(char *dst, const char *src);
>  void strtoupper(char *s);
>  void strtolower(char *s);

You may want to read the article here:

https://lwn.net/Articles/659214/

and follow up some of the discussion threads on LKML about the best
semantics to advertise for the strlcpy/strscpy variants.  It might be
helpful to return some kind of overflow/truncation error from your
copy functions so people can error-check the result.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com