date:20150817

Make it a generic function independent of the device info.

Signed-off-by: Jammy Zhou 
Reviewed-by: Christian KÃ¶nig 
---
 amdgpu/amdgpu_vamgr.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index cc4a1c4..71fd2b1 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -46,11 +46,12 @@ int amdgpu_va_range_query(amdgpu_device_handle dev,
return -EINVAL;
 }

-static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, struct 
amdgpu_device *dev)
+static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t start,
+ uint64_t max, uint64_t alignment)
 {
-   mgr->va_offset = dev->dev_info.virtual_address_offset;
-   mgr->va_max = dev->dev_info.virtual_address_max;
-   mgr->va_alignment = dev->dev_info.virtual_address_alignment;
+   mgr->va_offset = start;
+   mgr->va_max = max;
+   mgr->va_alignment = alignment;

list_inithead(&mgr->va_holes);
pthread_mutex_init(&mgr->bo_va_mutex, NULL);
@@ -72,7 +73,9 @@ drm_private struct amdgpu_bo_va_mgr * 
amdgpu_vamgr_get_global(struct amdgpu_devi
ref = atomic_inc_return(&vamgr.refcount);

if (ref == 1)
-   amdgpu_vamgr_init(&vamgr, dev);
+   amdgpu_vamgr_init(&vamgr, dev->dev_info.virtual_address_offset,
+ dev->dev_info.virtual_address_max,
+ dev->dev_info.virtual_address_alignment);
return &vamgr;
 }

-- 
1.9.1

[PATCH 1/4] drm: add interface to get drm devices on the system v3

From: Emil Velikov 

For mutiple GPU support, the devices on the system should be enumerated
to get necessary information about each device, and the drmGetDevices
interface is added for this. Currently only PCI devices are supported for
the enumeration.

Typical usage:
int count;
drmDevicePtr *foo;
count = drmGetDevices(NULL, 0);
foo = calloc(count, sizeof(drmDevicePtr));
count = drmGetDevices(foo, count);
/* find proper device, open correct device node, etc */
drmFreeDevices(foo, count);
free(foo);

v2: change according to feedback from Emil
v3: fix the signed extension for PCI device info

Signed-off-by: Jammy Zhou 
---
 xf86drm.c | 351 ++
 xf86drm.h |  34 ++
 2 files changed, 385 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index 5e02969..7d9e5f9 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -55,6 +55,7 @@
 #ifdef HAVE_SYS_MKDEV_H
 # include  /* defines major(), minor(), and makedev() on Solaris 
*/
 #endif
+#include 

 /* Not all systems have MAP_FAILED defined */
 #ifndef MAP_FAILED
@@ -2829,3 +2830,353 @@ char *drmGetRenderDeviceNameFromFd(int fd)
 {
return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
 }
+
+#ifdef __linux__
+static int drmParseSubsystemType(const char *str)
+{
+char link[PATH_MAX + 1] = "";
+char *name;
+
+if (readlink(str, link, PATH_MAX) < 0)
+return -EINVAL;
+
+name = strrchr(link, '/');
+if (!name)
+return -EINVAL;
+
+name++;
+
+if (strncmp(name, "pci", 3) == 0)
+return DRM_BUS_PCI;
+
+return -EINVAL;
+}
+
+static int drmParsePciBusInfo(const char *str, drmPciBusInfoPtr info)
+{
+int domain, bus, dev, func;
+char *value;
+
+if (str == NULL)
+return -EINVAL;
+
+value = strstr(str, "PCI_SLOT_NAME=");
+if (value == NULL)
+return -EINVAL;
+
+value += strlen("PCI_SLOT_NAME=");
+
+if (sscanf(value, "%04x:%02x:%02x.%1u",
+   &domain, &bus, &dev, &func) != 4)
+return -EINVAL;
+
+info->domain = domain;
+info->bus = bus;
+info->dev = dev;
+info->func = func;
+
+return 0;
+}
+
+static int drmSameDevice(drmDevicePtr a, drmDevicePtr b)
+{
+if (a->bustype != b->bustype)
+return 0;
+
+switch (a->bustype) {
+case DRM_BUS_PCI:
+if (memcmp(a->businfo.pci, b->businfo.pci, sizeof(drmPciBusInfo)) == 0)
+return 1;
+default:
+break;
+}
+
+return 0;
+}
+
+static int drmGetNodeType(const char *name)
+{
+if (strncmp(name, DRM_PRIMARY_MINOR_NAME,
+sizeof(DRM_PRIMARY_MINOR_NAME) - 1) == 0)
+return DRM_NODE_PRIMARY;
+
+if (strncmp(name, DRM_CONTROL_MINOR_NAME,
+sizeof(DRM_CONTROL_MINOR_NAME ) - 1) == 0)
+return DRM_NODE_CONTROL;
+
+if (strncmp(name, DRM_RENDER_MINOR_NAME,
+sizeof(DRM_RENDER_MINOR_NAME) - 1) == 0)
+return DRM_NODE_RENDER;
+
+return -EINVAL;
+}
+
+static int drmParsePciDeviceInfo(const unsigned char *config,
+ drmPciDeviceInfoPtr device)
+{
+if (config == NULL)
+return -EINVAL;
+
+device->vendor_id = config[0] | (config[1] << 8);
+device->device_id = config[2] | (config[3] << 8);
+device->revision_id = config[8];
+device->subvendor_id = config[44] | (config[45] << 8);
+device->subdevice_id = config[46] | (config[47] << 8);
+
+return 0;
+}
+
+static void drmFreeDevice(drmDevicePtr device)
+{
+int i;
+
+if (device == NULL)
+return;
+
+if (device->nodes != NULL)
+for (i = 0; i < DRM_NODE_MAX; i++)
+free(device->nodes[i]);
+
+free(device->nodes);
+free(device->businfo.pci);
+free(device->deviceinfo.pci);
+}
+
+void drmFreeDevices(drmDevicePtr devices[], int count)
+{
+int i;
+
+if (devices == NULL)
+return;
+
+for (i = 0; i < count; i++) {
+drmFreeDevice(devices[i]);
+free(devices[i]);
+devices[i] = NULL;
+}
+}
+
+/**
+ * Get drm devices on the system
+ *
+ * \param devices the array of devices with drmDevicePtr elements
+ *can be NULL to get the device number first
+ * \param max_devices the maximum number of devices for the array
+ *
+ * \return on error - negative error code,
+ * if devices is NULL - total number of devices available on the 
system,
+ * alternatively the number of devices stored in devices[], which is
+ * capped by the max_devices.
+ */
+int drmGetDevices(drmDevicePtr devices[], int max_devices)
+{
+drmDevicePtr devs = NULL;
+drmPciBusInfoPtr pcibus = NULL;
+drmPciDeviceInfoPtr pcidevice = NULL;
+DIR *sysdir = NULL;
+struct dirent *dent = NULL;
+struct stat sbuf = {0};
+char node[PATH_MAX + 1] = "";
+char path[PATH_MAX + 1] = "";
+char data[128] = "";
+unsigned char config[64] = "";
+int node_type, subsystem_type;
+int maj, min;
+int fd;
+int ret, i = 0, j, node_count, device_count = 0;
+

[PATCH 3/4] amdgpu: add flag to support 32bit VA address v4

The AMDGPU_VA_RANGE_32_BIT flag is added to request VA range in the
32bit address space for amdgpu_va_range_alloc.

The 32bit address space is reserved at initialization time, and managed
with a separate VAMGR as part of the global VAMGR. And if no enough VA
space available in range above 4GB, this reserved range can be used as
fallback.

v2: add comment for AMDGPU_VA_RANGE_32_BIT, and add vamgr to va_range
v3: rebase to Emil's drm_private series
v4: fix one warning

Signed-off-by: Jammy Zhou 
Reviewed-by: Christian KÃ¶nig 
---
 amdgpu/amdgpu.h  |  5 +
 amdgpu/amdgpu_device.c   | 20 
 amdgpu/amdgpu_internal.h |  9 +
 amdgpu/amdgpu_vamgr.c| 32 +---
 4 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index a90c1ac..1e633e3 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1075,6 +1075,11 @@ int amdgpu_read_mm_registers(amdgpu_device_handle dev, 
unsigned dword_offset,
 uint32_t *values);

 /**
+ * Flag to request VA address range in the 32bit address space
+*/
+#define AMDGPU_VA_RANGE_32_BIT 0x1
+
+/**
  * Allocate virtual address range
  *
  * \param dev - [in] Device handle. See #amdgpu_device_initialize()
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index b977847..0ef1d31 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -44,6 +44,7 @@
 #include "amdgpu_drm.h"
 #include "amdgpu_internal.h"
 #include "util_hash_table.h"
+#include "util_math.h"

 #define PTR_TO_UINT(x) ((unsigned)((intptr_t)(x)))
 #define UINT_TO_PTR(x) ((void *)((intptr_t)(x)))
@@ -174,6 +175,7 @@ int amdgpu_device_initialize(int fd,
int flag_auth = 0;
int flag_authexist=0;
uint32_t accel_working = 0;
+   uint64_t start, max;

*device_handle = NULL;

@@ -252,6 +254,19 @@ int amdgpu_device_initialize(int fd,

dev->vamgr = amdgpu_vamgr_get_global(dev);

+   max = MIN2(dev->dev_info.virtual_address_max, 0x);
+   start = amdgpu_vamgr_find_va(dev->vamgr,
+max - dev->dev_info.virtual_address_offset,
+dev->dev_info.virtual_address_alignment, 
0);
+   if (start > 0x)
+   goto free_va; /* shouldn't get here */
+
+   dev->vamgr_32 =  calloc(1, sizeof(struct amdgpu_bo_va_mgr));
+   if (dev->vamgr_32 == NULL)
+   goto free_va;
+   amdgpu_vamgr_init(dev->vamgr_32, start, max,
+ dev->dev_info.virtual_address_alignment);
+
*major_version = dev->major_version;
*minor_version = dev->minor_version;
*device_handle = dev;
@@ -260,6 +275,11 @@ int amdgpu_device_initialize(int fd,

return 0;

+free_va:
+   r = -ENOMEM;
+   amdgpu_vamgr_free_va(dev->vamgr, start,
+max - dev->dev_info.virtual_address_offset);
+
 cleanup:
if (dev->fd >= 0)
close(dev->fd);
diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
index 92eb5ec..ca155be 100644
--- a/amdgpu/amdgpu_internal.h
+++ b/amdgpu/amdgpu_internal.h
@@ -65,6 +65,7 @@ struct amdgpu_va {
uint64_t address;
uint64_t size;
enum amdgpu_gpu_va_range range;
+   struct amdgpu_bo_va_mgr *vamgr;
 };

 struct amdgpu_device {
@@ -82,7 +83,10 @@ struct amdgpu_device {
pthread_mutex_t bo_table_mutex;
struct drm_amdgpu_info_device dev_info;
struct amdgpu_gpu_info info;
+   /** The global VA manager for the whole virtual address space */
struct amdgpu_bo_va_mgr *vamgr;
+   /** The VA manager for the 32bit address space */
+   struct amdgpu_bo_va_mgr *vamgr_32;
 };

 struct amdgpu_bo {
@@ -124,6 +128,11 @@ drm_private struct amdgpu_bo_va_mgr* 
amdgpu_vamgr_get_global(struct amdgpu_devic

 drm_private void amdgpu_vamgr_reference(struct amdgpu_bo_va_mgr **dst, struct 
amdgpu_bo_va_mgr *src);

+drm_private void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t 
start,
+  uint64_t max, uint64_t alignment);
+
+drm_private void amdgpu_vamgr_deinit(struct amdgpu_bo_va_mgr *mgr);
+
 drm_private uint64_t amdgpu_vamgr_find_va(struct amdgpu_bo_va_mgr *mgr, 
uint64_t size,
uint64_t alignment, uint64_t base_required);

diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 71fd2b1..698826d 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -46,7 +46,7 @@ int amdgpu_va_range_query(amdgpu_device_handle dev,
return -EINVAL;
 }

-static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t start,
+drm_private void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t 
start,
  uint64_t max, uint64_t alignment)
 {
mgr->va_offset = start;
@@ -57,7 +57,7 @@ static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, 
uint64_t start,
pthread_mutex

[PATCH 4/4] amdgpu: make vamgr per device v2

Each device can have its own vamgr, so make it per device now.
This can fix the failure with multiple GPUs used in one single
process.

v2: rebase

Signed-off-by: Jammy Zhou 
Reviewed-by: Christian KÃ¶nig 
---
 amdgpu/amdgpu_device.c   | 13 +++--
 amdgpu/amdgpu_internal.h |  5 -
 amdgpu/amdgpu_vamgr.c| 24 +---
 3 files changed, 12 insertions(+), 30 deletions(-)

diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 0ef1d31..d5f65e5 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -131,7 +131,8 @@ static int amdgpu_get_auth(int fd, int *auth)

 static void amdgpu_device_free_internal(amdgpu_device_handle dev)
 {
-   amdgpu_vamgr_reference(&dev->vamgr, NULL);
+   amdgpu_vamgr_deinit(dev->vamgr);
+   free(dev->vamgr);
util_hash_table_destroy(dev->bo_flink_names);
util_hash_table_destroy(dev->bo_handles);
pthread_mutex_destroy(&dev->bo_table_mutex);
@@ -252,7 +253,13 @@ int amdgpu_device_initialize(int fd,
if (r)
goto cleanup;

-   dev->vamgr = amdgpu_vamgr_get_global(dev);
+   dev->vamgr = calloc(1, sizeof(struct amdgpu_bo_va_mgr));
+   if (dev->vamgr == NULL)
+   goto cleanup;
+
+   amdgpu_vamgr_init(dev->vamgr, dev->dev_info.virtual_address_offset,
+ dev->dev_info.virtual_address_max,
+ dev->dev_info.virtual_address_alignment);

max = MIN2(dev->dev_info.virtual_address_max, 0x);
start = amdgpu_vamgr_find_va(dev->vamgr,
@@ -279,6 +286,8 @@ free_va:
r = -ENOMEM;
amdgpu_vamgr_free_va(dev->vamgr, start,
 max - dev->dev_info.virtual_address_offset);
+   amdgpu_vamgr_deinit(dev->vamgr);
+   free(dev->vamgr);

 cleanup:
if (dev->fd >= 0)
diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
index ca155be..cb06dbf 100644
--- a/amdgpu/amdgpu_internal.h
+++ b/amdgpu/amdgpu_internal.h
@@ -51,7 +51,6 @@ struct amdgpu_bo_va_hole {
 };

 struct amdgpu_bo_va_mgr {
-   atomic_t refcount;
/* the start virtual address */
uint64_t va_offset;
uint64_t va_max;
@@ -124,10 +123,6 @@ struct amdgpu_context {

 drm_private void amdgpu_bo_free_internal(amdgpu_bo_handle bo);

-drm_private struct amdgpu_bo_va_mgr* amdgpu_vamgr_get_global(struct 
amdgpu_device *dev);
-
-drm_private void amdgpu_vamgr_reference(struct amdgpu_bo_va_mgr **dst, struct 
amdgpu_bo_va_mgr *src);
-
 drm_private void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t 
start,
   uint64_t max, uint64_t alignment);

diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 698826d..659e6c8 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -33,8 +33,6 @@
 #include "amdgpu_internal.h"
 #include "util_math.h"

-static struct amdgpu_bo_va_mgr vamgr = {{0}};
-
 int amdgpu_va_range_query(amdgpu_device_handle dev,
  enum amdgpu_gpu_va_range type, uint64_t *start, 
uint64_t *end)
 {
@@ -67,26 +65,6 @@ drm_private void amdgpu_vamgr_deinit(struct amdgpu_bo_va_mgr 
*mgr)
pthread_mutex_destroy(&mgr->bo_va_mutex);
 }

-drm_private struct amdgpu_bo_va_mgr * amdgpu_vamgr_get_global(struct 
amdgpu_device *dev)
-{
-   int ref;
-   ref = atomic_inc_return(&vamgr.refcount);
-
-   if (ref == 1)
-   amdgpu_vamgr_init(&vamgr, dev->dev_info.virtual_address_offset,
- dev->dev_info.virtual_address_max,
- dev->dev_info.virtual_address_alignment);
-   return &vamgr;
-}
-
-drm_private void amdgpu_vamgr_reference(struct amdgpu_bo_va_mgr **dst,
-   struct amdgpu_bo_va_mgr *src)
-{
-   if (update_references(&(*dst)->refcount, NULL))
-   amdgpu_vamgr_deinit(*dst);
-   *dst = src;
-}
-
 drm_private uint64_t amdgpu_vamgr_find_va(struct amdgpu_bo_va_mgr *mgr, 
uint64_t size,
uint64_t alignment, uint64_t base_required)
 {
@@ -102,7 +80,7 @@ drm_private uint64_t amdgpu_vamgr_find_va(struct 
amdgpu_bo_va_mgr *mgr, uint64_t
pthread_mutex_lock(&mgr->bo_va_mutex);
/* TODO: using more appropriate way to track the holes */
/* first look for a hole */
-   LIST_FOR_EACH_ENTRY_SAFE(hole, n, &vamgr.va_holes, list) {
+   LIST_FOR_EACH_ENTRY_SAFE(hole, n, &mgr->va_holes, list) {
if (base_required) {
if(hole->offset > base_required ||
(hole->offset + hole->size) < (base_required + 
size))
-- 
1.9.1

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

2015-08-17 Thread Stephen Rothwell

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/intel_atomic.c
  drivers/gpu/drm/i915/intel_display.c

between commits:

  f0fdc55db0c6 ("drm/i915: calculate primary visibility changes instead of 
calling from set_config")
  d2944cf21305 ("drm/i915: Commit planes on each crtc separately.")

from the drm-intel-fixes tree and commit:

  74c090b1bdc5 ("drm/i915: Use full atomic modeset.")

and maybe others from the drm tree.

I fixed it up (both these former commits are based on commits in the
latter tree, so I just used the latter tree versions) and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

[PATCH 08/14] drm/exynos: create a fake mmap offset with gem creation

2015-08-17 Thread Joonyoung Shim

On 08/16/2015 01:50 PM, Inki Dae wrote:
> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
>> not, it will call drm_gem_create_mmap_offset whenever user requests
>> DRM_IOCTL_MODE_MAP_DUMB ioctl.
> 
> This patch makes drm_gem_create_mmap_offset to be called even in case of
> not using dumb* interfaces. I.e.,
> exynos_drm_gem_create_ioctl -> exynos_drm_gem_mmap
> 

I know mmap() of exynos-drm also needs mmap offset in drm_gem_mmap().

> And drm_gem_create_mmap_offset checks if vma_node was already allocated
> or not so this patch doesn't make sense.
> 

OK, but it calls drm_gem_create_mmap_offset still and will be returned
after checking node->allocated. It's not unnecessary to me.

> Thanks,
> Inki Dae
> 
>>
>> Signed-off-by: Joonyoung Shim 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 550d267..c76aa8a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -151,6 +151,13 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct 
>> drm_device *dev,
>>  return ERR_PTR(ret);
>>  }
>>  
>> +ret = drm_gem_create_mmap_offset(obj);
>> +if (ret < 0) {
>> +drm_gem_object_release(obj);
>> +kfree(exynos_gem_obj);
>> +return ERR_PTR(ret);
>> +}
>> +
>>  DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
>>  
>>  return exynos_gem_obj;
>> @@ -521,14 +528,9 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
>> *file_priv,
>>  goto unlock;
>>  }
>>  
>> -ret = drm_gem_create_mmap_offset(obj);
>> -if (ret)
>> -goto out;
>> -
>>  *offset = drm_vma_node_offset_addr(&obj->vma_node);
>>  DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);
>>  
>> -out:
>>  drm_gem_object_unreference(obj);
>>  unlock:
>>  mutex_unlock(&dev->struct_mutex);
>>
> 
>

[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()

2015-08-17 Thread Joonyoung Shim

On 08/16/2015 02:07 PM, Inki Dae wrote:
> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>> The drm_gem_object_release() function already performs this cleanup,
>> so there is no reason to do it explicitly.
>>
>> Signed-off-by: Joonyoung Shim 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index c76aa8a..ab7d029 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -100,8 +100,6 @@ out:
>>  exynos_drm_fini_buf(obj->dev, buf);
>>  exynos_gem_obj->buffer = NULL;
>>  
>> -drm_gem_free_mmap_offset(obj);
>> -
>>  /* release file pointer to gem object. */
>>  drm_gem_object_release(obj);
>>  
>> @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
>> vm_area_struct *vma)
>>  
>>  err_close_vm:
>>  drm_gem_vm_close(vma);
>> -drm_gem_free_mmap_offset(obj);
> 
> Without previous patch, drm_gem_free_mmap_offset is required. I guess
> the reason you removed above line is that you thought
> drm_gem_object_release function would be called by drm_gem_vm_close
> function which drops a reference of the gem object.
> 
> However, drm_gem_vm_close should be a pair with drm_gem_vm_open
> function. These will be called whenever a process opens or closes the
> VMA. So the reference count of the gem object had already been taken by
> open operation when a new reference to the VMA had been created.
> 

This changes is not related with drm_gem_vm_close and prior patch. Why
should free mmap offset when mmap operation is failed? The mmap offset
can be used repeatedly.

drm-next amdgpu warning

2015-08-17 Thread Dave Airlie

Hey Alex,

this seems valid,

/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:
In function âamdgpu_uvd_cs_pass2â:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:491:17:
warning: âmin_ctx_sizeâ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  buf_sizes[0x4] = min_ctx_size;
 ^
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:377:58:
note: âmin_ctx_sizeâ was declared here
  unsigned image_size, tmp, min_dpb_size, num_dpb_buffer, min_ctx_size;
  ^
Dave.

[PULL] Add Freescale DCU DRM driver

2015-08-17 Thread Dave Airlie

On 31 July 2015 at 12:55, Jianwei Wang  wrote:
> Hi Dave,
>
> This is the pull request for Freescale DCU DRM driver.
>
Hi,

Thierry pulled the panel stuff already, so can you rebase this on
drm-next to drop that patch?

Dave.

>
> The following changes since commit dcd14dd957f02ef679c61325a2221a0574bdcab3:
>
>   Merge tag 'topic/connector-locking-2015-07-23' of
> git://anongit.freedesktop.org/drm-intel into drm-next (2015-07-24
> 14:30:29 +1000)
>
> are available in the git repository at:
>
>   https://github.com/Jianwei-Wang/linux-drm-fsl-dcu.git drm-next-fsl-dcu
>
> for you to fetch changes up to 0a16af5a9d87785f99ee5efdb04d88536e3e9d96:
>
>   MAINTAINERS: add Freescale DCU DRM driver maintainer (2015-07-29
> 16:01:58 +0800)
>
> 
> Jianwei Wang (4):
>   drm/layerscape: Add Freescale DCU DRM driver
>   devicetree: Add NEC to the vendor-prefix list
>   drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel
>   MAINTAINERS: add Freescale DCU DRM driver maintainer
>
>  Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt |   7 ++
>  Documentation/devicetree/bindings/vendor-prefixes.txt  |   1 +
>  Documentation/devicetree/bindings/video/fsl,dcu.txt|  22 
>  MAINTAINERS|   9 ++
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/fsl-dcu/Kconfig|  18 
>  drivers/gpu/drm/fsl-dcu/Makefile   |   7 ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 208
> 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h |  19 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 404
> +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 197
> ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c|  23 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  43 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h   |  33 ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 261
> 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h|  17 +++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  | 182
> +++
>  drivers/gpu/drm/panel/panel-simple.c   |  26 +
>  19 files changed, 1480 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
>  create mode 100644 Documentation/devicetree/bindings/video/fsl,dcu.txt
>  create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig
>  create mode 100644 drivers/gpu/drm/fsl-dcu/Makefile
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC v3 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On 08/14/15 12:57, Russell King - ARM Linux wrote:
> On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
>> +static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
>> +struct snd_pcm_hw_params *params,
>> +struct snd_soc_dai *dai)
>> +{
>> +struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
>> +struct hdmi_codec_params hp = {
>> +.cea = { 0 },
>
> Unnecessary initialisation - because you are initialising this structure,
> all unnamed fields will be zeroed.
>

True, I just tried to be explicit.

>> +.iec = {
>> +.status = {
>> +IEC958_AES0_CON_NOT_COPYRIGHT,
>> +IEC958_AES1_CON_GENERAL,
>> +IEC958_AES2_CON_SOURCE_UNSPEC,
>> +IEC958_AES3_CON_CLOCK_VARIABLE,
>> +},
>
> ...
>
>> +hdmi_audio_infoframe_init(&hp.cea);
>> +hp.cea.coding_type = HDMI_AUDIO_CODING_TYPE_PCM;
>
> Something tells me here that you haven't read the HDMI specification.
> HDMI says that the coding type will be zero (refer to stream header).
> The same goes for much of the CEA audio infoframe.  Please see the
> Audio InfoFrame details in the HDMI specification.
>

Must admit, that I have not read it end to end. Obviously I have missed 
a relevant piece of information here. I'll fix that and check the 
related items too.

>> +hp.cea.channels = params_channels(params);
>> +
>> +switch (params_width(params)) {
>> +case 16:
>> +hp.iec.status[4] |= IEC958_AES4_CON_WORDLEN_20_16;
>> +hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_16;
>> +break;
>> +case 18:
>> +hp.iec.status[4] |= IEC958_AES4_CON_WORDLEN_22_18;
>> +hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_20;
>> +break;
>> +case 20:
>> +hp.iec.status[4] |= IEC958_AES4_CON_WORDLEN_24_20;
>> +hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_20;
>> +break;
>> +case 24:
>> +case 32:
>> +hp.iec.status[4] |= IEC958_AES4_CON_MAX_WORDLEN_24 |
>> +IEC958_AES4_CON_WORDLEN_24_20;
>
> Why not use the generic code to generate the AES channel status bits?
> See sound/core/pcm_iec958.c.
>

Thanks, I did not know that exist. I'll make use of that.

Best regards,
Jyri

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-08-17 Thread Jani Nikula

On Fri, 14 Aug 2015, Rafael Antognolli  wrote:
> On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
>> On Wed, 12 Aug 2015, Thierry Reding  wrote:
>> > From: Thierry Reding 
>> >
>> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
>> > seq_file and can be used to make the DPCD available via debugfs for
>> > example.
>> 
>> See i915/i915_debugfs.c for one DPCD dump implementation.
>> 
>> Around the time that was added, there was also some discussion (and
>> patches [1]) to expose a read/write debugfs interface to DPCD, letting
>> userspace access arbitrary DPCD registers.
>> 
>> Just this week there was some discussion about revisiting that. It was
>> about accessing some proprietary panel features, but there's also the
>> ease of debugging without having to keep updating the kernel to dump
>> more.
>> 
>> I think it would be great to agree on a common debugfs interface to
>> access DPCD arbitrarily. Last time I checked, the blocker to that was
>> access to the aux channel from generic code; it's always driver
>> specific. SMOP. ;)
>
> Do you mean it would require the generic code/interface to somehow route
> this to the driver specific code? I am not sure yet how this works (if
> there's something like it around), but I'll take a look.

Drivers can choose to support DP AUX any way they like, and they don't
have to use the common helpers to do so. It's pretty much an
implementation detail. I think we could require the use of the common
helpers to support generic DPCD access from debugfs, but we'd still have
to come up with a way to get hold of struct drm_dp_aux (again, driver
internals) given a drm_connector in generic debugfs code.

Thierry, do you see any problems with having a connector function to get
hold of its drm_dp_aux?

>> I could put some effort into this (maybe Rafael too?), as long as we
>> could agree on the interface. As I wrote in the referenced thread, I
>> wasn't thrilled about what was proposed.
>> 
>
> Yes, I'm willing to put effort into this, for sure. Any help pointing to
> which direction to follow is greatly appreciated.

Great!

BR,
Jani.


>
> Thanks,
> Rafael
>
>> 
>> 
>> [1] http://mid.gmane.org/1428493301-20293-1-git-send-email-durgadoss.r at 
>> intel.com
>> 
>> 
>> 
>> >
>> > Signed-off-by: Thierry Reding 
>> > ---
>> >  drivers/gpu/drm/drm_dp_helper.c | 146 
>> > 
>> >  include/drm/drm_dp_helper.h |   2 +
>> >  2 files changed, 148 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> > b/drivers/gpu/drm/drm_dp_helper.c
>> > index 8968201ea93c..ea74884c9cb3 100644
>> > --- a/drivers/gpu/drm/drm_dp_helper.c
>> > +++ b/drivers/gpu/drm/drm_dp_helper.c
>> > @@ -27,6 +27,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >  
>> > @@ -292,6 +293,151 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux 
>> > *aux,
>> >  }
>> >  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>> >  
>> > +/**
>> > + * drm_dp_dpcd_dump() - dump DPCD content
>> > + * @aux: DisplayPort AUX channel
>> > + * @s: destination for DPCD dump
>> > + *
>> > + * Reads registers from the DPCD via a DisplayPort AUX channel and dumps 
>> > them
>> > + * to a seq_file.
>> > + */
>> > +void drm_dp_dpcd_dump(struct drm_dp_aux *aux, struct seq_file *s)
>> > +{
>> > +#define DUMP_REG(aux, offset) ({  \
>> > +  u8 value;   \
>> > +  int err;\
>> > +  err = drm_dp_dpcd_readb(aux, offset, &value);   \
>> > +  if (err < 0) {  \
>> > +  dev_err((aux)->dev, "failed to read %s: %d\n",  \
>> > +  #offset, err);  \
>> > +  return; \
>> > +  }   \
>> > +  seq_printf(s, "%-35s 0x%04x 0x%02x\n", #offset, offset, \
>> > + value);  \
>> > +  })
>> > +
>> > +  DUMP_REG(aux, DP_DPCD_REV);
>> > +  DUMP_REG(aux, DP_MAX_LINK_RATE);
>> > +  DUMP_REG(aux, DP_MAX_LANE_COUNT);
>> > +  DUMP_REG(aux, DP_MAX_DOWNSPREAD);
>> > +  DUMP_REG(aux, DP_NORP);
>> > +  DUMP_REG(aux, DP_DOWNSTREAMPORT_PRESENT);
>> > +  DUMP_REG(aux, DP_MAIN_LINK_CHANNEL_CODING);
>> > +  DUMP_REG(aux, DP_DOWN_STREAM_PORT_COUNT);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_0_CAP_0);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_0_BUFFER_SIZE);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_1_CAP_0);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_1_BUFFER_SIZE);
>> > +  DUMP_REG(aux, DP_I2C_SPEED_CAP);
>> > +  DUMP_REG(aux, DP_EDP_CONFIGURATION_CAP);
>> > +  DUMP_REG(aux, DP_TRAINING_AUX_RD_INTERVAL);
>> > +  DUMP_REG(aux, DP_ADAPTER_CAP);
>> > +  DUMP_REG(aux, DP_SUPPORTED_LINK_RATES);
>> > +  DUMP_REG(aux, DP_FAUX_CAP);
>>

[PATCH RFC v3 2/7] ASoC: hdmi: Remove obsolete dummy HDMI codec

On 08/14/15 19:10, Mark Brown wrote:
> On Fri, Aug 14, 2015 at 12:30:40PM +0300, Jyri Sarha wrote:
>> The hdmi stub codec has not been used since refactoring of OMAP HDMI
>> audio support.
>
> grep tells me that the OMAP HDMI4 and HDMI5 drivers are still
> registering this device in -next...
>

Really? My source trees for mainline and linux-next look like this:

$ git grep "hdmi-audio-codec"
sound/soc/codecs/hdmi.c:#define DRV_NAME "hdmi-audio-codec"

Don't you mean "omap-hdmi-audio", that is implemented in 
sound/soc/omap/omap-hdmi-audio.c ?

That driver is bit different. It implements ASoC card and uses generic 
dummy codec. The "hdmi-audio-codec" has not been used for OMAP HDMI 
audio for several releases already.

Best regards,
Jyri

[PATCH] drm/atmel-hlcdc: Compile suspend/resume for PM_SLEEP only

2015-08-17 Thread Boris Brezillon

On Fri, 14 Aug 2015 13:58:20 +0200
Thierry Reding  wrote:

> From: Thierry Reding 
> 
> If PM is enabled but PM_SLEEP is disabled, the suspend/resume functions
> are still unused and produce a compiler warning.
> 
> Signed-off-by: Thierry Reding 

Acked-by: Boris Brezillon 

Thanks,

Boris

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index b6bc5cb9b9ee..303ae68f983d 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -561,7 +561,7 @@ static int atmel_hlcdc_dc_drm_remove(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
>  static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
>  {
>   struct drm_device *drm_dev = dev_get_drvdata(dev);



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH RFC v3 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On 08/14/15 19:18, Mark Brown wrote:
> On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
>
>> +struct hdmi_codec_ops {
>> +/* For runtime clock configuration from ASoC machine driver.
>> + * A direct forward from set_sysclk in struct snd_soc_dai_ops.
>> + * Optional */
>> +int (*set_clk)(struct device *dev, int clk_id, int freq);
>
> I'd be much happier if we were using the clock API as the external
> interface here, it's where we want to be internally too and it's going
> to be easier to not introduce any external dependencies on the ASoC
> internal stuff.
>

Sounds better. I'll change that.

>> +/* Called when ASoC starts an audio stream setup. The call
>> + * provides an audio abort callback for stoping an ongoing
>> + * stream if the HDMI audio becomes unavailable.
>> + * Optional */
>> +int (*audio_startup)(struct device *dev,
>> + void (*abort_cb)(struct device *dev));
>
> I'm a bit confused about what is going to use abort_cb() and why they
> wouldn't just call shutdown instead?
>

audio_shutdown() is for ASoC side to tell video side that audio playback 
has stopped.

The abort_cb() is for video side to inform ASoC that current audio 
stream can not continue anymore and it should be aborted. The similar 
mechanism is currently in use in sound/soc/omap/omap-hdmi-audio.c.

>> +/* HDMI codec initalization data */
>> +struct hdmi_codec_pdata {
>> +struct device *dev; /* The HDMI encoder registering the codec */
>
> Shouldn't this just be dev->parent?
>
>> +enum {
>> +DAI_ID_I2C = 0,
>> +DAI_ID_SPDIF,
>> +};
>
> I2C?  :P
>

Right, should be I2S. Thanks!

Best regards,
Jyri

[Bug 102931] Radeon : EDID Reading Incorrectly

2015-08-17 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #3 from Maxqia  ---
Created attachment 185121
  --> https://bugzilla.kernel.org/attachment.cgi?id=185121&action=edit
get-edid | parse-edid output

According to the read-edid website and the program output, get-edid uses the
i2c bus.

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

[PATCH RFC v3 6/7] drm/i2c: tda998x: Register ASoC HDMI codec for audio functionality

On 08/14/15 13:06, Russell King - ARM Linux wrote:
> On Fri, Aug 14, 2015 at 12:30:44PM +0300, Jyri Sarha wrote:
>> +static int tda998x_write_aif(struct tda998x_priv *priv,
>> + struct hdmi_audio_infoframe *cea)
>> +{
>> +uint8_t buf[HDMI_INFOFRAME_SIZE(AUDIO)];
>> +int len;
>> +
>> +len = hdmi_audio_infoframe_pack(cea, buf, sizeof(buf));
>> +if (len < 0) {
>> +dev_err(&priv->hdmi->dev,
>> +"Failed to pack audio infoframe: %d\n", len);
>> +return len;
>> +}
>> +
>> +/* Write the audio information packet */
>> +tda998x_write_if(priv, DIP_IF_FLAGS_IF4, REG_IF4_HB0, buf, len);
>> +return 0;
>> +}
>> +
>
> I have such a function already queued up, but I can't push it out at the
> moment because of too many conflicts across all my DRM work.  I'm waiting
> for after 4.3-rc1 before publishing anything from or accepting anything
> else into DRM branches.
>

Ok, is the code available some where? Could take a look so I can align 
my code to that.

>>   static void
>>   tda998x_write_avi(struct tda998x_priv *priv, struct drm_display_mode *mode)
>>   {
>> @@ -670,19 +691,24 @@ static void tda998x_audio_mute(struct tda998x_priv 
>> *priv, bool on)
>>  }
>>   }
>>
>> -static void
>> +static int
>>   tda998x_configure_audio(struct tda998x_priv *priv,
>> -struct drm_display_mode *mode, struct tda998x_encoder_params *p)
>> +int mode_clock,
>> +int ena_ap,
>> +int dai_format,
>> +int sample_width,
>> +int sample_rate,
>> +const u8 *status)
>
> I don't think this is an improvement.
>

Still it makes the function more generic and enables its usage in 
HDMI-codec API implementation. I'll try to make it look tidier.

>> +static int tda998x_audio_get_eld(struct device *dev, uint8_t *buf, size_t 
>> len)
>> +{
>> +struct tda998x_priv *priv = dev_get_drvdata(dev);
>> +struct drm_mode_config *config = &priv->encoder->dev->mode_config;
>> +struct drm_connector *connector;
>> +int ret = -ENODEV;
>> +
>> +mutex_lock(&config.mutex);
>> +list_for_each_entry(connector, &config->connector_list, head) {
>> +if (priv->encoder == connector->encoder) {
>> +memcpy(buf, connector->eld,
>> +   min(sizeof(connector->eld), len));
>> +ret = 0;
>> +}
>> +}
>> +mutex_unlock(&config.mutex);
>
> Obviously untested.  Should be config->mutex.
>

Sorry. Should never do these last minute changes. I must have been 
compiling and testing different code version. I first had this function 
using config->connection_mutex, but then - after reading the eld related 
code - found that mode_config mutex should be used instead.

> But in any case, when I kill the DRM slave encoder code in here, this
> becomes unnecessary.
>

Ok, The information from ELD needs be passed to audio side constraints 
somehow. I'd love to see the code you have in queue.

Best regards,
Jyri

[PATCH 08/14] drm/exynos: create a fake mmap offset with gem creation

2015-08-17 Thread Inki Dae

On 2015ë 08ì 17ì¼ 14:29, Joonyoung Shim wrote:
> On 08/16/2015 01:50 PM, Inki Dae wrote:
>> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>>> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
>>> not, it will call drm_gem_create_mmap_offset whenever user requests
>>> DRM_IOCTL_MODE_MAP_DUMB ioctl.
>>
>> This patch makes drm_gem_create_mmap_offset to be called even in case of
>> not using dumb* interfaces. I.e.,
>> exynos_drm_gem_create_ioctl -> exynos_drm_gem_mmap
>>
> 
> I know mmap() of exynos-drm also needs mmap offset in drm_gem_mmap().

Ah, sorry. We already removed Exynos specific mmap ioctl. So we could
never use direct mapping ioctl anymore. I confused that.

> 
>> And drm_gem_create_mmap_offset checks if vma_node was already allocated
>> or not so this patch doesn't make sense.
>>
> 
> OK, but it calls drm_gem_create_mmap_offset still and will be returned
> after checking node->allocated. It's not unnecessary to me.
> 
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Joonyoung Shim 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
>>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index 550d267..c76aa8a 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -151,6 +151,13 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct 
>>> drm_device *dev,
>>> return ERR_PTR(ret);
>>> }
>>>  
>>> +   ret = drm_gem_create_mmap_offset(obj);
>>> +   if (ret < 0) {
>>> +   drm_gem_object_release(obj);
>>> +   kfree(exynos_gem_obj);
>>> +   return ERR_PTR(ret);
>>> +   }
>>> +
>>> DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
>>>  
>>> return exynos_gem_obj;
>>> @@ -521,14 +528,9 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
>>> *file_priv,
>>> goto unlock;
>>> }
>>>  
>>> -   ret = drm_gem_create_mmap_offset(obj);
>>> -   if (ret)
>>> -   goto out;
>>> -
>>> *offset = drm_vma_node_offset_addr(&obj->vma_node);
>>> DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);
>>>  
>>> -out:
>>> drm_gem_object_unreference(obj);
>>>  unlock:
>>> mutex_unlock(&dev->struct_mutex);
>>>
>>
>>
> 
>

[PATCH RFC 1/5] drm/edid: Add support to get edid early

2015-08-17 Thread Jani Nikula

On Fri, 14 Aug 2015, Srinivas Kandagatla  
wrote:
> This patch adds support to get edid way early before the connector is
> created, this is mainly used for panel drivers to auto-probe the panel
> based on the vendor and product id from EDID.
>
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/gpu/drm/drm_edid.c | 8 
>  include/drm/drm_crtc.h | 1 +
>  2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7087da3..30359cd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1388,6 +1388,14 @@ struct edid *drm_get_edid(struct drm_connector 
> *connector,
>  }
>  EXPORT_SYMBOL(drm_get_edid);
>  
> +struct edid *drm_get_edid_early(struct i2c_adapter *adapter)
> +{
> + struct drm_connector dummy_connector;
> +
> + return drm_get_edid(&dummy_connector, adapter);

This will oops the kernel on bad EDID.

BR,
Jani.


> +}
> +EXPORT_SYMBOL(drm_get_edid_early);
> +
>  /**
>   * drm_edid_duplicate - duplicate an EDID and the extensions
>   * @edid: EDID to duplicate
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 57ca8cc..35d8763 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1330,6 +1330,7 @@ extern void drm_reinit_primary_mode_group(struct 
> drm_device *dev);
>  extern bool drm_probe_ddc(struct i2c_adapter *adapter);
>  extern struct edid *drm_get_edid(struct drm_connector *connector,
>struct i2c_adapter *adapter);
> +extern struct edid *drm_get_edid_early(struct i2c_adapter *adapter);
>  extern struct edid *drm_edid_duplicate(const struct edid *edid);
>  extern int drm_add_edid_modes(struct drm_connector *connector, struct edid 
> *edid);
>  extern void drm_mode_config_init(struct drm_device *dev);
> -- 
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()

2015-08-17 Thread Inki Dae

On 2015ë 08ì 17ì¼ 14:29, Joonyoung Shim wrote:
> On 08/16/2015 02:07 PM, Inki Dae wrote:
>> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>>> The drm_gem_object_release() function already performs this cleanup,
>>> so there is no reason to do it explicitly.
>>>
>>> Signed-off-by: Joonyoung Shim 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index c76aa8a..ab7d029 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -100,8 +100,6 @@ out:
>>> exynos_drm_fini_buf(obj->dev, buf);
>>> exynos_gem_obj->buffer = NULL;
>>>  
>>> -   drm_gem_free_mmap_offset(obj);
>>> -
>>> /* release file pointer to gem object. */
>>> drm_gem_object_release(obj);
>>>  
>>> @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
>>> vm_area_struct *vma)
>>>  
>>>  err_close_vm:
>>> drm_gem_vm_close(vma);
>>> -   drm_gem_free_mmap_offset(obj);
>>
>> Without previous patch, drm_gem_free_mmap_offset is required. I guess
>> the reason you removed above line is that you thought
>> drm_gem_object_release function would be called by drm_gem_vm_close
>> function which drops a reference of the gem object.
>>
>> However, drm_gem_vm_close should be a pair with drm_gem_vm_open
>> function. These will be called whenever a process opens or closes the
>> VMA. So the reference count of the gem object had already been taken by
>> open operation when a new reference to the VMA had been created.
>>
> 
> This changes is not related with drm_gem_vm_close and prior patch. Why
> should free mmap offset when mmap operation is failed? The mmap offset
> can be used repeatedly.

Isn't vm space of vm manager still used even if any user-space process
doesn't use the region? And if mmap is failed, then the user-space
process will be terminated. Do you think it can be re-tried? However,
mmap system call never return -EAGAIN. Is it reasonable to you? I cannot
understand how the mmap offset can be re-used. So can you show me some
example?

>

[PATCH RFC v3 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

Missed one commet first time around...

On 08/14/15 19:18, Mark Brown wrote:
> On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
...
>> +/* HDMI codec initalization data */
>> +struct hdmi_codec_pdata {
>> +struct device *dev; /* The HDMI encoder registering the codec */
>
> Shouldn't this just be dev->parent?
>

No. The HDMI encoder device is the parent for HDMI-codec.

The patch you took in in the last round uses the ASoC component drivers 
parent's of-node if the component driver does not have one itself. In 
this case the phandle in the binding points to the HDMI encoder's node, 
which is the parent of the HDMI codec.

Best regards,
Jyri

[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()

2015-08-17 Thread Joonyoung Shim

On 08/17/2015 04:52 PM, Inki Dae wrote:
> On 2015ë 08ì 17ì¼ 14:29, Joonyoung Shim wrote:
>> On 08/16/2015 02:07 PM, Inki Dae wrote:
>>> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote:
 The drm_gem_object_release() function already performs this cleanup,
 so there is no reason to do it explicitly.

 Signed-off-by: Joonyoung Shim 
 ---
  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
  1 file changed, 3 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
 b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 index c76aa8a..ab7d029 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 @@ -100,8 +100,6 @@ out:
exynos_drm_fini_buf(obj->dev, buf);
exynos_gem_obj->buffer = NULL;
  
 -  drm_gem_free_mmap_offset(obj);
 -
/* release file pointer to gem object. */
drm_gem_object_release(obj);
  
 @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
 vm_area_struct *vma)
  
  err_close_vm:
drm_gem_vm_close(vma);
 -  drm_gem_free_mmap_offset(obj);
>>>
>>> Without previous patch, drm_gem_free_mmap_offset is required. I guess
>>> the reason you removed above line is that you thought
>>> drm_gem_object_release function would be called by drm_gem_vm_close
>>> function which drops a reference of the gem object.
>>>
>>> However, drm_gem_vm_close should be a pair with drm_gem_vm_open
>>> function. These will be called whenever a process opens or closes the
>>> VMA. So the reference count of the gem object had already been taken by
>>> open operation when a new reference to the VMA had been created.
>>>
>>
>> This changes is not related with drm_gem_vm_close and prior patch. Why
>> should free mmap offset when mmap operation is failed? The mmap offset
>> can be used repeatedly.
> 
> Isn't vm space of vm manager still used even if any user-space process
> doesn't use the region? And if mmap is failed, then the user-space
> process will be terminated. Do you think it can be re-tried? However,
> mmap system call never return -EAGAIN. Is it reasonable to you? I cannot
> understand how the mmap offset can be re-used. So can you show me some
> example?
> 

Currently, mmap offset of exynos-drm gem is made by 
DRM_IOCTL_MODE_MAP_DUMB ioctl and mmap() ioctl just uses the mmap 
offset. User will use same mmap offset about same gem. It's why mmap
offset made by DRM_IOCTL_MODE_MAP_DUMB ioctl is unnecessary, it's just
enough to make mmap offset from when gem is create. You can get a
reference from drm_gem_cma_helper.c file.

[PATCH RFC v2 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On 08/14/15 22:25, Mark Brown wrote:
> On Tue, May 26, 2015 at 09:59:07PM +0300, Jyri Sarha wrote:
>
>> +
>> +mutex_lock(&hcp->current_stream_lock);
>> +if (hcp->current_stream && hcp->current_stream->runtime &&
>> +snd_pcm_running(hcp->current_stream)) {
>> +dev_info(dev, "HDMI audio playback aborted\n");
>
> Does this really need to be dev_info()?
>

No, I'll change that to debug level.

>> +if (hcp->hcd.ops->get_eld) {
>> +hcp->eld = hcp->hcd.ops->get_eld(hcp->hcd.dev);
>> +
>> +/* Call snd_pcm_hw_constraint_eld here */
>> +}
>
> ...
>
>> +dev_dbg(dai->dev, "%s()\n", __func__);
>> +
>> +mutex_lock(&hcp->current_stream_lock);
>> +BUG_ON(hcp->current_stream != substream);
>> +hcp->current_stream = NULL;
>> +mutex_unlock(&hcp->current_stream_lock);
>> +
>> +hcp->hcd.ops->audio_shutdown(hcp->hcd.dev);
>
> Shouldn't the callback be in or before the lock?  Otherwise we could
> potentially race with starting a new stream.
>

Yes, it should be before it. I'll fix that.

If it is inside, there is a "possible deadlock" warning (atleast in the 
similar place in omap-hdmi-audio there was) if those warnings are turned 
on and there is another lock that is taken in the video side callbacks.

Thanks,
Jyri

[Bug 102401] Radeon Displayport Audio Warping

2015-08-17 Thread bugzilla-dae...@bugzilla.kernel.org

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

Maxqia  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Maxqia  ---
Replacing drm_detect_monitor_audio(radeon_connector_edid(connector)) with true
seems to fix the problem.

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

[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()

2015-08-17 Thread Inki Dae

On 2015ë 08ì 17ì¼ 17:17, Joonyoung Shim wrote:
> On 08/17/2015 04:52 PM, Inki Dae wrote:
>> On 2015ë 08ì 17ì¼ 14:29, Joonyoung Shim wrote:
>>> On 08/16/2015 02:07 PM, Inki Dae wrote:
 On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> The drm_gem_object_release() function already performs this cleanup,
> so there is no reason to do it explicitly.
>
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index c76aa8a..ab7d029 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -100,8 +100,6 @@ out:
>   exynos_drm_fini_buf(obj->dev, buf);
>   exynos_gem_obj->buffer = NULL;
>  
> - drm_gem_free_mmap_offset(obj);
> -
>   /* release file pointer to gem object. */
>   drm_gem_object_release(obj);
>  
> @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>  
>  err_close_vm:
>   drm_gem_vm_close(vma);
> - drm_gem_free_mmap_offset(obj);

 Without previous patch, drm_gem_free_mmap_offset is required. I guess
 the reason you removed above line is that you thought
 drm_gem_object_release function would be called by drm_gem_vm_close
 function which drops a reference of the gem object.

 However, drm_gem_vm_close should be a pair with drm_gem_vm_open
 function. These will be called whenever a process opens or closes the
 VMA. So the reference count of the gem object had already been taken by
 open operation when a new reference to the VMA had been created.

>>>
>>> This changes is not related with drm_gem_vm_close and prior patch. Why
>>> should free mmap offset when mmap operation is failed? The mmap offset
>>> can be used repeatedly.
>>
>> Isn't vm space of vm manager still used even if any user-space process
>> doesn't use the region? And if mmap is failed, then the user-space
>> process will be terminated. Do you think it can be re-tried? However,
>> mmap system call never return -EAGAIN. Is it reasonable to you? I cannot
>> understand how the mmap offset can be re-used. So can you show me some
>> example?
>>
> 
> Currently, mmap offset of exynos-drm gem is made by 
> DRM_IOCTL_MODE_MAP_DUMB ioctl and mmap() ioctl just uses the mmap 
> offset. User will use same mmap offset about same gem. It's why mmap
> offset made by DRM_IOCTL_MODE_MAP_DUMB ioctl is unnecessary, it's just
> enough to make mmap offset from when gem is create. You can get a
> reference from drm_gem_cma_helper.c file.

Hmm... It's not that the mmap offset can be re-used or not. It's that
the mmap offset should be released or not when mmap failed. As your
original comment, the call of drm_gem_free_mmap_offset() is unnecessary
if mmap offset is created when gem creation because the mmap offset is
removed by drm_gem_object_release() when gem is destroyed - gem should
also be released when mmap failed.

Ok, let's create mmap offset at gem creation and remove it gem
releasing. Will merge these two patches.

Thanks,
Inki Dae

>

[Bug 102931] Radeon : EDID Reading Incorrectly

2015-08-17 Thread bugzilla-dae...@bugzilla.kernel.org

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

Christian KÃ¶nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #4 from Christian KÃ¶nig  ---
get-edid calls into the BIOS directly to access the I2C bus and doesn't uses
the driver. With a kernel driver this is pretty much deprecated and shouldn't
be used any more.

Use the one provided in sysfs instead, try: find /sys -name "edid"

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

[Bug 102931] Radeon : EDID Reading Incorrectly

2015-08-17 Thread bugzilla-dae...@bugzilla.kernel.org

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

Maxqia  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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

[PATCH libdrm 2/2] tests/amdgpu: Remove unused local variable 'i'

2015-08-17 Thread Michel Dänzer

From: Michel DÃ¤nzer 

Signed-off-by: Michel DÃ¤nzer 
---
 tests/amdgpu/vce_tests.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/amdgpu/vce_tests.c b/tests/amdgpu/vce_tests.c
index 0542654..32fc001 100644
--- a/tests/amdgpu/vce_tests.c
+++ b/tests/amdgpu/vce_tests.c
@@ -400,7 +400,7 @@ static void check_result(struct amdgpu_vce_encode *enc)
 static void amdgpu_cs_vce_encode(void)
 {
uint32_t vbuf_size, bs_size = 0x154000, cpb_size;
-   int i, r;
+   int r;

vbuf_size = enc.width * enc.height * 1.5;
cpb_size = vbuf_size * 10;
-- 
2.5.0

[PATCH libdrm 1/2] tests/amdgpu: Include config.h first

2015-08-17 Thread Michel Dänzer

From: Michel DÃ¤nzer 

Fixes build failure on 32-bit because _FILE_OFFSET_BITS wasn't defined to
64.

Signed-off-by: Michel DÃ¤nzer 
---
 tests/amdgpu/amdgpu_test.c | 5 +
 tests/amdgpu/basic_tests.c | 5 +
 tests/amdgpu/bo_tests.c| 5 +
 tests/amdgpu/cs_tests.c| 5 +
 tests/amdgpu/vce_tests.c   | 4 
 5 files changed, 24 insertions(+)

diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index ed27e24..6568990 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -20,6 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
 */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
 #include 
 #include 
 #include 
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 44c6e4d..7874039 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -20,6 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
 */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
 #include 
 #include 
 #include 
diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index e4040d6..993895d 100644
--- a/tests/amdgpu/bo_tests.c
+++ b/tests/amdgpu/bo_tests.c
@@ -20,6 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
 */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
 #include 

 #include "CUnit/Basic.h"
diff --git a/tests/amdgpu/cs_tests.c b/tests/amdgpu/cs_tests.c
index faceb83..416f36b 100644
--- a/tests/amdgpu/cs_tests.c
+++ b/tests/amdgpu/cs_tests.c
@@ -20,6 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
 */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
 #include 

 #include "CUnit/Basic.h"
diff --git a/tests/amdgpu/vce_tests.c b/tests/amdgpu/vce_tests.c
index b549392..0542654 100644
--- a/tests/amdgpu/vce_tests.c
+++ b/tests/amdgpu/vce_tests.c
@@ -21,6 +21,10 @@
  *
 */

+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
 #include 
 #include 

-- 
2.5.0

[PATCH libdrm 1/2] tests/amdgpu: Include config.h first

2015-08-17 Thread Christian König

On 17.08.2015 11:44, Michel DÃ¤nzer wrote:
> From: Michel DÃ¤nzer 
>
> Fixes build failure on 32-bit because _FILE_OFFSET_BITS wasn't defined to
> 64.
>
> Signed-off-by: Michel DÃ¤nzer 

For both Reviewed-by: Christian KÃ¶nig 

> ---
>   tests/amdgpu/amdgpu_test.c | 5 +
>   tests/amdgpu/basic_tests.c | 5 +
>   tests/amdgpu/bo_tests.c| 5 +
>   tests/amdgpu/cs_tests.c| 5 +
>   tests/amdgpu/vce_tests.c   | 4 
>   5 files changed, 24 insertions(+)
>
> diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
> index ed27e24..6568990 100644
> --- a/tests/amdgpu/amdgpu_test.c
> +++ b/tests/amdgpu/amdgpu_test.c
> @@ -20,6 +20,11 @@
>* OTHER DEALINGS IN THE SOFTWARE.
>*
>   */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
>   #include 
>   #include 
>   #include 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 44c6e4d..7874039 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -20,6 +20,11 @@
>* OTHER DEALINGS IN THE SOFTWARE.
>*
>   */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
>   #include 
>   #include 
>   #include 
> diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
> index e4040d6..993895d 100644
> --- a/tests/amdgpu/bo_tests.c
> +++ b/tests/amdgpu/bo_tests.c
> @@ -20,6 +20,11 @@
>* OTHER DEALINGS IN THE SOFTWARE.
>*
>   */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
>   #include 
>   
>   #include "CUnit/Basic.h"
> diff --git a/tests/amdgpu/cs_tests.c b/tests/amdgpu/cs_tests.c
> index faceb83..416f36b 100644
> --- a/tests/amdgpu/cs_tests.c
> +++ b/tests/amdgpu/cs_tests.c
> @@ -20,6 +20,11 @@
>* OTHER DEALINGS IN THE SOFTWARE.
>*
>   */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
>   #include 
>   
>   #include "CUnit/Basic.h"
> diff --git a/tests/amdgpu/vce_tests.c b/tests/amdgpu/vce_tests.c
> index b549392..0542654 100644
> --- a/tests/amdgpu/vce_tests.c
> +++ b/tests/amdgpu/vce_tests.c
> @@ -21,6 +21,10 @@
>*
>   */
>   
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
>   #include 
>   #include 
>

[Bug 91666] build fail with cunit - OK on amd64 - KO for i386

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

Bug ID: 91666
   Summary: build fail with cunit - OK on amd64 - KO for i386
   Product: DRI
   Version: DRI git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: fabio.ped at libero.it

amd64 builds OK:
Full build log:
https://launchpadlibrarian.net/214693325/buildlog_ubuntu-vivid-amd64.libdrm_2.4.63%2Bgit1508171138.f05a74~gd~v_BUILDING.txt.gz

Same source package breaks with i386:
In file included from ../../../amdgpu/amdgpu_internal.h:35:0,
 from ../../../tests/amdgpu/cs_tests.c:32:
../../../libdrm_macros.h: In function 'drm_munmap':
../../../libdrm_macros.h:79:4: error: size of unnamed array is negative
STATIC_ASSERT(LARGE_OFF_T % 2147483629 == 721 &&
^
Full i386 build log:
https://launchpadlibrarian.net/214693090/buildlog_ubuntu-vivid-i386.libdrm_2.4.63%2Bgit1508171138.f05a74~gd~v_BUILDING.txt.gz

-- 
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/20150817/30eeff15/attachment.html>

[Bug 91666] build fail with cunit - OK on amd64 - KO for i386

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

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

--- Comment #1 from Michel DÃ¤nzer  ---
commit 25784d3af2f37d86fb25ee6cfa4afa6f3448af9b
Author: Michel DÃ¤nzer 
Date:   Mon Aug 17 18:41:11 2015 +0900

tests/amdgpu: Include config.h first

-- 
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/20150817/1cef567e/attachment.html>

[PATCH] drm: panel: simple: add QiaoDian qd43003c0-40

On Sat, Aug 01, 2015 at 12:44:31AM +0200, Alexandre Belloni wrote:
> From: Josh Wu 
> 
> The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.
> 
> Timings from the OTA5180A document, ver 0.9, section
> 10.1.1:
>   http://www.orientdisplay.com/pdf/OTA5180A.pdf
> 
> Signed-off-by: Josh Wu 
> Signed-off-by: Alexandre Belloni 
> ---
>  .../devicetree/bindings/panel/qd,qd43003c0-40.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt

You didn't run this through scripts/get_maintainer.pl, did you? It would
also help to use the standard prefix ("drm/panel: ") because I end up
filtering for that occasionally in case somebody didn't Cc me on panel
patches.

I only came across this by accident, and it's going to miss 4.3 now.

Also two comments below...

> diff --git a/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt 
> b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
> new file mode 100644
> index ..900bc6ebeaff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
> @@ -0,0 +1,7 @@
> +QiaoDian XianShi Corporation 4"3 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "qd,qd43003c0-40"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

I don't see a vendor prefix for QiaoDian XianShi Corporation in
Documentation/devicetree/bindings/vendor-prefixes.txt.

> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index f94201b6e882..e688fa545ae3 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -967,6 +967,29 @@ static const struct panel_desc ortustech_com43h4m85ulc = 
> {
>   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>  };
>  
> +static const struct drm_display_mode qd43003c0_40_mode = {
> + .clock = 9000,
> + .hdisplay = 480,
> + .hsync_start = 480 + 8,
> + .hsync_end = 480 + 8 + 4,
> + .htotal = 480 + 8 + 4 + 39,
> + .vdisplay = 272,
> + .vsync_start = 272 + 4,
> + .vsync_end = 272 + 4 + 10,
> + .vtotal = 272 + 4 + 10 + 2,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc qd43003c0_40 = {
> + .modes = &qd43003c0_40_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 95,
> + .height = 53,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> +};

Can you also add .bpc = 8 above so that drivers that don't support the
.bus_format can still support this panel?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/b3aafb8f/attachment-0001.sig>

[PATCH v2.1 1/3] vga_switcheroo: Add support for switching only the DDC

t; +int vga_switcheroo_lock_ddc(struct pci_dev *pdev)
> +{
> + int id;
> +
> + mutex_lock(&vgasr_priv.ddc_lock);
> +
> + if (!vgasr_priv.handler || !vgasr_priv.handler->switch_ddc)
> + return vgasr_priv.old_ddc_owner = -ENODEV;

I find this very hard to read. Can this be split across two lines?

> +
> + id = vgasr_priv.handler->get_client_id(pdev);
> + return vgasr_priv.old_ddc_owner = vgasr_priv.handler->switch_ddc(id);

This too. I also notice that the only place you call this from doesn't
care about the return value, so why even bother returning one?

> +int vga_switcheroo_unlock_ddc(struct pci_dev *pdev)
> +{
> + int ret, id;
> +
> + if (WARN_ON_ONCE(!mutex_is_locked(&vgasr_priv.ddc_lock)))
> + return -EINVAL;
> +
> + if (vgasr_priv.old_ddc_owner < 0) {
> + mutex_unlock(&vgasr_priv.ddc_lock);
> + return -ENODEV;
> + }
> +
> + id = vgasr_priv.handler->get_client_id(pdev);
> + if (vgasr_priv.old_ddc_owner != id)
> + ret = vgasr_priv.handler->switch_ddc(vgasr_priv.old_ddc_owner);
> + else
> + ret = vgasr_priv.old_ddc_owner;
> + mutex_unlock(&vgasr_priv.ddc_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(vga_switcheroo_unlock_ddc);

Same comment about the return value here.

> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index b483abd..62f303f 100644
> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -29,6 +29,7 @@ enum vga_switcheroo_client_id {
>  };
>  
>  struct vga_switcheroo_handler {
> + int (*switch_ddc)(enum vga_switcheroo_client_id id);
>   int (*switchto)(enum vga_switcheroo_client_id id);
>   int (*power_state)(enum vga_switcheroo_client_id id,
>  enum vga_switcheroo_state state);
> @@ -54,6 +55,9 @@ int vga_switcheroo_register_audio_client(struct pci_dev 
> *pdev,
>  void vga_switcheroo_client_fb_set(struct pci_dev *dev,
> struct fb_info *info);
>  
> +int vga_switcheroo_lock_ddc(struct pci_dev *pdev);
> +int vga_switcheroo_unlock_ddc(struct pci_dev *pdev);
> +
>  int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler);
>  void vga_switcheroo_unregister_handler(void);
>  
> @@ -72,6 +76,8 @@ static inline void vga_switcheroo_unregister_client(struct 
> pci_dev *dev) {}
>  static inline int vga_switcheroo_register_client(struct pci_dev *dev,
>   const struct vga_switcheroo_client_ops *ops, bool 
> driver_power_control) { return 0; }
>  static inline void vga_switcheroo_client_fb_set(struct pci_dev *dev, struct 
> fb_info *info) {}
> +static inline int vga_switcheroo_lock_ddc(struct pci_dev *pdev) { return 
> -ENODEV; }
> +static inline int vga_switcheroo_unlock_ddc(struct pci_dev *pdev) { return 
> -ENODEV; }

If you care about the return value you'll want to return 0 here to make
sure kernels without VGA switcheroo support will continue to work
properly.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/f43ddd5f/attachment.sig>

[PATCH v2.1 3/3] drm/edid: Switch DDC when reading the EDID

On Fri, Aug 14, 2015 at 06:28:35PM +0200, Lukas Wunner wrote:
> Originally by Seth Forshee , 2012-10-04:
> Some dual graphics machines support muxing the DDC separately from the
> display, so make use of this functionality when reading the EDID on the
> inactive GPU. Also serialize drm_get_edid() with a mutex to avoid races
> on the DDC mux state.
> 
> Modified by Dave Airlie , 2012-12-22:
> I can't figure out why I didn't like this, but I rewrote this [...] to
> lock/unlock the ddc lines [...]. I think I'd prefer something like that
> otherwise the interface got really ugly.
> 
> Modified by Lukas Wunner , 2015-03-27:
> Unlock DDC lines if drm_probe_ddc() fails.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
> Tested-by: Pierre Moreau 
> [MBP  5,3 2009  nvidia 9400M + 9600M GT   pre-retina]
> Tested-by: Paul Hordiienko 
> [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
> Tested-by: William Brown 
> [MBP  8,2 2011  intel SNB + amd turks pre-retina]
> Tested-by: Lukas Wunner 
> [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
> Tested-by: Bruno Bierbaumer 
> [MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]
> 
> Cc: Seth Forshee 
> Cc: Dave Airlie 
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/gpu/drm/drm_edid.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e6e05bb..cdb2fa1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1377,13 +1378,21 @@ struct edid *drm_get_edid(struct drm_connector 
> *connector,
> struct i2c_adapter *adapter)
>  {
>   struct edid *edid;
> + struct pci_dev *pdev = connector->dev->pdev;
>  
> - if (!drm_probe_ddc(adapter))
> + vga_switcheroo_lock_ddc(pdev);
> +
> + if (!drm_probe_ddc(adapter)) {
> + vga_switcheroo_unlock_ddc(pdev);
>   return NULL;
> + }
>  
>   edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
>   if (edid)
>   drm_get_displayid(connector, edid);
> +
> + vga_switcheroo_unlock_ddc(pdev);
> +
>   return edid;
>  }
>  EXPORT_SYMBOL(drm_get_edid);

I think this is backwards and it'd be more explicit (though I suspect
slightly more work for this patch) to add a separate helper that does
the VGA switcheroo wrapping rather than have this in drm_get_edid()
where essentially every driver will go through the motions even if it
doesn't remotely support switcheroo.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/02a0ebe2/attachment.sig>

drm-next amdgpu warning

On Mon, Aug 17, 2015 at 03:58:10PM +1000, Dave Airlie wrote:
> Hey Alex,
> 
> this seems valid,
> 
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:
> In function âamdgpu_uvd_cs_pass2â:
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:491:17:
> warning: âmin_ctx_sizeâ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>   buf_sizes[0x4] = min_ctx_size;
>  ^
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:377:58:
> note: âmin_ctx_sizeâ was declared here
>   unsigned image_size, tmp, min_dpb_size, num_dpb_buffer, min_ctx_size;
>   ^

There's a patch for this here:

https://patchwork.kernel.org/patch/7014391/

There's apparently also an internal patch that fixes this, but it wasn't
clear yet which one was going to be picked up.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/f475dfb0/attachment.sig>

[PATCH] gpu/drm/i2c/adv7511: Fix license, set to GPL v2

On Tue, Aug 11, 2015 at 02:22:43PM +0200, Mike Looijmans wrote:
> Header claims GPL v2, so make the MODULE_LICENSE reflect that properly.
> 
> Signed-off-by: Mike Looijmans 
> ---
>  drivers/gpu/drm/i2c/adv7511.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)


The subject prefix looks wrong. According to git log it should be "drm:
adv7511: " instead. Otherwise:

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/a258df13/attachment.sig>

[PATCH] gpu/drm/i2c/adv7511: Fix license, set to GPL v2

On Mon, Aug 17, 2015 at 12:52:20PM +0200, Thierry Reding wrote:
> On Tue, Aug 11, 2015 at 02:22:43PM +0200, Mike Looijmans wrote:
> > Header claims GPL v2, so make the MODULE_LICENSE reflect that properly.
> > 
> > Signed-off-by: Mike Looijmans 
> > ---
> >  drivers/gpu/drm/i2c/adv7511.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> The subject prefix looks wrong. According to git log it should be "drm:
> adv7511: " instead. Otherwise:
> 
> Reviewed-by: Thierry Reding 

Also, when you resend you might want to send To: David Airlie to
increase the chances of him taking notice.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/2f4f8b6b/attachment-0001.sig>

[PATCH] Update maintainers for DRM STI driver

On Thu, Aug 13, 2015 at 02:32:23PM +0200, Benjamin Gaignard wrote:
> Add Vincent Abriou and myself has maintainers.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  MAINTAINERS | 9 +
>  1 file changed, 9 insertions(+)

I'm glad to see this. I think we'll need a couple like this for other
drivers, too. A couple that come to mind: atmel-hlcdc, msm (!), omapdrm,
tilcdc and (possibly) vgem.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/9c4f0782/attachment.sig>

[PATCH] drm/sti: Do not export symbols

On Fri, Aug 14, 2015 at 02:36:53PM +0200, Benjamin Gaignard wrote:
> This patch break sti driver compilation when it is compile as module.
> The root cause is that sti driver is split in 4 modules (hdmi, dvo,
> compositor and driver)...
> Maybe that is something we could fix since binding issue has been fix
> in previous patch.

Closing the loop on this: Benjamin and I discussed this on IRC and
agreed that we can drop this for now and revisit after the merge window.
As Benjamin points out the driver is currently split into 4 modules but
that may no longer be necessary. If so, having a single module seems
like the simpler option.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/ff931578/attachment.sig>

[PATCH] drm/panel: auo novatek 1080p video mode panel

On Mon, Aug 10, 2015 at 12:54:20PM -0700, Bjorn Andersson wrote:
> On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:
> 
> > On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  > gmail.com> wrote:
> > > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
> [..]
> > >> +- compatible: should be "auo,novatek-1080p-vid"
> > >
> > > This looks a little generic for a compatible string. Can't we get at the
> > > specific panel model number that's been used? What if AUO ever produced
> > > some other Novatek panel with a 1080p resolution?
> > 
> > Maybe Sony or someone else can chime in?  That somewhat generic name
> > was all I could get from downstream android kernel.  I'm sure there is
> > a better possible name, although I have no means to find that out
> > myself.
> > 
> 
> We're working on it.
> 
> > > Also, what's the -vid suffix for?
> > 
> > the same panel seems to also work in cmd mode.. so idea was to have
> > -vid and -cmd compat strings to choose which mode to operate in.
> > 
> 
> An alternative would be to make it a bool property, to indicate video
> mode - following how the framework is implemented.

Please, let's not do either. This doesn't belong in the compatible
string. The compatible string specifies the panel, and the panel
supports both video and command modes. That's implied by the compatible
string.

Which mode to use is a configuration or policy decision and therefore
doesn't belong in device tree. It should be up to the display driver to
determine what the preferred mode of operation is.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/fe25b4f5/attachment.sig>

[PATCH] drm/panel: auo novatek 1080p video mode panel

On Fri, Aug 07, 2015 at 12:11:31PM -0400, Rob Clark wrote:
> On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  
> wrote:
> > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
[...]
> >> +static int auo_panel_on(struct auo_panel *auo)
> >> +{
> >> + struct mipi_dsi_device *dsi = auo->dsi;
> >> + int ret;
> >> +
> >> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> >
> > This is weird.
> >
> >> + ret = mipi_dsi_dcs_set_display_on(dsi);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + msleep(40);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int auo_panel_off(struct auo_panel *auo)
> >> +{
> >> + struct mipi_dsi_device *dsi = auo->dsi;
> >> + int ret;
> >> +
> >> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> >
> > And this even more. Doesn't the panel work when you simply send
> > everything in low-power mode?
> 
> I wouldn't expect low power mode to have enough bandwidth for the
> video signal.. but otoh it seems like I need to use lpm for
> power-on/off sequence.  Maybe we should wrap that up in a helper to
> enable/disable lpm?  But that seemed a bit overkill.

I think there's a misunderstanding, which arguable might stem from a
lack of documentation. The intention for MIPI_DSI_MODE_LPM was to be
used in conjunction with "host-driven" command mode.

Perhaps I should elaborate on the vocabulary here: Tegra supports two
types of command mode: "host-driven" and "DC-driven". Host driven
command mode is used to perform panel setup (using DCS and vendor-
specific commands). "DC-driven" command mode is used to update the
framebuffer using write_memory_start and write_memory_continue DCS
commands directly generated by the DSI controller.

In the latter case you'd obviously want to run in high-speed mode to
achieve the throughput necessary to drive you panel at the requested
resolution and framerate. In the former your device should be able to
receive command in both high speed and low power modes. However some
hardware is known not to work with high speed command transmission.
MIPI_DSI_MODE_LPM is targetted at these cases, so that display drivers
know not to attempt high-speed transmission of initial command packets.

Note how MIPI_DSI_MODE_LPM translates to MIPI_DSI_MSG_USE_LPM when
transferring messages (see mipi_dsi_device_transfer()). Looking at the
comment for the MIPI_DSI_MODE_LPM definition I realize that it isn't
very precise, but I have trouble coming up with anything better.
Perhaps:

/* transmit command messages (non-video data) in low power mode */
#define MIPI_DSI_MODE_LPM   BIT(11)

Any ideas?

On a semi-related note, some of the other flags are rather badly
documented. I do see that both Exynos and MSM implement most of these
(specifically the MIPI_DSI_MODE_VIDEO_H* ones), perhaps the comments
for all of those should be revisited. Ideally they'd be annotated with a
reference to the spec, like we do for MIPI_DSI_CLOCK_NON_CONTINUOUS.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/cf84c4b8/attachment.sig>

[PATCH] drm: panel: simple: add QiaoDian qd43003c0-40

On Mon, Aug 17, 2015 at 12:57:24PM +0200, Alexandre Belloni wrote:
> On 17/08/2015 at 12:09:14 +0200, Thierry Reding wrote :
> > On Sat, Aug 01, 2015 at 12:44:31AM +0200, Alexandre Belloni wrote:
> > > From: Josh Wu 
> > > 
> > > The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.
> > > 
> > > Timings from the OTA5180A document, ver 0.9, section
> > > 10.1.1:
> > >   http://www.orientdisplay.com/pdf/OTA5180A.pdf
> > > 
> > > Signed-off-by: Josh Wu 
> > > Signed-off-by: Alexandre Belloni 
> > > ---
> > >  .../devicetree/bindings/panel/qd,qd43003c0-40.txt  |  7 ++
> > >  drivers/gpu/drm/panel/panel-simple.c   | 26 
> > > ++
> > >  2 files changed, 33 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
> > 
> > You didn't run this through scripts/get_maintainer.pl, did you? It would
> > also help to use the standard prefix ("drm/panel: ") because I end up
> > filtering for that occasionally in case somebody didn't Cc me on panel
> > patches.
> > 
> 
> I'm pretty sure I did as you were the only one in the To: field.
> Maybe you want to check your spam filter.

Looking again, I see that you did indeed. Not sure what I was looking at
before. I apologize.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/4cd45f43/attachment.sig>

[PATCH RFC v3 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On 08/17/15 10:57, Jyri Sarha wrote:
> Missed one commet first time around...
>
> On 08/14/15 19:18, Mark Brown wrote:
>> On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
> ...
>>> +/* HDMI codec initalization data */
>>> +struct hdmi_codec_pdata {
>>> +struct device *dev; /* The HDMI encoder registering the codec */
>>
>> Shouldn't this just be dev->parent?
>>
>
> No. The HDMI encoder device is the parent for HDMI-codec.
>
> The patch you took in in the last round uses the ASoC component drivers
> parent's of-node if the component driver does not have one itself. In
> this case the phandle in the binding points to the HDMI encoder's node,
> which is the parent of the HDMI codec.
>

After reading the comment again I see now what you meant.

Yes, I can extract the encoder device from the dev->parent pointer. No 
need to have it in pdata.

Thanks,
Jyri

[PATCH v2 1/4] scripts/kernel-doc: Adding cross-reference links to html documentation.

2015-08-17 Thread Danilo Cesar Lemes de Paula

On 08/17/2015 01:10 AM, Jonathan Corbet wrote:
> On Tue, 28 Jul 2015 16:45:15 -0300
> Danilo Cesar Lemes de Paula  wrote:
> 
>> Functions, Structs and Parameters definitions on kernel documentation
>> are pure cosmetic, it only highlights the element.
>>
>> To ease the navigation in the documentation we should use  inside
>> those tags so readers can easily jump between methods directly.
>>
>> This was discussed in 2014[1] and is implemented by getting a list
>> of  from the DocBook XML to generate a database. Then it looks
>> for , and  tags that matches the ones in
>> the database. As it only links existent references, no broken links are
>> added.
> 
> So I had some airplane time today and was able to mess with this some.  I
> can't make it break anymore, and it clearly improves the resulting
> documentation, so I've applied it to the docs tree for 4.3.
> 
> I want to look at the rest of the stuff a bit more and play with it, but
> it's hard to imagine why we wouldn't want that as well.  I'm a bit more
> leery just because it adds another dependency to the build, even if it's
> an optional dependency.  My thinking at the moment is to apply it shortly

I totally agree about the dependency stuff. I even discussed it with
Daniel Vetter a bit. I started by writing my-very-own-markup-parser to
put alongside kernel-doc to avoid external dependencies, but it gets too
complex too quickly (specially when dealing with tables and multi-line
stuff). It would be a pain to maintain a something like that, and the
world probably doesn't need yet-another-markup-parser, so I decided to
use another tool.

> after the merge window so it can have a long soak in linux-next before a
> 4.4 merge; hope that sounds good.

It does sound good. Thanks!

> 
> Thanks for doing this work,

Glad I could help.


Danilo

[RFC] Repurpose reserved field in vblank event to crtc_id

Hi,

Right now, if an atomic commit sends multiple vblank events it is not
possible to distiguish for each crtc each event is for in userspace.
This series changes that be repurposing the reserved field in struct
drm_event_vblank.

Would this be a sane thing to do?

Thanks,
Ander

 drivers/gpu/drm/drm_atomic.c | 7 +--
 drivers/gpu/drm/drm_crtc.c   | 1 +
 drivers/gpu/drm/drm_ioctl.c  | 3 +++
 include/uapi/drm/drm.h   | 3 ++-
 4 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.4.3

[PATCH libdrm] xf86drmMode: Handle the crtc_id field of drm_event_vblank

Signed-off-by: Ander Conselvan de Oliveira 

---
 include/drm/drm.h |  2 +-
 xf86drm.h |  9 -
 xf86drmMode.c | 26 +-
 3 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 167b7b8..81f8af1 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -806,7 +806,7 @@ struct drm_event_vblank {
__u32 tv_sec;
__u32 tv_usec;
__u32 sequence;
-   __u32 reserved;
+   __u32 crtc_id;
 };

 #define DRM_CAP_DUMB_BUFFER 0x1
diff --git a/xf86drm.h b/xf86drm.h
index 360e04a..6eef8ac 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -726,7 +726,7 @@ extern void drmMsg(const char *format, ...) 
DRM_PRINTFLIKE(1, 2);
 extern int drmSetMaster(int fd);
 extern int drmDropMaster(int fd);

-#define DRM_EVENT_CONTEXT_VERSION 2
+#define DRM_EVENT_CONTEXT_VERSION 3

 typedef struct _drmEventContext {

@@ -746,6 +746,13 @@ typedef struct _drmEventContext {
  unsigned int tv_usec,
  void *user_data);

+   void (*page_flip_handler2)(int fd,
+  unsigned int sequence,
+  unsigned int tv_sec,
+  unsigned int tv_usec,
+  unsigned int crtc_id,
+  void *user_data);
+
 } drmEventContext, *drmEventContextPtr;

 extern int drmHandleEvent(int fd, drmEventContextPtr evctx);
diff --git a/xf86drmMode.c b/xf86drmMode.c
index fc19504..a9119a2 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -879,7 +879,8 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
int len, i;
struct drm_event *e;
struct drm_event_vblank *vblank;
-   
+   void *user_data;
+
/* The DRM read semantics guarantees that we always get only
 * complete events. */

@@ -905,15 +906,22 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
  U642VOID (vblank->user_data));
break;
case DRM_EVENT_FLIP_COMPLETE:
-   if (evctx->version < 2 ||
-   evctx->page_flip_handler == NULL)
-   break;
vblank = (struct drm_event_vblank *) e;
-   evctx->page_flip_handler(fd,
-vblank->sequence,
-vblank->tv_sec,
-vblank->tv_usec,
-U642VOID (vblank->user_data));
+   user_data = U642VOID (vblank->user_data);
+
+   if (evctx->version >= 3 && evctx->page_flip_handler2)
+   evctx->page_flip_handler2(fd,
+vblank->sequence,
+vblank->tv_sec,
+vblank->tv_usec,
+vblank->crtc_id,
+user_data);
+   else if (evctx->version == 2 && 
evctx->page_flip_handler)
+   evctx->page_flip_handler(fd,
+vblank->sequence,
+vblank->tv_sec,
+vblank->tv_usec,
+user_data);
break;
default:
break;
-- 
2.4.3

[PATCH] drm: Repurpose reserved field of drm_event_vlank to crtc_id

With the atomic API, it is possible that a single commit affects
multiple crtcs. If the user requests an event with that commit, one
event will be sent for each CRTC, but it is not possible to distinguish
which crtc an event is for in user space. To solve this, the reserved
field in struct drm_vblank_event is repurposed to include the crtc_id
which the event is for.

The DRM_CAP_CRTC_IN_VBLANK_EVENT is added to allow userspace to query if
the crtc field will be set properly.

Signed-off-by: Ander Conselvan de Oliveira 
---
 drivers/gpu/drm/drm_atomic.c | 7 +--
 drivers/gpu/drm/drm_crtc.c   | 1 +
 drivers/gpu/drm/drm_ioctl.c  | 3 +++
 include/uapi/drm/drm.h   | 3 ++-
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1066e4b..2a76d10 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1304,7 +1304,8 @@ EXPORT_SYMBOL(drm_atomic_async_commit);
  */

 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, struct drm_file *file_priv, uint64_t 
user_data)
+   struct drm_device *dev, struct drm_file *file_priv,
+   uint64_t user_data, struct drm_crtc *crtc)
 {
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
@@ -1328,6 +1329,7 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof e->event;
e->event.user_data = user_data;
+   e->event.crtc_id = crtc->base.id;
e->base.event = &e->event.base;
e->base.file_priv = file_priv;
e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
@@ -1529,7 +1531,8 @@ retry:
for_each_crtc_in_state(state, crtc, crtc_state, i) {
struct drm_pending_vblank_event *e;

-   e = create_vblank_event(dev, file_priv, arg->user_data);
+   e = create_vblank_event(dev, file_priv, arg->user_data,
+   crtc);
if (!e) {
ret = -ENOMEM;
goto out;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 33d877c..98fe624 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5212,6 +5212,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
e->event.user_data = page_flip->user_data;
+   e->event.crtc_id = crtc->base.id;
e->base.event = &e->event.base;
e->base.file_priv = file_priv;
e->base.destroy =
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index b1d303f..152aeba 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -312,6 +312,9 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
case DRM_CAP_ADDFB2_MODIFIERS:
req->value = dev->mode_config.allow_fb_modifiers;
break;
+   case DRM_CAP_CRTC_IN_VBLANK_EVENT:
+   req->value = 1;
+   break;
default:
return -EINVAL;
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..ecd9e96 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -631,6 +631,7 @@ struct drm_gem_open {
 #define DRM_CAP_CURSOR_WIDTH   0x8
 #define DRM_CAP_CURSOR_HEIGHT  0x9
 #define DRM_CAP_ADDFB2_MODIFIERS   0x10
+#define DRM_CAP_CRTC_IN_VBLANK_EVENT   0x11

 /** DRM_IOCTL_GET_CAP ioctl argument type */
 struct drm_get_cap {
@@ -826,7 +827,7 @@ struct drm_event_vblank {
__u32 tv_sec;
__u32 tv_usec;
__u32 sequence;
-   __u32 reserved;
+   __u32 crtc_id;
 };

 /* typedef area */
-- 
2.4.3

[PATCH] drm: Repurpose reserved field of drm_event_vlank to crtc_id

With the atomic API, it is possible that a single commit affects
multiple crtcs. If the user requests an event with that commit, one
event will be sent for each CRTC, but it is not possible to distinguish
which crtc an event is for in user space. To solve this, the reserved
field in struct drm_vblank_event is repurposed to include the crtc_id
which the event is for.

The DRM_CAP_CRTC_IN_VBLANK_EVENT is added to allow userspace to query if
the crtc field will be set properly.

Signed-off-by: Ander Conselvan de Oliveira 
---
 drivers/gpu/drm/drm_atomic.c | 7 +--
 drivers/gpu/drm/drm_crtc.c   | 1 +
 drivers/gpu/drm/drm_ioctl.c  | 3 +++
 include/uapi/drm/drm.h   | 3 ++-
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1066e4b..2a76d10 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1304,7 +1304,8 @@ EXPORT_SYMBOL(drm_atomic_async_commit);
  */

 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, struct drm_file *file_priv, uint64_t 
user_data)
+   struct drm_device *dev, struct drm_file *file_priv,
+   uint64_t user_data, struct drm_crtc *crtc)
 {
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
@@ -1328,6 +1329,7 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof e->event;
e->event.user_data = user_data;
+   e->event.crtc_id = crtc->base.id;
e->base.event = &e->event.base;
e->base.file_priv = file_priv;
e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
@@ -1529,7 +1531,8 @@ retry:
for_each_crtc_in_state(state, crtc, crtc_state, i) {
struct drm_pending_vblank_event *e;

-   e = create_vblank_event(dev, file_priv, arg->user_data);
+   e = create_vblank_event(dev, file_priv, arg->user_data,
+   crtc);
if (!e) {
ret = -ENOMEM;
goto out;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 33d877c..98fe624 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5212,6 +5212,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
e->event.user_data = page_flip->user_data;
+   e->event.crtc_id = crtc->base.id;
e->base.event = &e->event.base;
e->base.file_priv = file_priv;
e->base.destroy =
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index b1d303f..152aeba 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -312,6 +312,9 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
case DRM_CAP_ADDFB2_MODIFIERS:
req->value = dev->mode_config.allow_fb_modifiers;
break;
+   case DRM_CAP_CRTC_IN_VBLANK_EVENT:
+   req->value = 1;
+   break;
default:
return -EINVAL;
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..ecd9e96 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -631,6 +631,7 @@ struct drm_gem_open {
 #define DRM_CAP_CURSOR_WIDTH   0x8
 #define DRM_CAP_CURSOR_HEIGHT  0x9
 #define DRM_CAP_ADDFB2_MODIFIERS   0x10
+#define DRM_CAP_CRTC_IN_VBLANK_EVENT   0x11

 /** DRM_IOCTL_GET_CAP ioctl argument type */
 struct drm_get_cap {
@@ -826,7 +827,7 @@ struct drm_event_vblank {
__u32 tv_sec;
__u32 tv_usec;
__u32 sequence;
-   __u32 reserved;
+   __u32 crtc_id;
 };

 /* typedef area */
-- 
2.4.3

[PATCH 1/4] drm: add interface to get drm devices on the system v3

2015-08-17 Thread Emil Velikov

On 17 August 2015 at 04:09, Jammy Zhou  wrote:
> From: Emil Velikov 
>
> For mutiple GPU support, the devices on the system should be enumerated
> to get necessary information about each device, and the drmGetDevices
> interface is added for this. Currently only PCI devices are supported for
> the enumeration.
>
> Typical usage:
> int count;
> drmDevicePtr *foo;
> count = drmGetDevices(NULL, 0);
> foo = calloc(count, sizeof(drmDevicePtr));
> count = drmGetDevices(foo, count);
> /* find proper device, open correct device node, etc */
> drmFreeDevices(foo, count);
> free(foo);
>
> v2: change according to feedback from Emil
> v3: fix the signed extension for PCI device info
>
Thanks Jammy. That's better.

As I would suspect the amdgpu changes to be urgent, can we leave this
around for a few more days. I'd suspect some (potential) users will
want to like to take a look.

-Emil

drm-next amdgpu warning

2015-08-17 Thread Alex Deucher

On Mon, Aug 17, 2015 at 6:48 AM, Thierry Reding
 wrote:
> On Mon, Aug 17, 2015 at 03:58:10PM +1000, Dave Airlie wrote:
>> Hey Alex,
>>
>> this seems valid,
>>
>> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:
>> In function âamdgpu_uvd_cs_pass2â:
>> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:491:17:
>> warning: âmin_ctx_sizeâ may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>>   buf_sizes[0x4] = min_ctx_size;
>>  ^
>> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:377:58:
>> note: âmin_ctx_sizeâ was declared here
>>   unsigned image_size, tmp, min_dpb_size, num_dpb_buffer, min_ctx_size;
>>   ^
>
> There's a patch for this here:
>
> https://patchwork.kernel.org/patch/7014391/
>
> There's apparently also an internal patch that fixes this, but it wasn't
> clear yet which one was going to be picked up.
>
> Thierry

Fixed here:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.3-wip&id=21df89a5667de5fcd061753d3833e7dfcf5509d3

It's included in the -next pull I'll be sending out today.

Alex

[patch] drm/tegra: checking for IS_ERR() instead of NULL

2015-08-17 Thread Dan Carpenter

The tegra_sor_hdmi_find_settings() function returns NULL on error and
not an ERR_PTR.

Fixes: 459cc2c6800b ('drm/tegra: sor: Add HDMI support')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index da1715e..08c5461 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1961,9 +1961,9 @@ static void tegra_sor_hdmi_enable(struct drm_encoder 
*encoder)

/* production settings */
settings = tegra_sor_hdmi_find_settings(sor, mode->clock * 1000);
-   if (IS_ERR(settings)) {
-   dev_err(sor->dev, "no settings for pixel clock %d Hz: %ld\n",
-   mode->clock * 1000, PTR_ERR(settings));
+   if (!settings) {
+   dev_err(sor->dev, "no settings for pixel clock %d Hz\n",
+   mode->clock * 1000);
return;
}

[PATCH] drm/panel: auo novatek 1080p video mode panel

2015-08-17 Thread Rob Clark

On Mon, Aug 17, 2015 at 7:38 AM, Thierry Reding
 wrote:
> On Mon, Aug 10, 2015 at 12:54:20PM -0700, Bjorn Andersson wrote:
>> On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:
>>
>> > On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding > > gmail.com> wrote:
>> > > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
>> [..]
>> > >> +- compatible: should be "auo,novatek-1080p-vid"
>> > >
>> > > This looks a little generic for a compatible string. Can't we get at the
>> > > specific panel model number that's been used? What if AUO ever produced
>> > > some other Novatek panel with a 1080p resolution?
>> >
>> > Maybe Sony or someone else can chime in?  That somewhat generic name
>> > was all I could get from downstream android kernel.  I'm sure there is
>> > a better possible name, although I have no means to find that out
>> > myself.
>> >
>>
>> We're working on it.
>>
>> > > Also, what's the -vid suffix for?
>> >
>> > the same panel seems to also work in cmd mode.. so idea was to have
>> > -vid and -cmd compat strings to choose which mode to operate in.
>> >
>>
>> An alternative would be to make it a bool property, to indicate video
>> mode - following how the framework is implemented.
>
> Please, let's not do either. This doesn't belong in the compatible
> string. The compatible string specifies the panel, and the panel
> supports both video and command modes. That's implied by the compatible
> string.
>
> Which mode to use is a configuration or policy decision and therefore
> doesn't belong in device tree. It should be up to the display driver to
> determine what the preferred mode of operation is.

I would call it a "system integrator decision"..   and at least
currently we don't have anywhere better than DT for that.  Maybe it's
one of those "if all you have is a hammer, everything looks like a
nail" things..

BR,
-R

> Thierry

[PATCH] drm/panel: auo novatek 1080p video mode panel

On Mon, Aug 17, 2015 at 10:48:20AM -0400, Rob Clark wrote:
> On Mon, Aug 17, 2015 at 7:38 AM, Thierry Reding
>  wrote:
> > On Mon, Aug 10, 2015 at 12:54:20PM -0700, Bjorn Andersson wrote:
> >> On Fri 07 Aug 09:11 PDT 2015, Rob Clark wrote:
> >>
> >> > On Fri, Aug 7, 2015 at 9:19 AM, Thierry Reding  >> > gmail.com> wrote:
> >> > > On Tue, Jul 21, 2015 at 03:36:02PM -0400, Rob Clark wrote:
> >> [..]
> >> > >> +- compatible: should be "auo,novatek-1080p-vid"
> >> > >
> >> > > This looks a little generic for a compatible string. Can't we get at 
> >> > > the
> >> > > specific panel model number that's been used? What if AUO ever produced
> >> > > some other Novatek panel with a 1080p resolution?
> >> >
> >> > Maybe Sony or someone else can chime in?  That somewhat generic name
> >> > was all I could get from downstream android kernel.  I'm sure there is
> >> > a better possible name, although I have no means to find that out
> >> > myself.
> >> >
> >>
> >> We're working on it.
> >>
> >> > > Also, what's the -vid suffix for?
> >> >
> >> > the same panel seems to also work in cmd mode.. so idea was to have
> >> > -vid and -cmd compat strings to choose which mode to operate in.
> >> >
> >>
> >> An alternative would be to make it a bool property, to indicate video
> >> mode - following how the framework is implemented.
> >
> > Please, let's not do either. This doesn't belong in the compatible
> > string. The compatible string specifies the panel, and the panel
> > supports both video and command modes. That's implied by the compatible
> > string.
> >
> > Which mode to use is a configuration or policy decision and therefore
> > doesn't belong in device tree. It should be up to the display driver to
> > determine what the preferred mode of operation is.
> 
> I would call it a "system integrator decision"..   and at least
> currently we don't have anywhere better than DT for that.  Maybe it's
> one of those "if all you have is a hammer, everything looks like a
> nail" things..

If it were a system integrator decision then I'd agree it should be
parameterizable in DT. But to my knowledge you can run any command mode
capable display in video mode just fine.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/8fcab486/attachment.sig>

[PATCH 2/4] drm: Add support for ARM's HDLCD controller.

2015-08-17 Thread Liviu Dudau

On Sun, Aug 16, 2015 at 09:56:33AM +0100, Emil Velikov wrote:
> Hi Liviu,

Hi Emil,

> 
> On 5 August 2015 at 15:28, Liviu Dudau  wrote:
> > The HDLCD controller is a display controller that supports resolutions
> > up to 4096x4096 pixels. It is present on various development boards
> > produced by ARM Ltd and emulated by the latest Fast Models from the
> > company.
> >
> I believe there is a unofficial requirement(?) for new drm drivers to
> use atomic modesetting. Not 100% sure on this one though. The
> following drivers: tegra, msm, rcar-du, i915, and Daniel's blog [1]
> [2] cat provide some information on the topic.

I am also interested to know if this is a requirement or not.
Thanks for the pointers, I will review them again to see if I did miss
anything. I remember reading them at the beginning of the year but probably
the Christmas haze did not clear enough when I did.

> 
> The driver seems to has has a bit of dead code guarded by
> HDLCD_*_UNDERRUN. Perhaps these macros should become build or runtime
> switch(es) ?

There is a comment in hdlcd_drv.h explaining what HDLCD_SHOW_UNDERRUN can
be used for. As for HDLCD_COUNT_BUFFERUNDERRUNS, you are right, it's dead
code from the earlier debugging code that got removed before submission.
I will correct that.

> 
> Most DRM drivers do not threat dma, bus_error, vsync and/or underrun
> interrupts as debug functionality. They are of limited use in this
> driver, presently, yet the CONFIG_DEBUG_FS guard seems a bit strange
> imho.

The HDLCD device has only 1 interrupt that can fire and there is no other
way to show the reason for the interrupt in the driver. It was useful when
debugging underruns and/or vsync issues so I thought it might be useful
to keep around. Putting it the other way: if you are going to use this device
and the image is not completely rendered I would not be able to give you
support to figure out what went wrong without this debugging information.
With this in place I can tell the difference between a busy system vs one
where the interrupt latency is large.

Best regards,
Liviu

> 
> Cheers,
> Emil
> 
> [1] http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
> [2] http://blog.ffwll.ch/2015/01/update-for-atomic-display-updates.html
> 

-- 

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

drm/exynos: g2d userptr memory corruption

2015-08-17 Thread Tobias Jakobi

Thanks Lucas for the explanation!


Lucas Stach wrote:
> Hi Tobias,
> 
> Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
>> Hello,
>>
>> some time ago I checked whether I could use the userptr functionality to
>> do zero-copy from userspace allocated buffers via the G2D. This didn't
>> work out so well, so kinda put this to the bottom of my TODO list.
>>
>> Now that IOMMU support has landed and Jan Kara has rewrote page pinning
>> using frame vectors (see [1]) I gave userptr another try.
>>
>> The results are much better. I'm not experiencing any kernel lockups or
>> sysmmu pagefaults anymore. However the image now suffers from visual
>> artifacts. These images show the nature of the artifacts:
>> http://i.imgur.com/nzT6g3Y.jpg
>> http://i.imgur.com/wkuYI6X.jpg
>>
>> The corruption always manifests itself in these pixel lines of fixed
>> size and wrong color.
>>
>> I have written a testcase as part of libdrm for this issue:
>> https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71
>>
>> It allocates N (N an even number) buffers which are aligned to the
>> system pagesize. Then it does this each iteration:
>> 1) Fill the first N/2 buffers with random data
>> 2) Copy the first half to the second half of the buffers
>> 3) memcmp() first and second half (verification pass)
>>
>> Usually this verification already fails on the first iteration. An
>> interesting observation is that increasing (!) the buffer size (so the
>> amount of pixels that have to copied per buffer grows) makes this issue
>> less likely to happen.
>>
>> With the default 512x512 buffers however it happens, like I said above,
>> almost immediately.
>>
> This is obviously a cache flush missing. The memory you get from
> userspace is normal cached memory, so to make it visible to the GPU you
> need to flush parts of the cache out to main memory.
> 
> The corruption you are seeing is just unflushed cachelines. This also
> explains why increasing the buffer size helps: the more memory the CPU
> touches the more cachelines will be flushed out to be replaced with new
> data.
I should point out that the snapshots I uploaded were done with a
different setup. There only the source memory of the G2D operation is a
userspace allocated buffer. The destination is a GEM buffer allocated
through libdrm, which is then used as framebuffer. So the issue already
appears when just the source is userspace allocated.

What works however is an operation between GEM to GEM. However this
might be related to the default allocation flags libdrm uses.



> So you need to go and have a look at dma_map() and dma_sync_*_for_*()
> and friends.
> 
> Regards,
> Lucas
> 


With best wishes,
Tobias



--
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 91667] Tonga Oopses with uvd + agd5f drm-next-4.3-wip

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

Bug ID: 91667
Summary: Tonga Oopses with uvd + agd5f drm-next-4.3-wip
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel at lists.freedesktop.org
Reporter: adf.lists at gmail.com

Created attachment 117730
--> https://bugs.freedesktop.org/attachment.cgi?id=117730&action=edit
Oops 1

Tried the newly updated agd5f drm-next-4.3-wip today and got some oopses with
uvd.

These are provoked by repeatedly starting a vid with mpplayer - a known issue,
but the change for me on Tonga is getting the Oopses.

On other kernels amdgpu/amd-staging/drm-fixes the same test would provoke a
ring 9 lock (rarely ring 0) and a failed reset, which at least would leave me
alive enough to get a VT.

I notice GPU stall detection has now been disabled - but testing various
4.3-wips over some weeks I have never got one anyway. Doing something like this
test or running valley would just lock the display and log nothing. SysRq
worked OK as it still does - just now I get some logging (though not for the
one Unigine Valley lock I just provoked).

I am now running mesa/drm mesa/mesa Git Xorg with DRI3 enabled.

While testing I noticed the tree got another update - retested and still get
the same.

The first 2 are from the older tree, the second long as secondary Oopses were
provoked.

The third is current.

--
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/20150817/10c69e51/attachment-0001.html>

[Bug 91667] Tonga Oopses with uvd + agd5f drm-next-4.3-wip

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

--- Comment #1 from Andy Furniss  ---
Created attachment 117731
  --> https://bugs.freedesktop.org/attachment.cgi?id=117731&action=edit
Oops 2 long

-- 
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/20150817/c3919a44/attachment.html>

[Bug 91667] Tonga Oopses with uvd + agd5f drm-next-4.3-wip

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

--- Comment #2 from Andy Furniss  ---
Created attachment 117732
  --> https://bugs.freedesktop.org/attachment.cgi?id=117732&action=edit
Oops 3 - current tree

-- 
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/20150817/a7326a95/attachment.html>

[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

r<#secure method=pgpmime mode=sign>
Stephen Warren  writes:

> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>> This is the start of a full VC4 driver.  Right now this just supports
>> configuring the display using a pre-existing video mode (because
>> changing the pixel clock isn't available yet, and doesn't work when it
>> is).  However, this is enough for fbcon and bringing up X using
>> xf86-video-modesetting.
>
>> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
>
>> +config DRM_VC4
>> +tristate "Broadcom VC4 Graphics"
>
>> +help
>> +  Choose this option if you have a system that has a Broadcom
>> +  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
>> +
>> +  This driver requires that "avoid_warnings=2" be present in
>> +  the config.txt for the firmware, to keep it from smashing
>> +  our display setup.
>
> The need for "avoid_warnings=2" seems like it will trip people up. I
> don't think it's in any config.txt I've seen. Can you expand more on that?

The warnings thing is the firmware watching for undervoltage and then it
calls into dispmanx to overlay a little rainbow box on the screen.  This
of course interferes with our display setup.

I think we'll be able to wire up notifications to Linux for
undervoltage, at which point we can do something useful with that
information, ourselves.

commit f6d6913 'convert to markdown' breaks pdfdocs with double s

2015-08-17 Thread Danilo Cesar Lemes de Paula

On 08/17/2015 01:53 PM, Graham Whaley wrote:
> Hi,
>  commit f6d6913425a560c3cd213096e34834e797ef83f8: drm/doc: Convert to
> markdown
> 
> caused some changes to the drm.xml layout, particularly in the 
> parts,that make pdfdocs generation unhappy.  In particular (working at
> the commit above), the following new error:
> 
>  jade:/Documentation/DocBook/drm.xml:2491:8:E: document type does not
> allow element "para" here; missing one of "footnote", "caution",
> "important", "note", "tip", "warning", "blockquote", "informalexample"
> start-tag
> 
> comes from this code:
> 
>  drm.xml:2488
>  drm_vma_node_offset_addr.
>
>
>
>Additionally to offset management,
> 
> 
> That code comes from:
>   drm.tmpl:888: !Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager
> 
> Before markdown/pandoc (or if you turn off MARKDOWN in the Makefile)
> this looked like this:
> 
>  drm.xml:2488
>please see drm_vma_node_offset_addr.
>
>Additionally to offset management,
> 
> 
> I've failed to figure out exactly how/what/why markdown/pandoc is doing
> here or if it is a pandoc or kernel-doc or other error or
> incompatibility.
> As to the pdfdocs error, my suspicion is that nested s are not
> allowed, but the html generation 'gets away' with it - generating HTML
> like this (grrr - Evolution is messing with the html layout below, even
> in a 'plain text' email!):
> 
>  drm/drm-memory-management.html:391
> title="drm_vma_node_offset_addr">drm_vma_node_offset_addr  
> .  
> 
>
> 
>   
>Additionally to offset management,
> 
> 
> The double  is very easy to generate from pandoc. If the
> following fragment is fed to pandoc using the same parameters as used
> in kernel-doc then you see it. I grabbed the idea of the fragment by
> enabling some of the stderr debug in kernel-doc to try and see what was
> going on.
> 
>  fragment.in
> 
> x
> 
> 
> # pandoc --columns=80 -f markdown -t docbook fragment.in
>  stdout
> 
> 
> 
>   x
> 
> 
> 
> There are a number of occurrences of the 'double para' in the xml now,
> but I have not figured out if there is a pattern to what makes those
> specific parts come out that way, and not others.
> 
> Anybody got any ideas?

I think I know what's going on.

Pandoc is being called too late, Kernel-doc already applies some XML
formatting before the pandoc call is made.

I did see it before (and even fixed a minor side effect of that
behavior), but since it didn't cause any real issue with the html target
(error/warning-wise and visualization-wise) I didn't pay too much
attention to it.

Perhaps pandoc should be the one dealing with all paragraphs stuff in
case we have the markdown-down flag.
I will investigate this a bit more and send a fix soon.

Thanks for testing it and letting me know.

Danilo Cesar

* adding Jonathan Corbet to the CC list as he might be interested.

[PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.

Stephen Warren  writes:

> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>> Signed-off-by: Eric Anholt 
>
> This one definitely needs a patch description, since someone might not
> know what a VC4 is, and "git log" won't show the text from the binding
> doc itself. I'd suggest adding the initial paragraph of the binding doc
> as the patch description, or more.
>
>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
>> b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

>> +- hvss: List of references to HVS video scalers
>> +- encoders: List of references to output encoders (HDMI, SDTV)
>
> Would it make sense to make all those nodes child node of the vc4
> object. That way, there's no need to have these lists of objects; they
> can be automatically built up as the DT is enumerated. I know that e.g.
> the NVIDIA Tegra host1x binding works this way, and I think it may have
> been inspired by other similar cases.

I've looked at tegra, and the component system used by msm appears to be
nicer than it.  To follow tegra's model, it looks like I need to build
this extra bus thing corresponding to host1x that is effectively the
drivers/base/component.c code, so that I can get at vc4's structure from
the component drivers.

> Of course, this is only appropriate if the HW modules really are
> logically children of the VC4 HW module. Perhaps they aren't. If they
> aren't though, I wonder what this "vc4" module actually represents in HW?

It's the subsystem, same as we use a subsystem node for msm, sti,
rockchip, imx, and exynos.  This appears to be the common model of how
the collection of graphics-related components is represented in the DT.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/0b3f40da/attachment.sig>

[PATCH 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.

Stephen Warren  writes:

> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>> We need to use it for getting video modes over HDMI.
>
>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
>
>> +i2c2: i2c at 7e805000 {
>> +compatible = "brcm,bcm2835-i2c";
>> +reg = <0x7e805000 0x1000>;
>> +interrupts = <2 21>;
>> +clocks = <&clk_i2c>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>
> In an SoC .dtsi file, you'd typically write:
>
>   status = "disabled";
>
> ... in all nodes that represent IO controllers that interface to
> external HW, so that board DT files can/must explicitly choose to enable
> the device if it's actually in use on the board. Some systems might not
> have HDMI and hence might not hook up the HDMI_SCL/SDA pads.
>
> BCM2835-ARM-Peripherals.pdf states "Note that the BSC2 master is used
> dedicated with the HDMI interface and should not be accessed by user
> programs.". Does this imply the Linux kernel shouldn't be touching this
> I2C controller; that the VC4 firmware might also be attempting to use
> it? I wonder how any such sharing of the HW would work.

In order for *any* of this driver to work, we need to ensure that the
firmware doesn't try to write to the corresponding part of the hardware.
DDC I2C is no different.  All that will cause the firmware to do
anything with display is generating mbox/dispmanx requests (through the
firmware driver), and the undervoltage warnings.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/39e1921f/attachment.sig>

[PATCH 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

Stephen Warren  writes:

> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>
>> +DRM DRIVERS FOR VC4
>> +M:  Eric Anholt 
>> +T:  git git://github.com/anholt/linux
>> +S:  Maintained
>> +F:  drivers/gpu/drm/vc4/*
>
> S: Supported

Fixed.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150817/20d212eb/attachment.sig>

[PATCH v2.1 1/3] vga_switcheroo: Add support for switching only the DDC

2015-08-17 Thread Lukas Wunner

Hi Thierry,

Thanks a lot for your comments!

On Mon, Aug 17, 2015 at 12:36:55PM +0200, Thierry Reding wrote:
> On Fri, Aug 14, 2015 at 06:50:15PM +0200, Lukas Wunner wrote:
> > +int vga_switcheroo_lock_ddc(struct pci_dev *pdev)
> > +{
> > +   int id;
> > +
> > +   mutex_lock(&vgasr_priv.ddc_lock);
> > +
> > +   if (!vgasr_priv.handler || !vgasr_priv.handler->switch_ddc)
> > +   return vgasr_priv.old_ddc_owner = -ENODEV;
> 
> I find this very hard to read. Can this be split across two lines?

Ok, will rectify in v2.2.

> > +   id = vgasr_priv.handler->get_client_id(pdev);
> > +   return vgasr_priv.old_ddc_owner = vgasr_priv.handler->switch_ddc(id);
> 
> This too. I also notice that the only place you call this from doesn't
> care about the return value, so why even bother returning one?

I carried this over from Seth Forshee's and Dave Airlie's patches,
I believe the rationale is that the ->switch_ddc handler callback
might return an error and that is customarily passed up to the caller.

While drm_get_edid() does indeed ignore that return value (it will
just try to probe DDC anyway), some future function that invokes
vga_switcheroo_lock_ddc() might want to do something useful with it.

So either way has its merits and tbh I don't feel in a position to
judge what's right or wrong here. I'd be grateful if you or some
other maintainer would decide whether to make the return value
void or not and I'll be happy to change the patch accordingly.

> > +static inline int vga_switcheroo_lock_ddc(struct pci_dev *pdev) { return 
> > -ENODEV; }
> > +static inline int vga_switcheroo_unlock_ddc(struct pci_dev *pdev) { return 
> > -ENODEV; }
> 
> If you care about the return value you'll want to return 0 here to make
> sure kernels without VGA switcheroo support will continue to work
> properly.

Maybe I'm mistaken but I believe -ENODEV is correct. If there's no error
then vga_switcheroo_lock_ddc/unlock_ddc() return the old_ddc_owner which
is numbered from 0. E.g. on the MacBook Pro, 0 is IGD and 1 is DIS.
So returning 0 would mean "okay, successfully switched, was previously
switched to the integrated GPU".

Best regards,

Lukas

[PATCH RFC v3 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On 08/17/15 21:41, Mark Brown wrote:
> On Mon, Aug 17, 2015 at 10:07:55AM +0300, Jyri Sarha wrote:
>> On 08/14/15 19:18, Mark Brown wrote:
>>> On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
>
 +  /* Called when ASoC starts an audio stream setup. The call
 +   * provides an audio abort callback for stoping an ongoing
 +   * stream if the HDMI audio becomes unavailable.
 +   * Optional */
 +  int (*audio_startup)(struct device *dev,
 +   void (*abort_cb)(struct device *dev));
>
>>> I'm a bit confused about what is going to use abort_cb() and why they
>>> wouldn't just call shutdown instead?
>
>> audio_shutdown() is for ASoC side to tell video side that audio playback has
>> stopped.
>
>> The abort_cb() is for video side to inform ASoC that current audio stream
>> can not continue anymore and it should be aborted. The similar mechanism is
>> currently in use in sound/soc/omap/omap-hdmi-audio.c.
>
> Someone reading the code needs to be able to understand this.
>

Ok, I'll improve the comment above.

Thanks,
Jyri

[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley