[PATCH 24/29] drm/amd/dal: Add display core
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
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
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
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
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
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)
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
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
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
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
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
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
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
From: Mykola LysenkoCurrently 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
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
From: Andrey GrodzovskyAdd 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
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
From: Mykola LysenkoIn 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
From: Mykola LysenkoWe 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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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, zhoucm1wrote: 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
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
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 Vetterwrote: 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
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()
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.
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
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.
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
On 2017-03-20 05:42 AM, Shirish S wrote: On Mon, Mar 20, 2017 at 1:51 PM, Daniel Vetterwrote: 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
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
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
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
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
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
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
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
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
On 2017-08-16 01:22 PM, Daniel Vetter wrote: > On Wed, Aug 16, 2017 at 7:12 PM, Alex Deucherwrote: >> 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
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
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
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
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
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.
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.
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'?
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
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
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
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.
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.
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
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
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
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
On 2017-09-27 12:48 PM, Daniel Vetter wrote: > On Wed, Sep 27, 2017 at 6:38 PM, Sean Paulwrote: >> 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
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
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
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
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
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
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
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
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
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.
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
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
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änzerwrote: 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
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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