[PATCH RFC 000/111] Etnaviv DRM driver

[Christian Gmeiner]

2015-04-02 22:01 GMT+02:00 Robert Nelson :
> On Thu, Apr 2, 2015 at 10:59 AM, Lucas Stach  
> wrote:
>> Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM
>> Linux:
>>> On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
>>> > Hey all,
>>> >
>>> > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
>>> > influenced by the MSM driver, as can be clearly seen with the first 
>>> > commits.
>>>
>>> You should be copying Greg KH for staging too.
>>>
>> I didn't do that on purpose. As stated below in the cover letter I'm not
>> really happy to push things into staging. Especially after the
>> experience with imx-drm, where it took us a considerable amount of work
>> to even get people to look at the code after it had landed in staging.
>>
>> If possible I would like to collect feedback now and only if someone
>> feels genuinely unhappy about this code living under drivers/gpu/drm
>> then keep it in staging. Otherwise I would like to move it when removing
>> the RFC from this patchset.
>
> Looks good so far Lucas on my wand quad..
>
> Where's your libdrm/mesa tree located that you've been working on?
>
> debian at arm:~$ uname -r
> 4.0.0-rc6-armv7-devel-r24
> debian at arm:~$ dmesg | grep etnaviv
> [3.711866] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops)
> [3.718015] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops)
> [3.724133] etnaviv gpu-subsystem: bound 2204000.gpu (ops gpu_ops)
> [3.730351] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> [3.771045] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108
> [3.802887] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
> [3.848287] [drm] Initialized etnaviv 1.0.0 20150302 on minor 1
>
> Regards,
>
> --

Where can we find the userspace (libdrm, mesa, ..)?

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state

[Christian Gmeiner]

2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux :
> On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach wrote:
>> While this isn't the case on i.MX6 a single GPU pipe can have
>> multiple rendering backend states, which can be selected by the
>> pipe switch command, so there is no strict mapping between the
>> user "pipes" and the PIPE_2D/PIPE_3D execution states.
>
> This is good, because on Dove we have a single Vivante core which
> supports both 2D and 3D together.  It's always bugged me that
> etnadrm has not treated cores separately from their capabilities.
>

Today I finally got the idea how this multiple pipe stuff should be
done the right way - thanks Russell.
So maybe you/we need to rework how the driver is designed regarding
cores and pipes.

On the imx6 we should get 3 device nodes each only supporting one pipe
type. On the dove we
should get only one device node supporting 2 pipes types. What do you think?

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH RFC 087/111] staging: etnaviv: align command stream size to 64 bit

[Christian Gmeiner]

2015-04-02 18:45 GMT+02:00 Russell King - ARM Linux :
> On Thu, Apr 02, 2015 at 06:29:24PM +0200, Lucas Stach wrote:
>> The start of the commands must always be 64bit aligned, it's the same
>> for all pipes. The size can be dword aligned if the last command in the
>> stream is something like SET_STATE with a length of 2. In that case one
>> needs to insert another padding dword, but as it's the end of the stream
>> userspace may omit that.
>>
>> So that more a question of policy: do we want userspace to always
>> specify the size including the padding and reject streams with a size
>> not double-dword aligned, or do we just fix it up in the kernel, as it's
>> equally easily done there. I was a bit on the fence here and decided to
>> go the "let the kernel fix things" route.
>
> Without really knowing the hardware, it's hard to say.  However, they
> seem to be designed around a 64-bit architecture, and I would not be
> surprised if the front end DMA always fetches from the command buffer
> in 64-bit quantities.

Thats what the hardware does.

>
> You mention SET_STATE, but the same applies to NOP, WAIT and all of the
> other commands for the 2D cores - the command word must always be in
> the first 32-bits of each 64-bit naturally aligned word in memory.
>

Yup - see 
https://github.com/laanwj/etna_viv/blob/master/doc/hardware.md#command-stream

> Given that, my feeling (and it's only a feeling) is that it would be
> potentially dangerous to allow userspace to pass a buffer which isn't
> aligned.  As you've found, the kernel would have to align the buffer
> size up to a 64-bit quantity to add the LINK command at the end anyway.
>
> So, I would err on the side of having userspace always do that, and
> we initially enforce that on the kernel side.  If we find that's too
> strict, we can always relax the kernel side - and we still remain
> compatible with userspace.  If we do the reverse, it's harder for the
> kernel to become more strict without breaking userspace.  Given the
> "no regressions" rule, that's something we all want to avoid. :)
>

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH RFC 092/111] staging: etnaviv: convert to_etnaviv_bo() to real function

[Christian Gmeiner]

2015-04-02 18:29 GMT+02:00 Russell King - ARM Linux :
> On Thu, Apr 02, 2015 at 05:30:34PM +0200, Lucas Stach wrote:
>> This provides a bit more type safety.
>>
>> Signed-off-by: Lucas Stach 
>> ---
>>  drivers/staging/etnaviv/etnaviv_gem.h | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/etnaviv/etnaviv_gem.h 
>> b/drivers/staging/etnaviv/etnaviv_gem.h
>> index cfade337d4db..fadd5198b3e8 100644
>> --- a/drivers/staging/etnaviv/etnaviv_gem.h
>> +++ b/drivers/staging/etnaviv/etnaviv_gem.h
>> @@ -75,7 +75,12 @@ struct etnaviv_gem_object {
>>
>>   struct etnaviv_gem_userptr userptr;
>>  };
>> -#define to_etnaviv_bo(x) container_of(x, struct etnaviv_gem_object, base)
>> +
>> +static inline
>> +struct etnaviv_gem_object *to_etnaviv_bo(struct drm_gem_object *obj)
>> +{
>> + return container_of(obj, struct etnaviv_gem_object, base);
>> +}
>
> I've always wondered about patches like this, and wondered how they're
> supposed to be more type safe.
>
> The only thing which I can see is that the inline function will warn if
> you pass it a const or volatile pointer, whereas container_of() will
> only warn if it's passed a volatile pointer.  Apart from that, I don't
> see any difference between the two.

Eclipse CDT is happier with functions then macros in some case. I have
no opinion
about this patch.

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH RFC 003/111] staging: etnaviv: add drm driver

[Christian Gmeiner]

2015-04-02 17:29 GMT+02:00 Lucas Stach :
> From: Christian Gmeiner 
>
> This is a consolidation by Russell King of Christian's drm work.
>
> Signed-off-by: Christian Gmeiner 
> Signed-off-by: Russell King 
> ---
>  drivers/staging/Kconfig  |   2 +
>  drivers/staging/Makefile |   1 +
>  drivers/staging/etnaviv/Kconfig  |  20 +
>  drivers/staging/etnaviv/Makefile |  17 +
>  drivers/staging/etnaviv/cmdstream.xml.h  | 218 ++
>  drivers/staging/etnaviv/common.xml.h | 253 +++
>  drivers/staging/etnaviv/etnaviv_buffer.c | 201 ++
>  drivers/staging/etnaviv/etnaviv_drv.c| 621 +
>  drivers/staging/etnaviv/etnaviv_drv.h| 143 
>  drivers/staging/etnaviv/etnaviv_gem.c| 706 +++
>  drivers/staging/etnaviv/etnaviv_gem.h| 100 +++
>  drivers/staging/etnaviv/etnaviv_gem_prime.c  |  56 ++
>  drivers/staging/etnaviv/etnaviv_gem_submit.c | 407 +++
>  drivers/staging/etnaviv/etnaviv_gpu.c| 984 
> +++
>  drivers/staging/etnaviv/etnaviv_gpu.h| 152 +
>  drivers/staging/etnaviv/etnaviv_iommu.c  | 185 +
>  drivers/staging/etnaviv/etnaviv_iommu.h  |  25 +
>  drivers/staging/etnaviv/etnaviv_iommu_v2.c   |  32 +
>  drivers/staging/etnaviv/etnaviv_iommu_v2.h   |  25 +
>  drivers/staging/etnaviv/etnaviv_mmu.c| 111 +++
>  drivers/staging/etnaviv/etnaviv_mmu.h|  37 +
>  drivers/staging/etnaviv/state.xml.h  | 348 ++
>  drivers/staging/etnaviv/state_hi.xml.h   | 405 +++
>  include/uapi/drm/etnaviv_drm.h   | 225 ++
>  24 files changed, 5274 insertions(+)
>  create mode 100644 drivers/staging/etnaviv/Kconfig
>  create mode 100644 drivers/staging/etnaviv/Makefile
>  create mode 100644 drivers/staging/etnaviv/cmdstream.xml.h
>  create mode 100644 drivers/staging/etnaviv/common.xml.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_buffer.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_drv.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_drv.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem_prime.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gem_submit.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_gpu.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.h
>  create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.c
>  create mode 100644 drivers/staging/etnaviv/etnaviv_mmu.h
>  create mode 100644 drivers/staging/etnaviv/state.xml.h
>  create mode 100644 drivers/staging/etnaviv/state_hi.xml.h
>  create mode 100644 include/uapi/drm/etnaviv_drm.h
>
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index 45baa83be7ce..441b1afbfe4c 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -108,4 +108,6 @@ source "drivers/staging/fbtft/Kconfig"
>
>  source "drivers/staging/i2o/Kconfig"
>
> +source "drivers/staging/etnaviv/Kconfig"
> +
>  endif # STAGING
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 29160790841f..f53cf8412c0c 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -46,3 +46,4 @@ obj-$(CONFIG_UNISYSSPAR)  += unisys/
>  obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD)  += clocking-wizard/
>  obj-$(CONFIG_FB_TFT)   += fbtft/
>  obj-$(CONFIG_I2O)  += i2o/
> +obj-$(CONFIG_DRM_ETNAVIV)  += etnaviv/
> diff --git a/drivers/staging/etnaviv/Kconfig b/drivers/staging/etnaviv/Kconfig
> new file mode 100644
> index ..6f034eda914c
> --- /dev/null
> +++ b/drivers/staging/etnaviv/Kconfig
> @@ -0,0 +1,20 @@
> +
> +config DRM_ETNAVIV
> +   tristate "etnaviv DRM"
> +   depends on DRM
> +   select SHMEM
> +   select TMPFS
> +   select IOMMU_API
> +   select IOMMU_SUPPORT
> +   default y
> +   help
> + DRM driver for Vivante GPUs.
> +
> +config DRM_ETNAVIV_REGISTER_LOGGING
> +   bool "etnaviv DRM register logging"
> +   depends on DRM_ETNAVIV
> +   default n
> +   help
> + Compile in support for logging register reads/writes in a format
> + that can be parsed by envytools demsm tool.  If enabled, register
> + logging can be switched on via etnaviv.reglog=y module param.
> diff --git a/drivers/staging/etnaviv/Makefile 
> b/drivers/staging/etnaviv/Makefile
> new file mode 100644
> index ..ef0cffabdcce
> --- /dev/null
> +++ b/drivers/staging/etnaviv/Makefile
> @@ -0,0 +1,17 @@
> +ccflags-y := -Iinclude/drm 

[Bug 89785] GPU Fault 147 and Ring Stalls and Tests Fail in Pillars of Eternity

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

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

--- Comment #14 from Matthew Scheirer  ---
I built mesa-git and llvm-svn and tested quite a bit of the game, after an hour
of play nothing crashes. I then tried to do everything in game that would
generate new shaders (casted all the spells, traveled to several zones, changed
equipment, etc) to see if anything triggered the bug, and it seems to be
resolved on my end. Here is the player.log of around five minutes of gameplay
containing the debug output from llvm. Its about 20MB big, so I threw it on
Google Drive. Framerates are good, no graphical glitches, and no crashes.

https://drive.google.com/file/d/0ByAFDLY1V3W2T1ZUYUREZHFjRkE/view?usp=sharing

So this is fixed on my end upstream.

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

[PATCH RFC 094/111] staging: etnaviv: plug in fence waiting in cpu_prepare

[Christian Gmeiner]

2015-04-02 17:30 GMT+02:00 Lucas Stach :
> Allows userspace to properly synchronize with the GPU when accessing
> buffers.
>
> Signed-off-by: Lucas Stach 
> ---
>  drivers/staging/etnaviv/etnaviv_gem.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/etnaviv/etnaviv_gem.c 
> b/drivers/staging/etnaviv/etnaviv_gem.c
> index 849d5cbb510c..57f3080fb632 100644
> --- a/drivers/staging/etnaviv/etnaviv_gem.c
> +++ b/drivers/staging/etnaviv/etnaviv_gem.c
> @@ -467,28 +467,28 @@ void etnaviv_gem_move_to_inactive(struct drm_gem_object 
> *obj)
>  int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op,
> struct timespec *timeout)
>  {
> -/*
> +
> struct drm_device *dev = obj->dev;
> struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
> -*/
> +
> int ret = 0;
> -   /* TODO */
> -#if 0
> +
> if (is_active(etnaviv_obj)) {
> uint32_t fence = 0;
>
> -   if (op & MSM_PREP_READ)
> +   if (op & ETNA_PREP_READ)
> fence = etnaviv_obj->write_fence;
> -   if (op & MSM_PREP_WRITE)
> +   if (op & ETNA_PREP_WRITE)
> fence = max(fence, etnaviv_obj->read_fence);
> -   if (op & MSM_PREP_NOSYNC)
> +   if (op & ETNA_PREP_NOSYNC)
> timeout = NULL;
>
> -   ret = etnaviv_wait_fence_interruptable(dev, fence, timeout);
> +   ret = etnaviv_wait_fence_interruptable(dev, etnaviv_obj->gpu,
> +  fence, timeout);
> }
>
> /* TODO cache maintenance */
> -#endif
> +
> return ret;
>  }
>
> --
> 2.1.4
>

looks like a part from
https://github.com/austriancoder/linux/commit/0c347857d7eff27834bd82d5485c97c3b16339ce

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH RFC 024/111] staging: etnaviv: fix multiple command buffer submission in etnaviv_buffer_queue()

[Christian Gmeiner]

Is there a real use case to make use of multiple command buffers per
one submit ioctl? I have removed
it from my kernel tree.

2015-04-02 17:29 GMT+02:00 Lucas Stach :
> From: Russell King 
>
> etnaviv_buffer_queue() could not handle multiple command buffers.  We
> can handle this trivially by adapting the existing code - we record
> where we want to link to, and walk the submitted command buffers in
> reverse order, appending a LINK command to the previous target.
>
> This also means that we conveniently end up with the address and size
> to link to when changing the previous WAIT command.
>
> Signed-off-by: Russell King 
> ---
>  drivers/staging/etnaviv/etnaviv_buffer.c | 45 
> +---
>  1 file changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/staging/etnaviv/etnaviv_buffer.c 
> b/drivers/staging/etnaviv/etnaviv_buffer.c
> index 945af22db3f1..be2b02ce9a46 100644
> --- a/drivers/staging/etnaviv/etnaviv_buffer.c
> +++ b/drivers/staging/etnaviv/etnaviv_buffer.c
> @@ -148,7 +148,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event, struct et
> struct etnaviv_gem_object *buffer = to_etnaviv_bo(gpu->buffer);
> struct etnaviv_gem_object *cmd;
> u32 *lw = buffer->vaddr + ((buffer->offset - 4) * 4);
> -   u32 back;
> +   u32 back, link_target, link_size;
> u32 i;
>
> if (drm_debug & DRM_UT_DRIVER)
> @@ -156,6 +156,8 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event, struct et
>
> /* save offset back into main buffer */
> back = buffer->offset;
> +   link_target = buffer->paddr + buffer->offset * 4;
> +   link_size = 6;
>
> /* trigger event */
> CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) | 
> VIVS_GL_EVENT_FROM_PE);
> @@ -165,27 +167,28 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event, struct et
> CMD_LINK(buffer, 2, buffer->paddr + ((buffer->offset - 1) * 4));
>
> /* update offset for every cmd stream */
> -   for (i = 0; i < submit->nr_cmds; i++)
> -   submit->cmd[i].obj->offset = submit->cmd[i].offset +
> -submit->cmd[i].size;
> +   for (i = submit->nr_cmds; i--; ) {
> +   cmd = submit->cmd[i].obj;
>
> -   /* TODO: inter-connect all cmd buffers */
> +   cmd->offset = submit->cmd[i].offset + submit->cmd[i].size;
>
> -   /* jump back from last cmd to main buffer */
> -   cmd = submit->cmd[submit->nr_cmds - 1].obj;
> -   CMD_LINK(cmd, 4, buffer->paddr + (back * 4));
> +   if (drm_debug & DRM_UT_DRIVER)
> +   pr_info("stream link from buffer %u to 0x%08x @ 
> 0x%08x %p\n",
> +   i, link_target,
> +   cmd->paddr + cmd->offset * 4,
> +   cmd->vaddr + cmd->offset * 4);
>
> -   /* update the size */
> -   for (i = 0; i < submit->nr_cmds; i++)
> -   submit->cmd[i].size = submit->cmd[i].obj->offset -
> - submit->cmd[i].offset;
> +   /* jump back from last cmd to main buffer */
> +   CMD_LINK(cmd, link_size, link_target);
>
> -   if (drm_debug & DRM_UT_DRIVER) {
> -   pr_info("stream link @ 0x%08x\n",
> -   cmd->paddr + ((cmd->offset - 1) * 4));
> -   pr_info("stream link @ %p\n",
> -   cmd->vaddr + ((cmd->offset - 1) * 4));
> +   /* update the size */
> +   submit->cmd[i].size = cmd->offset - submit->cmd[i].offset;
> +
> +   link_target = cmd->paddr + submit->cmd[i].offset * 4;
> +   link_size = submit->cmd[i].size * 2;
> +   }
>
> +   if (drm_debug & DRM_UT_DRIVER) {
> for (i = 0; i < submit->nr_cmds; i++) {
> struct etnaviv_gem_object *obj = submit->cmd[i].obj;
>
> @@ -195,16 +198,16 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event, struct et
>
> pr_info("link op: %p\n", lw);
> pr_info("link addr: %p\n", lw + 1);
> -   pr_info("addr: 0x%08x\n", submit->cmd[0].obj->paddr);
> +   pr_info("addr: 0x%08x\n", link_target);
> pr_info("back: 0x%08x\n", buffer->paddr + (back * 4));
> pr_info("event: %d\n", event);
> }
>
> /* Change WAIT into a LINK command; write the address first. */
> -   i = VIV_FE_LINK_HEADER_OP_LINK | 
> VIV_FE_LINK_HEADER_PREFETCH(submit->cmd[0].size * 2);
> -   *(lw + 1) = submit->cmd[0].obj->paddr + submit->cmd[0].offset * 4;
> +   *(lw + 1) = link_target;
> mb();
> -   *(lw)= i;
> +   *(lw) = VIV_FE_LINK_HEADER_OP_LINK |
> +   VIV_FE_LINK_HEADER_PREFETCH(link_size);
>   

[PATCH RFC 005/111] staging: etnaviv: remove IOMMUv2 stubs

[Christian Gmeiner]

2015-04-02 17:29 GMT+02:00 Lucas Stach :
> IOMMUv2 support isn't implemented yet, so don't pretend it is there.
>
> Signed-off-by: Lucas Stach 
> ---
>  drivers/staging/etnaviv/etnaviv_gpu.c  | 10 ++
>  drivers/staging/etnaviv/etnaviv_iommu_v2.c | 32 
> --
>  drivers/staging/etnaviv/etnaviv_iommu_v2.h | 25 ---
>  3 files changed, 6 insertions(+), 61 deletions(-)
>  delete mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.c
>  delete mode 100644 drivers/staging/etnaviv/etnaviv_iommu_v2.h
>
> diff --git a/drivers/staging/etnaviv/etnaviv_gpu.c 
> b/drivers/staging/etnaviv/etnaviv_gpu.c
> index d2d0556a9bad..e3b93c293dca 100644
> --- a/drivers/staging/etnaviv/etnaviv_gpu.c
> +++ b/drivers/staging/etnaviv/etnaviv_gpu.c
> @@ -21,7 +21,6 @@
>  #include "etnaviv_gem.h"
>  #include "etnaviv_mmu.h"
>  #include "etnaviv_iommu.h"
> -#include "etnaviv_iommu_v2.h"
>  #include "common.xml.h"
>  #include "state.xml.h"
>  #include "state_hi.xml.h"
> @@ -329,10 +328,13 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
> mmuv2 = gpu->identity.minor_features1 & 
> chipMinorFeatures1_MMU_VERSION;
> dev_dbg(gpu->dev->dev, "mmuv2: %d\n", mmuv2);
>
> -   if (!mmuv2)
> +   if (!mmuv2) {
> iommu = etnaviv_iommu_domain_alloc(gpu);
> -   else
> -   iommu = etnaviv_iommu_v2_domain_alloc(gpu);
> +   } else {
> +   dev_err(gpu->dev, "IOMMUv2 support is not implemented 
> yet!\n");
> +   ret = -ENODEV;
> +   goto fail;
> +   }
>
> if (!iommu) {
> ret = -ENOMEM;
> diff --git a/drivers/staging/etnaviv/etnaviv_iommu_v2.c 
> b/drivers/staging/etnaviv/etnaviv_iommu_v2.c
> deleted file mode 100644
> index 3039ee9cbc6d..
> --- a/drivers/staging/etnaviv/etnaviv_iommu_v2.c
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -/*
> - * Copyright (C) 2014 Christian Gmeiner 
> -  *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * 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.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include "etnaviv_gpu.h"
> -#include "state_hi.xml.h"
> -
> -
> -struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu)
> -{
> -   /* TODO */
> -   return NULL;
> -}
> diff --git a/drivers/staging/etnaviv/etnaviv_iommu_v2.h 
> b/drivers/staging/etnaviv/etnaviv_iommu_v2.h
> deleted file mode 100644
> index 603ea41c5389..
> --- a/drivers/staging/etnaviv/etnaviv_iommu_v2.h
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -/*
> - * Copyright (C) 2014 Christian Gmeiner 
> -  *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * 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.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
> - */
> -
> -#ifndef __ETNAVIV_IOMMU_V2_H__
> -#define __ETNAVIV_IOMMU_V2_H__
> -
> -#include 
> -struct etnaviv_gpu;
> -
> -struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu);
> -
> -#endif /* __ETNAVIV_IOMMU_V2_H__ */
> --
> 2.1.4
>

I am fine with this change. You may have seen that I have a code for
mmuv2 ready in my git tree. but at
the moment I have no device to test it. So I will bring back support later.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Takashi Iwai]

At Sun, 5 Apr 2015 17:20:34 +0100,
Russell King - ARM Linux wrote:
> 
> On Sun, Apr 05, 2015 at 05:57:09PM +0200, Takashi Iwai wrote:
> > > diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h
> > > new file mode 100644
> > > index ..93357b25d2e2
> > > --- /dev/null
> > > +++ b/include/sound/pcm_drm_eld.h
> > > @@ -0,0 +1,6 @@
> > > +#ifndef __SOUND_PCM_DRM_ELD_H
> > > +#define __SOUND_PCM_DRM_ELD_H
> > > +
> > > +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void 
> > > *eld);
> > > +
> > > +#endif
> > 
> > IMO, a single line of function declaration can be merged to
> > sound/pcm.h.
> 
> Ok.
> 
> > > diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> > > index 313f22e9d929..b534c8a6046b 100644
> > > --- a/sound/core/Kconfig
> > > +++ b/sound/core/Kconfig
> > > @@ -6,6 +6,9 @@ config SND_PCM
> > >   tristate
> > >   select SND_TIMER
> > >  
> > > +config SND_PCM_ELD
> > > + bool
> > 
> > I don't mind much adding this one, but a new Kconfig is always a
> > question.  I'd like to hear other's opinion, too.
> 
> That's more a question whether you want it always included in the build
> or not, especially as it is dependent on DRM header files.

OK, then it makes sense to split.


> > > +printk("%s: r %d-%d c %d-%d m %x\n", __func__, r->min, r->max, c->min, 
> > > c->max, rate_mask);
> > 
> > I guess this will be removed in the final version? ;)
> 
> Of course.
> 
> > > +static int eld_limit_channels(struct snd_pcm_hw_params *params,
> > > +   struct snd_pcm_hw_rule *rule)
> > > +{
> > > + struct snd_interval *var = hw_param_interval(params, rule->var);
> > > + struct snd_interval t = { .min = 1, .max = 2, .integer = 1, };
> > > + unsigned int i;
> > > + const u8 *sad, *eld = rule->private;
> > > +
> > > + sad = drm_eld_sad(eld);
> > > + if (sad) {
> > > + for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) {
> > > + switch (sad[0] & 0x78) {
> > > + case 0x08:
> > > + t.max = max(t.max, (sad[0] & 7) + 1u);
> > > + break;
> > 
> > What about the minimal channel?
> 
> There isn't a minimum.  The SAD describes only the _maximum_ number of
> channels.  For example, if a TV supports 5.1 audio, at 32, 44.1 and 48
> kHz, it can do that with just one SAD entry which indicates support for
> six channels of audio at those sample rates.  However, it will happily
> accept 2 channel audio at those sample rates too.

Alright, I remembered wrong.  I took a look at the existing HD-audio
ELD parser code, and it also handles only the max channels.

> > Ideally, we should either give a list of channel numbers or process
> > the hw_constraints dynamically to narrow the min/max matching with the
> > eld.
> 
> The ELD can change as a result of the HDMI sink deciding to change its
> EDID (it does happen) or if the device is unplugged and re-plugged.  If
> I wanted to restrict the maximum channel/rates by building some sort of
> table, I'd do this at open time and avoid the complexity of having rule
> callbacks.

Right, this is the easiest approach.

> Since (afaik) ALSA has a lack of support for dynamic reconfiguration
> according to the attached device changing, the best we can do without
> a huge amount of re-work of HDMI support across all adapters is to
> process the capabilities of the attached device at prepare time
> according to the current capabilities.

Yeah, reconfiguration is tricky.  BTW, how is the HDMI unplug handled
during playback?

> Implementing dynamic reconfiguration in ALSA is not something I want to
> get involved with, and as we /already/ have HDMI support merged in the
> kernel, this is not a blocker for at least trying to get some semblence
> of sanity, rather than having every driver re-implementing stuff like
> this.

Well, I didn't mean about the dynamic reconfiguration.  I thought of
rather min/max pairs, but it was just a wrong assumption.  Scratch
it.

One another question: don't we need to deal with the sample bits in
sad[2]?


Takashi

[PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Russell King - ARM Linux]

On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote:
> At Sun, 5 Apr 2015 17:20:34 +0100,
> Russell King - ARM Linux wrote:
> > Since (afaik) ALSA has a lack of support for dynamic reconfiguration
> > according to the attached device changing, the best we can do without
> > a huge amount of re-work of HDMI support across all adapters is to
> > process the capabilities of the attached device at prepare time
> > according to the current capabilities.
> 
> Yeah, reconfiguration is tricky.  BTW, how is the HDMI unplug handled
> during playback?

We don't handle it right now - and we don't have any notification to
the audio drivers that that has happened.  Even if we did have such a
notification, I'm not sure what the audio driver could do with it at
the moment.

> > Implementing dynamic reconfiguration in ALSA is not something I want to
> > get involved with, and as we /already/ have HDMI support merged in the
> > kernel, this is not a blocker for at least trying to get some semblence
> > of sanity, rather than having every driver re-implementing stuff like
> > this.
> 
> Well, I didn't mean about the dynamic reconfiguration.  I thought of
> rather min/max pairs, but it was just a wrong assumption.  Scratch
> it.
> 
> One another question: don't we need to deal with the sample bits in
> sad[2]?

It should, but I'm very wary about doing that without seeing more
examples of real SADs.  Right now, all my examples only support
one SAD with either 2 channel or 6 channel audio at the standard
(basic) 32, 44.1 and 48kHz rates.

The HDMI / CEA specs are very loose in their wording about the
short audio descriptors.  I've no idea whether a sink can provide
(for example) descriptors such as:

LPCM, 6 channel 32, 44.1, 48kHz
LPCM, 2 channel, 32, 44.1, 48, 96, 192kHz

or whether have to describe that as a single descriptor.  I only
have two TVs to test with here.

What I'm concerned about is that when the ALSA parameter refining
starts, we start with (eg) 2-8 channels, 32-192kHz.  Given that,
if we invoke the channel restriction before the rate restriction,
we would end up limiting to 2 channel at 32-192kHz.  If we apply
the restrictions in the opposite order, we'd restrict to 6
channel, 32-48kHz.  Neither are obviously correct in this
circumstance, and I don't really see a way to solve it given my
understanding of the way ALSA's parameter refinement works.

I suspect this is why most HDMI drivers are implemented such that
they take the maximum capabilities over all SADs, which would end
up restricting audio in the above case to: up to 6 channels, at
32, 44.1, 48, 96 and 192kHz, even though 6 channel @ 192kHz isn't
hasn't been indicated as supported.

Most of this is speculation though, based off what is in the
documentation.  As I say, I don't have enough real-world examples
to get a feel for what manufacturers _actually_ do to give a hint
as to how the documentation should be interpreted.

So, maybe I should just copy what everyone else does and take the
maximum of all descriptors...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Takashi Iwai]

At Thu, 02 Apr 2015 10:22:06 +0100,
Russell King wrote:
> 
> Add a helper for the EDID like data structure, which is typically passed
> from a HDMI adapter to its associated audio driver.  This informs the
> audio driver of the capabilities of the attached HDMI sink.
> 
> Signed-off-by: Russell King 
> ---
>  include/sound/pcm_drm_eld.h |  6 +++
>  sound/core/Kconfig  |  3 ++
>  sound/core/Makefile |  1 +
>  sound/core/pcm_drm_eld.c| 92 
> +
>  4 files changed, 102 insertions(+)
>  create mode 100644 include/sound/pcm_drm_eld.h
>  create mode 100644 sound/core/pcm_drm_eld.c
> 
> diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h
> new file mode 100644
> index ..93357b25d2e2
> --- /dev/null
> +++ b/include/sound/pcm_drm_eld.h
> @@ -0,0 +1,6 @@
> +#ifndef __SOUND_PCM_DRM_ELD_H
> +#define __SOUND_PCM_DRM_ELD_H
> +
> +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld);
> +
> +#endif

IMO, a single line of function declaration can be merged to
sound/pcm.h.


> diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> index 313f22e9d929..b534c8a6046b 100644
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -6,6 +6,9 @@ config SND_PCM
>   tristate
>   select SND_TIMER
>  
> +config SND_PCM_ELD
> + bool

I don't mind much adding this one, but a new Kconfig is always a
question.  I'd like to hear other's opinion, too.

>  config SND_DMAENGINE_PCM
>   tristate
>  
> diff --git a/sound/core/Makefile b/sound/core/Makefile
> index 4daf2f58261c..591b49157b4d 100644
> --- a/sound/core/Makefile
> +++ b/sound/core/Makefile
> @@ -13,6 +13,7 @@ snd-$(CONFIG_SND_JACK)+= jack.o
>  snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o \
>   pcm_memory.o memalloc.o
>  snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
> +snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
>  
>  # for trace-points
>  CFLAGS_pcm_lib.o := -I$(src)
> diff --git a/sound/core/pcm_drm_eld.c b/sound/core/pcm_drm_eld.c
> new file mode 100644
> index ..47d9b60435fe
> --- /dev/null
> +++ b/sound/core/pcm_drm_eld.c
> @@ -0,0 +1,92 @@
> +/*
> + *  PCM DRM helpers
> + *
> + *   This program is free software; you can redistribute it and/or modify
> + *   it under the terms of the GNU General Public License version 2 as
> + *   published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const unsigned int eld_rates[] = {
> + 32000,
> + 44100,
> + 48000,
> + 88200,
> + 96000,
> + 176400,
> + 192000,
> +};
> +
> +static int eld_limit_rates(struct snd_pcm_hw_params *params,
> +struct snd_pcm_hw_rule *rule)
> +{
> + struct snd_interval *r = hw_param_interval(params, rule->var);
> + struct snd_interval *c;
> + unsigned int rate_mask = 7, i;
> + const u8 *sad, *eld = rule->private;
> +
> + sad = drm_eld_sad(eld);
> + if (sad) {
> + c = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS);
> +
> + for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) {
> + unsigned channels = 1 + (sad[0] & 7);
> +
> + /*
> +  * Exclude SADs which do not include the
> +  * requested number of channels.
> +  */
> + if (c->min <= channels)
> + rate_mask |= sad[1];
> + }
> +printk("%s: r %d-%d c %d-%d m %x\n", __func__, r->min, r->max, c->min, 
> c->max, rate_mask);

I guess this will be removed in the final version? ;)

> + }
> +
> + return snd_interval_list(r, ARRAY_SIZE(eld_rates), eld_rates,
> +  rate_mask);
> +}
> +
> +static int eld_limit_channels(struct snd_pcm_hw_params *params,
> +   struct snd_pcm_hw_rule *rule)
> +{
> + struct snd_interval *var = hw_param_interval(params, rule->var);
> + struct snd_interval t = { .min = 1, .max = 2, .integer = 1, };
> + unsigned int i;
> + const u8 *sad, *eld = rule->private;
> +
> + sad = drm_eld_sad(eld);
> + if (sad) {
> + for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) {
> + switch (sad[0] & 0x78) {
> + case 0x08:
> + t.max = max(t.max, (sad[0] & 7) + 1u);
> + break;

What about the minimal channel?

Ideally, we should either give a list of channel numbers or process
the hw_constraints dynamically to narrow the min/max matching with the
eld.


thanks,

Takashi

> + }
> + }
> + }
> +
> + return snd_interval_refine(var, );
> +}
> +
> +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld)
> +{
> + int ret;
> +
> + ret = snd_pcm_hw_rule_add(runtime, 0, 

[PATCH 3/3] drm/exynos: mixer: add 2x scaling to mixer_graph_buffer

[Emil Velikov]

Hi Tobias,

On 1 April 2015 at 14:29, Tobias Jakobi  
wrote:
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 5ab0e32..6822b36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c

> @@ -528,9 +552,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
> int win)
> fmt = ARGB;
> }
>
> -   /* 2x scaling feature */
> -   x_ratio = 0;
> -   y_ratio = 0;
> +   /* check if mixer supports requested scaling setup */
> +   if (mixer_setup_scale(plane, _ratio, _ratio)) return;
>
Having return on the same line as the if statement will make
checkpatch.pl unhappy :-(

Cheers
Emil

[PATCH RFC v2 10/13] sound/core: add DRM ELD helper

[Russell King - ARM Linux]

On Sun, Apr 05, 2015 at 05:57:09PM +0200, Takashi Iwai wrote:
> > diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h
> > new file mode 100644
> > index ..93357b25d2e2
> > --- /dev/null
> > +++ b/include/sound/pcm_drm_eld.h
> > @@ -0,0 +1,6 @@
> > +#ifndef __SOUND_PCM_DRM_ELD_H
> > +#define __SOUND_PCM_DRM_ELD_H
> > +
> > +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld);
> > +
> > +#endif
> 
> IMO, a single line of function declaration can be merged to
> sound/pcm.h.

Ok.

> > diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> > index 313f22e9d929..b534c8a6046b 100644
> > --- a/sound/core/Kconfig
> > +++ b/sound/core/Kconfig
> > @@ -6,6 +6,9 @@ config SND_PCM
> > tristate
> > select SND_TIMER
> >  
> > +config SND_PCM_ELD
> > +   bool
> 
> I don't mind much adding this one, but a new Kconfig is always a
> question.  I'd like to hear other's opinion, too.

That's more a question whether you want it always included in the build
or not, especially as it is dependent on DRM header files.

> > +printk("%s: r %d-%d c %d-%d m %x\n", __func__, r->min, r->max, c->min, 
> > c->max, rate_mask);
> 
> I guess this will be removed in the final version? ;)

Of course.

> > +static int eld_limit_channels(struct snd_pcm_hw_params *params,
> > + struct snd_pcm_hw_rule *rule)
> > +{
> > +   struct snd_interval *var = hw_param_interval(params, rule->var);
> > +   struct snd_interval t = { .min = 1, .max = 2, .integer = 1, };
> > +   unsigned int i;
> > +   const u8 *sad, *eld = rule->private;
> > +
> > +   sad = drm_eld_sad(eld);
> > +   if (sad) {
> > +   for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) {
> > +   switch (sad[0] & 0x78) {
> > +   case 0x08:
> > +   t.max = max(t.max, (sad[0] & 7) + 1u);
> > +   break;
> 
> What about the minimal channel?

There isn't a minimum.  The SAD describes only the _maximum_ number of
channels.  For example, if a TV supports 5.1 audio, at 32, 44.1 and 48
kHz, it can do that with just one SAD entry which indicates support for
six channels of audio at those sample rates.  However, it will happily
accept 2 channel audio at those sample rates too.

> Ideally, we should either give a list of channel numbers or process
> the hw_constraints dynamically to narrow the min/max matching with the
> eld.

The ELD can change as a result of the HDMI sink deciding to change its
EDID (it does happen) or if the device is unplugged and re-plugged.  If
I wanted to restrict the maximum channel/rates by building some sort of
table, I'd do this at open time and avoid the complexity of having rule
callbacks.

Since (afaik) ALSA has a lack of support for dynamic reconfiguration
according to the attached device changing, the best we can do without
a huge amount of re-work of HDMI support across all adapters is to
process the capabilities of the attached device at prepare time
according to the current capabilities.

Implementing dynamic reconfiguration in ALSA is not something I want to
get involved with, and as we /already/ have HDMI support merged in the
kernel, this is not a blocker for at least trying to get some semblence
of sanity, rather than having every driver re-implementing stuff like
this.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/2] drm: Shortcircuit vblank queries

[Chris Wilson]

Bypass all the spinlocks and return the last timestamp and counter from
the last vblank if the driver delcares that it is accurate (and stable
across on/off), and the vblank is currently enabled.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Cc: Laurent Pinchart 
Cc: Dave Airlie ,
Cc: Mario Kleiner 
---
 drivers/gpu/drm/drm_irq.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index ba80b51b4b00..be9c210bb22e 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1538,6 +1538,17 @@ err_put:
return ret;
 }

+static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
+{
+   if (vblwait->request.sequence)
+   return false;
+
+   return _DRM_VBLANK_RELATIVE ==
+   (vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
+ _DRM_VBLANK_EVENT |
+ _DRM_VBLANK_NEXTONMISS));
+}
+
 /*
  * Wait for VBLANK.
  *
@@ -1587,6 +1598,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,

vblank = >vblank[crtc];

+   /* If the counter is currently enabled and accurate, short-circuit 
queries
+* to return the cached timestamp of the last vblank.
+*/
+   if (dev->vblank_disable_immediate &&
+   drm_wait_vblank_is_query(vblwait) &&
+   vblank->enabled) {
+   struct timeval now;
+
+   vblwait->reply.sequence =
+   drm_vblank_count_and_time(dev, crtc, );
+   vblwait->reply.tval_sec = now.tv_sec;
+   vblwait->reply.tval_usec = now.tv_usec;
+   return 0;
+   }
+
ret = drm_vblank_get(dev, crtc);
if (ret) {
DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
-- 
2.1.4

[PATCH 1/2] drm: Shortcircuit vblank queries

[Chris Wilson]

Avoid adding to the waitqueue and reprobing the current vblank if the
caller is only querying the current vblank sequence and timestamp and
so we would return immediately.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Cc: Laurent Pinchart 
Cc: Dave Airlie ,
Cc: Mario Kleiner 
---
 drivers/gpu/drm/drm_irq.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 6f5dc18779e2..ba80b51b4b00 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1617,14 +1617,16 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
vblwait->request.sequence = seq + 1;
}

-   DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
- vblwait->request.sequence, crtc);
-   vblank->last_wait = vblwait->request.sequence;
-   DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
-   (((drm_vblank_count(dev, crtc) -
-  vblwait->request.sequence) <= (1 << 23)) ||
-!vblank->enabled ||
-!dev->irq_enabled));
+   if (vblwait->request.sequence != seq) {
+   DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
+ vblwait->request.sequence, crtc);
+   vblank->last_wait = vblwait->request.sequence;
+   DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
+   (((drm_vblank_count(dev, crtc) -
+  vblwait->request.sequence) <= (1 << 23)) ||
+!vblank->enabled ||
+!dev->irq_enabled));
+   }

if (ret != -EINTR) {
struct timeval now;
-- 
2.1.4

[PATCH libdrm v2 02/19] radeon: move bof.[ch] out of libdrm_radeon

[Emil Velikov]

The functions(files) are used if one explicitly modifies radeon_cs_gem.c
by setting CS_BOF_DUMP to 1. As bof.[ch] is used (copied) to other
out-of-tree projects, keep them around in the distribution tarball.

Cc: Jerome Glisse 
Signed-off-by: Emil Velikov 
---

This will essentially replaces patches 02-07 (inclusive) and bof.[ch]
will be left unchanged :-)

Cheers
Emil
---
 radeon/Makefile.am  | 2 +-
 radeon/Makefile.sources | 8 +---
 radeon/radeon_cs_gem.c  | 5 -
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/radeon/Makefile.am b/radeon/Makefile.am
index 5cca394..1e4c869 100644
--- a/radeon/Makefile.am
+++ b/radeon/Makefile.am
@@ -44,4 +44,4 @@ libdrm_radeoninclude_HEADERS = $(LIBDRM_RADEON_H_FILES)
 pkgconfigdir = @pkgconfigdir@
 pkgconfig_DATA = libdrm_radeon.pc

-EXTRA_DIST = Android.mk
+EXTRA_DIST = Android.mk $(LIBDRM_RADEON_BOF_FILES)
diff --git a/radeon/Makefile.sources b/radeon/Makefile.sources
index a17701a..1cf482a 100644
--- a/radeon/Makefile.sources
+++ b/radeon/Makefile.sources
@@ -4,9 +4,7 @@ LIBDRM_RADEON_FILES := \
radeon_cs_space.c \
radeon_bo.c \
radeon_cs.c \
-   radeon_surface.c \
-   bof.c \
-   bof.h
+   radeon_surface.c

 LIBDRM_RADEON_H_FILES := \
radeon_bo.h \
@@ -17,3 +15,7 @@ LIBDRM_RADEON_H_FILES := \
radeon_bo_int.h \
radeon_cs_int.h \
r600_pci_ids.h
+
+LIBDRM_RADEON_BOF_FILES := \
+   bof.c \
+   bof.h
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 705ee05..81b3184 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -48,9 +48,12 @@
 #include "xf86drm.h"
 #include "xf86atomic.h"
 #include "radeon_drm.h"
-#include "bof.h"

+/* Add LIBDRM_RADEON_BOF_FILES to libdrm_radeon_la_SOURCES when building with 
BOF_DUMP */
 #define CS_BOF_DUMP 0
+#if CS_BOF_DUMP
+#include "bof.h"
+#endif

 struct radeon_cs_manager_gem {
 struct radeon_cs_managerbase;
-- 
2.3.1

[Bug 89906] Account request for DRM

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

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

--- Comment #2 from Emil Velikov  ---
Hi Lucas,

Contributing to any drm kernel driver does not require you to have an account
at fd.o. Patches are submitted to the mailing list, people review them and
maintainers pick them off there. One could use github/bitbucket/fd.o/etc if
they want to, but that won't provide much added benefit.

-Emil

P.S. I'm not a member of the fd.o admin team, but a fellow contributor.

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

Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

On 1 April 2015 at 15:42,   wrote:
>
> Sorry, went to drafts and not to send...
>
 - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
 cruft for which, I would like to think, there are no more users.

 Obviously the latter can be confirmed by Randy and friends.
>>>
>>>
>>>   I'm somewhat confused by this statement, as I still see the use of
>>> struct drm_map, as is it's usage in the Solaris ports of drm.  Am I
>>> missing something (like I said, I still have a ways to go to get to any
>>> decent level of contribution)?
>>>
>> Can you relate Solaris ports of drm to the linux one in a sentence ? Or
>> if there is a public repo somewhere that would be great.
>
>
>   We may not be as behind as you might have believed, but we are not as
> close as I would like either.
>
>   In that sentance: we have an i915 KMS driver with a decent amount of
> feature set (reasonable Haswell and DRI/DRM that would support that chipset)
> to the end of 2013 (when we had a significant amount of help from Intel),
> but we have a way too much Solaris-centric port than I would have preferred.
>
>   The public repo (Mercurial based) is at:
>
> https://hg.java.net/hg/solaris-x11~x-s12-clone/
>
> The kernel driver source specifically at:
>
> https://hg.java.net/hg/solaris-x11~x-s12-clone/file/tip/open-src/kernel
>
> Note that the move of KMS drivers to this repo is recent, so there is little
> history of their evolution.
>
Right, so things are a few newer than I thought, but still a bit off
from upstream drm. Not too shocking though considering the amount of
work that goes in there ;-) The thing that struck me is that every drm
driver comes with its own version of core drm. Not critisizing, just a
bit unusual.

>>
>> Guessing that "legacy" is the keyword here - it refers to old drm
>> drivers that do user mode-setting - UMS, amongst other nasty stuff.
>> Based on the latest kernel sources the ioctls (and the struct) are
>> considered as legacy, that plus the lack of any users (very quick grep)
>> seems rather conclusive.
>
>
>   AFAICT, we aren't that bad.  And where we divert is probably more driven
> by our lack of knowlege at the time than the ability to properly converge,
> but I have lots of ground to cover before I can properly resolve the
> differences.
>
Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
not all places are updated/ported to KMS ? Not a big deal though.

>>
>> If you guys are still using legacy drm drivers (for whatever reason)
>> that would be rather unfortunate. Otherwise you should be able to kill
>> off the remaining users of struct drm_map/drmMapBufs/drmRmMap.
>>
>
>   For the most part, I have no problem with killing off any legacy layers
> that should go, as we will catch up (we do have the ability to at least
> offer a working frozen solution in the intrim).  At least in the near term,
> there are bodies actively working on getting the above driver source in sync
> with what the community has.
>
Great - glad to hear. Meanwhile I've noticed a few workarounds for
libdrm in the hg repo:
 - Force use of GCC and GNU make.
 - Disabled tests.

If you can provide some more information that would be appreciated.
Wouldn't mind squashing some bugs :-)

>>
>> Cheers,
>> Emil
>>
>
>   Ditto!
>
>   Randy
> (enjoying a bit of downtime a couple thousand miles from home)
>
Sweet, enjoy the break.

Thanks
Emil

of_parse_phandle: "could not find phandle"

[Steve Longerbeam]

Hi all,

If --strip-disabled option is passed to dtc, of_parse_phandle() emits
this error message for disabled nodes.

For example, imx_drm_platform_probe() will generate the messages
when it walks the list of endpoints to display bridge nodes that have
been left disabled for a particular target.

Given that there can now be missing phandles in a dtb due to --strip-disabled
option, and the use of the option would be the only reason there would be a
missing phandle in a successfully compiled dtb AFAIK, should this error
message be converted to pr_debug()?

Thanks,
Steve

[Bug 89909] [radeonsi][bisected] Cities: Skylines black rooftops

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

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

John Brooks  changed:

   What|Removed |Added

Summary|Cities: Skylines black  |[radeonsi][bisected]
   |rooftops|Cities: Skylines black
   ||rooftops

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

[Bug 89909] Cities: Skylines black rooftops

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

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

Bug ID: 89909
   Summary: Cities: Skylines black rooftops
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: john at fastquake.com
QA Contact: dri-devel at lists.freedesktop.org

Here's a screenshot of the bug:

http://i.imgur.com/DLp1dFr.png

I'm running an AMD R9 290 on Linux Mint 17.1, with kernel 4.0-rc5. I have
bisected mesa commits and found commit f9fd0c4a55afd97fd34d0e846000c75f5f6ecac2
(http://cgit.freedesktop.org/mesa/mesa/commit/?id=f9fd0c4a55afd97fd34d0e846000c75f5f6ecac2)
to be the culprit. Mesa was compiled with llvm 3.6 from the Ubuntu
repositories.

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

of_parse_phandle: "could not find phandle"

[Steve Longerbeam]

Hi all,

If --strip-disabled option is passed to dtc, of_parse_phandle() emits
this error message for disabled nodes.

For example, imx_drm_platform_probe() will generate the messages
when it walks the list of endpoints to display bridge nodes that have
been left disabled for a particular target.

Given that it is normal for their to be missing phandles in a dtb due
to --strip-disabled option, should this error message be converted
to pr_debug()?

Steve

[PATCH] xf86drmMode.h: inline -> __inline for use with gcc -std=c89 -pedantic

[Emil Velikov]

On 25 March 2015 at 01:01, Daniel Kurtz  wrote:
> Unfortunately, there are some users of libdrm installed headers that like
> to be built with -std=c89 -pedantic, which does not like "inline".
>
> However, __inline works.
>
Pushed to master. Thanks !

-Emil

[PATCH] xf86drm: Fix ioctl struct clearing in drmAgpEnable

[Emil Velikov]

On 24 March 2015 at 17:53, Connor Behan  wrote:
> This one is a bit harder to notice.
>
> Signed-off-by: Connor Behan 
Thanks for the patch Connor. Just pushed it to master.

-Emil

[PATCH 11/16] drm/msm/dp: fix error return code

[Julia Lawall]

Return a negative error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
when != 
*if(...)
{
  ... when != ret = e2
  when forall
 return ret;
}
// 

Signed-off-by: Julia Lawall 

---
 drivers/gpu/drm/msm/edp/edp_ctrl.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c 
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 0ec5abd..29e52d7 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -1149,12 +1149,13 @@ int msm_edp_ctrl_init(struct msm_edp *edp)
ctrl->aux = msm_edp_aux_init(dev, ctrl->base, >drm_aux);
if (!ctrl->aux || !ctrl->drm_aux) {
pr_err("%s:failed to init aux\n", __func__);
-   return ret;
+   return -ENOMEM;
}

ctrl->phy = msm_edp_phy_init(dev, ctrl->base);
if (!ctrl->phy) {
pr_err("%s:failed to init phy\n", __func__);
+   ret = -ENOMEM;
goto err_destory_aux;
}

[PATCH 0/16] fix error return code

[Julia Lawall]

The complate semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@ok exists@
identifier f,ret,i;
expression e;
constant c;
@@

// identify a function that returns a negative return value at least once.
f(...) {
... when any
(
return -c at i;
|
ret = -c at i;
... when != ret = e
return ret;
|
if (ret < 0) { ... return ret; }
)
... when any
}

@r exists@
identifier ret,ok.f,fn;
expression e1,e2,e3,e4,e5,e6,x;
statement S,S1;
position p1,p2,p3;
@@

// identify a case where the return variable is set to a non-negative value
// and then returned in error-handling code
f(...) {
... when any
(
if at p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret at p1 = 0
)
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when != 
when any
(
 if (<+... ret = e5 ...+>) S1
|
 if (<+...  ...+>) S1
|
if at p2(<+...x = fn(...)...+>)
 {
  ... when != ret = e6
  when forall
 return at p3 ret;
}
|
break;
|
x = fn(...)
... when != \(ret = e4\|ret++\|ret--\|ret+=e4\|ret-=e4\)
when != 
(
 if (<+... ret = e3 ...+>) S
|
 if (<+...  ...+>) S
|
if at p2(<+...\(x != 0\|x < 0\|x == NULL\|IS_ERR(x)\)...+>)
 {
  ... when != ret = e2
  when forall
 return at p3 ret;
}
)
)
... when any
}

@printer depends on r@
position p;
identifier ok.f,pr;
constant char [] c;
@@

f(...) { <...pr at p(...,c,...)...> }

@bad0 exists@
identifier r.ret,ok.f,g != {ERR_PTR,IS_ERR};
position p != printer.p;
@@

f(...) { ... when any
g at p(...,ret,...)
... when any
 }

@bad depends on !bad0 exists@
position r.p1,r.p2;
statement S1,S2;
identifier r.ret;
expression e1;
@@

// ignore the above if there is some path where the variable is set to
// something else
(
if at p1 (\(ret < 0\|ret != 0\)) S1
|
ret at p1 = 0
)
... when any
 \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\|\)
... when any
if at p2(...) S2

@bad1 depends on !bad0 && !bad exists@
position r.p2;
statement S2;
identifier r.ret;
expression e1;
constant c;
@@

ret = -c
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when != 
when any
if at p2(...) S2

@bad2 depends on !bad0 && !bad && !bad1 exists@
position r.p1,r.p2;
identifier r.ret;
expression e1;
statement S2;
constant c;
@@

// likewise ignore it if there has been an intervening return
ret at p1 = 0
... when != if (...) { ... ret = e1 ... return ret; }
when != if (...) { ... return -c; }
when any
if at p2(...) S2

@script:python depends on !bad0 && !bad && !bad1 && !bad2@
p1 << r.p1;
p2 << r.p2;
p3 << r.p3;
@@

cocci.print_main("",p1)
cocci.print_secs("",p2)
cocci.print_secs("",p3)
// 

Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[ran...@sibernet.com]

On Sun, 5 Apr 2015, Emil Velikov wrote:

>> Note that the move of KMS drivers to this repo is recent, so there is little
>> history of their evolution.
>>
> Right, so things are a few newer than I thought, but still a bit off
> from upstream drm. Not too shocking though considering the amount of
> work that goes in there ;-)

   It is a bit overwhelming, so I (currently) tend to scan this list 
irregularly, and look for some source snapshot for porting reference.


> The thing that struck me is that every drm driver comes with its own 
> version of core drm. Not critisizing, just a bit unusual.

   So technically, only one driver has it's own version, and that is mostly 
driven by a lack of hardware to verify it continues to work as drm changes 
(and is slated for removal as the hardware is obsolete and unavailable).

   With (currently) only one other drm driver, it would appear that the drm 
core is unique to it (and to some extent it is), but the evolution would 
be to be towards a common drm.


>>
>>   AFAICT, we aren't that bad.  And where we divert is probably more driven
>> by our lack of knowlege at the time than the ability to properly converge,
>> but I have lots of ground to cover before I can properly resolve the
>> differences.
>>
> Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
> not all places are updated/ported to KMS ? Not a big deal though.
>

   We're hopeful that this will change in the near future (we have someone 
working on a radeon KMS port, which is expected to use a common drm).


>>
>>   For the most part, I have no problem with killing off any legacy layers
>> that should go, as we will catch up (we do have the ability to at least
>> offer a working frozen solution in the intrim).  At least in the near term,
>> there are bodies actively working on getting the above driver source in sync
>> with what the community has.
>>
> Great - glad to hear. Meanwhile I've noticed a few workarounds for
> libdrm in the hg repo:
> - Force use of GCC and GNU make.
> - Disabled tests.
>
> If you can provide some more information that would be appreciated.
> Wouldn't mind squashing some bugs :-)

   Niveditha might be a better person to answer these questions as she has 
more history with libdrm.  I've only recently become aware of the tests, 
but hoping to somehow make use of them.

   I'm happy also to squash bugs as well, and also hoping to offer patches 
in the next couple of months (might need some help or understanding for 
those first few).


>>
>>   Randy
>> (enjoying a bit of downtime a couple thousand miles from home)
>>
> Sweet, enjoy the break.
>

   It was sort of part work, part relax and nice to get away, but now back 
to reality.


 Randy

[PATCH] drm/msm: fix build warning - missing prototype

[Nicholas Mc Guire]

On Sat, 04 Apr 2015, Rob Clark wrote:

> On Fri, Apr 3, 2015 at 10:39 PM, Nicholas Mc Guire  
> wrote:
> > fix build warning when building edp/edp_aux.o due to missing
> > prototype for edp_aux_transfer.
> >
> > Signed-off-by: Nicholas Mc Guire 
> > ---
> > building drivers/gpu/drm/msm/msm.ko gives the following warning:
> > drivers/gpu/drm/msm/edp/edp_aux.c:118:9: warning: no previous prototype for 
> > 'edp_aux_transfer' [-Wmissing-prototypes]
> >  ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct drm_dp_aux_msg 
> > *msg)
> >  ^
> >
> 
> thx.. fwiw, looks like edp_aux_transfer is only used in that one
> file.. so probably it actually wants to be static instead..
>
yup - missed that - making it static is the cleaner solution 
will resend.

thx!
hofrat