Re: [PATCH] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Marek Szyprowski]

Dear Inki,

On 2017-11-10 04:04, Inki Dae wrote:

2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:

When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
are contiguous, because of the underlying dma_alloc_attrs() function
provides only such buffers. In such case it makes no sense to keep

What if user disabled CMA support? In this case, it guarantees also to allocate 
physically contiguous memory?
I think it depends on CMA support so wouldn't be true.


dma_alloc_attrs() always guarantees the contiguity of the allocated memory
in DMA address space. When NOIOMMU is available, this mean that the 
allocated

buffer is contiguous in the physical memory. When CMA is disabled,
dma_alloc_attrs() uses alloc_pages() allocator. The drawback of 
alloc_pages()

is that it easily fails if physical memory is fragmented and it cannot
allocate memory larger than MAX_ORDER (4MiB in case of ARM32bit).


Real problem I think is that user don't know whether the gem buffer allocated 
with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer.
So user can request a page flip with NONCONTIG buffer to kernel which doesn't 
support IOMMU.

And another is that user may want to use NONCONTIG buffer for another purpose, 
not scanout.
So if we enforce on using CONTIG buffer on kernel without IOMMU support, then 
it wouldn't be really what user intended.


When IOMMU support is disabled, ANY buffer allocated with dma_alloc_attrs()
will be contiguous, so I see no point propagating incorrect flag for it.

The only way to create a NONCONTIG buffer with IOMMU disabled is to import
it from other driver and this path is already handled correctly.


My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can allocate 
a buffer with a different allocation type - CONTIG or NONCONTIG - according to 
IOMMU support.
And any page flip request with NONCONTIG buffer to kernel without IOMMU support 
should fail and it has to return a error with a proper error message.


I don't think that we need it. With the proposed patch the same 
userspace will

work fine in both cases IOMMU enabled and disabled, even if it allocate GEM
with NONCONTIG flag. We can assume that CONTIG is a special case of 
NONCONTIG

then.


BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
failures for buffer contiguity checks in the subsequent operations on GEM
objects.

Signed-off-by: Marek Szyprowski 
CC: sta...@vger.kernel.org # v4.4+
---
This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
support for exynos drm framework"), but this patch applies cleanly
only to v4.4+ kernel releases due changes in the surrounding code.
---
  drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 02f978bb9261..476c00fe1998 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -227,6 +227,13 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
drm_device *dev,
if (IS_ERR(exynos_gem))
return exynos_gem;
  
+	/*

+* when no IOMMU is available, all allocated buffers are contiguous
+* anyway, so drop EXYNOS_BO_NONCONTIG flag
+*/
+   if (!is_drm_iommu_supported(dev))
+   flags &= ~EXYNOS_BO_NONCONTIG;

So this could be a tempararily solution until the new flag is added, and you 
may need to modify above comments.

Thanks,
Inki Dae


+
/* set memory type and cache attribute from user side. */
exynos_gem->flags = flags;
  





Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 4/4] amdgpu: Add memory over allocation test.

[Andrey Grodzovsky]

Allocates 1 TB of memory. Test is disabled by default
since it's triggers OOM killer.

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/amdgpu_test.c |  4 
 tests/amdgpu/bo_tests.c| 20 
 2 files changed, 24 insertions(+)

diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 91010dc..3b10f82 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -417,6 +417,10 @@ static void amdgpu_disable_suits()
*/
if (amdgpu_set_test_active(DEADLOCK_TESTS_STR, "compute ring block 
test", CU_FALSE))
fprintf(stderr, "test deactivation failed - %s\n", 
CU_get_error_msg());
+
+   /* This test triggers OOM killer terminating the tester itself */
+   if (amdgpu_set_test_active(BO_TESTS_STR, "Memory fail alloc Test", 
CU_FALSE))
+   fprintf(stderr, "test deactivation failed - %s\n", 
CU_get_error_msg());
 }
 
 /* The main() function for setting up and running the tests.
diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index 4545196..c6d89aa 100644
--- a/tests/amdgpu/bo_tests.c
+++ b/tests/amdgpu/bo_tests.c
@@ -47,6 +47,7 @@ static void amdgpu_bo_export_import(void);
 static void amdgpu_bo_metadata(void);
 static void amdgpu_bo_map_unmap(void);
 static void amdgpu_memory_alloc(void);
+static void amdgpu_memory_fail_alloc(void);
 
 CU_TestInfo bo_tests[] = {
{ "Export/Import",  amdgpu_bo_export_import },
@@ -55,6 +56,7 @@ CU_TestInfo bo_tests[] = {
 #endif
{ "CPU map/unmap",  amdgpu_bo_map_unmap },
{ "Memory alloc Test",  amdgpu_memory_alloc },
+   { "Memory fail alloc Test",  amdgpu_memory_fail_alloc },
CU_TEST_INFO_NULL,
 };
 
@@ -244,3 +246,21 @@ static void amdgpu_memory_alloc(void)
r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
CU_ASSERT_EQUAL(r, 0);
 }
+
+static void amdgpu_memory_fail_alloc(void)
+{
+   amdgpu_bo_handle bo;
+   amdgpu_va_handle va_handle;
+   uint64_t bo_mc;
+   int r;
+
+   /* Test impossible mem allocation, 1TB */
+   bo = gpu_mem_alloc(device_handle, 0xE8D4A51000, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM,
+   AMDGPU_GEM_CREATE_NO_CPU_ACCESS,
+   &bo_mc, &va_handle);
+
+   r = gpu_mem_free(bo, va_handle, bo_mc, 0xE8D4A51000);
+   CU_ASSERT_EQUAL(r, 0);
+}
+
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 3/4] amdgpu: Move memory alloc tests in bo suite.

[Andrey Grodzovsky]

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/basic_tests.c | 49 --
 tests/amdgpu/bo_tests.c| 49 ++
 2 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 18bcf91..e7f48e3 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -44,7 +44,6 @@ static  uint32_t  minor_version;
 static  uint32_t  family_id;
 
 static void amdgpu_query_info_test(void);
-static void amdgpu_memory_alloc(void);
 static void amdgpu_command_submission_gfx(void);
 static void amdgpu_command_submission_compute(void);
 static void amdgpu_command_submission_multi_fence(void);
@@ -58,7 +57,6 @@ static void 
amdgpu_command_submission_copy_linear_helper(unsigned ip_type);
 
 CU_TestInfo basic_tests[] = {
{ "Query Info Test",  amdgpu_query_info_test },
-   { "Memory alloc Test",  amdgpu_memory_alloc },
{ "Userptr Test",  amdgpu_userptr_test },
{ "Command submission Test (GFX)",  amdgpu_command_submission_gfx },
{ "Command submission Test (Compute)", 
amdgpu_command_submission_compute },
@@ -277,53 +275,6 @@ static void amdgpu_query_info_test(void)
CU_ASSERT_EQUAL(r, 0);
 }
 
-static void amdgpu_memory_alloc(void)
-{
-   amdgpu_bo_handle bo;
-   amdgpu_va_handle va_handle;
-   uint64_t bo_mc;
-   int r;
-
-   /* Test visible VRAM */
-   bo = gpu_mem_alloc(device_handle,
-   4096, 4096,
-   AMDGPU_GEM_DOMAIN_VRAM,
-   AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED,
-   &bo_mc, &va_handle);
-
-   r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
-   CU_ASSERT_EQUAL(r, 0);
-
-   /* Test invisible VRAM */
-   bo = gpu_mem_alloc(device_handle,
-   4096, 4096,
-   AMDGPU_GEM_DOMAIN_VRAM,
-   AMDGPU_GEM_CREATE_NO_CPU_ACCESS,
-   &bo_mc, &va_handle);
-
-   r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
-   CU_ASSERT_EQUAL(r, 0);
-
-   /* Test GART Cacheable */
-   bo = gpu_mem_alloc(device_handle,
-   4096, 4096,
-   AMDGPU_GEM_DOMAIN_GTT,
-   0, &bo_mc, &va_handle);
-
-   r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
-   CU_ASSERT_EQUAL(r, 0);
-
-   /* Test GART USWC */
-   bo = gpu_mem_alloc(device_handle,
-   4096, 4096,
-   AMDGPU_GEM_DOMAIN_GTT,
-   AMDGPU_GEM_CREATE_CPU_GTT_USWC,
-   &bo_mc, &va_handle);
-
-   r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
-   CU_ASSERT_EQUAL(r, 0);
-}
-
 static void amdgpu_command_submission_gfx_separate_ibs(void)
 {
amdgpu_context_handle context_handle;
diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index 74b5e77..4545196 100644
--- a/tests/amdgpu/bo_tests.c
+++ b/tests/amdgpu/bo_tests.c
@@ -46,6 +46,7 @@ static amdgpu_va_handle va_handle;
 static void amdgpu_bo_export_import(void);
 static void amdgpu_bo_metadata(void);
 static void amdgpu_bo_map_unmap(void);
+static void amdgpu_memory_alloc(void);
 
 CU_TestInfo bo_tests[] = {
{ "Export/Import",  amdgpu_bo_export_import },
@@ -53,6 +54,7 @@ CU_TestInfo bo_tests[] = {
{ "Metadata",  amdgpu_bo_metadata },
 #endif
{ "CPU map/unmap",  amdgpu_bo_map_unmap },
+   { "Memory alloc Test",  amdgpu_memory_alloc },
CU_TEST_INFO_NULL,
 };
 
@@ -195,3 +197,50 @@ static void amdgpu_bo_map_unmap(void)
r = amdgpu_bo_cpu_unmap(buffer_handle);
CU_ASSERT_EQUAL(r, 0);
 }
+
+static void amdgpu_memory_alloc(void)
+{
+   amdgpu_bo_handle bo;
+   amdgpu_va_handle va_handle;
+   uint64_t bo_mc;
+   int r;
+
+   /* Test visible VRAM */
+   bo = gpu_mem_alloc(device_handle,
+   4096, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM,
+   AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED,
+   &bo_mc, &va_handle);
+
+   r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+   CU_ASSERT_EQUAL(r, 0);
+
+   /* Test invisible VRAM */
+   bo = gpu_mem_alloc(device_handle,
+   4096, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM,
+   AMDGPU_GEM_CREATE_NO_CPU_ACCESS,
+   &bo_mc, &va_handle);
+
+   r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+   CU_ASSERT_EQUAL(r, 0);
+
+   /* Test GART Cacheable */
+   bo = gpu_mem_alloc(device_handle,
+   4096, 4096,
+   AMDGPU_GEM_DOMAIN_GTT,
+   0, &bo_mc, &va_handle);
+
+   r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+   CU_ASSERT_EQUAL(r, 0);
+
+   /* Test GART USWC */
+   bo = gpu_mem_alloc(device_handle,
+   4096, 4096,
+  

[PATCH libdrm 2/4] amdgpu: Use new suite/test disabling functionality.

[Andrey Grodzovsky]

Switch from disabling tests during run to using the new disable
API.

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/amdgpu_test.c| 14 ++--
 tests/amdgpu/amdgpu_test.h| 15 
 tests/amdgpu/deadlock_tests.c |  8 +
 tests/amdgpu/uvd_enc_tests.c  | 81 +--
 tests/amdgpu/vce_tests.c  | 65 +-
 tests/amdgpu/vcn_tests.c  | 74 +--
 6 files changed, 123 insertions(+), 134 deletions(-)

diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 68ec5d3..91010dc 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -150,15 +150,15 @@ static Suites_Active_Status suites_active_stat[] = {
},
{
.pName = VCE_TESTS_STR,
-   .pActive = always_active,
+   .pActive = suite_vce_tests_enable,
},
{
.pName = VCN_TESTS_STR,
-   .pActive = always_active,
+   .pActive = suite_vcn_tests_enable,
},
{
.pName = UVD_ENC_TESTS_STR,
-   .pActive = always_active,
+   .pActive = suite_uvd_enc_tests_enable,
},
{
.pName = DEADLOCK_TESTS_STR,
@@ -409,6 +409,14 @@ static void amdgpu_disable_suits()
if (amdgpu_set_suite_active(suites_active_stat[i].pName,
suites_active_stat[i].pActive()))
fprintf(stderr, "suit deactivation failed - %s\n", 
CU_get_error_msg());
+
+   /* Explicitly disable specific tests due to known bugs or preferences */
+   /*
+   * BUG: Compute ring stalls and never recovers when the address is
+   * written after the command already submitted
+   */
+   if (amdgpu_set_test_active(DEADLOCK_TESTS_STR, "compute ring block 
test", CU_FALSE))
+   fprintf(stderr, "test deactivation failed - %s\n", 
CU_get_error_msg());
 }
 
 /* The main() function for setting up and running the tests.
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index 9ccc1ff..dd236ed 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -100,6 +100,11 @@ int suite_vce_tests_init();
 int suite_vce_tests_clean();
 
 /**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_vce_tests_enable(void);
+
+/**
  * Tests in vce test suite
  */
 extern CU_TestInfo vce_tests[];
@@ -115,6 +120,11 @@ int suite_vcn_tests_init();
 int suite_vcn_tests_clean();
 
 /**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_vcn_tests_enable(void);
+
+/**
 + * Tests in vcn test suite
 + */
 extern CU_TestInfo vcn_tests[];
@@ -130,6 +140,11 @@ int suite_uvd_enc_tests_init();
 int suite_uvd_enc_tests_clean();
 
 /**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_uvd_enc_tests_enable(void);
+
+/**
  * Tests in uvd enc test suite
  */
 extern CU_TestInfo uvd_enc_tests[];
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index e23d903..f5c4552 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -119,13 +119,7 @@ int suite_deadlock_tests_clean(void)
 
 CU_TestInfo deadlock_tests[] = {
{ "gfx ring block test",  amdgpu_deadlock_gfx },
-
-   /*
-   * BUG: Compute ring stalls and never recovers when the address is
-   * written after the command already submitted
-   */
-   /* { "compute ring block test",  amdgpu_deadlock_compute }, */
-
+   { "compute ring block test",  amdgpu_deadlock_compute },
CU_TEST_INFO_NULL,
 };
 
diff --git a/tests/amdgpu/uvd_enc_tests.c b/tests/amdgpu/uvd_enc_tests.c
index bbda131..bed8494 100644
--- a/tests/amdgpu/uvd_enc_tests.c
+++ b/tests/amdgpu/uvd_enc_tests.c
@@ -79,7 +79,6 @@ static void amdgpu_cs_uvd_enc_session_init(void);
 static void amdgpu_cs_uvd_enc_encode(void);
 static void amdgpu_cs_uvd_enc_destroy(void);
 
-static bool uvd_enc_support(void);
 
 CU_TestInfo uvd_enc_tests[] = {
{ "UVD ENC create",  amdgpu_cs_uvd_enc_create },
@@ -89,6 +88,27 @@ CU_TestInfo uvd_enc_tests[] = {
CU_TEST_INFO_NULL,
 };
 
+CU_BOOL suite_uvd_enc_tests_enable(void)
+{
+   int r;
+   struct drm_amdgpu_info_hw_ip info;
+
+   if (amdgpu_device_initialize(drm_amdgpu[0], &major_version,
+&minor_version, &device_handle))
+   return CU_FALSE;
+
+   r = amdgpu_query_hw_ip_info(device_handle, AMDGPU_HW_IP_UVD_ENC, 0, 
&info);
+
+   if (amdgpu_device_deinitialize(device_handle))
+   return CU_FALSE;
+
+   if (!info.available_rings)
+   printf("\n\nThe ASIC NOT support UVD ENC, suite disabled.\n");
+
+   return (r == 0 && (info.available_rings 

[PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Andrey Grodzovsky]

THe following  patch series intoroduce  dynamic tests dusabling/enabling
in amdgpu  tester using Cunit API. Today test suits that
don't apply to specific HW just return success w/o executing while
single tests that can't be executed properly are commented out.

Suits are diasbled based on hooks they provide (e.g incompatible 
ASIC or missing blocks) while single tests are diasbled explicitly since this 
is 
usually due to some bug preventing from the tester  or the system  to handle
the test w/o crashing or killing the tester.

Inside this series also a minor cleanup and new test for memory over allocation.

Andrey Grodzovsky (4):
  amdgpu: Add functions to disable suites and tests.
  amdgpu: Use new suite/test disabling functionality.
  amdgpu: Move memory alloc tests in bo suite.
  amdgpu: Add memory over allocation test.

 tests/amdgpu/amdgpu_test.c| 169 +-
 tests/amdgpu/amdgpu_test.h|  46 
 tests/amdgpu/basic_tests.c|  49 
 tests/amdgpu/bo_tests.c   |  69 +
 tests/amdgpu/deadlock_tests.c |   8 +-
 tests/amdgpu/uvd_enc_tests.c  |  81 
 tests/amdgpu/vce_tests.c  |  65 
 tests/amdgpu/vcn_tests.c  |  74 --
 8 files changed, 363 insertions(+), 198 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 1/4] amdgpu: Add functions to disable suites and tests.

[Andrey Grodzovsky]

Suits are diasbled based on hooks they provide (e.g incompatible
ASIC or missing blocks). Single tests are diasbled explicitly.
Suit or test can be forced to execute even if disabled by adding -f 
flag after specifying suit [test] ids.

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/amdgpu_test.c | 157 +++--
 tests/amdgpu/amdgpu_test.h |  31 +
 2 files changed, 170 insertions(+), 18 deletions(-)

diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index a82d9ab..68ec5d3 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -50,6 +50,16 @@
 
 #include "amdgpu_test.h"
 
+/* Test suit names */
+#define BASIC_TESTS_STR "Basic Tests"
+#define BO_TESTS_STR "BO Tests"
+#define CS_TESTS_STR "CS Tests"
+#define VCE_TESTS_STR "VCE Tests"
+#define VCN_TESTS_STR "VCN Tests"
+#define UVD_ENC_TESTS_STR "UVD ENC Tests"
+#define DEADLOCK_TESTS_STR "Deadlock Tests"
+#define VM_TESTS_STR "VM Tests"
+
 /**
  *  Open handles for amdgpu devices
  *
@@ -62,49 +72,49 @@ int open_render_node = 0;   /* By default run most tests on 
primary node */
 /** The table of all known test suites to run */
 static CU_SuiteInfo suites[] = {
{
-   .pName = "Basic Tests",
+   .pName = BASIC_TESTS_STR,
.pInitFunc = suite_basic_tests_init,
.pCleanupFunc = suite_basic_tests_clean,
.pTests = basic_tests,
},
{
-   .pName = "BO Tests",
+   .pName = BO_TESTS_STR,
.pInitFunc = suite_bo_tests_init,
.pCleanupFunc = suite_bo_tests_clean,
.pTests = bo_tests,
},
{
-   .pName = "CS Tests",
+   .pName = CS_TESTS_STR,
.pInitFunc = suite_cs_tests_init,
.pCleanupFunc = suite_cs_tests_clean,
.pTests = cs_tests,
},
{
-   .pName = "VCE Tests",
+   .pName = VCE_TESTS_STR,
.pInitFunc = suite_vce_tests_init,
.pCleanupFunc = suite_vce_tests_clean,
.pTests = vce_tests,
},
{
-   .pName = "VCN Tests",
+   .pName = VCN_TESTS_STR,
.pInitFunc = suite_vcn_tests_init,
.pCleanupFunc = suite_vcn_tests_clean,
.pTests = vcn_tests,
},
{
-   .pName = "UVD ENC Tests",
+   .pName = UVD_ENC_TESTS_STR,
.pInitFunc = suite_uvd_enc_tests_init,
.pCleanupFunc = suite_uvd_enc_tests_clean,
.pTests = uvd_enc_tests,
},
{
-   .pName = "Deadlock Tests",
+   .pName = DEADLOCK_TESTS_STR,
.pInitFunc = suite_deadlock_tests_init,
.pCleanupFunc = suite_deadlock_tests_clean,
.pTests = deadlock_tests,
},
{
-   .pName = "VM Tests",
+   .pName = VM_TESTS_STR,
.pInitFunc = suite_vm_tests_init,
.pCleanupFunc = suite_vm_tests_clean,
.pTests = vm_tests,
@@ -113,23 +123,99 @@ static CU_SuiteInfo suites[] = {
CU_SUITE_INFO_NULL,
 };
 
+typedef CU_BOOL (*active__stat_func)(void);
+
+typedef struct Suites_Active_Status {
+   char* pName;
+   active__stat_func pActive;
+}Suites_Active_Status;
+
+static CU_BOOL always_active()
+{
+   return CU_TRUE;
+}
+
+static Suites_Active_Status suites_active_stat[] = {
+   {
+   .pName = BASIC_TESTS_STR,
+   .pActive = always_active,
+   },
+   {
+   .pName = BO_TESTS_STR,
+   .pActive = always_active,
+   },
+   {
+   .pName = CS_TESTS_STR,
+   .pActive = always_active,
+   },
+   {
+   .pName = VCE_TESTS_STR,
+   .pActive = always_active,
+   },
+   {
+   .pName = VCN_TESTS_STR,
+   .pActive = always_active,
+   },
+   {
+   .pName = UVD_ENC_TESTS_STR,
+   .pActive = always_active,
+   },
+   {
+   .pName = DEADLOCK_TESTS_STR,
+   .pActive = always_active,
+   },
+   {
+   .pName = VM_TESTS_STR,
+   .pActive = always_active,
+   },
+};
+
 
-/** Display information about all  suites and their tests */
+/*
+ * Display information about all  suites and their tests
+ *
+ * NOTE: Must be run after registry is initialized and suites registered.
+ */
 static void display_test_suites(void)
 {
int iSuite;
int iTest;
+   CU_pSuite pSuite = NULL;
+   CU_pTe

Re: [PATCH] drm: gem_cma_helper.c: Allow importing of contiguous scatterlists with nents > 1

[Laurent Pinchart]

Hi Liviu,

Thank you for the patch.

On Wednesday, 1 November 2017 16:14:19 EET Liviu Dudau wrote:
> drm_gem_cma_prime_import_sg_table() will fail if the number of entries
> in the sg_table > 1. However, you can have a device that uses an IOMMU
> engine and can map a discontiguous buffer with multiple entries that
> have consecutive sg_dma_addresses, effectively making it contiguous.
> Allow for that scenario by testing the entries in the sg_table for
> contiguous coverage.
> 
> Reviewed-by: Brian Starkey 
> Signed-off-by: Liviu Dudau 
> ---
> 
> Hi,
> 
> This patch is the only change I need in order to be able to use existing
> IOMMU domain infrastructure with the Mali DP driver. I have tested the
> patch and I know it works correctly for my setup, but I would like to get
> some comments on whether I am on the right path or if CMA really wants to
> see an sg_table with only one entry.

CMA, as the memory allocator, doesn't care as it doesn't even see the sg 
table. The drm_gem_cma_helper is badly named as it doesn't depend on CMA, it 
should have been called drm_gem_dma_contig_helper or something similar.

The assumption at the base of that helper library is that the memory is DMA 
contiguous. Your patch guarantees that, so it should be fine. I've quickly 
checked the drivers using drm_gem_cma_prime_import_sg_table and none of them 
use cma_obj->sgt, so I think there's no risk of breakage. However, I would 
prefer if you updated the drm_gem_cma_object structure documentation to 
explicitly state that the sgt can contain multiple entries but that those 
entries are guaranteed to have contiguous DMA addresses.

With the documentation update,

Reviewed-by: Laurent Pinchart 

>  drivers/gpu/drm/drm_gem_cma_helper.c | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c index 020e7668dfaba..43b179212052d
> 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -482,8 +482,26 @@ drm_gem_cma_prime_import_sg_table(struct drm_device
> *dev, {
>   struct drm_gem_cma_object *cma_obj;
> 
> - if (sgt->nents != 1)
> - return ERR_PTR(-EINVAL);
> + if (sgt->nents != 1) {
> + /* check if the entries in the sg_table are contiguous */
> + dma_addr_t next_addr = sg_dma_address(sgt->sgl);
> + struct scatterlist *s;
> + unsigned int i;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + /*
> +  * sg_dma_address(s) is only valid for entries
> +  * that have sg_dma_len(s) != 0
> +  */
> + if (!sg_dma_len(s))
> + continue;
> +
> + if (sg_dma_address(s) != next_addr)
> + return ERR_PTR(-EINVAL);
> +
> + next_addr = sg_dma_address(s) + sg_dma_len(s);
> + }
> + }
> 
>   /* Create a CMA GEM buffer. */
>   cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm vmwgfx and i915 fixes

[Dave Airlie]

Hey Linus,

Last few patches to wrap up.

Two i915 fixes that are on their way to stable, one vmware black
screen bug, and one const patch that I was going to drop, but it was
clearly a pretty safe one liner, if you want I can remove it.

Dave.

The following changes since commit 39dae59d66acd86d1de24294bd2f343fd5e7a625:

  Linux 4.14-rc8 (2017-11-05 13:05:14 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.14-rc9

for you to fetch changes up to 60ccb31bd680469ee0db92b0b6594d79bd13ff87:

  Merge tag 'drm-intel-fixes-2017-11-08' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2017-11-09
11:17:32 +1000)


vmware and i915 fixes


Arvind Yadav (1):
  drm/vmwgfx: constify vmw_fence_ops

Chris Wilson (1):
  drm/i915: Deconstruct struct sgt_dma initialiser

Dave Airlie (2):
  Merge branch 'drm-vmwgfx-fixes' of
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes
  Merge tag 'drm-intel-fixes-2017-11-08' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Sinclair Yeh (1):
  drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue

Tvrtko Ursulin (1):
  drm/i915: Reject unknown syncobj flags

 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  8 
 drivers/gpu/drm/i915/i915_gem_gtt.c| 25 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  2 +-
 include/uapi/drm/i915_drm.h|  1 +
 5 files changed, 20 insertions(+), 18 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:drm-intel-next-queued 1/3] include/linux/compiler.h:276: undefined reference to `__tracepoint_dwc3_writel'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   7f017b19fbce6200a993305425bf930f38fcd9e6
commit: bccd3b831185e75c4138bc3fd5201f3214dfeb3d [1/3] drm/i915: Use 
trace_printk to provide a death rattle for GEM
config: x86_64-randconfig-g0-11100853 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
git checkout bccd3b831185e75c4138bc3fd5201f3214dfeb3d
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/usb/dwc3/core.o: In function `dwc3_event_buffers_setup':
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
   drivers/usb/dwc3/core.o:include/linux/compiler.h:276: more undefined 
references to `__tracepoint_dwc3_writel' follow
   drivers/usb/dwc3/core.o: In function `dwc3_phy_setup':
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'
   drivers/usb/dwc3/core.o: In function `dwc3_core_init':
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_readl'
>> include/linux/compiler.h:276: undefined reference to 
>> `__tracepoint_dwc3_writel'

vim +276 include/linux/compiler.h

d976441f Andrey Ryabinin   2015-10-19  272  
d976441f Andrey Ryabinin   2015-10-19  273  static __always_inline
d976441f Andrey Ryabinin   2015-10-19  274  void __read_once_size(const 
volatile void *p, void *res, int size)
230fa253 Christian Borntraeger 2014-11-25  275  {
d976441f Andrey Ryabinin   2015-10-19 @276  __READ_ONCE_SIZE;
230fa253 Christian Borntraeger 2014-11-25  277  }
d976441f Andrey Ryabinin   2015-10-19  278  

:: The code at line 276 was first introduced by commit
:: d976441f44bc5d48635d081d277aa76556ffbf8b compiler, atomics, kasan: 
Provide READ_ONCE_NOCHECK()

:: TO: Andrey Ryabinin 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Inki Dae]

2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:
> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
> are contiguous, because of the underlying dma_alloc_attrs() function
> provides only such buffers. In such case it makes no sense to keep

What if user disabled CMA support? In this case, it guarantees also to allocate 
physically contiguous memory?
I think it depends on CMA support so wouldn't be true.

Real problem I think is that user don't know whether the gem buffer allocated 
with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer.
So user can request a page flip with NONCONTIG buffer to kernel which doesn't 
support IOMMU.

And another is that user may want to use NONCONTIG buffer for another purpose, 
not scanout.
So if we enforce on using CONTIG buffer on kernel without IOMMU support, then 
it wouldn't be really what user intended.

My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can allocate 
a buffer with a different allocation type - CONTIG or NONCONTIG - according to 
IOMMU support.
And any page flip request with NONCONTIG buffer to kernel without IOMMU support 
should fail and it has to return a error with a proper error message.

> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
> failures for buffer contiguity checks in the subsequent operations on GEM
> objects.
> 
> Signed-off-by: Marek Szyprowski 
> CC: sta...@vger.kernel.org # v4.4+
> ---
> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
> support for exynos drm framework"), but this patch applies cleanly
> only to v4.4+ kernel releases due changes in the surrounding code.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 02f978bb9261..476c00fe1998 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -227,6 +227,13 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
> drm_device *dev,
>   if (IS_ERR(exynos_gem))
>   return exynos_gem;
>  
> + /*
> +  * when no IOMMU is available, all allocated buffers are contiguous
> +  * anyway, so drop EXYNOS_BO_NONCONTIG flag
> +  */
> + if (!is_drm_iommu_supported(dev))
> + flags &= ~EXYNOS_BO_NONCONTIG;

So this could be a tempararily solution until the new flag is added, and you 
may need to modify above comments.

Thanks,
Inki Dae

> +
>   /* set memory type and cache attribute from user side. */
>   exynos_gem->flags = flags;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/vc4: Ensure interrupts are disabled

[Stefan Schake]

The overflow mem work callback vc4_overflow_mem_work reenables its
associated interrupt upon completion. To ensure all interrupts are disabled
when we return from vc4_irq_uninstall, we need to disable it again if
cancel_work_sync indicated pending work.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_irq.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 61b2e53..7d780149d 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -231,7 +231,14 @@
/* Finish any interrupt handler still in flight. */
disable_irq(dev->irq);
 
-   cancel_work_sync(&vc4->overflow_mem_work);
+   if (cancel_work_sync(&vc4->overflow_mem_work)) {
+   /*
+* Work was still pending. The overflow mem work's
+* callback reenables the OUTOMEM interrupt upon
+* completion, so ensure it is disabled here.
+*/
+   V3D_WRITE(V3D_INTDIS, V3D_INT_OUTOMEM);
+   }
 }
 
 /** Reinitializes interrupt registers when a GPU reset is performed. */
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] drm/vc4: Correctly uninstall interrupts

[Stefan Schake]

This set of patches fixes issues with vc4_irq_uninstall.
The first patch fixes a NULL pointer dereference when the binner BO
would disappear during an in flight overflow mem work callback.

The second patch ensures we return with all interrupts disabled. This was
suspected to cause the NULL dereference but turned out to be unrelated.

Tested with a Raspberry Pi CM 3 that was previously stuck in a boot loop
due to the issue. With the patch applied, the NULL dereference was no
longer observed through numerous resets.

Stefan Schake (2):
  drm/vc4: Account for interrupts in flight
  drm/vc4: Ensure interrupts are disabled

 drivers/gpu/drm/vc4/vc4_irq.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/vc4: Account for interrupts in flight

[Stefan Schake]

Synchronously disable the IRQ to make the following cancel_work_sync
invocation effective.

An interrupt in flight could enqueue further overflow mem work. As we
free the binner BO immediately following vc4_irq_uninstall this caused
a NULL pointer dereference in the work callback vc4_overflow_mem_work.

Link: https://github.com/anholt/linux/issues/114
Signed-off-by: Stefan Schake 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
---
 drivers/gpu/drm/vc4/vc4_irq.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 7d7af3a..61b2e53 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -208,6 +208,9 @@
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
 
+   /* Undo the effects of a previous vc4_irq_uninstall. */
+   enable_irq(dev->irq);
+
/* Enable both the render done and out of memory interrupts. */
V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
 
@@ -225,6 +228,9 @@
/* Clear any pending interrupts we might have left. */
V3D_WRITE(V3D_INTCTL, V3D_DRIVER_IRQS);
 
+   /* Finish any interrupt handler still in flight. */
+   disable_irq(dev->irq);
+
cancel_work_sync(&vc4->overflow_mem_work);
 }
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:drm-intel-next-queued 1/3] ucsi.c:undefined reference to `__tracepoint_ucsi_ack'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   7f017b19fbce6200a993305425bf930f38fcd9e6
commit: bccd3b831185e75c4138bc3fd5201f3214dfeb3d [1/3] drm/i915: Use 
trace_printk to provide a death rattle for GEM
config: x86_64-randconfig-s0-11100726 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout bccd3b831185e75c4138bc3fd5201f3214dfeb3d
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/usb/typec/ucsi/ucsi.o: In function `ucsi_ack':
>> ucsi.c:(.text+0x125): undefined reference to `__tracepoint_ucsi_ack'
   ucsi.c:(.text+0x191): undefined reference to `__tracepoint_ucsi_ack'
   drivers/usb/typec/ucsi/ucsi.o: In function `ucsi_reset_ppm':
>> ucsi.c:(.text+0x550): undefined reference to `__tracepoint_ucsi_command'
   ucsi.c:(.text+0x5b0): undefined reference to `__tracepoint_ucsi_command'
>> ucsi.c:(.text+0x64c): undefined reference to `__tracepoint_ucsi_reset_ppm'
   ucsi.c:(.text+0x6db): undefined reference to `__tracepoint_ucsi_command'
   ucsi.c:(.text+0x79e): undefined reference to `__tracepoint_ucsi_command'
   ucsi.c:(.text+0x7dd): undefined reference to `__tracepoint_ucsi_reset_ppm'
   drivers/usb/typec/ucsi/ucsi.o: In function `ucsi_command':
   ucsi.c:(.text+0x9f4): undefined reference to `__tracepoint_ucsi_command'
   ucsi.c:(.text+0xa60): undefined reference to `__tracepoint_ucsi_command'
   drivers/usb/typec/ucsi/ucsi.o: In function `ucsi_run_command':
>> ucsi.c:(.text+0xbfd): undefined reference to `__tracepoint_ucsi_run_command'
   ucsi.c:(.text+0xc6c): undefined reference to `__tracepoint_ucsi_run_command'
   drivers/usb/typec/ucsi/ucsi.o: In function `ucsi_connector_change':
>> ucsi.c:(.text+0x10b5): undefined reference to 
>> `__tracepoint_ucsi_connector_change'
   ucsi.c:(.text+0x1218): undefined reference to 
`__tracepoint_ucsi_connector_change'
   drivers/usb/typec/ucsi/ucsi.o: In function `ucsi_init':
>> ucsi.c:(.text+0x1862): undefined reference to 
>> `__tracepoint_ucsi_register_port'
   ucsi.c:(.text+0x19c7): undefined reference to 
`__tracepoint_ucsi_register_port'
   drivers/usb/typec/ucsi/ucsi.o: In function `ucsi_notify':
>> ucsi.c:(.text+0x1f82): undefined reference to `__tracepoint_ucsi_notify'
   ucsi.c:(.text+0x205d): undefined reference to `__tracepoint_ucsi_notify'
>> drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0x10): undefined reference to 
>> `__tracepoint_ucsi_ack'
>> drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0x28): undefined reference to 
>> `__tracepoint_ucsi_command'
   drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0x40): undefined reference to 
`__tracepoint_ucsi_command'
>> drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0x58): undefined reference to 
>> `__tracepoint_ucsi_reset_ppm'
   drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0x70): undefined reference to 
`__tracepoint_ucsi_command'
>> drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0x88): undefined reference to 
>> `__tracepoint_ucsi_run_command'
>> drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0xa0): undefined reference to 
>> `__tracepoint_ucsi_connector_change'
>> drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0xb8): undefined reference to 
>> `__tracepoint_ucsi_register_port'
>> drivers/usb/typec/ucsi/ucsi.o:(__jump_table+0xd0): undefined reference to 
>> `__tracepoint_ucsi_notify'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

[Sharma, Deepak]

-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com] 
Sent: Monday, October 30, 2017 6:23 AM
To: Sharma, Deepak 
Cc: ML dri-devel ; Deucher, Alexander 
; Stéphane Marchesin 
Subject: Re: [PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

On 26 October 2017 at 00:02, Deepak Sharma  wrote:
> From: Deepak Sharma 
>
> Modify vgem_init to take platform dev as parent in drm_dev_init.
> This will make drm device available at "/sys/devices/platform/vgem"
> in x86 chromebook.
>
Shouldn't one update the drm_dev_init/drm_dev_alloc documentation while doing 
this?
But more importantly, this will change the "unique" string (see 
drm_dev_set_unique).

Sorry I did not get your comment about updating drm_dev_init/drm_dev_alloc 
documentation 
for this change. Do you see any issue if this "unique string " is changed

The topic around it rather convoluted and messy, so please check this change 
doesn't cause subtle regressions.
There's a doc hunk in drm_ioctl.c to begin with, plus userspace such as IGT [1] 
might rely on the current behaviour.

HTH
Emil

[1] https://cgit.freedesktop.org/drm/igt-gpu-tools/

I did run vgem test from IGT to check for regression , do you suspect 
regression in other tests ?

Thanks,
Deepak 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/selftests/mm: Add callsite indicator to common asserts

[Chris Wilson]

The majority of the asserts (validating nodes and ranges) are shared
amongst several subtests. This makes identification of which caller
failed hard; but we uniquely identify them if we include the callsite
into the assertion error message (a single frame stacktrace).

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/selftests/test-drm_mm.c | 46 +++--
 1 file changed, 32 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 7cc935d7b7aa..5f1477329bee 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -59,13 +59,16 @@ static bool assert_no_holes(const struct drm_mm *mm)
drm_mm_for_each_hole(hole, mm, hole_start, hole_end)
count++;
if (count) {
-   pr_err("Expected to find no holes (after reserve), found %lu 
instead\n", count);
+   pr_err("%pS: Expected to find no holes (after reserve), found 
%lu instead\n",
+  __builtin_return_address(0),
+  count);
return false;
}
 
drm_mm_for_each_node(hole, mm) {
if (drm_mm_hole_follows(hole)) {
-   pr_err("Hole follows node, expected none!\n");
+   pr_err("%pS: Hole follows node, expected none!\n",
+  __builtin_return_address(0));
return false;
}
}
@@ -87,7 +90,8 @@ static bool assert_one_hole(const struct drm_mm *mm, u64 
start, u64 end)
drm_mm_for_each_hole(hole, mm, hole_start, hole_end) {
if (start != hole_start || end != hole_end) {
if (ok)
-   pr_err("empty mm has incorrect hole, found 
(%llx, %llx), expect (%llx, %llx)\n",
+   pr_err("%pS: empty mm has incorrect hole, found 
(%llx, %llx), expect (%llx, %llx)\n",
+  __builtin_return_address(0),
   hole_start, hole_end,
   start, end);
ok = false;
@@ -95,7 +99,9 @@ static bool assert_one_hole(const struct drm_mm *mm, u64 
start, u64 end)
count++;
}
if (count != 1) {
-   pr_err("Expected to find one hole, found %lu instead\n", count);
+   pr_err("%pS: Expected to find one hole, found %lu instead\n",
+  __builtin_return_address(0),
+  count);
ok = false;
}
 
@@ -108,40 +114,48 @@ static bool assert_continuous(const struct drm_mm *mm, 
u64 size)
unsigned long n;
u64 addr;
 
-   if (!assert_no_holes(mm))
+   if (!assert_no_holes(mm)) {
+   pr_err("%pS: expected no holes!\n",
+  __builtin_return_address(0));
return false;
+   }
 
n = 0;
addr = 0;
drm_mm_for_each_node(node, mm) {
if (node->start != addr) {
-   pr_err("node[%ld] list out of order, expected %llx 
found %llx\n",
+   pr_err("%pS: node[%ld] list out of order, expected %llx 
found %llx\n",
+  __builtin_return_address(0),
   n, addr, node->start);
return false;
}
 
if (node->size != size) {
-   pr_err("node[%ld].size incorrect, expected %llx, found 
%llx\n",
+   pr_err("%pS: node[%ld].size incorrect, expected %llx, 
found %llx\n",
+  __builtin_return_address(0),
   n, size, node->size);
return false;
}
 
if (drm_mm_hole_follows(node)) {
-   pr_err("node[%ld] is followed by a hole!\n", n);
+   pr_err("%pS: node[%ld] is followed by a hole!\n",
+  __builtin_return_address(0), n);
return false;
}
 
found = NULL;
drm_mm_for_each_node_in_range(check, mm, addr, addr + size) {
if (node != check) {
-   pr_err("lookup return wrong node, expected 
start %llx, found %llx\n",
+   pr_err("%pS: lookup return wrong node, expected 
start %llx, found %llx\n",
+  __builtin_return_address(0),
   node->start, check->start);
return false;
}
found = check;
}
if (!found) {
-   pr_err("lookup failed for node %llx + %llx\n",
+   pr_err("

[PATCH 1/2] lib/rbtree,drm/mm: Add rbtree_replace_node_cached()

[Chris Wilson]

Add a variant of rbtree_replace_node() that maintains the leftmost
cached of struct rbtree_root_cached when replacing nodes within the
rbtree.

As drm_mm is the only rb_replace_node() being used on an interval tree,
the mistake looks fairly self-contained. Furthermore the only user of
drm_mm_replace_node() is its testsuite...

Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
Testcase: igt/drm_mm/replace
Signed-off-by: Chris Wilson 
Cc: Davidlohr Bueso 
Cc: Jérôme Glisse 
Cc: Andrew Morton 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_mm.c |  8 +---
 include/linux/rbtree.h   |  2 ++
 lib/rbtree.c | 10 ++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index eb86bc3f753b..186c4e90cc1c 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -575,21 +575,23 @@ EXPORT_SYMBOL(drm_mm_remove_node);
  */
 void drm_mm_replace_node(struct drm_mm_node *old, struct drm_mm_node *new)
 {
+   struct drm_mm *mm = old->mm;
+
DRM_MM_BUG_ON(!old->allocated);
 
*new = *old;
 
list_replace(&old->node_list, &new->node_list);
-   rb_replace_node(&old->rb, &new->rb, &old->mm->interval_tree.rb_root);
+   rb_replace_node_cached(&old->rb, &new->rb, &mm->interval_tree);
 
if (drm_mm_hole_follows(old)) {
list_replace(&old->hole_stack, &new->hole_stack);
rb_replace_node(&old->rb_hole_size,
&new->rb_hole_size,
-   &old->mm->holes_size);
+   &mm->holes_size);
rb_replace_node(&old->rb_hole_addr,
&new->rb_hole_addr,
-   &old->mm->holes_addr);
+   &mm->holes_addr);
}
 
old->allocated = false;
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index d574361943ea..fcbeed4053ef 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -99,6 +99,8 @@ extern void rb_replace_node(struct rb_node *victim, struct 
rb_node *new,
struct rb_root *root);
 extern void rb_replace_node_rcu(struct rb_node *victim, struct rb_node *new,
struct rb_root *root);
+extern void rb_replace_node_cached(struct rb_node *victim, struct rb_node *new,
+  struct rb_root_cached *root);
 
 static inline void rb_link_node(struct rb_node *node, struct rb_node *parent,
struct rb_node **rb_link)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index ba4a9d165f1b..d3ff682fd4b8 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -603,6 +603,16 @@ void rb_replace_node(struct rb_node *victim, struct 
rb_node *new,
 }
 EXPORT_SYMBOL(rb_replace_node);
 
+void rb_replace_node_cached(struct rb_node *victim, struct rb_node *new,
+   struct rb_root_cached *root)
+{
+   rb_replace_node(victim, new, &root->rb_root);
+
+   if (root->rb_leftmost == victim)
+   root->rb_leftmost = new;
+}
+EXPORT_SYMBOL(rb_replace_node_cached);
+
 void rb_replace_node_rcu(struct rb_node *victim, struct rb_node *new,
 struct rb_root *root)
 {
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Laura Abbott]

On 11/06/2017 07:59 AM, Benjamin Gaignard wrote:

Instead a getting only one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.

Allocation requests will be only allowed if the mask_id
match with device minor.
Query request could be done on any of the devices.



With this patch, sysfs looks like:

$ ls /sys/devices/
breakpoint ion platform software system virtual

From an Ion perspective, you can have

Acked-by: Laura Abbott 

Another Ack for the device model stuff would be good but I'll
assume deafening silence means nobody hates it.

Thanks,
Laura


Signed-off-by: Benjamin Gaignard 
---
  drivers/staging/android/TODO|  1 -
  drivers/staging/android/ion/Kconfig |  7 
  drivers/staging/android/ion/ion-ioctl.c | 18 --
  drivers/staging/android/ion/ion.c   | 62 +
  drivers/staging/android/ion/ion.h   | 15 ++--
  5 files changed, 91 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 687e0ea..8a11931 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -8,7 +8,6 @@ TODO:
  ion/
   - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
 involve putting appropriate bindings in a memory node for Ion to find.
- - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
   - Better test framework (integration with VGEM was suggested)
  
  Please send patches to Greg Kroah-Hartman  and Cc:

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index a517b2d..cb4666e 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,13 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
  
+config ION_LEGACY_DEVICE_API

+   bool "Keep using Ion legacy misc device API"
+   depends on ION
+   help
+ Choose this option to keep using Ion legacy misc device API
+ i.e. /dev/ion
+
  config ION_SYSTEM_HEAP
bool "Ion system heap"
depends on ION
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index e26b786..bb5c77b 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -25,7 +25,8 @@ union ion_ioctl_arg {
struct ion_heap_query query;
  };
  
-static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)

+static int validate_ioctl_arg(struct file *filp,
+ unsigned int cmd, union ion_ioctl_arg *arg)
  {
switch (cmd) {
case ION_IOC_HEAP_QUERY:
@@ -34,6 +35,19 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
arg->query.reserved2 )
return -EINVAL;
break;
+
+   case ION_IOC_ALLOC:
+   {
+   int mask = 1 << iminor(filp->f_inode);
+
+#ifdef CONFIG_ION_LEGACY_DEVICE_API
+   if (imajor(filp->f_inode) == MISC_MAJOR)
+   return 0;
+#endif
+   if (!(arg->allocation.heap_id_mask & mask))
+   return -EINVAL;
+   break;
+   }
default:
break;
}
@@ -69,7 +83,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd)))
return -EFAULT;
  
-	ret = validate_ioctl_arg(cmd, &data);

+   ret = validate_ioctl_arg(filp, cmd, &data);
if (WARN_ON_ONCE(ret))
return ret;
  
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c

index fda9756..2c2568b 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,9 @@
  
  #include "ion.h"
  
+#define ION_DEV_MAX 32

+#define ION_NAME "ion"
+
  static struct ion_device *internal_dev;
  static int heap_id;
  
@@ -535,15 +538,38 @@ static int debug_shrink_get(void *data, u64 *val)

  DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
  
-void ion_device_add_heap(struct ion_heap *heap)

+static struct device ion_bus = {
+   .init_name = ION_NAME,
+};
+
+static struct bus_type ion_bus_type = {
+   .name = ION_NAME,
+};
+
+int ion_device_add_heap(struct ion_heap *heap)
  {
struct dentry *debug_file;
struct ion_device *dev = internal_dev;
+   int ret = 0;
  
  	if (!heap->ops->allocate || !heap->ops->free)

pr_err("%s: can not add heap with invalid ops struct.\n",
   __func__);
  
+	if (heap_id >= ION_DEV_MAX)

+   return -EBUSY;
+
+   heap->ddev.parent = &ion_bus;
+   heap->ddev.bus = &ion_bus_type;

Re: [PATCH v6 1/2] staging: ion: reorder include

[Laura Abbott]

On 11/06/2017 07:59 AM, Benjamin Gaignard wrote:

Put include in alphabetic order



Acked-by: Laura Abbott 


Signed-off-by: Benjamin Gaignard 
---
  drivers/staging/android/ion/ion.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index a7d9b0e..fda9756 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -15,28 +15,28 @@
   *
   */
  
+#include 

+#include 
  #include 
+#include 
  #include 
+#include 
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
+#include 
  #include 
  #include 
-#include 
-#include 
-#include 
-#include 
  
  #include "ion.h"
  



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103654] GL_POINT_SMOOTH not handled

[bugzilla-daemon]

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

Bug ID: 103654
   Summary: GL_POINT_SMOOTH not handled
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: webgeek1...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135359
  --> https://bugs.freedesktop.org/attachment.cgi?id=135359&action=edit
Glut test program for GL_POINT_SMOOTH

I'm working on a legacy system with an RV730, reports as a Radeon E4690, on
RHEL 6.9. The software I'm supporting tries to draw points on a globe (using
the NASA worldwind map software). On fglrx, these render correctly; on mesa,
they render as squares. Close as I can tell, r600 is not handling
GL_POINT_SMOOTH correctly.

I have tested on Fedora all the way to rawhide, which just built mesa 17.3 rc3
and the problem still persists. Attached is a simple glut test I threw together
and tested against swrast, r600, and nva5. Swrast and nva5 render a circle,
r600 renders a square.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

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

--- Comment #18 from Harry Wentland  ---
Can you retest this on either one of the following trees?

Alex's amd-staging-drm-next tree
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

Dave's drm-next-amd-dc-staging
https://cgit.freedesktop.org/~airlied/linux/log/drivers/gpu/drm/amd/amdgpu?h=drm-next-amd-dc-staging

We believe this issue has been fixed but had trouble identifying the fix. We
only had a Dell 5k display to test with. There's a chance this is monitor
specific.

Please build with CONFIG_DRM_AMD_DC_PRE_VEGA or pass the amdgpu.dc=1 module
option and ensure dc is loaded by checking 'dmesg | grep Display'. You should
get the following:

[drm] Display Core initialized!

If the issue still reproduces we might have to give this another try or see if
we can find that HP z27q panel.

Thanks for your help on this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] dma-buf: Silence dma_fence __rcu sparse warnings

[Ville Syrjälä]

On Tue, Nov 07, 2017 at 01:37:10PM +0530, Sumit Semwal wrote:
> Hi Ville,
> 
> On 3 November 2017 at 13:18, Christian König  wrote:
> > Patch #4 is Reviewed-by: Christian König .
> >
> > The rest is Acked-by: Christian König .
> >
> > Regards,
> > Christian.
> >
> >
> > Am 02.11.2017 um 21:03 schrieb Ville Syrjala:
> >>
> >> From: Ville Syrjälä 
> >>
> >> When building drm+i915 I get around 150 lines of sparse noise from
> >> dma_fence __rcu warnings. This series eliminates all of that.
> >>
> >> The first two patches were already posted by Chris, but there wasn't
> >> any real reaction, so I figured I'd repost with a wider Cc list.
> >>
> >> As for the other two patches, I'm no expert on dma_fence and I didn't
> >> spend a lot of time looking at it so I can't be sure I annotated all
> >> the accesses correctly. But I figured someone will scream at me if
> >> I got it wrong ;)
> >>
> >> Cc: Dave Airlie 
> >> Cc: Jason Ekstrand 
> >> Cc: linaro-mm-...@lists.linaro.org
> >> Cc: linux-me...@vger.kernel.org
> >> Cc: Alex Deucher 
> >> Cc: Christian König 
> >> Cc: Sumit Semwal 
> >> Cc: Chris Wilson 
> >>
> >> Chris Wilson (2):
> >>drm/syncobj: Mark up the fence as an RCU protected pointer
> >>dma-buf/fence: Sparse wants __rcu on the object itself
> >>
> >> Ville Syrjälä (2):
> >>drm/syncobj: Use proper methods for accessing rcu protected pointers
> >>dma-buf: Use rcu_assign_pointer() to set rcu protected pointers
> 
> For patches 2 (with Daniel's minor comment) and 4, please feel free to add my
> Acked-by: Sumit Semwal  
> >>
> >>   drivers/dma-buf/reservation.c |  2 +-
> >>   drivers/gpu/drm/drm_syncobj.c | 11 +++
> >>   include/drm/drm_syncobj.h |  2 +-
> >>   include/linux/dma-fence.h |  2 +-
> >>   4 files changed, 10 insertions(+), 7 deletions(-)
> >>
> >
> 
> Best,
> Sumit.

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

Re: [PATCH 0/8] video: fbdev: au1200fb: Fix error handling path of 'au1200fb_drv_probe()'

[Christophe JAILLET]

Le 09/11/2017 à 14:12, Bartlomiej Zolnierkiewicz a écrit :


[...]
* patch description was changed to silence issues reported by checkpatch.pl:

WARNING: 'succesful' may be misspelled - perhaps 'successful'?
#4:
'au1200fb_drv_probe()' can not fail after a succesful call to

Odd. Even if I can not compile, I checkpatch.pl all patches I send.


ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("")' - ie: 'commit 1630d85a8312 ("au1200fb: fix hardcoded IRQ")'
#9:
1630d85a8312 ("au1200fb: fix hardcoded IRQ")
Seen and left as-is. The warning was just because the 'commit' was not 
on the same line of the tag. I didn't think it was important at all.


I guess that I only read the output of this 2nd warning and didn't see 
the first one.



Thanks for the review, correction and acknowledgement.

CJ



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103653] Unreal segfault since gallium/u_threaded: avoid syncs for get_query_result

[bugzilla-daemon]

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

Bug ID: 103653
   Summary: Unreal segfault since gallium/u_threaded: avoid syncs
for get_query_result
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: adf.li...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

R9 285 Tonga, since

commit 244536d3d6b40c1763d1e2b3e7676665afa69101
Author: Nicolai Hähnle 
Date:   Sun Oct 22 17:38:51 2017 +0200

gallium/u_threaded: avoid syncs for get_query_result

Queries should still get marked as flushed when flushes are executed
asynchronously in the driver thread.

To this end, the management of the unflushed_queries list is moved into
the driver thread.

I get a segfault starting Unreal Elemental demo or unreal tournament.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe34f5700 (LWP 7403)]
tc_call_end_query (pipe=0x5301430, payload=0x54c2a48) at
util/u_threaded_context.c:374
374if (!tq->head_unflushed.next)
(gdb) bt
#0  tc_call_end_query (pipe=0x5301430, payload=0x54c2a48) at
util/u_threaded_context.c:374
#1  0x711bfdaf in tc_batch_execute (job=job@entry=0x54c27c0,
thread_index=thread_index@entry=0) at util/u_threaded_context.c:96
#2  0x71083830 in util_queue_thread_func (input=input@entry=0x4c37fe0)
at u_queue.c:271
#3  0x710834d7 in impl_thrd_routine (p=) at
../../include/c11/threads_posix.h:87
#4  0x77bc5434 in start_thread () from /lib/libpthread.so.0
#5  0x76a1206d in clone () from /lib/libc.so.6

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102423] kwin segfaults when Alt+Tabbing with windows thumbnails on AMDGPU

[bugzilla-daemon]

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

Henry Hu  changed:

   What|Removed |Added

 CC||henry.hu...@gmail.com

--- Comment #3 from Henry Hu  ---
I also reported a similar bug to KDE:
https://bugs.kde.org/show_bug.cgi?id=384901
and they sent me upstream.

The backtrace is very similar. On the other hand, I am using the r600 dri
module.
It crashes every time I do alt+tab. I'll try to build with debug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

[Eric Anholt]

Daniel Vetter  writes:

> On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
>> Ville Syrjälä  writes:
>> 
>> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
>> >> Ville Syrjala  writes:
>> >> 
>> >> > From: Ville Syrjälä 
>> >> >
>> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
>> >> > and they get somehow confused when they see a non-zero YQ value.
>> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
>> >> > RGB range.
>> >> >
>> >> > Unfortunately there is no good way to tell whether the sink
>> >> > designer claims to have read CEA-861-F. The CEA extension block
>> >> > revision number has generally been stuck at 3 since forever,
>> >> > and even a very recently manufactured sink might be based on
>> >> > an old design so the manufacturing date doesn't seem like
>> >> > something we can use. In lieu of better information let's
>> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
>> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
>> >> >
>> >> > The alternative would of course be to always set YQ=0. And if
>> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
>> >> > we'll probably have to do.
>> >> 
>> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
>> >> source?
>> >
>> > As long as you stick to < 340 MHz modes you shouldn't have to do
>> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
>> >
>> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
>> > to bridges/encoders to filter out most things that aren't supported?
>> 
>> I had a patch for that at
>> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
>> into trouble with 4k monitors.
>
> Ack on the clock limiting patch, silly that it's stuck. No idea about CEC,
> better for Hans/Boris I guess.

Thanks!


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] drm/ttm: optimize ttm_mem_evict_first v2

[Michel Dänzer]

On 09/11/17 09:59 AM, Christian König wrote:
> Deleted BOs with the same reservation object can be reaped even if they
> can't be reserved.
> 
> v2: rebase and we still need to remove/add the BO from/to the LRU.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 39 +++
>  1 file changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 50a678b504f3..6545c4344684 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -735,20 +735,37 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
> *bo,
>  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>  
>  static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> - uint32_t mem_type,
> - const struct ttm_place *place,
> - bool interruptible,
> - bool no_wait_gpu)
> +struct reservation_object *resv,
> +uint32_t mem_type,
> +const struct ttm_place *place,
> +bool interruptible,
> +bool no_wait_gpu)
>  {
>   struct ttm_bo_global *glob = bdev->glob;
>   struct ttm_mem_type_manager *man = &bdev->man[mem_type];
>   struct ttm_buffer_object *bo;
>   int ret = -EBUSY;
> + bool locked;
>   unsigned i;
>  
>   spin_lock(&glob->lru_lock);
>   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>   list_for_each_entry(bo, &man->lru[i], lru) {
> + if (bo->resv == resv) {
> + if (list_empty(&bo->ddestroy))
> + continue;
> +
> + if (place &&
> + !bdev->driver->eviction_valuable(bo, place))
> + continue;
> +
> + ttm_bo_del_from_lru(bo);

Is this necessary, despite the existing ttm_bo_del_from_lru call before
unlocking the LRU lock? If yes, why isn't this necessary in the bo->resv
!= resv case?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/powerplay: fix copy-n-paste error on vddci_buf index

[Alex Deucher]

On Thu, Nov 9, 2017 at 6:35 AM, Colin King  wrote:
> From: Colin Ian King 
>
> The index to vddci_buf is using profile->ucElbVDDC_Num rather
> than profile->ucElbVDDCI_Num; this looks like a copy-n-paste
> error from previous code for the vddc_buf array and I'm pretty
> sure this is incorrect. Fix this by using the correct variable.
>
> Detected by CoverityScan, CID#1457172 ("Copy-paste error")
>
> Fixes: 970d9804b00d ("drm/amd/powerplay: Add support functions for CI to 
> ppatomctrl.c")
> Signed-off-by: Colin Ian King 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
> index a129bc5b1844..c6febbf0bf69 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
> @@ -1486,7 +1486,7 @@ int atomctrl_get_leakage_vddc_base_on_leakage(struct 
> pp_hwmgr *hwmgr,
> if (vddci_id_buf[i] == virtual_voltage_id) {
> for (j = 0; j < 
> profile->ucLeakageBinNum; j++) {
> if (efuse_voltage_id <= 
> leakage_bin[j]) {
> -   *vddci = vddci_buf[j 
> * profile->ucElbVDDC_Num + i];
> +   *vddci = vddci_buf[j 
> * profile->ucElbVDDCI_Num + i];
> break;
> }
> }
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

[Stefan Agner]

On 2017-11-09 17:49, Noralf Trønnes wrote:
> Den 09.11.2017 15.34, skrev Stefan Agner:
>> On 2017-11-06 20:18, Noralf Trønnes wrote:
>>> Replace driver's code with the generic helpers that do the same thing.
>> Tested using:
>> echo devices > /sys/power/pm_test
>> echo freeze > /sys/power/state
>>
>>
>> Note, currently I do get, but even without this patches, so this is
>> something else:
>>
>> [  930.992433] [ cut here ]
>> [  930.992494] WARNING: CPU: 0 PID: 361 at
>> drivers/gpu/drm/drm_atomic_helper.c:1249
>> drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
>> [  930.992502] [CRTC:28:crtc-0] vblank wait timed out
>>
>>
>> Tested-by: Stefan Agner 
>> Acked-by: Stefan Agner 
>>
>> Will you take the patch through drm-misc?
> 
> Yes if that's fine with you, thanks for testing.

Yes, fine for me!

Thanks,
Stefan

> 
> Noralf.
> 
>> --
>> Stefan
>>
>>
>>
>>> Cc: Stefan Agner 
>>> Cc: Alison Wang 
>>> Signed-off-by: Noralf Trønnes 
>>> ---
>>>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 24 ++--
>>>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
>>>   2 files changed, 6 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> index 58e9e0601a61..1a9ee657bbac 100644
>>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> @@ -27,6 +27,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>> #include "fsl_dcu_drm_crtc.h"
>>>   #include "fsl_dcu_drm_drv.h"
>>> @@ -188,26 +189,17 @@ static struct drm_driver fsl_dcu_drm_driver = {
>>>   static int fsl_dcu_drm_pm_suspend(struct device *dev)
>>>   {
>>> struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
>>> +   int ret;
>>> if (!fsl_dev)
>>> return 0;
>>> disable_irq(fsl_dev->irq);
>>> -   drm_kms_helper_poll_disable(fsl_dev->drm);
>>>   - console_lock();
>>> -   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
>>> -   console_unlock();
>>> -
>>> -   fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
>>> -   if (IS_ERR(fsl_dev->state)) {
>>> -   console_lock();
>>> -   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
>>> -   console_unlock();
>>> -
>>> -   drm_kms_helper_poll_enable(fsl_dev->drm);
>>> +   ret = drm_mode_config_helper_suspend(fsl_dev->drm);
>>> +   if (ret) {
>>> enable_irq(fsl_dev->irq);
>>> -   return PTR_ERR(fsl_dev->state);
>>> +   return ret;
>>> }
>>> clk_disable_unprepare(fsl_dev->pix_clk);
>>> @@ -233,13 +225,9 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
>>> if (fsl_dev->tcon)
>>> fsl_tcon_bypass_enable(fsl_dev->tcon);
>>> fsl_dcu_drm_init_planes(fsl_dev->drm);
>>> -   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
>>>   - console_lock();
>>> -   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
>>> -   console_unlock();
>>> +   drm_mode_config_helper_resume(fsl_dev->drm);
>>>   - drm_kms_helper_poll_enable(fsl_dev->drm);
>>> enable_irq(fsl_dev->irq);
>>> return 0;
>>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> index da9bfd432ca6..93bfb98012d4 100644
>>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> @@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
>>> struct drm_encoder encoder;
>>> struct fsl_dcu_drm_connector connector;
>>> const struct fsl_dcu_soc_data *soc;
>>> -   struct drm_atomic_state *state;
>>>   };
>>> int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/ttm: user reservation object wrappers

[Christian König]

Am 09.11.2017 um 17:50 schrieb Michel Dänzer:

On 09/11/17 09:59 AM, Christian König wrote:

Consistently use the reservation object wrappers instead of accessing
the ww_mutex directly.

Additional to that use the reservation object wrappers directly instead of
calling __ttm_bo_reserve with fixed parameters.

Signed-off-by: Christian König 

[...]


@@ -1823,7 +1823,9 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
return -ERESTARTSYS;
if (!ww_mutex_is_locked(&bo->resv->lock))
goto out_unlock;
-   ret = __ttm_bo_reserve(bo, true, false, NULL);
+   ret = reservation_object_lock_interruptible(bo->resv, NULL);
+   if (ret = -EINTR)
+   ret = -ERESTARTSYS;

Typo in the test, must be

 if (ret == -EINTR)


This bug caused the Xorg process to hang for me when trying to run
glxgears, requiring a hard reboot. Did you accidentally send an untested
version of this patch?
Yeah, just stumbled over this as well. I accidentally merged the fix for 
this into a later patch which I didn't send out yet.


Consider it fixed,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: Convert timers to use timer_setup()

[Bartlomiej Zolnierkiewicz]

On Tuesday, October 24, 2017 08:20:26 AM Kees Cook wrote:

> diff --git a/drivers/video/fbdev/pxa3xx-gcu.c 
> b/drivers/video/fbdev/pxa3xx-gcu.c
> index 933619da1a94..e88447eac32c 100644
> --- a/drivers/video/fbdev/pxa3xx-gcu.c
> +++ b/drivers/video/fbdev/pxa3xx-gcu.c
> @@ -513,16 +513,10 @@ pxa3xx_gcu_mmap(struct file *file, struct 
> vm_area_struct *vma)
>  #ifdef PXA3XX_GCU_DEBUG_TIMER
>  static struct timer_list pxa3xx_gcu_debug_timer;
>  
> -static void pxa3xx_gcu_debug_timedout(unsigned long ptr)
> +static void pxa3xx_gcu_debug_timedout(struct timer_list *unused)
>  {
> - struct pxa3xx_gcu_priv *priv = (struct pxa3xx_gcu_priv *) ptr;
> -
>   QERROR("Timer DUMP");

QERROR() macro is using priv so this code now fails to build.

[ Please compile these timer changes with PXA3XX_GCU_DEBUG and
  PXA3XX_GCU_DEBUG_TIMER defined. ]

Also please port your changes over fbdvev-for-next tree as
currently this patch doesn't apply (fbdev tree contains
"video: fbdev: pxa3xx_gcu: Use setup_timer and mod_timer"
cleanup).

> - /* init the timer structure */
> - init_timer(&pxa3xx_gcu_debug_timer);
> - pxa3xx_gcu_debug_timer.function = pxa3xx_gcu_debug_timedout;
> - pxa3xx_gcu_debug_timer.data = ptr;
>   pxa3xx_gcu_debug_timer.expires = jiffies + 5*HZ; /* one second */
>  
>   add_timer(&pxa3xx_gcu_debug_timer);
> @@ -530,7 +524,9 @@ static void pxa3xx_gcu_debug_timedout(unsigned long ptr)
>  
>  static void pxa3xx_gcu_init_debug_timer(void)
>  {
> - pxa3xx_gcu_debug_timedout((unsigned long) &pxa3xx_gcu_debug_timer);
> + /* init the timer structure */
> + timer_setup(&pxa3xx_gcu_debug_timer, pxa3xx_gcu_debug_timedout, 0);
> + pxa3xx_gcu_debug_timedout(NULL);
>  }
>  #else
>  static inline void pxa3xx_gcu_init_debug_timer(void) {}

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103142] R600g+sb: optimizer apparently stuck in an endless loop

[bugzilla-daemon]

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

--- Comment #6 from Gert Wollny  ---
In debug mode an assertion fires as a reminder that this  patch only works
around the real, yet to be understood bug. For that reason I think it would be
better to keep it open (At least the aforementioned bug #102387 is of a similar
nature).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/ttm: user reservation object wrappers

[Michel Dänzer]

On 09/11/17 09:59 AM, Christian König wrote:
> Consistently use the reservation object wrappers instead of accessing
> the ww_mutex directly.
> 
> Additional to that use the reservation object wrappers directly instead of
> calling __ttm_bo_reserve with fixed parameters.
> 
> Signed-off-by: Christian König 

[...]

> @@ -1823,7 +1823,9 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
>   return -ERESTARTSYS;
>   if (!ww_mutex_is_locked(&bo->resv->lock))
>   goto out_unlock;
> - ret = __ttm_bo_reserve(bo, true, false, NULL);
> + ret = reservation_object_lock_interruptible(bo->resv, NULL);
> + if (ret = -EINTR)
> + ret = -ERESTARTSYS;

Typo in the test, must be

if (ret == -EINTR)


This bug caused the Xorg process to hang for me when trying to run
glxgears, requiring a hard reboot. Did you accidentally send an untested
version of this patch?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

[Noralf Trønnes]

Den 09.11.2017 15.34, skrev Stefan Agner:

On 2017-11-06 20:18, Noralf Trønnes wrote:

Replace driver's code with the generic helpers that do the same thing.

Tested using:
echo devices > /sys/power/pm_test
echo freeze > /sys/power/state


Note, currently I do get, but even without this patches, so this is
something else:

[  930.992433] [ cut here ]
[  930.992494] WARNING: CPU: 0 PID: 361 at
drivers/gpu/drm/drm_atomic_helper.c:1249
drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
[  930.992502] [CRTC:28:crtc-0] vblank wait timed out


Tested-by: Stefan Agner 
Acked-by: Stefan Agner 

Will you take the patch through drm-misc?


Yes if that's fine with you, thanks for testing.

Noralf.


--
Stefan




Cc: Stefan Agner 
Cc: Alison Wang 
Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 24 ++--
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
  2 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 58e9e0601a61..1a9ee657bbac 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "fsl_dcu_drm_crtc.h"

  #include "fsl_dcu_drm_drv.h"
@@ -188,26 +189,17 @@ static struct drm_driver fsl_dcu_drm_driver = {
  static int fsl_dcu_drm_pm_suspend(struct device *dev)
  {
struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
+   int ret;
  
  	if (!fsl_dev)

return 0;
  
  	disable_irq(fsl_dev->irq);

-   drm_kms_helper_poll_disable(fsl_dev->drm);
  
-	console_lock();

-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
-   console_unlock();
-
-   fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
-   if (IS_ERR(fsl_dev->state)) {
-   console_lock();
-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
-
-   drm_kms_helper_poll_enable(fsl_dev->drm);
+   ret = drm_mode_config_helper_suspend(fsl_dev->drm);
+   if (ret) {
enable_irq(fsl_dev->irq);
-   return PTR_ERR(fsl_dev->state);
+   return ret;
}
  
  	clk_disable_unprepare(fsl_dev->pix_clk);

@@ -233,13 +225,9 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
if (fsl_dev->tcon)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
-   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
  
-	console_lock();

-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
+   drm_mode_config_helper_resume(fsl_dev->drm);
  
-	drm_kms_helper_poll_enable(fsl_dev->drm);

enable_irq(fsl_dev->irq);
  
  	return 0;

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index da9bfd432ca6..93bfb98012d4 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
struct drm_encoder encoder;
struct fsl_dcu_drm_connector connector;
const struct fsl_dcu_soc_data *soc;
-   struct drm_atomic_state *state;
  };
  
  int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 08/12] drm/arc: Use drm_gem_cma_print_info()

[Noralf Trønnes]

Den 09.11.2017 16.52, skrev Noralf Trønnes:


Den 07.11.2017 20.31, skrev Alexey Brodkin:

Hi Noralf,

On Tue, 2017-11-07 at 20:13 +0100, Noralf Trønnes wrote:

There is a new core debugfs file that prints fb/gem info:
/dri//framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Alexey Brodkin 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 

I think I acked the previous version but anyways,

Acked-by: Alexey Brodkin 



Indeed you did, but somehow patchwork didn't catch it:
https://patchwork.freedesktop.org/patch/185349/

But the ml did:
https://lists.freedesktop.org/archives/dri-devel/2017-October/156438.html

I use patchwork to respin series because I get all ack/rb applied 
automatically.

Thanks for re-acking :-)



Strange, patchwork didn't get your ack this time either:
https://patchwork.freedesktop.org/patch/186972/

I put your ack here so I don't miss it when I apply the patches:
Acked-by: Alexey Brodkin 

Noralf.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: sis_main: mark expected switch fall-throughs

[Bartlomiej Zolnierkiewicz]

On Wednesday, November 08, 2017 11:10:59 AM Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Addresses-Coverity-ID: 115025
> Addresses-Coverity-ID: 115026
> Addresses-Coverity-ID: 115027
> Addresses-Coverity-ID: 115028
> Signed-off-by: Gustavo A. R. Silva 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: cirrusfb: mark expected switch fall-throughs

[Bartlomiej Zolnierkiewicz]

On Monday, November 06, 2017 04:45:50 PM Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Notice that in this particular case I placed the "fall through" comment
> on its own line, which is what GCC is expecting to find.
> 
> Signed-off-by: Gustavo A. R. Silva 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: aty: radeon_pm: mark expected switch fall-throughs

[Bartlomiej Zolnierkiewicz]

On Monday, November 06, 2017 04:40:01 PM Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: sm501fb: mark expected switch fall-through in sm501fb_blank_crt

[Bartlomiej Zolnierkiewicz]

On Monday, November 06, 2017 04:31:18 PM Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: intelfb: remove redundant variables

[Bartlomiej Zolnierkiewicz]

On Monday, November 06, 2017 01:17:11 PM Colin King wrote:
> From: Colin Ian King 
> 
> Variables err_max, err_target and f_best are being assigned values but
> these are never read, hence they are redundant variables and can be
> removed. Cleans up clang warnings:
> 
> drivers/video/fbdev/intelfb/intelfbhw.c:946:2: warning: Value stored to
> 'err_max' is never read
> drivers/video/fbdev/intelfb/intelfbhw.c:947:2: warning: Value stored to
> 'err_target' is never read
> drivers/video/fbdev/intelfb/intelfbhw.c:995:6: warning: Value stored to
> 'f_best' is never read
> 
> Signed-off-by: Colin Ian King 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 08/12] drm/arc: Use drm_gem_cma_print_info()

[Noralf Trønnes]

Den 07.11.2017 20.31, skrev Alexey Brodkin:

Hi Noralf,

On Tue, 2017-11-07 at 20:13 +0100, Noralf Trønnes wrote:

There is a new core debugfs file that prints fb/gem info:
/dri//framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Alexey Brodkin 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 

I think I acked the previous version but anyways,

Acked-by: Alexey Brodkin 



Indeed you did, but somehow patchwork didn't catch it:
https://patchwork.freedesktop.org/patch/185349/

But the ml did:
https://lists.freedesktop.org/archives/dri-devel/2017-October/156438.html

I use patchwork to respin series because I get all ack/rb applied 
automatically.

Thanks for re-acking :-)

Noralf.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video/fbdev/dnfb: Use common error handling code in dnfb_probe()

[Bartlomiej Zolnierkiewicz]

On Sunday, November 05, 2017 03:43:05 PM SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sun, 5 Nov 2017 14:54:52 +0100
> 
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103142] R600g+sb: optimizer apparently stuck in an endless loop

[bugzilla-daemon]

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

--- Comment #5 from Emil Velikov  ---
Gert, should we close this considering 69eee511c63 ("r600/sb: bail out if
prepare_alu_group() doesn't find a proper scheduling") has landed?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline

[Lothar Waßmann]

Hi,

On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
> Lothar Waßmann  writes:
> 
> > Hi,
> >
> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
> > dysfunctional due to:
> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
> > |Author: Eric Anholt 
> > |Date:   Fri Jun 2 13:25:14 2017 -0700
> > |
> > |drm/bridge: Refactor out the panel wrapper from the lvds-encoder 
> > bridge.
> >
> > Also, there is no in-kernel user of this driver, so that it obviously
> > doesn't get tested in any way. There is only one dts file 
> > (r8a7779-marzen.dts)
> > that instantiates this driver, but it has an incomplete OF graph. The 
> > missing
> > link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or
> > r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in
> > the kernel source.
> >
> > Should the driver be removed or moved to staging, until it is properly
> > fixed?
> 
> I can't see any behavior change about the DT handling in that commit,
> and I didn't intend for there to be any.  Could you help me understand
> what went wrong?
>
With the offending commit applied, the lvds-encoder driver is being
attached to the device associated with the lcd-panel driver's of_node
(panel-simple in my case) rather than the lvds-encoder's of_node.


Lothar Waßmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Jani Nikula]

On Thu, 09 Nov 2017, Luís Mendes  wrote:
> Hi Jani,
>
> I tried:
> git clone git://people.freedesktop.org/~airlied/linux -b drm-next
> --depth=1 --single-branch
>
> I got this:
> EDID isn't loaded from file
>
> # cat /proc/cmdline
> console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
> drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl cma=128M

Please try adding D at the end of your video= parameter to force
connector on. Otherwise it'll do a ddc probe which apparently fails with
your display.

BR,
Jani.

>
> #zcat /proc/config.gz  | grep EDID
> CONFIG_DRM_LOAD_EDID_FIRMWARE=y
> # CONFIG_FIRMWARE_EDID is not set
>
> #cat /sys/class/drm/card1-HDMI-A-1/edid
> 
>
> dmesg output follows below...
>
> Regards,
> Luís Mendes
>
> [7.381500] dwhdmi-imx 12.hdmi: Detected HDMI TX controller
> v1.30a with HDCP (DWC HDMI 3D TX PHY)
> [7.409108] hdmi_set_clk_regenerator:521: dwhdmi-imx 12.hdmi:
> hdmi_set_clk_regenerator: fs=48000Hz ftdms=74.250MHz N=6144 cts=74250
> [7.411001] dw_hdmi_irq:2146: dwhdmi-imx 12.hdmi: EVENT=plugin
> [7.421524] imx-drm display-subsystem: bound 12.hdmi (ops
> dw_hdmi_imx_ops [dw_hdmi_imx])
> [7.481948] dw_hdmi_connector_get_modes:1917: dwhdmi-imx
> 12.hdmi: failed to get edid
> [7.537018] fsl-asoc-card sound: sgtl5000 <-> 2028000.ssi mapping ok
> [7.549254] [ cut here ]
> [7.549303] WARNING: CPU: 2 PID: 219 at
> drivers/gpu/drm/drm_vblank.c:303
> drm_crtc_accurate_vblank_count+0x80/0x84
> [7.549308] This function requires support for accurate vblank timestamps.
> [7.549312] Modules linked in: snd_soc_imx_spdif(+)
> snd_soc_fsl_asoc_card(+) snd_ac97_codec coda videobuf2_dma_contig
> imx_vdoa v4l2_mem2mem videobuf2_vmalloc videobuf2_memops dw_hdmi_imx
> imxdrm(+) dw_hdmi cec etnaviv imx_ipu_v3 binfmt_misc parport_pc ppdev
> lp parport
> [7.549396] CPU: 2 PID: 219 Comm: systemd-udevd Tainted: GW
>   4.14.0-rc7-gd65d313-dirty #1
> [7.549401] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [7.549405] Backtrace:
> [7.549427] [] (dump_backtrace) from []
> (show_stack+0x18/0x1c)
> [7.549436]  r7:c106eed0 r6: r5:600d0193 r4:c106eed0
> [7.549465] [] (show_stack) from []
> (dump_stack+0xac/0xd8)
> [7.549486] [] (dump_stack) from [] (__warn+0xec/0x104)
> [7.549496]  r10:edf56e00 r9:c0527bd8 r8:012f r7:0009
> r6:c0d4fc08 r5:
> [7.549501]  r4:edd15688 r3:
> [7.549514] [] (__warn) from []
> (warn_slowpath_fmt+0x40/0x48)
> [7.549523]  r9:edc2f3e0 r8:0001 r7:edc2f000 r6:
> r5:edc2f000 r4:c0d50064
> [7.549535] [] (warn_slowpath_fmt) from []
> (drm_crtc_accurate_vblank_count+0x80/0x84)
> [7.549540]  r3: r2:c0d50064
> [7.549544]  r4:edc2f000
> [7.549553] [] (drm_crtc_accurate_vblank_count) from
> [] (drm_crtc_arm_vblank_event+0x30/0x64)
> [7.549560]  r7:edc2f000 r6:0001 r5:edc2f000 r4:eeb3e400
> [7.549614] [] (drm_crtc_arm_vblank_event) from
> [] (ipu_crtc_atomic_begin+0x50/0x80 [imxdrm])
> [7.549620]  r5:eeb3e680 r4:edc2b018
> [7.549653] [] (ipu_crtc_atomic_begin [imxdrm]) from
> [] (drm_atomic_helper_commit_planes+0x8c/0x2a8)
> [7.549660]  r5:eeb3e680 r4:0018
> [7.549682] [] (drm_atomic_helper_commit_planes) from
> [] (imx_drm_atomic_commit_tail+0x30/0x144 [imxdrm])
> [7.549691]  r10:edf56e00 r9:edc2f3e0 r8:edfafdf8 r7:edc2f000
> r6:eeb3e680 r5:bf0ab088
> [7.549695]  r4:eeb3e680
> [7.549723] [] (imx_drm_atomic_commit_tail [imxdrm]) from
> [] (commit_tail+0x48/0x8c)
> [7.549732]  r10:edf56e00 r9:edc2f3e0 r8:edfafdf8 r7:edc2f000
> r6: r5:bf0ab088
> [7.549737]  r4:eeb3e680 r3:bf0a8174
> [7.549762] [] (commit_tail) from []
> (drm_atomic_helper_commit+0x140/0x148)
> [7.549780]  r5: r4:eeb3e680
> [7.549820] [] (drm_atomic_helper_commit) from
> [] (drm_atomic_commit+0x54/0x60)
> [7.549843]  r7:eeb3e680 r6:edc2f000 r5:eeb3e680 r4:
> [7.549865] [] (drm_atomic_commit) from []
> (restore_fbdev_mode_atomic+0x19c/0x1f8)
> [7.549874]  r7:eeb3e680 r6:0001 r5:003f r4:00a0
> [7.549886] [] (restore_fbdev_mode_atomic) from
> [] (restore_fbdev_mode+0x30/0x168)
> [7.549895]  r10:edf57800 r9:c17e5a70 r8: r7:edf56e00
> r6:c17e5bc8 r5:edf56ed0
> [7.549899]  r4:edf56e00
> [7.549914] [] (restore_fbdev_mode) from []
> (drm_fb_helper_restore_fbdev_mode_unlocked.part.8+0x28/0x7c)
> [7.549925]  r10:edf57800 r9:c17e5a70 r8: r7:c1022ed8
> r6:c17e5bc8 r5:edf56ed0
> [7.549931]  r4:edf56e00
> [7.549943] []
> (drm_fb_helper_restore_fbdev_mode_unlocked.part.8) from []
> (drm_fb_helper_set_par+0x5c/0x8c)
> [7.549950]  r7:c1022ed8 r6:c17e5bc8 r5:edfe3400 r4:
> [7.549972] [] (drm_fb_helper_set_par) from []
> (fbcon_init+0x564/0x5b0)
> [7.549977]  r5:edfe3400 r4:ee808c00
> [7.549992] [] (fbcon_init) from []
> (visual_init+0xcc/0x114

Re: [PATCH v2 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

[Stefan Agner]

On 2017-11-06 20:18, Noralf Trønnes wrote:
> Replace driver's code with the generic helpers that do the same thing.

Tested using:
echo devices > /sys/power/pm_test
echo freeze > /sys/power/state


Note, currently I do get, but even without this patches, so this is
something else:

[  930.992433] [ cut here ]
[  930.992494] WARNING: CPU: 0 PID: 361 at
drivers/gpu/drm/drm_atomic_helper.c:1249
drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
[  930.992502] [CRTC:28:crtc-0] vblank wait timed out


Tested-by: Stefan Agner 
Acked-by: Stefan Agner 

Will you take the patch through drm-misc?

--
Stefan



> 
> Cc: Stefan Agner 
> Cc: Alison Wang 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 24 ++--
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
>  2 files changed, 6 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 58e9e0601a61..1a9ee657bbac 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "fsl_dcu_drm_crtc.h"
>  #include "fsl_dcu_drm_drv.h"
> @@ -188,26 +189,17 @@ static struct drm_driver fsl_dcu_drm_driver = {
>  static int fsl_dcu_drm_pm_suspend(struct device *dev)
>  {
>   struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
> + int ret;
>  
>   if (!fsl_dev)
>   return 0;
>  
>   disable_irq(fsl_dev->irq);
> - drm_kms_helper_poll_disable(fsl_dev->drm);
>  
> - console_lock();
> - drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
> - console_unlock();
> -
> - fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
> - if (IS_ERR(fsl_dev->state)) {
> - console_lock();
> - drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
> - console_unlock();
> -
> - drm_kms_helper_poll_enable(fsl_dev->drm);
> + ret = drm_mode_config_helper_suspend(fsl_dev->drm);
> + if (ret) {
>   enable_irq(fsl_dev->irq);
> - return PTR_ERR(fsl_dev->state);
> + return ret;
>   }
>  
>   clk_disable_unprepare(fsl_dev->pix_clk);
> @@ -233,13 +225,9 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
>   if (fsl_dev->tcon)
>   fsl_tcon_bypass_enable(fsl_dev->tcon);
>   fsl_dcu_drm_init_planes(fsl_dev->drm);
> - drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
>  
> - console_lock();
> - drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
> - console_unlock();
> + drm_mode_config_helper_resume(fsl_dev->drm);
>  
> - drm_kms_helper_poll_enable(fsl_dev->drm);
>   enable_irq(fsl_dev->irq);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> index da9bfd432ca6..93bfb98012d4 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> @@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
>   struct drm_encoder encoder;
>   struct fsl_dcu_drm_connector connector;
>   const struct fsl_dcu_soc_data *soc;
> - struct drm_atomic_state *state;
>  };
>  
>  int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 3/5] Documentation: Add device tree binding for Goldfish FB driver

[Bartlomiej Zolnierkiewicz]

On Friday, November 03, 2017 06:21:36 PM Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
> 
> Add documentation for DT binding of Goldfish FB driver. The compatible
> string used by OS for binding the driver is "google,goldfish-fb".
> 
> Signed-off-by: Miodrag Dinic 
> Signed-off-by: Goran Ferenc 
> Signed-off-by: Aleksandar Markovic 
> Acked-by: Rob Herring 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fsl-dcu: set DPMS off before initializing connector

[Stefan Agner]

Hi Laurent,

On 2017-11-09 11:45, Laurent Pinchart wrote:
> Hi Stefan,
> 
> Thank you for the patch.
> 
> On Thursday, 9 November 2017 11:14:36 EET Stefan Agner wrote:
> 
> I notice you have changed the subject line. I'm not sure if the new wording 
> is 
> better, as this patch doesn't set DPMS to off, it instead skips setting it 
> manually. How about "drm/fsl-dcu: Don't set connector DPMS property manually" 
> or "drm/fsl-dcu: Don't set DPMS property before initializing connector" ?

In a first version I also added:

connector->dpms = DRM_MODE_DPMS_OFF;

before calling drm_connector_init, but I think this is not really
required so removed it again, but forgot to adjust the subject.

Will reset to "drm/fsl-dcu: Don't set connector DPMS property"

> 
> Additionally, would you mind retaining the authorship of the patch I have 
> originally submitted ?

Yeah, sorry, will send v2 with proper authorship and subject.

--
Stefan


>> Since commit 4a97a3da420b ("drm: Don't update property values for atomic
>> drivers") atomic drivers must not update property values as properties
>> are read from the state instead. To catch remaining users, the
>> drm_object_property_set_value() function now throws a warning when
>> called by atomic drivers on non-immutable properties, and we hit that
>> warning when creating connectors.
>>
>> The easy fix is to just remove the drm_object_property_set_value() as it
>> is used here to set the initial value of the connector's DPMS property
>> to OFF. The DPMS property applies on top of the connector's state crtc
>> pointer (initialized to NULL) that is the main connector on/off control,
>> and should thus default to ON.
>>
>> Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Laurent Pinchart 
>> Signed-off-by: Stefan Agner 
>> ---
>>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
>> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c index
>> edd7d8127d19..c54806d08dd7 100644
>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
>> @@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct
>> fsl_dcu_drm_device *fsl_dev, {
>>  struct drm_encoder *encoder = &fsl_dev->encoder;
>>  struct drm_connector *connector = &fsl_dev->connector.base;
>> -struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
> 
> Oops, I had missed that, sorry.
> 
>>  int ret;
>>
>>  fsl_dev->connector.encoder = encoder;
>> @@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct
>> fsl_dcu_drm_device *fsl_dev, if (ret < 0)
>>  goto err_sysfs;
>>
>> -drm_object_property_set_value(&connector->base,
>> -  mode_config->dpms_property,
>> -  DRM_MODE_DPMS_OFF);
>> -
>>  ret = drm_panel_attach(panel, connector);
>>  if (ret) {
>>  dev_err(fsl_dev->dev, "failed to attach panel\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: remove dead igafb driver

[Bartlomiej Zolnierkiewicz]

On Wednesday, October 18, 2017 04:45:31 PM Ondrej Zary wrote:
> On Wednesday 18 October 2017, David Miller wrote:
> > From: John Paul Adrian Glaubitz 
> > Date: Wed, 18 Oct 2017 15:14:27 +0200
> >
> > > Hi Bartlomiej!
> > >
> > > On 10/18/2017 02:56 PM, Bartlomiej Zolnierkiewicz wrote:
> > >> igafb driver hasn't compiled since at least kernel v2.6.34 as
> > >> commit 6016a363f6b5 ("of: unify phandle name in struct device_node")
> > >> missed updating igafb.c to use dp->phandle instead of dp->node.
> > >
> > > Would it take a lot of work to port the driver to the new interface?
> > >
> > > I'm not sure which SPARC machines use this particular framebuffer, but
> > > my plans are to fix up all these old framebuffer drivers. I have
> > > already
> > > received several Amiga (Zorro) graphics cards for testing the updated
> > > drivers on Amiga.
> > >
> > > It could be that I actually have this particular SPARC framebuffer in
> > > my hardware collection.
> >
> > Unless you have a 32-bit sparc laptop, you don't have a machine that
> > will use this driver.
> 
> There are also some x86 PCI cards using this chip.

Interesting, the driver has never supported x86 (it has always been
SPARC32 specific). Once somebody has the card we can think about adding
proper DRM driver for it (shouldn't be that hard). In the meantime I've
queued the patch removing dead igafb driver for 4.15.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] video: fbdev: au1200fb: Fix error handling path of 'au1200fb_drv_probe()'

[Bartlomiej Zolnierkiewicz]

On Monday, October 16, 2017 09:04:46 PM Christophe JAILLET wrote:
> This patch serie tries to fix several issues found in the error handling
> code of 'au1200fb_drv_probe()'.
> The 5 first patches fixes various issues (double free, missing error code,
> un-released resources on error, incorrect IRQ releasing and incomplete
> error handling path)
> 
> The 3 last patches are just cleanups.
> 
> 
> I've spilt the serie in 8 steps that look logical to me. They could
> also be merged together if preferred.
> 
> 
> These patches are provided as-is and ARE NOT even compile-tested (sorry in
> advance if a patch is broken) because I don't have a cross compiler for MIPS
> and won't install one.
> 
> 
> This serie already goes further that the fixes I usually provide, so
> please excuse me if I missed something or if it is somehow broken and/or
> incomplete.
> 
> ---
> V1 previously posted is patch 3/8 of this serie
> 
> Christophe JAILLET (8):
>   video: fbdev: au1200fb: Fix a potential double free
>   video: fbdev: au1200fb: Return an error code if a memory allocation
> fails
>   video: fbdev: au1200fb: Release some resources if a memory allocation
> fails
>   video: fbdev: au1200fb: Fix error handling path
>   video: fbdev: au1200fb: Fix error handling path
>   video: fbdev: au1200fb: Remove some dead code
>   video: fbdev: au1200fb: Propagate an error code
>   video: fbdev: au1200fb: Style clean up
> 
>  drivers/video/fbdev/au1200fb.c | 43 
> ++
>  1 file changed, 23 insertions(+), 20 deletions(-)

Thanks, I queued all patches for 4.15.

I also did some minor fixes to the patch #4 while merging it:

* patch summary was changed to "video: fbdev: au1200fb: Fix incorrect IRQ
  freeing") to be different from the patch summary of patch #5

* patch description was changed to silence issues reported by checkpatch.pl:

WARNING: 'succesful' may be misspelled - perhaps 'successful'?
#4: 
'au1200fb_drv_probe()' can not fail after a succesful call to

ERROR: Please use git commit description style 'commit <12+ chars of sha1> 
("")' - ie: 'commit 1630d85a8312 ("au1200fb: fix hardcoded IRQ")'
#9: 
1630d85a8312 ("au1200fb: fix hardcoded IRQ")

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [Intel-gfx] [RFC 1/7] drm: Add Plane Degamma properties

[Shankar, Uma]

>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, November 7, 2017 11:40 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC 1/7] drm: Add Plane Degamma properties
>
>On Tue, Nov 07, 2017 at 05:49:56PM +, Brian Starkey wrote:
>>
>>In one of the previous discussions[1] related to per-plane color
>>management, Lionel suggested that the 16-bit color lut entries weren't
>>enough when considering HDR.
>>
>>It might be worth creating a new gamma lut format with 32-bit entries
>>for these new properties, as HDR is very much a real rather than
>>hypothetical concern these days.
>>
>>Thanks,
>>-Brian
>
>Sorry, failed to paste the link:
>
>[1] https://patchwork.kernel.org/patch/9546905/

Thanks for the input Brian and sharing the link with earlier discussions around 
this.
I will try to create a separate LUT structure with 32 bit entries which gets 
used for plane color
features. Not sure what to do for pipe level color since we already use u16 
fields. May be the same
color_lut structure (we can call it color_lut2)  can be used for high precision 
use cases like HDR.

Regards,
Uma Shankar


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] Re: [PATCH v2 00/10] Allwinner H3/H5/A64(DE2) SimpleFB support

[Maxime Ripard]

On Thu, Nov 09, 2017 at 11:17:03AM +, Chris Obbard wrote:
> Hi Everyone,
> 
> What's the status of HDMI/SimpleFB driver for H5?
> 
> I don't see anything related to HDMI in linux-next dts files:
> 
> arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  (example board)
> arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> arch/arm/boot/dts/sunxi-h3-h5.dtsi

It will be part of 4.16 and are not in linux-next (yet).

Maxime

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


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Jani Nikula]

On Thu, 09 Nov 2017, Luís Mendes  wrote:
> I've just applied the referred individual patch to kernel-4.14-rc5 and
> the EDID isn't loaded. dw-hdmi gets no firmware at all.

Sorry, I didn't mean you could just cherry-pick that one commit and make
it work. There were a number of preparatory patches before that, and I
think some cleanups on top.

Please try drm-next to make sure you have it all.

We didn't intend for the commits to be backported, instead we very much
wanted them to get a gradually increasing amount of exposure first to
make sure we don't break stuff.

And as I said elsewhere in the thread, Russell's patch may be relevant
for current Linus' master and stable. We just need to reconciliate how
the two things should work together in drm-next and v4.15 and on.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-next-v2

[Inki Dae]

Hi Dave,

   Just added new IPP driver since previous pull request.

   We rewrited Exynos DRM IPP driver due to below limitations and issues,
   - Userspace API covers memory-2-memory picture operations together with
 CRTC writeback and duplicating features, which belongs to video plane.
   - Lack of support of the all required image formats (for example NV12
 Samsung-tiled cannot be used due to lack of pixel format modifier
 support).
   - Userspace API designed only to mimic hardware behaviour, not easy to
 understand.
   - Lack of proper input validation in the core, drivers also didn't do that
 correctly, so it was possible to set incorrect parameters and easil
 trigger IOMMU fault or memory trash.
   - Drivers were partially disfunctional or supported only a subset of modes.

   There is no user who uses old API excepting Tizen platform[1]
   we are developing, and we will update the platform with new version.

   Sample applications for new version,
   https://www.spinics.net/lists/linux-samsung-soc/msg60498.html
   https://github.com/tobiasjakobi/libdrm/blob/ippv2/exynos/exynos_ipp.c


   Please kindly let me know if there is any problem.

[1] https://www.tizen.org/

Thanks,
Inki Dae

The following changes since commit d65d31388a23b14df9494135ad6c6549a59a3caa:

  Merge tag 'drm-misc-next-fixes-2017-11-07' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-08 05:22:49 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v4.15-v2

for you to fetch changes up to e3e0028489c9eb3f0157f980a078c4197da8f9de:

  drm/exynos: Add driver for Exynos Scaler module (2017-11-09 19:59:22 +0900)


- Improved HDMI and Mixer drivers
  . It moves mode setup and plane update code to commit
like other CRTC drivers
  . It makes mode commit to be called in enable callback only one time
  . some cleanup and fixup to HDMI and Mixer drivers.
  . It adds 1024x768, 1280x1024 and 1366x768 modes support
- Added HDMI audio interface driver
  . As of now, HDMI audio worked on boards with external audio codec connected
in parallel with the HDMI audio transmitter's I2S interface.
This patch is required to support HDMI audio properly.
- Remove old version of Exynos DRM IPP driver and add new version.
- Convert each post processing driver - Rotator, GScaler and FIMC - to new API.


Andrzej Hajda (10):
  drm/exynos/mixer: abstract out output mode setup code
  drm/exynos/mixer: move mode commit to enable callback
  drm/exynos/mixer: move resolution configuration to single function
  drm/exynos/mixer: fix mode validation code
  drm/exynos/mixer: remove mixer_resources sub-structure
  drm/exynos/hdmi: remove redundant mode field
  drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops
  drm/exynos/mixer: pass actual mode on MIXER to encoder
  drm/exynos/hdmi: quirk for support mode timings conversion
  drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes

Andrzej Pietrasiewicz (1):
  drm/exynos: Add driver for Exynos Scaler module

Daniel Drake (1):
  drm/exynos/hdmi: add 85.5MHz pixel clock for v14 HDMI PHY

Marek Szyprowski (5):
  drm/exynos: ipp: Remove Exynos DRM IPP subsystem
  drm/exynos: ipp: Add IPP v2 framework
  drm/exynos: rotator: Convert driver to IPP v2 core API
  drm/exynos: gsc: Convert driver to IPP v2 core API
  drm/exynos: fimc: Convert driver to IPP v2 core API

Sylwester Nawrocki (1):
  drm: exynos: Add driver for HDMI audio interface

 .../devicetree/bindings/gpu/samsung-scaler.txt |   27 +
 drivers/gpu/drm/exynos/Kconfig |   18 +-
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   28 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   15 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   | 1035 +++--
 drivers/gpu/drm/exynos/exynos_drm_fimc.h   |   23 -
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 1063 +++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.h|   24 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c| 2256 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.h|  337 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c|  758 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.h|   19 -
 drivers/gpu/drm/exynos/exynos_drm_scaler.c |  694 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  310 ++-
 drivers/gpu/drm/exynos/exynos_mixer.c  |  460 ++--
 drivers/gpu/drm/exynos/regs-hdmi.h |8 +-
 drivers/gpu/drm/exynos/regs-scaler.h   |  426 
 include/uapi/drm/exynos_drm.h  

[radeon-alex:amd-staging-drm-next 2064/2165] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'; did you mean 'vread'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   c64efcaed73726bd3cfaa46c27768d3331a1ad35
commit: 0bd599b1f523598c05f13a4a562884e82a378c2c [2064/2165] ASoC: AMD: enable 
ACP3x drivers build
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0bd599b1f523598c05f13a4a562884e82a378c2c
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
>> sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 
>> 'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
   sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
>> sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function 
>> 'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
 vwrite
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
>> function 'devm_ioremap'; did you mean 'of_ioremap'? 
>> [-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
 ^~~~
 of_ioremap
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
   ^
   cc1: some warnings being treated as errors

vim +28 sound/soc/amd/raven/acp3x.h

4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  25  
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  26  static inline u32 
rv_readl(void __iomem *base_addr)
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  27  {
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 @28return readl(base_addr 
- ACP3x_PHY_BASE_ADDRESS);
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  29  }
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  30  
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  31  static inline void 
rv_writel(u32 val, void __iomem *base_addr)
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  32  {
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 @33writel(val, base_addr - 
ACP3x_PHY_BASE_ADDRESS);

:: The code at line 28 was first introduced by commit
:: 4eafb0d45ea9ed3fa7f53794c85f831659851d20 ASoC: AMD: add ACP3.0 PCI driver

:: TO: Maruthi Srinivas Bayyavarapu 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/powerplay: fix copy-n-paste error on vddci_buf index

[Colin King]

From: Colin Ian King 

The index to vddci_buf is using profile->ucElbVDDC_Num rather
than profile->ucElbVDDCI_Num; this looks like a copy-n-paste
error from previous code for the vddc_buf array and I'm pretty
sure this is incorrect. Fix this by using the correct variable.

Detected by CoverityScan, CID#1457172 ("Copy-paste error")

Fixes: 970d9804b00d ("drm/amd/powerplay: Add support functions for CI to 
ppatomctrl.c")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
index a129bc5b1844..c6febbf0bf69 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
@@ -1486,7 +1486,7 @@ int atomctrl_get_leakage_vddc_base_on_leakage(struct 
pp_hwmgr *hwmgr,
if (vddci_id_buf[i] == virtual_voltage_id) {
for (j = 0; j < 
profile->ucLeakageBinNum; j++) {
if (efuse_voltage_id <= 
leakage_bin[j]) {
-   *vddci = vddci_buf[j * 
profile->ucElbVDDC_Num + i];
+   *vddci = vddci_buf[j * 
profile->ucElbVDDCI_Num + i];
break;
}
}
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/bridge/sii8620: add DVI mode support

[Maciej Purski]

If the sink device is in HDMI mode, enable infoframe interrupt in scdt
irq handle function else call start_video function immediately, because
in DVI mode, there is no infoframe interrupt provided.

Rename start_hdmi function to start_video and get rid of the old
start_video function. In start_video, if the sink is DVI and mode is
MHL1 or MHl2, write appropriate values to registers else the path
should remain the same as in HDMI mode.

Signed-off-by: Maciej Purski 

---
v2:
- remove redundant defines
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704..bbf5200 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1169,8 +1169,18 @@ static void sii8620_set_infoframes(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_TPI_INFO_B0, buf, ret);
 }
 
-static void sii8620_start_hdmi(struct sii8620 *ctx)
+static void sii8620_start_video(struct sii8620 *ctx)
 {
+   if (!sii8620_is_mhl3(ctx))
+   sii8620_stop_video(ctx);
+
+   if (ctx->sink_type == SINK_DVI && !sii8620_is_mhl3(ctx)) {
+   sii8620_write(ctx, REG_RX_HDMI_CTRL2,
+ VAL_RX_HDMI_CTRL2_DEFVAL);
+   sii8620_write(ctx, REG_TPI_SC, 0);
+   return;
+   }
+
sii8620_write_seq_static(ctx,
REG_RX_HDMI_CTRL2, VAL_RX_HDMI_CTRL2_DEFVAL
| BIT_RX_HDMI_CTRL2_USE_AV_MUTE,
@@ -1229,21 +1239,6 @@ static void sii8620_start_hdmi(struct sii8620 *ctx)
sii8620_set_infoframes(ctx);
 }
 
-static void sii8620_start_video(struct sii8620 *ctx)
-{
-   if (!sii8620_is_mhl3(ctx))
-   sii8620_stop_video(ctx);
-
-   switch (ctx->sink_type) {
-   case SINK_HDMI:
-   sii8620_start_hdmi(ctx);
-   break;
-   case SINK_DVI:
-   default:
-   break;
-   }
-}
-
 static void sii8620_disable_hpd(struct sii8620 *ctx)
 {
sii8620_setbits(ctx, REG_EDID_CTRL, BIT_EDID_CTRL_EDID_PRIME_VALID, 0);
@@ -1945,8 +1940,13 @@ static void sii8620_irq_scdt(struct sii8620 *ctx)
if (stat & BIT_INTR_SCDT_CHANGE) {
u8 cstat = sii8620_readb(ctx, REG_TMDS_CSTAT_P3);
 
-   if (cstat & BIT_TMDS_CSTAT_P3_SCDT)
-   sii8620_scdt_high(ctx);
+   if (cstat & BIT_TMDS_CSTAT_P3_SCDT) {
+   if (ctx->sink_type == SINK_HDMI)
+   /* enable infoframe interrupt */
+   sii8620_scdt_high(ctx);
+   else
+   sii8620_start_video(ctx);
+   }
}
 
sii8620_write(ctx, REG_INTR5, stat);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fsl-dcu: set DPMS off before initializing connector

[Laurent Pinchart]

Hi Stefan,

Thank you for the patch.

On Thursday, 9 November 2017 11:14:36 EET Stefan Agner wrote:

I notice you have changed the subject line. I'm not sure if the new wording is 
better, as this patch doesn't set DPMS to off, it instead skips setting it 
manually. How about "drm/fsl-dcu: Don't set connector DPMS property manually" 
or "drm/fsl-dcu: Don't set DPMS property before initializing connector" ?

Additionally, would you mind retaining the authorship of the patch I have 
originally submitted ?

> Since commit 4a97a3da420b ("drm: Don't update property values for atomic
> drivers") atomic drivers must not update property values as properties
> are read from the state instead. To catch remaining users, the
> drm_object_property_set_value() function now throws a warning when
> called by atomic drivers on non-immutable properties, and we hit that
> warning when creating connectors.
> 
> The easy fix is to just remove the drm_object_property_set_value() as it
> is used here to set the initial value of the connector's DPMS property
> to OFF. The DPMS property applies on top of the connector's state crtc
> pointer (initialized to NULL) that is the main connector on/off control,
> and should thus default to ON.
> 
> Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Laurent Pinchart 
> Signed-off-by: Stefan Agner 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c index
> edd7d8127d19..c54806d08dd7 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct
> fsl_dcu_drm_device *fsl_dev, {
>   struct drm_encoder *encoder = &fsl_dev->encoder;
>   struct drm_connector *connector = &fsl_dev->connector.base;
> - struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;

Oops, I had missed that, sorry.

>   int ret;
> 
>   fsl_dev->connector.encoder = encoder;
> @@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct
> fsl_dcu_drm_device *fsl_dev, if (ret < 0)
>   goto err_sysfs;
> 
> - drm_object_property_set_value(&connector->base,
> -   mode_config->dpms_property,
> -   DRM_MODE_DPMS_OFF);
> -
>   ret = drm_panel_attach(panel, connector);
>   if (ret) {
>   dev_err(fsl_dev->dev, "failed to attach panel\n");

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 85667] GPU lockup when playing H264 video with vlc on Radeon 3850HD and R600_uvd.bin loaded

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #5 from Christian König  ---
This bug is ancient and the original problem long fixed.

If you experience similar problems on newer hardware generation please open a
new bug report.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 85667] GPU lockup when playing H264 video with vlc on Radeon 3850HD and R600_uvd.bin loaded

[bugzilla-daemon]

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

--- Comment #4 from Francois Cartegnie  ---

Lockup after playing field interlaced mpeg2 through hw accel.

https://streams.videolan.org/streams/ts/mpeg2-field-encoded-bff.ts


[84260.161266] radeon :01:00.0: ring 0 stalled for more than 10012msec
[84260.161272] radeon :01:00.0: GPU lockup (current fence id
0x00b8edec last fence id 0x00b8eea5 on ring 0)
[84260.161331] radeon :01:00.0: failed to get a new IB (-35)
[84260.161367] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to get ib !
[84260.569435] radeon :01:00.0: Saved 5911 dwords of commands on ring 0.
[84260.569448] radeon :01:00.0: GPU softreset: 0x0009
[84260.569452] radeon :01:00.0:   GRBM_STATUS   = 0xE5301828
[84260.569455] radeon :01:00.0:   GRBM_STATUS_SE0   = 0xF403
[84260.569459] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0007
[84260.569462] radeon :01:00.0:   SRBM_STATUS   = 0x20C0
[84260.569466] radeon :01:00.0:   SRBM_STATUS2  = 0x
[84260.569470] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[84260.569473] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x00010802
[84260.569477] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x00028006
[84260.569481] radeon :01:00.0:   R_008680_CP_STAT  = 0x80038647
[84260.569484] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[84260.578682] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B
[84260.578740] radeon :01:00.0: SRBM_SOFT_RESET=0x0100
[84260.579904] radeon :01:00.0:   GRBM_STATUS   = 0x3828
[84260.579910] radeon :01:00.0:   GRBM_STATUS_SE0   = 0x0007
[84260.579915] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0007
[84260.579919] radeon :01:00.0:   SRBM_STATUS   = 0x20C0
[84260.579923] radeon :01:00.0:   SRBM_STATUS2  = 0x
[84260.579928] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[84260.579932] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[84260.579935] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[84260.579940] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[84260.579944] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[84260.579958] radeon :01:00.0: GPU reset succeeded, trying to resume
[84260.602221] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[84260.604829] [drm] PCIE GART of 1024M enabled (table at 0x00162000).
[84260.604922] radeon :01:00.0: WB enabled
[84260.604924] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x9253cf1e6c00
[84260.604925] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x4c0c and cpu addr 0x9253cf1e6c0c
[84260.605678] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x00072118 and cpu addr 0xa40fc1632118
[84260.622062] [drm] ring test on 0 succeeded in 2 usecs
[84260.622074] [drm] ring test on 3 succeeded in 8 usecs
[84260.799573] [drm] ring test on 5 succeeded in 2 usecs
[84260.799582] [drm] UVD initialized successfully.
[84261.865301] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed
out.
[84261.865329] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
testing IB on GFX ring (-110).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge/sii8620: filter unsupported modes

[Marek Szyprowski]

The maximum pixel clock depends on the version of the connected MHL
adapter. Add mode_valid callback to filter out modes with too high pixel
clock to avoid failure in mode_fixup later.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704d0a8a..268d66d99337 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2191,6 +2191,19 @@ static void sii8620_detach(struct drm_bridge *bridge)
rc_unregister_device(ctx->rc_dev);
 }
 
+static enum drm_mode_status sii8620_mode_valid(struct drm_bridge *bridge,
+const struct drm_display_mode *mode)
+{
+   struct sii8620 *ctx = bridge_to_sii8620(bridge);
+   bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
+   MHL_DCAP_VID_LINK_PPIXEL;
+   unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
+  MHL1_MAX_LCLK;
+   max_pclk /= can_pack ? 2 : 3;
+
+   return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
+}
+
 static bool sii8620_mode_fixup(struct drm_bridge *bridge,
   const struct drm_display_mode *mode,
   struct drm_display_mode *adjusted_mode)
@@ -2238,6 +2251,7 @@ static const struct drm_bridge_funcs sii8620_bridge_funcs 
= {
.attach = sii8620_attach,
.detach = sii8620_detach,
.mode_fixup = sii8620_mode_fixup,
+   .mode_valid = sii8620_mode_valid,
 };
 
 static int sii8620_probe(struct i2c_client *client,
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Sorry for the commit noise on libdrm

[Christian König]

I've accidentally pushed two incomplete WIP patches to the libdrm master 
repository yesterday.


Just noticed the mistake and reverted the two.

Sorry for the noise,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Jani Nikula]

On Thu, 09 Nov 2017, Russell King - ARM Linux  wrote:
> On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
>> > Parsing the EDID for HDMI and audio information in the get_modes()
>> > callback is incorrect - this only parses the EDID read from the
>> > connector, not any override or firmware provided EDID.
>> > 
>> > The correct place to parse the EDID for these parameters is the
>> > fill_modes() callback, after we've called the helper.  Move the parsing
>> > there.  This caused problems for Luís Mendes.
>> > 
>> > Cc: 
>> > Reported-by: Luís Mendes 
>> > Tested-by: Luís Mendes 
>> > Signed-off-by: Russell King 
>> > ---
>> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 
>> > 
>> >  1 file changed, 24 insertions(+), 4 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> > index 9fe407f49986..2516a1c18a10 100644
>> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> > @@ -1905,10 +1905,7 @@ static int dw_hdmi_connector_get_modes(struct 
>> > drm_connector *connector)
>> >dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
>> >edid->width_cm, edid->height_cm);
>> >  
>> > -  hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
>> > -  hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>> >drm_mode_connector_update_edid_property(connector, edid);
>> > -  cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
>> >ret = drm_add_edid_modes(connector, edid);
>> >/* Store the ELD */
>> >drm_edid_to_eld(connector, edid);
>> > @@ -1920,6 +1917,29 @@ static int dw_hdmi_connector_get_modes(struct 
>> > drm_connector *connector)
>> >return ret;
>> >  }
>> >  
>> > +static int dw_hdmi_connector_fill_modes(struct drm_connector *connector,
>> > +  uint32_t maxX, uint32_t maxY)
>> > +{
>> > +  struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
>> > +  connector);
>> > +  int ret;
>> > +
>> > +  ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
>> > +
>> > +  if (connector->edid_blob_ptr) {
>> > +  struct edid *edid = (void *)connector->edid_blob_ptr->data;
>> > +
>> > +  hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
>> > +  hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>> > +  cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
>> > +  } else {
>> > +  hdmi->sink_is_hdmi = false;
>> > +  hdmi->sink_has_audio = false;
>> > +  }
>> > +
>> > +  return ret;
>> > +}
>> > +
>> >  static void dw_hdmi_connector_force(struct drm_connector *connector)
>> >  {
>> >struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
>> > @@ -1933,7 +1953,7 @@ static void dw_hdmi_connector_force(struct 
>> > drm_connector *connector)
>> >  }
>> >  
>> >  static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
>> > -  .fill_modes = drm_helper_probe_single_connector_modes,
>> > +  .fill_modes = dw_hdmi_connector_fill_modes,
>> 
>> Papering over helper functions shouldn't be necessary, except the helper
>> functions not handling the override edid is a known issue. Jani Nikula is
>> working on a proper fix, please coordinate with him.
>
> So, what you're basically saying is that fixing real bugs that affect
> users is not something that DRM people want.  That's fine, I'll ignore
> people who come to me for help with DRM bugs in future then because
> it's obviously a dead loss.

We may already have fixed the bug in drm-next at the proper
layer. Please see my other mail.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/22] drm/sti: Use drm_fb_cma_fbdev_init/fini()

[Benjamin Gaignard]

2017-11-09 9:20 GMT+01:00 Daniel Vetter :
> On Wed, Nov 08, 2017 at 04:21:04PM +0100, Noralf Trønnes wrote:
>>
>> Den 08.11.2017 13.21, skrev Benjamin Gaignard:
>> > 2017-11-04 14:04 GMT+01:00 Noralf Trønnes :
>> > > Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
>> > > the fact that drm_device holds a pointer to the drm_fb_helper structure.
>> > > This means that the driver doesn't have to keep track of that.
>> > > Also use the drm_fb_helper functions directly.
>> > >
>> > > Cc: Benjamin Gaignard 
>> > > Cc: Vincent Abriou 
>> > > Signed-off-by: Noralf Trønnes 
>> > > ---
>> > >   drivers/gpu/drm/sti/sti_drv.c | 25 +
>> > >   drivers/gpu/drm/sti/sti_drv.h |  1 -
>> > >   2 files changed, 5 insertions(+), 21 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/sti/sti_drv.c 
>> > > b/drivers/gpu/drm/sti/sti_drv.c
>> > > index 9e9343101738..d61efef30a82 100644
>> > > --- a/drivers/gpu/drm/sti/sti_drv.c
>> > > +++ b/drivers/gpu/drm/sti/sti_drv.c
>> > > @@ -17,6 +17,7 @@
>> > >   #include 
>> > >   #include 
>> > >   #include 
>> > > +#include 
>> > >   #include 
>> > >   #include 
>> > >
>> > > @@ -138,16 +139,9 @@ static int sti_atomic_check(struct drm_device *dev,
>> > >  return ret;
>> > >   }
>> > >
>> > > -static void sti_output_poll_changed(struct drm_device *ddev)
>> > > -{
>> > > -   struct sti_private *private = ddev->dev_private;
>> > > -
>> > > -   drm_fbdev_cma_hotplug_event(private->fbdev);
>> > > -}
>> > > -
>> > >   static const struct drm_mode_config_funcs sti_mode_config_funcs = {
>> > >  .fb_create = drm_gem_fb_create,
>> > > -   .output_poll_changed = sti_output_poll_changed,
>> > > +   .output_poll_changed = drm_fb_helper_output_poll_changed,
>> > >  .atomic_check = sti_atomic_check,
>> > >  .atomic_commit = drm_atomic_helper_commit,
>> > >   };
>> > > @@ -230,11 +224,7 @@ static void sti_cleanup(struct drm_device *ddev)
>> > >   {
>> > >  struct sti_private *private = ddev->dev_private;
>> > >
>> > > -   if (private->fbdev) {
>> > > -   drm_fbdev_cma_fini(private->fbdev);
>> > > -   private->fbdev = NULL;
>> > > -   }
>> > > -
>> > > +   drm_fb_cma_fbdev_fini(ddev);
>> > >  drm_kms_helper_poll_fini(ddev);
>> > >  component_unbind_all(ddev->dev, ddev);
>> > >  kfree(private);
>> > > @@ -245,7 +235,6 @@ static int sti_bind(struct device *dev)
>> > >   {
>> > >  struct drm_device *ddev;
>> > >  struct sti_private *private;
>> > > -   struct drm_fbdev_cma *fbdev;
>> > >  int ret;
>> > >
>> > >  ddev = drm_dev_alloc(&sti_driver, dev);
>> > > @@ -268,13 +257,9 @@ static int sti_bind(struct device *dev)
>> > >
>> > >  private = ddev->dev_private;
>> > >  if (ddev->mode_config.num_connector) {
>> > > -   fbdev = drm_fbdev_cma_init(ddev, 32,
>> > > -  
>> > > ddev->mode_config.num_connector);
>> > > -   if (IS_ERR(fbdev)) {
>> > > +   ret = drm_fb_cma_fbdev_init(ddev, 32, 0);
>> > > +   if (ret)
>> > >  DRM_DEBUG_DRIVER("Warning: fails to create 
>> > > fbdev\n");
>> > > -   fbdev = NULL;
>> > > -   }
>> > > -   private->fbdev = fbdev;
>> > >  }
>> > Like for stm driver I think that drm_kms_helper_poll_init() call
>> > should be move after
>> > this block of code.
>>
>> I fail to see how this patchset affects output polling.
>> What kind of problem are you seeing?
>>
>> I think we need to understand what's happening here because more
>> drivers call drm_kms_helper_poll_init() before fbdev init.
>
> That's kinda how you should be doing it - fbdev init needs to probe the
> outputs, if your poll work doesn't work yet then that's not going to pan
> out well. Now afaiui most of the current drivers need polling for fun
> stuff like TV-out or vga, so no one notices.
>
> And it might very well be that it's all 100% cargo-culted and people just
> put it there because everyone else does, not because they actually need
> output polling.
>>
>> These are the various call sequences in the cma helper drivers:
>>
>> arc, hdlcd, kirin, mxsfb, rcar-du, stm, zte:
>>
>> drm_mode_config_reset()
>> drm_kms_helper_poll_init()
>> drm_fbdev_cma_init()
>> drm_dev_register()
>
> This looks reasonable.
>>
>>
>> atmel-hlcdc, imx, meson, pl111, sun4i, tilcdc, tve200:
>>
>> drm_mode_config_reset()
>> drm_fbdev_cma_init()
>> drm_kms_helper_poll_init()
>> drm_dev_register()
>
> Probably they don't really need polling.
>>
>>
>> sti:
>>
>> drm_kms_helper_poll_init()
>> drm_dev_register()
>> drm_mode_config_reset()
>> drm_fbdev_cma_init()
>
> drm_dev_register should be last. Otherwise even looks correct.

I have redo the test, current ordering is working even with the Noralf patches,
no need to change drm_kms_helper_poll_init() location.

Benjamin

>
>> 

[PATCH] drm/fsl-dcu: set DPMS off before initializing connector

[Stefan Agner]

Since commit 4a97a3da420b ("drm: Don't update property values for atomic
drivers") atomic drivers must not update property values as properties
are read from the state instead. To catch remaining users, the
drm_object_property_set_value() function now throws a warning when
called by atomic drivers on non-immutable properties, and we hit that
warning when creating connectors.

The easy fix is to just remove the drm_object_property_set_value() as it
is used here to set the initial value of the connector's DPMS property
to OFF. The DPMS property applies on top of the connector's state crtc
pointer (initialized to NULL) that is the main connector on/off control,
and should thus default to ON.

Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
Cc: sta...@vger.kernel.org
Signed-off-by: Laurent Pinchart 
Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index edd7d8127d19..c54806d08dd7 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device 
*fsl_dev,
 {
struct drm_encoder *encoder = &fsl_dev->encoder;
struct drm_connector *connector = &fsl_dev->connector.base;
-   struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
int ret;
 
fsl_dev->connector.encoder = encoder;
@@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device 
*fsl_dev,
if (ret < 0)
goto err_sysfs;
 
-   drm_object_property_set_value(&connector->base,
- mode_config->dpms_property,
- DRM_MODE_DPMS_OFF);
-
ret = drm_panel_attach(panel, connector);
if (ret) {
dev_err(fsl_dev->dev, "failed to attach panel\n");
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

[Agrawal, Akshu]

On 11/8/2017 11:39 PM, Mark Brown wrote:

On Wed, Nov 08, 2017 at 12:24:03PM -0500, Alex Deucher wrote:


regmap_read(regmap, RT5645_VENDOR_ID2, &val);
  
+	/*

+* Read after 400msec, as it is the interval required between
+* read and power On.
+*/
+   msleep(TIME_TO_POWER_MS);
+   regmap_read(regmap, RT5645_VENDOR_ID2, &val);
+


This leaves the original read in there so we've both got the early read
(which might upset things potentially) and the delayed read.  Shouldn't
we just be adding a msleep() before the existing read?



My bad, I should have removed the addition of register read from the patch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] omapdss: fix problem enabling VDDS_DSI on OMAP3530 (OpenPandora)

[H. Nikolaus Schaller]

Hi Laurent,

> Am 09.11.2017 um 04:45 schrieb Laurent Pinchart 
> :
> 
> Hi Nikolaus,
> 
> Thank you for the patch.
> 
> On Wednesday, 8 November 2017 23:09:32 EET H. Nikolaus Schaller wrote:
>> commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to
>> dpi code")
>> 
>> introduced a new match table which turned out to be wrong, at least
>> for the 600 MHz OpenPandora using the OMAP3530.
>> 
>> The effect was strange: only the Blue channel of the RGB panel was
>> driven while Red and Green stayed black. So a coloured picture turned
>> into blue/black.
>> 
>> The GTA04 with DM3730 didn't show the effect.
>> 
>> It turned out that VDDS_DSI was not properly initialized on OMAP3530,
>> because the .family string is just "OMAP3" for these processors and
>> not "OMAP3xxx".
>> 
>> Therefore we match the .machine attribute.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
> 
> I've already submitted a similar patch (but without the problem pointed out 
> below) in the mail thread where we discussed the issue. It is customary to 
> use 
> the first patch posted (unless it is utterly broken of course).

Ah sorry. My workflow isn't well prepared for that and I already had committed
something to my private branch...

> Could you thus 
> please include it in this series in replacement of this patch ?

Well, you can as well reject my patch (it is just a proposal) and take yours
as a replacement. Especially as you better understand all the potential values
for .family and .machine than me.

Should be less work for both of us.

> 
>> ---
>> drivers/gpu/drm/omapdrm/dss/dpi.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
>> b/drivers/gpu/drm/omapdrm/dss/dpi.c index 4ed5fde11313..aae3626910bb 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
>> @@ -566,8 +566,7 @@ static int dpi_verify_pll(struct dss_pll *pll)
>> }
>> 
>> static const struct soc_device_attribute dpi_soc_devices[] = {
>> -{ .family = "OMAP3[456]*" },
>> -{ .family = "[AD]M37*" },
>> +{ .machine = "OMAP3[456]*" },
> 
> You also need 
> 
>   { .machine = "[AD]M37*" },
> 
> otherwise there will be no match for the OMAP3-like AM37xx and DM37xx SoCs.

Ah, ok. I wasn't aware that there are some AM37 and DM37 chips with and
some without OMAP3 prefix.

> 
> Another option would be to match on { .family = "OMAP3*" } but there could be 
> spurious matches, even though I haven't identified any.
> 
>>  { /* sentinel */ }
>> };
> 

BR and thanks,
Nikolaus Schaller

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

Hi Laurent,

> Am 09.11.2017 um 07:35 schrieb Laurent Pinchart 
> :
> 
> Hi Nikolaus,
> 
> On Thursday, 9 November 2017 08:05:15 EET H. Nikolaus Schaller wrote:
>>> Am 09.11.2017 um 04:33 schrieb Laurent Pinchart:
>>> On Wednesday, 8 November 2017 23:09:29 EET H. Nikolaus Schaller wrote:
 The vendor name was "toppoly" but other panels and the vendor list
 have defined it as "tpo". So let's fix it in driver and bindings.
 
 Signed-off-by: H. Nikolaus Schaller 
 ---
 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} | 4 ++--
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 4
 ++--
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 4
 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename
 Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt
 =>
 tpo,td028ttec1.txt} (84%)
 
 diff --git
 a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
 b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
 similarity index 84%
 rename from
 Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
 rename to
 Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt index
 7175dc3740ac..ed34253d9fb1 100644
 ---
 a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
 +++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
 @@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
 
 
 Required properties:
 -- compatible: "toppoly,td028ttec1"
 +- compatible: "tpo,td028ttec1"
 
 Optional properties:
 - label: a symbolic name for the panel
 @@ -14,7 +14,7 @@ Example
 ---
 
 lcd-panel: td028ttec1@0 {
 -  compatible = "toppoly,td028ttec1";
 +  compatible = "tpo,td028ttec1";
 
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
 
 diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
 b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c index
 0a38a0e8c925..2dab491478c2 100644
 --- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
 +++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
 @@ -452,7 +452,7 @@ static int td028ttec1_panel_remove(struct spi_device
 *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
 -  { .compatible = "omapdss,toppoly,td028ttec1", },
 +  { .compatible = "omapdss,tpo,td028ttec1", },
>>> 
>>> Doesn't this break backward compatibility with existing DT ?
>> 
>> Yes, it does. But I am only aware of the GTA04 which uses it and
>> there is a separate fix).
> 
> DT is supposed to be an ABI. In theory at least, one could boot a GTA04 with 
> an existing DT and a new kernel, and no regression should be noticed.

Yes, indeed...

> There 
> could also be other devices using this panel that you are not aware of.
> 
> For how to apply the theory to real life, I'll defer to Tomi :-)

Yes, Tomi should decide if we should keep the old compatible string in
the driver (in second place so to avoid a speed penalty)...

BR and thanks,
Nikolaus Schaller

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

We can remove the "omapdss," prefix.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
 
lcd: lcd@1 {
reg = <1>;  /* CS1 */
-   compatible ="omapdss,tpo,td043mtea1";
+   compatible ="tpo,td043mtea1";
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00h-0fh) Processors

[Bjorn Helgaas]

[+cc Andy]

On Fri, Nov 03, 2017 at 02:52:41PM +0100, Christian König wrote:
> Just add the extra PCI-ID to the existing fixup.
> 
> Signed-off-by: Christian König 

I folded all these additional devices into the original quirk.

> ---
>  arch/x86/pci/fixup.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 7b6bd76..1d2238d 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -639,7 +639,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
> quirk_apple_mbp_poweroff);
>   * configuring host bridge windows using the _PRS and _SRS methods.
>   *
>   * But this is rarely implemented, so we manually enable a large 64bit BAR 
> for
> - * PCIe device on AMD Family 15h (Models 30h-3fh) Processors here.
> + * PCIe device on AMD Family 15h (Models 00h-0fh, 30h-3fh) Processors here.
>   */
>  static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
>  {
> @@ -696,5 +696,6 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
>   pci_bus_add_resource(dev->bus, res, 0);
>  }
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1601, pci_amd_enable_64bit_bar);
>  
>  #endif
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] Fixes for omapdrm on OpenPandora and GTA04

[H. Nikolaus Schaller]

This patch set fixes vendor names of the panels
and fixes a problem on omapdrm with enabling
VDD_DSI for OMAP3 which is needed for displaying
the Red and Green channel on OMAP3530 (Pandora).

H. Nikolaus Schaller (4):
  omapdrm: fix compatible string for td028ttec1
  DTS: GTA04: fix panel compatibility string
  DTS: Pandora: fix panel compatibility string
  omapdss: fix problem enabling VDDS_DSI on OMAP3530 (OpenPandora)

 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}  | 4 ++--
 arch/arm/boot/dts/omap3-gta04.dtsi| 2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi   | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 4 ++--
 drivers/gpu/drm/omapdrm/dss/dpi.c | 3 +--
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 4 ++--
 6 files changed, 9 insertions(+), 10 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt 
=> tpo,td028ttec1.txt} (84%)

-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

Hi Laurent,

> Am 09.11.2017 um 04:33 schrieb Laurent Pinchart 
> :
> 
> Hi Nikolaus,
> 
> Thank you for the patch.
> 
> On Wednesday, 8 November 2017 23:09:29 EET H. Nikolaus Schaller wrote:
>> The vendor name was "toppoly" but other panels and the vendor list
>> have defined it as "tpo". So let's fix it in driver and bindings.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} | 4 ++--
>> drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 4 ++--
>> drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 4 ++--
>> 3 files changed, 6 insertions(+), 6 deletions(-)
>> rename
>> Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt =>
>> tpo,td028ttec1.txt} (84%)
>> 
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> similarity index 84%
>> rename from
>> Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> rename to
>> Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt index
>> 7175dc3740ac..ed34253d9fb1 100644
>> --- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt @@
>> -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
>> 
>> 
>> Required properties:
>> -- compatible: "toppoly,td028ttec1"
>> +- compatible: "tpo,td028ttec1"
>> 
>> Optional properties:
>> - label: a symbolic name for the panel
>> @@ -14,7 +14,7 @@ Example
>> ---
>> 
>> lcd-panel: td028ttec1@0 {
>> -compatible = "toppoly,td028ttec1";
>> +compatible = "tpo,td028ttec1";
>>  reg = <0>;
>>  spi-max-frequency = <10>;
>>  spi-cpol;
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c index
>> 0a38a0e8c925..2dab491478c2 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> @@ -452,7 +452,7 @@ static int td028ttec1_panel_remove(struct spi_device
>> *spi) }
>> 
>> static const struct of_device_id td028ttec1_of_match[] = {
>> -{ .compatible = "omapdss,toppoly,td028ttec1", },
>> +{ .compatible = "omapdss,tpo,td028ttec1", },
> 
> Doesn't this break backward compatibility with existing DT ?

Yes, it does. But I am only aware of the GTA04 which uses it and
there is a separate fix).

> 
>>  {},
>> };
>> 
>> @@ -471,7 +471,7 @@ static struct spi_driver td028ttec1_spi_driver = {
>> 
>> module_spi_driver(td028ttec1_spi_driver);
>> 
>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>> MODULE_AUTHOR("H. Nikolaus Schaller ");
>> MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
>> MODULE_LICENSE("GPL");
>> diff --git
>> a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
>> b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c index
>> 57e9e146ff74..39e1754746d2 100644
>> --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
>> +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
>> @@ -455,7 +455,7 @@ static int td028ttec1_panel_remove(struct spi_device
>> *spi) }
>> 
>> static const struct of_device_id td028ttec1_of_match[] = {
>> -{ .compatible = "omapdss,toppoly,td028ttec1", },
>> +{ .compatible = "omapdss,tpo,td028ttec1", },
>>  {},
>> };
>> 
>> @@ -474,7 +474,7 @@ static struct spi_driver td028ttec1_spi_driver = {
>> 
>> module_spi_driver(td028ttec1_spi_driver);
>> 
>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>> MODULE_AUTHOR("H. Nikolaus Schaller ");
>> MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
>> MODULE_LICENSE("GPL");
> 
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Vendor string is "tpo" and not "toppoly".

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
 
/* lcd panel */
lcd: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] omapdss: fix problem enabling VDDS_DSI on OMAP3530 (OpenPandora)

[H. Nikolaus Schaller]

commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi 
code")

introduced a new match table which turned out to be wrong, at least
for the 600 MHz OpenPandora using the OMAP3530.

The effect was strange: only the Blue channel of the RGB panel was
driven while Red and Green stayed black. So a coloured picture turned
into blue/black.

The GTA04 with DM3730 didn't show the effect.

It turned out that VDDS_DSI was not properly initialized on OMAP3530,
because the .family string is just "OMAP3" for these processors and
not "OMAP3xxx".

Therefore we match the .machine attribute.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/omapdrm/dss/dpi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 4ed5fde11313..aae3626910bb 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -566,8 +566,7 @@ static int dpi_verify_pll(struct dss_pll *pll)
 }
 
 static const struct soc_device_attribute dpi_soc_devices[] = {
-   { .family = "OMAP3[456]*" },
-   { .family = "[AD]M37*" },
+   { .machine = "OMAP3[456]*" },
{ /* sentinel */ }
 };
 
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()

[Ernst Sjöstrand]

Can't find these anywhere yet, errors still there.

https://patchwork.freedesktop.org/series/31220/

Regards
//Ernst

2017-09-30 10:25 GMT+02:00 Christian König :
> Am 30.09.2017 um 10:13 schrieb Dan Carpenter:
>>
>> We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
>> amdgpu_cs_sysvm_access_required into find_mapping") and now my static
>> checker complains that "r" might not be initialized at the end of the
>> function.  I've reviewed the code, and that seems possible, but it's
>> also possible I may have missed something.
>>
>> Signed-off-by: Dan Carpenter 
>
>
> Good catches, Reviewed-by: Christian König  for
> both patches.
>
>
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> index b46280c1279f..2918de2f39ec 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> @@ -648,7 +648,7 @@ int amdgpu_vce_ring_parse_cs(struct amdgpu_cs_parser
>> *p, uint32_t ib_idx)
>> uint32_t allocated = 0;
>> uint32_t tmp, handle = 0;
>> uint32_t *size = &tmp;
>> -   int i, r, idx = 0;
>> +   int i, r = 0, idx = 0;
>> p->job->vm = NULL;
>> ib->gpu_addr = amdgpu_sa_bo_gpu_addr(ib->sa_bo);
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/virtio: add create_handle support.

[Lepton Wu]

Add create_handle support to virtio fb. Without this, screenshot tool
in chromium OS can't work.

Signed-off-by: Lepton Wu 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index b6d52055a11f..274b4206ca96 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -71,7 +71,19 @@ virtio_gpu_framebuffer_surface_dirty(struct drm_framebuffer 
*fb,
return virtio_gpu_surface_dirty(virtio_gpu_fb, clips, num_clips);
 }
 
+static int
+virtio_gpu_framebuffer_create_handle(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int *handle)
+{
+   struct virtio_gpu_framebuffer *virtio_gpu_fb =
+   to_virtio_gpu_framebuffer(fb);
+
+   return drm_gem_handle_create(file_priv, virtio_gpu_fb->obj, handle);
+}
+
 static const struct drm_framebuffer_funcs virtio_gpu_fb_funcs = {
+   .create_handle = virtio_gpu_framebuffer_create_handle,
.destroy = virtio_gpu_user_framebuffer_destroy,
.dirty = virtio_gpu_framebuffer_surface_dirty,
 };
-- 
2.15.0.403.gc27cc4dac6-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

> Am 09.11.2017 um 04:36 schrieb Laurent Pinchart 
> :
> 
> Hi Nikolaus,
> 
> Thank you for the patch.
> 
> On Wednesday, 8 November 2017 23:09:31 EET H. Nikolaus Schaller wrote:
>> We can remove the "omapdss," prefix.
> 
> I agree but you should explain why.

I can add a sentence if someone helps me to formulate it correctly.
Or Tomi, please add when accepting the patch.

> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> b/arch/arm/boot/dts/omap3-pandora-common.dtsi index
>> 53e007abdc71..64d967ec8c58 100644
>> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> @@ -626,7 +626,7 @@
>> 
>>  lcd: lcd@1 {
>>  reg = <1>;  /* CS1 */
>> -compatible ="omapdss,tpo,td043mtea1";
>> +compatible ="tpo,td043mtea1";
>>  spi-max-frequency = <10>;
>>  spi-cpol;
>>  spi-cpha;
> 
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

[Guenter Roeck]

On Wed, Nov 8, 2017 at 11:35 AM, Alex Deucher  wrote:

> On Wed, Nov 8, 2017 at 2:30 PM, Guenter Roeck  wrote:
> > On Wed, Nov 8, 2017 at 11:18 AM, Deucher, Alexander
> >  wrote:
> >>
> >> > -Original Message-
> >> > From: Mark Brown [mailto:broo...@kernel.org]
> >> > Sent: Wednesday, November 08, 2017 1:48 PM
> >> > To: Alex Deucher
> >> > Cc: amd-gfx list; alsa-de...@alsa-project.org; Maling list - DRI
> >> > developers;
> >> > Mukunda, Vijendar; Liam Girdwood; Takashi Iwai; Guenter Roeck;
> Deucher,
> >> > Alexander
> >> > Subject: Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma
> >> >
> >> > On Wed, Nov 08, 2017 at 01:40:32PM -0500, Alex Deucher wrote:
> >> > > On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown 
> >> > wrote:
> >> >
> >> > > > Like I said in reply to your other mail please don't resubmit
> >> > > > already
> >> > > > applied patches.  The current tip of my topic/amd branch appears
> to
> >> > > > be
> >> > > > this very patch, if there's anything needs changing please send an
> >> > > > incremental patch.
> >> >
> >> > > I'm not seeing this one in your tree either.  This is just a resend
> of
> >> > > Guenter's patch from an hour ago with the chromium stuff removed.
> >> > > Maybe you already applied it in the interim?
> >> >
> >> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
> >> > which was applied at 16:07?
> >>
> >> Yes, this is a fix for that patch.  It fixes a 64 bit division that
> wasn't
> >> properly handled.
> >>
> >
> > In that case, the subject should reflect the problem fixed, the
> description
> > should describe the problem, and there should be a Fixes: tag pointing to
> > the problematic patch.
>
> I updated the patch subject and added a fixes tag when I resent it
> after removing the chrome tags.  The subject could have been bit
> better, but I wasn't sure how far to take it since it wasn't my patch
> originally.
>
>
In such situations, it is probably better to write a new patch with proper
subject and description and add a tag such as "Reported-by:",
"Suggested-by:", or "Originally-from:" to give some credit if you feel
generous. The attempt to retain my ownership caused way more trouble than
it is worth.

Guenter



> Alex
>
> >
> > Sorry, I was not aware that the problematic patch is already pending
> > upstream, or I would have submitted a proper patch upstream myself.
> >
> > Guenter
> >
> >>
> >> Alex
> >>
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

[Jani Nikula]

On Thu, 09 Nov 2017, Jani Nikula  wrote:
> On Wed, 08 Nov 2017, "Gustavo A. R. Silva"  wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Addresses-Coverity-ID: 141432
>> Addresses-Coverity-ID: 141433
>> Addresses-Coverity-ID: 141434
>> Addresses-Coverity-ID: 141435
>> Addresses-Coverity-ID: 141436
>> Signed-off-by: Gustavo A. R. Silva 
>
> Acked-by: Jani Nikula 

More explicitly, the patch looks good, but I'll give others the chance
to chime in before merging. In particular Chris has been doing plenty of
warning fixes lately.

BR,
Jani.


>
>> ---
>>  drivers/gpu/drm/i915/intel_sdvo.c | 11 ++-
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
>> b/drivers/gpu/drm/i915/intel_sdvo.c
>> index 7437944..921e372 100644
>> --- a/drivers/gpu/drm/i915/intel_sdvo.c
>> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
>> @@ -1327,6 +1327,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder 
>> *intel_encoder,
>>  switch (crtc_state->pixel_multiplier) {
>>  default:
>>  WARN(1, "unknown pixel multiplier specified\n");
>> +/* fall through */
>>  case 1: rate = SDVO_CLOCK_RATE_MULT_1X; break;
>>  case 2: rate = SDVO_CLOCK_RATE_MULT_2X; break;
>>  case 4: rate = SDVO_CLOCK_RATE_MULT_4X; break;
>> @@ -2274,15 +2275,15 @@ intel_sdvo_guess_ddc_bus(struct intel_sdvo *sdvo)
>>   */
>>  switch (sdvo->controlled_output) {
>>  case SDVO_OUTPUT_LVDS1:
>> -mask |= SDVO_OUTPUT_LVDS1;
>> +mask |= SDVO_OUTPUT_LVDS1; /* fall through */
>>  case SDVO_OUTPUT_LVDS0:
>> -mask |= SDVO_OUTPUT_LVDS0;
>> +mask |= SDVO_OUTPUT_LVDS0; /* fall through */
>>  case SDVO_OUTPUT_TMDS1:
>> -mask |= SDVO_OUTPUT_TMDS1;
>> +mask |= SDVO_OUTPUT_TMDS1; /* fall through */
>>  case SDVO_OUTPUT_TMDS0:
>> -mask |= SDVO_OUTPUT_TMDS0;
>> +mask |= SDVO_OUTPUT_TMDS0; /* fall through */
>>  case SDVO_OUTPUT_RGB1:
>> -mask |= SDVO_OUTPUT_RGB1;
>> +mask |= SDVO_OUTPUT_RGB1; /* fall through */
>>  case SDVO_OUTPUT_RGB0:
>>  mask |= SDVO_OUTPUT_RGB0;
>>  break;

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: add clut mode support

[Peter Rosin]

On 2017-11-07 16:53, Philippe CORNU wrote:
> + Peter
> 
> Hi Peter,
> 
> CLUT support on STM32 has been removed thanks to your clean up patch 

Support is a bit strong for what I thought was a dead function, or
are you saying that it used to work before my series? Really sorry
if that is the case!

Anyway, the function I removed seemed to indicate that the hardware
could handle a separate clut for each layer, but your new version
does not. Why is that?

Cheers,
peda

> named "drm: stm: remove dead code and pointless local lut storage" 
> (https://patchwork.freedesktop.org/patch/166898/)
> 
> This below patch puts back the clut mode support using the new drm gamma 
> api.
> 
> May I ask you please a short review on this patch?
> 
> Many thanks,
> Philippe :-)
> 
> 
> On 10/26/2017 01:17 PM, Philippe Cornu wrote:
>> Add the 8-bit clut mode support at crtc level.
>> Useful for low memory footprint user interfaces but also for
>> 8-bit old games (including color shifting visual effects).
>> Tested with fbdev FBIOPUTCMAP & drm DRM_IOCTL_MODE_SETGAMMA
>> ioctls.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>   drivers/gpu/drm/stm/ltdc.c | 30 ++
>>   1 file changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 7be6710..d5c8a42 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -174,6 +174,8 @@
>>   
>>   #define LXCFBLNR_CFBLN GENMASK(10, 0)  /* Color Frame Buffer Line 
>> Number */
>>   
>> +#define CLUT_SIZE   256
>> +
>>   #define CONSTA_MAX 0xFF/* CONSTant Alpha MAX= 1.0 */
>>   #define BF1_PAXCA  0x600   /* Pixel Alpha x Constant Alpha */
>>   #define BF1_CA 0x400   /* Constant Alpha */
>> @@ -362,6 +364,28 @@ static irqreturn_t ltdc_irq(int irq, void *arg)
>>* DRM_CRTC
>>*/
>>   
>> +static void ltdc_crtc_update_clut(struct drm_crtc *crtc)
>> +{
>> +struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>> +struct drm_color_lut *lut;
>> +u32 val;
>> +int i;
>> +
>> +if (!crtc || !crtc->state)
>> +return;
>> +
>> +if (!crtc->state->color_mgmt_changed || !crtc->state->gamma_lut)
>> +return;
>> +
>> +lut = (struct drm_color_lut *)crtc->state->gamma_lut->data;
>> +
>> +for (i = 0; i < CLUT_SIZE; i++, lut++) {
>> +val = ((lut->red << 8) & 0xff) | (lut->green & 0xff00) |
>> +(lut->blue >> 8) | (i << 24);
>> +reg_write(ldev->regs, LTDC_L1CLUTWR, val);
>> +}
>> +}
>> +
>>   static void ltdc_crtc_atomic_enable(struct drm_crtc *crtc,
>>  struct drm_crtc_state *old_state)
>>   {
>> @@ -485,6 +509,8 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
>>   
>>  DRM_DEBUG_ATOMIC("\n");
>>   
>> +ltdc_crtc_update_clut(crtc);
>> +
>>  /* Commit shadow registers = update planes at next vblank */
>>  reg_set(ldev->regs, LTDC_SRCR, SRCR_VBR);
>>   
>> @@ -532,6 +558,7 @@ void ltdc_crtc_disable_vblank(struct drm_device *ddev, 
>> unsigned int pipe)
>>  .reset = drm_atomic_helper_crtc_reset,
>>  .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>>  .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>> +.gamma_set = drm_atomic_helper_legacy_gamma_set,
>>   };
>>   
>>   /*
>> @@ -764,6 +791,9 @@ static int ltdc_crtc_init(struct drm_device *ddev, 
>> struct drm_crtc *crtc)
>>   
>>  drm_crtc_helper_add(crtc, >   
>> +drm_mode_crtc_set_gamma_size(crtc, CLUT_SIZE);
>> +drm_crtc_enable_color_mgmt(crtc, 0, false, CLUT_SIZE);
>> +
>>  DRM_DEBUG_DRIVER("CRTC:%d created\n", crtc->base.id);
>>   
>>  /* Add planes. Note : the first layer is used by primary plane */

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: fbdev: sis_main: mark expected switch fall-throughs

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 115025
Addresses-Coverity-ID: 115026
Addresses-Coverity-ID: 115027
Addresses-Coverity-ID: 115028
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/sis/sis_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/video/fbdev/sis/sis_main.c 
b/drivers/video/fbdev/sis/sis_main.c
index e923038..ecdd054 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -1702,6 +1702,7 @@ static intsisfb_ioctl(struct fb_info *info, 
unsigned int cmd,
if(ivideo->warncount++ < 10)
printk(KERN_INFO
"sisfb: Deprecated ioctl call received - update 
your application!\n");
+   /* fall through */
   case SISFB_GET_INFO:  /* For communication with X driver */
ivideo->sisfb_infoblock.sisfb_id = SISFB_ID;
ivideo->sisfb_infoblock.sisfb_version= VER_MAJOR;
@@ -1755,6 +1756,7 @@ static intsisfb_ioctl(struct fb_info *info, 
unsigned int cmd,
if(ivideo->warncount++ < 10)
printk(KERN_INFO
"sisfb: Deprecated ioctl call received - update 
your application!\n");
+   /* fall through */
   case SISFB_GET_VBRSTATUS:
if(sisfb_CheckVBRetrace(ivideo))
return put_user((u32)1, argp);
@@ -1765,6 +1767,7 @@ static intsisfb_ioctl(struct fb_info *info, 
unsigned int cmd,
if(ivideo->warncount++ < 10)
printk(KERN_INFO
"sisfb: Deprecated ioctl call received - update 
your application!\n");
+   /* fall through */
   case SISFB_GET_AUTOMAXIMIZE:
if(ivideo->sisfb_max)
return put_user((u32)1, argp);
@@ -1775,6 +1778,7 @@ static intsisfb_ioctl(struct fb_info *info, 
unsigned int cmd,
if(ivideo->warncount++ < 10)
printk(KERN_INFO
"sisfb: Deprecated ioctl call received - update 
your application!\n");
+   /* fall through */
   case SISFB_SET_AUTOMAXIMIZE:
if(get_user(gpu32, argp))
return -EFAULT;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 141432
Addresses-Coverity-ID: 141433
Addresses-Coverity-ID: 141434
Addresses-Coverity-ID: 141435
Addresses-Coverity-ID: 141436
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 7437944..921e372 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1327,6 +1327,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder 
*intel_encoder,
switch (crtc_state->pixel_multiplier) {
default:
WARN(1, "unknown pixel multiplier specified\n");
+   /* fall through */
case 1: rate = SDVO_CLOCK_RATE_MULT_1X; break;
case 2: rate = SDVO_CLOCK_RATE_MULT_2X; break;
case 4: rate = SDVO_CLOCK_RATE_MULT_4X; break;
@@ -2274,15 +2275,15 @@ intel_sdvo_guess_ddc_bus(struct intel_sdvo *sdvo)
 */
switch (sdvo->controlled_output) {
case SDVO_OUTPUT_LVDS1:
-   mask |= SDVO_OUTPUT_LVDS1;
+   mask |= SDVO_OUTPUT_LVDS1; /* fall through */
case SDVO_OUTPUT_LVDS0:
-   mask |= SDVO_OUTPUT_LVDS0;
+   mask |= SDVO_OUTPUT_LVDS0; /* fall through */
case SDVO_OUTPUT_TMDS1:
-   mask |= SDVO_OUTPUT_TMDS1;
+   mask |= SDVO_OUTPUT_TMDS1; /* fall through */
case SDVO_OUTPUT_TMDS0:
-   mask |= SDVO_OUTPUT_TMDS0;
+   mask |= SDVO_OUTPUT_TMDS0; /* fall through */
case SDVO_OUTPUT_RGB1:
-   mask |= SDVO_OUTPUT_RGB1;
+   mask |= SDVO_OUTPUT_RGB1; /* fall through */
case SDVO_OUTPUT_RGB0:
mask |= SDVO_OUTPUT_RGB0;
break;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

[Guenter Roeck]

On Wed, Nov 8, 2017 at 9:24 AM, Alex Deucher  wrote:

> From: Guenter Roeck 
>
> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
>
> 64-bit divides require special operations to avoid build errors on 32-bit
> systems.
>
> BUG=b:63121716
> TEST="Build i386:allmodconfig"
>
>
Is this an upstream submission ? Fine with me, but it should not include
any chromium specific tags, neither in the subject not in the description.

Guenter


> Signed-off-by: Guenter Roeck 
> Reviewed-on: https://chromium-review.googlesource.com/678919
> Reviewed-by: Jason Clinton 
> (cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
> Reviewed-on: https://chromium-review.googlesource.com/681618
> Signed-off-by: Alex Deucher 
> ---
>  sound/soc/amd/acp-pcm-dma.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
> index 13d040a4d26f..ef7e98ad960c 100644
> --- a/sound/soc/amd/acp-pcm-dma.c
> +++ b/sound/soc/amd/acp-pcm-dma.c
> @@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
> snd_pcm_substream *substream)
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> if (bytescount > rtd->renderbytescount)
> bytescount = bytescount - rtd->renderbytescount;
> -   pos =  bytescount % buffersize;
> } else {
> if (bytescount > rtd->capturebytescount)
> bytescount = bytescount - rtd->capturebytescount;
> -   pos = bytescount % buffersize;
> }
> +   pos = do_div(bytescount, buffersize);
> return bytes_to_frames(runtime, pos);
>  }
>
> --
> 2.13.6
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

The vendor name was "toppoly" but other panels and the vendor list
have defined it as "tpo". So let's fix it in driver and bindings.

Signed-off-by: H. Nikolaus Schaller 
---
 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}  | 4 ++--
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 4 ++--
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt 
=> tpo,td028ttec1.txt} (84%)

diff --git 
a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt 
b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
similarity index 84%
rename from 
Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
rename to Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
index 7175dc3740ac..ed34253d9fb1 100644
--- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
+++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
@@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
 
 
 Required properties:
-- compatible: "toppoly,td028ttec1"
+- compatible: "tpo,td028ttec1"
 
 Optional properties:
 - label: a symbolic name for the panel
@@ -14,7 +14,7 @@ Example
 ---
 
 lcd-panel: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index 0a38a0e8c925..2dab491478c2 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -452,7 +452,7 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
-   { .compatible = "omapdss,toppoly,td028ttec1", },
+   { .compatible = "omapdss,tpo,td028ttec1", },
{},
 };
 
@@ -471,7 +471,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:toppoly,td028ttec1");
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index 57e9e146ff74..39e1754746d2 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -455,7 +455,7 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
-   { .compatible = "omapdss,toppoly,td028ttec1", },
+   { .compatible = "omapdss,tpo,td028ttec1", },
{},
 };
 
@@ -474,7 +474,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:toppoly,td028ttec1");
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
-- 
2.12.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH v3 05/12] drm/i915: Use drm_fb_helper_output_poll_changed()

[Noralf Trønnes]

Den 06.11.2017 23.48, skrev Noralf Trønnes:

This driver can use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---

I'm resending to get a CI run.


This didin't trigger a CI run, anyone know why?

Noralf.



Noralf.

  drivers/gpu/drm/i915/intel_display.c | 2 +-
  drivers/gpu/drm/i915/intel_drv.h | 5 -
  drivers/gpu/drm/i915/intel_fbdev.c   | 8 
  3 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f780f39e0758..b205e2c782bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14123,7 +14123,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)
  static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
.get_format_info = intel_get_format_info,
-   .output_poll_changed = intel_fbdev_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
.atomic_state_alloc = intel_atomic_state_alloc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 463ed152e6b1..dfcf5ba220e8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1607,7 +1607,6 @@ extern void intel_fbdev_initial_config_async(struct 
drm_device *dev);
  extern void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
  extern void intel_fbdev_fini(struct drm_i915_private *dev_priv);
  extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool 
synchronous);
-extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
  extern void intel_fbdev_restore_mode(struct drm_device *dev);
  #else
  static inline int intel_fbdev_init(struct drm_device *dev)
@@ -1631,10 +1630,6 @@ static inline void intel_fbdev_set_suspend(struct 
drm_device *dev, int state, bo
  {
  }
  
-static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)

-{
-}
-
  static inline void intel_fbdev_restore_mode(struct drm_device *dev)
  {
  }
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index f2bb8116227c..35babbadfc5a 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -796,14 +796,6 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
state, bool synchronous
console_unlock();
  }
  
-void intel_fbdev_output_poll_changed(struct drm_device *dev)

-{
-   struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
-
-   if (ifbdev)
-   drm_fb_helper_hotplug_event(&ifbdev->helper);
-}
-
  void intel_fbdev_restore_mode(struct drm_device *dev)
  {
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/ttm: remove ttm_bo_unreserve_ticket

[Christian König]

Just another alias for ttm_bo_unreserve.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c |  2 +-
 include/drm/ttm/ttm_bo_driver.h   | 13 -
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 2170534101ca..dedd58fee67b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -349,7 +349,7 @@ validate_fini_no_ticket(struct validate_op *op, struct 
nouveau_fence *fence,
 
list_del(&nvbo->entry);
nvbo->reserved_by = NULL;
-   ttm_bo_unreserve_ticket(&nvbo->bo, &op->ticket);
+   ttm_bo_unreserve(&nvbo->bo);
drm_gem_object_unreference_unlocked(&nvbo->gem);
}
 }
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 3659cf6150d2..cba1477aa983 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -957,19 +957,6 @@ static inline void ttm_bo_unreserve(struct 
ttm_buffer_object *bo)
reservation_object_unlock(bo->resv);
 }
 
-/**
- * ttm_bo_unreserve_ticket
- * @bo: A pointer to a struct ttm_buffer_object.
- * @ticket: ww_acquire_ctx used for reserving
- *
- * Unreserve a previous reservation of @bo made with @ticket.
- */
-static inline void ttm_bo_unreserve_ticket(struct ttm_buffer_object *bo,
-  struct ww_acquire_ctx *t)
-{
-   ttm_bo_unreserve(bo);
-}
-
 /*
  * ttm_bo_util.c
  */
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

[Christian König]

Needed for the next patch.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 52 
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6f5d18366e6e..50a678b504f3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -486,20 +486,21 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
 }
 
 /**
- * function ttm_bo_cleanup_refs_and_unlock
+ * function ttm_bo_cleanup_refs
  * If bo idle, remove from delayed- and lru lists, and unref.
  * If not idle, do nothing.
  *
  * Must be called with lru_lock and reservation held, this function
- * will drop both before returning.
+ * will drop the lru lock and optionally the reservation lock before returning.
  *
  * @interruptible Any sleeps should occur interruptibly.
  * @no_wait_gpu   Never wait for gpu. Return -EBUSY instead.
+ * @unlock_resv   Unlock the reservation lock as well.
  */
 
-static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
- bool interruptible,
- bool no_wait_gpu)
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+  bool interruptible, bool no_wait_gpu,
+  bool unlock_resv)
 {
struct ttm_bo_global *glob = bo->glob;
struct reservation_object *resv;
@@ -518,7 +519,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
if (ret && !no_wait_gpu) {
long lret;
 
-   reservation_object_unlock(bo->resv);
+   if (unlock_resv)
+   reservation_object_unlock(bo->resv);
spin_unlock(&glob->lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true,
@@ -531,19 +533,22 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return -EBUSY;
 
spin_lock(&glob->lru_lock);
-   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
-
-   /*
-* We raced, and lost, someone else holds the reservation now,
-* and is probably busy in ttm_bo_cleanup_memtype_use.
-*
-* Even if it's not the case, because we finished waiting any
-* delayed destruction would succeed, so just return success
-* here.
-*/
-   if (ret) {
-   spin_unlock(&glob->lru_lock);
-   return 0;
+   if (unlock_resv) {
+   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
+   /*
+* We raced, and lost, someone else holds the 
reservation now,
+* and is probably busy in ttm_bo_cleanup_memtype_use.
+*
+* Even if it's not the case, because we finished 
waiting any
+* delayed destruction would succeed, so just return 
success
+* here.
+*/
+   if (ret) {
+   spin_unlock(&glob->lru_lock);
+   return 0;
+   }
+   } else {
+   ret = 0;
}
}
 
@@ -600,8 +605,8 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
}
 
if (!ret)
-   ret = ttm_bo_cleanup_refs_and_unlock(entry, false,
-!remove_all);
+   ret = ttm_bo_cleanup_refs(entry, false, !remove_all,
+ true);
else
spin_unlock(&glob->lru_lock);
 
@@ -770,8 +775,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
kref_get(&bo->list_kref);
 
if (!list_empty(&bo->ddestroy)) {
-   ret = ttm_bo_cleanup_refs_and_unlock(bo, interruptible,
-no_wait_gpu);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}
@@ -1735,7 +1739,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
kref_get(&bo->list_kref);
 
if (!list_empty(&bo->ddestroy)) {
-   ret = ttm_bo_cleanup_refs_and_unlock(bo, false, false);
+   ret = ttm_bo_cleanup_refs(bo, false, false, true);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}
-- 
2.11.0

___
dri-devel mailing list
dri-devel@

[PATCH 4/7] drm/ttm: user reservation object wrappers

[Christian König]

Consistently use the reservation object wrappers instead of accessing
the ww_mutex directly.

Additional to that use the reservation object wrappers directly instead of
calling __ttm_bo_reserve with fixed parameters.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c| 16 +---
 include/drm/ttm/ttm_bo_driver.h |  6 +++---
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6f55310a9d09..6f5d18366e6e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -446,7 +446,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
}
 
spin_lock(&glob->lru_lock);
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
if (!ret) {
if (reservation_object_test_signaled_rcu(&bo->ttm_resv, true)) {
ttm_bo_del_from_lru(bo);
@@ -531,7 +531,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return -EBUSY;
 
spin_lock(&glob->lru_lock);
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
 
/*
 * We raced, and lost, someone else holds the reservation now,
@@ -592,10 +592,10 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
kref_get(&nentry->list_kref);
}
 
-   ret = __ttm_bo_reserve(entry, false, true, NULL);
+   ret = reservation_object_trylock(entry->resv) ? 0 : -EBUSY;
if (remove_all && ret) {
spin_unlock(&glob->lru_lock);
-   ret = __ttm_bo_reserve(entry, false, false, NULL);
+   ret = reservation_object_lock(entry->resv, NULL);
spin_lock(&glob->lru_lock);
}
 
@@ -744,7 +744,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
if (ret)
continue;
 
@@ -1719,7 +1719,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &glob->swap_lru[i], swap) {
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
if (!ret)
break;
}
@@ -1823,7 +1823,9 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
return -ERESTARTSYS;
if (!ww_mutex_is_locked(&bo->resv->lock))
goto out_unlock;
-   ret = __ttm_bo_reserve(bo, true, false, NULL);
+   ret = reservation_object_lock_interruptible(bo->resv, NULL);
+   if (ret = -EINTR)
+   ret = -ERESTARTSYS;
if (unlikely(ret != 0))
goto out_unlock;
reservation_object_unlock(bo->resv);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 389359a0006b..3659cf6150d2 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -836,14 +836,14 @@ static inline int __ttm_bo_reserve(struct 
ttm_buffer_object *bo,
if (WARN_ON(ticket))
return -EBUSY;
 
-   success = ww_mutex_trylock(&bo->resv->lock);
+   success = reservation_object_trylock(bo->resv);
return success ? 0 : -EBUSY;
}
 
if (interruptible)
-   ret = ww_mutex_lock_interruptible(&bo->resv->lock, ticket);
+   ret = reservation_object_lock_interruptible(bo->resv, ticket);
else
-   ret = ww_mutex_lock(&bo->resv->lock, ticket);
+   ret = reservation_object_lock(bo->resv, ticket);
if (ret == -EINTR)
return -ERESTARTSYS;
return ret;
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm/ttm: optimize ttm_mem_evict_first v2

[Christian König]

Deleted BOs with the same reservation object can be reaped even if they
can't be reserved.

v2: rebase and we still need to remove/add the BO from/to the LRU.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 50a678b504f3..6545c4344684 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -735,20 +735,37 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
*bo,
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   uint32_t mem_type,
-   const struct ttm_place *place,
-   bool interruptible,
-   bool no_wait_gpu)
+  struct reservation_object *resv,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  bool interruptible,
+  bool no_wait_gpu)
 {
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+   bool locked;
unsigned i;
 
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
+   if (bo->resv == resv) {
+   if (list_empty(&bo->ddestroy))
+   continue;
+
+   if (place &&
+   !bdev->driver->eviction_valuable(bo, place))
+   continue;
+
+   ttm_bo_del_from_lru(bo);
+
+   ret = 0;
+   locked = false;
+   break;
+   }
+
ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
if (ret)
continue;
@@ -760,6 +777,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
continue;
}
 
+   locked = true;
break;
}
 
@@ -775,7 +793,8 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
kref_get(&bo->list_kref);
 
if (!list_empty(&bo->ddestroy)) {
-   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu,
+ locked);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}
@@ -786,7 +805,10 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
BUG_ON(ret != 0);
 
ret = ttm_bo_evict(bo, interruptible, no_wait_gpu);
-   ttm_bo_unreserve(bo);
+   if (locked)
+   ttm_bo_unreserve(bo);
+   else
+   ttm_bo_add_to_lru(bo);
 
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
@@ -850,7 +872,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type, place,
+   ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place,
  interruptible, no_wait_gpu);
if (unlikely(ret != 0))
return ret;
@@ -1353,7 +1375,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, 
false);
+   ret = ttm_mem_evict_first(bdev, NULL, mem_type, NULL,
+ false, false);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/ttm: move unlocking out of ttm_bo_cleanup_memtype_use

[Christian König]

Needed for the next patch and makes the code quite a bit easier to
understand.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c088703777e2..9905cf41cba6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -390,8 +390,6 @@ static void ttm_bo_cleanup_memtype_use(struct 
ttm_buffer_object *bo)
ttm_tt_destroy(bo->ttm);
bo->ttm = NULL;
ttm_bo_mem_put(bo, &bo->mem);
-
-   ww_mutex_unlock (&bo->resv->lock);
 }
 
 static int ttm_bo_individualize_resv(struct ttm_buffer_object *bo)
@@ -457,6 +455,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
reservation_object_unlock(&bo->ttm_resv);
 
ttm_bo_cleanup_memtype_use(bo);
+   reservation_object_unlock(bo->resv);
return;
}
 
@@ -559,6 +558,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
 
spin_unlock(&glob->lru_lock);
ttm_bo_cleanup_memtype_use(bo);
+   reservation_object_unlock(bo->resv);
 
return 0;
 }
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] dma-buf: add reservation_object_lock_interruptible()

[Christian König]

That's the only wrapper function missing and necessary to cleanup TTM.

Signed-off-by: Christian König 
---
 include/linux/reservation.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 21fc84d82d41..02166e815afb 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -167,6 +167,29 @@ reservation_object_lock(struct reservation_object *obj,
 }
 
 /**
+ * reservation_object_lock_interruptible - lock the reservation object
+ * @obj: the reservation object
+ * @ctx: the locking context
+ *
+ * Locks the reservation object interruptible for exclusive access and
+ * modification. Note, that the lock is only against other writers, readers
+ * will run concurrently with a writer under RCU. The seqlock is used to
+ * notify readers if they overlap with a writer.
+ *
+ * As the reservation object may be locked by multiple parties in an
+ * undefined order, a #ww_acquire_ctx is passed to unwind if a cycle
+ * is detected. See ww_mutex_lock() and ww_acquire_init(). A reservation
+ * object may be locked by itself by passing NULL as @ctx.
+ */
+static inline int
+reservation_object_lock_interruptible(struct reservation_object *obj,
+ struct ww_acquire_ctx *ctx)
+{
+   return ww_mutex_lock_interruptible(&obj->lock, ctx);
+}
+
+
+/**
  * reservation_object_trylock - trylock the reservation object
  * @obj: the reservation object
  *
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] drm/ttm: consistently use reservation_object_unlock

[Christian König]

Instead of having a confusing wrapper or call the underlying ww_mutex
function directly.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/qxl/qxl_release.c  |  2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   | 13 +++--
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  8 
 include/drm/ttm/ttm_bo_driver.h| 14 +-
 4 files changed, 13 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index e6ec845b5be0..a5acd723be41 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -469,7 +469,7 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)
 
reservation_object_add_shared_fence(bo->resv, &release->base);
ttm_bo_add_to_lru(bo);
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
spin_unlock(&glob->lru_lock);
ww_acquire_fini(&release->ticket);
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9905cf41cba6..6f55310a9d09 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -471,7 +471,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
ttm_bo_add_to_lru(bo);
}
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
if (bo->resv != &bo->ttm_resv)
reservation_object_unlock(&bo->ttm_resv);
@@ -517,7 +517,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
 
if (ret && !no_wait_gpu) {
long lret;
-   ww_mutex_unlock(&bo->resv->lock);
+
+   reservation_object_unlock(bo->resv);
spin_unlock(&glob->lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true,
@@ -547,7 +548,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
}
 
if (ret || unlikely(list_empty(&bo->ddestroy))) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
spin_unlock(&glob->lru_lock);
return ret;
}
@@ -749,7 +750,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
 
if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
ret = -EBUSY;
continue;
}
@@ -1788,7 +1789,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
 * already swapped buffer.
 */
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
 }
@@ -1825,7 +1826,7 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
ret = __ttm_bo_reserve(bo, true, false, NULL);
if (unlikely(ret != 0))
goto out_unlock;
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
 
 out_unlock:
mutex_unlock(&bo->wu_mutex);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 5e1bcabffef5..373ced0b2fc2 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -38,7 +38,7 @@ static void ttm_eu_backoff_reservation_reverse(struct 
list_head *list,
list_for_each_entry_continue_reverse(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
 }
 
@@ -69,7 +69,7 @@ void ttm_eu_backoff_reservation(struct ww_acquire_ctx *ticket,
struct ttm_buffer_object *bo = entry->bo;
 
ttm_bo_add_to_lru(bo);
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
spin_unlock(&glob->lru_lock);
 
@@ -112,7 +112,7 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
 
ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), ticket);
if (!ret && unlikely(atomic_read(&bo->cpu_writers) > 0)) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
 
ret = -EBUSY;
 
@@ -203,7 +203,7 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx 
*ticket,
else
reservation_object_add_excl_fence(bo->resv, fence);
ttm_bo_add_to_lru(bo);
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
spin_unlock(&glob->lru_lock);
if (ticket)
diff --git a/include

[PATCH] drm/atomic-helper: always track connector commits, too

[Daniel Vetter]

It's useful for syncing async connector work like link retraining.

v2: Make it work (Manasi&Ville)

Cc: Manasi Navare 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c18c271e7508..ced1ac8e68a0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1793,11 +1793,8 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,

!try_wait_for_completion(&old_conn_state->commit->flip_done))
return -EBUSY;
 
-   /* commit tracked through new_crtc_state->commit, no need to do 
it explicitly */
-   if (new_conn_state->crtc)
-   continue;
-
-   commit = crtc_or_fake_commit(state, old_conn_state->crtc);
+   /* Always track connectors explicitly for e.g. link retraining. 
*/
+   commit = crtc_or_fake_commit(state, new_conn_state->crtc ?: 
old_conn_state->crtc);
if (!commit)
return -ENOMEM;
 
@@ -1811,10 +1808,7 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,

!try_wait_for_completion(&old_plane_state->commit->flip_done))
return -EBUSY;
 
-   /*
-* Unlike connectors, always track planes explicitly for
-* async pageflip support.
-*/
+   /* Always track planes explicitly for async pageflip support. */
commit = crtc_or_fake_commit(state, new_plane_state->crtc ?: 
old_plane_state->crtc);
if (!commit)
return -ENOMEM;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 06/15] drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()

[Inki Dae]

2017년 10월 31일 19:28에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Oct 30, 2017 at 04:39:42PM +0100, Noralf Trønnes wrote:
>> This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
>> It can also use drm_fb_helper_output_poll_changed() as its
>> .output_poll_changed callback.
>>
>> Cc: Inki Dae 
>> Cc: Joonyoung Shim 
>> Cc: Seung-Woo Kim 
>> Cc: Kyungmin Park 
>> Signed-off-by: Noralf Trønnes 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++--
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 --
>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
>>  4 files changed, 3 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index e651a58c18cf..70f4895ac49c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  
>> @@ -89,11 +90,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
>> struct drm_file *file)
>>  file->driver_priv = NULL;
>>  }
>>  
>> -static void exynos_drm_lastclose(struct drm_device *dev)
>> -{
>> -exynos_drm_fbdev_restore_mode(dev);
>> -}
>> -
>>  static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
>>  .fault = exynos_drm_gem_fault,
>>  .open = drm_gem_vm_open,
>> @@ -140,7 +136,7 @@ static struct drm_driver exynos_drm_driver = {
>>  .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME
>>| DRIVER_ATOMIC | DRIVER_RENDER,
>>  .open   = exynos_drm_open,
>> -.lastclose  = exynos_drm_lastclose,
>> +.lastclose  = drm_fb_helper_lastclose,
>>  .postclose  = exynos_drm_postclose,
>>  .gem_free_object_unlocked = exynos_drm_gem_free_object,
>>  .gem_vm_ops = &exynos_drm_gem_vm_ops,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> index 8208df56a88f..0faaf829f5bf 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -205,7 +205,7 @@ static struct drm_mode_config_helper_funcs 
>> exynos_drm_mode_config_helpers = {
>>  
>>  static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
>>  .fb_create = exynos_user_fb_create,
>> -.output_poll_changed = exynos_drm_output_poll_changed,
>> +.output_poll_changed = drm_fb_helper_output_poll_changed,
>>  .atomic_check = exynos_atomic_check,
>>  .atomic_commit = drm_atomic_helper_commit,
>>  };
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index dfb66ecf417b..132dd52d0ac7 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -270,24 +270,6 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
>>  private->fb_helper = NULL;
>>  }
>>  
>> -void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
>> -{
>> -struct exynos_drm_private *private = dev->dev_private;
>> -
>> -if (!private || !private->fb_helper)
> 
> Not sure this isn't risky, exynos has a strange load sequence ... Probably
> best if we get an ack from Inki.

I didn't test this patch on real hardware due to below two issues,
1. many warning messages printed out at vblank period.
   - to finalize atomic flush drm_crtc_arm_vblank_event function is called but 
Exynos drm driver has no implementation of get_vblank_timestamp and 
get_scanout_position callbacks.
2. tranferring Panel commands to Panel device - s6e3ha2 Panel device - timed 
out when exynos_drm_fbdev_restore_mode is called. 

So I just looked into this patch and looks good to me.
Only a difference between old and new helper functions is above condition - 
checking if private and private->fb_helper are null or not.
And dev->dev_private and private->fb_helper are cleared after calling 
drm_dev_unregister function which calls drm_fb_helpaer_lastclose function so it 
must be no problem.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> -Daniel
>> -return;
>> -
>> -drm_fb_helper_restore_fbdev_mode_unlocked(private->fb_helper);
>> -}
>> -
>> -void exynos_drm_output_poll_changed(struct drm_device *dev)
>> -{
>> -struct exynos_drm_private *private = dev->dev_private;
>> -struct drm_fb_helper *fb_helper = private->fb_helper;
>> -
>> -drm_fb_helper_hotplug_event(fb_helper);
>> -}
>> -
>>  void exynos_drm_fbdev_suspend(struct drm_device *dev)
>>  {
>>  struct exynos_drm_private *private = dev->dev_private;
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
>> index 645d1bb7f665..b33847223a85 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
>> 

[PATCH] drm/bridge/sii8620: add DVI mode support

[Maciej Purski]

If the sink device is in HDMI mode, enable infoframe interrupt in scdt
irq handle function else call start_video function immediately, because
in DVI mode, there is no infoframe interrupt provided.

Rename start_hdmi function to start_video and get rid of the old
start_video function. In start_video, if the sink is DVI and mode is
MHL1 or MHl2, write appropriate values to registers else the path
should remain the same as in HDMI mode.

Signed-off-by: Maciej Purski 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 37 ++--
 drivers/gpu/drm/bridge/sil-sii8620.h |  2 ++
 2 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704..657a453 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1169,8 +1169,19 @@ static void sii8620_set_infoframes(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_TPI_INFO_B0, buf, ret);
 }
 
-static void sii8620_start_hdmi(struct sii8620 *ctx)
+static void sii8620_start_video(struct sii8620 *ctx)
 {
+   if (!sii8620_is_mhl3(ctx))
+   sii8620_stop_video(ctx);
+
+   if (ctx->sink_type == SINK_DVI && !sii8620_is_mhl3(ctx)) {
+   sii8620_write(ctx, REG_RX_HDMI_CTRL2,
+ VAL_RX_HDMI_CTRL2_DEFVAL_DVI);
+   sii8620_write(ctx, REG_TPI_SC,
+ BIT_TPI_SC_TPI_OUTPUT_MODE_0_DVI);
+   return;
+   }
+
sii8620_write_seq_static(ctx,
REG_RX_HDMI_CTRL2, VAL_RX_HDMI_CTRL2_DEFVAL
| BIT_RX_HDMI_CTRL2_USE_AV_MUTE,
@@ -1229,21 +1240,6 @@ static void sii8620_start_hdmi(struct sii8620 *ctx)
sii8620_set_infoframes(ctx);
 }
 
-static void sii8620_start_video(struct sii8620 *ctx)
-{
-   if (!sii8620_is_mhl3(ctx))
-   sii8620_stop_video(ctx);
-
-   switch (ctx->sink_type) {
-   case SINK_HDMI:
-   sii8620_start_hdmi(ctx);
-   break;
-   case SINK_DVI:
-   default:
-   break;
-   }
-}
-
 static void sii8620_disable_hpd(struct sii8620 *ctx)
 {
sii8620_setbits(ctx, REG_EDID_CTRL, BIT_EDID_CTRL_EDID_PRIME_VALID, 0);
@@ -1945,8 +1941,13 @@ static void sii8620_irq_scdt(struct sii8620 *ctx)
if (stat & BIT_INTR_SCDT_CHANGE) {
u8 cstat = sii8620_readb(ctx, REG_TMDS_CSTAT_P3);
 
-   if (cstat & BIT_TMDS_CSTAT_P3_SCDT)
-   sii8620_scdt_high(ctx);
+   if (cstat & BIT_TMDS_CSTAT_P3_SCDT) {
+   if (ctx->sink_type == SINK_HDMI)
+   /* enable infoframe interrupt */
+   sii8620_scdt_high(ctx);
+   else
+   sii8620_start_video(ctx);
+   }
}
 
sii8620_write(ctx, REG_INTR5, stat);
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.h 
b/drivers/gpu/drm/bridge/sil-sii8620.h
index 51ab540..c2f19b80 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.h
+++ b/drivers/gpu/drm/bridge/sil-sii8620.h
@@ -554,6 +554,7 @@
 #define REG_RX_HDMI_CTRL2  0x02a3
 #define MSK_RX_HDMI_CTRL2_IDLE_CNT 0xf0
 #define VAL_RX_HDMI_CTRL2_IDLE_CNT(n)  ((n) << 4)
+#define VAL_RX_HDMI_CTRL2_DEFVAL_DVI   0x30
 #define BIT_RX_HDMI_CTRL2_USE_AV_MUTE  BIT(3)
 #define BIT_RX_HDMI_CTRL2_VSI_MON_SEL_VSI  BIT(0)
 
@@ -1024,6 +1025,7 @@
 #define BIT_TPI_SC_TPI_AV_MUTE BIT(3)
 #define BIT_TPI_SC_DDC_GPU_REQUEST BIT(2)
 #define BIT_TPI_SC_DDC_TPI_SW  BIT(1)
+#define BIT_TPI_SC_TPI_OUTPUT_MODE_0_DVI   BIT(1)
 #define BIT_TPI_SC_TPI_OUTPUT_MODE_0_HDMI  BIT(0)
 
 /* TPI COPP Query Data, default value: 0x00 */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/mode_object: fix documentation for object lookups.

[Daniel Vetter]

On Thu, Nov 09, 2017 at 09:39:31AM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> The lease updates missed a few bits of docs, fixed up
> the wrong name on the property lookup fn as well.
> 
> Signed-off-by: Dave Airlie 

Thanks a lot! Would have typed them myself, but was a bit late yesterday.

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 1 +
>  drivers/gpu/drm/drm_mode_object.c | 1 +
>  include/drm/drm_connector.h   | 1 +
>  include/drm/drm_crtc.h| 1 +
>  include/drm/drm_encoder.h | 1 +
>  include/drm/drm_plane.h   | 1 +
>  include/drm/drm_property.h| 3 ++-
>  7 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 2affe53..279c103 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -681,6 +681,7 @@ EXPORT_SYMBOL(drm_framebuffer_init);
>  /**
>   * drm_framebuffer_lookup - look up a drm framebuffer and grab a reference
>   * @dev: drm device
> + * @file_priv: drm file to check for lease against.
>   * @id: id of the fb object
>   *
>   * If successful, this grabs an additional reference to the framebuffer -
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index 7c8b269..ce4d2fb 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -151,6 +151,7 @@ struct drm_mode_object *__drm_mode_object_find(struct 
> drm_device *dev,
>  
>  /**
>   * drm_mode_object_find - look up a drm object with static lifetime
> + * @dev: drm device
>   * @file_priv: drm file
>   * @id: id of the mode object
>   * @type: type of the mode object
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b4285c40..7a71405 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -933,6 +933,7 @@ static inline unsigned drm_connector_index(struct 
> drm_connector *connector)
>  /**
>   * drm_connector_lookup - lookup connector object
>   * @dev: DRM device
> + * @file_priv: drm file to check for lease against.
>   * @id: connector object id
>   *
>   * This function looks up the connector object specified by id
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f7fccee..a2d81d2 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -952,6 +952,7 @@ struct drm_crtc *drm_crtc_from_index(struct drm_device 
> *dev, int idx);
>  /**
>   * drm_crtc_find - look up a CRTC object from its ID
>   * @dev: DRM device
> + * @file_priv: drm file to check for lease against.
>   * @id: &drm_mode_object ID
>   *
>   * This can be used to look up a CRTC from its userspace ID. Only used by
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index 86db0da..ee4cfbe 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -208,6 +208,7 @@ static inline bool drm_encoder_crtc_ok(struct drm_encoder 
> *encoder,
>  /**
>   * drm_encoder_find - find a &drm_encoder
>   * @dev: DRM device
> + * @file_priv: drm file to check for lease against.
>   * @id: encoder id
>   *
>   * Returns the encoder with @id, NULL if it doesn't exist. Simple wrapper 
> around
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 069c4c8..5716150 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -591,6 +591,7 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
>  /**
>   * drm_plane_find - find a &drm_plane
>   * @dev: DRM device
> + * @file_priv: drm file to check for lease against.
>   * @id: plane id
>   *
>   * Returns the plane with @id, NULL if it doesn't exist. Simple wrapper 
> around
> diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
> index 429d821..8a522b4 100644
> --- a/include/drm/drm_property.h
> +++ b/include/drm/drm_property.h
> @@ -305,8 +305,9 @@ drm_property_unreference_blob(struct drm_property_blob 
> *blob)
>  }
>  
>  /**
> - * drm_connector_find - find property object
> + * drm_property_find - find property object
>   * @dev: DRM device
> + * @file_priv: drm file to check for lease against.
>   * @id: property object id
>   *
>   * This function looks up the property object specified by id and returns it.
> -- 
> 2.9.5
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Update docs for legacy kms state

[Daniel Vetter]

On Wed, Nov 08, 2017 at 12:57:30PM -0800, Manasi Navare wrote:
> On Wed, Nov 08, 2017 at 09:30:07PM +0100, Daniel Vetter wrote:
> > Point at the equivalent atomic state and explain that atomic drivers
> > shouldn't really depend upon legacy state.
> > 
> > Motivated by questions from Manasi about how this all is supposed to
> > work.
> > 
> > Cc: Manasi Navare 
> > Signed-off-by: Daniel Vetter 
> 
> Thanks for the patch, clarifies the usage of the atomic state
> objects in place of legacy mode objects.
> 
> Reviewed-by: Manasi Navare 

Applied, thanks.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c |  6 ++
> >  include/drm/drm_connector.h |  9 +++--
> >  include/drm/drm_encoder.h   |  6 +-
> >  include/drm/drm_plane.h | 12 ++--
> >  4 files changed, 28 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index ea781d55f2c1..09512a64c336 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -907,6 +907,12 @@ disable_outputs(struct drm_device *dev, struct 
> > drm_atomic_state *old_state)
> >   *
> >   * Drivers can use this for building their own atomic commit if they don't 
> > have
> >   * a pure helper-based modeset implementation.
> > + *
> > + * Since these updates are not synchronized with lockings, only code paths
> > + * called from &drm_mode_config_helper_funcs.atomic_commit_tail can look 
> > at the
> > + * legacy state filled out by this helper. Defacto this means this helper 
> > and
> > + * the legacy state pointers are only really useful for transitioning an
> > + * existing driver to the atomic world.
> >   */
> >  void
> >  drm_atomic_helper_update_legacy_modeset_state(struct drm_device *dev,
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index b4285c40e1e4..bb6629b5c55c 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -699,7 +699,6 @@ struct drm_cmdline_mode {
> >   * @force: a DRM_FORCE_ state for forced mode sets
> >   * @override_edid: has the EDID been overwritten through debugfs for 
> > testing?
> >   * @encoder_ids: valid encoders for this connector
> > - * @encoder: encoder driving this connector, if any
> >   * @eld: EDID-like data, if present
> >   * @latency_present: AV delay info from ELD, if found
> >   * @video_latency: video latency info from ELD, if found
> > @@ -869,7 +868,13 @@ struct drm_connector {
> >  
> >  #define DRM_CONNECTOR_MAX_ENCODER 3
> > uint32_t encoder_ids[DRM_CONNECTOR_MAX_ENCODER];
> > -   struct drm_encoder *encoder; /* currently active encoder */
> > +   /**
> > +* @encoder: Currently bound encoder driving this connector, if any.
> > +* Only really meaningful for non-atomic drivers. Atomic drivers should
> > +* instead look at &drm_connector_state.best_encoder, and in case they
> > +* need the CRTC driving this output, &drm_connector_state.crtc.
> > +*/
> > +   struct drm_encoder *encoder;
> >  
> >  #define MAX_ELD_BYTES  128
> > /* EDID bits */
> > diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> > index 86db0da8bdcb..67e1bccfb49d 100644
> > --- a/include/drm/drm_encoder.h
> > +++ b/include/drm/drm_encoder.h
> > @@ -88,7 +88,6 @@ struct drm_encoder_funcs {
> >   * @head: list management
> >   * @base: base KMS object
> >   * @name: human readable name, can be overwritten by the driver
> > - * @crtc: currently bound CRTC
> >   * @bridge: bridge associated to the encoder
> >   * @funcs: control functions
> >   * @helper_private: mid-layer private data
> > @@ -166,6 +165,11 @@ struct drm_encoder {
> >  */
> > uint32_t possible_clones;
> >  
> > +   /**
> > +* @crtc: Currently bound CRTC, only really meaningful for non-atomic
> > +* drivers.  Atomic drivers should instead check
> > +* &drm_connector_state.crtc.
> > +*/
> > struct drm_crtc *crtc;
> > struct drm_bridge *bridge;
> > const struct drm_encoder_funcs *funcs;
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index 069c4c8ce360..0efd38cd990b 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -474,8 +474,6 @@ enum drm_plane_type {
> >   * @format_types: array of formats supported by this plane
> >   * @format_count: number of formats supported
> >   * @format_default: driver hasn't supplied supported formats for the plane
> > - * @crtc: currently bound CRTC
> > - * @fb: currently bound fb
> >   * @old_fb: Temporary tracking of the old fb while a modeset is ongoing. 
> > Used by
> >   * drm_mode_set_config_internal() to implement correct refcounting.
> >   * @funcs: helper functions
> > @@ -512,7 +510,17 @@ struct drm_plane {
> > uint64_t *modifiers;
> > unsigned int modifier_count;
> >  
> > +   /**
> > +* @crtc: Currently bound CRTC, only really meaningful for non-atomic
> > + 

Re: [PATCH libdrm 0/6] drm-next header syncing

[Daniel Vetter]

On Wed, Nov 08, 2017 at 11:34:41AM -0800, Eric Anholt wrote:
> I wanted to update the vc4 header so that I could land some igt
> testcases (though I'd much rather just be importing the header into
> igt and ditching libdrm).  In the process, I cleaned up some other
> header deltas to the kernel so that there's less diff for the next
> person to look at.

I'm mildly tempted to just pull a mesa in igt too and put the headers in
directly. To avoid the need for way too many libdrm releases when hacking
on tests we atm add all the uapi stuff with a local_ prefix, but that's
kinda silly.

Maybe start a thread with vc4 as example converted (I guess we need to
make sure the include order is right) to get this started.
-Daniel

> 
> I skipped the actual ABI changes for the other drivers, though.
> 
> Eric Anholt (6):
>   headers: Sync vc4 header from drm-next.
>   headers: Sync up some header guard changes from drm-next.
>   headers: Sync up some comment spelling and whitespace fixes from
> drm-next.
>   headers: Sync up mga_drm.h from drm-next.
>   headers: Sync up kernel changes to use kernel types instead of
> stdint.h.
>   headers: Drop outdated node about a delta in drm_mode.h.
> 
>  include/drm/README|  22 +---
>  include/drm/mga_drm.h |  12 -
>  include/drm/nouveau_drm.h |  94 +++---
>  include/drm/qxl_drm.h |  82 +++--
>  include/drm/r128_drm.h|  10 
>  include/drm/radeon_drm.h  | 128 
> +++---
>  include/drm/savage_drm.h  |  20 ++--
>  include/drm/sis_drm.h |  10 
>  include/drm/tegra_drm.h   |  14 +++--
>  include/drm/vc4_drm.h |  47 +++--
>  include/drm/via_drm.h |   8 +++
>  include/drm/vmwgfx_drm.h  |   9 
>  12 files changed, 280 insertions(+), 176 deletions(-)
> 
> -- 
> 2.15.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

[Daniel Vetter]

On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
> Ville Syrjälä  writes:
> 
> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> >> Ville Syrjala  writes:
> >> 
> >> > From: Ville Syrjälä 
> >> >
> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
> >> > and they get somehow confused when they see a non-zero YQ value.
> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
> >> > RGB range.
> >> >
> >> > Unfortunately there is no good way to tell whether the sink
> >> > designer claims to have read CEA-861-F. The CEA extension block
> >> > revision number has generally been stuck at 3 since forever,
> >> > and even a very recently manufactured sink might be based on
> >> > an old design so the manufacturing date doesn't seem like
> >> > something we can use. In lieu of better information let's
> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> >> >
> >> > The alternative would of course be to always set YQ=0. And if
> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> >> > we'll probably have to do.
> >> 
> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
> >> source?
> >
> > As long as you stick to < 340 MHz modes you shouldn't have to do
> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
> >
> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
> > to bridges/encoders to filter out most things that aren't supported?
> 
> I had a patch for that at
> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
> into trouble with 4k monitors.

Ack on the clock limiting patch, silly that it's stuck. No idea about CEC,
better for Hans/Boris I guess.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Jani Nikula]

On Tue, 07 Nov 2017, Russell King  wrote:
> Parsing the EDID for HDMI and audio information in the get_modes()
> callback is incorrect - this only parses the EDID read from the
> connector, not any override or firmware provided EDID.
>
> The correct place to parse the EDID for these parameters is the
> fill_modes() callback, after we've called the helper.  Move the parsing
> there.  This caused problems for Luís Mendes.
>
> Cc: 
> Reported-by: Luís Mendes 
> Tested-by: Luís Mendes 
> Signed-off-by: Russell King 

Is this still needed after 53fd40a90f3c ("drm: handle override and
firmware EDID at drm_do_get_edid() level") that is headed for v4.15? I'm
thinking this might be applicable only for current Linus master and
stable.

BR,
Jani.


> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 
>  1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 9fe407f49986..2516a1c18a10 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1905,10 +1905,7 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
>   edid->width_cm, edid->height_cm);
>  
> - hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> - hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>   drm_mode_connector_update_edid_property(connector, edid);
> - cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
>   ret = drm_add_edid_modes(connector, edid);
>   /* Store the ELD */
>   drm_edid_to_eld(connector, edid);
> @@ -1920,6 +1917,29 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   return ret;
>  }
>  
> +static int dw_hdmi_connector_fill_modes(struct drm_connector *connector,
> + uint32_t maxX, uint32_t maxY)
> +{
> + struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> + connector);
> + int ret;
> +
> + ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> +
> + if (connector->edid_blob_ptr) {
> + struct edid *edid = (void *)connector->edid_blob_ptr->data;
> +
> + hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> + hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> + cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
> + } else {
> + hdmi->sink_is_hdmi = false;
> + hdmi->sink_has_audio = false;
> + }
> +
> + return ret;
> +}
> +
>  static void dw_hdmi_connector_force(struct drm_connector *connector)
>  {
>   struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> @@ -1933,7 +1953,7 @@ static void dw_hdmi_connector_force(struct 
> drm_connector *connector)
>  }
>  
>  static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = dw_hdmi_connector_fill_modes,
>   .detect = dw_hdmi_connector_detect,
>   .destroy = drm_connector_cleanup,
>   .force = dw_hdmi_connector_force,

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel