[PATCH 7/7] vulkan: Add VK_GOOGLE_display_timing extension (x11 and display backends)

[Keith Packard]

This adds support for the VK_GOOGLE_display timing extension, which
provides two things:

 1) Detailed information about when frames are displayed, including
slack time between GPU execution and display frame.

 2) Absolute time control over swapchain queue processing. This allows
the application to request frames be displayed at specific
absolute times, using the same timebase as that provided in vblank
events.

Support for this extension has been implemented for the x11 and
display backends; adding support to other backends should be
reasonable straightforward for one familiar with those systems and
should not require any additional device-specific code.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py   |   1 +
 src/amd/vulkan/radv_wsi.c   |  32 +
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_wsi.c  |  29 
 src/vulkan/wsi/wsi_common.c | 254 +++-
 src/vulkan/wsi/wsi_common.h |  24 
 src/vulkan/wsi/wsi_common_display.c | 143 +++-
 src/vulkan/wsi/wsi_common_private.h |  35 +
 src/vulkan/wsi/wsi_common_x11.c |  69 +-
 9 files changed, 577 insertions(+), 11 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index fed198df412..f38d6903a80 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -96,6 +96,7 @@ EXTENSIONS = [
 Extension('VK_AMD_rasterization_order',   1, 
'device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2'),
 Extension('VK_AMD_shader_info',   1, True),
 Extension('VK_MESA_query_timestamp',  1, True),
+Extension('VK_GOOGLE_display_timing', 1, True),
 ]
 
 class VkVersion:
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 2d2a30ebbb1..48ff7107232 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -247,3 +247,35 @@ VkResult radv_QueuePresentKHR(
queue->queue_family_index,
pPresentInfo);
 }
+
+/* VK_GOOGLE_display_timing */
+VkResult
+radv_GetRefreshCycleDurationGOOGLE(
+   VkDevice  _device,
+   VkSwapchainKHRswapchain,
+   VkRefreshCycleDurationGOOGLE  *pDisplayTimingProperties)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_refresh_cycle_duration(>wsi_device,
+_device,
+swapchain,
+pDisplayTimingProperties);
+}
+
+VkResult
+radv_GetPastPresentationTimingGOOGLE(VkDevice
_device,
+VkSwapchainKHR  
swapchain,
+uint32_t
*pPresentationTimingCount,
+VkPastPresentationTimingGOOGLE  
*pPresentationTimings)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_past_presentation_timing(>wsi_device,
+  _device,
+  swapchain,
+  pPresentationTimingCount,
+  pPresentationTimings);
+}
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index dd4d5a1f970..c45ef9ad09f 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -92,6 +92,7 @@ EXTENSIONS = [
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_MESA_query_timestamp',  1, True),
+Extension('VK_GOOGLE_display_timing', 1, True),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 52362adfb71..7801a989e0d 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -239,3 +239,32 @@ VkResult anv_QueuePresentKHR(
_queue, 0,
pPresentInfo);
 }
+
+/* VK_GOOGLE_display_timing */
+VkResult
+anv_GetRefreshCycleDurationGOOGLE(VkDevice  _device,
+  VkSwapchainKHRswapchain,
+  VkRefreshCycleDurationGOOGLE  
*pDisplayTimingProperties)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+
+   

[PATCH 4/7] vulkan: Add VK_EXT_display_surface_counter [v4]

[Keith Packard]

This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

v2: Thanks to kisak

Fix spelling of VkSurfaceCapabilities2EXT in wsi_common_wayland.c,
it was using ext instead of EXT.

Fix spelling of VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT

v3: Fix wayland WSI, regularize spelling

Misspelled 'surface' in get_capabilities2ext
Remove extra _ from get_capabilities_2ext in a couple of places

v4: Add anv support

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py   |  1 +
 src/amd/vulkan/radv_wsi.c   | 12 
 src/intel/vulkan/anv_extensions.py  |  1 +
 src/intel/vulkan/anv_wsi.c  | 12 
 src/vulkan/wsi/wsi_common.c | 11 +++
 src/vulkan/wsi/wsi_common.h |  5 +
 src/vulkan/wsi/wsi_common_display.c | 27 +++
 src/vulkan/wsi/wsi_common_private.h |  2 ++
 src/vulkan/wsi/wsi_common_wayland.c | 27 +++
 src/vulkan/wsi/wsi_common_x11.c | 27 +++
 10 files changed, 125 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 2d804afed35..3f315e074b5 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -84,6 +84,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
+Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, '!ANDROID'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_discard_rectangles',1, True),
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 5ec872a63d0..2d2a30ebbb1 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -103,6 +103,18 @@ VkResult radv_GetPhysicalDeviceSurfaceCapabilities2KHR(
pSurfaceCapabilities);
 }
 
+VkResult radv_GetPhysicalDeviceSurfaceCapabilities2EXT(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   VkSurfaceCapabilities2EXT*  pSurfaceCapabilities)
+{
+   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_surface_capabilities2ext(>wsi_device,
+   surface,
+   pSurfaceCapabilities);
+}
+
 VkResult radv_GetPhysicalDeviceSurfaceFormatsKHR(
VkPhysicalDevicephysicalDevice,
VkSurfaceKHRsurface,
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 32a240acdcb..8265077d894 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -89,6 +89,7 @@ EXTENSIONS = [
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
+Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index f86d83589ea..52362adfb71 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -104,6 +104,18 @@ VkResult anv_GetPhysicalDeviceSurfaceCapabilities2KHR(
pSurfaceCapabilities);
 }
 
+VkResult anv_GetPhysicalDeviceSurfaceCapabilities2EXT(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   VkSurfaceCapabilities2EXT*  pSurfaceCapabilities)
+{
+   ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_surface_capabilities2ext(>wsi_device,
+  surface,
+  pSurfaceCapabilities);
+}
+
 VkResult anv_GetPhysicalDeviceSurfaceFormatsKHR(
 VkPhysicalDevicephysicalDevice,
 VkSurfaceKHRsurface,
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index c0a285e5814..02abc9ef7fb 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -579,6 +579,17 @@ wsi_common_get_surface_capabilities2(struct wsi_device 
*wsi_device,
pSurfaceCapabilities);
 }
 
+VkResult

[PATCH 2/7] vulkan: Add EXT_direct_mode_display

[Keith Packard]

Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py   |  1 +
 src/amd/vulkan/radv_wsi_display.c   | 11 +++
 src/intel/vulkan/anv_extensions.py  |  1 +
 src/intel/vulkan/anv_wsi_display.c  | 11 +++
 src/vulkan/wsi/wsi_common_display.c | 17 +
 src/vulkan/wsi/wsi_common_display.h |  5 +
 6 files changed, 46 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 24cab8cbb39..f784681ff57 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -82,6 +82,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xcb_surface',   6, 
'VK_USE_PLATFORM_XCB_KHR'),
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHR_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, '!ANDROID'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_discard_rectangles',1, True),
diff --git a/src/amd/vulkan/radv_wsi_display.c 
b/src/amd/vulkan/radv_wsi_display.c
index b0a4db0344b..0051f5ac865 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -141,3 +141,14 @@ radv_CreateDisplayPlaneSurfaceKHR(VkInstance   
 _instanc
 
return wsi_create_display_surface(_instance, alloc, create_info, surface);
 }
+
+VkResult
+radv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
+   VkDisplayKHR display)
+{
+   RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+   return wsi_release_display(physical_device,
+  >wsi_device,
+  display);
+}
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 978a219e2b2..633e378e605 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -84,6 +84,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xcb_surface',   6, 
'VK_USE_PLATFORM_XCB_KHR'),
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHR_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
diff --git a/src/intel/vulkan/anv_wsi_display.c 
b/src/intel/vulkan/anv_wsi_display.c
index 9b00d7f02e4..e6f67f7dec9 100644
--- a/src/intel/vulkan/anv_wsi_display.c
+++ b/src/intel/vulkan/anv_wsi_display.c
@@ -127,3 +127,14 @@ anv_CreateDisplayPlaneSurfaceKHR(VkInstance
_instance
 
return wsi_create_display_surface(_instance, alloc, create_info, surface);
 }
+
+VkResult
+anv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
+   VkDisplayKHR display)
+{
+   ANV_FROM_HANDLE(anv_physical_device, pdevice, physical_device);
+
+   return wsi_release_display(physical_device,
+  >wsi_device,
+  display);
+}
diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index 2732b1dd721..5c123e6465e 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -1366,3 +1366,20 @@ wsi_display_finish_wsi(struct wsi_device *wsi_device,
   vk_free(alloc, wsi);
}
 }
+
+/*
+ * Implement vkReleaseDisplay
+ */
+VkResult
+wsi_release_display(VkPhysicalDevicephysical_device,
+struct wsi_device   *wsi_device,
+VkDisplayKHRdisplay)
+{
+   struct wsi_display   *wsi = (struct wsi_display *) 
wsi_device->wsi[VK_ICD_WSI_PLATFORM_DISPLAY];
+
+   if (wsi->master_fd >= 0 && wsi->master_fd != wsi->render_fd) {
+  close(wsi->master_fd);
+  wsi->master_fd = -1;
+   }
+   return VK_SUCCESS;
+}
diff --git a/src/vulkan/wsi/wsi_common_display.h 
b/src/vulkan/wsi/wsi_common_display.h
index b414a226293..5fbb6925e4a 100644
--- a/src/vulkan/wsi/wsi_common_display.h
+++ b/src/vulkan/wsi/wsi_common_display.h
@@ -69,4 +69,9 @@ wsi_create_display_surface(VkInstance instance,
const VkDisplaySurfaceCreateInfoKHR *pCreateInfo,
VkSurfaceKHR *pSurface);
 
+VkResult
+wsi_release_display(VkPhysicalDevicephysical_device,
+struct wsi_device   *wsi_device,
+VkDisplayKHR  

[PATCH 6/7] vulkan: Add new VK_MESA_query_timestamp extension

[Keith Packard]

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.

Signed-off-by: Keith Packard 
---
 include/vulkan/vulkan.h |  6 ++
 src/Makefile.am |  1 +
 src/amd/vulkan/Makefile.am  |  3 +++
 src/amd/vulkan/meson.build  |  8 
 src/amd/vulkan/radv_device.c|  8 
 src/amd/vulkan/radv_extensions.py   |  1 +
 src/intel/Makefile.vulkan.am|  7 +++
 src/intel/vulkan/anv_extensions.py  |  1 +
 src/intel/vulkan/anv_gem.c  | 13 +
 src/intel/vulkan/anv_private.h  |  1 +
 src/intel/vulkan/genX_query.c   | 15 +++
 src/intel/vulkan/meson.build| 12 ++--
 src/vulkan/meson.build  |  1 +
 src/vulkan/registry/vk_mesa_query_timestamp.xml | 22 ++
 14 files changed, 89 insertions(+), 10 deletions(-)
 create mode 100644 src/vulkan/registry/vk_mesa_query_timestamp.xml

diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
index d3e2e246cf3..5523eb7586f 100644
--- a/include/vulkan/vulkan.h
+++ b/include/vulkan/vulkan.h
@@ -7025,6 +7025,12 @@ VKAPI_ATTR VkResult VKAPI_CALL 
vkGetMemoryHostPointerPropertiesEXT(
 VkMemoryHostPointerPropertiesEXT*   pMemoryHostPointerProperties);
 #endif
 
+typedef VkResult (VKAPI_PTR *PFN_vkQueryCurrentTimestampMESA)(VkDevice device, 
uint64_t *timestamp);
+
+VKAPI_ATTR VkResult VKAPI_CALL vkQueryCurrentTimestampMESA(
+VkDevice_device,
+uint64_t*timestamp);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/Makefile.am b/src/Makefile.am
index 014ffaf3e29..74ff305d7c6 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -68,6 +68,7 @@ endif
 
 EXTRA_DIST += vulkan/registry/vk.xml
 EXTRA_DIST += vulkan/registry/vk_android_native_buffer.xml
+EXTRA_DIST += vulkan/registry/vk_mesa_query_timestamp.xml
 
 if HAVE_AMD_DRIVERS
 SUBDIRS += amd
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 94ece06e99e..0626fa2b3b3 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -129,12 +129,14 @@ libvulkan_radeon_la_SOURCES = $(VULKAN_GEM_FILES)
 
 vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
 vk_android_native_buffer_xml = 
$(top_srcdir)/src/vulkan/registry/vk_android_native_buffer.xml
+vk_mesa_query_timestamp_xml = 
$(top_srcdir)/src/vulkan/registry/vk_mesa_query_timestamps.xml
 
 radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py 
$(vulkan_api_xml)
$(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_entrypoints_gen.py \
--xml $(vulkan_api_xml) \
--xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
--outdir $(builddir)
 radv_entrypoints.h: radv_entrypoints.c
 
@@ -144,6 +146,7 @@ radv_extensions.c: radv_extensions.py \
$(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_extensions.py \
--xml $(vulkan_api_xml) \
--xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
--out $@
 
 vk_format_table.c: vk_format_table.py \
diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
index 0b92a1763a1..34f578476c0 100644
--- a/src/amd/vulkan/meson.build
+++ b/src/amd/vulkan/meson.build
@@ -20,10 +20,10 @@
 
 radv_entrypoints = custom_target(
   'radv_entrypoints.[ch]',
-  input : ['radv_entrypoints_gen.py', vk_api_xml],
+  input : ['radv_entrypoints_gen.py', vk_api_xml, 
vk_android_native_buffer_xml, vk_mesa_query_timestamp_xml],
   output : ['radv_entrypoints.h', 'radv_entrypoints.c'],
   command : [
-prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--outdir',
+prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--xml', '@INPUT3@', '--outdir',
 meson.current_build_dir()
   ],
   depend_files : files('radv_extensions.py'),
@@ -31,10 +31,10 @@ radv_entrypoints = custom_target(
 
 radv_extensions_c = custom_target(
   'radv_extensions.c',
-  input : ['radv_extensions.py', vk_api_xml, vk_android_native_buffer_xml],
+  input : ['radv_extensions.py', vk_api_xml, vk_android_native_buffer_xml, 
vk_mesa_query_timestamp_xml],
   output : ['radv_extensions.c'],
   command : [
-prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--out', '@OUTPUT@',
+prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--xml', '@INPUT3@', '--out', '@OUTPUT@',
   ],
 )
 
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index adf33eb35dc..6c13efba9e0 100644
--- 

[PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

This adds support for the KHR_display extension to the anv and radv
Vulkan drivers. The drivers now attempt to open the master DRM node
when the KHR_display extension is requested so that the common winsys
code can perform the necessary operations.

Signed-off-by: Keith Packard 
---
 configure.ac   |1 +
 meson.build|4 +-
 src/amd/vulkan/Makefile.am |8 +
 src/amd/vulkan/Makefile.sources|3 +
 src/amd/vulkan/meson.build |7 +
 src/amd/vulkan/radv_device.c   |   28 +-
 src/amd/vulkan/radv_extensions.py  |7 +-
 src/amd/vulkan/radv_private.h  |2 +
 src/amd/vulkan/radv_wsi.c  |3 +-
 src/amd/vulkan/radv_wsi_display.c  |  143 
 src/intel/Makefile.sources |3 +
 src/intel/Makefile.vulkan.am   |7 +
 src/intel/vulkan/anv_device.c  |   18 +-
 src/intel/vulkan/anv_extensions.py |1 +
 src/intel/vulkan/anv_extensions_gen.py |5 +-
 src/intel/vulkan/anv_wsi.c |3 +-
 src/intel/vulkan/anv_wsi_display.c |  129 +++
 src/intel/vulkan/meson.build   |7 +
 src/vulkan/Makefile.am |7 +
 src/vulkan/Makefile.sources|4 +
 src/vulkan/wsi/meson.build |   10 +
 src/vulkan/wsi/wsi_common.c|   19 +-
 src/vulkan/wsi/wsi_common.h|5 +-
 src/vulkan/wsi/wsi_common_display.c| 1368 
 src/vulkan/wsi/wsi_common_display.h|   72 ++
 src/vulkan/wsi/wsi_common_private.h|   10 +
 26 files changed, 1858 insertions(+), 16 deletions(-)
 create mode 100644 src/amd/vulkan/radv_wsi_display.c
 create mode 100644 src/intel/vulkan/anv_wsi_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.h

diff --git a/configure.ac b/configure.ac
index 8ed606c7694..46318365603 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1849,6 +1849,7 @@ fi
 AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
 AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
 AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
+AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$platforms" | grep -q 'drm')
 AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
'surfaceless')
 AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
 
diff --git a/meson.build b/meson.build
index b39e2f8ab96..aeb7f5e2917 100644
--- a/meson.build
+++ b/meson.build
@@ -239,11 +239,12 @@ with_platform_wayland = false
 with_platform_x11 = false
 with_platform_drm = false
 with_platform_surfaceless = false
+with_platform_display = false
 egl_native_platform = ''
 _platforms = get_option('platforms')
 if _platforms == 'auto'
   if system_has_kms_drm
-_platforms = 'x11,wayland,drm,surfaceless'
+_platforms = 'x11,wayland,drm,surfaceless,display'
   elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
 _platforms = 'x11,surfaceless'
   else
@@ -257,6 +258,7 @@ if _platforms != ''
   with_platform_wayland = _split.contains('wayland')
   with_platform_drm = _split.contains('drm')
   with_platform_surfaceless = _split.contains('surfaceless')
+  with_platform_display = _split.contains('display')
   egl_native_platform = _split[0]
 endif
 
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 61025968942..061b8144b88 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -76,6 +76,14 @@ VULKAN_LIB_DEPS = \
$(DLOPEN_LIBS) \
-lm
 
+if HAVE_PLATFORM_DISPLAY
+AM_CPPFLAGS += \
+   -DVK_USE_PLATFORM_DISPLAY_KHR
+
+VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
+
+endif
+
 if HAVE_PLATFORM_X11
 AM_CPPFLAGS += \
$(XCB_DRI3_CFLAGS) \
diff --git a/src/amd/vulkan/Makefile.sources b/src/amd/vulkan/Makefile.sources
index a510d88d965..618a6cdaed0 100644
--- a/src/amd/vulkan/Makefile.sources
+++ b/src/amd/vulkan/Makefile.sources
@@ -78,6 +78,9 @@ VULKAN_WSI_WAYLAND_FILES := \
 VULKAN_WSI_X11_FILES := \
radv_wsi_x11.c
 
+VULKAN_WSI_DISPLAY_FILES := \
+   radv_wsi_display.c
+
 VULKAN_GENERATED_FILES := \
radv_entrypoints.c \
radv_entrypoints.h \
diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
index 0a7b7c0bf3c..b7bb1075e7d 100644
--- a/src/amd/vulkan/meson.build
+++ b/src/amd/vulkan/meson.build
@@ -112,6 +112,13 @@ if with_platform_wayland
   libradv_files += files('radv_wsi_wayland.c')
 endif
 
+if with_platform_display
+  radv_flags += [
+'-DVK_USE_PLATFORM_DISPLAY_KHR',
+  ]
+  libradv_files += files('radv_wsi_display.c')
+endif
+
 libvulkan_radeon = shared_library(
   'vulkan_radeon',
   [libradv_files, radv_entrypoints, radv_extensions_c, vk_format_table_c],
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 09bb382eeb8..adf33eb35dc 100644
--- 

[PATCH 3/7] vulkan: Add EXT_acquire_xlib_display

[Keith Packard]

This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application. For DRM, we use the
Linux resource leasing mechanism.

Signed-off-by: Keith Packard 
---
 configure.ac   |  25 ++
 meson.build|  17 ++
 meson_options.txt  |   7 +
 src/amd/vulkan/Makefile.am |   7 +
 src/amd/vulkan/meson.build |   7 +
 src/amd/vulkan/radv_extensions.py  |  11 +-
 src/amd/vulkan/radv_wsi_display.c  |  30 +++
 src/intel/Makefile.vulkan.am   |   7 +
 src/intel/vulkan/anv_extensions.py |   1 +
 src/intel/vulkan/anv_extensions_gen.py |  10 +-
 src/intel/vulkan/anv_wsi_display.c |  30 +++
 src/intel/vulkan/meson.build   |   7 +
 src/vulkan/Makefile.am |   5 +
 src/vulkan/wsi/meson.build |   7 +
 src/vulkan/wsi/wsi_common_display.c| 472 +
 src/vulkan/wsi/wsi_common_display.h|  17 ++
 16 files changed, 650 insertions(+), 10 deletions(-)

diff --git a/configure.ac b/configure.ac
index 46318365603..9effd15e8c5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1547,6 +1547,7 @@ AM_CONDITIONAL(HAVE_APPLEDRI, test "x$enable_dri" = xyes 
-a "x$dri_platform" = x
 AM_CONDITIONAL(HAVE_LMSENSORS, test "x$enable_lmsensors" = xyes )
 AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
xyes )
 AM_CONDITIONAL(HAVE_WINDOWSDRI, test "x$enable_dri" = xyes -a "x$dri_platform" 
= xwindows )
+AM_CONDITIONAL(HAVE_XLEASE, test "x$have_xlease" = xyes )
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
@@ -1846,6 +1847,11 @@ if test x"$enable_dri3" = xyes; then
 PKG_CHECK_MODULES([XCB_DRI3], [$dri3_modules])
 fi
 
+if test x"$have_xlease" = xyes; then
+randr_modules="x11-xcb xcb-randr"
+PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
+fi
+
 AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
 AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
 AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
@@ -1853,6 +1859,25 @@ AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$platforms" 
| grep -q 'drm')
 AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
'surfaceless')
 AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
 
+AC_ARG_ENABLE(xlib-lease,
+[AS_HELP_STRING([--enable-xlib-lease]
+[enable VK_acquire_xlib_display using X leases])],
+[enable_xlib_lease=$enableval], [enable_xlib_lease=auto])
+case "x$enable_xlib_lease" in
+xyes)
+;;
+xno)
+;;
+*)
+if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm';
+enable_xlib_lease=yes
+else
+enable_xlib_lease=no
+fi
+esac
+
+AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)
+
 dnl
 dnl More DRI setup
 dnl
diff --git a/meson.build b/meson.build
index aeb7f5e2917..595b0f66cd7 100644
--- a/meson.build
+++ b/meson.build
@@ -262,6 +262,19 @@ if _platforms != ''
   egl_native_platform = _split[0]
 endif
 
+with_xlib_lease = get_option('xlib-lease')
+if with_xlib_lease == 'auto'
+  if with_platform_x11 and with_platform_display
+with_xlib_lease = true
+  else
+with_xlib_lease = false
+  endif
+elif with_xlib_lease == 'true'
+  with_xlib_lease = true
+else
+  with_xlib_lease = false
+endif
+
 with_glx = get_option('glx')
 if with_glx == 'auto'
   if with_dri
@@ -1151,6 +1164,7 @@ dep_xcb_present = []
 dep_xcb_sync = []
 dep_xcb_xfixes = []
 dep_xshmfence = []
+dep_xcb_xrandr = []
 if with_platform_x11
   if with_glx == 'xlib' or with_glx == 'gallium-xlib'
 dep_x11 = dependency('x11')
@@ -1190,6 +1204,9 @@ if with_platform_x11
   if with_egl
 dep_xcb_xfixes = dependency('xcb-xfixes')
   endif
+  if with_xlib_lease
+dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')
+  endif
 endif
 
 if get_option('gallium-extra-hud')
diff --git a/meson_options.txt b/meson_options.txt
index 7fafe2deaac..d38c9aa6149 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -286,3 +286,10 @@ option(
   value : '',
   description : 'Comma delimited list of tools to build. choices : 
freedreno,glsl,intel,nir,nouveau or all'
 )
+option(
+  'xlib-lease',
+  type : 'combo',
+  value : 'auto',
+  choices : ['auto', 'true', 'false'],
+  description : 'Enable VK_EXT_acquire_xlib_display.'
+)
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 061b8144b88..94ece06e99e 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -81,7 +81,14 @@ AM_CPPFLAGS += \
-DVK_USE_PLATFORM_DISPLAY_KHR
 
 VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
+endif
+
+if HAVE_XLIB_LEASE
+AM_CPPFLAGS += \
+   -DVK_USE_PLATFORM_XLIB_XRANDR_EXT \
+   $(XCB_RANDR_CFLAGS)
 
+VULKAN_LIB_DEPS += $(XCB_RANDR_LIBS)
 endif
 
 if HAVE_PLATFORM_X11
diff --git a/src/amd/vulkan/meson.build 

[PATCH 0/7] vulkan: Add direct display extensions

[Keith Packard]

Here's a series of extensions necessary to perform reasonable direct
display operations, either directly through DRM with no window system,
or using RandR and Linux leases.

There's one new extension, MESA_query_timestamp which performs the
same operation as glGetInteger64v(GL_TIMESTAMP, ) -- it gets
the current GPU tick using an immediate register read so that the
application can correlate GPU and CPU times. I'd love to be able to
have a single call that got both CPU and GPU times so we could put
that in the kernel, but there's no standard timestamp for the various
winsys layers (although most (all?) appear to use MONOTONIC currently,
at least on Linux).

I've refactored this series so that each patch adds a single
extension, and the code for each extension is generally grouped
together. I did not split the code in the new wsi_common_display.c
apart; it's all related to implementing various modes related to
KHR_display, so I didn't see a good place to break it apart that
wouldn't end up with a bunch of extra complexity.

-keith

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

[PATCH 5/7] vulkan: add VK_EXT_display_control [v4]

[Keith Packard]

This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.

v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
been removed from the proposed kernel API.

Add NULL parameter to drmCrtcQueueSequence ioctl as we
don't care what sequence the event was actually queued to.

v3: Adapt to pthread clock switch to MONOTONIC

v4: Add support for anv

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py   |   1 +
 src/amd/vulkan/radv_private.h   |  11 +-
 src/amd/vulkan/radv_wsi_display.c   | 109 ++
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_private.h  |   4 +
 src/intel/vulkan/anv_queue.c|  59 +++-
 src/intel/vulkan/anv_wsi_display.c  | 103 +
 src/vulkan/wsi/wsi_common.h |   9 ++
 src/vulkan/wsi/wsi_common_display.c | 286 +++-
 src/vulkan/wsi/wsi_common_display.h |  29 
 10 files changed, 603 insertions(+), 9 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 3f315e074b5..775d1ed4be6 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -85,6 +85,7 @@ EXTENSIONS = [
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, '!ANDROID'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_discard_rectangles',1, True),
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 1e3719bcc4f..2aee38f0159 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1647,8 +1647,17 @@ void radv_initialise_cmask(struct radv_cmd_buffer 
*cmd_buffer,
 void radv_initialize_dcc(struct radv_cmd_buffer *cmd_buffer,
 struct radv_image *image, uint32_t value);
 
+enum radv_fence_type {
+RADV_FENCE_TYPE_WINSYS = 0,
+RADV_FENCE_TYPE_WSI = 1
+};
+
 struct radv_fence {
-   struct radeon_winsys_fence *fence;
+enum radv_fence_type type;
+union {
+struct radeon_winsys_fence  *fence;
+struct wsi_fence*fence_wsi;
+};
bool submitted;
bool signalled;
 
diff --git a/src/amd/vulkan/radv_wsi_display.c 
b/src/amd/vulkan/radv_wsi_display.c
index 9b76ce623b0..5dd66b34a1a 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -182,3 +182,112 @@ radv_GetRandROutputDisplayEXT(VkPhysicalDevice  
physical_device,
display);
 }
 #endif /* VK_USE_PLATFORM_XLIB_XRANDR_EXT */
+
+/* VK_EXT_display_control */
+
+VkResult
+radv_DisplayPowerControlEXT(VkDevice_device,
+VkDisplayKHRdisplay,
+const VkDisplayPowerInfoEXT *display_power_info)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+
+   return wsi_display_power_control(_device,
+>physical_device->wsi_device,
+display,
+display_power_info);
+}
+
+VkResult
+radv_RegisterDeviceEventEXT(VkDevice_device,
+const VkDeviceEventInfoEXT  *device_event_info,
+const VkAllocationCallbacks *allocator,
+VkFence *_fence)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   const VkAllocationCallbacks  *alloc;
+   struct radv_fence*fence;
+   VkResult ret;
+
+   if (allocator)
+ alloc = allocator;
+   else
+ alloc = >instance->alloc;
+
+   fence = vk_alloc(alloc, sizeof (*fence), 8,
+VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
+   if (!fence)
+  return VK_ERROR_OUT_OF_HOST_MEMORY;
+
+   fence->type = RADV_FENCE_TYPE_WSI;
+   fence->submitted = true;
+   fence->signalled = false;
+
+   ret = wsi_register_device_event(_device,
+   >physical_device->wsi_device,
+   device_event_info,
+   alloc,
+   >fence_wsi);
+   if (ret == VK_SUCCESS)
+  *_fence = radv_fence_to_handle(fence);
+   else
+  vk_free(alloc, fence);
+   return ret;
+}
+
+VkResult
+radv_RegisterDisplayEventEXT(VkDevice   _device,
+ 

[Bug 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

--- Comment #8 from Will  ---
After triple checking, nomodeset or radeon.dpm=0 prevents boot loops on my
hardware.

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

[PATCH RFC v3 4/6] drm: drm_fourcc: Add new formats for Xilinx IPs

[Hyun Kwon]

This patch adds new formats needed by Xilinx IP. Pixels are not
byte-aligned in these formats, and the drm_format_info for these
formats has macro-pixel information.

Signed-off-by: Jeffrey Mouroux 
Signed-off-by: Hyun Kwon 
---
v3
- Update entries for changes
- Squash fourcc patch into this
v2
- Add detailed descriptions
- Remove formats with no user
---
---
 drivers/gpu/drm/drm_fourcc.c  | 2 ++
 include/uapi/drm/drm_fourcc.h | 8 
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ed95de2..36bff7a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -168,6 +168,8 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_NV61,.depth = 0,  
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_NV24,.depth = 0,  
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_NV42,.depth = 0,  
.num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XV15,.depth = 0,  
.num_planes = 2, .pixels_per_macropixel = { 3, 3, 0 }, .bytes_per_macropixel = 
{ 4, 8, 0 }, .hsub = 2, .vsub = 2, },
+   { .format = DRM_FORMAT_XV20,.depth = 0,  
.num_planes = 2, .pixels_per_macropixel = { 3, 3, 0 }, .bytes_per_macropixel = 
{ 4, 8, 0 }, .hsub = 2, .vsub = 1, },
{ .format = DRM_FORMAT_YUYV,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_YVYU,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d..6ac5282 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -142,6 +142,14 @@ extern "C" {
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
 
 /*
+ * 2 plane 10 bit per component YCbCr
+ * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
+ * index 1 = Cb:Cr plane, [63:0] x:Cb2:Cr2:Cb1:x:Cr1:Cb0:Cr0 
2:10:10:10:2:10:10:10 little endian
+ */
+#define DRM_FORMAT_XV15fourcc_code('X', 'V', '1', '5') /* 2x2 
subsampled Cb:Cr plane 2:10:10:10 */
+#define DRM_FORMAT_XV20fourcc_code('X', 'V', '2', '0') /* 2x1 
subsampled Cb:Cr plane 2:10:10:10 */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
-- 
2.7.4

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

[PATCH RFC v3 0/6] Support of non-byte aligned formats in drm

[Hyun Kwon]

Hi,

Following up on v1 [1] and v2 [2], this series is to address non-byte aligned
formats in drm. Based on the comments, the set is getting simplified, and
any further comment would be appreciated. Brief description:

Patch 1 just changes comment style for change in patch 2
Patch 2 adds macro-pixel information to drm_format_info
Patch 3 adds a drm function that uses the macro-pixel information
Patch 4 adds new formats along with macro-pixel info
Patch 5 shows the example of driver integration
Patch 6 includes additional format strings

Thanks,
-hyun

[1] https://lists.freedesktop.org/archives/dri-devel/2017-November/158744.html
[2] https://www.spinics.net/lists/dri-devel/msg163388.html

Hyun Kwon (6):
  drm: fourcc.h: Use inline kern-doc style for struct drm_format_info
  drm: drm_fourcc: Introduce macro-pixel info to drm_format_info
  drm: fourcc: Add drm_format_plane_width_bytes()
  drm: drm_fourcc: Add new formats for Xilinx IPs
  drm: xlnx: zynqmp: Add XV15 and XV20 formats
  drm: fourcc: Add new formats needed by Xilinx IP

 drivers/gpu/drm/drm_fb_cma_helper.c |  3 +-
 drivers/gpu/drm/drm_fourcc.c| 42 ++
 drivers/gpu/drm/xlnx/zynqmp_disp.c  | 22 +++-
 include/drm/drm_fourcc.h| 69 -
 include/uapi/drm/drm_fourcc.h   | 15 
 5 files changed, 141 insertions(+), 10 deletions(-)

-- 
2.7.4

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

[PATCH RFC v3 3/6] drm: fourcc: Add drm_format_plane_width_bytes()

[Hyun Kwon]

drm_format_plane_width_bytes() calculates and returns the number of bytes
for given width of specified format. The calculation uses @cpp
in drm format info for byte-aligned formats. If the format isn't
byte-aligned, @cpp should 0, and the macro pixel information is used.
This avoids bit level rounding.

Use this drm_fb_cma_get_gem_addr() for offset calculation.

Signed-off-by: Hyun Kwon 
---
v3
- Update according to member changes
- Use @cpp for byte-aligned formats, and macro-pixel for non byte-aligned ones
- Squash a change in drm_fb_cma_helper.c into this
v2
- This function is added
---
---
 drivers/gpu/drm/drm_fb_cma_helper.c |  3 ++-
 drivers/gpu/drm/drm_fourcc.c| 35 +++
 include/drm/drm_fourcc.h|  2 ++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00a..271175e 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -124,7 +124,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer 
*fb,
return 0;
 
paddr = obj->paddr + fb->offsets[plane];
-   paddr += fb->format->cpp[plane] * (state->src_x >> 16);
+   paddr += drm_format_plane_width_bytes(fb->format, plane,
+ state->src_x >> 16);
paddr += fb->pitches[plane] * (state->src_y >> 16);
 
return paddr;
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152d..ed95de2 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -348,3 +348,38 @@ int drm_format_plane_height(int height, uint32_t format, 
int plane)
return height / info->vsub;
 }
 EXPORT_SYMBOL(drm_format_plane_height);
+
+/**
+ * drm_format_plane_width_bytes - bytes of the given width of the plane
+ * @info: DRM format information
+ * @plane: plane index
+ * @width: width to get the number of bytes
+ *
+ * This returns the number of bytes for given @width and @plane.
+ * The @cpp or macro pixel information should be valid.
+ *
+ * Returns:
+ * The bytes of @width of @plane. 0 for invalid format info.
+ */
+int drm_format_plane_width_bytes(const struct drm_format_info *info,
+int plane, int width)
+{
+   if (!info || plane >= info->num_planes)
+   return 0;
+
+   if (info->cpp[plane])
+   return info->cpp[plane] * width;
+
+   if (WARN_ON(!info->bytes_per_macropixel[plane] ||
+   !info->pixels_per_macropixel[plane])) {
+   struct drm_format_name_buf buf;
+
+   DRM_WARN("Either cpp or macro-pixel info should be valid: %s\n",
+drm_get_format_name(info->format, ));
+   return 0;
+   }
+
+   return DIV_ROUND_UP(width * info->bytes_per_macropixel[plane],
+   info->pixels_per_macropixel[plane]);
+}
+EXPORT_SYMBOL(drm_format_plane_width_bytes);
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index ce59329..8158290 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -119,6 +119,8 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
+int drm_format_plane_width_bytes(const struct drm_format_info *info,
+int plane, int width);
 const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
*buf);
 
 #endif /* __DRM_FOURCC_H__ */
-- 
2.7.4

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

[PATCH RFC v3 2/6] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

[Hyun Kwon]

Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
This is to model formats where multiple non-byte aligned pixels are stored
together in a byte-aligned way. For example, if 3 - 10 bit
pixels are stored in 32 bit, the 32 bit stroage can be treated as
a single macro-pixel with 3 pixels. This aligns non-byte addressable
formats with drm core where each pixel / component is expected to be
byte aligned.

Add 'pixels_per_macro' to note how many pixels are in a macro-pixel.
'bytes_per_macro' specifies the size of a macro-pixel in bytes.

Signed-off-by: Hyun Kwon 
---
v3
- Rename members and rephrase descriptions
- Rephrase the commit message
- Use in-line style comments
v2
- Introduce macro-pixel over scaling factors
---
---
 include/drm/drm_fourcc.h | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index b00bae4..ce59329 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -58,11 +58,33 @@ struct drm_format_info {
/**
 * @cpp:
 *
-* Number of bytes per pixel (per plane)
+* Number of bytes per pixel (per plane). @cpp shouldn't be used when
+* @pixels_per_macropixel and @bytes_per_macropixel are used.
 */
u8 cpp[3];
 
/**
+* @pixels_per_macropixel:
+*
+* Number of pixels per macro-pixel (per plane). A macro-pixel is
+* composed of multiple pixels, and there can be extra bits between
+* pixels. This must be used along with @bytes_per_macropixel, only
+* when single pixel size is not byte-aligned. In this case, @cpp
+* is not valid and should be 0.
+*/
+   u8 pixels_per_macropixel[3];
+
+   /*
+* @bytes_per_macropixel:
+*
+* Number of bytes per macro-pixel (per plane). A macro-pixel is
+* composed of multiple pixels. The size of single macro-pixel should
+* be byte-aligned. This should be used with @pixels_per_macropixel,
+* and @cpp should be 0.
+*/
+   u8 bytes_per_macropixel[3];
+
+   /**
 * @hsub:
 *
 * Horizontal chroma subsampling factor
-- 
2.7.4

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

[PATCH RFC v3 6/6] drm: fourcc: Add new formats needed by Xilinx IP

[Hyun Kwon]

This adds packed YUV and grey scale format fourccs.

Signed-off-by: Hyun Kwon 

---
v3
- Update entries for changes
- Squash fourcc patch into this
- Note these don't have any reference in mainline
v2
- Split from the previous patch
---
---
 drivers/gpu/drm/drm_fourcc.c  | 5 +
 include/uapi/drm/drm_fourcc.h | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 36bff7a..cf35251 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -175,6 +175,11 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_VUY888,  .depth = 0,  
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XVUY,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XVUY2101010, .depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_Y8,  .depth = 0,  
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_Y10, .depth = 0,  
.num_planes = 1, .pixels_per_macropixel =  { 3, 0, 0 }, .bytes_per_macropixel = 
{ 4, 0, 0 }, .hsub = 1, .vsub = 1 },
};
 
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6ac5282..7014a3d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -112,6 +112,13 @@ extern "C" {
 #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /* 
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
 
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_VUY888  fourcc_code('V', 'U', '2', '4') /* [23:0] 
Cr:Cb:Y 8:8:8 little endian */
+#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /* [31:0] 
x:Cr:Cb:Y 8:8:8:8 little endian */
+#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'Y', '3', '0') /* [31:0] 
x:Cr:Cb:Y 2:10:10:10 little endian */
+
+/* Grey scale */
+#define DRM_FORMAT_Y8  fourcc_code('G', 'R', 'E', 'Y') /* 8  Greyscale 
*/
+#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /* 10 Greyscale 
*/
 
 /*
  * 2 plane RGB + A
-- 
2.7.4

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

[PATCH RFC v3 1/6] drm: fourcc.h: Use inline kern-doc style for struct drm_format_info

[Hyun Kwon]

Use the inline kern-doc style for struct drm_format_info for better
readability. This is just a preliminary change for further table update.

Signed-off-by: Hyun Kwon 
---
v3
- This is added
---
---
 include/drm/drm_fourcc.h | 45 +
 1 file changed, 37 insertions(+), 8 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 6942e84..b00bae4 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -30,21 +30,50 @@ struct drm_mode_fb_cmd2;
 
 /**
  * struct drm_format_info - information about a DRM format
- * @format: 4CC format identifier (DRM_FORMAT_*)
- * @depth: Color depth (number of bits per pixel excluding padding bits),
- * valid for a subset of RGB formats only. This is a legacy field, do not
- * use in new code and set to 0 for new formats.
- * @num_planes: Number of color planes (1 to 3)
- * @cpp: Number of bytes per pixel (per plane)
- * @hsub: Horizontal chroma subsampling factor
- * @vsub: Vertical chroma subsampling factor
  */
 struct drm_format_info {
+   /**
+* @format:
+*
+* 4CC format identifier (DRM_FORMAT_*)
+*/
u32 format;
+
+   /**
+* @depth:
+*
+* Color depth (number of bits per pixel excluding padding bits),
+* valid for a subset of RGB formats only. This is a legacy field,
+* do not use in new code and set to 0 for new formats.
+*/
u8 depth;
+
+   /**
+* @num_planes:
+*
+* Number of color planes (1 to 3)
+*/
u8 num_planes;
+
+   /**
+* @cpp:
+*
+* Number of bytes per pixel (per plane)
+*/
u8 cpp[3];
+
+   /**
+* @hsub:
+*
+* Horizontal chroma subsampling factor
+*/
u8 hsub;
+
+   /**
+* @vsub:
+*
+* Vertical chroma subsampling factor
+*/
u8 vsub;
 };
 
-- 
2.7.4

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

[PATCH RFC v3 5/6] drm: xlnx: zynqmp: Add XV15 and XV20 formats

[Hyun Kwon]

Use drm_format_width_bytes() to support non-byte aligned formats.

Signed-off-by: Hyun Kwon 
---
v3
- 2 patches are squashed
---
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index e47d77d..13053fc 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -968,6 +968,24 @@ static const struct zynqmp_disp_fmt av_buf_vid_fmts[] = {
.sf[0]  = ZYNQMP_DISP_AV_BUF_8BIT_SF,
.sf[1]  = ZYNQMP_DISP_AV_BUF_8BIT_SF,
.sf[2]  = ZYNQMP_DISP_AV_BUF_8BIT_SF,
+   }, {
+   .drm_fmt= DRM_FORMAT_XV15,
+   .disp_fmt   = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_420_10,
+   .rgb= false,
+   .swap   = false,
+   .chroma_sub = true,
+   .sf[0]  = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+   .sf[1]  = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+   .sf[2]  = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+   }, {
+   .drm_fmt= DRM_FORMAT_XV20,
+   .disp_fmt   = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_10,
+   .rgb= false,
+   .swap   = false,
+   .chroma_sub = true,
+   .sf[0]  = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+   .sf[1]  = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+   .sf[2]  = ZYNQMP_DISP_AV_BUF_10BIT_SF,
}
 };
 
@@ -2133,6 +2151,7 @@ static int zynqmp_disp_plane_mode_set(struct drm_plane 
*plane,
for (i = 0; i < info->num_planes; i++) {
unsigned int width = src_w / (i ? info->hsub : 1);
unsigned int height = src_h / (i ? info->vsub : 1);
+   int width_bytes;
 
paddr = drm_fb_cma_get_gem_addr(fb, plane->state, i);
if (!paddr) {
@@ -2141,7 +2160,8 @@ static int zynqmp_disp_plane_mode_set(struct drm_plane 
*plane,
}
 
layer->dma[i].xt.numf = height;
-   layer->dma[i].sgl[0].size = width * info->cpp[i];
+   width_bytes = drm_format_plane_width_bytes(info, i, width);
+   layer->dma[i].sgl[0].size = width_bytes;
layer->dma[i].sgl[0].icg = fb->pitches[i] -
   layer->dma[i].sgl[0].size;
layer->dma[i].xt.src_start = paddr;
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Pandiyan, Dhinakaran]

On Thu, 2018-02-08 at 23:39 -0800, Rodrigo Vivi wrote:
> Rodrigo Vivi  writes:
> 
> > "Pandiyan, Dhinakaran"  writes:
> >
> >> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> >>> Hi Andy,
> >>>
> >>> thanks for getting involved with PSR and sorry for not replying sooner.
> >>>
> >>> I first saw this patch on that bugzilla entry but only now I stop to
> >>> really think why I have written the code that way.
> >>>
> >>> So some clarity below.
> >>>
> >>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> >>> > The current PSR code has a two call sites that each schedule delayed
> >>> > work to activate PSR.  As far as I can tell, each call site intends
> >>> > to keep PSR inactive for the given amount of time and then allow it
> >>> > to be activated.
> >>> >
> >>> > The call sites are:
> >>> >
> >>> >  - intel_psr_enable(), which explicitly states in a comment that
> >>> >it's trying to keep PSR off a short time after the dispay is
> >>> >initialized as a workaround.
> >>>
> >>> First of all I really want to kill this call here and remove the
> >>> FIXME. It was an ugly hack that I added to solve a corner case
> >>> that was leaving me with blank screens when activating so sooner.
> >>>
> >>> >
> >>> >  - intel_psr_flush().  There isn't an explcit explanation, but the
> >>> >intent is presumably to keep PSR off until the display has been
> >>> >idle for 100ms.
> >>>
> >>> The reason for 100 is kind of ugly-nonsense-empirical value
> >>> I concluded from VLV/CHV experience.
> >>> On platforms with HW tracking HW waits few identical frames
> >>> until really activating PSR. VLV/CHV activation is immediate.
> >>> But HW is also different and there it seemed that hw needed a
> >>> few more time before starting the transitions.
> >>> Furthermore I didn't want to add that so quickly because I didn't
> >>> want to take the risk of killing battery with software tracking
> >>> when doing transitions so quickly using software tracking.
> >>>
> >>> >
> >>> > The current code doesn't actually accomplish either of these goals.
> >>> > Rather than keeping PSR inactive for the given amount of time, it
> >>> > will schedule PSR for activation after the given time, with the
> >>> > earliest target time in such a request winning.
> >>>
> >>> Putting that way I was asking myself how that hack had ever fixed
> >>> my issue. Because the way you explained here seems obvious that it
> >>> wouldn't ever fix my bug or any other.
> >>>
> >>> So I applied your patch and it made even more sense (without considering
> >>> the fact I want to kill the first call anyways).
> >>>
> >>> So I came back, removed your patch and tried to understand how did
> >>> it ever worked.
> >>>
> >>> So, the thing is that intel_psr_flush will never be really executed
> >>> if intel_psr_enable wasn't executed. That is guaranteed by:
> >>>
> >>> mutex_lock(_priv->psr.lock);
> >>>   if (!dev_priv->psr.enabled) {
> >>>
> >>> So, intel_psr_enable will be for sure the first one to schedule the
> >>> work delayed to the ugly higher delay.
> >>>
> >>> >
> >>> > In other words, if intel_psr_enable() is immediately followed by
> >>> > intel_psr_flush(), then PSR will be activated after 100ms even if
> >>> > intel_psr_enable() wanted a longer delay.  And, if the screen is
> >>> > being constantly updated so that intel_psr_flush() is called once
> >>> > per frame at 60Hz, PSR will still be activated once every 100ms.
> >>>
> >>> During this time you are right, many calls of intel_psr_exit
> >>> coming from flush functions can be called... But none of
> >>> them will schedule the work with 100 delay.
> >>>
> >>> they will skip on
> >>> if (!work_busy(_priv->psr.work.work))
> >>
> >> Wouldn't work_busy() return false until the work is actually queued
> >> which is 100ms after calling schedule_delayed_work()?
> >
> > That's not my understanding of work_busy man.
> >
> > "work_busy - test whether a work is currently pending or running"

Sorry about this, WORK_STRUCT_PENDING_BIT is indeed set as soon as
schedule_delayed_work() is called.

> >
> > I consider it as pending one...
> >
> > But yeap... it was a long time ago that I did this so I'm not sure...
> 
> I wouldn't be able to sleep today if I hand't experiment this.
> 
> So, I move the hacked scheduled to 10s and forced psr_activate 10ms
> after that and the result is this:
> 
> 
> [   11.757909] [drm:intel_psr_enable [i915]] *ERROR* I915-DEBUG:
> Scheduling 10s
> [   11.778586] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> ...
> a bunch more of Work busy
> ...
> [   21.980643] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> [   21.983060] [drm:intel_psr_work [i915]] *ERROR* I915-DEBUG: Work running
> [   21.986353] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Scheduling 
> normal 100ms
> So, the schedules are working as expected, I'm not crazy and I will be
> able to sleep :)
> 
> (I 

[PATCH] amdgpu/dc: Remove unnecessary initialization in dc_link_handle_hpd_rx_irq()

[Matthias Kaehlcke]

The initialization of 'result' is unnecessary, the variable is assigned
unconditionally a few lines below. Removing the initialization also fixes
the following warning when building with clang:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1931:26:
  error: implicit conversion from enumeration type 'enum ddc_result'
  to different enumeration type 'enum dc_status' [-Werror,-Wenum-conversion]
enum dc_status result = DDC_RESULT_UNKNOWN;

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 4ee4c03a6724..8e3a8c1395a3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -1926,7 +1926,7 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link, 
union hpd_irq_data *out_hpd
 {
union hpd_irq_data hpd_irq_dpcd_data = 0;
union device_service_irq device_service_clear = { { 0 } };
-   enum dc_status result = DDC_RESULT_UNKNOWN;
+   enum dc_status result;
bool status = false;
/* For use cases related to down stream connection status change,
 * PSR and device auto test, refer to function handle_sst_hpd_irq
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

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

--- Comment #33 from Mike Bendel  ---
I'm also experiencing the same issues, but on much lower refresh rates. I have
a 3840x1600 monitor (LG 38UC99) and when running at 75Hz, display corruption is
observed on both AMD GPUs I have, a Radeon Pro WX 5100 and Radeon RX 550.

Fortunately, setting the power level to high makes the display corruption go
away entirely, but also raises temperatures substantially. The idle temp on my
WX 5100 gets up to 60 C by doing that.

Is there a way to lower the clocks in the high performance state? I know some 
utilities like MSI Afterburner allow for this in Windows, but I'm not sure how
to do it on Linux.

-- 
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] amdgpu/dc: Add missing cast in dce_clock_set_min_clocks_state()

[Matthias Kaehlcke]

El Fri, Feb 09, 2018 at 04:55:57PM -0500 Harry Wentland ha dit:

> On 2018-02-09 04:28 PM, Matthias Kaehlcke wrote:
> > dce_clock_set_min_clocks_state() assigns (intentionally) a value of type
> > 'enum dm_pp_clocks_state' to a variable of type 'enum dm_pp_power_level'
> > without an explicit cast. This causes clang to raise the following
> > warning:
> > 
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clocks.c:308:4: error:
> >   implicit conversion from enumeration type 'enum dm_pp_clocks_state'
> >   to different enumeration type 'enum dm_pp_power_level' 
> > [-Werror,-Wenum-conversion]
> > clocks_state };
> > 
> > Make the cast explicit.
> > 
> > Signed-off-by: Matthias Kaehlcke 
> > ---
> >  drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c 
> > b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> > index 9e98a5f39a6d..db3ceb283255 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> > @@ -304,7 +304,8 @@ static bool dce_clock_set_min_clocks_state(
> > enum dm_pp_clocks_state clocks_state)
> >  {
> > struct dm_pp_power_level_change_request level_change_req = {
> > -   clocks_state };
> > +   .power_level = (enum dm_pp_power_level)clocks_state
> 
> Thanks for spotting this. Looks like both enums are exactly the same so no 
> need to keep both. I sent a patch to remove the dm_pp_power_level enum to 
> amd-gfx and CC'd you on it.

Even better, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

--- Comment #7 from NickForum  ---
Hi

Some problem after 4.15 update.
Radeon HD 5770 Evergreen


kernel 4.15.2-2-ARCH

disable dpm is a workaround

-- 
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] amdgpu/dc: Add missing cast in dce_clock_set_min_clocks_state()

[Harry Wentland]

On 2018-02-09 04:28 PM, Matthias Kaehlcke wrote:
> dce_clock_set_min_clocks_state() assigns (intentionally) a value of type
> 'enum dm_pp_clocks_state' to a variable of type 'enum dm_pp_power_level'
> without an explicit cast. This causes clang to raise the following
> warning:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clocks.c:308:4: error:
>   implicit conversion from enumeration type 'enum dm_pp_clocks_state'
>   to different enumeration type 'enum dm_pp_power_level' 
> [-Werror,-Wenum-conversion]
> clocks_state };
> 
> Make the cast explicit.
> 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> index 9e98a5f39a6d..db3ceb283255 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> @@ -304,7 +304,8 @@ static bool dce_clock_set_min_clocks_state(
>   enum dm_pp_clocks_state clocks_state)
>  {
>   struct dm_pp_power_level_change_request level_change_req = {
> - clocks_state };
> + .power_level = (enum dm_pp_power_level)clocks_state

Thanks for spotting this. Looks like both enums are exactly the same so no need 
to keep both. I sent a patch to remove the dm_pp_power_level enum to amd-gfx 
and CC'd you on it.

Harry

> + };
>  
>   if (clocks_state > clk->max_clks_state) {
>   /*Requested state exceeds max supported state.*/
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] amdgpu/dc: Add missing cast in dce_clock_set_min_clocks_state()

[Matthias Kaehlcke]

dce_clock_set_min_clocks_state() assigns (intentionally) a value of type
'enum dm_pp_clocks_state' to a variable of type 'enum dm_pp_power_level'
without an explicit cast. This causes clang to raise the following
warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clocks.c:308:4: error:
  implicit conversion from enumeration type 'enum dm_pp_clocks_state'
  to different enumeration type 'enum dm_pp_power_level' 
[-Werror,-Wenum-conversion]
clocks_state };

Make the cast explicit.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
index 9e98a5f39a6d..db3ceb283255 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
@@ -304,7 +304,8 @@ static bool dce_clock_set_min_clocks_state(
enum dm_pp_clocks_state clocks_state)
 {
struct dm_pp_power_level_change_request level_change_req = {
-   clocks_state };
+   .power_level = (enum dm_pp_power_level)clocks_state
+   };
 
if (clocks_state > clk->max_clks_state) {
/*Requested state exceeds max supported state.*/
-- 
2.16.0.rc1.238.g530d649a79-goog

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

Re: [PATCH v3 1/4] ASoC: dapm: fix debugfs read using path->connected

[Matthias Kaehlcke]

Sorry, I unintentionally 'recycled' git send-email parameters, please
ignore this patch :(

El Fri, Feb 09, 2018 at 01:22:13PM -0800 Matthias Kaehlcke ha dit:

> From: KaiChieh Chuang 
> 
> This fix a bug in dapm_widget_power_read_file(),
> where it may sent opposite order of source/sink widget
> into the p->connected().
> 
> for example,
> static int connected_check(source, sink);
> {"w_sink", NULL, "w_source", connected_check}
> 
> the dapm_widget_power_read_file() will query p->connected()
> in following case
>   p->conneted("w_source", "w_sink")
>   p->conneted("w_sink", "w_source")
> we should avoid the last case, since it's the wrong order (source/sink)
> as declared in snd_soc_dapm_route.
> 
> Signed-off-by: KaiChieh Chuang 
> Signed-off-by: Mark Brown 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  sound/soc/soc-dapm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
> index a10b21cfc31e..ee6d9d9a3c5e 100644
> --- a/sound/soc/soc-dapm.c
> +++ b/sound/soc/soc-dapm.c
> @@ -2026,7 +2026,7 @@ static ssize_t dapm_widget_power_read_file(struct file 
> *file,
>   snd_soc_dapm_for_each_direction(dir) {
>   rdir = SND_SOC_DAPM_DIR_REVERSE(dir);
>   snd_soc_dapm_widget_for_each_path(w, dir, p) {
> - if (p->connected && !p->connected(w, p->node[rdir]))
> + if (p->connected && !p->connected(p->source, p->sink))
>   continue;
>  
>   if (!p->connect)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/4] ASoC: dapm: fix debugfs read using path->connected

[Matthias Kaehlcke]

From: KaiChieh Chuang 

This fix a bug in dapm_widget_power_read_file(),
where it may sent opposite order of source/sink widget
into the p->connected().

for example,
static int connected_check(source, sink);
{"w_sink", NULL, "w_source", connected_check}

the dapm_widget_power_read_file() will query p->connected()
in following case
p->conneted("w_source", "w_sink")
p->conneted("w_sink", "w_source")
we should avoid the last case, since it's the wrong order (source/sink)
as declared in snd_soc_dapm_route.

Signed-off-by: KaiChieh Chuang 
Signed-off-by: Mark Brown 
Signed-off-by: Matthias Kaehlcke 
---
 sound/soc/soc-dapm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index a10b21cfc31e..ee6d9d9a3c5e 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -2026,7 +2026,7 @@ static ssize_t dapm_widget_power_read_file(struct file 
*file,
snd_soc_dapm_for_each_direction(dir) {
rdir = SND_SOC_DAPM_DIR_REVERSE(dir);
snd_soc_dapm_widget_for_each_path(w, dir, p) {
-   if (p->connected && !p->connected(w, p->node[rdir]))
+   if (p->connected && !p->connected(p->source, p->sink))
continue;
 
if (!p->connect)
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[Bug 105026] glxgears asserts with pp_jimenezmlaa=1

[bugzilla-daemon]

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

Bug ID: 105026
   Summary: glxgears asserts with pp_jimenezmlaa=1
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: e...@xmw.de
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137249
  --> https://bugs.freedesktop.org/attachment.cgi?id=137249=edit
glxgears/mesa backtrace with -Og

Any program asserts when pp_jimenezmlaa is enabled. For example glxgears.

> gdb glxgears
> (gdb) set environment pp_jimenezmlaa 1
> (gdb) run

Might be a duplicate of bug 99549

-- 
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 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #9 from Dmitry  ---
I will not be able to do, not enough skill.

Tried to drag through TV files, TV breaks after the loss of the signal on the
main machine. Also tried to register in the console dmesg creation with the
switched-off screen, but nothing left. Perhaps there is a bug not with the
video, and no signal from keyboard and mouse. Why not get out of standby.

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

Re: [PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Christian König]

Am 09.02.2018 um 19:19 schrieb Tom St Denis:

On 09/02/18 01:17 PM, Christian König wrote:

Am 09.02.2018 um 18:28 schrieb Tom St Denis:

On 09/02/18 12:27 PM, Tom St Denis wrote:

From: Christian König 


Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.


The patch before this one isn't merged yet because I'm still not sure 
if that works under all circumstances or not.


Could you give it some extended testing? Especially if it work with 
eviction.


I supposed there is a race on the kmap'ed memory which is why I added 
a ptr check.  Not perfect but since it's a debugfs entry probably 
better than it needs to be.


I think you can drop that, kmap can only return NULL on 32bit systems 
when we ran out of vmap area and then you can basically call panic() as 
well.


The question is if setting page->mapping during allocation has some 
undesired side effect.


Christian.



I'll give it a try on some live traffic next.

Cheers,
Tom
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


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

[Bug 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

--- Comment #6 from Will  ---
That's my bad, my hardware is more different than I thought AND I spelled it
wrong, it's an A88XM-E45. I'll have to check again later tonight if
radeon.dpm=0 worked on its own, I'm having a hard time remembering now. How
embarrassing.

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

[radeon-alex:drm-next-4.17-wip 284/304] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:34: error: positional initialization of field in 'struct' declared with 'designated_init' attribut

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   9778e0d1a858869180a199844c578b199040271b
commit: b5d7df79439443dc493cbad1ccf800b0801fcbb6 [284/304] drm/amd/powerplay: 
implement set_mmhub_powergating_by_smu for Raven
config: x86_64-randconfig-s5-02092347 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout b5d7df79439443dc493cbad1ccf800b0801fcbb6
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the radeon-alex/drm-next-4.17-wip HEAD 
9778e0d1a858869180a199844c578b199040271b builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:3: error: 
'const struct pp_hwmgr_func' has no member named 'set_mmhub_powergating_by_smu'
 .set_mmhub_powergating_by_smu = rv_set_mmhub_powergating_by_smu,
  ^~~~
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:34: error: 
>> positional initialization of field in 'struct' declared with 
>> 'designated_init' attribute [-Werror=designated-init]
 .set_mmhub_powergating_by_smu = rv_set_mmhub_powergating_by_smu,
 ^~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:34: note: 
(near initialization for 'rv_hwmgr_funcs')
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:34: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:34: note: 
(near initialization for 
'rv_hwmgr_funcs.check_smc_update_required_for_display_configuration')
   cc1: some warnings being treated as errors

vim +1067 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c

  1033  
  1034  static const struct pp_hwmgr_func rv_hwmgr_funcs = {
  1035  .backend_init = rv_hwmgr_backend_init,
  1036  .backend_fini = rv_hwmgr_backend_fini,
  1037  .asic_setup = NULL,
  1038  .apply_state_adjust_rules = rv_apply_state_adjust_rules,
  1039  .force_dpm_level = rv_dpm_force_dpm_level,
  1040  .get_power_state_size = rv_get_power_state_size,
  1041  .powerdown_uvd = NULL,
  1042  .powergate_uvd = NULL,
  1043  .powergate_vce = NULL,
  1044  .get_mclk = rv_dpm_get_mclk,
  1045  .get_sclk = rv_dpm_get_sclk,
  1046  .patch_boot_state = rv_dpm_patch_boot_state,
  1047  .get_pp_table_entry = rv_dpm_get_pp_table_entry,
  1048  .get_num_of_pp_table_entries = 
rv_dpm_get_num_of_pp_table_entries,
  1049  .set_cpu_power_state = rv_set_cpu_power_state,
  1050  .store_cc6_data = rv_store_cc6_data,
  1051  .force_clock_level = rv_force_clock_level,
  1052  .print_clock_levels = rv_print_clock_levels,
  1053  .get_dal_power_level = rv_get_dal_power_level,
  1054  .get_performance_level = rv_get_performance_level,
  1055  .get_current_shallow_sleep_clocks = 
rv_get_current_shallow_sleep_clocks,
  1056  .get_clock_by_type_with_latency = 
rv_get_clock_by_type_with_latency,
  1057  .get_clock_by_type_with_voltage = 
rv_get_clock_by_type_with_voltage,
  1058  .get_max_high_clocks = rv_get_max_high_clocks,
  1059  .read_sensor = rv_read_sensor,
  1060  .set_active_display_count = rv_set_active_display_count,
  1061  .set_deep_sleep_dcefclk = rv_set_deep_sleep_dcefclk,
  1062  .dynamic_state_management_enable = rv_enable_dpm_tasks,
  1063  .power_off_asic = rv_power_off_asic,
  1064  .asic_setup = rv_setup_asic_task,
  1065  .power_state_set = rv_set_power_state_tasks,
  1066  .dynamic_state_management_disable = rv_disable_dpm_tasks,
> 1067  .set_mmhub_powergating_by_smu = rv_set_mmhub_powergating_by_smu,
  1068  };
  1069  

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


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

Re: [PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Tom St Denis]

On 09/02/18 01:17 PM, Christian König wrote:

Am 09.02.2018 um 18:28 schrieb Tom St Denis:

On 09/02/18 12:27 PM, Tom St Denis wrote:

From: Christian König 


Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.


The patch before this one isn't merged yet because I'm still not sure if 
that works under all circumstances or not.


Could you give it some extended testing? Especially if it work with 
eviction.


I supposed there is a race on the kmap'ed memory which is why I added a 
ptr check.  Not perfect but since it's a debugfs entry probably better 
than it needs to be.


I'll give it a try on some live traffic next.

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

Re: [PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Christian König]

Am 09.02.2018 um 18:28 schrieb Tom St Denis:

On 09/02/18 12:27 PM, Tom St Denis wrote:

From: Christian König 


Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.


The patch before this one isn't merged yet because I'm still not sure if 
that works under all circumstances or not.


Could you give it some extended testing? Especially if it work with 
eviction.


Christian.



Tom



This allows access to pages allocated through the driver with optional
IOMMU mapping.

v2: Fix number of bytes copied and add write method

Original-by: Christian König 
Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 110 
++--

  1 file changed, 89 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

index b372d8d650a5..d6c56b001a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,106 @@ static const struct file_operations 
amdgpu_ttm_gtt_fops = {

    #endif
  -static ssize_t amdgpu_iova_to_phys_read(struct file *f, char 
__user *buf,

-   size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+ size_t size, loff_t *pos)
  {
  struct amdgpu_device *adev = file_inode(f)->i_private;
-    int r;
-    uint64_t phys;
  struct iommu_domain *dom;
+    ssize_t result = 0;
+    int r;
  -    // always return 8 bytes
-    if (size != 8)
-    return -EINVAL;
+    dom = iommu_get_domain_for_dev(adev->dev);
  -    // only accept page addresses
-    if (*pos & 0xFFF)
-    return -EINVAL;
+    while (size) {
+    phys_addr_t addr = *pos & PAGE_MASK;
+    loff_t off = *pos & ~PAGE_MASK;
+    size_t bytes = PAGE_SIZE - off;
+    unsigned long pfn;
+    struct page *p;
+    void *ptr;
+
+    bytes = bytes < size ? bytes : size;
+
+    addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
+
+    pfn = addr >> PAGE_SHIFT;
+    if (!pfn_valid(pfn))
+    return -EPERM;
+
+    p = pfn_to_page(pfn);
+    if (p->mapping != adev->mman.bdev.dev_mapping)
+    return -EPERM;
+
+    ptr = kmap(p);
+    if (ptr) {
+    r = copy_to_user(buf, ptr, bytes);
+    kunmap(p);
+    if (r)
+    return -EFAULT;
+    } else {
+    return -EFAULT;
+    }
+
+    size -= bytes;
+    *pos += bytes;
+    result += bytes;
+    }
+
+    return result;
+}
+
+static ssize_t amdgpu_iomem_write(struct file *f, const char __user 
*buf,

+ size_t size, loff_t *pos)
+{
+    struct amdgpu_device *adev = file_inode(f)->i_private;
+    struct iommu_domain *dom;
+    ssize_t result = 0;
+    int r;
    dom = iommu_get_domain_for_dev(adev->dev);
-    if (dom)
-    phys = iommu_iova_to_phys(dom, *pos);
-    else
-    phys = *pos;
  -    r = copy_to_user(buf, , 8);
-    if (r)
-    return -EFAULT;
+    while (size) {
+    phys_addr_t addr = *pos & PAGE_MASK;
+    loff_t off = *pos & ~PAGE_MASK;
+    size_t bytes = PAGE_SIZE - off;
+    unsigned long pfn;
+    struct page *p;
+    void *ptr;
+
+    bytes = bytes < size ? bytes : size;
+
+    addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
  -    return 8;
+    pfn = addr >> PAGE_SHIFT;
+    if (!pfn_valid(pfn))
+    return -EPERM;
+
+    p = pfn_to_page(pfn);
+    if (p->mapping != adev->mman.bdev.dev_mapping)
+    return -EPERM;
+
+    ptr = kmap(p);
+    if (ptr) {
+    r = copy_from_user(ptr, buf, bytes);
+    kunmap(p);
+    if (r)
+    return -EFAULT;
+    } else {
+    return -EFAULT;
+    }
+
+    size -= bytes;
+    *pos += bytes;
+    result += bytes;
+    }
+
+    return result;
  }
  -static const struct file_operations amdgpu_ttm_iova_fops = {
+static const struct file_operations amdgpu_ttm_iomem_fops = {
  .owner = THIS_MODULE,
-    .read = amdgpu_iova_to_phys_read,
+    .read = amdgpu_iomem_read,
+    .write = amdgpu_iomem_write,
  .llseek = default_llseek
  };
  @@ -1973,7 +2041,7 @@ static const struct {
  #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
  { "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
  #endif
-    { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
+    { "amdgpu_iomem", _ttm_iomem_fops, TTM_PL_SYSTEM },
  };
    #endif





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

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Andy Lutomirski]

On Fri, Feb 9, 2018 at 7:39 AM, Rodrigo Vivi  wrote:
> Rodrigo Vivi  writes:
>
>> "Pandiyan, Dhinakaran"  writes:
>>
>>> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
 Hi Andy,

 thanks for getting involved with PSR and sorry for not replying sooner.

 I first saw this patch on that bugzilla entry but only now I stop to
 really think why I have written the code that way.

 So some clarity below.

 On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
 > The current PSR code has a two call sites that each schedule delayed
 > work to activate PSR.  As far as I can tell, each call site intends
 > to keep PSR inactive for the given amount of time and then allow it
 > to be activated.
 >
 > The call sites are:
 >
 >  - intel_psr_enable(), which explicitly states in a comment that
 >it's trying to keep PSR off a short time after the dispay is
 >initialized as a workaround.

 First of all I really want to kill this call here and remove the
 FIXME. It was an ugly hack that I added to solve a corner case
 that was leaving me with blank screens when activating so sooner.

 >
 >  - intel_psr_flush().  There isn't an explcit explanation, but the
 >intent is presumably to keep PSR off until the display has been
 >idle for 100ms.

 The reason for 100 is kind of ugly-nonsense-empirical value
 I concluded from VLV/CHV experience.
 On platforms with HW tracking HW waits few identical frames
 until really activating PSR. VLV/CHV activation is immediate.
 But HW is also different and there it seemed that hw needed a
 few more time before starting the transitions.
 Furthermore I didn't want to add that so quickly because I didn't
 want to take the risk of killing battery with software tracking
 when doing transitions so quickly using software tracking.

 >
 > The current code doesn't actually accomplish either of these goals.
 > Rather than keeping PSR inactive for the given amount of time, it
 > will schedule PSR for activation after the given time, with the
 > earliest target time in such a request winning.

 Putting that way I was asking myself how that hack had ever fixed
 my issue. Because the way you explained here seems obvious that it
 wouldn't ever fix my bug or any other.

 So I applied your patch and it made even more sense (without considering
 the fact I want to kill the first call anyways).

 So I came back, removed your patch and tried to understand how did
 it ever worked.

 So, the thing is that intel_psr_flush will never be really executed
 if intel_psr_enable wasn't executed. That is guaranteed by:

 mutex_lock(_priv->psr.lock);
 if (!dev_priv->psr.enabled) {

 So, intel_psr_enable will be for sure the first one to schedule the
 work delayed to the ugly higher delay.

 >
 > In other words, if intel_psr_enable() is immediately followed by
 > intel_psr_flush(), then PSR will be activated after 100ms even if
 > intel_psr_enable() wanted a longer delay.  And, if the screen is
 > being constantly updated so that intel_psr_flush() is called once
 > per frame at 60Hz, PSR will still be activated once every 100ms.

 During this time you are right, many calls of intel_psr_exit
 coming from flush functions can be called... But none of
 them will schedule the work with 100 delay.

 they will skip on
 if (!work_busy(_priv->psr.work.work))
>>>
>>> Wouldn't work_busy() return false until the work is actually queued
>>> which is 100ms after calling schedule_delayed_work()?
>>
>> That's not my understanding of work_busy man.
>>
>> "work_busy - test whether a work is currently pending or running"
>>
>> I consider it as pending one...
>>
>> But yeap... it was a long time ago that I did this so I'm not sure...
>
> I wouldn't be able to sleep today if I hand't experiment this.
>
> So, I move the hacked scheduled to 10s and forced psr_activate 10ms
> after that and the result is this:
>
>
> [   11.757909] [drm:intel_psr_enable [i915]] *ERROR* I915-DEBUG:
> Scheduling 10s
> [   11.778586] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> ...
> a bunch more of Work busy
> ...
> [   21.980643] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!

This like ("Work busy!") is intel_psr_flush() noticing that
work_busy() returns true (which it does indeed do when the work is
scheduled for the future).  But this means that intel_psr_flush()
wants to keep PSR off for a little bit (10s with your patch applied)
because the screen isn't idle.

> [   21.983060] [drm:intel_psr_work [i915]] *ERROR* I915-DEBUG: Work running

And here's intel_psr_work() turning PSR back on 3ms later.

So I think you're 

Re: [PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Tom St Denis]

On 09/02/18 12:27 PM, Tom St Denis wrote:

From: Christian König 


Oops, I'll remove this from the commit message before pushing :-)

I did give you credit below though.

Tom



This allows access to pages allocated through the driver with optional
IOMMU mapping.

v2: Fix number of bytes copied and add write method

Original-by: Christian König 
Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 110 ++--
  1 file changed, 89 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b372d8d650a5..d6c56b001a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,106 @@ static const struct file_operations 
amdgpu_ttm_gtt_fops = {
  
  #endif
  
-static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,

-  size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+size_t size, loff_t *pos)
  {
struct amdgpu_device *adev = file_inode(f)->i_private;
-   int r;
-   uint64_t phys;
struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
  
-	// always return 8 bytes

-   if (size != 8)
-   return -EINVAL;
+   dom = iommu_get_domain_for_dev(adev->dev);
  
-	// only accept page addresses

-   if (*pos & 0xFFF)
-   return -EINVAL;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
+
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
+
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   if (ptr) {
+   r = copy_to_user(buf, ptr, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+   } else {
+   return -EFAULT;
+   }
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
+}
+
+static ssize_t amdgpu_iomem_write(struct file *f, const char __user *buf,
+size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
  
  	dom = iommu_get_domain_for_dev(adev->dev);

-   if (dom)
-   phys = iommu_iova_to_phys(dom, *pos);
-   else
-   phys = *pos;
  
-	r = copy_to_user(buf, , 8);

-   if (r)
-   return -EFAULT;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
+
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
  
-	return 8;

+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   if (ptr) {
+   r = copy_from_user(ptr, buf, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+   } else {
+   return -EFAULT;
+   }
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
  }
  
-static const struct file_operations amdgpu_ttm_iova_fops = {

+static const struct file_operations amdgpu_ttm_iomem_fops = {
.owner = THIS_MODULE,
-   .read = amdgpu_iova_to_phys_read,
+   .read = amdgpu_iomem_read,
+   .write = amdgpu_iomem_write,
.llseek = default_llseek
  };
  
@@ -1973,7 +2041,7 @@ static const struct {

  #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
  #endif
-   { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
+   { "amdgpu_iomem", _ttm_iomem_fops, TTM_PL_SYSTEM },
  };
  
  #endif




___

[PATCH] drm/amdgpu: replace iova debugfs file with iomem (v2)

[Tom St Denis]

From: Christian König 

This allows access to pages allocated through the driver with optional
IOMMU mapping.

v2: Fix number of bytes copied and add write method

Original-by: Christian König 
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 110 ++--
 1 file changed, 89 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b372d8d650a5..d6c56b001a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,106 @@ static const struct file_operations 
amdgpu_ttm_gtt_fops = {
 
 #endif
 
-static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
-  size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+size_t size, loff_t *pos)
 {
struct amdgpu_device *adev = file_inode(f)->i_private;
-   int r;
-   uint64_t phys;
struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
 
-   // always return 8 bytes
-   if (size != 8)
-   return -EINVAL;
+   dom = iommu_get_domain_for_dev(adev->dev);
 
-   // only accept page addresses
-   if (*pos & 0xFFF)
-   return -EINVAL;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
+
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
+
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   if (ptr) {
+   r = copy_to_user(buf, ptr, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+   } else {
+   return -EFAULT;
+   }
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
+}
+
+static ssize_t amdgpu_iomem_write(struct file *f, const char __user *buf,
+size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
 
dom = iommu_get_domain_for_dev(adev->dev);
-   if (dom)
-   phys = iommu_iova_to_phys(dom, *pos);
-   else
-   phys = *pos;
 
-   r = copy_to_user(buf, , 8);
-   if (r)
-   return -EFAULT;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
+
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
 
-   return 8;
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   if (ptr) {
+   r = copy_from_user(ptr, buf, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+   } else {
+   return -EFAULT;
+   }
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
 }
 
-static const struct file_operations amdgpu_ttm_iova_fops = {
+static const struct file_operations amdgpu_ttm_iomem_fops = {
.owner = THIS_MODULE,
-   .read = amdgpu_iova_to_phys_read,
+   .read = amdgpu_iomem_read,
+   .write = amdgpu_iomem_write,
.llseek = default_llseek
 };
 
@@ -1973,7 +2041,7 @@ static const struct {
 #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
 #endif
-   { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
+   { "amdgpu_iomem", _ttm_iomem_fops, TTM_PL_SYSTEM },
 };
 
 #endif
-- 
2.14.3

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

Re: Questions on page flips and atomic modeset

[Ville Syrjälä]

On Fri, Feb 09, 2018 at 06:30:08PM +0200, Oleksandr Andrushchenko wrote:
> -- OFFTOP --
> BTW, what is the right branch should I use
> for a new DRM driver and the patch like the above?
> I am lost a bit :)

Usual recommendation is to use:
git://anongit.freedesktop.org/drm-tip drm-tip

But note that as an integration tree it gets rebuilt every time
someone pushes something to one of the proper branches that are part of
drm-tip. So you don't want to use 'git rebase /drm-tip' to rebase
your work on top, and instead you'll want to use the rebase --onto
thing. 'dim retip' [1] (or the equivalent 'git retip' [2] in your
.gitconfig) does that for you neatly.

[1] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html

[2]
 [alias]
find-tip = log -1 --format=%H --grep=\"^drm-tip: .* integration 
manifest$\"
retip = "!git rebase --onto drm_tip/drm-tip `git find-tip`"

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

Re: Questions on page flips and atomic modeset

[Oleksandr Andrushchenko]

On 02/09/2018 06:24 PM, Ville Syrjälä wrote:

On Fri, Feb 09, 2018 at 06:09:09PM +0200, Oleksandr Andrushchenko wrote:

On 02/09/2018 05:53 PM, Ville Syrjälä wrote:

On Thu, Feb 08, 2018 at 11:53:30AM +0200, Oleksandr Andrushchenko wrote:

Hello, Ville!

On 02/06/2018 06:04 PM, Ville Syrjälä wrote:

On Tue, Feb 06, 2018 at 11:59:37AM +0200, Oleksandr Andrushchenko wrote:

Hello, Ville!

Thank you very much for such a comprehensive answer.

Please see inline


On 02/05/2018 06:47 PM, Ville Syrjälä wrote:

On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:

Hello,


I have a DRM driver which implements display protocol for Xen [1]
and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
tells the other end that some display buffer needs to be displayed,
e.g. it is issued by the frontend DRM driver to the corresponding
backend when the former wants to display a buffer.
Two notes:
1. Communication between two remote parties can obviously fail.
2. At the moment only primary plane is supported, so we can think of
the display buffer as of CRTC's primary fb.

There are two APIs available for user-space to initiate a page-flip
(please correct me if I am wrong here): legacy via DRM_IOCTL_MODE_PAGE_FLIP
and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
(which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
I can return an error code, so the DRM core knows that page flip
cannot be done.

But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via .atomic_check +
.atomic_flush callbacks.

The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP request
to the .atomic_flush callback which seems to be the right place to serve
both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).

The questions I have with this are:

1. What is the framebuffer I can send to the backend?
I assume I can use crtc->primary->fb from
drm_crtc_helper_funcs.atomic_flush,
is this assumption correct?

Planes are explicit in the atomic world, so you should just deal with
the plane if and when it's part of the drm_atomic_state. Look at eg.
drm_atomic_helper_commit_planes() how to figure out what's in the
state.

Yes, this is clear. The question was about the frame buffer
I get in drm_crtc_helper_funcs.atomic_flush which only has
old_crtc_state, so I assumed I can use crtc->primary->fb there.
Or you mean I have to dig into old_crtc_state->state to find
out if there is a plane and if it has a frambuffer and if so
use it instead of crtc->primary->fb?

You will get the plane explicitly as part of the drm_atomic_state.
Normally you shouldn't need to go find it via other means.

Oh, and never use the plane->fb etc. pointers in an atomic driver.
Those are for legacy purposes only. Atomic drivers should only ever
deal with proper state objects.

I am using fb from corresponding state now, thank you

 And I guess you're already planning on using that helper since
you mention .atomic_flush().

Not directly, but via drm_mode_config_funcs.atomic_commit

.atomic_commit() is a hook the driver has to provide. Most drivers use
the helper for it, which in turn requires the driver to provide other
hooks such as .atomic_flush(). That is what you appear to be doing.

you are correct

One should really think of the drm_atomic_state as more of a transaction
rather than as a state (since not all objects need be part of it).

Thank you

2. Is the check (either to send or not) for crtc->primary->fb != NULL
enough?
I assume there are other cases when .atomic_flush gets called,
so is there a way I can filter out unneeded cases? E.g. those which
are not for page flipping?

Each object taking part in the transaction will have an associated
new state and old state.

As I replied above I only have old state in .atomic_flush

Oh right. That way of passing the old state only dates back to earlier
days of atomic. To find the new state what you should do these days
is something like:

foo(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
struct drm_atomic_state *state = old_state->state;
struct drm_crtc_state *new_state =
drm_atomic_get_new_crtc_state(state, crtc);
...

The old way was to use the crtc->state pointer as either the old
or new state depending on where you are in the commit sequence.
But that wasn't very good so Maarten changed things so that we
now have explicit old and new states for each object tracked in
the drm_atomic_state.

I think what we should really do is change most of the hooks to
pass crtc+drm_atomic_state instead, and let each function grab
the old and/or new crtc state from the drm_atomic_state as needed.
I believe that would avoid confusing people with just the old or
new state.

That would be great

 You can compare the two to figure out what
changed, and in addition 

Re: Questions on page flips and atomic modeset

[Ville Syrjälä]

On Fri, Feb 09, 2018 at 06:09:09PM +0200, Oleksandr Andrushchenko wrote:
> On 02/09/2018 05:53 PM, Ville Syrjälä wrote:
> > On Thu, Feb 08, 2018 at 11:53:30AM +0200, Oleksandr Andrushchenko wrote:
> >> Hello, Ville!
> >>
> >> On 02/06/2018 06:04 PM, Ville Syrjälä wrote:
> >>> On Tue, Feb 06, 2018 at 11:59:37AM +0200, Oleksandr Andrushchenko wrote:
>  Hello, Ville!
> 
>  Thank you very much for such a comprehensive answer.
> 
>  Please see inline
> 
> 
>  On 02/05/2018 06:47 PM, Ville Syrjälä wrote:
> > On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:
> >> Hello,
> >>
> >>
> >> I have a DRM driver which implements display protocol for Xen [1]
> >> and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
> >> tells the other end that some display buffer needs to be displayed,
> >> e.g. it is issued by the frontend DRM driver to the corresponding
> >> backend when the former wants to display a buffer.
> >> Two notes:
> >> 1. Communication between two remote parties can obviously fail.
> >> 2. At the moment only primary plane is supported, so we can think of
> >> the display buffer as of CRTC's primary fb.
> >>
> >> There are two APIs available for user-space to initiate a page-flip
> >> (please correct me if I am wrong here): legacy via 
> >> DRM_IOCTL_MODE_PAGE_FLIP
> >> and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
> >> (which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
> >> XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
> >> I can return an error code, so the DRM core knows that page flip
> >> cannot be done.
> >>
> >> But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC 
> >> for
> >> which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via 
> >> .atomic_check +
> >> .atomic_flush callbacks.
> >>
> >> The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP 
> >> request
> >> to the .atomic_flush callback which seems to be the right place to 
> >> serve
> >> both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).
> >>
> >> The questions I have with this are:
> >>
> >> 1. What is the framebuffer I can send to the backend?
> >> I assume I can use crtc->primary->fb from
> >> drm_crtc_helper_funcs.atomic_flush,
> >> is this assumption correct?
> > Planes are explicit in the atomic world, so you should just deal with
> > the plane if and when it's part of the drm_atomic_state. Look at eg.
> > drm_atomic_helper_commit_planes() how to figure out what's in the
> > state.
>  Yes, this is clear. The question was about the frame buffer
>  I get in drm_crtc_helper_funcs.atomic_flush which only has
>  old_crtc_state, so I assumed I can use crtc->primary->fb there.
>  Or you mean I have to dig into old_crtc_state->state to find
>  out if there is a plane and if it has a frambuffer and if so
>  use it instead of crtc->primary->fb?
> >>> You will get the plane explicitly as part of the drm_atomic_state.
> >>> Normally you shouldn't need to go find it via other means.
> >>>
> >>> Oh, and never use the plane->fb etc. pointers in an atomic driver.
> >>> Those are for legacy purposes only. Atomic drivers should only ever
> >>> deal with proper state objects.
> >> I am using fb from corresponding state now, thank you
> > And I guess you're already planning on using that helper since
> > you mention .atomic_flush().
>  Not directly, but via drm_mode_config_funcs.atomic_commit
> >>> .atomic_commit() is a hook the driver has to provide. Most drivers use
> >>> the helper for it, which in turn requires the driver to provide other
> >>> hooks such as .atomic_flush(). That is what you appear to be doing.
> >> you are correct
> > One should really think of the drm_atomic_state as more of a transaction
> > rather than as a state (since not all objects need be part of it).
>  Thank you
> >> 2. Is the check (either to send or not) for crtc->primary->fb != NULL
> >> enough?
> >> I assume there are other cases when .atomic_flush gets called,
> >> so is there a way I can filter out unneeded cases? E.g. those which
> >> are not for page flipping?
> > Each object taking part in the transaction will have an associated
> > new state and old state.
>  As I replied above I only have old state in .atomic_flush
> >>> Oh right. That way of passing the old state only dates back to earlier
> >>> days of atomic. To find the new state what you should do these days
> >>> is something like:
> >>>
> >>> foo(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
> >>> {
> >>>   struct drm_atomic_state *state = old_state->state;
> >>>   struct drm_crtc_state *new_state =
> >>>   drm_atomic_get_new_crtc_state(state, 

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Tom St Denis]

On 09/02/18 09:56 AM, Christian König wrote:

Am 09.02.2018 um 15:51 schrieb Tom St Denis:

On 09/02/18 09:12 AM, Christian König wrote:
No, there is simply no need to initialize the system domain. What are 
the values of p->mapping and adev->mman.bdev.dev_mapping when they 
don't match? Maybe we are allocating memory before initializing 
adev->mman.bdev.dev_mapping.


In my test setup I'm running test 3 from libdrm (suite 1) with a pause 
before the unmap/free call.  So the IB should still be mapped.  Indeed 
the VM PTE decoding has the V bit set.


Or do you have more than one GPU in the system? E.g. APU+dGPU? Could 
it be that you read through the wrong device?


I found the issue:

while (size) {
    phys_addr_t addr = *pos & PAGE_MASK;
    loff_t off = *pos & ~PAGE_MASK;
    size_t bytes = PAGE_SIZE - off;

"bytes" should be limited by the 'size' parameter passed in.  What is 
happening instead is it's reading the entire PTB until it hits a V=0 
page and then returns an error and in the process is doing "fun 
things" to the user mode application (by copying more data than I 
asked for).


Ah, obvious problem.

Do you want to fix it or should I take a look? You wanted to add write 
support as well anyway IIRC.


Yup, I can tackle this this afternoon.

I'll take your read only patch and make it do both read/write (and fix 
the minor error).


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

Re: Questions on page flips and atomic modeset

[Oleksandr Andrushchenko]

On 02/09/2018 05:53 PM, Ville Syrjälä wrote:

On Thu, Feb 08, 2018 at 11:53:30AM +0200, Oleksandr Andrushchenko wrote:

Hello, Ville!

On 02/06/2018 06:04 PM, Ville Syrjälä wrote:

On Tue, Feb 06, 2018 at 11:59:37AM +0200, Oleksandr Andrushchenko wrote:

Hello, Ville!

Thank you very much for such a comprehensive answer.

Please see inline


On 02/05/2018 06:47 PM, Ville Syrjälä wrote:

On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:

Hello,


I have a DRM driver which implements display protocol for Xen [1]
and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
tells the other end that some display buffer needs to be displayed,
e.g. it is issued by the frontend DRM driver to the corresponding
backend when the former wants to display a buffer.
Two notes:
1. Communication between two remote parties can obviously fail.
2. At the moment only primary plane is supported, so we can think of
the display buffer as of CRTC's primary fb.

There are two APIs available for user-space to initiate a page-flip
(please correct me if I am wrong here): legacy via DRM_IOCTL_MODE_PAGE_FLIP
and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
(which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
I can return an error code, so the DRM core knows that page flip
cannot be done.

But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via .atomic_check +
.atomic_flush callbacks.

The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP request
to the .atomic_flush callback which seems to be the right place to serve
both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).

The questions I have with this are:

1. What is the framebuffer I can send to the backend?
I assume I can use crtc->primary->fb from
drm_crtc_helper_funcs.atomic_flush,
is this assumption correct?

Planes are explicit in the atomic world, so you should just deal with
the plane if and when it's part of the drm_atomic_state. Look at eg.
drm_atomic_helper_commit_planes() how to figure out what's in the
state.

Yes, this is clear. The question was about the frame buffer
I get in drm_crtc_helper_funcs.atomic_flush which only has
old_crtc_state, so I assumed I can use crtc->primary->fb there.
Or you mean I have to dig into old_crtc_state->state to find
out if there is a plane and if it has a frambuffer and if so
use it instead of crtc->primary->fb?

You will get the plane explicitly as part of the drm_atomic_state.
Normally you shouldn't need to go find it via other means.

Oh, and never use the plane->fb etc. pointers in an atomic driver.
Those are for legacy purposes only. Atomic drivers should only ever
deal with proper state objects.

I am using fb from corresponding state now, thank you

And I guess you're already planning on using that helper since
you mention .atomic_flush().

Not directly, but via drm_mode_config_funcs.atomic_commit

.atomic_commit() is a hook the driver has to provide. Most drivers use
the helper for it, which in turn requires the driver to provide other
hooks such as .atomic_flush(). That is what you appear to be doing.

you are correct

One should really think of the drm_atomic_state as more of a transaction
rather than as a state (since not all objects need be part of it).

Thank you

2. Is the check (either to send or not) for crtc->primary->fb != NULL
enough?
I assume there are other cases when .atomic_flush gets called,
so is there a way I can filter out unneeded cases? E.g. those which
are not for page flipping?

Each object taking part in the transaction will have an associated
new state and old state.

As I replied above I only have old state in .atomic_flush

Oh right. That way of passing the old state only dates back to earlier
days of atomic. To find the new state what you should do these days
is something like:

foo(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
struct drm_atomic_state *state = old_state->state;
struct drm_crtc_state *new_state =
drm_atomic_get_new_crtc_state(state, crtc);
...

The old way was to use the crtc->state pointer as either the old
or new state depending on where you are in the commit sequence.
But that wasn't very good so Maarten changed things so that we
now have explicit old and new states for each object tracked in
the drm_atomic_state.

I think what we should really do is change most of the hooks to
pass crtc+drm_atomic_state instead, and let each function grab
the old and/or new crtc state from the drm_atomic_state as needed.
I believe that would avoid confusing people with just the old or
new state.

That would be great

You can compare the two to figure out what
changed, and in addition there may already some flags in the base
class for the state that indicate what may have changed (eg.

Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

[Chris Chiu]

On Thu, Feb 1, 2018 at 9:13 PM, Chris Chiu  wrote:
> On Thu, Feb 1, 2018 at 12:08 AM, Harry Wentland  
> wrote:
>> On 2018-01-31 09:31 AM, Chris Chiu wrote:
>>> Hi,
>>> We are working with new laptops that have the AMD Ravenl Ridge
>>> chipset with this `/proc/cpuinfo`
>>> https://gist.github.com/mschiu77/b06dba574e89b9a30cf4c450eaec49bc
>>>
>>> With the latest kernel 4.15, there're lots of different
>>> panics/oops during boot so no chance to get into X. It also happens
>>> during shutdown. Then I tried to build kernel from
>>> git://people.freedesktop.org/~agd5f/linux on branch
>>> amd-staging-drm-next with head on commit "drm: Fix trailing semicolon"
>>> and update the linux-firmware. Things seem to get better, only 1 oops
>>> observed. Here's the oops
>>> https://gist.github.com/mschiu77/1a68f27272b24775b2040acdb474cdd3.
>>
>> Hi Chris,
>>
>> what are the steps to reproduce this oops?
>>
>> Does it reproduce all the time or is it intermittent?
>>
>> Can you send a dmesg with amdgpu.dc_log=1, in addition to drm.debug=0xe?
>>
>> Thanks,
>> Harry
>>
>
> I did nothing special to reproduce the oops. Boot and sometimes it
> just shows blank
> screen but still responds to magic sysrq. So I reboot and take the journal 
> log.
>
> It's intermittent, I ran into it 2 times during 13 reboots.
> The logs are listed as follows
> https://gist.github.com/mschiu77/9307d1ca0acd046cc6817f8cad63d79c
> https://gist.github.com/mschiu77/fa81110f93428721f017cb9fbfd06fbe
>
> One more log here. It enters X OK but after few minutes the display
> went black and
> only a mouse cursor left. But the mouse cursor can't even move. So I do a 
> sysrq
> reboot again.
> The last error is
> ""
> [  636.312759] endless kernel:
> [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR*
> [CRTC:41:crtc-0] flip_done timed out
> [  646.552344] endless kernel:
> [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR*
> [CRTC:41:crtc-0] flip_done timed out
> ""
> full log here 
> https://gist.github.com/mschiu77/c8696e5fefb17bb1c53598214fb4e382
>
> Only 4 times I can login X, blank screen or hangs w/o responding to
> magic sysrq for
> the rest. I took a picture of the only panic although I think it's not
> about amdgpu.
> It's here.
> https://pasteboard.co/H5CUvxk.jpg
>
> Hope they can be helpful.
>
> Chris
>
>>> However, I still get stuck on the following messages during boot very
>>> often
>>> ""
>>> [4.998241] endless kernel: [drm] amdgpu kernel modesetting enabled.
>>> [4.998288] endless kernel: checking generic (e000 7f) vs
>>> hw (e000 1000)
>>> [4.998289] endless kernel: fb: switching to amdgpudrmfb from EFI VGA
>>> ""
>>> I turned on drm.debug=0xe while booting, but no more information at this 
>>> point.
>>> Anything I can do at this point?
>>>
>>> And there's 1 more information may be helpful. Sometimes the
>>> system boots OK with the blank screen, I can't switch to virtual
>>> console, but it did respond to the magic sys-rq key. The dmesg with
>>> drm.debug=0xe is here
>>> https://gist.github.com/mschiu77/291e47b1f07dc52be9461c55c820464c.
>>>
>>> I'm pretty sure it's due to the amdgpu driver. Because when I boot
>>> with my own kernel which disables the amdgpu driver, all these
>>> symptoms went away. Please suggest anything I can do for this. Thanks
>>>
>>> Chris
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>

Gentle ping, cheers.

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

[PATCH] gpu/drm/udl: Replace struct_mutex with driver private lock

[Shreeya Patel]

dev->struct_mutex is the Big DRM Lock and the only bit where
it’s mandatory is serializing GEM buffer object destruction.
Which unfortunately means drivers have to keep track of that
lock and either call unreference or unreference_locked
depending upon context. Core GEM doesn’t have a need for
struct_mutex any more since kernel 4.8.

For drivers that need struct_mutex it should be replaced by a driver
private lock.

Signed-off-by: Shreeya Patel 
---
 drivers/gpu/drm/udl/udl_dmabuf.c | 5 +++--
 drivers/gpu/drm/udl/udl_drv.h| 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c b/drivers/gpu/drm/udl/udl_dmabuf.c
index 2867ed1..120d2d9 100644
--- a/drivers/gpu/drm/udl/udl_dmabuf.c
+++ b/drivers/gpu/drm/udl/udl_dmabuf.c
@@ -76,6 +76,7 @@ static struct sg_table *udl_map_dma_buf(struct 
dma_buf_attachment *attach,
struct udl_drm_dmabuf_attachment *udl_attach = attach->priv;
struct udl_gem_object *obj = to_udl_bo(attach->dmabuf->priv);
struct drm_device *dev = obj->base.dev;
+   struct udl_device *udl = dev->dev_private;
struct scatterlist *rd, *wr;
struct sg_table *sgt = NULL;
unsigned int i;
@@ -112,7 +113,7 @@ static struct sg_table *udl_map_dma_buf(struct 
dma_buf_attachment *attach,
return ERR_PTR(-ENOMEM);
}
 
-   mutex_lock(>struct_mutex);
+   mutex_lock(>urbs.plock);
 
rd = obj->sg->sgl;
wr = sgt->sgl;
@@ -137,7 +138,7 @@ static struct sg_table *udl_map_dma_buf(struct 
dma_buf_attachment *attach,
attach->priv = udl_attach;
 
 err_unlock:
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>urbs.plock);
return sgt;
 }
 
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 2a75ab8..24cca17 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -39,6 +39,7 @@ struct urb_node {
 
 struct urb_list {
struct list_head list;
+   struct mutex plock;
spinlock_t lock;
struct semaphore limit_sem;
int available;
-- 
2.7.4

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

[PATCH v8 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Vivek Gautam]

qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements. This smmu core is used with
multiple masters on msm8996, viz. mdss, video, etc.
Add bindings for the same.

Signed-off-by: Vivek Gautam 
Reviewed-by: Rob Herring 
---

Changes in v8:
 - Added the missing IOMMU_OF_DECLARE declaration for "qcom,smmu-v2"

 .../devicetree/bindings/iommu/arm,smmu.txt | 43 ++
 drivers/iommu/arm-smmu.c   | 14 +++
 2 files changed, 57 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 8a6ffce12af5..169222ae2706 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -17,10 +17,19 @@ conditions.
 "arm,mmu-401"
 "arm,mmu-500"
 "cavium,smmu-v2"
+"qcom,-smmu-v2", "qcom,smmu-v2"
 
   depending on the particular implementation and/or the
   version of the architecture implemented.
 
+  A number of Qcom SoCs use qcom,smmu-v2 version of the IP.
+  "qcom,-smmu-v2" represents a soc specific compatible
+  string that should be present along with the "qcom,smmu-v2"
+  to facilitate SoC specific clocks/power connections and to
+  address specific bug fixes.
+  An example string would be -
+  "qcom,msm8996-smmu-v2", "qcom,smmu-v2".
+
 - reg   : Base address and size of the SMMU.
 
 - #global-interrupts : The number of global interrupts exposed by the
@@ -71,6 +80,23 @@ conditions.
   or using stream matching with #iommu-cells = <2>, and
   may be ignored if present in such cases.
 
+- clock-names:Should be "bus", and "iface" for "qcom,smmu-v2"
+  implementation.
+
+  "bus" clock for "qcom,smmu-v2" is required for downstream
+  bus access and for the smmu ptw.
+
+  "iface" clock is required to access smmu's registers through
+  the TCU's programming interface.
+
+- clocks: Phandles for respective clocks described by clock-names.
+
+- power-domains:  Phandles to SMMU's power domain specifier. This is
+  required even if SMMU belongs to the master's power
+  domain, as the SMMU will have to be enabled and
+  accessed before master gets enabled and linked to its
+  SMMU.
+
 ** Deprecated properties:
 
 - mmu-masters (deprecated in favour of the generic "iommus" binding) :
@@ -137,3 +163,20 @@ conditions.
 iommu-map = <0  0 0x400>;
 ...
 };
+
+   /* Qcom's arm,smmu-v2 implementation */
+   smmu4: iommu {
+   compatible = "qcom,msm8996-smmu-v2", "qcom,smmu-v2";
+   reg = <0xd0 0x1>;
+
+   #global-interrupts = <1>;
+   interrupts = ,
+,
+;
+   #iommu-cells = <1>;
+   power-domains = < MDSS_GDSC>;
+
+   clocks = < SMMU_MDP_AXI_CLK>,
+< SMMU_MDP_AHB_CLK>;
+   clock-names = "bus", "iface";
+   };
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c7e924d553bd..40da3f251acf 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -119,6 +119,7 @@ enum arm_smmu_implementation {
GENERIC_SMMU,
ARM_MMU500,
CAVIUM_SMMUV2,
+   QCOM_SMMUV2,
 };
 
 struct arm_smmu_s2cr {
@@ -1950,6 +1951,17 @@ struct arm_smmu_match_data {
 ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
 ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
 
+static const char * const qcom_smmuv2_clks[] = {
+   "bus", "iface",
+};
+
+static const struct arm_smmu_match_data qcom_smmuv2 = {
+   .version = ARM_SMMU_V2,
+   .model = QCOM_SMMUV2,
+   .clks = qcom_smmuv2_clks,
+   .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
+};
+
 static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = _generic_v1 },
{ .compatible = "arm,smmu-v2", .data = _generic_v2 },
@@ -1957,6 +1969,7 @@ struct arm_smmu_match_data {
{ .compatible = "arm,mmu-401", .data = _mmu401 },
{ .compatible = "arm,mmu-500", .data = _mmu500 },
{ .compatible = "cavium,smmu-v2", .data = _smmuv2 },
+   { .compatible = "qcom,smmu-v2", .data = _smmuv2 },
{ },
 };
 MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
@@ -2319,6 +2332,7 @@ static int __maybe_unused arm_smmu_runtime_suspend(struct 
device *dev)
 IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
 IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
 

Re: Questions on page flips and atomic modeset

[Ville Syrjälä]

On Thu, Feb 08, 2018 at 11:53:30AM +0200, Oleksandr Andrushchenko wrote:
> Hello, Ville!
> 
> On 02/06/2018 06:04 PM, Ville Syrjälä wrote:
> > On Tue, Feb 06, 2018 at 11:59:37AM +0200, Oleksandr Andrushchenko wrote:
> >> Hello, Ville!
> >>
> >> Thank you very much for such a comprehensive answer.
> >>
> >> Please see inline
> >>
> >>
> >> On 02/05/2018 06:47 PM, Ville Syrjälä wrote:
> >>> On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:
>  Hello,
> 
> 
>  I have a DRM driver which implements display protocol for Xen [1]
>  and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
>  tells the other end that some display buffer needs to be displayed,
>  e.g. it is issued by the frontend DRM driver to the corresponding
>  backend when the former wants to display a buffer.
>  Two notes:
>  1. Communication between two remote parties can obviously fail.
>  2. At the moment only primary plane is supported, so we can think of
>  the display buffer as of CRTC's primary fb.
> 
>  There are two APIs available for user-space to initiate a page-flip
>  (please correct me if I am wrong here): legacy via 
>  DRM_IOCTL_MODE_PAGE_FLIP
>  and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
>  (which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
>  XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
>  I can return an error code, so the DRM core knows that page flip
>  cannot be done.
> 
>  But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
>  which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via 
>  .atomic_check +
>  .atomic_flush callbacks.
> 
>  The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP 
>  request
>  to the .atomic_flush callback which seems to be the right place to serve
>  both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).
> 
>  The questions I have with this are:
> 
>  1. What is the framebuffer I can send to the backend?
>  I assume I can use crtc->primary->fb from
>  drm_crtc_helper_funcs.atomic_flush,
>  is this assumption correct?
> >>> Planes are explicit in the atomic world, so you should just deal with
> >>> the plane if and when it's part of the drm_atomic_state. Look at eg.
> >>> drm_atomic_helper_commit_planes() how to figure out what's in the
> >>> state.
> >> Yes, this is clear. The question was about the frame buffer
> >> I get in drm_crtc_helper_funcs.atomic_flush which only has
> >> old_crtc_state, so I assumed I can use crtc->primary->fb there.
> >> Or you mean I have to dig into old_crtc_state->state to find
> >> out if there is a plane and if it has a frambuffer and if so
> >> use it instead of crtc->primary->fb?
> > You will get the plane explicitly as part of the drm_atomic_state.
> > Normally you shouldn't need to go find it via other means.
> >
> > Oh, and never use the plane->fb etc. pointers in an atomic driver.
> > Those are for legacy purposes only. Atomic drivers should only ever
> > deal with proper state objects.
> I am using fb from corresponding state now, thank you
> >
> >>>And I guess you're already planning on using that helper since
> >>> you mention .atomic_flush().
> >> Not directly, but via drm_mode_config_funcs.atomic_commit
> > .atomic_commit() is a hook the driver has to provide. Most drivers use
> > the helper for it, which in turn requires the driver to provide other
> > hooks such as .atomic_flush(). That is what you appear to be doing.
> you are correct
> >>> One should really think of the drm_atomic_state as more of a transaction
> >>> rather than as a state (since not all objects need be part of it).
> >> Thank you
>  2. Is the check (either to send or not) for crtc->primary->fb != NULL
>  enough?
>  I assume there are other cases when .atomic_flush gets called,
>  so is there a way I can filter out unneeded cases? E.g. those which
>  are not for page flipping?
> >>> Each object taking part in the transaction will have an associated
> >>> new state and old state.
> >> As I replied above I only have old state in .atomic_flush
> > Oh right. That way of passing the old state only dates back to earlier
> > days of atomic. To find the new state what you should do these days
> > is something like:
> >
> > foo(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
> > {
> > struct drm_atomic_state *state = old_state->state;
> > struct drm_crtc_state *new_state =
> > drm_atomic_get_new_crtc_state(state, crtc);
> > ...
> >
> > The old way was to use the crtc->state pointer as either the old
> > or new state depending on where you are in the commit sequence.
> > But that wasn't very good so Maarten changed things so that we
> > now have explicit old and new states for each object tracked in
> > the drm_atomic_state.
> >
> > I 

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

--- Comment #4 from arne_woer...@yahoo.com ---
Created attachment 137247
  --> https://bugs.freedesktop.org/attachment.cgi?id=137247=edit
amdgpu related interrupt count

Michel Dänzer asked:
> When it's slow, do the numbers on the amdgpu line in
> /proc/interrupts increase over time?
>
in the first few seconds yes, but then no...
and the CPU number changes from 1 to 0...
-arne

-- 
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 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Christian König]

Am 09.02.2018 um 15:51 schrieb Tom St Denis:

On 09/02/18 09:12 AM, Christian König wrote:
No, there is simply no need to initialize the system domain. What are 
the values of p->mapping and adev->mman.bdev.dev_mapping when they 
don't match? Maybe we are allocating memory before initializing 
adev->mman.bdev.dev_mapping.


In my test setup I'm running test 3 from libdrm (suite 1) with a pause 
before the unmap/free call.  So the IB should still be mapped.  Indeed 
the VM PTE decoding has the V bit set.


Or do you have more than one GPU in the system? E.g. APU+dGPU? Could 
it be that you read through the wrong device?


I found the issue:

while (size) {
    phys_addr_t addr = *pos & PAGE_MASK;
    loff_t off = *pos & ~PAGE_MASK;
    size_t bytes = PAGE_SIZE - off;

"bytes" should be limited by the 'size' parameter passed in.  What is 
happening instead is it's reading the entire PTB until it hits a V=0 
page and then returns an error and in the process is doing "fun 
things" to the user mode application (by copying more data than I 
asked for).


Ah, obvious problem.

Do you want to fix it or should I take a look? You wanted to add write 
support as well anyway IIRC.


I've just pushed the first three patches from that series to 
amd-staging-drm-next.


Thanks for testing,
Christian.




Tom


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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Tom St Denis]

On 09/02/18 09:12 AM, Christian König wrote:
No, there is simply no need to initialize the system domain. What are 
the values of p->mapping and adev->mman.bdev.dev_mapping when they don't 
match? Maybe we are allocating memory before initializing 
adev->mman.bdev.dev_mapping.


In my test setup I'm running test 3 from libdrm (suite 1) with a pause 
before the unmap/free call.  So the IB should still be mapped.  Indeed 
the VM PTE decoding has the V bit set.


Or do you have more than one GPU in the system? E.g. APU+dGPU? Could it 
be that you read through the wrong device?


I found the issue:

while (size) {
phys_addr_t addr = *pos & PAGE_MASK;
loff_t off = *pos & ~PAGE_MASK;
size_t bytes = PAGE_SIZE - off;

"bytes" should be limited by the 'size' parameter passed in.  What is 
happening instead is it's reading the entire PTB until it hits a V=0 
page and then returns an error and in the process is doing "fun things" 
to the user mode application (by copying more data than I asked for).



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

Re: [PATCH v1 1/1] drm: Multiple Null pointer dereference [null-pointer-deref] (CWE 476) problems:

[Joe Moriarty]

On 2/9/2018 7:17 AM, Jani Nikula wrote:

On Thu, 08 Feb 2018, Joe Moriarty  wrote:

The Parfait (version 2.1.0) static code analysis tool found multiple NULL
pointer derefernce problems.


Thanks for the patch. Multiple problems requires multiple patches to fix
them, one patch per problem. Please split up the patch.

Thanks,
Jani.



- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to allocate memory for port->mstb.

- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered.  2 helper
functions where added for pointer manipulation (drm_minor_get_slot()
and drm_minor_set_minor()) along with checks for valid pointers for
struct drm_device variables throughout this module.

- drivers/gpu/drm/drm_edid.c
The call to drm_cvt_mode() in function drm_mode_std() for the
HDTV hack resulted in the possibility of accessing a NULL pointer
if drm_mode_std() returned NULL.  A check for this added right after
the call to drm_cvt_mode() in this particular area of code.

- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from calls to
drm_crtc_from_index().  There is a possibility, however minute, that
crtc->index may not be found when trying to find the struct crtc
from it's assigned index given in drm_crtc_init_with_planes().
3 return checks for NULL where added.

Signed-off-by: Joe Moriarty 
Reviewed-by: Steven Sistare 
---
  drivers/gpu/drm/drm_dp_mst_topology.c |  8 +---
  drivers/gpu/drm/drm_drv.c | 38 +++
  drivers/gpu/drm/drm_edid.c|  2 ++
  drivers/gpu/drm/drm_vblank.c  |  6 +++---
  4 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70dcfa58d3c2..ec503d416062 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1082,10 +1082,12 @@ static bool drm_dp_port_setup_pdt(struct 
drm_dp_mst_port *port)
lct = drm_dp_calculate_rad(port, rad);
  
  		port->mstb = drm_dp_add_mst_branch_device(lct, rad);

-   port->mstb->mgr = port->mgr;
-   port->mstb->port_parent = port;
+   if (port->mstb) {
+   port->mstb->mgr = port->mgr;
+   port->mstb->port_parent = port;
  
-		send_link = true;

+   send_link = true;
+   }
break;
}
return send_link;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9acc1e157813..938eee77f014 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -99,10 +99,36 @@ static struct drm_minor **drm_minor_get_slot(struct 
drm_device *dev,
case DRM_MINOR_CONTROL:
return >control;
default:
+   DRM_ERROR("Error in %s: Invalid dev, type = %d\n",
+ __func__, type);
return NULL;
}
  }
  
+static inline int drm_minor_set_minor(struct drm_device *dev,

+ unsigned int type,
+ struct drm_minor *minor)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+   int retval = -ENODEV;
+
+   if (slot) {
+   retval = 0;
+   *slot = minor;
+   }
+   return retval;
+}
+
+static inline struct drm_minor *drm_minor_get_minor(struct drm_device *dev,
+   unsigned int type)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+
+   if (slot)
+   return *slot;
+   return NULL;
+}
+
  static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
  {
struct drm_minor *minor;
@@ -137,8 +163,9 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned 
int type)
goto err_index;
}
  
-	*drm_minor_get_slot(dev, type) = minor;

-   return 0;
+   r = drm_minor_set_minor(dev, type, minor);
+   if (r == 0)
+   return r;
  
  err_index:

spin_lock_irqsave(_minor_lock, flags);
@@ -155,6 +182,9 @@ static void drm_minor_free(struct drm_device *dev, unsigned 
int type)
unsigned long flags;
  
  	slot = drm_minor_get_slot(dev, type);

+   if (!slot)
+   return
+
minor = *slot;
if (!minor)
return;
@@ -177,7 +207,7 @@ static int drm_minor_register(struct drm_device *dev, 
unsigned int type)
  
  	DRM_DEBUG("\n");
  
-	minor = *drm_minor_get_slot(dev, type);

+   minor = drm_minor_get_slot(dev, type);
if (!minor)
return 0;
  
@@ -209,7 +239,7 @@ static void 

Re: nouveau 30bpp / deep color status

[Ville Syrjälä]

On Thu, Feb 08, 2018 at 07:34:11PM -0500, Ilia Mirkin wrote:
> On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä
>  wrote:
> > On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
> >> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> >> > In case anyone's curious about 30bpp framebuffer support, here's the
> >> > current status:
> >> >
> >> > Kernel:
> >> >
> >> > Ben and I have switched the code to using a 256-based LUT for Kepler+,
> >> > and I've also written a patch to cause the addfb ioctl to use the
> >> > proper format. You can pick this up at:
> >> >
> >> > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
> >> > https://patchwork.freedesktop.org/patch/202322/
> >> >
> >> > With these two, you should be able to use "X -depth 30" again on any
> >> > G80+ GPU to bring up a screen (as you could in kernel 4.9 and
> >> > earlier). However this still has some deficiencies, some of which I've
> >> > addressed:
> >> >
> >> > xf86-video-nouveau:
> >> >
> >> > DRI3 was broken, and Xv was broken. Patches available at:
> >> >
> >> > https://github.com/imirkin/xf86-video-nouveau/commits/master
> >> >
> >> > mesa:
> >> >
> >> > The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
> >> > nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
> >> > Mesa was only enabled for XRGB, so I've piped XBGR through all the
> >> > same places:
> >> >
> >> > https://github.com/imirkin/mesa/commits/30bpp
> >> >
> >> > libdrm:
> >> >
> >> > For testing, I added a modetest gradient pattern split horizontally.
> >> > Top half is 10bpc, bottom half is 8bpc. This is useful for seeing
> >> > whether you're really getting 10bpc, or if things are getting
> >> > truncated along the way. Definitely hacky, but ... wasn't intending on
> >> > upstreaming it anyways:
> >> >
> >> > https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441
> >> >
> >> > -
> >> >
> >> > Results with the patches (tested on a GK208B and a "deep color" TV over 
> >> > HDMI):
> >> >  - modetest with a 10bpc gradient shows up smoother than an 8bpc
> >> > gradient. However it's still dithered to 8bpc, not "real" 10bpc.
> >> >  - things generally work in X -- dri2 and dri3, xv, and obviously
> >> > regular X rendering / acceleration
> >> >  - lots of X software can't handle 30bpp modes (mplayer hates it for
> >> > xv and x11 rendering, aterm bails on shading the root pixmap, probably
> >> > others)
> >> >
> >> > I'm also told that with DP, it should actually send the higher-bpc
> >> > data over the wire. With HDMI, we're still stuck at 24bpp for now
> >> > (although the hardware can do 36bpp as well). This is why my gradient
> >> > result above was still dithered.
> >> >
> >> > Things to do - mostly nouveau specific, but probably some general
> >> > infra needed too:
> >> >  - Figure out how to properly expose the 1024-sized LUT
> >>
> >> We have the properties in the kernel. Not sure if x11 could expose it
> >> to clients somehow, or would we just have to interpolate the missing
> >> bits in the ddx?
> >
> > Oh, and I think we're going to have to come up with a fancier uapi for
> > this stuff because in the future the input points may not be evenly
> > spaced (for HDR stuff). Also the hardware may provide various different
> > modes for the gamma LUTs with different tradeoffs. So we may even want
> > to somehow try to enumerate the different modes and let userspace pick
> > the mode that best suits its needs.
> 
> That's already the case -- NVIDIA actually has like 5 different LUT
> modes on recent chips.
> 
> https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L25
> 
> 
> 
> 
> 
> 

Yeah, we also have several LUT modes on intel hw. IIRC ~4 on current hw.
The main questions are whether all of them are actually useful for userspace,
and how we can expose the relevant details to userspace in a succinct and hw
independent way.

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Christian König]

Am 09.02.2018 um 15:02 schrieb Tom St Denis:

On 09/02/18 08:56 AM, Christian König wrote:

Am 09.02.2018 um 14:32 schrieb Tom St Denis:

On 02/02/18 02:09 PM, Christian König wrote:

[SNIP]
+    if (p->mapping != adev->mman.bdev.dev_mapping)
+    return -EPERM;


This comparison fails for both IOMMU and non-IOMMU devices in my 
carrizo+polaris10 box.


The address being read from is what the VM decodes to (checked with 
strace).


Have you applied the whole series? That patches before this one are 
necessary to initialize p->mapping when there isn't any userspace 
mapping for the page.



Yes, I have the entire 5 pages applied to a temp branch based on the 
tip of drm-next


$ git log --oneline HEAD~10..
405bc1dc85db (HEAD -> iomem) wip
a06d7a6f29e4 drm/amdgpu: replace iova debugfs file with iomem
d324c21f2c5e drm/ttm: set page mapping during allocation
9f440ee91c58 drm/radeon: remove extra TT unpopulated check
f55d505b0387 drm/amdgpu: remove extra TT unpopulated check
37d705119ea8 drm/ttm: add ttm_tt_populate wrapper
53af6035d04b (origin/amd-staging-drm-next, amd-staging-drm-next) 
drm/radeon: only enable swiotlb path when need v2


(the wip is me adding printks to see which error path is taken).

I don't see an init call for adev->mman.bdev.man[TTM_PL_SYSTEM] 
anywhere.  Maybe that's related?


No, there is simply no need to initialize the system domain. What are 
the values of p->mapping and adev->mman.bdev.dev_mapping when they don't 
match? Maybe we are allocating memory before initializing 
adev->mman.bdev.dev_mapping.


Or do you have more than one GPU in the system? E.g. APU+dGPU? Could it 
be that you read through the wrong device?


Christian.



Tom


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

[GIT PULL] fbdev fix for v4.16

[Bartlomiej Zolnierkiewicz]

Hi Linus,

Please pull fbdev fix for v4.16 (just a single fix to make
omapfb driver build again).

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


The following changes since commit f1517df8701c9f12dae9ce7f43a5d300a6917619:

  Merge tag 'nfsd-4.16' of git://linux-nfs.org/~bfields/linux (2018-02-08 
15:18:32 -0800)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.16-fix

for you to fetch changes up to b9058afcd6c725a8d293bb0a1b30bad68113235e:

  video: omapfb: fix missing #includes (2018-02-09 14:43:49 +0100)


fbdev fix for v4.16:

- fix building of the omapfb driver (Tomi Valkeinen)


Tomi Valkeinen (1):
  video: omapfb: fix missing #includes

 drivers/video/fbdev/omap2/omapfb/dss/dss.c  | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 2 ++
 drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c  | 2 ++
 4 files changed, 6 insertions(+)

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 39fe724..f0cac9e 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c 
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
index eee09b4b..11dbc05 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 
 #include "dss.h"
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c 
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
index eac3665..bc591fc 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c 
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c
index 705373e..4af6ba2 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 
 #include "dss.h"

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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Tom St Denis]

On 09/02/18 08:56 AM, Christian König wrote:

Am 09.02.2018 um 14:32 schrieb Tom St Denis:

On 02/02/18 02:09 PM, Christian König wrote:

[SNIP]
+    if (p->mapping != adev->mman.bdev.dev_mapping)
+    return -EPERM;


This comparison fails for both IOMMU and non-IOMMU devices in my 
carrizo+polaris10 box.


The address being read from is what the VM decodes to (checked with 
strace).


Have you applied the whole series? That patches before this one are 
necessary to initialize p->mapping when there isn't any userspace 
mapping for the page.



Yes, I have the entire 5 pages applied to a temp branch based on the tip 
of drm-next


$ git log --oneline HEAD~10..
405bc1dc85db (HEAD -> iomem) wip
a06d7a6f29e4 drm/amdgpu: replace iova debugfs file with iomem
d324c21f2c5e drm/ttm: set page mapping during allocation
9f440ee91c58 drm/radeon: remove extra TT unpopulated check
f55d505b0387 drm/amdgpu: remove extra TT unpopulated check
37d705119ea8 drm/ttm: add ttm_tt_populate wrapper
53af6035d04b (origin/amd-staging-drm-next, amd-staging-drm-next) 
drm/radeon: only enable swiotlb path when need v2


(the wip is me adding printks to see which error path is taken).

I don't see an init call for adev->mman.bdev.man[TTM_PL_SYSTEM] 
anywhere.  Maybe that's related?


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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #25 from Christian König  ---
(In reply to Andreas Kilgus from comment #24)
> (In reply to Christian König from comment #23)
> > Take a look at /proc/pagetypeinfo. There must at least be pages at order 9
> > or higher for an 2MB swiotlb allocation to succeed.
> 
> OK, I had a look and if I got it right: memory fragmentation lets the malloc
> fail. I still would not call that to "run out of memory" - there is
> enough memory available, its current layout is just not in the desired
> shape. ;)

Yeah, correct.

One interesting point is that this only seems to happen when DC is enabled, so
that points to a possible memory leak there.

Would be interesting to monitor amdgpu_gem_info if there are an increasing
number of buffers around when DC is enabled.

-- 
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 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Christian König]

Am 09.02.2018 um 14:32 schrieb Tom St Denis:

On 02/02/18 02:09 PM, Christian König wrote:

[SNIP]
+    if (p->mapping != adev->mman.bdev.dev_mapping)
+    return -EPERM;


This comparison fails for both IOMMU and non-IOMMU devices in my 
carrizo+polaris10 box.


The address being read from is what the VM decodes to (checked with 
strace).


Have you applied the whole series? That patches before this one are 
necessary to initialize p->mapping when there isn't any userspace 
mapping for the page.


Christian.



Tom


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

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Tom St Denis]

On 02/02/18 02:09 PM, Christian König wrote:

This allows access to pages allocated through the driver with optional
IOMMU mapping.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 57 -
  1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 648c449aaa79..795ceaeb82d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,51 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
  
  #endif
  
-static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,

-  size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+size_t size, loff_t *pos)
  {
struct amdgpu_device *adev = file_inode(f)->i_private;
-   int r;
-   uint64_t phys;
struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
  
-	// always return 8 bytes

-   if (size != 8)
-   return -EINVAL;
+   dom = iommu_get_domain_for_dev(adev->dev);
  
-	// only accept page addresses

-   if (*pos & 0xFFF)
-   return -EINVAL;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
  
-	dom = iommu_get_domain_for_dev(adev->dev);

-   if (dom)
-   phys = iommu_iova_to_phys(dom, *pos);
-   else
-   phys = *pos;
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
  
-	r = copy_to_user(buf, , 8);

-   if (r)
-   return -EFAULT;
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;


This comparison fails for both IOMMU and non-IOMMU devices in my 
carrizo+polaris10 box.


The address being read from is what the VM decodes to (checked with strace).

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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #24 from Andreas Kilgus  ---
(In reply to Christian König from comment #23)
> Take a look at /proc/pagetypeinfo. There must at least be pages at order 9
> or higher for an 2MB swiotlb allocation to succeed.

OK, I had a look and if I got it right: memory fragmentation lets the malloc
fail. I still would not call that to "run out of memory" - there is
enough memory available, its current layout is just not in the desired
shape. ;)

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #23 from Christian König  ---
(In reply to Andreas Kilgus from comment #22)
> I am getting these messsages on my machine right now, too.
> 
>  total   used   free sharedbuffers cached
> Mem:  16386788   151572521229536 761064  888522660664
> -/+ buffers/cache:   124077363979052
> Swap: 25165820156   25165664
> 
> There is enough RAM left to allocate a 2 MiB block.

No there isn't. 1229536 pages free means that there are 1229536 4k pages
available that doesn't tell us anything about 2MB pages, nor if those are
usable for swiotlb.

Take a look at /proc/pagetypeinfo. There must at least be pages at order 9 or
higher for an 2MB swiotlb allocation to succeed.

An alternative workaround is David Zhou's patch which completely avoids the
swiotlb allocator on x86.

-- 
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 3/3] drm/ttm: check if free mem space is under the lower limit

[Christian König]

Am 09.02.2018 um 11:00 schrieb Roger He:

the free mem space and the lower limit both include two parts:
system memory and swap space.

For the OOM triggered by TTM, that is the case as below:
first swap space is full of swapped out pages and soon
system memory also is filled up with ttm pages. and then
any memory allocation request will run into OOM.

to cover two cases:
a. if no swap disk at all or free swap space is under swap mem
limit but available system mem is bigger than sys mem limit,
allow TTM allocation;

b. if the available system mem is less than sys mem limit but
free swap space is bigger than swap mem limit, allow TTM
allocation.

v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
 TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC

Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_memory.c | 35 
  drivers/gpu/drm/ttm/ttm_page_alloc.c |  4 
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  4 
  include/drm/ttm/ttm_memory.h |  5 +
  4 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..0d41a99 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define TTM_MEMORY_ALLOC_RETRIES 4
  
@@ -375,6 +376,11 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
  
  	si_meminfo();
  
+	/* lower limit of swap space and 256MB is enough */

+   glob->lower_mem_limit = 256 << 8;
+   /* lower limit of ram and keep consistent with each zone->emer_mem */
+   glob->lower_mem_limit += si.totalram >> 2;


That looks really good to me, but we need to make sure that this is 
configurable.


E.g. we need to add an attribute to ttm_mem_glob_kobj_type and implement 
the show/store callbacks.


Apart from that one more comment below.


+
ret = ttm_mem_init_kernel_zone(glob, );
if (unlikely(ret != 0))
goto out_no_zone;
@@ -469,6 +475,35 @@ void ttm_mem_global_free(struct ttm_mem_global *glob,
  }
  EXPORT_SYMBOL(ttm_mem_global_free);
  
+/*

+ * check if the available mem is under lower memory limit
+ *
+ * a. if no swap disk at all or free swap space is under swap_mem_limit
+ * but available system mem is bigger than sys_mem_limit, allow TTM
+ * allocation;
+ *
+ * b. if the available system mem is less than sys_mem_limit but free
+ * swap disk is bigger than swap_mem_limit, allow TTM allocation.
+ */
+bool
+ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
+   uint64_t num_pages, bool force_alloc)


I would pass in the whole ttm_operation_ctx here.

Regards,
Christian.


+{
+   bool ret = false;
+   int64_t available;
+
+   if (force_alloc)
+   return false;
+
+   available = get_nr_swap_pages() + si_mem_available();
+   available -= num_pages;
+   if (available < glob->lower_mem_limit)
+   ret = true;
+
+   return ret;
+}
+EXPORT_SYMBOL(ttm_check_under_lowerlimit);
+
  static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
  struct ttm_mem_zone *single_zone,
  uint64_t amount, bool reserve)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 5edcd89..bd312e6 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1100,6 +1100,10 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
if (ttm->state != tt_unpopulated)
return 0;
  
+	if (ttm_check_under_lowerlimit(mem_glob, ttm->num_pages,

+  ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC))
+   return -ENOMEM;
+
ret = ttm_get_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
ttm->caching_state);
if (unlikely(ret != 0)) {
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index b122f6e..fc32096 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -940,6 +940,10 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
if (ttm->state != tt_unpopulated)
return 0;
  
+	if (ttm_check_under_lowerlimit(mem_glob, num_pages,

+  ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC))
+   return -ENOMEM;
+
INIT_LIST_HEAD(_dma->pages_list);
i = 0;
  
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h

index 8936285..5ada921 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -49,6 +49,8 @@
   * @work: The workqueue callback for the shrink queue.
   * @lock: Lock to 

Re: [PATCH] gpu/drm/udl: Replace struct_mutex with driver private lock

[Chris Wilson]

Quoting Shreeya Patel (2018-02-09 12:10:56)
> dev->struct_mutex is the Big DRM Lock and the only bit where
> it’s mandatory is serializing GEM buffer object destruction.
> Which unfortunately means drivers have to keep track of that
> lock and either call unreference or unreference_locked
> depending upon context. Core GEM doesn’t have a need for
> struct_mutex any more since kernel 4.8.
> 
> For drivers that need struct_mutex it should be replaced by a driver
> private lock.

In that regard, dev->struct_mutex is already a driver private lock. The
impetus is to reduce a big lock into lots of little locks where
contention deems prudent.

> Signed-off-by: Shreeya Patel 
> ---
>  drivers/gpu/drm/udl/udl_dmabuf.c | 5 +++--
>  drivers/gpu/drm/udl/udl_drv.h| 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c 
> b/drivers/gpu/drm/udl/udl_dmabuf.c
> index 2867ed1..120d2d9 100644
> --- a/drivers/gpu/drm/udl/udl_dmabuf.c
> +++ b/drivers/gpu/drm/udl/udl_dmabuf.c
> @@ -76,6 +76,7 @@ static struct sg_table *udl_map_dma_buf(struct 
> dma_buf_attachment *attach,
> struct udl_drm_dmabuf_attachment *udl_attach = attach->priv;
> struct udl_gem_object *obj = to_udl_bo(attach->dmabuf->priv);
> struct drm_device *dev = obj->base.dev;
> +   struct udl_device *udl = dev->dev_private;
> struct scatterlist *rd, *wr;
> struct sg_table *sgt = NULL;
> unsigned int i;
> @@ -112,7 +113,7 @@ static struct sg_table *udl_map_dma_buf(struct 
> dma_buf_attachment *attach,
> return ERR_PTR(-ENOMEM);
> }
>  
> -   mutex_lock(>struct_mutex);
> +   mutex_lock(>urbs.plock);
>  
> rd = obj->sg->sgl;
> wr = sgt->sgl;
> @@ -137,7 +138,7 @@ static struct sg_table *udl_map_dma_buf(struct 
> dma_buf_attachment *attach,
> attach->priv = udl_attach;
>  
>  err_unlock:
> -   mutex_unlock(>struct_mutex);
> +   mutex_unlock(>urbs.plock);
> return sgt;
>  }
>  
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 2a75ab8..24cca17 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -39,6 +39,7 @@ struct urb_node {
>  
>  struct urb_list {
> struct list_head list;
> +   struct mutex plock;
> spinlock_t lock;
> struct semaphore limit_sem;
> int available;

This hasn't seen much testing as it lacks a mutex_init, and one would
wish for a description of what it is guarding.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/1] drm: Multiple Null pointer dereference [null-pointer-deref] (CWE 476) problems:

[Jani Nikula]

On Thu, 08 Feb 2018, Joe Moriarty  wrote:
> The Parfait (version 2.1.0) static code analysis tool found multiple NULL
> pointer derefernce problems.

Thanks for the patch. Multiple problems requires multiple patches to fix
them, one patch per problem. Please split up the patch.

Thanks,
Jani.

>
> - drivers/gpu/drm/drm_dp_mst_topology.c
> The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
> could result in a NULL pointer being returned to port->mstb due to a
> failure to allocate memory for port->mstb.
>
> - drivers/gpu/drm/drm_drv.c
> Any calls to drm_minor_get_slot() could result in the return of a NULL
> pointer when an invalid DRM device type is encountered.  2 helper
> functions where added for pointer manipulation (drm_minor_get_slot()
> and drm_minor_set_minor()) along with checks for valid pointers for
> struct drm_device variables throughout this module.
>
> - drivers/gpu/drm/drm_edid.c
> The call to drm_cvt_mode() in function drm_mode_std() for the
> HDTV hack resulted in the possibility of accessing a NULL pointer
> if drm_mode_std() returned NULL.  A check for this added right after
> the call to drm_cvt_mode() in this particular area of code.
>
> - drivers/gpu/drm/drm_vblank.c
> Null pointer checks were added to return values from calls to
> drm_crtc_from_index().  There is a possibility, however minute, that
> crtc->index may not be found when trying to find the struct crtc
> from it's assigned index given in drm_crtc_init_with_planes().
> 3 return checks for NULL where added.
>
> Signed-off-by: Joe Moriarty 
> Reviewed-by: Steven Sistare 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c |  8 +---
>  drivers/gpu/drm/drm_drv.c | 38 
> +++
>  drivers/gpu/drm/drm_edid.c|  2 ++
>  drivers/gpu/drm/drm_vblank.c  |  6 +++---
>  4 files changed, 44 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa58d3c2..ec503d416062 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1082,10 +1082,12 @@ static bool drm_dp_port_setup_pdt(struct 
> drm_dp_mst_port *port)
>   lct = drm_dp_calculate_rad(port, rad);
>  
>   port->mstb = drm_dp_add_mst_branch_device(lct, rad);
> - port->mstb->mgr = port->mgr;
> - port->mstb->port_parent = port;
> + if (port->mstb) {
> + port->mstb->mgr = port->mgr;
> + port->mstb->port_parent = port;
>  
> - send_link = true;
> + send_link = true;
> + }
>   break;
>   }
>   return send_link;
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 9acc1e157813..938eee77f014 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -99,10 +99,36 @@ static struct drm_minor **drm_minor_get_slot(struct 
> drm_device *dev,
>   case DRM_MINOR_CONTROL:
>   return >control;
>   default:
> + DRM_ERROR("Error in %s: Invalid dev, type = %d\n",
> +   __func__, type);
>   return NULL;
>   }
>  }
>  
> +static inline int drm_minor_set_minor(struct drm_device *dev,
> +   unsigned int type,
> +   struct drm_minor *minor)
> +{
> + struct drm_minor **slot = drm_minor_get_slot(dev, type);
> + int retval = -ENODEV;
> +
> + if (slot) {
> + retval = 0;
> + *slot = minor;
> + }
> + return retval;
> +}
> +
> +static inline struct drm_minor *drm_minor_get_minor(struct drm_device *dev,
> + unsigned int type)
> +{
> + struct drm_minor **slot = drm_minor_get_slot(dev, type);
> +
> + if (slot)
> + return *slot;
> + return NULL;
> +}
> +
>  static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
>  {
>   struct drm_minor *minor;
> @@ -137,8 +163,9 @@ static int drm_minor_alloc(struct drm_device *dev, 
> unsigned int type)
>   goto err_index;
>   }
>  
> - *drm_minor_get_slot(dev, type) = minor;
> - return 0;
> + r = drm_minor_set_minor(dev, type, minor);
> + if (r == 0)
> + return r;
>  
>  err_index:
>   spin_lock_irqsave(_minor_lock, flags);
> @@ -155,6 +182,9 @@ static void drm_minor_free(struct drm_device *dev, 
> unsigned int type)
>   unsigned long flags;
>  
>   slot = drm_minor_get_slot(dev, type);
> + if (!slot)
> + return
> +
>   minor = *slot;
>   if (!minor)
>   return;
> @@ -177,7 +207,7 @@ static int drm_minor_register(struct drm_device *dev, 
> unsigned int type)
>  
>   DRM_DEBUG("\n");
>  
> - minor = *drm_minor_get_slot(dev, type);
> 

Re: [PATCH 1/3] drm/ttm: add bit flag TTM_OPT_FLAG_FORCE_ALLOC

[Christian König]

Am 09.02.2018 um 11:00 schrieb Roger He:

set TTM_OPT_FLAG_FORCE_ALLOC when we are servicing for page
fault routine.

for ttm_mem_global_reserve if in page fault routine, allow the gtt
pages reservation always. because page fault routing already grabbed
system memory and the allowance of this exception is harmless.
Otherwise, it will trigger OOM killer.

will be used later.

v2: set the FORCE_ALLOC always
v3: minor refine

Signed-off-by: Roger He 


Patches #1 and #2 are Reviewed-by: Christian König 
.


Regards,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
  include/drm/ttm/ttm_bo_api.h| 4 +++-
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 716e724..7ad8d70 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -226,7 +226,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
} else {
struct ttm_operation_ctx ctx = {
.interruptible = false,
-   .no_wait_gpu = false
+   .no_wait_gpu = false,
+   .flags = TTM_OPT_FLAG_FORCE_ALLOC
+
};
  
  		ttm = bo->ttm;

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 872ff6c..2142639 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -278,7 +278,9 @@ struct ttm_operation_ctx {
  };
  
  /* Allow eviction of reserved BOs */

-#define TTM_OPT_FLAG_ALLOW_RES_EVICT   0x1
+#define TTM_OPT_FLAG_ALLOW_RES_EVICT   0x1
+/* when serving page fault or suspend, allow alloc anyway */
+#define TTM_OPT_FLAG_FORCE_ALLOC   0x2
  
  /**

   * ttm_bo_reference - reference a struct ttm_buffer_object


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

Re: [PATCH libdrm] meson: include headers in root directory in ext_libdrm

[Eric Anholt]

Dylan Baker  writes:

> Which is used in wraps.

Reviewed-by: Eric Anholt 


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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Tomeu Vizoso]

Hi Gerd and Stefan,

can we reach agreement on whether vsock should be involved in this?

Thanks,

Tomeu

On 02/07/2018 10:49 AM, Tomeu Vizoso wrote:

On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:

   Hi,


Hmm?  I'm assuming the wayland client (in the guest) talks to the
wayland proxy, using the wayland protocol, like it would talk to a
wayland display server.  Buffers must be passed from client to
server/proxy somehow, probably using fd passing, so where is the
problem?

Or did I misunderstand the role of the proxy?


Hi Gerd,

it's starting to look to me that we're talking a bit past the other, so I
have pasted below a few words describing my current plan regarding the 
3 key

scenarios that I'm addressing.


You are describing the details, but I'm missing the big picture ...

So, virtualization aside, how do buffers work in wayland?  As far I know
it goes like this:

   (a) software rendering: client allocates shared memory buffer, renders
   into it, then passes a file handle for that shmem block together
   with some meta data (size, format, ...) to the wayland server.

   (b) gpu rendering: client opens a render node, allocates a buffer,
   asks the cpu to renders into it, exports the buffer as dma-buf
   (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
   (again including meta data of course).

Is that correct?


Both are correct descriptions of typical behaviors. But it isn't spec'ed 
anywhere who has to do the buffer allocation.


In practical terms, the buffer allocation happens in either the 2D GUI 
toolkit (gtk+, for example), or the EGL implementation. Someone using 
this in a real product would most probably be interested in avoiding any 
extra copies and make sure that both allocate buffers via virtio-gpu, for 
example.


Depending on the use case, they could be also interested in supporting 
unmodified clients with an extra copy per buffer presentation.


That's to say that if we cannot come up with a zero-copy solution for 
unmodified clients, we should at least support zero-copy for cooperative 
clients.



Now, with virtualization added to the mix it becomes a bit more
complicated.  Client and server are unmodified.  The client talks to the
guest proxy (wayland protocol).  The guest proxy talks to the host proxy
(protocol to be defined). The host proxy talks to the server (wayland
protocol).

Buffers must be managed along the way, and we want avoid copying around
the buffers.  The host proxy could be implemented directly in qemu, or
as separate process which cooperates with qemu for buffer management.

Fine so far?


Yep.

I really think that whatever we come up with needs to support 3D 
clients as

well.


Lets start with 3d clients, I think these are easier.  They simply use
virtio-gpu for 3d rendering as usual.  When they are done the rendered
buffer already lives in a host drm buffer (because virgl runs the actual
rendering on the host gpu).  So the client passes the dma-buf to the
guest proxy, the guest proxy imports it to look up the resource-id,
passes the resource-id to the host proxy, the host proxy looks up the
drm buffer and exports it as dma-buf, then passes it to the server.
Done, without any extra data copies.


Yep.


Creation of shareable buffer by guest
-

1. Client requests virtio driver to create a buffer suitable for sharing
with host (DRM_VIRTGPU_RESOURCE_CREATE)


client or guest proxy?


As per the above, the GUI toolkit could have been modified so the client 
directly creates a shareable buffer, and renders directly to it without 
any extra copies.


If clients cannot be modified, then it's the guest proxy what has to 
create the shareable buffer and keep it in sync with the client's 
non-shareable buffer at the right times, by intercepting 
wl_surface.commit messages and copying buffer contents.



4. QEMU maps that buffer to the guest's address space
(KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver


That part is problematic.  The host can't simply allocate something in
the physical address space, because most physical address space
management is done by the guest.  All pci bars are mapped by the guest
firmware for example (or by the guest OS in case of hotplug).


How can KVM_SET_USER_MEMORY_REGION ever be safely used then? I would have 
expected that callers of that ioctl have enough knowledge to be able to 
choose a physical address that won't conflict with the guest's kernel.


I see that the ivshmem device in QEMU registers the memory region in BAR 
2 of a PCI device instead. Would that be better in your opinion?



4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
resource, sends data + FDs to the compositor with SCM_RIGHTS


BTW: Is there a 1:1 relationship between buffers and shmem blocks?  Or
does the wayland protocol allow for offsets in buffer meta data, so you
can place multiple buffers in a single shmem block?


The 

[Bug 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

--- Comment #5 from VF  ---
And my MoBo is not the same : A88XM-E35

-- 
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 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

--- Comment #4 from VF  ---
radeon.dpm=0 was the only workaround for me (or nomodeset)

-- 
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 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Chen-Yu Tsai]

On Fri, Feb 9, 2018 at 4:40 AM, Maxime Ripard  wrote:
> On Wed, Feb 07, 2018 at 01:49:59PM +0100, Giulio Benetti wrote:
>> Hi,
>>
>> Il 07/02/2018 11:39, Maxime Ripard ha scritto:
>> > On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
>> > Also, how was it tested? This seems quite weird that we haven't caught
>> > that one sooner, and I'm a bit worried about the possible regressions
>> > here.
>> 
>>  It sounds really strange to me too,
>>  because everybody under uboot use "sync:3"(HIGH).
>>  I will retry to measure,
>>  unfortunately at home I don't have a scope,
>>  but I think I'm going to have one soon, because of this. :)
>> >>>
>> >>> Here I am with scope captures and tcon0 registers dump:
>> >>> tcon0_regs => https://pasteboard.co/H4r8Zcs.png
>> >>> dclk_d0 => https://pasteboard.co/H4r8QRe.png
>> >>> dclk_de => https://pasteboard.co/H4r8zh4R.png
>> >>> dclk_vsnc => https://pasteboard.co/H4r8Hye.png
>> >>>
>> >>> As you can see circled in reg on registers,
>> >>> TCON0_IO_POL_REG = 0x.
>> >>> But on all the waveforms you can see:
>> >>> - dclk_d0: clock phase is 0, but it starts with falling edge, otherwise
>> >>> the rising front overlaps dclk rising edge(not good), so to me this is
>> >>> falling, then I mean it Negative.
>> >>> - dclk_de: de pulse is clearly negative, even if register is 0 and its'
>> >>> polarity bit is 0.
>> >>> - dclk_vsnc: same as dclk_de
>> >>> - dclk_hsync: I didn't take scope screenshot but I can assure you it's
>> >>> negative.
>> >>>
>> >>> You can also check all the other registers about TCON0.
>> >>>
>> >>> Now I proceed testing it on A33, maybe the peripheral is slightly
>> >>> different between Axx SoCs, if I find it that way,
>> >>> it should be only a check about SoC or peripheral ID,
>> >>> and treat polarity as it should be done.
>> >>
>> >> Here I am with A33 waveforms:
>> >> tcon0_regs => https://pasteboard.co/H4rXfN0M.png
>> >> dclk_d0 => https://pasteboard.co/H4rVXwy.png
>> >> dclk_de => https://pasteboard.co/H4rWDt8.png
>> >> dclk_vsnc => https://pasteboard.co/H4rWRACu.png
>> >> dclk_hsync => https://pasteboard.co/H4rWK6I.png
>> >>
>> >> It behaves the same way as A20, so as I mean IO polarity,
>> >> all signals(except D0-D23), are inverted.
>> >> For A33 I've used A33-OLinuXino.
>> >> For A20 our LiNova1.
>> >
>> > If you have an A33 handy, you probably want to read that mail:
>> > https://lists.freedesktop.org/archives/dri-devel/2017-July/147951.html
>> >
>> > Especially the 90-phase part.
>>
>> Here is a summary of different SoCs TCON:
>> With DCLK_Sel:
>> 0x0 => normal phase
>> 0x1 => 1/3 phase
>> 0x2 => 2/3 phase
>>
>> A10, A20
>
> Have you tested the option 4 and 5 there too?
>
>> With DCLK_Sel:
>> 0x0 => normal phase
>> 0x1 => 1/3 phase
>> 0x2 => 2/3 phase
>> 0x5 => DCLK/2 phase 0
>> 0x4 => DCLK/2 phase 90
>>
>> A31, A31s, A33, A80, A83T
>
> Ok, great, so Chen-Yu was right :)
>
> I guess the option 5 (DCLK/2 phase 0) is still to early, just like
> you've shown in the previous captures?
>
>> Also I've found that TCON1 has not this feature,
>> nor first, nor second case(at least is not described on user manuals).
>
> At lot of things are not described, unfortunately...

On some SoCs, TCON1 does not have channel 0 (LCD), so it does
not have a configurable dot clock, so no settings.

ChenYu

>> So I could handle differently according to SoC.
>> Unfortunately there is not TCON register keeping IP version,
>> so the only way I see is to create a long if-or statement to understand
>> which kind of TCON we're using.
>
> You can base that on the compatible, and add a field in the
> sun4i_tcon_quirks structure, that will avoid the if statements you
> mentionned.
>
>> But what sounds not the best to me, is that DCLK is divided by 2 if
>> using phase 90. So we need to reconsider also bitclock driver according
>> to this.
>> I don't know if it make sense.
>>
>> IMHO, I would keep only:
>> - As normal => "0x1 => 1/3 phase"
>
> So that would mean sampling at raising edge on this one??
>
>> - As inverted => "0x0 => normal phase"
>
> And falling edge?
>
> If so, and if remember the captures properly, the sampling would occur
> right before the rise, and not really around the fall.
>
> Would 2/3 be better here?
>
>> According to scope captures above on both A20 and A33.
>> Unfortunately I don't have other boards for the other SoCs to take captures.
>>
>> What do you think?
>
> I guess we can make that part applicable to all SoCs, we haven't seen
> any significant differences on those part.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> http://bootlin.com
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
___
dri-devel mailing list

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #22 from Andreas Kilgus  ---
(In reply to Christian König from comment #21)
> (In reply to Stratos Zolotas from comment #20)
> > Maybe it is a coincidence, for sure I'm not running out of memory when it is
> > happening and started with kernel 4.15 and (or) Mesa 18.0 without any change
> > on Virtualbox side. I'll wait for the fix to see what happens...
> 
> Well the message means that we ran out of memory to allocate a 2MB block and
> instead use many small 4K blocks.

I am getting these messsages on my machine right now, too.

 total   used   free sharedbuffers cached
Mem:  16386788   151572521229536 761064  888522660664
-/+ buffers/cache:   124077363979052
Swap: 25165820156   25165664

There is enough RAM left to allocate a 2 MiB block.

-- 
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: [2/9] phy: add Rockchip Innosilicon hdmi phy

[Heiko Stuebner]

Am Freitag, 9. Februar 2018, 11:06:49 CET schrieb Andrzej Hajda:
> On 09.02.2018 10:24, Heiko Stuebner wrote:
> > Hi Martin,
> >
> > Am Montag, 5. Februar 2018, 22:32:08 CET schrieb Martin Cerveny:
> >> On Mon, 5 Feb 2018, Heiko Stuebner wrote:
> >>> From: Zheng Yang 
> >>>
> >>> Add a driver for the Innosilicon hdmi phy used on rk3228/rk3229
> >>> and rk3328 socs from Rockchip.
> >>>
> >>> Signed-off-by: Zheng Yang 
> >>> Signed-off-by: Heiko Stuebner 
> >>> ---
> >>> +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> >>> +static u32 inno_hdmi_phy_get_tmdsclk(struct inno_hdmi_phy *inno, int 
> >>> rate)
> >>> +{
> >>> + int bus_width = phy_get_bus_width(inno->phy);
> >>> + u32 tmdsclk;
> >>> +
> >>> + switch (bus_width) {
> >>> + case 4:
> >>> + tmdsclk = rate / 2;
> >>> + break;
> >>> + case 5:
> >>> + tmdsclk = rate * 5 / 8;
> >>> + break;
> >>> + case 6:
> >>> + tmdsclk = rate * 3 / 4;
> >>> + break;
> >>> + case 10:
> >>> + tmdsclk = rate * 5 / 4;
> >>> + break;
> >>> + case 12:
> >>> + tmdsclk = rate * 3 / 2;
> >>> + break;
> >>> + case 16:
> >>> + tmdsclk = rate * 2;
> >>> + break;
> >>> + default:
> >>> + tmdsclk = rate;
> >>> + }
> >>> +
> >>> + return tmdsclk;
> >>> +}
> >> Please corrects integer overflow 
> >> like 
> >> https://github.com/mcerveny/rockchip-linux/commit/b4bc703f2dca4e5115b22155920d2277671a9f00
> > thanks for finding that possible issue. I've adapted the phy driver
> > in a similar way (using u64 though) and will include that change in the
> > next version.
> 
> Btw, wouldn't be simpler to just use:
> switch (bus_width) {
> case 4:
> case 5:
> case 6:
> case 10:
> case 12:
> case 16:
> return (u64)rate * bus_width / 8;
> default:
> return rate;
> }

you're a genius ;-) .
I must be looking at this code for way to long to not see this relation.


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

Re: [2/9] phy: add Rockchip Innosilicon hdmi phy

[Andrzej Hajda]

On 09.02.2018 10:24, Heiko Stuebner wrote:
> Hi Martin,
>
> Am Montag, 5. Februar 2018, 22:32:08 CET schrieb Martin Cerveny:
>> On Mon, 5 Feb 2018, Heiko Stuebner wrote:
>>> From: Zheng Yang 
>>>
>>> Add a driver for the Innosilicon hdmi phy used on rk3228/rk3229
>>> and rk3328 socs from Rockchip.
>>>
>>> Signed-off-by: Zheng Yang 
>>> Signed-off-by: Heiko Stuebner 
>>> ---
>>> +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>>> +static u32 inno_hdmi_phy_get_tmdsclk(struct inno_hdmi_phy *inno, int rate)
>>> +{
>>> +   int bus_width = phy_get_bus_width(inno->phy);
>>> +   u32 tmdsclk;
>>> +
>>> +   switch (bus_width) {
>>> +   case 4:
>>> +   tmdsclk = rate / 2;
>>> +   break;
>>> +   case 5:
>>> +   tmdsclk = rate * 5 / 8;
>>> +   break;
>>> +   case 6:
>>> +   tmdsclk = rate * 3 / 4;
>>> +   break;
>>> +   case 10:
>>> +   tmdsclk = rate * 5 / 4;
>>> +   break;
>>> +   case 12:
>>> +   tmdsclk = rate * 3 / 2;
>>> +   break;
>>> +   case 16:
>>> +   tmdsclk = rate * 2;
>>> +   break;
>>> +   default:
>>> +   tmdsclk = rate;
>>> +   }
>>> +
>>> +   return tmdsclk;
>>> +}
>> Please corrects integer overflow 
>> like 
>> https://github.com/mcerveny/rockchip-linux/commit/b4bc703f2dca4e5115b22155920d2277671a9f00
> thanks for finding that possible issue. I've adapted the phy driver
> in a similar way (using u64 though) and will include that change in the
> next version.

Btw, wouldn't be simpler to just use:
switch (bus_width) {
case 4:
case 5:
case 6:
case 10:
case 12:
case 16:
    return (u64)rate * bus_width / 8;
default:
    return rate;
}

Regards
Andrzej

>
>
> Thanks
> Heiko
>
>
>

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

[PATCH 3/3] drm/ttm: check if free mem space is under the lower limit

[Roger He]

the free mem space and the lower limit both include two parts:
system memory and swap space.

For the OOM triggered by TTM, that is the case as below:
first swap space is full of swapped out pages and soon
system memory also is filled up with ttm pages. and then
any memory allocation request will run into OOM.

to cover two cases:
a. if no swap disk at all or free swap space is under swap mem
   limit but available system mem is bigger than sys mem limit,
   allow TTM allocation;

b. if the available system mem is less than sys mem limit but
   free swap space is bigger than swap mem limit, allow TTM
   allocation.

v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_memory.c | 35 
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  4 
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  4 
 include/drm/ttm/ttm_memory.h |  5 +
 4 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..0d41a99 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TTM_MEMORY_ALLOC_RETRIES 4
 
@@ -375,6 +376,11 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
 
si_meminfo();
 
+   /* lower limit of swap space and 256MB is enough */
+   glob->lower_mem_limit = 256 << 8;
+   /* lower limit of ram and keep consistent with each zone->emer_mem */
+   glob->lower_mem_limit += si.totalram >> 2;
+
ret = ttm_mem_init_kernel_zone(glob, );
if (unlikely(ret != 0))
goto out_no_zone;
@@ -469,6 +475,35 @@ void ttm_mem_global_free(struct ttm_mem_global *glob,
 }
 EXPORT_SYMBOL(ttm_mem_global_free);
 
+/*
+ * check if the available mem is under lower memory limit
+ *
+ * a. if no swap disk at all or free swap space is under swap_mem_limit
+ * but available system mem is bigger than sys_mem_limit, allow TTM
+ * allocation;
+ *
+ * b. if the available system mem is less than sys_mem_limit but free
+ * swap disk is bigger than swap_mem_limit, allow TTM allocation.
+ */
+bool
+ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
+   uint64_t num_pages, bool force_alloc)
+{
+   bool ret = false;
+   int64_t available;
+
+   if (force_alloc)
+   return false;
+
+   available = get_nr_swap_pages() + si_mem_available();
+   available -= num_pages;
+   if (available < glob->lower_mem_limit)
+   ret = true;
+
+   return ret;
+}
+EXPORT_SYMBOL(ttm_check_under_lowerlimit);
+
 static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
  struct ttm_mem_zone *single_zone,
  uint64_t amount, bool reserve)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 5edcd89..bd312e6 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1100,6 +1100,10 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
if (ttm->state != tt_unpopulated)
return 0;
 
+   if (ttm_check_under_lowerlimit(mem_glob, ttm->num_pages,
+  ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC))
+   return -ENOMEM;
+
ret = ttm_get_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
ttm->caching_state);
if (unlikely(ret != 0)) {
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index b122f6e..fc32096 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -940,6 +940,10 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
if (ttm->state != tt_unpopulated)
return 0;
 
+   if (ttm_check_under_lowerlimit(mem_glob, num_pages,
+  ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC))
+   return -ENOMEM;
+
INIT_LIST_HEAD(_dma->pages_list);
i = 0;
 
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 8936285..5ada921 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -49,6 +49,8 @@
  * @work: The workqueue callback for the shrink queue.
  * @lock: Lock to protect the @shrink - and the memory accounting members,
  * that is, essentially the whole structure with some exceptions.
+ * @lower_mem_limit: include lower limit of swap space and lower limit of
+ * system memory.
  * @zones: Array of pointers to accounting zones.
  * @num_zones: Number of populated entries in the @zones array.
  * @zone_kernel: Pointer 

[PATCH 2/3] drm/ttm: set TTM_OPT_FLAG_FORCE_ALLOC in ttm_bo_force_list_clean

[Roger He]

Because ttm_bo_force_list_clean() is only called on two occasions:
1. By ttm_bo_evict_mm() during suspend.
2. By ttm_bo_clean_mm() when the driver unloads.
On both cases we absolutely don't want any memory allocation failure.

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a907311..2bde372 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1344,7 +1344,11 @@ EXPORT_SYMBOL(ttm_bo_create);
 static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
   unsigned mem_type)
 {
-   struct ttm_operation_ctx ctx = { false, false };
+   struct ttm_operation_ctx ctx = {
+   .interruptible = false,
+   .no_wait_gpu = false,
+   .flags = TTM_OPT_FLAG_FORCE_ALLOC
+   };
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
struct dma_fence *fence;
-- 
2.7.4

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

[PATCH 1/3] drm/ttm: add bit flag TTM_OPT_FLAG_FORCE_ALLOC

[Roger He]

set TTM_OPT_FLAG_FORCE_ALLOC when we are servicing for page
fault routine.

for ttm_mem_global_reserve if in page fault routine, allow the gtt
pages reservation always. because page fault routing already grabbed
system memory and the allowance of this exception is harmless.
Otherwise, it will trigger OOM killer.

will be used later.

v2: set the FORCE_ALLOC always
v3: minor refine

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
 include/drm/ttm/ttm_bo_api.h| 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 716e724..7ad8d70 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -226,7 +226,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
} else {
struct ttm_operation_ctx ctx = {
.interruptible = false,
-   .no_wait_gpu = false
+   .no_wait_gpu = false,
+   .flags = TTM_OPT_FLAG_FORCE_ALLOC
+
};
 
ttm = bo->ttm;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 872ff6c..2142639 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -278,7 +278,9 @@ struct ttm_operation_ctx {
 };
 
 /* Allow eviction of reserved BOs */
-#define TTM_OPT_FLAG_ALLOW_RES_EVICT   0x1
+#define TTM_OPT_FLAG_ALLOW_RES_EVICT   0x1
+/* when serving page fault or suspend, allow alloc anyway */
+#define TTM_OPT_FLAG_FORCE_ALLOC   0x2
 
 /**
  * ttm_bo_reference - reference a struct ttm_buffer_object
-- 
2.7.4

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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #21 from Christian König  ---
(In reply to Stratos Zolotas from comment #20)
> Maybe it is a coincidence, for sure I'm not running out of memory when it is
> happening and started with kernel 4.15 and (or) Mesa 18.0 without any change
> on Virtualbox side. I'll wait for the fix to see what happens...

Well the message means that we ran out of memory to allocate a 2MB block and
instead use many small 4K blocks.

What could be is that there is a memory leak somewhere triggering both the
message and the VM faults you are seeing.

-- 
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 2/3] drm/ttm: add input parameter force_alloc for ttm_bo_force_list_clean

[He, Roger]

Ok. please ignore patch3 since I have some minor changes.
Will send out later.

Thanks
Roger(Hongbo.He)
-Original Message-
From: Koenig, Christian 
Sent: Friday, February 09, 2018 5:38 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/ttm: add input parameter force_alloc for 
ttm_bo_force_list_clean

Am 09.02.2018 um 08:30 schrieb Roger He:
> if it is  true, allocate TTM pages regardless of zone global memory 
> account limit. For example suspend, We should avoid TTM memory 
> allocate failure to lead to whole process fail.
>
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 13 -
>   1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> b/drivers/gpu/drm/ttm/ttm_bo.c index a907311..685baad 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1342,15 +1342,17 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
>   EXPORT_SYMBOL(ttm_bo_create);
>   
>   static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
> -unsigned mem_type)
> + unsigned mem_type, bool force_alloc)
>   {
> - struct ttm_operation_ctx ctx = { false, false };
> + struct ttm_operation_ctx ttm_opt_ctx = { false, false };
>   struct ttm_mem_type_manager *man = >man[mem_type];
>   struct ttm_bo_global *glob = bdev->glob;
>   struct dma_fence *fence;
>   int ret;
>   unsigned i;
>   
> + if (force_alloc)
> + ttm_opt_ctx.flags = TTM_OPT_FLAG_FORCE_ALLOC;

Just unconditional set that flag here as well. ttm_bo_force_list_clean() is 
only called on two occasions:
1. By ttm_bo_evict_mm() during suspend.
2. By ttm_bo_clean_mm() when the driver unloads.

On both cases we absolutely don't want any memory allocation failure.






Christian.

>   /*
>* Can't use standard list traversal since we're unlocking.
>*/
> @@ -1359,7 +1361,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
> *bdev,
>   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>   while (!list_empty(>lru[i])) {
>   spin_unlock(>lru_lock);
> - ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
> + ret = ttm_mem_evict_first(bdev, mem_type, NULL,
> +   _opt_ctx);
>   if (ret)
>   return ret;
>   spin_lock(>lru_lock);
> @@ -1403,7 +1406,7 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, 
> unsigned mem_type)
>   
>   ret = 0;
>   if (mem_type > 0) {
> - ret = ttm_bo_force_list_clean(bdev, mem_type);
> + ret = ttm_bo_force_list_clean(bdev, mem_type, true);
>   if (ret) {
>   pr_err("Cleanup eviction failed\n");
>   return ret;
> @@ -1433,7 +1436,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, 
> unsigned mem_type)
>   return 0;
>   }
>   
> - return ttm_bo_force_list_clean(bdev, mem_type);
> + return ttm_bo_force_list_clean(bdev, mem_type, true);
>   }
>   EXPORT_SYMBOL(ttm_bo_evict_mm);
>   

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

Re: [PATCH 2/3] drm/ttm: add input parameter force_alloc for ttm_bo_force_list_clean

[Christian König]

Am 09.02.2018 um 08:30 schrieb Roger He:

if it is  true, allocate TTM pages regardless of zone global memory
account limit. For example suspend, We should avoid TTM memory
allocate failure to lead to whole process fail.

Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a907311..685baad 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1342,15 +1342,17 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
  EXPORT_SYMBOL(ttm_bo_create);
  
  static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,

-  unsigned mem_type)
+   unsigned mem_type, bool force_alloc)
  {
-   struct ttm_operation_ctx ctx = { false, false };
+   struct ttm_operation_ctx ttm_opt_ctx = { false, false };
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
struct dma_fence *fence;
int ret;
unsigned i;
  
+	if (force_alloc)

+   ttm_opt_ctx.flags = TTM_OPT_FLAG_FORCE_ALLOC;


Just unconditional set that flag here as well. ttm_bo_force_list_clean() 
is only called on two occasions:

1. By ttm_bo_evict_mm() during suspend.
2. By ttm_bo_clean_mm() when the driver unloads.

On both cases we absolutely don't want any memory allocation failure.

Christian.


/*
 * Can't use standard list traversal since we're unlocking.
 */
@@ -1359,7 +1361,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(>lru[i])) {
spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
+   ret = ttm_mem_evict_first(bdev, mem_type, NULL,
+ _opt_ctx);
if (ret)
return ret;
spin_lock(>lru_lock);
@@ -1403,7 +1406,7 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
  
  	ret = 0;

if (mem_type > 0) {
-   ret = ttm_bo_force_list_clean(bdev, mem_type);
+   ret = ttm_bo_force_list_clean(bdev, mem_type, true);
if (ret) {
pr_err("Cleanup eviction failed\n");
return ret;
@@ -1433,7 +1436,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
return 0;
}
  
-	return ttm_bo_force_list_clean(bdev, mem_type);

+   return ttm_bo_force_list_clean(bdev, mem_type, true);
  }
  EXPORT_SYMBOL(ttm_bo_evict_mm);
  


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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #20 from Stratos Zolotas  ---
(In reply to Michel Dänzer from comment #19)
> 
> That's either simply coincidence, or means the kernel ran out of memory. The
> messages this report is about are triggered by transient memory allocation
> failures, for which there is a fallback path.

Maybe it is a coincidence, for sure I'm not running out of memory when it is
happening and started with kernel 4.15 and (or) Mesa 18.0 without any change on
Virtualbox side. I'll wait for the fix to see what happens...

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #19 from Michel Dänzer  ---
(In reply to Stratos Zolotas from comment #18)
> I can say that it is not completely harmless. I'm using virtualbox on my KDE
> plasma desktop and I have several crashes on windows VMs which are "aborted"
> while running. At the time the "aborted" is happening, I can see a flood of
> this type of messages on my logs.

That's either simply coincidence, or means the kernel ran out of memory. The
messages this report is about are triggered by transient memory allocation
failures, for which there is a fallback path.

-- 
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: [2/9] phy: add Rockchip Innosilicon hdmi phy

[Heiko Stuebner]

Hi Martin,

Am Montag, 5. Februar 2018, 22:32:08 CET schrieb Martin Cerveny:
> On Mon, 5 Feb 2018, Heiko Stuebner wrote:
> > From: Zheng Yang 
> >
> > Add a driver for the Innosilicon hdmi phy used on rk3228/rk3229
> > and rk3328 socs from Rockchip.
> >
> > Signed-off-by: Zheng Yang 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
> > +static u32 inno_hdmi_phy_get_tmdsclk(struct inno_hdmi_phy *inno, int rate)
> > +{
> > +   int bus_width = phy_get_bus_width(inno->phy);
> > +   u32 tmdsclk;
> > +
> > +   switch (bus_width) {
> > +   case 4:
> > +   tmdsclk = rate / 2;
> > +   break;
> > +   case 5:
> > +   tmdsclk = rate * 5 / 8;
> > +   break;
> > +   case 6:
> > +   tmdsclk = rate * 3 / 4;
> > +   break;
> > +   case 10:
> > +   tmdsclk = rate * 5 / 4;
> > +   break;
> > +   case 12:
> > +   tmdsclk = rate * 3 / 2;
> > +   break;
> > +   case 16:
> > +   tmdsclk = rate * 2;
> > +   break;
> > +   default:
> > +   tmdsclk = rate;
> > +   }
> > +
> > +   return tmdsclk;
> > +}
> 
> Please corrects integer overflow 
> like 
> https://github.com/mcerveny/rockchip-linux/commit/b4bc703f2dca4e5115b22155920d2277671a9f00

thanks for finding that possible issue. I've adapted the phy driver
in a similar way (using u64 though) and will include that change in the
next version.


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

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

--- Comment #1 from Michel Dänzer  ---
(In reply to L.S.S. from comment #0)
> I've thought about the possibility of it being DC-related as I saw similar
> bug reports, but I was wrong, as at one time I was able to reproduce it even
> after passing amdgpu.dc=0 during boot.

The rest of your report mostly points towards a DC specific issue. If you can
still reproduce an issue without DC, it would be best to file a separate report
about that.

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #18 from Stratos Zolotas  ---
(In reply to Michel Dänzer from comment #17)
> The swiotlb messages this report is about are harmless (though a fix is on
> the way anyway), the other issues you mention are probably not directly
> related.

I can say that it is not completely harmless. I'm using virtualbox on my KDE
plasma desktop and I have several crashes on windows VMs which are "aborted"
while running. At the time the "aborted" is happening, I can see a flood of
this type of messages on my logs. Didn't had any issue with my windows
virtualbox VMs up to now and the "aborted" crash has resulted on broken VMs who
need repair. Although haven't seen any btrfs corruption or other issue.

-- 
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 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/AMDgpu   |DRM/AMDgpu
Product|xorg|DRI
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
 QA Contact|xorg-t...@lists.x.org   |

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #17 from Michel Dänzer  ---
(In reply to Matthew Scheirer from comment #16)
> I get this as well with a 290 on 4.15 ONLY when DC is enabled. Its a dirty
> enough taint to leave btrfs volumes in inconsistent states so its straight
> crashing the kernel.

The swiotlb messages this report is about are harmless (though a fix is on the
way anyway), the other issues you mention are probably not directly related.

-- 
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/3] drm: add func to get max iomem address v2

[Michel Dänzer]

On 2018-02-09 03:44 AM, Chunming Zhou wrote:
> it will be used to check if the driver needs swiotlb
> v2: Don't use inline, instead, move function to drm_memory.c (Mechel Daenzer 
> )

Typo in my first name. With that fixed,

Reviewed-by: Michel Dänzer 


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

Re: [PATCH 1/3] drm/ttm: add bit flag TTM_OPT_FLAG_FORCE_ALLOC

[Christian König]

Am 09.02.2018 um 08:30 schrieb Roger He:

set TTM_OPT_FLAG_FORCE_ALLOC when we are servicing for page
fault routine.

for ttm_mem_global_reserve if in page fault routine, allow the gtt
pages reservation always. because page fault routing already grabbed
system memory and the allowance of this exception is harmless.
Otherwise, it will trigger OOM killer.

v2: keep original behavior except ttm bo with flag no_retry
v3: forward the ttm_operation_ctx to ttm_mem_global_reserve

Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo_vm.c  |  6 --
  drivers/gpu/drm/ttm/ttm_memory.c | 18 ++
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  1 -
  include/drm/ttm/ttm_bo_api.h |  4 +++-
  4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 716e724..313398a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -224,7 +224,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
} else {
-   struct ttm_operation_ctx ctx = {
+   struct ttm_operation_ctx ttm_opt_ctx = {


Drop all those variable renames, if we really want to do this we should 
have a separate patch.



.interruptible = false,
.no_wait_gpu = false
};
@@ -233,8 +233,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
  
+		if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)

+   ttm_opt_ctx.flags = TTM_OPT_FLAG_FORCE_ALLOC;


Just set that flag unconditionally for the page fault context.


/* Allocate all page at once, most common usage */
-   if (ttm->bdev->driver->ttm_tt_populate(ttm, )) {
+   if (ttm->bdev->driver->ttm_tt_populate(ttm, _opt_ctx)) {
ret = VM_FAULT_OOM;
goto out_io_unlock;
}
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..154719b 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -471,7 +471,8 @@ EXPORT_SYMBOL(ttm_mem_global_free);
  
  static int ttm_mem_global_reserve(struct ttm_mem_global *glob,

  struct ttm_mem_zone *single_zone,
- uint64_t amount, bool reserve)
+ uint64_t amount, bool reserve,
+ struct ttm_operation_ctx *ctx)
  {
uint64_t limit;
int ret = -ENOMEM;
@@ -479,6 +480,15 @@ static int ttm_mem_global_reserve(struct ttm_mem_global 
*glob,
struct ttm_mem_zone *zone;
  
  	spin_lock(>lock);

+   /*
+* to cover two special cases:
+* a. if serving page_fault allow reservation anyway since
+* it already allocated system pages. Otherwise it will trigger OOM.
+* b. if serving suspend, allow reservation anyway as well.
+*/
+   if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
+   goto force_reserve;
+


Oh, you want to skip the zone check as well? Not sure if that is a good 
idea or not.


Please drop that hunk for now and only skip the new limit when setting 
the ctx flag.



for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
if (single_zone && zone != single_zone)
@@ -491,6 +501,7 @@ static int ttm_mem_global_reserve(struct ttm_mem_global 
*glob,
goto out_unlock;
}
  
+force_reserve:

if (reserve) {
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
@@ -516,9 +527,8 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global 
*glob,
  {
int count = TTM_MEMORY_ALLOC_RETRIES;
  
-	while (unlikely(ttm_mem_global_reserve(glob,

-  single_zone,
-  memory, true)
+   while (unlikely(ttm_mem_global_reserve(glob, single_zone,
+  memory, true, ctx)
!= 0)) {
if (ctx->no_wait_gpu)
return -ENOMEM;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index b122f6e..354e0e1 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.cttm_mem_global_reserve
@@ -944,7 +944,6 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
i = 0;
  
  	type = ttm_to_type(ttm->page_flags, ttm->caching_state);

-


Unrelated whitespace change please drop that.

[PATCHv2 3/8] drm/omap: add support for manually updated displays

[Sebastian Reichel]

This adds the required infrastructure for manually
updated displays, such as DSI command mode panels.

While those panels often support partial updates
we currently always do a full refresh. Display
will be refreshed when something calls the dirty
callback, such as libdrm's drmModeDirtyFB().

This is currently being implemented for the kernel
console and for Xorg. Weston currently does not
implement this and is known not to work on manually
updated displays.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 110 +---
 drivers/gpu/drm/omapdrm/omap_crtc.h |   1 +
 drivers/gpu/drm/omapdrm/omap_fb.c   |  20 +++
 3 files changed, 123 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 2278e3433008..c2defb514b9f 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -51,6 +51,7 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+   struct delayed_work update_work;
 
void (*framedone_handler)(void *);
void *framedone_handler_data;
@@ -142,6 +143,28 @@ static void omap_crtc_dss_disconnect(enum omap_channel 
channel,
 
 static void omap_crtc_dss_start_update(enum omap_channel channel)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct omap_drm_private *priv = omap_crtc->base.dev->dev_private;
+
+   priv->dispc_ops->mgr_enable(channel, true);
+}
+
+static bool omap_crtc_is_manually_updated(struct drm_crtc *crtc)
+{
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+   bool result = false;
+
+   drm_connector_list_iter_begin(crtc->dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   if (connector->state->crtc != crtc)
+   continue;
+   result = omap_connector_get_manually_updated(connector);
+   break;
+   }
+   drm_connector_list_iter_end(_iter);
+
+   return result;
 }
 
 /* Called only from the encoder enable/disable and suspend/resume handlers. */
@@ -153,12 +176,17 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
enum omap_channel channel = omap_crtc->channel;
struct omap_irq_wait *wait;
u32 framedone_irq, vsync_irq;
+   bool is_manual = omap_crtc_is_manually_updated(crtc);
+   enum omap_display_type type = omap_crtc_output[channel]->output_type;
int ret;
 
if (WARN_ON(omap_crtc->enabled == enable))
return;
 
-   if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
+   if (is_manual)
+   omap_irq_enable_framedone(crtc, enable);
+
+   if (is_manual || type == OMAP_DISPLAY_TYPE_HDMI) {
priv->dispc_ops->mgr_enable(channel, enable);
omap_crtc->enabled = enable;
return;
@@ -209,7 +237,6 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
}
 }
 
-
 static int omap_crtc_dss_enable(enum omap_channel channel)
 {
struct omap_crtc *omap_crtc = omap_crtcs[channel];
@@ -369,6 +396,53 @@ void omap_crtc_framedone_irq(struct drm_crtc *crtc, 
uint32_t irqstatus)
wake_up(_crtc->pending_wait);
 }
 
+void omap_crtc_flush(struct drm_crtc *crtc)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   if (!omap_crtc_is_manually_updated(crtc))
+   return;
+
+   if (!delayed_work_pending(_crtc->update_work))
+   schedule_delayed_work(_crtc->update_work, 0);
+}
+
+static void omap_crtc_manual_display_update(struct work_struct *data)
+{
+   struct omap_crtc *omap_crtc =
+   container_of(data, struct omap_crtc, update_work.work);
+   struct omap_dss_device *dssdev = omap_crtc_output[omap_crtc->channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+   struct omap_dss_driver *dssdrv;
+   int ret, width, height;
+
+   if (!dssdev || !dssdev->dst) {
+   dev_err_once(dev->dev, "missing dssdev!");
+   return;
+   }
+
+   dssdev = dssdev->dst;
+   dssdrv = dssdev->driver;
+
+   if (!dssdrv || !dssdrv->update) {
+   dev_err_once(dev->dev, "incorrect dssdrv!");
+   return;
+   }
+
+   if (dssdrv->sync)
+   dssdrv->sync(dssdev);
+
+   width = dssdev->panel.vm.hactive;
+   height = dssdev->panel.vm.vactive;
+   ret = dssdrv->update(dssdev, 0, 0, width, height);
+   if (ret < 0) {
+   spin_lock_irq(>event_lock);
+   omap_crtc->pending = false;
+   spin_unlock_irq(>event_lock);
+   wake_up(_crtc->pending_wait);
+   }
+}
+
 static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
 {
struct 

[PATCHv2 8/8] drm/omap: plane: update fifo size on ovl setup

[Sebastian Reichel]

This is a workaround for a hardware bug occuring on OMAP3
with manually updated panels. Details about the HW bug are
unknown to me, but without this fix the panel refresh does
not work at all on Nokia N950. This is not the case for the
OMAP4 based Droid 4, which works perfectly fine with default
settings.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 4e8f68efd169..0904c3201914 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -157,6 +157,8 @@ struct dispc_features {
bool has_gamma_table:1;
 
bool has_gamma_i734_bug:1;
+
+   bool has_fifo_stallmode_bug:1;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -1489,6 +1491,18 @@ void dispc_ovl_compute_fifo_thresholds(enum 
omap_plane_id plane,
}
 }
 
+static void dispc_ovl_set_manual_fifo_threshold(enum omap_plane_id plane)
+{
+   u32 fifo_low, fifo_high;
+   bool use_fifo_merge = false;
+   bool use_manual_update = true;
+
+   dispc_ovl_compute_fifo_thresholds(plane, _low, _high,
+ use_fifo_merge, use_manual_update);
+
+   dispc_ovl_set_fifo_threshold(plane, fifo_low, fifo_high);
+}
+
 static void dispc_ovl_set_mflag(enum omap_plane_id plane, bool enable)
 {
int bit;
@@ -2651,8 +2665,21 @@ static int dispc_ovl_setup(enum omap_plane_id plane,
oi->out_width, oi->out_height, oi->fourcc, oi->rotation,
oi->zorder, oi->pre_mult_alpha, oi->global_alpha,
oi->rotation_type, replication, vm, mem_to_mem);
+   if (r)
+   return r;
 
-   return r;
+   /*
+* OMAP3 chips have non-working FIFO thresholds for manually updated
+* displays. The issue is not fully understood, but this workaround
+* fixes the issue. OMAP4 is known to work with default thresholds.
+*/
+   if (mgr_fld_read(channel, DISPC_MGR_FLD_STALLMODE) &&
+   dispc.feat->has_fifo_stallmode_bug) {
+   DSSDBG("Enable OMAP3 FIFO stallmode bug workaround!\n");
+   dispc_ovl_set_manual_fifo_threshold(plane);
+   }
+
+   return 0;
 }
 
 int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
@@ -4067,6 +4094,7 @@ static const struct dispc_features omap24xx_dispc_feats = 
{
.no_framedone_tv=   true,
.set_max_preload=   false,
.last_pixel_inc_missing =   true,
+   .has_fifo_stallmode_bug =   true,
 };
 
 static const struct dispc_features omap34xx_rev1_0_dispc_feats = {
@@ -4101,6 +4129,7 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats = {
.no_framedone_tv=   true,
.set_max_preload=   false,
.last_pixel_inc_missing =   true,
+   .has_fifo_stallmode_bug =   true,
 };
 
 static const struct dispc_features omap34xx_rev3_0_dispc_feats = {
@@ -4135,6 +4164,7 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats = {
.no_framedone_tv=   true,
.set_max_preload=   false,
.last_pixel_inc_missing =   true,
+   .has_fifo_stallmode_bug =   true,
 };
 
 static const struct dispc_features omap36xx_dispc_feats = {
@@ -4169,6 +4199,7 @@ static const struct dispc_features omap36xx_dispc_feats = 
{
.no_framedone_tv=   true,
.set_max_preload=   false,
.last_pixel_inc_missing =   true,
+   .has_fifo_stallmode_bug =   true,
 };
 
 static const struct dispc_features am43xx_dispc_feats = {
@@ -4203,6 +4234,7 @@ static const struct dispc_features am43xx_dispc_feats = {
.no_framedone_tv=   true,
.set_max_preload=   false,
.last_pixel_inc_missing =   true,
+   .has_fifo_stallmode_bug =   false,
 };
 
 static const struct dispc_features omap44xx_dispc_feats = {
@@ -4242,6 +4274,7 @@ static const struct dispc_features omap44xx_dispc_feats = 
{
.reverse_ilace_field_order =true,
.has_gamma_table=   true,
.has_gamma_i734_bug =   true,
+   .has_fifo_stallmode_bug =   false,
 };
 
 static const struct dispc_features omap54xx_dispc_feats = {
@@ -4282,6 +4315,7 @@ static const struct dispc_features omap54xx_dispc_feats = 
{
.reverse_ilace_field_order =true,
.has_gamma_table=   true,
.has_gamma_i734_bug =   true,
+   .has_fifo_stallmode_bug =   false,
 };
 
 static irqreturn_t dispc_irq_handler(int irq, void *arg)
-- 
2.15.1

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

[PATCHv2 4/8] dt-bindings: panel: common: document orientation property

[Sebastian Reichel]

Introduce new "orientation" property for describing in which
orientation a panel has been mounted to the device. This can
be used by the operating system to automatically rotate the
display correctly.

Signed-off-by: Sebastian Reichel 
---
 .../devicetree/bindings/display/panel/panel-common.txt | 12 
 include/dt-bindings/display/common.h   | 14 ++
 2 files changed, 26 insertions(+)
 create mode 100644 include/dt-bindings/display/common.h

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
b/Documentation/devicetree/bindings/display/panel/panel-common.txt
index 557fa765adcb..c646b8908458 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
@@ -18,6 +18,18 @@ Descriptive Properties
   physical area where images are displayed. These properties are expressed in
   millimeters and rounded to the closest unit.
 
+- orientation: The orientation property specifies the panel orientation
+  in relation to the device's casing. The following values are possible:
+
+   * 0 = The top side of the panel matches the top side of the device's
+ casing.
+   * 1 = The top side of the panel matches the bottom side of the device's
+ casing. In other words the panel is mounted upside-down.
+   * 2 = The left side of the panel matches the top side of the device's
+ casing.
+   * 3 = The right side of the panel matches the top side of the device's
+ casing.
+
 - label: The label property specifies a symbolic name for the panel as a
   string suitable for use by humans. It typically contains a name inscribed on
   the system (e.g. as an affixed label) or specified in the system's
diff --git a/include/dt-bindings/display/common.h 
b/include/dt-bindings/display/common.h
new file mode 100644
index ..a864775445a0
--- /dev/null
+++ b/include/dt-bindings/display/common.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides common constants for displays
+ */
+
+#ifndef _DT_BINDINGS_DISPLAY_COMMON_H
+#define _DT_BINDINGS_DISPLAY_COMMON_H
+
+#define PANEL_ORIENTATION_NORMAL 0
+#define PANEL_ORIENTATION_BOTTOM_UP 1
+#define PANEL_ORIENTATION_LEFT_UP 2
+#define PANEL_ORIENTATION_RIGHT_UP 3
+
+#endif
-- 
2.15.1

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

Re: [PATCH v2] spi: kconfig: Remove AVR32 dep. from SPI_ATMEL

[Matthias Brugger]

On 02/08/2018 03:44 AM, Ulf Magnusson wrote:
> The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
> support for AVR32 architecture").

You forgot the Signed-off-by tag.

> ---
> Changes in v2:
> Remove the AVR32 reference from the help text too.
> 
>  drivers/spi/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 603783976b81..6fb0347a24f2 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -72,10 +72,10 @@ config SPI_ARMADA_3700
>  config SPI_ATMEL
>   tristate "Atmel SPI Controller"
>   depends on HAS_DMA
> - depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
> + depends on (ARCH_AT91 || COMPILE_TEST)
>   help
> This selects a driver for the Atmel SPI Controller, present on
> -   many AT32 (AVR32) and AT91 (ARM) chips.
> +   many AT91 (ARM) chips.
>  
>  config SPI_AU1550
>   tristate "Au1550/Au1200/Au1300 SPI Controller"
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 0/8] omapdrm: DSI command mode panel support

[Sebastian Reichel]

Hi,

These are the remaining patches from my previous patchset to get
Droid 4 (omap4) display working. The patches have been rebased to
current master branch from Torvalds (581e400ff935). Since N950
(omap3) is broken even with the workaround I moved it to the end,
so that it can be skipped.

Working on Droid 4:
 * Framebuffer Console, updated at 1Hz due to blinking cursor
 * kmstest (static image)
 * Display blanking
 * Xorg with omap and modesetting driver
 * No updates send when nothing needs to be sent
 * Orientation DRM property is attached to the DSI panel

Known issues:
 * N950 (omap3) is broken. I have updated the omap3 fifo workaround,
   but it's not enough to fix omap3.
 * N950 (and N9) has first and last few lines covered by plastic, so
   we should expose a smaller screen

Changes since PATCHv1:
 * Drop patches, that were queued by Tomi
 * Rebase to current master
 * Rework the omap3 workaround patch to only affect omap3
 * Add orientation DRM property support

-- Sebastian


Sebastian Reichel (8):
  drm/omap: add framedone interrupt support
  drm/omap: add manual update detection helper
  drm/omap: add support for manually updated displays
  dt-bindings: panel: common: document orientation property
  drm/omap: add support for orientation hints from display drivers
  drm/omap: panel-dsi-cm: add orientation support
  ARM: dts: omap4-droid4: Add LCD panel orientation property
  drm/omap: plane: update fifo size on ovl setup

 .../bindings/display/panel/panel-common.txt|  12 ++
 arch/arm/boot/dts/omap4-droid4-xt894.dts   |   3 +
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|  13 ++
 drivers/gpu/drm/omapdrm/dss/dispc.c|  36 -
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |   2 +
 drivers/gpu/drm/omapdrm/omap_connector.c   |  18 ++-
 drivers/gpu/drm/omapdrm/omap_connector.h   |   1 +
 drivers/gpu/drm/omapdrm/omap_crtc.c| 158 +++--
 drivers/gpu/drm/omapdrm/omap_crtc.h|   2 +
 drivers/gpu/drm/omapdrm/omap_fb.c  |  20 +++
 drivers/gpu/drm/omapdrm/omap_irq.c |  24 
 drivers/gpu/drm/omapdrm/omap_irq.h |   1 +
 include/dt-bindings/display/common.h   |  14 ++
 13 files changed, 294 insertions(+), 10 deletions(-)
 create mode 100644 include/dt-bindings/display/common.h

-- 
2.15.1

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

[PATCH v3] spi: kconfig: Remove AVR32 dep. from SPI_ATMEL

[Ulf Magnusson]

The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
support for AVR32 architecture").

Signed-off-by: Ulf Magnusson 
---
Changes in v3:
Add Signed-off-by tag

Changes in v2:
Remove the AVR32 reference from the help text too.

 drivers/spi/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 603783976b81..6fb0347a24f2 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -72,10 +72,10 @@ config SPI_ARMADA_3700
 config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on HAS_DMA
-   depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
+   depends on (ARCH_AT91 || COMPILE_TEST)
help
  This selects a driver for the Atmel SPI Controller, present on
- many AT32 (AVR32) and AT91 (ARM) chips.
+ many AT91 (ARM) chips.
 
 config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
-- 
2.14.1

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

Re: [PATCHv2 0/8] omapdrm: DSI command mode panel support

[Tony Lindgren]

* Sebastian Reichel  [180208 10:31]:
> Hi,
> 
> These are the remaining patches from my previous patchset to get
> Droid 4 (omap4) display working. The patches have been rebased to
> current master branch from Torvalds (581e400ff935). Since N950
> (omap3) is broken even with the workaround I moved it to the end,
> so that it can be skipped.
> 
> Working on Droid 4:
>  * Framebuffer Console, updated at 1Hz due to blinking cursor
>  * kmstest (static image)
>  * Display blanking
>  * Xorg with omap and modesetting driver
>  * No updates send when nothing needs to be sent
>  * Orientation DRM property is attached to the DSI panel

Great, still works for me :) Seems like the dts change is
safe to merge along with the driver changes once no more
comments. For patches 1 - 7, please feel free to add:

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

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

[Sebastian Reichel]

Hi,

On Thu, Feb 08, 2018 at 12:53:16PM +0200, Tomi Valkeinen wrote:
> On 08/02/18 11:41, Pavel Machek wrote:
> >> I've also picked patches 7-12.
> > 
> > It seems that part of the support made it to v4.16. Is it supposed to
> > be complete?
> > 
> > I still have these in my tree, and result works on Nokia N9. Is there
> > any way I can help with the merge?
> 
> I picked the patches that seemed safe to pick. I think we can do another
> review round if someone rebases and posts the patches. Although I see
> that they have conflicts with other patches that have been posted, so
> we'll see how it goes.
> 
> Btw, you seem to have something in your tree that was not in the series.
> Nothing in the series touches mipi_display.h.

I have a rebased series based on recent origin/master. It works
properly on Droid 4 (omap4), but has issues on omap3 even with
the fifo bug fix applied. I do not yet know the reason, but I
think we should proceed anyways. I originally planned to send
this based on rc1, but will do so now.

-- Sebastian


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

Re: [PATCH] drm/bridge/synopsys: dsi: Adopt SPDX identifiers

[Philippe Ombredanne]

Benjamin,

On Wed, Jan 24, 2018 at 9:57 AM, Benjamin Gaignard
 wrote:
> 2018-01-24 0:32 GMT+01:00 Laurent Pinchart 
> :
>> Hi Philippe,
>>
>> On Tuesday, 23 January 2018 12:25:51 EET Philippe CORNU wrote:
>>> On 01/23/2018 12:30 AM, Laurent Pinchart wrote:
>>> > On Monday, 22 January 2018 12:26:08 EET Philippe Cornu wrote:
>>> >> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI
>>> >> host controller driver.
>>> >>
>>> >> Signed-off-by: Philippe Cornu 
>>> >> ---
>>> >>
>>> >>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +-
>>> >>   1 file changed, 1 insertion(+), 5 deletions(-)
>>> >>
>>> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> >> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
>>> >> 46b0e73404d1..e06836dec77c 100644
>>> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> >> @@ -1,12 +1,8 @@
>>> >> +// SPDX-License-Identifier: GPL-2.0
>>> >
>>> > According to Documentation/process/license-rules.txt this would change
>>> > the existing license. The correct identifier is GPL-2.0+.
>>>
>>> You are right, I did not put the correct identifier :(
>>>
>>> After reading more spdx.org, I wonder if the correct value should be
>>> GPL-2.0-or-later instead of GPL-2.0+
>>>
>>> https://spdx.org/licenses/GPL-2.0-or-later.html
>>> https://spdx.org/licenses/GPL-2.0+.html
>>>
>>> What is your opinion?
>>
>> I agree in principle, and I've even asked for that before, but I've been told
>> that we should stick to the license identifiers defined in Documentation/
>> process/license-rules.txt. The file might get updated to use GPL-2.0-or-later
>> and GPL-2.0-only later, and kernel sources will likely then get patched in 
>> one
>> go.
>
> + Philippe O. to check what I'm writing just below.
>
> In -next branch I only see reference to GPL-2.0+ identifier so for me
> it fine to use it here.
> Is that right ? or should we use GPL-2.0-or-later keyword ?


Sorry for the late reply!
IMHO it is essential to stick to what is in the kernel doc, meaning
that you should not use the GPL-2.0-or-later identifier until it is
part of the kernel doc. Otherwise this is going to be a mess ;)
Consistency matters a lot.
-- 
Cordially
Philippe Ombredanne
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/bridge/synopsys: dsi: Adopt SPDX identifiers

[Philippe Ombredanne]

On Thu, Feb 8, 2018 at 3:58 PM, Philippe Cornu  wrote:
> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI
> host controller driver.
>
> Signed-off-by: Philippe Cornu 
> ---
> Changes in v2: Update to "GPL-2.0+" following comments from Laurent
> Pinchart, Benjamin Gaignard & Philippe Ombredanne.
>
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 7bac101c285c..99f0e4f51716 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -1,12 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>   * Copyright (C) STMicroelectronics SA 2017
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
>   * Modified by Philippe Cornu 
>   * This generic Synopsys DesignWare MIPI DSI host driver is based on the
>   * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
> --
> 2.15.1
>

Thank you.

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

[PATCHv2 2/8] drm/omap: add manual update detection helper

[Sebastian Reichel]

In preparation for manually updated display support, such as DSI
command mode panels, this adds a simple helper to see if a connector
is manually updated.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 8 
 drivers/gpu/drm/omapdrm/omap_connector.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index a0d7b1d905e8..a33b51484b2d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -57,6 +57,14 @@ bool omap_connector_get_hdmi_mode(struct drm_connector 
*connector)
return omap_connector->hdmi_mode;
 }
 
+bool omap_connector_get_manually_updated(struct drm_connector *connector)
+{
+   struct omap_connector *omap_connector = to_omap_connector(connector);
+
+   return !!(omap_connector->dssdev->caps &
+ OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE);
+}
+
 static enum drm_connector_status omap_connector_detect(
struct drm_connector *connector, bool force)
 {
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.h 
b/drivers/gpu/drm/omapdrm/omap_connector.h
index 98bbc779b302..652136d167f5 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.h
+++ b/drivers/gpu/drm/omapdrm/omap_connector.h
@@ -33,5 +33,6 @@ struct drm_connector *omap_connector_init(struct drm_device 
*dev,
 struct drm_encoder *omap_connector_attached_encoder(
struct drm_connector *connector);
 bool omap_connector_get_hdmi_mode(struct drm_connector *connector);
+bool omap_connector_get_manually_updated(struct drm_connector *connector);
 
 #endif /* __OMAPDRM_CONNECTOR_H__ */
-- 
2.15.1

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

[PATCH] drm/amdgpu: add new device to use atpx quirk

[Kai-Heng Feng]

The affected system (0x0813) is pretty similar to another one (0x0812),
it also needs to use ATPX power control.

Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
index e2c3c5ec42d1..c53095b3b0fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk amdgpu_px_quirk_list[] 
= {
/* HG _PR3 doesn't seem to work on this A+A weston board */
{ 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
+   { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
{ 0, 0, 0, 0, 0 },
 };
 
-- 
2.15.1

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

[PATCHv2 7/8] ARM: dts: omap4-droid4: Add LCD panel orientation property

[Sebastian Reichel]

This adds a LCD panel orientation hint to the Droid 4. If the
display is rotated this way the keyboard can be used properly.

Signed-off-by: Sebastian Reichel 
---
 arch/arm/boot/dts/omap4-droid4-xt894.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts 
b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index b21084da490b..e11a24397163 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 
 #include 
+#include 
 #include "omap443x.dtsi"
 #include "motorola-cpcap-mapphone.dtsi"
 
@@ -181,6 +182,8 @@
height-mm = <89>;
backlight = <_backlight>;
 
+   orientation = ;
+
panel-timing {
clock-frequency = <0>;  /* Calculated by dsi */
 
-- 
2.15.1

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

[PATCHv2 5/8] drm/omap: add support for orientation hints from display drivers

[Sebastian Reichel]

This adds support for setting DRM panel orientation property
based on information from the display driver.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/omapdss.h|  2 ++
 drivers/gpu/drm/omapdrm/omap_connector.c | 10 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index f8f83e826a56..72ebd82409d3 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -565,6 +565,8 @@ struct omap_dss_driver {
struct videomode *vm);
void (*get_size)(struct omap_dss_device *dssdev,
 unsigned int *width, unsigned int *height);
+   void (*get_orientation)(struct omap_dss_device *dssdev,
+   int *orientation);
 
int (*set_wss)(struct omap_dss_device *dssdev, u32 wss);
u32 (*get_wss)(struct omap_dss_device *dssdev);
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index a33b51484b2d..2f296d29b74b 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -249,6 +249,7 @@ struct drm_connector *omap_connector_init(struct drm_device 
*dev,
struct drm_connector *connector = NULL;
struct omap_connector *omap_connector;
bool hpd_supported = false;
+   int ret;
 
DBG("%s", dssdev->name);
 
@@ -267,7 +268,7 @@ struct drm_connector *omap_connector_init(struct drm_device 
*dev,
drm_connector_helper_add(connector, _connector_helper_funcs);
 
if (dssdev->driver->register_hpd_cb) {
-   int ret = dssdev->driver->register_hpd_cb(dssdev,
+   ret = dssdev->driver->register_hpd_cb(dssdev,
  omap_connector_hpd_cb,
  omap_connector);
if (!ret)
@@ -288,6 +289,13 @@ struct drm_connector *omap_connector_init(struct 
drm_device *dev,
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
 
+   if (dssdev->driver->get_orientation)
+   dssdev->driver->get_orientation(dssdev, 
>display_info.panel_orientation);
+
+   ret = drm_connector_init_panel_orientation_property(connector, 0, 0);
+   if (ret)
+   DBG("%s: Failed to init orientation property (%d)", 
dssdev->name, ret);
+
return connector;
 
 fail:
-- 
2.15.1

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

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Farhan Ali]

On 02/08/2018 08:11 AM, Bartlomiej Zolnierkiewicz wrote:


Hi,

[ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]

On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:

On 02/01/2018 07:41 PM, Farhan Ali wrote:

The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
added the HAS_IOMEM dependecy for "Graphics support". This disabled the
"Graphics support" menu for S390. But if we enable VT layer for S390,
we would also need to enable the dummy console. So let's remove the
HAS_IOMEM dependency.

Move this dependency to Opencores framebuffer driver which would fail to build
with CONFIG_HAS_IOMEM disabled:

ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!


"Graphics support" menu covers other things (i.e. DRM), I assume that
they were also checked to not break due to this change?

Yes, DRM compiled fine. And we (s390) would need the DRM subsystem for 
Virtio GPU as well.



Moreover it seems that after this change "Graphics support" menu will
be also enabled (besides s390) for score, tile and um architectures,
I assume that this is okay?


Signed-off-by: Farhan Ali 
Tested-by: Dong Jia Shi 


This also enables several PCI based graphic device driver on s390.
This makes no sense but they all compile fine so I guess this is ok.

I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
tree?



---
  drivers/video/Kconfig   | 1 -
  drivers/video/fbdev/Kconfig | 2 +-
  2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..41e7ba9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -3,7 +3,6 @@
  #

  menu "Graphics support"
-   depends on HAS_IOMEM

  config HAVE_FB_ATMEL
bool
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2f615b7..ec9c9ce 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -966,7 +966,7 @@ config FB_PVR2

  config FB_OPENCORES
tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
-   depends on FB && HAS_DMA
+   depends on FB && HAS_DMA && HAS_IOMEM
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT


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



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

[PATCHv2 1/8] drm/omap: add framedone interrupt support

[Sebastian Reichel]

This prepares framedone interrupt handling for
manual display update support.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 48 +
 drivers/gpu/drm/omapdrm/omap_crtc.h |  1 +
 drivers/gpu/drm/omapdrm/omap_irq.c  | 24 +++
 drivers/gpu/drm/omapdrm/omap_irq.h  |  1 +
 4 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 1b8154e58d18..2278e3433008 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -51,6 +51,9 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+
+   void (*framedone_handler)(void *);
+   void *framedone_handler_data;
 };
 
 /* 
-
@@ -247,6 +250,17 @@ static int omap_crtc_dss_register_framedone(
enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   if (omap_crtc->framedone_handler)
+   return -EBUSY;
+
+   dev_dbg(dev->dev, "register framedone %s", omap_crtc->name);
+
+   omap_crtc->framedone_handler = handler;
+   omap_crtc->framedone_handler_data = data;
+
return 0;
 }
 
@@ -254,6 +268,16 @@ static void omap_crtc_dss_unregister_framedone(
enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   dev_dbg(dev->dev, "unregister framedone %s", omap_crtc->name);
+
+   WARN_ON(omap_crtc->framedone_handler != handler);
+   WARN_ON(omap_crtc->framedone_handler_data != data);
+
+   omap_crtc->framedone_handler = NULL;
+   omap_crtc->framedone_handler_data = NULL;
 }
 
 static const struct dss_mgr_ops mgr_ops = {
@@ -321,6 +345,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
 }
 
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   if (!omap_crtc->framedone_handler) {
+   dev_warn(omap_crtc->base.dev->dev, "no framedone handler?");
+   return;
+   }
+
+   omap_crtc->framedone_handler(omap_crtc->framedone_handler_data);
+
+   spin_lock(>dev->event_lock);
+   /* Send the vblank event if one has been requested. */
+   if (omap_crtc->event) {
+   drm_crtc_send_vblank_event(crtc, omap_crtc->event);
+   omap_crtc->event = NULL;
+   }
+   omap_crtc->pending = false;
+   spin_unlock(>dev->event_lock);
+
+   /* Wake up omap_atomic_complete. */
+   wake_up(_crtc->pending_wait);
+}
+
 static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
 {
struct omap_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h 
b/drivers/gpu/drm/omapdrm/omap_crtc.h
index ad7b007c6174..bd316bc0b6f4 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.h
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
@@ -39,5 +39,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
 int omap_crtc_wait_pending(struct drm_crtc *crtc);
 void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus);
 void omap_crtc_vblank_irq(struct drm_crtc *crtc);
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus);
 
 #endif /* __OMAPDRM_CRTC_H__ */
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 53ba424823b2..354df3583229 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -85,6 +85,27 @@ int omap_irq_wait(struct drm_device *dev, struct 
omap_irq_wait *wait,
return ret == 0 ? -1 : 0;
 }
 
+int omap_irq_enable_framedone(struct drm_crtc *crtc, bool enable)
+{
+   struct drm_device *dev = crtc->dev;
+   struct omap_drm_private *priv = dev->dev_private;
+   unsigned long flags;
+   enum omap_channel channel = omap_crtc_channel(crtc);
+   int framedone_irq = priv->dispc_ops->mgr_get_framedone_irq(channel);
+
+   DBG("dev=%p, crtc=%u, enable=%d", dev, channel, enable);
+
+   spin_lock_irqsave(>wait_lock, flags);
+   if (enable)
+   priv->irq_mask |= framedone_irq;
+   else
+   priv->irq_mask &= ~framedone_irq;
+   omap_irq_update(dev);
+   spin_unlock_irqrestore(>wait_lock, flags);
+
+   return 0;
+}
+
 /**
  * enable_vblank - enable vblank interrupt events
  * @dev: DRM device
@@ -215,6 +236,9 @@ static irqreturn_t omap_irq_handler(int irq, void *arg)
 
if (irqstatus & priv->dispc_ops->mgr_get_sync_lost_irq(channel))