aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-10-09drm/i915/vbt: Add VRR VBT toggleJosé Roberto de Souza1-0/+1
This will be used in future but already adding to VBT so we are updated with VBT changes. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-3-jose.souza@intel.com
2020-10-09drm/i915/vbt: Update the version and expected size of BDB_GENERAL_DEFINITIONS mapJosé Roberto de Souza1-1/+1
This will remove the "Expected child device config size for VBT version 235 not known" debug message seen in TGL, although this is not fixing anything it good to keep our VBT parser updated. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-2-jose.souza@intel.com
2020-10-09drm/i915/vbt: Fix backlight parsing for VBT 234+José Roberto de Souza2-4/+38
Child min_brightness is obsolete from VBT 234+, instead the new min_brightness field in the main structure should be used. This new field is 16 bits wide, so backlight_precision_bits is needed to check if value needs to be scaled down but it is only available in VBT 236+ so working around it by using the also new backlight_level in the main struct. v2: - missed that backlight_data->level is also obsolete v3: - s/backlight/brightness to better match specification - using u16 to specify brightness level instead of a u32 : 16 BSpec: 20149 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-1-jose.souza@intel.com
2020-10-10Merge tag 'drm-misc-next-fixes-2020-10-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-nextDave Airlie3-9/+29
Three fixes for vc4 that addresses dual-display breakages Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201002065243.ry7gp4or3ywhluer@gilmour.lan
2020-10-09drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_initYe Bin1-1/+1
Fix follow warning: Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: ''. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: CONFIG_ACPI... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: 'CONFIG_ACPI'. ...... Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: CONFIG_X86... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: 'CONFIG_X86'. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: _X86_... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: '_X86_'. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: __linux__... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: '__linux__'. Fixes: 97d798b276e9 ("drm/amdgpu: simplify ATIF backlight handling") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ye Bin <yebin10@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: Remove warning for virtual_displayEmily.Deng1-1/+3
Remove the virtual_display warning in drm_crtc_vblank_off when dev->num_crtcs is null. Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Emily.Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: kfd_initialized can be statickernel test robot1-1/+1
Fixes: c7651b73586600 ("drm/amdgpu: Fix handling of KFD initialization failures") Signed-off-by: kernel test robot <lkp@intel.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: setup APU dpm clock table in SMU HW initializationEvan Quan1-11/+11
As the dpm clock table is needed during DC HW initialization. And that (DC HW initialization) comes before smu_late_init() where current APU dpm clock table setup is performed. So, NULL pointer dereference will be triggered. By moving APU dpm clock table setup to smu_hw_init(), this can be avoided. Fixes: 02cf91c113ea ("drm/amd/powerplay: postpone operations not required for hw setup to late_init") Signed-off-by: Evan Quan <evan.quan@amd.com> Reported-by: Dirk Gouders <dirk@gouders.net> Acked-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: prevent spurious warningAlex Deucher1-1/+3
The default auto setting for kcq should not generate a warning. Fixes: a300de40f66b ("drm/amdgpu: introduce a new parameter to configure how many KCQ we want(v5)") Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu/swsmu: fix ARC build errorsAlex Deucher2-4/+24
We want to use the dev_* functions here rather than the pr_* variants. Switch to using dev_warn() which mirrors what we do on other asics. Fixes the following build errors on ARC: ../drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c: In function 'navi10_fill_i2c_req': ../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function 'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration] ../drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c: In function 'sienna_cichlid_fill_i2c_req': ../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function 'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot <lkp@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Evan Quan <evan.quan@amd.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: linux-snps-arc@lists.infradead.org Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/display: Fix OPTC_DATA_FORMAT programmingDmytro Laktyushkin3-16/+11
This should be programmed with timing rather than with odm. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/display: Don't allow pstate if no support in blankAlvin Lee1-1/+1
[Why] We will hang if we report switch in VACTIVE but not in VBLANK and DPG_EN = 1 [How] Block switch in ACTIVE if not supported in BLANK Signed-off-by: Alvin Lee <alvin.lee2@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: Fix inconsistent of format with argument type in amdgpu_xgmi.cYe Bin1-1/+1
Fix follow warning: [drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:249]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ye Bin <yebin10@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_initYe Bin1-1/+1
Fix follow warning: Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: ''. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: CONFIG_ACPI... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: 'CONFIG_ACPI'. ...... Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: CONFIG_X86... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: 'CONFIG_X86'. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: _X86_... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: '_X86_'. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: __linux__... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: '__linux__'. Fixes: 97d798b276e9 ("drm/amdgpu: simplify ATIF backlight handling") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ye Bin <yebin10@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu/swsmu: clean up a bunch of stale interfacesAlex Deucher5-276/+4
These were leftover from the initial implementation, but never used. Drop them. Reviewed-by: Evan Quan <evan.quan@amd.com> Noticed-by: Ryan Taylor <ryan.taylor@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: setup APU dpm clock table in SMU HW initializationEvan Quan1-11/+11
As the dpm clock table is needed during DC HW initialization. And that (DC HW initialization) comes before smu_late_init() where current APU dpm clock table setup is performed. So, NULL pointer dereference will be triggered. By moving APU dpm clock table setup to smu_hw_init(), this can be avoided. Fixes: 02cf91c113ea ("drm/amd/powerplay: postpone operations not required for hw setup to late_init") Signed-off-by: Evan Quan <evan.quan@amd.com> Reported-by: Dirk Gouders <dirk@gouders.net> Acked-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: modify cp_flags to pg_flags in gfx_v10_cntl_power_gatingChangfeng1-1/+1
It needs to use adev->pg_flags other than adev->cg_glags in gfx_v10_cntl_power_gating Signed-off-by: Changfeng <Changfeng.Zhu@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: Remove warning for virtual_displayEmily.Deng1-1/+3
Remove the virtual_display warning in drm_crtc_vblank_off when dev->num_crtcs is null. Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Emily.Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: kfd_initialized can be statickernel test robot1-1/+1
Fixes: c7651b73586600 ("drm/amdgpu: Fix handling of KFD initialization failures") Signed-off-by: kernel test robot <lkp@intel.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09amd/amdgpu_ctx: Use struct_size() helper and kmalloc() (v2)Gustavo A. R. Silva1-1/+1
Make use of the new struct_size() helper instead of the offsetof() idiom. Also, use kmalloc() instead of kcalloc(). v2: squash in kzalloc fix Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amdgpu: Use struct_size() helper in kmalloc()Gustavo A. R. Silva1-2/+1
Make use of the new struct_size() helper instead of the offsetof() idiom. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_ppt_v1_pcie_tableGustavo A. R. Silva3-21/+13
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_ppt_v1_pcie_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7db0bc.7Xivn4K83f7XW0ug%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_ppt_v1_voltage_lookup_tableGustavo A. R. Silva3-15/+7
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_ppt_v1_voltage_lookup_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7d61df.jWrFfnjxGbjSkPOp%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_ppt_v1_mm_clock_voltage_dependency_tableGustavo A. R. Silva3-14/+8
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_ppt_v1_mm_clock_voltage_dependency_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7d61e2.qiTVTyG2pVoG8bb0%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_ppt_v1_clock_voltage_dependency_tableGustavo A. R. Silva3-56/+27
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_ppt_v1_clock_voltage_dependency_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c433c.TTk9rnA+F58kyDUy%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_samu_clock_voltage_dependency_tableGustavo A. R. Silva2-8/+5
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_samu_clock_voltage_dependency_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, save some heap space as the original code is multiplying table->numEntries by sizeof(struct phm_samu_clock_voltage_dependency_table) when it should have been multiplied it by sizeof(struct phm_samu_clock_voltage_dependency_record) instead. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c5d3a.ryM4GmZr3e0JeZy+%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_cac_leakage_tableGustavo A. R. Silva2-9/+6
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_cac_leakage_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, save some heap space as the original code is multiplying table->ucNumEntries by sizeof(struct phm_cac_leakage_table) when it should have been multiplied it by sizeof(struct phm_cac_leakage_record) instead. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c5d38.iT%2FQTjN+659XUDo5%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_vce_clock_voltage_dependency_tableGustavo A. R. Silva2-8/+5
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_vce_clock_voltage_dependency_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, save some heap space as the original code is multiplying table->numEntries by sizeof(struct phm_vce_clock_voltage_dependency_table) when it should have multiplied it by sizeof(struct phm_vce_clock_voltage_dependency_record) instead. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c5d35.pJToGs3H9khZK6ws%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_phase_shedding_limits_tableGustavo A. R. Silva2-9/+5
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_phase_shedding_limits_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, save some heap space as the original code is multiplying ptable->ucNumEntries by sizeof(struct phm_phase_shedding_limits_table) when it should have multiplied it by sizeof(struct phm_phase_shedding_limits_record) instead. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c5d36.6PStUZp2HRxAz7IM%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_acp_clock_voltage_dependency_tableGustavo A. R. Silva2-8/+5
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_acp_clock_voltage_dependency_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, save some heap space as the original code is multiplying table->numEntries by sizeof(struct phm_acp_clock_voltage_dependency_table) when it should have multiplied it by sizeof(phm_acp_clock_voltage_dependency_record) instead. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c5d3c.TyfOhg%2FA6JycL6ZN%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_uvd_clock_voltage_dependency_tableGustavo A. R. Silva2-8/+5
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_uvd_clock_voltage_dependency_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, save some heap space as the original code is multiplying table->numEntries by sizeof(struct phm_uvd_clock_voltage_dependency_table) when it should have multiplied it by sizeof(phm_uvd_clock_voltage_dependency_record) instead. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c433e.pXkC6KsN6HN%2FLdhj%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array in struct phm_clock_arrayGustavo A. R. Silva4-18/+11
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_clock_array, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c433f.ZyMD+YUIVAwiHGVe%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array member in struct vi_dpm_tableGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use a flexible-array member in struct vi_dpm_table instead of a one-element array. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c433c.TTk9rnA+F58kyDUy%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/amd/pm: Replace one-element array with flexible-array memberGustavo A. R. Silva4-12/+8
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct phm_clock_voltage_dependency_table, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Build-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f7c295c.8iqp1Ifc6oiVDq%2F%2F%25lkp@intel.com/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-09drm/i915: s/int/u32/ for aux_offset/alignmentVille Syrjälä1-2/+2
ggtt offsets/alignments are u32 everywhere else. Don't use a signed int for them here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008101608.8652-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-10-09drm/i915: Skip aux plane stuff when there is no aux planeVille Syrjälä2-10/+17
when the hardware isn't going to use the aux plane there's no real point in dealing with the relevant hardware restrictions. So let's just skip all that when not necessary. We can now also remove the offset=~0xfff behaviour for unused color planes. Let's just zero out everyting so as to not leave stale garbage behind to confuse people debugging the code. v2: Explicitly set AUX_DIST to zero when there is no aux plane Reviewed-by: Imre Deak <imre.deak@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201009120028.32422-1-ville.syrjala@linux.intel.com
2020-10-09drm/i915: Set all unused color plane offsets to ~0xfff againVille Syrjälä1-12/+5
When the number of potential color planes grew to 4 we stopped setting all unused color plane offsets to ~0xfff. The code still tries to do this, but actually does nothing since the loop limits are bogus. skl_check_main_surface() actually depends on this ~0xfff behaviour as it will make sure to move the main surface offset below the aux surface offset because the hardware AUX_DIST must be a non-negative value [1], and for simplicity it doesn't bother checking if the AUX plane is actually needed or not. So currently it may end up shuffling the main surface around based on some stale leftover AUX offset. The skl+ plane code also just blindly calculates the AUX_DIST whether or not the AUX plane is actually needed by the hw or not, and that too will now potentially use some stale AUX surface offset in the calculation. Would seem nicer to guarantee a consistent non-negative AUX_DIST always. So bring back the original ~0xfff offset behaviour for unused color planes. Though it doesn't seem super likely that this inconsistency would cause any real issues. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Fixes: 2dfbf9d2873a ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008101608.8652-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-10-09drm/i915: Rename i915_{save,restore}_state()Ville Syrjälä3-46/+42
i915_{save,restore}_state() are actually all about the display. Currently they are split into display part + SWF part. But since the SWF part is also related to the display let's just move that part into its own thing and flip the roles around so that the current display part is the main function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201005171441.26612-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-10-09drm/i915: Wait for VLV/CHV/BXT/GLK DSI panel power cycle delay on rebootVille Syrjälä1-0/+8
As with eDP and LVDS we should also respect the power cycle delay on DSI panels. We are not using the power sequencer for these, and we have no optimizations around the sleep duration, so we just msleep() the whole thing away. Note that the ICL+ DSI code doesn't seem to have any power off/power cycle delay handling whatsoever. The only thing it handles is the power on delay. As that looks pretty busted in general I won't bother dealing with it for the time being. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-10-09drm/i915: Wait for LVDS panel power cycle delay on rebootVille Syrjälä1-0/+10
Just like with eDP let's wait for the power sequencer power cycle delay before we reboot the machine, as otherwise we can't guarantee the panel's minimum power cycle delay will be respected. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-10-09drm/i915: Wait for eDP panel power cycle delay on reboot on all platformsVille Syrjälä3-3/+4
Extend the eDP panel power cycle delay wait on reboot handling to cover all platforms. No reason to think that VLV/CHV are in any way special since the documentation states that the hardware power cycle delay goes back to its default value on reset, and that may not be enough for all panels. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-10-09drm/i915: Replace the VLV/CHV eDP reboot notifier with the .shutdown() hookVille Syrjälä2-46/+14
Currently VLV/CHV use a reboot notifier to make sure the panel power cycle delay isn't violated across a system reboot. Replace that with the new encoder .shutdown() hook. And let's also stop overriding the power cycle delay with the max value. No idea why the current code does that. The already programmed delay should be correct. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-10-09drm/i915: Add an encoder .shutdown() hookVille Syrjälä2-0/+18
Add a new encoder hook .shutdown() which will get called at the end of the pci .shutdown() hook. We shall use this to deal with the panel power cycle delay issues. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-10-09drm/i915: Shut down displays gracefully on rebootVille Syrjälä3-0/+25
Implement the pci .shutdown() hook in order to quiesce the hardware prior to reboot. The main purpose here is to turn all displays off. Some displays/other drivers tend to get confused if the state after reboot isn't exactly as they expected. One specific example was the Dell UP2414Q in MST mode. It would require me to pull the power cord after a reboot or else it would just not come back to life. Sadly I don't have that at hand anymore so not sure if it's still misbehaving without the graceful shutdown, or if we managed to fix something else since I last tested it. For good measure we do a gem suspend as well, so that we match the suspend flow more closely. Also stopping all DMA and whatnot is probably a good idea for kexec. I would expect that some kind of GT reset happens on normal reboot so probably not totally necessary there. v2: Use the pci .shutdown() hook instead of a reboot notifier (Lukas) Do the gem suspend for kexec (Chris) Cc: Lukas Wunner <lukas@wunner.de> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-10-09drm/panfrost: increase readl_relaxed_poll_timeout valuesChristian Hewitt1-2/+2
Amlogic SoC devices report the following errors frequently causing excessive dmesg log spam and early log rotataion, although the errors appear to be harmless as everything works fine: [ 7.202702] panfrost ffe40000.gpu: error powering up gpu L2 [ 7.203760] panfrost ffe40000.gpu: error powering up gpu shader ARM staff have advised increasing the timeout values to eliminate the errors in most normal scenarios, and testing with several different G31/G52 devices shows 20000 to be a reliable value. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Suggested-by: Steven Price <steven.price@arm.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008141738.13560-1-christianshewitt@gmail.com
2020-10-09drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPSThomas Zimmermann1-6/+1
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Joel Stanley <joel@jms.id.au> Acked-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20200603083132.4610-5-tzimmermann@suse.de
2020-10-09drm/atomic: Pass the full state to CRTC atomic enable/disableMaxime Ripard42-88/+129
If the CRTC driver ever needs to access the full DRM state, it can't do so at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state will have cleared the pointer from the struct drm_crtc_state to the struct drm_atomic_state before calling those hooks. In order to allow that, let's pass the full DRM state to atomic_enable and atomic_disable. The conversion was done using the coccinelle script below, built tested on all the drivers and actually tested on vc4. virtual report @@ struct drm_crtc_helper_funcs *FUNCS; identifier dev, state; identifier crtc, crtc_state; @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *state) { <... - FUNCS->atomic_disable(crtc, crtc_state); + FUNCS->atomic_disable(crtc, state); ...> } @@ struct drm_crtc_helper_funcs *FUNCS; identifier dev, state; identifier crtc, crtc_state; @@ drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, struct drm_atomic_state *state) { <... - FUNCS->atomic_enable(crtc, crtc_state); + FUNCS->atomic_enable(crtc, state); ...> } @@ identifier crtc, old_state; @@ struct drm_crtc_helper_funcs { ... - void (*atomic_enable)(struct drm_crtc *crtc, struct drm_crtc_state *old_state); + void (*atomic_enable)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... - void (*atomic_disable)(struct drm_crtc *crtc, struct drm_crtc_state *old_state); + void (*atomic_disable)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... } @ crtc_atomic_func @ identifier helpers; identifier func; @@ ( static struct drm_crtc_helper_funcs helpers = { ..., .atomic_enable = func, ..., }; | static struct drm_crtc_helper_funcs helpers = { ..., .atomic_disable = func, ..., }; ) @ ignores_old_state @ identifier crtc_atomic_func.func; identifier crtc, old_state; @@ void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state) { ... when != old_state } @ adds_old_state depends on crtc_atomic_func && !ignores_old_state @ identifier crtc_atomic_func.func; identifier crtc, old_state; @@ void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state) { + struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, crtc); ... } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; expression E; type T; @@ void func(...) { ... - T state = E; + T crtc_state = E; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; type T; @@ void func(...) { ... - T state; + T crtc_state; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; identifier old_state; identifier crtc; @@ void func(struct drm_crtc *crtc, - struct drm_crtc_state *old_state + struct drm_atomic_state *state ) { ... } @ include depends on adds_old_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_old_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/845aa10ef171fc0ea060495efef142a0c13f7870.1602161031.git-series.maxime@cerno.tech
2020-10-09drm: aspeed: Fix GENMASK misuseOndrej Jirman1-1/+1
Arguments to GENMASK should be msb >= lsb. Signed-off-by: Ondrej Jirman <megous@megous.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20200222235152.242816-1-megous@megous.com
2020-10-09drm/aspeed: Add sysfs for output settingsJoel Stanley1-0/+71
These settings are used by an ASPEED BMC to determine when the host is trying to drive the display over PCIe (vga_pw) and to switch the output between PCIe and the internal graphics device (dac_mux). The valid values for the dac mux are: 00: VGA mode (default, aka PCIe) 01: Graphics CRT (aka BMC internal graphics, this driver) 10: Pass through mode from video input port A 11: Pass through mode from video input port B Values for the read-only vga password register are: 1: Host driving the display 0: Host not driving the display Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20200916083413.777307-1-joel@jms.id.au
2020-10-08drm/amd/display: Change ABM config init interfaceYongqiang Sun3-6/+19
[Why & How] change abm config init interface to support multiple ABMs. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.