date:20171026

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

--- Comment #7 from shiris...@amd.com ---
Cool, will get the patch reviewed and merged.

-- 
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] display: panel: Add Tianma tm070rvhg71 display support (800x480)

On Sat, Oct 21, 2017 at 12:10:03AM +0200, Lukasz Majewski wrote:
> Signed-off-by: Lukasz Majewski 
> ---
>  .../bindings/display/panel/tianma,tm070rvhg71.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 27 
> ++
>  2 files changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt 
> b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> new file mode 100644
> index 000..b84217f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt
> @@ -0,0 +1,7 @@
> +Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "tianma,tm070rvhg71
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

No supplies? Still need to list power-supply here if so, so it is clear 
that this display has a single supply (or you need to list multiple ones 
if not).

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

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

On Fri, Oct 20, 2017 at 04:33:36PM +0200, 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 
> ---
>  .../devicetree/bindings/display/google,goldfish-fb.txt | 18 
> ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/google,goldfish-fb.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/google,goldfish-fb.txt 
> b/Documentation/devicetree/bindings/display/google,goldfish-fb.txt
> new file mode 100644
> index 000..9ce0615
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/google,goldfish-fb.txt
> @@ -0,0 +1,18 @@
> +Android Goldfish framebuffer
> +
> +Android Goldfish framebuffer device used by Android emulator.
> +
> +Required properties:
> +
> +- compatible : should contain "google,goldfish-fb"
> +- reg: 
> +- interrupts : 
> +
> +Example:
> +
> + goldfish_fb@1f008000 {

Use generic node names:

display-controller@...

With that,

Acked-by: Rob Herring 


> + compatible = "google,goldfish-fb";
> + interrupts = <0x10>;
> + reg = <0x1f008000 0x0 0x100>;

An address of one cell and size of 2 cells is strange...

> + compatible = "google,goldfish-fb";
> + };
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] amdgpu dc drm-next-4.15-dc

2017-10-26 Thread Dieter Nützel

Am 26.10.2017 19:26, schrieb Alex Deucher:
On Thu, Oct 26, 2017 at 10:10 AM, Dieter Nützel
wrote:

Hello Alex & Rex,

any progress?
The 'screen blank' (monitor standby mode) is really annoying.

Does this patch help?
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=ddabbf65aae36e21b4c79354940f80eae6c36104

Alex

Yes, it seems so. Many thanks to Jerry for this fix.
I've tested it with latest amd-staging-drm-next #4ce527eb8bb3 on my
Polaris 20. Both cases (kdm_greet and 'screen blank') are solved. W'll
apply it on drm-next-4.15-dc, too.

Side note:
HDMI audio is _gone_ after logout and relogin.
Missing reinitialization?

Next:
Fix fan speed...

Thank you very much!
Dieter

Thanks,
Dieter

Am 23.10.2017 03:03, schrieb Dieter Nützel:

Am 22.10.2017 23:48, schrieb Dieter Nützel:

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Last batch of new stuff for DC. Highlights:
- Fix some memory leaks
- S3 fixes
- Hotplug fixes
- Fix some CX multi-display issues
- MST fixes
- DML updates from the hw team
- Various code cleanups
- Misc bug fixes

Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Second:
KDE's greeter 'kdm_greet' (login screen went into dpms) and KDE's
'screen blank' (energy saving / dpms off) never came back. All I can
do is a clean reboot. So I have to disable all 'dpms'.
But I could attach gdb remotely on it.
'kdm_greet' hang in 'poll'.
Nothing alarming in 'dmesg' and 'Xorg.0.log'. (Both available taken
from 'amd-staging-drm-next' if needed).

Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the
'screen blank' (monitor standby mode):

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe
due

to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within
KDE session with replugging the video cable, but for all later tests
on both kernels I have to blindly switching back to login screen
(kdm_greet) and then replugging the video cable.

For me these regression started with 'amd-staging-drm-next' much
earlier than with the latest commit.

Dieter
___
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 1/3] dt-bindings: display/ti: Add optional property to set memory bandwidth limit

On Fri, Oct 20, 2017 at 04:12:56PM +0300, Peter Ujfalusi wrote:
> max-memory-bandwidth can be used to specify the maximum bandwidth dispc
> can use when reading display data from main memory.
> 
> In some SoC (am437x for example) we have memory bandwidth limitation
> which causes underflow in the display subsystem.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt  | 5 +
>  Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt | 4 
>  Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt | 4 
>  Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt | 4 
>  Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 
>  5 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt 
> b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt
> index c30f9ec189ed..91279f1060fe 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt
> +++ b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt
> @@ -47,6 +47,11 @@ Required properties:
>  - clocks: handle to fclk
>  - clock-names: "fck"
>  
> +Optional properties:
> +- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth 
> limit
> + in bytes per second

Can we move this to a common location since we already have the same 
prop for ARM pl11x.

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

[PATCH libdrm 2/2] amdgpu: Add VMID reservation per GPU context test.

2017-10-26 Thread Andrey Grodzovsky

The test will Reserve a VMID, submit a command and
unreserve the VMID.

Change-Id: I2e5320b2c3044d1375bc5b18d936d3c0637f5daa
Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/Makefile.am   |   3 +-
 tests/amdgpu/amdgpu_test.c |   7 +++
 tests/amdgpu/amdgpu_test.h |  15 +
 tests/amdgpu/vm_tests.c| 151 +
 4 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 tests/amdgpu/vm_tests.c

diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index 8700c4d..e79c1bd 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -31,4 +31,5 @@ amdgpu_test_SOURCES = \
uvd_enc_tests.c \
vcn_tests.c \
uve_ib.h \
-   deadlock_tests.c
+   deadlock_tests.c \
+   vm_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 9925503..a82d9ab 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -103,6 +103,13 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_deadlock_tests_clean,
.pTests = deadlock_tests,
},
+   {
+   .pName = "VM Tests",
+   .pInitFunc = suite_vm_tests_init,
+   .pCleanupFunc = suite_vm_tests_clean,
+   .pTests = vm_tests,
+   },
+
CU_SUITE_INFO_NULL,
 };
 
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index ece93f4..4fffbc6 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -150,6 +150,21 @@ int suite_deadlock_tests_clean();
 extern CU_TestInfo deadlock_tests[];
 
 /**
+ * Initialize vm test suite
+ */
+int suite_vm_tests_init();
+
+/**
+ * Deinitialize deadlock test suite
+ */
+int suite_vm_tests_clean();
+
+/**
+ * Tests in vm test suite
+ */
+extern CU_TestInfo vm_tests[];
+
+/**
  * Helper functions
  */
 static inline amdgpu_bo_handle gpu_mem_alloc(
diff --git a/tests/amdgpu/vm_tests.c b/tests/amdgpu/vm_tests.c
new file mode 100644
index 000..22bac37
--- /dev/null
+++ b/tests/amdgpu/vm_tests.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+
+static  amdgpu_device_handle device_handle;
+static  uint32_t  major_version;
+static  uint32_t  minor_version;
+
+
+static void amdgpu_vmid_reserve_test(void);
+
+int suite_vm_tests_init(void)
+{
+   struct amdgpu_gpu_info gpu_info = {0};
+   int r;
+
+   r = amdgpu_device_initialize(drm_amdgpu[0], &major_version,
+  &minor_version, &device_handle);
+
+   if (r) {
+   if ((r == -EACCES) && (errno == EACCES))
+   printf("\n\nError:%s. "
+   "Hint:Try to run this test program as root.",
+   strerror(errno));
+   return CUE_SINIT_FAILED;
+   }
+
+   return CUE_SUCCESS;
+}
+
+int suite_vm_tests_clean(void)
+{
+   int r = amdgpu_device_deinitialize(device_handle);
+
+   if (r == 0)
+   return CUE_SUCCESS;
+   else
+   return CUE_SCLEAN_FAILED;
+}
+
+
+CU_TestInfo vm_tests[] = {
+   { "resere vmid test",  amdgpu_vmid_reserve_test },
+   CU_TEST_INFO_NULL,
+};
+
+static void amdgpu_vmid_reserve_test(void)
+{
+   amdgpu_context_handle context_handle;
+   amdgpu_bo_handle ib_result_handle;
+   void *ib_result_cpu;
+   uint64_t ib_result_mc_address;
+   struct amdgpu_cs_request ibs_request;
+   struct amdgpu_cs_ib_info ib_info;
+   struct amdgpu_cs_fence fence_status;
+   uint32_t expired, flags;
+   int i, r, instance;
+   amdgpu_bo_list_handle bo_list;
+   amdgpu_va_handle va_handle;
+   union drm_amdgpu_vm vm;
+   static uint32_t *ptr;
+
+   r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+

[PATCH libdrm 1/2] amdgpu: Add wrappers for AMDGPU_VM IOCTL.

2017-10-26 Thread Andrey Grodzovsky

Change-Id: I7eafb85c1ca96d6d255f0183bed0ce4129746fe0
Signed-off-by: Andrey Grodzovsky 
---
 amdgpu/Makefile.sources |  1 +
 amdgpu/amdgpu.h | 20 +++
 amdgpu/amdgpu_vm.c  | 52 +
 3 files changed, 73 insertions(+)
 create mode 100644 amdgpu/amdgpu_vm.c

diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
index bc3abaa..498b64c 100644
--- a/amdgpu/Makefile.sources
+++ b/amdgpu/Makefile.sources
@@ -6,6 +6,7 @@ LIBDRM_AMDGPU_FILES := \
amdgpu_gpu_info.c \
amdgpu_internal.h \
amdgpu_vamgr.c \
+   amdgpu_vm.c \
util_hash.c \
util_hash.h \
util_hash_table.c \
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index ecc975f..07f2851 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1489,6 +1489,26 @@ void amdgpu_cs_chunk_fence_to_dep(struct amdgpu_cs_fence 
*fence,
 void amdgpu_cs_chunk_fence_info_to_data(struct amdgpu_cs_fence_info 
*fence_info,
struct drm_amdgpu_cs_chunk_data *data);
 
+/**
+ * Reserve VMID
+ * \param   context - \c [in]  GPU Context
+ * \param   flags - \c [in]  TBD
+ *
+ * \return  0 on success otherwise POSIX Error code
+*/
+int amdgpu_vm_alloc_reserved_vmid(amdgpu_context_handle context,
+ uint32_t  
flags);
+
+/**
+ * Free reserved VMID
+ * \param   context - \c [in]  GPU Context
+ * \param   flags - \c [in]  TBD
+ *
+ * \return  0 on success otherwise POSIX Error code
+*/
+int amdgpu_vm_free_reserved_vmid(amdgpu_context_handle context,
+uint32_t   
flags);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/amdgpu/amdgpu_vm.c b/amdgpu/amdgpu_vm.c
new file mode 100644
index 000..1664b7b
--- /dev/null
+++ b/amdgpu/amdgpu_vm.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+
+#include "amdgpu.h"
+#include "amdgpu_drm.h"
+#include "xf86drm.h"
+#include "amdgpu_internal.h"
+
+int amdgpu_vm_alloc_reserved_vmid(amdgpu_context_handle context,
+ uint32_t  
flags)
+{
+   union drm_amdgpu_vm vm;
+
+   vm.in.op = AMDGPU_VM_OP_RESERVE_VMID;
+   vm.in.flags = flags;
+
+   return drmCommandWriteRead(context->dev->fd, DRM_AMDGPU_VM,
+  &vm, sizeof(vm));
+}
+
+int amdgpu_vm_free_reserved_vmid(amdgpu_context_handle context,
+uint32_t   
flags)
+{
+   union drm_amdgpu_vm vm;
+
+   vm.in.op = AMDGPU_VM_OP_UNRESERVE_VMID;
+   vm.in.flags = flags;
+
+   return drmCommandWriteRead(context->dev->fd, DRM_AMDGPU_VM,
+  &vm, sizeof(vm));
+}
-- 
2.7.4

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

[drm-intel:for-linux-next 14/15] cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'

2017-10-26 Thread kbuild test robot

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   886c6b8692ba5f71b578097524b3b082e2e02119
commit: 39bf4de89ff7c87a2205e7ec5483e7424b86a1f6 [14/15] drm/i915: Add -Wall 
-Wextra to our build, set warnings to full
config: i386-randconfig-x0-10270203 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 39bf4de89ff7c87a2205e7ec5483e7424b86a1f6
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strlcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:293:3: note: in expansion of macro 'if'
  if (len >= p_size)
  ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strlcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:291:3: note: in expansion of macro 'if'
  if (__builtin_constant_p(len) && len >= p_size)
  ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strlcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:289:2: note: in expansion of macro 'if'
 if (size) {
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strlcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:286:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1 && q_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strnlen' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:274:2: note: in expansion of macro 'if'
 if (p_size <= ret && maxlen != ret)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strlen' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:264:2: note: in expansion of macro 'if'
 if (p_size <= ret)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strlen' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:261:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strcat' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:252:2: note: in expansion of macro 'if'
 if (strlcat(p, q, p_size) >= p_size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strcat' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:250:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strncpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:242:2: note: in expansion of macro 'if'
 if (p_size <

[PULL] drm-intel-fixes

2017-10-26 Thread Rodrigo Vivi

Hi Dave,

Here goes drm-intel-fixes-2017-10-26.

It is basically yesterday's one plus GVT fixes
I received today morning.

One fix for stable:

- fix perf enable/disable ioctls for 32bits (Lionel)

Plus GVT fixes:

- Fix per_ctx_bb check (Zhenyu)
- Fix GPU hang of Linux guest (Xion)
- Refine MMIO_RING_F to check for presence of VCS2 ring (Zhi)

Thanks,
Rodrigo.

The following changes since commit bb176f67090ca54869fc1262c913aa69d2ede070:

  Linux 4.14-rc6 (2017-10-23 06:49:47 -0400)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2017-10-26

for you to fetch changes up to 894e287b3dcc8bfc8d974f883dab3b5c66344089:

  drm/i915/gvt: Adding ACTHD mmio read handler (2017-10-26 11:29:44 -0700)


drm-intel-fixes-2017-10-26:

One fix for stable:

- fix perf enable/disable ioctls for 32bits (Lionel)

Plus GVT fixes:

- Fix per_ctx_bb check (Zhenyu)
- Fix GPU hang of Linux guest (Xion)
- Refine MMIO_RING_F to check for presence of VCS2 ring (Zhi)


Lionel Landwerlin (1):
  drm/i915/perf: fix perf enable/disable ioctls with 32bits userspace

Xiong Zhang (2):
  drm/i915/gvt: Extract mmio_read_from_hw() common function
  drm/i915/gvt: Adding ACTHD mmio read handler

Zhenyu Wang (1):
  drm/i915/gvt: properly check per_ctx bb valid state

Zhi Wang (1):
  drm/i915/gvt: Refine MMIO_RING_F()

 drivers/gpu/drm/i915/gvt/cmd_parser.c |  3 ++
 drivers/gpu/drm/i915/gvt/execlist.c   |  3 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 70 +--
 drivers/gpu/drm/i915/gvt/reg.h|  3 --
 drivers/gpu/drm/i915/gvt/scheduler.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c  |  4 ++
 6 files changed, 19 insertions(+), 65 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo

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

--- Comment #18 from James Payne  ---
Would be good to get to the bottom of this one as it affects my wife's laptop
:(

Currently stuck with Windows 10 which is sluggish to do anything...

Running the kernels from https://github.com/M-Bab/linux-kernel-amdgpu-binaries
did actually allow it to boot to a proper desktop. Though was a little flakey,
mainly very fast flickering of the screen when logged out and additionally when
the laptop was tried to move to sleep mode it just went nuts, the screen was
just overdrawing on itself until the entire screen was white!

Still it does look as if the DC merge in the kernel may help significantly with
this problem if those kernels are anything to go by. Saying that my wireless is
completely broken with this kernel :( 

Just can't win!

-- 
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 9875] Pixel formats with >8 bits per channel not available via OpenGL although apparently supported by hardware

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

--- Comment #5 from Chris Wilson  ---
But Mesa still doesn't support 10bpc FbConfigs; not even for i965. Though there
are finally patches to do so, so maybe next year!

-- 
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 9875] Pixel formats with >8 bits per channel not available via OpenGL although apparently supported by hardware

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

Elizabeth  changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO

--- Comment #4 from Elizabeth  ---
Good afternoon everyone. This request is too old, reported with Mesa 6.5 and
i810 DRI driver. This should be closed or updated with latest versions. Please
update information or case will be closed soon. Thank you.

-- 
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 103408] [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes"

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

dwagner  changed:

   What|Removed |Added

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

--- Comment #6 from dwagner  ---
Yes, the patch fixes this issue for me, too. Thank!

-- 
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 v3 3/6] drm/rockchip/dsi: correct Feedback divider setting

2017-10-26 Thread Brian Norris

(correction zyw's email ".comg" is not a TLD!)

Hi,

On Thu, Oct 26, 2017 at 09:44:14AM +, Philippe CORNU wrote:
> On 10/26/2017 06:13 AM, Archit Taneja wrote:
> > On 10/26/2017 06:39 AM, Brian Norris wrote:
> >> On Wed, Oct 25, 2017 at 03:57:19AM -0400, Sean Paul wrote:
> >>> Archit asked a question about moving to
> >>> dw-mipi-dsi
> >>
> >> That question made me think though: this approach seems backwards. It
> >> seems like someone did copy/paste/fork, and then we're asking the
> >> authors of the original driver to un-fork? It seems like this should
> >> happen the other way around -- those trying to support a new incarnation
> >> should have looked to try to abstract the original driver for their
> >> uses first.
> > 
> > Yes, ST wanted to replicate rockchip's version of the mipi DSI driver and
> > put it in their folder. If they did that, their KMS driver would have been
> > the third driver to implement a third instance of the DW DSI controller 
> > driver.
> > Hisilicon and Rockchip being the other 2.

I hadn't noticed Hisilicon's version. That's an unfortunate start :(

> > It was either that or attempt at a common DSI DW bridge driver. I suggested
> > the latter.
> > 
> > The ST guys have abstracted out the PHY pieces, which they knew varied 
> > between
> > rockchip and ST. Ideally, they should have also tried to create a RFC 
> > patch to
> > make the rockchip driver use the bridge too. But they didn't do that, and
> > the rockchip or hisilicon people were interested in even looking at it,
> > even after I CC'ed them.

I see. At least the current code from Philippe isn't that big, and it is
indeed fairly similar.

But I still think the way to get cooperation upstream is to enforce it;
so there was a 3rd option to the above -- don't merge *any* new driver
without posting at least an attempt to unify the existing drivers.

> >> IIUC, that's exactly what Rockchip did for much of their Analogix eDP
> >> code -- they reworked the Exynos DP driver to split common Analogix code
> >> from any Exynos-specific bits.
> > 
> > I get that. I had hoped either ST or Rockchip guys would have done the 
> > similar
> > thing, but no one volunteered.

:(

Nickey, can you confirm that you or someone on your team will look at
utilizing the common driver? Please reply to this email thread before
sending another version of this series.

> >> And actually, the current stuff in
> >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c is completely unused. It
> >> exports some functions, but I see no users of it. Is that intended? Is
> > 
> > The ST kms driver uses it:
> > 
> > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > 
> 
> I confirm STM32 chipsets use the Synopsys dw dsi bridge driver.
> 
> I plan to improve this bridge driver by adding new features (see todos + 
> dsi read, command mode with bta & gpio...).
> 
> For the first commit, I did my best to keep the source code as close as 
> possible to the Rockchip version, in order to ease the port for Rockchip 
> guys.

That's nice to see, even if it still isn't ideal.

> >> somebody already working on refactoring existing Rockchip code to use
> >> this?
> > 
> > I don't know. If rockchip isn't interested in doing it, we can check with
> > Philippe from ST if he can try creating a RFC that converts the rockchip
> > driver to use the dw-mipi-dsi driver.
> 
> I am not really interested in doing this port for Rockchip (or Hisilicon 
> or i.MX...) but happy to help anyone that wants to use the dw-mipi-dsi 
> bridge driver :)

Well, see my comments above. Your "interest" is obviously in merging
code to support your own IP, but the community can *make* it your
interest by requiring you do the unification before your code goes
upstream. Apparently that's not the policy here though.

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

[Bug 103408] [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes"

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

--- Comment #5 from Andy Furniss  ---
Patch is good for me, thanks.

-- 
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 v3 4/8] drm/print: Add drm_printf_indent()

2017-10-26 Thread Ville Syrjälä

On Thu, Oct 26, 2017 at 08:51:57PM +0200, Noralf Trønnes wrote:
> 
> Den 26.10.2017 19.49, skrev Ville Syrjälä:
> > On Thu, Oct 26, 2017 at 06:57:27PM +0200, Noralf Trønnes wrote:
> >> Add drm_printf_indent() that adds tab indentation according to argument.
> >>
> >> Signed-off-by: Noralf Trønnes 
> >> ---
> >>   drivers/gpu/drm/drm_print.c | 21 +
> >>   include/drm/drm_print.h |  2 ++
> >>   2 files changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> >> index 0b3bf476dc4b..dac3ee98b30f 100644
> >> --- a/drivers/gpu/drm/drm_print.c
> >> +++ b/drivers/gpu/drm/drm_print.c
> >> @@ -64,6 +64,27 @@ void drm_printf(struct drm_printer *p, const char *f, 
> >> ...)
> >>   }
> >>   EXPORT_SYMBOL(drm_printf);
> >>   
> >> +/**
> >> + * drm_printf_indent - print to a &drm_printer stream with indentation
> >> + * @p: the &drm_printer
> >> + * @i: indentation
> >> + * @f: format string
> >> + */
> >> +void drm_printf_indent(struct drm_printer *p, unsigned int i, const char 
> >> *f, ...)
> >> +{
> >> +  struct va_format vaf;
> >> +  va_list args;
> >> +
> >> +  drm_printf(p, "%.*s", i, "\t\t\t\t\t\t\t\t\t\t");
> >> +
> >> +  va_start(args, f);
> >> +  vaf.fmt = f;
> >> +  vaf.va = &args;
> >> +  p->printfn(p, &vaf);
> >> +  va_end(args);
> >> +}
> >> +EXPORT_SYMBOL(drm_printf_indent);
> > The double printf() is rather unfortunate. Sadly I don't think there's
> > any proper way to manipulate a va_list to avoid that.
> >
> > Hmm. Would it work if we simply make it a macro? Eg.
> >
> > #define drm_printf_indent(printer, indent, fmt, ...) \
> > drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t", ##__VA_ARGS__)
> 
> The macro worked fine and it looks like a better solution to me.

Only downside is that it bloats every format string. But as long
as there aren't a huge number of useless callers we should be fine.

> 
> > The "\t\t\t..." thing is also rather off putting, but I guess it's
> > the best we can do if we want to keep it to one printf(). And maybe we
> > should have a check in there to make sure we have enought tabs in the
> > string to satisfy the indent level, or we just clamp the indent level
> > silently to something reasonable?
> 
> I put 10 tabs in my suggestion, which should be enough and I think it's
> OK to just silently fail to do more. If 10 isn't enough it's easy to add
> more for the developer that hits the limit.

10 is probably even overkill. I'd say if you have to go past four or so
then there's alredy a bigger problem in the code ;)

> 
> Noralf.
> 
> > Oh, seeing the \t now reminds me that tabs won't necesarily get printed
> > out properly. At least I've seen fbcon just printing some weird blobs
> > instead of tabs. Not sure if it's just a matter of having a crappy font
> > or what. That said, the state dump code is using tabs already, so I guess
> > this wouldn't make it worse at least.
> >
> >> +
> >>   #define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> >>   
> >>   void drm_dev_printk(const struct device *dev, const char *level,
> >> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> >> index 7b9c86a6ca3e..73dcd16eca49 100644
> >> --- a/include/drm/drm_print.h
> >> +++ b/include/drm/drm_print.h
> >> @@ -79,6 +79,8 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
> >> va_format *vaf);
> >>   
> >>   __printf(2, 3)
> >>   void drm_printf(struct drm_printer *p, const char *f, ...);
> >> +__printf(3, 4)
> >> +void drm_printf_indent(struct drm_printer *p, unsigned int i, const char 
> >> *f, ...);
> >>   
> >>   
> >>   /**
> >> -- 
> >> 2.14.2

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

Re: [PATCH v3 4/8] drm/print: Add drm_printf_indent()



Den 26.10.2017 19.49, skrev Ville Syrjälä:

On Thu, Oct 26, 2017 at 06:57:27PM +0200, Noralf Trønnes wrote:

Add drm_printf_indent() that adds tab indentation according to argument.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_print.c | 21 +
  include/drm/drm_print.h |  2 ++
  2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 0b3bf476dc4b..dac3ee98b30f 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -64,6 +64,27 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
  }
  EXPORT_SYMBOL(drm_printf);
  
+/**

+ * drm_printf_indent - print to a &drm_printer stream with indentation
+ * @p: the &drm_printer
+ * @i: indentation
+ * @f: format string
+ */
+void drm_printf_indent(struct drm_printer *p, unsigned int i, const char *f, 
...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   drm_printf(p, "%.*s", i, "\t\t\t\t\t\t\t\t\t\t");
+
+   va_start(args, f);
+   vaf.fmt = f;
+   vaf.va = &args;
+   p->printfn(p, &vaf);
+   va_end(args);
+}
+EXPORT_SYMBOL(drm_printf_indent);

The double printf() is rather unfortunate. Sadly I don't think there's
any proper way to manipulate a va_list to avoid that.

Hmm. Would it work if we simply make it a macro? Eg.

#define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t", ##__VA_ARGS__)


The macro worked fine and it looks like a better solution to me.


The "\t\t\t..." thing is also rather off putting, but I guess it's
the best we can do if we want to keep it to one printf(). And maybe we
should have a check in there to make sure we have enought tabs in the
string to satisfy the indent level, or we just clamp the indent level
silently to something reasonable?


I put 10 tabs in my suggestion, which should be enough and I think it's
OK to just silently fail to do more. If 10 isn't enough it's easy to add
more for the developer that hits the limit.

Noralf.


Oh, seeing the \t now reminds me that tabs won't necesarily get printed
out properly. At least I've seen fbcon just printing some weird blobs
instead of tabs. Not sure if it's just a matter of having a crappy font
or what. That said, the state dump code is using tabs already, so I guess
this wouldn't make it worse at least.


+
  #define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
  
  void drm_dev_printk(const struct device *dev, const char *level,

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 7b9c86a6ca3e..73dcd16eca49 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -79,6 +79,8 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
va_format *vaf);
  
  __printf(2, 3)

  void drm_printf(struct drm_printer *p, const char *f, ...);
+__printf(3, 4)
+void drm_printf_indent(struct drm_printer *p, unsigned int i, const char *f, 
...);
  
  
  /**

--
2.14.2


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

Re: [PATCH v3 3/8] drm/gem: Remove trailing whitespace

2017-10-26 Thread Ville Syrjälä

On Thu, Oct 26, 2017 at 06:57:26PM +0200, Noralf Trønnes wrote:
> Remove two trailing spaces.
> 
> Signed-off-by: Noralf Trønnes 

Patches 1-3 are
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_gem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 55d6182555c7..4c84b23d37cc 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -348,7 +348,7 @@ EXPORT_SYMBOL_GPL(drm_gem_dumb_map_offset);
>   * @file: drm file-private structure to remove the dumb handle from
>   * @dev: corresponding drm_device
>   * @handle: the dumb handle to remove
> - * 
> + *
>   * This implements the &drm_driver.dumb_destroy kms driver callback for 
> drivers
>   * which use gem to manage their backing storage.
>   */
> @@ -365,7 +365,7 @@ EXPORT_SYMBOL(drm_gem_dumb_destroy);
>   * @file_priv: drm file-private structure to register the handle for
>   * @obj: object to register
>   * @handlep: pointer to return the created handle to the caller
> - * 
> + *
>   * This expects the &drm_device.object_name_lock to be held already and will
>   * drop it before returning. Used to avoid races in establishing new handles
>   * when importing an object from either an flink name or a dma-buf.
> -- 
> 2.14.2

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

Re: [PATCH v3 4/8] drm/print: Add drm_printf_indent()

2017-10-26 Thread Ville Syrjälä

On Thu, Oct 26, 2017 at 06:57:27PM +0200, Noralf Trønnes wrote:
> Add drm_printf_indent() that adds tab indentation according to argument.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_print.c | 21 +
>  include/drm/drm_print.h |  2 ++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 0b3bf476dc4b..dac3ee98b30f 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -64,6 +64,27 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
>  }
>  EXPORT_SYMBOL(drm_printf);
>  
> +/**
> + * drm_printf_indent - print to a &drm_printer stream with indentation
> + * @p: the &drm_printer
> + * @i: indentation
> + * @f: format string
> + */
> +void drm_printf_indent(struct drm_printer *p, unsigned int i, const char *f, 
> ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + drm_printf(p, "%.*s", i, "\t\t\t\t\t\t\t\t\t\t");
> +
> + va_start(args, f);
> + vaf.fmt = f;
> + vaf.va = &args;
> + p->printfn(p, &vaf);
> + va_end(args);
> +}
> +EXPORT_SYMBOL(drm_printf_indent);

The double printf() is rather unfortunate. Sadly I don't think there's
any proper way to manipulate a va_list to avoid that.

Hmm. Would it work if we simply make it a macro? Eg.

#define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t", ##__VA_ARGS__)

The "\t\t\t..." thing is also rather off putting, but I guess it's
the best we can do if we want to keep it to one printf(). And maybe we
should have a check in there to make sure we have enought tabs in the
string to satisfy the indent level, or we just clamp the indent level
silently to something reasonable?

Oh, seeing the \t now reminds me that tabs won't necesarily get printed
out properly. At least I've seen fbcon just printing some weird blobs
instead of tabs. Not sure if it's just a matter of having a crappy font
or what. That said, the state dump code is using tabs already, so I guess
this wouldn't make it worse at least.

> +
>  #define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
>  
>  void drm_dev_printk(const struct device *dev, const char *level,
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 7b9c86a6ca3e..73dcd16eca49 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -79,6 +79,8 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
> va_format *vaf);
>  
>  __printf(2, 3)
>  void drm_printf(struct drm_printer *p, const char *f, ...);
> +__printf(3, 4)
> +void drm_printf_indent(struct drm_printer *p, unsigned int i, const char *f, 
> ...);
>  
>  
>  /**
> -- 
> 2.14.2

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Bit definition for D3 power state that keeps AUX fully powered

2017-10-26 Thread Pandiyan, Dhinakaran


On Thu, 2017-10-26 at 10:59 +0300, Jani Nikula wrote:
> On Thu, 10 Aug 2017, Dhinakaran Pandiyan  wrote:
> > DPCD 600h - SET_POWER & SET_DP_PWR_VOLTAGE defines power state
> >
> > 101 = Set Main-Link for local Sink device and all downstream Sink
> > devices to D3 (power-down mode), keep AUX block fully powered, ready to
> > reply within a Response Timeout period of 300us.
> >
> > This state is useful in a MST dock + MST monitor configuration that
> > doesn't wake up from D3 state.
> 
> Dhinakaran, these two seem to have fallen through the cracks, please
> resend.
> 

So the "drm/dp/mst: Sideband message transaction to power up/down nodes"
series I sent fixed the DPMS issues I was seeing with my setup. We'll
have to evaluate whether this patch is still useful for anyone (probably
https://bugs.freedesktop.org/show_bug.cgi?id=90963).


> Sorry & thanks,
> Jani.
> 
> 
> >
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  include/drm/drm_dp_helper.h | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index b17476a..d77e0f5 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -614,10 +614,11 @@
> >  #define DP_BRANCH_HW_REV0x509
> >  #define DP_BRANCH_SW_REV0x50A
> >  
> > -#define DP_SET_POWER0x600
> > -# define DP_SET_POWER_D00x1
> > -# define DP_SET_POWER_D30x2
> > -# define DP_SET_POWER_MASK  0x3
> > +#define DP_SET_POWER   0x600
> > +# define DP_SET_POWER_D0   0x1
> > +# define DP_SET_POWER_D3   0x2
> > +# define DP_SET_POWER_MASK 0x3
> > +# define DP_SET_POWER_D3_AUX_ON0x5
> >  
> >  #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */
> >  # define DP_EDP_11 0x00
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] amdgpu dc drm-next-4.15-dc

2017-10-26 Thread Alex Deucher

On Thu, Oct 26, 2017 at 10:10 AM, Dieter Nützel  wrote:
> Hello Alex & Rex,
>
> any progress?
> The 'screen blank' (monitor standby mode) is really annoying.

Does this patch help?
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=ddabbf65aae36e21b4c79354940f80eae6c36104

Alex

>
> Thanks,
> Dieter
>
> Am 23.10.2017 03:03, schrieb Dieter Nützel:
>>
>> Am 22.10.2017 23:48, schrieb Dieter Nützel:
>>>
>>> Am 21.10.2017 23:22, schrieb Alex Deucher:

 Hi Dave,

 Last batch of new stuff for DC. Highlights:
 - Fix some memory leaks
 - S3 fixes
 - Hotplug fixes
 - Fix some CX multi-display issues
 - MST fixes
 - DML updates from the hw team
 - Various code cleanups
 - Misc bug fixes
>>>
>>>
>>> Now this tree has the same fan regression as 'amd-staging-drm-next'
>>> startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.
>>>
>>> Look here:
>>> [amd-staging-drm-next] regression - no fan info (sensors) on RX580
>>> https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html
>>>
>>> Second:
>>> KDE's greeter 'kdm_greet' (login screen went into dpms) and KDE's
>>> 'screen blank' (energy saving / dpms off) never came back. All I can
>>> do is a clean reboot. So I have to disable all 'dpms'.
>>> But I could attach gdb remotely on it.
>>> 'kdm_greet' hang in 'poll'.
>>> Nothing alarming in 'dmesg' and 'Xorg.0.log'. (Both available taken
>>> from 'amd-staging-drm-next' if needed).
>>
>>
>> Hello Alex and Rex,
>>
>> I've found good hint from Jan (randomsalad) on phoronix for the
>> 'screen blank' (monitor standby mode):
>>
>> https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555
>>
>> My Reply:
>>
>> https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581
>>
>> I can swear, that I could 'return' one time (the first time, maybe due
>> to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within
>> KDE session with replugging the video cable, but for all later tests
>> on both kernels I have to blindly switching back to login screen
>> (kdm_greet) and then replugging the video cable.
>>
>> For me these regression started with 'amd-staging-drm-next' much
>> earlier than with the latest commit.
>>
>> Dieter
>> ___
>> 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

[PATCH v3 2/8] drm/framebuffer: drm_framebuffer_read_refcount() constify argument

Constify argument so functions calling into this take a const argument.

Signed-off-by: Noralf Trønnes 
---
 include/drm/drm_framebuffer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index b6996ddb19d6..6cce22e1a0f2 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -263,7 +263,7 @@ static inline void drm_framebuffer_unreference(struct 
drm_framebuffer *fb)
  *
  * This functions returns the framebuffer's reference count.
  */
-static inline uint32_t drm_framebuffer_read_refcount(struct drm_framebuffer 
*fb)
+static inline uint32_t drm_framebuffer_read_refcount(const struct 
drm_framebuffer *fb)
 {
return kref_read(&fb->base.refcount);
 }
-- 
2.14.2

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

[PATCH v3 6/8] drm/atomic: Use drm_framebuffer_print_info()

Use drm_framebuffer_print_info() to print framebuffer info in
drm_atomic_plane_print_state(). This will give optional GEM info as well.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_atomic.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6c9c4a8e09af..6d626355ba4e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -33,6 +33,7 @@
 #include 
 
 #include "drm_crtc_internal.h"
+#include "drm_internal.h"
 
 void __drm_crtc_commit_free(struct kref *kref)
 {
@@ -934,21 +935,8 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
drm_printf(p, "plane[%u]: %s\n", plane->base.id, plane->name);
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
"(null)");
drm_printf(p, "\tfb=%u\n", state->fb ? state->fb->base.id : 0);
-   if (state->fb) {
-   struct drm_framebuffer *fb = state->fb;
-   int i, n = fb->format->num_planes;
-   struct drm_format_name_buf format_name;
-
-   drm_printf(p, "\t\tformat=%s\n",
- drm_get_format_name(fb->format->format, 
&format_name));
-   drm_printf(p, "\t\t\tmodifier=0x%llx\n", fb->modifier);
-   drm_printf(p, "\t\tsize=%dx%d\n", fb->width, fb->height);
-   drm_printf(p, "\t\tlayers:\n");
-   for (i = 0; i < n; i++) {
-   drm_printf(p, "\t\t\tpitch[%d]=%u\n", i, 
fb->pitches[i]);
-   drm_printf(p, "\t\t\toffset[%d]=%u\n", i, 
fb->offsets[i]);
-   }
-   }
+   if (state->fb)
+   drm_framebuffer_print_info(p, 2, state->fb);
drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG(&dest));
drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", DRM_RECT_FP_ARG(&src));
drm_printf(p, "\trotation=%x\n", state->rotation);
-- 
2.14.2

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

[PATCH v3 8/8] drm/tinydrm: Use drm_gem_cma_print_info()

Use drm_gem_cma_print_info() instead of drm_fb_cma_debugfs_show()
to print framebuffer/gem info to debugfs. The debugfs file is now:
/dri//framebuffer

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 8 +---
 include/drm/tinydrm/tinydrm.h  | 1 +
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index d43e992ab432..347f9b226f26 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -961,10 +961,6 @@ static const struct file_operations 
mipi_dbi_debugfs_command_fops = {
.write = mipi_dbi_debugfs_command_write,
 };
 
-static const struct drm_info_list mipi_dbi_debugfs_list[] = {
-   { "fb",   drm_fb_cma_debugfs_show, 0 },
-};
-
 /**
  * mipi_dbi_debugfs_init - Create debugfs entries
  * @minor: DRM minor
@@ -987,9 +983,7 @@ int mipi_dbi_debugfs_init(struct drm_minor *minor)
debugfs_create_file("command", mode, minor->debugfs_root, mipi,
&mipi_dbi_debugfs_command_fops);
 
-   return drm_debugfs_create_files(mipi_dbi_debugfs_list,
-   ARRAY_SIZE(mipi_dbi_debugfs_list),
-   minor->debugfs_root, minor);
+   return 0;
 }
 EXPORT_SYMBOL(mipi_dbi_debugfs_init);
 
diff --git a/include/drm/tinydrm/tinydrm.h b/include/drm/tinydrm/tinydrm.h
index 4774fe3d4273..423828922e5a 100644
--- a/include/drm/tinydrm/tinydrm.h
+++ b/include/drm/tinydrm/tinydrm.h
@@ -46,6 +46,7 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
  */
 #define TINYDRM_GEM_DRIVER_OPS \
.gem_free_object= tinydrm_gem_cma_free_object, \
+   .gem_print_info = drm_gem_cma_print_info, \
.gem_vm_ops = &drm_gem_cma_vm_ops, \
.prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
.prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
-- 
2.14.2

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

[PATCH v3 3/8] drm/gem: Remove trailing whitespace

Remove two trailing spaces.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 55d6182555c7..4c84b23d37cc 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -348,7 +348,7 @@ EXPORT_SYMBOL_GPL(drm_gem_dumb_map_offset);
  * @file: drm file-private structure to remove the dumb handle from
  * @dev: corresponding drm_device
  * @handle: the dumb handle to remove
- * 
+ *
  * This implements the &drm_driver.dumb_destroy kms driver callback for drivers
  * which use gem to manage their backing storage.
  */
@@ -365,7 +365,7 @@ EXPORT_SYMBOL(drm_gem_dumb_destroy);
  * @file_priv: drm file-private structure to register the handle for
  * @obj: object to register
  * @handlep: pointer to return the created handle to the caller
- * 
+ *
  * This expects the &drm_device.object_name_lock to be held already and will
  * drop it before returning. Used to avoid races in establishing new handles
  * when importing an object from either an flink name or a dma-buf.
-- 
2.14.2

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

[PATCH v3 4/8] drm/print: Add drm_printf_indent()

Add drm_printf_indent() that adds tab indentation according to argument.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_print.c | 21 +
 include/drm/drm_print.h |  2 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 0b3bf476dc4b..dac3ee98b30f 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -64,6 +64,27 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
 }
 EXPORT_SYMBOL(drm_printf);
 
+/**
+ * drm_printf_indent - print to a &drm_printer stream with indentation
+ * @p: the &drm_printer
+ * @i: indentation
+ * @f: format string
+ */
+void drm_printf_indent(struct drm_printer *p, unsigned int i, const char *f, 
...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   drm_printf(p, "%.*s", i, "\t\t\t\t\t\t\t\t\t\t");
+
+   va_start(args, f);
+   vaf.fmt = f;
+   vaf.va = &args;
+   p->printfn(p, &vaf);
+   va_end(args);
+}
+EXPORT_SYMBOL(drm_printf_indent);
+
 #define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
 
 void drm_dev_printk(const struct device *dev, const char *level,
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 7b9c86a6ca3e..73dcd16eca49 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -79,6 +79,8 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
va_format *vaf);
 
 __printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
+__printf(3, 4)
+void drm_printf_indent(struct drm_printer *p, unsigned int i, const char *f, 
...);
 
 
 /**
-- 
2.14.2

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

[PATCH v3 1/8] drm/vma-manager: drm_vma_node_start() constify argument

Constify argument so functions calling into this take a const argument.

Signed-off-by: Noralf Trønnes 
---
 include/drm/drm_vma_manager.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index d84d52f6d2b1..8758df94e9a0 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -152,7 +152,7 @@ static inline void drm_vma_node_reset(struct 
drm_vma_offset_node *node)
  * Start address of @node for page-based addressing. 0 if the node does not
  * have an offset allocated.
  */
-static inline unsigned long drm_vma_node_start(struct drm_vma_offset_node 
*node)
+static inline unsigned long drm_vma_node_start(const struct 
drm_vma_offset_node *node)
 {
return node->vm_node.start;
 }
-- 
2.14.2

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

[PATCH v3 7/8] drm/cma-helper: Add drm_gem_cma_print_info()

Add drm_gem_cma_print_info() for debugfs printing
struct drm_gem_cma_object specific info.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 19 +++
 include/drm/drm_gem_cma_helper.h |  5 -
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 020e7668dfab..89dc7f04fae6 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -423,6 +423,25 @@ void drm_gem_cma_describe(struct drm_gem_cma_object 
*cma_obj,
 EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
 #endif
 
+/**
+ * drm_gem_cma_print_info() - Print &drm_gem_cma_object info for debugfs
+ * @p: DRM printer
+ * @indent: Tab indentation level
+ * @gem: GEM object
+ *
+ * This function can be used as the &drm_driver->gem_print_info callback.
+ * It prints paddr and vaddr for use in e.g. debugfs output.
+ */
+void drm_gem_cma_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_gem_object *obj)
+{
+   struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
+
+   drm_printf_indent(p, indent, "paddr=%pad\n", &cma_obj->paddr);
+   drm_printf_indent(p, indent, "vaddr=%p\n", cma_obj->vaddr);
+}
+EXPORT_SYMBOL(drm_gem_cma_print_info);
+
 /**
  * drm_gem_cma_prime_get_sg_table - provide a scatter/gather table of pinned
  * pages for a CMA GEM object
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 58a739bf15f1..bc47e6eba271 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -21,7 +21,7 @@ struct drm_gem_cma_object {
 };
 
 static inline struct drm_gem_cma_object *
-to_drm_gem_cma_obj(struct drm_gem_object *gem_obj)
+to_drm_gem_cma_obj(const struct drm_gem_object *gem_obj)
 {
return container_of(gem_obj, struct drm_gem_cma_object, base);
 }
@@ -94,6 +94,9 @@ unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
 void drm_gem_cma_describe(struct drm_gem_cma_object *obj, struct seq_file *m);
 #endif
 
+void drm_gem_cma_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_gem_object *obj);
+
 struct sg_table *drm_gem_cma_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *
 drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
-- 
2.14.2

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

[PATCH v3 5/8] drm/framebuffer: Add framebuffer debugfs file

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_debugfs.c |  6 
 drivers/gpu/drm/drm_framebuffer.c | 59 +++
 drivers/gpu/drm/drm_gem.c | 17 +++
 drivers/gpu/drm/drm_internal.h|  7 +
 include/drm/drm_drv.h | 11 
 5 files changed, 100 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index c1807d5754b2..550f29de6c1f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
}
}
 
+   ret = drm_framebuffer_debugfs_init(minor);
+   if (ret) {
+   DRM_ERROR("Failed to create framebuffer debugfs file\n");
+   return ret;
+   }
+
if (dev->driver->debugfs_init) {
ret = dev->driver->debugfs_init(minor);
if (ret) {
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index af279844d7ce..4f7873a1b922 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -25,7 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 
+#include "drm_internal.h"
 #include "drm_crtc_internal.h"
 
 /**
@@ -955,3 +957,60 @@ int drm_framebuffer_plane_height(int height,
return fb_plane_height(height, fb->format, plane);
 }
 EXPORT_SYMBOL(drm_framebuffer_plane_height);
+
+void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_framebuffer *fb)
+{
+   struct drm_format_name_buf format_name;
+   int i;
+
+   drm_printf_indent(p, indent, "refcount=%d\n",
+ drm_framebuffer_read_refcount(fb));
+   drm_printf_indent(p, indent, "format=%s\n",
+ drm_get_format_name(fb->format->format, 
&format_name));
+   drm_printf_indent(p, indent, "modifier=0x%llx\n", fb->modifier);
+   drm_printf_indent(p, indent, "size=%dx%d\n", fb->width, fb->height);
+   drm_printf_indent(p, indent, "layers:\n");
+
+   for (i = 0; i < fb->format->num_planes; i++) {
+   drm_printf_indent(p, indent + 1, "size[%d]=%dx%d\n", i,
+ drm_framebuffer_plane_width(fb->width, fb, i),
+ drm_framebuffer_plane_height(fb->height, fb, 
i));
+   drm_printf_indent(p, indent + 1, "pitch[%d]=%u\n", i, 
fb->pitches[i]);
+   drm_printf_indent(p, indent + 1, "offset[%d]=%u\n", i, 
fb->offsets[i]);
+   drm_printf_indent(p, indent + 1, "obj[%d]:%s\n", i,
+ fb->obj[i] ? "" : "(null)");
+   if (fb->obj[i])
+   drm_gem_print_info(p, indent + 2, fb->obj[i]);
+   }
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int drm_framebuffer_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+   struct drm_framebuffer *fb;
+
+   mutex_lock(&dev->mode_config.fb_lock);
+   drm_for_each_fb(fb, dev) {
+   drm_printf(&p, "framebuffer[%d]:\n", fb->base.id);
+   drm_framebuffer_print_info(&p, 1, fb);
+   }
+   mutex_unlock(&dev->mode_config.fb_lock);
+
+   return 0;
+}
+
+static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
+   { "framebuffer", drm_framebuffer_info, 0 },
+};
+
+int drm_framebuffer_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(drm_framebuffer_debugfs_list,
+   ARRAY_SIZE(drm_framebuffer_debugfs_list),
+   minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4c84b23d37cc..152bd6210dde 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drm_internal.h"
 
 /** @file drm_gem.c
@@ -1040,3 +1041,19 @@ int drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return ret;
 }
 EXPORT_SYMBOL(drm_gem_mmap);
+
+void drm_gem_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_gem_object *obj)
+{
+   drm_printf_indent(p, indent, "name=%d\n", obj->name);
+   drm_printf_indent(p, indent, "refcount=%d\n",
+ kref_read(&obj->refcount));
+   drm_printf_indent(p, indent, "start=%08lx\n",
+ drm_vma_node_start(&obj->vma_node));
+   drm_printf_indent(p, indent, "size=%zu\n", obj->size);
+   drm_printf_indent(p, indent, "imported=%s\n",
+ obj->import_attach ? "yes" : "no");
+
+   if (obj->dev->driver

[PATCH v3 0/8] drm/framebuffer: Add framebuffer debugfs file

This patchset adds a debugfs file that prints info about the
framebuffers.

This version has a lot of changes since the previous version. The
previous version was inspired by drm_fb_cma_debugfs_show(), but this one
strictly follows the style of drm_state_info(). This means that the
added drm_framebuffer_print_info() could also be used in
drm_atomic_plane_print_state(). In order to do that I had to add a way
to vary indentation to fit both use cases.

I've also converted the cma helper so I could add the driver callback.
If this approach turns out to be the way to go, I'll convert hdlcd and
tilcdc as well in the next version so I can remove
drm_fb_cma_debugfs_show().

This is how it looks:
$ sudo cat /sys/kernel/debug/dri/0/framebuffer
framebuffer[33]:
refcount=3
format=RG16 little-endian (0x36314752)
modifier=0x0
size=320x240
layers:
size[0]=320x240
pitch[0]=640
offset[0]=0
obj[0]:
name=0
refcount=1
start=0001
size=155648
imported=no
paddr=0x17c8
vaddr=d7c8

$ sudo cat /sys/kernel/debug/dri/0/state
plane[28]: plane-0
crtc=crtc-0
fb=33
refcount=3
format=RG16 little-endian (0x36314752)
modifier=0x0
size=320x240
layers:
size[0]=320x240
pitch[0]=640
offset[0]=0
obj[0]:
name=0
refcount=1
start=0001
size=155648
imported=no
paddr=0x17c8
vaddr=d7c8
crtc-pos=320x240+0+0
src-pos=320.00x240.00+0.00+0.00
rotation=1
crtc[29]: crtc-0
<...>


Noralf Trønnes (8):
  drm/vma-manager: drm_vma_node_start() constify argument
  drm/framebuffer: drm_framebuffer_read_refcount() constify argument
  drm/gem: Remove trailing whitespace
  drm/print: Add drm_printf_indent()
  drm/framebuffer: Add framebuffer debugfs file
  drm/atomic: Use drm_framebuffer_print_info()
  drm/cma-helper: Add drm_gem_cma_print_info()
  drm/tinydrm: Use drm_gem_cma_print_info()

 drivers/gpu/drm/drm_atomic.c | 18 ++-
 drivers/gpu/drm/drm_debugfs.c|  6 
 drivers/gpu/drm/drm_framebuffer.c| 59 
 drivers/gpu/drm/drm_gem.c| 21 +++--
 drivers/gpu/drm/drm_gem_cma_helper.c | 19 
 drivers/gpu/drm/drm_internal.h   |  7 +
 drivers/gpu/drm/drm_print.c  | 21 +
 drivers/gpu/drm/tinydrm/mipi-dbi.c   |  8 +
 include/drm/drm_drv.h| 11 +++
 include/drm/drm_framebuffer.h|  2 +-
 include/drm/drm_gem_cma_helper.h |  5 ++-
 include/drm/drm_print.h  |  2 ++
 include/drm/drm_vma_manager.h|  2 +-
 include/drm/tinydrm/tinydrm.h|  1 +
 14 files changed, 155 insertions(+), 27 deletions(-)

--
2.14.2

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

[PATCH] dt-bindings: display: stm32: add pixel clock mandatory property

Add the DPI/RGB input pixel clock in mandatory properties
because it really offers a better preciseness for timing
computations.
Note: Fix also the DSI panel example where "ref" & "pclk"
clocks were swapped.

Signed-off-by: Philippe Cornu 
---
 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
index 0292522..99823fb 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -28,6 +28,7 @@ Mandatory properties specific to STM32 DSI:
 - #size-cells: Should be <0>.
 - compatible: "st,stm32-dsi".
 - clock-names:
+  - DPI/RGB input pixel clock string name, must be "px_clk".
   - phy pll reference clock string name, must be "ref".
 - resets: see [5].
 - reset-names: see [5].
@@ -97,8 +98,9 @@ Example 2: DSI panel
#size-cells = <0>;
compatible = "st,stm32-dsi";
reg = <0x40016c00 0x800>;
-   clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>;
-   clock-names = "ref", "pclk";
+   clocks = <&rcc 1 CLK_F469_DSI>, <&rcc 1 CLK_LCD>,
+<&clk_hse>;
+   clock-names = "pclk", "px_clk", "ref";
resets = <&rcc STM32F4_APB2_RESET(DSI)>;
reset-names = "apb";
 
-- 
1.9.1

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

[PATCH] drm/bridge/synopsys: dsi: add optional pixel clock

The pixel clock is optional. When available, it offers a better
preciseness for timing computations.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d9cca4f..8b3787d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -225,6 +225,7 @@ struct dw_mipi_dsi {
void __iomem *base;
 
struct clk *pclk;
+   struct clk *px_clk;
 
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -753,24 +754,28 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge 
*bridge,
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
void *priv_data = dsi->plat_data->priv_data;
+   struct drm_display_mode px_clk_mode = *mode;
int ret;
 
clk_prepare_enable(dsi->pclk);
 
-   ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
+   if (dsi->px_clk)
+   px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
+
+   ret = phy_ops->get_lane_mbps(priv_data, &px_clk_mode, dsi->mode_flags,
 dsi->lanes, dsi->format, &dsi->lane_mbps);
if (ret)
DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
 
pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
-   dw_mipi_dsi_dpi_config(dsi, mode);
+   dw_mipi_dsi_dpi_config(dsi, &px_clk_mode);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
-   dw_mipi_dsi_video_packet_config(dsi, mode);
+   dw_mipi_dsi_video_packet_config(dsi, &px_clk_mode);
dw_mipi_dsi_command_mode_config(dsi);
-   dw_mipi_dsi_line_timer_config(dsi, mode);
-   dw_mipi_dsi_vertical_timing_config(dsi, mode);
+   dw_mipi_dsi_line_timer_config(dsi, &px_clk_mode);
+   dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode);
 
dw_mipi_dsi_dphy_init(dsi);
dw_mipi_dsi_dphy_timing_config(dsi);
@@ -784,7 +789,7 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
 
dw_mipi_dsi_dphy_enable(dsi);
 
-   dw_mipi_dsi_wait_for_two_frames(mode);
+   dw_mipi_dsi_wait_for_two_frames(&px_clk_mode);
 
/* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
dw_mipi_dsi_set_mode(dsi, 0);
@@ -878,6 +883,13 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
*bridge)
return ERR_PTR(ret);
}
 
+   dsi->px_clk = devm_clk_get(dev, "px_clk");
+   if (IS_ERR(dsi->px_clk)) {
+   ret = PTR_ERR(dsi->px_clk);
+   dev_dbg(dev, "Unable to get optional px_clk: %d\n", ret);
+   dsi->px_clk = NULL;
+   }
+
/*
 * Note that the reset was not defined in the initial device tree, so
 * we have to be prepared for it not being found.
-- 
1.9.1

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

Re: [RFC PATCH hwc] drm_hwcomposer: provide a common gralloc handle definition

On Thu, Oct 26, 2017 at 6:59 AM, Robert Foss  wrote:
> Hey Rob,
>
> On Tue, 2017-10-24 at 18:40 -0500, Rob Herring wrote:
>> EGL, gralloc, and HWC must all have a common definition of fd's and
>> int's
>> in native_handle_t to share the fd and width, height, format, etc.
>> of a dmabuf.
>>
>> Move the definition into HWC so we aren't dependent on a specific
>> gralloc
>> implementation and so we don't have to create an importer just for
>> different native_handle_t layouts. This will allow supporting
>> multiple
>> gralloc implementations that conform to this layout.
>
> I think this makes sense to me, and is an improvement over the current
> situation.
> As far as I can see there is no perfect way of doing this. But this is
> definitely better.

There's also still a mesa to gralloc dependency to get the device FD.
We don't need that if using render nodes, but we still support
android-x86 using the card node and GEM names. Also, I'm not sure what
to do in the s/w rendering case that still uses the card node. Plus
with Treble, things are moving to separate processes, so retrieving an
FD is broken.

>> Perhaps we should allow for multiple levels of subclassing by only
>> defining
>> the fields we care about here and not validating magic and the size.
>
> So the idea with the subclassing would be for each gralloc
> implementations to be able to add their special sauce?

Right. So the owner and data pointer fields would be gone from here.
Not sure if it is worth the churn and breakage that may cause until
everyone is in sync.

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

Re: [pull] amdgpu dc drm-next-4.15-dc

2017-10-26 Thread Dieter Nützel

Hello Alex & Rex,

any progress?
The 'screen blank' (monitor standby mode) is really annoying.

Thanks,
Dieter

Am 23.10.2017 03:03, schrieb Dieter Nützel:

Am 22.10.2017 23:48, schrieb Dieter Nützel:

Am 21.10.2017 23:22, schrieb Alex Deucher:

Hi Dave,

Now this tree has the same fan regression as 'amd-staging-drm-next'
startet with 0944c350c8eddf4064e7abb881dd245032fdfa23.

Look here:
[amd-staging-drm-next] regression - no fan info (sensors) on RX580
https://lists.freedesktop.org/archives/amd-gfx/2017-October/014065.html

Hello Alex and Rex,

I've found good hint from Jan (randomsalad) on phoronix for the
'screen blank' (monitor standby mode):
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984555#post984555

My Reply:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/984483-amdgpu-dc-gets-a-final-batch-of-changes-before-linux-4-15?p=984581#post984581

I can swear, that I could 'return' one time (the first time, maybe due
to only warm reboot) on 'drm-next-4.15-dc-wip' directly from within
KDE session with replugging the video cable, but for all later tests
on both kernels I have to blindly switching back to login screen
(kdm_greet) and then replugging the video cable.

For me these regression started with 'amd-staging-drm-next' much
earlier than with the latest commit.

Dieter
___
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

[Bug 103408] [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes"

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

--- Comment #4 from shiris...@amd.com ---
I have tested the bisected patch:

drm/amd/display: add hardware_planes_only to list of affected planes

in ChromeOS on Stoney platform and did not find any regression during rendering
or video p/b, also may be the reason why Andy Furniss did not see the issue on
composited full screen.

I have attached a patch in anticipation to the description of bug, please try
it and let me know if it works.

-- 
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 103408] [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes"

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

--- Comment #3 from shiris...@amd.com ---
Created attachment 135062
  --> https://bugs.freedesktop.org/attachment.cgi?id=135062&action=edit
check if modeset is required before adding plane

-- 
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 1/2] drm/rcar-du: Use common error handling code in rcar_du_encoders_init()

2017-10-26 Thread kbuild test robot

Hi Markus,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.14-rc6 next-20171018]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/R-Car-Display-Unit-Fine-tuning-for-some-function-implementations/20171026-160928
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_encoders_init':
>> drivers/gpu/drm/rcar-du/rcar_du_kms.c:415:9: error: 'ret' undeclared (first 
>> use in this function)
 return ret;
^~~
   drivers/gpu/drm/rcar-du/rcar_du_kms.c:415:9: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/gpu/drm/rcar-du/rcar_du_kms.c:416:1: warning: control reaches end of 
>> non-void function [-Wreturn-type]
}
^

vim +/ret +415 drivers/gpu/drm/rcar-du/rcar_du_kms.c

   362  
   363  static int rcar_du_encoders_init(struct rcar_du_device *rcdu)
   364  {
   365  struct device_node *np = rcdu->dev->of_node;
   366  struct device_node *ep_node;
   367  unsigned int num_encoders = 0;
   368  
   369  /*
   370   * Iterate over the endpoints and create one encoder for each 
output
   371   * pipeline.
   372   */
   373  for_each_endpoint_of_node(np, ep_node) {
   374  enum rcar_du_output output;
   375  struct of_endpoint ep;
   376  unsigned int i;
   377  int ret;
   378  
   379  ret = of_graph_parse_endpoint(ep_node, &ep);
   380  if (ret < 0)
   381  goto put_node;
   382  
   383  /* Find the output route corresponding to the port 
number. */
   384  for (i = 0; i < RCAR_DU_OUTPUT_MAX; ++i) {
   385  if (rcdu->info->routes[i].possible_crtcs &&
   386  rcdu->info->routes[i].port == ep.port) {
   387  output = i;
   388  break;
   389  }
   390  }
   391  
   392  if (i == RCAR_DU_OUTPUT_MAX) {
   393  dev_warn(rcdu->dev,
   394   "port %u references unexisting output, 
skipping\n",
   395   ep.port);
   396  continue;
   397  }
   398  
   399  /* Process the output pipeline. */
   400  ret = rcar_du_encoders_init_one(rcdu, output, &ep);
   401  if (ret < 0) {
   402  if (ret == -EPROBE_DEFER)
   403  goto put_node;
   404  
   405  continue;
   406  }
   407  
   408  num_encoders++;
   409  }
   410  
   411  return num_encoders;
   412  
   413  put_node:
   414  of_node_put(ep_node);
 > 415  return ret;
 > 416  }
   417  

---
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: [RFC PATCH hwc] drm_hwcomposer: provide a common gralloc handle definition

2017-10-26 Thread Robert Foss

Hey Rob,

On Tue, 2017-10-24 at 18:40 -0500, Rob Herring wrote:
> EGL, gralloc, and HWC must all have a common definition of fd's and
> int's
> in native_handle_t to share the fd and width, height, format, etc.
> of a dmabuf.
> 
> Move the definition into HWC so we aren't dependent on a specific
> gralloc
> implementation and so we don't have to create an importer just for
> different native_handle_t layouts. This will allow supporting
> multiple
> gralloc implementations that conform to this layout.

I think this makes sense to me, and is an improvement over the current
situation.
As far as I can see there is no perfect way of doing this. But this is
definitely better.

> 
> Perhaps we should allow for multiple levels of subclassing by only
> defining
> the fields we care about here and not validating magic and the size.

So the idea with the subclassing would be for each gralloc
implementations to be able to add their special sauce?

> 
> Signed-off-by: Rob Herring 
> ---
> I'm not sure if there's a better way, but I can't find a way to
> remove 
> the gralloc dependency. At least for EGL, only the fd is needed as
> it 
> has the ANativeWindow and can get all the info from that.
> 
> 
>  Android.mk   |  1 -
>  gralloc_drm_handle.h | 85
> 
>  2 files changed, 85 insertions(+), 1 deletion(-)
>  create mode 100644 gralloc_drm_handle.h
> 
> diff --git a/Android.mk b/Android.mk
> index 611fcb75190b..ee5b8bfb44d0 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -47,7 +47,6 @@ LOCAL_SHARED_LIBRARIES := \
>  LOCAL_STATIC_LIBRARIES := libdrmhwc_utils
>  
>  LOCAL_C_INCLUDES := \
> - external/gbm_gralloc \
>   system/core/libsync
>  
>  LOCAL_SRC_FILES := \
> diff --git a/gralloc_drm_handle.h b/gralloc_drm_handle.h
> new file mode 100644
> index ..aa89e46db619
> --- /dev/null
> +++ b/gralloc_drm_handle.h
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2010-2011 Chia-I Wu 
> + * Copyright (C) 2010-2011 LunarG Inc.
> + * Copyright (C) 2016 Linaro, Ltd., Rob Herring 
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> the
> + * Software is furnished to do so, subject to the following
> conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> included
> + * in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
> OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _GRALLOC_DRM_HANDLE_H_
> +#define _GRALLOC_DRM_HANDLE_H_
> +
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +struct gralloc_drm_handle_t {
> + native_handle_t base;
> +
> + /* file descriptors */
> + int prime_fd;
> +
> + /* integers */
> + int magic;
> +
> + int width;
> + int height;
> + int format;
> + int usage;
> + int stride; /* the stride in bytes */
> + uint64_t modifier; /* buffer modifiers */
> +
> + int data_owner; /* owner of data (for validation) */
> + union {
> + void *data; /* private pointer for gralloc */
> + uint64_t reserved;
> + } __attribute__((aligned(8)));
> +};
> +#define GRALLOC_HANDLE_MAGIC 0x5f47424d
> +#define GRALLOC_HANDLE_NUM_FDS 1
> +#define GRALLOC_HANDLE_NUM_INTS (
>   \
> + ((sizeof(struct gralloc_drm_handle_t) -
> sizeof(native_handle_t))/sizeof(int)) \
> +  - GRALLOC_HANDLE_NUM_FDS)
> +
> +static inline struct gralloc_drm_handle_t
> *gralloc_drm_handle(buffer_handle_t _handle)
> +{
> + struct gralloc_drm_handle_t *handle =
> + (struct gralloc_drm_handle_t *) _handle;
> +
> + if (handle && (handle->base.version != sizeof(handle->base)
> ||
> +    handle->base.numInts !=
> GRALLOC_HANDLE_NUM_INTS ||
> +    handle->base.numFds != GRALLOC_HANDLE_NUM_FDS
> ||
> +    handle->magic != GRALLOC_HANDLE_MAGIC))
> + return NULL;
> +
> + return handle;
> +}
> +
> +static inline int gralloc_drm_get_prime_fd(buffer_handle_t _handle)
> +{
> + struct gralloc_drm_handle_t *handle =
> gralloc_drm_handle(_handle);
> + return (handle) ? handle->prime_fd : -1;
> +}
>

Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

2017-10-26 Thread Tomi Valkeinen

On 24/10/17 01:01, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Oct 13, 2017 at 10:12:08AM -0700, Tony Lindgren wrote:
>> * Tomi Valkeinen  [171012 01:46]:
>>> On 29/09/17 16:26, Sebastian Reichel wrote:
 Hi Tomi & Laurent,

 ping?
>>>
>>> I've been having quick glances at this every now and then, but I'm not
>>> sure what to do with the series.
>>>
>>> We have one work item that more or less overrides everything but
>>> critical fixes: moving to common DRM encoder/panel drivers. Anything
>>> that makes that work more difficult should be postponed.
>>>
>>> Especially patch 6 in this series most likely falls into that category,
>>> and might require a very different implementation with common DRM
>>> drivers. Also everything in panel-dsi-cm needs to be ported to a common
>>> DRM panel driver when can use them.
>>>
>>> So my gut feeling is that it's best to keep this out for now, and rework
>>> it after Laurent gets the common DRM drivers working with omapdrm.
>>
>> Laurent, got any other comments?
>>
>> Maybe some of patches can be already applied to shrink down this
>> set a bit?
> 
> I talked with Laurent at ELCE about this patchset and he is fine
> with this series going in before his work assuming its fine
> otherwise. He has not yet reviewed it, though and is busy the
> next two weeks.
> 
> Regarding the panel-dsi-cm porting work: I will take care of this
> once the driver uses common DRM drivers. I don't expect major
> problems once omapdrm implements common drm's mipi_dsi_host. I
> do use the standard DT properties already.
> 
> I do agree, that not applying this series makes Laurent's porting
> work easier, since he can rip out all of DSI. It's not used by
> anything except panel-dsi-cm, which is broken without this patchset.
> I don't think that's a fair thing to do, though.
> 
> P.S.: I got asked by different people about the status of this
> patchset, which is required for display support on N9, N950 and
> Droid 4. It's not just me and Tony, that are interested in this :)

Ok. If you agree to help with the DSI part in the future, I have no
problems applying these (after review and testing, of course).

My worry is not only with complicating Laurent's work towards common DRM
drivers, but also with the maintenance burden this brings. Keeping DSI
working in the future may be challenging due to the lack of users and
(easy to use) boards. I do have a N950 and OMAP4 Blaze Tablet, though,
so I'm able to test both command and video modes. But getting those boot
up is not always trivial, especially for the blaze tablet.

I've also spent many hours this year debugging obscure OMAP3 DSS HW
issues, so my opinion about adding more OMAP3 DSS features may be a bit
biased =).

I'll have a look at this series when I find a bit of spare time.

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 1/2] dt-bindings: display: stm32: add a 2nd endpoint

ltdc can have up to 2 endpoints:
 - dpi external gpios: for rgb panels or external bridge ICs.
 - dpi internal ios: connected internally to dsi.

Note: Refer to the reference manual to know if the dsi is
present on your device.

Signed-off-by: Philippe Cornu 
---
 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
index 74b5ac7..0292522 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -10,7 +10,11 @@
   - "lcd" for the clock feeding the output pixel clock & IP clock.
   - resets: reset to be used by the device (defined by use of RCC macro).
   Required nodes:
-- Video port for RGB output.
+  - Video port for DPI RGB output: ltdc has one video port with up to 2
+endpoints:
+  - for external dpi rgb panel or bridge, using gpios.
+  - for internal dpi input of the MIPI DSI host controller.
+  Note: These 2 endpoints cannot be activated simultaneously.
 
 * STMicroelectronics STM32 DSI controller specific extensions to Synopsys
   DesignWare MIPI DSI host controller
-- 
1.9.1

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

[PATCH v1 2/2] drm/stm: ltdc: add a 2nd endpoint

ltdc can have up to 2 endpoints:
 - dpi external gpios: for rgb panels or external bridge ICs.
 - dpi internal ios: connected internally to dsi.

Note: Refer to the reference manual to know if the dsi is
present on your device.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/ltdc.c | 64 --
 1 file changed, 45 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index d5c8a42..38a6739 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -33,6 +33,8 @@
 
 #define MAX_IRQ 4
 
+#define MAX_ENDPOINTS 2
+
 #define HWVER_10200 0x010200
 #define HWVER_10300 0x010300
 #define HWVER_20101 0x020101
@@ -886,18 +888,33 @@ int ltdc_load(struct drm_device *ddev)
struct ltdc_device *ldev = ddev->dev_private;
struct device *dev = ddev->dev;
struct device_node *np = dev->of_node;
-   struct drm_bridge *bridge;
-   struct drm_panel *panel;
+   struct drm_bridge *bridge[MAX_ENDPOINTS] = {NULL};
+   struct drm_panel *panel[MAX_ENDPOINTS] = {NULL};
struct drm_crtc *crtc;
struct reset_control *rstc;
struct resource *res;
-   int irq, ret, i;
+   int irq, ret, i, endpoint_not_ready = -ENODEV;
 
DRM_DEBUG_DRIVER("\n");
 
-   ret = drm_of_find_panel_or_bridge(np, 0, 0, &panel, &bridge);
-   if (ret)
-   return ret;
+   /* Get endpoints if any */
+   for (i = 0; i < MAX_ENDPOINTS; i++) {
+   ret = drm_of_find_panel_or_bridge(np, 0, i, &panel[i],
+ &bridge[i]);
+
+   /*
+* If at least one endpoint is ready, continue probing,
+* else if at least one endpoint is -EPROBE_DEFER and
+* there is no previous ready endpoints, defer probing.
+*/
+   if (!ret)
+   endpoint_not_ready = 0;
+   else if (ret == -EPROBE_DEFER && endpoint_not_ready)
+   endpoint_not_ready = -EPROBE_DEFER;
+   }
+
+   if (endpoint_not_ready)
+   return endpoint_not_ready;
 
rstc = devm_reset_control_get_exclusive(dev, NULL);
 
@@ -958,19 +975,25 @@ int ltdc_load(struct drm_device *ddev)
 
DRM_INFO("ltdc hw version 0x%08x - ready\n", ldev->caps.hw_version);
 
-   if (panel) {
-   bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
-   if (IS_ERR(bridge)) {
-   DRM_ERROR("Failed to create panel-bridge\n");
-   ret = PTR_ERR(bridge);
-   goto err;
+   /* Add endpoints panels or bridges if any */
+   for (i = 0; i < MAX_ENDPOINTS; i++) {
+   if (panel[i]) {
+   bridge[i] = drm_panel_bridge_add(panel[i],
+   DRM_MODE_CONNECTOR_DPI);
+   if (IS_ERR(bridge[i])) {
+   DRM_ERROR("panel-bridge endpoint %d\n", i);
+   ret = PTR_ERR(bridge[i]);
+   goto err;
+   }
}
-   }
 
-   ret = ltdc_encoder_init(ddev, bridge);
-   if (ret) {
-   DRM_ERROR("Failed to init encoder\n");
-   goto err;
+   if (bridge[i]) {
+   ret = ltdc_encoder_init(ddev, bridge[i]);
+   if (ret) {
+   DRM_ERROR("init encoder endpoint %d\n", i);
+   goto err;
+   }
+   }
}
 
crtc = devm_kzalloc(dev, sizeof(*crtc), GFP_KERNEL);
@@ -998,7 +1021,8 @@ int ltdc_load(struct drm_device *ddev)
return 0;
 
 err:
-   drm_panel_bridge_remove(bridge);
+   for (i = 0; i < MAX_ENDPOINTS; i++)
+   drm_panel_bridge_remove(bridge[i]);
 
clk_disable_unprepare(ldev->pixel_clk);
 
@@ -1008,10 +1032,12 @@ int ltdc_load(struct drm_device *ddev)
 void ltdc_unload(struct drm_device *ddev)
 {
struct ltdc_device *ldev = ddev->dev_private;
+   int i;
 
DRM_DEBUG_DRIVER("\n");
 
-   drm_of_panel_bridge_remove(ddev->dev->of_node, 0, 0);
+   for (i = 0; i < MAX_ENDPOINTS; i++)
+   drm_of_panel_bridge_remove(ddev->dev->of_node, 0, i);
 
clk_disable_unprepare(ldev->pixel_clk);
 }
-- 
1.9.1

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

[PATCH v1 0/2] drm/stm: ltdc: add a 2nd endpoint

Version 1:
- Initial commit

The purpose of this set of patches is to offer the possibility
to use up to 2 endpoints for the ltdc dpi video port.

Philippe Cornu (2):
  dt-bindings: display: stm32: add a 2nd endpoint
  drm/stm: ltdc: add a 2nd endpoint

 .../devicetree/bindings/display/st,stm32-ltdc.txt  |  6 +-
 drivers/gpu/drm/stm/ltdc.c | 64 +++---
 2 files changed, 50 insertions(+), 20 deletions(-)

-- 
1.9.1

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

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

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, base.id);
 
/* Add planes. Note : the first layer is used by primary plane */
-- 
1.9.1

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

RE: [PATCH] drm/amd/display: assign fb_location only if bo is pinned

2017-10-26 Thread S, Shirish

I have reverted 
[PATCH 2/2] drm/amd/display: cleanup addReq and fix fb_location
and applied 
[PATCH] drm/amd/display: fix high part address in dm_plane_helper_prepare_fb()
onto amd-drm-staging kernel.

Regards,
Shirish S

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Wednesday, October 25, 2017 3:54 PM
To: S, Shirish ; Grodzovsky, Andrey 

Cc: Deucher, Alexander ; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/display: assign fb_location only if bo is pinned

On 25/10/17 12:05 PM, S, Shirish wrote:
> Hi Alex, Michel & Andrey,
> 
>  [PATCH] drm/amd/display: assign fb_location only if bo is pinned  
> [PATCH 2/2] drm/amd/display: cleanup addReq and fix fb_location
> 
> should be dropped and instead:

Since you pushed the latter to amd-staging-drm-next, please revert it there, or 
maybe submit another patch removing all fb_location related code from 
get_fb_info and fill_plane_attributes_from_fb.

> [PATCH] drm/amd/display: fix high part address in 
> dm_plane_helper_prepare_fb()
> 
> should be reviewed .

Reviewed-by: Michel Dänzer 

But please wait for review from DC folks.

-- 
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

[PATCH] drm/stm: checkpatch strict minor updates

Minor fixes detected with "scripts/checkpatch.pl --strict"

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 4 ++--
 drivers/gpu/drm/stm/ltdc.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 10b2b77..3e8b9ed 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -129,7 +129,7 @@ static int dsi_pll_get_params(int clkin_khz, int clkout_khz,
int fvco_min, fvco_max, delta, best_delta; /* all in khz */
 
/* Early checks preventing division by 0 & odd results */
-   if ((clkin_khz <= 0) || (clkout_khz <= 0))
+   if (clkin_khz <= 0 || clkout_khz <= 0)
return -EINVAL;
 
fvco_min = LANE_MIN_KBPS * 2 * ODF_MAX;
@@ -155,7 +155,7 @@ static int dsi_pll_get_params(int clkin_khz, int clkout_khz,
for (o = ODF_MIN; o <= ODF_MAX; o *= 2) {
n = DIV_ROUND_CLOSEST(i * o * clkout_khz, clkin_khz);
/* Check ndiv according to vco range */
-   if ((n < n_min) || (n > n_max))
+   if (n < n_min || n > n_max)
continue;
/* Check if new delta is better & saves parameters */
delta = dsi_pll_get_clkout_khz(clkin_khz, i, n, o) -
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 735c908..7be6710 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -556,7 +556,7 @@ static int ltdc_plane_atomic_check(struct drm_plane *plane,
src_h = state->src_h >> 16;
 
/* Reject scaling */
-   if ((src_w != state->crtc_w) || (src_h != state->crtc_h)) {
+   if (src_w != state->crtc_w || src_h != state->crtc_h) {
DRM_ERROR("Scaling is not supported");
return -EINVAL;
}
-- 
1.9.1

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

Re: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting

2017-10-26 Thread Philippe CORNU

Hi,

On 10/26/2017 06:13 AM, Archit Taneja wrote:
> Hi,
> 
> On 10/26/2017 06:39 AM, Brian Norris wrote:
>> On Wed, Oct 25, 2017 at 03:57:19AM -0400, Sean Paul wrote:
>>> Archit asked a question about moving to
>>> dw-mipi-dsi
>>
>> That question made me think though: this approach seems backwards. It
>> seems like someone did copy/paste/fork, and then we're asking the
>> authors of the original driver to un-fork? It seems like this should
>> happen the other way around -- those trying to support a new incarnation
>> should have looked to try to abstract the original driver for their
>> uses first.
> 
> Yes, ST wanted to replicate rockchip's version of the mipi DSI driver and
> put it in their folder. If they did that, their KMS driver would have been
> the third driver to implement a third instance of the DW DSI controller 
> driver.
> Hisilicon and Rockchip being the other 2.
> 
> It was either that or attempt at a common DSI DW bridge driver. I suggested
> the latter.
> 
> The ST guys have abstracted out the PHY pieces, which they knew varied 
> between
> rockchip and ST. Ideally, they should have also tried to create a RFC 
> patch to
> make the rockchip driver use the bridge too. But they didn't do that, and
> the rockchip or hisilicon people were interested in even looking at it,
> even after I CC'ed them.
> 
>>
>> IIUC, that's exactly what Rockchip did for much of their Analogix eDP
>> code -- they reworked the Exynos DP driver to split common Analogix code
>> from any Exynos-specific bits.
> 
> I get that. I had hoped either ST or Rockchip guys would have done the 
> similar
> thing, but no one volunteered.
> 
>>
>> And actually, the current stuff in
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c is completely unused. It
>> exports some functions, but I see no users of it. Is that intended? Is
> 
> The ST kms driver uses it:
> 
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> 

I confirm STM32 chipsets use the Synopsys dw dsi bridge driver.

I plan to improve this bridge driver by adding new features (see todos + 
dsi read, command mode with bta & gpio...).

For the first commit, I did my best to keep the source code as close as 
possible to the Rockchip version, in order to ease the port for Rockchip 
guys.

>> somebody already working on refactoring existing Rockchip code to use
>> this?
> 
> I don't know. If rockchip isn't interested in doing it, we can check with
> Philippe from ST if he can try creating a RFC that converts the rockchip
> driver to use the dw-mipi-dsi driver.

I am not really interested in doing this port for Rockchip (or Hisilicon 
or i.MX...) but happy to help anyone that wants to use the dw-mipi-dsi 
bridge driver :)

Many thanks,
Philippe :)

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

[PATCH] drm/stm: dsi: Rename driver name

Rename the driver name from "dw_mipi_dsi-stm" to
"stm32-display-dsi" for a better readability
in /sys/bus/platform/drivers entries.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index e5b6310..10b2b77 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -342,7 +342,7 @@ static int dw_mipi_dsi_stm_remove(struct platform_device 
*pdev)
.remove = dw_mipi_dsi_stm_remove,
.driver = {
.of_match_table = dw_mipi_dsi_stm_dt_ids,
-   .name   = "dw_mipi_dsi-stm",
+   .name   = "stm32-display-dsi",
},
 };
 
-- 
1.9.1

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

[Bug 103413] R9285 Xonotic gpu lock since radeonsi: split si_emit_shader_pointer

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

--- Comment #1 from Andy Furniss  ---
Lots of "normal" runs indicated the commit before the "bad" is OK - I've not
locked doing many of

vblank_mode=0 ./xonotic-linux64-glx -benchmarkruns 20 -benchmark
demos/the-big-keybench.dem

cpu & gpu set high for testing.
vblank_mode=0 or the perf settings are not required to provoke lock, they are
just much faster to get the multiple runs in.

xonotic settings are ultra with aniso and aa highest, 1920x1080 fullscreen.

Unfortunately, I tried a more abnormal test = with a 2160p framebuffer +
panning and like that I can still lock. Locks are again in same place, but that
place is different = frame 9411.

Over time I'll try to go back further.

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #10 from Dennis Schridde  ---
(In reply to Michel Dänzer from comment #9)
> (In reply to Dennis Schridde from comment #0)
> > During a boot like this, the second card (AMD Radeon RX 560) fails to come 
> > up
> > and is not available to the system.
> 
> That's actually because of:
> 
>  [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed
> (scratch(0xC040)=0xCAFEDEAD)
>  [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block 
> failed -22
>  amdgpu :01:00.0: amdgpu_init failed
> 
> the other messages are probably mostly harmless / not directly related to
> this problem.
> 
> 
> > * Hangs of the entire system when I start Steam using `env DRI_PRIME=1
> > steam` (nothing reacts to commands anymore, including mouse clicks, the 
> > power
> > button and the num-lock key, and the mouse cursor moves very sluggishly)
> 
> That's probably related to the above.

Clarification / more information: The missing RX 560 happens for a few boots
*after* the full system hang.  I.e. first I run Steam with DRI_PRIME=1, click
around for a bit until the system hangs (sometimes waiting alone seems to be
enough, though), then I hard-reset the system, when Linux started the RX 560 is
missing, I reboot, RX 560 is still missing, ... (loop for a few iterations)
..., RX 560 is back and we have a "regular boot".

> > * The firmware and GRUB (and Linux, initially) display at 1024x768, while
> > the monitor's native resolution is 2560x1080.
> 
> That's a motherboard firmware / video card ROM issue, nothing to do with the
> Linux kernel / drivers.

One more bit of information (though probably still unrelated): The resolution
is correct when I do not plug in the RX 560, or connect the display to the RX
560 directly (and setup the mainboard firmware to use the dGPU as primary video
adapter).

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #9 from Michel Dänzer  ---
(In reply to Dennis Schridde from comment #0)
> During a boot like this, the second card (AMD Radeon RX 560) fails to come up
> and is not available to the system.

That's actually because of:

 [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed
(scratch(0xC040)=0xCAFEDEAD)
 [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block 
failed -22
 amdgpu :01:00.0: amdgpu_init failed

the other messages are probably mostly harmless / not directly related to this
problem.


> * Hangs of the entire system when I start Steam using `env DRI_PRIME=1
> steam` (nothing reacts to commands anymore, including mouse clicks, the power
> button and the num-lock key, and the mouse cursor moves very sluggishly)

That's probably related to the above.


> * The firmware and GRUB (and Linux, initially) display at 1024x768, while
> the monitor's native resolution is 2560x1080.

That's a motherboard firmware / video card ROM issue, nothing to do with the
Linux kernel / drivers.

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #135050|text/x-log  |text/plain
  mime type||

-- 
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 103370] `DRI_PRIME=1 glxgears -info` halts the system with Intel Graphics [8086:5917] + AMD Graphics [1002:6665].

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

--- Comment #23 from Mike Lothian  ---
Can you show the dmesg and Xorg.0.log with radeon.si_support=0
amdgpu.si_support=1

On Thu, 26 Oct 2017 at 05:17  wrote:

> *Comment # 22  on
> bug 103370  from
> Shih-Yuan Lee  *
>
> (In reply to Mike Lothian from comment #19 
> )> You have to 
> blacklist radeon to use amdgpu as both modules try and claim the
> > device
>
> After I blacklist radeon, there is no AMD graphics provider from `xrandr
> --listproviders`.
>
> [1.937326] amdgpu :01:00.0: enabling device ( -> 0003)
> [1.937633] amdgpu :01:00.0: SI support provided by radeon.
> [1.937635] amdgpu :01:00.0: Use radeon.si_support=0 
> amdgpu.si_support=1
> to override.
>
> After I use 'radeon.si_support=0 amdgpu.si_support=1', X window system can not
> start up.
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

Dennis Schridde  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=103234

-- 
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 103234] KWin crashed when Alt+Tab-ing through open windows

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

Dennis Schridde  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=103463

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #7 from Dennis Schridde  ---
Created attachment 135057
  --> https://bugs.freedesktop.org/attachment.cgi?id=135057&action=edit
glxinfo (regular boot)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #8 from Dennis Schridde  ---
Created attachment 135058
  --> https://bugs.freedesktop.org/attachment.cgi?id=135058&action=edit
glxinfo (regular boot, DRI_PRIME=1)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #5 from Dennis Schridde  ---
Created attachment 135055
  --> https://bugs.freedesktop.org/attachment.cgi?id=135055&action=edit
lspci (regular boot)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #6 from Dennis Schridde  ---
Created attachment 135056
  --> https://bugs.freedesktop.org/attachment.cgi?id=135056&action=edit
glxinfo (broken boot)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #4 from Dennis Schridde  ---
Created attachment 135054
  --> https://bugs.freedesktop.org/attachment.cgi?id=135054&action=edit
lspci (broken boot)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #2 from Dennis Schridde  ---
Created attachment 135052
  --> https://bugs.freedesktop.org/attachment.cgi?id=135052&action=edit
lshw (broken boot)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #1 from Dennis Schridde  ---
Created attachment 135051
  --> https://bugs.freedesktop.org/attachment.cgi?id=135051&action=edit
dmesg (regular boot)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)

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

--- Comment #3 from Dennis Schridde  ---
Created attachment 135053
  --> https://bugs.freedesktop.org/attachment.cgi?id=135053&action=edit
lshw (regular boot)

-- 
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 103463] [drm:amdgpu_get_bios [amdgpu]] ERROR ACPI VFCT table present but broken (too short #2)