[PATCH 24/29] drm/amd/dal: Add display core

2016-02-11 Thread Harry Wentland
Adds a logical representation of our hardware. Provides ability to
- dc_validate_resources - validate a display configuration
- dc_commit_targets - commit a display configuration
- dc_commit_surfaces_to_target - update surfaces
- dc_link_detect - detect displays at link
- dc_resume - resume display HW
- dc_interrupt_set/ack - set and ack interrupts
- etc.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/Makefile   |   28 +
 drivers/gpu/drm/amd/dal/dc/core/dc.c  |  932 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_hw_sequencer.c |   56 +
 drivers/gpu/drm/amd/dal/dc/core/dc_link.c | 1644 
 drivers/gpu/drm/amd/dal/dc/core/dc_link_ddc.c | 1151 ++
 drivers/gpu/drm/amd/dal/dc/core/dc_link_dp.c  | 1728 +
 drivers/gpu/drm/amd/dal/dc/core/dc_link_hwss.c|  201 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_resource.c | 1243 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_sink.c |  116 ++
 drivers/gpu/drm/amd/dal/dc/core/dc_stream.c   |  188 +++
 drivers/gpu/drm/amd/dal/dc/core/dc_surface.c  |  123 ++
 drivers/gpu/drm/amd/dal/dc/core/dc_target.c   |  548 +++
 12 files changed, 7958 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_hw_sequencer.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link_ddc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link_dp.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_link_hwss.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_resource.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_sink.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_stream.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_surface.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/core/dc_target.c

diff --git a/drivers/gpu/drm/amd/dal/dc/Makefile 
b/drivers/gpu/drm/amd/dal/dc/Makefile
new file mode 100644
index ..aed26eec81f9
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/Makefile
@@ -0,0 +1,28 @@
+#
+# Makefile for Display Core (dc) component.
+#
+
+DC_LIBS = adapter asic_capability audio basics bios calcs \
+gpio gpu i2caux irq virtual
+
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+DC_LIBS += dce110
+endif
+
+ifdef CONFIG_DRM_AMD_DAL_DCE10_0
+DC_LIBS += dce100
+endif
+
+AMD_DC = $(addsuffix /Makefile, $(addprefix 
$(FULL_AMD_DAL_PATH)/dc/,$(DC_LIBS)))
+
+include $(AMD_DC)
+
+DISPLAY_CORE = dc.o dc_link.o dc_resource.o dc_target.o dc_sink.o dc_stream.o \
+dc_hw_sequencer.o dc_surface.o dc_link_hwss.o dc_link_dp.o dc_link_ddc.o
+
+AMD_DISPLAY_CORE = $(addprefix $(AMDDALPATH)/dc/core/,$(DISPLAY_CORE))
+
+AMD_DAL_FILES += $(AMD_DISPLAY_CORE)
+
+
+
diff --git a/drivers/gpu/drm/amd/dal/dc/core/dc.c 
b/drivers/gpu/drm/amd/dal/dc/core/dc.c
new file mode 100644
index ..0b8f158c0ec2
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/core/dc.c
@@ -0,0 +1,932 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ */
+
+#include "dm_services.h"
+
+#include "dc.h"
+
+#include "core_status.h"
+#include "core_types.h"
+#include "hw_sequencer.h"
+
+#include "resource.h"
+
+#include "adapter_service_interface.h"
+#include "clock_source.h"
+#include "dc_bios_types.h"
+
+#include "bandwidth_calcs.h"
+#include "include/irq_service_interface.h"
+#include "transform.h"
+#include "timing_generator.h"
+#include "virtual/virtual_link_encoder.h"
+
+#include "link_hwss.h"
+#include "link_encoder.h"
+
+#include "dc_link_ddc.h"
+
+/*

[PATCH 27/29] drm/amd/dal: Correctly interpret rotation as bit set

2016-02-16 Thread Harry Wentland
For sure. Thanks, Oded.

I'll send out squashed patches later today.

Harry

On 2016-02-11 04:00 PM, Oded Gabbay wrote:
> On Thu, Feb 11, 2016 at 7:20 PM, Harry Wentland  
> wrote:
>> Signed-off-by: Harry Wentland 
>> Reviewed-by: Mykola Lysenko 
>> ---
>>   drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c | 8 
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c 
>> b/drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c
>> index 1cc9fd1054ab..da6c0116aa1a 100644
>> --- a/drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c
>> +++ b/drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c
>> @@ -366,16 +366,16 @@ static bool fill_rects_from_plane_state(
>>  surface->clip_rect = surface->dst_rect;
>>
>>  switch (state->rotation) {
>> -   case DRM_ROTATE_0:
>> +   case BIT(DRM_ROTATE_0):
>>  surface->rotation = ROTATION_ANGLE_0;
>>  break;
>> -   case DRM_ROTATE_90:
>> +   case BIT(DRM_ROTATE_90):
>>  surface->rotation = ROTATION_ANGLE_90;
>>  break;
>> -   case DRM_ROTATE_180:
>> +   case BIT(DRM_ROTATE_180):
>>  surface->rotation = ROTATION_ANGLE_180;
>>  break;
>> -   case DRM_ROTATE_270:
>> +   case BIT(DRM_ROTATE_270):
>>  surface->rotation = ROTATION_ANGLE_270;
>>  break;
>>  default:
>> --
>> 2.1.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> One minor suggestion for the V2 of this patch-set, please squash
> patches 27-29 into the previous patches (relevant to the code they
> change). No point in reviewing code of earlier patches that is later
> going to be changed by a patch in the same patch-set.
>
> Thanks,
>
>   Oded



[PATCH v2 00/26] Enabling new DAL display driver for amdgpu on Carrizo and Tonga

2016-02-16 Thread Harry Wentland
v2 Update:
This is just a squash of the three small fixes into the main patches to
make for an easier read. No other changes yet.


This set of patches enables the new DAL display driver for amdgpu on Carrizo
Tonga, and Fiji ASICs. This driver will allow us going forward to bring
display features on the open amdgpu driver (mostly) on par with the Catalyst
driver.

This driver adds support for 
- Atomic KMS API
- MST
- HDMI 2.0
- Better powerplay integration
- Support of HW bandwidth formula on Carrizo
- Better multi-display support and handling of co-functionality
- Broader support of display dongles
- Timing synchronization between DP and HDMI

This patch series is based on Alex Deucher's drm-next-4.6-wip tree.


Harry Wentland (26):
  drm/amd/dal: Add dal headers
  drm/amd/dal: Add DAL Basic Types and Logger
  drm/amd/dal: Fixed point arithmetic
  drm/amd/dal: Asic Capabilities
  drm/amd/dal: GPIO (General Purpose IO)
  drm/amd/dal: Adapter Service
  drm/amd/dal: BIOS Parser
  drm/amd/dal: I2C Aux Manager
  drm/amd/dal: IRQ Service
  drm/amd/dal: GPU
  drm/amd/dal: Audio
  drm/amd/dal: Bandwidth calculations
  drm/amd/dal: Add encoder HW programming
  drm/amd/dal: Add clock source HW programming
  drm/amd/dal: Add timing generator HW programming
  drm/amd/dal: Add surface HW programming
  drm/amd/dal: Add framebuffer compression HW programming
  drm/amd/dal: Add input pixel processing HW programming
  drm/amd/dal: Add output pixel processing HW programming
  drm/amd/dal: Add transform & scaler HW programming
  drm/amd/dal: Add Carrizo HW sequencer and resource
  drm/amd/dal: Add Tonga/Fiji HW sequencer and resource
  drm/amd/dal: Add empty encoder programming for virtual HW
  drm/amd/dal: Add display core
  drm/amd/dal: Adding amdgpu_dm for dal
  drm/amdgpu: Use dal driver for Carrizo, Tonga, and Fiji

 drivers/gpu/drm/amd/amdgpu/Kconfig |3 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   17 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   69 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|   20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   54 +-
 drivers/gpu/drm/amd/amdgpu/vi.c|  250 +
 drivers/gpu/drm/amd/dal/Kconfig|   48 +
 drivers/gpu/drm/amd/dal/Makefile   |   21 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile |   17 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c  | 1468 ++
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.h  |  168 +
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_helpers.c  |  474 ++
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.c  |  820 
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.h  |  122 +
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.c|  480 ++
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.h|   36 +
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_services.c |  457 ++
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c| 2577 ++
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.h|  100 +
 drivers/gpu/drm/amd/dal/dal_services.h |  266 ++
 drivers/gpu/drm/amd/dal/dal_services_types.h   |   62 +
 drivers/gpu/drm/amd/dal/dc/Makefile|   28 +
 drivers/gpu/drm/amd/dal/dc/adapter/Makefile|   24 +
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.c   | 2089 
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.h   |   71 +
 .../adapter/dce110/hw_ctx_adapter_service_dce110.c |  304 ++
 .../adapter/dce110/hw_ctx_adapter_service_dce110.h |   40 +
 .../diagnostics/hw_ctx_adapter_service_diag.c  |  133 +
 .../diagnostics/hw_ctx_adapter_service_diag.h  |   33 +
 .../amd/dal/dc/adapter/hw_ctx_adapter_service.c|  164 +
 .../amd/dal/dc/adapter/hw_ctx_adapter_service.h|   86 +
 .../drm/amd/dal/dc/adapter/wireless_data_source.c  |  208 +
 .../drm/amd/dal/dc/adapter/wireless_data_source.h  |   80 +
 .../gpu/drm/amd/dal/dc/asic_capability/Makefile|   35 +
 .../amd/dal/dc/asic_capability/asic_capability.c   |  190 +
 .../dc/asic_capability/carrizo_asic_capability.c   |  147 +
 .../dc/asic_capability/carrizo_asic_capability.h   |   36 +
 .../dal/dc/asic_capability/tonga_asic_capability.c |  146 +
 .../dal/dc/asic_capability/tonga_asic_capability.h |   36 +
 drivers/gpu/drm/amd/dal/dc/audio/Makefile  |   22 +
 drivers/gpu/drm/amd/dal/dc/audio/audio.h   |  195 +
 drivers/gpu/drm/amd/dal/dc/audio/audio_base.c  |  470 ++
 .../gpu/drm/amd/dal/dc/audio/dce110/audio_dce110.c |  453 ++
 .../gpu/drm/amd/dal/dc/audio/dce110/audio_dce110.h |   42 +
 .../amd/dal/dc/audio/dce110/hw_ctx_audio_dce110.c  | 1930 
 .../amd/dal/dc/audio/dce110/hw_ctx_audio_dce110.h  |   47 +
 drivers/gpu/drm/amd/dal/dc/audio/hw_ctx_audio.c|  771 +++
 drivers/gpu/drm/amd/dal/dc/audio/hw_ctx_audio.h| 

[PATCH v2 02/26] drm/amd/dal: Add DAL Basic Types and Logger

2016-02-16 Thread Harry Wentland
Laying the groundwork for the AMD DAL display driver.
This patch includes the basic services and defines basic
types required by the display driver, such as:
- ASIC register access
- VBIOS access
- Vector and flat_set data structures
- Display signal types
- ASIC versions and IDs
- HW IDs
- Logging functionality

This patch adds Kconfig options to enable the DAL
display driver.
- DRM_AMD_DAL
- DRM_AMD_DAL_VBIOS_PRESENT
- DRM_AMD_DAL_DCE11_0
- DRM_AMD_DAL_DCE10_0
- DEBUG_KERNEL_DAL

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/Kconfig|  48 ++
 drivers/gpu/drm/amd/dal/Makefile   |  21 +
 drivers/gpu/drm/amd/dal/dc/basics/Makefile |  10 +
 drivers/gpu/drm/amd/dal/dc/basics/conversion.c | 224 +
 drivers/gpu/drm/amd/dal/dc/basics/conversion.h |  49 ++
 drivers/gpu/drm/amd/dal/dc/basics/grph_object_id.c | 134 +++
 drivers/gpu/drm/amd/dal/dc/basics/logger.c | 954 +
 drivers/gpu/drm/amd/dal/dc/basics/logger.h |  64 ++
 .../gpu/drm/amd/dal/dc/basics/register_logger.c| 197 +
 drivers/gpu/drm/amd/dal/dc/basics/signal_types.c   | 116 +++
 drivers/gpu/drm/amd/dal/dc/basics/vector.c | 309 +++
 11 files changed, 2126 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/Kconfig
 create mode 100644 drivers/gpu/drm/amd/dal/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/conversion.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/conversion.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/grph_object_id.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/logger.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/logger.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/register_logger.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/signal_types.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/vector.c

diff --git a/drivers/gpu/drm/amd/dal/Kconfig b/drivers/gpu/drm/amd/dal/Kconfig
new file mode 100644
index ..2289c0b10dae
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/Kconfig
@@ -0,0 +1,48 @@
+menu "Display Engine Configuration"
+   depends on DRM && (DRM_AMDSOC || DRM_AMDGPU)
+
+config DRM_AMD_DAL
+bool "AMD DAL - Enable new display engine
+help
+  Choose this option if you want to use the new display engine
+  support for AMD SOC.
+
+  Will be deprecated when the DAL component becomes stable and
+  AMDSOC will fully switch to it.
+
+config DRM_AMD_DAL_VBIOS_PRESENT
+bool "Video Bios available on board"
+depends on DRM_AMD_DAL
+help
+ This option is needed to allow a full range of feature
+support when working on
+x86 platforms and there is a VBIOS
+present in the system
+
+config DRM_AMD_DAL_DCE11_0
+bool "Carrizo family"
+depends on DRM_AMD_DAL
+help
+ Choose this option
+if you want to have
+CZ family
+for display engine
+
+config DRM_AMD_DAL_DCE10_0
+bool "VI family"
+depends on DRM_AMD_DAL
+help
+ Choose this option
+if you want to have
+VI family for display
+engine.
+
+config DEBUG_KERNEL_DAL
+bool "Enable kgdb break in DAL"
+depends on DRM_AMD_DAL
+help
+ Choose this option
+ if you want to hit
+ kdgb_break in assert.
+
+endmenu
diff --git a/drivers/gpu/drm/amd/dal/Makefile b/drivers/gpu/drm/amd/dal/Makefile
new file mode 100644
index ..25ae4646c4d3
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/Makefile
@@ -0,0 +1,21 @@
+#
+# Makefile for the DAL (Display Abstract Layer), which is a  sub-component
+# of the AMDGPU drm driver.
+# It provides the HW control for display related functionalities.
+
+AMDDALPATH = $(RELATIVE_AMD_DAL_PATH)
+
+subdir-ccflags-y += -Werror
+
+subdir-ccflags-y += -I$(AMDDALPATH)/ -I$(AMDDALPATH)/include
+
+subdir-ccflags-y += -I$(FULL_AMD_DAL_PATH)/dc/inc/
+
+#TODO: remove when Timing Sync feature is complete
+subdir-ccflags-y += -DBUILD_FEATURE_TIMING_SYNC=0
+
+DAL_LIBS = amdgpu_dm dc
+
+AMD_DAL = $(addsuffix /Makefile, $(addprefix 
$(FULL_AMD_DAL_PATH)/,$(DAL_LIBS)))
+
+include $(AMD_DAL)
diff --git a/drivers/gpu/drm/amd/dal/dc/basics/Makefile 
b/drivers/gpu/drm/amd/dal/dc/basics/Makefile
new file mode 100644
index ..6f382812fae3
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/basics/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile for the 'utils' sub-component of DAL.
+# It provides the general basic services required by other DAL
+# subcomponents.
+
+BASICS = conversion.o grph_object_id.o logger.o register_logger.o 
signal_types.o vector.o
+
+AMD_DAL_BASICS = $(addprefix $(AMDDALPATH)/dc/basics/,$(BASICS))
+
+AMD_DAL_FILES += $(AMD_DAL_BASICS)
diff --git a/drivers/gpu/d

[PATCH v2 03/26] drm/amd/dal: Fixed point arithmetic

2016-02-16 Thread Harry Wentland
Arithmetic operations on real numbers represented
as fixed-point numbers.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/basics/Makefile |   2 +-
 drivers/gpu/drm/amd/dal/dc/basics/fixpt31_32.c | 692 +
 drivers/gpu/drm/amd/dal/dc/basics/fixpt32_32.c | 223 
 3 files changed, 916 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/fixpt31_32.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/basics/fixpt32_32.c

diff --git a/drivers/gpu/drm/amd/dal/dc/basics/Makefile 
b/drivers/gpu/drm/amd/dal/dc/basics/Makefile
index 6f382812fae3..93e23714e411 100644
--- a/drivers/gpu/drm/amd/dal/dc/basics/Makefile
+++ b/drivers/gpu/drm/amd/dal/dc/basics/Makefile
@@ -3,7 +3,7 @@
 # It provides the general basic services required by other DAL
 # subcomponents.

-BASICS = conversion.o grph_object_id.o logger.o register_logger.o 
signal_types.o vector.o
+BASICS = conversion.o fixpt31_32.o fixpt32_32.o grph_object_id.o logger.o 
register_logger.o signal_types.o vector.o

 AMD_DAL_BASICS = $(addprefix $(AMDDALPATH)/dc/basics/,$(BASICS))

diff --git a/drivers/gpu/drm/amd/dal/dc/basics/fixpt31_32.c 
b/drivers/gpu/drm/amd/dal/dc/basics/fixpt31_32.c
new file mode 100644
index ..9f93b3b20634
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/basics/fixpt31_32.c
@@ -0,0 +1,692 @@
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dm_services.h"
+#include "include/fixed31_32.h"
+
+static inline uint64_t abs_i64(
+   int64_t arg)
+{
+   if (arg > 0)
+   return (uint64_t)arg;
+   else
+   return (uint64_t)(-arg);
+}
+
+/*
+ * @brief
+ * result = dividend / divisor
+ * *remainder = dividend % divisor
+ */
+static inline uint64_t complete_integer_division_u64(
+   uint64_t dividend,
+   uint64_t divisor,
+   uint64_t *remainder)
+{
+   uint64_t result;
+
+   ASSERT(divisor);
+
+   result = div64_u64_rem(dividend, divisor, remainder);
+
+   return result;
+}
+
+#define BITS_PER_FRACTIONAL_PART \
+   32
+
+#define FRACTIONAL_PART_MASK \
+   ((1ULL << BITS_PER_FRACTIONAL_PART) - 1)
+
+#define GET_INTEGER_PART(x) \
+   ((x) >> BITS_PER_FRACTIONAL_PART)
+
+#define GET_FRACTIONAL_PART(x) \
+   (FRACTIONAL_PART_MASK & (x))
+
+struct fixed31_32 dal_fixed31_32_from_fraction(
+   int64_t numerator,
+   int64_t denominator)
+{
+   struct fixed31_32 res;
+
+   bool arg1_negative = numerator < 0;
+   bool arg2_negative = denominator < 0;
+
+   uint64_t arg1_value = arg1_negative ? -numerator : numerator;
+   uint64_t arg2_value = arg2_negative ? -denominator : denominator;
+
+   uint64_t remainder;
+
+   /* determine integer part */
+
+   uint64_t res_value = complete_integer_division_u64(
+   arg1_value, arg2_value, );
+
+   ASSERT(res_value <= LONG_MAX);
+
+   /* determine fractional part */
+   {
+   uint32_t i = BITS_PER_FRACTIONAL_PART;
+
+   do {
+   remainder <<= 1;
+
+   res_value <<= 1;
+
+   if (remainder >= arg2_value) {
+   res_value |= 1;
+   remainder -= arg2_value;
+   }
+   } while (--i != 0);
+   }
+
+   /* round up LSB */
+   {
+   uint64_t summand = (remainder << 1) >= arg2_value;
+
+   ASSERT(res_value <= LLONG_MAX - summand);
+
+   res_value += summand;
+   }
+
+   res.value = (int64_t)res_value;
+
+   if (arg1_negative ^ arg2_negative)
+   res.value = -res.value;
+
+   return res;
+}
+
+struct fixed31_32 d

[PATCH v2 04/26] drm/amd/dal: Asic Capabilities

2016-02-16 Thread Harry Wentland
Add a generic way to manage display HW capabilities
for different ASICs and implement it for Carrizo.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 .../gpu/drm/amd/dal/dc/asic_capability/Makefile|  35 
 .../amd/dal/dc/asic_capability/asic_capability.c   | 190 +
 .../dc/asic_capability/carrizo_asic_capability.c   | 147 
 .../dc/asic_capability/carrizo_asic_capability.h   |  36 
 .../dal/dc/asic_capability/tonga_asic_capability.c | 146 
 .../dal/dc/asic_capability/tonga_asic_capability.h |  36 
 6 files changed, 590 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/asic_capability/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/asic_capability/asic_capability.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/asic_capability/carrizo_asic_capability.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/asic_capability/carrizo_asic_capability.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/asic_capability/tonga_asic_capability.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/asic_capability/tonga_asic_capability.h

diff --git a/drivers/gpu/drm/amd/dal/dc/asic_capability/Makefile 
b/drivers/gpu/drm/amd/dal/dc/asic_capability/Makefile
new file mode 100644
index ..8491b38ae726
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/asic_capability/Makefile
@@ -0,0 +1,35 @@
+#
+# Makefile for the 'asic_capability' sub-component of DAL.
+#
+
+ASIC_CAPABILITY = asic_capability.o
+
+AMD_DAL_ASIC_CAPABILITY = \
+   $(addprefix $(AMDDALPATH)/dc/asic_capability/,$(ASIC_CAPABILITY))
+
+AMD_DAL_FILES += $(AMD_DAL_ASIC_CAPABILITY)
+
+###
+# DCE 10x
+###
+ifdef CONFIG_DRM_AMD_DAL_DCE10_0
+ASIC_CAPABILITY_DCE10 = tonga_asic_capability.o
+
+AMD_DAL_ASIC_CAPABILITY_DCE10 = \
+   $(addprefix $(AMDDALPATH)/dc/asic_capability/,$(ASIC_CAPABILITY_DCE10))
+
+AMD_DAL_FILES += $(AMD_DAL_ASIC_CAPABILITY_DCE10)
+endif
+
+
+###
+# DCE 11x
+###
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+ASIC_CAPABILITY_DCE11 = carrizo_asic_capability.o
+
+AMD_DAL_ASIC_CAPABILITY_DCE11 = \
+   $(addprefix $(AMDDALPATH)/dc/asic_capability/,$(ASIC_CAPABILITY_DCE11))
+
+AMD_DAL_FILES += $(AMD_DAL_ASIC_CAPABILITY_DCE11)
+endif
diff --git a/drivers/gpu/drm/amd/dal/dc/asic_capability/asic_capability.c 
b/drivers/gpu/drm/amd/dal/dc/asic_capability/asic_capability.c
new file mode 100644
index ..7a905f532040
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/asic_capability/asic_capability.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dm_services.h"
+
+#include "include/logger_interface.h"
+
+#include "include/asic_capability_interface.h"
+#include "include/asic_capability_types.h"
+#include "include/dal_types.h"
+#include "include/dal_asic_id.h"
+
+#if defined(CONFIG_DRM_AMD_DAL_DCE10_0)
+#include "tonga_asic_capability.h"
+#endif
+
+#if defined(CONFIG_DRM_AMD_DAL_DCE11_0)
+#include "carrizo_asic_capability.h"
+#endif
+
+/*
+ * Initializes asic_capability instance.
+ */
+static bool construct(
+   struct asic_capability *cap,
+   struct hw_asic_id *init,
+   struct dc_context *ctx)
+{
+   bool asic_supported = false;
+
+   cap->ctx = ctx;
+   dm_memset(cap->data, 0, sizeof(cap->data));
+
+   /* ASIC data */
+   cap->data[ASIC_DATA_VRAM_TYPE] = init->vram_type;
+   cap->data[ASIC_DATA_VRAM_BITWIDTH] = init->vram_width;
+   cap-

[PATCH v2 05/26] drm/amd/dal: GPIO (General Purpose IO)

2016-02-16 Thread Harry Wentland
Manages all DCE GPIO pins. The pins are represented as generic IO
handles as well as handles dedicated for certain functions, such as
DDC, HPD, and DVO.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/gpio/Makefile   |  32 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.c | 882 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.h |  46 ++
 .../drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.c |  81 ++
 .../drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.h |  32 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.c | 366 +
 .../gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.h |  47 ++
 .../amd/dal/dc/gpio/dce110/hw_translate_dce110.c   | 400 ++
 .../amd/dal/dc/gpio/dce110/hw_translate_dce110.h   |  34 +
 drivers/gpu/drm/amd/dal/dc/gpio/ddc.c  | 290 +++
 drivers/gpu/drm/amd/dal/dc/gpio/ddc.h  |  45 ++
 .../drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.c  |  97 +++
 .../drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.h  |  34 +
 .../amd/dal/dc/gpio/diagnostics/hw_factory_diag.c  |  65 ++
 .../amd/dal/dc/gpio/diagnostics/hw_factory_diag.h  |  32 +
 .../drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.c  | 101 +++
 .../drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.h  |  35 +
 .../dal/dc/gpio/diagnostics/hw_translate_diag.c|  41 +
 .../dal/dc/gpio/diagnostics/hw_translate_diag.h|  34 +
 drivers/gpu/drm/amd/dal/dc/gpio/gpio.h |  48 ++
 drivers/gpu/drm/amd/dal/dc/gpio/gpio_base.c| 279 +++
 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.c | 386 +
 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.h |  57 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.c   | 104 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.h   |  60 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.c   |  93 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.h   |  71 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.c  | 407 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.h  | 129 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.c  |  92 +++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.h  |  47 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pin.c  |  85 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pin.h  |  79 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_hpd.c   |  87 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_hpd.h   |  45 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_translate.c |  77 ++
 drivers/gpu/drm/amd/dal/dc/gpio/hw_translate.h |  50 ++
 drivers/gpu/drm/amd/dal/dc/gpio/irq.c  | 180 +
 drivers/gpu/drm/amd/dal/dc/gpio/irq.h  |  42 +
 39 files changed, 5112 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_ddc_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_factory_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_hpd_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_translate_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/dce110/hw_translate_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/ddc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/ddc.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_ddc_diag.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_factory_diag.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_factory_diag.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_hpd_diag.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_translate_diag.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpio/diagnostics/hw_translate_diag.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio_base.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/gpio_service.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_ddc.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_factory.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pad.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpio/hw_gpio_pin.c
 create mode 100644 drivers

[PATCH v2 08/26] drm/amd/dal: I2C Aux Manager

2016-02-16 Thread Harry Wentland
Implements low-level communication layer over I2C and Aux lines using
GPIO handles.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/i2caux/Makefile |  33 +
 drivers/gpu/drm/amd/dal/dc/i2caux/aux_engine.c | 567 
 drivers/gpu/drm/amd/dal/dc/i2caux/aux_engine.h | 119 +++
 .../amd/dal/dc/i2caux/dce110/aux_engine_dce110.c   | 788 +
 .../amd/dal/dc/i2caux/dce110/aux_engine_dce110.h   |  56 ++
 .../i2caux/dce110/i2c_generic_hw_engine_dce110.h   |  25 +
 .../dal/dc/i2caux/dce110/i2c_hw_engine_dce110.c| 954 +
 .../dal/dc/i2caux/dce110/i2c_hw_engine_dce110.h|  58 ++
 .../dal/dc/i2caux/dce110/i2c_sw_engine_dce110.c| 172 
 .../dal/dc/i2caux/dce110/i2c_sw_engine_dce110.h|  43 +
 .../drm/amd/dal/dc/i2caux/dce110/i2caux_dce110.c   | 266 ++
 .../drm/amd/dal/dc/i2caux/dce110/i2caux_dce110.h   |  39 +
 .../amd/dal/dc/i2caux/diagnostics/i2caux_diag.c| 112 +++
 .../amd/dal/dc/i2caux/diagnostics/i2caux_diag.h|  33 +
 drivers/gpu/drm/amd/dal/dc/i2caux/engine.h | 129 +++
 drivers/gpu/drm/amd/dal/dc/i2caux/engine_base.c|  67 ++
 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_engine.c | 121 +++
 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_engine.h | 113 +++
 .../drm/amd/dal/dc/i2caux/i2c_generic_hw_engine.c  | 286 ++
 .../drm/amd/dal/dc/i2caux/i2c_generic_hw_engine.h  |  77 ++
 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_hw_engine.c  | 246 ++
 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_hw_engine.h  |  80 ++
 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_sw_engine.c  | 614 +
 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_sw_engine.h  |  81 ++
 drivers/gpu/drm/amd/dal/dc/i2caux/i2caux.c | 529 
 drivers/gpu/drm/amd/dal/dc/i2caux/i2caux.h | 123 +++
 26 files changed, 5731 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/aux_engine.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/aux_engine.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/dce110/aux_engine_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/dce110/aux_engine_dce110.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/i2caux/dce110/i2c_generic_hw_engine_dce110.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/i2caux/dce110/i2c_hw_engine_dce110.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/i2caux/dce110/i2c_hw_engine_dce110.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/i2caux/dce110/i2c_sw_engine_dce110.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/i2caux/dce110/i2c_sw_engine_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/dce110/i2caux_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/dce110/i2caux_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/diagnostics/i2caux_diag.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/diagnostics/i2caux_diag.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/engine.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/engine_base.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_engine.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_engine.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_generic_hw_engine.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_generic_hw_engine.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_hw_engine.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_hw_engine.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_sw_engine.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2c_sw_engine.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2caux.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/i2caux/i2caux.h

diff --git a/drivers/gpu/drm/amd/dal/dc/i2caux/Makefile 
b/drivers/gpu/drm/amd/dal/dc/i2caux/Makefile
new file mode 100644
index ..390d83d649f5
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/i2caux/Makefile
@@ -0,0 +1,33 @@
+#
+# Makefile for the 'i2c' sub-component of DAL.
+# It provides the control and status of HW i2c engine of the adapter.
+
+I2CAUX = aux_engine.o engine_base.o i2caux.o i2c_engine.o \
+i2c_generic_hw_engine.o i2c_hw_engine.o i2c_sw_engine.o
+
+AMD_DAL_I2CAUX = $(addprefix $(AMDDALPATH)/dc/i2caux/,$(I2CAUX))
+
+AMD_DAL_FILES += $(AMD_DAL_I2CAUX)
+
+
+###
+# DCE 11x family
+###
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+I2CAUX_DCE110 = i2caux_dce110.o i2c_sw_engine_dce110.o i2c_hw_engine_dce110.o \
+   aux_engine_dce110.o
+
+AMD_DAL_I2CAUX_DCE110 = $(addprefix 
$(AMDDALPATH)/dc/i2caux/dce110/,$(I2CAUX_DCE110))
+
+AMD_DAL_FILES += $(AMD_DAL_I2CAUX_DCE110)
+endif
+
+###
+# Diagnostics on FPGA

[PATCH v2 06/26] drm/amd/dal: Adapter Service

2016-02-16 Thread Harry Wentland
Provides information about ASIC features and capabilities. Also provides
access to ASIC resources such as VBIOS, GPIO and I2cAux Manager

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/adapter/Makefile|   24 +
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.c   | 2089 
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.h   |   71 +
 .../adapter/dce110/hw_ctx_adapter_service_dce110.c |  304 +++
 .../adapter/dce110/hw_ctx_adapter_service_dce110.h |   40 +
 .../diagnostics/hw_ctx_adapter_service_diag.c  |  133 ++
 .../diagnostics/hw_ctx_adapter_service_diag.h  |   33 +
 .../amd/dal/dc/adapter/hw_ctx_adapter_service.c|  164 ++
 .../amd/dal/dc/adapter/hw_ctx_adapter_service.h|   86 +
 .../drm/amd/dal/dc/adapter/wireless_data_source.c  |  208 ++
 .../drm/amd/dal/dc/adapter/wireless_data_source.h  |   80 +
 11 files changed, 3232 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/adapter/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/adapter/adapter_service.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/adapter/adapter_service.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/adapter/dce110/hw_ctx_adapter_service_dce110.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/adapter/dce110/hw_ctx_adapter_service_dce110.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/adapter/diagnostics/hw_ctx_adapter_service_diag.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/adapter/diagnostics/hw_ctx_adapter_service_diag.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/adapter/hw_ctx_adapter_service.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/adapter/hw_ctx_adapter_service.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/adapter/wireless_data_source.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/adapter/wireless_data_source.h

diff --git a/drivers/gpu/drm/amd/dal/dc/adapter/Makefile 
b/drivers/gpu/drm/amd/dal/dc/adapter/Makefile
new file mode 100644
index ..2c6ca7a513bd
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/adapter/Makefile
@@ -0,0 +1,24 @@
+#
+# Makefile for the 'adapter' sub-component of DAL.
+# It provides the control and status of HW adapter.
+
+ADAPTER = adapter_service.o hw_ctx_adapter_service.o wireless_data_source.o
+
+AMD_DAL_ADAPTER = $(addprefix $(AMDDALPATH)/dc/adapter/,$(ADAPTER))
+
+AMD_DAL_FILES += $(AMD_DAL_ADAPTER)
+
+
+###
+# DCE 11x
+###
+
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+AMD_DAL_FILES += 
$(AMDDALPATH)/dc/adapter/dce110/hw_ctx_adapter_service_dce110.o
+endif
+
+###
+# FPGA Diagnositcs
+###
+
+AMD_DAL_FILES += 
$(AMDDALPATH)/dc/adapter/diagnostics/hw_ctx_adapter_service_diag.o
diff --git a/drivers/gpu/drm/amd/dal/dc/adapter/adapter_service.c 
b/drivers/gpu/drm/amd/dal/dc/adapter/adapter_service.c
new file mode 100644
index ..dd2f931fe9a1
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/adapter/adapter_service.c
@@ -0,0 +1,2089 @@
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dm_services.h"
+
+#include "dc_bios_types.h"
+
+#include "include/adapter_service_interface.h"
+#include "include/i2caux_interface.h"
+#include "include/asic_capability_types.h"
+#include "include/gpio_service_interface.h"
+#include "include/asic_capability_interface.h"
+#include "include/logger_interface.h"
+
+#include "adapter_service.h"
+
+#include "hw_ctx_adapter_service.h"
+#include "wireless_data_source.h"
+
+#include "

[PATCH v2 09/26] drm/amd/dal: IRQ Service

2016-02-16 Thread Harry Wentland
Interface to set and ack DCE interrupts.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/irq/Makefile|  21 ++
 .../drm/amd/dal/dc/irq/dce110/irq_service_dce110.c | 389 +
 .../drm/amd/dal/dc/irq/dce110/irq_service_dce110.h |  34 ++
 drivers/gpu/drm/amd/dal/dc/irq/irq_service.c   | 177 ++
 drivers/gpu/drm/amd/dal/dc/irq/irq_service.h   |  85 +
 5 files changed, 706 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/irq/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/irq/dce110/irq_service_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/irq/dce110/irq_service_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/irq/irq_service.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/irq/irq_service.h

diff --git a/drivers/gpu/drm/amd/dal/dc/irq/Makefile 
b/drivers/gpu/drm/amd/dal/dc/irq/Makefile
new file mode 100644
index ..f1c5faf94b83
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/irq/Makefile
@@ -0,0 +1,21 @@
+#
+# Makefile for the 'audio' sub-component of DAL.
+# It provides the control and status of HW adapter resources,
+# that are global for the ASIC and sharable between pipes.
+
+IRQ = irq_service.o
+
+AMD_DAL_IRQ = $(addprefix $(AMDDALPATH)/dc/irq/,$(IRQ))
+
+AMD_DAL_FILES += $(AMD_DAL_IRQ)
+
+###
+# DCE 11x
+###
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+IRQ_DCE11 = irq_service_dce110.o
+
+AMD_DAL_IRQ_DCE11 = $(addprefix $(AMDDALPATH)/dc/irq/dce110/,$(IRQ_DCE11))
+
+AMD_DAL_FILES += $(AMD_DAL_IRQ_DCE11)
+endif
diff --git a/drivers/gpu/drm/amd/dal/dc/irq/dce110/irq_service_dce110.c 
b/drivers/gpu/drm/amd/dal/dc/irq/dce110/irq_service_dce110.c
new file mode 100644
index ..4085b6f6e7fd
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/irq/dce110/irq_service_dce110.c
@@ -0,0 +1,389 @@
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dm_services.h"
+
+#include "include/logger_interface.h"
+
+#include "irq_service_dce110.h"
+
+#include "dce/dce_11_0_d.h"
+#include "dce/dce_11_0_sh_mask.h"
+#include "ivsrcid/ivsrcid_vislands30.h"
+
+static bool hpd_ack(
+   struct irq_service *irq_service,
+   const struct irq_source_info *info)
+{
+   uint32_t addr = info->status_reg;
+   uint32_t value = dm_read_reg(irq_service->ctx, addr);
+   uint32_t current_status =
+   get_reg_field_value(
+   value,
+   DC_HPD_INT_STATUS,
+   DC_HPD_SENSE_DELAYED);
+
+   dal_irq_service_ack_generic(irq_service, info);
+
+   value = dm_read_reg(irq_service->ctx, info->enable_reg);
+
+   set_reg_field_value(
+   value,
+   current_status ? 0 : 1,
+   DC_HPD_INT_CONTROL,
+   DC_HPD_INT_POLARITY);
+
+   dm_write_reg(irq_service->ctx, info->enable_reg, value);
+
+   return true;
+}
+
+static const struct irq_source_info_funcs hpd_irq_info_funcs = {
+   .set = NULL,
+   .ack = hpd_ack
+};
+
+static const struct irq_source_info_funcs hpd_rx_irq_info_funcs = {
+   .set = NULL,
+   .ack = NULL
+};
+
+static const struct irq_source_info_funcs pflip_irq_info_funcs = {
+   .set = NULL,
+   .ack = NULL
+};
+
+static const struct irq_source_info_funcs vblank_irq_info_funcs = {
+   .set = NULL,
+   .ack = NULL
+};
+
+#define hpd_int_entry(reg_num)\
+   [DC_IRQ_SOURCE_HPD1 + reg_num] = {\
+   .enable_reg = mmHPD ## reg_num ## _DC_HPD_INT_CONTROL,\
+   .enable_mask = DC_HPD_INT_CONTROL__DC_HPD_INT_EN_MASK,\

[PATCH v2 10/26] drm/amd/dal: GPU

2016-02-16 Thread Harry Wentland
Encapsulates programming for HW blocks which are shared between display
paths, such as clock sources.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/gpu/Makefile|  22 +
 .../gpu/drm/amd/dal/dc/gpu/dc_clock_generator.c|  92 ++
 .../gpu/drm/amd/dal/dc/gpu/dc_clock_generator.h|  63 ++
 .../amd/dal/dc/gpu/dce110/dc_clock_gating_dce110.c |  90 ++
 .../amd/dal/dc/gpu/dce110/dc_clock_gating_dce110.h |  33 +
 .../amd/dal/dc/gpu/dce110/display_clock_dce110.c   | 968 +
 .../amd/dal/dc/gpu/dce110/display_clock_dce110.h   |  53 ++
 drivers/gpu/drm/amd/dal/dc/gpu/display_clock.c | 205 +
 drivers/gpu/drm/amd/dal/dc/gpu/display_clock.h |  82 ++
 drivers/gpu/drm/amd/dal/dc/gpu/divider_range.c | 127 +++
 drivers/gpu/drm/amd/dal/dc/gpu/divider_range.h |  63 ++
 11 files changed, 1798 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/dc_clock_generator.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/dc_clock_generator.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpu/dce110/dc_clock_gating_dce110.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/gpu/dce110/dc_clock_gating_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/dce110/display_clock_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/dce110/display_clock_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/display_clock.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/display_clock.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/divider_range.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/gpu/divider_range.h

diff --git a/drivers/gpu/drm/amd/dal/dc/gpu/Makefile 
b/drivers/gpu/drm/amd/dal/dc/gpu/Makefile
new file mode 100644
index ..b481a6d5c6bb
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/gpu/Makefile
@@ -0,0 +1,22 @@
+#
+# Makefile for the 'gpu' sub-component of DAL.
+# It provides the control and status of HW adapter resources,
+# that are global for the ASIC and sharable between pipes.
+
+GPU = dc_clock_generator.o display_clock.o divider_range.o
+
+AMD_DAL_GPU = $(addprefix $(AMDDALPATH)/dc/gpu/,$(GPU))
+
+AMD_DAL_FILES += $(AMD_DAL_GPU)
+
+
+###
+# DCE 110 family
+###
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+GPU_DCE110 = display_clock_dce110.o dc_clock_gating_dce110.o
+
+AMD_DAL_GPU_DCE110 = $(addprefix $(AMDDALPATH)/dc/gpu/dce110/,$(GPU_DCE110))
+
+AMD_DAL_FILES += $(AMD_DAL_GPU_DCE110)
+endif
diff --git a/drivers/gpu/drm/amd/dal/dc/gpu/dc_clock_generator.c 
b/drivers/gpu/drm/amd/dal/dc/gpu/dc_clock_generator.c
new file mode 100644
index ..b3b0f99933f7
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/gpu/dc_clock_generator.c
@@ -0,0 +1,92 @@
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dm_services.h"
+
+#include "dc_clock_generator.h"
+
+void dal_dc_clock_generator_destroy(struct dc_clock_generator **dc)
+{
+   if (dc == NULL || *dc == NULL) {
+   BREAK_TO_DEBUGGER();
+   return;
+   }
+
+   (*dc)->funcs->destroy(dc);
+
+   *dc = NULL;
+}
+
+void dal_dc_clock_generator_set_display_pipe_mapping(
+   struct dc_clock_generator *dc_clk_gen,
+   struct dccg_mapping_params *params)
+{
+   dc_clk_gen->funcs->set_display_pipe_mapping(dc_clk_gen, params);
+}
+
+bool dal_dc_clock_generator_get_dp_ref_clk_ds_params(
+   struct dc_clock_generator *dc_clk_gen,
+   struct dccg_dp_ref_clk_ds_params *params)
+{
+   return dc_clk_gen->funcs->get_dp_ref_clk_ds_params(dc_clk_gen, params);
+}
+
+bool dal_dc_clock_generator_enable_

[PATCH v2 11/26] drm/amd/dal: Audio

2016-02-16 Thread Harry Wentland
Responsible for programming the audio encoder in the display path.

Signed-off-by: Harry Wentland 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/dal/dc/audio/Makefile  |   22 +
 drivers/gpu/drm/amd/dal/dc/audio/audio.h   |  195 ++
 drivers/gpu/drm/amd/dal/dc/audio/audio_base.c  |  470 +
 .../gpu/drm/amd/dal/dc/audio/dce110/audio_dce110.c |  453 +
 .../gpu/drm/amd/dal/dc/audio/dce110/audio_dce110.h |   42 +
 .../amd/dal/dc/audio/dce110/hw_ctx_audio_dce110.c  | 1930 
 .../amd/dal/dc/audio/dce110/hw_ctx_audio_dce110.h  |   47 +
 drivers/gpu/drm/amd/dal/dc/audio/hw_ctx_audio.c|  771 
 drivers/gpu/drm/amd/dal/dc/audio/hw_ctx_audio.h|  285 +++
 9 files changed, 4215 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/dal/dc/audio/Makefile
 create mode 100644 drivers/gpu/drm/amd/dal/dc/audio/audio.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/audio/audio_base.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/audio/dce110/audio_dce110.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/audio/dce110/audio_dce110.h
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/audio/dce110/hw_ctx_audio_dce110.c
 create mode 100644 
drivers/gpu/drm/amd/dal/dc/audio/dce110/hw_ctx_audio_dce110.h
 create mode 100644 drivers/gpu/drm/amd/dal/dc/audio/hw_ctx_audio.c
 create mode 100644 drivers/gpu/drm/amd/dal/dc/audio/hw_ctx_audio.h

diff --git a/drivers/gpu/drm/amd/dal/dc/audio/Makefile 
b/drivers/gpu/drm/amd/dal/dc/audio/Makefile
new file mode 100644
index ..0999372cecf0
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/audio/Makefile
@@ -0,0 +1,22 @@
+#
+# Makefile for the 'audio' sub-component of DAL.
+# It provides the control and status of HW adapter resources,
+# that are global for the ASIC and sharable between pipes.
+
+AUDIO = audio_base.o hw_ctx_audio.o
+
+AMD_DAL_AUDIO = $(addprefix $(AMDDALPATH)/dc/audio/,$(AUDIO))
+
+AMD_DAL_FILES += $(AMD_DAL_AUDIO)
+
+
+###
+# DCE 11x
+###
+ifdef CONFIG_DRM_AMD_DAL_DCE11_0
+AUDIO_DCE11 = audio_dce110.o hw_ctx_audio_dce110.o
+
+AMD_DAL_AUDIO_DCE11 = $(addprefix 
$(AMDDALPATH)/dc/audio/dce110/,$(AUDIO_DCE11))
+
+AMD_DAL_FILES += $(AMD_DAL_AUDIO_DCE11)
+endif
diff --git a/drivers/gpu/drm/amd/dal/dc/audio/audio.h 
b/drivers/gpu/drm/amd/dal/dc/audio/audio.h
new file mode 100644
index ..ad2dc18ef37b
--- /dev/null
+++ b/drivers/gpu/drm/amd/dal/dc/audio/audio.h
@@ -0,0 +1,195 @@
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#ifndef __DAL_AUDIO_H__
+#define __DAL_AUDIO_H__
+
+#include "include/audio_interface.h"
+#include "hw_ctx_audio.h"
+#include "include/link_service_types.h"
+
+/* only for hook functions  */
+/**
+ *which will be overwritten by derived audio object.
+ *audio hw context object is independent object
+ */
+
+struct audio;
+
+struct audio_funcs {
+   /*
+*get_object_id
+*get_object_type
+*enumerate_input_signals
+*enumerate_output_signals
+*is_input_signal_supported
+*is_output_signal_supported
+*set_object_properties
+*get_object_properties
+*/
+
+   void (*destroy)(struct audio **audio);
+   /*power_up
+*power_down
+*release_hw_base
+*/
+
+   /* setup audio */
+   enum audio_result (*setup)(
+   struct audio *audio,
+   struct audio_output *output,
+   struct audio_info *info);
+
+   enum audio_result (*enable_output)(
+   struct audio *audio,
+   enum engine_id engine_id,
+   enum signal_type signal);
+
+   enum audio_result (*disable_output)(
+   struct audi

[PATCH 2/2] drm/dp/mst: save vcpi with payloads

2015-12-07 Thread Harry Wentland
This makes it possibly for drivers to find the associated
mst_port by looking at the payload allocation table.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 64a0a3729643..3b6627dde9ff 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1673,6 +1673,7 @@ int drm_dp_update_payload_part1(struct 
drm_dp_mst_topology_mgr *mgr)
if (mgr->proposed_vcpis[i]) {
port = container_of(mgr->proposed_vcpis[i], struct 
drm_dp_mst_port, vcpi);
req_payload.num_slots = 
mgr->proposed_vcpis[i]->num_slots;
+   req_payload.vcpi = mgr->proposed_vcpis[i]->vcpi;
} else {
port = NULL;
req_payload.num_slots = 0;
@@ -1688,6 +1689,7 @@ int drm_dp_update_payload_part1(struct 
drm_dp_mst_topology_mgr *mgr)
if (req_payload.num_slots) {
drm_dp_create_payload_step1(mgr, 
mgr->proposed_vcpis[i]->vcpi, _payload);
mgr->payloads[i].num_slots = 
req_payload.num_slots;
+   mgr->payloads[i].vcpi = req_payload.vcpi;
} else if (mgr->payloads[i].num_slots) {
mgr->payloads[i].num_slots = 0;
drm_dp_destroy_payload_step1(mgr, port, 
port->vcpi.vcpi, >payloads[i]);
-- 
2.1.4



[PATCH 1/2] drm/dp/mst: reply with ACK for UP reqs

2015-12-07 Thread Harry Wentland
From: Mykola Lysenko 

Currently we reply with NACK to UP requests which might
confuse receivers. We haven't seen any actual issues with
this but should still respond to UP requests correctly.

Signed-off-by: Mykola Lysenko 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 809959d56d78..64a0a3729643 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1823,7 +1823,7 @@ static int drm_dp_encode_up_ack_reply(struct 
drm_dp_sideband_msg_tx *msg, u8 req
 {
struct drm_dp_sideband_msg_reply_body reply;

-   reply.reply_type = 1;
+   reply.reply_type = 0;
reply.req_type = req_type;
drm_dp_encode_sideband_reply(, msg);
return 0;
-- 
2.1.4



[PATCH 0/2] Two small patches for MST

2015-12-07 Thread Harry Wentland
Two minor patches for MST here. We were replying NACK to UP requests
when we intended to ACK them. We were also not filling in the vcpi
field for mst_mgr->payloads although it's defined. Saving the vcpi
simplifies the new amdgpu MST implementation that we currently work
on.

Harry Wentland (1):
  drm/dp/mst: save vcpi with payloads

Mykola Lysenko (1):
  drm/dp/mst: reply with ACK for UP reqs

 drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.1.4



[PATCH] drm: Print pid in drm log

2015-12-18 Thread Harry Wentland
From: Andrey Grodzovsky 

Add task ids to all DRM prints so it is easier to resolve
concurency issues and understand the logic.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/drm_drv.c | 16 +---
 include/drm/drmP.h|  6 --
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7dd6728dd092..7b17a9ae0b07 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -55,6 +55,16 @@ static struct idr drm_minors_idr;

 static struct dentry *drm_debugfs_root;

+pid_t get_my_pid(void) {
+
+   if (!in_interrupt())
+   return current->pid;
+
+   return 0;
+}
+
+EXPORT_SYMBOL(get_my_pid);
+
 void drm_err(const char *format, ...)
 {
struct va_format vaf;
@@ -65,8 +75,8 @@ void drm_err(const char *format, ...)
vaf.fmt = format;
vaf.va = 

-   printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
-  __builtin_return_address(0), );
+   printk(KERN_ERR "[%u][" DRM_NAME ":%ps] *ERROR* %pV",
+   get_my_pid(),__builtin_return_address(0), );

va_end(args);
 }
@@ -81,7 +91,7 @@ void drm_ut_debug_printk(const char *function_name, const 
char *format, ...)
vaf.fmt = format;
vaf.va = 

-   printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, );
+   printk(KERN_DEBUG "[%u][" DRM_NAME ":%s] %pV",get_my_pid(), 
function_name, );

va_end(args);
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5531d7bbe851..4b17f890ca14 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -183,11 +183,13 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })

+pid_t get_my_pid(void);
+
 #define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
+   printk(KERN_INFO "[%u][" DRM_NAME "] " fmt,get_my_pid(), ##__VA_ARGS__)

 #define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
+   printk_once(KERN_INFO "[%u][" DRM_NAME "] " fmt,get_my_pid(), 
##__VA_ARGS__)

 /**
  * Debug output.
-- 
2.1.4



[PATCH 0/2] Fix MST with downstream branches

2015-12-18 Thread Harry Wentland
Two MST patches that we discovered during MST bringup
with two daisy-chained MST displays.

Mykola Lysenko (2):
  drm/dp/mst: process broadcast messages correctly
  drm/dp/mst: always send reply for UP request

 drivers/gpu/drm/drm_dp_mst_topology.c | 125 ++
 include/drm/drm_dp_mst_helper.h   |   2 -
 2 files changed, 95 insertions(+), 32 deletions(-)

-- 
2.1.4



[PATCH 1/2] drm/dp/mst: process broadcast messages correctly

2015-12-18 Thread Harry Wentland
From: Mykola Lysenko 

In case broadcast message received in UP request,
RAD cannot be used to identify message originator.
Message should be parsed, originator should be found
by GUID from parsed message.

Also reply with broadcast in case broadcast message
received (for now it is always broadcast)

Signed-off-by: Mykola Lysenko 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 95 +++
 1 file changed, 84 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 809959d56d78..3baa95c1b14b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1210,6 +1210,50 @@ out:
return mstb;
 }

+static struct drm_dp_mst_branch *get_mst_branch_device_by_guid_helper(
+   struct drm_dp_mst_branch *mstb,
+   uint8_t *guid)
+{
+   struct drm_dp_mst_branch *found_mstb;
+   struct drm_dp_mst_port *port;
+
+   list_for_each_entry(port, >ports, next) {
+   if (!port->mstb)
+   continue;
+
+   if (port->guid_valid && memcmp(port->guid, guid, 16) == 0)
+   return port->mstb;
+
+   found_mstb = get_mst_branch_device_by_guid_helper(port->mstb, 
guid);
+
+   if (found_mstb)
+   return found_mstb;
+   }
+
+   return NULL;
+}
+
+static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device_by_guid(
+   struct drm_dp_mst_topology_mgr *mgr,
+   uint8_t *guid)
+{
+   struct drm_dp_mst_branch *mstb;
+
+   /* find the port by iterating down */
+   mutex_lock(>lock);
+
+   if (mgr->guid_valid && memcmp(mgr->guid, guid, 16) == 0)
+   mstb = mgr->mst_primary;
+   else
+   mstb = get_mst_branch_device_by_guid_helper(mgr->mst_primary, 
guid);
+
+   if (mstb)
+   kref_get(>kref);
+
+   mutex_unlock(>lock);
+   return mstb;
+}
+
 static void drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr 
*mgr,
   struct drm_dp_mst_branch *mstb)
 {
@@ -1320,6 +1364,7 @@ static int set_hdr_from_dst_qlock(struct 
drm_dp_sideband_msg_hdr *hdr,
  struct drm_dp_sideband_msg_tx *txmsg)
 {
struct drm_dp_mst_branch *mstb = txmsg->dst;
+   u8 req_type;

/* both msg slots are full */
if (txmsg->seqno == -1) {
@@ -1336,7 +1381,13 @@ static int set_hdr_from_dst_qlock(struct 
drm_dp_sideband_msg_hdr *hdr,
txmsg->seqno = 1;
mstb->tx_slots[txmsg->seqno] = txmsg;
}
-   hdr->broadcast = 0;
+
+   req_type = txmsg->msg[0] & 0x7f;
+   if (req_type == DP_CONNECTION_STATUS_NOTIFY ||
+   req_type == DP_RESOURCE_STATUS_NOTIFY)
+   hdr->broadcast = 1;
+   else
+   hdr->broadcast = 0;
hdr->path_msg = txmsg->path_msg;
hdr->lct = mstb->lct;
hdr->lcr = mstb->lct - 1;
@@ -2145,28 +2196,50 @@ static int drm_dp_mst_handle_up_req(struct 
drm_dp_mst_topology_mgr *mgr)

if (mgr->up_req_recv.have_eomt) {
struct drm_dp_sideband_msg_req_body msg;
-   struct drm_dp_mst_branch *mstb;
+   struct drm_dp_mst_branch *mstb = NULL;
bool seqno;
-   mstb = drm_dp_get_mst_branch_device(mgr,
-   
mgr->up_req_recv.initial_hdr.lct,
-   
mgr->up_req_recv.initial_hdr.rad);
-   if (!mstb) {
-   DRM_DEBUG_KMS("Got MST reply from unknown device %d\n", 
mgr->up_req_recv.initial_hdr.lct);
-   memset(>up_req_recv, 0, sizeof(struct 
drm_dp_sideband_msg_rx));
-   return 0;
+
+   if (!mgr->up_req_recv.initial_hdr.broadcast) {
+   mstb = drm_dp_get_mst_branch_device(mgr,
+   
mgr->up_req_recv.initial_hdr.lct,
+   
mgr->up_req_recv.initial_hdr.rad);
+   if (!mstb) {
+   DRM_DEBUG_KMS("Got MST reply from unknown 
device %d\n", mgr->up_req_recv.initial_hdr.lct);
+   memset(>up_req_recv, 0, sizeof(struct 
drm_dp_sideband_msg_rx));
+   return 0;
+   }
}

seqno = mgr->up_req_recv.initial_hdr.seqno;
drm_dp_sideband_parse_req(>up_req_recv, );

if (msg.req_type == DP_CONNECTION_STATUS_NOTIFY) {
-   drm_dp_send_up_ack_reply(mgr, mstb, msg.req_type, 
seqno, false);
+   drm_dp_send_up_ack_reply(mgr, mgr->mst_primary, 
msg.req_type, seqno, false);
+
+   if (!mstb)
+  

[PATCH 2/2] drm/dp/mst: always send reply for UP request

2015-12-18 Thread Harry Wentland
From: Mykola Lysenko 

We should always send reply for UP request in order
to make downstream device clean-up resources appropriately.

Issue was that reply for UP request was sent only once.

Signed-off-by: Mykola Lysenko 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 30 +++---
 include/drm/drm_dp_mst_helper.h   |  2 --
 2 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 3baa95c1b14b..bda9be9a3087 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1489,26 +1489,18 @@ static void process_single_down_tx_qlock(struct 
drm_dp_mst_topology_mgr *mgr)
 }

 /* called holding qlock */
-static void process_single_up_tx_qlock(struct drm_dp_mst_topology_mgr *mgr)
+static void process_single_up_tx_qlock(struct drm_dp_mst_topology_mgr *mgr,
+  struct drm_dp_sideband_msg_tx *txmsg)
 {
-   struct drm_dp_sideband_msg_tx *txmsg;
int ret;

/* construct a chunk from the first msg in the tx_msg queue */
-   if (list_empty(>tx_msg_upq)) {
-   mgr->tx_up_in_progress = false;
-   return;
-   }
-
-   txmsg = list_first_entry(>tx_msg_upq, struct 
drm_dp_sideband_msg_tx, next);
ret = process_single_tx_qlock(mgr, txmsg, true);
-   if (ret == 1) {
-   /* up txmsgs aren't put in slots - so free after we send it */
-   list_del(>next);
-   kfree(txmsg);
-   } else if (ret)
+
+   if (ret != 1)
DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
-   mgr->tx_up_in_progress = true;
+
+   txmsg->dst->tx_slots[txmsg->seqno] = NULL;
 }

 static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
@@ -1895,11 +1887,12 @@ static int drm_dp_send_up_ack_reply(struct 
drm_dp_mst_topology_mgr *mgr,
drm_dp_encode_up_ack_reply(txmsg, req_type);

mutex_lock(>qlock);
-   list_add_tail(>next, >tx_msg_upq);
-   if (!mgr->tx_up_in_progress) {
-   process_single_up_tx_qlock(mgr);
-   }
+
+   process_single_up_tx_qlock(mgr, txmsg);
+
mutex_unlock(>qlock);
+
+   kfree(txmsg);
return 0;
 }

@@ -2809,7 +2802,6 @@ int drm_dp_mst_topology_mgr_init(struct 
drm_dp_mst_topology_mgr *mgr,
mutex_init(>qlock);
mutex_init(>payload_lock);
mutex_init(>destroy_connector_lock);
-   INIT_LIST_HEAD(>tx_msg_upq);
INIT_LIST_HEAD(>tx_msg_downq);
INIT_LIST_HEAD(>destroy_connector_list);
INIT_WORK(>work, drm_dp_mst_link_probe_work);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 5340099741ae..006062a27639 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -450,9 +450,7 @@ struct drm_dp_mst_topology_mgr {
   the mstb tx_slots and txmsg->state once they are queued */
struct mutex qlock;
struct list_head tx_msg_downq;
-   struct list_head tx_msg_upq;
bool tx_down_in_progress;
-   bool tx_up_in_progress;

/* payload info + lock for it */
struct mutex payload_lock;
-- 
2.1.4



[PATCH 5/7] [RFC] drm/amdgpu: drop DVO encoders support.

2016-04-14 Thread Harry Wentland
DVO was mainly used for crossfire pre-DCE 8, and possibly on some DCE 8 
(Tonga) SKUs as well. On newer ASICs crossfire uses XDMA so there's no 
longer a need for DVO.

It's probably safe to drop it for amdgpu. Radeon driver might still want 
to keep it if there's support for it.

Harry


On 2016-04-13 10:56 PM, Dave Airlie wrote:
> From: Dave Airlie 
>
> I'm a bit confused whether this is needed so it would be good to
> confirm if hw shipped with it.
>
> DAL as currently is doesn't have any support for this, it doesn't
> have any encoder ids for DVO that I can see.
>
> So before porting to DAL graphics objects, I'm removing this code,
> so we can see if any regressions land here.
>
> Signed-off-by: Dave Airlie 
> ---
>   drivers/gpu/drm/amd/amdgpu/atombios_crtc.c |   3 -
>   drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 100 
> -
>   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |   8 --
>   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |   8 --
>   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |   8 --
>   5 files changed, 127 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> index 49aa350..072a729 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> @@ -344,9 +344,6 @@ static u32 amdgpu_atombios_crtc_adjust_pll(struct 
> drm_crtc *crtc,
>   }
>   }
>   
> - /* DVO wants 2x pixel clock if the DVO chip is in 12 bit mode */
> - if (amdgpu_encoder->encoder_id == 
> ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1)
> - adjusted_clock = mode->clock * 2;
>   if (amdgpu_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT))
>   amdgpu_crtc->pll_flags |= AMDGPU_PLL_PREFER_CLOSEST_LOWER;
>   if (amdgpu_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index 4367941..7ef93c6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -272,7 +272,6 @@ bool amdgpu_atombios_encoder_is_digital(struct 
> drm_encoder *encoder)
>   {
>   struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
>   switch (amdgpu_encoder->encoder_id) {
> - case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
>   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
>   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
>   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> @@ -369,79 +368,8 @@ static u8 amdgpu_atombios_encoder_get_bpc(struct 
> drm_encoder *encoder)
>   }
>   }
>   
> -union dvo_encoder_control {
> - ENABLE_EXTERNAL_TMDS_ENCODER_PS_ALLOCATION ext_tmds;
> - DVO_ENCODER_CONTROL_PS_ALLOCATION dvo;
> - DVO_ENCODER_CONTROL_PS_ALLOCATION_V3 dvo_v3;
> - DVO_ENCODER_CONTROL_PS_ALLOCATION_V1_4 dvo_v4;
> -};
> -
> -static void
> -amdgpu_atombios_encoder_setup_dvo(struct drm_encoder *encoder, int action)
> -{
> - struct drm_device *dev = encoder->dev;
> - struct amdgpu_device *adev = dev->dev_private;
> - struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
> - union dvo_encoder_control args;
> - int index = GetIndexIntoMasterTable(COMMAND, DVOEncoderControl);
> - uint8_t frev, crev;
> -
> - memset(, 0, sizeof(args));
> -
> - if (!amdgpu_atom_parse_cmd_header(adev->mode_info.atom_context, index, 
> , ))
> - return;
> -
> - switch (frev) {
> - case 1:
> - switch (crev) {
> - case 1:
> - /* R4xx, R5xx */
> - args.ext_tmds.sXTmdsEncoder.ucEnable = action;
> -
> - if (amdgpu_dig_monitor_is_duallink(encoder, 
> amdgpu_encoder->pixel_clock))
> - args.ext_tmds.sXTmdsEncoder.ucMisc |= 
> PANEL_ENCODER_MISC_DUAL;
> -
> - args.ext_tmds.sXTmdsEncoder.ucMisc |= 
> ATOM_PANEL_MISC_888RGB;
> - break;
> - case 2:
> - /* RS600/690/740 */
> - args.dvo.sDVOEncoder.ucAction = action;
> - args.dvo.sDVOEncoder.usPixelClock = 
> cpu_to_le16(amdgpu_encoder->pixel_clock / 10);
> - /* DFP1, CRT1, TV1 depending on the type of port */
> - args.dvo.sDVOEncoder.ucDeviceType = 
> ATOM_DEVICE_DFP1_INDEX;
> -
> - if (amdgpu_dig_monitor_is_duallink(encoder, 
> amdgpu_encoder->pixel_clock))
> - 
> args.dvo.sDVOEncoder.usDevAttr.sDigAttrib.ucAttribute |= 
> PANEL_ENCODER_MISC_DUAL;
> - break;
> - case 3:
> - /* R6xx */
> - args.dvo_v3.ucAction = action;
> - args.dvo_v3.usPixelClock = 
> cpu_to_le16(amdgpu_encoder->pixel_clock / 10);
> - args.dvo_v3.ucDVOConfig = 0; /* XXX */
> -

[PATCH] drm/dp/mst: Restore primary hub guid on resume

2016-04-15 Thread Harry Wentland
Patch makes sense to me. It looks like when the receiver detects an 
upstream disconnect it will reset its internal state, at least somewhat. 
We've seen that happen when system enters S3 and GPU loses power.

Reviewed-by: Harry Wentland 

Harry

On 2016-04-13 04:50 PM, Lyude wrote:
> Some hubs are forgetful, and end up forgetting whatever GUID we set
> previously after we do a suspend/resume cycle. This can lead to
> hotplugging breaking (along with probably other things) since the hub
> will start sending connection notifications with the wrong GUID. As
> such, we need to check on resume whether or not the GUID the hub is
> giving us is valid.
>
> Signed-off-by: Lyude 
> Signed-off-by: Dave Airlie 
> ---
>   drivers/gpu/drm/drm_dp_mst_topology.c | 12 
>   1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 27fbd79..d2efd78 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2121,6 +2121,8 @@ int drm_dp_mst_topology_mgr_resume(struct 
> drm_dp_mst_topology_mgr *mgr)
>   
>   if (mgr->mst_primary) {
>   int sret;
> + u8 guid[16];
> +
>   sret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd, 
> DP_RECEIVER_CAP_SIZE);
>   if (sret != DP_RECEIVER_CAP_SIZE) {
>   DRM_DEBUG_KMS("dpcd read failed - undocked during 
> suspend?\n");
> @@ -2135,6 +2137,16 @@ int drm_dp_mst_topology_mgr_resume(struct 
> drm_dp_mst_topology_mgr *mgr)
>   ret = -1;
>   goto out_unlock;
>   }
> +
> + /* Some hubs forget their guids after they resume */
> + sret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
> + if (sret != 16) {
> + DRM_DEBUG_KMS("dpcd read failed - undocked during 
> suspend?\n");
> + ret = -1;
> + goto out_unlock;
> + }
> + drm_dp_check_mstb_guid(mgr->mst_primary, guid);
> +
>   ret = 0;
>   } else
>   ret = -1;



drm/amdgpu: start using graphics object ids from DAL.

2016-04-15 Thread Harry Wentland
Makes sense to me.

Reviewed-by: Harry Wentland 

Harry

On 2016-04-14 04:25 AM, Christian König wrote:
> Am 14.04.2016 um 04:56 schrieb Dave Airlie:
>> DAL has a concept of storing the graphics object ids in a special
>> small struct, and adding type safety to them.
>>
>> I'm starting to contemplate bringing some pieces of DAL into the
>> mainline modesetting code (like the bios parser for a start),
>> and I think this is the best first step in that direction.
>>
>> This series converts connectors, encoders and crtcs id to the
>> DAL objects. I haven't done PLLs yet they are a bit messier and
>> I probably need to think about them a bit more.
>>
>> Also DAL doesn't support any of the DVO/external encoders, I've no idea
>> if they even exist on DCE8 or newer GPUs, so I've done a separate
>> patch to drop them.
>
> I'm not so deep into the display engine stuff or DAL, but this looks 
> like a good start to me to better integrate some of the DAL code into 
> the existing code base.
>
> So the patches are Acked-by: Christian König .
>
> I will ask around about the DVO stuff. Let me know if you need 
> anything else while Alex is still asleep.
>
> Regards,
> Christian.
>
>> Dave.
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



Funky new vblank counter regressions in Linux 4.4-rc1

2015-11-23 Thread Harry Wentland
Hi Mario,

when we've had issues with this on amdgpu Christian fixed it by enabling 
page flip irq all the time, rather than turning it on when usermode 
request a flip and turning it back off after we handled it. I believe 
that fix exists on radeon already. Michel should have more info on that.

See other comments inline.

Thanks,
Harry


On 2015-11-23 11:02 AM, Mario Kleiner wrote:
> On 11/20/2015 04:42 AM, Alex Deucher wrote:
>> On Thu, Nov 19, 2015 at 12:46 PM, Mario Kleiner
>>  wrote:
>>> Hi Alex and Michel and Ville,
>>>
>>> it's "fix vblank stuff" time again ;-)
>>
>> Adding Harry from our display team.  He might be able to fill in the
>> blanks of on some of this better than I can.  It might also be worth
>> checking to see how our DAL (our new display code which is being
>> developed directly by our display team) code handles this.  It could
>> be that we are just missing register settings:
>
> Thanks Alex! And hello Harry :)
>
>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=DAL-wip
>
> I'll have a look at this.
>
>> Additionally we've published full registers headers for the display 
>> block:
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/include/asic_reg/dce
>>  
>>
>> The DCE8 stuff should generally apply back to DCE4.  If you have
>> questions about registers older asics not covered in the hw docs, let
>> me know.  Note the new headers are dword aligned rather than byte
>> aligned.
>>
>
> I've tested now with two different progressive modes on DCE3 and one 
> progressive mode on DCE4, the only cards i have atm. So far it seems 
> that the framecounter indeed increments when the vpos from the scanout 
> position query jumps back to zero. Attached for reference is my 
> current patch to radeon-kms. This one seems to work reliably so far, 
> also if i enable the immediate vblank irq disable which we so far only 
> used on intel-kms.
>
> But according to this patch the framecounter increment happens 
> somewhere in the middle of vblank.
>
> Essentially from the vpos extracted from 
> EVERGREEN_CRTC_STATUS_POSITION which defines start of vblank ("Start" 
> part of EVERGREEN_CRTC_V_BLANK_START_END) until maximum ie. VTOTAL-1 
> the framecounter stays on the count of the old previous scanout cycle. 
> Then when vpos wraps to zero the framecounter increments by 1. And 
> then we have another couple of dozen lines inside vblank until 
> reaching the "End" part of EVERGREEN_CRTC_V_BLANK_START_END and 
> entering active scanout for the new frame.
>
> So the position of observed framecounter increment seems to be not 
> close to the end of vblank ("start of frame" indicator?), but a couple 
> of scanlines after start of vblank.
>
> E.g., for a 2560x1440 video mode at 60 Hz, start of vblank is 1478, 
> vtotal is 1481, end of vblank is 38. So i enter the vblank and see the 
> old framecounter for vpos = 1478, 1479, 1480, then it wraps to 0 and 
> the framecounter increments by 1, then 38 scanlines later the vblank 
> ends.
>
> So i seem to have something that seems to work in practice and this 
> "increment framecounter if vpos wraps back to zero" behavior makes 
> some sense. It just doesn't conform to what those descriptions for 
> start_line and "start of frame" indicator describe?
>
This is correct. Our HW doesn't really have a vblank counter but a frame 
counter. The framecounter increments at the start of vsync, which is 
when we wrap to zero which doesn't coincide with the start of vblank.

What we're trying to do with get_vblank_counter isn't the same as what 
framecount gives us, but we could probably do something like:

if (get_scanout_pos > vblank_start)
   return frame_count + 1;
else
   return frame_count;

Harry

> I'll test with a few more video modes.
>
> thanks,
> -mario
>
>
>>>
>>> Ville's changes to the DRM's drm_handle_vblank() / 
>>> drm_update_vblank_count()
>>> code in Linux 4.4 not only made that code more elegant, but also 
>>> removed the
>>> robustness against the vblank irq quirks in AMD hw and similar 
>>> hardware. So
>>> now i get tons of off-by-one errors and
>>>
>>> "[   432.345] (WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip
>>> completion event has impossible msc 24803 < target_msc 24804" XOrg 
>>> messages
>>> from that kernel.
>>>
>>> One of the reasons for trouble is that AMD hw quirk where the hw 
>>> fires an
>>> extra vblank irq shortly after vblank irq's get enabled, not 
>>> synchronized to
>>> vblank, but typically in the middle of active scanout, so we get a 
>>> redundant
>>> call to drm_handle_vblank in the middle of scanout.
>>>
>>> To fix that i have a minor patch to make drm_update_vblank_count() 
>>> again
>>> robust against such redundant calls, which i will send out later to the
>>> mailing list. Diff attached for reference.
>>>
>>> The second quirk of AMD hw is that the vblank interrupt fires a few
>>> scanlines before start of vblank, so drm_handle_vblank ->
>>> drm_update_vblank_count() -> 

Re: [PATCH] drm: simplify the locking in the GETCRTC ioctl

2017-03-28 Thread Harry Wentland

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

On 2017-03-28 03:01 AM, Daniel Vetter wrote:

No need to grab both plane and crtc locks at the same time, we can do
them one after the other. If userspace races it'll get what it
deserves either way.

This removes another user of drm_modeset_lock_crtc. There's only one
left.

v2: Make sure all access to primary->state is properly protected
(Harry).

Cc: Harry Wentland <harry.wentl...@amd.com>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
 drivers/gpu/drm/drm_crtc.c   | 11 ---
 drivers/gpu/drm/i915/intel_display.c |  5 +
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 660b4c8715de..55b3da2e2a82 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -406,9 +406,9 @@ int drm_mode_getcrtc(struct drm_device *dev,
if (!crtc)
return -ENOENT;

-   drm_modeset_lock_crtc(crtc, crtc->primary);
crtc_resp->gamma_size = crtc->gamma_size;

+   drm_modeset_lock(>primary->mutex, NULL);
if (crtc->primary->state && crtc->primary->state->fb)
crtc_resp->fb_id = crtc->primary->state->fb->base.id;
else if (!crtc->primary->state && crtc->primary->fb)
@@ -416,9 +416,14 @@ int drm_mode_getcrtc(struct drm_device *dev,
else
crtc_resp->fb_id = 0;

-   if (crtc->state) {
+   if (crtc->primary->state) {
crtc_resp->x = crtc->primary->state->src_x >> 16;
crtc_resp->y = crtc->primary->state->src_y >> 16;
+   }
+   drm_modeset_unlock(>primary->mutex);
+
+   drm_modeset_lock(>mutex, NULL);
+   if (crtc->state) {
if (crtc->state->enable) {
drm_mode_convert_to_umode(_resp->mode, 
>state->mode);
crtc_resp->mode_valid = 1;
@@ -437,7 +442,7 @@ int drm_mode_getcrtc(struct drm_device *dev,
crtc_resp->mode_valid = 0;
}
}
-   drm_modeset_unlock_crtc(crtc);
+   drm_modeset_unlock(>mutex);

return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 68cded453882..43dbad62786e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12463,6 +12463,11 @@ static int intel_atomic_check(struct drm_device *dev,
ret = drm_atomic_helper_check_modeset(dev, state);
if (ret)
return ret;
+   /* enocder->atomic_check might upgrade some crtc to a full modeset */
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+

for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, crtc_state, 
i) {
struct intel_crtc_state *pipe_config =


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


Re: [PATCH 01/19] drm: Wire up proper acquire ctx for plane functions

2017-03-28 Thread Harry Wentland



On 2017-03-28 03:02 AM, Daniel Vetter wrote:

On Tue, Mar 28, 2017 at 08:23:53AM +0200, Daniel Vetter wrote:

On Mon, Mar 27, 2017 at 04:12:05PM -0400, Harry Wentland wrote:

On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:

This is just prep work to get an acquire ctx into every place where we
call ->update_plane or ->disable_plane.

v2: Keep the hidden acquire_ctx pointers valid while transitioning.

Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
 drivers/gpu/drm/drm_plane.c | 52
- 1 file changed, 42
insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a22e76837065..0d04888172a7 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -457,7 +457,8 @@ static int __setplane_internal(struct drm_plane *plane,
   uint32_t crtc_w, uint32_t crtc_h,
   /* src_{x,y,w,h} values are 16.16 fixed point */
   uint32_t src_x, uint32_t src_y,
-  uint32_t src_w, uint32_t src_h)
+  uint32_t src_w, uint32_t src_h,
+  struct drm_modeset_acquire_ctx *ctx)
 {
int ret = 0;

@@ -537,13 +538,26 @@ static int setplane_internal(struct drm_plane *plane,
 uint32_t src_x, uint32_t src_y,
 uint32_t src_w, uint32_t src_h)
 {
+   struct drm_modeset_acquire_ctx ctx;
int ret;

-   drm_modeset_lock_all(plane->dev);
+   drm_modeset_acquire_init(, 0);
+retry:
+   ret = drm_modeset_lock_all_ctx(plane->dev, );
+   if (ret)
+   goto fail;
+   plane->dev->mode_config.acquire_ctx = 
ret = __setplane_internal(plane, crtc, fb,
  crtc_x, crtc_y, crtc_w, crtc_h,
- src_x, src_y, src_w, src_h);
-   drm_modeset_unlock_all(plane->dev);
+ src_x, src_y, src_w, src_h, );
+
+fail:
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();

return ret;
 }
@@ -613,11 +627,22 @@ static int drm_mode_cursor_universal(struct drm_crtc
*crtc, int32_t crtc_x, crtc_y;
uint32_t crtc_w = 0, crtc_h = 0;
uint32_t src_w = 0, src_h = 0;
+   struct drm_modeset_acquire_ctx ctx;
int ret = 0;

BUG_ON(!crtc->cursor);
WARN_ON(crtc->cursor->crtc != crtc && crtc->cursor->crtc != NULL);

+   drm_modeset_acquire_init(, 0);
+retry:
+   ret = drm_modeset_lock(>mutex, );
+   if (ret)
+   goto fail;
+   ret = drm_modeset_lock(>cursor->mutex, );
+   if (ret)
+   goto fail;
+   crtc->acquire_ctx = 
+
/*
 * Obtain fb we'll be using (either new or existing) and take an extra
 * reference to it if fb != null.  setplane will take care of dropping
@@ -662,7 +687,7 @@ static int drm_mode_cursor_universal(struct drm_crtc
*crtc, */
ret = __setplane_internal(crtc->cursor, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
-   0, 0, src_w, src_h);
+   0, 0, src_w, src_h, );

/* Update successful; save new cursor position, if necessary */
if (ret == 0 && req->flags & DRM_MODE_CURSOR_MOVE) {
@@ -670,6 +695,15 @@ static int drm_mode_cursor_universal(struct drm_crtc
*crtc, crtc->cursor_y = req->y;
}

+fail:
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
return ret;
 }

@@ -696,12 +730,10 @@ static int drm_mode_cursor_common(struct drm_device
*dev, * If this crtc has a universal cursor plane, call that plane's update
* handler rather than using legacy cursor handlers.
 */
-   drm_modeset_lock_crtc(crtc, crtc->cursor);
-   if (crtc->cursor) {
-   ret = drm_mode_cursor_universal(crtc, req, file_priv);
-   goto out;
-   }
+   if (crtc->cursor)
+   return drm_mode_cursor_universal(crtc, req, file_priv);

+   drm_modeset_lock_crtc(crtc, crtc->cursor);


Why are you moving the lock? Shouldn't it still be covering the call to
drm_mode_cursor_universal?


It would deadlock, because the new acquire ctx dance for universal planes
also takes the same locks as this helper?

But I just realized that crtc->cursor is NULL here, I can simplify this
some more.


Specifically this gets reshuffled in patch 14, but that is blocked on the
vmwgfx story for now.


Ah, right, the lock moves down into drm_mode_cursor_universal. I do

Re: [PATCH 01/19] drm: Wire up proper acquire ctx for plane functions

2017-03-27 Thread Harry Wentland
On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> This is just prep work to get an acquire ctx into every place where we
> call ->update_plane or ->disable_plane.
> 
> v2: Keep the hidden acquire_ctx pointers valid while transitioning.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_plane.c | 52
> - 1 file changed, 42
> insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index a22e76837065..0d04888172a7 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -457,7 +457,8 @@ static int __setplane_internal(struct drm_plane *plane,
>  uint32_t crtc_w, uint32_t crtc_h,
>  /* src_{x,y,w,h} values are 16.16 fixed point */
>  uint32_t src_x, uint32_t src_y,
> -uint32_t src_w, uint32_t src_h)
> +uint32_t src_w, uint32_t src_h,
> +struct drm_modeset_acquire_ctx *ctx)
>  {
>   int ret = 0;
> 
> @@ -537,13 +538,26 @@ static int setplane_internal(struct drm_plane *plane,
>uint32_t src_x, uint32_t src_y,
>uint32_t src_w, uint32_t src_h)
>  {
> + struct drm_modeset_acquire_ctx ctx;
>   int ret;
> 
> - drm_modeset_lock_all(plane->dev);
> + drm_modeset_acquire_init(, 0);
> +retry:
> + ret = drm_modeset_lock_all_ctx(plane->dev, );
> + if (ret)
> + goto fail;
> + plane->dev->mode_config.acquire_ctx = 
>   ret = __setplane_internal(plane, crtc, fb,
> crtc_x, crtc_y, crtc_w, crtc_h,
> -   src_x, src_y, src_w, src_h);
> - drm_modeset_unlock_all(plane->dev);
> +   src_x, src_y, src_w, src_h, );
> +
> +fail:
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + }
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> 
>   return ret;
>  }
> @@ -613,11 +627,22 @@ static int drm_mode_cursor_universal(struct drm_crtc
> *crtc, int32_t crtc_x, crtc_y;
>   uint32_t crtc_w = 0, crtc_h = 0;
>   uint32_t src_w = 0, src_h = 0;
> + struct drm_modeset_acquire_ctx ctx;
>   int ret = 0;
> 
>   BUG_ON(!crtc->cursor);
>   WARN_ON(crtc->cursor->crtc != crtc && crtc->cursor->crtc != NULL);
> 
> + drm_modeset_acquire_init(, 0);
> +retry:
> + ret = drm_modeset_lock(>mutex, );
> + if (ret)
> + goto fail;
> + ret = drm_modeset_lock(>cursor->mutex, );
> + if (ret)
> + goto fail;
> + crtc->acquire_ctx = 
> +
>   /*
>* Obtain fb we'll be using (either new or existing) and take an extra
>* reference to it if fb != null.  setplane will take care of dropping
> @@ -662,7 +687,7 @@ static int drm_mode_cursor_universal(struct drm_crtc
> *crtc, */
>   ret = __setplane_internal(crtc->cursor, crtc, fb,
>   crtc_x, crtc_y, crtc_w, crtc_h,
> - 0, 0, src_w, src_h);
> + 0, 0, src_w, src_h, );
> 
>   /* Update successful; save new cursor position, if necessary */
>   if (ret == 0 && req->flags & DRM_MODE_CURSOR_MOVE) {
> @@ -670,6 +695,15 @@ static int drm_mode_cursor_universal(struct drm_crtc
> *crtc, crtc->cursor_y = req->y;
>   }
> 
> +fail:
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + }
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
>   return ret;
>  }
> 
> @@ -696,12 +730,10 @@ static int drm_mode_cursor_common(struct drm_device
> *dev, * If this crtc has a universal cursor plane, call that plane's update
> * handler rather than using legacy cursor handlers.
>*/
> - drm_modeset_lock_crtc(crtc, crtc->cursor);
> - if (crtc->cursor) {
> - ret = drm_mode_cursor_universal(crtc, req, file_priv);
> - goto out;
> - }
> + if (crtc->cursor)
> + return drm_mode_cursor_universal(crtc, req, file_priv);
> 
> + drm_modeset_lock_crtc(crtc, crtc->cursor);

Why are you moving the lock? Shouldn't it still be covering the call to 
drm_mode_cursor_universal?

Harry


>   if (req->flags & DRM_MODE_CURSOR_BO) {
>   if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
>   ret = -ENXIO;


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


Re: [PATCH 3/3] drm: document the all the atomic iterators

2017-03-28 Thread Harry Wentland

Patches 1-3 are Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

On 2017-03-28 11:53 AM, Daniel Vetter wrote:

Mostly because I want the links from the newly-added @state functions
to work. But I think explaining when they're useful and that the
implicit one is deprecated is good either way. Slightly repetitive
unfortunately.

Cc: Harry Wentland <harry.wentl...@amd.com>
Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
 include/drm/drm_atomic.h | 159 ++-
 1 file changed, 158 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 0147a047878d..fd33ed5eaeb4 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -498,6 +498,23 @@ int __must_check drm_atomic_nonblocking_commit(struct 
drm_atomic_state *state);

 void drm_state_dump(struct drm_device *dev, struct drm_printer *p);

+/**
+ * for_each_connector_in_state - iterate over all connectors in an atomic 
update
+ * @__state:  drm_atomic_state pointer
+ * @connector:  drm_connector iteration cursor
+ * @connector_state:  drm_connector_state iteration cursor
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all connectors in an atomic update. Note that before the
+ * software state is committed (by calling drm_atomic_helper_swap_state(), this
+ * points to the new state, while afterwards it points to the old state. Due to
+ * this tricky confusion this macro is deprecated.
+ *
+ * FIXME:
+ *
+ * Replace all usage of this with one of the explicit iterators below and then
+ * remove this macro.
+ */
 #define for_each_connector_in_state(__state, connector, connector_state, __i) \
for ((__i) = 0; \
 (__i) < (__state)->num_connector &&  \
@@ -506,6 +523,20 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if (connector)

+/**
+ * for_each_oldnew_connector_in_state - iterate over all connectors in an 
atomic update
+ * @__state:  drm_atomic_state pointer
+ * @connector:  drm_connector iteration cursor
+ * @old_connector_state:  drm_connector_state iteration cursor for the
+ * old state
+ * @new_connector_state:  drm_connector_state iteration cursor for the
+ * new state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all connectors in an atomic update, tracking both old and
+ * new state. This is useful in places where the state delta needs to be
+ * considered, for example in atomic check functions.
+ */
 #define for_each_oldnew_connector_in_state(__state, connector, 
old_connector_state, new_connector_state, __i) \
for ((__i) = 0; 
\
 (__i) < (__state)->num_connector &&  \
@@ -515,6 +546,18 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if (connector)

+/**
+ * for_each_old_connector_in_state - iterate over all connectors in an atomic 
update
+ * @__state:  drm_atomic_state pointer
+ * @connector:  drm_connector iteration cursor
+ * @old_connector_state:  drm_connector_state iteration cursor for the
+ * old state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all connectors in an atomic update, tracking only the old
+ * state. This is useful in disable functions, where we need the old state the
+ * hardware is still in.
+ */
 #define for_each_old_connector_in_state(__state, connector, 
old_connector_state, __i) \
for ((__i) = 0; 
\
 (__i) < (__state)->num_connector &&  \
@@ -523,6 +566,18 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if (connector)

+/**
+ * for_each_new_connector_in_state - iterate over all connectors in an atomic 
update
+ * @__state:  drm_atomic_state pointer
+ * @connector:  drm_connector iteration cursor
+ * @new_connector_state:  drm_connector_state iteration cursor for the
+ * new state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all connectors in an atomic update, tracking only the new
+ * state. This is useful in enable functions, where we need the new state the
+ * hardware should be in when the atomic commit operation has completed.
+ */
 #define for_each_new_connector_in_state(__state, connector, 
new_connector_state, __i) \
for ((__i) = 0;   

Re: [PATCH] drm: Clear e after kfree in drm_mode_page_flip_ioctl

2017-03-30 Thread Harry Wentland

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

On 2017-03-30 09:32 AM, Daniel Vetter wrote:

With the explicit retry loop static analyzers get confused by the
control flow and believe that e could be accessed after kfree. That's
not possible, but it's non-obvious, so let's clear it to NULL.

We already cleared e = NULL at the top of the function, so this is all
in line.

Cc: Julia Lawall <julia.law...@lip6.fr>
Reported-by: Julia Lawall <julia.law...@lip6.fr>
Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
Cc: Harry Wentland <harry.wentl...@amd.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
  drivers/gpu/drm/drm_plane.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index ec62221d64a9..3a6de27bafed 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -922,6 +922,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);
if (ret) {
kfree(e);
+   e = NULL;
goto out;
}
}


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


Re: [PATCH] drm: Fix locking gotcha in page_flip ioctl

2017-03-30 Thread Harry Wentland

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry


On 2017-03-30 04:48 PM, Daniel Vetter wrote:

We want to lock the primary plane, not the cursor (which might be
optional). Real bad case of copy-paste fail, unfortunately our CI
didn't catch that because i915 does have a cursor plane.

Cc: Eric Anholt <e...@anholt.net>
Reported-by: Eric Anholt <e...@anholt.net>
Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
Cc: Harry Wentland <harry.wentl...@amd.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
 drivers/gpu/drm/drm_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 3a6de27bafed..838ca742a28b 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -871,7 +871,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
ret = drm_modeset_lock(>mutex, );
if (ret)
goto out;
-   ret = drm_modeset_lock(>cursor->mutex, );
+   ret = drm_modeset_lock(>primary->mutex, );
if (ret)
goto out;



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


Re: [PATCH] drm: Fixup failure paths in drm_atomic_helper_set_config

2017-03-29 Thread Harry Wentland

Of course. I totally missed that.

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

On 2017-03-29 01:41 PM, Daniel Vetter wrote:

I've screwed this up when removing the legacy backoff hack.

Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from 
set_config")
Cc: Harry Wentland <harry.wentl...@amd.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Cc: David Airlie <airl...@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
  drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9dc67b52b905..d5915317e7d3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2294,10 +2294,11 @@ int drm_atomic_helper_set_config(struct drm_mode_set 
*set,
state->acquire_ctx = ctx;
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
-   return ret;
+   goto fail;
  
  	ret = drm_atomic_commit(state);
  
+fail:

drm_atomic_state_put(state);
return ret;
  }


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


Re: [PATCH 13/19] drm: simplify the locking in the GETCRTC ioctl

2017-03-27 Thread Harry Wentland
On Wednesday, March 22, 2017 10:50:52 PM EDT Daniel Vetter wrote:
> No need to grab both plane and crtc locks at the same time, we can do
> them one after the other. If userspace races it'll get what it
> deserves either way.
> 
> This removes another user of drm_modeset_lock_crtc. There's only one
> left.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 660b4c8715de..df1ff0b8818b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -406,16 +406,18 @@ int drm_mode_getcrtc(struct drm_device *dev,
>   if (!crtc)
>   return -ENOENT;
> 
> - drm_modeset_lock_crtc(crtc, crtc->primary);
>   crtc_resp->gamma_size = crtc->gamma_size;
> 
> + drm_modeset_lock(>primary->mutex, NULL);
>   if (crtc->primary->state && crtc->primary->state->fb)
>   crtc_resp->fb_id = crtc->primary->state->fb->base.id;
>   else if (!crtc->primary->state && crtc->primary->fb)
>   crtc_resp->fb_id = crtc->primary->fb->base.id;
>   else
>   crtc_resp->fb_id = 0;
> + drm_modeset_unlock(>primary->mutex);
> 
> + drm_modeset_lock(>mutex, NULL);
>   if (crtc->state) {
>   crtc_resp->x = crtc->primary->state->src_x >> 16;
>   crtc_resp->y = crtc->primary->state->src_y >> 16;

What about crtc->primary here? Shouldn't that also be locked with the crtc-
>primary->mutex or do we treat state differently? Still not 100% on the exact 
locking semantics.

Harry

> @@ -437,7 +439,7 @@ int drm_mode_getcrtc(struct drm_device *dev,
>   crtc_resp->mode_valid = 0;
>   }
>   }
> - drm_modeset_unlock_crtc(crtc);
> + drm_modeset_unlock(>mutex);
> 
>   return 0;
>  }


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


Re: [PATCH 00/19] wire acquire ctx through legacy modeset paths

2017-03-27 Thread Harry Wentland
Patches 2-5, 9-12, 14-19: Reviewed-by: Harry Wentland <harry.wentl...@amd.com>
Patches 1,13: Questions in response to those patches
Patches 6-8: Acked-by: Harry Wentland <harry.wentl...@amd.com>

Looks like a nice cleanup.

Harry



On Wednesday, March 22, 2017 10:50:39 PM EDT Daniel Vetter wrote:
> Hi all,
> 
> This is something I kinda had on my todo list ever since atomic landed. The
> legacy_backoff() hack really doesn't work if you need to acquire additional
> locks, which does restrict drivers in how they handle and protect legacy
> paths, and kinda forces us to be overzealous with taking locks for legacy
> paths, just in case.
> 
> This patch set here fixes this, with 2 huge exceptions:
> - get/set_property calls aren't fixed. The locking in there is a mess and
> needs some serious attention. My goal would be that for atomic we take no
> lock at all, and entirely rely upon the magic of drm_modeset_lock and
> atomic to just grab the minimal set required to update a property.
> 
> - fbdev emulation helpers. It abused the modeset_lock_all bkl as its own
> lock, which prevents us from pushing it down just around the (atomic)
> modeset calls, and hence from switching over to handling the acquire
> context in an explicit fashion. Thierry started to fix this with the
> addition of proper locking for fbdev emulation, but it needs a pile more
> work.
> 
> Survived light testing with full ww mutex debugging, I'll rely on CI to
> catch the remaining mixups :-)
> 
> Cheers, Daniel
> 
> Daniel Vetter (19):
>   drm: Wire up proper acquire ctx for plane functions
>   drm: Add acquire ctx parameter to ->update_plane
>   drm: drm_plane_force_disable is not for atomic drivers
>   drm: Add acquire ctx parameter to ->plane_disable
>   drm/atomic-helper: remove backoff hack from disable/update_plane
>   drm/vmwgfx: Drop the cursor locking hack
>   drm/tegra: Don't use modeset_lock_crtc
>   drm/tilcdc: Drop calls to modeset_lock_crtc
>   drm: Make drm_modeset_lock_crtc internal
>   drm: Roll out acquire context for the page_flip ioctl
>   drm: Add acquire ctx parameter to ->page_flip(_target)
>   drm/atomic-helper: remove backoff hack from page_flip
>   drm: simplify the locking in the GETCRTC ioctl
>   drm: Remove drm_modeset_(un)lock_crtc
>   drm: Remove drm_modeset_legacy_acquire_ctx and crtc->acquire_ctx
>   drm: Restrict drm_mode_set_config_internal to non-atomic drivers
>   drm: Add explicit acquire ctx handling around ->set_config
>   drm: Add acquire ctx parameter to ->set_config
>   drm/atomic-helper: Remove the backoff hack from set_config
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   6 +-
>  drivers/gpu/drm/armada/armada_crtc.c|   3 +-
>  drivers/gpu/drm/armada/armada_overlay.c |   6 +-
>  drivers/gpu/drm/bochs/bochs_kms.c   |   3 +-
>  drivers/gpu/drm/drm_atomic.c|  14 ---
>  drivers/gpu/drm/drm_atomic_helper.c | 132
> +--- drivers/gpu/drm/drm_crtc.c  | 
> 61 -
>  drivers/gpu/drm/drm_crtc_helper.c   |   4 +-
>  drivers/gpu/drm/drm_modeset_lock.c  | 102 -
>  drivers/gpu/drm/drm_plane.c |  87 ++
>  drivers/gpu/drm/drm_plane_helper.c  |  11 ++-
>  drivers/gpu/drm/gma500/gma_display.c|   7 +-
>  drivers/gpu/drm/gma500/gma_display.h|   3 +-
>  drivers/gpu/drm/i915/intel_display.c|   9 +-
>  drivers/gpu/drm/i915/intel_pipe_crc.c   |   2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   8 +-
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c |   7 +-
>  drivers/gpu/drm/nouveau/dispnv04/overlay.c  |  18 ++--
>  drivers/gpu/drm/nouveau/nouveau_display.c   |   3 +-
>  drivers/gpu/drm/nouveau/nouveau_display.h   |   4 +-
>  drivers/gpu/drm/radeon/radeon_display.c |   8 +-
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |   3 +-
>  drivers/gpu/drm/shmobile/shmob_drm_plane.c  |   8 +-
>  drivers/gpu/drm/tegra/dc.c  |   8 +-
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c|  12 +--
>  drivers/gpu/drm/udl/udl_modeset.c   |   3 +-
>  drivers/gpu/drm/vc4/vc4_crtc.c  |   5 +-
>  drivers/gpu/drm/vc4/vc4_plane.c |   6 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  25 --
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |   3 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   6 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   6 +-
>  include/drm/drm_atomic_helper.h |  15 ++--
>  include/drm/drm_crtc.h  |  18 ++--
>  include/drm/drm_crtc_helper.h   |   3 +-
>  include/drm/drm_mod

Re: [PATCH] drm: add check for plane functions

2017-03-17 Thread Harry Wentland

On 2017-03-17 03:55 AM, Shirish S wrote:

update_plane() and disable_plane() functions
assoiciated with setting plane are called
without any check, causing kernel panic.

This patch adds the required check to avoid it.

Change-Id: I0d6792608b33e674c217388aa57c4b7d680d9bc7
Signed-off-by: Shirish S 
---
 drivers/gpu/drm/drm_plane.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 249c0ae..f675f8b 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -456,6 +456,12 @@ static int __setplane_internal(struct drm_plane *plane,
 {
int ret = 0;

+   if (plane->funcs->disable_plane == NULL ||
+   plane->funcs->update_plane == NULL) {


Thanks, Shirish, for sending these out on amd-gfx and dri-devel.

I've had a second look at this. It seems like there are a bunch of other 
places that assume these functions are implemented by drivers. Does this 
check serve any purpose other than as an immediate step when 
implementing universal planes?


Harry


+   DRM_ERROR("plane funcs not implemented\n");
+   ret = -EPERM;
+   goto out;
+   }
/* No fb means shut it down */
if (!fb) {
plane->old_fb = plane->fb;


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


Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

2017-03-14 Thread Harry Wentland

On 2017-03-14 06:04 AM, zhoucm1 wrote:



On 2017年03月14日 17:20, Christian König wrote:

Am 14.03.2017 um 09:54 schrieb Daniel Vetter:

On Tue, Mar 14, 2017 at 11:30:40AM +0800, zhoucm1 wrote:


On 2017年03月14日 10:52, Dave Airlie wrote:

On 14 March 2017 at 12:00, zhoucm1  wrote:

Hi Dave,

Could you tell me why you create your new one patch? I remember I
send out
our the whole implementation, Why not directly review our patches?

This is patch review, I'm not sure what you are expecting in terms of
direct review.

The patches you sent out were reviewed by Christian, he stated he
thinks this should
use sync_file, I was interested to see if this was actually possible,
so I just adapted
the patches to check if it was possible to avoid adding a lot of amd
specific code
for something that isn't required to be. Hence why I've sent this as
an rfc, as I want
to see if others think using sync_file is a good or bad idea. We may
end up going
back to the non-sync_file based patches if this proves to be a bad
idea, so far it
doesn't look like one.

I also reviewed the patches and noted it shouldn't add the wait/signal
interfaces,
that it should use the chunks on command submission, so while I was in
there I re
wrote that as well.

Yeah, then I'm ok with this, just our internal team has used this
implementation, they find some gaps between yours and previous, they
could
need to change their's again, they are annoyance for this.

This is why you _must_ get anything you're doing discussed in upstream
first. Your internal teams simply do not have design authority on stuff
like that. And yes it takes forever to get formerly proprietary
internal-only teams to understand this, speaking from years of
experience
implement a proper upstream-design-first approach to feature development
here at intel.


"internal teams simply do not have design authority on stuff like that"

Can I print that on a t-shirt and start to sell it?

I guess you cannot dress it to go to office..:)



I'd wear it to the office.

https://www.customink.com/lab?cid=hkp0-00ay-6vjg

Harry


David Zhou


Christian.


-Daniel





___
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


Re: [PATCH] drm: Document code of conduct

2017-04-11 Thread Harry Wentland



On 2017-04-11 02:48 AM, Daniel Vetter wrote:

freedesktop.org has adopted a formal code of conduct:

https://www.fooishbar.org/blog/fdo-contributor-covenant/
https://www.freedesktop.org/wiki/CodeOfConduct/

Besides formalizing things a bit more I don't think this changes
anything for us, we've already peer-enforced respectful and
constructive interactions since a long time. But it's good to document
things properly.

Note: As Daniel Stone mentioned in the announcement fd.o admins
started chatting with the communities their hosting, which includs the
X.org foundation board, to figure out how to fan out enforcement and
allow projects to run things on their own (with fd.o still as the
fallback).  So the details of enforcement (and appealing decisions)
might still change, but since this involves the board and lots more
people it'll take a while to get there. For now this is good enough I
think.

For the text itself I went with the same blurb as the Wayland project,
didn't feel creative yet this early in the morning:

https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c

Cc: Daniel Stone <dani...@collabora.com>
Cc: Keith Packard <kei...@keithp.com>
Cc: tfh...@err.no
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>


Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry


---
 Documentation/gpu/introduction.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/gpu/introduction.rst 
b/Documentation/gpu/introduction.rst
index 05a82bdfbca4..0f5173e29bdc 100644
--- a/Documentation/gpu/introduction.rst
+++ b/Documentation/gpu/introduction.rst
@@ -85,3 +85,14 @@ This means that there's a blackout-period of about one month 
where feature work
 can't be merged. The recommended way to deal with that is having a -next tree
 that's always open, but making sure to not feed it into linux-next during the
 blackout period. As an example, drm-misc works like that.
+
+Code of Conduct
+---
+
+As a freedesktop.org project, dri-devel and the DRM community follows the
+Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct
+
+Please conduct yourself in a respectful and civilised manner when
+interacting with community members on mailing lists, IRC, or bug
+trackers. The community represents the project as a whole, and abusive
+or bullying behaviour is not tolerated by the project.


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


Re: Static inline DRM functions calling into GPL-only code

2017-04-11 Thread Harry Wentland

On 2017-04-11 11:15 AM, James Jones wrote:

On 04/10/2017 11:20 PM, Daniel Vetter wrote:

On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter  wrote:

On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale 
wrote:

My name is Nikhil Mahale, and I work at NVIDIA in the Linux drivers
team.

I have been working on adding DRM KMS support to our driver. The NVIDIA
GPU driver package (364.12 and higher) provides a kernel module,
nvidia-drm.ko, which is licensed as "MIT". This module registers a DRM
driver with the DRM subsystem of the Linux kernel and advertises KMS
capability on Linux kernel v4.1 or higher, with CONFIG_DRM and
CONFIG_DRM_KMS_HELPER enabled.

We have been able to maintain compatibility between nvidia-drm.ko and
Linux kernels from v2.6.9 to v4.10. Unfortunately
with release candidates of v4.11:

* Commit 10383aea2f445bce9b2a2b308def08134b438c8e changed the kernel's
kref implementation to use refcount_inc and refcount_dec_and_test.
* Commit 29dee3c03abce04cd527878ef5f9e5f91b7b83f4 made refcount_inc and
refcount_dec_and_test EXPORT_SYMBOL_GPL.

DRM drivers call refcount_inc through static inline function callchains
such as:

drm_crtc_commit_put() => kref_put() => refcount_dec_and_test()
drm_crtc_commit_get() => kref_get() => refcount_inc()

drm_atomic_state_put() => kref_put() => refcount_dec_and_test()
drm_atomic_state_get() => kref_get() => refcount_inc()

drm_gem_object_reference() => kref_get => refcount_inc()

This causes nvidia-drm.ko to inadvertently pick up references to
EXPORT_SYMBOL_GPL symbols.

There is not interest in relaxing the export of refcount_inc, and
changing the license of nvidia-drm.ko isn't viable right now.

So, the remaining options we see are:

* Make these static inline DRM functions EXPORT_SYMBOL instead of
inline.

* Make these static inline DRM functions not use kref.

* Make nvidia-drm.ko not use these static inline DRM functions.

None of those seem good, though the first might be least bad.  Do
any of
those seem reasonable?


* Open-source the nvidia kernel driver? tbh I'm not sure how much you
can still make the case that your driver is fully an independent thing
if you're adopting stuff like atomic modesetting. Might be better to
make all the glue/remapping code from linux atomic to the shared
cross-os code at least open


As the original message stated, this code is already open (MIT license).



Just out of curiosity, can I find this on any public repo or webpage?

If inlining is the issue it looks like this is not used by any upstream 
DRM driver (or DAL) directly but only from a bunch of atomic functions, 
none of which are inline.


If this is an issue for NVidia would this also be an issue for any other 
MIT licensed code, such as drm_atomic_helper.c?


Harry


Thanks,
-James


... And atomic is pretty much guaranteed
to change all the time anyway, we're definitely not going to make a
stable kabi for you folks, so you might want to do that for practical
reasons anyway.

Just my 2cents, personal opinion, not reflecting intel's, not legal
advice, yadayada and all that :-)


Apparently coffee didn't work yet, so let me retry the more serious
part of my reply. I'd go with a shim that essentially remaps the linux
atomic to whatever cross-os datastructures and semantics you have in
the blob. That also has the benefit of insulating you a bit more from
upstream changes in atomic (which will happen), and enthusiasts might
get around to porting to new kernels before you do. Essentially pick
the architecture of amd's DAL, then fully open the glue layer. With my
maintainer hat on I'm at least not inclinced to add the "is this fair
use or not" hacks on upstream's side, simply because sooner or later
we'll break them and then we have the angry users, instead of nvidia.
And that's the wrong place for bug reports for blobs :-)
-Daniel


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

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


Re: Static inline DRM functions calling into GPL-only code

2017-04-11 Thread Harry Wentland

On 2017-04-11 12:37 PM, James Jones wrote:

On 04/11/2017 09:09 AM, Harry Wentland wrote:

On 2017-04-11 11:15 AM, James Jones wrote:

On 04/10/2017 11:20 PM, Daniel Vetter wrote:

On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter <dan...@ffwll.ch> wrote:

On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale <nmah...@nvidia.com>
wrote:

My name is Nikhil Mahale, and I work at NVIDIA in the Linux drivers
team.

I have been working on adding DRM KMS support to our driver. The
NVIDIA
GPU driver package (364.12 and higher) provides a kernel module,
nvidia-drm.ko, which is licensed as "MIT". This module registers a
DRM
driver with the DRM subsystem of the Linux kernel and advertises KMS
capability on Linux kernel v4.1 or higher, with CONFIG_DRM and
CONFIG_DRM_KMS_HELPER enabled.

We have been able to maintain compatibility between nvidia-drm.ko and
Linux kernels from v2.6.9 to v4.10. Unfortunately
with release candidates of v4.11:

* Commit 10383aea2f445bce9b2a2b308def08134b438c8e changed the
kernel's
kref implementation to use refcount_inc and refcount_dec_and_test.
* Commit 29dee3c03abce04cd527878ef5f9e5f91b7b83f4 made refcount_inc
and
refcount_dec_and_test EXPORT_SYMBOL_GPL.

DRM drivers call refcount_inc through static inline function
callchains
such as:

drm_crtc_commit_put() => kref_put() => refcount_dec_and_test()
drm_crtc_commit_get() => kref_get() => refcount_inc()

drm_atomic_state_put() => kref_put() => refcount_dec_and_test()
drm_atomic_state_get() => kref_get() => refcount_inc()

drm_gem_object_reference() => kref_get => refcount_inc()

This causes nvidia-drm.ko to inadvertently pick up references to
EXPORT_SYMBOL_GPL symbols.

There is not interest in relaxing the export of refcount_inc, and
changing the license of nvidia-drm.ko isn't viable right now.

So, the remaining options we see are:

* Make these static inline DRM functions EXPORT_SYMBOL instead of
inline.

* Make these static inline DRM functions not use kref.

* Make nvidia-drm.ko not use these static inline DRM functions.

None of those seem good, though the first might be least bad.  Do
any of
those seem reasonable?


* Open-source the nvidia kernel driver? tbh I'm not sure how much you
can still make the case that your driver is fully an independent thing
if you're adopting stuff like atomic modesetting. Might be better to
make all the glue/remapping code from linux atomic to the shared
cross-os code at least open


As the original message stated, this code is already open (MIT license).



Just out of curiosity, can I find this on any public repo or webpage?


This is our usual Linux driver download landing page:

https://www.nvidia.com/object/unix.html

We don't break out the nvidia-drm source into a separate package like we
do for some of our other open-source components, but it's included when
you download the full driver.  You can unpack it without installing, e.g:

  $ sh ~/Downloads/NVIDIA-Linux-x86_64-378.13.run -x

Then it will be in ./NVIDIA-Linux-x86_64-378.13/kernel/nvidia-drm/

Feedback welcome.


Thanks. Looks nice. I only spent 20 mins looking at it but really like 
how you guys deal with changes in kernel interfaces for kernel 
compatibility based on indicators in the kernel source.


I also like your nvidia-drm-modeset. Looks really nice and clean, at 
least on the surface.


Harry



Thanks,
-James


If inlining is the issue it looks like this is not used by any upstream
DRM driver (or DAL) directly but only from a bunch of atomic functions,
none of which are inline.

If this is an issue for NVidia would this also be an issue for any other
MIT licensed code, such as drm_atomic_helper.c?

Harry


Thanks,
-James


... And atomic is pretty much guaranteed
to change all the time anyway, we're definitely not going to make a
stable kabi for you folks, so you might want to do that for practical
reasons anyway.

Just my 2cents, personal opinion, not reflecting intel's, not legal
advice, yadayada and all that :-)


Apparently coffee didn't work yet, so let me retry the more serious
part of my reply. I'd go with a shim that essentially remaps the linux
atomic to whatever cross-os datastructures and semantics you have in
the blob. That also has the benefit of insulating you a bit more from
upstream changes in atomic (which will happen), and enthusiasts might
get around to porting to new kernels before you do. Essentially pick
the architecture of amd's DAL, then fully open the glue layer. With my
maintainer hat on I'm at least not inclinced to add the "is this fair
use or not" hacks on upstream's side, simply because sooner or later
we'll break them and then we have the angry users, instead of nvidia.
And that's the wrong place for bug reports for blobs :-)
-Daniel


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

__

Re: [PATCH] drm/amdgpu: Fix a NULL deref in amdgpu_vm_add_prt_cb()

2017-04-03 Thread Harry Wentland

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

On 2017-04-03 02:41 PM, Dan Carpenter wrote:

We accidentally dereference "cb" if the kmalloc() fails.

Fixes: 451bc8eb8fe6 ("drm/amdgpu: fix PRT teardown on VM fini v3")
Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 0235d7933efd..45a1bcfc41f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1518,7 +1518,7 @@ static void amdgpu_vm_add_prt_cb(struct amdgpu_device 
*adev,
if (fence)
dma_fence_wait(fence, false);

-   amdgpu_vm_prt_put(cb->adev);
+   amdgpu_vm_prt_put(adev);
} else {
cb->adev = adev;
if (!fence || dma_fence_add_callback(fence, >cb,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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


Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

2017-04-21 Thread Harry Wentland

Thanks, Christian for adding me.

On 2017-04-21 09:27 AM, Christian König wrote:

Adding Harry to this mail thread as well, cause is one of the people
really affected by this.

Christian.

Am 21.04.2017 um 15:21 schrieb Christian König:

Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:

   Hi,


"native" to me feels more like "native to the GPU" since these things
really are tied to the GPU not the CPU. That's also why I went with
the
explicit endianness originally so that the driver could properly
declare
what the GPU supports.

And to be honest I would really prefer to stick with that approach for
exactly that reason.



I strongly agree with Christian and Ville on this. I understand fourcc 
endianness as GPU endianness. Usermode needs to be clear on the 
framebuffer format, whether it's GPU or CPU rendered, so kernel should 
define this clearly.


In practice it probably doesn't currently make much difference for AMD 
GPUs. I've never heard of anyone using them on big-endian systems.


Harry



The proposed change would require that drivers have different code path
for different CPU byte order. Those code path tend to be not tested
very
well and are additional complexity we probably don't want inside the
driver.

We can add fixed-endian #defines without too much effort, at least for
the 8 bits per color formats.  In qemu we have the same problem, only
with pixman.  Those formats are native endian too, but often we have to
handle a fixed format, so we did this:

/*
  * pixman image formats are defined to be native endian,
  * that means host byte order on qemu.  So we go define
  * fixed formats here for cases where it is needed, like
  * feeding libjpeg / libpng and writing screenshots.
  */

#ifdef HOST_WORDS_BIGENDIAN
# define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8
# define PIXMAN_BE_x8r8g8b8   PIXMAN_x8r8g8b8
# define PIXMAN_BE_a8r8g8b8   PIXMAN_a8r8g8b8
# define PIXMAN_BE_b8g8r8x8   PIXMAN_b8g8r8x8
# define PIXMAN_BE_b8g8r8a8   PIXMAN_b8g8r8a8
# define PIXMAN_BE_r8g8b8x8   PIXMAN_r8g8b8x8
# define PIXMAN_BE_r8g8b8a8   PIXMAN_r8g8b8a8
# define PIXMAN_BE_x8b8g8r8   PIXMAN_x8b8g8r8
# define PIXMAN_BE_a8b8g8r8   PIXMAN_a8b8g8r8
# define PIXMAN_LE_x8r8g8b8   PIXMAN_b8g8r8x8
#else
# define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8
# define PIXMAN_BE_x8r8g8b8   PIXMAN_b8g8r8x8
# define PIXMAN_BE_a8r8g8b8   PIXMAN_b8g8r8a8
# define PIXMAN_BE_b8g8r8x8   PIXMAN_x8r8g8b8
# define PIXMAN_BE_b8g8r8a8   PIXMAN_a8r8g8b8
# define PIXMAN_BE_r8g8b8x8   PIXMAN_x8b8g8r8
# define PIXMAN_BE_r8g8b8a8   PIXMAN_a8b8g8r8
# define PIXMAN_BE_x8b8g8r8   PIXMAN_r8g8b8x8
# define PIXMAN_BE_a8b8g8r8   PIXMAN_r8g8b8a8
# define PIXMAN_LE_x8r8g8b8   PIXMAN_x8r8g8b8
#endif


Exactly what Mesa did as well.


My personal opinion is that formats in drm_fourcc.h should be
independent of the CPU byte order and the function
drm_mode_legacy_fb_format() and drivers depending on that incorrect
assumption be fixed instead.

The problem is this isn't a kernel-internal thing any more. With the
addition of the ADDFB2 ioctl the fourcc codes became part of the
kernel/userspace abi ...


I know and that's exactly the reason I'm going to object those changes.

The kernel/userspace abi is fixed and changing it like this could
potentially break drivers I'm the co-maintainer of. So that whole
approach is a clear NAK from my side.

If you find a driver or userspace which doesn't use the formats as
defined in the comments of drm_fourcc.h the fix the driver instead of
trying to adjust the common header to broken behavior. Cause the later
will clearly cause problems with drivers who correctly implemented the
interface.

Regards,
Christian.



cheers,
   Gerd

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



___
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


Re: [PATCH] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

2017-04-21 Thread Harry Wentland



On 2017-04-21 11:05 AM, Mario Kleiner wrote:

The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.

Add a quirk to get the full 10 bpc.

Cc: sta...@vger.kernel.org
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>


Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry


---
 drivers/gpu/drm/drm_edid.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fad3d44..2e55599 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -80,6 +80,8 @@
 #define EDID_QUIRK_FORCE_12BPC (1 << 9)
 /* Force 6bpc */
 #define EDID_QUIRK_FORCE_6BPC  (1 << 10)
+/* Force 10bpc */
+#define EDID_QUIRK_FORCE_10BPC (1 << 11)

 struct detailed_mode_closure {
struct drm_connector *connector;
@@ -122,6 +124,9 @@ static const struct edid_quirk {
{ "FCM", 13600, EDID_QUIRK_PREFER_LARGE_75 |
  EDID_QUIRK_DETAILED_IN_CM },

+   /* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
+   { "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+
/* LG Philips LCD LP154W01-A5 */
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
@@ -4244,6 +4249,9 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
if (quirks & EDID_QUIRK_FORCE_8BPC)
connector->display_info.bpc = 8;

+   if (quirks & EDID_QUIRK_FORCE_10BPC)
+   connector->display_info.bpc = 10;
+
if (quirks & EDID_QUIRK_FORCE_12BPC)
connector->display_info.bpc = 12;



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


Re: Pageflip fixes for the amd dal/dc staging tree.

2017-04-21 Thread Harry Wentland

On 2017-04-21 12:23 PM, Mario Kleiner wrote:

Hi

These two patches were written and tested against Harry's
hwentland amd-staging-dc-drm-next branch from a few days ago.
Not sure if that is the right one to base dal/dc patches against,
but it looks recent and active enough?


Yes, I suggest you use that one? It doesn't get extensive testing like 
Alex's amd-staging-4.9 but it's based on a more recent tree. Andrey and 
I use that for cleaning up DC.




They fix pageflip scheduling to always flip at the right target vblank
and pageflip completion events to send out the correct vblank count
and timestamp of flip completion.

Successfully tested on AMD R9 380 Tonga Pro - VI/DCE-10. After applying
these, the dal staging branch performs nicely with my tests :)

I've also tested amdgpu-pro 17.10.2 on the same setup against Linux 4.4/4.8
and found a couple of similar bugs and fixes, but that in a separate mail.


Thanks for your extensive testing and the fixes. I'll let Andrey review 
this more thoroughly as he's spent quite a bit of time trying to get our 
flip/vblank model right. This series looks quite sensible to me, though, 
so feel free to add my


Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry



-mario


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


Re: [PATCH] drm: add check for plane functions

2017-03-21 Thread Harry Wentland



On 2017-03-20 05:42 AM, Shirish S wrote:

On Mon, Mar 20, 2017 at 1:51 PM, Daniel Vetter  wrote:

On Mon, Mar 20, 2017 at 09:58:01AM +0530, Shirish S wrote:

First of all, thanks for your comments/insights.

On Sat, Mar 18, 2017 at 12:59 AM, Eric Anholt  wrote:

Ville Syrjälä  writes:


On Fri, Mar 17, 2017 at 05:57:52PM +0100, Daniel Vetter wrote:

On Fri, Mar 17, 2017 at 01:08:43PM +0200, Ville Syrjälä wrote:

On Fri, Mar 17, 2017 at 03:46:34PM +0530, Shirish S wrote:

On Fri, Mar 17, 2017 at 3:26 PM, Ville Syrjälä
 wrote:

On Fri, Mar 17, 2017 at 01:25:08PM +0530, Shirish S wrote:

update_plane() and disable_plane() functions
assoiciated with setting plane are called
without any check, causing kernel panic.


Why are you registering a plane without the funcs?


Basically, enabling planes and making them fully functional is
generally a 2 -step process,
so i suggest for new drivers wanting to implement/re-design  planes,
would like to tap
the flow at enabling(listing caps) and later at ensuring it works.


I don't think there's much point in exposing something that
doesn't work. And even if you do, you could always just use
stub functions.


Yes, just wire up stub functions if you want to enable planes with
multi-step patch series.


I noticed that there is a underlying assumption only for
plane->(funcs) are implemented, whereas for
other function for crtc/connector/encoder function calls there is a
sanity check(or WARN_ON) through out the framework.

I believe this check wont cause any performance/functional impact.
Please let me know if am missing anything.
And further more help developers to focus on enabling planes via
various tests without causing reboots/system hangs.


I don't particularly like adding more unconditional runtime checks
that just to protect developers from themselves. If you really
think there's value in these, then at least add the checks into
the plane init codepath so that it's a one time cost.


All the plane->funcs are guarded before being called , be it:
 late_register()
 early_unregister()
atomic_destroy_state() etc.,
only update/disable_plane() are called without checking their
existence, am just extending  the protocol.

The same approach could be used for all the other non-optional
hooks. Otherwise the same WARN_ON()s would have to be sprinkled
all over the place, and there's always the risk of missing a few
codepaths that call a specific hook.


I think for these here there's negative value - it allows developers to
create completely broken planes. Stub functions really seem like a much
better idea.


I was thinking

drm_whatever_init()
{
  if (WARN_ON(!funcs->mandatory_thing))
  return -EINVAL;
}


I think since the motive here is to
* convey user space that it does not have permissions to
update/disable available plane due to implementation issues.
* Keeping system alive/usable after non-permitted call.
Adding  a WARN_ON() trace showing something is missing at boot/insmod
time, wont solve the purpose.

This  development phase here could be setting-up infra for adding a
plane available on hardware,populate its capabilities
and to know how user space reads it and tweak it before moving to
configuring registers.

To add to what @Eric Anholt mentioned, without this patch developer
comes to know about
the mandatory functions required in a real tough way of panic and
system freezes,
just because the core framework invokes a NULL function pointer
without checking.
(Am re-stressing here, that only update/disable planes are exceptions
rest all have required checks.)


Eric acked Ville's idea, not your patch.



rather than putting the WARN_ON()s around each call of
funcs->mandatory_thing().


There are similar checks around every
"[crtc/encoder]->funcs->[hooked_up_function specific to vendor]",
including  plane functions called in drm_plane.c & other places like:
 drivers/gpu/drm/drm_crtc_helper.c:1074: if
(plane->funcs->atomic_duplicate_state)
 drivers/gpu/drm/drm_mode_config.c:176:  if (plane->funcs->reset)
 drivers/gpu/drm/drm_plane.c:162:if
(plane->funcs->late_register)
 drivers/gpu/drm/drm_plane.c:242:if (plane->state &&
plane->funcs->atomic_destroy_state)
and so on...
For consistency sake lets have this check.


Those are different functions. They are in transitional helpers, where
we explicitly assume not all the atomic bits are ready yet.

Different use-case, different semantics.


That will fail gracefully (which I guess is what people are after here),
and gives the developer a clear message what's missing.


Having this in our init functions for funcs and helpers would have saved
me tons of time in vc4 and clcd.

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




Re: [PATCH v7 0/4] Adding driver-private objects to atomic state

2017-04-24 Thread Harry Wentland

Patches 1-3: Reviewed-by: Harry Wentland <harry.wentl...@amd.com>
Patch 4: Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

On 2017-04-21 01:51 AM, Dhinakaran Pandiyan wrote:

Changes in this version:
Used connector->atomic_check() to release vcpi slots instead of the
atomic_release() callback.

This series introduces void * type driver-private objects in core and adds
helper functions that operate on these private objects. Drivers need to
implement object-specific functions to swap and clear object states. The
advantage of having void * for these objects in the core is objects of different
types can be managed in the same atomic state array. The series implements
DP-MST link bw tracking using the driver-private object infrastructure.

Pandiyan, Dhinakaran (4):
  drm: Add driver-private objects to atomic state
  drm/dp: Introduce MST topology state to track available link bandwidth
  drm/dp: Add DP MST helpers to atomically find and release vcpi slots
  drm/dp: Track MST link bandwidth

 drivers/gpu/drm/drm_atomic.c  |  65 +++
 drivers/gpu/drm/drm_atomic_helper.c   |   5 ++
 drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
 drivers/gpu/drm/i915/intel_dp_mst.c   |  57 +++--
 include/drm/drm_atomic.h  | 101 +++
 include/drm/drm_dp_mst_helper.h   |  26 ++
 6 files changed, 398 insertions(+), 6 deletions(-)


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


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

2017-08-14 Thread Harry Wentland


On 2017-08-11 02:10 PM, Dhinakaran Pandiyan wrote:
> DPCD 600h - SET_POWER & SET_DP_PWR_VOLTAGE defines power state
> 
> 101 = Set Main-Link for local Sink device and all downstream Sink
> devices to D3 (power-down mode), keep AUX block fully powered, ready to
> reply within a Response Timeout period of 300us.
> 
> This state is useful in a MST dock + MST monitor configuration that
> doesn't wake up from D3 state.
> 
> v2: Use spaces instead of tabs (Jani)
> 
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  include/drm/drm_dp_helper.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index b17476a..47a6cdb 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -618,6 +618,7 @@
>  # define DP_SET_POWER_D00x1
>  # define DP_SET_POWER_D30x2
>  # define DP_SET_POWER_MASK  0x3
> +# define DP_SET_POWER_D3_AUX_ON 0x5
>  
>  #define DP_EDP_DPCD_REV  0x700/* eDP 1.2 */
>  # define DP_EDP_11   0x00
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/14] amdgpu: powerplay: Remove unused function

2017-07-24 Thread Harry Wentland
On 2017-07-24 10:06 AM, Ricardo Ribalda Delgado wrote:
> Hi Harry
> On Mon, Jul 24, 2017 at 4:01 PM, Harry Wentland <harry.wentl...@amd.com> 
> wrote:
> 
>>
>> This is used and needed by the DC display driver. See
>> display/amdgpu_dm/amdgpu_dm_services.c:193 in Alex's amd-staging-4.11 tree:
>>
>> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c?h=amd-staging-4.11
>>
> 
> I could not find any reference to the function in linux-next (>4.12)
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/amd
> 
> Is there any plan to merge Alex's amd-stagin tree?

The plan is to merge/upstream the amd/display portion of Alex's
amd-staging tree. We're currently working on the community feedback we
received to get it into shape.

Harry

> 
> Sorry, I am not very familiar with this subsystem.
> 
> Regards!
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/14] amdgpu: powerplay: Remove unused function

2017-07-24 Thread Harry Wentland
On 2017-07-24 09:35 AM, Ricardo Ribalda Delgado wrote:
> amd_powerplay_display_configuration_change is never called.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 21 -
>  drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h |  3 ---
>  2 files changed, 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
> b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index f73e80c4bf33..1ee7aa5546bf 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -1237,27 +1237,6 @@ int amd_powerplay_reset(void *handle)
>   return pem_handle_event(eventmgr, AMD_PP_EVENT_COMPLETE_INIT, 
> _data);
>  }
>  
> -/* export this function to DAL */
> -
> -int amd_powerplay_display_configuration_change(void *handle,
> - const struct amd_pp_display_configuration *display_config)

This is used and needed by the DC display driver. See
display/amdgpu_dm/amdgpu_dm_services.c:193 in Alex's amd-staging-4.11 tree:

https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c?h=amd-staging-4.11

Harry

> -{
> - struct pp_hwmgr  *hwmgr;
> - struct pp_instance *pp_handle = (struct pp_instance *)handle;
> - int ret = 0;
> -
> - ret = pp_check(pp_handle);
> -
> - if (ret != 0)
> - return ret;
> -
> - hwmgr = pp_handle->hwmgr;
> - mutex_lock(_handle->pp_lock);
> - phm_store_dal_configuration_data(hwmgr, display_config);
> - mutex_unlock(_handle->pp_lock);
> - return 0;
> -}
> -
>  int amd_powerplay_get_display_power_level(void *handle,
>   struct amd_pp_simple_clock_info *output)
>  {
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h 
> b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
> index 07e9c0b5915d..ae49af5cc5d1 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
> @@ -407,9 +407,6 @@ int amd_powerplay_destroy(void *handle);
>  
>  int amd_powerplay_reset(void *handle);
>  
> -int amd_powerplay_display_configuration_change(void *handle,
> - const struct amd_pp_display_configuration *input);
> -
>  int amd_powerplay_get_display_power_level(void *handle,
>   struct amd_pp_simple_clock_info *output);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

2017-07-24 Thread Harry Wentland
On 2017-07-24 10:54 AM, Paul Kocialkowski wrote:
> This adds a common drm helper to detect whether the EDID changed from
> the last known cached one. This is useful help detect that a monitor was
> changed during a suspend/resume cycle.
> 
> When that happens (a monitor is replaced by another one during suspend),
> no hotplug event will be triggered so the change will not be caught at
> resume time. Detecting that the EDID changed allows detecting it.
> 

This makes sense and could be used by other drivers.

Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> Signed-off-by: Paul Kocialkowski <paul.kocialkow...@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c | 45 +
>  include/drm/drm_edid.h |  3 +++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6bb6337be920..f6ce8bc2907a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5036,3 +5036,48 @@ static void drm_get_displayid(struct drm_connector 
> *connector,
>   }
>   return;
>  }
> +
> +/**
> + * drm_check_edid_changed - Check whether the EDID changed since the last 
> update
> + * @connector: connector we're probing
> + * @adapter: I2C adapter to use for DDC
> + *
> + * Check whether the EDID changed since the last time it was updated in the
> + * drm blob cache.
> + *
> + * Return: A boolean indicating whether a change happened or not.
> + */
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter)
> +{
> + struct drm_property_blob *edid_blob;
> + struct edid *edid_stored;
> + struct edid *edid_read;
> + int ret = 0;
> +
> + if (!connector->edid_blob_ptr)
> + return false;
> +
> + edid_blob = drm_property_blob_get(connector->edid_blob_ptr);
> + if (!edid_blob)
> + return false;
> +
> + if (!edid_blob->data || edid_blob->length != sizeof(struct edid))
> + goto out;
> +
> + edid_stored = (struct edid *) edid_blob->data;
> +
> + edid_read = drm_get_edid(connector, adapter);
> + if (!edid_read)
> + goto out;
> +
> + ret = memcmp(edid_stored, edid_read, sizeof(struct edid));
> +
> + kfree(edid_read);
> +
> +out:
> + drm_property_blob_put(edid_blob);
> +
> + return ret != 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_check_edid_changed);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 1e1908a6b1d6..593a97b269c3 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -485,4 +485,7 @@ void drm_edid_get_monitor_name(struct edid *edid, char 
> *name,
>  struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
>  int hsize, int vsize, int fresh,
>  bool rb);
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter);
> +
>  #endif /* __DRM_EDID_H__ */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/14] amdgpu: powerplay: Remove unused function

2017-07-26 Thread Harry Wentland
On 2017-07-26 09:47 AM, Ricardo Ribalda Delgado wrote:
> Hi Harry
> 
> On Mon, Jul 24, 2017 at 5:45 PM, Harry Wentland <harry.wentl...@amd.com> 
> wrote:
>> On 2017-07-24 10:06 AM, Ricardo Ribalda Delgado wrote:
>>> Hi Harry
>>> On Mon, Jul 24, 2017 at 4:01 PM, Harry Wentland <harry.wentl...@amd.com> 
>>> wrote:
>>>
>>>>
>>>> This is used and needed by the DC display driver. See
>>>> display/amdgpu_dm/amdgpu_dm_services.c:193 in Alex's amd-staging-4.11 tree:
>>>>
>>>> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c?h=amd-staging-4.11
>>>>
>>>
>>> I could not find any reference to the function in linux-next (>4.12)
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/amd
>>>
>>> Is there any plan to merge Alex's amd-stagin tree?
>>
>> The plan is to merge/upstream the amd/display portion of Alex's
>> amd-staging tree. We're currently working on the community feedback we
>> received to get it into shape.
> 
> Is there any timeframe for this?
> 

We're actively working on this. It depends on cleaning up our codebase a
fair bit.

Harry

>  At least we should remove the   pr_info("min_core_set_clock not
> set\n"); message.>
> it is (very) misleading right now.
> 
> Regards!
> 
>>
>> Harry
>>
>>>
>>> Sorry, I am not very familiar with this subsystem.
>>>
>>> Regards!
>>>
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 13/13] drm/atomic-helper: Realign function parameters

2017-06-27 Thread Harry Wentland
On 2017-06-27 10:59 AM, Daniel Vetter wrote:
> Too jarring.
> 
> Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers 
> (v2)")
> Cc: Andrey Grodzovsky <andrey.grodzov...@amd.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2f269e4267da..5a80b6960ae1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2964,12 +2964,11 @@ drm_atomic_helper_connector_set_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
>  
> -static int page_flip_common(
> - struct drm_atomic_state *state,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags)
> +static int page_flip_common(struct drm_atomic_state *state,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_plane_state *plane_state;
> @@ -3063,13 +3062,12 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip);
>   * Returns:
>   * Returns 0 on success, negative errno numbers on failure.
>   */
> -int drm_atomic_helper_page_flip_target(
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags,
> - uint32_t target,
> - struct drm_modeset_acquire_ctx *ctx)
> +int drm_atomic_helper_page_flip_target(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event *event,
> +uint32_t flags,
> +uint32_t target,
> +struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_atomic_state *state;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Planned Vega support in Linux

2017-08-08 Thread Harry Wentland
Hi David,

upstream kernels currently have only headless support. We're still
working on getting our display driver accepted upstream but in the
meantime you can compile it yourself from
https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-4.12. With this
you should have no issues booting to desktop with whatever displays you got.

As for the rest of our driver Alex can probably give you a better
picture but I imagine pretty much everything should be working on Vega
on that tree.

Harry


On 2017-08-08 04:12 PM, David Niklas wrote:
> Hello,
> I'm not seeking any secret info.
> I'm a Gentoo Linux user who wants to run some massively parallel
> experiments.
> I'm unwilling to wait and see what kind of support Linux gets because
> the annoying bitcoin miners tend to cause the price to go through the roof
> quickly.
> My current card is an AMD SI HD7780 by MSI.
> I know that currently some form of headless support already exists, but
> then I'd have to use crossfire (which does not work with the opensource
> driver AFAIK).
> I filed a ticket at AMD on 05/07/17 but AMD has not gotten back to me on
> this matter and like I said, if I wait then I risk having to buy
> something way out of my price range.
> --And I really have tried to wait till the last minute--
> Anything official or unofficial will do.
> I am planning to use the OpenCL language to do my MP experiments.
> 
> Thanks,
> David
> 
> BTW: I got the emails to CC from the discussion:
> [RFC] Using DC in amdgpu for upcoming GPU
> so don't worry that I have an email harvester or something.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amd/display: put commit when -ERESTARTSYS received

2017-08-16 Thread Harry Wentland
On 2017-08-16 01:22 PM, Daniel Vetter wrote:
> On Wed, Aug 16, 2017 at 7:12 PM, Alex Deucher  wrote:
>> On Wed, Aug 16, 2017 at 10:22 AM, Jerry Zuo  wrote:
>>> During page flip atomic_check and atomic_commit can return
>>> -ERESTARTSYS to restart the ioctl. When this happens we fail to
>>> put the commit object leading to a memory leak.
>>>
>>> Signed-off-by: Jerry Zuo 
>>
>> The subject should be:
>> drm/atomic: put commit when -ERESTARTSYS received
>> Since the change is in the core atomic code.
> 
> Do we have an igt testcase to exercise this? This is the kind of error
> case handling igt really is made for, and igt has ready-made helpers
> to interrupt ioctls. I think Maarten was even working on such a
> testcase, adding him.

I'm not aware of an IGT test for this. We triggered this scenario when
running mode changes while glxgears is running. We observed no
user-visible issue, only a memory leak. Is IGT able to capture those
(semi-)reliably?

I agree that it would be great to have an IGT test for these corner cases.

Harry

> -Daniel
> >>
>> Alex
>>
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c | 25 +++--
>>>  1 file changed, 23 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index f32506a7c1d6..f2f623dacf90 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -1642,14 +1642,35 @@ int drm_atomic_nonblocking_commit(struct 
>>> drm_atomic_state *state)
>>>  {
>>> struct drm_mode_config *config = >dev->mode_config;
>>> int ret;
>>> +   int i;
>>> +   struct drm_crtc *crtc;
>>> +   struct drm_crtc_state *crtc_state;
>>>
>>> ret = drm_atomic_check_only(state);
>>> -   if (ret)
>>> +   if (ret) {
>>> +   if (ret == -ERESTARTSYS)
>>> +   goto fail;
>>> +
>>> return ret;
>>> +   }
>>>
>>> DRM_DEBUG_ATOMIC("commiting %p nonblocking\n", state);
>>>
>>> -   return config->funcs->atomic_commit(state->dev, state, true);
>>> +   ret = config->funcs->atomic_commit(state->dev, state, true);
>>> +   if (ret == -ERESTARTSYS)
>>> +   goto fail;
>>> +
>>> +   return ret;
>>> +
>>> +   /* cleanup commit object if commit fails with ERESTARTSYS */
>>> +fail:
>>> +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>>> +   if (state->crtcs[i].commit) {
>>> +   drm_crtc_commit_put(state->crtcs[i].commit);
>>> +   }
>>> +   }
>>> +
>>> +   return ret;
>>>  }
>>>  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
>>>
>>> --
>>> 2.11.0
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Soliciting DRM feedback on latest DC rework

2017-05-03 Thread Harry Wentland

Hi all,

Over the last few months we (mostly Andrey and myself) have taken and 
addressed some of the feedback received from December's DC RFC. A lot of 
our work so far centers around atomic. We were able to take a whole 
bunch of the areas where we rolled our own solution and use DRM atomic 
helpers instead.


You can find our most recent drm-next based tree at 
https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip


An outline of the changes with commit hashes from that tree are listed 
below. They aren't necessarily in order but are grouped by functionality.


I would like to solicit input on the changes and the current state of 
amd/display in general.


I'm on IRC every weekday from 9-5 eastern time, sometimes at other 
hours. Feel free to ask questions, discuss, leave comments. Let me know 
if there's anything else I can do to facilitate review.


We know there's more work to be done but would much rather prioritize 
that work based on community feedback than merely our own impressions.


We haven't finished plumbing drm types to the dc types yet, and there 
are still a bunch of other things in progress.  We are not looking to 
re-hash the previous discussion, but rather we'd like some feedback on 
our work so far.


The list of changes (trimmed commit tags):

== Use common helpers for pageflip ==
144da239b047 Use pflip prepare and submit parts (v2)
ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change


== implement atomic_get_properties ==
cf4a84df7189 Fallback on legacy properties in atomic_get_properties
01f96706b6ca get_atomic_property missing for drm_connector_funcs


== Use common helpers for gamma ==
3f547d7098de Use atomic helpers for gamma


== Use atomic helpers for commit ==
41831f55bd58 Refactor atomic commit implementation. (v2)
6c67dd3c5cd5 Refactor headless to use atomic commit.
eb22ef1ecb16 Remove page_fleep_needed function.


== Use atomic helpers for S3 ==
5a6ae6f76249 Switch to DRM helpers in s3.


== Simmplify mapping between DRM and DC objects ==
84a3ee023b9b Remove get_connector_for_link.
6d8978a98b40 Remove get_connector_for_sink.


== Use DRM EDID read instead of DC ==
566969dacfad Fix i2c write flag.
527c3699ff3c Refactor edid read.
5ac51023d275 Fix missing irq refactor causing potential i2c race


== Save DC validate_ctx in atomic_check and use in commit ==
8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper function
27eef98b38c8 Return context from validate_context
ca3ee10e915b Add DM global atomic state
8ba1ca856532 Hook dm private state into atomic_check
10160455ac6d Add correct retain/release for objs in dm_atomic_state
0f1b2e2aecbb Commit validation set from state
258e6a91fc61 Add validate_context to atomic_state
64f569b5df20 Use validate_context from atomic_check in commit


== Start multi-plane implementation ==
601ff4e70b7c decouple per-crtc-plane model
a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
ee02010d7a82 update plane functionalities
3b7345fd1abb Allow planes on all crtcs
d9cf37462156 initialize YUV plane capabilities
248f06b2613e Universal cursor plane hook-up.


== Minor cleanups ==
d99bf02cb8fc Rename atomic_commit parameter.
f15fb9726502 Use amdgpu mode funcs statically
d3e37fa70643 Remove unused define from amdgpu_dm_types
80a38ad58125 Add lock around updating freesync property
8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots

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


Re: Soliciting DRM feedback on latest DC rework

2017-05-03 Thread Harry Wentland



On 2017-05-03 11:02 AM, Daniel Vetter wrote:

On Wed, May 03, 2017 at 04:26:51PM +0200, Christian König wrote:

Hi Harry,

while this looks more and more like it could work something which would
really help would be to have a set of patches squashed together and rebased
on drm-next.

The dc-drm-next-atomic-wip looks like a start, but we need more something
like:
drm/amdgpu: add base DC components
drm/amdgpu: add DCE8 support for DC
drm/amdgpu: add DCE9 support for DC
drm/amdgpu: add DCE10 support for DC
...
drm/amdgpu: enable DC globally
drm/amdgpu: remove old display infrastructure

Otherwise I fear that people will just be lost in the mass amount of patches
we have in the branch.


I think for a quick first feedback round simply something that's based on
top of recent drm-next is good enough, since I'll probably only look at
the aggregate diff anyway (or resulting tree).


This was basically what I figured which is why I didn't invest more time 
to squash changes. I agree with Christian that eventually we probably 
want something like his suggested split but for now I'd rather focus on 
tying a dc_surface to a drm_plane (and same for other objects). Starting 
to tie our objects to drm objects has been very eye-opening, to say the 
least.


Daniel, do you think you'll find time to take a look at this this week 
or next?


Harry


-Daniel



Regards,
Christian.

Am 03.05.2017 um 16:13 schrieb Harry Wentland:

Hi all,

Over the last few months we (mostly Andrey and myself) have taken and
addressed some of the feedback received from December's DC RFC. A lot of
our work so far centers around atomic. We were able to take a whole
bunch of the areas where we rolled our own solution and use DRM atomic
helpers instead.

You can find our most recent drm-next based tree at
https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip

An outline of the changes with commit hashes from that tree are listed
below. They aren't necessarily in order but are grouped by
functionality.

I would like to solicit input on the changes and the current state of
amd/display in general.

I'm on IRC every weekday from 9-5 eastern time, sometimes at other
hours. Feel free to ask questions, discuss, leave comments. Let me know
if there's anything else I can do to facilitate review.

We know there's more work to be done but would much rather prioritize
that work based on community feedback than merely our own impressions.

We haven't finished plumbing drm types to the dc types yet, and there
are still a bunch of other things in progress.  We are not looking to
re-hash the previous discussion, but rather we'd like some feedback on
our work so far.

The list of changes (trimmed commit tags):

== Use common helpers for pageflip ==
144da239b047 Use pflip prepare and submit parts (v2)
ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change


== implement atomic_get_properties ==
cf4a84df7189 Fallback on legacy properties in atomic_get_properties
01f96706b6ca get_atomic_property missing for drm_connector_funcs


== Use common helpers for gamma ==
3f547d7098de Use atomic helpers for gamma


== Use atomic helpers for commit ==
41831f55bd58 Refactor atomic commit implementation. (v2)
6c67dd3c5cd5 Refactor headless to use atomic commit.
eb22ef1ecb16 Remove page_fleep_needed function.


== Use atomic helpers for S3 ==
5a6ae6f76249 Switch to DRM helpers in s3.


== Simmplify mapping between DRM and DC objects ==
84a3ee023b9b Remove get_connector_for_link.
6d8978a98b40 Remove get_connector_for_sink.


== Use DRM EDID read instead of DC ==
566969dacfad Fix i2c write flag.
527c3699ff3c Refactor edid read.
5ac51023d275 Fix missing irq refactor causing potential i2c race


== Save DC validate_ctx in atomic_check and use in commit ==
8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper
function
27eef98b38c8 Return context from validate_context
ca3ee10e915b Add DM global atomic state
8ba1ca856532 Hook dm private state into atomic_check
10160455ac6d Add correct retain/release for objs in dm_atomic_state
0f1b2e2aecbb Commit validation set from state
258e6a91fc61 Add validate_context to atomic_state
64f569b5df20 Use validate_context from atomic_check in commit


== Start multi-plane implementation ==
601ff4e70b7c decouple per-crtc-plane model
a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
ee02010d7a82 update plane functionalities
3b7345fd1abb Allow planes on all crtcs
d9cf37462156 initialize YUV plane capabilities
248f06b2613e Universal cursor plane hook-up.


== Minor cleanups ==
d99bf02cb8fc Rename atomic_commit parameter.
f15fb9726502 Use amdgpu mode funcs statically
d3e37fa70643 Remove unused define from amdgpu_dm_types
80a38ad58125 Add lock around updating freesync property
8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots

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

Re: [PATCH v2 0/3] drm/amd/display: add HDMI Stereo 3D support

2017-05-09 Thread Harry Wentland

Series is Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

On 2017-05-08 12:35 PM, Jeff Smith wrote:

Changes: I have broken one patch into three.

Note: this only covers the display (not amdgpu) portion and does not
  include the code to make it work over the card's DVI port.

I only have one Stereo-3D-capable display to test this on, an LG TV from
about 2014.  All 3 modes (side-by-side half, top-and-bottom, and
frame-packing) appear to work as intended.

Jeff Smith (3):
  drm/amd/display: translate drm's mode to display's stereo-3D timing
  drm/amd/display: use stereo-3D-aware methods when calculating
dimensions
  drm/amd/display: enable stereo-3D modes/timings

 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 33 +++---
 .../display/dc/dce110/dce110_timing_generator.c|  4 ---
 2 files changed, 23 insertions(+), 14 deletions(-)


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


Re: Soliciting DRM feedback on latest DC rework

2017-05-09 Thread Harry Wentland



On 2017-05-09 04:24 AM, Daniel Vetter wrote:

On Mon, May 08, 2017 at 02:54:22PM -0400, Harry Wentland wrote:

Hi Daniel,

Thanks for taking the time to look at DC.

I had a couple more questions/comments in regard to the patch you posted on
IRC: http://paste.debian.net/plain/930704

My impression is that this item is the most important next step for us:


From a quick glance I think what we want instead is:
- amdgpu_crtc_state and amdgpu_plane_state as following:

struct amdgpu_crtc_state {
struct drm_crtc_state base;
struct dc_stream;
};


Unfortunately as sketched here it doesn't quite mesh with what we currently
have, which is:

struct stream {
struct core_stream protected;
...
}

struct core_stream {
struct dc_stream public;
...
}

struct dc_stream {
...
}

Any objections to doing something like this instead:

#ifdef LINUX
#include "drm_crtc.h"
#endif

struct dc_stream {
#ifdef LINUX
struct drm_crtc_state base;
#endif
...
}

The ifdefs are then removed on Linux versions of DC, while other OSs
wouldn't compile with the LINUX flag.


- validate_context->res_ctx->pool looks extremely fishy. In principle,
  refcounting does not mesh with the duplicate, check, then
  free-or-commit semantics of atomic. Are you sure this works
  correctly when doing TEST_ONLY commits? igt or weston (with Daniel's
  patches) are your friend (or enemy) here :-)

  The common approach all other drivers implement:
  - Same duplicate semantics for private objects as for core drm
objects. The private obj helpers will help with cutting down the
boiler-plate.
  - No refcounts, instead an allocation bitmask in the object one up
in the hierarchy (usually global state, but sometimes also
crtc/stream).
  - If you want to keep the current design, then you
must do a deep copy of pool (i.e. not just the struct, but also
every struct that might change it points too). The above
accomplishes that essentially, except in standard atomic patterns.
  - You'll probably need a bunch of for_each_foo_in_context macros,
built using the private state helpers.

  Trying to review correctness of atomic_check when private resources
  are refcounted is real hard. The only case we have is vc4, and it's
  kinda not pretty (it has it's own manual rollback hacks in the
  release functions). Going entirely with free-standing stuff is much
  better.


Good points here. I think I'll ultimately have to get IGT running against
our code with TEST_ONLY commits and see what happens. Ultimately we probably
have to deep copy, one way or another. I don't really want any rollback
stuff as that would be near impossible to maintain.


This shouldn't be a huge conceptual change in the DC design (it
already has checks for "is this unchanged" and then ignore that
object), just quite a bit more invasive than sprinkling for_each_*
macros all over the place. From a glane it could be that you'd get
80% there by having a for_each_changed_*_in_context set of macros,
with the current code everywhere else, and the "jumps over unchanged
obj because they're not in drm_atomic_state/dc_validation_context"
logic on drm atomic.


Yeah, this should fit mostly with DC design. Will evaluate this once we link
DC objects to DRM state objects.


@@ -1640,6 +1644,8 @@ static void dm_crtc_helper_disable(struct drm_crtc *crtc)
 {
 }

+/* no dummy funcs pls, counts everywhere */
+


Does the comment apply to the preceding or next function? What do you mean
with "counts everywhere"?


In general you have a lot of callbacks which are either just {} or {
return 0; }, aka empty/dummy implementations.

We've refactored atomic helpers a lot to make all of these optional, pls
remove them. This was a somewhat recent development, I guess initial
atomic DC still had to have all these dummy callbacks.



That makes sense. We haven't really revisited these since our initial 
work on atomic more than a year ago.



 static int dm_crtc_helper_atomic_check(
struct drm_crtc *crtc,
struct drm_crtc_state *state)




@@ -3077,6 +3102,15 @@ int amdgpu_dm_atomic_check(struct drm_device *dev,

acrtc = to_amdgpu_crtc(crtc);

+   /* This is the wrong way round. If you have a requirement for a
+* 1:1 connector/crtc mapping, then loop over connectors and
+* grab the crtc from there. Plus make sure there's really only
+* 1 connector per crtc (but the possible clones stuff should
+* catch that for you I think, at least with latest atomic
+* helpers.
+*
+* Similar for the same loop in commit.
+*/
aconnector = 
amdgpu_dm_find_f

Re: [PATCH v2 0/3] drm/amd/display: add HDMI Stereo 3D support

2017-05-10 Thread Harry Wentland

On 2017-05-08 12:35 PM, Jeff Smith wrote:

Changes: I have broken one patch into three.

Note: this only covers the display (not amdgpu) portion and does not
  include the code to make it work over the card's DVI port.

I only have one Stereo-3D-capable display to test this on, an LG TV from
about 2014.  All 3 modes (side-by-side half, top-and-bottom, and
frame-packing) appear to work as intended.



Hi Jeff,

how do you test this? Which app, etc, are you using? I've never tested 
stereo 3D before on Linux but would really love to give this a quick 
spin before pulling these patches. Everything that pops up on google 
points me to the bino video player but that segfaults on Ubuntu 17.04 
with any video.


Harry



Jeff Smith (3):
  drm/amd/display: translate drm's mode to display's stereo-3D timing
  drm/amd/display: use stereo-3D-aware methods when calculating
dimensions
  drm/amd/display: enable stereo-3D modes/timings

 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 33 +++---
 .../display/dc/dce110/dce110_timing_generator.c|  4 ---
 2 files changed, 23 insertions(+), 14 deletions(-)


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


Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

2017-06-26 Thread Harry Wentland
On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> Problem : While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immediately following  an atomic_commit.
> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the state and only disabled
> planes. This probably due to a commit which hadn't changed any property
> which would require attaching crtc state. This means drmHandleEvent
> will never wake up from read since without CRTC in atomic state
> the event fd will not be signaled.
> 
> Fix: Protect against this issue by failing atomic_commit early in
> drm_mode_atomic_commit where such probelm can be identified.
> 
> v2:
> Fix typos and extra newlines.
> 
> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
> Signed-off-by: Andrey Grodzovsky <andrey.grodzov...@amd.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..48145bf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
> - int i, ret;
> + int i, c = 0, ret;
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>   return 0;
> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  
>   crtc_state->event->base.fence = fence;
>   }
> +
> + c++;
>   }
>  
> + /*
> +  * Having this flag means user mode pends on event which will never
> +  * reach due to lack of at least one CRTC for signaling
> +  */
> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> + return -EINVAL;
> +
>   return 0;
>  }
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

2017-06-19 Thread Harry Wentland
On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> Problem:
> While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immidietly follwoing an atomic_commit.

s/immidietly/immediately/g
s/follwoing/following/g

> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the state and only disabled
> planes. This probably due to a commit which hadn't changed any property
> which would require attaching crtc state. This means drmHandleEvent
> will never wake up from read since without CRTC in atomic state
> the event fd will not be singnaled.

s/singnaled/signaled/g

> This point to a bug in IGT but also DRM should gracefully
> fail  such scenario so no hang on user side will happen.
> 

Can we create an IGT fix for this to make sure this won't happen?

> Fix:
> Explicitly fail by failing atomic_commit early in
> drm_mode_atomic_commit where such problem can be identified.
> 

The change seems reasonable to me but I would like to see some input
from someone who's more familiar with the usermode side of things.

> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/drm_atomic.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..32eae1c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
> - int i, ret;
> + int i, c = 0, ret;
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>   return 0;
> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  
>   crtc_state->event->base.fence = fence;
>   }
> +
> + c++;

Not sure if intentional, but I like it.

>   }
>  
> + /*
> +  * Having this flag means user mode pends on event which will never
> +  * reach due to lack of at least one CRTC for signaling
> +  */
> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> + return -EINVAL;
> +
>   return 0;
>  }
>  
> @@ -2179,6 +2188,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   drm_mode_object_unreference(obj);
>   }
>  
> +
> +

Remove these extraneous newlines.

Harry

>   ret = prepare_crtc_signaling(dev, state, arg, file_priv, _state,
>_fences);
>   if (ret)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [kbuild-all] [radeon-alex:amd-staging-4.11 1061/1085] sparc64-linux-gnu-gcc: error: unrecognized command line option '-msse'; did you mean '-fdse'?

2017-05-19 Thread Harry Wentland

On 2017-05-16 05:56 AM, Christian König wrote:

Am 16.05.2017 um 11:16 schrieb Michel Dänzer:

[ Dropping build robot aliases, adding amd-gfx and DC folks ]

On 16/05/17 05:18 PM, Philip Li wrote:

On Tue, May 16, 2017 at 10:04:32AM +0200, Christian König wrote:

Am 16.05.2017 um 07:20 schrieb zhoucm1:

On 2017年05月15日 17:52, kbuild test robot wrote:

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
head:   c285c73f2213f503a93aa142fff186e160b4a371
commit: 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24 [1061/1085]
drm/amd: fix init order of sched job
config: sparc-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross 


-O ~/bin/make.cross
 chmod +x ~/bin/make.cross
 git checkout 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24
 # save the attached .config to linux build tree
 make.cross ARCH=sparc

All errors (new ones prefixed by >>):


sparc64-linux-gnu-gcc: error: unrecognized command line
option '-msse'; did you mean '-fdse'?
sparc64-linux-gnu-gcc: error: unrecognized command line
option '-mpreferred-stack-boundary=4'

[...]


Thanks for input, the issue does exist (as introduced by
"drm/amdgpu/display: Enable DCN in DC"), so the report like
https://lists.01.org/pipermail/kbuild-all/2017-May/033857.html
does make sense.

It's because some DC Makefiles hardcode -msse and other compiler flags
which aren't supported on all architectures.

DC folks, please fix this, either by only adding flags on architectures
where they're supported, or by preventing the corresponding code from
getting built on architectures where they're not supported.


Ah, yes that's indeed an issue.

But please at least fix the bisect or otherwise the wrong people get 
those mails and wonder about the error messages.




I just submitted a fix for this: "drm/amd/display: Limit DCN to x86 arch"

It seems to do the trick but I've never really dealt with multiple 
architectures before. Would appreciate if someone more knowledgeable 
than myself reviews this.


Essentially I'm blocking DCN code for non-x86 architectures for now.

Thanks,
Harry


Christian.


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


Re: Soliciting DRM feedback on latest DC rework

2017-05-08 Thread Harry Wentland

Hi Daniel,

Thanks for taking the time to look at DC.

I had a couple more questions/comments in regard to the patch you posted 
on IRC: http://paste.debian.net/plain/930704


My impression is that this item is the most important next step for us:


From a quick glance I think what we want instead is:
- amdgpu_crtc_state and amdgpu_plane_state as following:

struct amdgpu_crtc_state {
struct drm_crtc_state base;
struct dc_stream;
};


Unfortunately as sketched here it doesn't quite mesh with what we 
currently have, which is:


struct stream {
struct core_stream protected;
...
}

struct core_stream {
struct dc_stream public;
...
}

struct dc_stream {
...
}

Any objections to doing something like this instead:

#ifdef LINUX
#include "drm_crtc.h"
#endif

struct dc_stream {
#ifdef LINUX
struct drm_crtc_state base;
#endif
...
}

The ifdefs are then removed on Linux versions of DC, while other OSs 
wouldn't compile with the LINUX flag.



- validate_context->res_ctx->pool looks extremely fishy. In principle,
  refcounting does not mesh with the duplicate, check, then
  free-or-commit semantics of atomic. Are you sure this works
  correctly when doing TEST_ONLY commits? igt or weston (with Daniel's
  patches) are your friend (or enemy) here :-)

  The common approach all other drivers implement:
  - Same duplicate semantics for private objects as for core drm
objects. The private obj helpers will help with cutting down the
boiler-plate.
  - No refcounts, instead an allocation bitmask in the object one up
in the hierarchy (usually global state, but sometimes also
crtc/stream).
  - If you want to keep the current design, then you
must do a deep copy of pool (i.e. not just the struct, but also
every struct that might change it points too). The above
accomplishes that essentially, except in standard atomic patterns.
  - You'll probably need a bunch of for_each_foo_in_context macros,
built using the private state helpers.

  Trying to review correctness of atomic_check when private resources
  are refcounted is real hard. The only case we have is vc4, and it's
  kinda not pretty (it has it's own manual rollback hacks in the
  release functions). Going entirely with free-standing stuff is much
  better.


Good points here. I think I'll ultimately have to get IGT running 
against our code with TEST_ONLY commits and see what happens. Ultimately 
we probably have to deep copy, one way or another. I don't really want 
any rollback stuff as that would be near impossible to maintain.



This shouldn't be a huge conceptual change in the DC design (it
already has checks for "is this unchanged" and then ignore that
object), just quite a bit more invasive than sprinkling for_each_*
macros all over the place. From a glane it could be that you'd get
80% there by having a for_each_changed_*_in_context set of macros,
with the current code everywhere else, and the "jumps over unchanged
obj because they're not in drm_atomic_state/dc_validation_context"
logic on drm atomic.


Yeah, this should fit mostly with DC design. Will evaluate this once we 
link DC objects to DRM state objects.



@@ -1640,6 +1644,8 @@ static void dm_crtc_helper_disable(struct drm_crtc *crtc)
 {
 }

+/* no dummy funcs pls, counts everywhere */
+


Does the comment apply to the preceding or next function? What do you 
mean with "counts everywhere"?



 static int dm_crtc_helper_atomic_check(
struct drm_crtc *crtc,
struct drm_crtc_state *state)




@@ -3077,6 +3102,15 @@ int amdgpu_dm_atomic_check(struct drm_device *dev,

acrtc = to_amdgpu_crtc(crtc);

+   /* This is the wrong way round. If you have a requirement for a
+* 1:1 connector/crtc mapping, then loop over connectors and
+* grab the crtc from there. Plus make sure there's really only
+* 1 connector per crtc (but the possible clones stuff should
+* catch that for you I think, at least with latest atomic
+* helpers.
+*
+* Similar for the same loop in commit.
+*/
aconnector = 
amdgpu_dm_find_first_crct_matching_connector(state, crtc, true);

action = get_dm_commit_action(crtc_state);


Good point. This code is still a bit of a mess.

Harry


On 2017-05-03 03:12 PM, Harry Wentland wrote:



On 2017-05-03 11:02 AM, Daniel Vetter wrote:

On Wed, May 03, 2017 at 04:26:51PM +0200, Christian König wrote:

Hi Harry,

while this looks more and more like it could work something which would
really help would be to have a set of patches squashed together and
rebased
on drm-next.

The dc-drm-next-atomic-wip looks like a star

Re: Soliciting DRM feedback on latest DC rework

2017-05-08 Thread Harry Wentland



On 2017-05-08 03:07 PM, Dave Airlie wrote:

On 9 May 2017 at 04:54, Harry Wentland <harry.wentl...@amd.com> wrote:

Hi Daniel,

Thanks for taking the time to look at DC.

I had a couple more questions/comments in regard to the patch you posted on
IRC: http://paste.debian.net/plain/930704

My impression is that this item is the most important next step for us:


From a quick glance I think what we want instead is:
- amdgpu_crtc_state and amdgpu_plane_state as following:

struct amdgpu_crtc_state {
struct drm_crtc_state base;
struct dc_stream;
};



Unfortunately as sketched here it doesn't quite mesh with what we currently
have, which is:

struct stream {
struct core_stream protected;
...
}

struct core_stream {
struct dc_stream public;
...
}

struct dc_stream {
...
}



Is there any major reason to keep all those abstractions?

Could you collapse everything into struct dc_stream?

I haven't looked recently but I didn't get the impression there was a
lot of design around what was public/protected, more whatever needed
to be used by someone else was in public.



Yeah, I've been thinking the same recently.

The thought behind public/protected was that DM can modify public but 
would never touch protected. We don't really want to give DM an 
opportunity to touch core_stream directly. If it does we might lose a 
lot of our confidence in DC correctness which comes from running the 
same code on different OSes.


That said, this could be caught during code review and collapsing these 
structs would simplify things a bit. For one, it would allow me to take 
Daniel's proposal as-is.


I'll think about it some more and maybe mock up a couple patches and see 
how they're received internally.


Harry


Dave.


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


Re: [PATCH 2/6] drm/amd/display: Use new DRM API where possible

2017-10-13 Thread Harry Wentland
On 2017-10-12 05:15 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li" 
> 
> To conform to DRM's new API, we should not be accessing a DRM object's
> internal state directly. Rather, the DRM for_each_old/new_* iterators,
> and drm_atomic_get_old/new_* interface should be used.
> 
> This is an ongoing process. For now, update the DRM-facing atomic
> functions, where the atomic state object is given.
> 
> Signed-off-by: Leo (Sunpeng) Li 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 131 
> +++---
>  1 file changed, 66 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index cc024ab..d4426b3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3873,28 +3873,31 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
>  {
>   uint32_t i;
>   struct drm_plane *plane;
> - struct drm_plane_state *old_plane_state;
> + struct drm_plane_state *old_plane_state, *new_plane_state;
>   struct dc_stream_state *dc_stream_attach;
>   struct dc_plane_state *plane_states_constructed[MAX_SURFACES];
>   struct amdgpu_crtc *acrtc_attach = to_amdgpu_crtc(pcrtc);
> - struct dm_crtc_state *acrtc_state = to_dm_crtc_state(pcrtc->state);
> + struct drm_crtc_state *new_pcrtc_state =
> + drm_atomic_get_new_crtc_state(state, pcrtc);
> + struct dm_crtc_state *acrtc_state = to_dm_crtc_state(new_pcrtc_state);
>   int planes_count = 0;
>   unsigned long flags;
>  
>   /* update planes when needed */
> - for_each_old_plane_in_state(state, plane, old_plane_state, i) {
> - struct drm_plane_state *plane_state = plane->state;
> - struct drm_crtc *crtc = plane_state->crtc;
> - struct drm_framebuffer *fb = plane_state->fb;
> + for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
> new_plane_state, i) {
> + struct drm_crtc *crtc = new_plane_state->crtc;
> + struct drm_crtc_state *new_crtc_state =
> + drm_atomic_get_new_crtc_state(state, crtc);
> + struct drm_framebuffer *fb = new_plane_state->fb;
>   bool pflip_needed;
> - struct dm_plane_state *dm_plane_state = 
> to_dm_plane_state(plane_state);
> + struct dm_plane_state *dm_plane_state = 
> to_dm_plane_state(new_plane_state);
>  
>   if (plane->type == DRM_PLANE_TYPE_CURSOR) {
>   handle_cursor_update(plane, old_plane_state);
>   continue;
>   }
>  
> - if (!fb || !crtc || pcrtc != crtc || !crtc->state->active)
> + if (!fb || !crtc || pcrtc != crtc || !new_crtc_state->active)
>   continue;
>  
>   pflip_needed = !state->allow_modeset;
> @@ -3918,13 +3921,13 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
>   dc_stream_attach = acrtc_state->stream;
>   planes_count++;
>  
> - } else if (crtc->state->planes_changed) {
> + } else if (new_crtc_state->planes_changed) {
>   /* Assume even ONE crtc with immediate flip means
>* entire can't wait for VBLANK
>* TODO Check if it's correct
>*/
>   *wait_for_vblank =
> - pcrtc->state->pageflip_flags & 
> DRM_MODE_PAGE_FLIP_ASYNC ?
> + new_pcrtc_state->pageflip_flags & 
> DRM_MODE_PAGE_FLIP_ASYNC ?
>   false : true;
>  
>   /* TODO: Needs rework for multiplane flip */
> @@ -3942,7 +3945,7 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
>   if (planes_count) {
>   unsigned long flags;
>  
> - if (pcrtc->state->event) {
> + if (new_pcrtc_state->event) {
>  
>   drm_crtc_vblank_get(pcrtc);
>  
> @@ -3968,7 +3971,7 @@ int amdgpu_dm_atomic_commit(
>   bool nonblock)
>  {
>   struct drm_crtc *crtc;
> - struct drm_crtc_state *new_state;
> + struct drm_crtc_state *old_crtc_state, *new_state;
>   struct amdgpu_device *adev = dev->dev_private;
>   int i;
>  
> @@ -3979,8 +3982,8 @@ int amdgpu_dm_atomic_commit(
>* it will update crtc->dm_crtc_state->stream pointer which is used in
>* the ISRs.
>*/
> - for_each_new_crtc_in_state(state, crtc, new_state, i) {
> - struct dm_crtc_state *old_acrtc_state = 
> to_dm_crtc_state(crtc->state);
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_state, 
> i) {
> + struct dm_crtc_state *old_acrtc_state = 
> 

Re: [PATCH 0/6] Use new DRM API where possible, and cleanups.

2017-10-13 Thread Harry Wentland
Patches 3-6 are
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

On 2017-10-12 05:15 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li" <sunpeng...@amd.com>
> 
> Hi Dave,
> 
> This series reworks the previous patch. Patch 1 is a v2 of the previous,
> and additional patches are from the feedback received. They apply on top
> of your drm-next-amd-dc-staging branch.
> 
> Thanks,
> Leo
> 
> Leo (Sunpeng) Li (6):
>   drm/amd/display: Use DRM new-style object iterators.
>   drm/amd/display: Use new DRM API where possible
>   drm/amd/display: Unify DRM state variable namings.
>   drm/amd/display: Unify amdgpu_dm state variable namings.
>   drm/amd/display: Fix typo
>   drm/amd/display: Remove useless pcrtc pointer
> 
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 320 
> +++---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +-
>  2 files changed, 156 insertions(+), 167 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/6] drm/amd/display: Use DRM new-style object iterators.

2017-10-13 Thread Harry Wentland
On 2017-10-13 03:29 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li" <sunpeng...@amd.com>
> 
> Use the correct for_each_new/old_* iterators instead of for_each_*
> 
> The following functions were considered:
> 
> amdgpu_dm_find_first_crtc_matching_connector: use for_each_new
> - Old from_state_var flag was always choosing the new state
> 
> amdgpu_dm_display_resume: use for_each_new
> - drm_atomic_helper_duplicate_state is called during suspend to
>   cache the state
> - It sets 'state' within the state triplet to 'new_state'
> 
> amdgpu_dm_commit_planes: use for_each_old
> - Called after the state was swapped (via atomic commit tail)
> 
> amdgpu_dm_atomic_commit: use for_each_new
> - Called before the state is swapped
> 
> amdgpu_dm_atomic_commit_tail: use for_each_old
> - Called after the state was swapped
> 
> dm_update_crtcs_state: use for_each_new
> - Called before the state is swapped (via atomic check)
> 
> amdgpu_dm_atomic_check: use for_each_new
> - Called before the state is swapped
> 
> v2: Split out typo fixes to a new patch.
> 
> v3: Say "functions considered" instead of "affected functions". The
> latter implies that changes are made to each.
> 
> Signed-off-by: Leo (Sunpeng) Li <sunpeng...@amd.com>

Patches 1-2 (v3) are also
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  3 +--
>  2 files changed, 12 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 9bfe1f9..cc024ab 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -570,23 +570,15 @@ static int dm_suspend(void *handle)
>  
>  struct amdgpu_dm_connector *amdgpu_dm_find_first_crct_matching_connector(
>   struct drm_atomic_state *state,
> - struct drm_crtc *crtc,
> - bool from_state_var)
> + struct drm_crtc *crtc)
>  {
>   uint32_t i;
>   struct drm_connector_state *conn_state;
>   struct drm_connector *connector;
>   struct drm_crtc *crtc_from_state;
>  
> - for_each_new_connector_in_state(
> - state,
> - connector,
> - conn_state,
> - i) {
> - crtc_from_state =
> - from_state_var ?
> - conn_state->crtc :
> - connector->state->crtc;
> + for_each_new_connector_in_state(state, connector, conn_state, i) {
> + crtc_from_state = conn_state->crtc;
>  
>   if (crtc_from_state == crtc)
>   return to_amdgpu_dm_connector(connector);
> @@ -3890,7 +3882,7 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
>   unsigned long flags;
>  
>   /* update planes when needed */
> - for_each_new_plane_in_state(state, plane, old_plane_state, i) {
> + for_each_old_plane_in_state(state, plane, old_plane_state, i) {
>   struct drm_plane_state *plane_state = plane->state;
>   struct drm_crtc *crtc = plane_state->crtc;
>   struct drm_framebuffer *fb = plane_state->fb;
> @@ -4024,7 +4016,7 @@ void amdgpu_dm_atomic_commit_tail(
>   dm_state = to_dm_atomic_state(state);
>  
>   /* update changed items */
> - for_each_new_crtc_in_state(state, crtc, old_crtc_state, i) {
> + for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
>   struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
>   struct drm_crtc_state *new_state = crtc->state;
>  
> @@ -4113,11 +4105,9 @@ void amdgpu_dm_atomic_commit_tail(
>   new_acrtc_state = 
> to_dm_crtc_state(new_crtcs[i]->base.state);
>  
>   new_stream = new_acrtc_state->stream;
> - aconnector =
> - amdgpu_dm_find_first_crct_matching_connector(
> + aconnector = 
> amdgpu_dm_find_first_crct_matching_connector(
>   state,
> - _crtcs[i]->base,
> - false);
> + _crtcs[i]->base);
>   if (!aconnector) {
>   DRM_DEBUG_DRIVER("Atomic commit: Failed to find 
> connector for acrtc id:%d "
>

Re: [PATCH 2/6] drm/amd/display: Use new DRM API where possible

2017-10-13 Thread Harry Wentland
On 2017-10-13 01:26 PM, Andrey Grodzovsky wrote:
> 
> 
> On 10/13/2017 12:18 PM, Harry Wentland wrote:
>> On 2017-10-12 05:15 PM, sunpeng...@amd.com wrote:
>>> From: "Leo (Sunpeng) Li" <sunpeng...@amd.com>
>>>
>>> To conform to DRM's new API, we should not be accessing a DRM object's
>>> internal state directly. Rather, the DRM for_each_old/new_* iterators,
>>> and drm_atomic_get_old/new_* interface should be used.
>>>
>>> This is an ongoing process. For now, update the DRM-facing atomic
>>> functions, where the atomic state object is given.
>>>
>>> Signed-off-by: Leo (Sunpeng) Li <sunpeng...@amd.com>
>>> ---
>>>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 131 
>>> +++---
>>>   1 file changed, 66 insertions(+), 65 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> index cc024ab..d4426b3 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -3873,28 +3873,31 @@ static void amdgpu_dm_commit_planes(struct 
>>> drm_atomic_state *state,
>>>   {
>>>   uint32_t i;
>>>   struct drm_plane *plane;
>>> -    struct drm_plane_state *old_plane_state;
>>> +    struct drm_plane_state *old_plane_state, *new_plane_state;
>>>   struct dc_stream_state *dc_stream_attach;
>>>   struct dc_plane_state *plane_states_constructed[MAX_SURFACES];
>>>   struct amdgpu_crtc *acrtc_attach = to_amdgpu_crtc(pcrtc);
>>> -    struct dm_crtc_state *acrtc_state = to_dm_crtc_state(pcrtc->state);
>>> +    struct drm_crtc_state *new_pcrtc_state =
>>> +    drm_atomic_get_new_crtc_state(state, pcrtc);
>>> +    struct dm_crtc_state *acrtc_state = to_dm_crtc_state(new_pcrtc_state);
>>>   int planes_count = 0;
>>>   unsigned long flags;
>>>     /* update planes when needed */
>>> -    for_each_old_plane_in_state(state, plane, old_plane_state, i) {
>>> -    struct drm_plane_state *plane_state = plane->state;
>>> -    struct drm_crtc *crtc = plane_state->crtc;
>>> -    struct drm_framebuffer *fb = plane_state->fb;
>>> +    for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
>>> new_plane_state, i) {
>>> +    struct drm_crtc *crtc = new_plane_state->crtc;
>>> +    struct drm_crtc_state *new_crtc_state =
>>> +    drm_atomic_get_new_crtc_state(state, crtc);
>>> +    struct drm_framebuffer *fb = new_plane_state->fb;
>>>   bool pflip_needed;
>>> -    struct dm_plane_state *dm_plane_state = 
>>> to_dm_plane_state(plane_state);
>>> +    struct dm_plane_state *dm_plane_state = 
>>> to_dm_plane_state(new_plane_state);
>>>     if (plane->type == DRM_PLANE_TYPE_CURSOR) {
>>>   handle_cursor_update(plane, old_plane_state);
>>>   continue;
>>>   }
>>>   -    if (!fb || !crtc || pcrtc != crtc || !crtc->state->active)
>>> +    if (!fb || !crtc || pcrtc != crtc || !new_crtc_state->active)
>>>   continue;
>>>     pflip_needed = !state->allow_modeset;
>>> @@ -3918,13 +3921,13 @@ static void amdgpu_dm_commit_planes(struct 
>>> drm_atomic_state *state,
>>>   dc_stream_attach = acrtc_state->stream;
>>>   planes_count++;
>>>   -    } else if (crtc->state->planes_changed) {
>>> +    } else if (new_crtc_state->planes_changed) {
>>>   /* Assume even ONE crtc with immediate flip means
>>>    * entire can't wait for VBLANK
>>>    * TODO Check if it's correct
>>>    */
>>>   *wait_for_vblank =
>>> -    pcrtc->state->pageflip_flags & 
>>> DRM_MODE_PAGE_FLIP_ASYNC ?
>>> +    new_pcrtc_state->pageflip_flags & 
>>> DRM_MODE_PAGE_FLIP_ASYNC ?
>>>   false : true;
>>>     /* TODO: Needs rework for multiplane flip */
>>> @@ -3942,7 +3945,7 @@ static void amdgpu_dm_commit_planes(struct 
>>> drm_atomic_state *state,
>>>   if (planes_count) {
>>>   unsigned long flags;
>>>   -    if (pcrtc->state->event) {
>>> +  

Re: [PATCH] drm/amd/dc: fix semicolon.cocci warnings

2017-10-13 Thread Harry Wentland
On 2017-10-12 07:35 PM, kbuild test robot wrote:
> drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:134:2-3: 
> Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> Fixes: 80be23c57868 ("drm/amd/dc: Add dc display driver (v2)")
> CC: Harry Wentland <harry.wentl...@amd.com>
> Signed-off-by: Fengguang Wu <fengguang...@intel.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
> 
>  gpio_service.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c
> +++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c
> @@ -131,7 +131,7 @@ failure_2:
>  
>   if (slot)
>   dm_free(slot);
> - };
> + }
>  
>  failure_1:
>   dm_free(service);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amd/display: fix ifnullfree.cocci warnings

2017-10-13 Thread Harry Wentland
On 2017-10-12 07:17 PM, kbuild test robot wrote:
> drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:134:3-8: 
> WARNING: NULL check before freeing functions like kfree, debugfs_remove, 
> debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider 
> reorganizing relevant code to avoid passing NULL values.
> drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:175:4-9: 
> WARNING: NULL check before freeing functions like kfree, debugfs_remove, 
> debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider 
> reorganizing relevant code to avoid passing NULL values.
> 
>  NULL check before some freeing functions is not needed.
> 
>  Based on checkpatch warning
>  "kfree(NULL) is safe this check is probably not required"
>  and kfreeaddr.cocci by Julia Lawall.
> 
> Generated by: scripts/coccinelle/free/ifnullfree.cocci
> 
> Fixes: f09cd1f46388 ("drm/amd/display: Use kernel alloc/free")
> Signed-off-by: Fengguang Wu <fengguang...@intel.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
> 
>  gpio_service.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> --- a/drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c
> +++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c
> @@ -130,8 +130,7 @@ failure_2:
>  
>   slot = service->busyness[index_of_id];
>  
> - if (slot)
> - kfree(slot);
> + kfree(slot);
>   };
>  
>  failure_1:
> @@ -171,8 +170,7 @@ void dal_gpio_service_destroy(
>   do {
>   uint32_t *slot = (*ptr)->busyness[index_of_id];
>  
> - if (slot)
> - kfree(slot);
> + kfree(slot);
>  
>   ++index_of_id;
>   } while (index_of_id < GPIO_ID_COUNT);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amd: DC pull request review

2017-09-27 Thread Harry Wentland
On 2017-09-27 12:48 PM, Daniel Vetter wrote:
> On Wed, Sep 27, 2017 at 6:38 PM, Sean Paul  wrote:
>> Any chance we can address the i2c/gpio [re-]implementations as well?
> 
> It's already on the list. Part of this is code that's probably dead,
> the other is a bit too much layer cake still left, and the final bits
> are not fully using drm helpers for edid parsing and tons of other
> stuff. But afaics all the i2c stuff does go through the i2c_adapter
> abstraction in a proper fashion, which is at least the foundational
> work. The other bits should be all captured in the todo already.

There might still be some dead code around i2c stuff. I'll take a look
and see what I can rip out.

If there's any specific function, struct, etc. that's of concern let me
know as well.

Harry

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


Re: [PATCH] drm/amd: DC pull request review

2017-09-27 Thread Harry Wentland
On 2017-09-27 02:12 PM, Harry Wentland wrote:
> On 2017-09-27 12:48 PM, Daniel Vetter wrote:
>> On Wed, Sep 27, 2017 at 6:38 PM, Sean Paul <seanp...@chromium.org> wrote:
>>> Any chance we can address the i2c/gpio [re-]implementations as well?
>>
>> It's already on the list. Part of this is code that's probably dead,
>> the other is a bit too much layer cake still left, and the final bits
>> are not fully using drm helpers for edid parsing and tons of other
>> stuff. But afaics all the i2c stuff does go through the i2c_adapter
>> abstraction in a proper fashion, which is at least the foundational
>> work. The other bits should be all captured in the todo already.
> 
> There might still be some dead code around i2c stuff. I'll take a look
> and see what I can rip out.
> 

Looks like there currently are no easy pickings. What we have is:

1) Connector info read

See get_ext_display_connection_info

On some boards the connector information has to be read through a
special I2C channel. This line is only used for this purpose and only on
driver init.


2) SCDC stuff

This should all be reworked to go through DRM's SCDC code. When this is
done some unnecessary I2C code can be retired as well.


3) Max TMDS clock read

See dal_ddc_service_i2c_query_dp_dual_mode_adaptor

This should happen in DRM as well. I haven't checked if there's
currently functionality in DRM. If not we can propose something.


4) HDMI retimer programming

Some boards have an HDMI retimer that we need to program to pass PHY
compliance.

It would take a bit of time to address all of them. I'll add them on the
TODO.

1 & 3 might be a good exercise if someone is looking for things to do.

Harry


> If there's any specific function, struct, etc. that's of concern let me
> know as well.
> 
> Harry
> 
>> -Daniel
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3] DC pull request cleanup

2017-09-27 Thread Harry Wentland
Patches to make DC use kzalloc/krealloc/kfree directly.

Also updating the TODO list after a closer look at I2C in DC.

Harry Wentland (3):
  drm/amd/display: Use kernel alloc/free
  drm/amd/display: Remove alloc/free macros
  drm/amd/display: DC I2C review

 drivers/gpu/drm/amd/display/TODO   | 26 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/basics/logger.c | 18 ---
 drivers/gpu/drm/amd/display/dc/basics/vector.c | 19 +++
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 17 +++---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 14 ++---
 drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c   |  5 +-
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 42 ---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  | 18 +++
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_sink.c  | 11 ++--
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c|  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc_surface.c   | 15 +++---
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c   |  4 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.c |  4 +-
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.c  | 12 +++--
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c| 10 ++--
 drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c  |  6 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_ipp.c   |  2 +-
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.c   |  2 +-
 .../drm/amd/display/dc/dce100/dce100_resource.c| 43 +++
 .../drm/amd/display/dc/dce110/dce110_compressor.c  |  6 +--
 .../drm/amd/display/dc/dce110/dce110_resource.c| 61 --
 .../drm/amd/display/dc/dce112/dce112_compressor.c  |  6 +--
 .../drm/amd/display/dc/dce112/dce112_resource.c| 43 +++
 .../drm/amd/display/dc/dce120/dce120_resource.c| 43 +++
 .../drm/amd/display/dc/dce80/dce80_compressor.c|  6 +--
 .../gpu/drm/amd/display/dc/dce80/dce80_resource.c  | 47 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_ipp.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_opp.c   |  2 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  | 56 ++--
 drivers/gpu/drm/amd/display/dc/dm_services.h   |  4 --
 drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c|  4 +-
 drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 21 
 drivers/gpu/drm/amd/display/dc/gpio/hw_ddc.c   |  6 +--
 drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/gpio/hw_hpd.c   |  6 +--
 .../amd/display/dc/i2caux/dce100/i2caux_dce100.c   |  4 +-
 .../display/dc/i2caux/dce110/aux_engine_dce110.c   |  6 +--
 .../dc/i2caux/dce110/i2c_hw_engine_dce110.c|  7 +--
 .../dc/i2caux/dce110/i2c_sw_engine_dce110.c|  7 +--
 .../amd/display/dc/i2caux/dce110/i2caux_dce110.c   |  6 +--
 .../amd/display/dc/i2caux/dce112/i2caux_dce112.c   |  4 +-
 .../amd/display/dc/i2caux/dce120/i2caux_dce120.c   |  4 +-
 .../display/dc/i2caux/dce80/i2c_hw_engine_dce80.c  |  6 +--
 .../display/dc/i2caux/dce80/i2c_sw_engine_dce80.c  |  6 +--
 .../drm/amd/display/dc/i2caux/dce80/i2caux_dce80.c |  6 +--
 .../drm/amd/display/dc/i2caux/dcn10/i2caux_dcn10.c |  4 +-
 .../display/dc/i2caux/diagnostics/i2caux_diag.c|  7 +--
 .../gpu/drm/amd/display/dc/i2caux/i2c_sw_engine.c  |  6 +--
 .../amd/display/dc/irq/dce110/irq_service_dce110.c |  5 +-
 .../amd/display/dc/irq/dce120/irq_service_dce120.c |  5 +-
 .../amd/display/dc/irq/dce80/irq_service_dce80.c   |  5 +-
 .../amd/display/dc/irq/dcn10/irq_service_dcn10.c   |  5 +-
 drivers/gpu/drm/amd/display/dc/irq/irq_service.c   |  2 +-
 .../amd/display/dc/virtual/virtual_link_encoder.c  |  2 +-
 .../display/dc/virtual/virtual_stream_encoder.c|  4 +-
 .../drm/amd/display/modules/freesync/freesync.c| 14 ++---
 drivers/gpu/drm/amd/display/replace_alloc.cocci| 25 +
 62 files changed, 399 insertions(+), 348 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/display/replace_alloc.cocci

-- 
2.11.0

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


[PATCH 1/3] drm/amd/display: Use kernel alloc/free

2017-09-27 Thread Harry Wentland
Abstractions are frowned upon.

Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/basics/logger.c | 18 ---
 drivers/gpu/drm/amd/display/dc/basics/vector.c | 19 +++
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 17 +++---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 14 ++---
 drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c   |  5 +-
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 42 ---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  | 18 +++
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_sink.c  | 11 ++--
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c|  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc_surface.c   | 15 +++---
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c   |  4 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.c |  4 +-
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.c  | 12 +++--
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c| 10 ++--
 drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c  |  6 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_ipp.c   |  2 +-
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.c   |  2 +-
 .../drm/amd/display/dc/dce100/dce100_resource.c| 43 +++
 .../drm/amd/display/dc/dce110/dce110_compressor.c  |  6 +--
 .../drm/amd/display/dc/dce110/dce110_resource.c| 61 --
 .../drm/amd/display/dc/dce112/dce112_compressor.c  |  6 +--
 .../drm/amd/display/dc/dce112/dce112_resource.c| 43 +++
 .../drm/amd/display/dc/dce120/dce120_resource.c| 43 +++
 .../drm/amd/display/dc/dce80/dce80_compressor.c|  6 +--
 .../gpu/drm/amd/display/dc/dce80/dce80_resource.c  | 47 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_ipp.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_opp.c   |  2 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  | 56 ++--
 drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c|  4 +-
 drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 21 
 drivers/gpu/drm/amd/display/dc/gpio/hw_ddc.c   |  6 +--
 drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/gpio/hw_hpd.c   |  6 +--
 .../amd/display/dc/i2caux/dce100/i2caux_dce100.c   |  4 +-
 .../display/dc/i2caux/dce110/aux_engine_dce110.c   |  6 +--
 .../dc/i2caux/dce110/i2c_hw_engine_dce110.c|  7 +--
 .../dc/i2caux/dce110/i2c_sw_engine_dce110.c|  7 +--
 .../amd/display/dc/i2caux/dce110/i2caux_dce110.c   |  6 +--
 .../amd/display/dc/i2caux/dce112/i2caux_dce112.c   |  4 +-
 .../amd/display/dc/i2caux/dce120/i2caux_dce120.c   |  4 +-
 .../display/dc/i2caux/dce80/i2c_hw_engine_dce80.c  |  6 +--
 .../display/dc/i2caux/dce80/i2c_sw_engine_dce80.c  |  6 +--
 .../drm/amd/display/dc/i2caux/dce80/i2caux_dce80.c |  6 +--
 .../drm/amd/display/dc/i2caux/dcn10/i2caux_dcn10.c |  4 +-
 .../display/dc/i2caux/diagnostics/i2caux_diag.c|  7 +--
 .../gpu/drm/amd/display/dc/i2caux/i2c_sw_engine.c  |  6 +--
 .../amd/display/dc/irq/dce110/irq_service_dce110.c |  5 +-
 .../amd/display/dc/irq/dce120/irq_service_dce120.c |  5 +-
 .../amd/display/dc/irq/dce80/irq_service_dce80.c   |  5 +-
 .../amd/display/dc/irq/dcn10/irq_service_dcn10.c   |  5 +-
 drivers/gpu/drm/amd/display/dc/irq/irq_service.c   |  2 +-
 .../amd/display/dc/virtual/virtual_link_encoder.c  |  2 +-
 .../display/dc/virtual/virtual_stream_encoder.c|  4 +-
 .../drm/amd/display/modules/freesync/freesync.c| 14 ++---
 drivers/gpu/drm/amd/display/replace_alloc.cocci| 25 +
 60 files changed, 387 insertions(+), 330 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/display/replace_alloc.cocci

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 36635486b937..2afa99c0e95e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2429,7 +2429,7 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
if (WARN_ON(!crtc->state))
return NULL;
 
-   state = dm_alloc(sizeof(*state));
+   state = kzalloc(sizeof(*state), GFP_ATOMIC);
 
__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
 
diff --git a/drivers/gpu/drm/amd/display/dc/basics/logger.c 
b/drivers/gpu/drm/amd/display/dc/basics/logger.c
index 5895dd3903a3..9180050424b9 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/logger.c
+++ b/drivers/gpu/drm/amd/display/dc/basics/logger.c
@@ -70,8 +70,8 @@ static bool construct(struct dc_context *ctx, struct 
dal_logger *logger,
 {
/* malloc buffer and init offsets */
logger->

[PATCH 2/3] drm/amd/display: Remove alloc/free macros

2017-09-27 Thread Harry Wentland
Now that we don't abstract kernel alloc interfaces we don't need
those anymore.

Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
---
 drivers/gpu/drm/amd/display/dc/dm_services.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dm_services.h 
b/drivers/gpu/drm/amd/display/dc/dm_services.h
index 8ab0af6f4c6b..7260e772725d 100644
--- a/drivers/gpu/drm/amd/display/dc/dm_services.h
+++ b/drivers/gpu/drm/amd/display/dc/dm_services.h
@@ -79,10 +79,6 @@
 #include 
 #endif
 
-#define dm_alloc(size) kzalloc(size, GFP_KERNEL)
-#define dm_realloc(ptr, size) krealloc(ptr, size, GFP_KERNEL)
-#define dm_free(ptr) kfree(ptr)
-
 irq_handler_idx dm_register_interrupt(
struct dc_context *ctx,
struct dc_interrupt_params *int_params,
-- 
2.11.0

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


[PATCH 3/3] drm/amd/display: DC I2C review

2017-09-27 Thread Harry Wentland
While reviewing I2C in DC identified a few places. Added a couple to the
TODO list.

1) Connector info read

See get_ext_display_connection_info

On some boards the connector information has to be read through a
special I2C channel. This line is only used for this purpose and only on
driver init.

2) SCDC stuff

This should all be reworked to go through DRM's SCDC code. When this is
done some unnecessary I2C code can be retired as well.

3) Max TMDS clock read

See dal_ddc_service_i2c_query_dp_dual_mode_adaptor

This should happen in DRM as well. I haven't checked if there's
currently functionality in DRM. If not we can propose something.

4) HDMI retimer programming

Some boards have an HDMI retimer that we need to program to pass PHY
compliance.

1 & 3 might be a good exercise if someone is looking for things to do.

Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
---
 drivers/gpu/drm/amd/display/TODO | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/TODO b/drivers/gpu/drm/amd/display/TODO
index eea645b102a1..981352bc95f0 100644
--- a/drivers/gpu/drm/amd/display/TODO
+++ b/drivers/gpu/drm/amd/display/TODO
@@ -62,20 +62,10 @@ TODOs
 ~ Daniel Vetter
 
 
-11. Remove existing i2c implementation from DC
-
-"Similar story for i2c, it uses the kernel's i2c code now, but there's
-still a full i2c implementation hidden beneath that in
-display/dc/i2caux. Kinda not cool, but imo ok if you fix that
-post-merging (perhaps by not including any of this in the linux DC
-code in the upstream kernel, but as an aux module in your internal
-codebase since there you probably need that, same applies to the edid
-parsing DC still does. For both cases I assume that the minimal shim
-you need on linux (bit banging and edid parsing isn't rocket since) is
-a lot less than the glue code to interface with the dc-provided
-abstraction."
-~ Daniel Vetter
-
+11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an
+overy complicated HW programming function for sendind and receiving i2c/aux
+commands. We can greatly simplify that and move it into dc/dceXYZ like other
+HW blocks.
 
 12. drm_modeset_lock in MST should no longer be needed in recent kernels
 * Adopt appropriate locking scheme
@@ -110,3 +100,11 @@ guilty.
 stuff just isn't up to the challenges either. We need to figure out something
 that integrates better with DRM and linux debug printing, while not being
 useless with filtering output. dynamic debug printing might be an option.
+
+20. Move Max TMDS clock read to DRM. See
+dal_ddc_service_i2c_query_dp_dual_mode_adaptor. I haven't checked if there's
+currently functionality in DRM. If not we can propose something.
+
+21. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI
+retimer that we need to program to pass PHY compliance. Currently that's
+bypassing the i2c device and goes directly to HW. This should be changed.
-- 
2.11.0

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


[PATCH] drm/amd/display: Remove DWB

2017-09-28 Thread Harry Wentland
It's not in a good shape and currently completely unused.

Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
---
 drivers/gpu/drm/amd/display/dc/core/dc.c   |   9 -
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile  |   2 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c   | 365 -
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.h   | 277 
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |  57 
 drivers/gpu/drm/amd/display/dc/inc/core_types.h|   3 -
 drivers/gpu/drm/amd/display/dc/inc/hw/dwb.h| 193 ---
 7 files changed, 1 insertion(+), 905 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
 delete mode 100644 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.h
 delete mode 100644 drivers/gpu/drm/amd/display/dc/inc/hw/dwb.h

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index d86d9796e4cc..7fd42fc8bdfa 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1525,15 +1525,6 @@ struct dc_link *dc_get_link_at_index(struct dc *dc, 
uint32_t link_index)
return dc->links[link_index];
 }
 
-struct dwbc *dc_get_dwb_at_pipe(struct dc *dc, uint32_t pipe)
-{
-   if ((pipe >= dwb_pipe0) && (pipe < dwb_pipe_max_num)) {
-   return dc->res_pool->dwbc[(int)pipe];
-   } else {
-   return NULL;
-   }
-}
-
 const struct graphics_object_id dc_get_link_id_at_index(
struct dc *dc, uint32_t link_index)
 {
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
index e92ac2997a1a..2d6d3a371858 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
@@ -3,7 +3,7 @@
 
 DCN10 = dcn10_resource.o dcn10_ipp.o dcn10_hw_sequencer.o \
dcn10_dpp.o dcn10_opp.o dcn10_timing_generator.o \
-   dcn10_mem_input.o dcn10_mpc.o dcn10_dwb.o \
+   dcn10_mem_input.o dcn10_mpc.o \
dcn10_dpp_dscl.o dcn10_dpp_cm.o dcn10_dpp_cm_helper.o
 
 AMD_DAL_DCN10 = $(addprefix $(AMDDALPATH)/dc/dcn10/,$(DCN10))
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
deleted file mode 100644
index 4ec5554f0f5b..
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
+++ /dev/null
@@ -1,365 +0,0 @@
-/*
- * Copyright 2012-17 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: AMD
- *
- */
-
-#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
-
-#include "reg_helper.h"
-#include "resource.h"
-#include "dwb.h"
-#include "dcn10_dwb.h"
-
-
-#define REG(reg)\
-   dwbc10->dwbc_regs->reg
-
-#define CTX \
-   dwbc10->base.ctx
-
-#undef FN
-#define FN(reg_name, field_name) \
-   dwbc10->dwbc_shift->field_name, dwbc10->dwbc_mask->field_name
-
-#define TO_DCN10_DWBC(dwbc_base) \
-   container_of(dwbc_base, struct dcn10_dwbc, base)
-
-static bool get_caps(struct dwbc *dwbc, struct dwb_caps *caps)
-{
-   if (caps) {
-   caps->adapter_id = 0;   /* we only support 1 adapter currently 
*/
-   caps->hw_version = DCN_VERSION_1_0;
-   caps->num_pipes = 2;
-   memset(>reserved, 0, sizeof(caps->reserved));
-   memset(>reserved2, 0, sizeof(caps->reserved2));
-   caps->sw_version = dwb_ver_1_0;
-   caps->caps.support_dwb = true;
-   caps->caps.support_ogam = false;
-   caps->caps.support_wbscl = true;
-   caps->caps.support_ocsc = false;
-   return true;
-   } else {
-   return false;
-   }
-}
-
-static bool enable(struct dwbc *dwbc)
-

[PATCH v2] drm/amd/display: DC I2C review

2017-09-28 Thread Harry Wentland
While reviewing I2C in DC identified a few places. Added a couple to the
TODO list.

1) Connector info read

See get_ext_display_connection_info

On some boards the connector information has to be read through a
special I2C channel. This line is only used for this purpose and only on
driver init.

2) SCDC stuff

This should all be reworked to go through DRM's SCDC code. When this is
done some unnecessary I2C code can be retired as well.

3) Max TMDS clock read

See dal_ddc_service_i2c_query_dp_dual_mode_adaptor

This should happen in DRM as well. I haven't checked if there's
currently functionality in DRM. If not we can propose something.

4) HDMI retimer programming

Some boards have an HDMI retimer that we need to program to pass PHY
compliance.

1 & 3 might be a good exercise if someone is looking for things to do.

v2: Merge dp_dual_mode_adaptor TODO

Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
 drivers/gpu/drm/amd/display/TODO | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/TODO b/drivers/gpu/drm/amd/display/TODO
index eea645b102a1..46464678f2b3 100644
--- a/drivers/gpu/drm/amd/display/TODO
+++ b/drivers/gpu/drm/amd/display/TODO
@@ -62,20 +62,10 @@ TODOs
 ~ Daniel Vetter
 
 
-11. Remove existing i2c implementation from DC
-
-"Similar story for i2c, it uses the kernel's i2c code now, but there's
-still a full i2c implementation hidden beneath that in
-display/dc/i2caux. Kinda not cool, but imo ok if you fix that
-post-merging (perhaps by not including any of this in the linux DC
-code in the upstream kernel, but as an aux module in your internal
-codebase since there you probably need that, same applies to the edid
-parsing DC still does. For both cases I assume that the minimal shim
-you need on linux (bit banging and edid parsing isn't rocket since) is
-a lot less than the glue code to interface with the dc-provided
-abstraction."
-~ Daniel Vetter
-
+11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an
+overy complicated HW programming function for sendind and receiving i2c/aux
+commands. We can greatly simplify that and move it into dc/dceXYZ like other
+HW blocks.
 
 12. drm_modeset_lock in MST should no longer be needed in recent kernels
 * Adopt appropriate locking scheme
@@ -89,7 +79,8 @@ moving all your driver state printing into the various 
atomic_print_state
 callbacks. There's also plans to expose this stuff in a standard way across all
 drivers, to make debugging userspace compositors easier across different hw.
 
-15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c.
+15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See
+dal_ddc_service_i2c_query_dp_dual_mode_adaptor.
 
 16. Move to core SCDC helpers (I think those are new since initial DC review).
 
@@ -110,3 +101,7 @@ guilty.
 stuff just isn't up to the challenges either. We need to figure out something
 that integrates better with DRM and linux debug printing, while not being
 useless with filtering output. dynamic debug printing might be an option.
+
+20. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI
+retimer that we need to program to pass PHY compliance. Currently that's
+bypassing the i2c device and goes directly to HW. This should be changed.
-- 
2.11.0

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


[PATCH v2] drm/amd/display: Use kernel alloc/free

2017-09-27 Thread Harry Wentland
Abstractions are frowned upon.

cocci script:
virtual context
virtual patch
virtual org
virtual report

@@
expression ptr;
@@

- dm_alloc(ptr)
+ kzalloc(ptr, GFP_KERNEL)

@@
expression ptr, size;
@@

- dm_realloc(ptr, size)
+ krealloc(ptr, size, GFP_KERNEL)

@@
expression ptr;
@@

- dm_free(ptr)
+ kfree(ptr)

v2: use GFP_KERNEL, not GFP_ATOMIC. add cocci script

Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/basics/logger.c | 18 ---
 drivers/gpu/drm/amd/display/dc/basics/vector.c | 19 +++
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 17 +++---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 14 ++---
 drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c   |  5 +-
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 42 ---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  | 18 +++
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_sink.c  | 11 ++--
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c|  6 +--
 drivers/gpu/drm/amd/display/dc/core/dc_surface.c   | 15 +++---
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c   |  4 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.c |  4 +-
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.c  | 12 +++--
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c| 10 ++--
 drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c  |  6 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_ipp.c   |  2 +-
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.c   |  2 +-
 .../drm/amd/display/dc/dce100/dce100_resource.c| 43 +++
 .../drm/amd/display/dc/dce110/dce110_compressor.c  |  6 +--
 .../drm/amd/display/dc/dce110/dce110_resource.c| 61 --
 .../drm/amd/display/dc/dce112/dce112_compressor.c  |  6 +--
 .../drm/amd/display/dc/dce112/dce112_resource.c| 43 +++
 .../drm/amd/display/dc/dce120/dce120_resource.c| 43 +++
 .../drm/amd/display/dc/dce80/dce80_compressor.c|  6 +--
 .../gpu/drm/amd/display/dc/dce80/dce80_resource.c  | 47 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_ipp.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_opp.c   |  2 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  | 56 ++--
 drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c|  4 +-
 drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 21 
 drivers/gpu/drm/amd/display/dc/gpio/hw_ddc.c   |  6 +--
 drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/gpio/hw_hpd.c   |  6 +--
 .../amd/display/dc/i2caux/dce100/i2caux_dce100.c   |  4 +-
 .../display/dc/i2caux/dce110/aux_engine_dce110.c   |  6 +--
 .../dc/i2caux/dce110/i2c_hw_engine_dce110.c|  7 +--
 .../dc/i2caux/dce110/i2c_sw_engine_dce110.c|  7 +--
 .../amd/display/dc/i2caux/dce110/i2caux_dce110.c   |  6 +--
 .../amd/display/dc/i2caux/dce112/i2caux_dce112.c   |  4 +-
 .../amd/display/dc/i2caux/dce120/i2caux_dce120.c   |  4 +-
 .../display/dc/i2caux/dce80/i2c_hw_engine_dce80.c  |  6 +--
 .../display/dc/i2caux/dce80/i2c_sw_engine_dce80.c  |  6 +--
 .../drm/amd/display/dc/i2caux/dce80/i2caux_dce80.c |  6 +--
 .../drm/amd/display/dc/i2caux/dcn10/i2caux_dcn10.c |  4 +-
 .../display/dc/i2caux/diagnostics/i2caux_diag.c|  7 +--
 .../gpu/drm/amd/display/dc/i2caux/i2c_sw_engine.c  |  6 +--
 .../amd/display/dc/irq/dce110/irq_service_dce110.c |  5 +-
 .../amd/display/dc/irq/dce120/irq_service_dce120.c |  5 +-
 .../amd/display/dc/irq/dce80/irq_service_dce80.c   |  5 +-
 .../amd/display/dc/irq/dcn10/irq_service_dcn10.c   |  5 +-
 drivers/gpu/drm/amd/display/dc/irq/irq_service.c   |  2 +-
 .../amd/display/dc/virtual/virtual_link_encoder.c  |  2 +-
 .../display/dc/virtual/virtual_stream_encoder.c|  4 +-
 .../drm/amd/display/modules/freesync/freesync.c| 14 ++---
 59 files changed, 362 insertions(+), 330 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 36635486b937..dba54c0a7b5f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2429,7 +2429,7 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
if (WARN_ON(!crtc->state))
return NULL;
 
-   state = dm_alloc(sizeof(*state));
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
 
__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
 
diff --git a/drivers/gpu/drm/amd/display/dc/basics/logger.c 
b/drivers/gpu/drm/amd/display/dc/basics/logger.c
index 5895dd3903a3..afb6d2d80e0c 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/logger.c
+++ b/drivers/gpu/drm/amd/displ

Re: [PATCH] drm/amd/powerplay/hwmgr: Remove null check before kfree

2017-08-29 Thread Harry Wentland
On 2017-08-29 09:12 AM, Himanshu Jha wrote:
> kfree on NULL pointer is a no-op and therefore checking is redundant.
> 
> Signed-off-by: Himanshu Jha <himanshujha199...@gmail.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c |  6 +-
>  .../gpu/drm/amd/powerplay/hwmgr/processpptables.c  | 96 
> --
>  drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 52 
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 12 +--
>  4 files changed, 56 insertions(+), 110 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> index bc839ff..9f2c037 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> @@ -1225,10 +1225,8 @@ static int cz_hwmgr_backend_fini(struct pp_hwmgr 
> *hwmgr)
>   phm_destroy_table(hwmgr, &(hwmgr->power_down_asic));
>   phm_destroy_table(hwmgr, &(hwmgr->setup_asic));
>  
> - if (NULL != hwmgr->dyn_state.vddc_dep_on_dal_pwrl) {
> - kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
> - hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
> + hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
>  
>   kfree(hwmgr->backend);
>   hwmgr->backend = NULL;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> index 2716721..a6dbc55 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> @@ -1615,85 +1615,53 @@ static int pp_tables_uninitialize(struct pp_hwmgr 
> *hwmgr)
>   if (hwmgr->chip_id == CHIP_RAVEN)
>   return 0;
>  
> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) {
> - kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
> - hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
> + hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
>  
> - if (NULL != hwmgr->dyn_state.vddci_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
> - hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
> + hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
>  
> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
> - hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
> + hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
>  
> - if (NULL != hwmgr->dyn_state.mvdd_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
> - hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
> + hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
>  
> - if (NULL != hwmgr->dyn_state.valid_mclk_values) {
> - kfree(hwmgr->dyn_state.valid_mclk_values);
> - hwmgr->dyn_state.valid_mclk_values = NULL;
> - }
> + kfree(hwmgr->dyn_state.valid_mclk_values);
> + hwmgr->dyn_state.valid_mclk_values = NULL;
>  
> - if (NULL != hwmgr->dyn_state.valid_sclk_values) {
> - kfree(hwmgr->dyn_state.valid_sclk_values);
> - hwmgr->dyn_state.valid_sclk_values = NULL;
> - }
> + kfree(hwmgr->dyn_state.valid_sclk_values);
> + hwmgr->dyn_state.valid_sclk_values = NULL;
>  
> - if (NULL != hwmgr->dyn_state.cac_leakage_table) {
> - kfree(hwmgr->dyn_state.cac_leakage_table);
> - hwmgr->dyn_state.cac_leakage_table = NULL;
> - }
> + kfree(hwmgr->dyn_state.cac_leakage_table);
> + hwmgr->dyn_state.cac_leakage_table = NULL;
>  
> - if (NULL != hwmgr->dyn_state.vddc_phase_shed_limits_table) {
> - kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
> - hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
> + hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
>  
> - if (NULL != hwmgr->dyn_state.vce_clock_voltage_depend

Re: [PATCH] amdgpu/dc: Use DRM new-style object iterators.

2017-10-11 Thread Harry Wentland
On 2017-10-11 03:46 PM, Maarten Lankhorst wrote:
> Op 11-10-17 om 20:55 schreef Leo:
>>
>>
>> On 2017-10-11 10:30 AM, Maarten Lankhorst wrote:
>>> Op 11-10-17 om 16:24 schreef sunpeng...@amd.com:
 From: "Leo (Sunpeng) Li" 

 Use the correct for_each_new/old_* iterators instead of for_each_*

 List of affected functions:

 amdgpu_dm_find_first_crtc_matching_connector: use for_each_new
  - Old from_state_var flag was always choosing the new state

 amdgpu_dm_display_resume: use for_each_new
  - drm_atomic_helper_duplicate_state is called during suspend to
cache the state
  - It sets 'state' within the state triplet to 'new_state'

 amdgpu_dm_commit_planes: use for_each_old
  - Called after the state was swapped (via atomic commit tail)

 amdgpu_dm_atomic_commit: use for_each_new
  - Called before the state is swapped

 amdgpu_dm_atomic_commit_tail: use for_each_old
  - Called after the state was swapped

 dm_update_crtcs_state: use for_each_new
  - Called before the state is swapped (via atomic check)

 amdgpu_dm_atomic_check: use for_each_new
  - Called before the state is swapped

 Also fix some typos.

 crct -> crtc
 undersacn -> underscan

 Signed-off-by: Leo (Sunpeng) Li 
 ---

 Hi Dave,

 This patch goes on top of your fixup for new api's patch. Please feel
 free to squash them.

 Thanks,
 Leo

   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 
 +--
   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  5 ++-
   2 files changed, 16 insertions(+), 27 deletions(-)

 diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
 b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
 index 9bfe1f9..9394558 100644
 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
 +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
 @@ -568,25 +568,17 @@ static int dm_suspend(void *handle)
   return ret;
   }
   -struct amdgpu_dm_connector 
 *amdgpu_dm_find_first_crct_matching_connector(
 +struct amdgpu_dm_connector *amdgpu_dm_find_first_crtc_matching_connector(
   struct drm_atomic_state *state,
 -struct drm_crtc *crtc,
 -bool from_state_var)
 +struct drm_crtc *crtc)
   {
   uint32_t i;
   struct drm_connector_state *conn_state;
   struct drm_connector *connector;
   struct drm_crtc *crtc_from_state;
   -for_each_new_connector_in_state(
 -state,
 -connector,
 -conn_state,
 -i) {
 -crtc_from_state =
 -from_state_var ?
 -conn_state->crtc :
 -connector->state->crtc;
 +for_each_new_connector_in_state(state, connector, conn_state, i) {
 +crtc_from_state = conn_state->crtc;
>>> Please assign crtc_from_state here with drm_atomic_get_(new/old)_crtc_state.
>>
>> We're trying to fetch a drm_crtc from a drm_connector_state, I don't think 
>> the state getters are applicable here.
>>
>> Also, the function should really be named 
>> 'find_first_connector_matching_crtc'. I'll fix that.
> Oh I misunderstood. But in general derefencing $obj->state should be frowned 
> upon. If you ever want to support atomic flip depth > 1,
> all those references should be gone from your driver, and replaced with 
> get_old/new_state..

If I understand correctly this is the forward-looking way of how we get the
state now? I still see plenty of $obj->state in i915 and other drivers.

Any objections to doing this as a follow-up patch?

What's atomic flip depth > 1?

Harry

>>>
>>>
   if (crtc_from_state == crtc)
   return to_amdgpu_dm_connector(connector);
 @@ -3890,7 +3882,7 @@ static void amdgpu_dm_commit_planes(struct 
 drm_atomic_state *state,
   unsigned long flags;
 /* update planes when needed */
 -for_each_new_plane_in_state(state, plane, old_plane_state, i) {
 +for_each_old_plane_in_state(state, plane, old_plane_state, i) {
   struct drm_plane_state *plane_state = plane->state;
   struct drm_crtc *crtc = plane_state->crtc;
   struct drm_framebuffer *fb = plane_state->fb;
>>> Use for_each_oldnew_*_in_state
 @@ -4024,7 +4016,7 @@ void amdgpu_dm_atomic_commit_tail(
   dm_state = to_dm_atomic_state(state);
 /* update changed items */
 -for_each_new_crtc_in_state(state, crtc, old_crtc_state, i) {
 +for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
   struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
   struct drm_crtc_state *new_state = crtc->state;
>>> Same.
>>
>> Good points, it seems like there's 

Re: [PATCH] drm/amd: DC pull request review

2017-09-27 Thread Harry Wentland
On 2017-09-27 06:15 AM, Daniel Vetter wrote:
> Ok, here's one more attempt at scrolling through 130k diff.
> 
> Overall verdict from me is that DC is big project, and like any big
> project it's never done. So at least for me the goal isn't to make
> things perfect, becaue if that's the hoop to jump through we wouldn't
> have any gpu drivers at all. More important is whether merging a new
> driver base will benefit the overall subsystem, and here this
> primarily means whether the DC team understands how upstream works and
> is designed, and whether the code is largely aligned with upstream
> (especially the atomic modeset) architecture.
> 
> Looking back over the last two years I think that's the case now, so
> 
> Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> 
> for merging this pull.
> 
> While scrolling through the pull I spotted a bunch more things that
> should be refactored, but most of these will be a real pain with DC
> is out of tree, and much easier in tree since in many of these areas
> the in-tree helpers aren't up to snuff yet for what DC needs. That
> kind of work is best done when there's one tree with everything
> integrated.
> 
> That's also why I think we should merge DC into drm-next directly, so
> we can get started on the integration polish right away. That has a
> bit higher risk of Linus having a spazz, so here's my recommendation
> for merging:
> 
> - There's a few additions to drm_dp_helper.h sprinkled all over the
>   pull. I think those should be put into a patch of it's own, and
>   merged first. No need to rebase DC, git merge will dtrt and not end
>   up with duplicates.
> 
> - dm_alloc/realloc/free is something Dave Airlie noticed, and I agree
>   it's an easy red flag that might upset Linus. cocci can fix this
>   easy, so no real problem I think to patch up in one big patch (I
>   thought we've had a "remove malloc wrappers" todo item in the very
>   first review, apparently there was more than one such wrapper).
> 
> - The history is huge, but AMD folks want to keep it if possible, and
>   I see the value in that. Would be good to get an ack from Linus for
>   that (but shouldn't be an issue, not the first time we've merged the
>   full history of out-of-tree work).
> 
> Short term TODO items are still tracked, might be a good idea
> to integrate those the overall drm todo in our gpu documentation, for
> more visibility.
> 
> So in a way this is kinda like staging, except not with the horribly
> broken process of having an entirely separate tree for staging drivers
> which just makes refactoring needlessly painful (which defeats the
> point of staging really). So staging-within-the-subsystem. We've had
> that before, with early nouveau.
> 
> And yes some of the files are utterly horrible to read and not
> anything close to kernel coding style standards. But that's the point,
> they're essentially gospel from hw engineers that happens to be
> parseable by gcc.
> 
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

Thanks for the feedback, ack and help along the way.

This patch is
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

> ---
>  drivers/gpu/drm/amd/display/TODO | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/TODO 
> b/drivers/gpu/drm/amd/display/TODO
> index 2737873db12d..eea645b102a1 100644
> --- a/drivers/gpu/drm/amd/display/TODO
> +++ b/drivers/gpu/drm/amd/display/TODO
> @@ -79,3 +79,34 @@ TODOs
>  
>  12. drm_modeset_lock in MST should no longer be needed in recent kernels
>  * Adopt appropriate locking scheme
> +
> +13. get_modes and best_encoder callbacks look a bit funny. Can probably rip 
> out
> +a few indirections, and consider removing entirely and using the
> +drm_atomic_helper_best_encoder default behaviour.
> +
> +14. core/dc_debug.c, consider switching to the atomic state debug helpers and
> +moving all your driver state printing into the various atomic_print_state
> +callbacks. There's also plans to expose this stuff in a standard way across 
> all
> +drivers, to make debugging userspace compositors easier across different hw.
> +
> +15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c.
> +
> +16. Move to core SCDC helpers (I think those are new since initial DC 
> review).
> +
> +17. There's still a pretty massive layer cake around dp aux and DPCD 
> handling,
> +with like 3 levels of abstraction and using your own structures instead of 
> the
> +stuff in drm_dp_helper.h. drm_dp_helper.h isn't really great and already has 
> 2
> +incompatible styles, just means more reasons not to add a third (or well 
> third
> +one gets

Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

2017-10-18 Thread Harry Wentland
On 2017-10-18 04:10 AM, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote:
>> On 17.10.2017 19:16, Daniel Vetter wrote:
>>> On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer  wrote:
 On 17/10/17 05:04 PM, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
>> On 17/10/17 02:22 PM, Daniel Vetter wrote:
>>> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
 On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
>>>
> Common sense suggests that there need to be two side to FreeSync / 
> VESA
> Adaptive Sync support:
>
> 1. Query the display capabilities. This means querying minimum / 
> maximum
> refresh duration, plus possibly a query for when the earliest/latest
> timing of the *next* refresh.
>
> 2. Signal desired present time. This means passing a target timer 
> value
> instead of a target vblank count, e.g. something like this for the KMS
> interface:
>
>int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t 
> fb_id,
>uint32_t flags, void *user_data,
>uint64_t target);
>
>+ a flag to indicate whether target is the vblank count or the
> CLOCK_MONOTONIC (?) time in ns.

 drmModePageFlip(Target) is part of the pre-atomic KMS API, but 
 adapative
 sync should probably only be supported via the atomic API, presumably
 via output properties.
>>>
>>> +1
>>>
>>> At least now that DC is on track to land properly, and you want to do 
>>> this
>>> for DC-only anyway there's no reason to pimp the legacy interfaces
>>> further. And atomic is soo much easier to extend.
>>>
>>> The big question imo is where we need to put the flag on the kms side,
>>> since freesync is not just about presenting earlier, but also about
>>> presenting later. But for backwards compat we can't stretch the refresh
>>> rate by default for everyone, or clients that rely on high precision
>>> timestamps and regular refresh will get a bad surprise.
>>
>> The idea described above is that adaptive sync would be used for flips
>> with a target timestamp. Apps which don't want to use adaptive sync
>> wouldn't set a target timestamp.
>>
>>
>>> I think a boolean enable_freesync property is probably what we want, 
>>> which
>>> enables freesync for as long as it's set.
>>
>> The question then becomes under what circumstances the property is (not)
>> set. Not sure offhand this will actually solve any problem, or just push
>> it somewhere else.
>
> I thought that's what the driconf switch is for, with a policy of "please
> schedule asap" instead of a specific timestamp.

 The driconf switch is just for the user's intention to use adaptive sync
 when possible. A property as you suggest cannot be set by the client
 directly, because it can't know when adaptive sync can actually be used
 (only when its window is fullscreen and using page flipping). So the
 property would have to be set by the X server/driver / Wayland
 compositor / ... instead. The question is whether such a property is
 actually needed, or whether the kernel could just enable adaptive sync
 when there's a flip with a target timestamp, and disable it when there's
 a flip without a target timestamp, or something like that.
>>>
>>> If your adaptive sync also supports extending the vblank beyond the
>>> nominal limit, then you can't do that with a per-flip flag. Because
>>> absent of a userspace requesting adaptive sync you must flip at the
>>> nominal vrefresh rate. So if your userspace is a tad bit late with the
>>> frame and would like to extend the frame to avoid missing a frame
>>> entirely it'll be too late by the time the vblank actually gets
>>> submitted. That's a bit a variation of what Ville brought up about
>>> what we're going to do when the timestamp was missed by the time all
>>> the depending fences signalled.
>>
>> These are very good points. It does sound like we'd need both an
>> "AdaptiveSync" boolean property and an (optional) "DesiredPresentTime"
>> property.
>>
>> The DesiredPresentTime property applies only to a single commit and could
>> perhaps be left out in a first version. The AdaptiveSync property is
>> persistent. When enabled, it means:
>>
>> - handle page flip requests as soon as possible
>> - while no page flip is requested, delay vblank as long as possible
>>
>> How does that sound?
> 
> Yeah, that's what I had in mind. No idea it'll work out on real hw/full
> stack.
> 

A bit late to the thread but whatever has been suggested sounds quite good.

Our experience generally has been that we don't want 

Re: [PATCH] drm/amd/display: Fix potential NULL pointer dereferences in amdgpu_dm_atomic_commit_tail

2017-11-27 Thread Harry Wentland
On 2017-11-27 09:57 AM, Gustavo A. R. Silva wrote:
> dm_new_crtc_state->stream and disconnected_acrtc are being dereferenced
> before they are null checked, hence there is a potential null pointer
> dereference.
> 
> Fix this by null checking such pointers before they are dereferenced.
> 
> Addresses-Coverity-ID: 1423745 ("Dereference before null check")
> Addresses-Coverity-ID: 1423833 ("Dereference before null check")
> Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm")
> Fixes: 54d765752467 ("drm/amd/display: Unify amdgpu_dm state variable 
> namings.")
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 889ed24..3bdd137 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4190,6 +4190,9 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
>  
> + if (!dm_new_crtc_state->stream)
> + continue;
> +
>   
> update_stream_scaling_settings(_new_con_state->base.crtc->mode,
>   dm_new_con_state, (struct dc_stream_state 
> *)dm_new_crtc_state->stream);
>  
> @@ -4197,9 +4200,6 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   WARN_ON(!status);
>   WARN_ON(!status->plane_count);
>  
> - if (!dm_new_crtc_state->stream)
> - continue;
> -
>   /*TODO How it works with MPO ?*/
>   if (!dc_commit_planes_to_stream(
>   dm->dc,
> @@ -4332,9 +4332,11 @@ void dm_restore_drm_connector_state(struct drm_device 
> *dev,
>   return;
>  
>   disconnected_acrtc = to_amdgpu_crtc(connector->encoder->crtc);
> - acrtc_state = to_dm_crtc_state(disconnected_acrtc->base.state);
> + if (!disconnected_acrtc)
> + return;
>  
> - if (!disconnected_acrtc || !acrtc_state->stream)
> + acrtc_state = to_dm_crtc_state(disconnected_acrtc->base.state);
> + if (!acrtc_state->stream)
>   return;

This part is already in 
https://lists.freedesktop.org/archives/amd-gfx/2017-November/016389.html on its 
way to be merged.

The rest of the patch is
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

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


Re: [PATCH] drm/amd/display: fix memory leaks on error exit return

2017-11-22 Thread Harry Wentland
On 2017-11-22 11:47 AM, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> Currently in the case where some of the allocations fail for dce110_tgv,
> dce110_xfmv, dce110_miv or dce110_oppv then the exit return path ends
> up leaking allocated objects. Fix this by kfree'ing them before returning.
> Also re-work the comparison of the null pointers to use the !ptr idiom.
> 
> Detected by CoverityScan, CID#1460246, 1460325, 1460324, 1460392
> ("Resource Leak")
> 
> Fixes: c4562236b3bc ("drm/amd/dc: Add dc display driver (v2)")
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>

Thanks. I got the same patch but was too slow to post.

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> index db96d2b47ff1..61adb8174ce0 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> @@ -1037,11 +1037,13 @@ static bool underlay_create(struct dc_context *ctx, 
> struct resource_pool *pool)
>   struct dce110_opp *dce110_oppv = kzalloc(sizeof(*dce110_oppv),
>GFP_KERNEL);
>  
> - if ((dce110_tgv == NULL) ||
> - (dce110_xfmv == NULL) ||
> - (dce110_miv == NULL) ||
> - (dce110_oppv == NULL))
> - return false;
> + if (!dce110_tgv || !dce110_xfmv || !dce110_miv || !dce110_oppv) {
> + kfree(dce110_tgv);
> + kfree(dce110_xfmv);
> + kfree(dce110_miv);
> + kfree(dce110_oppv);
> + return false;
> + }
>  
>   dce110_opp_v_construct(dce110_oppv, ctx);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: amd: dc: don't use FP math when Kcov is enabled

2017-12-04 Thread Harry Wentland
On 2017-12-04 08:08 AM, Arnd Bergmann wrote:
> Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
> and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
> that do a comparison of floating-point variables:
> 
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `dcn_bw_calc_rq_dlg_ttu':
> dcn_calcs.c:(.text+0x263): undefined reference to `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `hack_force_pipe_split':
> dcn_calcs.c:(.text+0x155b): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `dcn_find_dcfclk_suits_all':
> dcn_calcs.c:(.text+0x190e): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `dcn_validate_bandwidth':
> dcn_calcs.c:(.text+0xe121): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_mod':
> dcn_calc_math.c:(.text+0x22): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_min2':
> dcn_calc_math.c:(.text+0xb2): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_ceil2':
> dcn_calc_math.c:(.text+0x2a0): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_max3':
> dcn_calc_math.c:(.text+0x325): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_max5':
> dcn_calc_math.c:(.text+0x3c3): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_log':
> dcn_calc_math.c:(.text+0x54e): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> dcn_calc_math.c:(.text+0x57c): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `scaler_settings_calculation':
> dcn_calc_auto.c:(.text+0x5c5): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0x137c): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0x9233): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0xb70f): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0x121fd): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `display_pipe_configuration':
> dcn_calc_auto.c:(.text+0x15a2f): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x17c2d): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x19362): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x25575): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x27f33): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
> `get_refcyc_per_delivery':
> display_rq_dlg_calc.c:(.text+0xb5): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
> `calculate_ttu_cursor.isra.1':
> display_rq_dlg_calc.c:(.text+0x9f6): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
> `dml_rq_dlg_get_dlg_params':
> display_rq_dlg_calc.c:(.text+0x82cc): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.o: In function 
> 

Re: [PATCH] drm/amd/display: remove redundant null check of array 'data'

2017-12-15 Thread Harry Wentland
On 2017-12-15 05:53 AM, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> The null check on aconnector->base.edid_blob_ptr->data is redundant
> since data is an array and can never be null.  Remove it.
> 
> Detected by CoverityScan, CID#1460369 ("Array compared against 0")
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ccbf10e3bbb6..c388778dbba3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2725,8 +2725,7 @@ static void create_eml_sink(struct amdgpu_dm_connector 
> *aconnector)
>   };
>   struct edid *edid;
>  
> - if (!aconnector->base.edid_blob_ptr ||
> - !aconnector->base.edid_blob_ptr->data) {
> + if (!aconnector->base.edid_blob_ptr) {
>   DRM_ERROR("No EDID firmware found on connector: %s ,forcing to 
> OFF!\n",
>   aconnector->base.name);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/4] drm: amd: Fix line continuation formats

2017-11-16 Thread Harry Wentland


On 2017-11-16 10:27 AM, Joe Perches wrote:
> Line continuations with excess spacing causes unexpected output.
> 
> Miscellanea:
> 
> o Added missing '\n' to a few of the coalesced pr_ formats
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 11 -
>  .../amd/powerplay/hwmgr/process_pptables_v1_0.c|  6 ++---
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 27 
> --
>  drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c   |  6 ++---
>  .../gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c  |  9 +++-
>  .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c   |  6 ++---
>  6 files changed, 22 insertions(+), 43 deletions(-)
> 
> 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 ced42484dcfc..6743786afcce 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
> @@ -220,8 +220,7 @@ static void dpcd_set_lt_pattern_and_lane_settings(
>   size_in_bytes);
>  
>   dm_logger_write(link->ctx->logger, LOG_HW_LINK_TRAINING,
> - "%s:\n %x VS set = %x  PE set = %x \
> - max VS Reached = %x  max PE Reached = %x\n",
> + "%s:\n %x VS set = %x  PE set = %x max VS Reached = %x  max PE 
> Reached = %x\n",
>   __func__,
>   DP_TRAINING_LANE0_SET,
>   dpcd_lane[0].bits.VOLTAGE_SWING_SET,
> @@ -558,8 +557,7 @@ static void dpcd_set_lane_settings(
>   */
>  
>   dm_logger_write(link->ctx->logger, LOG_HW_LINK_TRAINING,
> - "%s\n %x VS set = %x  PE set = %x \
> - max VS Reached = %x  max PE Reached = %x\n",
> + "%s\n %x VS set = %x  PE set = %x max VS Reached = %x  max PE 
> Reached = %x\n",
>   __func__,
>   DP_TRAINING_LANE0_SET,
>   dpcd_lane[0].bits.VOLTAGE_SWING_SET,
> @@ -872,9 +870,8 @@ static bool perform_clock_recovery_sequence(
>   if (retry_count >= LINK_TRAINING_MAX_CR_RETRY) {
>   ASSERT(0);
>   dm_logger_write(link->ctx->logger, LOG_ERROR,
> - "%s: Link Training Error, could not \
> -  get CR after %d tries. \
> - Possibly voltage swing issue", __func__,
> + "%s: Link Training Error, could not get CR after %d 
> tries. Possibly voltage swing issue",

Would probably be good to add a '\n' here as well but that's not the main 
intention of this patch.

Either way patch is
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> + __func__,
>   LINK_TRAINING_MAX_CR_RETRY);
>  
>   }
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> index d1af1483c69b..813f827e4270 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> @@ -523,8 +523,7 @@ static int get_pcie_table(
>   if ((uint32_t)atom_pcie_table->ucNumEntries <= pcie_count)
>   pcie_count = (uint32_t)atom_pcie_table->ucNumEntries;
>   else
> - pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! \
> - Disregarding the excess entries... \n");
> + pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! Disregarding the excess entries...\n");
>  
>   pcie_table->count = pcie_count;
>   for (i = 0; i < pcie_count; i++) {
> @@ -563,8 +562,7 @@ static int get_pcie_table(
>   if ((uint32_t)atom_pcie_table->ucNumEntries <= pcie_count)
>   pcie_count = (uint32_t)atom_pcie_table->ucNumEntries;
>   else
> - pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! \
> - Disregarding the excess entries... \n");
> + pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! Disregarding the excess entries...\n");
>  
>   pcie_table->count = pcie_count;
>  
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index 4f79c21f27ed..9599fe0ba779 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/v

Re: [PATCH] drm/amd/display/dc/dce110/dce110_mem_input_v: use swap macro in program_size_and_rotation

2017-11-17 Thread Harry Wentland
On 2017-11-10 05:31 PM, Gustavo A. R. Silva wrote:
> Make use of the swap macro instead of _manually_ swapping values
> and remove unnecessary variable swap.
> 
> This makes the code easier to read and maintain.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  .../drm/amd/display/dc/dce110/dce110_mem_input_v.c | 28 
> +++---
>  1 file changed, 8 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c
> index a06c602..7bab8c6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c
> @@ -237,26 +237,14 @@ static void program_size_and_rotation(
>   if (rotation == ROTATION_ANGLE_90 ||
>   rotation == ROTATION_ANGLE_270) {
>  
> - uint32_t swap;
> - swap = local_size.video.luma_size.x;
> - local_size.video.luma_size.x =
> - local_size.video.luma_size.y;
> - local_size.video.luma_size.y  = swap;
> -
> - swap = local_size.video.luma_size.width;
> - local_size.video.luma_size.width =
> - local_size.video.luma_size.height;
> - local_size.video.luma_size.height = swap;
> -
> - swap = local_size.video.chroma_size.x;
> - local_size.video.chroma_size.x =
> - local_size.video.chroma_size.y;
> - local_size.video.chroma_size.y  = swap;
> -
> - swap = local_size.video.chroma_size.width;
> - local_size.video.chroma_size.width =
> - local_size.video.chroma_size.height;
> - local_size.video.chroma_size.height = swap;
> + swap(local_size.video.luma_size.x,
> +  local_size.video.luma_size.y);
> + swap(local_size.video.luma_size.width,
> +  local_size.video.luma_size.height);
> + swap(local_size.video.chroma_size.x,
> +  local_size.video.chroma_size.y);
> + swap(local_size.video.chroma_size.width,
> +  local_size.video.chroma_size.height);
>   }
>  
>   value = 0;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amd/display/dc/core/dc_resource: use swap macro in rect_swap_helper

2017-11-17 Thread Harry Wentland
On 2017-11-10 05:38 PM, Gustavo A. R. Silva wrote:
> Make use of the swap macro instead of _manually_ swapping values
> and remove unnecessary variable temp.
> 
> This makes the code easier to read and maintain.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> index d1cdf9f..ee216f2 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> @@ -426,15 +426,8 @@ static enum pixel_format 
> convert_pixel_format_to_dalsurface(
>  
>  static void rect_swap_helper(struct rect *rect)
>  {
> - uint32_t temp = 0;
> -
> - temp = rect->height;
> - rect->height = rect->width;
> - rect->width = temp;
> -
> - temp = rect->x;
> - rect->x = rect->y;
> - rect->y = temp;
> + swap(rect->height, rect->width);
> + swap(rect->x, rect->y);
>  }
>  
>  static void calculate_viewport(struct pipe_ctx *pipe_ctx)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amdgpu/virt: don't dereference undefined 'module' struct

2017-11-02 Thread Harry Wentland
On 2017-11-02 07:25 AM, Arnd Bergmann wrote:
> Accessing the THIS_MODULE directly is only possible when modules
> are enabled, otherwise we get a build failure:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: In function 
> 'amdgpu_virt_init_data_exchange':
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing pointer 
> to incomplete type 'struct module'
> 
> Further, THIS_MODULE is NULL when the driver is built-in, so the
> code would likely cause a NULL pointer dereference.
> 
> This adds an #ifdef check to avoid the compile-time error, plus
> a NULL pointer check before dereferencing THIS_MODULE. It might
> be better to find a way to avoid using the module version
> altogether.
> 
> Fixes: 2dc8f81e4f82 ("drm/amdgpu: SR-IOV data exchange between PF")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Looks like 'str' isn't even used here.

Either way, this change by itself is correct and
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index e97f80f86005..4e4a476593e8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -328,9 +328,11 @@ void amdgpu_virt_init_data_exchange(struct amdgpu_device 
> *adev)
>   sizeof(amdgim_vf2pf_info));
>   AMDGPU_FW_VRAM_VF2PF_READ(adev, driver_version,
>   );
> +#ifdef MODULE
>   if (THIS_MODULE->version != NULL)
>   strcpy(str, THIS_MODULE->version);
>   else
> +#endif
>   strcpy(str, "N/A");
>   AMDGPU_FW_VRAM_VF2PF_WRITE(adev, driver_cert,
>   0);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: AMD, please run Smatch on your driver

2017-11-07 Thread Harry Wentland
Thanks, Dan, for bringing this to our attention. We (the display guys here) 
weren't aware of smatch and will give it a spin and try to address some of the 
remaining items (after your, Dave's, and Ernst's patches).

Harry

On 2017-11-06 06:34 AM, Dan Carpenter wrote:
> Linux-next was offline for the last month and the AMD drm driver went
> through major changes.  Anyway, I'm a bit overwhelmed by the number of
> warnings and I'm not going to be able to go through them all so I'm just
> sending them to you unfiltered.
> 
> Part of the problem is that I'm not running the released version of
> Smatch myself.  That has two effects.  1) The released version is
> crappier than I had imagined.  2) I get *way* more warnings than you see
> which is overwhelming...  So this is mostly my fault and I will try to
> do better.
> 
> Here are the current warnings from Friday's linux-next, lightly edited.
> I know that everyone hates a big dump of static checker warnings...
> Speaking of being ignored, I sent a fix for this one back in August but
> never heard back:
> 
>   drivers/gpu/drm/amd/amdgpu/ci_dpm.c:4553 ci_set_mc_special_registers()
>   error: buffer overflow 'table->mc_reg_address' 16 <= 16
> 
> https://lists.freedesktop.org/archives/amd-gfx/2017-August/012333.html
> 
> So this is partly your fault as well because if you cleaned up static
> checker warnings little by little, then they wouldn't pile up like this.
> Eventually, everyone is going to have to start running Smatch for
> themselves because it scales better than relying on me to do it.
> 
> regards,
> dan carpenter
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:2224 amdgpu_device_init() warn: 
> 'adev->rio_mem' was not released on error
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:2395 amdgpu_device_init() warn: 
> 'adev->rio_mem' was not released on error
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3373 amdgpu_debugfs_regs_write() 
> warn: 'mutex:>pm.mutex' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3377 amdgpu_debugfs_regs_write() 
> warn: 'mutex:>pm.mutex' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3771 amdgpu_debugfs_gpr_read() 
> error: buffer overflow 'data' 1024 <= 4095
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:155 amdgpu_driver_load_kms() warn: we 
> tested 'r' before and it was 'false'
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:689 amdgpu_gem_op_ioctl() warn: 
> should 'robj->tbo.mem.page_alignment << 12' be a 64 bit type?
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:196 amdgpu_cs_parser_init() warn: 
> 'mutex:>ctx->lock' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:674 amdgpu_cs_parser_bos() warn: we 
> tested 'r' before and it was 'false'
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:755 amdgpu_cs_parser_fini() warn: 
> 'mutex:>ctx->lock' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/atombios_i2c.c:72 
> amdgpu_atombios_i2c_process_i2c_ch() warn: impossible condition '(num > 255) 
> => (0-255 > 255)'
> drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c:217 amdgpu_queue_mgr_map() 
> warn: variable dereferenced before check 'mgr' (see line 215)
> drivers/gpu/drm/amd/amdgpu/kv_dpm.c:1618 kv_get_acp_boot_level() warn: always 
> true condition '(table->entries[i]->clk >= 0) => (0-u32max >= 0)'
> drivers/gpu/drm/amd/amdgpu/ci_dpm.c:4560 ci_set_mc_special_registers() error: 
> buffer overflow 'table->mc_reg_address' 16 <= 16
> drivers/gpu/drm/amd/amdgpu/ci_dpm.c:5065 
> ci_request_link_speed_change_before_state_change() warn: missing break? 
> reassigning 'pi->force_pcie_gen'
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5256 gfx_v7_0_get_cu_info() error: 
> buffer overflow 'cu_info->bitmap' 4 <= 4
> drivers/gpu/drm/amd/amdgpu/si.c:1288 si_common_early_init() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:3026 dce_v6_0_pageflip_irq() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/si_dpm.c:6242 
> si_request_link_speed_change_before_state_change() warn: missing break? 
> reassigning 'si_pi->force_pcie_gen'
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:5222 gfx_v8_0_pre_soft_reset() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:7105 gfx_v8_0_get_cu_info() error: 
> buffer overflow 'cu_info->bitmap' 4 <= 4
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3077 gfx_v9_0_soft_reset() warn: we 
> tested 'grbm_soft_reset' before and it was 'true'
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3644 gfx_v9_0_ring_emit_ib_gfx() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:4457 gfx_v9_0_get_cu_info() error: 
> buffer overflow 'cu_info->bitmap' 4 <= 4
> drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:605 amdgpu_cgs_lock_grbm_idx() warn: 
> 'mutex:>grbm_idx_mutex' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/../scheduler/gpu_scheduler.c:696 amd_sched_init() 
> warn: call of 'kthread_create_on_node' with 

Re: [PATCH 3/3] drm/amdgpu/display: fix integer arithmetic problem

2017-11-02 Thread Harry Wentland
On 2017-11-02 07:26 AM, Arnd Bergmann wrote:
> gcc warns about an ambiguous integer calculation:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function 
> 'calculate_bandwidth':
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:534:5: error: this 
> decimal constant is unsigned only in ISO C90 [-Werror]
>  data->lb_line_pitch = bw_ceil2(bw_mul(bw_div(bw_frc_to_fixed(2401171875, 
> 1), bw_int_to_fixed(3)), bw_ceil2(data->source_width_in_lb, 
> bw_int_to_fixed(8))), bw_int_to_fixed(48));
>  ^~~~
> 
> Marking the constant as explicitly unsigned makes it work fine everywhere
> without warnings.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Thanks for these fixes.

Series is
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index 15cbfc400633..4f8a95368ffc 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -531,7 +531,7 @@ static void calculate_bandwidth(
>   }
>   switch (data->lb_bpc[i]) {
>   case 8:
> - data->lb_line_pitch = 
> bw_ceil2(bw_mul(bw_div(bw_frc_to_fixed(2401171875, 1), 
> bw_int_to_fixed(3)), bw_ceil2(data->source_width_in_lb, bw_int_to_fixed(8))), 
> bw_int_to_fixed(48));
> + data->lb_line_pitch = 
> bw_ceil2(bw_mul(bw_div(bw_frc_to_fixed(2401171875ul, 1), 
> bw_int_to_fixed(3)), bw_ceil2(data->source_width_in_lb, bw_int_to_fixed(8))), 
> bw_int_to_fixed(48));
>   break;
>   case 10:
>   data->lb_line_pitch = 
> bw_ceil2(bw_mul(bw_div(bw_frc_to_fixed(300234375, 1000), 
> bw_int_to_fixed(3)), bw_ceil2(data->source_width_in_lb, bw_int_to_fixed(8))), 
> bw_int_to_fixed(48));
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm/amdgpu/display: provide ASSERT macros unconditionally

2017-11-02 Thread Harry Wentland
On 2017-11-02 10:24 AM, Arnd Bergmann wrote:
> It seems impossible to build this driver without setting either
> CONFIG_DEBUG_KERNEL or CONFIG_DEBUG_DRIVER:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h: In function 
> 'set_reg_field_value_ex':
> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132:2: error: implicit 
> declaration of function 'ASSERT'; did you mean 'IS_ERR'? 
> [-Werror=implicit-function-declaration]
> 
> This moves the ASSERT() macro and related helpers outside of
> the #ifdef to get it to build again.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/os_types.h | 4 
>  1 file changed, 4 deletions(-)
> 
> v2: remove accidtental comment change.
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h 
> b/drivers/gpu/drm/amd/display/dc/os_types.h
> index 86170b40b5c5..a87c0329541f 100644
> --- a/drivers/gpu/drm/amd/display/dc/os_types.h
> +++ b/drivers/gpu/drm/amd/display/dc/os_types.h
> @@ -61,8 +61,6 @@
>   * general debug capabilities
>   *
>   */
> -#if defined(CONFIG_DEBUG_KERNEL) || defined(CONFIG_DEBUG_DRIVER)
> -
>  #if defined(CONFIG_HAVE_KGDB) || defined(CONFIG_KGDB)
>  #define ASSERT_CRITICAL(expr) do {   \
>   if (WARN_ON(!(expr))) { \
> @@ -86,8 +84,6 @@
>  
>  #define BREAK_TO_DEBUGGER() ASSERT(0)
>  
> -#endif /* CONFIG_DEBUG_KERNEL || CONFIG_DEBUG_DRIVER */
> -
>  #define DC_ERR(...)  do { \
>   dm_error(__VA_ARGS__); \
>   BREAK_TO_DEBUGGER(); \
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: amd: dc: don't use FP math when Kcov is enabled

2017-12-05 Thread Harry Wentland
On 2017-12-05 07:05 AM, Arnd Bergmann wrote:
> On Mon, Dec 4, 2017 at 9:34 PM, Harry Wentland <harry.wentl...@amd.com> wrote:
>> On 2017-12-04 08:08 AM, Arnd Bergmann wrote:
>>> Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
>>> and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many 
>>> functions
>>> that do a comparison of floating-point variables:
>>>
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `dcn_bw_calc_rq_dlg_ttu':
>>> dcn_calcs.c:(.text+0x263): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `hack_force_pipe_split':
>>> dcn_calcs.c:(.text+0x155b): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `dcn_find_dcfclk_suits_all':
>>> dcn_calcs.c:(.text+0x190e): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `dcn_validate_bandwidth':
>>> dcn_calcs.c:(.text+0xe121): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_mod':
>>> dcn_calc_math.c:(.text+0x22): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_min2':
>>> dcn_calc_math.c:(.text+0xb2): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_ceil2':
>>> dcn_calc_math.c:(.text+0x2a0): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_max3':
>>> dcn_calc_math.c:(.text+0x325): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_max5':
>>> dcn_calc_math.c:(.text+0x3c3): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_log':
>>> dcn_calc_math.c:(.text+0x54e): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> dcn_calc_math.c:(.text+0x57c): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `scaler_settings_calculation':
>>> dcn_calc_auto.c:(.text+0x5c5): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0x137c): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0x9233): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0xb70f): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0x121fd): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `display_pipe_configuration':
>>> dcn_calc_auto.c:(.text+0x15a2f): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>>> dcn_calc_auto.c:(.text+0x17c2d): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>>> dcn_calc_auto.c:(.text+0x19362): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance

Re: [PATCH 1/3] drm/connector: Add generic underscan properties

2018-05-07 Thread Harry Wentland


On 2018-05-07 12:19 PM, Boris Brezillon wrote:
> On Mon, 7 May 2018 18:01:44 +0300
> Ville Syrjälä  wrote:
> 
>> On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillon wrote:
>>> We have 3 drivers defining the "underscan", "underscan hborder" and
>>> "underscan vborder" properties (radeon, amd and nouveau) and we are
>>> about to add the same kind of thing in VC4.
>>>
>>> Define generic underscan props and add new fields to the drm_connector
>>> state so that the property parsing logic can be shared by all DRM
>>> drivers.
>>>
>>> A driver can now attach underscan properties to its connector through
>>> the drm_connector_attach_underscan_properties() helper, and can
>>> check/apply the underscan setup based on the
>>> drm_connector_state->underscan fields.
>>>
>>> Signed-off-by: Boris Brezillon 
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c|  12 
>>>  drivers/gpu/drm/drm_connector.c | 120 
>>> 
>>>  include/drm/drm_connector.h |  78 ++
>>>  3 files changed, 210 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index dc850b4b6e21..b7312bd172c9 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -1278,6 +1278,12 @@ static int drm_atomic_connector_set_property(struct 
>>> drm_connector *connector,
>>> return -EINVAL;
>>> }
>>> state->content_protection = val;
>>> +   } else if (property == connector->underscan_mode_property) {
>>> +   state->underscan.mode = val;
>>> +   } else if (property == connector->underscan_hborder_property) {
>>> +   state->underscan.hborder = val;
>>> +   } else if (property == connector->underscan_vborder_property) {
>>> +   state->underscan.vborder = val;
>>> } else if (connector->funcs->atomic_set_property) {
>>> return connector->funcs->atomic_set_property(connector,
>>> state, property, val);
>>> @@ -1359,6 +1365,12 @@ drm_atomic_connector_get_property(struct 
>>> drm_connector *connector,
>>> *val = state->scaling_mode;
>>> } else if (property == connector->content_protection_property) {
>>> *val = state->content_protection;
>>> +   } else if (property == connector->underscan_mode_property) {
>>> +   *val = state->underscan.mode;
>>> +   } else if (property == connector->underscan_hborder_property) {
>>> +   *val = state->underscan.hborder;
>>> +   } else if (property == connector->underscan_vborder_property) {
>>> +   *val = state->underscan.vborder;
>>> } else if (connector->funcs->atomic_get_property) {
>>> return connector->funcs->atomic_get_property(connector,
>>> state, property, val);
>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>> b/drivers/gpu/drm/drm_connector.c
>>> index dfc8ca1e9413..9937390b8a25 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -914,6 +914,31 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, 
>>> drm_cp_enum_list)
>>>   * can also expose this property to external outputs, in which case they
>>>   * must support "None", which should be the default (since external screens
>>>   * have a built-in scaler).
>>> + *
>>> + * underscan:
>>> + * This properties defines whether underscan is activated or not, and when
>>> + * it is activated, how the horizontal and vertical borders are calculated:
>>> + *
>>> + * off:
>>> + * Underscan is disabled. The output image shouldn't be scaled to
>>> + * take screen borders into account.  
>>
>>> + * on:
>>> + * Underscan is activated and horizontal and vertical borders are
>>> + * specified through the "underscan hborder" and
>>> + * "underscan vborder" properties.  
>>
>> How is the output scaled?
> 
> In HW. The formula is
> 
>   hfactor = (hdisplay - hborder) / hdisplay
>   vfactor = (vdisplay - vborder) / vdisplay
> 
>> What does the user mode hdisplay/vdisplay mean
>> in this case?
> 
> The same as before this patch: the output resolution. You just add
> black margins.
> 
>> What if I want underscan without scaling?
> 
> Then don't involve the DRM driver and do that from userspace: just
> fill the visible portion of the framebuffer and leave the rest black.
> There nothing the DRM driver can do to help with that, except maybe
> exposing the information about the active area of the screen. It would
> be nice to do that, but that means patching all userspace libs to take
> this into account.
> 
>>
>>> + * auto:
>>> + * Underscan is activated and horizontal and vertical borders are
>>> + * automatically chosen by the driver.  
>>
>> Seems overly vague to be useful. You didn't even seem to implement it
>> for vc4.
> 

FWIW, amdgpu treats UNDERSCAN_AUTO like UNDERSCAN_ON. 

Re: [PATCH v2 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

2018-05-16 Thread Harry Wentland
On 2018-05-14 10:05 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> from VESA.
> 
> v2:
> * Fix the comments for kernel-doc
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Signed-off-by: Manasi Navare 
> ---
>  include/drm/drm_dsc.h | 437 
> ++
>  1 file changed, 437 insertions(+)
>  create mode 100644 include/drm/drm_dsc.h
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> new file mode 100644
> index 000..5ee72e8
> --- /dev/null
> +++ b/include/drm/drm_dsc.h
> @@ -0,0 +1,437 @@
> +/*
> + * Copyright (C) 2018 Intel Corp.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * Manasi Navare 
> + */
> +
> +#ifndef DRM_DSC_H_
> +#define DRM_DSC_H_
> +
> +#include 
> +
> +#define DSC_NUM_BUF_RANGES   15
> +
> +/**
> + * struct picture_parameter_set - Represents 128 bytes of Picture Parameter 
> Set
> + *
> + * The VESA DSC standard defines picture parameter set (PPS) which display 
> stream
> + * compression encoders must communicate to decoders. The PPS is encapsulated
> + * in 128 bytes (PPS 0 through PPS 127). The fields in this structure are as 
> per
> + * Table 4.1 in Vesa DSC specification v1.1/v1.2.
> + * The PPS fields that span over more than a byte should be stored in Big 
> Endian
> + * format.
> + */
> +struct picture_parameter_set {
> + /**
> +  * @dsc_version_minor:
> +  * PPS0[3:0] - Contains Minor version of DSC
> +  */
> + u8 dsc_version_minor:4;
> + /**
> +  * @dsc_version_major:
> +  * PPS0[7:4] - Contains major version of DSC
> +  */
> + u8 dsc_version_major:4;
> + /**
> +  * @pps_identifier:
> +  * PPS1[7:0] - Application specific identifier that can be
> +  * used to differentiate between different PPS tables.
> +  */
> + u8 pps_identifier;
> + /**
> +  * @pps2_reserved:
> +  * PPS2[7:0]- RESERVED Byte
> +  */
> + u8 pps2_reserved;
> + /**
> +  * @linebuf_depth:
> +  * PPS3[3:0] - Contains linebuffer bit depth used to generate
> +  * the bitstream. (0x0 - 16 bits for DSc 1.2, 0x8 - 8 bits,
> +  * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> +  * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> +  */
> + u8 linebuf_depth:4;
> + /**
> +  * @bits_per_component:
> +  * PPS3[7:4] - Bits per component fo rthe original pixels

typo: "for the"

> +  * of the encoded picture.
> +  */

Would it make sense to indicate in the comments what the values mean?

From the spec:
0x0 = 16bpc (allowed only when dsc_version_minor = 0x2).
0x8 = 8bpc.
0xA = 10bpc.
0xC = 12bpc.
0xE = 14bpc (allowed only when dsc_version_minor = 0x2).
All other encodings are RESERVED.

Harry

> + u8 bits_per_component:4;
> + /**
> +  * @bpp_high:
> +  * PPS4[1:0] - These are the most significant 2 bits of
> +  * compressed BPP bits_per_pixel[9:0] syntax element.
> +  */
> + u8 bpp_high:2;
> + /**
> +  * @vbr_enable:
> +  * PPS4[2] - 0 = VBR disabled, 1 = VBR enabled
> +  */
> + u8 vbr_enable:1;
> + /**
> +  * @simple_422:
> +  * PPS4[3] - Indicates if decoder drops samples to
> +  * reconstruct the 4:2:2 picture.
> +  */
> + u8 simple_422:1;
> + /**
> +  * @convert_rgb:
> +  * PPS4[4] - Indicates if DSC color space conversion is active
> +  */
> + u8 convert_rgb:1;
> 

Re: [PATCH v2 3/4] drm/dsc: Define VESA Display Stream Compression Capabilities

2018-05-16 Thread Harry Wentland
On 2018-05-14 10:05 PM, Manasi Navare wrote:
> From: Gaurav K Singh 
> 
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
> 
> v2: Define this struct in DRM (From Manasi)
> * Changed the data types to u8/u16 instead of unsigned longs (Manasi)
> * Remove driver specific fields (Manasi)
> * Move this struct definition to DRM (Manasi)
> * Define DSC 1.2 parameters (Manasi)
> * Use DSC_NUM_BUF_RANGES (Manasi)
> * Call it drm_dsc_config (Manasi)
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Gaurav K Singh 
> ---
>  include/drm/drm_dsc.h | 111 
> ++
>  1 file changed, 111 insertions(+)
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index 5ee72e8..04501e2 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -30,6 +30,117 @@
>  
>  #define DSC_NUM_BUF_RANGES   15
>  
> +/* VESA Display Stream Compression DSC 1.2 constants */
> +#define DSC_NUM_BUF_RANGES   15

Duplicate definition of previous line.

Harry

> +
> +/* Configuration for a single Rate Control model range */
> +struct dsc_rc_range_parameters {
> + /* Min Quantization Parameters allowed for this range */
> + u8 range_min_qp;
> + /* Max Quantization Parameters allowed for this range */
> + u8 range_max_qp;
> + /* Bits/group offset to apply to target for this group */
> + u8 range_bpg_offset;
> +};
> +
> +struct drm_dsc_config {
> + /* Bits / component for previous reconstructed line buffer */
> + u8 line_buf_depth;
> + /* Bits per component to code (must be 8, 10, or 12) */
> + u8 bits_per_component;
> + /*
> +  * Flag indicating to do RGB - YCoCg conversion
> +  * and back (should be 1 for RGB input)
> +  */
> + bool convert_rgb;
> + u8 slice_count;
> + /* Slice Width */
> + u16 slice_width;
> + /* Slice Height */
> + u16 slice_height;
> + /*
> +  * 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
> +  * outside of DSC encode/decode algorithm)
> +  */
> + bool enable422;
> + /* Picture Width */
> + u16 pic_width;
> + /* Picture Height */
> + u16 pic_height;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_high;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_low;
> + /* Bits/pixel target << 4 (ie., 4 fractional bits) */
> + u16 bits_per_pixel;
> + /*
> +  * Factor to determine if an edge is present based
> +  * on the bits produced
> +  */
> + u8 rc_edge_factor;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit1;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit0;
> + /* Number of pixels to delay the initial transmission */
> + u16 initial_xmit_delay;
> + /* Number of pixels to delay the VLD on the decoder,not including SSM */
> + u16  initial_dec_delay;
> + /* Block prediction enable */
> + bool block_pred_enable;
> + /* Bits/group offset to use for first line of the slice */
> + u8 first_line_bpg_offset;
> + /* Value to use for RC model offset at slice start */
> + u16 initial_offset;
> + /* Thresholds defining each of the buffer ranges */
> + u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
> + /* Parameters for each of the RC ranges */
> + struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> + /* Total size of RC model */
> + u16 rc_model_size;
> + /* Minimum QP where flatness information is sent */
> + u8 flatness_min_qp;
> + /* Maximum QP where flatness information is sent */
> + u8 flatness_max_qp;
> + /* Initial value for scale factor */
> + u8 initial_scale_value;
> + /* Decrement scale factor every scale_decrement_interval groups */
> + u16 scale_decrement_interval;
> + /* Increment scale factor every scale_increment_interval groups */
> + u16 scale_increment_interval;
> + /* Non-first line BPG offset to use */
> + u16 nfl_bpg_offset;
> + /* BPG offset used to enforce slice bit */
> + u16 slice_bpg_offset;
> + /* Final RC linear transformation offset value */
> + u16 final_offset;
> + /* Enable on-off VBR (ie., disable stuffing bits) */
> + bool vbr_enable;
> + /* Mux word size (in bits) for SSM mode */
> + u8 mux_word_size;
> + /*
> +  * The (max) size in bytes of the "chunks" that are
> +  * used in slice multiplexing
> +  */
> + u16 slice_chunk_size;
> + /* Rate Control buffer siz in bits */
> + 

Re: [PATCH v2 0/4] DRM helpers for Display Stream Compression PPS infoframes

2018-05-16 Thread Harry Wentland
On 2018-05-14 10:05 PM, Manasi Navare wrote:
> VESA Display Stream Compression is a specification for visually losless
> video compression over display links. The DSC standard also defines
> a picture parameter set (PPS) which encoder must communicate to decoders.
> This is done by encapsulating PPS header and payload bytes in an infoframe
> that can be sent to the display sink using secondary data packets
> as defined in DP 1.4 spec.
> 
> This patch series creates a new files drm_dsc.h and drm_dsc.c
> which define all the DSC related structures and helpers that
> can be called by drivers to form DSC PPS infoframes before
> enabling Display Stream compression on eDP/DP/MIPI
> 
> v2:
> *This is a v2 of the original patch series which adds kernel-doc
> hooks for the new dsc files in drm-kms-helpers.rst. (Daniel Vetter)
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> Cc: Anusha Srivatsa <anusha.sriva...@intel.com>

With my comments for patch 2 and 3 addressed patches 1-3 are
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Patch 4 is
Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> 
> Gaurav K Singh (1):
>   drm/dsc: Define VESA Display Stream Compression Capabilities
> 
> Manasi Navare (3):
>   drm/dp: Define payload size for DP SDP PPS packet
>   drm/dsc: Define Display Stream Compression PPS infoframe
>   drm/dsc: Add helpers for DSC picture parameter set infoframes
> 
>  Documentation/gpu/drm-kms-helpers.rst |  12 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_dsc.c | 227 ++
>  include/drm/drm_dp_helper.h   |   1 +
>  include/drm/drm_dsc.h | 564 
> ++
>  5 files changed, 805 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dsc.c
>  create mode 100644 include/drm/drm_dsc.h
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] amdgpu: display: use modern ktime accessors

2018-06-18 Thread Harry Wentland
On 2018-06-18 11:35 AM, Arnd Bergmann wrote:
> getrawmonotonic64() is deprecated because of the nonstandard naming.
> 
> The replacement functions ktime_get_raw_ns() also simplifies the callers.
> 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 8 
>  drivers/gpu/drm/amd/display/dc/dm_services.h   | 5 -
>  2 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c
> index 5a3346124a01..e861929dd981 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c
> @@ -35,14 +35,6 @@
>  #include "amdgpu_dm_irq.h"
>  #include "amdgpu_pm.h"
>  
> -unsigned long long dm_get_timestamp(struct dc_context *ctx)
> -{
> - struct timespec64 time;
> -
> - getrawmonotonic64();
> - return timespec64_to_ns();
> -}
> -
>  unsigned long long dm_get_elapse_time_in_ns(struct dc_context *ctx,
>   unsigned long long current_time_stamp,
>   unsigned long long last_time_stamp)
> diff --git a/drivers/gpu/drm/amd/display/dc/dm_services.h 
> b/drivers/gpu/drm/amd/display/dc/dm_services.h
> index 4ff9b2bba178..eb5ab3978e84 100644
> --- a/drivers/gpu/drm/amd/display/dc/dm_services.h
> +++ b/drivers/gpu/drm/amd/display/dc/dm_services.h
> @@ -339,7 +339,10 @@ bool dm_dmcu_set_pipe(struct dc_context *ctx, unsigned 
> int controller_id);
>  #define dm_log_to_buffer(buffer, size, fmt, args)\
>   vsnprintf(buffer, size, fmt, args)
>  
> -unsigned long long dm_get_timestamp(struct dc_context *ctx);
> +static inline unsigned long long dm_get_timestamp(struct dc_context *ctx)
> +{
> + return ktime_get_raw_ns();
> +}
>  
>  unsigned long long dm_get_elapse_time_in_ns(struct dc_context *ctx,
>   unsigned long long current_time_stamp,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/3] drm: Print bad user modes

2018-06-12 Thread Harry Wentland
On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Print out the modeline when we reject a bad user mode. Avoids having to
> guess why it was rejected.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic.c| 20 +---
>  drivers/gpu/drm/drm_crtc.c  |  4 +++-
>  drivers/gpu/drm/drm_crtc_internal.h |  3 +++
>  drivers/gpu/drm/drm_modes.c |  2 +-
>  4 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d7de83a6c1c2..5fe5e06062a9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -400,10 +400,24 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>   memset(>mode, 0, sizeof(state->mode));
>  
>   if (blob) {
> - if (blob->length != sizeof(struct drm_mode_modeinfo) ||
> - drm_mode_convert_umode(state->crtc->dev, >mode,
> -blob->data))
> + int ret;
> +
> + if (blob->length != sizeof(struct drm_mode_modeinfo)) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] bad mode blob length: 
> %zu\n",
> +  crtc->base.id, crtc->name,
> +  blob->length);
> + return -EINVAL;
> + }
> +
> + ret = drm_mode_convert_umode(crtc->dev,
> +  >mode, blob->data);
> + if (ret) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] invalid mode (ret=%d, 
> status=%s):\n",
> +  crtc->base.id, crtc->name,
> +  ret, 
> drm_get_mode_status_name(state->mode.status));
> + drm_mode_debug_printmodeline(>mode);
>   return -EINVAL;
> + }
>  
>   state->mode_blob = drm_property_blob_get(blob);
>   state->enable = true;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 53828fc8d911..163d82ac7d76 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -649,7 +649,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>  
>   ret = drm_mode_convert_umode(dev, mode, _req->mode);
>   if (ret) {
> - DRM_DEBUG_KMS("Invalid mode\n");
> + DRM_DEBUG_KMS("Invalid mode (ret=%d, status=%s)\n",
> +   ret, 
> drm_get_mode_status_name(mode->status));
> + drm_mode_debug_printmodeline(mode);
>   goto out;
>   }
>  
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 5d307b23a4e6..34499800932a 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -56,6 +56,9 @@ int drm_mode_setcrtc(struct drm_device *dev,
>  int drm_modeset_register_all(struct drm_device *dev);
>  void drm_modeset_unregister_all(struct drm_device *dev);
>  
> +/* drm_modes.c */
> +const char *drm_get_mode_status_name(enum drm_mode_status status);
> +
>  /* IOCTLs */
>  int drm_mode_getresources(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index c78ca0e84ffd..7f552d5fa88e 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1257,7 +1257,7 @@ static const char * const drm_mode_status_names[] = {
>  
>  #undef MODE_STATUS
>  
> -static const char *drm_get_mode_status_name(enum drm_mode_status status)
> +const char *drm_get_mode_status_name(enum drm_mode_status status)
>  {
>   int index = status + 3;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3] drm/atomic: Improve debug messages

2018-06-12 Thread Harry Wentland
On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Print the id/name of the object we're dealing with. Makes it easier to
> figure out what's going on. Also toss in a few extra debug prints that
> might be useful.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic.c | 88 
> ++--
>  1 file changed, 61 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ee4b43b9404e..d7de83a6c1c2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -339,6 +339,7 @@ static s32 __user *get_out_fence_for_crtc(struct 
> drm_atomic_state *state,
>  int drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
>const struct drm_display_mode *mode)
>  {
> + struct drm_crtc *crtc = state->crtc;
>   struct drm_mode_modeinfo umode;
>  
>   /* Early return for no change. */
> @@ -359,13 +360,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
> *state,
>  
>   drm_mode_copy(>mode, mode);
>   state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> -  mode->name, state);
> + DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> +  mode->name, crtc->base.id, crtc->name, state);
>   } else {
>   memset(>mode, 0, sizeof(state->mode));
>   state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
> -  state);
> + DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> +  crtc->base.id, crtc->name, state);
>   }
>  
>   return 0;
> @@ -388,6 +389,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
>  int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
>struct drm_property_blob *blob)
>  {
> + struct drm_crtc *crtc = state->crtc;
> +
>   if (blob == state->mode_blob)
>   return 0;
>  
> @@ -404,12 +407,13 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>  
>   state->mode_blob = drm_property_blob_get(blob);
>   state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> -  state->mode.name, state);
> + DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> +  state->mode.name, crtc->base.id, crtc->name,
> +  state);
>   } else {
>   state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
> -  state);
> + DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> +  crtc->base.id, crtc->name, state);
>   }
>  
>   return 0;
> @@ -539,10 +543,14 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   return -EFAULT;
>  
>   set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> - } else if (crtc->funcs->atomic_set_property)
> + } else if (crtc->funcs->atomic_set_property) {
>   return crtc->funcs->atomic_set_property(crtc, state, property, 
> val);
> - else
> + } else {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] unknown property 
> [PROP:%d:%s]]\n",
> +  crtc->base.id, crtc->name,
> +  property->base.id, property->name);
>   return -EINVAL;
> + }
>  
>   return 0;
>  }
> @@ -799,8 +807,11 @@ static int drm_atomic_plane_set_property(struct 
> drm_plane *plane,
>   } else if (property == plane->alpha_property) {
>   state->alpha = val;
>   } else if (property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
> + if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask: 
> 0x%llx\n",
> +  plane->base.id, plane->name, val);
>   return -EINVAL;
> + }
>   state->rotation = val;
>   } else if (pr

Re: [PATCH] drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()

2018-06-05 Thread Harry Wentland
On 2018-06-04 03:35 PM, Lyude Paul wrote:
> So, unfortunately I recently made the discovery that in the upstream
> kernel, the only reason that amdgpu is not currently suffering from
> issues with runtime PM putting the GPU into suspend while it's driving
> displays is due to the fact that on most prime systems, we have sound
> devices associated with the GPU that hold their own runtime PM ref for
> the GPU.
> 
> What this means however, is that in the event that there isn't any kind
> of sound device active (which can easily be reproduced by building a
> kernel with sound drivers disabled), the GPU will fall asleep even when
> there's displays active. This appears to be in part due to the fact that
> amdgpu has not actually ever relied on it's rpm_idle() function to be
> the only thing keeping it running, and normally grabs it's own power
> references whenever there are displays active (as can be seen with the
> original pre-DC codepath in amdgpu_display_crtc_set_config() in
> amdgpu_display.c). This means it's very likely that this bug was
> introduced during the switch over the DC.
> 
> So to fix this, we start grabbing runtime PM references every time we
> enable a previously disabled CRTC in atomic_commit_tail(). This appears
> to be the correct solution, as it matches up with what i915 does in
> i915/intel_runtime_pm.c.
> 
> The one sideaffect of this is that we ignore the variable that the
> pre-DC code used to use for tracking when it needed runtime PM refs,
> adev->have_disp_power_ref. This is mainly because there's no way for a
> driver to tell whether or not all of it's CRTCs are enabled or disabled
> when we've begun committing an atomic state, as there may be CRTC
> commits happening in parallel that aren't contained within the atomic
> state being committed. So, it's safer to just get/put a reference for
> each CRTC being enabled or disabled in the new atomic state.
> 
> Signed-off-by: Lyude Paul 


I'm not familiar with the runtime_pm stuff, as is painfully obvious from the 
fact that we missed that with the DC driver. That said, from a cursory look at 
runtime_pm.txt, this looks right. 

Reviewed-by: Harry Wentland 

I'll pull this in through the amd-stg tree.

> ---
> As a note, I'm not entirely happy with this fix and I wouldn't be
> surprised if I missed something while looking through amdgpu. So, please
> don't hesistate to suggest a better fix :).

I still don't really like amdgpu_dm_atomic_commit_tail and related functions. 
We have plans to rework these and make them more straight-forward.

Harry

> 
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1dd1142246c2..361b81ef6997 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -4211,6 +4212,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   if (dm_old_crtc_state->stream)
>   remove_stream(adev, acrtc, 
> dm_old_crtc_state->stream);
>  
> + pm_runtime_get_noresume(dev->dev);
> +
>   acrtc->enabled = true;
>   acrtc->hw_mode = new_crtc_state->mode;
>   crtc->hwmode = new_crtc_state->mode;
> @@ -4396,6 +4399,16 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   drm_atomic_helper_wait_for_flip_done(dev, state);
>  
>   drm_atomic_helper_cleanup_planes(dev, state);
> +
> + /* Finally, drop a runtime PM reference for each newly disabled CRTC,
> +  * so we can put the GPU into runtime suspend if we're not driving any
> +  * displays anymore
> +  */
> + pm_runtime_mark_last_busy(dev->dev);
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + if (old_crtc_state->active && !new_crtc_state->active)
> + pm_runtime_put_autosuspend(dev->dev);
> + }
>  }
>  
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


<    1   2   3   4   5   6   7   8   9   10   >