- Oct 09, 2020
-
-
Gustavo A. R. Silva authored
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>
-
Gustavo A. R. Silva authored
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:
-
Gustavo A. R. Silva authored
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:
-
Gustavo A. R. Silva authored
drm/amd/pm: Replace one-element array with flexible-array in struct phm_ppt_v1_mm_clock_voltage_dependency_table 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:
-
Gustavo A. R. Silva authored
drm/amd/pm: Replace one-element array with flexible-array in struct phm_ppt_v1_clock_voltage_dependency_table 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:
-
Gustavo A. R. Silva authored
drm/amd/pm: Replace one-element array with flexible-array in struct phm_samu_clock_voltage_dependency_table 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:
-
Gustavo A. R. Silva authored
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:
-
Gustavo A. R. Silva authored
drm/amd/pm: Replace one-element array with flexible-array in struct phm_vce_clock_voltage_dependency_table 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:
-
Gustavo A. R. Silva authored
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:
-
Gustavo A. R. Silva authored
drm/amd/pm: Replace one-element array with flexible-array in struct phm_acp_clock_voltage_dependency_table 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:
-
Gustavo A. R. Silva authored
drm/amd/pm: Replace one-element array with flexible-array in struct phm_uvd_clock_voltage_dependency_table 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:
-
Gustavo A. R. Silva authored
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:
-
Gustavo A. R. Silva authored
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:
-
Gustavo A. R. Silva authored
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:
-
- Oct 07, 2020
-
-
Thong Thai authored
Enable Green_Sardine VCN support and VCN firmware loading v2: use apu flags Signed-off-by:
Thong Thai <thong.thai@amd.com> Signed-off-by:
-
Aaron Liu authored
This patch enable green_sardine_asd.bin loading. v2: use apu flags Signed-off-by:
Aaron Liu <aaron.liu@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Prike Liang <Prike.Liang@amd.com> Signed-off-by:
-
Prike Liang authored
Initialize the SDMA IP for green_sardine. v2: use apu flags Signed-off-by:
-
Prike Liang authored
Enable the gfx base HW function of green_sardine. v2: use apu flags Signed-off-by:
-
Prike Liang authored
This patch adds common ip support for green_sardine. v2: use apu flags, squash in CG/PG enablement v3: rebase Signed-off-by:
-
Prike Liang authored
This patch adds green_sardine support for gpu_info firmware and ip block setting. v2: use apu flag Signed-off-by:
-
Alex Deucher authored
Will be used for Green_Sardine which is a new APU. Signed-off-by: -
Alex Deucher authored
The default auto setting for kcq should not generate a warning. Fixes: a300de40 ("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 authored
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:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Jonathan Kim authored
Add xgmi perfmons for Arcturus. v4: Align with patch 2 with struct improvements v3: Align with patch 2 streamlining perf types versus event config types. v2: Resend for re-review with alignment for v3 in patch 2. Signed-off-by:
Jonathan Kim <jonathan.kim@amd.com> Tested-by:
Chris Freehill <chris.freehill@amd.com> Reviewed-by:
Harish Kasiviswanathan <harish.kasiviswanathan@amd.com> Signed-off-by:
-
Jonathan Kim authored
Non-outbound data metrics are non useful so mark them as legacy. Bucket new perf counters into device and not device ip. Bind events to chip instead of IP. Report available event counters and not number of hw counter banks. Move DF public macros to private since not needed outside of IP version. v5: cleanup by moving per chip configs into structs v4: After more discussion, replace *_LEGACY references with IP references to indicate concept of pmu-typed versus event-config-typed event registration. v3: attr groups const array is global but attr groups are allocated per device which doesn't work and causes problems on memory allocation and de-allocation for pmu unregister. Switch to building const attr groups per pmu instead to simplify solution. v2: add comments on sysfs structure and formatting. Signed-off-by:
-
Jonathan Kim authored
Mapping hw counters per event config will cause ABA problems so map per event instead. v2: Discontinue starting perf counters if add fails. Make it clear what's happening with pmc_start. Signed-off-by:
-
- Oct 05, 2020
-
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
Eryk Brol <eryk.brol@amd.com> Signed-off-by:
-
Anthony Koo authored
Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
-
Alvin Lee authored
[Why] DAL resume from BACO time is longer if we always flush inst_fb [How] Check if backdoor loading to flush inst_fb Signed-off-by:
Alvin Lee <alvin.lee2@amd.com> Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
-
Alvin Lee authored
[Why] When forcing 3D mode in DAL, we set the right address to be the same as the left address. We need to do the same for the meta addresses. [How] Program right meta to be same as left meta. Signed-off-by:
-
Sung Lee authored
[WHY] Currently construction of clock limits gets skipped for diags. This logic would be useful to get tested in diags. [HOW] Copy existing states to clk_table such that update_bw_bounding_box logic gets used to fill the table. Signed-off-by:
Sung Lee <sung.lee@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Aric Cyr authored
[Why] On narrow range monitors without LFC, a margin prevents good utilization of the available range. [How] Decrease the margin for exiting fixed mode and fix the frame counter to reset if a non-consecutive render is found. Signed-off-by:
-
Dmytro Laktyushkin authored
This should be programmed with timing rather than with odm. Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
Charlene Liu authored
[why] HDCP 1.4 failed on SL8800 SW w/a test driver use. [how] Slow down the HW i2c speed when used by HW i2c. This request: each acquired_i2c_engine setup the i2c speed needed and sets the I2c engine for HDCP use at release_engine. This covers SW using HW i2c engine and HDCP using HW i2c engine. for dmcu using HW i2c engine, needs add similar logic in dmcu fw. Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
-
Yongqiang Sun authored
[Why] enable ODM on eDP panel with ABM will result in color difference on the panel due to only one ABM module to set one pipe. [How] Block ABM in case of ODM enabled on eDP. Signed-off-by:
Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Joshua Aberback authored
[Why] When we transfer the WM range table to SMU, they can perform a watermark switch right away. This can be a problem if we're in not in accelerated mode during hw_init as SMU may initiate a dummy p-state change before the rest of the watermarks are programmed. Watermark set A is defined to be sufficient for all cases, so we can copy the values from set A to all other sets, avoiding any issues from SMU doing WM switches. [How] - new hubbub func init_watermarks - copy register values from set A to all other sets - call init_watermarks before calling notify_wm_ranges Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Joshua Aberback authored
[Why] During driver unload, it is expected that p-state switching is supported. If it's not supported, PMFW will hang due to a forced p-state switch. Even if the current timing does not support p-state normally, we still want to force allow because the worst that can happen is underflow. This will match Navi10 behaviour. [How] - new hubbub func to control the force pstate register - force allow when releasing display ownership - registers are inaccessible after due to m_cgs.hwNotAvailable - explicitly disable force signal during hw_init - if driver is disabled and re-enabled, register not cleared otherwise Also, remove DCN3 part of dcn10_init_hw, we will not be going back to it. Signed-off-by:
-
Felipe authored
[WHY] This change was implemented because the comment style was not uniform across the file. In some lines comments were initiated with // and in others they were in between /* ... */. Additionally, the style for multi-line comments was also not uniform and some comment lines were missing the space between the opening /* and the first word of the comment. [HOW] All comments are now in between /*.../*, multi line comments also use /*...*/ and for every comment there is now a space between the opening /* and the first word of the comment. Signed-off-by:
Felipe <Felipe.Clark@amd.com> Acked-by:
-
Aric Cyr authored
[Why] When running games or benchmarking with v-sync disabled, disabling a plane (which is v-sync) can cause underflow. This is caused by flips pending before pipe locking being applied after locks are released and pipes could have been re-arranged or disconnected. This could potentially apply a flip on incorrect pipe. Also, previous logic of always locking pipes was unnecessary. [How] Only lock the pipes when there is a pipe being disabled to increase efficiency. Before the pipes are locked, check that any pending flips are cleared to ensure the flips are applied to the correct pipe. Signed-off-by:
-
Alvin Lee authored
[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:
-
